From fweimer at redhat.com  Sun Mar  1 10:41:55 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Sun, 01 Mar 2015 11:41:55 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <493F2892-E8A4-4547-A68C-EF7E1E61BAB9@oracle.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>	<54F070B6.4070204@redhat.com>
	<54F07D39.8000406@oracle.com>	<54F09192.5070104@redhat.com>
	<493F2892-E8A4-4547-A68C-EF7E1E61BAB9@oracle.com>
Message-ID: <54F2ECF3.8050803@redhat.com>

On 02/27/2015 06:16 PM, Paul Sandoz wrote:
> On Feb 27, 2015, at 4:47 PM, Florian Weimer <fweimer at redhat.com> wrote:
>> I really don't think this tooling support will provide sufficient
>> enticement to developers to maintain separate 7/8/9 source branches of
>> their libraries.  Isn't that the main obstacle, and not the way the bits
>> are delivered?
>>
> 
> What if all the source for 7/8/9 bits were under one project?

Tool support for that is still worse than for separate branches of the
same project.

In general, VCS support for branches is still quite poor because the
sensible thing to do is to develop a feature on the master branch and
then backport it to older release branches as needed.  But such
selective backwards-merging very much lacks VCS support because the
least common ancestor logic build into almost all current tools does not
apply in this scenario.  From a tool perspective, developing the feature
in the oldest relevant release and then merging forward is the only
supported way.  But it's usually bad engineering because you want new
features to use current facilities of the code base.  So the only thing
you have left is to cherry-pick individual patches (I think thats what
?hg transplant? does in Mercurial).

Anyway, you lose the tiny bit of tool support you have for backporting
if you have everything in the same source repository.

> For example, say there is a source file:
> 
>   src/main/java/foo/Foo.java
> 
> whose content is:
> 
>   import sun.misc.BASE64Decoder;
> 
>   public class Foo {
>     // does something with sun.misc.BASE64Decoder	
>   }
> 
> There might be another source file located in the 8 area that overrides that in the unversioned area:
> 
>   src/main-8/java/foo/Foo.java
> 
> whose content is:
> 
>   import java.util.Base64;
> 
>   public class Foo {
>     // does something equivalent with java.util.Base64	
>   }

This really screams preprocessor. :-(

> The public contract of Foo should remain identical across the major Java platform dependent versions, in a more strict sense the public signatures in the byte code should be identical (the jar tool has been modified to check this).

If that's the goal, something like Retroweaver seems far more
appropriate than forcing library authors to maintain separate sources.

Multi-version JAR files seem useful because they will eventually allow
evolution of the class file format.  But I think the current use case
isn't really there, I'm afraid.

-- 
Florian Weimer / Red Hat Product Security


From forax at univ-mlv.fr  Sun Mar  1 11:53:28 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 01 Mar 2015 12:53:28 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <54F2ECF3.8050803@redhat.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>	<54F070B6.4070204@redhat.com>	<54F07D39.8000406@oracle.com>	<54F09192.5070104@redhat.com>	<493F2892-E8A4-4547-A68C-EF7E1E61BAB9@oracle.com>
	<54F2ECF3.8050803@redhat.com>
Message-ID: <54F2FDB8.1000102@univ-mlv.fr>


On 03/01/2015 11:41 AM, Florian Weimer wrote:
> On 02/27/2015 06:16 PM, Paul Sandoz wrote:
>> On Feb 27, 2015, at 4:47 PM, Florian Weimer <fweimer at redhat.com> wrote:
>>> I really don't think this tooling support will provide sufficient
>>> enticement to developers to maintain separate 7/8/9 source branches of
>>> their libraries.  Isn't that the main obstacle, and not the way the bits
>>> are delivered?
>>>
>> What if all the source for 7/8/9 bits were under one project?
> Tool support for that is still worse than for separate branches of the
> same project.
>
> In general, VCS support for branches is still quite poor because the
> sensible thing to do is to develop a feature on the master branch and
> then backport it to older release branches as needed.  But such
> selective backwards-merging very much lacks VCS support because the
> least common ancestor logic build into almost all current tools does not
> apply in this scenario.  From a tool perspective, developing the feature
> in the oldest relevant release and then merging forward is the only
> supported way.  But it's usually bad engineering because you want new
> features to use current facilities of the code base.  So the only thing
> you have left is to cherry-pick individual patches (I think thats what
> ?hg transplant? does in Mercurial).
>
> Anyway, you lose the tiny bit of tool support you have for backporting
> if you have everything in the same source repository.
>
>> For example, say there is a source file:
>>
>>    src/main/java/foo/Foo.java
>>
>> whose content is:
>>
>>    import sun.misc.BASE64Decoder;
>>
>>    public class Foo {
>>      // does something with sun.misc.BASE64Decoder	
>>    }
>>
>> There might be another source file located in the 8 area that overrides that in the unversioned area:
>>
>>    src/main-8/java/foo/Foo.java
>>
>> whose content is:
>>
>>    import java.util.Base64;
>>
>>    public class Foo {
>>      // does something equivalent with java.util.Base64	
>>    }
> This really screams preprocessor. :-(
>
>> The public contract of Foo should remain identical across the major Java platform dependent versions, in a more strict sense the public signatures in the byte code should be identical (the jar tool has been modified to check this).
> If that's the goal, something like Retroweaver seems far more
> appropriate than forcing library authors to maintain separate sources.

yes, i fully agree,
in that case you need to bundle
- a jar compatible with the lastest version
- and some metadata to help the 'retroweaver' to transform the new code 
to the old code.
then you need a special step during the install process where you can 
inspect the dependencies
and choose to run the 'retroweaver' or not.

>
> Multi-version JAR files seem useful because they will eventually allow
> evolution of the class file format.  But I think the current use case
> isn't really there, I'm afraid.

I think being able to ship several versions in one jar is a valid use 
case but the solution seems causing more troubles than just solving this 
use case.

Currently, there are two ways to solve the Base64 issue:
- by loading at runtime either the class that use java.util.Base64 or 
the class sun.misc.BASE64Decoder and use it through an interface
- by using using only one class this a code like this:
      try {
        // use java.util.Base64
      } catch(NoClassDefFoundError e) {
        // use sun.misc.BASE64Decoder
      }
    at compile time, you need to provide a fake empty class 
sun.misc.BASE64Decoder
    that will not be bundled in the destination jar.

R?mi



From ivan.gerasimov at oracle.com  Sun Mar  1 15:10:06 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sun, 01 Mar 2015 18:10:06 +0300
Subject: RFR 8074066: Useless code in share/native/libjava/VM.c
Message-ID: <54F32BCE.9040209@oracle.com>

Hello everybody!

Java_sun_misc_VM_initialize() calls JVM_GetVersionInfo(), but doesn't 
use the results.

This code was added with a massive merge to jdk7 [1].
I wonder if it might be some debugging code.

I propose to delete that, unless someone explains why it is needed.

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

[1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9053bcc8eef0

Sincerely yours,
Ivan



From ivan.gerasimov at oracle.com  Sun Mar  1 15:20:49 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sun, 01 Mar 2015 18:20:49 +0300
Subject: RFR 8074067: Cleanup in java.base/share/native/libjava/Bits.c
Message-ID: <54F32E51.5040601@oracle.com>

Hello everyone!

Code in the file Bits.c can be made a bit shorter:
First, we can remove updating the variables which aren't used:
  103         dstAddr += size;
  138         srcAddr += size;
... and alike.

Second, the 'size' variable may only be updated when 'length' becomes 
less than MBYTE.
The warning not to modify the code which has just been modified was also 
removed.

I've built jdk on all available platforms (both production and debug) to 
make sure the code is still compilable.

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

Sincerely yours,
Ivan



From peter.levart at gmail.com  Sun Mar  1 18:08:30 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 01 Mar 2015 19:08:30 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <54F2FDB8.1000102@univ-mlv.fr>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>	<54F070B6.4070204@redhat.com>	<54F07D39.8000406@oracle.com>	<54F09192.5070104@redhat.com>	<493F2892-E8A4-4547-A68C-EF7E1E61BAB9@oracle.com>	<54F2ECF3.8050803@redhat.com>
	<54F2FDB8.1000102@univ-mlv.fr>
Message-ID: <54F3559E.7010100@gmail.com>

On 03/01/2015 12:53 PM, Remi Forax wrote:
> Currently, there are two ways to solve the Base64 issue:
> - by loading at runtime either the class that use java.util.Base64 or 
> the class sun.misc.BASE64Decoder and use it through an interface 

And this, I think, is also the cleanest way to approach a problem that 
multi-version JAR wants to solve. The only argument against it is that 
it perhaps requires more work and planing, but that doesn't mean it is 
less maintainable. In general one has to split the software into "modules":

- base module (platform independent code) + facade interfaces to access 
platform dependent functionality
- platform dependent module(s) that depend on base module and contain 
implementations of facade interfaces published as services through 
ServiceLoader - one module per "target platform version" / "platform 
dependent feature" combination

Base module is compiled 1st (it does not depend on platform version, so 
it should be compiled with lowest version javac/rt.jar to be able to run 
on any target platform)

Platform dependent module(s) are compiled against classes of base module 
and with javac/rt.jar of the desired target platform(s).


Now if module system of JDK9 had a feature that would enable/disable the 
deployed module conditionally, then that condition could be an exact 
target platform version.

But I know, multi-version JAR wants to solve similar problem for 
pre-JDK9 target platforms too which don't yet have modules. The approach 
to organizing sources and compiling can be the same as described, just 
packaging can then use multi-version JARs instead of "conditional" modules.

One problem I see with requirering that in multi-version JARs each 
version sub-path must have same public classes with same public APIs is 
that IDEs don't like that. They don't like to see multiple versions of 
same class and they paint them red. Refactoring doesn't work correctly 
if IDEs see multiple versions of same class and can never be made to 
work correctly as it would have to keep versions always in sync. I 
always have problems with IDEA when I present it the unix/windows 
versions of classes in JDK build at the same time. This can be solved 
nicely by not requirering that and simply relying on the programmer that 
(s)he knows what (s)he is doing. With interfaces as services and 
implementations locateable via ServiceLoader, one does not have to use 
same names of classes for implementations of interfaces targeting 
different platforms and IDEs will be happy.

Regards, Peter



From forax at univ-mlv.fr  Sun Mar  1 23:37:57 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 02 Mar 2015 00:37:57 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <54F3559E.7010100@gmail.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>	<54F070B6.4070204@redhat.com>	<54F07D39.8000406@oracle.com>	<54F09192.5070104@redhat.com>	<493F2892-E8A4-4547-A68C-EF7E1E61BAB9@oracle.com>	<54F2ECF3.8050803@redhat.com>
	<54F2FDB8.1000102@univ-mlv.fr> <54F3559E.7010100@gmail.com>
Message-ID: <54F3A2D5.8070108@univ-mlv.fr>


On 03/01/2015 07:08 PM, Peter Levart wrote:

Hi Peter,
You can see the whole thing in the opposite way which I think is less 
disruptive in term of tooling.

You only maintain one module which depend on the latest version.
When you ship the module let say as a jar, you also ship the way to 
downgrade it as an executable code.
At install time, when all the modules are known, before trying to create 
the images,
the code that downgrades the module is executed if necessary.
This code can rewrite the whole bytecodes of all the classes the module 
thus ensure backward compatibility without providing binary backward 
compatibility.

It's a win-win-win strategy, your code doesn't live in the past, the 
bytecode rewriter can fail saying there is a problem before runtime (if 
by example a method is missing), you can break the binary backward 
compatibility if this is necessary and still being compatible.

You can see this mechanism as a kind of annotation processor that will 
be executed at install time instead of at compile time.

cheers,
R?mi


> On 03/01/2015 12:53 PM, Remi Forax wrote:
>> Currently, there are two ways to solve the Base64 issue:
>> - by loading at runtime either the class that use java.util.Base64 or 
>> the class sun.misc.BASE64Decoder and use it through an interface 
>
> And this, I think, is also the cleanest way to approach a problem that 
> multi-version JAR wants to solve. The only argument against it is that 
> it perhaps requires more work and planing, but that doesn't mean it is 
> less maintainable. In general one has to split the software into 
> "modules":
>
> - base module (platform independent code) + facade interfaces to 
> access platform dependent functionality
> - platform dependent module(s) that depend on base module and contain 
> implementations of facade interfaces published as services through 
> ServiceLoader - one module per "target platform version" / "platform 
> dependent feature" combination
>
> Base module is compiled 1st (it does not depend on platform version, 
> so it should be compiled with lowest version javac/rt.jar to be able 
> to run on any target platform)
>
> Platform dependent module(s) are compiled against classes of base 
> module and with javac/rt.jar of the desired target platform(s).
>
>
> Now if module system of JDK9 had a feature that would enable/disable 
> the deployed module conditionally, then that condition could be an 
> exact target platform version.
>
> But I know, multi-version JAR wants to solve similar problem for 
> pre-JDK9 target platforms too which don't yet have modules. The 
> approach to organizing sources and compiling can be the same as 
> described, just packaging can then use multi-version JARs instead of 
> "conditional" modules.
>
> One problem I see with requirering that in multi-version JARs each 
> version sub-path must have same public classes with same public APIs 
> is that IDEs don't like that. They don't like to see multiple versions 
> of same class and they paint them red. Refactoring doesn't work 
> correctly if IDEs see multiple versions of same class and can never be 
> made to work correctly as it would have to keep versions always in 
> sync. I always have problems with IDEA when I present it the 
> unix/windows versions of classes in JDK build at the same time. This 
> can be solved nicely by not requirering that and simply relying on the 
> programmer that (s)he knows what (s)he is doing. With interfaces as 
> services and implementations locateable via ServiceLoader, one does 
> not have to use same names of classes for implementations of 
> interfaces targeting different platforms and IDEs will be happy.
>
> Regards, Peter
>



From ivan.gerasimov at oracle.com  Mon Mar  2 07:35:23 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 02 Mar 2015 10:35:23 +0300
Subject: RFR 8055915: (ch) FileDispatcherImpl.truncate0 should use
	SetFileInformationByHandle
Message-ID: <54F412BB.2060303@oracle.com>

Hello!

This is another cleanup proposal.
This change has already been reviewed once [1], though I had to withdraw 
it, as it turned out jdk9 was still tested on older machines at that time.
A few other changes that require Windows Vista or newer were integrated 
since then, so this change shouldn't now break anything.

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

The fix was built and successfully tested with existing regtests on all 
available platforms.

[1] http://mail.openjdk.java.net/pipermail/nio-dev/2014-August/002726.html

Sincerely yours,
Ivan


From Alan.Bateman at oracle.com  Mon Mar  2 07:53:09 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 02 Mar 2015 07:53:09 +0000
Subject: RFR 8055915: (ch) FileDispatcherImpl.truncate0 should use
	SetFileInformationByHandle
In-Reply-To: <54F412BB.2060303@oracle.com>
References: <54F412BB.2060303@oracle.com>
Message-ID: <54F416E5.8080702@oracle.com>

On 02/03/2015 07:35, Ivan Gerasimov wrote:
> Hello!
>
> This is another cleanup proposal.
> This change has already been reviewed once [1], though I had to 
> withdraw it, as it turned out jdk9 was still tested on older machines 
> at that time.
> A few other changes that require Windows Vista or newer were 
> integrated since then, so this change shouldn't now break anything.
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055915
> WEBREV: http://cr.openjdk.java.net/~igerasim/8055915/1/webrev/
>
> The fix was built and successfully tested with existing regtests on 
> all available platforms.
Yes, I think should be okay to push now but should not be back-ported to 
8uX.

-Alan.


From paul.sandoz at oracle.com  Mon Mar  2 09:49:07 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 2 Mar 2015 10:49:07 +0100
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <54F138BE.10503@oracle.com>
References: <8890A88D-98D4-4F22-A71E-9C29A9F5545B@oracle.com>	<D23B81AC-3A4A-43CD-879D-D50F4A631741@oracle.com>	<54DAAA15.3080301@oracle.com>	<05A0E203-F057-4B5B-8C47-0F190CA6D667@oracle.com>	<54DBAC35.1060903@oracle.com>	<5BB0E788-9908-460E-A63F-46C5189CBCB1@oracle.com>	<54DC0D6F.3000406@oracle.com>	<4EB3EE4A-8139-41C8-A5BE-F277091EFAE8@oracle.com>	<54DD4365.3050007@oracle.com>	<5D1880CE-29E9-4C7C-A88B-94566517C905@oracle.com>	<54DE4FF9.6050609@oracle.com>	<67B7F7EA-3B80-458E-9ED3-2C7EAD901C81@oracle.com>	<54F0B4E2.5060003@oracle.com>	<959E1D9F-4445-42B2-94E8-2E8F2106932F@oracle.com>	<54F0BBF1.2000901@oracle.com>	<9BBCF56A-13DF-46E7-A645-36F04FD3881C@oracle.com>	<54F0C3AB.4020203@oracle.com>
	<54F0D643.5060005@oracle.com> <54F0FB9D.4000508@oracle.com>
	<54F138BE.10503@oracle.com>
Message-ID: <D4DCF09D-E0BD-4CD9-808E-521D0077515E@oracle.com>

On Feb 28, 2015, at 4:40 AM, Xueming Shen <xueming.shen at oracle.com> wrote:
> Updated to a static private class for the toMatchResult(). Added a private field MatchResult for the anonymous MatchResult
> wrapper.
> 
> http://cr.openjdk.java.net/~sherman/regex.stream/src/java.base/share/classes/java/util/regex/Matcher.java.sdiff.html
> 

Many thanks, i took most of that code and updated:

http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/src/java.base/share/classes/java/util/regex/Matcher.java.sdiff.html

- additional documentation for replacer function parameter is moved to the main body

- there is no need for an internal MatchResult instance wrapper. It does not protect against state modification, does not protect against escape, creates another object for all matcher instances, and results in more wrapping. The only way we can avoid the first 2 is by using an immutable match result, which has it's own cost that unfortunately we cannot avoid in the results().

Paul.


From ivan.gerasimov at oracle.com  Mon Mar  2 10:03:18 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 02 Mar 2015 13:03:18 +0300
Subject: RFR 8055915: (ch) FileDispatcherImpl.truncate0 should use
	SetFileInformationByHandle
In-Reply-To: <54F416E5.8080702@oracle.com>
References: <54F412BB.2060303@oracle.com> <54F416E5.8080702@oracle.com>
Message-ID: <54F43566.4050801@oracle.com>

Thank you Alan!

Pushed in jdk9.

Sincerely yours,
Ivan

On 02.03.2015 10:53, Alan Bateman wrote:
> On 02/03/2015 07:35, Ivan Gerasimov wrote:
>> Hello!
>>
>> This is another cleanup proposal.
>> This change has already been reviewed once [1], though I had to 
>> withdraw it, as it turned out jdk9 was still tested on older machines 
>> at that time.
>> A few other changes that require Windows Vista or newer were 
>> integrated since then, so this change shouldn't now break anything.
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055915
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8055915/1/webrev/
>>
>> The fix was built and successfully tested with existing regtests on 
>> all available platforms.
> Yes, I think should be okay to push now but should not be back-ported 
> to 8uX.
>
> -Alan.
>
>



From peter.levart at gmail.com  Mon Mar  2 11:25:51 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 02 Mar 2015 12:25:51 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <54F3A2D5.8070108@univ-mlv.fr>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>	<54F070B6.4070204@redhat.com>	<54F07D39.8000406@oracle.com>	<54F09192.5070104@redhat.com>	<493F2892-E8A4-4547-A68C-EF7E1E61BAB9@oracle.com>	<54F2ECF3.8050803@redhat.com>
	<54F2FDB8.1000102@univ-mlv.fr> <54F3559E.7010100@gmail.com>
	<54F3A2D5.8070108@univ-mlv.fr>
Message-ID: <54F448BF.4070605@gmail.com>

On 03/02/2015 12:37 AM, Remi Forax wrote:
>
> On 03/01/2015 07:08 PM, Peter Levart wrote:
>
> Hi Peter,
> You can see the whole thing in the opposite way which I think is less 
> disruptive in term of tooling.
>
> You only maintain one module which depend on the latest version.
> When you ship the module let say as a jar, you also ship the way to 
> downgrade it as an executable code.
> At install time, when all the modules are known, before trying to 
> create the images,
> the code that downgrades the module is executed if necessary.
> This code can rewrite the whole bytecodes of all the classes the 
> module thus ensure backward compatibility without providing binary 
> backward compatibility.
>
> It's a win-win-win strategy, your code doesn't live in the past, the 
> bytecode rewriter can fail saying there is a problem before runtime 
> (if by example a method is missing), you can break the binary backward 
> compatibility if this is necessary and still being compatible.
>
> You can see this mechanism as a kind of annotation processor that will 
> be executed at install time instead of at compile time.
>
> cheers,
> R?mi

Such "way to downgrade executable code" is something that doesn't exist 
(yet)? Is it planned? I imagine this as a kind of compiler. It has to 
understand executable code, identify "problematic platform-dependent 
code sequences / API usages" and convert them to semantically equivalent 
code targeted at specific platform. Who is going to write and support 
such tool? Should it be extensible, so that the application programmer 
can extend and "program" it? How are semantically equivalent code 
sequences targeting specific platform going to be represented? How are 
"problematic platform-dependent code patterns / API usages" going to be 
represented? We already have a language-level way to represent 
semantically equivalent code sequences targeting specific platforms - 
different implementations of the same interface. By choosing the 
appropriate implementation at runtime, we can avoid needing a tool that 
understands executable code and identifies problematic 
platform-dependent code. In terms of tooling, I don't see any problems 
as good IDEs and even Maven already support specifying platform 
dependencies / compilation for different target platforms at the 
module-level in the same project.

But I may be persuaded by a good implementation of such "retroweaver". 
There was one such tool in JDK 1.4 -> 1.5 times.

Regards, Peter

>
>
>> On 03/01/2015 12:53 PM, Remi Forax wrote:
>>> Currently, there are two ways to solve the Base64 issue:
>>> - by loading at runtime either the class that use java.util.Base64 
>>> or the class sun.misc.BASE64Decoder and use it through an interface 
>>
>> And this, I think, is also the cleanest way to approach a problem 
>> that multi-version JAR wants to solve. The only argument against it 
>> is that it perhaps requires more work and planing, but that doesn't 
>> mean it is less maintainable. In general one has to split the 
>> software into "modules":
>>
>> - base module (platform independent code) + facade interfaces to 
>> access platform dependent functionality
>> - platform dependent module(s) that depend on base module and contain 
>> implementations of facade interfaces published as services through 
>> ServiceLoader - one module per "target platform version" / "platform 
>> dependent feature" combination
>>
>> Base module is compiled 1st (it does not depend on platform version, 
>> so it should be compiled with lowest version javac/rt.jar to be able 
>> to run on any target platform)
>>
>> Platform dependent module(s) are compiled against classes of base 
>> module and with javac/rt.jar of the desired target platform(s).
>>
>>
>> Now if module system of JDK9 had a feature that would enable/disable 
>> the deployed module conditionally, then that condition could be an 
>> exact target platform version.
>>
>> But I know, multi-version JAR wants to solve similar problem for 
>> pre-JDK9 target platforms too which don't yet have modules. The 
>> approach to organizing sources and compiling can be the same as 
>> described, just packaging can then use multi-version JARs instead of 
>> "conditional" modules.
>>
>> One problem I see with requirering that in multi-version JARs each 
>> version sub-path must have same public classes with same public APIs 
>> is that IDEs don't like that. They don't like to see multiple 
>> versions of same class and they paint them red. Refactoring doesn't 
>> work correctly if IDEs see multiple versions of same class and can 
>> never be made to work correctly as it would have to keep versions 
>> always in sync. I always have problems with IDEA when I present it 
>> the unix/windows versions of classes in JDK build at the same time. 
>> This can be solved nicely by not requirering that and simply relying 
>> on the programmer that (s)he knows what (s)he is doing. With 
>> interfaces as services and implementations locateable via 
>> ServiceLoader, one does not have to use same names of classes for 
>> implementations of interfaces targeting different platforms and IDEs 
>> will be happy.
>>
>> Regards, Peter
>>
>



From paul.sandoz at oracle.com  Mon Mar  2 13:07:13 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 2 Mar 2015 14:07:13 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <6882C9A35DFB9B4FA2779F7BF5B9757D2070034A6A@GSCMAMP06EX.firmwide.corp.gs.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>
	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
	<54F070B6.4070204@redhat.com> <54F07D39.8000406@oracle.com>
	<54F09192.5070104@redhat.com>
	<493F2892-E8A4-4547-A68C-EF7E1E61BAB9@oracle.com>
	<6882C9A35DFB9B4FA2779F7BF5B9757D2070034A6A@GSCMAMP06EX.firmwide.corp.gs.com>
Message-ID: <EA132EC7-112F-4938-8B5E-A443660F8FFD@oracle.com>

Hi Moh,

On Feb 27, 2015, at 7:23 PM, "Rezaei, Mohammad A." <Mohammad.Rezaei at gs.com> wrote:
> Why do you expect the new classes in the JDK not to be part of the API?

An MVJAR is one unit of release. Should it have two or more public APIs? if so what is it's version and set of dependencies? Can it be deployed to maven central? Are those APIs source and/or binary compatibility?

So far we have taken a strict approach in terms of compatibility as it simplifies certain things at the expense of restricting other things as you have noted. 

Perhaps it's possible to relax that approach to some degree of compatibility? In your use-case could CustomFunction be extended to support Function in a source and binary compatible manner?


In general, as i tried to allude in the design document, there is this tension between: 

1) supporting the same API across multiple versions of the Java platform; and 

2) creating a new major version of the API, breaking compatibility with the old API and starting with a newer base Java platform version. 

This tension is always going to exist, especially for popular libraries. MVJARs is focused on the first case for some definition of "same".

Paul.


> Simple example:
> 
> I have a library that's 5 years old. The API needed the equivalent of java.util.Function (from Java 8), which obviously was not there when I wrote my library. Let's say I had defined CustomFunction and now I want the API to use Function. 
> 
> This sort of useful abstraction has been part and parcel with new JDK's for a long time (e.g. HashTable -> Map [1.2], String -> CharSequence [1.4], Generics [1.5], Deque [1.6], AutoClosable [1.7], a dozen useful functional interfaces [1.8]).
> 
> Currently, my choices are:
> 1) Abandon multi-jdk compatibility and release a new version of library for the new jdk. Keep the new version source compatible by making CustomFunction extend Function (possibly with a default delegating method).
> 2) Have two versions of the code base and release separate jars for each, porting new stuff between the two versions for a while.
> 
> How does an MV jar give me a third choice?
> 
> Thanks
> Moh


From peter.levart at gmail.com  Mon Mar  2 13:31:42 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 02 Mar 2015 14:31:42 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <54EDF7E2.2030401@oracle.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>	<CACzrW9ACv0X==y0Yz_ThjFTy2Erirhr_BZ_GiNAB8X5FoEgf=g@mail.gmail.com>
	<54EDF7E2.2030401@oracle.com>
Message-ID: <54F4663E.6050904@gmail.com>

On 02/25/2015 05:27 PM, Brian Goetz wrote:
>
>
> On 2/12/2015 5:59 PM, Stephen Colebourne wrote:
>>
>>
>> I would expect IDEs to have some considerable work to do.
>
> Agree on the "work" part, but I doubt it is "considerable".
>
> For creating MV JARs, the 'jar' tool does all the heavy lifting.
>
> For running Java apps, the classloader does all the heavy lifting.
>
> For tools that have to consume JARs, the JarFile API does all the 
> heavy lifting.  If you use JarFile, it's a one-line change to the 
> constructor to get a version-specific view of the JAR.
>
> So in each of these cases, the work is limited to:
>  - Figure out how you intend to interact with MVJars;
>  - Configure the appropriate tool (jar tool, JarFile) appropriately; 
> this is generally a matter of new constructor arguments and/or new 
> command line arguments.
>
> So I totally agree there will be lots of things that change, but those 
> changes should be individually quite small (and this is consistent 
> with our experience supporting MVJars in the JDK tools.)
>

One aspect that is overlooked here is the "coding phase" which is 
nowadays performed in IDEs. Refactoring and such. One would like to have 
all versions of a particular class targeting distinct platforms 
accessible in IDE not only for primitive text-editing, but also for 
refactoring. IDEs currently don't like seeing multiple versions of same 
class at the same time. Supporting this in an IDE is a considerable work 
to do, I think, and requires IDE to "understand" multiple source files 
for same class name as distinct versions of the same class which it must 
keep in sync regarding the public API of the class. I don't think any 
IDE has this mechanisms in place currently, but I might be wrong. Does 
anybody know?

Peter



From scolebourne at joda.org  Mon Mar  2 14:00:57 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 2 Mar 2015 14:00:57 +0000
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <54F3A2D5.8070108@univ-mlv.fr>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>
	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
	<54F070B6.4070204@redhat.com>
	<54F07D39.8000406@oracle.com> <54F09192.5070104@redhat.com>
	<493F2892-E8A4-4547-A68C-EF7E1E61BAB9@oracle.com>
	<54F2ECF3.8050803@redhat.com>
	<54F2FDB8.1000102@univ-mlv.fr> <54F3559E.7010100@gmail.com>
	<54F3A2D5.8070108@univ-mlv.fr>
Message-ID: <CACzrW9AT_mzv_TrN0fOz8AxjCd4xAT02cjSE0NJY8Gxf0u9EMQ@mail.gmail.com>

On 1 March 2015 at 23:37, Remi Forax <forax at univ-mlv.fr> wrote:
> You only maintain one module which depend on the latest version.
> When you ship the module let say as a jar, you also ship the way to
> downgrade it as an executable code.
> At install time, when all the modules are known, before trying to create the
> images,
> the code that downgrades the module is executed if necessary.
> This code can rewrite the whole bytecodes of all the classes the module thus
> ensure backward compatibility without providing binary backward
> compatibility.

This direction certainly has potential. In many ways, the biggest
potential benefit any language could bring is the ability to handle
change of code over time (ie. its a huge potential language feature
for any new language). While we've always had deprecation, there is no
actual mechanism in code/compiler/linker terms to ensure that the
client has followed the deprecation (callers just get an error if the
code is removed). Thus, what is really needed is a standard
compiler/language mechanism to map old code to new code.

It would allow a method to be renamed (eg. Duration.getNano() to getNanos())
It would allow a class to be renamed, say java.util.Date to
DumbOldTimestampThing
It would allow an enum constant to be renamed
If done well, it might allow for much more complex refactoring
changes, but there would have to be limits

This comes under the modules banner in my eyes, because modules is
adding a linker step where this kind of stuff could be done. I hope
its on the radar (maybe fore JDK 10 rather than 9), as its a lot more
useful than MVJARs alone (which seem to have a pretty limited use, one
which could be helped over time just by making reflection easier to
use).

Note that this is slightly different to Remi's suggestion, which is
"downgrading" new code to run on an old JDK. Here I'm discussing
"upgrading" old code to run against a newer JDK. Its likely that the
both mechanisms make sense.

Stephen


From Alan.Bateman at oracle.com  Mon Mar  2 15:46:24 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 02 Mar 2015 15:46:24 +0000
Subject: RFR 8074067: Cleanup in java.base/share/native/libjava/Bits.c
In-Reply-To: <54F32E51.5040601@oracle.com>
References: <54F32E51.5040601@oracle.com>
Message-ID: <54F485D0.4020501@oracle.com>

On 01/03/2015 15:20, Ivan Gerasimov wrote:
> Hello everyone!
>
> Code in the file Bits.c can be made a bit shorter:
> First, we can remove updating the variables which aren't used:
>  103         dstAddr += size;
>  138         srcAddr += size;
> ... and alike.
>
> Second, the 'size' variable may only be updated when 'length' becomes 
> less than MBYTE.
> The warning not to modify the code which has just been modified was 
> also removed.
>
> I've built jdk on all available platforms (both production and debug) 
> to make sure the code is still compilable.
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8074067
> WEBREV: http://cr.openjdk.java.net/~igerasim/8074067/0/webrev/
As you've noted, there is no need to update xxxAddr because the position 
is updated during swapping copy. That looks okay to me.

Only updating size for the last chunk is okay too, but that a bit of 
coin toss as to whether to change this as the current code is easy to 
read. The stale comment should be removed of course.

-Alan.


From xueming.shen at oracle.com  Mon Mar  2 16:56:39 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 02 Mar 2015 08:56:39 -0800
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <D4DCF09D-E0BD-4CD9-808E-521D0077515E@oracle.com>
References: <8890A88D-98D4-4F22-A71E-9C29A9F5545B@oracle.com>	<D23B81AC-3A4A-43CD-879D-D50F4A631741@oracle.com>	<54DAAA15.3080301@oracle.com>	<05A0E203-F057-4B5B-8C47-0F190CA6D667@oracle.com>	<54DBAC35.1060903@oracle.com>	<5BB0E788-9908-460E-A63F-46C5189CBCB1@oracle.com>	<54DC0D6F.3000406@oracle.com>	<4EB3EE4A-8139-41C8-A5BE-F277091EFAE8@oracle.com>	<54DD4365.3050007@oracle.com>	<5D1880CE-29E9-4C7C-A88B-94566517C905@oracle.com>	<54DE4FF9.6050609@oracle.com>	<67B7F7EA-3B80-458E-9ED3-2C7EAD901C81@oracle.com>	<54F0B4E2.5060003@oracle.com>	<959E1D9F-4445-42B2-94E8-2E8F2106932F@oracle.com>	<54F0BBF1.2000901@oracle.com>	<9BBCF56A-13DF-46E7-A645-36F04FD3881C@oracle.com>	<54F0C3AB.4020203@oracle.com>	<54F0D643.5060005@oracle.com>
	<54F0FB9D.4000508@oracle.com>	<54F138BE.10503@oracle.com>
	<D4DCF09D-E0BD-4CD9-808E-521D0077515E@oracle.com>
Message-ID: <54F49647.6060507@oracle.com>

Hi Paul, it looks good to me.

Thanks,
-Sherman

On 03/02/2015 01:49 AM, Paul Sandoz wrote:
> On Feb 28, 2015, at 4:40 AM, Xueming Shen<xueming.shen at oracle.com>  wrote:
>> Updated to a static private class for the toMatchResult(). Added a private field MatchResult for the anonymous MatchResult
>> wrapper.
>>
>> http://cr.openjdk.java.net/~sherman/regex.stream/src/java.base/share/classes/java/util/regex/Matcher.java.sdiff.html
>>
> Many thanks, i took most of that code and updated:
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/src/java.base/share/classes/java/util/regex/Matcher.java.sdiff.html
>
> - additional documentation for replacer function parameter is moved to the main body
>
> - there is no need for an internal MatchResult instance wrapper. It does not protect against state modification, does not protect against escape, creates another object for all matcher instances, and results in more wrapping. The only way we can avoid the first 2 is by using an immutable match result, which has it's own cost that unfortunately we cannot avoid in the results().
>
> Paul.



From ecki at zusammenkunft.net  Mon Mar  2 17:30:23 2015
From: ecki at zusammenkunft.net (Bernd)
Date: Mon, 2 Mar 2015 18:30:23 +0100
Subject: com.sun.xml.internal.stream.XMLInputFactoryImpl getProperty - IAE for
	name=null
Message-ID: <CABOR3+w_N0QLA==1=iUMvm6VA1bmp40Nspp1gFeHBD3BwOibjA@mail.gmail.com>

Hello,

I noticed that getProperty(String) will throw an IAE("Property not supported")
when null is specified. I think at least the message should be different
for the null case, as it is missleading (Not sure if NPE can be introduced
into this code now - the javadoc somehow allows it?).

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/com/sun/xml/internal/stream/XMLInputFactoryImpl.java#210

Also the non-null case of a not-supported property does not name the
property which was requested. In my experience this is helpfull to have
those names in the reason message.

Both things combined are somewhat better handled in the setter code, so it
might be best to borrow it:

   if (name == null || !fPropertyManager.containsProperty(name) ) {
     throw new IllegalArgumentException("Property "+name+" is not
supported");
   }

(hasProperty could also be used, it returns false on null).

Gruss
Bernd


From aph at redhat.com  Mon Mar  2 19:30:43 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 02 Mar 2015 19:30:43 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54EDFBA3.6080609@redhat.com>
References: <54EB6DD1.4090803@redhat.com>
	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>
	<54EDFBA3.6080609@redhat.com>
Message-ID: <54F4BA63.5060506@redhat.com>

On 02/25/2015 04:43 PM, Andrew Haley wrote:
> On 02/24/2015 11:18 PM, John Rose wrote:
>> My bottom line:  I think we should use the internal HotSpot
>> API bytes.hpp by surfacing relevant parts of it up into Unsafe.

I have done this except that I have used the Java typenames for the
methods.

>> Looking at the various platform code for bytes.hpp, I suppose
>> one could argue that there are just two cases of interest:
>> A single instruction (x86/arm) and a complicated 4-way
>> switch (sparc/ppc). 

And 32-bit ARM which is usually little-endian with no unaligned
support.

>> Distinct big and little endian access modes are also available
>> on some machines, such as SPARC (ASI_LITTLE, etc.).
>> But I do *not* believe that this capability should be surfaced
>> as distinct intrinsics in Unsafe.  Many cpus and source bases
>> deal with endian-matching simply by adjoining a separate
>> "byte swap" operation to the memory access.  In Java,
>> this is already an intrinsic, {Long,Integer,...}.reverseBytes.
>> And SPARC already optimizes some compositions of
>> byte reversal and memory access to its special ASI_LITTLE
>> instructions.
>>
>> My second bottom line:  Don't multiply endian options.
>> Use reverseBytes calls instead.

I have done this as much as is possible, but methods which assemble
and split sub-words are necessarily endian-dependent.  I have
separated the native big- and little-endian code into two classes,
only one of which will ever be loaded into a system.

>> Suggestion:  Have getIntUnaligned take an optional boolean
>> parameter, which is "bigEndian" (since that's relatively exceptional).
>> An extra line of code can conditionally swap the bytes, taking
>> both the flag and the platform into account.  Default value of the
>> boolean is whatever is natural to the platform.  If you specifically
>> want Java's big-endian order, you specify true, etc.

I've done this in Java.  I tried some HotSpot intrinsic code to handle
the "bigEndian" parameter but foundered when I noticed that
Op_ReverseBytesXX nodes are optional, so an intrinsic might either be
emitted as an instruction or a call to a native method.  This was all
too messy so I reverted to doing it in Java; the code quality does not
seem to suffer as a result of this.  (Another possibility is to define
intrinsics which would only be used if Op_ReverseBytesXX nodes were
supported, but I don't know that such an intrinsic would buy us
anything.)

It wasn't clear to me whether you might also want set-XX-Unaligned
methods with specific endianness, so I didn't write any.

I have not written any Unsafe support for floating-point types.  It's
not clear to me that it is needed.  Perhaps the caller should convert
floating-point types as necessary; what do you think?

There are several places in the JDK where we have special cases for
alignment, endianness, and arrays and some could benefit from use of
these new methods, but except for HeapByteBuffers I haven't changed
anything.

I am aware that the code is uncommented.  I will fix that once we
agree about what to do next.

http://cr.openjdk.java.net/~aph/unaligned.hotspot.1/
http://cr.openjdk.java.net/~aph/unaligned.jdk.2/

Andrew.


From ivan.gerasimov at oracle.com  Mon Mar  2 20:59:12 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 02 Mar 2015 23:59:12 +0300
Subject: RFR 8074067: Cleanup in java.base/share/native/libjava/Bits.c
In-Reply-To: <54F485D0.4020501@oracle.com>
References: <54F32E51.5040601@oracle.com> <54F485D0.4020501@oracle.com>
Message-ID: <54F4CF20.2070003@oracle.com>

Thank you Alan for review!

>>
> As you've noted, there is no need to update xxxAddr because the 
> position is updated during swapping copy. That looks okay to me.
>
> Only updating size for the last chunk is okay too, but that a bit of 
> coin toss as to whether to change this as the current code is easy to 
> read. The stale comment should be removed of course.
>
I agree that readability is important.
Below is the updated webrev.  I couldn't resist to making it a bit 
shorter, though :)

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

I checked that the source can be built on all platforms, despite of the 
warning in the comments.

Sincerely yours,
Ivan



From martinrb at google.com  Mon Mar  2 21:08:14 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 2 Mar 2015 13:08:14 -0800
Subject: RFR 8074067: Cleanup in java.base/share/native/libjava/Bits.c
In-Reply-To: <54F4CF20.2070003@oracle.com>
References: <54F32E51.5040601@oracle.com> <54F485D0.4020501@oracle.com>
	<54F4CF20.2070003@oracle.com>
Message-ID: <CA+kOe088ziEoK9hJk6+L9RHXvHD1NbYv=Ln7C6D_97_yVYpsLw@mail.gmail.com>

slightly safer (more likely to compile everywhere) might be to convert
input length into a size_t immediately and to

#define MBYTE ((size_t)  1048576)

On Mon, Mar 2, 2015 at 12:59 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

> Thank you Alan for review!
>
>
>>>  As you've noted, there is no need to update xxxAddr because the
>> position is updated during swapping copy. That looks okay to me.
>>
>> Only updating size for the last chunk is okay too, but that a bit of coin
>> toss as to whether to change this as the current code is easy to read. The
>> stale comment should be removed of course.
>>
>>  I agree that readability is important.
> Below is the updated webrev.  I couldn't resist to making it a bit
> shorter, though :)
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8074067
> WEBREV: http://cr.openjdk.java.net/~igerasim/8074067/1/webrev/
>
> I checked that the source can be built on all platforms, despite of the
> warning in the comments.
>
> Sincerely yours,
> Ivan
>
>


From Alan.Bateman at oracle.com  Mon Mar  2 21:52:04 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 02 Mar 2015 21:52:04 +0000
Subject: RFR 8074067: Cleanup in java.base/share/native/libjava/Bits.c
In-Reply-To: <CA+kOe088ziEoK9hJk6+L9RHXvHD1NbYv=Ln7C6D_97_yVYpsLw@mail.gmail.com>
References: <54F32E51.5040601@oracle.com>	<54F485D0.4020501@oracle.com>	<54F4CF20.2070003@oracle.com>
	<CA+kOe088ziEoK9hJk6+L9RHXvHD1NbYv=Ln7C6D_97_yVYpsLw@mail.gmail.com>
Message-ID: <54F4DB84.3070907@oracle.com>

On 02/03/2015 21:08, Martin Buchholz wrote:
> slightly safer (more likely to compile everywhere) might be to convert 
> input length into a size_t immediately and to
>
> #define MBYTE ((size_t)  1048576)
>
I'd go with that too.

-Alan


From martinrb at google.com  Mon Mar  2 23:12:08 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 2 Mar 2015 15:12:08 -0800
Subject: stop using mmap for zip I/O
In-Reply-To: <54F07C5F.7060204@oracle.com>
References: <20150226221759.4560B17FDAA@rebar.astron.com>
	<54F03A09.9060507@redhat.com> <54F03E30.6040709@oracle.com>
	<54F0555F.3090200@redhat.com> <54F07C5F.7060204@oracle.com>
Message-ID: <CA+kOe09kB6XxUBwDcK5816x=5HbZ_jqBVNM2WUT=RrD2mKNTXg@mail.gmail.com>

Our experience at Google is also that many people run into crashes when
overwriting zip files.  Our standard answer is "don't do that, then!"
 Instead of the "evil" overwriting cp program, make a temp file, then move
it into place.  More generally, follow a policy of "immutability" for file
contents.  But that's not necessarily easy advice to follow - sometimes you
have to use Other People's Broken Software.

Yes, we could prevent the crashes by using only ordinary file I/O, but
you'd still run into input zip file corruption, so the effect would end up
being similar (but more recoverable - a "friendlier" crash).

A zip file is a kind of filesystem, and recovery from zip file corruption
is similar to recovery from any other kind of filesystem corruption
(especially when your app is partially located on the filesystem in
question).

But turning the SEGV/SIGBUS into a ZipException would definitely be
progress.  It would be nice if hotspot's existing signal handler could
cooperate somehow with zip_util.c to make that happen, but I don't know how
to do that, especially not without increasing coupling between libraries
and VM.

On Fri, Feb 27, 2015 at 6:17 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 27/02/2015 11:30, Andrew Haley wrote:
>
>> On 02/27/2015 09:51 AM, Se?n Coffey wrote:
>>
>>> So we catch the signal, right?  Maybe there's something I'm missing...
>>>>
>>> We don't catch/detect such SEGV's. Would it make sense, is it possible ?
>>>
>> Sure.  There's some fiddly low-level code involved but it's perfectly
>> possible, at least on GNU/Linux.  Maybe it's not worth the effort,
>> though.
>>
>>  The closest is MappedByteBuffer and there is code in hotspot to handle
> the SIGBUS and recover (recover in the form of throw an Error). It should
> be possible to do the same for zip but I assume would require this code to
> go through the VM. Much easier if we just disable mapping the central
> directory. At one point then Sherman and I talked about only mapping the
> directory of rt.jar and other JAR files in the JDK, don't map for zip/JAR
> files elsewhere. This gets easier now because we don't have JAR files in
> the JDK image, hence we just need to flip the default on the property that
> enables/disable this. Better again is Sherman's patch to move from native
> completely, we've had good experience along these lines already with the
> NIO zip provider.
>
> -Alan
>


From joe.darcy at oracle.com  Mon Mar  2 23:25:52 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 02 Mar 2015 15:25:52 -0800
Subject: JDK 9 RFR of JDK-8074126: Correct @see cross-refs to the JLS in
	java.lang[.annotation]
Message-ID: <54F4F180.2030006@oracle.com>

Hello,

Please review the straightforward changes below to correct and 
supplement some @jls links from the core libs area into the Java 
Language Specification. Patch at the end.

Thanks to Helbig Wolfgang for indirectly pointing out this issue on 
jdk9-dev.

Cheers,

-Joe

diff -r c9257ce77b6f 
src/java.base/share/classes/java/lang/FunctionalInterface.java
--- a/src/java.base/share/classes/java/lang/FunctionalInterface.java Mon 
Mar 02 13:37:30 2015 -0800
+++ b/src/java.base/share/classes/java/lang/FunctionalInterface.java Mon 
Mar 02 15:25:00 2015 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2012, 2015, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -60,6 +60,7 @@
   * @jls 4.3.2. The Class Object
   * @jls 9.8 Functional Interfaces
   * @jls 9.4.3 Interface Method Body
+ * @jls 9.6.4.9 @FunctionalInterface
   * @since 1.8
   */
  @Documented
diff -r c9257ce77b6f src/java.base/share/classes/java/lang/Override.java
--- a/src/java.base/share/classes/java/lang/Override.java    Mon Mar 02 
13:37:30 2015 -0800
+++ b/src/java.base/share/classes/java/lang/Override.java    Mon Mar 02 
15:25:00 2015 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -43,7 +43,7 @@
   *
   * @author  Peter von der Ah&eacute;
   * @author  Joshua Bloch
- * @jls 9.6.1.4 @Override
+ * @jls 9.6.4.4 @Override
   * @since 1.5
   */
  @Target(ElementType.METHOD)
diff -r c9257ce77b6f src/java.base/share/classes/java/lang/SafeVarargs.java
--- a/src/java.base/share/classes/java/lang/SafeVarargs.java    Mon Mar 
02 13:37:30 2015 -0800
+++ b/src/java.base/share/classes/java/lang/SafeVarargs.java    Mon Mar 
02 15:25:00 2015 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2010, 2014, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2010, 2015, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -85,7 +85,7 @@
   * @since 1.7
   * @jls 4.7 Reifiable Types
   * @jls 8.4.1 Formal Parameters
- * @jls 9.6.3.7 @SafeVarargs
+ * @jls 9.6.4.7 @SafeVarargs
   */
  @Documented
  @Retention(RetentionPolicy.RUNTIME)
diff -r c9257ce77b6f 
src/java.base/share/classes/java/lang/SuppressWarnings.java
--- a/src/java.base/share/classes/java/lang/SuppressWarnings.java Mon 
Mar 02 13:37:30 2015 -0800
+++ b/src/java.base/share/classes/java/lang/SuppressWarnings.java Mon 
Mar 02 15:25:00 2015 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -47,7 +47,7 @@
   * @jls 4.12.2 Variables of Reference Type
   * @jls 5.1.9 Unchecked Conversion
   * @jls 5.5.2 Checked Casts and Unchecked Casts
- * @jls 9.6.3.5 @SuppressWarnings
+ * @jls 9.6.4.5 @SuppressWarnings
   */
  @Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE})
  @Retention(RetentionPolicy.SOURCE)
diff -r c9257ce77b6f 
src/java.base/share/classes/java/lang/annotation/Inherited.java
--- a/src/java.base/share/classes/java/lang/annotation/Inherited.java 
Mon Mar 02 13:37:30 2015 -0800
+++ b/src/java.base/share/classes/java/lang/annotation/Inherited.java 
Mon Mar 02 15:25:00 2015 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -44,7 +44,7 @@
   *
   * @author  Joshua Bloch
   * @since 1.5
- * @jls 9.6.3.3 @Inherited
+ * @jls 9.6.4.3 @Inherited
   */
  @Documented
  @Retention(RetentionPolicy.RUNTIME)
diff -r c9257ce77b6f 
src/java.base/share/classes/java/lang/annotation/Repeatable.java
--- a/src/java.base/share/classes/java/lang/annotation/Repeatable.java 
Mon Mar 02 13:37:30 2015 -0800
+++ b/src/java.base/share/classes/java/lang/annotation/Repeatable.java 
Mon Mar 02 15:25:00 2015 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2012, 2015, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -33,8 +33,8 @@
   * type</em> for the repeatable annotation type.
   *
   * @since 1.8
- * @jls 9.6 Annotation Types
- * @jls 9.7 Annotations
+ * @jls 9.6.3 Repeatable Annotation Types
+ * @jls 9.7.5 Multiple Annotations of the Same Type
   */
  @Documented
  @Retention(RetentionPolicy.RUNTIME)
diff -r c9257ce77b6f 
src/java.base/share/classes/java/lang/annotation/Retention.java
--- a/src/java.base/share/classes/java/lang/annotation/Retention.java 
Mon Mar 02 13:37:30 2015 -0800
+++ b/src/java.base/share/classes/java/lang/annotation/Retention.java 
Mon Mar 02 15:25:00 2015 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -38,7 +38,7 @@
   *
   * @author  Joshua Bloch
   * @since 1.5
- * @jls 9.6.3.2 @Retention
+ * @jls 9.6.4.2 @Retention
   */
  @Documented
  @Retention(RetentionPolicy.RUNTIME)
diff -r c9257ce77b6f 
src/java.base/share/classes/java/lang/annotation/Target.java
--- a/src/java.base/share/classes/java/lang/annotation/Target.java Mon 
Mar 02 13:37:30 2015 -0800
+++ b/src/java.base/share/classes/java/lang/annotation/Target.java Mon 
Mar 02 15:25:00 2015 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -72,6 +72,7 @@
   * @since 1.5
   * @jls 9.6.4.1 @Target
   * @jls 9.7.4 Where Annotations May Appear
+ * @jls 9.7.5 Multiple Annotations of the Same Type
   */
  @Documented
  @Retention(RetentionPolicy.RUNTIME)



From Lance.Andersen at oracle.com  Mon Mar  2 23:49:30 2015
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Mon, 2 Mar 2015 18:49:30 -0500
Subject: JDK 9 RFR of JDK-8074126: Correct @see cross-refs to the JLS in
	java.lang[.annotation]
In-Reply-To: <54F4F180.2030006@oracle.com>
References: <54F4F180.2030006@oracle.com>
Message-ID: <F3679BD9-8C55-4328-9E98-204EB2882F04@oracle.com>

+1
On Mar 2, 2015, at 6:25 PM, joe darcy <joe.darcy at oracle.com> wrote:

> Hello,
> 
> Please review the straightforward changes below to correct and supplement some @jls links from the core libs area into the Java Language Specification. Patch at the end.
> 
> Thanks to Helbig Wolfgang for indirectly pointing out this issue on jdk9-dev.
> 
> Cheers,
> 
> -Joe
> 
> diff -r c9257ce77b6f src/java.base/share/classes/java/lang/FunctionalInterface.java
> --- a/src/java.base/share/classes/java/lang/FunctionalInterface.java Mon Mar 02 13:37:30 2015 -0800
> +++ b/src/java.base/share/classes/java/lang/FunctionalInterface.java Mon Mar 02 15:25:00 2015 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2012, 2015, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -60,6 +60,7 @@
>  * @jls 4.3.2. The Class Object
>  * @jls 9.8 Functional Interfaces
>  * @jls 9.4.3 Interface Method Body
> + * @jls 9.6.4.9 @FunctionalInterface
>  * @since 1.8
>  */
> @Documented
> diff -r c9257ce77b6f src/java.base/share/classes/java/lang/Override.java
> --- a/src/java.base/share/classes/java/lang/Override.java    Mon Mar 02 13:37:30 2015 -0800
> +++ b/src/java.base/share/classes/java/lang/Override.java    Mon Mar 02 15:25:00 2015 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -43,7 +43,7 @@
>  *
>  * @author  Peter von der Ah&eacute;
>  * @author  Joshua Bloch
> - * @jls 9.6.1.4 @Override
> + * @jls 9.6.4.4 @Override
>  * @since 1.5
>  */
> @Target(ElementType.METHOD)
> diff -r c9257ce77b6f src/java.base/share/classes/java/lang/SafeVarargs.java
> --- a/src/java.base/share/classes/java/lang/SafeVarargs.java    Mon Mar 02 13:37:30 2015 -0800
> +++ b/src/java.base/share/classes/java/lang/SafeVarargs.java    Mon Mar 02 15:25:00 2015 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2010, 2014, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2010, 2015, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -85,7 +85,7 @@
>  * @since 1.7
>  * @jls 4.7 Reifiable Types
>  * @jls 8.4.1 Formal Parameters
> - * @jls 9.6.3.7 @SafeVarargs
> + * @jls 9.6.4.7 @SafeVarargs
>  */
> @Documented
> @Retention(RetentionPolicy.RUNTIME)
> diff -r c9257ce77b6f src/java.base/share/classes/java/lang/SuppressWarnings.java
> --- a/src/java.base/share/classes/java/lang/SuppressWarnings.java Mon Mar 02 13:37:30 2015 -0800
> +++ b/src/java.base/share/classes/java/lang/SuppressWarnings.java Mon Mar 02 15:25:00 2015 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -47,7 +47,7 @@
>  * @jls 4.12.2 Variables of Reference Type
>  * @jls 5.1.9 Unchecked Conversion
>  * @jls 5.5.2 Checked Casts and Unchecked Casts
> - * @jls 9.6.3.5 @SuppressWarnings
> + * @jls 9.6.4.5 @SuppressWarnings
>  */
> @Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE})
> @Retention(RetentionPolicy.SOURCE)
> diff -r c9257ce77b6f src/java.base/share/classes/java/lang/annotation/Inherited.java
> --- a/src/java.base/share/classes/java/lang/annotation/Inherited.java Mon Mar 02 13:37:30 2015 -0800
> +++ b/src/java.base/share/classes/java/lang/annotation/Inherited.java Mon Mar 02 15:25:00 2015 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -44,7 +44,7 @@
>  *
>  * @author  Joshua Bloch
>  * @since 1.5
> - * @jls 9.6.3.3 @Inherited
> + * @jls 9.6.4.3 @Inherited
>  */
> @Documented
> @Retention(RetentionPolicy.RUNTIME)
> diff -r c9257ce77b6f src/java.base/share/classes/java/lang/annotation/Repeatable.java
> --- a/src/java.base/share/classes/java/lang/annotation/Repeatable.java Mon Mar 02 13:37:30 2015 -0800
> +++ b/src/java.base/share/classes/java/lang/annotation/Repeatable.java Mon Mar 02 15:25:00 2015 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2012, 2015, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -33,8 +33,8 @@
>  * type</em> for the repeatable annotation type.
>  *
>  * @since 1.8
> - * @jls 9.6 Annotation Types
> - * @jls 9.7 Annotations
> + * @jls 9.6.3 Repeatable Annotation Types
> + * @jls 9.7.5 Multiple Annotations of the Same Type
>  */
> @Documented
> @Retention(RetentionPolicy.RUNTIME)
> diff -r c9257ce77b6f src/java.base/share/classes/java/lang/annotation/Retention.java
> --- a/src/java.base/share/classes/java/lang/annotation/Retention.java Mon Mar 02 13:37:30 2015 -0800
> +++ b/src/java.base/share/classes/java/lang/annotation/Retention.java Mon Mar 02 15:25:00 2015 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -38,7 +38,7 @@
>  *
>  * @author  Joshua Bloch
>  * @since 1.5
> - * @jls 9.6.3.2 @Retention
> + * @jls 9.6.4.2 @Retention
>  */
> @Documented
> @Retention(RetentionPolicy.RUNTIME)
> diff -r c9257ce77b6f src/java.base/share/classes/java/lang/annotation/Target.java
> --- a/src/java.base/share/classes/java/lang/annotation/Target.java Mon Mar 02 13:37:30 2015 -0800
> +++ b/src/java.base/share/classes/java/lang/annotation/Target.java Mon Mar 02 15:25:00 2015 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -72,6 +72,7 @@
>  * @since 1.5
>  * @jls 9.6.4.1 @Target
>  * @jls 9.7.4 Where Annotations May Appear
> + * @jls 9.7.5 Multiple Annotations of the Same Type
>  */
> @Documented
> @Retention(RetentionPolicy.RUNTIME)
> 




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






From joe.darcy at oracle.com  Mon Mar  2 23:56:12 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 02 Mar 2015 15:56:12 -0800
Subject: JDK 9 RFR of JDK-8074126: Correct @see cross-refs to the JLS
	in java.lang[.annotation]
In-Reply-To: <F3679BD9-8C55-4328-9E98-204EB2882F04@oracle.com>
References: <54F4F180.2030006@oracle.com>
	<F3679BD9-8C55-4328-9E98-204EB2882F04@oracle.com>
Message-ID: <54F4F89C.9090901@oracle.com>

PS Taking another scan of the changes, I'll also add links to the JLS 
discussion of overriding in classes (chapter 8) and interfaces (chapter 
9)  to the Override annotation:

diff -r c9257ce77b6f src/java.base/share/classes/java/lang/Override.java
--- a/src/java.base/share/classes/java/lang/Override.java    Mon Mar 02 
13:37:30 2015 -0800
+++ b/src/java.base/share/classes/java/lang/Override.java    Mon Mar 02 
15:53:36 2015 -0800
@@ -43,7 +43,9 @@
   *
   * @author  Peter von der Ah&eacute;
   * @author  Joshua Bloch
- * @jls 9.6.1.4 @Override
+ * @jls 8.4.8 Inheritance, Overriding, and Hiding
+ * @jls 9.4.1 Inheritance and Overriding
+ * @jls 9.6.4.4 @Override
   * @since 1.5
   */

Thanks for the quick review,

-Joe

On 3/2/2015 3:49 PM, Lance Andersen wrote:
> +1
> On Mar 2, 2015, at 6:25 PM, joe darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>> Hello,
>>
>> Please review the straightforward changes below to correct and 
>> supplement some @jls links from the core libs area into the Java 
>> Language Specification. Patch at the end.
>>
>> Thanks to Helbig Wolfgang for indirectly pointing out this issue on 
>> jdk9-dev.
>>
>> Cheers,
>>
>> -Joe
>>
>> diff -r c9257ce77b6f 
>> src/java.base/share/classes/java/lang/FunctionalInterface.java
>> --- a/src/java.base/share/classes/java/lang/FunctionalInterface.java 
>> Mon Mar 02 13:37:30 2015 -0800
>> +++ b/src/java.base/share/classes/java/lang/FunctionalInterface.java 
>> Mon Mar 02 15:25:00 2015 -0800
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 2012, 2015, Oracle and/or its affiliates. All 
>> rights reserved.
>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>  *
>>  * This code is free software; you can redistribute it and/or modify it
>> @@ -60,6 +60,7 @@
>>  * @jls 4.3.2. The Class Object
>>  * @jls 9.8 Functional Interfaces
>>  * @jls 9.4.3 Interface Method Body
>> + * @jls 9.6.4.9 @FunctionalInterface
>>  * @since 1.8
>>  */
>> @Documented
>> diff -r c9257ce77b6f src/java.base/share/classes/java/lang/Override.java
>> --- a/src/java.base/share/classes/java/lang/Override.java    Mon Mar 
>> 02 13:37:30 2015 -0800
>> +++ b/src/java.base/share/classes/java/lang/Override.java    Mon Mar 
>> 02 15:25:00 2015 -0800
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All 
>> rights reserved.
>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>  *
>>  * This code is free software; you can redistribute it and/or modify it
>> @@ -43,7 +43,7 @@
>>  *
>>  * @author  Peter von der Ah&eacute;
>>  * @author  Joshua Bloch
>> - * @jls 9.6.1.4 @Override
>> + * @jls 9.6.4.4 @Override
>>  * @since 1.5
>>  */
>> @Target(ElementType.METHOD)
>> diff -r c9257ce77b6f 
>> src/java.base/share/classes/java/lang/SafeVarargs.java
>> --- a/src/java.base/share/classes/java/lang/SafeVarargs.java    Mon 
>> Mar 02 13:37:30 2015 -0800
>> +++ b/src/java.base/share/classes/java/lang/SafeVarargs.java    Mon 
>> Mar 02 15:25:00 2015 -0800
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2010, 2014, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 2010, 2015, Oracle and/or its affiliates. All 
>> rights reserved.
>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>  *
>>  * This code is free software; you can redistribute it and/or modify it
>> @@ -85,7 +85,7 @@
>>  * @since 1.7
>>  * @jls 4.7 Reifiable Types
>>  * @jls 8.4.1 Formal Parameters
>> - * @jls 9.6.3.7 @SafeVarargs
>> + * @jls 9.6.4.7 @SafeVarargs
>>  */
>> @Documented
>> @Retention(RetentionPolicy.RUNTIME)
>> diff -r c9257ce77b6f 
>> src/java.base/share/classes/java/lang/SuppressWarnings.java
>> --- a/src/java.base/share/classes/java/lang/SuppressWarnings.java Mon 
>> Mar 02 13:37:30 2015 -0800
>> +++ b/src/java.base/share/classes/java/lang/SuppressWarnings.java Mon 
>> Mar 02 15:25:00 2015 -0800
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2004, 2013, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All 
>> rights reserved.
>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>  *
>>  * This code is free software; you can redistribute it and/or modify it
>> @@ -47,7 +47,7 @@
>>  * @jls 4.12.2 Variables of Reference Type
>>  * @jls 5.1.9 Unchecked Conversion
>>  * @jls 5.5.2 Checked Casts and Unchecked Casts
>> - * @jls 9.6.3.5 @SuppressWarnings
>> + * @jls 9.6.4.5 @SuppressWarnings
>>  */
>> @Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE})
>> @Retention(RetentionPolicy.SOURCE)
>> diff -r c9257ce77b6f 
>> src/java.base/share/classes/java/lang/annotation/Inherited.java
>> --- a/src/java.base/share/classes/java/lang/annotation/Inherited.java 
>> Mon Mar 02 13:37:30 2015 -0800
>> +++ b/src/java.base/share/classes/java/lang/annotation/Inherited.java 
>> Mon Mar 02 15:25:00 2015 -0800
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All 
>> rights reserved.
>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>  *
>>  * This code is free software; you can redistribute it and/or modify it
>> @@ -44,7 +44,7 @@
>>  *
>>  * @author  Joshua Bloch
>>  * @since 1.5
>> - * @jls 9.6.3.3 @Inherited
>> + * @jls 9.6.4.3 @Inherited
>>  */
>> @Documented
>> @Retention(RetentionPolicy.RUNTIME)
>> diff -r c9257ce77b6f 
>> src/java.base/share/classes/java/lang/annotation/Repeatable.java
>> --- 
>> a/src/java.base/share/classes/java/lang/annotation/Repeatable.java 
>> Mon Mar 02 13:37:30 2015 -0800
>> +++ 
>> b/src/java.base/share/classes/java/lang/annotation/Repeatable.java 
>> Mon Mar 02 15:25:00 2015 -0800
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 2012, 2015, Oracle and/or its affiliates. All 
>> rights reserved.
>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>  *
>>  * This code is free software; you can redistribute it and/or modify it
>> @@ -33,8 +33,8 @@
>>  * type</em> for the repeatable annotation type.
>>  *
>>  * @since 1.8
>> - * @jls 9.6 Annotation Types
>> - * @jls 9.7 Annotations
>> + * @jls 9.6.3 Repeatable Annotation Types
>> + * @jls 9.7.5 Multiple Annotations of the Same Type
>>  */
>> @Documented
>> @Retention(RetentionPolicy.RUNTIME)
>> diff -r c9257ce77b6f 
>> src/java.base/share/classes/java/lang/annotation/Retention.java
>> --- a/src/java.base/share/classes/java/lang/annotation/Retention.java 
>> Mon Mar 02 13:37:30 2015 -0800
>> +++ b/src/java.base/share/classes/java/lang/annotation/Retention.java 
>> Mon Mar 02 15:25:00 2015 -0800
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All 
>> rights reserved.
>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>  *
>>  * This code is free software; you can redistribute it and/or modify it
>> @@ -38,7 +38,7 @@
>>  *
>>  * @author  Joshua Bloch
>>  * @since 1.5
>> - * @jls 9.6.3.2 @Retention
>> + * @jls 9.6.4.2 @Retention
>>  */
>> @Documented
>> @Retention(RetentionPolicy.RUNTIME)
>> diff -r c9257ce77b6f 
>> src/java.base/share/classes/java/lang/annotation/Target.java
>> --- a/src/java.base/share/classes/java/lang/annotation/Target.java 
>> Mon Mar 02 13:37:30 2015 -0800
>> +++ b/src/java.base/share/classes/java/lang/annotation/Target.java 
>> Mon Mar 02 15:25:00 2015 -0800
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All 
>> rights reserved.
>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>  *
>>  * This code is free software; you can redistribute it and/or modify it
>> @@ -72,6 +72,7 @@
>>  * @since 1.5
>>  * @jls 9.6.4.1 @Target
>>  * @jls 9.7.4 Where Annotations May Appear
>> + * @jls 9.7.5 Multiple Annotations of the Same Type
>>  */
>> @Documented
>> @Retention(RetentionPolicy.RUNTIME)
>>
>
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance.Andersen at oracle.com 
> <mailto:Lance.Andersen at oracle.com>
>
>
>
>



From Lance.Andersen at oracle.com  Mon Mar  2 23:59:10 2015
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Mon, 2 Mar 2015 18:59:10 -0500
Subject: JDK 9 RFR of JDK-8074126: Correct @see cross-refs to the JLS in
	java.lang[.annotation]
In-Reply-To: <54F4F89C.9090901@oracle.com>
References: <54F4F180.2030006@oracle.com>
	<F3679BD9-8C55-4328-9E98-204EB2882F04@oracle.com>
	<54F4F89C.9090901@oracle.com>
Message-ID: <6C126276-1424-4DF3-9922-85086AF4225C@oracle.com>

+1 * 2 :-)
On Mar 2, 2015, at 6:56 PM, joe darcy <joe.darcy at oracle.com> wrote:

> PS Taking another scan of the changes, I'll also add links to the JLS discussion of overriding in classes (chapter 8) and interfaces (chapter 9)  to the Override annotation: 
> 
> diff -r c9257ce77b6f src/java.base/share/classes/java/lang/Override.java
> --- a/src/java.base/share/classes/java/lang/Override.java    Mon Mar 02 13:37:30 2015 -0800
> +++ b/src/java.base/share/classes/java/lang/Override.java    Mon Mar 02 15:53:36 2015 -0800
> @@ -43,7 +43,9 @@
>   *
>   * @author  Peter von der Ah&eacute;
>   * @author  Joshua Bloch
> - * @jls 9.6.1.4 @Override
> + * @jls 8.4.8 Inheritance, Overriding, and Hiding
> + * @jls 9.4.1 Inheritance and Overriding
> + * @jls 9.6.4.4 @Override
>   * @since 1.5
>   */
> 
> Thanks for the quick review,
> 
> -Joe
> 
> On 3/2/2015 3:49 PM, Lance Andersen wrote:
>> +1
>> On Mar 2, 2015, at 6:25 PM, joe darcy <joe.darcy at oracle.com> wrote:
>> 
>>> Hello,
>>> 
>>> Please review the straightforward changes below to correct and supplement some @jls links from the core libs area into the Java Language Specification. Patch at the end.
>>> 
>>> Thanks to Helbig Wolfgang for indirectly pointing out this issue on jdk9-dev.
>>> 
>>> Cheers,
>>> 
>>> -Joe
>>> 
>>> diff -r c9257ce77b6f src/java.base/share/classes/java/lang/FunctionalInterface.java
>>> --- a/src/java.base/share/classes/java/lang/FunctionalInterface.java Mon Mar 02 13:37:30 2015 -0800
>>> +++ b/src/java.base/share/classes/java/lang/FunctionalInterface.java Mon Mar 02 15:25:00 2015 -0800
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2012, 2015, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -60,6 +60,7 @@
>>>  * @jls 4.3.2. The Class Object
>>>  * @jls 9.8 Functional Interfaces
>>>  * @jls 9.4.3 Interface Method Body
>>> + * @jls 9.6.4.9 @FunctionalInterface
>>>  * @since 1.8
>>>  */
>>> @Documented
>>> diff -r c9257ce77b6f src/java.base/share/classes/java/lang/Override.java
>>> --- a/src/java.base/share/classes/java/lang/Override.java    Mon Mar 02 13:37:30 2015 -0800
>>> +++ b/src/java.base/share/classes/java/lang/Override.java    Mon Mar 02 15:25:00 2015 -0800
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -43,7 +43,7 @@
>>>  *
>>>  * @author  Peter von der Ah&eacute;
>>>  * @author  Joshua Bloch
>>> - * @jls 9.6.1.4 @Override
>>> + * @jls 9.6.4.4 @Override
>>>  * @since 1.5
>>>  */
>>> @Target(ElementType.METHOD)
>>> diff -r c9257ce77b6f src/java.base/share/classes/java/lang/SafeVarargs.java
>>> --- a/src/java.base/share/classes/java/lang/SafeVarargs.java    Mon Mar 02 13:37:30 2015 -0800
>>> +++ b/src/java.base/share/classes/java/lang/SafeVarargs.java    Mon Mar 02 15:25:00 2015 -0800
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2010, 2014, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2010, 2015, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -85,7 +85,7 @@
>>>  * @since 1.7
>>>  * @jls 4.7 Reifiable Types
>>>  * @jls 8.4.1 Formal Parameters
>>> - * @jls 9.6.3.7 @SafeVarargs
>>> + * @jls 9.6.4.7 @SafeVarargs
>>>  */
>>> @Documented
>>> @Retention(RetentionPolicy.RUNTIME)
>>> diff -r c9257ce77b6f src/java.base/share/classes/java/lang/SuppressWarnings.java
>>> --- a/src/java.base/share/classes/java/lang/SuppressWarnings.java Mon Mar 02 13:37:30 2015 -0800
>>> +++ b/src/java.base/share/classes/java/lang/SuppressWarnings.java Mon Mar 02 15:25:00 2015 -0800
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -47,7 +47,7 @@
>>>  * @jls 4.12.2 Variables of Reference Type
>>>  * @jls 5.1.9 Unchecked Conversion
>>>  * @jls 5.5.2 Checked Casts and Unchecked Casts
>>> - * @jls 9.6.3.5 @SuppressWarnings
>>> + * @jls 9.6.4.5 @SuppressWarnings
>>>  */
>>> @Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE})
>>> @Retention(RetentionPolicy.SOURCE)
>>> diff -r c9257ce77b6f src/java.base/share/classes/java/lang/annotation/Inherited.java
>>> --- a/src/java.base/share/classes/java/lang/annotation/Inherited.java Mon Mar 02 13:37:30 2015 -0800
>>> +++ b/src/java.base/share/classes/java/lang/annotation/Inherited.java Mon Mar 02 15:25:00 2015 -0800
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -44,7 +44,7 @@
>>>  *
>>>  * @author  Joshua Bloch
>>>  * @since 1.5
>>> - * @jls 9.6.3.3 @Inherited
>>> + * @jls 9.6.4.3 @Inherited
>>>  */
>>> @Documented
>>> @Retention(RetentionPolicy.RUNTIME)
>>> diff -r c9257ce77b6f src/java.base/share/classes/java/lang/annotation/Repeatable.java
>>> --- a/src/java.base/share/classes/java/lang/annotation/Repeatable.java Mon Mar 02 13:37:30 2015 -0800
>>> +++ b/src/java.base/share/classes/java/lang/annotation/Repeatable.java Mon Mar 02 15:25:00 2015 -0800
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2012, 2015, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -33,8 +33,8 @@
>>>  * type</em> for the repeatable annotation type.
>>>  *
>>>  * @since 1.8
>>> - * @jls 9.6 Annotation Types
>>> - * @jls 9.7 Annotations
>>> + * @jls 9.6.3 Repeatable Annotation Types
>>> + * @jls 9.7.5 Multiple Annotations of the Same Type
>>>  */
>>> @Documented
>>> @Retention(RetentionPolicy.RUNTIME)
>>> diff -r c9257ce77b6f src/java.base/share/classes/java/lang/annotation/Retention.java
>>> --- a/src/java.base/share/classes/java/lang/annotation/Retention.java Mon Mar 02 13:37:30 2015 -0800
>>> +++ b/src/java.base/share/classes/java/lang/annotation/Retention.java Mon Mar 02 15:25:00 2015 -0800
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -38,7 +38,7 @@
>>>  *
>>>  * @author  Joshua Bloch
>>>  * @since 1.5
>>> - * @jls 9.6.3.2 @Retention
>>> + * @jls 9.6.4.2 @Retention
>>>  */
>>> @Documented
>>> @Retention(RetentionPolicy.RUNTIME)
>>> diff -r c9257ce77b6f src/java.base/share/classes/java/lang/annotation/Target.java
>>> --- a/src/java.base/share/classes/java/lang/annotation/Target.java Mon Mar 02 13:37:30 2015 -0800
>>> +++ b/src/java.base/share/classes/java/lang/annotation/Target.java Mon Mar 02 15:25:00 2015 -0800
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -72,6 +72,7 @@
>>>  * @since 1.5
>>>  * @jls 9.6.4.1 @Target
>>>  * @jls 9.7.4 Where Annotations May Appear
>>> + * @jls 9.7.5 Multiple Annotations of the Same Type
>>>  */
>>> @Documented
>>> @Retention(RetentionPolicy.RUNTIME)
>>> 
>> 
>> 
>> <Mail Attachment.gif>
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering 
>> 1 Network Drive 
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>> 
>> 
>> 
>> 
> 




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






From mandy.chung at oracle.com  Tue Mar  3 00:00:49 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 02 Mar 2015 16:00:49 -0800
Subject: RFR 8074066: Useless code in share/native/libjava/VM.c
In-Reply-To: <54F32BCE.9040209@oracle.com>
References: <54F32BCE.9040209@oracle.com>
Message-ID: <54F4F9B1.3030604@oracle.com>

On 3/1/15 7:10 AM, Ivan Gerasimov wrote:
> Hello everybody!
>
> Java_sun_misc_VM_initialize() calls JVM_GetVersionInfo(), but doesn't 
> use the results.
>
> This code was added with a massive merge to jdk7 [1].
> I wonder if it might be some debugging code.
>
> I propose to delete that, unless someone explains why it is needed.
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8074066
> WEBREV: http://cr.openjdk.java.net/~igerasim/8074066/0/webrev/

Looks good to me.

Mandy


From joe.darcy at oracle.com  Tue Mar  3 00:05:27 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 02 Mar 2015 16:05:27 -0800
Subject: JAXP repo warnings fixed
In-Reply-To: <CACYLA9HOwJruWEq2w2w6NsACCF1MkU0MSUUwVp5JAWJUz4S1fg@mail.gmail.com>
References: <CACYLA9HOwJruWEq2w2w6NsACCF1MkU0MSUUwVp5JAWJUz4S1fg@mail.gmail.com>
Message-ID: <54F4FAC7.9050208@oracle.com>

Hello,

Sorry for the belated reply, I tried the URLs and some obvious 
variations, but the webrevs didn't come up as being there.

Have they been moved?

Thanks,

-Joe

On 2/18/2015 12:17 PM, Ivan St. Ivanov wrote:
> Hi Joe, core libs developers,
>
> Last night we had a hackathon in Bulgarian Java User Group. Its 
> purpose was to work on fixing some compiler warnings in OpenJDK. The 
> day before the meeting we ran the following command:
>
> make clean 
> JAVAC_WARNINGS="-Xlint:all,deprecation,rawtypes,unchecked,cast,serial,dep-ann,static,fallthrough,try,varargs,empty,finally 
> -Xmaxwarns 10000" DISABLE_WARNINGS="-Xlint:all" LOG=info images
>
> After that, looking at the build.log, we identified the following 
> number of warnings per repo left to be fixed:
>
> 359 corba
> 100 jaxp
> 500 jaxws
> 0 nashorn
>
> We decided to take the jaxp repository, where the situation was the 
> following:
>
> rawtypes 43
> unchecked 14
> serial 32
> cast 10
> dep-ann 1
>
> The latter three types were easy to fix. After we did them, we created 
> our first webrev for the night:
>
> http://bgjug.sty.bz/bgjug/~bgjug/fix-warnings-jaxp-part1/webrev.00/ 
> <http://bgjug.sty.bz/bgjug/%7Ebgjug/fix-warnings-jaxp-part1/webrev.00/>
>
> Later we continued with rawtypes and unchecked. We didn't fix them 
> all, as some of the warnings concerned public method parameters, which 
> change might virtually break client code. The good news here is that 
> all these public methods belong to classes located in 'internal' 
> packages. Which we hope will not be public any more once project 
> Jigsaw meets java.xml module :)
>
> Anyway, this is the second webrev that we created:
>
> http://bgjug.sty.bz/bgjug/~bgjug/fix-warnings-jaxp-full/webrev.00/ 
> <http://bgjug.sty.bz/bgjug/%7Ebgjug/fix-warnings-jaxp-full/webrev.00/>
>
> As its name implies, it contains all the fixes that we did last night.
>
> We would be happy to get feedback from you and even happier if this 
> becomes our first contribution to OpenJDK as part of our adoption efforts.
>
> Regards,
> Ivan, Bulgarian JUG
>



From stuart.marks at oracle.com  Tue Mar  3 01:57:41 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 02 Mar 2015 17:57:41 -0800
Subject: RFR(s): 8073923: Files.lines() documentation needs clarification
Message-ID: <54F51515.1040700@oracle.com>

Hi all,

Please review minor clarifications to Files.lines() and other Files methods that 
return streams. The changes emphasize that try-with-resources should be used. 
This also clarifies and strengthens a bit of the Stream class doc that talks 
about when to use try-with-resources on streams.

Bug:

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

Webrev:

	http://cr.openjdk.java.net/~smarks/reviews/8073923/webrev.0/

Thanks,

s'marks


From stuart.marks at oracle.com  Tue Mar  3 02:09:42 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 02 Mar 2015 18:09:42 -0800
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <D4DCF09D-E0BD-4CD9-808E-521D0077515E@oracle.com>
References: <8890A88D-98D4-4F22-A71E-9C29A9F5545B@oracle.com>	<D23B81AC-3A4A-43CD-879D-D50F4A631741@oracle.com>	<54DAAA15.3080301@oracle.com>	<05A0E203-F057-4B5B-8C47-0F190CA6D667@oracle.com>	<54DBAC35.1060903@oracle.com>	<5BB0E788-9908-460E-A63F-46C5189CBCB1@oracle.com>	<54DC0D6F.3000406@oracle.com>	<4EB3EE4A-8139-41C8-A5BE-F277091EFAE8@oracle.com>	<54DD4365.3050007@oracle.com>	<5D1880CE-29E9-4C7C-A88B-94566517C905@oracle.com>	<54DE4FF9.6050609@oracle.com>	<67B7F7EA-3B80-458E-9ED3-2C7EAD901C81@oracle.com>	<54F0B4E2.5060003@oracle.com>	<959E1D9F-4445-42B2-94E8-2E8F2106932F@oracle.com>	<54F0BBF1.2000901@oracle.com>	<9BBCF56A-13DF-46E7-A645-36F04FD3881C@oracle.com>	<54F0C3AB.4020203@oracle.com>	<54F0D643.5060005@oracle.com>
	<54F0FB9D.4000508@oracle.com>	<54F138BE.10503@oracle.com>
	<D4DCF09D-E0BD-4CD9-808E-521D0077515E@oracle.com>
Message-ID: <54F517E6.8060803@oracle.com>

On 3/2/15 1:49 AM, Paul Sandoz wrote:
> On Feb 28, 2015, at 4:40 AM, Xueming Shen <xueming.shen at oracle.com> wrote:
>> Updated to a static private class for the toMatchResult(). Added a private field MatchResult for the anonymous MatchResult
>> wrapper.
>>
>> http://cr.openjdk.java.net/~sherman/regex.stream/src/java.base/share/classes/java/util/regex/Matcher.java.sdiff.html
>>
>
> Many thanks, i took most of that code and updated:
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/src/java.base/share/classes/java/util/regex/Matcher.java.sdiff.html
>
> - additional documentation for replacer function parameter is moved to the main body
>
> - there is no need for an internal MatchResult instance wrapper. It does not protect against state modification, does not protect against escape, creates another object for all matcher instances, and results in more wrapping. The only way we can avoid the first 2 is by using an immutable match result, which has it's own cost that unfortunately we cannot avoid in the results().


Even though there's more overhead, I like the idea of creating a distinct match 
result for each stream value. Consider what might happen if somebody decided to 
collect the match results into a list at the end of the pipeline. (Did the 
earlier versions pass "this" down the stream? If so, boy, was that a latent 
bug.) I'm reminded of one of the old Map entrySet iterators that reused the same 
Map.Entry instance for the duration of the iteration. That caused some problems.

Anyway, this latest version looks fine.

s'marks


From joe.darcy at oracle.com  Tue Mar  3 02:14:58 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 02 Mar 2015 18:14:58 -0800
Subject: RFR(s): 8073923: Files.lines() documentation needs clarification
In-Reply-To: <54F51515.1040700@oracle.com>
References: <54F51515.1040700@oracle.com>
Message-ID: <54F51922.4060109@oracle.com>

Hi Stuart,

Since try-with-resources is "just" a desugaring, I think the statements like

          [The resource] must be opened as a resource within a 
try-with-resources
  136  * statement to ensure that it is closed promptly after its 
operations have completed.

should be replaced with the milder

     ... with a try-with-resources statement or similar control 
structure to ensure...

Thanks,

-Joe

On 3/2/2015 5:57 PM, Stuart Marks wrote:
> Hi all,
>
> Please review minor clarifications to Files.lines() and other Files 
> methods that return streams. The changes emphasize that 
> try-with-resources should be used. This also clarifies and strengthens 
> a bit of the Stream class doc that talks about when to use 
> try-with-resources on streams.
>
> Bug:
>
>     https://bugs.openjdk.java.net/browse/JDK-8073923
>
> Webrev:
>
>     http://cr.openjdk.java.net/~smarks/reviews/8073923/webrev.0/
>
> Thanks,
>
> s'marks



From stuart.marks at oracle.com  Tue Mar  3 02:43:16 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 02 Mar 2015 18:43:16 -0800
Subject: RFR(s): 8073923: Files.lines() documentation needs clarification
In-Reply-To: <54F51922.4060109@oracle.com>
References: <54F51515.1040700@oracle.com> <54F51922.4060109@oracle.com>
Message-ID: <54F51FC4.4030100@oracle.com>

Hi Joe,

Oh yes, good point. Revised webrev:

	http://cr.openjdk.java.net/~smarks/reviews/8073923/webrev.1/

Thanks,

s'marks


On 3/2/15 6:14 PM, Joseph D. Darcy wrote:
> Hi Stuart,
>
> Since try-with-resources is "just" a desugaring, I think the statements like
>
>           [The resource] must be opened as a resource within a try-with-resources
>   136  * statement to ensure that it is closed promptly after its operations
> have completed.
>
> should be replaced with the milder
>
>      ... with a try-with-resources statement or similar control structure to
> ensure...
>
> Thanks,
>
> -Joe
>
> On 3/2/2015 5:57 PM, Stuart Marks wrote:
>> Hi all,
>>
>> Please review minor clarifications to Files.lines() and other Files methods
>> that return streams. The changes emphasize that try-with-resources should be
>> used. This also clarifies and strengthens a bit of the Stream class doc that
>> talks about when to use try-with-resources on streams.
>>
>> Bug:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8073923
>>
>> Webrev:
>>
>>     http://cr.openjdk.java.net/~smarks/reviews/8073923/webrev.0/
>>
>> Thanks,
>>
>> s'marks
>


From joe.darcy at oracle.com  Tue Mar  3 02:46:15 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 02 Mar 2015 18:46:15 -0800
Subject: RFR(s): 8073923: Files.lines() documentation needs clarification
In-Reply-To: <54F51FC4.4030100@oracle.com>
References: <54F51515.1040700@oracle.com> <54F51922.4060109@oracle.com>
	<54F51FC4.4030100@oracle.com>
Message-ID: <54F52077.2010604@oracle.com>

Hi Stuart,

The revised version looks good; thanks,

-Joe

On 3/2/2015 6:43 PM, Stuart Marks wrote:
> Hi Joe,
>
> Oh yes, good point. Revised webrev:
>
>     http://cr.openjdk.java.net/~smarks/reviews/8073923/webrev.1/
>
> Thanks,
>
> s'marks
>
>
> On 3/2/15 6:14 PM, Joseph D. Darcy wrote:
>> Hi Stuart,
>>
>> Since try-with-resources is "just" a desugaring, I think the 
>> statements like
>>
>>           [The resource] must be opened as a resource within a 
>> try-with-resources
>>   136  * statement to ensure that it is closed promptly after its 
>> operations
>> have completed.
>>
>> should be replaced with the milder
>>
>>      ... with a try-with-resources statement or similar control 
>> structure to
>> ensure...
>>
>> Thanks,
>>
>> -Joe
>>
>> On 3/2/2015 5:57 PM, Stuart Marks wrote:
>>> Hi all,
>>>
>>> Please review minor clarifications to Files.lines() and other Files 
>>> methods
>>> that return streams. The changes emphasize that try-with-resources 
>>> should be
>>> used. This also clarifies and strengthens a bit of the Stream class 
>>> doc that
>>> talks about when to use try-with-resources on streams.
>>>
>>> Bug:
>>>
>>>     https://bugs.openjdk.java.net/browse/JDK-8073923
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~smarks/reviews/8073923/webrev.0/
>>>
>>> Thanks,
>>>
>>> s'marks
>>



From john.r.rose at oracle.com  Tue Mar  3 04:32:33 2015
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 2 Mar 2015 20:32:33 -0800
Subject: stop using mmap for zip I/O
In-Reply-To: <CA+kOe09kB6XxUBwDcK5816x=5HbZ_jqBVNM2WUT=RrD2mKNTXg@mail.gmail.com>
References: <20150226221759.4560B17FDAA@rebar.astron.com>
	<54F03A09.9060507@redhat.com> <54F03E30.6040709@oracle.com>
	<54F0555F.3090200@redhat.com> <54F07C5F.7060204@oracle.com>
	<CA+kOe09kB6XxUBwDcK5816x=5HbZ_jqBVNM2WUT=RrD2mKNTXg@mail.gmail.com>
Message-ID: <26BC9661-3964-4B78-94C9-08AD3422DC6F@oracle.com>

On Mar 2, 2015, at 3:12 PM, Martin Buchholz <martinrb at google.com> wrote:
> 
> Our experience at Google is also that many people run into crashes when
> overwriting zip files.  Our standard answer is "don't do that, then!"
> Instead of the "evil" overwriting cp program, make a temp file, then move
> it into place.  More generally, follow a policy of "immutability" for file
> contents.

I wonder if it's not too late to wedge this policy into Java's basic io behaviors.

Most Java codes use FileOutputStream to write a file.  We could change its
behavior to delete its output file instead of truncating.  This could be fine-tuned
by various knobs (properties, callbacks, etc.).  Then if the offending code uses
Java to write a file, it would no longer tickle this class of bugs.

Maybe it's just wishful thinking, but I think it's worth asking what would be
the exact compatibility expense of making such a change.

Alternatively, and less invasively, the JVM hook which maps a file
(don't recall what it is; something in NIO) could make a JVM-private
copy of the mmap-ed file.  Sounds silly, but maybe there are practical
ways to limit the costs, yet still get the benefit on zip files.
Maybe the JVM can copy the file to a private directory, once per
file timestamp.  Or maybe not.

Worst case is (a) mmap files are large and very seldom changing,
and (b) non-JVM tools (like /bin/cp) perform the truncate-and-write.

? John

From ivan.gerasimov at oracle.com  Tue Mar  3 07:36:36 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 03 Mar 2015 10:36:36 +0300
Subject: RFR 8074066: Useless code in share/native/libjava/VM.c
In-Reply-To: <54F4F9B1.3030604@oracle.com>
References: <54F32BCE.9040209@oracle.com> <54F4F9B1.3030604@oracle.com>
Message-ID: <54F56484.5070103@oracle.com>

Thank you Mandy for review!

Ivan

On 03.03.2015 3:00, Mandy Chung wrote:
> On 3/1/15 7:10 AM, Ivan Gerasimov wrote:
>> Hello everybody!
>>
>> Java_sun_misc_VM_initialize() calls JVM_GetVersionInfo(), but doesn't 
>> use the results.
>>
>> This code was added with a massive merge to jdk7 [1].
>> I wonder if it might be some debugging code.
>>
>> I propose to delete that, unless someone explains why it is needed.
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8074066
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8074066/0/webrev/
>
> Looks good to me.
>
> Mandy
>
>



From ivan.gerasimov at oracle.com  Tue Mar  3 08:15:24 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 03 Mar 2015 11:15:24 +0300
Subject: RFR 8074067: Cleanup in java.base/share/native/libjava/Bits.c
In-Reply-To: <CA+kOe088ziEoK9hJk6+L9RHXvHD1NbYv=Ln7C6D_97_yVYpsLw@mail.gmail.com>
References: <54F32E51.5040601@oracle.com>	<54F485D0.4020501@oracle.com>	<54F4CF20.2070003@oracle.com>
	<CA+kOe088ziEoK9hJk6+L9RHXvHD1NbYv=Ln7C6D_97_yVYpsLw@mail.gmail.com>
Message-ID: <54F56D9C.5070707@oracle.com>

Thanks Martin for the suggestion!

On 03.03.2015 0:08, Martin Buchholz wrote:
> slightly safer (more likely to compile everywhere) might be to convert 
> input length into a size_t immediately and to
>
I'm not quite sure it would be correct.
If size_t happens to be 32-bit int, then the length could overflow, 
since it represents the size of the array in bytes, while we're 
operating on the the array of shorts, ints and longs.
I would feel more comfortable if length gets cast to size_t only when it 
is guaranteed to be in the range (0, 1048576).


By the way, in 
'java.base/share/classes/java/nio/Direct-X-Buffer.java.template' I see 
this code:
     public $Type$Buffer get($type$[] dst, int offset, *int*length) {
         if ((*length**<< $LG_BYTES_PER_VALUE$*) > 
Bits.JNI_COPY_TO_ARRAY_THRESHOLD) {

Am I correct this would cause overflow for LongBuffer.get(buff, 0, (1 << 
24)) ?


Sincerely yours,
Ivan


> #define MBYTE ((size_t)  1048576)
>
> On Mon, Mar 2, 2015 at 12:59 PM, Ivan Gerasimov 
> <ivan.gerasimov at oracle.com <mailto:ivan.gerasimov at oracle.com>> wrote:
>
>     Thank you Alan for review!
>
>
>         As you've noted, there is no need to update xxxAddr because
>         the position is updated during swapping copy. That looks okay
>         to me.
>
>         Only updating size for the last chunk is okay too, but that a
>         bit of coin toss as to whether to change this as the current
>         code is easy to read. The stale comment should be removed of
>         course.
>
>     I agree that readability is important.
>     Below is the updated webrev.  I couldn't resist to making it a bit
>     shorter, though :)
>
>     BUGURL: https://bugs.openjdk.java.net/browse/JDK-8074067
>     WEBREV: http://cr.openjdk.java.net/~igerasim/8074067/1/webrev/
>     <http://cr.openjdk.java.net/%7Eigerasim/8074067/1/webrev/>
>
>     I checked that the source can be built on all platforms, despite
>     of the warning in the comments.
>
>     Sincerely yours,
>     Ivan
>
>



From martinrb at google.com  Tue Mar  3 09:23:04 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 3 Mar 2015 01:23:04 -0800
Subject: RFR 8074067: Cleanup in java.base/share/native/libjava/Bits.c
In-Reply-To: <54F56D9C.5070707@oracle.com>
References: <54F32E51.5040601@oracle.com> <54F485D0.4020501@oracle.com>
	<54F4CF20.2070003@oracle.com>
	<CA+kOe088ziEoK9hJk6+L9RHXvHD1NbYv=Ln7C6D_97_yVYpsLw@mail.gmail.com>
	<54F56D9C.5070707@oracle.com>
Message-ID: <CA+kOe0_Ju1MOOEMYtmfQTPf0p+CD3jv1Hn+hWx7Gqd12etEnNA@mail.gmail.com>

On Tue, Mar 3, 2015 at 12:15 AM, Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

>  Thanks Martin for the suggestion!
>
> On 03.03.2015 0:08, Martin Buchholz wrote:
>
> slightly safer (more likely to compile everywhere) might be to convert
> input length into a size_t immediately and to
>
>  I'm not quite sure it would be correct.
> If size_t happens to be 32-bit int, then the length could overflow, since
> it represents the size of the array in bytes, while we're operating on the
> the array of shorts, ints and longs.
> I would feel more comfortable if length gets cast to size_t only when it
> is guaranteed to be in the range (0, 1048576).
>
>
Sounds good to me!
It's still good practice to have both branches of a ternary expression have
the same signedness.

BTW, it seems those static native methods like copyFromShortArray should
have a jclass clazz second arg, not a jobject this.


From fweimer at redhat.com  Tue Mar  3 10:10:18 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 03 Mar 2015 11:10:18 +0100
Subject: stop using mmap for zip I/O
In-Reply-To: <26BC9661-3964-4B78-94C9-08AD3422DC6F@oracle.com>
References: <20150226221759.4560B17FDAA@rebar.astron.com>	<54F03A09.9060507@redhat.com>
	<54F03E30.6040709@oracle.com>	<54F0555F.3090200@redhat.com>
	<54F07C5F.7060204@oracle.com>	<CA+kOe09kB6XxUBwDcK5816x=5HbZ_jqBVNM2WUT=RrD2mKNTXg@mail.gmail.com>
	<26BC9661-3964-4B78-94C9-08AD3422DC6F@oracle.com>
Message-ID: <54F5888A.7010905@redhat.com>

On 03/03/2015 05:32 AM, John Rose wrote:

> Most Java codes use FileOutputStream to write a file.  We could change its
> behavior to delete its output file instead of truncating.  This could be fine-tuned
> by various knobs (properties, callbacks, etc.).  Then if the offending code uses
> Java to write a file, it would no longer tickle this class of bugs.

On some systems, this may introduce a security vulnerability if the file
is in a shared directory for temporary files.

Regarding the original mapping problem, Linux prevents this failure
scenario for executable files (the ETXTBUSY error code).  The triggering
conditions for that are a bit bizarre.  It seems this only applies to
the main executable file, and not objects which are mapped subsequently.
 This is not too surprising because other options would allow
unprivileged users to prevent modification of any file.

-- 
Florian Weimer / Red Hat Product Security


From paul.sandoz at oracle.com  Tue Mar  3 11:34:27 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 3 Mar 2015 12:34:27 +0100
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <54F517E6.8060803@oracle.com>
References: <8890A88D-98D4-4F22-A71E-9C29A9F5545B@oracle.com>	<D23B81AC-3A4A-43CD-879D-D50F4A631741@oracle.com>	<54DAAA15.3080301@oracle.com>	<05A0E203-F057-4B5B-8C47-0F190CA6D667@oracle.com>	<54DBAC35.1060903@oracle.com>	<5BB0E788-9908-460E-A63F-46C5189CBCB1@oracle.com>	<54DC0D6F.3000406@oracle.com>	<4EB3EE4A-8139-41C8-A5BE-F277091EFAE8@oracle.com>	<54DD4365.3050007@oracle.com>	<5D1880CE-29E9-4C7C-A88B-94566517C905@oracle.com>	<54DE4FF9.6050609@oracle.com>	<67B7F7EA-3B80-458E-9ED3-2C7EAD901C81@oracle.com>	<54F0B4E2.5060003@oracle.com>	<959E1D9F-4445-42B2-94E8-2E8F2106932F@oracle.com>	<54F0BBF1.2000901@oracle.com>	<9BBCF56A-13DF-46E7-A645-36F04FD3881C@oracle.com>	<54F0C3AB.4020203@oracle.com>	<54F0D643.5060005@oracle.com>
	<54F0FB9D.4000508@oracle.com>	<54F138BE.10503@oracle.com>
	<D4DCF09D-E0BD-4CD9-808E-521D0077515E@oracle.com>
	<54F517E6.8060803@oracle.com>
Message-ID: <BA78F45B-29CC-41CB-B3AB-9448403069FD@oracle.com>


On Mar 3, 2015, at 3:09 AM, Stuart Marks <stuart.marks at oracle.com> wrote:

> On 3/2/15 1:49 AM, Paul Sandoz wrote:
>> On Feb 28, 2015, at 4:40 AM, Xueming Shen <xueming.shen at oracle.com> wrote:
>>> Updated to a static private class for the toMatchResult(). Added a private field MatchResult for the anonymous MatchResult
>>> wrapper.
>>> 
>>> http://cr.openjdk.java.net/~sherman/regex.stream/src/java.base/share/classes/java/util/regex/Matcher.java.sdiff.html
>>> 
>> 
>> Many thanks, i took most of that code and updated:
>> 
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/src/java.base/share/classes/java/util/regex/Matcher.java.sdiff.html
>> 
>> - additional documentation for replacer function parameter is moved to the main body
>> 
>> - there is no need for an internal MatchResult instance wrapper. It does not protect against state modification, does not protect against escape, creates another object for all matcher instances, and results in more wrapping. The only way we can avoid the first 2 is by using an immutable match result, which has it's own cost that unfortunately we cannot avoid in the results().
> 
> 
> Even though there's more overhead, I like the idea of creating a distinct match result for each stream value. Consider what might happen if somebody decided to collect the match results into a list at the end of the pipeline.

Right, we cannot avoid it (sequentially or for parallel).


> (Did the earlier versions pass "this" down the stream?

No.


> If so, boy, was that a latent bug.)


> I'm reminded of one of the old Map entrySet iterators that reused the same Map.Entry instance for the duration of the iteration. That caused some problems.
> 

See ServiceLoader :-)


> Anyway, this latest version looks fine.
> 

Thanks!
Paul.


From dmitry.samersoff at oracle.com  Tue Mar  3 11:41:54 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 03 Mar 2015 14:41:54 +0300
Subject: stop using mmap for zip I/O
In-Reply-To: <20150226221759.4560B17FDAA@rebar.astron.com>
References: <20150226221759.4560B17FDAA@rebar.astron.com>
Message-ID: <54F59E02.9050209@oracle.com>

Christos,

JVM install it's own signal handler and use it to numerous tasks, so add
signal handler to zip_util.c is problematic.

The simplest way to address the problem is use mlock/munlock to test
page presence before touching it.

i.e. add code like

     if ((i % 4096) == 0) {
             if ( mlock(v+i, 4096) < 0) {
               printf("No page. Bail out\n");
               return;
             }
          }

to *compute()* in your example below.


-Dmitry




On 2015-02-27 01:17, christos at zoulas.com wrote:
> Hi,
> 
> There are numerous bug reports about the jvm crashing in libzip...
> Just google for "libzip java crash". The bottom line is that using
> mmap is problematic (I can get into more per OS details if necessary)
> because it will potentially signal when the file size is altered.
> Can we please turn USE_MMAP off, and/or remove the code (zip_util.c)?
> I don't think it is acceptable for the jvm to crash if it tries to
> read a file while it is being modified. The following simple program
> demonstrates the issue... just:
> 
> $ cc mmap.c
> $ cp a.out b.out
> $ ./a.out b.out
> 
> Best,
> 
> christos
> 
> $ cat << _EOF > mmap.c
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <fcntl.h>
> #include <err.h>
> #include <signal.h>
> 
> #include <sys/mman.h>
> #include <sys/stat.h>
> 
> volatile size_t i;
> size_t size = 0;
> 
> void
> sig(int s)
> {
> 	printf("boom %d %zu\n", s, i);
> 	exit(1);
> }
> 
> void
> compute(unsigned char *v)
> {
> 	int j = 0;
> 	for (i = 0; i < size; i++)
> 		j += v[i];
> 	printf("%d\n", j);
> }
> 
> int
> main(int argc, char *argv[])
> {
> 	struct stat st;
> 	unsigned char *v;
> 	int fd;
> 
> 	signal(SIGSEGV, sig);
> 	signal(SIGBUS, sig);
> 	fd = open(argv[1], O_RDONLY);
> 	if (fd == -1)
> 		err(1, "open %s", argv[1]);
> 
> 	if (fstat(fd, &st) == -1)
> 		err(1, "fstat %s", argv[1]);
> 	size = st.st_size;
> 	if (size == 0)
> 		errx(1, "0 sized file");
> 	
> 	v = mmap(0, size, PROT_READ, MAP_FILE | MAP_PRIVATE, fd, 0);
> 	if (v == MAP_FAILED)
> 		err(1, "mmap");
> 
> 	printf("go1\n");
> 	compute(v);
> 	truncate(argv[1], 0);
> 	printf("go2\n");
> 	compute(v);
> 	return 0;
> }
> _EOF
> 


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


From paul.sandoz at oracle.com  Tue Mar  3 13:32:35 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 3 Mar 2015 14:32:35 +0100
Subject: RFR(s): 8073923: Files.lines() documentation needs clarification
In-Reply-To: <54F51FC4.4030100@oracle.com>
References: <54F51515.1040700@oracle.com> <54F51922.4060109@oracle.com>
	<54F51FC4.4030100@oracle.com>
Message-ID: <85F4800A-5EEA-41BD-BDDF-3ED8513AA918@oracle.com>


On Mar 3, 2015, at 3:43 AM, Stuart Marks <stuart.marks at oracle.com> wrote:

> Hi Joe,
> 
> Oh yes, good point. Revised webrev:
> 
> 	http://cr.openjdk.java.net/~smarks/reviews/8073923/webrev.1/
> 

+1

Paul.


From Alan.Bateman at oracle.com  Tue Mar  3 13:42:00 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 03 Mar 2015 13:42:00 +0000
Subject: RFR(s): 8073923: Files.lines() documentation needs clarification
In-Reply-To: <54F51FC4.4030100@oracle.com>
References: <54F51515.1040700@oracle.com> <54F51922.4060109@oracle.com>
	<54F51FC4.4030100@oracle.com>
Message-ID: <54F5BA28.2090404@oracle.com>

On 03/03/2015 02:43, Stuart Marks wrote:
> Hi Joe,
>
> Oh yes, good point. Revised webrev:
>
>     http://cr.openjdk.java.net/~smarks/reviews/8073923/webrev.1/
>
One small quibble is "contains an open file" as it's really that the 
stream has a reference to an open file.

The other thing is the list and walk methods where it specifies that the 
returned stream encapsulates one or more DirectoryStream object, a point 
that could be downgraded to an implementation note. It is of course 
important to make it clear that these methods return a stream that has 
references to open directories.

-Alan


From christos at zoulas.com  Tue Mar  3 13:55:35 2015
From: christos at zoulas.com (Christos Zoulas)
Date: Tue, 3 Mar 2015 08:55:35 -0500
Subject: stop using mmap for zip I/O
In-Reply-To: <54F59E02.9050209@oracle.com>
	from Dmitry Samersoff (Mar  3,  2:41pm)
Message-ID: <20150303135535.0565717FDAA@rebar.astron.com>

On Mar 3,  2:41pm, dmitry.samersoff at oracle.com (Dmitry Samersoff) wrote:
-- Subject: Re: stop using mmap for zip I/O

| Christos,
| 
| JVM install it's own signal handler and use it to numerous tasks, so add
| signal handler to zip_util.c is problematic.

Yes, I understand; this is why I mentioned that we not change it
until the pure java implementation is released.

| The simplest way to address the problem is use mlock/munlock to test
| page presence before touching it.
| 
| i.e. add code like
| 
|      if ((i % 4096) == 0) {
|              if ( mlock(v+i, 4096) < 0) {
|                printf("No page. Bail out\n");
|                return;
|              }
|           }
| 
| to *compute()* in your example below.

Yes, that fixes it too, at the cost of more syscalls and complexity...
I just mentioned disable mmap, because it is easy and fixes a common
problem without any performance penalties. Perhaps the mmap code made
sense when it was mapping the whole file, but now mapping just the
central directory doesn't. (IMHO :-)

christos


From ivan.st.ivanov at gmail.com  Tue Mar  3 18:06:20 2015
From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov)
Date: Tue, 3 Mar 2015 20:06:20 +0200
Subject: JAXP repo warnings fixed
In-Reply-To: <54F4FAC7.9050208@oracle.com>
References: <CACYLA9HOwJruWEq2w2w6NsACCF1MkU0MSUUwVp5JAWJUz4S1fg@mail.gmail.com>
	<54F4FAC7.9050208@oracle.com>
Message-ID: <CACYLA9F99YFjGHcsxJ-edTnH0k28BE8kMyitJuj=ogx57mYMog@mail.gmail.com>

Hi Joe,

The links are correct, but our server was down for a while. It is available
now.

Regards,
Ivan

On Tue, Mar 3, 2015 at 2:05 AM, Joseph D. Darcy <joe.darcy at oracle.com>
wrote:

> Hello,
>
> Sorry for the belated reply, I tried the URLs and some obvious variations,
> but the webrevs didn't come up as being there.
>
> Have they been moved?
>
> Thanks,
>
> -Joe
>
> On 2/18/2015 12:17 PM, Ivan St. Ivanov wrote:
>
>> Hi Joe, core libs developers,
>>
>> Last night we had a hackathon in Bulgarian Java User Group. Its purpose
>> was to work on fixing some compiler warnings in OpenJDK. The day before the
>> meeting we ran the following command:
>>
>> make clean JAVAC_WARNINGS="-Xlint:all,deprecation,rawtypes,
>> unchecked,cast,serial,dep-ann,static,fallthrough,try,varargs,empty,finally
>> -Xmaxwarns 10000" DISABLE_WARNINGS="-Xlint:all" LOG=info images
>>
>> After that, looking at the build.log, we identified the following number
>> of warnings per repo left to be fixed:
>>
>> 359 corba
>> 100 jaxp
>> 500 jaxws
>> 0 nashorn
>>
>> We decided to take the jaxp repository, where the situation was the
>> following:
>>
>> rawtypes 43
>> unchecked 14
>> serial 32
>> cast 10
>> dep-ann 1
>>
>> The latter three types were easy to fix. After we did them, we created
>> our first webrev for the night:
>>
>> http://bgjug.sty.bz/bgjug/~bgjug/fix-warnings-jaxp-part1/webrev.00/ <
>> http://bgjug.sty.bz/bgjug/%7Ebgjug/fix-warnings-jaxp-part1/webrev.00/>
>>
>> Later we continued with rawtypes and unchecked. We didn't fix them all,
>> as some of the warnings concerned public method parameters, which change
>> might virtually break client code. The good news here is that all these
>> public methods belong to classes located in 'internal' packages. Which we
>> hope will not be public any more once project Jigsaw meets java.xml module
>> :)
>>
>> Anyway, this is the second webrev that we created:
>>
>> http://bgjug.sty.bz/bgjug/~bgjug/fix-warnings-jaxp-full/webrev.00/ <
>> http://bgjug.sty.bz/bgjug/%7Ebgjug/fix-warnings-jaxp-full/webrev.00/>
>>
>> As its name implies, it contains all the fixes that we did last night.
>>
>> We would be happy to get feedback from you and even happier if this
>> becomes our first contribution to OpenJDK as part of our adoption efforts.
>>
>> Regards,
>> Ivan, Bulgarian JUG
>>
>>
>


From stuart.marks at oracle.com  Tue Mar  3 18:16:48 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 03 Mar 2015 10:16:48 -0800
Subject: RFR(s): 8073923: Files.lines() documentation needs clarification
In-Reply-To: <54F5BA28.2090404@oracle.com>
References: <54F51515.1040700@oracle.com> <54F51922.4060109@oracle.com>
	<54F51FC4.4030100@oracle.com> <54F5BA28.2090404@oracle.com>
Message-ID: <54F5FA90.3020008@oracle.com>

On 3/3/15 5:42 AM, Alan Bateman wrote:
> On 03/03/2015 02:43, Stuart Marks wrote:
>> Oh yes, good point. Revised webrev:
>>
>>     http://cr.openjdk.java.net/~smarks/reviews/8073923/webrev.1/
>>
> One small quibble is "contains an open file" as it's really that the stream has
> a reference to an open file.

True. I can change this if you like.

> The other thing is the list and walk methods where it specifies that the
> returned stream encapsulates one or more DirectoryStream object, a point that
> could be downgraded to an implementation note. It is of course important to make
> it clear that these methods return a stream that has references to open
> directories.

Yeah, it was a little uncomfortable leaving the "contains one or more 
DirectoryStreams" where it was, and separating the @apiNote recommending use of 
try-with-resources. But I did so deliberately, because the statement about 
containing a DirectoryStream (or open file) that is closed by the closed() call 
is a normative part of the spec, and indeed it's testable. (I don't know whether 
in fact it is tested though.) I didn't think that it belonged in the @apiNote.

s'marks


From ivan.gerasimov at oracle.com  Tue Mar  3 18:39:40 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 03 Mar 2015 21:39:40 +0300
Subject: RFR 8074067: Cleanup in java.base/share/native/libjava/Bits.c
In-Reply-To: <CA+kOe0_Ju1MOOEMYtmfQTPf0p+CD3jv1Hn+hWx7Gqd12etEnNA@mail.gmail.com>
References: <54F32E51.5040601@oracle.com>	<54F485D0.4020501@oracle.com>	<54F4CF20.2070003@oracle.com>	<CA+kOe088ziEoK9hJk6+L9RHXvHD1NbYv=Ln7C6D_97_yVYpsLw@mail.gmail.com>	<54F56D9C.5070707@oracle.com>
	<CA+kOe0_Ju1MOOEMYtmfQTPf0p+CD3jv1Hn+hWx7Gqd12etEnNA@mail.gmail.com>
Message-ID: <54F5FFEC.9050005@oracle.com>



On 03.03.2015 12:23, Martin Buchholz wrote:
>
>
> On Tue, Mar 3, 2015 at 12:15 AM, Ivan Gerasimov 
> <ivan.gerasimov at oracle.com <mailto:ivan.gerasimov at oracle.com>> wrote:
>
>     Thanks Martin for the suggestion!
>
>     On 03.03.2015 0:08, Martin Buchholz wrote:
>>     slightly safer (more likely to compile everywhere) might be to
>>     convert input length into a size_t immediately and to
>>
>     I'm not quite sure it would be correct.
>     If size_t happens to be 32-bit int, then the length could
>     overflow, since it represents the size of the array in bytes,
>     while we're operating on the the array of shorts, ints and longs.
>     I would feel more comfortable if length gets cast to size_t only
>     when it is guaranteed to be in the range (0, 1048576).
>
>
> Sounds good to me!
> It's still good practice to have both branches of a ternary expression 
> have the same signedness.
>
Okay. But I don't want to make MBYTE unsigned, or we'll have '/comparing 
signed to unsigned/' compile-time warning.

> BTW, it seems those static native methods like copyFromShortArray 
> should have a jclass clazz second arg, not a jobject this.
Cool! I'll include fixing that too.

http://cr.openjdk.java.net/~igerasim/8074067/2/webrev/src/java.base/share/native/libjava/Bits.c.sdiff.html

Sincerely yours,
Ivan




From martinrb at google.com  Tue Mar  3 18:53:51 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 3 Mar 2015 10:53:51 -0800
Subject: RFR 8074067: Cleanup in java.base/share/native/libjava/Bits.c
In-Reply-To: <54F5FFEC.9050005@oracle.com>
References: <54F32E51.5040601@oracle.com> <54F485D0.4020501@oracle.com>
	<54F4CF20.2070003@oracle.com>
	<CA+kOe088ziEoK9hJk6+L9RHXvHD1NbYv=Ln7C6D_97_yVYpsLw@mail.gmail.com>
	<54F56D9C.5070707@oracle.com>
	<CA+kOe0_Ju1MOOEMYtmfQTPf0p+CD3jv1Hn+hWx7Gqd12etEnNA@mail.gmail.com>
	<54F5FFEC.9050005@oracle.com>
Message-ID: <CA+kOe08DnOdoGOK1kofBt-1Z97qb50ubeDsSBT-Y4dmBkwN=oQ@mail.gmail.com>

Looks good!

On Tue, Mar 3, 2015 at 10:39 AM, Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

>
>
> On 03.03.2015 12:23, Martin Buchholz wrote:
>
>
>
> On Tue, Mar 3, 2015 at 12:15 AM, Ivan Gerasimov <ivan.gerasimov at oracle.com
> > wrote:
>
>>  Thanks Martin for the suggestion!
>>
>> On 03.03.2015 0:08, Martin Buchholz wrote:
>>
>> slightly safer (more likely to compile everywhere) might be to convert
>> input length into a size_t immediately and to
>>
>>   I'm not quite sure it would be correct.
>> If size_t happens to be 32-bit int, then the length could overflow, since
>> it represents the size of the array in bytes, while we're operating on the
>> the array of shorts, ints and longs.
>> I would feel more comfortable if length gets cast to size_t only when it
>> is guaranteed to be in the range (0, 1048576).
>>
>>
>  Sounds good to me!
> It's still good practice to have both branches of a ternary expression
> have the same signedness.
>
>    Okay. But I don't want to make MBYTE unsigned, or we'll have '*comparing
> signed to unsigned*' compile-time warning.
>
>   BTW, it seems those static native methods like copyFromShortArray
> should have a jclass clazz second arg, not a jobject this.
>
>
> Cool! I'll include fixing that too.
>
>
> http://cr.openjdk.java.net/~igerasim/8074067/2/webrev/src/java.base/share/native/libjava/Bits.c.sdiff.html
>
> Sincerely yours,
> Ivan
>
>
>


From kumar.x.srinivasan at oracle.com  Tue Mar  3 19:55:06 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 03 Mar 2015 11:55:06 -0800
Subject: RFR (EZ): 8073972: Deprecate Multi-Version Java Launcher (mJRE) for
	JDK8
Message-ID: <54F6119A.4050505@oracle.com>

Hello,

Please review this simple change to the launcher help display.

Webrev:
http://cr.openjdk.java.net/~ksrini/8073972/webrev.00/

bug:
http://bugs.openjdk.java.net/browse/JDK-8073972

Thanks
Kumar



From mandy.chung at oracle.com  Tue Mar  3 20:15:01 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 03 Mar 2015 12:15:01 -0800
Subject: RFR (EZ): 8073972: Deprecate Multi-Version Java Launcher (mJRE)
	for JDK8
In-Reply-To: <54F6119A.4050505@oracle.com>
References: <54F6119A.4050505@oracle.com>
Message-ID: <54F61645.3040707@oracle.com>

Looks fine to me.
Mandy

On 3/3/15 11:55 AM, Kumar Srinivasan wrote:
> Hello,
>
> Please review this simple change to the launcher help display.
>
> Webrev:
> http://cr.openjdk.java.net/~ksrini/8073972/webrev.00/
>
> bug:
> http://bugs.openjdk.java.net/browse/JDK-8073972
>
> Thanks
> Kumar
>



From Alan.Bateman at oracle.com  Tue Mar  3 20:24:14 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 03 Mar 2015 20:24:14 +0000
Subject: RFR 8074067: Cleanup in java.base/share/native/libjava/Bits.c
In-Reply-To: <54F5FFEC.9050005@oracle.com>
References: <54F32E51.5040601@oracle.com>	<54F485D0.4020501@oracle.com>	<54F4CF20.2070003@oracle.com>	<CA+kOe088ziEoK9hJk6+L9RHXvHD1NbYv=Ln7C6D_97_yVYpsLw@mail.gmail.com>	<54F56D9C.5070707@oracle.com>
	<CA+kOe0_Ju1MOOEMYtmfQTPf0p+CD3jv1Hn+hWx7Gqd12etEnNA@mail.gmail.com>
	<54F5FFEC.9050005@oracle.com>
Message-ID: <54F6186E.8090706@oracle.com>

On 03/03/2015 18:39, Ivan Gerasimov wrote:
> :
>
>
> http://cr.openjdk.java.net/~igerasim/8074067/2/webrev/src/java.base/share/native/libjava/Bits.c.sdiff.html
I think you are good to go too.

-Alan


From Alan.Bateman at oracle.com  Tue Mar  3 20:27:12 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 03 Mar 2015 20:27:12 +0000
Subject: RFR(s): 8073923: Files.lines() documentation needs clarification
In-Reply-To: <54F5FA90.3020008@oracle.com>
References: <54F51515.1040700@oracle.com> <54F51922.4060109@oracle.com>
	<54F51FC4.4030100@oracle.com> <54F5BA28.2090404@oracle.com>
	<54F5FA90.3020008@oracle.com>
Message-ID: <54F61920.5000808@oracle.com>

On 03/03/2015 18:16, Stuart Marks wrote:
> On 3/3/15 5:42 AM, Alan Bateman wrote:
>> One small quibble is "contains an open file" as it's really that the 
>> stream has
>> a reference to an open file.
>
> True. I can change this if you like.
That would be good, thanks.


> :
>
> Yeah, it was a little uncomfortable leaving the "contains one or more 
> DirectoryStreams" where it was, and separating the @apiNote 
> recommending use of try-with-resources. But I did so deliberately, 
> because the statement about containing a DirectoryStream (or open 
> file) that is closed by the closed() call is a normative part of the 
> spec, and indeed it's testable. (I don't know whether in fact it is 
> tested though.) I didn't think that it belonged in the @apiNote.
It's a testable with custom file system provider or if you interpose on 
the default provider, but not easy. If methods such as lines specify 
that they need a reference to an open file then I think it should be 
okay for list/walk to specify that they keep a reference to the open 
directory (or directories). That would allow you to drop any reference 
to DirectoryStream, except perhaps @see or @implNote.

-Alan


From Alan.Bateman at oracle.com  Tue Mar  3 20:27:52 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 03 Mar 2015 20:27:52 +0000
Subject: RFR (EZ): 8073972: Deprecate Multi-Version Java Launcher (mJRE)
	for JDK8
In-Reply-To: <54F6119A.4050505@oracle.com>
References: <54F6119A.4050505@oracle.com>
Message-ID: <54F61948.5020607@oracle.com>

On 03/03/2015 19:55, Kumar Srinivasan wrote:
> Hello,
>
> Please review this simple change to the launcher help display.
>
> Webrev:
> http://cr.openjdk.java.net/~ksrini/8073972/webrev.00/
>
The reasoning and the wording look good to me.

-Alan.


From john.r.rose at oracle.com  Tue Mar  3 20:48:12 2015
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 3 Mar 2015 12:48:12 -0800
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54F4BA63.5060506@redhat.com>
References: <54EB6DD1.4090803@redhat.com>
	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>
	<54EDFBA3.6080609@redhat.com> <54F4BA63.5060506@redhat.com>
Message-ID: <3625DCDD-DB34-427C-ADAE-ABD1F9B08523@oracle.com>

On Mar 2, 2015, at 11:30 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 02/25/2015 04:43 PM, Andrew Haley wrote:
> I have done this as much as is possible, but methods which assemble
> and split sub-words are necessarily endian-dependent.  I have
> separated the native big- and little-endian code into two classes,
> only one of which will ever be loaded into a system.

Here is a way to merge the twin classes, using gated "pick" operators:
  http://cr.openjdk.java.net/~jrose/draft/Unsafe.NativeEitherEndian.java

If merging them actually works, then the merged result should be
folded back into Unsafe, and static variables used everywhere.
I think this is better than quasi-duplicate code, if it optimizes right.

(The JIT optimizer should commute shift-mask and reversal intrinsics
to get the same result, but it doesn't at present; explicit pick is second-best.)

> 
>>> Suggestion:  Have getIntUnaligned take an optional boolean
>>> parameter, which is "bigEndian" (since that's relatively exceptional).
>>> An extra line of code can conditionally swap the bytes, taking
>>> both the flag and the platform into account.  Default value of the
>>> boolean is whatever is natural to the platform.  If you specifically
>>> want Java's big-endian order, you specify true, etc.
> 
> I've done this in Java.  I tried some HotSpot intrinsic code to handle
> the "bigEndian" parameter but foundered when I noticed that
> Op_ReverseBytesXX nodes are optional, so an intrinsic might either be
> emitted as an instruction or a call to a native method.  This was all
> too messy so I reverted to doing it in Java; the code quality does not
> seem to suffer as a result of this.  (Another possibility is to define
> intrinsics which would only be used if Op_ReverseBytesXX nodes were
> supported, but I don't know that such an intrinsic would buy us
> anything.)

I'm surprised it backed off to a native method.  It should have backed
off to bytecode equivalent to what you wrote (see Integer.java for the code).

> It wasn't clear to me whether you might also want set-XX-Unaligned
> methods with specific endianness, so I didn't write any.

That's fine; it can be composed using swaps.  The optimizer
needs to do the commuting optimization mentioned above,
but that can be deferred.

> I have not written any Unsafe support for floating-point types.  It's
> not clear to me that it is needed.  Perhaps the caller should convert
> floating-point types as necessary; what do you think?

Just bitwise load/store is fine IMO.  Clients can call floatToIntBits etc.

> There are several places in the JDK where we have special cases for
> alignment, endianness, and arrays and some could benefit from use of
> these new methods, but except for HeapByteBuffers I haven't changed
> anything.

It would be good to call them out; we can file followup bugs.

> I am aware that the code is uncommented.  I will fix that once we
> agree about what to do next.
> 
> http://cr.openjdk.java.net/~aph/unaligned.hotspot.1/
> http://cr.openjdk.java.net/~aph/unaligned.jdk.2/

I like it!

I'm a little puzzled by the meaning of UseUnalignedAccesses.
From a portable point of view, it sounds like the JVM will be using special access operators.
But in fact, it is using the normal aligned memory access operators for unaligned accesses also.
(Remember, from a portability point of view the normal memory access operators work only on aligned addresses.)
I don't have a nice replacement name thought.

? John

From ecki at zusammenkunft.net  Tue Mar  3 21:05:14 2015
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Tue, 3 Mar 2015 22:05:14 +0100
Subject: Unsafe.{get,put}-X-Unaligned; Efficient array comparison
	intrinsics
In-Reply-To: <3625DCDD-DB34-427C-ADAE-ABD1F9B08523@oracle.com>
References: <54EB6DD1.4090803@redhat.com>
	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>
	<54EDFBA3.6080609@redhat.com> <54F4BA63.5060506@redhat.com>
	<3625DCDD-DB34-427C-ADAE-ABD1F9B08523@oracle.com>
Message-ID: <20150303220514.000076e3.ecki@zusammenkunft.net>

Am Tue, 3 Mar 2015 12:48:12 -0800
schrieb John Rose <john.r.rose at oracle.com>:
> I'm a little puzzled by the meaning of UseUnalignedAccesses.
> From a portable point of view, it sounds like the JVM will be using
> special access operators. But in fact, it is using the normal aligned
> memory access operators for unaligned accesses also. (Remember, from
> a portability point of view the normal memory access operators work
> only on aligned addresses.) I don't have a nice replacement name
> thought.

Maybe UseUnconstrainedAccess or AlignmentInsensitiveAccess?

Gruss
Bernd


From iris.clark at oracle.com  Tue Mar  3 21:13:15 2015
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 3 Mar 2015 13:13:15 -0800 (PST)
Subject: RFR (EZ): 8073972: Deprecate Multi-Version Java Launcher (mJRE)
	for JDK8
In-Reply-To: <54F6119A.4050505@oracle.com>
References: <54F6119A.4050505@oracle.com>
Message-ID: <df43da2b-df1a-40b6-80bd-2f0fbc6d077d@default>

Hi, Kumar.

The warning looks fine to me.

Thanks,
iris

-----Original Message-----
From: Kumar Srinivasan 
Sent: Tuesday, March 03, 2015 11:55 AM
To: core-libs-dev
Subject: RFR (EZ): 8073972: Deprecate Multi-Version Java Launcher (mJRE) for JDK8

Hello,

Please review this simple change to the launcher help display.

Webrev:
http://cr.openjdk.java.net/~ksrini/8073972/webrev.00/

bug:
http://bugs.openjdk.java.net/browse/JDK-8073972

Thanks
Kumar



From stuart.marks at oracle.com  Tue Mar  3 23:05:26 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 03 Mar 2015 15:05:26 -0800
Subject: RFR(s): 8073923: Files.lines() documentation needs clarification
In-Reply-To: <54F61920.5000808@oracle.com>
References: <54F51515.1040700@oracle.com> <54F51922.4060109@oracle.com>
	<54F51FC4.4030100@oracle.com> <54F5BA28.2090404@oracle.com>
	<54F5FA90.3020008@oracle.com> <54F61920.5000808@oracle.com>
Message-ID: <54F63E36.6040603@oracle.com>



On 3/3/15 12:27 PM, Alan Bateman wrote:
> On 03/03/2015 18:16, Stuart Marks wrote:
>> On 3/3/15 5:42 AM, Alan Bateman wrote:
>>> One small quibble is "contains an open file" as it's really that the stream has
>>> a reference to an open file.
>>
>> True. I can change this if you like.
> That would be good, thanks.

Changed.

>> Yeah, it was a little uncomfortable leaving the "contains one or more
>> DirectoryStreams" where it was, and separating the @apiNote recommending use
>> of try-with-resources. But I did so deliberately, because the statement about
>> containing a DirectoryStream (or open file) that is closed by the closed()
>> call is a normative part of the spec, and indeed it's testable. (I don't know
>> whether in fact it is tested though.) I didn't think that it belonged in the
>> @apiNote.
> It's a testable with custom file system provider or if you interpose on the
> default provider, but not easy. If methods such as lines specify that they need
> a reference to an open file then I think it should be okay for list/walk to
> specify that they keep a reference to the open directory (or directories). That
> would allow you to drop any reference to DirectoryStream, except perhaps @see or
> @implNote.

Hm, yes, it is rather strange for the docs to reference DirectoryStream 
specifically, when the point is not this specific class, but more the abstract 
concept of an open resource. I've reworded the clauses to remove mentions of the 
specific DirectoryStream class, and I've replaced the mentions with wording such 
as "references to one or more open files."

Updated webrev:

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

s'marks


From joe.darcy at oracle.com  Wed Mar  4 02:21:46 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 03 Mar 2015 18:21:46 -0800
Subject: JAXP repo warnings fixed
In-Reply-To: <CACYLA9F99YFjGHcsxJ-edTnH0k28BE8kMyitJuj=ogx57mYMog@mail.gmail.com>
References: <CACYLA9HOwJruWEq2w2w6NsACCF1MkU0MSUUwVp5JAWJUz4S1fg@mail.gmail.com>	<54F4FAC7.9050208@oracle.com>
	<CACYLA9F99YFjGHcsxJ-edTnH0k28BE8kMyitJuj=ogx57mYMog@mail.gmail.com>
Message-ID: <54F66C3A.9000701@oracle.com>

Hi Ivan,

I've skimmed over the patch and didn't see anything technically amiss. 
However, I believe at least some of the changes, such as adding 
@Deprecated and the generification updates will need to go through an 
internal review process before they can be pushed.

Joe Wang (cc'ed as huizhe.wang at oracle.com) is the jaxp lead and he will 
also need to review of the changes for jaxp-specific concerns.

Thanks,

-Joe

On 3/3/2015 10:06 AM, Ivan St. Ivanov wrote:
> Hi Joe,
>
> The links are correct, but our server was down for a while. It is 
> available now.
>
> Regards,
> Ivan
>
> On Tue, Mar 3, 2015 at 2:05 AM, Joseph D. Darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>     Hello,
>
>     Sorry for the belated reply, I tried the URLs and some obvious
>     variations, but the webrevs didn't come up as being there.
>
>     Have they been moved?
>
>     Thanks,
>
>     -Joe
>
>     On 2/18/2015 12:17 PM, Ivan St. Ivanov wrote:
>
>         Hi Joe, core libs developers,
>
>         Last night we had a hackathon in Bulgarian Java User Group.
>         Its purpose was to work on fixing some compiler warnings in
>         OpenJDK. The day before the meeting we ran the following command:
>
>         make clean
>         JAVAC_WARNINGS="-Xlint:all,deprecation,rawtypes,unchecked,cast,serial,dep-ann,static,fallthrough,try,varargs,empty,finally
>         -Xmaxwarns 10000" DISABLE_WARNINGS="-Xlint:all" LOG=info images
>
>         After that, looking at the build.log, we identified the
>         following number of warnings per repo left to be fixed:
>
>         359 corba
>         100 jaxp
>         500 jaxws
>         0 nashorn
>
>         We decided to take the jaxp repository, where the situation
>         was the following:
>
>         rawtypes 43
>         unchecked 14
>         serial 32
>         cast 10
>         dep-ann 1
>
>         The latter three types were easy to fix. After we did them, we
>         created our first webrev for the night:
>
>         http://bgjug.sty.bz/bgjug/~bgjug/fix-warnings-jaxp-part1/webrev.00/
>         <http://bgjug.sty.bz/bgjug/%7Ebgjug/fix-warnings-jaxp-part1/webrev.00/>
>         <http://bgjug.sty.bz/bgjug/%7Ebgjug/fix-warnings-jaxp-part1/webrev.00/>
>
>         Later we continued with rawtypes and unchecked. We didn't fix
>         them all, as some of the warnings concerned public method
>         parameters, which change might virtually break client code.
>         The good news here is that all these public methods belong to
>         classes located in 'internal' packages. Which we hope will not
>         be public any more once project Jigsaw meets java.xml module :)
>
>         Anyway, this is the second webrev that we created:
>
>         http://bgjug.sty.bz/bgjug/~bgjug/fix-warnings-jaxp-full/webrev.00/
>         <http://bgjug.sty.bz/bgjug/%7Ebgjug/fix-warnings-jaxp-full/webrev.00/>
>         <http://bgjug.sty.bz/bgjug/%7Ebgjug/fix-warnings-jaxp-full/webrev.00/>
>
>         As its name implies, it contains all the fixes that we did
>         last night.
>
>         We would be happy to get feedback from you and even happier if
>         this becomes our first contribution to OpenJDK as part of our
>         adoption efforts.
>
>         Regards,
>         Ivan, Bulgarian JUG
>
>
>



From huizhe.wang at oracle.com  Wed Mar  4 05:09:22 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 03 Mar 2015 21:09:22 -0800
Subject: JAXP repo warnings fixed
In-Reply-To: <54F66C3A.9000701@oracle.com>
References: <CACYLA9HOwJruWEq2w2w6NsACCF1MkU0MSUUwVp5JAWJUz4S1fg@mail.gmail.com>	<54F4FAC7.9050208@oracle.com>
	<CACYLA9F99YFjGHcsxJ-edTnH0k28BE8kMyitJuj=ogx57mYMog@mail.gmail.com>
	<54F66C3A.9000701@oracle.com>
Message-ID: <54F69382.6040102@oracle.com>


On 3/3/2015 6:21 PM, Joseph D. Darcy wrote:
> Hi Ivan,
>
> I've skimmed over the patch and didn't see anything technically amiss. 
> However, I believe at least some of the changes, such as adding 
> @Deprecated and the generification updates will need to go through an 
> internal review process before they can be pushed.
>
> Joe Wang (cc'ed as huizhe.wang at oracle.com) is the jaxp lead and he 
> will also need to review of the changes for jaxp-specific concerns.

Just coming back from a two-week vacation, I have a lot of catch-ups to 
do. Please allow me some time to get to this.

Thanks,
Joe

>
> Thanks,
>
> -Joe
>
> On 3/3/2015 10:06 AM, Ivan St. Ivanov wrote:
>> Hi Joe,
>>
>> The links are correct, but our server was down for a while. It is 
>> available now.
>>
>> Regards,
>> Ivan
>>
>> On Tue, Mar 3, 2015 at 2:05 AM, Joseph D. Darcy <joe.darcy at oracle.com 
>> <mailto:joe.darcy at oracle.com>> wrote:
>>
>>     Hello,
>>
>>     Sorry for the belated reply, I tried the URLs and some obvious
>>     variations, but the webrevs didn't come up as being there.
>>
>>     Have they been moved?
>>
>>     Thanks,
>>
>>     -Joe
>>
>>     On 2/18/2015 12:17 PM, Ivan St. Ivanov wrote:
>>
>>         Hi Joe, core libs developers,
>>
>>         Last night we had a hackathon in Bulgarian Java User Group.
>>         Its purpose was to work on fixing some compiler warnings in
>>         OpenJDK. The day before the meeting we ran the following command:
>>
>>         make clean
>>         JAVAC_WARNINGS="-Xlint:all,deprecation,rawtypes,unchecked,cast,serial,dep-ann,static,fallthrough,try,varargs,empty,finally
>>         -Xmaxwarns 10000" DISABLE_WARNINGS="-Xlint:all" LOG=info images
>>
>>         After that, looking at the build.log, we identified the
>>         following number of warnings per repo left to be fixed:
>>
>>         359 corba
>>         100 jaxp
>>         500 jaxws
>>         0 nashorn
>>
>>         We decided to take the jaxp repository, where the situation
>>         was the following:
>>
>>         rawtypes 43
>>         unchecked 14
>>         serial 32
>>         cast 10
>>         dep-ann 1
>>
>>         The latter three types were easy to fix. After we did them,
>>         we created our first webrev for the night:
>>
>>         http://bgjug.sty.bz/bgjug/~bgjug/fix-warnings-jaxp-part1/webrev.00/
>>         <http://bgjug.sty.bz/bgjug/%7Ebgjug/fix-warnings-jaxp-part1/webrev.00/>
>>         <http://bgjug.sty.bz/bgjug/%7Ebgjug/fix-warnings-jaxp-part1/webrev.00/>
>>
>>         Later we continued with rawtypes and unchecked. We didn't fix
>>         them all, as some of the warnings concerned public method
>>         parameters, which change might virtually break client code.
>>         The good news here is that all these public methods belong to
>>         classes located in 'internal' packages. Which we hope will
>>         not be public any more once project Jigsaw meets java.xml
>>         module :)
>>
>>         Anyway, this is the second webrev that we created:
>>
>>         http://bgjug.sty.bz/bgjug/~bgjug/fix-warnings-jaxp-full/webrev.00/
>>         <http://bgjug.sty.bz/bgjug/%7Ebgjug/fix-warnings-jaxp-full/webrev.00/>
>>         <http://bgjug.sty.bz/bgjug/%7Ebgjug/fix-warnings-jaxp-full/webrev.00/>
>>
>>         As its name implies, it contains all the fixes that we did
>>         last night.
>>
>>         We would be happy to get feedback from you and even happier
>>         if this becomes our first contribution to OpenJDK as part of
>>         our adoption efforts.
>>
>>         Regards,
>>         Ivan, Bulgarian JUG
>>
>>
>>
>



From Alan.Bateman at oracle.com  Wed Mar  4 08:31:04 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 04 Mar 2015 08:31:04 +0000
Subject: RFR(s): 8073923: Files.lines() documentation needs clarification
In-Reply-To: <54F63E36.6040603@oracle.com>
References: <54F51515.1040700@oracle.com> <54F51922.4060109@oracle.com>
	<54F51FC4.4030100@oracle.com> <54F5BA28.2090404@oracle.com>
	<54F5FA90.3020008@oracle.com> <54F61920.5000808@oracle.com>
	<54F63E36.6040603@oracle.com>
Message-ID: <54F6C2C8.1030206@oracle.com>

On 03/03/2015 23:05, Stuart Marks wrote:
> :
>
>
> Updated webrev:
>
>     http://cr.openjdk.java.net/~smarks/reviews/8073923/webrev.2/
This looks good. Minor re-wording suggestions, ignore if you want:

"... reference to an open XXX, which is closed by ..."
   => "... reference to an open XXX. The XXX is closed by ..."

"to ensure that the stream's open XXX reference is closed"
   => "to ensure that the XXX is closed".

-Alan


From aph at redhat.com  Wed Mar  4 09:25:01 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 04 Mar 2015 09:25:01 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <3625DCDD-DB34-427C-ADAE-ABD1F9B08523@oracle.com>
References: <54EB6DD1.4090803@redhat.com>
	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>
	<54EDFBA3.6080609@redhat.com> <54F4BA63.5060506@redhat.com>
	<3625DCDD-DB34-427C-ADAE-ABD1F9B08523@oracle.com>
Message-ID: <54F6CF6D.1020904@redhat.com>

On 03/03/15 20:48, John Rose wrote:
> On Mar 2, 2015, at 11:30 AM, Andrew Haley <aph at redhat.com> wrote:
>>
>> On 02/25/2015 04:43 PM, Andrew Haley wrote:
>> I have done this as much as is possible, but methods which assemble
>> and split sub-words are necessarily endian-dependent.  I have
>> separated the native big- and little-endian code into two classes,
>> only one of which will ever be loaded into a system.
> 
> Here is a way to merge the twin classes, using gated "pick" operators:
>   http://cr.openjdk.java.net/~jrose/draft/Unsafe.NativeEitherEndian.java
> 
> If merging them actually works, then the merged result should be
> folded back into Unsafe, and static variables used everywhere.
> I think this is better than quasi-duplicate code, if it optimizes right.

That looks very nice.  I'll see if it optimizes well.

>>>> Suggestion:  Have getIntUnaligned take an optional boolean
>>>> parameter, which is "bigEndian" (since that's relatively exceptional).
>>>> An extra line of code can conditionally swap the bytes, taking
>>>> both the flag and the platform into account.  Default value of the
>>>> boolean is whatever is natural to the platform.  If you specifically
>>>> want Java's big-endian order, you specify true, etc.
>>
>> I've done this in Java.  I tried some HotSpot intrinsic code to handle
>> the "bigEndian" parameter but foundered when I noticed that
>> Op_ReverseBytesXX nodes are optional, so an intrinsic might either be
>> emitted as an instruction or a call to a native method.  This was all
>> too messy so I reverted to doing it in Java; the code quality does not
>> seem to suffer as a result of this.  (Another possibility is to define
>> intrinsics which would only be used if Op_ReverseBytesXX nodes were
>> supported, but I don't know that such an intrinsic would buy us
>> anything.)
> 
> I'm surprised it backed off to a native method.  It should have backed
> off to bytecode equivalent to what you wrote (see Integer.java for the code).

I'm sorry, I misspoke. I mean that reverse may be emitted as a call to
a method if the C2 node isn't supported.

>> There are several places in the JDK where we have special cases for
>> alignment, endianness, and arrays and some could benefit from use of
>> these new methods, but except for HeapByteBuffers I haven't changed
>> anything.
> 
> It would be good to call them out; we can file followup bugs.

Okay.

>> I am aware that the code is uncommented.  I will fix that once we
>> agree about what to do next.
>>
>> http://cr.openjdk.java.net/~aph/unaligned.hotspot.1/
>> http://cr.openjdk.java.net/~aph/unaligned.jdk.2/
> 
> I like it!
> 
> I'm a little puzzled by the meaning of UseUnalignedAccesses.
> From a portable point of view, it sounds like the JVM will be using special access operators.
> But in fact, it is using the normal aligned memory access operators for unaligned accesses also.
> (Remember, from a portability point of view the normal memory access operators work only on aligned addresses.)
> I don't have a nice replacement name thought.

Sure.  It's a developer-only flag, and we have something of a
tradition of obscurely-named developer flags.  But I might be able to
think of a better name.

Andrew.


From ivan.gerasimov at oracle.com  Wed Mar  4 11:13:00 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 04 Mar 2015 14:13:00 +0300
Subject: RFR 8074067: Cleanup in java.base/share/native/libjava/Bits.c
In-Reply-To: <54F6186E.8090706@oracle.com>
References: <54F32E51.5040601@oracle.com>	<54F485D0.4020501@oracle.com>	<54F4CF20.2070003@oracle.com>	<CA+kOe088ziEoK9hJk6+L9RHXvHD1NbYv=Ln7C6D_97_yVYpsLw@mail.gmail.com>	<54F56D9C.5070707@oracle.com>
	<CA+kOe0_Ju1MOOEMYtmfQTPf0p+CD3jv1Hn+hWx7Gqd12etEnNA@mail.gmail.com>
	<54F5FFEC.9050005@oracle.com> <54F6186E.8090706@oracle.com>
Message-ID: <54F6E8BC.3070903@oracle.com>

Thanks Alan, thanks Martin!

Sincerely yours,
Ivan

On 03.03.2015 23:24, Alan Bateman wrote:
> On 03/03/2015 18:39, Ivan Gerasimov wrote:
>> :
>>
>>
>> http://cr.openjdk.java.net/~igerasim/8074067/2/webrev/src/java.base/share/native/libjava/Bits.c.sdiff.html
> I think you are good to go too.
>
> -Alan



From magnus.ihse.bursie at oracle.com  Wed Mar  4 13:17:20 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 04 Mar 2015 14:17:20 +0100
Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a
	per-library basis
Message-ID: <54F705E0.2030102@oracle.com>

When building the native code in the jdk repo, a lot of warnings are 
generated. So many that it's hard to spot any new issues.

While the ultimate goal must be to address and fix these warnings 
individually, this bug is about disabling these warnings where they 
occur, so that it is easier to spot new warnings, and that the existing 
warnings can be addressed one at a time.

Disabling warnings instead of fixing them can be problematic. If you are 
too broad with disabling warnings, you might hide future problems. On 
the other hand, there have been a lot of warnings that indicate serious 
problems that has been "hidden in plain sight" for a very long time in 
the code base anyway.

I have opted to disable warnings at the library level. Disabling 
warnings globally would be too broad. Disabling per file would have been 
too tedious. Many warnings also tend to repeat across multiple files in 
the same library, due to e.g. less well-suited programming style or 
design choice. A library also seems like a suitable chunk of work to 
address later on, in trying to get rid of the source of the warnings.

This fix will not get rid of all warnings, but the bulk of them. It will 
make the remaining warnings stick out more. The few warnings that remain 
are either:
* Not possible to disable.
* Not resulting from native compilation (but from linking, or javadoc, etc).
* Not possible to disable with this framework (this goes for builds on 
pre-4.4 gcc, which Oracle currently does as default on macosx), and 
libfontmanager on Solaris, which mixes C and C++ code. (While the 
solstudio C compiler does not fail on requests to disable C++ warnings, 
the converse is unfortunately not true). It did not seem worth the 
trouble to build a more extensible framework to handle this, compared to 
actually fixing these warnings.

Note that the current JPRT build environment in Oracle uses a pre-4.4 
gcc for macosx by default, so the default macosx build will still 
contain warnings. When building with --with-toolchain-type=clang, the 
clang warning disabling kicks in. (This will be the default in JPRT 
later on this year.)

I intend to file individual bugs to handle these remaining warnings, so 
the net result will be a completely warning free build.

I also intend to file individual bugs on all the libraries that has had 
warnings disabled. I expect the outcome of these bugs to be either:

A) The code modified so it does not trigger warnings, and the warnings 
re-enabled, or

B) The warnings (or a subset of them) kept disabled, but a comment added 
to the makefile describing why this is the proper course of action.

Not all bugs might be worth fixing. For instance, the GCC warnings 
type-limits, sign-compare, pointer-to-int-cast, conversion-null, 
deprecated-declarations, clobbered, int-to-pointer-cast and type-limits 
are all more or less benign, and is possibly the result of a false positive.

On the other hands, warnings such as format-nonliteral, unused-result, 
maybe-uninitialized, format, format-security, int-to-pointer-cast, 
reorder and delete-non-virtual-dtor are more likely to actually point to 
real issues. I recommend anyone finding these warnings on a library they 
care about to try and fix them as soon as possible.

Here is a summary of the libraries and binaries that have gotten 
warnings disabled. I'm not sure about what group owns all these 
libraries; if I missed sending this mail to the correct list, please 
help me and forward it.

* libunpack
* libfdlibm
* libverify
* libjava
* libzip
* libjli/libjli_static
* libj2gss
* libsunec
* libj2pkcs11
* libnet
* libnio
* libosxkrb5
* libosxapp
* libosx
* libapplescriptengine
* libjsound
* libjsoundalsa
* libmlib_image
* libawt
* libawt_xawt
* libawt_lwawt
* liblcms
* libjavajpeg
* libawt_headless
* libfontmanager
* libsplashscreen
* unpack200
* The JVMTI demos compiledMethodLoad and waiters

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

WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.01

/Magnus



From erik.joelsson at oracle.com  Wed Mar  4 13:31:53 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 04 Mar 2015 14:31:53 +0100
Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a
	per-library basis
In-Reply-To: <54F705E0.2030102@oracle.com>
References: <54F705E0.2030102@oracle.com>
Message-ID: <54F70949.4040900@oracle.com>

Hello,

Really nice to finally see this patch getting done!

Only one comment:

flags.m4:
In the grep expression, could you move the extra [] outside of the 
actual command line options to grep so that the command line could be 
copied to the shell for debugging in the future? Also, how hard would it 
be to instead do AC_COMPILE_IFELSE with a dummy warning to instead test 
for capability?

/Erik

On 2015-03-04 14:17, Magnus Ihse Bursie wrote:
> When building the native code in the jdk repo, a lot of warnings are 
> generated. So many that it's hard to spot any new issues.
>
> While the ultimate goal must be to address and fix these warnings 
> individually, this bug is about disabling these warnings where they 
> occur, so that it is easier to spot new warnings, and that the 
> existing warnings can be addressed one at a time.
>
> Disabling warnings instead of fixing them can be problematic. If you 
> are too broad with disabling warnings, you might hide future problems. 
> On the other hand, there have been a lot of warnings that indicate 
> serious problems that has been "hidden in plain sight" for a very long 
> time in the code base anyway.
>
> I have opted to disable warnings at the library level. Disabling 
> warnings globally would be too broad. Disabling per file would have 
> been too tedious. Many warnings also tend to repeat across multiple 
> files in the same library, due to e.g. less well-suited programming 
> style or design choice. A library also seems like a suitable chunk of 
> work to address later on, in trying to get rid of the source of the 
> warnings.
>
> This fix will not get rid of all warnings, but the bulk of them. It 
> will make the remaining warnings stick out more. The few warnings that 
> remain are either:
> * Not possible to disable.
> * Not resulting from native compilation (but from linking, or javadoc, 
> etc).
> * Not possible to disable with this framework (this goes for builds on 
> pre-4.4 gcc, which Oracle currently does as default on macosx), and 
> libfontmanager on Solaris, which mixes C and C++ code. (While the 
> solstudio C compiler does not fail on requests to disable C++ 
> warnings, the converse is unfortunately not true). It did not seem 
> worth the trouble to build a more extensible framework to handle this, 
> compared to actually fixing these warnings.
>
> Note that the current JPRT build environment in Oracle uses a pre-4.4 
> gcc for macosx by default, so the default macosx build will still 
> contain warnings. When building with --with-toolchain-type=clang, the 
> clang warning disabling kicks in. (This will be the default in JPRT 
> later on this year.)
>
> I intend to file individual bugs to handle these remaining warnings, 
> so the net result will be a completely warning free build.
>
> I also intend to file individual bugs on all the libraries that has 
> had warnings disabled. I expect the outcome of these bugs to be either:
>
> A) The code modified so it does not trigger warnings, and the warnings 
> re-enabled, or
>
> B) The warnings (or a subset of them) kept disabled, but a comment 
> added to the makefile describing why this is the proper course of action.
>
> Not all bugs might be worth fixing. For instance, the GCC warnings 
> type-limits, sign-compare, pointer-to-int-cast, conversion-null, 
> deprecated-declarations, clobbered, int-to-pointer-cast and 
> type-limits are all more or less benign, and is possibly the result of 
> a false positive.
>
> On the other hands, warnings such as format-nonliteral, unused-result, 
> maybe-uninitialized, format, format-security, int-to-pointer-cast, 
> reorder and delete-non-virtual-dtor are more likely to actually point 
> to real issues. I recommend anyone finding these warnings on a library 
> they care about to try and fix them as soon as possible.
>
> Here is a summary of the libraries and binaries that have gotten 
> warnings disabled. I'm not sure about what group owns all these 
> libraries; if I missed sending this mail to the correct list, please 
> help me and forward it.
>
> * libunpack
> * libfdlibm
> * libverify
> * libjava
> * libzip
> * libjli/libjli_static
> * libj2gss
> * libsunec
> * libj2pkcs11
> * libnet
> * libnio
> * libosxkrb5
> * libosxapp
> * libosx
> * libapplescriptengine
> * libjsound
> * libjsoundalsa
> * libmlib_image
> * libawt
> * libawt_xawt
> * libawt_lwawt
> * liblcms
> * libjavajpeg
> * libawt_headless
> * libfontmanager
> * libsplashscreen
> * unpack200
> * The JVMTI demos compiledMethodLoad and waiters
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074096
>
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.01
>
> /Magnus
>



From Alan.Bateman at oracle.com  Wed Mar  4 13:48:50 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 04 Mar 2015 13:48:50 +0000
Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a
	per-library basis
In-Reply-To: <54F705E0.2030102@oracle.com>
References: <54F705E0.2030102@oracle.com>
Message-ID: <54F70D42.3010905@oracle.com>

On 04/03/2015 13:17, Magnus Ihse Bursie wrote:
> :
>
> I intend to file individual bugs to handle these remaining warnings, 
> so the net result will be a completely warning free build.
>
> I also intend to file individual bugs on all the libraries that has 
> had warnings disabled. I expect the outcome of these bugs to be either:
>
> A) The code modified so it does not trigger warnings, and the warnings 
> re-enabled, or
>
> B) The warnings (or a subset of them) kept disabled, but a comment 
> added to the makefile describing why this is the proper course of action.
>
> Not all bugs might be worth fixing. For instance, the GCC warnings 
> type-limits, sign-compare, pointer-to-int-cast, conversion-null, 
> deprecated-declarations, clobbered, int-to-pointer-cast and 
> type-limits are all more or less benign, and is possibly the result of 
> a false positive.
Right, although for some of these it is important to double check.

Do you plan to paste in the warnings into the bugs that you will create? 
That wold be useful as warnings are a moving target.

-Alan


From paul.sandoz at oracle.com  Wed Mar  4 14:15:19 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 4 Mar 2015 15:15:19 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54F4BA63.5060506@redhat.com>
References: <54EB6DD1.4090803@redhat.com>
	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>
	<54EDFBA3.6080609@redhat.com> <54F4BA63.5060506@redhat.com>
Message-ID: <7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>


On Mar 2, 2015, at 8:30 PM, Andrew Haley <aph at redhat.com> wrote:

> On 02/25/2015 04:43 PM, Andrew Haley wrote:
>> On 02/24/2015 11:18 PM, John Rose wrote:
>>> My bottom line:  I think we should use the internal HotSpot
>>> API bytes.hpp by surfacing relevant parts of it up into Unsafe.
> 
> I have done this except that I have used the Java typenames for the
> methods.
> 
>>> Looking at the various platform code for bytes.hpp, I suppose
>>> one could argue that there are just two cases of interest:
>>> A single instruction (x86/arm) and a complicated 4-way
>>> switch (sparc/ppc). 
> 
> And 32-bit ARM which is usually little-endian with no unaligned
> support.
> 
>>> Distinct big and little endian access modes are also available
>>> on some machines, such as SPARC (ASI_LITTLE, etc.).
>>> But I do *not* believe that this capability should be surfaced
>>> as distinct intrinsics in Unsafe.  Many cpus and source bases
>>> deal with endian-matching simply by adjoining a separate
>>> "byte swap" operation to the memory access.  In Java,
>>> this is already an intrinsic, {Long,Integer,...}.reverseBytes.
>>> And SPARC already optimizes some compositions of
>>> byte reversal and memory access to its special ASI_LITTLE
>>> instructions.
>>> 
>>> My second bottom line:  Don't multiply endian options.
>>> Use reverseBytes calls instead.
> 
> I have done this as much as is possible, but methods which assemble
> and split sub-words are necessarily endian-dependent.  I have
> separated the native big- and little-endian code into two classes,
> only one of which will ever be loaded into a system.
> 
>>> Suggestion:  Have getIntUnaligned take an optional boolean
>>> parameter, which is "bigEndian" (since that's relatively exceptional).
>>> An extra line of code can conditionally swap the bytes, taking
>>> both the flag and the platform into account.  Default value of the
>>> boolean is whatever is natural to the platform.  If you specifically
>>> want Java's big-endian order, you specify true, etc.
> 
> I've done this in Java.  I tried some HotSpot intrinsic code to handle
> the "bigEndian" parameter but foundered when I noticed that
> Op_ReverseBytesXX nodes are optional, so an intrinsic might either be
> emitted as an instruction or a call to a native method.  This was all
> too messy so I reverted to doing it in Java; the code quality does not
> seem to suffer as a result of this.  (Another possibility is to define
> intrinsics which would only be used if Op_ReverseBytesXX nodes were
> supported, but I don't know that such an intrinsic would buy us
> anything.)
> 
> It wasn't clear to me whether you might also want set-XX-Unaligned
> methods with specific endianness, so I didn't write any.
> 
> I have not written any Unsafe support for floating-point types.  It's
> not clear to me that it is needed.  Perhaps the caller should convert
> floating-point types as necessary; what do you think?
> 
> There are several places in the JDK where we have special cases for
> alignment, endianness, and arrays and some could benefit from use of
> these new methods, but except for HeapByteBuffers I haven't changed
> anything.
> 
> I am aware that the code is uncommented.  I will fix that once we
> agree about what to do next.
> 
> http://cr.openjdk.java.net/~aph/unaligned.hotspot.1/
> http://cr.openjdk.java.net/~aph/unaligned.jdk.2/
> 

This is looking good.


The flag UseUnalignedAccesses feels a little awkward. IIUC it seems to be acting as two things, a flag signalling an unaligned architecture and a developer option to disable/enable unaligned intrinsics.  Should this flag even be allowed to be set to true on aligned architectures?

Perhaps we need to separate out into two constants? one exposed via Unsafe.unalignedAccess, and then a developer flag UseUnalignedAccessesIntrinsics (true by default if unaligned architecture) to disable intrinsics for testing purposes.


My inclination is to remove the get*Unaligned(..., boolean bigEndian) methods and thereby consistently use Bits.swap in the heap buffer. A similar pattern applies for float/double conversion.


It might be useful to have unaligned access methods for the single-register addressing mode methods. Using those would clean up logic in MappedByteBuffer and perhaps similar twiddling methods in Bits could be removed, thus consolidating all such logic within Unsafe?


Paul.


From aph at redhat.com  Wed Mar  4 14:29:17 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 04 Mar 2015 14:29:17 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>
	<54F4BA63.5060506@redhat.com>
	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>
Message-ID: <54F716BD.2030706@redhat.com>

On 03/04/2015 02:15 PM, Paul Sandoz wrote:

> The flag UseUnalignedAccesses feels a little awkward. IIUC it seems
> to be acting as two things, a flag signalling an unaligned
> architecture and a developer option to disable/enable unaligned
> intrinsics.  Should this flag even be allowed to be set to true on
> aligned architectures?

No.  I guess they should unconditionally set it to false in their
vm_version files.

> Perhaps we need to separate out into two constants? one exposed via
> Unsafe.unalignedAccess, and then a developer flag
> UseUnalignedAccessesIntrinsics (true by default if unaligned
> architecture) to disable intrinsics for testing purposes.

The "constant" exposed via Unsafe.unalignedAccess has to be
initialized to some value.  I think that setting it in vm_version (in
a cpu-dependent way) is a good idea.  For testing purposes it's
important that the whole VM gets a consistent version of whether
unaligned memory accesses are allowed.

> My inclination is to remove the get*Unaligned(..., boolean
> bigEndian) methods and thereby consistently use Bits.swap in the
> heap buffer. A similar pattern applies for float/double conversion.

I suggest that you and John argue that between yourselves!  I think
there's a lot to be said for that approach on architectures which can
do unaligned accesses and have big- and little-endian memory
operators.

> It might be useful to have unaligned access methods for the
> single-register addressing mode methods. 

Ah, you mean the methods which simply take an address?  Yes.

> Using those would clean up logic in MappedByteBuffer and perhaps
> similar twiddling methods in Bits could be removed, thus
> consolidating all such logic within Unsafe?

Absolutely, yes.  There are twiddling methods all over the place, and
we should be able to remove most of them.

Andrew.


From chris.hegarty at oracle.com  Wed Mar  4 14:59:41 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 04 Mar 2015 14:59:41 +0000
Subject: RFR 8068260:
	java/io/Serializable/clearHandleTable/ClearHandleTable.java timed out
Message-ID: <54F71DDD.7000203@oracle.com>

This is a small, test only, review request to fix an intermittently 
failing test.

It replaces a "bad" technique, heap exhaustion, with the "less bad" 
technique of calling System.gc, potentially multiple times, to clear 
weak references. With this change the test runs much quicker, and has 
not failed in several thousands of runs on a local machine.

http://cr.openjdk.java.net/~chegar/8068260/webrev.00/webrev/

-Chris.


From chris.hegarty at oracle.com  Wed Mar  4 15:01:45 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 04 Mar 2015 15:01:45 +0000
Subject: RFR 8005226: TEST_BUG:
	java/rmi/transport/pinClientSocketFactory/PinClientSocketFactory.java
	fails intermittently
Message-ID: <54F71E59.5020707@oracle.com>

This is a small, test only, review request to fix an intermittently 
failing test.

There is an inherent race, and possible failure, following the 
getUnusedRandomPort pattern. This test can be modified to use a custom 
socket factory, supporting listening on an ephemeral port, without 
changing the behavior of the test.

http://cr.openjdk.java.net/~chegar/8005226/webrev.00/webrev/

-Chris.


From magnus.ihse.bursie at oracle.com  Wed Mar  4 15:03:20 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 04 Mar 2015 16:03:20 +0100
Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a
	per-library basis
In-Reply-To: <54F70D42.3010905@oracle.com>
References: <54F705E0.2030102@oracle.com> <54F70D42.3010905@oracle.com>
Message-ID: <54F71EB8.3030109@oracle.com>

On 2015-03-04 14:48, Alan Bateman wrote:
> On 04/03/2015 13:17, Magnus Ihse Bursie wrote:
>> :
>>
>> I intend to file individual bugs to handle these remaining warnings, 
>> so the net result will be a completely warning free build.
>>
>> I also intend to file individual bugs on all the libraries that has 
>> had warnings disabled. I expect the outcome of these bugs to be either:
>>
>> A) The code modified so it does not trigger warnings, and the 
>> warnings re-enabled, or
>>
>> B) The warnings (or a subset of them) kept disabled, but a comment 
>> added to the makefile describing why this is the proper course of 
>> action.
>>
>> Not all bugs might be worth fixing. For instance, the GCC warnings 
>> type-limits, sign-compare, pointer-to-int-cast, conversion-null, 
>> deprecated-declarations, clobbered, int-to-pointer-cast and 
>> type-limits are all more or less benign, and is possibly the result 
>> of a false positive.
> Right, although for some of these it is important to double check.
I believe all warnings are important to check! Unfortunately, this has 
not been done for a lot of warnings for a lot of time. :(

With this framework, it is simple to enable a single warning, recompile 
and see the effect. Hopefully this lowers the threshold far enough so 
that all warnings are given proper attention. The incremental build 
functionality will come in very handy. Just by simply removing a warning 
from the DISABLED_WARNINGS_<toolchain> on a library and running "make" 
again, only the files affected will be recompiled.
>
> Do you plan to paste in the warnings into the bugs that you will 
> create? That wold be useful as warnings are a moving target.

I can easily paste in what warning categories are disabled for a 
specific library, yes.

However, if you are asking me to build each library, individually, with 
warnings re-enabled, and pasting the output, I'd rather not. That would 
be a lot of work, to detangle the output of each individual library.

/Magnus


From paul.sandoz at oracle.com  Wed Mar  4 15:07:37 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 4 Mar 2015 16:07:37 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54F716BD.2030706@redhat.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>
	<54F4BA63.5060506@redhat.com>
	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>
	<54F716BD.2030706@redhat.com>
Message-ID: <486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>


On Mar 4, 2015, at 3:29 PM, Andrew Haley <aph at redhat.com> wrote:

> On 03/04/2015 02:15 PM, Paul Sandoz wrote:
> 
>> The flag UseUnalignedAccesses feels a little awkward. IIUC it seems
>> to be acting as two things, a flag signalling an unaligned
>> architecture and a developer option to disable/enable unaligned
>> intrinsics.  Should this flag even be allowed to be set to true on
>> aligned architectures?
> 
> No.  I guess they should unconditionally set it to false in their
> vm_version files.
> 
>> Perhaps we need to separate out into two constants? one exposed via
>> Unsafe.unalignedAccess, and then a developer flag
>> UseUnalignedAccessesIntrinsics (true by default if unaligned
>> architecture) to disable intrinsics for testing purposes.
> 
> The "constant" exposed via Unsafe.unalignedAccess has to be
> initialized to some value.

Yes, i was unsure how to do that.


> I think that setting it in vm_version (in
> a cpu-dependent way) is a good idea.

Ok.


> For testing purposes it's
> important that the whole VM gets a consistent version of whether
> unaligned memory accesses are allowed.
> 
>> My inclination is to remove the get*Unaligned(..., boolean
>> bigEndian) methods and thereby consistently use Bits.swap in the
>> heap buffer. A similar pattern applies for float/double conversion.
> 
> I suggest that you and John argue that between yourselves!  I think
> there's a lot to be said for that approach on architectures which can
> do unaligned accesses and have big- and little-endian memory
> operators.
> 

If so then presumably that would be applicable to both get* and set*?

Could those boolean accepting methods be intrinsified or would they always be Java only?


>> It might be useful to have unaligned access methods for the
>> single-register addressing mode methods. 
> 
> Ah, you mean the methods which simply take an address?

Yes, like those used by the mapped byte buffers


> Yes.
> 
>> Using those would clean up logic in MappedByteBuffer and perhaps
>> similar twiddling methods in Bits could be removed, thus
>> consolidating all such logic within Unsafe?
> 
> Absolutely, yes.  There are twiddling methods all over the place, and
> we should be able to remove most of them.
> 

Right, this is turning out to be a little more work but overall i think it's worth it.

Paul.


From Roger.Riggs at Oracle.com  Wed Mar  4 15:17:15 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 04 Mar 2015 10:17:15 -0500
Subject: RFR 8068260:
	java/io/Serializable/clearHandleTable/ClearHandleTable.java timed out
In-Reply-To: <54F71DDD.7000203@oracle.com>
References: <54F71DDD.7000203@oracle.com>
Message-ID: <54F721FB.70400@Oracle.com>

Hi Chris,

looks fine.

Do you suppose the test library should have a function that takes a set 
of (Weak)Refs
and does whatever it takes to clear them (or timeout).

Perhaps even a public API in Runtime...

Roger

On 3/4/2015 9:59 AM, Chris Hegarty wrote:
> This is a small, test only, review request to fix an intermittently 
> failing test.
>
> It replaces a "bad" technique, heap exhaustion, with the "less bad" 
> technique of calling System.gc, potentially multiple times, to clear 
> weak references. With this change the test runs much quicker, and has 
> not failed in several thousands of runs on a local machine.
>
> http://cr.openjdk.java.net/~chegar/8068260/webrev.00/webrev/
>
> -Chris.



From aph at redhat.com  Wed Mar  4 15:21:08 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 04 Mar 2015 15:21:08 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54F716BD.2030706@redhat.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>
	<54F716BD.2030706@redhat.com>
Message-ID: <54F722E4.8000503@redhat.com>

On 03/04/2015 02:29 PM, Andrew Haley wrote:
>> My inclination is to remove the get*Unaligned(..., boolean
>> bigEndian) methods and thereby consistently use Bits.swap in the
>> heap buffer. A similar pattern applies for float/double conversion.
>
> I suggest that you and John argue that between yourselves!  I think
> there's a lot to be said for that approach on architectures which can
> do unaligned accesses and have big- and little-endian memory
> operators.

The new API gives us HeapByteBuffer methods

    public long getLong(int i) {
        return unsafe.getLongUnaligned(hb, byteOffset(checkIndex(i, 8)), bigEndian);
    }

If we get rid of the get*Unaligned(..., boolean bigEndian) methods
we'll end up with

    public long getLong(int i) {
        long x = unsafe.getLongUnaligned(hb, byteOffset(checkIndex(i, 8)));
        return nativeByteOrder ? x : Bits.swap(x));
    }

... which has the disadvantage that all of the Buffer methods have to
know about the native endianness.

One suggestion: if we exposed Unsafe.fromEndian we could do something
like

    public long getLong(int i) {
        long x = unsafe.getLongUnaligned(hb, byteOffset(checkIndex(i, 8)));
        return unsafe.fromEndian(bigEndian, x));
    }

Andrew.


From Roger.Riggs at Oracle.com  Wed Mar  4 15:26:08 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 04 Mar 2015 10:26:08 -0500
Subject: RFR 8005226: TEST_BUG:
	java/rmi/transport/pinClientSocketFactory/PinClientSocketFactory.java
	fails intermittently
In-Reply-To: <54F71E59.5020707@oracle.com>
References: <54F71E59.5020707@oracle.com>
Message-ID: <54F72410.9070004@Oracle.com>

Hi Chris,

Is the choice of 9999 as the ephemeral port ok?
Though it is artificial is there any chance it will be confused with a 
real port?

Would a negative number   (or zero) work just as well for this purpose?
Or does it get rejected in one of the layers it has to pass through.

typo:  "support listing on an ephemeral port"-> "support *listening* on 
an ephemeral port"

Roger


[1] http://en.wikipedia.org/wiki/Ephemeral_port

On 3/4/2015 10:01 AM, Chris Hegarty wrote:
> This is a small, test only, review request to fix an intermittently 
> failing test.
>
> There is an inherent race, and possible failure, following the 
> getUnusedRandomPort pattern. This test can be modified to use a custom 
> socket factory, supporting listening on an ephemeral port, without 
> changing the behavior of the test.
>
> http://cr.openjdk.java.net/~chegar/8005226/webrev.00/webrev/
>
> -Chris.



From aph at redhat.com  Wed Mar  4 15:35:22 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 04 Mar 2015 15:35:22 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>
	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>
Message-ID: <54F7263A.7040902@redhat.com>

On 03/04/2015 03:07 PM, Paul Sandoz wrote:

> If so then presumably that would be applicable to both get* and
> set*?

I think so.

> Could those boolean accepting methods be intrinsified or would they
> always be Java only?

Sure, but I've been wondering if it's necessary.  Suppose we had some
hypothetical machine which is natively little-endian and has big- and
little-endian unaligned stores.  We could match a big-endian store
with something like

instruct bigEndianStoreL(iRegL src, memory mem)
%{
  match(Set mem (StoreL mem (ReverseBytesI src)));
  format %{ "str.be  $src, $mem\t" %}

so maybe there aren't any architectures where we'd gain any advantage
from intrinsifying such loads and stores?

Andrew.


From chris.hegarty at oracle.com  Wed Mar  4 15:53:32 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 04 Mar 2015 15:53:32 +0000
Subject: RFR 8005226: TEST_BUG:
	java/rmi/transport/pinClientSocketFactory/PinClientSocketFactory.java
	fails intermittently
In-Reply-To: <54F72410.9070004@Oracle.com>
References: <54F71E59.5020707@oracle.com> <54F72410.9070004@Oracle.com>
Message-ID: <54F72A7C.7030204@oracle.com>

On 04/03/15 15:26, Roger Riggs wrote:
> Hi Chris,
>
> Is the choice of 9999 as the ephemeral port ok?

It should be, or it could be any positive integer value.

> Though it is artificial is there any chance it will be confused with a
> real port?

There should be no confusion since the test is providing a custom socket 
factory, and that factory knows about this "special" port number.

> Would a negative number   (or zero) work just as well for this purpose?
> Or does it get rejected in one of the layers it has to pass through.

It gets rejected :-(

> typo:  "support listing on an ephemeral port"-> "support *listening* on
> an ephemeral port"

Fixed.

-Chris.

> Roger
>
>
> [1] http://en.wikipedia.org/wiki/Ephemeral_port
>
> On 3/4/2015 10:01 AM, Chris Hegarty wrote:
>> This is a small, test only, review request to fix an intermittently
>> failing test.
>>
>> There is an inherent race, and possible failure, following the
>> getUnusedRandomPort pattern. This test can be modified to use a custom
>> socket factory, supporting listening on an ephemeral port, without
>> changing the behavior of the test.
>>
>> http://cr.openjdk.java.net/~chegar/8005226/webrev.00/webrev/
>>
>> -Chris.
>


From paul.sandoz at oracle.com  Wed Mar  4 15:51:03 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 4 Mar 2015 16:51:03 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54F7263A.7040902@redhat.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>
	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>
	<54F7263A.7040902@redhat.com>
Message-ID: <C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>


On Mar 4, 2015, at 4:35 PM, Andrew Haley <aph at redhat.com> wrote:

> On 03/04/2015 03:07 PM, Paul Sandoz wrote:
> 
>> If so then presumably that would be applicable to both get* and
>> set*?
> 
> I think so.
> 
>> Could those boolean accepting methods be intrinsified or would they
>> always be Java only?
> 
> Sure, but I've been wondering if it's necessary.  

In that case maybe they don't carry their weight. Some (i am presuming static ) helper methods as you suggest in your previous email seem reasonable in that context.


> Suppose we had some
> hypothetical machine which is natively little-endian and has big- and
> little-endian unaligned stores.  We could match a big-endian store
> with something like
> 
> instruct bigEndianStoreL(iRegL src, memory mem)
> %{
>  match(Set mem (StoreL mem (ReverseBytesI src)));
>  format %{ "str.be  $src, $mem\t" %}
> 
> so maybe there aren't any architectures where we'd gain any advantage
> from intrinsifying such loads and stores?
> 

Yeah, it seems hypothetical to me, but i lack knowledge in this area.

Paul.


From chris.hegarty at oracle.com  Wed Mar  4 15:57:43 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 04 Mar 2015 15:57:43 +0000
Subject: RFR 8068260:
	java/io/Serializable/clearHandleTable/ClearHandleTable.java timed out
In-Reply-To: <54F721FB.70400@Oracle.com>
References: <54F71DDD.7000203@oracle.com> <54F721FB.70400@Oracle.com>
Message-ID: <54F72B77.6030802@oracle.com>

On 04/03/15 15:17, Roger Riggs wrote:
> Hi Chris,
>
> looks fine.

Thanks Roger.

> Do you suppose the test library should have a function that takes a set
> of (Weak)Refs
> and does whatever it takes to clear them (or timeout).

Well, the problem is: What is "whatever it takes"? The changes in this 
test are only "less bad", and typically take less time to execute. I'd 
like to keep an eye on the test after this change is pushed to see if 
there are any future issues with it.

> Perhaps even a public API in Runtime...

I think, System.gc is good enough, but maybe there is scope for 
something else here.

-Chris.

> Roger
>
> On 3/4/2015 9:59 AM, Chris Hegarty wrote:
>> This is a small, test only, review request to fix an intermittently
>> failing test.
>>
>> It replaces a "bad" technique, heap exhaustion, with the "less bad"
>> technique of calling System.gc, potentially multiple times, to clear
>> weak references. With this change the test runs much quicker, and has
>> not failed in several thousands of runs on a local machine.
>>
>> http://cr.openjdk.java.net/~chegar/8068260/webrev.00/webrev/
>>
>> -Chris.
>


From Roger.Riggs at Oracle.com  Wed Mar  4 15:58:40 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 04 Mar 2015 10:58:40 -0500
Subject: RFR 8068260:
	java/io/Serializable/clearHandleTable/ClearHandleTable.java timed out
In-Reply-To: <54F72B77.6030802@oracle.com>
References: <54F71DDD.7000203@oracle.com> <54F721FB.70400@Oracle.com>
	<54F72B77.6030802@oracle.com>
Message-ID: <54F72BB0.5070400@Oracle.com>

Hi Chris,

ok, though if System.gc is good enough it would not need a loop and 
timeout logic.

It would be interesting to know if it ever needs to go through the loop 
more than once.
Maybe some indication of that can be added to the test output.

Thanks, Roger


On 3/4/2015 10:57 AM, Chris Hegarty wrote:
> On 04/03/15 15:17, Roger Riggs wrote:
>> Hi Chris,
>>
>> looks fine.
>
> Thanks Roger.
>
>> Do you suppose the test library should have a function that takes a set
>> of (Weak)Refs
>> and does whatever it takes to clear them (or timeout).
>
> Well, the problem is: What is "whatever it takes"? The changes in this 
> test are only "less bad", and typically take less time to execute. I'd 
> like to keep an eye on the test after this change is pushed to see if 
> there are any future issues with it.
>
>> Perhaps even a public API in Runtime...
>
> I think, System.gc is good enough, but maybe there is scope for 
> something else here.
>
> -Chris.
>
>> Roger
>>
>> On 3/4/2015 9:59 AM, Chris Hegarty wrote:
>>> This is a small, test only, review request to fix an intermittently
>>> failing test.
>>>
>>> It replaces a "bad" technique, heap exhaustion, with the "less bad"
>>> technique of calling System.gc, potentially multiple times, to clear
>>> weak references. With this change the test runs much quicker, and has
>>> not failed in several thousands of runs on a local machine.
>>>
>>> http://cr.openjdk.java.net/~chegar/8068260/webrev.00/webrev/
>>>
>>> -Chris.
>>



From Roger.Riggs at Oracle.com  Wed Mar  4 16:00:20 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 04 Mar 2015 11:00:20 -0500
Subject: RFR 8005226: TEST_BUG:
	java/rmi/transport/pinClientSocketFactory/PinClientSocketFactory.java
	fails intermittently
In-Reply-To: <54F72A7C.7030204@oracle.com>
References: <54F71E59.5020707@oracle.com> <54F72410.9070004@Oracle.com>
	<54F72A7C.7030204@oracle.com>
Message-ID: <54F72C14.5030704@Oracle.com>

Thanks, looks fine to me.

Roger

On 3/4/2015 10:53 AM, Chris Hegarty wrote:
> On 04/03/15 15:26, Roger Riggs wrote:
>> Hi Chris,
>>
>> Is the choice of 9999 as the ephemeral port ok?
>
> It should be, or it could be any positive integer value.
>
>> Though it is artificial is there any chance it will be confused with a
>> real port?
>
> There should be no confusion since the test is providing a custom 
> socket factory, and that factory knows about this "special" port number.
>
>> Would a negative number   (or zero) work just as well for this purpose?
>> Or does it get rejected in one of the layers it has to pass through.
>
> It gets rejected :-(
>
>> typo:  "support listing on an ephemeral port"-> "support *listening* on
>> an ephemeral port"
>
> Fixed.
>
> -Chris.
>
>> Roger
>>
>>
>> [1] http://en.wikipedia.org/wiki/Ephemeral_port
>>
>> On 3/4/2015 10:01 AM, Chris Hegarty wrote:
>>> This is a small, test only, review request to fix an intermittently
>>> failing test.
>>>
>>> There is an inherent race, and possible failure, following the
>>> getUnusedRandomPort pattern. This test can be modified to use a custom
>>> socket factory, supporting listening on an ephemeral port, without
>>> changing the behavior of the test.
>>>
>>> http://cr.openjdk.java.net/~chegar/8005226/webrev.00/webrev/
>>>
>>> -Chris.
>>



From chris.hegarty at oracle.com  Wed Mar  4 16:15:15 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 04 Mar 2015 16:15:15 +0000
Subject: RFR 8068260:
	java/io/Serializable/clearHandleTable/ClearHandleTable.java timed out
In-Reply-To: <54F72BB0.5070400@Oracle.com>
References: <54F71DDD.7000203@oracle.com> <54F721FB.70400@Oracle.com>
	<54F72B77.6030802@oracle.com> <54F72BB0.5070400@Oracle.com>
Message-ID: <54F72F93.5000003@oracle.com>

On 04/03/15 15:58, Roger Riggs wrote:
> Hi Chris,
>
> ok, though if System.gc is good enough it would not need a loop and
> timeout logic.

Ah ok, so some common library function taking a Predicate, or similar. I 
got you now.

> It would be interesting to know if it ever needs to go through the loop
> more than once.

In my testing it only ever goes through once.

> Maybe some indication of that can be added to the test output.

I added some output ( updated the webrev in-place). The test should be 
quiet unless there is a problem.

-Chris.

>
> Thanks, Roger
>
>
> On 3/4/2015 10:57 AM, Chris Hegarty wrote:
>> On 04/03/15 15:17, Roger Riggs wrote:
>>> Hi Chris,
>>>
>>> looks fine.
>>
>> Thanks Roger.
>>
>>> Do you suppose the test library should have a function that takes a set
>>> of (Weak)Refs
>>> and does whatever it takes to clear them (or timeout).
>>
>> Well, the problem is: What is "whatever it takes"? The changes in this
>> test are only "less bad", and typically take less time to execute. I'd
>> like to keep an eye on the test after this change is pushed to see if
>> there are any future issues with it.
>>
>>> Perhaps even a public API in Runtime...
>>
>> I think, System.gc is good enough, but maybe there is scope for
>> something else here.
>>
>> -Chris.
>>
>>> Roger
>>>
>>> On 3/4/2015 9:59 AM, Chris Hegarty wrote:
>>>> This is a small, test only, review request to fix an intermittently
>>>> failing test.
>>>>
>>>> It replaces a "bad" technique, heap exhaustion, with the "less bad"
>>>> technique of calling System.gc, potentially multiple times, to clear
>>>> weak references. With this change the test runs much quicker, and has
>>>> not failed in several thousands of runs on a local machine.
>>>>
>>>> http://cr.openjdk.java.net/~chegar/8068260/webrev.00/webrev/
>>>>
>>>> -Chris.
>>>
>


From tim.bell at oracle.com  Wed Mar  4 16:19:32 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 04 Mar 2015 08:19:32 -0800
Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a
	per-library basis
In-Reply-To: <54F70949.4040900@oracle.com>
References: <54F705E0.2030102@oracle.com> <54F70949.4040900@oracle.com>
Message-ID: <54F73094.8020108@oracle.com>

Magnus:

Looks good to me as well.

Tim

On 03/04/15 05:31, Erik Joelsson wrote:
> Hello,
>
> Really nice to finally see this patch getting done!
>
> Only one comment:
>
> flags.m4:
> In the grep expression, could you move the extra [] outside of the 
> actual command line options to grep so that the command line could be 
> copied to the shell for debugging in the future? Also, how hard would 
> it be to instead do AC_COMPILE_IFELSE with a dummy warning to instead 
> test for capability?
>
> /Erik
>
> On 2015-03-04 14:17, Magnus Ihse Bursie wrote:
>> When building the native code in the jdk repo, a lot of warnings are 
>> generated. So many that it's hard to spot any new issues.
>>
>> While the ultimate goal must be to address and fix these warnings 
>> individually, this bug is about disabling these warnings where they 
>> occur, so that it is easier to spot new warnings, and that the 
>> existing warnings can be addressed one at a time.
>>
>> Disabling warnings instead of fixing them can be problematic. If you 
>> are too broad with disabling warnings, you might hide future 
>> problems. On the other hand, there have been a lot of warnings that 
>> indicate serious problems that has been "hidden in plain sight" for a 
>> very long time in the code base anyway.
>>
>> I have opted to disable warnings at the library level. Disabling 
>> warnings globally would be too broad. Disabling per file would have 
>> been too tedious. Many warnings also tend to repeat across multiple 
>> files in the same library, due to e.g. less well-suited programming 
>> style or design choice. A library also seems like a suitable chunk of 
>> work to address later on, in trying to get rid of the source of the 
>> warnings.
>>
>> This fix will not get rid of all warnings, but the bulk of them. It 
>> will make the remaining warnings stick out more. The few warnings 
>> that remain are either:
>> * Not possible to disable.
>> * Not resulting from native compilation (but from linking, or 
>> javadoc, etc).
>> * Not possible to disable with this framework (this goes for builds 
>> on pre-4.4 gcc, which Oracle currently does as default on macosx), 
>> and libfontmanager on Solaris, which mixes C and C++ code. (While the 
>> solstudio C compiler does not fail on requests to disable C++ 
>> warnings, the converse is unfortunately not true). It did not seem 
>> worth the trouble to build a more extensible framework to handle 
>> this, compared to actually fixing these warnings.
>>
>> Note that the current JPRT build environment in Oracle uses a pre-4.4 
>> gcc for macosx by default, so the default macosx build will still 
>> contain warnings. When building with --with-toolchain-type=clang, the 
>> clang warning disabling kicks in. (This will be the default in JPRT 
>> later on this year.)
>>
>> I intend to file individual bugs to handle these remaining warnings, 
>> so the net result will be a completely warning free build.
>>
>> I also intend to file individual bugs on all the libraries that has 
>> had warnings disabled. I expect the outcome of these bugs to be either:
>>
>> A) The code modified so it does not trigger warnings, and the 
>> warnings re-enabled, or
>>
>> B) The warnings (or a subset of them) kept disabled, but a comment 
>> added to the makefile describing why this is the proper course of 
>> action.
>>
>> Not all bugs might be worth fixing. For instance, the GCC warnings 
>> type-limits, sign-compare, pointer-to-int-cast, conversion-null, 
>> deprecated-declarations, clobbered, int-to-pointer-cast and 
>> type-limits are all more or less benign, and is possibly the result 
>> of a false positive.
>>
>> On the other hands, warnings such as format-nonliteral, 
>> unused-result, maybe-uninitialized, format, format-security, 
>> int-to-pointer-cast, reorder and delete-non-virtual-dtor are more 
>> likely to actually point to real issues. I recommend anyone finding 
>> these warnings on a library they care about to try and fix them as 
>> soon as possible.
>>
>> Here is a summary of the libraries and binaries that have gotten 
>> warnings disabled. I'm not sure about what group owns all these 
>> libraries; if I missed sending this mail to the correct list, please 
>> help me and forward it.
>>
>> * libunpack
>> * libfdlibm
>> * libverify
>> * libjava
>> * libzip
>> * libjli/libjli_static
>> * libj2gss
>> * libsunec
>> * libj2pkcs11
>> * libnet
>> * libnio
>> * libosxkrb5
>> * libosxapp
>> * libosx
>> * libapplescriptengine
>> * libjsound
>> * libjsoundalsa
>> * libmlib_image
>> * libawt
>> * libawt_xawt
>> * libawt_lwawt
>> * liblcms
>> * libjavajpeg
>> * libawt_headless
>> * libfontmanager
>> * libsplashscreen
>> * unpack200
>> * The JVMTI demos compiledMethodLoad and waiters
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074096
>>
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.01
>>
>> /Magnus
>>
>



From Alan.Bateman at oracle.com  Wed Mar  4 16:30:47 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 04 Mar 2015 16:30:47 +0000
Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a
	per-library basis
In-Reply-To: <54F71EB8.3030109@oracle.com>
References: <54F705E0.2030102@oracle.com> <54F70D42.3010905@oracle.com>
	<54F71EB8.3030109@oracle.com>
Message-ID: <54F73337.3090309@oracle.com>

On 04/03/2015 15:03, Magnus Ihse Bursie wrote:
> I believe all warnings are important to check! Unfortunately, this has 
> not been done for a lot of warnings for a lot of time. :(
Right, although in the past we had some areas close to be cleared of 
warnings, it's just that we didn't keep up the effort and of course the 
compilers get more pedantic with each version.

>
> With this framework, it is simple to enable a single warning, 
> recompile and see the effect. Hopefully this lowers the threshold far 
> enough so that all warnings are given proper attention. The 
> incremental build functionality will come in very handy. Just by 
> simply removing a warning from the DISABLED_WARNINGS_<toolchain> on a 
> library and running "make" again, only the files affected will be 
> recompiled.
Yes, it looks easy to maintain.


>
> I can easily paste in what warning categories are disabled for a 
> specific library, yes.
>
> However, if you are asking me to build each library, individually, 
> with warnings re-enabled, and pasting the output, I'd rather not. That 
> would be a lot of work, to detangle the output of each individual 
> library.
I'm not asking that, it would be too much work. Maybe it's worth saving 
the logs somewhere so that you can point the bugs at it. It would also 
be useful for the bugs to point to your change sets (when they are 
pushed) so that it's obvious which make files were changed to silence 
the warnings.

-Alan


From stuart.marks at oracle.com  Wed Mar  4 17:56:14 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 04 Mar 2015 09:56:14 -0800
Subject: RFR 8068260:
	java/io/Serializable/clearHandleTable/ClearHandleTable.java timed out
In-Reply-To: <54F72F93.5000003@oracle.com>
References: <54F71DDD.7000203@oracle.com>
	<54F721FB.70400@Oracle.com>	<54F72B77.6030802@oracle.com>
	<54F72BB0.5070400@Oracle.com> <54F72F93.5000003@oracle.com>
Message-ID: <54F7473E.8000107@oracle.com>

Hi Chris, Roger,

Just as a background, the loop with System.gc() and sleep() was arrived at via 
review comments between Eric Wang and David Holmes. See this thread:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-June/010592.html

which continued here:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-July/010741.html

We had decided that the loop can be an "infinite" loop, since the test framework 
will timeout the test after a while (two minutes by default). As David said, if 
the weak refs haven't been cleared in that time, there's clearly a problem. In 
some ways I prefer having an "infinite" loop, since that time will be scaled by 
the timeout factor, whereas TIMES will not be.

I think the point about having a gc/sleep in a loop is that, depending on which 
GC is in use, it might take more than one cycle to clear the reference(s). In 
addition, GC is asynchronous, so the caller really does have to sleep each time.

For checking the list of weak refs, you might be able to do something like

     refs.removeIf(ref -> ref.get() == null)

if we don't care about backporting this any earlier than Java 8.

Finally, I think it would be a good idea to have a test library for this kind of 
weak reference clearing ... eventually. I think it would be good to build up 
several different use cases and then refactor the commonality into a library 
that we know they can all use. We're already building up a few examples:

1) this test
2) java/lang/annotation/loaderLeak/Main.java (mentioned above)
3) java/rmi/transport/pinLastArguments/PinLastArguments.java
    (mentioned in the bug report)

I'm not sure whether we want to do this now (i.e., part of this changeset) though.

s'marks


On 3/4/15 8:15 AM, Chris Hegarty wrote:
> On 04/03/15 15:58, Roger Riggs wrote:
>> Hi Chris,
>>
>> ok, though if System.gc is good enough it would not need a loop and
>> timeout logic.
>
> Ah ok, so some common library function taking a Predicate, or similar. I got you
> now.
>
>> It would be interesting to know if it ever needs to go through the loop
>> more than once.
>
> In my testing it only ever goes through once.
>
>> Maybe some indication of that can be added to the test output.
>
> I added some output ( updated the webrev in-place). The test should be quiet
> unless there is a problem.
>
> -Chris.
>
>>
>> Thanks, Roger
>>
>>
>> On 3/4/2015 10:57 AM, Chris Hegarty wrote:
>>> On 04/03/15 15:17, Roger Riggs wrote:
>>>> Hi Chris,
>>>>
>>>> looks fine.
>>>
>>> Thanks Roger.
>>>
>>>> Do you suppose the test library should have a function that takes a set
>>>> of (Weak)Refs
>>>> and does whatever it takes to clear them (or timeout).
>>>
>>> Well, the problem is: What is "whatever it takes"? The changes in this
>>> test are only "less bad", and typically take less time to execute. I'd
>>> like to keep an eye on the test after this change is pushed to see if
>>> there are any future issues with it.
>>>
>>>> Perhaps even a public API in Runtime...
>>>
>>> I think, System.gc is good enough, but maybe there is scope for
>>> something else here.
>>>
>>> -Chris.
>>>
>>>> Roger
>>>>
>>>> On 3/4/2015 9:59 AM, Chris Hegarty wrote:
>>>>> This is a small, test only, review request to fix an intermittently
>>>>> failing test.
>>>>>
>>>>> It replaces a "bad" technique, heap exhaustion, with the "less bad"
>>>>> technique of calling System.gc, potentially multiple times, to clear
>>>>> weak references. With this change the test runs much quicker, and has
>>>>> not failed in several thousands of runs on a local machine.
>>>>>
>>>>> http://cr.openjdk.java.net/~chegar/8068260/webrev.00/webrev/
>>>>>
>>>>> -Chris.
>>>>
>>


From stuart.marks at oracle.com  Wed Mar  4 18:10:10 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 04 Mar 2015 10:10:10 -0800
Subject: RFR 8005226: TEST_BUG:
	java/rmi/transport/pinClientSocketFactory/PinClientSocketFactory.java
	fails intermittently
In-Reply-To: <54F71E59.5020707@oracle.com>
References: <54F71E59.5020707@oracle.com>
Message-ID: <54F74A82.2020504@oracle.com>

Hi Chris,

Instead of creating a socket factory for this purpose, this test can use RMI's 
test library TestLibrary.createRegistryOnUnusedPort(). Now, internally, this 
uses the now disfavored "getUnusedRandomPort" pattern, but it can (and should) 
be changed to avoid this. In, fact, passing 0 will work, though it could use its 
own socket factory if necessary. (It would be good to keep this knowledge within 
the test library.)

The actual port number in use can be fished out of the registry implementation 
by calling TestLibrary.getRegistryPort().

s'marks


On 3/4/15 7:01 AM, Chris Hegarty wrote:
> This is a small, test only, review request to fix an intermittently failing test.
>
> There is an inherent race, and possible failure, following the
> getUnusedRandomPort pattern. This test can be modified to use a custom socket
> factory, supporting listening on an ephemeral port, without changing the
> behavior of the test.
>
> http://cr.openjdk.java.net/~chegar/8005226/webrev.00/webrev/
>
> -Chris.


From douglas.surber at oracle.com  Wed Mar  4 18:28:23 2015
From: douglas.surber at oracle.com (Douglas Surber)
Date: Wed, 04 Mar 2015 10:28:23 -0800
Subject: java.text.SimpleDateFormat.parse should recognize America/Los_Angeles
Message-ID: <6.2.5.6.2.20150304092130.05b64bf0@oracle.com>

java.text.SimpleDateFormat.parse does not recognize time zone ids.

    new SimpleDateFormat("yyyy-MM-dd HH:mm:ss 
ZZZZ").parse("2015-03-03 09:25:00 America/Los_Angeles")

does not recognize "America/Los_Angeles" as a time zone. 
"America/Los_Angeles" is a time zone id and the "ZZZZ" format looks 
for time zone names such as "PST" and "Pacific Standard Time". None 
of the various time zone formats (or at least none that I have tried) 
will recognize a time zone id, eg America/Los_Angeles.

The code in question is in java.text.SimpleDateFormat.

   private int matchZoneString(String text, int start, String[] 
zoneNames) {
       for (int i = 1; i <= 4; ++i) {
           // Checking long and short zones [1 & 2],
           // and long and short daylight [3 & 4].
           String zoneName = zoneNames[i];
           if (text.regionMatches(true, start,
                                  zoneName, 0, zoneName.length())) {
               return i;
           }
       }
       return -1;
   }

The argument zoneNames is a 5 element array. Element 0 is a time zone 
id such as "America/Los_Angeles" and the next four are long and 
short, standard and daylight time names such as "PST" and "Pacific 
Daylight Time". This array comes from 
java.text.DateFormatSymbols.getZoneStringsWrapper, which returns an 
array of such String[]s.

Changing the initial index in the for loop from 1 to 0 would include 
the zone id in the set of Strings to compare and thus would match 
"America/Los_Angeles" or "Europe/London". It would also be necessary 
to modify SimpleDateFormat.subParseZoneString to correctly set 
useSameName. A simple change would be to test if nameIndex == 0 as 
the zone id is the same for standard and daylight time though this 
might not be correct as I haven't fully investigated how useSameName 
is used.

What exactly the various format character sequences are supposed to 
recognize is sufficiently vague that no change to the spec appears 
necessary, thought it might be beneficial.

A separate issue would be to consider the performance of doing 
regionMatches over this large String[][].

Douglas



From chris.hegarty at oracle.com  Wed Mar  4 19:07:25 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 4 Mar 2015 19:07:25 +0000
Subject: RFR 8068260:
	java/io/Serializable/clearHandleTable/ClearHandleTable.java timed out
In-Reply-To: <54F7473E.8000107@oracle.com>
References: <54F71DDD.7000203@oracle.com> <54F721FB.70400@Oracle.com>
	<54F72B77.6030802@oracle.com> <54F72BB0.5070400@Oracle.com>
	<54F72F93.5000003@oracle.com> <54F7473E.8000107@oracle.com>
Message-ID: <67F211FC-9F70-4F63-8395-25693A0C4E7E@oracle.com>


> On 4 Mar 2015, at 17:56, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> Hi Chris, Roger,
> 
> Just as a background, the loop with System.gc() and sleep() was arrived at via review comments between Eric Wang and David Holmes. See this thread:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-June/010592.html
> 
> which continued here:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-July/010741.html
> 
> We had decided that the loop can be an "infinite" loop, since the test framework will timeout the test after a while (two minutes by default). As David said, if the weak refs haven't been cleared in that time, there's clearly a problem. In some ways I prefer having an "infinite" loop, since that time will be scaled by the timeout factor, whereas TIMES will not be.

If the references are not cleared after 1000 tries, then there is probably an issue and further tries are unlikely to succeed ( given the quiescent nature of the VM running the test ) . I see no benefit in relying on jtregs interrupt mechanism for this trivial case.

> I think the point about having a gc/sleep in a loop is that, depending on which GC is in use, it might take more than one cycle to clear the reference(s). In addition, GC is asynchronous, so the caller really does have to sleep each time.
> 
> For checking the list of weak refs, you might be able to do something like
> 
>    refs.removeIf(ref -> ref.get() == null)
> 
> if we don't care about backporting this any earlier than Java 8.

I?d prefer to keep the code as is, as this may be a candidate for test stabilisation in a previous release.

> Finally, I think it would be a good idea to have a test library for this kind of weak reference clearing ... eventually.

Right. This can be done under a separate bug number, as several test would need to be refactored to use it. No doubt it will generate a significant amount of debate.

-Chris.

> I think it would be good to build up several different use cases and then refactor the commonality into a library that we know they can all use. We're already building up a few examples:
> 
> 1) this test
> 2) java/lang/annotation/loaderLeak/Main.java (mentioned above)
> 3) java/rmi/transport/pinLastArguments/PinLastArguments.java
>   (mentioned in the bug report)
> 
> I'm not sure whether we want to do this now (i.e., part of this changeset) though.
> 
> s'marks
> 
> 
> On 3/4/15 8:15 AM, Chris Hegarty wrote:
>> On 04/03/15 15:58, Roger Riggs wrote:
>>> Hi Chris,
>>> 
>>> ok, though if System.gc is good enough it would not need a loop and
>>> timeout logic.
>> 
>> Ah ok, so some common library function taking a Predicate, or similar. I got you
>> now.
>> 
>>> It would be interesting to know if it ever needs to go through the loop
>>> more than once.
>> 
>> In my testing it only ever goes through once.
>> 
>>> Maybe some indication of that can be added to the test output.
>> 
>> I added some output ( updated the webrev in-place). The test should be quiet
>> unless there is a problem.
>> 
>> -Chris.
>> 
>>> 
>>> Thanks, Roger
>>> 
>>> 
>>> On 3/4/2015 10:57 AM, Chris Hegarty wrote:
>>>> On 04/03/15 15:17, Roger Riggs wrote:
>>>>> Hi Chris,
>>>>> 
>>>>> looks fine.
>>>> 
>>>> Thanks Roger.
>>>> 
>>>>> Do you suppose the test library should have a function that takes a set
>>>>> of (Weak)Refs
>>>>> and does whatever it takes to clear them (or timeout).
>>>> 
>>>> Well, the problem is: What is "whatever it takes"? The changes in this
>>>> test are only "less bad", and typically take less time to execute. I'd
>>>> like to keep an eye on the test after this change is pushed to see if
>>>> there are any future issues with it.
>>>> 
>>>>> Perhaps even a public API in Runtime...
>>>> 
>>>> I think, System.gc is good enough, but maybe there is scope for
>>>> something else here.
>>>> 
>>>> -Chris.
>>>> 
>>>>> Roger
>>>>> 
>>>>> On 3/4/2015 9:59 AM, Chris Hegarty wrote:
>>>>>> This is a small, test only, review request to fix an intermittently
>>>>>> failing test.
>>>>>> 
>>>>>> It replaces a "bad" technique, heap exhaustion, with the "less bad"
>>>>>> technique of calling System.gc, potentially multiple times, to clear
>>>>>> weak references. With this change the test runs much quicker, and has
>>>>>> not failed in several thousands of runs on a local machine.
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~chegar/8068260/webrev.00/webrev/
>>>>>> 
>>>>>> -Chris.
>>>>> 
>>> 



From chris.hegarty at oracle.com  Wed Mar  4 19:14:59 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 4 Mar 2015 19:14:59 +0000
Subject: RFR 8005226: TEST_BUG:
	java/rmi/transport/pinClientSocketFactory/PinClientSocketFactory.java
	fails intermittently
In-Reply-To: <54F74A82.2020504@oracle.com>
References: <54F71E59.5020707@oracle.com> <54F74A82.2020504@oracle.com>
Message-ID: <C5E026F5-6B27-4353-B64E-F051525C12C7@oracle.com>


> On 4 Mar 2015, at 18:10, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> Hi Chris,
> 
> Instead of creating a socket factory for this purpose, this test can use RMI's test library TestLibrary.createRegistryOnUnusedPort(). Now, internally, this uses the now disfavored "getUnusedRandomPort" pattern, but it can (and should) be changed to avoid this. In, fact, passing 0 will work, though it could use its own socket factory if necessary. (It would be good to keep this knowledge within the test library.)

Sorry, I?m confused. Are you suggesting that I change TestLibrary.createRegistryOnUnusedPort to use a socket factory, similar to the changes in the webrev? Or are you saying that the TestLibrary already supports bind to an ephemeral port and subsequently disclosing that port?

-Chris.

> The actual port number in use can be fished out of the registry implementation by calling TestLibrary.getRegistryPort().
> 
> s'marks
> 
> 
> On 3/4/15 7:01 AM, Chris Hegarty wrote:
>> This is a small, test only, review request to fix an intermittently failing test.
>> 
>> There is an inherent race, and possible failure, following the
>> getUnusedRandomPort pattern. This test can be modified to use a custom socket
>> factory, supporting listening on an ephemeral port, without changing the
>> behavior of the test.
>> 
>> http://cr.openjdk.java.net/~chegar/8005226/webrev.00/webrev/
>> 
>> -Chris.



From xueming.shen at oracle.com  Wed Mar  4 19:48:21 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 04 Mar 2015 11:48:21 -0800
Subject: RFR: JDK-8074406 DateTimeFormatter.appendZoneOrOffsetId() fails to
	resolve a ZoneOffset for OffsetDateTime
Message-ID: <54F76185.70909@oracle.com>

Stephen and Roger,

This is the DTF.appendZoneOrOffsetId() issues we discussed last year. Somehow the
ball was dropped somewhere :-)

Here is the proposed change we discussed. The only difference is I leave the ZoneOffset
to throw the DateTimeException, instead of inside the Parsed.query() directly.

I also updated the TCKZoneIdPrinterParser to (1) add the appendZoneOrOffsetId() (it appears
we don't have any corresponding test cases for it) and (2) return a ZoneOffset for "offset"
if there is indeed a ZoneOffset inside the parsed.

Issue: https://bugs.openjdk.java.net/browse/JDK-8074406
webrev: http://cr.openjdk.java.net/~sherman/8074406/webrev

Thanks!
-Sherman


From huizhe.wang at oracle.com  Wed Mar  4 19:50:55 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 04 Mar 2015 11:50:55 -0800
Subject: RFR (JAXP): 8049378: Examine references to ${java.home}/lib in JAXP
Message-ID: <54F7621F.3050300@oracle.com>

Hi,

This is the additional specification change after the move from lib to 
conf in the jigsaw/m2 forest. Besides the change from lib to conf, the 
new specification also made the reference to the location non-normative.

Please review:
http://cr.openjdk.java.net/~joehw/jdk9/8049378/webrev/

Bug (please login):
https://bugs.openjdk.java.net/browse/JDK-8049378

Thanks,
Joe



From srikanth.adayapalam at oracle.com  Wed Mar  4 15:16:30 2015
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Wed, 04 Mar 2015 20:46:30 +0530
Subject: Compiler support for private interface methods.
Message-ID: <54F721CE.4010009@oracle.com>

Hello !

The javac team is pleased to inform you that the compiler support for 
private methods in interfaces
has been released through here:

JBS: https://bugs.openjdk.java.net/browse/JDK-8071453,
HG: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/592d64800143

into the JDK9 dev stream.

This is a special announcement to the core libs team so you can consider 
whether there are libraries
that could be retrofitted to use this feature - 
https://bugs.openjdk.java.net/browse/JDK-8074282 is
also in consideration - when this is completed, you will have 
suggestions from the compiler on where
such refactorings are possible.

We appreciate your testing and any feedback and defect reports.

Thanks!
Srikanth


From aph at redhat.com  Wed Mar  4 20:21:11 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 04 Mar 2015 20:21:11 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>
	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>
Message-ID: <54F76937.2040203@redhat.com>

John's suggestion works well; the code is smaller and neater.

http://cr.openjdk.java.net/~aph/unaligned.jdk.3/
http://cr.openjdk.java.net/~aph/unaligned.hotspot.3/hotspot.patch

Andrew.


From stuart.marks at oracle.com  Wed Mar  4 21:02:13 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 04 Mar 2015 13:02:13 -0800
Subject: RFR 8005226: TEST_BUG:
	java/rmi/transport/pinClientSocketFactory/PinClientSocketFactory.java
	fails intermittently
In-Reply-To: <C5E026F5-6B27-4353-B64E-F051525C12C7@oracle.com>
References: <54F71E59.5020707@oracle.com> <54F74A82.2020504@oracle.com>
	<C5E026F5-6B27-4353-B64E-F051525C12C7@oracle.com>
Message-ID: <54F772D5.5040509@oracle.com>

On 3/4/15 11:14 AM, Chris Hegarty wrote:
>
>> On 4 Mar 2015, at 18:10, Stuart Marks <stuart.marks at oracle.com> wrote:
>>
>> Hi Chris,
>>
>> Instead of creating a socket factory for this purpose, this test can use RMI's test library TestLibrary.createRegistryOnUnusedPort(). Now, internally, this uses the now disfavored "getUnusedRandomPort" pattern, but it can (and should) be changed to avoid this. In, fact, passing 0 will work, though it could use its own socket factory if necessary. (It would be good to keep this knowledge within the test library.)
>
> Sorry, I?m confused. Are you suggesting that I change TestLibrary.createRegistryOnUnusedPort to use a socket factory, similar to the changes in the webrev? Or are you saying that the TestLibrary already supports bind to an ephemeral port and subsequently disclosing that port?

Sorry, there are several pieces moving around here and a couple (or more) layers 
of technical debt.

1) The test itself should call TestLibrary.createRegistryOnUnusedPort() and 
TestLibrary.getRegistryPort(), since those are the abstractions the test library 
is attempting to provide. Unfortunately, doing this by itself doesn't fix the 
problem, since the test library itself calls getUnusedRandomPort().

2) TestLibrary.createRegistryOnUnusedPort() can be changed to call 
LocateRegistry.createRegistry(0), which seems to be permitted by the API and the 
implementation, and which works in my limited testing. But it would need to be 
tested more thoroughly, and if for some reason it doesn't work, it could use the 
socket factory technique or some other technique.

3) Other RMI tests that create registries will need to be retrofitted to use the 
test library in this way. Probably beyond the scope of this changeset.

I'd prefer not to have the socket factory stuff added to the test, since it'd 
just have to be ripped out later when better ephemeral port handling is 
supported by the test library.

4) If a quick fix is necessary, the test could call 
LocateRegistry.createRegistry(0) itself (assuming this works well) if you don't 
want to take on the modification of the test library, but this too would have to 
be changed eventually.

So I'd like to see one of the following:

  - both (1) and (2); or
  - just (4)

Your option, depending on how much you want to take on.

s'marks


>
> -Chris.
>
>> The actual port number in use can be fished out of the registry implementation by calling TestLibrary.getRegistryPort().
>>
>> s'marks
>>
>>
>> On 3/4/15 7:01 AM, Chris Hegarty wrote:
>>> This is a small, test only, review request to fix an intermittently failing test.
>>>
>>> There is an inherent race, and possible failure, following the
>>> getUnusedRandomPort pattern. This test can be modified to use a custom socket
>>> factory, supporting listening on an ephemeral port, without changing the
>>> behavior of the test.
>>>
>>> http://cr.openjdk.java.net/~chegar/8005226/webrev.00/webrev/
>>>
>>> -Chris.
>


From Alan.Bateman at oracle.com  Wed Mar  4 21:15:22 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 04 Mar 2015 21:15:22 +0000
Subject: RFR (JAXP): 8049378: Examine references to ${java.home}/lib in
	JAXP
In-Reply-To: <54F7621F.3050300@oracle.com>
References: <54F7621F.3050300@oracle.com>
Message-ID: <54F775EA.1040903@oracle.com>

On 04/03/2015 19:50, huizhe wang wrote:
> Hi,
>
> This is the additional specification change after the move from lib to 
> conf in the jigsaw/m2 forest. Besides the change from lib to conf, the 
> new specification also made the reference to the location non-normative.
>
> Please review:
> http://cr.openjdk.java.net/~joehw/jdk9/8049378/webrev/
>
> Bug (please login):
> https://bugs.openjdk.java.net/browse/JDK-8049378
This looks okay, a small suggestion is to use {@code conf}.

The additional of the <p> tags caused me to re-read the paraph "Use the 
srevice-provider ..." where "facility" might be more better than 
"facilities".

-Alan


From philip.race at oracle.com  Wed Mar  4 21:31:34 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 04 Mar 2015 13:31:34 -0800
Subject: <AWT Dev> RFR: JDK-8074096 Disable (most) native warnings in
	JDK on a per-library basis
In-Reply-To: <54F73337.3090309@oracle.com>
References: <54F705E0.2030102@oracle.com> <54F70D42.3010905@oracle.com>
	<54F71EB8.3030109@oracle.com> <54F73337.3090309@oracle.com>
Message-ID: <54F779B6.1000503@oracle.com>

I like the overall approach.
We can then attack the warnings lib by lib and/or platform by platform.

I do want to mention that some libs like liblcms are 3rd party open 
source libraries
and it may not always be possible to convince upstream to change their code.

-phil.


On 03/04/2015 08:30 AM, Alan Bateman wrote:
> On 04/03/2015 15:03, Magnus Ihse Bursie wrote:
>> I believe all warnings are important to check! Unfortunately, this 
>> has not been done for a lot of warnings for a lot of time. :(
> Right, although in the past we had some areas close to be cleared of 
> warnings, it's just that we didn't keep up the effort and of course 
> the compilers get more pedantic with each version.
>
>>
>> With this framework, it is simple to enable a single warning, 
>> recompile and see the effect. Hopefully this lowers the threshold far 
>> enough so that all warnings are given proper attention. The 
>> incremental build functionality will come in very handy. Just by 
>> simply removing a warning from the DISABLED_WARNINGS_<toolchain> on a 
>> library and running "make" again, only the files affected will be 
>> recompiled.
> Yes, it looks easy to maintain.
>
>
>>
>> I can easily paste in what warning categories are disabled for a 
>> specific library, yes.
>>
>> However, if you are asking me to build each library, individually, 
>> with warnings re-enabled, and pasting the output, I'd rather not. 
>> That would be a lot of work, to detangle the output of each 
>> individual library.
> I'm not asking that, it would be too much work. Maybe it's worth 
> saving the logs somewhere so that you can point the bugs at it. It 
> would also be useful for the bugs to point to your change sets (when 
> they are pushed) so that it's obvious which make files were changed to 
> silence the warnings.
>
> -Alan



From lance.andersen at oracle.com  Wed Mar  4 21:46:49 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 4 Mar 2015 16:46:49 -0500
Subject: RFR (JAXP): 8049378: Examine references to ${java.home}/lib in
	JAXP
In-Reply-To: <54F775EA.1040903@oracle.com>
References: <54F7621F.3050300@oracle.com> <54F775EA.1040903@oracle.com>
Message-ID: <FA573EB6-6074-47C9-A2E9-EA1C024D642F@oracle.com>

Hi Joe,

A couple other very minor suggestions  to consider assuming -Xdoclint is clean:

-  Your new changes just use  <P> where the older code used <P></P>.   It would be nice if we can to be consistent if you have the time.  I think a while a go it was decide that <P> was the way to go.
- In some cases you start a comment off with <p> and others it is on a line of its own. When/if you go back to these files, it might be nice to be consistent (again minor issue). See XMLInputFactory as an example
- Perhaps consider @code{SchemaFactory} vs <code>SchemaFactory</code> (I think this is what Alan was suggesting below as it is in multiple files)

As long as -Xdoclint is clean, you could put this on your todo list for a rainy day and ignore for now :-)

Best
Lance

On Mar 4, 2015, at 4:15 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 04/03/2015 19:50, huizhe wang wrote:
>> Hi,
>> 
>> This is the additional specification change after the move from lib to conf in the jigsaw/m2 forest. Besides the change from lib to conf, the new specification also made the reference to the location non-normative.
>> 
>> Please review:
>> http://cr.openjdk.java.net/~joehw/jdk9/8049378/webrev/
>> 
>> Bug (please login):
>> https://bugs.openjdk.java.net/browse/JDK-8049378
> This looks okay, a small suggestion is to use {@code conf}.
> 
> The additional of the <p> tags caused me to re-read the paraph "Use the srevice-provider ..." where "facility" might be more better than "facilities".
> 
> -Alan



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 stuart.marks at oracle.com  Wed Mar  4 22:16:56 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 04 Mar 2015 14:16:56 -0800
Subject: RFR(s): 8073923: Files.lines() documentation needs clarification
In-Reply-To: <54F6C2C8.1030206@oracle.com>
References: <54F51515.1040700@oracle.com> <54F51922.4060109@oracle.com>
	<54F51FC4.4030100@oracle.com> <54F5BA28.2090404@oracle.com>
	<54F5FA90.3020008@oracle.com> <54F61920.5000808@oracle.com>
	<54F63E36.6040603@oracle.com> <54F6C2C8.1030206@oracle.com>
Message-ID: <54F78458.2000605@oracle.com>

On 3/4/15 12:31 AM, Alan Bateman wrote:
> On 03/03/2015 23:05, Stuart Marks wrote:
>> Updated webrev:
>>
>>     http://cr.openjdk.java.net/~smarks/reviews/8073923/webrev.2/
> This looks good. Minor re-wording suggestions, ignore if you want:
>
> "... reference to an open XXX, which is closed by ..."
>    => "... reference to an open XXX. The XXX is closed by ..."

Yes. Reads a bit better this way.

> "to ensure that the stream's open XXX reference is closed"
>    => "to ensure that the XXX is closed".

I considered this but sometimes the earlier mention of the XXX was far enough 
away that it wasn't clear what this was talking about. I changed these 
essentially to "to ensure that the stream's open XXX is closed" which makes more 
sense, I think, since "closing a file" makes more sense than "closing a 
reference to a file."

I've made these changes and pushed the changeset. Thanks for the reviews.

s'marks


From huizhe.wang at oracle.com  Thu Mar  5 00:35:57 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 04 Mar 2015 16:35:57 -0800
Subject: RFR (JAXP): 8049378: Examine references to ${java.home}/lib in
	JAXP
In-Reply-To: <54F775EA.1040903@oracle.com>
References: <54F7621F.3050300@oracle.com> <54F775EA.1040903@oracle.com>
Message-ID: <54F7A4ED.9070906@oracle.com>


On 3/4/2015 1:15 PM, Alan Bateman wrote:
> On 04/03/2015 19:50, huizhe wang wrote:
>> Hi,
>>
>> This is the additional specification change after the move from lib 
>> to conf in the jigsaw/m2 forest. Besides the change from lib to conf, 
>> the new specification also made the reference to the location 
>> non-normative.
>>
>> Please review:
>> http://cr.openjdk.java.net/~joehw/jdk9/8049378/webrev/
>>
>> Bug (please login):
>> https://bugs.openjdk.java.net/browse/JDK-8049378
> This looks okay, a small suggestion is to use {@code conf}.
>
> The additional of the <p> tags caused me to re-read the paraph "Use 
> the srevice-provider ..." where "facility" might be more better than 
> "facilities".

Fixed both.

Thanks,
Joe

>
> -Alan



From huizhe.wang at oracle.com  Thu Mar  5 00:54:27 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 04 Mar 2015 16:54:27 -0800
Subject: RFR (JAXP): 8049378: Examine references to ${java.home}/lib in
	JAXP
In-Reply-To: <FA573EB6-6074-47C9-A2E9-EA1C024D642F@oracle.com>
References: <54F7621F.3050300@oracle.com> <54F775EA.1040903@oracle.com>
	<FA573EB6-6074-47C9-A2E9-EA1C024D642F@oracle.com>
Message-ID: <54F7A943.8070101@oracle.com>


On 3/4/2015 1:46 PM, Lance Andersen wrote:
> Hi Joe,
>
> A couple other very minor suggestions  to consider assuming -Xdoclint 
> is clean:
>
> -  Your new changes just use  <P> where the older code used <P></P>.   
> It would be nice if we can to be consistent if you have the time.  I 
> think a while a go it was decide that <P> was the way to go.

Yes, <p> is the way to go.

> - In some cases you start a comment off with <p> and others it is on a 
> line of its own. When/if you go back to these files, it might be nice 
> to be consistent (again minor issue). See XMLInputFactory as an example

True. I kind of dropped a <p> there when there's already an empty line.

> - Perhaps consider @code{SchemaFactory} vs <code>SchemaFactory</code> 
> (I think this is what Alan was suggesting below as it is in multiple 
> files)

Sure.
>
> As long as -Xdoclint is clean, you could put this on your todo list 
> for a rainy day and ignore for now :-)

Later, in the bug-fix stage, I'll see if I can get them fixed along with 
lints. For now, I did a few 'replace-all' without manually editing the 
other inconsistent format (so you'll see some lines with{@code xxx}where 
</p> was not removed. Pls forgive me for not being complete. It's 
painful to think that I should have spent the time on the other thing, 
but I thought this was needed so that Deva could get started on StAX.

Thanks,
Joe

>
> Best
> Lance
>
> On Mar 4, 2015, at 4:15 PM, Alan Bateman <Alan.Bateman at oracle.com 
> <mailto:Alan.Bateman at oracle.com>> wrote:
>
>> On 04/03/2015 19:50, huizhe wang wrote:
>>> Hi,
>>>
>>> This is the additional specification change after the move from lib 
>>> to conf in the jigsaw/m2 forest. Besides the change from lib to 
>>> conf, the new specification also made the reference to the location 
>>> non-normative.
>>>
>>> Please review:
>>> http://cr.openjdk.java.net/~joehw/jdk9/8049378/webrev/ 
>>> <http://cr.openjdk.java.net/%7Ejoehw/jdk9/8049378/webrev/>
>>>
>>> Bug (please login):
>>> https://bugs.openjdk.java.net/browse/JDK-8049378
>> This looks okay, a small suggestion is to use {@code conf}.
>>
>> The additional of the <p> tags caused me to re-read the paraph "Use 
>> the srevice-provider ..." where "facility" might be more better than 
>> "facilities".
>>
>> -Alan
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>



From david.holmes at oracle.com  Thu Mar  5 01:01:10 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 05 Mar 2015 11:01:10 +1000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54F76937.2040203@redhat.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>
	<54F76937.2040203@redhat.com>
Message-ID: <54F7AAD6.8040206@oracle.com>

I'm only glancing at parts of this ...

On 5/03/2015 6:21 AM, Andrew Haley wrote:
> John's suggestion works well; the code is smaller and neater.
>
> http://cr.openjdk.java.net/~aph/unaligned.jdk.3/

This doesn't make sense to me:

  929     // The byte ordering of this machine
  930     public final static boolean LITTLE_ENDIAN = false;
  931     public final static boolean BIG_ENDIAN = true;

as they won't necessarily represent "this" machine! And the usage:

!     private static final ByteOrder byteOrder
!         = unsafe.getByteOrder() == Unsafe.LITTLE_ENDIAN ? 
ByteOrder.LITTLE_ENDIAN : ByteOrder.BIG_ENDIAN;

suggests getByteorder() is really isBigEndian() (which the hotspot part 
confirms) - so then the two constants can be removed completely:

private static final ByteOrder byteOrder
     = unsafe.isBigEndian() ? ByteOrder.BIG_ENDIAN : 
ByteOrder.LITTLE_ENDIAN;

David
-----

> http://cr.openjdk.java.net/~aph/unaligned.hotspot.3/hotspot.patch
>
> Andrew.
>


From frank.yuan at oracle.com  Thu Mar  5 07:30:26 2015
From: frank.yuan at oracle.com (Frank Yuan)
Date: Thu, 5 Mar 2015 15:30:26 +0800
Subject: RFR: 8061293: Update javax/xml tests to remove references of jre dir
Message-ID: <012e01d05716$41685d00$c4391700$@oracle.com>

Hi All

 

Would you like to review the code change for bug:
https://bugs.openjdk.java.net/browse/JDK-8061293, this is a Jigsaw related
bug, it's to clean up the reference to "jre" dir.

webrev: http://cr.openjdk.java.net/~fyuan/8061293/webrev/

 

Best Regards

Frank



From aph at redhat.com  Thu Mar  5 08:45:45 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 05 Mar 2015 08:45:45 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54F7AAD6.8040206@oracle.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>
	<54F76937.2040203@redhat.com> <54F7AAD6.8040206@oracle.com>
Message-ID: <54F817B9.8090500@redhat.com>

On 05/03/15 01:01, David Holmes wrote:
> I'm only glancing at parts of this ...
> 
> On 5/03/2015 6:21 AM, Andrew Haley wrote:
>> John's suggestion works well; the code is smaller and neater.
>>
>> http://cr.openjdk.java.net/~aph/unaligned.jdk.3/
> 
> This doesn't make sense to me:
> 
>   929     // The byte ordering of this machine
>   930     public final static boolean LITTLE_ENDIAN = false;
>   931     public final static boolean BIG_ENDIAN = true;
> 
> as they won't necessarily represent "this" machine! And the usage:
> 
> !     private static final ByteOrder byteOrder
> !         = unsafe.getByteOrder() == Unsafe.LITTLE_ENDIAN ? 
> ByteOrder.LITTLE_ENDIAN : ByteOrder.BIG_ENDIAN;
> 
> suggests getByteorder() is really isBigEndian() (which the hotspot part 
> confirms) - so then the two constants can be removed completely:
> 
> private static final ByteOrder byteOrder
>      = unsafe.isBigEndian() ? ByteOrder.BIG_ENDIAN : 
> ByteOrder.LITTLE_ENDIAN;

Indeed, I was thinking of giving that method a better name.  Works for me.

Andrew.




From miroslav.kos at oracle.com  Thu Mar  5 08:51:22 2015
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Thu, 05 Mar 2015 09:51:22 +0100
Subject: RFR: 8061293: Update javax/xml tests to remove references of
	jre dir
In-Reply-To: <012e01d05716$41685d00$c4391700$@oracle.com>
References: <012e01d05716$41685d00$c4391700$@oracle.com>
Message-ID: <54F8190A.5090608@oracle.com>

Looks ok to me.

Thanks
Miran


On 05/03/15 08:30, Frank Yuan wrote:
>
> Hi All
>
> Would you like to review the code change for bug: 
> https://bugs.openjdk.java.net/browse/JDK-8061293, this is a Jigsaw 
> related bug, it's to clean up the reference to "jre" dir.
>
> webrev: http://cr.openjdk.java.net/~fyuan/8061293/webrev/ 
> <http://cr.openjdk.java.net/%7Efyuan/8061293/webrev/>
>
> Best Regards
>
> Frank
>



From lance.andersen at oracle.com  Thu Mar  5 13:07:39 2015
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Thu, 5 Mar 2015 08:07:39 -0500
Subject: RFR: 8061293: Update javax/xml tests to remove references of jre
	dir
In-Reply-To: <012e01d05716$41685d00$c4391700$@oracle.com>
References: <012e01d05716$41685d00$c4391700$@oracle.com>
Message-ID: <A6736D9F-F497-40A1-95CE-9A2480855330@oracle.com>

Looks fine frank


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
Sent from my iPad

> On Mar 5, 2015, at 2:30 AM, Frank Yuan <frank.yuan at oracle.com> wrote:
> 
> Hi All
> 
> 
> 
> Would you like to review the code change for bug:
> https://bugs.openjdk.java.net/browse/JDK-8061293, this is a Jigsaw related
> bug, it's to clean up the reference to "jre" dir.
> 
> webrev: http://cr.openjdk.java.net/~fyuan/8061293/webrev/
> 
> 
> 
> Best Regards
> 
> Frank
> 


From Alan.Bateman at oracle.com  Thu Mar  5 13:12:48 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 05 Mar 2015 13:12:48 +0000
Subject: RFR (JAXP): 8049378: Examine references to ${java.home}/lib in
	JAXP
In-Reply-To: <54F7A4ED.9070906@oracle.com>
References: <54F7621F.3050300@oracle.com> <54F775EA.1040903@oracle.com>
	<54F7A4ED.9070906@oracle.com>
Message-ID: <54F85650.408@oracle.com>

On 05/03/2015 00:35, huizhe wang wrote:
> :
>
> Fixed both.
The update looks good to me.

-Alan


From chris.hegarty at oracle.com  Thu Mar  5 13:37:05 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 5 Mar 2015 13:37:05 +0000
Subject: RFR 8005226: TEST_BUG:
	java/rmi/transport/pinClientSocketFactory/PinClientSocketFactory.java
	fails intermittently
In-Reply-To: <54F772D5.5040509@oracle.com>
References: <54F71E59.5020707@oracle.com> <54F74A82.2020504@oracle.com>
	<C5E026F5-6B27-4353-B64E-F051525C12C7@oracle.com>
	<54F772D5.5040509@oracle.com>
Message-ID: <3C8AA04C-CD90-4F6D-A7F7-2033B88C6F69@oracle.com>


On 4 Mar 2015, at 21:02, Stuart Marks <stuart.marks at oracle.com> wrote:

> On 3/4/15 11:14 AM, Chris Hegarty wrote:
>> 
>>> On 4 Mar 2015, at 18:10, Stuart Marks <stuart.marks at oracle.com> wrote:
>>> 
>>> Hi Chris,
>>> 
>>> Instead of creating a socket factory for this purpose, this test can use RMI's test library TestLibrary.createRegistryOnUnusedPort(). Now, internally, this uses the now disfavored "getUnusedRandomPort" pattern, but it can (and should) be changed to avoid this. In, fact, passing 0 will work, though it could use its own socket factory if necessary. (It would be good to keep this knowledge within the test library.)
>> 
>> Sorry, I?m confused. Are you suggesting that I change TestLibrary.createRegistryOnUnusedPort to use a socket factory, similar to the changes in the webrev? Or are you saying that the TestLibrary already supports bind to an ephemeral port and subsequently disclosing that port?
> 
> Sorry, there are several pieces moving around here and a couple (or more) layers of technical debt.
> 
> 1) The test itself should call TestLibrary.createRegistryOnUnusedPort() and TestLibrary.getRegistryPort(), since those are the abstractions the test library is attempting to provide. Unfortunately, doing this by itself doesn't fix the problem, since the test library itself calls getUnusedRandomPort().
> 
> 2) TestLibrary.createRegistryOnUnusedPort() can be changed to call LocateRegistry.createRegistry(0), which seems to be permitted by the API and the implementation, and which works in my limited testing. But it would need to be tested more thoroughly, and if for some reason it doesn't work, it could use the socket factory technique or some other technique.

Great. This works well, and passes on all platforms.

I added TestLibrary.createRegistryOnEphemeralPort(). Eventually other tests using createRegistryOnUnusedPort can be moved over to createRegistryOnEphemeralPort, and then createRegistryOnUnusedPort removed. For now, lets just move PinClientSocketFactory.java and see how it goes.

Updated webrev:
  http://cr.openjdk.java.net/~chegar/8005226/webrev.01/webrev/

Thanks,
-Chris


> 3) Other RMI tests that create registries will need to be retrofitted to use the test library in this way. Probably beyond the scope of this changeset.
> 
> I'd prefer not to have the socket factory stuff added to the test, since it'd just have to be ripped out later when better ephemeral port handling is supported by the test library.
> 
> 4) If a quick fix is necessary, the test could call LocateRegistry.createRegistry(0) itself (assuming this works well) if you don't want to take on the modification of the test library, but this too would have to be changed eventually.
> 
> So I'd like to see one of the following:
> 
> - both (1) and (2); or
> - just (4)
> 
> Your option, depending on how much you want to take on.
> 
> s'marks
> 
> 
>> 
>> -Chris.
>> 
>>> The actual port number in use can be fished out of the registry implementation by calling TestLibrary.getRegistryPort().
>>> 
>>> s'marks
>>> 
>>> 
>>> On 3/4/15 7:01 AM, Chris Hegarty wrote:
>>>> This is a small, test only, review request to fix an intermittently failing test.
>>>> 
>>>> There is an inherent race, and possible failure, following the
>>>> getUnusedRandomPort pattern. This test can be modified to use a custom socket
>>>> factory, supporting listening on an ephemeral port, without changing the
>>>> behavior of the test.
>>>> 
>>>> http://cr.openjdk.java.net/~chegar/8005226/webrev.00/webrev/
>>>> 
>>>> -Chris.
>> 



From chris.hegarty at oracle.com  Thu Mar  5 13:46:27 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 5 Mar 2015 13:46:27 +0000
Subject: RFR [9] 8071472: Add field access to support setting final fields in
	readObject 
Message-ID: <3F1CE33B-5C13-4172-A78B-72F476E0654E@oracle.com>

Hi,

Peter Levart and I have been working on an API to support setting of final fields during custom deserialization. Dealing with final fields during deserialization is a pain point only partially addressed in JSR 133 ( in Java 5 ). What we are proposing is a simple API solution to resolve this.

Current limitations ( primary motivation for the new API ): 

 * defaultReadObject can set final fields, but it is somewhat limiting.
   The fields must have a value in the deserialized stream. This is
   not flexible when evolving a classes representation, or when
   dealing with transient final fields. 

 * Setting final fields in readObject using reflection requires
   java.lang.reflect.ReflectPermission("suppressAccessChecks"). 
   Granting this permission, when only required to set final fields
   during custom deserialization, is dangerous. Information
   (possibly confidential) and methods normally unavailable may
   be accessible to malicious code. 

 * It is not possible to grant 'suppressAccessChecks' for particular
   classes or objects, or restrict the ability to set final fields through
   reflection for the period of the readObject callback, and just for
   the object being reconstructed. 
  
 * Using reflection to set final fields can have a performance cost,
   as the reflective implementation may issue a barrier for each
   field set.

Outline of the new API:

 * New interface ObjectInputStream.FieldAccess with overloaded
   set(name, value) methods. Similar in some respects to Get/PutField,
   but with j.l.r.Field semantics.
 
 * The FieldAccess instance is retrieved from ObjectInputStream.fields(),
    which can only be called during a readObject callback. Similar to
    readFields() (returns GetField).

 * FieldAccess, once retrieved, ensures that all final fields are set,
   and set only once. 

 * No behaviour changes to existing code. Unless fields() is called
   existing code is unaffected.

 * Can be used with either GetFields, or defaultReadObject.

Specification:
   http://cr.openjdk.java.net/~chegar/8071472/00/specdiff/

Example:
    class Stamp implements Serializable {
        private transient final long millis;
        Stamp() { millis = System.currentTimeMillis(); }
        public long stamp() { return millis; }

        private void readObject(java.io.ObjectInputStream in) throws Exception {
            in.fields().set("millis", System.currentTimeMillis());
        }
    }

We have a fully working implementation, tests, etc, in the sandbox:
    hg clone http://hg.openjdk.java.net/jdk9/sandbox sandbox
    cd sandbox
    sh get_source.sh
    sh common/bin/hgforest.sh update -r serial-exp-branch
    
  Webrev for convenience:
    http://cr.openjdk.java.net/~chegar/8071472/00/webrev/

Feedback welcome.

-Chris.

From ivan.gerasimov at oracle.com  Thu Mar  5 15:12:23 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 05 Mar 2015 18:12:23 +0300
Subject: RFR 8073692: (cs) Inconsistent docs for CharsetDecoder.replaceWith
	and CharsetEncoder.replaceWith
Message-ID: <54F87257.4020707@oracle.com>

Hello!

It was noticed, that the javadoc for CharsetDecoder#replaceWith is 
missing the words about constraints on the length of the new replacement 
string [1].

Another small glitch is that the common part (of both encoder and 
decoder) of the 'newReplacement' param description is prepended to each 
specific description, so they read like that: "The replacement value The 
new replacement; ..."

Would you please help review the fix?

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

Sincerely yours,
Ivan

[1] 
http://docs.oracle.com/javase/8/docs/api/java/nio/charset/CharsetDecoder.html#replaceWith-java.lang.String-




From stuart.marks at oracle.com  Thu Mar  5 16:49:59 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 05 Mar 2015 08:49:59 -0800
Subject: RFR 8005226: TEST_BUG:
	java/rmi/transport/pinClientSocketFactory/PinClientSocketFactory.java
	fails intermittently
In-Reply-To: <3C8AA04C-CD90-4F6D-A7F7-2033B88C6F69@oracle.com>
References: <54F71E59.5020707@oracle.com> <54F74A82.2020504@oracle.com>
	<C5E026F5-6B27-4353-B64E-F051525C12C7@oracle.com>
	<54F772D5.5040509@oracle.com>
	<3C8AA04C-CD90-4F6D-A7F7-2033B88C6F69@oracle.com>
Message-ID: <54F88937.1060305@oracle.com>

On 3/5/15 5:37 AM, Chris Hegarty wrote:
> I added TestLibrary.createRegistryOnEphemeralPort(). Eventually other tests using createRegistryOnUnusedPort can be moved over to createRegistryOnEphemeralPort, and then createRegistryOnUnusedPort removed. For now, lets just move PinClientSocketFactory.java and see how it goes.
>
> Updated webrev:
>    http://cr.openjdk.java.net/~chegar/8005226/webrev.01/webrev/
>
> Thanks,
> -Chris

Great, having "ephemeral" in the name is more precise, and the change is pretty 
simple too. Looks good. Thanks!

s'marks


From martinrb at google.com  Thu Mar  5 17:48:38 2015
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 5 Mar 2015 09:48:38 -0800
Subject: RFR 8073692: (cs) Inconsistent docs for CharsetDecoder.replaceWith
	and CharsetEncoder.replaceWith
In-Reply-To: <54F87257.4020707@oracle.com>
References: <54F87257.4020707@oracle.com>
Message-ID: <CA+kOe09rXRZHYNdcWhCwe2N4Lx9yQTy0U+9Qb8C-5wc6s9LkBg@mail.gmail.com>

Looks good to me!

On Thu, Mar 5, 2015 at 7:12 AM, Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

> Hello!
>
> It was noticed, that the javadoc for CharsetDecoder#replaceWith is missing
> the words about constraints on the length of the new replacement string [1].
>
> Another small glitch is that the common part (of both encoder and decoder)
> of the 'newReplacement' param description is prepended to each specific
> description, so they read like that: "The replacement value The new
> replacement; ..."
>
> Would you please help review the fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8073692
> WEBREV: http://cr.openjdk.java.net/~igerasim/8073692/0/webrev/
>
> Sincerely yours,
> Ivan
>
> [1] http://docs.oracle.com/javase/8/docs/api/java/nio/charset/
> CharsetDecoder.html#replaceWith-java.lang.String-
>
>
>


From kumar.x.srinivasan at oracle.com  Thu Mar  5 18:13:50 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 05 Mar 2015 10:13:50 -0800
Subject: RFR: 8074373: NMT is not enabled if NMT option is specified after
	class path specifiers (launcher fix)
Message-ID: <54F89CDE.1040903@oracle.com>

Hello,

Please review the following bug-fix:
http://cr.openjdk.java.net/~ksrini/8074373/webrev.00/

Addresses:
https://bugs.openjdk.java.net/browse/JDK-8074373

Caused by:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/37d1442d53bc

Thanks
Kumar



From john.r.rose at oracle.com  Thu Mar  5 20:31:30 2015
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 5 Mar 2015 12:31:30 -0800
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54F817B9.8090500@redhat.com>
References: <54EB6DD1.4090803@redhat.com>
	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>
	<54EDFBA3.6080609@redhat.com> <54F4BA63.5060506@redhat.com>
	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>
	<54F716BD.2030706@redhat.com>
	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>
	<54F7263A.7040902@redhat.com>
	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>
	<54F76937.2040203@redhat.com> <54F7AAD6.8040206@oracle.com>
	<54F817B9.8090500@redhat.com>
Message-ID: <DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>

I suggest calling the configuration query "static boolean byteOrderIsBigEndian()".  Then it fits better alongside addressSize().

Now that we're down to picking identifiers we're about done.  Here are some observations on names relative to Unsafe, for those who like watching paint dry on bikesheds.

It's very common to use raw ints as enumeration constants, via this trick of defining "static final" names constants.  Andrew, you extend this trick to raw booleans (you can only have two names then but it works).  I think that follows the naming pattern of "Unsafe.addressSize", etc.

But I also would (slightly) prefer an accessor that returned raw boolean, and whose name clearly documents the sense of the boolean.  So a name like isBigEndian or isLittleEndian, returning a forthright true or false, would be reasonable.

One nit (and maybe this is why you did it the other way first):  Accessors often have get/set prefixes, but Unsafe only uses those sort of prefixes for actual load and store operations.  For configuration parameters, there are no get/set.  Since "is" is a variation of "get" (for boolean accessors), it looks (in Unsafe) like something that is loading a boolean, but it's not.  So I see why adding the "get" or "is" makes a wrong note.

? John

P.S. Whatever polarity of boolean we pick, let's use it consistently.  If we have "boolean bigEndian" somewhere, lets not allow "boolean littleEndian" parameters if we can help it.  Using true/1 to signal big-endian seems slightly better than false/0 (though I can't say why).

On Mar 5, 2015, at 12:45 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 05/03/15 01:01, David Holmes wrote:
>> I'm only glancing at parts of this ...
>> 
>> On 5/03/2015 6:21 AM, Andrew Haley wrote:
>>> John's suggestion works well; the code is smaller and neater.
>>> 
>>> http://cr.openjdk.java.net/~aph/unaligned.jdk.3/
>> 
>> This doesn't make sense to me:
>> 
>>  929     // The byte ordering of this machine
>>  930     public final static boolean LITTLE_ENDIAN = false;
>>  931     public final static boolean BIG_ENDIAN = true;
>> 
>> as they won't necessarily represent "this" machine! And the usage:
>> 
>> !     private static final ByteOrder byteOrder
>> !         = unsafe.getByteOrder() == Unsafe.LITTLE_ENDIAN ? 
>> ByteOrder.LITTLE_ENDIAN : ByteOrder.BIG_ENDIAN;
>> 
>> suggests getByteorder() is really isBigEndian() (which the hotspot part 
>> confirms) - so then the two constants can be removed completely:
>> 
>> private static final ByteOrder byteOrder
>>     = unsafe.isBigEndian() ? ByteOrder.BIG_ENDIAN : 
>> ByteOrder.LITTLE_ENDIAN;
> 
> Indeed, I was thinking of giving that method a better name.  Works for me.
> 
> Andrew.



From david.holmes at oracle.com  Thu Mar  5 21:16:21 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 06 Mar 2015 07:16:21 +1000
Subject: RFR: 8074373: NMT is not enabled if NMT option is specified after
	class path specifiers (launcher fix)
In-Reply-To: <54F89CDE.1040903@oracle.com>
References: <54F89CDE.1040903@oracle.com>
Message-ID: <54F8C7A5.6020400@oracle.com>

On 6/03/2015 4:13 AM, Kumar Srinivasan wrote:
> Hello,
>
> Please review the following bug-fix:
> http://cr.openjdk.java.net/~ksrini/8074373/webrev.00/

Ugghhh! Can't believe we overlooked that :( Are we sure this is the last 
remaining glitch here?

Looks good.

Thanks,
David

> Addresses:
> https://bugs.openjdk.java.net/browse/JDK-8074373
>
> Caused by:
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/37d1442d53bc
>
> Thanks
> Kumar
>


From kumar.x.srinivasan at oracle.com  Thu Mar  5 22:28:32 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 05 Mar 2015 14:28:32 -0800
Subject: RFR: 8074373: NMT is not enabled if NMT option is specified after
	class path specifiers (launcher fix)
In-Reply-To: <54F8C7A5.6020400@oracle.com>
References: <54F89CDE.1040903@oracle.com> <54F8C7A5.6020400@oracle.com>
Message-ID: <54F8D890.2020107@oracle.com>


On 3/5/2015 1:16 PM, David Holmes wrote:
> On 6/03/2015 4:13 AM, Kumar Srinivasan wrote:
>> Hello,
>>
>> Please review the following bug-fix:
>> http://cr.openjdk.java.net/~ksrini/8074373/webrev.00/
>
> Ugghhh! Can't believe we overlooked that :( Are we sure this is the 
> last remaining glitch here?

Yes :-[ ,  that is it, as far as I can tell.

Kumar

>
> Looks good.
>
> Thanks,
> David
>
>> Addresses:
>> https://bugs.openjdk.java.net/browse/JDK-8074373
>>
>> Caused by:
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/37d1442d53bc
>>
>> Thanks
>> Kumar
>>



From scolebourne at joda.org  Thu Mar  5 22:53:57 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 5 Mar 2015 22:53:57 +0000
Subject: RFR: JDK-8074406 DateTimeFormatter.appendZoneOrOffsetId() fails
	to resolve a ZoneOffset for OffsetDateTime
In-Reply-To: <54F76185.70909@oracle.com>
References: <54F76185.70909@oracle.com>
Message-ID: <CACzrW9DADKE2+-BZ92DvG5Mw+fXUw=G-2fuW1Bgwhd1T25JS5Q@mail.gmail.com>

I think the fix looks good. I haven't had time to look through the
tests in detail (as there are lots)
Stephen

On 4 March 2015 at 19:48, Xueming Shen <xueming.shen at oracle.com> wrote:
> Stephen and Roger,
>
> This is the DTF.appendZoneOrOffsetId() issues we discussed last year.
> Somehow the
> ball was dropped somewhere :-)
>
> Here is the proposed change we discussed. The only difference is I leave the
> ZoneOffset
> to throw the DateTimeException, instead of inside the Parsed.query()
> directly.
>
> I also updated the TCKZoneIdPrinterParser to (1) add the
> appendZoneOrOffsetId() (it appears
> we don't have any corresponding test cases for it) and (2) return a
> ZoneOffset for "offset"
> if there is indeed a ZoneOffset inside the parsed.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8074406
> webrev: http://cr.openjdk.java.net/~sherman/8074406/webrev
>
> Thanks!
> -Sherman


From chris.hegarty at oracle.com  Fri Mar  6 11:59:28 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 6 Mar 2015 11:59:28 +0000
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54E393BC.4030600@Oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>
	<54DE1969.2040508@gmail.com> <54E393BC.4030600@Oracle.com>
Message-ID: <992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>

Roger,

I?ve taken a look at these changes in the sandbox ( JDK-8046092-branch ). Overall I welcome this addition. 

Some comments, most of which I stuffed into a webrev based on your branch,
  http://cr.openjdk.java.net/~chegar/process_comments/webrev/

1) ProcessHandle.compareTo() can drop the ClassCastException
    Also, I think the comparison is the wrong way around. It should
    be compare(this, other), rather than compare(other, this), right?

2) I know there has been a lot of discussion about the use of CF, 
    but I have a few more comments:
    
    a) Both onExist and onProcessExit are implemented to unconditionally
        throw UOE. Is the intention to make the implementation of these
        methods optional? If so, then UOE should be documented, If not,
        then I think they can be abstract, right?
      
    b) The wording in the spec talks about async functions and actions.
        I think this may be not quite right. The intention is to support, as is 
        provided by CF, the ability to chain both sync and async tasks.
        [ I suggested some wording in the webrev ]

    c) Why the need for ISE if the process is the current process, and not
        just return a CF that never completes? Do you consider this an
        error situation that you want to notify, or consistency with other
        parts of the API ?

    d) I wonder if onProcessExit should have a small API note, saying
        that it is preferred over onExit, when you have a Process. Or
        something to promote its use over onExit, or briefly explain its
        existence. ( I know why it is there, but it may appear as duplication )

     e) Maybe onProcessExit would benefit from an apiNote to indicate
         that it is essentially an alternative to waitFor() ?

3) Should ProcessHandle.getPid declare that it can throw IOE?
    Process.getPid declares UOE.

4) ProcessHandle.Info.user() ? owner() seems more appropriate, no?

5) The description of info() talks about fields, when it is an interface.
     I added some suggested rewording. Also, all methods now return
     references, so -1 can be removed. Similar for the Info class description.
        
6) There are a couple of @since 1.9 tags missing from Process 
     supportsDestroyForcibly and onProcessExit

That?s all for now.

-Chris.





From thomas.stuefe at gmail.com  Fri Mar  6 12:40:17 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 6 Mar 2015 13:40:17 +0100
Subject: libjli, get_cpuid() implementation missing for MacOs, breaks
	libjli.so build in slowdebug
Message-ID: <CAA-vtUyFSpCWBamXDZVv4LURQGLwMCx947AU8RUOE8Vq9m3qpw@mail.gmail.com>

Hi all,

I see a build error when building the libjli on MacOs with slowdebug:

Undefined symbols for architecture x86_64:
  "_get_cpuid", referenced from:
      _hyperthreading_support in ergo_i586.o
      _logical_processors_per_package in ergo_i586.o
ld: symbol(s) not found for architecture x86_64


The reason seems to me that is that in ergo_i586.c, the implementation for
"get_cpuid()" is missing for the MacOS case (one is provided for solaris
and linux).

This only breaks the build in slowdebug, because the function is only used
from static functions which are not exported; so when building with
optimization (e.g. fastdebug), all these functions are thrown away by the
compiler and therefore get_cpuid() is not needed.

I opened a bug:

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

but do not provide a fix because I am not sure which way to fix this:

- one could provide an empty implementation for this function
- or one could provide a fully functional implementation

Also, maybe I overlooked something and my analysis is wrong.

What do you guys think?

Kind Regards, Thomas Stuefe


From ivan.gerasimov at oracle.com  Fri Mar  6 12:57:26 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 06 Mar 2015 15:57:26 +0300
Subject: RFR 8073692: (cs) Inconsistent docs for CharsetDecoder.replaceWith
	and CharsetEncoder.replaceWith
In-Reply-To: <CA+kOe09rXRZHYNdcWhCwe2N4Lx9yQTy0U+9Qb8C-5wc6s9LkBg@mail.gmail.com>
References: <54F87257.4020707@oracle.com>
	<CA+kOe09rXRZHYNdcWhCwe2N4Lx9yQTy0U+9Qb8C-5wc6s9LkBg@mail.gmail.com>
Message-ID: <54F9A436.9010202@oracle.com>

Thanks!

On 05.03.2015 20:48, Martin Buchholz wrote:
> Looks good to me!
>
> On Thu, Mar 5, 2015 at 7:12 AM, Ivan Gerasimov 
> <ivan.gerasimov at oracle.com <mailto:ivan.gerasimov at oracle.com>> wrote:
>
>     Hello!
>
>     It was noticed, that the javadoc for CharsetDecoder#replaceWith is
>     missing the words about constraints on the length of the new
>     replacement string [1].
>
>     Another small glitch is that the common part (of both encoder and
>     decoder) of the 'newReplacement' param description is prepended to
>     each specific description, so they read like that: "The
>     replacement value The new replacement; ..."
>
>     Would you please help review the fix?
>
>     BUGURL: https://bugs.openjdk.java.net/browse/JDK-8073692
>     WEBREV: http://cr.openjdk.java.net/~igerasim/8073692/0/webrev/
>     <http://cr.openjdk.java.net/%7Eigerasim/8073692/0/webrev/>
>
>     Sincerely yours,
>     Ivan
>
>     [1]
>     http://docs.oracle.com/javase/8/docs/api/java/nio/charset/CharsetDecoder.html#replaceWith-java.lang.String-
>
>
>



From staffan.larsen at oracle.com  Fri Mar  6 13:30:37 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 6 Mar 2015 14:30:37 +0100
Subject: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
In-Reply-To: <3CB05A58-C466-4F91-A405-694F2ADDA401@oracle.com>
References: <B5F7A180-60F2-4B08-87B1-A8479D8AC43E@oracle.com>
	<BBFDE9CE-36F9-42DE-B058-B871ED7E489F@oracle.com>
	<54E1D71A.1080906@univ-mlv.fr>
	<7AE8811E-F669-480E-AD91-8300561BD8B7@oracle.com>
	<313ABEF2-036C-4E7F-A15D-F3240E417629@oracle.com>
	<3CB05A58-C466-4F91-A405-694F2ADDA401@oracle.com>
Message-ID: <B3715318-6B57-4BEF-8BC8-FE463840488A@oracle.com>

I would like to backport this bug fix to jdk8 - does anyone see any problems with that? The patch applies cleanly (after shuffling) and the java/lang/invoke/ tests succeed.

Thanks,
/Staffan

From forax at univ-mlv.fr  Fri Mar  6 14:09:08 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 06 Mar 2015 15:09:08 +0100
Subject: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
In-Reply-To: <B3715318-6B57-4BEF-8BC8-FE463840488A@oracle.com>
References: <B5F7A180-60F2-4B08-87B1-A8479D8AC43E@oracle.com>
	<BBFDE9CE-36F9-42DE-B058-B871ED7E489F@oracle.com>
	<54E1D71A.1080906@univ-mlv.fr>
	<7AE8811E-F669-480E-AD91-8300561BD8B7@oracle.com>
	<313ABEF2-036C-4E7F-A15D-F3240E417629@oracle.com>
	<3CB05A58-C466-4F91-A405-694F2ADDA401@oracle.com>
	<B3715318-6B57-4BEF-8BC8-FE463840488A@oracle.com>
Message-ID: <54F9B504.6070208@univ-mlv.fr>


On 03/06/2015 02:30 PM, Staffan Larsen wrote:
> I would like to backport this bug fix to jdk8 - does anyone see any problems with that? The patch applies cleanly (after shuffling) and the java/lang/invoke/ tests succeed.
>
> Thanks,
> /Staffan

I see no problem, quite the opposite, please backport it,
nobody like big stack traces.

R?mi



From magnus.ihse.bursie at oracle.com  Fri Mar  6 16:13:09 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 06 Mar 2015 17:13:09 +0100
Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a
	per-library basis
In-Reply-To: <54F73337.3090309@oracle.com>
References: <54F705E0.2030102@oracle.com> <54F70D42.3010905@oracle.com>
	<54F71EB8.3030109@oracle.com> <54F73337.3090309@oracle.com>
Message-ID: <54F9D215.8090806@oracle.com>

On 2015-03-04 17:30, Alan Bateman wrote:
> On 04/03/2015 15:03, Magnus Ihse Bursie wrote:
>> I believe all warnings are important to check! Unfortunately, this 
>> has not been done for a lot of warnings for a lot of time. :(
> Right, although in the past we had some areas close to be cleared of 
> warnings, it's just that we didn't keep up the effort and of course 
> the compilers get more pedantic with each version.
>
>>
>> With this framework, it is simple to enable a single warning, 
>> recompile and see the effect. Hopefully this lowers the threshold far 
>> enough so that all warnings are given proper attention. The 
>> incremental build functionality will come in very handy. Just by 
>> simply removing a warning from the DISABLED_WARNINGS_<toolchain> on a 
>> library and running "make" again, only the files affected will be 
>> recompiled.
> Yes, it looks easy to maintain.
>
>
>>
>> I can easily paste in what warning categories are disabled for a 
>> specific library, yes.
>>
>> However, if you are asking me to build each library, individually, 
>> with warnings re-enabled, and pasting the output, I'd rather not. 
>> That would be a lot of work, to detangle the output of each 
>> individual library.
> I'm not asking that, it would be too much work. Maybe it's worth 
> saving the logs somewhere so that you can point the bugs at it. It 
> would also be useful for the bugs to point to your change sets (when 
> they are pushed) so that it's obvious which make files were changed to 
> silence the warnings.

I'll try to locate a suitable way of storing the logs, and record a 
pointer to that in the bugs. I'll also link to the change set in the 
bugs as you request.

/Magnus

>
> -Alan



From magnus.ihse.bursie at oracle.com  Fri Mar  6 16:14:57 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 06 Mar 2015 17:14:57 +0100
Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a
	per-library basis
In-Reply-To: <54F70949.4040900@oracle.com>
References: <54F705E0.2030102@oracle.com> <54F70949.4040900@oracle.com>
Message-ID: <54F9D281.3030206@oracle.com>

On 2015-03-04 14:31, Erik Joelsson wrote:
> Hello,
>
> Really nice to finally see this patch getting done!
>
> Only one comment:
>
> flags.m4:
> In the grep expression, could you move the extra [] outside of the 
> actual command line options to grep so that the command line could be 
> copied to the shell for debugging in the future? Also, how hard would 
> it be to instead do AC_COMPILE_IFELSE with a dummy warning to instead 
> test for capability?

I have updated the fix to use the eminent FLAGS_COMPILER_CHECK_ARGUMENTS 
instead. :-)

http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.02

/Magnus



From aph at redhat.com  Fri Mar  6 18:50:41 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 06 Mar 2015 18:50:41 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>
References: <54EB6DD1.4090803@redhat.com>
	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>
	<54EDFBA3.6080609@redhat.com> <54F4BA63.5060506@redhat.com>
	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>
	<54F716BD.2030706@redhat.com>
	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>
	<54F7263A.7040902@redhat.com>
	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>
	<54F76937.2040203@redhat.com> <54F7AAD6.8040206@oracle.com>
	<54F817B9.8090500@redhat.com>
	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>
Message-ID: <54F9F701.90501@redhat.com>

I've tried to so everything I've been asked.  If this version passes
muster with everyone I'll Javadoc all the public methods and fields
and put it up for RFA next week.

I guess it's going to need a lot of testing and security analysis.

I added versions of all {put,get} methods with the boolean bigEndian
argument.  This makes HeapByteBuffer much cleaner, and it does not
need to know the machine endianness at all.  I hope that's OK.

Andrew.


http://cr.openjdk.java.net/~aph/unaligned.hotspot.4/
http://cr.openjdk.java.net/~aph/unaligned.jdk.4/


From Roger.Riggs at Oracle.com  Fri Mar  6 18:58:42 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 06 Mar 2015 13:58:42 -0500
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>
	<54DE1969.2040508@gmail.com> <54E393BC.4030600@Oracle.com>
	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>
Message-ID: <54F9F8E2.1020502@Oracle.com>

Hi Chris,

Thanks for the comments.

On 3/6/2015 6:59 AM, Chris Hegarty wrote:
> Roger,
>
> I?ve taken a look at these changes in the sandbox ( JDK-8046092-branch ). Overall I welcome this addition.
>
> Some comments, most of which I stuffed into a webrev based on your branch,
>    http://cr.openjdk.java.net/~chegar/process_comments/webrev/
>
> 1) ProcessHandle.compareTo() can drop the ClassCastException
>      Also, I think the comparison is the wrong way around. It should
>      be compare(this, other), rather than compare(other, this), right?
yes, thanks
>
> 2) I know there has been a lot of discussion about the use of CF,
>      but I have a few more comments:
>      
>      a) Both onExit and onProcessExit are implemented to unconditionally
>          throw UOE. Is the intention to make the implementation of these
>          methods optional? If so, then UOE should be documented, If not,
>          then I think they can be abstract, right?
There are existing non-jdk implementations of Process and it would be 
source
incompatible if default implementations were not supplied.  So, not 
abstract.

Since the behavior applies to Process, the note in the class documentation
defines the behavior.
"Methods of {@code Process} that are not otherwise specified or 
overridden throw
  {@link java.lang.UnsupportedOperationException}."

More direct documentation could be provided in the override of onExit
but that would raise the visibility to ordinary developers who should use
onProcessExit that returns the correctly typed CF and not onExit.
The note should be sufficient for implementers without distracting the 
ordinary developer.

Perhaps, a description similar to that used in destroy(), the behavior 
of Processes
returned from ProcessBuilder can be more tightly specified. Alternatively,
ProcessBuilder could specify the behavior of Process instances it 
returns, at present,
the behavior of the Process instances is split between the two classes.

>        
>      b) The wording in the spec talks about async functions and actions.
>          I think this may be not quite right. The intention is to support, as is
>          provided by CF, the ability to chain both sync and async tasks.
>          [ I suggested some wording in the webrev ]
Yes, thanks for the wording.
Note that the completion of the returned CF is always performed 
asynchronously.
Any additional behaviors dependent on the CF can be async or sync.
>
>      c) Why the need for ISE if the process is the current process, and not
>          just return a CF that never completes? Do you consider this an
>          error situation that you want to notify, or consistency with other
>          parts of the API ?
Since a CF for the current process will never complete it is a 
programmer error and should
be notified immediately.  Though consistency might be desirable, it 
would lead to a situation
that is very hard to debug without the understanding that a PH happens 
to refer to the current process.
>
>      d) I wonder if onProcessExit should have a small API note, saying
>          that it is preferred over onExit, when you have a Process. Or
>          something to promote its use over onExit, or briefly explain its
>          existence. ( I know why it is there, but it may appear as duplication )
I'm open to suggestions;  it might become a distraction. The API goes to 
some pains
to make sure onExit has minimal visibility in Process.
>
>       e) Maybe onProcessExit would benefit from an apiNote to indicate
>           that it is essentially an alternative to waitFor() ?
Yes, that would be useful to point out the additional functionality and 
alternative
programming model.
>
> 3) Should ProcessHandle.getPid declare that it can throw IOE?
>      Process.getPid declares UOE.
Process declares UOE because not all subclasses can be guaranteed to 
implement it.
All other implementations of ProcessHandle will create PH instances only
when there is an (initially) valid value for the pid.

But I see your point about the contract of ProcessHandle;
Process cannot add exceptional behavior outside of the scope defined by PH.

>
> 4) ProcessHandle.Info.user() ? owner() seems more appropriate, no?
Most typical command line tools identify it as the 'user';
(It was owner in a previous iteration).
>
> 5) The description of info() talks about fields, when it is an interface.
>       I added some suggested rewording. Also, all methods now return
>       references, so -1 can be removed. Similar for the Info class description.
Thanks for the improvements.
>          
> 6) There are a couple of @since 1.9 tags missing from Process
>       supportsDestroyForcibly and onProcessExit
ok

Thanks, Roger
>
> That?s all for now.
>
> -Chris.
>
>
>



From brent.christian at oracle.com  Fri Mar  6 19:08:29 2015
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 06 Mar 2015 11:08:29 -0800
Subject: RFC: Adding ConcurrentModificationException for
	HashMap.computeIfAbsent(), and JDK-8071667
In-Reply-To: <54D52E37.6040705@oracle.com>
References: <54D1616F.50104@oracle.com>
	<54D18B9A.2020906@oracle.com>	<84AD741C-CB02-4540-B41B-8F95490FF8E4@oracle.com>	<54D2BB16.80508@oracle.com>
	<77020461-FD36-41FC-9996-9B476670C20D@oracle.com>
	<54D52E37.6040705@oracle.com>
Message-ID: <54F9FB2D.6070908@oracle.com>

Hi.  I'm picking this back up now.

In Map/HashMap, there are already two methods that accept lambdas and 
throw a CME:
   forEach(BiConsumer)
   replaceAll(BiFunction)

The Map interface documents these methods to state that "Exceptions are 
relayed to the caller", and has an @throws CME tag "if an entry is found 
to be removed".  (The default code does not throw a CME if items are added).

HashMap adds no additional documentation on these methods.  It has code 
to check the modCount, and throws a CME if it changes.


The Map/HashMap methods I would like to update with this fix are:
   compute(Key, BiFunction)
   computeIfAbsent(Key, Function)
   computeIfPresent(Key, BiFunction)
   merge(Key, Value, BiFunction)

I would like to update the docs & code as follows:
Map:
     Docs: discourage modifying the map from function code; encourage 
implementing classes to detect/throw CME
     Code: no change

HashMap/Hashtable:
     Docs: document that structural modifications will result in a CME; 
add @throws CME
     Code: check modCount & throw CME

ConcurrentMap:
     Docs: discourage modifying the map from function code
     Code: no change


My first draft for the docs change, on computeIfAbsent():

diff -r 330dcd651f3b src/java.base/share/classes/java/util/Map.java
--- a/src/java.base/share/classes/java/util/Map.java    Mon Feb 02 
12:35:18 2015 -0800
+++ b/src/java.base/share/classes/java/util/Map.java    Fri Feb 06 
12:49:19 2015 -0800
@@ -925,6 +925,11 @@
       * }
       * }</pre>
       *
+     * <p>The mappingFunction itself should not make changes to this map.
+     * Implementing classes are encouraged to detect such modifications and
+     * throw ConcurrentModificationException. The default 
implementation does
+     * not do so.
+     *
       * <p>The default implementation makes no guarantees about 
synchronization
       * or atomicity properties of this method. Any implementation 
providing
       * atomicity guarantees must override this method and document its

diff -r 330dcd651f3b src/java.base/share/classes/java/util/HashMap.java
--- a/src/java.base/share/classes/java/util/HashMap.java        Mon Feb 
02 12:35:18 2015 -0800
+++ b/src/java.base/share/classes/java/util/HashMap.java        Fri Feb 
06 12:49:19 2015 -0800
@@ -1082,6 +1082,17 @@
          return null;
      }

+    /**
+     * {@inheritDoc}
+     *
+     * <p>The mappingFunction itself should not make changes to this map.
+     * If the function causes a structural modification to the map, a
+     * ConcurrentModificationException will be thrown.  As with 
iterators, this
+     * exception is thrown on a best-effort basis.
+     *
+     * @throws ConcurrentModificationException if a structural change was
+     * detected while executing the mappingFunction
+     */
      @Override
      public V computeIfAbsent(K key,
                               Function<? super K, ? extends V> 
mappingFunction) {

diff -r 330dcd651f3b 
src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java
--- 
a/src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java 
   Mon Feb 02 12:35:18 2015 -0800
+++ 
b/src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java 
   Fri Feb 06 12:49:19 2015 -0800
@@ -305,6 +305,8 @@
       * threads attempt updates including potentially calling the mapping
       * function multiple times.
       *
+     * <p>The mappingFunction itself should not make changes to this map.
+     *
       * <p>This implementation assumes that the ConcurrentMap cannot 
contain null
       * values and {@code get()} returning null unambiguously means the 
key is
---

If that looks okay, I will apply it to the other methods.


I came across a few methods used by the list classes that I wanted to 
point out:

forEach(Consumer) on the Iterable interface
removeIf(Predicate) on the Collection interface
replaceAll(UnaryOperator) on the List interface

They all document that exceptions are relayed to the caller.  They do 
not have a @throws CME tag.  The default code uses iterators (or 
enhanced for()).   LinkedList uses the default versions.  ArrayList 
overrides the methods, adds no docs of its own, and has code to check 
the modCount and throw CME.

Would an "@throws CME" improve the JavaDoc of these default methods? 
I'm leaning toward, "not really."  Between the clause about exceptions 
being relayed to the caller, and knowing that the default method is 
using iterators (mentioned in the JavaDoc), and that iterators will 
throw CMEs, one can deduce that modifying the list from the lambda will 
result in a CME.  It's not clearly spelled out, but then, modifying the 
collection this way falls outside the intended usage of these methods.

Thanks for any additional feedback.

-Brent

On 2/6/15 1:12 PM, Brent Christian wrote:
> diff -r 330dcd651f3b src/java.base/share/classes/java/util/Map.java
> --- a/src/java.base/share/classes/java/util/Map.java    Mon Feb 02
> 12:35:18 2015 -0800
> +++ b/src/java.base/share/classes/java/util/Map.java    Fri Feb 06
> 12:49:19 2015 -0800
> @@ -925,6 +925,11 @@
>        * }
>        * }</pre>
>        *
> +     * <p>The mappingFunction itself should not make changes to this map.
> +     * Implementing classes are encouraged to detect such modifications
> and
> +     * throw ConcurrentModificationException. The default
> implementation does
> +     * not do so.
> +     *
>        * <p>The default implementation makes no guarantees about
> synchronization
>        * or atomicity properties of this method. Any implementation
> providing
>        * atomicity guarantees must override this method and document its
>
> diff -r 330dcd651f3b src/java.base/share/classes/java/util/HashMap.java
> --- a/src/java.base/share/classes/java/util/HashMap.java        Mon Feb
> 02 12:35:18 2015 -0800
> +++ b/src/java.base/share/classes/java/util/HashMap.java        Fri Feb
> 06 12:49:19 2015 -0800
> @@ -1082,6 +1082,17 @@
>           return null;
>       }
>
> +    /**
> +     * {@inheritDoc}
> +     *
> +     * <p>The mappingFunction itself should not make changes to this map.
> +     * If the function causes a structural modification to the map, a
> +     * ConcurrentModificationException will be thrown.  As with
> iterators, this
> +     * exception is thrown on a best-effort basis.
> +     *
> +     * @throws ConcurrentModificationException if a structural change was
> +     * detected while executing the mappingFunction
> +     */
>       @Override
>       public V computeIfAbsent(K key,
>                                Function<? super K, ? extends V>
> mappingFunction) {
>
> diff -r 330dcd651f3b
> src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java
> ---
> a/src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java
>      Mon Feb 02 12:35:18 2015 -0800
> +++
> b/src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java
>      Fri Feb 06 12:49:19 2015 -0800
> @@ -305,6 +305,8 @@
>        * threads attempt updates including potentially calling the mapping
>        * function multiple times.
>        *
> +     * <p>The mappingFunction itself should not make changes to this map.
> +     *
>        * <p>This implementation assumes that the ConcurrentMap cannot
> contain null
>        * values and {@code get()} returning null unambiguously means the
> key is


From jason_mehrens at hotmail.com  Fri Mar  6 19:34:34 2015
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Fri, 6 Mar 2015 13:34:34 -0600
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>
	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>
	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>
	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>
	<54DDEFE0.7090108@gmail.com>
	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>
	<54DE1506.8020407@gmail.com>
	<54DE15BC.7040007@redhat.com>,<54DE1969.2040508@gmail.com>
	<54E393BC.4030600@Oracle.com>,
	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>
Message-ID: <BLU175-W460A71BD3351510864D3E0831C0@phx.gbl>

Hi Chris,

 

Since getPid can throw UOE that means that compareTo could now throw UOE.

 

Jason


----------------------------------------
> Subject: Re: JEP 102 Process Updates revised API draft
> From: chris.hegarty at oracle.com
> Date: Fri, 6 Mar 2015 11:59:28 +0000
> To: Roger.Riggs at oracle.com
> CC: core-libs-dev at openjdk.java.net
>
> Roger,
>
> I?ve taken a look at these changes in the sandbox ( JDK-8046092-branch ). Overall I welcome this addition.
>
> Some comments, most of which I stuffed into a webrev based on your branch,
> http://cr.openjdk.java.net/~chegar/process_comments/webrev/
>
> 1) ProcessHandle.compareTo() can drop the ClassCastException
> Also, I think the comparison is the wrong way around. It should
> be compare(this, other), rather than compare(other, this), right?
>
> 2) I know there has been a lot of discussion about the use of CF,
> but I have a few more comments:
>
> a) Both onExist and onProcessExit are implemented to unconditionally
> throw UOE. Is the intention to make the implementation of these
> methods optional? If so, then UOE should be documented, If not,
> then I think they can be abstract, right?
>
> b) The wording in the spec talks about async functions and actions.
> I think this may be not quite right. The intention is to support, as is
> provided by CF, the ability to chain both sync and async tasks.
> [ I suggested some wording in the webrev ]
>
> c) Why the need for ISE if the process is the current process, and not
> just return a CF that never completes? Do you consider this an
> error situation that you want to notify, or consistency with other
> parts of the API ?
>
> d) I wonder if onProcessExit should have a small API note, saying
> that it is preferred over onExit, when you have a Process. Or
> something to promote its use over onExit, or briefly explain its
> existence. ( I know why it is there, but it may appear as duplication )
>
> e) Maybe onProcessExit would benefit from an apiNote to indicate
> that it is essentially an alternative to waitFor() ?
>
> 3) Should ProcessHandle.getPid declare that it can throw IOE?
> Process.getPid declares UOE.
>
> 4) ProcessHandle.Info.user() ? owner() seems more appropriate, no?
>
> 5) The description of info() talks about fields, when it is an interface.
> I added some suggested rewording. Also, all methods now return
> references, so -1 can be removed. Similar for the Info class description.
>
> 6) There are a couple of @since 1.9 tags missing from Process
> supportsDestroyForcibly and onProcessExit
>
> That?s all for now.
>
> -Chris.
>
>
> 		 	   		  

From martinrb at google.com  Fri Mar  6 19:35:51 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 6 Mar 2015 11:35:51 -0800
Subject: Why not "weakNanoTime" for jdk9?
Message-ID: <CA+kOe08ypd93wW4GrcwhUrzGsqx_DnEYXWG6pKnDhs5bHUfb2w@mail.gmail.com>

We all know that nanoTime has problems.  Many (most?) users of nanoTime,
especially for benchmarking or concurrent algorithms, don't really care
about the monotonicity guarantee and just want a "best-effort"
"as-efficient-as-possible" version of nanoTime.  Sure, some algorithms in
java.util.concurrent might need to change slightly to accommodate nanoTime
going backwards, but we already do this to some extent.

http://shipilev.net/blog/2014/nanotrusting-nanotime/

Some users have already created such a private nanoTime.


From brian.burkhalter at oracle.com  Fri Mar  6 20:03:56 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 6 Mar 2015 12:03:56 -0800
Subject: [9] RFR of 8074460: Always print seeds used in [Splittable]Random
	instances in java.math tests
Message-ID: <2FF58C0F-8209-48B3-96B1-20B04AD2E264@oracle.com>

Please review at your convenience:

Issue:	https://bugs.openjdk.java.net/browse/JDK-8074460
Patch:	http://cr.openjdk.java.net/~bpb/8074460/webrev.00/

Summary: Create a utility class which creates a pseudorandom number generator (PRNG) and retains the seed. Use this class in java.math tests which use a PRNG. Always print the seed value before the PRNG is used.

Thanks,

Brian

From aph at redhat.com  Fri Mar  6 20:14:31 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 06 Mar 2015 20:14:31 +0000
Subject: Why not "weakNanoTime" for jdk9?
In-Reply-To: <CA+kOe08ypd93wW4GrcwhUrzGsqx_DnEYXWG6pKnDhs5bHUfb2w@mail.gmail.com>
References: <CA+kOe08ypd93wW4GrcwhUrzGsqx_DnEYXWG6pKnDhs5bHUfb2w@mail.gmail.com>
Message-ID: <54FA0AA7.5090208@redhat.com>

On 03/06/2015 07:35 PM, Martin Buchholz wrote:
> We all know that nanoTime has problems.  Many (most?) users of nanoTime,
> especially for benchmarking or concurrent algorithms, don't really care
> about the monotonicity guarantee and just want a "best-effort"
> "as-efficient-as-possible" version of nanoTime.  Sure, some algorithms in
> java.util.concurrent might need to change slightly to accommodate nanoTime
> going backwards, but we already do this to some extent.
> 
> http://shipilev.net/blog/2014/nanotrusting-nanotime/
> 
> Some users have already created such a private nanoTime.

Indeed.  See
http://developerblog.redhat.com/2014/06/24/ultra-lightweight-high-precision-logger-for-openjdk/
for an example of an interval timer with sub-nanosecond resolution and
about 30-nanosecond latency.

It'd be nice to be able to do something close to that in pure Java.

I'm not at all sure how Aleksey managed to get 30ns latency from
System.nanoTime().  Maybe the implementation has changed since I
tried it.

Andrew.


From martinrb at google.com  Fri Mar  6 20:46:39 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 6 Mar 2015 12:46:39 -0800
Subject: RFR: JDK-8074579 Use more efficient and readable way of checking
	PKZIP signatures
Message-ID: <CA+kOe08YtJNffw633_K54vqWYvv6+XwZTELfjc-aqFZ7GaDOfg@mail.gmail.com>

Hi jar/zip maintainers,

Here's an easy improvement.

http://cr.openjdk.java.net/~martin/webrevs/openjdk9/PKsig/
https://bugs.openjdk.java.net/browse/JDK-8074579


From martinrb at google.com  Fri Mar  6 20:49:08 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 6 Mar 2015 12:49:08 -0800
Subject: RFR: JDK-8074578 Document memory visibility effects of some Unsafe
	methods
Message-ID: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>

A wee code review fer ya:

https://bugs.openjdk.java.net/browse/JDK-8074578
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Unsafe-CAS-spec/


From martinrb at google.com  Fri Mar  6 20:51:36 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 6 Mar 2015 12:51:36 -0800
Subject: RFR: JDK-8074577 Modernize Unsafe internal javadoc
Message-ID: <CA+kOe0_fUvP9TynvhoqRP-1ofuS10MwSCPW2v_+F1in9WbMV_Q@mail.gmail.com>

A boring code review:

http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Unsafe-javadoc-style/
https://bugs.openjdk.java.net/browse/JDK-8074577


From xueming.shen at oracle.com  Fri Mar  6 21:37:36 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 06 Mar 2015 13:37:36 -0800
Subject: RFR: JDK-8074579 Use more efficient and readable way of checking
	PKZIP signatures
In-Reply-To: <CA+kOe08YtJNffw633_K54vqWYvv6+XwZTELfjc-aqFZ7GaDOfg@mail.gmail.com>
References: <CA+kOe08YtJNffw633_K54vqWYvv6+XwZTELfjc-aqFZ7GaDOfg@mail.gmail.com>
Message-ID: <54FA1E20.9000301@oracle.com>

On 03/06/2015 12:46 PM, Martin Buchholz wrote:
> Hi jar/zip maintainers,
>
> Here's an easy improvement.
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/PKsig/ <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/PKsig/>
> https://bugs.openjdk.java.net/browse/JDK-8074579
Looks fine, assume the statement of "byte-byte-byte comparing is more efficient" is true
In most cases, the signature comparing is just a "confirm", should not miss though.

-Sherman


From john.r.rose at oracle.com  Fri Mar  6 22:01:38 2015
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 6 Mar 2015 14:01:38 -0800
Subject: RFR: JDK-8074577 Modernize Unsafe internal javadoc
In-Reply-To: <CA+kOe0_fUvP9TynvhoqRP-1ofuS10MwSCPW2v_+F1in9WbMV_Q@mail.gmail.com>
References: <CA+kOe0_fUvP9TynvhoqRP-1ofuS10MwSCPW2v_+F1in9WbMV_Q@mail.gmail.com>
Message-ID: <DEC9D368-8F8B-49F3-BCE7-F56288B41381@oracle.com>

On Mar 6, 2015, at 12:51 PM, Martin Buchholz <martinrb at google.com> wrote:
> 
> A boring code review:
> 
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Unsafe-javadoc-style/
> https://bugs.openjdk.java.net/browse/JDK-8074577

(Yawn.)  Reviewed.  ? John
P.S. Thanks.



From martinrb at google.com  Fri Mar  6 22:13:07 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 6 Mar 2015 14:13:07 -0800
Subject: RFR: JDK-8074579 Use more efficient and readable way of checking
	PKZIP signatures
In-Reply-To: <54FA1E20.9000301@oracle.com>
References: <CA+kOe08YtJNffw633_K54vqWYvv6+XwZTELfjc-aqFZ7GaDOfg@mail.gmail.com>
	<54FA1E20.9000301@oracle.com>
Message-ID: <CA+kOe0-p7Qvjynw1G-QYqJO3a62AVMUJ53qNaWKm7_9JvNYDkA@mail.gmail.com>

On Fri, Mar 6, 2015 at 1:37 PM, Xueming Shen <xueming.shen at oracle.com>
wrote:

> On 03/06/2015 12:46 PM, Martin Buchholz wrote:
>
>> Hi jar/zip maintainers,
>>
>> Here's an easy improvement.
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/PKsig/ <
>> http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/PKsig/>
>> https://bugs.openjdk.java.net/browse/JDK-8074579
>>
> Looks fine, assume the statement of "byte-byte-byte comparing is more
> efficient" is true
> In most cases, the signature comparing is just a "confirm", should not
> miss though.
>

Reading the whole signature with one read might be more efficient if
unaligned 4-byte reads were available and being used (which they're not).
IIRC we experimented with that on x86 but found no improvement (perhaps
because many fields are 2-byte).  Anyways, it should still be a win because
the individual bytes aren't being assembled/shifted into an int, and the
byte comparisons can use "immediate" instructions.

(a reason to worry just occurred to me - my change introduces more
branches, which might be slower when lacking branch prediction... hmmmm ...)

Ahhh, of course, we can remove the branches by doing:

#define PKZIP_SIGNATURE_AT(p, b2, b3) \
  ((((p)[0] - 'P') | ((p)[1] - 'K') | ((p)[2] - b2) | ((p)[3] - b3)) == 0)

Well, now that looks like much less of a win, performance wise... but still
worth doing.
We haz new webrev.


From john.r.rose at oracle.com  Fri Mar  6 22:37:08 2015
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 6 Mar 2015 14:37:08 -0800
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54F9F701.90501@redhat.com>
References: <54EB6DD1.4090803@redhat.com>
	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>
	<54EDFBA3.6080609@redhat.com> <54F4BA63.5060506@redhat.com>
	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>
	<54F716BD.2030706@redhat.com>
	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>
	<54F7263A.7040902@redhat.com>
	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>
	<54F76937.2040203@redhat.com> <54F7AAD6.8040206@oracle.com>
	<54F817B9.8090500@redhat.com>
	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>
	<54F9F701.90501@redhat.com>
Message-ID: <174320CB-4DEB-4C84-AA5E-A895193369AA@oracle.com>

Wow, this looks excellent.  I send a summary to panama-dev, FYI:

http://mail.openjdk.java.net/pipermail/panama-dev/2015-March/000098.html

That note has some discussion of atomicity which you might want to incorporate when you write the javadoc.

? John

On Mar 6, 2015, at 10:50 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> I've tried to so everything I've been asked.  If this version passes
> muster with everyone I'll Javadoc all the public methods and fields
> and put it up for RFA next week.
> 
> I guess it's going to need a lot of testing and security analysis.
> 
> I added versions of all {put,get} methods with the boolean bigEndian
> argument.  This makes HeapByteBuffer much cleaner, and it does not
> need to know the machine endianness at all.  I hope that's OK.
> 
> Andrew.
> 
> 
> http://cr.openjdk.java.net/~aph/unaligned.hotspot.4/
> http://cr.openjdk.java.net/~aph/unaligned.jdk.4/



From joe.darcy at oracle.com  Fri Mar  6 22:52:17 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Fri, 06 Mar 2015 14:52:17 -0800
Subject: [9] RFR of 8074460: Always print seeds used in [Splittable]Random
	instances in java.math tests
In-Reply-To: <2FF58C0F-8209-48B3-96B1-20B04AD2E264@oracle.com>
References: <2FF58C0F-8209-48B3-96B1-20B04AD2E264@oracle.com>
Message-ID: <54FA2FA1.7000501@oracle.com>

Looks good; thanks,

-Joe

On 3/6/2015 12:03 PM, Brian Burkhalter wrote:
> Please review at your convenience:
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8074460
> Patch:	http://cr.openjdk.java.net/~bpb/8074460/webrev.00/
>
> Summary: Create a utility class which creates a pseudorandom number generator (PRNG) and retains the seed. Use this class in java.math tests which use a PRNG. Always print the seed value before the PRNG is used.
>
> Thanks,
>
> Brian



From aleksey.shipilev at oracle.com  Fri Mar  6 23:27:04 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Sat, 07 Mar 2015 02:27:04 +0300
Subject: Why not "weakNanoTime" for jdk9?
In-Reply-To: <54FA0AA7.5090208@redhat.com>
References: <CA+kOe08ypd93wW4GrcwhUrzGsqx_DnEYXWG6pKnDhs5bHUfb2w@mail.gmail.com>
	<54FA0AA7.5090208@redhat.com>
Message-ID: <54FA37C8.3090800@oracle.com>

Hi guys,

On 03/06/2015 11:14 PM, Andrew Haley wrote:
> On 03/06/2015 07:35 PM, Martin Buchholz wrote:
>> We all know that nanoTime has problems. 

It would really help if you list what problems weakNanoTime is supposed
to solve.

> Many (most?) users of nanoTime,
>> especially for benchmarking or concurrent algorithms, don't really care
>> about the monotonicity guarantee and just want a "best-effort"
>> "as-efficient-as-possible" version of nanoTime. 

I disagree on this premise. In the absence of proper API for CPU
affinity and CPU frequency control, we *do* need monotonicity and
linearity guarantees. Efficiency is a second-order concern here; you can
measure garbage with what you perceive as the nanosecond
precision/latency, but not exactly nanosecond accuracy. And you really
want accuracy, not precision.

Personally, I have doubts you need the single-digit-nanosecond
timestamping. The amount of in-flight ops modern CPUs do at those
timescales greatly blurs the meaning of measured time.


>> Some users have already created such a private nanoTime.
> 
> Indeed.  See
> http://developerblog.redhat.com/2014/06/24/ultra-lightweight-high-precision-logger-for-openjdk/
> for an example of an interval timer with sub-nanosecond resolution and
> about 30-nanosecond latency.

I'm curious what does it mean to have sub-nanosecond resolution with 30
nanosecond latency...


> I'm not at all sure how Aleksey managed to get 30ns latency from
> System.nanoTime().  Maybe the implementation has changed since I
> tried it.

As of now, C2 inlines the System.nanoTime() call into the call to
os::javaTimeNanos in OS-specific runtime code, which is then calling
clock_gettime in glibc, which is then turns to Linux's vDSO
__vdso_clock_gettime, and quickly returns.

Juggling the clock type in os::javaTimeNanos...

CLOCK_MONOTONIC (default now):
 Benchmark                         Mode  Cnt       Score   Error  Units
 TimersBench.granularity_nanotime  avgt    5      22.424 ? 0.609  ns/op
 TimersBench.latency_nanotime      avgt    5      21.569 ? 0.341  ns/op

CLOCK_MONOTONIC_RAW:
 Benchmark                         Mode  Cnt       Score    Error  Units
 TimersBench.granularity_nanotime  avgt    5     328.502 ?  7.631  ns/op
 TimersBench.latency_nanotime      avgt    5     332.489 ? 11.013  ns/op

CLOCK_MONOTONIC_COARSE:
 Benchmark                         Mode  Cnt        Score   Error  Units
 TimersBench.granularity_nanotime  avgt    5  3999733.222 ? 0.403  ns/op
 TimersBench.latency_nanotime      avgt    5        7.046 ? 0.328  ns/op

CLOCK_MONOTONIC_RAW is apparently unsupported by my kernel, and goes to
fallback code and real syscall. Maybe what Andrew was seeing before was
the absence of vDSO opts for CLOCK_MONOTONIC.


Thanks,
-Aleksey.




From snazy at snazy.de  Fri Mar  6 23:50:27 2015
From: snazy at snazy.de (Robert Stupp)
Date: Sat, 7 Mar 2015 00:50:27 +0100
Subject: Why not "weakNanoTime" for jdk9?
In-Reply-To: <54FA37C8.3090800@oracle.com>
References: <CA+kOe08ypd93wW4GrcwhUrzGsqx_DnEYXWG6pKnDhs5bHUfb2w@mail.gmail.com>
	<54FA0AA7.5090208@redhat.com> <54FA37C8.3090800@oracle.com>
Message-ID: <B5D09EEC-0C00-4502-8A11-E699B3F9DEE0@snazy.de>


> Am 07.03.2015 um 00:27 schrieb Aleksey Shipilev <aleksey.shipilev at oracle.com>:
> 
> I disagree on this premise. In the absence of proper API for CPU
> affinity and CPU frequency control, we *do* need monotonicity and
> linearity guarantees.

+1 on that.

The problem is that there is nothing like CPU affinity out of the box in Java. I.e. some option to declare a "critical section" that must not be interrupted or even moved to another core.
What I'd really like to see is some kind of @com.sun.CriticalSection on a method which guarantees that there will be no context switch during execution. I don't have timing stuff in mind - but concurrent data structures.
If there would also be a way to inquire the current core, that could really help with some concurrent data structures.
Additionally if there's a way to define CPU affinity per Java Thread or thread group even more fancy data structures could be possible (although there's already some project that already does this).

Have to admit, that I've no real clue how expensive it is to enter or leave such a "critical section".

?
Robert Stupp
@snazy



From ben_manes at yahoo.com  Fri Mar  6 23:57:08 2015
From: ben_manes at yahoo.com (Ben Manes)
Date: Fri, 6 Mar 2015 23:57:08 +0000 (UTC)
Subject: RFC: Adding ConcurrentModificationException for
	HashMap.computeIfAbsent(), and JDK-8071667
In-Reply-To: <54F9FB2D.6070908@oracle.com>
References: <54D1616F.50104@oracle.com> <54D18B9A.2020906@oracle.com>
	<84AD741C-CB02-4540-B41B-8F95490FF8E4@oracle.com>
	<54D2BB16.80508@oracle.com>
	<77020461-FD36-41FC-9996-9B476670C20D@oracle.com>
	<54D52E37.6040705@oracle.com> <54F9FB2D.6070908@oracle.com>
Message-ID: <542970762.4331723.1425686228327.JavaMail.yahoo@mail.yahoo.com>

I'd recommend that the exception thrown should be an IllegalStateException. This is documented in ConcurrentHashMap's computeIfAbsent as,

* @throws IllegalStateException if the computation detectably
*         attempts a recursive update to this map that would

*         otherwise never complete

The detection logic is in Doug's repository to be merged in for JDK-8062841.

It is also unexpected to have a concurrent data structure throw a ConcurrentModificationException, which is why I believe that IllegalStateException was chosen for ConcurrentHashMap.


From ben_manes at yahoo.com  Fri Mar  6 23:58:35 2015
From: ben_manes at yahoo.com (Ben Manes)
Date: Fri, 6 Mar 2015 23:58:35 +0000 (UTC)
Subject: RFC: Adding ConcurrentModificationException for
	HashMap.computeIfAbsent(), and JDK-8071667
In-Reply-To: <542970762.4331723.1425686228327.JavaMail.yahoo@mail.yahoo.com>
References: <54D1616F.50104@oracle.com> <54D18B9A.2020906@oracle.com>
	<84AD741C-CB02-4540-B41B-8F95490FF8E4@oracle.com>
	<54D2BB16.80508@oracle.com>
	<77020461-FD36-41FC-9996-9B476670C20D@oracle.com>
	<54D52E37.6040705@oracle.com> <54F9FB2D.6070908@oracle.com>
	<542970762.4331723.1425686228327.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <423016741.4343936.1425686315181.JavaMail.yahoo@mail.yahoo.com>

Nevermind, sorry somehow I missed the previous emails in the thread.



On Friday, March 6, 2015 3:57 PM, Ben Manes <ben_manes at yahoo.com> wrote:
I'd recommend that the exception thrown should be an IllegalStateException. This is documented in ConcurrentHashMap's computeIfAbsent as,

* @throws IllegalStateException if the computation detectably
*         attempts a recursive update to this map that would

*         otherwise never complete

The detection logic is in Doug's repository to be merged in for JDK-8062841.

It is also unexpected to have a concurrent data structure throw a ConcurrentModificationException, which is why I believe that IllegalStateException was chosen for ConcurrentHashMap.


From sandhya.viswanathan at intel.com  Sat Mar  7 01:19:31 2015
From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya)
Date: Sat, 7 Mar 2015 01:19:31 +0000
Subject: Compression acceleration for Java
Message-ID: <02FCFB8477C4EF43A2AD8E0C60F3DA2B6331E0A4@FMSMSX112.amr.corp.intel.com>

Hi All,

This is a request for support in JVM to use system zlib or alternative implementations of zlib.

Compression is heavily used in Java based big data, genomics and middleware applications. There are many products in market today which help in compression performance either through software or hardware acceleration. Intel has faster compression libraries as part of IPP and also there are hardware compression accelerator products from Intel. Both of these products are available in the market today and support the zlib interface as an API. Support in the JVM to use system zlib on a JVM command line option would make these acceleration capabilities available to Linux java users through java.util.zip.
The JVM could support this on an option UseSystemZlib which can be set to false by default. When the option is set to true on command line by the user, the load_zip_library() function in classLoader.cpp can load libszip.so instead of libzip.so. Also the JVM can set the java.util.zip.UseSystemZlib property accordingly.

The JDK would need to include two libraries for zip in jre/lib/amd64: libzip.so and libszip.so. The libzip.so will be built as before with statically linking system zlib with it and libszip.so will be built without statically linking system zlib with it. Also the java.lang.System.initializeSystemClass will load libzip.so or libszip.so based on the java.util.zip.UseSystemZlib property.

The users can then use system zlib by including the -XX:+UseSystemZlib option on the command line and compression accelerators by setting the LD_LIBRARY_PATH and LD_PRELOAD appropriately.

I am very interested to know your thoughts on this feature support.

Thanks,
Sandhya



From davidcholmes at aapt.net.au  Sat Mar  7 01:44:24 2015
From: davidcholmes at aapt.net.au (David Holmes)
Date: Sat, 7 Mar 2015 11:44:24 +1000
Subject: [concurrency-interest] Why not "weakNanoTime" for jdk9?
In-Reply-To: <0FD072A166C6DC4C851F6115F37DDD279AEED75A@sm-ex-01-vm.guidewire.com>
Message-ID: <NFBBKALFDCPFIDBNKAPCAECKKOAA.davidcholmes@aapt.net.au>

The VM uses whatever high-resolution "clock" the OS provides it. If
experience shows that clock is not monotonic when it is meant to be then we
added internal guards to ensure time doesn't go backwards (which means
sometimes it stands still which has its own issues). As time goes by and
things like frequency-stable, cross-core synchronized TSC becomes available,
the need for the extra monotonicity guard is reduced, and for those
situations when you know what your platform provides we could have a VM flag
to say "trust the OS timer". I know we have an open bug for that on Solaris.
A new API that simply returns whatever the OS returns may be useful for some
people. However I would not support trying to implement something direct to
the hardware in the VM.

Just be aware that the implementation of these timers varies greatly
depending on the hardware and the OS. And once you throw in virtualization
many more problems arise.

Also we'll start using CLOCK_MONOTONIC_RAW on linux at some point. (There's
a bug open for that too.)

David

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Justin
> Sampson
> Sent: Saturday, 7 March 2015 10:42 AM
> To: Aleksey Shipilev; Andrew Haley; Martin Buchholz;
> concurrency-interest; core-libs-dev
> Subject: Re: [concurrency-interest] Why not "weakNanoTime" for jdk9?
>
>
> Aleksey Shipilev wrote:
>
> > It would really help if you list what problems weakNanoTime is
> > supposed to solve.
>
> I was talking to Martin about this idea recently so I'll take a shot
> at describing why it's appealing to me (with the usual disclaimer
> that I know I'm much less of an expert than most other folks here).
>
> The main case I'm interested in is handling timeout calculations in
> concurrent operations. The usual case should be that the operation
> succeeds without timing out, and if it _does_ time out it's often
> after waiting several seconds or minutes, in which case being off
> by, say, a few microseconds is not a big deal.
>
> Given those assumptions, we really want the usual case (success) to
> be as fast as possible, and especially not to impose any additional
> synchronization or volatile accesses. Since strict monotonicity
> requires checking some kind of centrally synchronized clock state,
> it fails that use case.
>
> Furthermore, in this particular use case, it's trivial to have the
> appearance of monotonicity _within_ a particular operation: Just
> keep a local variable with the last time seen, and only update it if
> the next time seen is greater than the last time seen. No extra
> synchronization is required.
>
> The semantics I'm imagining would be for a very fast timer that is
> _usually_ monotonic, as long as the current thread stays on one
> processor, with occasional blips when switching between processors.
> We would still want those blips to be as small as practically
> achievable, so I guess there would still have to be some occasional
> synchronization to keep the fast timer within some tolerance of the
> central system clock.
>
> The way I see it, good concurrency semantics are about acknowledging
> the reality of the hardware, and a strictly monotonic clock is
> simply not the reality of the hardware when there's more than one
> processor involved.
>
> Actually, come to think of it, given an underlying non-monotonic
> timer, the weakNanoTime method could easily provide monotonicity on
> a per-thread basis without any synchronization overhead. That would
> mean most concurrent code wouldn't even have to change to become
> tolerant of non-monotonicity. It would just have to be made really
> clear to users that different threads might see timer values out of
> order relative to each other, though still within some best-effort
> tolerance.
>
> Cheers,
> Justin
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



From martinrb at google.com  Sat Mar  7 05:50:07 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 6 Mar 2015 21:50:07 -0800
Subject: RFR: JDK-8074579 Use more efficient and readable way of checking
	PKZIP signatures
In-Reply-To: <CA+kOe0-p7Qvjynw1G-QYqJO3a62AVMUJ53qNaWKm7_9JvNYDkA@mail.gmail.com>
References: <CA+kOe08YtJNffw633_K54vqWYvv6+XwZTELfjc-aqFZ7GaDOfg@mail.gmail.com>
	<54FA1E20.9000301@oracle.com>
	<CA+kOe0-p7Qvjynw1G-QYqJO3a62AVMUJ53qNaWKm7_9JvNYDkA@mail.gmail.com>
Message-ID: <CA+kOe0_oZ0cagWuaLAGCp=Z5DV6fj2bLJBgO9f306yCGxoPaTQ@mail.gmail.com>

Err...

#define PKZIP_SIGNATURE_AT(p, b2, b3) \
  (((p)[0] == 'P') & ((p)[1] == 'K') & ((p)[2] == b2) & ((p)[3] == b3))


From Alan.Bateman at oracle.com  Sat Mar  7 09:32:17 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 07 Mar 2015 09:32:17 +0000
Subject: Compression acceleration for Java
In-Reply-To: <02FCFB8477C4EF43A2AD8E0C60F3DA2B6331E0A4@FMSMSX112.amr.corp.intel.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B6331E0A4@FMSMSX112.amr.corp.intel.com>
Message-ID: <54FAC5A1.3020409@oracle.com>

On 07/03/2015 01:19, Viswanathan, Sandhya wrote:
> Hi All,
>
> This is a request for support in JVM to use system zlib or alternative implementations of zlib.
>
> Compression is heavily used in Java based big data, genomics and middleware applications. There are many products in market today which help in compression performance either through software or hardware acceleration. Intel has faster compression libraries as part of IPP and also there are hardware compression accelerator products from Intel. Both of these products are available in the market today and support the zlib interface as an API. Support in the JVM to use system zlib on a JVM command line option would make these acceleration capabilities available to Linux java users through java.util.zip.
> The JVM could support this on an option UseSystemZlib which can be set to false by default. When the option is set to true on command line by the user, the load_zip_library() function in classLoader.cpp can load libszip.so instead of libzip.so. Also the JVM can set the java.util.zip.UseSystemZlib property accordingly.
>
> The JDK would need to include two libraries for zip in jre/lib/amd64: libzip.so and libszip.so. The libzip.so will be built as before with statically linking system zlib with it and libszip.so will be built without statically linking system zlib with it. Also the java.lang.System.initializeSystemClass will load libzip.so or libszip.so based on the java.util.zip.UseSystemZlib property.
>
> The users can then use system zlib by including the -XX:+UseSystemZlib option on the command line and compression accelerators by setting the LD_LIBRARY_PATH and LD_PRELOAD appropriately.
>
> I am very interested to know your thoughts on this feature support.
>
You may know this already but there is a configure option to use the 
system zlib (configure --with-zlib=system). I will assume that if you 
build with this option and run with LD_* set to the IPP libraries then 
it should work.

That said, I think your mail is timely as we do need to re-examine how 
zlib is used. It would be nice if the build used the system rather than 
the bundled zlib when building on Linux and Solaris (OS X already uses 
the system zlib). Ditto for Oracle builds. That would avoid needing to 
split libzip and avoid needing to introduce a runtime option to select 
between the bundled and system zlib.

Another long standing suggestion is to just move to a pure java 
implementation, something that Sherman Shen prototyped some time ago and 
mentioned in a recent thread here on memory mapping the zip central 
directory. If we were to go down that route then use of zlib couldn't be 
dropped completely, I think it would still be needed for HotSpot to 
support -Xbootclasspath/a and the JVM TI agent equivalent (with the JEP 
220 work then rt.jar/friends go away so HotSpot only rarely needs to 
call into libzip now). Moving to a pure java implementation might nobble 
your proposal of course but it might open other opportunities for the 
compiler.

-Alan


From Roger.Riggs at Oracle.com  Sat Mar  7 16:37:35 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Sat, 07 Mar 2015 11:37:35 -0500
Subject: RFR: JDK-8074406 DateTimeFormatter.appendZoneOrOffsetId() fails
	to resolve a ZoneOffset for OffsetDateTime
In-Reply-To: <CACzrW9DADKE2+-BZ92DvG5Mw+fXUw=G-2fuW1Bgwhd1T25JS5Q@mail.gmail.com>
References: <54F76185.70909@oracle.com>
	<CACzrW9DADKE2+-BZ92DvG5Mw+fXUw=G-2fuW1Bgwhd1T25JS5Q@mail.gmail.com>
Message-ID: <54FB294F.6020706@Oracle.com>

Hi Sherman,

Sorry for the delay, the change and test updates look fine.
Thanks for the fix.

Reviewed.
Roger


On 3/5/2015 5:53 PM, Stephen Colebourne wrote:
> I think the fix looks good. I haven't had time to look through the
> tests in detail (as there are lots)
> Stephen
>
> On 4 March 2015 at 19:48, Xueming Shen <xueming.shen at oracle.com> wrote:
>> Stephen and Roger,
>>
>> This is the DTF.appendZoneOrOffsetId() issues we discussed last year.
>> Somehow the
>> ball was dropped somewhere :-)
>>
>> Here is the proposed change we discussed. The only difference is I leave the
>> ZoneOffset
>> to throw the DateTimeException, instead of inside the Parsed.query()
>> directly.
>>
>> I also updated the TCKZoneIdPrinterParser to (1) add the
>> appendZoneOrOffsetId() (it appears
>> we don't have any corresponding test cases for it) and (2) return a
>> ZoneOffset for "offset"
>> if there is indeed a ZoneOffset inside the parsed.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8074406
>> webrev: http://cr.openjdk.java.net/~sherman/8074406/webrev
>>
>> Thanks!
>> -Sherman



From forax at univ-mlv.fr  Sat Mar  7 17:57:31 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 07 Mar 2015 18:57:31 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54F9F701.90501@redhat.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>
	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>	<54F76937.2040203@redhat.com>
	<54F7AAD6.8040206@oracle.com>	<54F817B9.8090500@redhat.com>	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>
	<54F9F701.90501@redhat.com>
Message-ID: <54FB3C0B.6010800@univ-mlv.fr>

Hi Andrew,
I've just read carefully the JDK part and I'm mostly ok with it.

in Unsafe, all private methods should be static and
I think that isBigEndian() and unalignedAccess() native methods should 
be called once in a static block
and their results cached/stored as static final fields. In that case the 
public version of isBigEndian() and unalignedAccess()
should just return the value of the static final fields.
Also I'm wondering if this method are really unsafe, exporting the 
endianess or the support of unaligned access
doesn't seem unsafe too me; maybe there is a security issue ?; if not, 
the static final fields should be public and the public methods removed.

cheers,
R?mi

On 03/06/2015 07:50 PM, Andrew Haley wrote:
> I've tried to so everything I've been asked.  If this version passes
> muster with everyone I'll Javadoc all the public methods and fields
> and put it up for RFA next week.
>
> I guess it's going to need a lot of testing and security analysis.
>
> I added versions of all {put,get} methods with the boolean bigEndian
> argument.  This makes HeapByteBuffer much cleaner, and it does not
> need to know the machine endianness at all.  I hope that's OK.
>
> Andrew.
>
>
> http://cr.openjdk.java.net/~aph/unaligned.hotspot.4/
> http://cr.openjdk.java.net/~aph/unaligned.jdk.4/



From aph at redhat.com  Sat Mar  7 18:48:40 2015
From: aph at redhat.com (Andrew Haley)
Date: Sat, 07 Mar 2015 18:48:40 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FB3C0B.6010800@univ-mlv.fr>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>
	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>	<54F76937.2040203@redhat.com>
	<54F7AAD6.8040206@oracle.com>	<54F817B9.8090500@redhat.com>	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>
	<54F9F701.90501@redhat.com> <54FB3C0B.6010800@univ-mlv.fr>
Message-ID: <54FB4808.3080802@redhat.com>

On 03/07/2015 05:57 PM, Remi Forax wrote:
> Hi Andrew,
> I've just read carefully the JDK part and I'm mostly ok with it.
> 
> in Unsafe, all private methods should be static

You're going to have to explain that.  Firstly, why?  There's no real
performance advantage, and secondly, how is a static method supposed
to invoke the virtual methods in Unsafe?  I suppose it could use
theUnsafe.blah() but that would be worse than a simple virtual call.

> and I think that isBigEndian() and unalignedAccess() native methods
> should be called once in a static block and their results
> cached/stored as static final fields.

That's not unreasonable.

> In that case the public version of isBigEndian() and
> unalignedAccess() should just return the value of the static final
> fields.

OK.

> Also I'm wondering if this method are really unsafe, exporting the
> endianess or the support of unaligned access doesn't seem unsafe too
> me;

It's not, but the we have a public API to get the endianness of this
machine in java.nio,ByteOrder.nativeOrder() and I really don't want to
create another one.  With regard to unalignedAccess() I don't really
mind making it public static but it's of marginal use in that form
IMO.  Maybe some user code could make use of this information, in
which case it shouldn't be in Unsafe at all.

> maybe there is a security issue ?; if not, the static final
> fields should be public and the public methods removed.

Sorry, I don't want to do that.  Accessor methods for such things
should stay as methods, not public fields.

Andrew.


From forax at univ-mlv.fr  Sat Mar  7 19:24:34 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 07 Mar 2015 20:24:34 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FB4808.3080802@redhat.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>
	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>	<54F76937.2040203@redhat.com>
	<54F7AAD6.8040206@oracle.com>	<54F817B9.8090500@redhat.com>	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>
	<54F9F701.90501@redhat.com> <54FB3C0B.6010800@univ-mlv.fr>
	<54FB4808.3080802@redhat.com>
Message-ID: <54FB5072.6050107@univ-mlv.fr>


On 03/07/2015 07:48 PM, Andrew Haley wrote:
> On 03/07/2015 05:57 PM, Remi Forax wrote:
>> Hi Andrew,
>> I've just read carefully the JDK part and I'm mostly ok with it.
>>
>> in Unsafe, all private methods should be static
> You're going to have to explain that.  Firstly, why?  There's no real
> performance advantage, and secondly, how is a static method supposed
> to invoke the virtual methods in Unsafe?  I suppose it could use
> theUnsafe.blah() but that would be worse than a simple virtual call.

I mean all private methods that doesn't starts with "put*",
convEndian, toUnsignedInt/toUnsignedLong, pick, make*, pickPos.


>
>> and I think that isBigEndian() and unalignedAccess() native methods
>> should be called once in a static block and their results
>> cached/stored as static final fields.
> That's not unreasonable.
>
>> In that case the public version of isBigEndian() and
>> unalignedAccess() should just return the value of the static final
>> fields.
> OK.
>
>> Also I'm wondering if this method are really unsafe, exporting the
>> endianess or the support of unaligned access doesn't seem unsafe too
>> me;
> It's not, but the we have a public API to get the endianness of this
> machine in java.nio,ByteOrder.nativeOrder() and I really don't want to
> create another one.  With regard to unalignedAccess() I don't really
> mind making it public static but it's of marginal use in that form
> IMO.  Maybe some user code could make use of this information, in
> which case it shouldn't be in Unsafe at all.
>
>> maybe there is a security issue ?; if not, the static final
>> fields should be public and the public methods removed.
> Sorry, I don't want to do that.  Accessor methods for such things
> should stay as methods, not public fields.

OK.

>
> Andrew.

R?mi



From peter.levart at gmail.com  Sat Mar  7 21:23:06 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 07 Mar 2015 22:23:06 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54F9F701.90501@redhat.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>
	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>	<54F76937.2040203@redhat.com>
	<54F7AAD6.8040206@oracle.com>	<54F817B9.8090500@redhat.com>	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>
	<54F9F701.90501@redhat.com>
Message-ID: <54FB6C3A.4070508@gmail.com>



On 03/06/2015 07:50 PM, Andrew Haley wrote:
> I've tried to so everything I've been asked.  If this version passes
> muster with everyone I'll Javadoc all the public methods and fields
> and put it up for RFA next week.
>
> I guess it's going to need a lot of testing and security analysis.
>
> I added versions of all {put,get} methods with the boolean bigEndian
> argument.  This makes HeapByteBuffer much cleaner, and it does not
> need to know the machine endianness at all.  I hope that's OK.
>
> Andrew.
>
>
> http://cr.openjdk.java.net/~aph/unaligned.hotspot.4/
> http://cr.openjdk.java.net/~aph/unaligned.jdk.4/

Hi Andrew,

I see you're not using Unsafe.unalignedAccess() method in Unsafe code at 
all. So the approach to use this information and decide whether to use 
Unsafe.getXXX() or Unsafe.getXXXUnaligned() is left to the user of 
Unsafe API. That's OK if you think this approach is a better division of 
concerns (Unsafe being low-level), but in Heap-X-Buffer you are only 
using Unsafe.get|putXXXUnaligned() and don't consider using get|putXXX 
directly when unalignedAccess() == true.

In java.nio.Bits, the Unsafe.unalignedAccess() is used to lazily 
initialize the Bits.unaligned static field. This lazy initialization is 
unnecessary now and 'unaligned' field can be made final.

Regards, Peter



From aph at redhat.com  Sun Mar  8 11:13:41 2015
From: aph at redhat.com (Andrew Haley)
Date: Sun, 08 Mar 2015 11:13:41 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FB6C3A.4070508@gmail.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>
	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>	<54F76937.2040203@redhat.com>
	<54F7AAD6.8040206@oracle.com>	<54F817B9.8090500@redhat.com>	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>
	<54F9F701.90501@redhat.com> <54FB6C3A.4070508@gmail.com>
Message-ID: <54FC2EE5.2040601@redhat.com>

On 03/07/2015 09:23 PM, Peter Levart wrote:

> I see you're not using Unsafe.unalignedAccess() method in Unsafe
> code at all. So the approach to use this information and decide
> whether to use Unsafe.getXXX() or Unsafe.getXXXUnaligned() is left
> to the user of Unsafe API.

I don't think that there is any reason to keep library code from being
able to discover whether this machine can do unaligned loads.
However, there is now no reason to use Unsafe.getXXX() on an unaligned
word.  unalignedAccess() is for tuning, not correctness.

> That's OK if you think this approach is a better division of
> concerns (Unsafe being low-level), but in Heap-X-Buffer you are only
> using Unsafe.get|putXXXUnaligned() and don't consider using
> get|putXXX directly when unalignedAccess() == true.

Right, because there's no point in doing so when unalignedAccess() ==
true because the exact same code will be generated.  In my Utopian
world nothing except Unsafe would have to deal with issues such as
this.  However, I think that people writing library code (e.g. array
comparison intrinsics) might still need to know.

The problem is that in reality unalignedAccess() isn't as simple as a
binary yes/no.  For example, on some machines unaligned accessess
might be significantly slower than aligned ones but still work; so,
unalignedAccess() will (?) return true even though it might not be
ideal.  Library code is then to have to use some sort of heuristic to
decide whether to use e.g. getLongUnaligned() or getInt() (when
comparing e.g. int arrays).

I wonder if on all machines it's worth using getLongUnaligned() for
int array comparisons.  I don't know.  I hope it is, but I suspect it
isn't.

> In java.nio.Bits, the Unsafe.unalignedAccess() is used to lazily
> initialize the Bits.unaligned static field. This lazy initialization
> is unnecessary now and 'unaligned' field can be made final.

I agree, but there are quite a few other places which could also be
improved by the use of this API, and every patch must stop somewhere.
This one is the first.

Andrew.



From john.r.rose at oracle.com  Sun Mar  8 21:24:03 2015
From: john.r.rose at oracle.com (John Rose)
Date: Sun, 8 Mar 2015 14:24:03 -0700
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FC2EE5.2040601@redhat.com>
References: <54EB6DD1.4090803@redhat.com>
	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>
	<54EDFBA3.6080609@redhat.com> <54F4BA63.5060506@redhat.com>
	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>
	<54F716BD.2030706@redhat.com>
	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>
	<54F7263A.7040902@redhat.com>
	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>
	<54F76937.2040203@redhat.com> <54F7AAD6.8040206@oracle.com>
	<54F817B9.8090500@redhat.com>
	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>
	<54F9F701.90501@redhat.com> <54FB6C3A.4070508@gmail.com>
	<54FC2EE5.2040601@redhat.com>
Message-ID: <6CA8BC2D-82EF-440B-8485-F5598BCA386C@oracle.com>

On Mar 8, 2015, at 4:13 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 03/07/2015 09:23 PM, Peter Levart wrote:
> 
>> I see you're not using Unsafe.unalignedAccess() method in Unsafe
>> code at all. So the approach to use this information and decide
>> whether to use Unsafe.getXXX() or Unsafe.getXXXUnaligned() is left
>> to the user of Unsafe API.
> 
> I don't think that there is any reason to keep library code from being
> able to discover whether this machine can do unaligned loads.
> However, there is now no reason to use Unsafe.getXXX() on an unaligned
> word.  unalignedAccess() is for tuning, not correctness.

+1

>> That's OK if you think this approach is a better division of
>> concerns (Unsafe being low-level), but in Heap-X-Buffer you are only
>> using Unsafe.get|putXXXUnaligned() and don't consider using
>> get|putXXX directly when unalignedAccess() == true.
> 
> Right, because there's no point in doing so when unalignedAccess() ==
> true because the exact same code will be generated.  In my Utopian
> world nothing except Unsafe would have to deal with issues such as
> this.  However, I think that people writing library code (e.g. array
> comparison intrinsics) might still need to know.

+1  Unsafe exposes some low-level information like this, rather than hiding it.

(For the next level of detail, see https://bugs.openjdk.java.net/browse/JDK-8014710.)

> The problem is that in reality unalignedAccess() isn't as simple as a
> binary yes/no.  For example, on some machines unaligned accessess
> might be significantly slower than aligned ones but still work; so,
> unalignedAccess() will (?) return true even though it might not be
> ideal.  Library code is then to have to use some sort of heuristic to
> decide whether to use e.g. getLongUnaligned() or getInt() (when
> comparing e.g. int arrays).

Hardware and OS designers play trapping games sometimes to handle misaligned.
That's not on the table now.  The present design keeps options open.

> I wonder if on all machines it's worth using getLongUnaligned() for
> int array comparisons.  I don't know.  I hope it is, but I suspect it
> isn't.

Best performance will come from vectorization, and we have a better chance
to do this if we have portably-named intrinsics for the unaligned accesses,
instead of random looking byte-peek-poke.

That's the main benefit from this patch, I think:  Having portable names
for the unaligned accesses.  That's the reason I'm happy to see it.
It will require additional work, in the JIT, to optimize fully.

> 
>> In java.nio.Bits, the Unsafe.unalignedAccess() is used to lazily
>> initialize the Bits.unaligned static field. This lazy initialization
>> is unnecessary now and 'unaligned' field can be made final.
> 
> I agree, but there are quite a few other places which could also be
> improved by the use of this API, and every patch must stop somewhere.
> This one is the first.

We need to capture the information in your head about those quite a few
other places, and attach it to a followup RFE.  If you want you can
dump some notes to email.  (Preferably in a message separate from
this thread).  The compiler vectorization requirement is either a third
bug or else part of fulfilling the efficient array comparison intrinsic RFE.

Thanks for doing this work.

? John

From john.r.rose at oracle.com  Sun Mar  8 21:28:04 2015
From: john.r.rose at oracle.com (John Rose)
Date: Sun, 8 Mar 2015 14:28:04 -0700
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FB5072.6050107@univ-mlv.fr>
References: <54EB6DD1.4090803@redhat.com>
	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>
	<54EDFBA3.6080609@redhat.com> <54F4BA63.5060506@redhat.com>
	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>
	<54F716BD.2030706@redhat.com>
	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>
	<54F7263A.7040902@redhat.com>
	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>
	<54F76937.2040203@redhat.com> <54F7AAD6.8040206@oracle.com>
	<54F817B9.8090500@redhat.com>
	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>
	<54F9F701.90501@redhat.com> <54FB3C0B.6010800@univ-mlv.fr>
	<54FB4808.3080802@redhat.com> <54FB5072.6050107@univ-mlv.fr>
Message-ID: <F507BDC7-2573-4E01-B15C-60F982ABA286@oracle.com>

On Mar 7, 2015, at 11:24 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> 
> On 03/07/2015 07:48 PM, Andrew Haley wrote:
>> On 03/07/2015 05:57 PM, Remi Forax wrote:
>>> Hi Andrew,
>>> I've just read carefully the JDK part and I'm mostly ok with it.
>>> 
>>> in Unsafe, all private methods should be static
>> You're going to have to explain that.  Firstly, why?  There's no real
>> performance advantage, and secondly, how is a static method supposed
>> to invoke the virtual methods in Unsafe?  I suppose it could use
>> theUnsafe.blah() but that would be worse than a simple virtual call.
> 
> I mean all private methods that doesn't starts with "put*",
> convEndian, toUnsignedInt/toUnsignedLong, pick, make*, pickPos.

It's a small point but I agree with this.  Leaving out "static" makes it harder to
understand the roles of the relevant methods.  Scrutable code is better code.

It almost never matters, but there is also a slight effect on the code pipeline:
passing 'this' as an argument slightly increases the complexity of the methods.

? John

From peter.levart at gmail.com  Sun Mar  8 23:04:09 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 09 Mar 2015 00:04:09 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FC2EE5.2040601@redhat.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>
	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>	<54F76937.2040203@redhat.com>
	<54F7AAD6.8040206@oracle.com>	<54F817B9.8090500@redhat.com>	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>
	<54F9F701.90501@redhat.com> <54FB6C3A.4070508@gmail.com>
	<54FC2EE5.2040601@redhat.com>
Message-ID: <54FCD569.6040806@gmail.com>



On 03/08/2015 12:13 PM, Andrew Haley wrote:
>> >That's OK if you think this approach is a better division of
>> >concerns (Unsafe being low-level), but in Heap-X-Buffer you are only
>> >using Unsafe.get|putXXXUnaligned() and don't consider using
>> >get|putXXX directly when unalignedAccess() == true.
> Right, because there's no point in doing so when unalignedAccess() ==
> true because the exact same code will be generated.  In my Utopian
> world nothing except Unsafe would have to deal with issues such as
> this.  However, I think that people writing library code (e.g. array
> comparison intrinsics) might still need to know.

Ah, sorry. I haven't realized that the same code will be generated by 
compiler intrinsics. So the Java part is just for interpreter and 
platforms not supporting unaligned access and when UseUnalignedAccesses 
is explicitly disabled?

Peter



From peter.levart at gmail.com  Sun Mar  8 23:11:08 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 09 Mar 2015 00:11:08 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FCD569.6040806@gmail.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>
	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>	<54F76937.2040203@redhat.com>
	<54F7AAD6.8040206@oracle.com>	<54F817B9.8090500@redhat.com>	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>
	<54F9F701.90501@redhat.com> <54FB6C3A.4070508@gmail.com>
	<54FC2EE5.2040601@redhat.com> <54FCD569.6040806@gmail.com>
Message-ID: <54FCD70C.1030209@gmail.com>



On 03/09/2015 12:04 AM, Peter Levart wrote:
>
>
> On 03/08/2015 12:13 PM, Andrew Haley wrote:
>>> >That's OK if you think this approach is a better division of
>>> >concerns (Unsafe being low-level), but in Heap-X-Buffer you are only
>>> >using Unsafe.get|putXXXUnaligned() and don't consider using
>>> >get|putXXX directly when unalignedAccess() == true.
>> Right, because there's no point in doing so when unalignedAccess() ==
>> true because the exact same code will be generated.  In my Utopian
>> world nothing except Unsafe would have to deal with issues such as
>> this.  However, I think that people writing library code (e.g. array
>> comparison intrinsics) might still need to know.
>
> Ah, sorry. I haven't realized that the same code will be generated by 
> compiler intrinsics. So the Java part is just for interpreter and 
> platforms not supporting unaligned access and when 
> UseUnalignedAccesses is explicitly disabled?

If the last statement is true, then perhaps instead of 
UseUnalignedAccesses, the flag could be called EmulateUnalignedAccesses 
(with the opposite meaning), so that you can always turn it ON (for 
testing), but can't turn it OFF on platforms that don't support 
unaligned access.

Peter



From david.holmes at oracle.com  Sun Mar  8 23:11:54 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 09 Mar 2015 09:11:54 +1000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54F9F701.90501@redhat.com>
References: <54EB6DD1.4090803@redhat.com>
	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>
	<54EDFBA3.6080609@redhat.com> <54F4BA63.5060506@redhat.com>
	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>
	<54F716BD.2030706@redhat.com>
	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>
	<54F7263A.7040902@redhat.com>
	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>
	<54F76937.2040203@redhat.com> <54F7AAD6.8040206@oracle.com>
	<54F817B9.8090500@redhat.com>
	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>
	<54F9F701.90501@redhat.com>
Message-ID: <54FCD73A.3040808@oracle.com>

On 7/03/2015 4:50 AM, Andrew Haley wrote:
> I've tried to so everything I've been asked.  If this version passes
> muster with everyone I'll Javadoc all the public methods and fields
> and put it up for RFA next week.
>
> I guess it's going to need a lot of testing and security analysis.
>
> I added versions of all {put,get} methods with the boolean bigEndian
> argument.  This makes HeapByteBuffer much cleaner, and it does not
> need to know the machine endianness at all.  I hope that's OK.
>
> Andrew.
>
>
> http://cr.openjdk.java.net/~aph/unaligned.hotspot.4/
> http://cr.openjdk.java.net/~aph/unaligned.jdk.4/

I think it is cleaner and more efficient if Unsafe maintains BE as an 
instance variable (initialized at construction) and that isBigEndian() 
simply returns that. The native check should only need to be called once 
in the lifetime of the VM.

David



From forax at univ-mlv.fr  Sun Mar  8 23:21:53 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 09 Mar 2015 00:21:53 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FCD73A.3040808@oracle.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>
	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>	<54F76937.2040203@redhat.com>
	<54F7AAD6.8040206@oracle.com>	<54F817B9.8090500@redhat.com>	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>	<54F9F701.90501@redhat.com>
	<54FCD73A.3040808@oracle.com>
Message-ID: <54FCD991.4070907@univ-mlv.fr>


On 03/09/2015 12:11 AM, David Holmes wrote:
> On 7/03/2015 4:50 AM, Andrew Haley wrote:
>> I've tried to so everything I've been asked.  If this version passes
>> muster with everyone I'll Javadoc all the public methods and fields
>> and put it up for RFA next week.
>>
>> I guess it's going to need a lot of testing and security analysis.
>>
>> I added versions of all {put,get} methods with the boolean bigEndian
>> argument.  This makes HeapByteBuffer much cleaner, and it does not
>> need to know the machine endianness at all.  I hope that's OK.
>>
>> Andrew.
>>
>>
>> http://cr.openjdk.java.net/~aph/unaligned.hotspot.4/
>> http://cr.openjdk.java.net/~aph/unaligned.jdk.4/
>
> I think it is cleaner and more efficient if Unsafe maintains BE as an 
> instance variable (initialized at construction) and that isBigEndian() 
> simply returns that. The native check should only need to be called 
> once in the lifetime of the VM.
>
> David
>

BE doesn't need to be an instance, method of Unsafe are instance methods 
just to enforce security,
you can not call them if you don"t have an instance of Unsafe (and 
getUnsafe() does the security check).

BE is private so it doesn't have to be an instance field it can be 
static field.

And I agree with you that the native isBigEndian() should be called once 
in the lifetime of the VM.

so the idea is to write:

public boolean isBigEndian() {
   return BE;
}
private static final boolean BE = isBigEndian0();

private static native boolean isBigEndian0();

cheers,
R?mi



From david.holmes at oracle.com  Sun Mar  8 23:32:41 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 09 Mar 2015 09:32:41 +1000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FCD991.4070907@univ-mlv.fr>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>	<54F76937.2040203@redhat.com>	<54F7AAD6.8040206@oracle.com>	<54F817B9.8090500@redhat.com>	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>	<54F9F701.90501@redhat.com>	<54FCD73A.3040808@oracle.com>
	<54FCD991.4070907@univ-mlv.fr>
Message-ID: <54FCDC19.1090804@oracle.com>

On 9/03/2015 9:21 AM, Remi Forax wrote:
>
> On 03/09/2015 12:11 AM, David Holmes wrote:
>> On 7/03/2015 4:50 AM, Andrew Haley wrote:
>>> I've tried to so everything I've been asked.  If this version passes
>>> muster with everyone I'll Javadoc all the public methods and fields
>>> and put it up for RFA next week.
>>>
>>> I guess it's going to need a lot of testing and security analysis.
>>>
>>> I added versions of all {put,get} methods with the boolean bigEndian
>>> argument.  This makes HeapByteBuffer much cleaner, and it does not
>>> need to know the machine endianness at all.  I hope that's OK.
>>>
>>> Andrew.
>>>
>>>
>>> http://cr.openjdk.java.net/~aph/unaligned.hotspot.4/
>>> http://cr.openjdk.java.net/~aph/unaligned.jdk.4/
>>
>> I think it is cleaner and more efficient if Unsafe maintains BE as an
>> instance variable (initialized at construction) and that isBigEndian()
>> simply returns that. The native check should only need to be called
>> once in the lifetime of the VM.
>>
>> David
>>
>
> BE doesn't need to be an instance, method of Unsafe are instance methods
> just to enforce security,
> you can not call them if you don"t have an instance of Unsafe (and
> getUnsafe() does the security check).
>
> BE is private so it doesn't have to be an instance field it can be
> static field.

Yes it could but why should it be? You have a singleton instance with 
all instance methods, so cached state should be in an instance field not 
a static one.

> And I agree with you that the native isBigEndian() should be called once
> in the lifetime of the VM.
>
> so the idea is to write:
>
> public boolean isBigEndian() {
>    return BE;
> }
> private static final boolean BE = isBigEndian0();
>
> private static native boolean isBigEndian0();

Other than the static parts that is what I was suggesting :)

Cheers,
David

> cheers,
> R?mi
>


From forax at univ-mlv.fr  Sun Mar  8 23:57:45 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 09 Mar 2015 00:57:45 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FCDC19.1090804@oracle.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>	<54F76937.2040203@redhat.com>	<54F7AAD6.8040206@oracle.com>	<54F817B9.8090500@redhat.com>	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>	<54F9F701.90501@redhat.com>	<54FCD73A.3040808@oracle.com>
	<54FCD991.4070907@univ-mlv.fr> <54FCDC19.1090804@oracle.com>
Message-ID: <54FCE1F9.7060109@univ-mlv.fr>


On 03/09/2015 12:32 AM, David Holmes wrote:
> On 9/03/2015 9:21 AM, Remi Forax wrote:
>>
>> On 03/09/2015 12:11 AM, David Holmes wrote:
>>> On 7/03/2015 4:50 AM, Andrew Haley wrote:
>>>> I've tried to so everything I've been asked.  If this version passes
>>>> muster with everyone I'll Javadoc all the public methods and fields
>>>> and put it up for RFA next week.
>>>>
>>>> I guess it's going to need a lot of testing and security analysis.
>>>>
>>>> I added versions of all {put,get} methods with the boolean bigEndian
>>>> argument.  This makes HeapByteBuffer much cleaner, and it does not
>>>> need to know the machine endianness at all.  I hope that's OK.
>>>>
>>>> Andrew.
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~aph/unaligned.hotspot.4/
>>>> http://cr.openjdk.java.net/~aph/unaligned.jdk.4/
>>>
>>> I think it is cleaner and more efficient if Unsafe maintains BE as an
>>> instance variable (initialized at construction) and that isBigEndian()
>>> simply returns that. The native check should only need to be called
>>> once in the lifetime of the VM.
>>>
>>> David
>>>
>>
>> BE doesn't need to be an instance, method of Unsafe are instance methods
>> just to enforce security,
>> you can not call them if you don"t have an instance of Unsafe (and
>> getUnsafe() does the security check).
>>
>> BE is private so it doesn't have to be an instance field it can be
>> static field.
>
> Yes it could but why should it be? You have a singleton instance with 
> all instance methods, so cached state should be in an instance field 
> not a static one.

because the instance of Unsafe is a kind of security token (you get the 
instance once you have pass the security check) and starting to add 
instance field to it will obscure its meaning.

>
>> And I agree with you that the native isBigEndian() should be called once
>> in the lifetime of the VM.
>>
>> so the idea is to write:
>>
>> public boolean isBigEndian() {
>>    return BE;
>> }
>> private static final boolean BE = isBigEndian0();
>>
>> private static native boolean isBigEndian0();
>
> Other than the static parts that is what I was suggesting :)
>
> Cheers,
> David

cheers,
R?mi



From david.holmes at oracle.com  Mon Mar  9 00:02:48 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 09 Mar 2015 10:02:48 +1000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FCE1F9.7060109@univ-mlv.fr>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>	<54F76937.2040203@redhat.com>	<54F7AAD6.8040206@oracle.com>	<54F817B9.8090500@redhat.com>	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>	<54F9F701.90501@redhat.com>	<54FCD73A.3040808@oracle.com>
	<54FCD991.4070907@univ-mlv.fr> <54FCDC19.1090804@oracle.com>
	<54FCE1F9.7060109@univ-mlv.fr>
Message-ID: <54FCE328.3020007@oracle.com>

On 9/03/2015 9:57 AM, Remi Forax wrote:
>
> On 03/09/2015 12:32 AM, David Holmes wrote:
>> On 9/03/2015 9:21 AM, Remi Forax wrote:
>>>
>>> On 03/09/2015 12:11 AM, David Holmes wrote:
>>>> On 7/03/2015 4:50 AM, Andrew Haley wrote:
>>>>> I've tried to so everything I've been asked.  If this version passes
>>>>> muster with everyone I'll Javadoc all the public methods and fields
>>>>> and put it up for RFA next week.
>>>>>
>>>>> I guess it's going to need a lot of testing and security analysis.
>>>>>
>>>>> I added versions of all {put,get} methods with the boolean bigEndian
>>>>> argument.  This makes HeapByteBuffer much cleaner, and it does not
>>>>> need to know the machine endianness at all.  I hope that's OK.
>>>>>
>>>>> Andrew.
>>>>>
>>>>>
>>>>> http://cr.openjdk.java.net/~aph/unaligned.hotspot.4/
>>>>> http://cr.openjdk.java.net/~aph/unaligned.jdk.4/
>>>>
>>>> I think it is cleaner and more efficient if Unsafe maintains BE as an
>>>> instance variable (initialized at construction) and that isBigEndian()
>>>> simply returns that. The native check should only need to be called
>>>> once in the lifetime of the VM.
>>>>
>>>> David
>>>>
>>>
>>> BE doesn't need to be an instance, method of Unsafe are instance methods
>>> just to enforce security,
>>> you can not call them if you don"t have an instance of Unsafe (and
>>> getUnsafe() does the security check).
>>>
>>> BE is private so it doesn't have to be an instance field it can be
>>> static field.
>>
>> Yes it could but why should it be? You have a singleton instance with
>> all instance methods, so cached state should be in an instance field
>> not a static one.
>
> because the instance of Unsafe is a kind of security token (you get the
> instance once you have pass the security check) and starting to add
> instance field to it will obscure its meaning.

You've completely lost me there. It is an instance therefore it makes 
sense to define everything at the instance level, regardless of why it 
was necessary to define it as an instance in the first place.

David

>>
>>> And I agree with you that the native isBigEndian() should be called once
>>> in the lifetime of the VM.
>>>
>>> so the idea is to write:
>>>
>>> public boolean isBigEndian() {
>>>    return BE;
>>> }
>>> private static final boolean BE = isBigEndian0();
>>>
>>> private static native boolean isBigEndian0();
>>
>> Other than the static parts that is what I was suggesting :)
>>
>> Cheers,
>> David
>
> cheers,
> R?mi
>


From david.holmes at oracle.com  Mon Mar  9 00:34:15 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 09 Mar 2015 10:34:15 +1000
Subject: RFR: JDK-8074578 Document memory visibility effects of some Unsafe
	methods
In-Reply-To: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>
References: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>
Message-ID: <54FCEA87.3030509@oracle.com>

On 7/03/2015 6:49 AM, Martin Buchholz wrote:
> A wee code review fer ya:
>
> https://bugs.openjdk.java.net/browse/JDK-8074578
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Unsafe-CAS-spec/

Sorry Martin but this is neither accurate nor meaningful. It isn't 
accurate because the actual Atomic::cmpxchg operations have full 
bi-directional fences, and in the long case if locking is used you get 
locking related barriers not volatile access barriers. It isn't 
meaningful because you haven't said what variable the volatile semantics 
apply to (not that that would help in the lock-based case).

David


From martinrb at google.com  Mon Mar  9 05:03:41 2015
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 8 Mar 2015 22:03:41 -0700
Subject: RFR: JDK-8074578 Document memory visibility effects of some
	Unsafe methods
In-Reply-To: <54FCEA87.3030509@oracle.com>
References: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>
	<54FCEA87.3030509@oracle.com>
Message-ID: <CA+kOe0_fmYipnWyPfFyrLwYHRZa6zO+At9T1khmCW4GasHjdPQ@mail.gmail.com>

I didn't expect this to be controversial.
The spec for regular compareAndSet has similar wording.
I don't think it matters whether implementation is via a lock, because the
lock itself entails at least a volatile read and write.
As to which variable is being read/written to, it should be obvious that
it's the location being CAS'ed (or equivalent).

Can we clarify existing spec for atomics?

http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/package-summary.html

   - compareAndSet and all other read-and-update operations such as
   getAndIncrement have the memory effects of both reading and writing
   volatile variables.


On Sun, Mar 8, 2015 at 5:34 PM, David Holmes <david.holmes at oracle.com>
wrote:

> On 7/03/2015 6:49 AM, Martin Buchholz wrote:
>
>> A wee code review fer ya:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8074578
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Unsafe-CAS-spec/
>>
>
> Sorry Martin but this is neither accurate nor meaningful. It isn't
> accurate because the actual Atomic::cmpxchg operations have full
> bi-directional fences, and in the long case if locking is used you get
> locking related barriers not volatile access barriers. It isn't meaningful
> because you haven't said what variable the volatile semantics apply to (not
> that that would help in the lock-based case).
>
> David
>


From john.r.rose at oracle.com  Mon Mar  9 05:53:18 2015
From: john.r.rose at oracle.com (John Rose)
Date: Sun, 8 Mar 2015 22:53:18 -0700
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FCD73A.3040808@oracle.com>
References: <54EB6DD1.4090803@redhat.com>
	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>
	<54EDFBA3.6080609@redhat.com> <54F4BA63.5060506@redhat.com>
	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>
	<54F716BD.2030706@redhat.com>
	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>
	<54F7263A.7040902@redhat.com>
	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>
	<54F76937.2040203@redhat.com> <54F7AAD6.8040206@oracle.com>
	<54F817B9.8090500@redhat.com>
	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>
	<54F9F701.90501@redhat.com> <54FCD73A.3040808@oracle.com>
Message-ID: <29AA6FCC-73A8-452D-A316-A1B276D812D2@oracle.com>

On Mar 8, 2015, at 4:11 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 7/03/2015 4:50 AM, Andrew Haley wrote:
>> I've tried to so everything I've been asked.  If this version passes
>> muster with everyone I'll Javadoc all the public methods and fields
>> and put it up for RFA next week.
>> 
>> I guess it's going to need a lot of testing and security analysis.
>> 
>> I added versions of all {put,get} methods with the boolean bigEndian
>> argument.  This makes HeapByteBuffer much cleaner, and it does not
>> need to know the machine endianness at all.  I hope that's OK.
>> 
>> Andrew.
>> 
>> 
>> http://cr.openjdk.java.net/~aph/unaligned.hotspot.4/
>> http://cr.openjdk.java.net/~aph/unaligned.jdk.4/
> 
> I think it is cleaner and more efficient if Unsafe maintains BE as an instance variable (initialized at construction) and that isBigEndian() simply returns that. The native check should only need to be called once in the lifetime of the VM.

It should be a static final variable, since those have the most robust constant folding optimizations.

? John

From john.r.rose at oracle.com  Mon Mar  9 05:56:21 2015
From: john.r.rose at oracle.com (John Rose)
Date: Sun, 8 Mar 2015 22:56:21 -0700
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FCDC19.1090804@oracle.com>
References: <54EB6DD1.4090803@redhat.com>
	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>
	<54EDFBA3.6080609@redhat.com> <54F4BA63.5060506@redhat.com>
	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>
	<54F716BD.2030706@redhat.com>
	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>
	<54F7263A.7040902@redhat.com>
	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>
	<54F76937.2040203@redhat.com> <54F7AAD6.8040206@oracle.com>
	<54F817B9.8090500@redhat.com>
	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>
	<54F9F701.90501@redhat.com> <54FCD73A.3040808@oracle.com>
	<54FCD991.4070907@univ-mlv.fr> <54FCDC19.1090804@oracle.com>
Message-ID: <AEA33D96-4026-4673-9844-F691EA5B4914@oracle.com>

On Mar 8, 2015, at 4:32 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Yes it could but why should it be? You have a singleton instance with all instance methods, so cached state should be in an instance field not a static one.

No, the singleton instance is *not* currently used, so it would add new constraints on the optimizer to begin using fields from it.
Only the non-nullness of its reference is significant.  It has no state by design.
Put another way:  It is a uniquely simple empty singleton object.
To pass the unsafe access check, the JIT need only check that some non-null reference is available.
And JVM JITs are very good at exactly that check.

? John

From john.r.rose at oracle.com  Mon Mar  9 05:57:00 2015
From: john.r.rose at oracle.com (John Rose)
Date: Sun, 8 Mar 2015 22:57:00 -0700
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FCE328.3020007@oracle.com>
References: <54EB6DD1.4090803@redhat.com>
	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>
	<54EDFBA3.6080609@redhat.com> <54F4BA63.5060506@redhat.com>
	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>
	<54F716BD.2030706@redhat.com>
	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>
	<54F7263A.7040902@redhat.com>
	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>
	<54F76937.2040203@redhat.com> <54F7AAD6.8040206@oracle.com>
	<54F817B9.8090500@redhat.com>
	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>
	<54F9F701.90501@redhat.com> <54FCD73A.3040808@oracle.com>
	<54FCD991.4070907@univ-mlv.fr> <54FCDC19.1090804@oracle.com>
	<54FCE1F9.7060109@univ-mlv.fr> <54FCE328.3020007@oracle.com>
Message-ID: <41A0F131-D9AD-4A20-9FE5-F8D277B35555@oracle.com>

On Mar 8, 2015, at 5:02 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> It is an instance therefore it makes sense to define everything at the instance level

Nope.  See previous messages.

From david.holmes at oracle.com  Mon Mar  9 06:06:19 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 09 Mar 2015 16:06:19 +1000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <AEA33D96-4026-4673-9844-F691EA5B4914@oracle.com>
References: <54EB6DD1.4090803@redhat.com>
	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>
	<54EDFBA3.6080609@redhat.com> <54F4BA63.5060506@redhat.com>
	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>
	<54F716BD.2030706@redhat.com>
	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>
	<54F7263A.7040902@redhat.com>
	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>
	<54F76937.2040203@redhat.com> <54F7AAD6.8040206@oracle.com>
	<54F817B9.8090500@redhat.com>
	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>
	<54F9F701.90501@redhat.com> <54FCD73A.3040808@oracle.com>
	<54FCD991.4070907@univ-mlv.fr> <54FCDC19.1090804@oracle.com>
	<AEA33D96-4026-4673-9844-F691EA5B4914@oracle.com>
Message-ID: <54FD385B.6000002@oracle.com>

On 9/03/2015 3:56 PM, John Rose wrote:
> On Mar 8, 2015, at 4:32 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>>
>> Yes it could but why should it be? You have a singleton instance with
>> all instance methods, so cached state should be in an instance field
>> not a static one.
>
> No, the singleton instance is *not* currently used, so it would add new
> constraints on the optimizer to begin using fields from it.

No sure what you mean by it isn't used - code invokes instance methods 
on the unsafe instance all over the JDK ???

> Only the non-nullness of its reference is significant.  It has no state
> by design.

Given all existing methods are stateless I can't tell if this a 
statement of intent (ie it must never have state) or simply a statement 
of fact as all the methods are stateless. If it should in fact never 
have any state then that should be documented.

> Put another way:  It is a uniquely simple empty singleton object.
> To pass the unsafe access check, the JIT need only check that some
> non-null reference is available.
> And JVM JITs are very good at exactly that check.

So the reason to use a static field from an instance method is simply an 
artifact of the interaction of our JIT with this class?

David

> ? John


From amy.lu at oracle.com  Mon Mar  9 08:41:10 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Mon, 09 Mar 2015 16:41:10 +0800
Subject: JDK 9 RFR of JDK-8074674: Doclint regression in
	java/util/regex/Matcher.java
Message-ID: <54FD5CA6.1020203@oracle.com>

Please review the fix for Doclint regression in 
java/util/regex/Matcher.java:

     error: bad use of '>'

from
     * <tt>mr -> mr.group().toUpperCase()</tt>, an invocation of this 
method on

This fixed by using @code tag

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

I also need a sponsor for this fix.

Thanks,
Amy


From aph at redhat.com  Mon Mar  9 09:06:51 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 09 Mar 2015 09:06:51 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FCD569.6040806@gmail.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>
	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>	<54F76937.2040203@redhat.com>
	<54F7AAD6.8040206@oracle.com>	<54F817B9.8090500@redhat.com>	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>
	<54F9F701.90501@redhat.com> <54FB6C3A.4070508@gmail.com>
	<54FC2EE5.2040601@redhat.com> <54FCD569.6040806@gmail.com>
Message-ID: <54FD62AB.1090905@redhat.com>

On 08/03/15 23:04, Peter Levart wrote:
> 
> On 03/08/2015 12:13 PM, Andrew Haley wrote:
>>> > That's OK if you think this approach is a better division of
>>> > concerns (Unsafe being low-level), but in Heap-X-Buffer you are only
>>> > using Unsafe.get|putXXXUnaligned() and don't consider using
>>> > get|putXXX directly when unalignedAccess() == true.
>> Right, because there's no point in doing so when unalignedAccess() ==
>> true because the exact same code will be generated.  In my Utopian
>> world nothing except Unsafe would have to deal with issues such as
>> this.  However, I think that people writing library code (e.g. array
>> comparison intrinsics) might still need to know.
>
> Ah, sorry. I haven't realized that the same code will be generated
> by compiler intrinsics. So the Java part is just for interpreter and
> platforms not supporting unaligned access and when
> UseUnalignedAccesses is explicitly disabled?

That's right.  You really have to look at both of these patches, the
HotSpot and the JDK part, for this approach to make sense.

Andrew.


From erik.joelsson at oracle.com  Mon Mar  9 09:08:54 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 09 Mar 2015 10:08:54 +0100
Subject: RFR: JDK-8074096 Disable (most) native warnings in JDK on a
	per-library basis
In-Reply-To: <54F9D281.3030206@oracle.com>
References: <54F705E0.2030102@oracle.com> <54F70949.4040900@oracle.com>
	<54F9D281.3030206@oracle.com>
Message-ID: <54FD6326.4070403@oracle.com>

Thanks, looks good!

/Erik

On 2015-03-06 17:14, Magnus Ihse Bursie wrote:
> On 2015-03-04 14:31, Erik Joelsson wrote:
>> Hello,
>>
>> Really nice to finally see this patch getting done!
>>
>> Only one comment:
>>
>> flags.m4:
>> In the grep expression, could you move the extra [] outside of the 
>> actual command line options to grep so that the command line could be 
>> copied to the shell for debugging in the future? Also, how hard would 
>> it be to instead do AC_COMPILE_IFELSE with a dummy warning to instead 
>> test for capability?
>
> I have updated the fix to use the eminent 
> FLAGS_COMPILER_CHECK_ARGUMENTS instead. :-)
>
> http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.02 
>
>
> /Magnus
>



From aph at redhat.com  Mon Mar  9 09:11:19 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 09 Mar 2015 09:11:19 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FCD991.4070907@univ-mlv.fr>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>	<54F76937.2040203@redhat.com>	<54F7AAD6.8040206@oracle.com>	<54F817B9.8090500@redhat.com>	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>	<54F9F701.90501@redhat.com>	<54FCD73A.3040808@oracle.com>
	<54FCD991.4070907@univ-mlv.fr>
Message-ID: <54FD63B7.8040400@redhat.com>

On 08/03/15 23:21, Remi Forax wrote:
> BE doesn't need to be an instance, method of Unsafe are instance methods 
> just to enforce security,
> you can not call them if you don"t have an instance of Unsafe (and 
> getUnsafe() does the security check).
> 
> BE is private so it doesn't have to be an instance field it can be 
> static field.
> 
> And I agree with you that the native isBigEndian() should be called once 
> in the lifetime of the VM.
> 
> so the idea is to write:
> 
> public boolean isBigEndian() {
>    return BE;
> }
> private static final boolean BE = isBigEndian0();
> 
> private static native boolean isBigEndian0();

I understand.  However, the callers of isBigEndian() do their own
caching, so it seems to me that this will be a case of double-caching.
It's not important from a performance point of view, but it is
additional complexity.

Andrew.


From aph at redhat.com  Mon Mar  9 09:27:03 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 09 Mar 2015 09:27:03 +0000
Subject: RFR: JDK-8074578 Document memory visibility effects of some Unsafe
	methods
In-Reply-To: <54FCEA87.3030509@oracle.com>
References: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>
	<54FCEA87.3030509@oracle.com>
Message-ID: <54FD6767.8020506@redhat.com>

On 09/03/15 00:34, David Holmes wrote:
> On 7/03/2015 6:49 AM, Martin Buchholz wrote:
>> A wee code review fer ya:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8074578
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Unsafe-CAS-spec/
> 
> Sorry Martin but this is neither accurate nor meaningful. It isn't 
> accurate because the actual Atomic::cmpxchg operations have full 
> bi-directional fences, and in the long case if locking is used you get 
> locking related barriers not volatile access barriers.

But the fact that an implementation is stronger than is strictly
required has no bearing on the specification.  We've discussed this at
some length on the concurrency-interest list, and the semantics of a
volatile read followed by a volatile write (if the copmpare is
successful) are what is required by the JMM.

Andrew.


From chris.hegarty at oracle.com  Mon Mar  9 10:10:04 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 09 Mar 2015 10:10:04 +0000
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <BLU175-W460A71BD3351510864D3E0831C0@phx.gbl>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>,
	<54DE1969.2040508@gmail.com> <54E393BC.4030600@Oracle.com>,
	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>
	<BLU175-W460A71BD3351510864D3E0831C0@phx.gbl>
Message-ID: <54FD717C.1070500@oracle.com>

On 06/03/15 19:34, Jason Mehrens wrote:
> Hi Chris,

>
> Since getPid can throw UOE that means that compareTo could now throw UOE.

Ooh... I don't like this.

Has any consideration been given to getPid returning -1, if unknown or 
the default implementation? Or would this be any better?

-Chris

>
>
>
> Jason
>
>
> ----------------------------------------
>> Subject: Re: JEP 102 Process Updates revised API draft
>> From: chris.hegarty at oracle.com
>> Date: Fri, 6 Mar 2015 11:59:28 +0000
>> To: Roger.Riggs at oracle.com
>> CC: core-libs-dev at openjdk.java.net
>>
>> Roger,
>>
>> I?ve taken a look at these changes in the sandbox ( JDK-8046092-branch ). Overall I welcome this addition.
>>
>> Some comments, most of which I stuffed into a webrev based on your branch,
>> http://cr.openjdk.java.net/~chegar/process_comments/webrev/
>>
>> 1) ProcessHandle.compareTo() can drop the ClassCastException
>> Also, I think the comparison is the wrong way around. It should
>> be compare(this, other), rather than compare(other, this), right?
>>
>> 2) I know there has been a lot of discussion about the use of CF,
>> but I have a few more comments:
>>
>> a) Both onExist and onProcessExit are implemented to unconditionally
>> throw UOE. Is the intention to make the implementation of these
>> methods optional? If so, then UOE should be documented, If not,
>> then I think they can be abstract, right?
>>
>> b) The wording in the spec talks about async functions and actions.
>> I think this may be not quite right. The intention is to support, as is
>> provided by CF, the ability to chain both sync and async tasks.
>> [ I suggested some wording in the webrev ]
>>
>> c) Why the need for ISE if the process is the current process, and not
>> just return a CF that never completes? Do you consider this an
>> error situation that you want to notify, or consistency with other
>> parts of the API ?
>>
>> d) I wonder if onProcessExit should have a small API note, saying
>> that it is preferred over onExit, when you have a Process. Or
>> something to promote its use over onExit, or briefly explain its
>> existence. ( I know why it is there, but it may appear as duplication )
>>
>> e) Maybe onProcessExit would benefit from an apiNote to indicate
>> that it is essentially an alternative to waitFor() ?
>>
>> 3) Should ProcessHandle.getPid declare that it can throw IOE?
>> Process.getPid declares UOE.
>>
>> 4) ProcessHandle.Info.user() ? owner() seems more appropriate, no?
>>
>> 5) The description of info() talks about fields, when it is an interface.
>> I added some suggested rewording. Also, all methods now return
>> references, so -1 can be removed. Similar for the Info class description.
>>
>> 6) There are a couple of @since 1.9 tags missing from Process
>> supportsDestroyForcibly and onProcessExit
>>
>> That?s all for now.
>>
>> -Chris.
>>
>>
>> 		 	   		


From david.holmes at oracle.com  Mon Mar  9 11:13:29 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 09 Mar 2015 21:13:29 +1000
Subject: RFR: JDK-8074578 Document memory visibility effects of some Unsafe
	methods
In-Reply-To: <54FD6767.8020506@redhat.com>
References: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>
	<54FCEA87.3030509@oracle.com> <54FD6767.8020506@redhat.com>
Message-ID: <54FD8059.9050205@oracle.com>

On 9/03/2015 7:27 PM, Andrew Haley wrote:
> On 09/03/15 00:34, David Holmes wrote:
>> On 7/03/2015 6:49 AM, Martin Buchholz wrote:
>>> A wee code review fer ya:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8074578
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Unsafe-CAS-spec/
>>
>> Sorry Martin but this is neither accurate nor meaningful. It isn't
>> accurate because the actual Atomic::cmpxchg operations have full
>> bi-directional fences, and in the long case if locking is used you get
>> locking related barriers not volatile access barriers.
>
> But the fact that an implementation is stronger than is strictly
> required has no bearing on the specification.  We've discussed this at
> some length on the concurrency-interest list, and the semantics of a
> volatile read followed by a volatile write (if the copmpare is
> successful) are what is required by the JMM.

But who is to say that is the specification for the Unsafe API? The 
public API's have a specification for what they provide to the 
programmer. On what basis are we assigning that same specification to 
Unsafe API? The Unsafe API has to meet the requirements of the public 
APIs that use it, but that doesn't  mean it necessarily should have the 
same specification as those APIs.

David

> Andrew.
>


From aph at redhat.com  Mon Mar  9 11:24:56 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 09 Mar 2015 11:24:56 +0000
Subject: RFR: JDK-8074578 Document memory visibility effects of some Unsafe
	methods
In-Reply-To: <54FD8059.9050205@oracle.com>
References: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>
	<54FCEA87.3030509@oracle.com> <54FD6767.8020506@redhat.com>
	<54FD8059.9050205@oracle.com>
Message-ID: <54FD8308.3020806@redhat.com>

On 03/09/2015 11:13 AM, David Holmes wrote:
> On 9/03/2015 7:27 PM, Andrew Haley wrote:
>> On 09/03/15 00:34, David Holmes wrote:
>>> On 7/03/2015 6:49 AM, Martin Buchholz wrote:
>>>> A wee code review fer ya:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8074578
>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Unsafe-CAS-spec/
>>>
>>> Sorry Martin but this is neither accurate nor meaningful. It isn't
>>> accurate because the actual Atomic::cmpxchg operations have full
>>> bi-directional fences, and in the long case if locking is used you get
>>> locking related barriers not volatile access barriers.
>>
>> But the fact that an implementation is stronger than is strictly
>> required has no bearing on the specification.  We've discussed this at
>> some length on the concurrency-interest list, and the semantics of a
>> volatile read followed by a volatile write (if the compare is
>> successful) are what is required by the JMM.
> 
> But who is to say that is the specification for the Unsafe API? The 
> public API's have a specification for what they provide to the 
> programmer. On what basis are we assigning that same specification to 
> Unsafe API? The Unsafe API has to meet the requirements of the public 
> APIs that use it, but that doesn't  mean it necessarily should have the 
> same specification as those APIs.

No, it doesn't, but there is no reason that the Unsafe API should
provide stronger guarantees than the public APIs, and to do so would,
to quote Hans Boehm, be "too strong in ways that everybody pays for,
but that only benefit racy programs and experts who should know
better."

Andrew.


From peter.levart at gmail.com  Mon Mar  9 11:32:29 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 09 Mar 2015 12:32:29 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FD63B7.8040400@redhat.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>	<54F76937.2040203@redhat.com>	<54F7AAD6.8040206@oracle.com>	<54F817B9.8090500@redhat.com>	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>	<54F9F701.90501@redhat.com>	<54FCD73A.3040808@oracle.com>	<54FCD991.4070907@univ-mlv.fr>
	<54FD63B7.8040400@redhat.com>
Message-ID: <54FD84CD.6040307@gmail.com>

On 03/09/2015 10:11 AM, Andrew Haley wrote:
> On 08/03/15 23:21, Remi Forax wrote:
>> BE doesn't need to be an instance, method of Unsafe are instance methods
>> just to enforce security,
>> you can not call them if you don"t have an instance of Unsafe (and
>> getUnsafe() does the security check).
>>
>> BE is private so it doesn't have to be an instance field it can be
>> static field.
>>
>> And I agree with you that the native isBigEndian() should be called once
>> in the lifetime of the VM.
>>
>> so the idea is to write:
>>
>> public boolean isBigEndian() {
>>     return BE;
>> }
>> private static final boolean BE = isBigEndian0();
>>
>> private static native boolean isBigEndian0();
> I understand.  However, the callers of isBigEndian() do their own
> caching, so it seems to me that this will be a case of double-caching.
> It's not important from a performance point of view, but it is
> additional complexity.
>
> Andrew.

If we take a look at status quo, then the pattern for safe constant 
state in Unsafe is as follows:

     public native int arrayBaseOffset(Class<?> arrayClass);

     /** The value of {@code arrayBaseOffset(boolean[].class)} */
     public static final int ARRAY_BOOLEAN_BASE_OFFSET
             = theUnsafe.arrayBaseOffset(boolean[].class);


...this has the benefit that it doesn't require caching at use site. But 
the above pattern could be tweaked a bit in case of isBigEndian(). The 
method could be declared as private since it does not add a utility like 
above method which is a function of 1 argument.

The argument that we don't want to expose public API is unfounded as 
Unsafe won't be visible to normal code in JDK9, right?

Regards, Peter




From paul.sandoz at oracle.com  Mon Mar  9 11:36:20 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 9 Mar 2015 12:36:20 +0100
Subject: JDK 9 RFR of JDK-8074674: Doclint regression in
	java/util/regex/Matcher.java
In-Reply-To: <54FD5CA6.1020203@oracle.com>
References: <54FD5CA6.1020203@oracle.com>
Message-ID: <9A40EE4F-8DD5-4EA5-823E-62B8C20857A0@oracle.com>


On Mar 9, 2015, at 9:41 AM, Amy Lu <amy.lu at oracle.com> wrote:

> Please review the fix for Doclint regression in java/util/regex/Matcher.java:
> 
>    error: bad use of '>'
> 
> from
>    * <tt>mr -> mr.group().toUpperCase()</tt>, an invocation of this method on
> 
> This fixed by using @code tag
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8074674
> webrev: http://cr.openjdk.java.net/~amlu/8074674/webrev.00/
> 
> I also need a sponsor for this fix.
> 

Ooops that was my fault, sorry.

+1

I did perform a "make docs" locally and did not observe any errors/warnings in the output, was that because i missed them or because the doclint is run as a separate process?

Paul.


From aph at redhat.com  Mon Mar  9 14:11:26 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 09 Mar 2015 14:11:26 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FD84CD.6040307@gmail.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>	<54F76937.2040203@redhat.com>	<54F7AAD6.8040206@oracle.com>	<54F817B9.8090500@redhat.com>	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>	<54F9F701.90501@redhat.com>	<54FCD73A.3040808@oracle.com>	<54FCD991.4070907@univ-mlv.fr>	<54FD63B7.8040400@redhat.com>
	<54FD84CD.6040307@gmail.com>
Message-ID: <54FDAA0E.4050109@redhat.com>

On 03/09/2015 11:32 AM, Peter Levart wrote:
> On 03/09/2015 10:11 AM, Andrew Haley wrote:
>> On 08/03/15 23:21, Remi Forax wrote:
>>> BE doesn't need to be an instance, method of Unsafe are instance methods
>>> just to enforce security,
>>> you can not call them if you don"t have an instance of Unsafe (and
>>> getUnsafe() does the security check).
>>>
>>> BE is private so it doesn't have to be an instance field it can be
>>> static field.
>>>
>>> And I agree with you that the native isBigEndian() should be called once
>>> in the lifetime of the VM.
>>>
>>> so the idea is to write:
>>>
>>> public boolean isBigEndian() {
>>>     return BE;
>>> }
>>> private static final boolean BE = isBigEndian0();
>>>
>>> private static native boolean isBigEndian0();
>> I understand.  However, the callers of isBigEndian() do their own
>> caching, so it seems to me that this will be a case of double-caching.
>> It's not important from a performance point of view, but it is
>> additional complexity.
> 
> If we take a look at status quo, then the pattern for safe constant 
> state in Unsafe is as follows:
> 
>      public native int arrayBaseOffset(Class<?> arrayClass);
> 
>      /** The value of {@code arrayBaseOffset(boolean[].class)} */
>      public static final int ARRAY_BOOLEAN_BASE_OFFSET
>              = theUnsafe.arrayBaseOffset(boolean[].class);
> 
> 
> ...this has the benefit that it doesn't require caching at use site. But 
> the above pattern could be tweaked a bit in case of isBigEndian(). The 
> method could be declared as private since it does not add a utility like 
> above method which is a function of 1 argument.
> 
> The argument that we don't want to expose public API is unfounded as 
> Unsafe won't be visible to normal code in JDK9, right?

I see your point, but I don't want to tie our hands with respect to
future implementations.  We might want to refactor this code in the
future, and leaving isBigEndian() as an accessor costs little.  For
that reason I really don't want to make this a public final field but
I will cache it in Unsafe if people want me to.

Andrew.


From Roger.Riggs at Oracle.com  Mon Mar  9 14:28:37 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 09 Mar 2015 10:28:37 -0400
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54FD717C.1070500@oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>,
	<54DE1969.2040508@gmail.com> <54E393BC.4030600@Oracle.com>,
	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>
	<BLU175-W460A71BD3351510864D3E0831C0@phx.gbl>
	<54FD717C.1070500@oracle.com>
Message-ID: <54FDAE15.8080606@Oracle.com>

Hi,

The problem could be isolated to compareTo by defining the ordering if 
getPid
throws UOE and without diluting the spec for getPid returning the native 
os process identifier.

Defining the default for getPid() to return -1, might not have too big 
an impact.
It would order the incompletely implemented Process subtypes before the 
real ones
but the order is not usually significant except to be able to have a 
predictable iteration order
or use TreeMap. Returning Long.MAX_VALUE as the default might be another 
option.

Roger



On 3/9/2015 6:10 AM, Chris Hegarty wrote:
> On 06/03/15 19:34, Jason Mehrens wrote:
>> Hi Chris,
>
>>
>> Since getPid can throw UOE that means that compareTo could now throw 
>> UOE.
>
> Ooh... I don't like this.
>
> Has any consideration been given to getPid returning -1, if unknown or 
> the default implementation? Or would this be any better?
>
> -Chris
>
>>
>>
>>
>> Jason
>>
>>
>> ----------------------------------------
>>> Subject: Re: JEP 102 Process Updates revised API draft
>>> From: chris.hegarty at oracle.com
>>> Date: Fri, 6 Mar 2015 11:59:28 +0000
>>> To: Roger.Riggs at oracle.com
>>> CC: core-libs-dev at openjdk.java.net
>>>
>>> Roger,
>>>
>>> I?ve taken a look at these changes in the sandbox ( 
>>> JDK-8046092-branch ). Overall I welcome this addition.
>>>
>>> Some comments, most of which I stuffed into a webrev based on your 
>>> branch,
>>> http://cr.openjdk.java.net/~chegar/process_comments/webrev/
>>>
>>> 1) ProcessHandle.compareTo() can drop the ClassCastException
>>> Also, I think the comparison is the wrong way around. It should
>>> be compare(this, other), rather than compare(other, this), right?
>>>
>>> 2) I know there has been a lot of discussion about the use of CF,
>>> but I have a few more comments:
>>>
>>> a) Both onExist and onProcessExit are implemented to unconditionally
>>> throw UOE. Is the intention to make the implementation of these
>>> methods optional? If so, then UOE should be documented, If not,
>>> then I think they can be abstract, right?
>>>
>>> b) The wording in the spec talks about async functions and actions.
>>> I think this may be not quite right. The intention is to support, as is
>>> provided by CF, the ability to chain both sync and async tasks.
>>> [ I suggested some wording in the webrev ]
>>>
>>> c) Why the need for ISE if the process is the current process, and not
>>> just return a CF that never completes? Do you consider this an
>>> error situation that you want to notify, or consistency with other
>>> parts of the API ?
>>>
>>> d) I wonder if onProcessExit should have a small API note, saying
>>> that it is preferred over onExit, when you have a Process. Or
>>> something to promote its use over onExit, or briefly explain its
>>> existence. ( I know why it is there, but it may appear as duplication )
>>>
>>> e) Maybe onProcessExit would benefit from an apiNote to indicate
>>> that it is essentially an alternative to waitFor() ?
>>>
>>> 3) Should ProcessHandle.getPid declare that it can throw IOE?
>>> Process.getPid declares UOE.
>>>
>>> 4) ProcessHandle.Info.user() ? owner() seems more appropriate, no?
>>>
>>> 5) The description of info() talks about fields, when it is an 
>>> interface.
>>> I added some suggested rewording. Also, all methods now return
>>> references, so -1 can be removed. Similar for the Info class 
>>> description.
>>>
>>> 6) There are a couple of @since 1.9 tags missing from Process
>>> supportsDestroyForcibly and onProcessExit
>>>
>>> That?s all for now.
>>>
>>> -Chris.
>>>
>>>
>>>



From chris.hegarty at oracle.com  Mon Mar  9 14:43:20 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 09 Mar 2015 14:43:20 +0000
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54FDAE15.8080606@Oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>,
	<54DE1969.2040508@gmail.com> <54E393BC.4030600@Oracle.com>,
	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>
	<BLU175-W460A71BD3351510864D3E0831C0@phx.gbl>
	<54FD717C.1070500@oracle.com> <54FDAE15.8080606@Oracle.com>
Message-ID: <54FDB188.1000602@oracle.com>

On 09/03/15 14:28, Roger Riggs wrote:
> Hi,
>
> The problem could be isolated to compareTo by defining the ordering if
> getPid
> throws UOE and without diluting the spec for getPid returning the native
> os process identifier.

Yes, that would work.

> Defining the default for getPid() to return -1, might not have too big
> an impact.
> It would order the incompletely implemented Process subtypes before the
> real ones
> but the order is not usually significant except to be able to have a
> predictable iteration order
> or use TreeMap. Returning Long.MAX_VALUE as the default might be another
> option.

That would probably be ok too, and then the UOE could be removed from 
Process.getPid() too, right? Which solves that small API wart.

-Chris.

> Roger
>
>
>
> On 3/9/2015 6:10 AM, Chris Hegarty wrote:
>> On 06/03/15 19:34, Jason Mehrens wrote:
>>> Hi Chris,
>>
>>>
>>> Since getPid can throw UOE that means that compareTo could now throw
>>> UOE.
>>
>> Ooh... I don't like this.
>>
>> Has any consideration been given to getPid returning -1, if unknown or
>> the default implementation? Or would this be any better?
>>
>> -Chris
>>
>>>
>>>
>>>
>>> Jason
>>>
>>>
>>> ----------------------------------------
>>>> Subject: Re: JEP 102 Process Updates revised API draft
>>>> From: chris.hegarty at oracle.com
>>>> Date: Fri, 6 Mar 2015 11:59:28 +0000
>>>> To: Roger.Riggs at oracle.com
>>>> CC: core-libs-dev at openjdk.java.net
>>>>
>>>> Roger,
>>>>
>>>> I?ve taken a look at these changes in the sandbox (
>>>> JDK-8046092-branch ). Overall I welcome this addition.
>>>>
>>>> Some comments, most of which I stuffed into a webrev based on your
>>>> branch,
>>>> http://cr.openjdk.java.net/~chegar/process_comments/webrev/
>>>>
>>>> 1) ProcessHandle.compareTo() can drop the ClassCastException
>>>> Also, I think the comparison is the wrong way around. It should
>>>> be compare(this, other), rather than compare(other, this), right?
>>>>
>>>> 2) I know there has been a lot of discussion about the use of CF,
>>>> but I have a few more comments:
>>>>
>>>> a) Both onExist and onProcessExit are implemented to unconditionally
>>>> throw UOE. Is the intention to make the implementation of these
>>>> methods optional? If so, then UOE should be documented, If not,
>>>> then I think they can be abstract, right?
>>>>
>>>> b) The wording in the spec talks about async functions and actions.
>>>> I think this may be not quite right. The intention is to support, as is
>>>> provided by CF, the ability to chain both sync and async tasks.
>>>> [ I suggested some wording in the webrev ]
>>>>
>>>> c) Why the need for ISE if the process is the current process, and not
>>>> just return a CF that never completes? Do you consider this an
>>>> error situation that you want to notify, or consistency with other
>>>> parts of the API ?
>>>>
>>>> d) I wonder if onProcessExit should have a small API note, saying
>>>> that it is preferred over onExit, when you have a Process. Or
>>>> something to promote its use over onExit, or briefly explain its
>>>> existence. ( I know why it is there, but it may appear as duplication )
>>>>
>>>> e) Maybe onProcessExit would benefit from an apiNote to indicate
>>>> that it is essentially an alternative to waitFor() ?
>>>>
>>>> 3) Should ProcessHandle.getPid declare that it can throw IOE?
>>>> Process.getPid declares UOE.
>>>>
>>>> 4) ProcessHandle.Info.user() ? owner() seems more appropriate, no?
>>>>
>>>> 5) The description of info() talks about fields, when it is an
>>>> interface.
>>>> I added some suggested rewording. Also, all methods now return
>>>> references, so -1 can be removed. Similar for the Info class
>>>> description.
>>>>
>>>> 6) There are a couple of @since 1.9 tags missing from Process
>>>> supportsDestroyForcibly and onProcessExit
>>>>
>>>> That?s all for now.
>>>>
>>>> -Chris.
>>>>
>>>>
>>>>
>


From paul.sandoz at oracle.com  Mon Mar  9 15:10:13 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 9 Mar 2015 16:10:13 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54F9F701.90501@redhat.com>
References: <54EB6DD1.4090803@redhat.com>
	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>
	<54EDFBA3.6080609@redhat.com> <54F4BA63.5060506@redhat.com>
	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>
	<54F716BD.2030706@redhat.com>
	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>
	<54F7263A.7040902@redhat.com>
	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>
	<54F76937.2040203@redhat.com> <54F7AAD6.8040206@oracle.com>
	<54F817B9.8090500@redhat.com>
	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>
	<54F9F701.90501@redhat.com>
Message-ID: <A7C18995-E9E5-4CCE-927F-46326ED1B563@oracle.com>


On Mar 6, 2015, at 7:50 PM, Andrew Haley <aph at redhat.com> wrote:

> I've tried to so everything I've been asked.  If this version passes
> muster with everyone I'll Javadoc all the public methods and fields
> and put it up for RFA next week.
> 

Do you want to tackle the single-address access methods as a follow up issue? If so that's fine.


> I guess it's going to need a lot of testing and security analysis.
> 

Not sure about the latter, but the former yes, i can help with that and sponsor if you like.


> I added versions of all {put,get} methods with the boolean bigEndian
> argument.  This makes HeapByteBuffer much cleaner, and it does not
> need to know the machine endianness at all.  I hope that's OK.
> 

Yes, i like the end result in HeapByteBuffer.

Paul.

> Andrew.
> 
> 
> http://cr.openjdk.java.net/~aph/unaligned.hotspot.4/
> http://cr.openjdk.java.net/~aph/unaligned.jdk.4/



From aph at redhat.com  Mon Mar  9 16:04:05 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 09 Mar 2015 16:04:05 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <A7C18995-E9E5-4CCE-927F-46326ED1B563@oracle.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>
	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>	<54F76937.2040203@redhat.com>
	<54F7AAD6.8040206@oracle.com>	<54F817B9.8090500@redhat.com>	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>	<54F9F701.90501@redhat.com>
	<A7C18995-E9E5-4CCE-927F-46326ED1B563@oracle.com>
Message-ID: <54FDC475.5030602@redhat.com>

On 03/09/2015 03:10 PM, Paul Sandoz wrote:
> Do you want to tackle the single-address access methods as a follow up issue?

It's not clear to me that we need any single-address access methods
because we can pass in a null object.  Personally I would prefer that.
Thoughts?

Andrew.



From martinrb at google.com  Mon Mar  9 16:21:10 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 9 Mar 2015 09:21:10 -0700
Subject: RFR: JDK-8074578 Document memory visibility effects of some
	Unsafe methods
In-Reply-To: <54FD8059.9050205@oracle.com>
References: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>
	<54FCEA87.3030509@oracle.com> <54FD6767.8020506@redhat.com>
	<54FD8059.9050205@oracle.com>
Message-ID: <CA+kOe0-NSsfYwDE6xzquWAe9OVhx389tX27vo5_DUpUSdTEpeQ@mail.gmail.com>

On Mon, Mar 9, 2015 at 4:13 AM, David Holmes <david.holmes at oracle.com>
wrote:

> On 9/03/2015 7:27 PM, Andrew Haley wrote:
>
>>
>> But who is to say that is the specification for the Unsafe API?


It's for us to say!


> The public API's have a specification for what they provide to the
> programmer. On what basis are we assigning that same specification to
> Unsafe API? The Unsafe API has to meet the requirements of the public APIs
> that use it, but that doesn't  mean it necessarily should have the same
> specification as those APIs.
>

We already have lots of code that implicitly depends on volatile read/write
visibility, especially in j.u.c.
Most obviously, how do you implement compareAndSet methods without the same
visibility guarantees on the Unsafe equivalents?
My spec change only documents what "everyone already knows to be true".
Another way of looking at it is that the Unsafe methods are a low-level
optimization of the equivalent j.u.c.a. objects without requiring memory
allocation.


From jason_mehrens at hotmail.com  Mon Mar  9 16:49:58 2015
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Mon, 9 Mar 2015 11:49:58 -0500
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54FDB188.1000602@oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>
	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>
	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>
	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>
	<54DDEFE0.7090108@gmail.com>
	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>
	<54DE1506.8020407@gmail.com>
	<54DE15BC.7040007@redhat.com>,<54DE1969.2040508@gmail.com>
	<54E393BC.4030600@Oracle.com>,
	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>
	<BLU175-W460A71BD3351510864D3E0831C0@phx.gbl>
	<54FD717C.1070500@oracle.com>
	<54FDAE15.8080606@Oracle.com>,<54FDB188.1000602@oracle.com>
Message-ID: <BLU175-W180FE85C6CA81825886349831B0@phx.gbl>

Anything but allowing UOE to escape compareTo sounds good.


Apologies if I missed this in previous threads but, shouldn't ProcessHandle.compareTo compare hostname, startInstant, and then pid?  Or assuming they are not comparable between hosts then just startInstant and pid.


Jason



----------------------------------------
> Date: Mon, 9 Mar 2015 14:43:20 +0000
> From: chris.hegarty at oracle.com
> To: Roger.Riggs at oracle.com; jason_mehrens at hotmail.com
> CC: core-libs-dev at openjdk.java.net
> Subject: Re: JEP 102 Process Updates revised API draft
>
> On 09/03/15 14:28, Roger Riggs wrote:
>> Hi,
>>
>> The problem could be isolated to compareTo by defining the ordering if
>> getPid
>> throws UOE and without diluting the spec for getPid returning the native
>> os process identifier.
>
> Yes, that would work.
>
>> Defining the default for getPid() to return -1, might not have too big
>> an impact.
>> It would order the incompletely implemented Process subtypes before the
>> real ones
>> but the order is not usually significant except to be able to have a
>> predictable iteration order
>> or use TreeMap. Returning Long.MAX_VALUE as the default might be another
>> option.
>
> That would probably be ok too, and then the UOE could be removed from
> Process.getPid() too, right? Which solves that small API wart.
>
> -Chris.
>
>> Roger
>>
>>
>>
>> On 3/9/2015 6:10 AM, Chris Hegarty wrote:
>>> On 06/03/15 19:34, Jason Mehrens wrote:
>>>> Hi Chris,
>>>
>>>>
>>>> Since getPid can throw UOE that means that compareTo could now throw
>>>> UOE.
>>>
>>> Ooh... I don't like this.
>>>
>>> Has any consideration been given to getPid returning -1, if unknown or
>>> the default implementation? Or would this be any better?
>>>
>>> -Chris
>>>
>>>>
>>>>
>>>>
>>>> Jason
>>>>
>>>>
>>>> ----------------------------------------
>>>>> Subject: Re: JEP 102 Process Updates revised API draft
>>>>> From: chris.hegarty at oracle.com
>>>>> Date: Fri, 6 Mar 2015 11:59:28 +0000
>>>>> To: Roger.Riggs at oracle.com
>>>>> CC: core-libs-dev at openjdk.java.net
>>>>>
>>>>> Roger,
>>>>>
>>>>> I?ve taken a look at these changes in the sandbox (
>>>>> JDK-8046092-branch ). Overall I welcome this addition.
>>>>>
>>>>> Some comments, most of which I stuffed into a webrev based on your
>>>>> branch,
>>>>> http://cr.openjdk.java.net/~chegar/process_comments/webrev/
>>>>>
>>>>> 1) ProcessHandle.compareTo() can drop the ClassCastException
>>>>> Also, I think the comparison is the wrong way around. It should
>>>>> be compare(this, other), rather than compare(other, this), right?
>>>>>
>>>>> 2) I know there has been a lot of discussion about the use of CF,
>>>>> but I have a few more comments:
>>>>>
>>>>> a) Both onExist and onProcessExit are implemented to unconditionally
>>>>> throw UOE. Is the intention to make the implementation of these
>>>>> methods optional? If so, then UOE should be documented, If not,
>>>>> then I think they can be abstract, right?
>>>>>
>>>>> b) The wording in the spec talks about async functions and actions.
>>>>> I think this may be not quite right. The intention is to support, as is
>>>>> provided by CF, the ability to chain both sync and async tasks.
>>>>> [ I suggested some wording in the webrev ]
>>>>>
>>>>> c) Why the need for ISE if the process is the current process, and not
>>>>> just return a CF that never completes? Do you consider this an
>>>>> error situation that you want to notify, or consistency with other
>>>>> parts of the API ?
>>>>>
>>>>> d) I wonder if onProcessExit should have a small API note, saying
>>>>> that it is preferred over onExit, when you have a Process. Or
>>>>> something to promote its use over onExit, or briefly explain its
>>>>> existence. ( I know why it is there, but it may appear as duplication )
>>>>>
>>>>> e) Maybe onProcessExit would benefit from an apiNote to indicate
>>>>> that it is essentially an alternative to waitFor() ?
>>>>>
>>>>> 3) Should ProcessHandle.getPid declare that it can throw IOE?
>>>>> Process.getPid declares UOE.
>>>>>
>>>>> 4) ProcessHandle.Info.user() ? owner() seems more appropriate, no?
>>>>>
>>>>> 5) The description of info() talks about fields, when it is an
>>>>> interface.
>>>>> I added some suggested rewording. Also, all methods now return
>>>>> references, so -1 can be removed. Similar for the Info class
>>>>> description.
>>>>>
>>>>> 6) There are a couple of @since 1.9 tags missing from Process
>>>>> supportsDestroyForcibly and onProcessExit
>>>>>
>>>>> That?s all for now.
>>>>>
>>>>> -Chris.
>>>>>
>>>>>
>>>>>
>> 		 	   		  

From paul.sandoz at oracle.com  Mon Mar  9 16:59:37 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 9 Mar 2015 17:59:37 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FDC475.5030602@redhat.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>
	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>	<54F76937.2040203@redhat.com>
	<54F7AAD6.8040206@oracle.com>	<54F817B9.8090500@redhat.com>	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>	<54F9F701.90501@redhat.com>
	<A7C18995-E9E5-4CCE-927F-46326ED1B563@oracle.com>
	<54FDC475.5030602@redhat.com>
Message-ID: <587883F5-1CCE-41CB-AE3A-444A31FC2A4A@oracle.com>


On Mar 9, 2015, at 5:04 PM, Andrew Haley <aph at redhat.com> wrote:

> On 03/09/2015 03:10 PM, Paul Sandoz wrote:
>> Do you want to tackle the single-address access methods as a follow up issue?
> 
> It's not clear to me that we need any single-address access methods
> because we can pass in a null object.  Personally I would prefer that.
> Thoughts?
> 

I agree that would be desirable. 

I know that people rely on that behaviour for off-heap CAS etc, but i was wondering about such behaviour given that the base and offset should, as documented, be derived from an object/staticFieldBase and objectFieldOffset/staticFieldOffset respectfully. Are there subtle differences? I looked at the C2 code and it seems the results might be equivalent but i cannot say the same for C1 from quickly eyeballing the code.

e.g. LibraryCallKit::inline_unsafe_access:

if (!is_native_ptr) {
  // The base is either a Java object or a value produced by Unsafe.staticFieldBase
  Node* base = argument(1);  // type: oop
  // The offset is a value produced by Unsafe.staticFieldOffset or Unsafe.objectFieldOffset
  offset = argument(2);  // type: long
  // We currently rely on the cookies produced by Unsafe.xxxFieldOffset
  // to be plain byte offsets, which are also the same as those accepted
  // by oopDesc::field_base.
  assert(Unsafe_field_offset_to_byte_offset(11) == 11,
         "fieldOffset must be byte-scaled");       <----- weird assertion
  // 32-bit machines ignore the high half!
  offset = ConvL2X(offset);
  adr = make_unsafe_address(base, offset);
  heap_base_oop = base;
  val = is_store ? argument(4) : NULL;
} else {
  Node* ptr = argument(1);  // type: long
  ptr = ConvL2X(ptr);  // adjust Java long to machine word
  adr = make_unsafe_address(NULL, ptr);
  val = is_store ? argument(3) : NULL;
}

Paul.



From aph at redhat.com  Mon Mar  9 17:09:53 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 09 Mar 2015 17:09:53 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <587883F5-1CCE-41CB-AE3A-444A31FC2A4A@oracle.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>	<54F76937.2040203@redhat.com>	<54F7AAD6.8040206@oracle.com>	<54F817B9.8090500@redhat.com>	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>	<54F9F701.90501@redhat.com>	<A7C18995-E9E5-4CCE-927F-46326ED1B563@oracle.com>	<54FDC475.5030602@redhat.com>
	<587883F5-1CCE-41CB-AE3A-444A31FC2A4A@oracle.com>
Message-ID: <54FDD3E1.8030100@redhat.com>

On 03/09/2015 04:59 PM, Paul Sandoz wrote:
> 
> On Mar 9, 2015, at 5:04 PM, Andrew Haley <aph at redhat.com> wrote:
> 
>> On 03/09/2015 03:10 PM, Paul Sandoz wrote:
>>> Do you want to tackle the single-address access methods as a follow up issue?
>>
>> It's not clear to me that we need any single-address access methods
>> because we can pass in a null object.  Personally I would prefer that.
>> Thoughts?
>>
> 
> I agree that would be desirable. 
> 
> I know that people rely on that behaviour for off-heap CAS etc, but
> i was wondering about such behaviour given that the base and offset
> should, as documented, be derived from an object/staticFieldBase and
> objectFieldOffset/staticFieldOffset respectfully.

The doc for Unsafe.getInt() says:

  public int getInt(java.lang.Object o,
                    long offset)

  Fetches a value from a given Java variable. More specifically, fetches
  a field or array element within the given object o at the given
  offset, or (if o is null) from the memory address whose numerical
  value is the given offset.

Therefore it seems to me that passing in a null object to the
unaligned methods would be entirely legitimate and in keeping with the
rest of Unsafe.

> Are there subtle differences? I looked at the C2 code and it seems
> the results might be equivalent but i cannot say the same for C1
> from quickly eyeballing the code.
> 
> e.g. LibraryCallKit::inline_unsafe_access:
> 
> if (!is_native_ptr) {
>   // The base is either a Java object or a value produced by Unsafe.staticFieldBase
>   Node* base = argument(1);  // type: oop
>   // The offset is a value produced by Unsafe.staticFieldOffset or Unsafe.objectFieldOffset
>   offset = argument(2);  // type: long
>   // We currently rely on the cookies produced by Unsafe.xxxFieldOffset
>   // to be plain byte offsets, which are also the same as those accepted
>   // by oopDesc::field_base.
>   assert(Unsafe_field_offset_to_byte_offset(11) == 11,
>          "fieldOffset must be byte-scaled");       <----- weird assertion

Indeed it is.  There was in the past some weirdness to do with offset
being a kind of opaque handle rather than guaranteed to be a byte
offset; I guess that's what this assert is thinking of.

Andrew.


From joe.darcy at oracle.com  Mon Mar  9 17:29:54 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 09 Mar 2015 10:29:54 -0700
Subject: JDK 9 RFR of JDK-8074674: Doclint regression in
	java/util/regex/Matcher.java
In-Reply-To: <9A40EE4F-8DD5-4EA5-823E-62B8C20857A0@oracle.com>
References: <54FD5CA6.1020203@oracle.com>
	<9A40EE4F-8DD5-4EA5-823E-62B8C20857A0@oracle.com>
Message-ID: <54FDD892.4000803@oracle.com>

On 3/9/2015 4:36 AM, Paul Sandoz wrote:
> On Mar 9, 2015, at 9:41 AM, Amy Lu <amy.lu at oracle.com> wrote:
>
>> Please review the fix for Doclint regression in java/util/regex/Matcher.java:
>>
>>     error: bad use of '>'
>>
>> from
>>     * <tt>mr -> mr.group().toUpperCase()</tt>, an invocation of this method on
>>
>> This fixed by using @code tag
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8074674
>> webrev: http://cr.openjdk.java.net/~amlu/8074674/webrev.00/
>>
>> I also need a sponsor for this fix.
>>
> Ooops that was my fault, sorry.
>
> +1
>
> I did perform a "make docs" locally and did not observe any errors/warnings in the output, was that because i missed them or because the doclint is run as a separate process?

Doclint is currently run separately; however, when the rest of JEP 212 
is done (http://openjdk.java.net/jeps/212) doclint checks will be run as 
part of the main source build in javac.

-Joe


From joe.darcy at oracle.com  Mon Mar  9 17:56:25 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 09 Mar 2015 10:56:25 -0700
Subject: JDK 9 RFR of JDK-8074714 : Add javax/xml/jaxp/testng/validation to
	othervm.dirs in TEST.ROOT
Message-ID: <54FDDEC9.5010401@oracle.com>

Hello,

In some internal test runs, we're seeing intermittent test failures of 
the  javax/xml/jaxp/testng/validation tests when run in jtreg with high 
concurrency. While some underlying issues are investigated, I'd like to 
add the javax/xml/jaxp/testng/validation directory to the list of 
directories excluded from concurrent runs.

Patch below.

Thanks,

-Joe

--- a/test/TEST.ROOT    Mon Mar 09 16:18:33 2015 +0100
+++ b/test/TEST.ROOT    Mon Mar 09 10:52:27 2015 -0700
@@ -8,7 +8,7 @@
  othervm.dirs=java/awt java/beans javax/accessibility javax/imageio 
javax/sound javax/print javax/management com/sun/awt sun/awt sun/java2d 
sun/pisces

  # Tests that cannot run concurrently
-exclusiveAccess.dirs=java/rmi/Naming java/util/prefs 
sun/management/jmxremote sun/tools/jstatd sun/security/mscapi 
java/util/stream
+exclusiveAccess.dirs=java/rmi/Naming java/util/prefs 
sun/management/jmxremote sun/tools/jstatd sun/security/mscapi 
java/util/stream javax/xml/jaxp/testng/validation

  # Group definitions
  groups=TEST.groups [closed/TEST.groups]



From Lance.Andersen at oracle.com  Mon Mar  9 17:57:58 2015
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Mon, 9 Mar 2015 13:57:58 -0400
Subject: JDK 9 RFR of JDK-8074714 : Add javax/xml/jaxp/testng/validation
	to othervm.dirs in TEST.ROOT
In-Reply-To: <54FDDEC9.5010401@oracle.com>
References: <54FDDEC9.5010401@oracle.com>
Message-ID: <A008A6F3-CFBA-4766-8264-C41B29C4FD30@oracle.com>

Works for me till we figure it out
On Mar 9, 2015, at 1:56 PM, joe darcy <joe.darcy at oracle.com> wrote:

> Hello,
> 
> In some internal test runs, we're seeing intermittent test failures of the  javax/xml/jaxp/testng/validation tests when run in jtreg with high concurrency. While some underlying issues are investigated, I'd like to add the javax/xml/jaxp/testng/validation directory to the list of directories excluded from concurrent runs.
> 
> Patch below.
> 
> Thanks,
> 
> -Joe
> 
> --- a/test/TEST.ROOT    Mon Mar 09 16:18:33 2015 +0100
> +++ b/test/TEST.ROOT    Mon Mar 09 10:52:27 2015 -0700
> @@ -8,7 +8,7 @@
> othervm.dirs=java/awt java/beans javax/accessibility javax/imageio javax/sound javax/print javax/management com/sun/awt sun/awt sun/java2d sun/pisces
> 
> # Tests that cannot run concurrently
> -exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd sun/security/mscapi java/util/stream
> +exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd sun/security/mscapi java/util/stream javax/xml/jaxp/testng/validation
> 
> # Group definitions
> groups=TEST.groups [closed/TEST.groups]
> 




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 paul.sandoz at oracle.com  Mon Mar  9 17:46:47 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 9 Mar 2015 18:46:47 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54FDD3E1.8030100@redhat.com>
References: <54EB6DD1.4090803@redhat.com>	<D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>	<54EDFBA3.6080609@redhat.com>	<54F4BA63.5060506@redhat.com>	<7C6071BF-7C4E-4062-8F39-DBFC613E7DD1@oracle.com>	<54F716BD.2030706@redhat.com>	<486270A2-F83F-4406-9A43-FD33283FFD7F@oracle.com>	<54F7263A.7040902@redhat.com>	<C9D533DC-CC33-4F57-9C28-684542703D64@oracle.com>	<54F76937.2040203@redhat.com>	<54F7AAD6.8040206@oracle.com>	<54F817B9.8090500@redhat.com>	<DB86E701-5882-4EBC-85A2-C12B3D13A864@oracle.com>	<54F9F701.90501@redhat.com>	<A7C18995-E9E5-4CCE-927F-46326ED1B563@oracle.com>	<54FDC475.5030602@redhat.com>
	<587883F5-1CCE-41CB-AE3A-444A31FC2A4A@oracle.com>
	<54FDD3E1.8030100@redhat.com>
Message-ID: <D922C63F-ADBA-4E5A-87F2-42B3389DDD17@oracle.com>


On Mar 9, 2015, at 6:09 PM, Andrew Haley <aph at redhat.com> wrote:

> On 03/09/2015 04:59 PM, Paul Sandoz wrote:
>> 
>> On Mar 9, 2015, at 5:04 PM, Andrew Haley <aph at redhat.com> wrote:
>> 
>>> On 03/09/2015 03:10 PM, Paul Sandoz wrote:
>>>> Do you want to tackle the single-address access methods as a follow up issue?
>>> 
>>> It's not clear to me that we need any single-address access methods
>>> because we can pass in a null object.  Personally I would prefer that.
>>> Thoughts?
>>> 
>> 
>> I agree that would be desirable. 
>> 
>> I know that people rely on that behaviour for off-heap CAS etc, but
>> i was wondering about such behaviour given that the base and offset
>> should, as documented, be derived from an object/staticFieldBase and
>> objectFieldOffset/staticFieldOffset respectfully.
> 
> The doc for Unsafe.getInt() says:
> 
>  public int getInt(java.lang.Object o,
>                    long offset)
> 
>  Fetches a value from a given Java variable. More specifically, fetches
>  a field or array element within the given object o at the given
>  offset, or (if o is null) from the memory address whose numerical
>  value is the given offset.
> 
> Therefore it seems to me that passing in a null object to the
> unaligned methods would be entirely legitimate and in keeping with the
> rest of Unsafe.
> 

But after that there is also:

* The results are undefined unless one of the following cases is true:
...
* If one of the above cases is true, the call references a specific Java
* variable (field or array element).  However, the results are undefined
* if that variable is not in fact of the type returned by this method.

Perhaps we just need to clear up some inconsistencies in the docs, it's hard to see how this would be undefined for the primitive values.


>> Are there subtle differences? I looked at the C2 code and it seems
>> the results might be equivalent but i cannot say the same for C1
>> from quickly eyeballing the code.
>> 
>> e.g. LibraryCallKit::inline_unsafe_access:
>> 
>> if (!is_native_ptr) {
>>  // The base is either a Java object or a value produced by Unsafe.staticFieldBase
>>  Node* base = argument(1);  // type: oop
>>  // The offset is a value produced by Unsafe.staticFieldOffset or Unsafe.objectFieldOffset
>>  offset = argument(2);  // type: long
>>  // We currently rely on the cookies produced by Unsafe.xxxFieldOffset
>>  // to be plain byte offsets, which are also the same as those accepted
>>  // by oopDesc::field_base.
>>  assert(Unsafe_field_offset_to_byte_offset(11) == 11,
>>         "fieldOffset must be byte-scaled");       <----- weird assertion
> 
> Indeed it is.  There was in the past some weirdness to do with offset
> being a kind of opaque handle rather than guaranteed to be a byte
> offset; I guess that's what this assert is thinking of.
> 

So perhaps i can remove that assert and Unsafe_field_offset_to_byte_offset (i conservatively left them in there in the previous clean up because there is usage in the shark vm code i could not work out was important or not)

Paul.



From Roger.Riggs at Oracle.com  Mon Mar  9 18:46:25 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 09 Mar 2015 14:46:25 -0400
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <BLU175-W180FE85C6CA81825886349831B0@phx.gbl>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>,
	<54DE1969.2040508@gmail.com> <54E393BC.4030600@Oracle.com>,
	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>
	<BLU175-W460A71BD3351510864D3E0831C0@phx.gbl>
	<54FD717C.1070500@oracle.com> <54FDAE15.8080606@Oracle.com>,
	<54FDB188.1000602@oracle.com>
	<BLU175-W180FE85C6CA81825886349831B0@phx.gbl>
Message-ID: <54FDEA81.70206@Oracle.com>

Hi Jason,

Comparing with startInstant is a possibility, assuming it is cached in 
the ProcessHandle
and increases the cost of creating ProcessHandles since it needs to be 
parsed from /proc files.
And it can help a long standing potential issue of pid's being re-used.
ProcessHandle is only within a single host; there is no cross host 
invocation mechanism.

Roger


On 3/9/2015 12:49 PM, Jason Mehrens wrote:
> Anything but allowing UOE to escape compareTo sounds good.
>
>
> Apologies if I missed this in previous threads but, shouldn't ProcessHandle.compareTo compare hostname, startInstant, and then pid?  Or assuming they are not comparable between hosts then just startInstant and pid.
>
>
> Jason
>
>
>
> ----------------------------------------
>> Date: Mon, 9 Mar 2015 14:43:20 +0000
>> From: chris.hegarty at oracle.com
>> To: Roger.Riggs at oracle.com; jason_mehrens at hotmail.com
>> CC: core-libs-dev at openjdk.java.net
>> Subject: Re: JEP 102 Process Updates revised API draft
>>
>> On 09/03/15 14:28, Roger Riggs wrote:
>>> Hi,
>>>
>>> The problem could be isolated to compareTo by defining the ordering if
>>> getPid
>>> throws UOE and without diluting the spec for getPid returning the native
>>> os process identifier.
>> Yes, that would work.
>>
>>> Defining the default for getPid() to return -1, might not have too big
>>> an impact.
>>> It would order the incompletely implemented Process subtypes before the
>>> real ones
>>> but the order is not usually significant except to be able to have a
>>> predictable iteration order
>>> or use TreeMap. Returning Long.MAX_VALUE as the default might be another
>>> option.
>> That would probably be ok too, and then the UOE could be removed from
>> Process.getPid() too, right? Which solves that small API wart.
>>
>> -Chris.
>>
>>> Roger
>>>
>>>
>>>
>>> On 3/9/2015 6:10 AM, Chris Hegarty wrote:
>>>> On 06/03/15 19:34, Jason Mehrens wrote:
>>>>> Hi Chris,
>>>>> Since getPid can throw UOE that means that compareTo could now throw
>>>>> UOE.
>>>> Ooh... I don't like this.
>>>>
>>>> Has any consideration been given to getPid returning -1, if unknown or
>>>> the default implementation? Or would this be any better?
>>>>
>>>> -Chris
>>>>
>>>>>
>>>>>
>>>>> Jason
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> Subject: Re: JEP 102 Process Updates revised API draft
>>>>>> From: chris.hegarty at oracle.com
>>>>>> Date: Fri, 6 Mar 2015 11:59:28 +0000
>>>>>> To: Roger.Riggs at oracle.com
>>>>>> CC: core-libs-dev at openjdk.java.net
>>>>>>
>>>>>> Roger,
>>>>>>
>>>>>> I?ve taken a look at these changes in the sandbox (
>>>>>> JDK-8046092-branch ). Overall I welcome this addition.
>>>>>>
>>>>>> Some comments, most of which I stuffed into a webrev based on your
>>>>>> branch,
>>>>>> http://cr.openjdk.java.net/~chegar/process_comments/webrev/
>>>>>>
>>>>>> 1) ProcessHandle.compareTo() can drop the ClassCastException
>>>>>> Also, I think the comparison is the wrong way around. It should
>>>>>> be compare(this, other), rather than compare(other, this), right?
>>>>>>
>>>>>> 2) I know there has been a lot of discussion about the use of CF,
>>>>>> but I have a few more comments:
>>>>>>
>>>>>> a) Both onExist and onProcessExit are implemented to unconditionally
>>>>>> throw UOE. Is the intention to make the implementation of these
>>>>>> methods optional? If so, then UOE should be documented, If not,
>>>>>> then I think they can be abstract, right?
>>>>>>
>>>>>> b) The wording in the spec talks about async functions and actions.
>>>>>> I think this may be not quite right. The intention is to support, as is
>>>>>> provided by CF, the ability to chain both sync and async tasks.
>>>>>> [ I suggested some wording in the webrev ]
>>>>>>
>>>>>> c) Why the need for ISE if the process is the current process, and not
>>>>>> just return a CF that never completes? Do you consider this an
>>>>>> error situation that you want to notify, or consistency with other
>>>>>> parts of the API ?
>>>>>>
>>>>>> d) I wonder if onProcessExit should have a small API note, saying
>>>>>> that it is preferred over onExit, when you have a Process. Or
>>>>>> something to promote its use over onExit, or briefly explain its
>>>>>> existence. ( I know why it is there, but it may appear as duplication )
>>>>>>
>>>>>> e) Maybe onProcessExit would benefit from an apiNote to indicate
>>>>>> that it is essentially an alternative to waitFor() ?
>>>>>>
>>>>>> 3) Should ProcessHandle.getPid declare that it can throw IOE?
>>>>>> Process.getPid declares UOE.
>>>>>>
>>>>>> 4) ProcessHandle.Info.user() ? owner() seems more appropriate, no?
>>>>>>
>>>>>> 5) The description of info() talks about fields, when it is an
>>>>>> interface.
>>>>>> I added some suggested rewording. Also, all methods now return
>>>>>> references, so -1 can be removed. Similar for the Info class
>>>>>> description.
>>>>>>
>>>>>> 6) There are a couple of @since 1.9 tags missing from Process
>>>>>> supportsDestroyForcibly and onProcessExit
>>>>>>
>>>>>> That?s all for now.
>>>>>>
>>>>>> -Chris.
>>>>>>
>>>>>>
>>>>>>
>>> 		 	   		



From Roger.Riggs at Oracle.com  Mon Mar  9 19:47:26 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 09 Mar 2015 15:47:26 -0400
Subject: RFR 9   8058464 (process spec) ProcessBuilder.redirectXXX throws
	unspecified NPE
Message-ID: <54FDF8CE.6040609@Oracle.com>

Please review this update to specify that ProcessBuilder methods throw 
NullPointerException
when arguments are null.  The implementation behavior is unchanged and 
correct
but the specification of NPE is missing for methods redirectInput, 
redirectOutput, and redirectError.

The choice of a single class javadoc statement applies to all methods 
and @throws clauses
on individual methods are redundant.

Webrev:
     http://cr.openjdk.java.net/~rriggs/webrev-npe-8058464/

Issue:
    8058464 (process spec) ProcessBuilder.redirectXXX throws unspecified 
NPE <https://bugs.openjdk.java.net/browse/JDK-8058464>

Roger



From martinrb at google.com  Mon Mar  9 19:52:45 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 9 Mar 2015 12:52:45 -0700
Subject: RFR 9 8058464 (process spec) ProcessBuilder.redirectXXX throws
	unspecified NPE
In-Reply-To: <54FDF8CE.6040609@Oracle.com>
References: <54FDF8CE.6040609@Oracle.com>
Message-ID: <CA+kOe08+4U2Pev9qSpUzGw7NEuRO-buCZ76LL78W1ziUYAibmA@mail.gmail.com>

Seems alright.

On Mon, Mar 9, 2015 at 12:47 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Please review this update to specify that ProcessBuilder methods throw
> NullPointerException
> when arguments are null.  The implementation behavior is unchanged and
> correct
> but the specification of NPE is missing for methods redirectInput,
> redirectOutput, and redirectError.
>
> The choice of a single class javadoc statement applies to all methods and
> @throws clauses
> on individual methods are redundant.
>
> Webrev:
>     http://cr.openjdk.java.net/~rriggs/webrev-npe-8058464/
>
> Issue:
>    8058464 (process spec) ProcessBuilder.redirectXXX throws unspecified
> NPE <https://bugs.openjdk.java.net/browse/JDK-8058464>
>
> Roger
>
>


From martinrb at google.com  Mon Mar  9 20:14:45 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 9 Mar 2015 13:14:45 -0700
Subject: RFR: JDK-8074579 Use more efficient and readable way of checking
	PKZIP signatures
In-Reply-To: <CA+kOe0_oZ0cagWuaLAGCp=Z5DV6fj2bLJBgO9f306yCGxoPaTQ@mail.gmail.com>
References: <CA+kOe08YtJNffw633_K54vqWYvv6+XwZTELfjc-aqFZ7GaDOfg@mail.gmail.com>
	<54FA1E20.9000301@oracle.com>
	<CA+kOe0-p7Qvjynw1G-QYqJO3a62AVMUJ53qNaWKm7_9JvNYDkA@mail.gmail.com>
	<CA+kOe0_oZ0cagWuaLAGCp=Z5DV6fj2bLJBgO9f306yCGxoPaTQ@mail.gmail.com>
Message-ID: <CA+kOe09r0ro-n0Yh-G+AiEgQ1SmoQ3OiSoWXdww0G5bneUSBkQ@mail.gmail.com>

I actually benchmarked my last suggestion to be 20% faster on an ad-hoc
microbenchmark.  We can go faster yet on x86 if we use unaligned 4-byte
uint32 reads.  Maybe in a future change.

In general, hardware is moving in the direction of allowing unaligned reads
without performance penalty, especially on x86, and it would be good to
start taking advantage of that.

On Fri, Mar 6, 2015 at 9:50 PM, Martin Buchholz <martinrb at google.com> wrote:

> Err...
>
> #define PKZIP_SIGNATURE_AT(p, b2, b3) \
>   (((p)[0] == 'P') & ((p)[1] == 'K') & ((p)[2] == b2) & ((p)[3] == b3))
>
>


From martinrb at google.com  Mon Mar  9 20:30:26 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 9 Mar 2015 13:30:26 -0700
Subject: [concurrency-interest] Why not "weakNanoTime" for jdk9?
In-Reply-To: <NFBBKALFDCPFIDBNKAPCAECKKOAA.davidcholmes@aapt.net.au>
References: <0FD072A166C6DC4C851F6115F37DDD279AEED75A@sm-ex-01-vm.guidewire.com>
	<NFBBKALFDCPFIDBNKAPCAECKKOAA.davidcholmes@aapt.net.au>
Message-ID: <CA+kOe0_osR6ax9DsU4BbH7w4yVdQAi-nw3JikKFY4L3Nz2vaQA@mail.gmail.com>

Perhaps I shouldn't have tried to do anything on this front, given the
cross-system difficulties that especially David has battled for years.  I'm
surprised Aleksey is not a fan - I expected Aleksey to want a version of
nanoTime more suitable for benchmarking.

I learned about the various "clocks" on linux/posix.  I'm surprised the
low-level CLOCKs also promise monotonicity (CLOCK_MONOTONIC).  Perhaps what
was really originally intended was that CLOCK_MONOTONIC was immune to the
effects of sysadmin action (and also adjustments by NTP would be gradual
and preserve monotonicity).

Anyways, having a version of nanoTime that does not promise monotonicity is
only useful if there is a significant benefit, probably in reduced overhead.

No consensus - giving up.


From Alan.Bateman at oracle.com  Mon Mar  9 20:54:23 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 09 Mar 2015 20:54:23 +0000
Subject: RFR 9 8058464 (process spec) ProcessBuilder.redirectXXX throws
	unspecified NPE
In-Reply-To: <54FDF8CE.6040609@Oracle.com>
References: <54FDF8CE.6040609@Oracle.com>
Message-ID: <54FE087F.3010608@oracle.com>

On 09/03/2015 19:47, Roger Riggs wrote:
> Please review this update to specify that ProcessBuilder methods throw 
> NullPointerException
> when arguments are null.  The implementation behavior is unchanged and 
> correct
> but the specification of NPE is missing for methods redirectInput, 
> redirectOutput, and redirectError.
>
> The choice of a single class javadoc statement applies to all methods 
> and @throws clauses
> on individual methods are redundant.
>
> Webrev:
>     http://cr.openjdk.java.net/~rriggs/webrev-npe-8058464/
Looks good to me.

-Alan


From huizhe.wang at oracle.com  Mon Mar  9 20:55:34 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 09 Mar 2015 13:55:34 -0700
Subject: JAXP repo warnings fixed
In-Reply-To: <54F69382.6040102@oracle.com>
References: <CACYLA9HOwJruWEq2w2w6NsACCF1MkU0MSUUwVp5JAWJUz4S1fg@mail.gmail.com>	<54F4FAC7.9050208@oracle.com>
	<CACYLA9F99YFjGHcsxJ-edTnH0k28BE8kMyitJuj=ogx57mYMog@mail.gmail.com>
	<54F66C3A.9000701@oracle.com> <54F69382.6040102@oracle.com>
Message-ID: <54FE08C6.1000702@oracle.com>

Hi Ivan,

I really appreciate you and others for proactively contributing to the 
jaxp code.  Unfortunately, I have to say sorry that it may be not 
feasible to apply this patch. The reason is that the patch covers just 
the BCEL component, but the upstream source had been updated already. 
The proper way to fix these warnings is therefore getting the updates 
from the upstream source.

As described here http://openjdk.java.net/contribute/, it would be nice 
if you could discuss your intended change within the alias before 
investing significant time working on it (I saw that you did list three 
bugs that you intended to work on).

Thanks,
Joe

On 3/3/2015 9:09 PM, huizhe wang wrote:
>
> On 3/3/2015 6:21 PM, Joseph D. Darcy wrote:
>> Hi Ivan,
>>
>> I've skimmed over the patch and didn't see anything technically 
>> amiss. However, I believe at least some of the changes, such as 
>> adding @Deprecated and the generification updates will need to go 
>> through an internal review process before they can be pushed.
>>
>> Joe Wang (cc'ed as huizhe.wang at oracle.com) is the jaxp lead and he 
>> will also need to review of the changes for jaxp-specific concerns.
>
> Just coming back from a two-week vacation, I have a lot of catch-ups 
> to do. Please allow me some time to get to this.
>
> Thanks,
> Joe
>
>>
>> Thanks,
>>
>> -Joe
>>
>> On 3/3/2015 10:06 AM, Ivan St. Ivanov wrote:
>>> Hi Joe,
>>>
>>> The links are correct, but our server was down for a while. It is 
>>> available now.
>>>
>>> Regards,
>>> Ivan
>>>
>>> On Tue, Mar 3, 2015 at 2:05 AM, Joseph D. Darcy 
>>> <joe.darcy at oracle.com <mailto:joe.darcy at oracle.com>> wrote:
>>>
>>>     Hello,
>>>
>>>     Sorry for the belated reply, I tried the URLs and some obvious
>>>     variations, but the webrevs didn't come up as being there.
>>>
>>>     Have they been moved?
>>>
>>>     Thanks,
>>>
>>>     -Joe
>>>
>>>     On 2/18/2015 12:17 PM, Ivan St. Ivanov wrote:
>>>
>>>         Hi Joe, core libs developers,
>>>
>>>         Last night we had a hackathon in Bulgarian Java User Group.
>>>         Its purpose was to work on fixing some compiler warnings in
>>>         OpenJDK. The day before the meeting we ran the following 
>>> command:
>>>
>>>         make clean
>>> JAVAC_WARNINGS="-Xlint:all,deprecation,rawtypes,unchecked,cast,serial,dep-ann,static,fallthrough,try,varargs,empty,finally
>>>         -Xmaxwarns 10000" DISABLE_WARNINGS="-Xlint:all" LOG=info images
>>>
>>>         After that, looking at the build.log, we identified the
>>>         following number of warnings per repo left to be fixed:
>>>
>>>         359 corba
>>>         100 jaxp
>>>         500 jaxws
>>>         0 nashorn
>>>
>>>         We decided to take the jaxp repository, where the situation
>>>         was the following:
>>>
>>>         rawtypes 43
>>>         unchecked 14
>>>         serial 32
>>>         cast 10
>>>         dep-ann 1
>>>
>>>         The latter three types were easy to fix. After we did them,
>>>         we created our first webrev for the night:
>>>
>>> http://bgjug.sty.bz/bgjug/~bgjug/fix-warnings-jaxp-part1/webrev.00/
>>> <http://bgjug.sty.bz/bgjug/%7Ebgjug/fix-warnings-jaxp-part1/webrev.00/>
>>> <http://bgjug.sty.bz/bgjug/%7Ebgjug/fix-warnings-jaxp-part1/webrev.00/>
>>>
>>>         Later we continued with rawtypes and unchecked. We didn't fix
>>>         them all, as some of the warnings concerned public method
>>>         parameters, which change might virtually break client code.
>>>         The good news here is that all these public methods belong to
>>>         classes located in 'internal' packages. Which we hope will
>>>         not be public any more once project Jigsaw meets java.xml
>>>         module :)
>>>
>>>         Anyway, this is the second webrev that we created:
>>>
>>> http://bgjug.sty.bz/bgjug/~bgjug/fix-warnings-jaxp-full/webrev.00/
>>> <http://bgjug.sty.bz/bgjug/%7Ebgjug/fix-warnings-jaxp-full/webrev.00/>
>>> <http://bgjug.sty.bz/bgjug/%7Ebgjug/fix-warnings-jaxp-full/webrev.00/>
>>>
>>>         As its name implies, it contains all the fixes that we did
>>>         last night.
>>>
>>>         We would be happy to get feedback from you and even happier
>>>         if this becomes our first contribution to OpenJDK as part of
>>>         our adoption efforts.
>>>
>>>         Regards,
>>>         Ivan, Bulgarian JUG
>>>
>>>
>>>
>>
>



From xueming.shen at oracle.com  Mon Mar  9 22:22:54 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 09 Mar 2015 15:22:54 -0700
Subject: RFR: JDK-8074579 Use more efficient and readable way of checking
	PKZIP signatures
In-Reply-To: <CA+kOe09r0ro-n0Yh-G+AiEgQ1SmoQ3OiSoWXdww0G5bneUSBkQ@mail.gmail.com>
References: <CA+kOe08YtJNffw633_K54vqWYvv6+XwZTELfjc-aqFZ7GaDOfg@mail.gmail.com>	<54FA1E20.9000301@oracle.com>	<CA+kOe0-p7Qvjynw1G-QYqJO3a62AVMUJ53qNaWKm7_9JvNYDkA@mail.gmail.com>	<CA+kOe0_oZ0cagWuaLAGCp=Z5DV6fj2bLJBgO9f306yCGxoPaTQ@mail.gmail.com>
	<CA+kOe09r0ro-n0Yh-G+AiEgQ1SmoQ3OiSoWXdww0G5bneUSBkQ@mail.gmail.com>
Message-ID: <54FE1D3E.7060905@oracle.com>

The result looks good, though I doubt it will bring in any real "meaningful" performance
improvement when reading a zip/jar file. But faster is faster. The same improvement might
not applied to the java version, given those range check?

-Sherman

On 03/09/2015 01:14 PM, Martin Buchholz wrote:
> I actually benchmarked my last suggestion to be 20% faster on an ad-hoc microbenchmark.  We can go faster yet on x86 if we use unaligned 4-byte uint32 reads.  Maybe in a future change.
>
> In general, hardware is moving in the direction of allowing unaligned reads without performance penalty, especially on x86, and it would be good to start taking advantage of that.
>
> On Fri, Mar 6, 2015 at 9:50 PM, Martin Buchholz <martinrb at google.com <mailto:martinrb at google.com>> wrote:
>
>     Err...
>
>     #define PKZIP_SIGNATURE_AT(p, b2, b3) \
>       (((p)[0] == 'P') & ((p)[1] == 'K') & ((p)[2] == b2) & ((p)[3] == b3))
>
>



From martinrb at google.com  Mon Mar  9 22:33:40 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 9 Mar 2015 15:33:40 -0700
Subject: RFR: JDK-8074579 Use more efficient and readable way of checking
	PKZIP signatures
In-Reply-To: <54FE1D3E.7060905@oracle.com>
References: <CA+kOe08YtJNffw633_K54vqWYvv6+XwZTELfjc-aqFZ7GaDOfg@mail.gmail.com>
	<54FA1E20.9000301@oracle.com>
	<CA+kOe0-p7Qvjynw1G-QYqJO3a62AVMUJ53qNaWKm7_9JvNYDkA@mail.gmail.com>
	<CA+kOe0_oZ0cagWuaLAGCp=Z5DV6fj2bLJBgO9f306yCGxoPaTQ@mail.gmail.com>
	<CA+kOe09r0ro-n0Yh-G+AiEgQ1SmoQ3OiSoWXdww0G5bneUSBkQ@mail.gmail.com>
	<54FE1D3E.7060905@oracle.com>
Message-ID: <CA+kOe0_o-Aj=R0oBwPq3XA2_FxEPcbm7CLh7sEtot5k=keS2Cg@mail.gmail.com>

On Mon, Mar 9, 2015 at 3:22 PM, Xueming Shen <xueming.shen at oracle.com>
wrote:

>  The result looks good, though I doubt it will bring in any real
> "meaningful" performance
> improvement when reading a zip/jar file. But faster is faster.
>

You're right - it will make a 20% improvement in something that is only a
small part of java startup.  But it's still worth it.


> The same improvement might
> not applied to the java version, given those range check?
>

I think a similar future change to ZipConstants and friends will also be
worth it.

Other jar/zip changes coming as well.


From david.holmes at oracle.com  Tue Mar 10 01:30:43 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Mar 2015 11:30:43 +1000
Subject: RFR: JDK-8074578 Document memory visibility effects of some Unsafe
	methods
In-Reply-To: <CA+kOe0-NSsfYwDE6xzquWAe9OVhx389tX27vo5_DUpUSdTEpeQ@mail.gmail.com>
References: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>	<54FCEA87.3030509@oracle.com>	<54FD6767.8020506@redhat.com>	<54FD8059.9050205@oracle.com>
	<CA+kOe0-NSsfYwDE6xzquWAe9OVhx389tX27vo5_DUpUSdTEpeQ@mail.gmail.com>
Message-ID: <54FE4943.1030008@oracle.com>

On 10/03/2015 2:21 AM, Martin Buchholz wrote:
> On Mon, Mar 9, 2015 at 4:13 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     On 9/03/2015 7:27 PM, Andrew Haley wrote:
>
>
>     But who is to say that is the specification for the Unsafe API?
>
>
> It's for us to say!

I meant specifically the choice of the specification, not the right to 
suggest one.

>     The public API's have a specification for what they provide to the
>     programmer. On what basis are we assigning that same specification
>     to Unsafe API? The Unsafe API has to meet the requirements of the
>     public APIs that use it, but that doesn't  mean it necessarily
>     should have the same specification as those APIs.
>
>
> We already have lots of code that implicitly depends on volatile
> read/write visibility, especially in j.u.c.
> Most obviously, how do you implement compareAndSet methods without the
> same visibility guarantees on the Unsafe equivalents?

Obviously Unsafe has to be implemented in a way that satisfies the j.u.c 
routines that use it.

> My spec change only documents what "everyone already knows to be true".
> Another way of looking at it is that the Unsafe methods are a low-level
> optimization of the equivalent j.u.c.a. objects without requiring memory
> allocation.

The public API methods specify memory ordering semantics so that the end 
programmer can use those to reason about their use of j.u.c components.

The implementation of j.u.c has to satisfy its specified semantics.

The current implementation of j.u.c uses Unsafe operations that in turn 
utilize JVM operations. The JVM operations have memory synchronization 
affects that are stronger than required by j.u.c, and so satisfy them.

So the question is: should Unsafe specify the expectations of its j.u.c 
client (what you propose); or should it specify what the JVM 
implementations provide; or should it not actually specify anything in 
this regard knowing that the implementation is required to correctly 
implement the public APIs? I don't see much point in pushing down the 
spec from the public APIs to the Unsafe API. To me it suffices to say 
that the Unsafe methods must correctly implement the requirements of the 
public API without specifying that in specific terms of volatile 
read/writes (which it doesn't actually use) or full bi-directional 
fences (which it does use). It's not as if Unsafe were a public API for 
which we might switch in implementations from different providers and 
hence we need a clear specification for those implementors to follow.

But if you think it important that these Unsafe methods say something 
about memory synchronization then the wording still needs to make clear 
what "volatile" is assumed to be being accessed. In particular the j.u.c 
usage always passes the offset of a variable that is volatile - hence 
getting volatile read/write semantics. But you can pass the Unsafe 
methods the offset for a variable that is not declared volatile - so 
what then? Should the specification state that the offset is 
assumed/expected to that for a volatile variable and hence it provides 
volatile read/write only if that variable is volatile? Or should we 
state something more generic as in:

"This operation reads the Java variable at the given offset with 
volatile load semantics, and writes it with volatile store semantics."

That doesn't force the variable to be volatile but does require Unsafe 
to act as if it were. The wording is also similar to that used in 
getObjectVolatile/putObjectVolatile. (It also doesn't attempt to the 
address the debate as to whether there is any volatile write on failure 
- should it?)

Or should we say something else?

Cheers,
David


From david.holmes at oracle.com  Tue Mar 10 01:38:23 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Mar 2015 11:38:23 +1000
Subject: RFR: JDK-8074578 Document memory visibility effects of some Unsafe
	methods
In-Reply-To: <54FE4943.1030008@oracle.com>
References: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>	<54FCEA87.3030509@oracle.com>	<54FD6767.8020506@redhat.com>	<54FD8059.9050205@oracle.com>	<CA+kOe0-NSsfYwDE6xzquWAe9OVhx389tX27vo5_DUpUSdTEpeQ@mail.gmail.com>
	<54FE4943.1030008@oracle.com>
Message-ID: <54FE4B0F.5080506@oracle.com>

PS. You state: "Corresponds to C11 atomic_compare_exchange_strong." Yet 
that would match with the full bi-directional fences of the VM 
implementation (due to memory_order_seq_cst), not a volatile read 
followed by a volatile write (which would be memory_order_acq_rel).

http://en.cppreference.com/w/c/atomic/atomic_compare_exchange
http://en.cppreference.com/w/c/atomic/memory_order

David

On 10/03/2015 11:30 AM, David Holmes wrote:
> On 10/03/2015 2:21 AM, Martin Buchholz wrote:
>> On Mon, Mar 9, 2015 at 4:13 AM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     On 9/03/2015 7:27 PM, Andrew Haley wrote:
>>
>>
>>     But who is to say that is the specification for the Unsafe API?
>>
>>
>> It's for us to say!
>
> I meant specifically the choice of the specification, not the right to
> suggest one.
>
>>     The public API's have a specification for what they provide to the
>>     programmer. On what basis are we assigning that same specification
>>     to Unsafe API? The Unsafe API has to meet the requirements of the
>>     public APIs that use it, but that doesn't  mean it necessarily
>>     should have the same specification as those APIs.
>>
>>
>> We already have lots of code that implicitly depends on volatile
>> read/write visibility, especially in j.u.c.
>> Most obviously, how do you implement compareAndSet methods without the
>> same visibility guarantees on the Unsafe equivalents?
>
> Obviously Unsafe has to be implemented in a way that satisfies the j.u.c
> routines that use it.
>
>> My spec change only documents what "everyone already knows to be true".
>> Another way of looking at it is that the Unsafe methods are a low-level
>> optimization of the equivalent j.u.c.a. objects without requiring memory
>> allocation.
>
> The public API methods specify memory ordering semantics so that the end
> programmer can use those to reason about their use of j.u.c components.
>
> The implementation of j.u.c has to satisfy its specified semantics.
>
> The current implementation of j.u.c uses Unsafe operations that in turn
> utilize JVM operations. The JVM operations have memory synchronization
> affects that are stronger than required by j.u.c, and so satisfy them.
>
> So the question is: should Unsafe specify the expectations of its j.u.c
> client (what you propose); or should it specify what the JVM
> implementations provide; or should it not actually specify anything in
> this regard knowing that the implementation is required to correctly
> implement the public APIs? I don't see much point in pushing down the
> spec from the public APIs to the Unsafe API. To me it suffices to say
> that the Unsafe methods must correctly implement the requirements of the
> public API without specifying that in specific terms of volatile
> read/writes (which it doesn't actually use) or full bi-directional
> fences (which it does use). It's not as if Unsafe were a public API for
> which we might switch in implementations from different providers and
> hence we need a clear specification for those implementors to follow.
>
> But if you think it important that these Unsafe methods say something
> about memory synchronization then the wording still needs to make clear
> what "volatile" is assumed to be being accessed. In particular the j.u.c
> usage always passes the offset of a variable that is volatile - hence
> getting volatile read/write semantics. But you can pass the Unsafe
> methods the offset for a variable that is not declared volatile - so
> what then? Should the specification state that the offset is
> assumed/expected to that for a volatile variable and hence it provides
> volatile read/write only if that variable is volatile? Or should we
> state something more generic as in:
>
> "This operation reads the Java variable at the given offset with
> volatile load semantics, and writes it with volatile store semantics."
>
> That doesn't force the variable to be volatile but does require Unsafe
> to act as if it were. The wording is also similar to that used in
> getObjectVolatile/putObjectVolatile. (It also doesn't attempt to the
> address the debate as to whether there is any volatile write on failure
> - should it?)
>
> Or should we say something else?
>
> Cheers,
> David


From martinrb at google.com  Tue Mar 10 05:04:24 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 9 Mar 2015 22:04:24 -0700
Subject: RFR: JDK-8074578 Document memory visibility effects of some
	Unsafe methods
In-Reply-To: <54FE4B0F.5080506@oracle.com>
References: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>
	<54FCEA87.3030509@oracle.com> <54FD6767.8020506@redhat.com>
	<54FD8059.9050205@oracle.com>
	<CA+kOe0-NSsfYwDE6xzquWAe9OVhx389tX27vo5_DUpUSdTEpeQ@mail.gmail.com>
	<54FE4943.1030008@oracle.com> <54FE4B0F.5080506@oracle.com>
Message-ID: <CA+kOe0_EYLfSKbQt27dPMucN4TfJ6cNJtQJux+QUr2B+_Uaz-g@mail.gmail.com>

??
I mentally map Java volatile operations to C11 seq_cst because of the total
order over all operations on volatile variables.
Volatile reads and writes do not just have acquire/release semantics.
The java memory model does not (yet) have C11-style relaxed atomics (like
acquire or release)

On Mon, Mar 9, 2015 at 6:38 PM, David Holmes <david.holmes at oracle.com>
wrote:

> PS. You state: "Corresponds to C11 atomic_compare_exchange_strong." Yet
> that would match with the full bi-directional fences of the VM
> implementation (due to memory_order_seq_cst), not a volatile read followed
> by a volatile write (which would be memory_order_acq_rel).
>


From david.holmes at oracle.com  Tue Mar 10 05:17:21 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Mar 2015 15:17:21 +1000
Subject: RFR: JDK-8074578 Document memory visibility effects of some Unsafe
	methods
In-Reply-To: <CA+kOe0_EYLfSKbQt27dPMucN4TfJ6cNJtQJux+QUr2B+_Uaz-g@mail.gmail.com>
References: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>	<54FCEA87.3030509@oracle.com>	<54FD6767.8020506@redhat.com>	<54FD8059.9050205@oracle.com>	<CA+kOe0-NSsfYwDE6xzquWAe9OVhx389tX27vo5_DUpUSdTEpeQ@mail.gmail.com>	<54FE4943.1030008@oracle.com>	<54FE4B0F.5080506@oracle.com>
	<CA+kOe0_EYLfSKbQt27dPMucN4TfJ6cNJtQJux+QUr2B+_Uaz-g@mail.gmail.com>
Message-ID: <54FE7E61.1010800@oracle.com>

On 10/03/2015 3:04 PM, Martin Buchholz wrote:
> ??
> I mentally map Java volatile operations to C11 seq_cst because of the
> total order over all operations on volatile variables.
> Volatile reads and writes do not just have acquire/release semantics.

You may be right. The synchronization order (not just operations on 
volatiles) is a total order. I tend to only think about the 
acquire/release semantics of volatile accesses - or more specifically 
the allowed reorderings with respect to other stores and loads. I 
confess I don't know what having a total order requires beyond the 
barriers we utilize for the volatile read/write actions ?? The fact we 
have two different orderings in C11 suggests something extra is required 
by the implementation to achieve seq_cst.

David

> The java memory model does not (yet) have C11-style relaxed atomics
> (like acquire or release)
>
> On Mon, Mar 9, 2015 at 6:38 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     PS. You state: "Corresponds to C11
>     atomic_compare_exchange___strong." Yet that would match with the
>     full bi-directional fences of the VM implementation (due to
>     memory_order_seq_cst), not a volatile read followed by a volatile
>     write (which would be memory_order_acq_rel).
>


From aph at redhat.com  Tue Mar 10 07:16:17 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 10 Mar 2015 07:16:17 +0000
Subject: RFR: JDK-8074578 Document memory visibility effects of some Unsafe
	methods
In-Reply-To: <54FE4B0F.5080506@oracle.com>
References: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>	<54FCEA87.3030509@oracle.com>	<54FD6767.8020506@redhat.com>	<54FD8059.9050205@oracle.com>	<CA+kOe0-NSsfYwDE6xzquWAe9OVhx389tX27vo5_DUpUSdTEpeQ@mail.gmail.com>	<54FE4943.1030008@oracle.com>
	<54FE4B0F.5080506@oracle.com>
Message-ID: <54FE9A41.5090502@redhat.com>

On 10/03/15 01:38, David Holmes wrote:
> PS. You state: "Corresponds to C11 atomic_compare_exchange_strong." Yet 
> that would match with the full bi-directional fences of the VM 
> implementation (due to memory_order_seq_cst), not a volatile read 
> followed by a volatile write (which would be memory_order_acq_rel).

Sequential consistency between atomics does not require full
bidirectional fences with regard to other non-volatile memory
accesses.

Andrew.



From aph at redhat.com  Tue Mar 10 07:31:38 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 10 Mar 2015 07:31:38 +0000
Subject: RFR: JDK-8074578 Document memory visibility effects of some Unsafe
	methods
In-Reply-To: <54FE4943.1030008@oracle.com>
References: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>	<54FCEA87.3030509@oracle.com>	<54FD6767.8020506@redhat.com>	<54FD8059.9050205@oracle.com>
	<CA+kOe0-NSsfYwDE6xzquWAe9OVhx389tX27vo5_DUpUSdTEpeQ@mail.gmail.com>
	<54FE4943.1030008@oracle.com>
Message-ID: <54FE9DDA.8030301@redhat.com>

On 10/03/15 01:30, David Holmes wrote:
> On 10/03/2015 2:21 AM, Martin Buchholz wrote:
>> On Mon, Mar 9, 2015 at 4:13 AM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     On 9/03/2015 7:27 PM, Andrew Haley wrote:
>>
>>
>>     But who is to say that is the specification for the Unsafe API?
>>
>>
>> It's for us to say!
> 
> I meant specifically the choice of the specification, not the right to 
> suggest one.
> 
>>     The public API's have a specification for what they provide to the
>>     programmer. On what basis are we assigning that same specification
>>     to Unsafe API? The Unsafe API has to meet the requirements of the
>>     public APIs that use it, but that doesn't  mean it necessarily
>>     should have the same specification as those APIs.
>>
>>
>> We already have lots of code that implicitly depends on volatile
>> read/write visibility, especially in j.u.c.
>> Most obviously, how do you implement compareAndSet methods without the
>> same visibility guarantees on the Unsafe equivalents?
> 
> Obviously Unsafe has to be implemented in a way that satisfies the j.u.c 
> routines that use it.
>
>> My spec change only documents what "everyone already knows to be true".
>> Another way of looking at it is that the Unsafe methods are a low-level
>> optimization of the equivalent j.u.c.a. objects without requiring memory
>> allocation.
> 
> The public API methods specify memory ordering semantics so that the
> end programmer can use those to reason about their use of j.u.c
> components.
> 
> The implementation of j.u.c has to satisfy its specified semantics.
> 
> The current implementation of j.u.c uses Unsafe operations that in
> turn utilize JVM operations. The JVM operations have memory
> synchronization affects that are stronger than required by j.u.c,
> and so satisfy them.
> 
> So the question is: should Unsafe specify the expectations of its
> j.u.c client (what you propose); or should it specify what the JVM
> implementations provide; or should it not actually specify anything
> in this regard knowing that the implementation is required to
> correctly implement the public APIs?

Unsafe is an API, so should be specified.  (Whether it's really a
public API has been a matter of some controversy, and people certainly
have treated it as though it were one!)  There is more than one
implementation of some of these methods, and some architectures
(AArch64 is the one I care about the most) have instructions which
implement the JMM requirements perfectly but not anything stronger.
If we were to adopt a stronger API for Unsafe that would slow down
such platforms.

> I don't see much point in pushing down the spec from the public APIs
> to the Unsafe API. To me it suffices to say that the Unsafe methods
> must correctly implement the requirements of the public API without
> specifying that in specific terms of volatile read/writes (which it
> doesn't actually use) or full bi-directional fences (which it does
> use).

It certainly can use volatile read/writes and I would very much like
that to happen (at least on AArch64) before JDK9 is released.

> It's not as if Unsafe were a public API for which we might switch in
> implementations from different providers and hence we need a clear
> specification for those implementors to follow.

Yes it is!  There are other Java VMs which use the OpenJDK class
library, and they will probably have their own Unsafe builtins.

Andrew.


From dmitry.samersoff at oracle.com  Tue Mar 10 07:53:14 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 10 Mar 2015 10:53:14 +0300
Subject: RFR(S): JDK-8073584 Native compilation warning in unpack code
In-Reply-To: <54EBE0B8.80804@oracle.com>
References: <54E77CA2.3090304@oracle.com> <54EA8B75.5040406@oracle.com>
	<54EB330F.1090503@oracle.com> <54EBE0B8.80804@oracle.com>
Message-ID: <54FEA2EA.7050409@oracle.com>

David at all,

May I consider the fix as reviewed and continue with integration?

-Dmitry


On 2015-02-24 05:23, David Holmes wrote:
> On 24/02/2015 12:02 AM, Dmitry Samersoff wrote:
>> Hi Everyone,
>>
>> Webrev updated in-place (press shift-reload)
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8073584/webrev.01/
> 
> share/native/libunpack/jni.cpp
> 
> 295     return (jobject) NULL;
> 
> Why do you need a cast on NULL?
> 
>> Updated formatting.
>>
>> Hack in main.cpp replaced with true error check.
> 
> Not sure it is appropriate to lump the "res != 1" in with the CR error.
> Doesn't this case deserve its own u.abort(xxx) ?
> 
> Thanks,
> David
> 
>> -Dmitry
>>
>>
>> On 2015-02-23 05:07, David Holmes wrote:
>>> On 21/02/2015 4:27 AM, Dmitry Samersoff wrote:
>>>> Hi Everyone,
>>>>
>>>> It's my $0.02 to the warning cleanup work. Please review:
>>>>
>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8073584/webrev.01/
>>>>
>>>> Notes:
>>>>
>>>> I use an ugly trick: (void) (read() + 1) to get rid of ignored value
>>>> warning because since gcc 4.6 just (void) is not enough.
>>>
>>> Why not just check the return value for correctness?
>>>
>>> David
>>>
>>>>
>>>> -Dmitry
>>>>
>>>>
>>
>>


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


From peter.levart at gmail.com  Tue Mar 10 09:17:37 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 10 Mar 2015 10:17:37 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54FDEA81.70206@Oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>,
	<54DE1969.2040508@gmail.com> <54E393BC.4030600@Oracle.com>,
	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<BLU175-W460A71BD3351510864D3E0831C0@phx.gbl>	<54FD717C.1070500@oracle.com>
	<54FDAE15.8080606@Oracle.com>,
	<54FDB188.1000602@oracle.com>	<BLU175-W180FE85C6CA81825886349831B0@phx.gbl>
	<54FDEA81.70206@Oracle.com>
Message-ID: <54FEB6B1.8080608@gmail.com>

Hi,

On 03/09/2015 07:46 PM, Roger Riggs wrote:
> Hi Jason,
>
> Comparing with startInstant is a possibility, assuming it is cached in 
> the ProcessHandle
> and increases the cost of creating ProcessHandles since it needs to be 
> parsed from /proc files.

Unless it is obtained lazily and then cached. Internal logic of 
Process[Handle][Impl] doesn't need Comparable interface, right? Only 
client code might need it to order instances and identify duplicates.

Returning 0 from ph1.compareTo(ph2) for two otherwise distinct system 
processes (in case getPid() is not supported) means that such objects 
can't be used as keys in TreeMap. If we can't support Comparable to be a 
total-order that differentiates objects based on some form of process 
identity, we might better not implement Comparable and let users use 
getPid() and/or make their own Comparators to support custom 
Process[Handle] implementations, etc...

At least for Process objects that are guaranteed to be singletons per 
system process, there could be a tie-breaking integer allocated at 
construction time.

ProcessHandle is new API and we can mandate the implementations to 
support some sort of total-order Comparable even if getPid() is not 
supported. That reises the question: should we also mandate 
ProcessHandle.equals() to return true for ph1.equals(ph2) when and only 
when ph1 represents the same system process as ph2? Process objects 
already behave like that with default equals (since they are singletons 
per process). To be sure that every external implementation of 
ProcessHandle adheres to that specification, both compareTo() and 
equals()/hashCode() should be declared as abstract in ProcessHandle.

What this means is that different implementations of ProcessHandle won't 
be mutually comparable or equatable, but I don't see this as a problem 
if it is specified explicitly.

Regards, Peter

> And it can help a long standing potential issue of pid's being re-used.
> ProcessHandle is only within a single host; there is no cross host 
> invocation mechanism.
>
> Roger
>
>
> On 3/9/2015 12:49 PM, Jason Mehrens wrote:
>> Anything but allowing UOE to escape compareTo sounds good.
>>
>>
>> Apologies if I missed this in previous threads but, shouldn't 
>> ProcessHandle.compareTo compare hostname, startInstant, and then 
>> pid?  Or assuming they are not comparable between hosts then just 
>> startInstant and pid.
>>
>>
>> Jason
>>
>>
>>
>> ----------------------------------------
>>> Date: Mon, 9 Mar 2015 14:43:20 +0000
>>> From: chris.hegarty at oracle.com
>>> To: Roger.Riggs at oracle.com; jason_mehrens at hotmail.com
>>> CC: core-libs-dev at openjdk.java.net
>>> Subject: Re: JEP 102 Process Updates revised API draft
>>>
>>> On 09/03/15 14:28, Roger Riggs wrote:
>>>> Hi,
>>>>
>>>> The problem could be isolated to compareTo by defining the ordering if
>>>> getPid
>>>> throws UOE and without diluting the spec for getPid returning the 
>>>> native
>>>> os process identifier.
>>> Yes, that would work.
>>>
>>>> Defining the default for getPid() to return -1, might not have too big
>>>> an impact.
>>>> It would order the incompletely implemented Process subtypes before 
>>>> the
>>>> real ones
>>>> but the order is not usually significant except to be able to have a
>>>> predictable iteration order
>>>> or use TreeMap. Returning Long.MAX_VALUE as the default might be 
>>>> another
>>>> option.
>>> That would probably be ok too, and then the UOE could be removed from
>>> Process.getPid() too, right? Which solves that small API wart.
>>>
>>> -Chris.
>>>
>>>> Roger
>>>>
>>>>
>>>>
>>>> On 3/9/2015 6:10 AM, Chris Hegarty wrote:
>>>>> On 06/03/15 19:34, Jason Mehrens wrote:
>>>>>> Hi Chris,
>>>>>> Since getPid can throw UOE that means that compareTo could now throw
>>>>>> UOE.
>>>>> Ooh... I don't like this.
>>>>>
>>>>> Has any consideration been given to getPid returning -1, if 
>>>>> unknown or
>>>>> the default implementation? Or would this be any better?
>>>>>
>>>>> -Chris
>>>>>
>>>>>>
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> Subject: Re: JEP 102 Process Updates revised API draft
>>>>>>> From: chris.hegarty at oracle.com
>>>>>>> Date: Fri, 6 Mar 2015 11:59:28 +0000
>>>>>>> To: Roger.Riggs at oracle.com
>>>>>>> CC: core-libs-dev at openjdk.java.net
>>>>>>>
>>>>>>> Roger,
>>>>>>>
>>>>>>> I?ve taken a look at these changes in the sandbox (
>>>>>>> JDK-8046092-branch ). Overall I welcome this addition.
>>>>>>>
>>>>>>> Some comments, most of which I stuffed into a webrev based on your
>>>>>>> branch,
>>>>>>> http://cr.openjdk.java.net/~chegar/process_comments/webrev/
>>>>>>>
>>>>>>> 1) ProcessHandle.compareTo() can drop the ClassCastException
>>>>>>> Also, I think the comparison is the wrong way around. It should
>>>>>>> be compare(this, other), rather than compare(other, this), right?
>>>>>>>
>>>>>>> 2) I know there has been a lot of discussion about the use of CF,
>>>>>>> but I have a few more comments:
>>>>>>>
>>>>>>> a) Both onExist and onProcessExit are implemented to 
>>>>>>> unconditionally
>>>>>>> throw UOE. Is the intention to make the implementation of these
>>>>>>> methods optional? If so, then UOE should be documented, If not,
>>>>>>> then I think they can be abstract, right?
>>>>>>>
>>>>>>> b) The wording in the spec talks about async functions and actions.
>>>>>>> I think this may be not quite right. The intention is to 
>>>>>>> support, as is
>>>>>>> provided by CF, the ability to chain both sync and async tasks.
>>>>>>> [ I suggested some wording in the webrev ]
>>>>>>>
>>>>>>> c) Why the need for ISE if the process is the current process, 
>>>>>>> and not
>>>>>>> just return a CF that never completes? Do you consider this an
>>>>>>> error situation that you want to notify, or consistency with other
>>>>>>> parts of the API ?
>>>>>>>
>>>>>>> d) I wonder if onProcessExit should have a small API note, saying
>>>>>>> that it is preferred over onExit, when you have a Process. Or
>>>>>>> something to promote its use over onExit, or briefly explain its
>>>>>>> existence. ( I know why it is there, but it may appear as 
>>>>>>> duplication )
>>>>>>>
>>>>>>> e) Maybe onProcessExit would benefit from an apiNote to indicate
>>>>>>> that it is essentially an alternative to waitFor() ?
>>>>>>>
>>>>>>> 3) Should ProcessHandle.getPid declare that it can throw IOE?
>>>>>>> Process.getPid declares UOE.
>>>>>>>
>>>>>>> 4) ProcessHandle.Info.user() ? owner() seems more appropriate, no?
>>>>>>>
>>>>>>> 5) The description of info() talks about fields, when it is an
>>>>>>> interface.
>>>>>>> I added some suggested rewording. Also, all methods now return
>>>>>>> references, so -1 can be removed. Similar for the Info class
>>>>>>> description.
>>>>>>>
>>>>>>> 6) There are a couple of @since 1.9 tags missing from Process
>>>>>>> supportsDestroyForcibly and onProcessExit
>>>>>>>
>>>>>>> That?s all for now.
>>>>>>>
>>>>>>> -Chris.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>



From paul.sandoz at oracle.com  Tue Mar 10 09:50:41 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 10 Mar 2015 10:50:41 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54F9F8E2.1020502@Oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>
	<54DE1969.2040508@gmail.com> <54E393BC.4030600@Oracle.com>
	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>
	<54F9F8E2.1020502@Oracle.com>
Message-ID: <01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>

On Mar 6, 2015, at 7:58 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
>> 2) I know there has been a lot of discussion about the use of CF,
>>     but I have a few more comments:
>>          a) Both onExit and onProcessExit are implemented to unconditionally
>>         throw UOE. Is the intention to make the implementation of these
>>         methods optional? If so, then UOE should be documented, If not,
>>         then I think they can be abstract, right?
> There are existing non-jdk implementations of Process and it would be source
> incompatible if default implementations were not supplied.  So, not abstract.
> 
> Since the behavior applies to Process, the note in the class documentation
> defines the behavior.
> "Methods of {@code Process} that are not otherwise specified or overridden throw
> {@link java.lang.UnsupportedOperationException}."
> 
> More direct documentation could be provided in the override of onExit
> but that would raise the visibility to ordinary developers who should use
> onProcessExit that returns the correctly typed CF and not onExit.
> The note should be sufficient for implementers without distracting the ordinary developer.
> 
> Perhaps, a description similar to that used in destroy(), the behavior of Processes
> returned from ProcessBuilder can be more tightly specified. Alternatively,
> ProcessBuilder could specify the behavior of Process instances it returns, at present,
> the behavior of the Process instances is split between the two classes.
> 

Throwing USO for default implementations is a warning sign to me that something does not fit quite right. It feels like we are giving up :-)  

I now see Process.getPid was previously added and it throws USO by default. So we might be stuck due to the tricky nature of this area. 

Any sub-type of Process that does not override getPid will essentially result in that USO being propagated to many ProcessHandle methods that depend on the PID (parent, children, allChildren, info, compareTo). That effectively renders ProcessHandle almost useless for sub-types outside of our control that that not been updated.

Is it common to sub-type Process? If so then perhaps Process should not extend ProcessHandle and instead there should be a way to view a Process as a ProcessHandle, whose default implementation is:

  return ProcessHandle.of(getPid()); // throws USO if getPid does 

(java.lang.ProcessImpl could implement Processhandle thereby the implementation is "return this".)

Thus once you have a ProcessHandle instance (from whatever source) it's possible to operate on it without fear of a USO.


A possible default implementation for Process.onProcessExit could be:

  return CF.supplyAsync(() -> { this.waitFor(); return p}, cachedThreadPool);

Paul.


From david.holmes at oracle.com  Tue Mar 10 11:07:49 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Mar 2015 21:07:49 +1000
Subject: RFR(S): JDK-8073584 Native compilation warning in unpack code
In-Reply-To: <54FEA2EA.7050409@oracle.com>
References: <54E77CA2.3090304@oracle.com> <54EA8B75.5040406@oracle.com>
	<54EB330F.1090503@oracle.com> <54EBE0B8.80804@oracle.com>
	<54FEA2EA.7050409@oracle.com>
Message-ID: <54FED085.7000708@oracle.com>

On 10/03/2015 5:53 PM, Dmitry Samersoff wrote:
> David at all,
>
> May I consider the fix as reviewed and continue with integration?

Seems okay to me.

David

> -Dmitry
>
>
> On 2015-02-24 05:23, David Holmes wrote:
>> On 24/02/2015 12:02 AM, Dmitry Samersoff wrote:
>>> Hi Everyone,
>>>
>>> Webrev updated in-place (press shift-reload)
>>>
>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8073584/webrev.01/
>>
>> share/native/libunpack/jni.cpp
>>
>> 295     return (jobject) NULL;
>>
>> Why do you need a cast on NULL?
>>
>>> Updated formatting.
>>>
>>> Hack in main.cpp replaced with true error check.
>>
>> Not sure it is appropriate to lump the "res != 1" in with the CR error.
>> Doesn't this case deserve its own u.abort(xxx) ?
>>
>> Thanks,
>> David
>>
>>> -Dmitry
>>>
>>>
>>> On 2015-02-23 05:07, David Holmes wrote:
>>>> On 21/02/2015 4:27 AM, Dmitry Samersoff wrote:
>>>>> Hi Everyone,
>>>>>
>>>>> It's my $0.02 to the warning cleanup work. Please review:
>>>>>
>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8073584/webrev.01/
>>>>>
>>>>> Notes:
>>>>>
>>>>> I use an ugly trick: (void) (read() + 1) to get rid of ignored value
>>>>> warning because since gcc 4.6 just (void) is not enough.
>>>>
>>>> Why not just check the return value for correctness?
>>>>
>>>> David
>>>>
>>>>>
>>>>> -Dmitry
>>>>>
>>>>>
>>>
>>>
>
>


From paul.sandoz at oracle.com  Tue Mar 10 13:45:24 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 10 Mar 2015 14:45:24 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <54F2ECF3.8050803@redhat.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>	<54F070B6.4070204@redhat.com>
	<54F07D39.8000406@oracle.com>	<54F09192.5070104@redhat.com>
	<493F2892-E8A4-4547-A68C-EF7E1E61BAB9@oracle.com>
	<54F2ECF3.8050803@redhat.com>
Message-ID: <89C2AE55-041A-4E08-847F-A1F6E227A1B3@oracle.com>

Sorry for the late reply, getting through email backlogs...

On Mar 1, 2015, at 11:41 AM, Florian Weimer <fweimer at redhat.com> wrote:

> On 02/27/2015 06:16 PM, Paul Sandoz wrote:
>> On Feb 27, 2015, at 4:47 PM, Florian Weimer <fweimer at redhat.com> wrote:
>>> I really don't think this tooling support will provide sufficient
>>> enticement to developers to maintain separate 7/8/9 source branches of
>>> their libraries.  Isn't that the main obstacle, and not the way the bits
>>> are delivered?
>>> 
>> 
>> What if all the source for 7/8/9 bits were under one project?
> 
> Tool support for that is still worse than for separate branches of the
> same project.
> 

Separate branches and different library versions with most likely backwards incompatible APIs, right?


> In general, VCS support for branches is still quite poor because the
> sensible thing to do is to develop a feature on the master branch and
> then backport it to older release branches as needed.  But such
> selective backwards-merging very much lacks VCS support because the
> least common ancestor logic build into almost all current tools does not
> apply in this scenario.  From a tool perspective, developing the feature
> in the oldest relevant release and then merging forward is the only
> supported way.  But it's usually bad engineering because you want new
> features to use current facilities of the code base.  So the only thing
> you have left is to cherry-pick individual patches (I think thats what
> ?hg transplant? does in Mercurial).
> 
> Anyway, you lose the tiny bit of tool support you have for backporting
> if you have everything in the same source repository.
> 

>> For example, say there is a source file:
>> 
>>  src/main/java/foo/Foo.java
>> 
>> whose content is:
>> 
>>  import sun.misc.BASE64Decoder;
>> 
>>  public class Foo {
>>    // does something with sun.misc.BASE64Decoder	
>>  }
>> 
>> There might be another source file located in the 8 area that overrides that in the unversioned area:
>> 
>>  src/main-8/java/foo/Foo.java
>> 
>> whose content is:
>> 
>>  import java.util.Base64;
>> 
>>  public class Foo {
>>    // does something equivalent with java.util.Base64	
>>  }
> 
> This really screams preprocessor. :-(

That's another approach, generate the sources using a pre-processor, which of course has it's own issues w.r.t. IDEs. Note i am not trying to dictate a particular project approach here.


> 
>> The public contract of Foo should remain identical across the major Java platform dependent versions, in a more strict sense the public signatures in the byte code should be identical (the jar tool has been modified to check this).
> 
> If that's the goal, something like Retroweaver seems far more
> appropriate than forcing library authors to maintain separate sources.
> 

Consider the case of library code using Unsafe for lexicographical unsigned byte[] comparison. It might be quite tricky for a tool to automate without the library itself telling the tool what to do. We are not proposing something more sophisticated such as runtime code transformations (discussed further by Remi).


> Multi-version JAR files seem useful because they will eventually allow
> evolution of the class file format.

Sorry, you lost me on that point.

Paul.

>  But I think the current use case
> isn't really there, I'm afraid.
> 
> -- 
> Florian Weimer / Red Hat Product Security



From Roger.Riggs at Oracle.com  Tue Mar 10 13:55:08 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 10 Mar 2015 09:55:08 -0400
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54FEB6B1.8080608@gmail.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>,
	<54DE1969.2040508@gmail.com> <54E393BC.4030600@Oracle.com>,
	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<BLU175-W460A71BD3351510864D3E0831C0@phx.gbl>	<54FD717C.1070500@oracle.com>
	<54FDAE15.8080606@Oracle.com>,
	<54FDB188.1000602@oracle.com>	<BLU175-W180FE85C6CA81825886349831B0@phx.gbl>
	<54FDEA81.70206@Oracle.com> <54FEB6B1.8080608@gmail.com>
Message-ID: <54FEF7BC.8050702@Oracle.com>

Hi Peter,

On 3/10/2015 5:17 AM, Peter Levart wrote:
> Hi,
>
> On 03/09/2015 07:46 PM, Roger Riggs wrote:
>> Hi Jason,
>>
>> Comparing with startInstant is a possibility, assuming it is cached 
>> in the ProcessHandle
>> and increases the cost of creating ProcessHandles since it needs to 
>> be parsed from /proc files.
>
> Unless it is obtained lazily and then cached. Internal logic of 
> Process[Handle][Impl] doesn't need Comparable interface, right? Only 
> client code might need it to order instances and identify duplicates.
Correct, though if cached lazily, there might be an issue with its 
validity some
indeterminate time later; but that's not worse than the case today 
without a timestamp.
>
> Returning 0 from ph1.compareTo(ph2) for two otherwise distinct system 
> processes (in case getPid() is not supported) means that such objects 
> can't be used as keys in TreeMap. If we can't support Comparable to be 
> a total-order that differentiates objects based on some form of 
> process identity, we might better not implement Comparable and let 
> users use getPid() and/or make their own Comparators to support custom 
> Process[Handle] implementations, etc...
That's always an option; though it will be harder for an application to 
cope with having
to refer to comparators for custom implementations.
>
> At least for Process objects that are guaranteed to be singletons per 
> system process, there could be a tie-breaking integer allocated at 
> construction time.
yes, for example, Instead of -1, Process.getPid() could assign a unique 
negative long.
>
> ProcessHandle is new API and we can mandate the implementations to 
> support some sort of total-order Comparable even if getPid() is not 
> supported. That raises the question: should we also mandate 
> ProcessHandle.equals() to return true for ph1.equals(ph2) when and 
> only when ph1 represents the same system process as ph2? Process 
> objects already behave like that with default equals (since they are 
> singletons per process). To be sure that every external implementation 
> of ProcessHandle adheres to that specification, both compareTo() and 
> equals()/hashCode() should be declared as abstract in ProcessHandle.
ProcessHandle is designed to not to have an external implementations 
(the constructor is package private).
Process can be extended, exposing the issues Paul has raised.  But yes, 
equals should reflect
that two instances refer to the same system process (as far as can be 
determined from the OS).
>
> What this means is that different implementations of ProcessHandle 
> won't be mutually comparable or equatable, but I don't see this as a 
> problem if it is specified explicitly.
ok

Thanks, Roger

>
> Regards, Peter
>
>> And it can help a long standing potential issue of pid's being re-used.
>> ProcessHandle is only within a single host; there is no cross host 
>> invocation mechanism.
>>
>> Roger
>>
>>
>> On 3/9/2015 12:49 PM, Jason Mehrens wrote:
>>> Anything but allowing UOE to escape compareTo sounds good.
>>>
>>>
>>> Apologies if I missed this in previous threads but, shouldn't 
>>> ProcessHandle.compareTo compare hostname, startInstant, and then 
>>> pid?  Or assuming they are not comparable between hosts then just 
>>> startInstant and pid.
>>>
>>>
>>> Jason
>>>
>>>
>>>
>>> ----------------------------------------
>>>> Date: Mon, 9 Mar 2015 14:43:20 +0000
>>>> From: chris.hegarty at oracle.com
>>>> To: Roger.Riggs at oracle.com; jason_mehrens at hotmail.com
>>>> CC: core-libs-dev at openjdk.java.net
>>>> Subject: Re: JEP 102 Process Updates revised API draft
>>>>
>>>> On 09/03/15 14:28, Roger Riggs wrote:
>>>>> Hi,
>>>>>
>>>>> The problem could be isolated to compareTo by defining the 
>>>>> ordering if
>>>>> getPid
>>>>> throws UOE and without diluting the spec for getPid returning the 
>>>>> native
>>>>> os process identifier.
>>>> Yes, that would work.
>>>>
>>>>> Defining the default for getPid() to return -1, might not have too 
>>>>> big
>>>>> an impact.
>>>>> It would order the incompletely implemented Process subtypes 
>>>>> before the
>>>>> real ones
>>>>> but the order is not usually significant except to be able to have a
>>>>> predictable iteration order
>>>>> or use TreeMap. Returning Long.MAX_VALUE as the default might be 
>>>>> another
>>>>> option.
>>>> That would probably be ok too, and then the UOE could be removed from
>>>> Process.getPid() too, right? Which solves that small API wart.
>>>>
>>>> -Chris.
>>>>
>>>>> Roger
>>>>>
>>>>>
>>>>>
>>>>> On 3/9/2015 6:10 AM, Chris Hegarty wrote:
>>>>>> On 06/03/15 19:34, Jason Mehrens wrote:
>>>>>>> Hi Chris,
>>>>>>> Since getPid can throw UOE that means that compareTo could now 
>>>>>>> throw
>>>>>>> UOE.
>>>>>> Ooh... I don't like this.
>>>>>>
>>>>>> Has any consideration been given to getPid returning -1, if 
>>>>>> unknown or
>>>>>> the default implementation? Or would this be any better?
>>>>>>
>>>>>> -Chris
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Jason
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> Subject: Re: JEP 102 Process Updates revised API draft
>>>>>>>> From: chris.hegarty at oracle.com
>>>>>>>> Date: Fri, 6 Mar 2015 11:59:28 +0000
>>>>>>>> To: Roger.Riggs at oracle.com
>>>>>>>> CC: core-libs-dev at openjdk.java.net
>>>>>>>>
>>>>>>>> Roger,
>>>>>>>>
>>>>>>>> I?ve taken a look at these changes in the sandbox (
>>>>>>>> JDK-8046092-branch ). Overall I welcome this addition.
>>>>>>>>
>>>>>>>> Some comments, most of which I stuffed into a webrev based on your
>>>>>>>> branch,
>>>>>>>> http://cr.openjdk.java.net/~chegar/process_comments/webrev/
>>>>>>>>
>>>>>>>> 1) ProcessHandle.compareTo() can drop the ClassCastException
>>>>>>>> Also, I think the comparison is the wrong way around. It should
>>>>>>>> be compare(this, other), rather than compare(other, this), right?
>>>>>>>>
>>>>>>>> 2) I know there has been a lot of discussion about the use of CF,
>>>>>>>> but I have a few more comments:
>>>>>>>>
>>>>>>>> a) Both onExist and onProcessExit are implemented to 
>>>>>>>> unconditionally
>>>>>>>> throw UOE. Is the intention to make the implementation of these
>>>>>>>> methods optional? If so, then UOE should be documented, If not,
>>>>>>>> then I think they can be abstract, right?
>>>>>>>>
>>>>>>>> b) The wording in the spec talks about async functions and 
>>>>>>>> actions.
>>>>>>>> I think this may be not quite right. The intention is to 
>>>>>>>> support, as is
>>>>>>>> provided by CF, the ability to chain both sync and async tasks.
>>>>>>>> [ I suggested some wording in the webrev ]
>>>>>>>>
>>>>>>>> c) Why the need for ISE if the process is the current process, 
>>>>>>>> and not
>>>>>>>> just return a CF that never completes? Do you consider this an
>>>>>>>> error situation that you want to notify, or consistency with other
>>>>>>>> parts of the API ?
>>>>>>>>
>>>>>>>> d) I wonder if onProcessExit should have a small API note, saying
>>>>>>>> that it is preferred over onExit, when you have a Process. Or
>>>>>>>> something to promote its use over onExit, or briefly explain its
>>>>>>>> existence. ( I know why it is there, but it may appear as 
>>>>>>>> duplication )
>>>>>>>>
>>>>>>>> e) Maybe onProcessExit would benefit from an apiNote to indicate
>>>>>>>> that it is essentially an alternative to waitFor() ?
>>>>>>>>
>>>>>>>> 3) Should ProcessHandle.getPid declare that it can throw IOE?
>>>>>>>> Process.getPid declares UOE.
>>>>>>>>
>>>>>>>> 4) ProcessHandle.Info.user() ? owner() seems more appropriate, no?
>>>>>>>>
>>>>>>>> 5) The description of info() talks about fields, when it is an
>>>>>>>> interface.
>>>>>>>> I added some suggested rewording. Also, all methods now return
>>>>>>>> references, so -1 can be removed. Similar for the Info class
>>>>>>>> description.
>>>>>>>>
>>>>>>>> 6) There are a couple of @since 1.9 tags missing from Process
>>>>>>>> supportsDestroyForcibly and onProcessExit
>>>>>>>>
>>>>>>>> That?s all for now.
>>>>>>>>
>>>>>>>> -Chris.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>
>



From Roger.Riggs at Oracle.com  Tue Mar 10 14:16:06 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 10 Mar 2015 10:16:06 -0400
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>
	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>
	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>
Message-ID: <54FEFCA6.4020107@Oracle.com>

Hi Paul,

On 3/10/2015 5:50 AM, Paul Sandoz wrote:
> On Mar 6, 2015, at 7:58 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
>>> 2) I know there has been a lot of discussion about the use of CF,
>>>      but I have a few more comments:
>>>           a) Both onExit and onProcessExit are implemented to unconditionally
>>>          throw UOE. Is the intention to make the implementation of these
>>>          methods optional? If so, then UOE should be documented, If not,
>>>          then I think they can be abstract, right?
>> There are existing non-jdk implementations of Process and it would be source
>> incompatible if default implementations were not supplied.  So, not abstract.
>>
>> Since the behavior applies to Process, the note in the class documentation
>> defines the behavior.
>> "Methods of {@code Process} that are not otherwise specified or overridden throw
>> {@link java.lang.UnsupportedOperationException}."
>>
>> More direct documentation could be provided in the override of onExit
>> but that would raise the visibility to ordinary developers who should use
>> onProcessExit that returns the correctly typed CF and not onExit.
>> The note should be sufficient for implementers without distracting the ordinary developer.
>>
>> Perhaps, a description similar to that used in destroy(), the behavior of Processes
>> returned from ProcessBuilder can be more tightly specified. Alternatively,
>> ProcessBuilder could specify the behavior of Process instances it returns, at present,
>> the behavior of the Process instances is split between the two classes.
>>
> Throwing USO for default implementations is a warning sign to me that something does not fit quite right. It feels like we are giving up :-)
It is an artifact of extending the API of an externally subclassable class.
>
> I now see Process.getPid was previously added and it throws USO by default. So we might be stuck due to the tricky nature of this area.
Added early in 9, IMHO it can be revisited if necessary.
>
> Any sub-type of Process that does not override getPid will essentially result in that USO being propagated to many ProcessHandle methods that depend on the PID (parent, children, allChildren, info, compareTo). That effectively renders ProcessHandle almost useless for sub-types outside of our control that that not been updated.
For those methods, the default behavior can be specified, except for 
compareTo
they already have return values that allow for the fact that the 
information may
not be available, either due to OS restrictions (permissions) or is not 
provided.
Empty lists for children, nulls returned from info, and even allowing 
for an unavailable parent.
>
> Is it common to sub-type Process?
Subclassing is very limited; usually for some kind of interposition or 
delegation.
> If so then perhaps Process should not extend ProcessHandle and instead there should be a way to view a Process as a ProcessHandle, whose default implementation is:
>
>    return ProcessHandle.of(getPid()); // throws USO if getPid does
>
> (java.lang.ProcessImpl could implement Processhandle thereby the implementation is "return this".)
Only if ProcessImpl extends ProcessHandle but it already extends Process 
and if Process does not extend ProcessHandle...

Regardless, the same methods parent, children, allChldren, info, 
compareTo would be useful
on Process and will have the same issues with subclassing and default 
implementations.

It is not a high priority to provide first class support for external 
subclasses of Process.
The focus is on Processes created by ProcessBuilder.

Thanks, Roger


>
> Thus once you have a ProcessHandle instance (from whatever source) it's possible to operate on it without fear of a USO.
>
>
> A possible default implementation for Process.onProcessExit could be:
>
>    return CF.supplyAsync(() -> { this.waitFor(); return p}, cachedThreadPool);
>
> Paul.



From paul.sandoz at oracle.com  Tue Mar 10 15:22:59 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 10 Mar 2015 16:22:59 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54FEFCA6.4020107@Oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>
	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>
	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>
	<54FEFCA6.4020107@Oracle.com>
Message-ID: <8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>

On Mar 10, 2015, at 3:16 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> On 3/10/2015 5:50 AM, Paul Sandoz wrote:
>> On Mar 6, 2015, at 7:58 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
>>>> 2) I know there has been a lot of discussion about the use of CF,
>>>>     but I have a few more comments:
>>>>          a) Both onExit and onProcessExit are implemented to unconditionally
>>>>         throw UOE. Is the intention to make the implementation of these
>>>>         methods optional? If so, then UOE should be documented, If not,
>>>>         then I think they can be abstract, right?
>>> There are existing non-jdk implementations of Process and it would be source
>>> incompatible if default implementations were not supplied.  So, not abstract.
>>> 
>>> Since the behavior applies to Process, the note in the class documentation
>>> defines the behavior.
>>> "Methods of {@code Process} that are not otherwise specified or overridden throw
>>> {@link java.lang.UnsupportedOperationException}."
>>> 
>>> More direct documentation could be provided in the override of onExit
>>> but that would raise the visibility to ordinary developers who should use
>>> onProcessExit that returns the correctly typed CF and not onExit.
>>> The note should be sufficient for implementers without distracting the ordinary developer.
>>> 
>>> Perhaps, a description similar to that used in destroy(), the behavior of Processes
>>> returned from ProcessBuilder can be more tightly specified. Alternatively,
>>> ProcessBuilder could specify the behavior of Process instances it returns, at present,
>>> the behavior of the Process instances is split between the two classes.
>>> 
>> Throwing USO for default implementations is a warning sign to me that something does not fit quite right. It feels like we are giving up :-)
> It is an artifact of extending the API of an externally subclassable class.
>> 
>> I now see Process.getPid was previously added and it throws USO by default. So we might be stuck due to the tricky nature of this area.
> Added early in 9, IMHO it can be revisited if necessary.

Perhaps, it seems more to point to a fundamental trickiness we cannot easily avoid.


>> 
>> Any sub-type of Process that does not override getPid will essentially result in that USO being propagated to many ProcessHandle methods that depend on the PID (parent, children, allChildren, info, compareTo). That effectively renders ProcessHandle almost useless for sub-types outside of our control that that not been updated.
> For those methods, the default behavior can be specified, except for compareTo
> they already have return values that allow for the fact that the information may
> not be available, either due to OS restrictions (permissions) or is not provided.
> Empty lists for children, nulls returned from info, and even allowing for an unavailable parent.

That's a separate issue. 

If i get a ProcessHandle given to me, i do not know it's source, i dunno if it's gonna barf if i operate on it.


>> 
>> Is it common to sub-type Process?
> Subclassing is very limited; usually for some kind of interposition or delegation.

Ok.


>> If so then perhaps Process should not extend ProcessHandle and instead there should be a way to view a Process as a ProcessHandle, whose default implementation is:
>> 
>>   return ProcessHandle.of(getPid()); // throws USO if getPid does
>> 
>> (java.lang.ProcessImpl could implement Processhandle thereby the implementation is "return this".)
> Only if ProcessImpl extends ProcessHandle but it already extends Process and if Process does not extend ProcessHandle...
> 

Doh! scrap that optimisation, i keep wanting ProcessHandle to be an iface.


> Regardless, the same methods parent, children, allChldren, info, compareTo would be useful
> on Process and will have the same issues with subclassing and default implementations.
> 

For all but comparison one could go through the view, it's a little more verbose, but not terrible.


> It is not a high priority to provide first class support for external subclasses of Process.
> The focus is on Processes created by ProcessBuilder.
> 

Ok. We should probably call that out more clearly in the docs if that is the design direction.

Paul.


From paul.sandoz at oracle.com  Tue Mar 10 15:29:39 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 10 Mar 2015 16:29:39 +0100
Subject: RFC: Adding ConcurrentModificationException for
	HashMap.computeIfAbsent(), and JDK-8071667
In-Reply-To: <54F9FB2D.6070908@oracle.com>
References: <54D1616F.50104@oracle.com>
	<54D18B9A.2020906@oracle.com>	<84AD741C-CB02-4540-B41B-8F95490FF8E4@oracle.com>	<54D2BB16.80508@oracle.com>
	<77020461-FD36-41FC-9996-9B476670C20D@oracle.com>
	<54D52E37.6040705@oracle.com> <54F9FB2D.6070908@oracle.com>
Message-ID: <DCA6D762-7ECE-4346-99EA-C3099F4CC6A4@oracle.com>

Hi Brent,

On the Map.compute* methods.

Perhaps we can reuse similar language to that we added for Matcher:

  The mapping function should not modify this map during computation. This method will, on a best-effort basis, throw a
  ConcurrentModification if such modification is detected. 

It's tempting to place the second sentence on the @throws ConcurrentModificationException as i believe will not show up for methods on ConcurrentMap, so keeps it somewhat contained documentation wise.



On Mar 6, 2015, at 8:08 PM, Brent Christian <brent.christian at oracle.com> wrote:

> Hi.  I'm picking this back up now.
> 
> In Map/HashMap, there are already two methods that accept lambdas and throw a CME:
>  forEach(BiConsumer)
>  replaceAll(BiFunction)
> 
> The Map interface documents these methods to state that "Exceptions are relayed to the caller", and has an @throws CME tag "if an entry is found to be removed".  (The default code does not throw a CME if items are added).
> 

Right, although the iterator might still be fail-fast.


> HashMap adds no additional documentation on these methods.  It has code to check the modCount, and throws a CME if it changes.
> 
> 
> The Map/HashMap methods I would like to update with this fix are:
>  compute(Key, BiFunction)
>  computeIfAbsent(Key, Function)
>  computeIfPresent(Key, BiFunction)
>  merge(Key, Value, BiFunction)
> 
> I would like to update the docs & code as follows:
> Map:
>    Docs: discourage modifying the map from function code; encourage implementing classes to detect/throw CME
>    Code: no change
> 
> HashMap/Hashtable:
>    Docs: document that structural modifications will result in a CME; add @throws CME
>    Code: check modCount & throw CME
> 
> ConcurrentMap:
>    Docs: discourage modifying the map from function code
>    Code: no change
> 
> 
> My first draft for the docs change, on computeIfAbsent():
> 
> diff -r 330dcd651f3b src/java.base/share/classes/java/util/Map.java
> --- a/src/java.base/share/classes/java/util/Map.java    Mon Feb 02 12:35:18 2015 -0800
> +++ b/src/java.base/share/classes/java/util/Map.java    Fri Feb 06 12:49:19 2015 -0800
> @@ -925,6 +925,11 @@
>      * }
>      * }</pre>
>      *
> +     * <p>The mappingFunction itself should not make changes to this map.
> +     * Implementing classes are encouraged to detect such modifications and
> +     * throw ConcurrentModificationException. The default implementation does
> +     * not do so.
> +     *
>      * <p>The default implementation makes no guarantees about synchronization
>      * or atomicity properties of this method. Any implementation providing
>      * atomicity guarantees must override this method and document its
> 
> diff -r 330dcd651f3b src/java.base/share/classes/java/util/HashMap.java
> --- a/src/java.base/share/classes/java/util/HashMap.java        Mon Feb 02 12:35:18 2015 -0800
> +++ b/src/java.base/share/classes/java/util/HashMap.java        Fri Feb 06 12:49:19 2015 -0800
> @@ -1082,6 +1082,17 @@
>         return null;
>     }
> 
> +    /**
> +     * {@inheritDoc}
> +     *
> +     * <p>The mappingFunction itself should not make changes to this map.
> +     * If the function causes a structural modification to the map, a
> +     * ConcurrentModificationException will be thrown.  As with iterators, this
> +     * exception is thrown on a best-effort basis.
> +     *
> +     * @throws ConcurrentModificationException if a structural change was
> +     * detected while executing the mappingFunction
> +     */
>     @Override
>     public V computeIfAbsent(K key,
>                              Function<? super K, ? extends V> mappingFunction) {
> 
> diff -r 330dcd651f3b src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java
> --- a/src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java   Mon Feb 02 12:35:18 2015 -0800
> +++ b/src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java   Fri Feb 06 12:49:19 2015 -0800
> @@ -305,6 +305,8 @@
>      * threads attempt updates including potentially calling the mapping
>      * function multiple times.
>      *
> +     * <p>The mappingFunction itself should not make changes to this map.
> +     *
>      * <p>This implementation assumes that the ConcurrentMap cannot contain null
>      * values and {@code get()} returning null unambiguously means the key is
> ---
> 
> If that looks okay, I will apply it to the other methods.
> 
> 
> I came across a few methods used by the list classes that I wanted to point out:
> 
> forEach(Consumer) on the Iterable interface
> removeIf(Predicate) on the Collection interface
> replaceAll(UnaryOperator) on the List interface
> 
> They all document that exceptions are relayed to the caller.  They do not have a @throws CME tag.  The default code uses iterators (or enhanced for()).   LinkedList uses the default versions.  ArrayList overrides the methods, adds no docs of its own, and has code to check the modCount and throw CME.
> 
> Would an "@throws CME" improve the JavaDoc of these default methods? I'm leaning toward, "not really."  

Same here, they require traversal so use an iterator or an internal equivalent, thus the CME pops out due to that.

Paul.

> Between the clause about exceptions being relayed to the caller, and knowing that the default method is using iterators (mentioned in the JavaDoc), and that iterators will throw CMEs, one can deduce that modifying the list from the lambda will result in a CME.  It's not clearly spelled out, but then, modifying the collection this way falls outside the intended usage of these methods.
> 
> Thanks for any additional feedback.
> 
> -Brent
> 
> On 2/6/15 1:12 PM, Brent Christian wrote:
>> diff -r 330dcd651f3b src/java.base/share/classes/java/util/Map.java
>> --- a/src/java.base/share/classes/java/util/Map.java    Mon Feb 02
>> 12:35:18 2015 -0800
>> +++ b/src/java.base/share/classes/java/util/Map.java    Fri Feb 06
>> 12:49:19 2015 -0800
>> @@ -925,6 +925,11 @@
>>       * }
>>       * }</pre>
>>       *
>> +     * <p>The mappingFunction itself should not make changes to this map.
>> +     * Implementing classes are encouraged to detect such modifications
>> and
>> +     * throw ConcurrentModificationException. The default
>> implementation does
>> +     * not do so.
>> +     *
>>       * <p>The default implementation makes no guarantees about
>> synchronization
>>       * or atomicity properties of this method. Any implementation
>> providing
>>       * atomicity guarantees must override this method and document its
>> 
>> diff -r 330dcd651f3b src/java.base/share/classes/java/util/HashMap.java
>> --- a/src/java.base/share/classes/java/util/HashMap.java        Mon Feb
>> 02 12:35:18 2015 -0800
>> +++ b/src/java.base/share/classes/java/util/HashMap.java        Fri Feb
>> 06 12:49:19 2015 -0800
>> @@ -1082,6 +1082,17 @@
>>          return null;
>>      }
>> 
>> +    /**
>> +     * {@inheritDoc}
>> +     *
>> +     * <p>The mappingFunction itself should not make changes to this map.
>> +     * If the function causes a structural modification to the map, a
>> +     * ConcurrentModificationException will be thrown.  As with
>> iterators, this
>> +     * exception is thrown on a best-effort basis.
>> +     *
>> +     * @throws ConcurrentModificationException if a structural change was
>> +     * detected while executing the mappingFunction
>> +     */
>>      @Override
>>      public V computeIfAbsent(K key,
>>                               Function<? super K, ? extends V>
>> mappingFunction) {
>> 
>> diff -r 330dcd651f3b
>> src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java
>> ---
>> a/src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java
>>     Mon Feb 02 12:35:18 2015 -0800
>> +++
>> b/src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java
>>     Fri Feb 06 12:49:19 2015 -0800
>> @@ -305,6 +305,8 @@
>>       * threads attempt updates including potentially calling the mapping
>>       * function multiple times.
>>       *
>> +     * <p>The mappingFunction itself should not make changes to this map.
>> +     *
>>       * <p>This implementation assumes that the ConcurrentMap cannot
>> contain null
>>       * values and {@code get()} returning null unambiguously means the
>> key is



From Roger.Riggs at Oracle.com  Tue Mar 10 15:41:38 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 10 Mar 2015 11:41:38 -0400
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>
	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>
Message-ID: <54FF10B2.4010605@Oracle.com>

Hi Paul,

On 3/10/2015 11:22 AM, Paul Sandoz wrote:
>
>>> Any sub-type of Process that does not override getPid will essentially result in that USO being propagated to many ProcessHandle methods that depend on the PID (parent, children, allChildren, info, compareTo). That effectively renders ProcessHandle almost useless for sub-types outside of our control that that not been updated.
>> For those methods, the default behavior can be specified, except for compareTo
>> they already have return values that allow for the fact that the information may
>> not be available, either due to OS restrictions (permissions) or is not provided.
>> Empty lists for children, nulls returned from info, and even allowing for an unavailable parent.
> That's a separate issue.
>
> If i get a ProcessHandle given to me, i do not know it's source, i dunno if it's gonna barf if i operate on it.
It can be a goal to never throw UOE, to achieve that, the behaviors of 
all of the methods
(of Process) would be defined to have outputs that have to be checked by 
the app;
hence the reference to nulls; empty lists, etc.

In many cases already, if the OS does not provide values or the OS 
permissions do not permit
it then the values returned are empty (instead of throwing exceptions).
That design can be extended to the external subclasses by specifying the 
default behavior
of Process and then defining the behaviors of Processes created by 
ProcessBuilder.

Roger



From baiduzhyi.devel at gmail.com  Tue Mar 10 16:18:06 2015
From: baiduzhyi.devel at gmail.com (Stanislav Baiduzhyi)
Date: Tue, 10 Mar 2015 17:18:06 +0100
Subject: RFR (XS) 8074761: Empty optional parameters of LDAP query are not
	interpreted as empty
Message-ID: <2031750.BZlfoUzYlO@thinkpad>

Hi All,

Please review the patch for LdapURL. Patch fixes the parsing of query part of 
LDAP URL, leaving empty optional fields as null instead of "".

Webrev:
http://goo.gl/OO0V38

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

JTreg:
http://goo.gl/ermmoh

Details:

RFC 2255 [1] allows any of the query parameters to be empty. Current 
implementation of parsing method extracts substring without checking for 
length, leaving empty fields as "" instead of null. But the code under 
com.sun.jndi.ldap package checks only for null when handling optional fields. 
So the patch modifies the parsing method to avoid substring operations on 
empty fields and leaving them as null instead.

In proposed patch, I was not able to generalize the code, so using similar 
code blocks to make it obvious if additional changes will be required later.

It would be even better to use java.util.Optional for this, but it will be 
compatibility-breaking change, I'm not sure it worth doing even under 
com.sun.* packages.

There is wider test case in RedHat Bugzilla [2], includes OpenDS setup and 
small client app, shows the difference in results between openldap-clients 
with Java-based implementation. Proposed patch fixes the java client 
behaviour.

[1]: https://tools.ietf.org/html/rfc2255#section-3
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1194226

-- 
Regards,
    Stas


From peter.levart at gmail.com  Tue Mar 10 16:37:42 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 10 Mar 2015 17:37:42 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>
	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>
	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>
Message-ID: <54FF1DD6.90603@gmail.com>

On 03/10/2015 10:50 AM, Paul Sandoz wrote:
> On Mar 6, 2015, at 7:58 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
>>> 2) I know there has been a lot of discussion about the use of CF,
>>>      but I have a few more comments:
>>>           a) Both onExit and onProcessExit are implemented to unconditionally
>>>          throw UOE. Is the intention to make the implementation of these
>>>          methods optional? If so, then UOE should be documented, If not,
>>>          then I think they can be abstract, right?
>> There are existing non-jdk implementations of Process and it would be source
>> incompatible if default implementations were not supplied.  So, not abstract.
>>
>> Since the behavior applies to Process, the note in the class documentation
>> defines the behavior.
>> "Methods of {@code Process} that are not otherwise specified or overridden throw
>> {@link java.lang.UnsupportedOperationException}."
>>
>> More direct documentation could be provided in the override of onExit
>> but that would raise the visibility to ordinary developers who should use
>> onProcessExit that returns the correctly typed CF and not onExit.
>> The note should be sufficient for implementers without distracting the ordinary developer.
>>
>> Perhaps, a description similar to that used in destroy(), the behavior of Processes
>> returned from ProcessBuilder can be more tightly specified. Alternatively,
>> ProcessBuilder could specify the behavior of Process instances it returns, at present,
>> the behavior of the Process instances is split between the two classes.
>>
> Throwing USO for default implementations is a warning sign to me that something does not fit quite right. It feels like we are giving up :-)

I concur. I think current ProcessHandle is a mix of specification and 
partial implementation that does not help in any way to hypothetical 
external implementations. It effectively disables any consistent 
alternative implementations. Take for example the following method in 
ProcessHandle:

     public final ProcessHandle parent() {
         return ProcessHandleImpl.parent(getPid());
     }

There's no way an alternative implementation of ProcessHandle could be 
created that returned alternative implementations using method parent(). 
What if alternative implementation doesn't support getPid()?

I think ProcessHandle should be mostly a specification and only have 
abstract methods. Only a method that does not depend on implementation 
could be concrete. I think it could be an interface. A package-private 
constructor does not help as there is a Process class that has a public 
constructor already, so anyone can create arbitrary instances of 
arbitrary subclass of Process which is-a ProcessHandle...

>
> I now see Process.getPid was previously added and it throws USO by default. So we might be stuck due to the tricky nature of this area.

Unfortunately. Default methods (in publicly extendable abstract classes 
and interfaces) can not provide new functionality. They can just re-pack 
existing functionality. getPid() is new functionality and so are all new 
methods of ProcessHandle that Process inherits from. So we can not just 
simply delegate to our implementation which might be incompatible 
(unsupported platform).

>
> Any sub-type of Process that does not override getPid will essentially result in that USO being propagated to many ProcessHandle methods that depend on the PID (parent, children, allChildren, info, compareTo). That effectively renders ProcessHandle almost useless for sub-types outside of our control that that not been updated.

So here's some changes I propose to the tip of JDK-8046092-branch that 
hopefully fix these issues:

http://cr.openjdk.java.net/~plevart/jdk9-sandbox/JDK-8046092-branch/webrev.02/

The changes are:
- Process.getPid() is back to throwing UOE if unsupported
- ProcessHandle is all-abstract interface (only allChildren() is a 
default method, since it is just a utility independent of implementation)
- ProcessHandle.compareTo() specifies that only same-implementations of 
ProcessHandle(s) are mutually comparable otherwise ClassCastException 
must be thrown
- ProcessHandleImpl.onExit() and ProcessImpl.onProcessExit() propagate 
error from waitForProcessExit0 native method as exceptional completion 
of CompletableFuture. exitValue is set to -1 on UNIX in this case 
(instead of 0). What's the exitStatus on Windows in this case? This area 
needs more work, I think.
- Some tweaks to javadocs in a few places

>
> Is it common to sub-type Process? If so then perhaps Process should not extend ProcessHandle and instead there should be a way to view a Process as a ProcessHandle, whose default implementation is:
>
>    return ProcessHandle.of(getPid()); // throws USO if getPid does
>
> (java.lang.ProcessImpl could implement Processhandle thereby the implementation is "return this".)
>
> Thus once you have a ProcessHandle instance (from whatever source) it's possible to operate on it without fear of a USO.
>
>
> A possible default implementation for Process.onProcessExit could be:
>
>    return CF.supplyAsync(() -> { this.waitFor(); return p}, cachedThreadPool);

It could be, but this would encourage external implementations to not 
override it and this implementation is not very efficient in terms of 
thread stack sizes. We could use a default implementation that is 
similar to Windows' ProcessImpl - only use waitFor() instead of 
ProcessHandleImpl.waitForProcessExit0() native method, but on UNIX 
waitFor() *is* implemented on top of this implementation, so I think the 
best is to force the implementor to do it optimally from the ground-up. 
Default methods should really be reserved for something very trivial 
that is not only implementation independent, but also equally efficient 
regardless of underlying implementation.

Regards, Peter

>
> Paul.



From j-f.savard at hotmail.com  Thu Mar  5 16:37:57 2015
From: j-f.savard at hotmail.com (=?iso-8859-1?B?SmVhbi1GcmFu529pcyBTYXZhcmQ=?=)
Date: Thu, 5 Mar 2015 11:37:57 -0500
Subject: Oddity in JDK 8
Message-ID: <BLU168-W31D49FE8ED563626AFA22BD31F0@phx.gbl>

Hi,I've noticed something odd in the JDK8 source code. I've asked the question on StackOverflow in the hope someone could answer, but it seems like no one is able to give me the right answer.However, since the question interested me a lot and seemed to interest a lot of people (as you can see on the post), I've decided to dig more into this. Unfortunately, I have not been able to come to a conclusion that would satisfy me.Would you please have a look at this question (it is well detailed and fast to read) : http://stackoverflow.com/questions/28770822/why-is-the-size-constant-only-native-for-integer-and-long ?Feel free to answer directly on the post if whoever receive these mails have an account on StackOverflow, else you can just answer here and I will be happy to share the knowledge with others (giving you credits for sure).Best regards,Jean-Fran?ois Savard. 		 	   		  

From j-f.savard at hotmail.com  Tue Mar 10 02:58:04 2015
From: j-f.savard at hotmail.com (=?iso-8859-1?B?SmVhbi1GcmFu529pcyBTYXZhcmQ=?=)
Date: Mon, 9 Mar 2015 22:58:04 -0400
Subject: Why is java.awt.image.BufferedImage not serializable ?
Message-ID: <BLU168-W90C3DBAF0F68664696D306D3180@phx.gbl>

Hi,

I believe java.awt.image.BufferedImage (and all java images type) are not serializable simply because it is illogical to serializable an Image file, as the point of serializing is to keep something as a file independent of the JVM. Which is already the case for a normal image file.
Would you please confirm ? 		 	   		  

From jsampson at guidewire.com  Sat Mar  7 00:41:45 2015
From: jsampson at guidewire.com (Justin Sampson)
Date: Sat, 7 Mar 2015 00:41:45 +0000
Subject: [concurrency-interest] Why not "weakNanoTime" for jdk9?
In-Reply-To: <54FA37C8.3090800@oracle.com>
References: <CA+kOe08ypd93wW4GrcwhUrzGsqx_DnEYXWG6pKnDhs5bHUfb2w@mail.gmail.com>
	<54FA0AA7.5090208@redhat.com> <54FA37C8.3090800@oracle.com>
Message-ID: <0FD072A166C6DC4C851F6115F37DDD279AEED75A@sm-ex-01-vm.guidewire.com>

Aleksey Shipilev wrote:

> It would really help if you list what problems weakNanoTime is
> supposed to solve.

I was talking to Martin about this idea recently so I'll take a shot
at describing why it's appealing to me (with the usual disclaimer
that I know I'm much less of an expert than most other folks here).

The main case I'm interested in is handling timeout calculations in
concurrent operations. The usual case should be that the operation
succeeds without timing out, and if it _does_ time out it's often
after waiting several seconds or minutes, in which case being off
by, say, a few microseconds is not a big deal.

Given those assumptions, we really want the usual case (success) to
be as fast as possible, and especially not to impose any additional
synchronization or volatile accesses. Since strict monotonicity
requires checking some kind of centrally synchronized clock state,
it fails that use case.

Furthermore, in this particular use case, it's trivial to have the
appearance of monotonicity _within_ a particular operation: Just
keep a local variable with the last time seen, and only update it if
the next time seen is greater than the last time seen. No extra
synchronization is required.

The semantics I'm imagining would be for a very fast timer that is
_usually_ monotonic, as long as the current thread stays on one
processor, with occasional blips when switching between processors.
We would still want those blips to be as small as practically
achievable, so I guess there would still have to be some occasional
synchronization to keep the fast timer within some tolerance of the
central system clock.

The way I see it, good concurrency semantics are about acknowledging
the reality of the hardware, and a strictly monotonic clock is
simply not the reality of the hardware when there's more than one
processor involved.

Actually, come to think of it, given an underlying non-monotonic
timer, the weakNanoTime method could easily provide monotonicity on
a per-thread basis without any synchronization overhead. That would
mean most concurrent code wouldn't even have to change to become
tolerant of non-monotonicity. It would just have to be made really
clear to users that different threads might see timer values out of
order relative to each other, though still within some best-effort
tolerance.

Cheers,
Justin

From peter.levart at gmail.com  Tue Mar 10 16:47:41 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 10 Mar 2015 17:47:41 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54FEF7BC.8050702@Oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>,
	<54DE1969.2040508@gmail.com> <54E393BC.4030600@Oracle.com>,
	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<BLU175-W460A71BD3351510864D3E0831C0@phx.gbl>	<54FD717C.1070500@oracle.com>
	<54FDAE15.8080606@Oracle.com>,
	<54FDB188.1000602@oracle.com>	<BLU175-W180FE85C6CA81825886349831B0@phx.gbl>
	<54FDEA81.70206@Oracle.com> <54FEB6B1.8080608@gmail.com>
	<54FEF7BC.8050702@Oracle.com>
Message-ID: <54FF202D.4060604@gmail.com>

On 03/10/2015 02:55 PM, Roger Riggs wrote:
> ProcessHandle is designed to not to have an external implementations 
> (the constructor is package private). 

I don't see a purpose in this. You can still subclass it freely, because 
you can subclass Process which is-a ProcessHandle. I think it can be an 
interface (see previous post).

For the same reason Process is designed to support custom/external 
implementations (for platforms not directly supported by Oracle, for 
example), there is a reason to support costom/external implementations 
of ProcessHandle. But we should not stop at what we have now. Instead of 
static factory methods creating just internal implementations, we could 
add a Process[Handle]Spi locatable via ServiceLoader to fully support 
external implementations for the whole API (static methods too). This 
can be added later if it is too much work for JDK9.

What do you think?

Regards, Peter



From brian.burkhalter at oracle.com  Tue Mar 10 16:59:02 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 10 Mar 2015 09:59:02 -0700
Subject: Why is java.awt.image.BufferedImage not serializable ?
In-Reply-To: <BLU168-W90C3DBAF0F68664696D306D3180@phx.gbl>
References: <BLU168-W90C3DBAF0F68664696D306D3180@phx.gbl>
Message-ID: <CDB961AB-E263-418F-AB81-7E7CF4C2A738@oracle.com>

Bonjour,

I think your question would be better directed to the 2d-dev list:

http://mail.openjdk.java.net/mailman/listinfo/2d-dev

Merci,

Brian

On Mar 9, 2015, at 7:58 PM, Jean-Fran?ois Savard <j-f.savard at hotmail.com> wrote:

> I believe java.awt.image.BufferedImage (and all java images type) are not serializable simply because it is illogical to serializable an Image file, as the point of serializing is to keep something as a file independent of the JVM. Which is already the case for a normal image file.
> Would you please confirm ?



From Roger.Riggs at Oracle.com  Tue Mar 10 17:27:52 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 10 Mar 2015 13:27:52 -0400
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54FF1DD6.90603@gmail.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>
	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>
	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>
	<54FF1DD6.90603@gmail.com>
Message-ID: <54FF2998.8080306@Oracle.com>

Hi Peter,

Differing design approaches...

On 3/10/2015 12:37 PM, Peter Levart wrote:
> On 03/10/2015 10:50 AM, Paul Sandoz wrote:
>> On Mar 6, 2015, at 7:58 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
>>>> 2) I know there has been a lot of discussion about the use of CF,
>>>>      but I have a few more comments:
>>>>           a) Both onExit and onProcessExit are implemented to 
>>>> unconditionally
>>>>          throw UOE. Is the intention to make the implementation of 
>>>> these
>>>>          methods optional? If so, then UOE should be documented, If 
>>>> not,
>>>>          then I think they can be abstract, right?
>>> There are existing non-jdk implementations of Process and it would 
>>> be source
>>> incompatible if default implementations were not supplied. So, not 
>>> abstract.
>>>
>>> Since the behavior applies to Process, the note in the class 
>>> documentation
>>> defines the behavior.
>>> "Methods of {@code Process} that are not otherwise specified or 
>>> overridden throw
>>> {@link java.lang.UnsupportedOperationException}."
>>>
>>> More direct documentation could be provided in the override of onExit
>>> but that would raise the visibility to ordinary developers who 
>>> should use
>>> onProcessExit that returns the correctly typed CF and not onExit.
>>> The note should be sufficient for implementers without distracting 
>>> the ordinary developer.
>>>
>>> Perhaps, a description similar to that used in destroy(), the 
>>> behavior of Processes
>>> returned from ProcessBuilder can be more tightly specified. 
>>> Alternatively,
>>> ProcessBuilder could specify the behavior of Process instances it 
>>> returns, at present,
>>> the behavior of the Process instances is split between the two classes.
>>>
>> Throwing USO for default implementations is a warning sign to me that 
>> something does not fit quite right. It feels like we are giving up :-)
>
> I concur. I think current ProcessHandle is a mix of specification and 
> partial implementation that does not help in any way to hypothetical 
> external implementations. It effectively disables any consistent 
> alternative implementations. Take for example the following method in 
> ProcessHandle:
>
>     public final ProcessHandle parent() {
>         return ProcessHandleImpl.parent(getPid());
>     }
ProcessHandle is not intended to be *externally* extended; as an 
interface or abstract class
it can not make *any* guarantees about the implementation.
No caller can depend on any of the behavior based on the compile time type.
With the changes proposed, the callers using ProcessHandle must be 
prepared to handle UOE
in addition to dealing with the normal absent or missing information 
from the OS.

We should not open up another hole like Process without fully understanding
the use cases and the requirements on extensibility.  There may be a 
middle ground
that leaves the door open but not to start with.
>
> There's no way an alternative implementation of ProcessHandle could be 
> created that returned alternative implementations using method 
> parent(). What if alternative implementation doesn't support getPid()?
I have not considered supporting alternate implementations a goal but 
not breaking existing ones is essential.
>
> I think ProcessHandle should be mostly a specification and only have 
> abstract methods. Only a method that does not depend on implementation 
> could be concrete. I think it could be an interface. A package-private 
> constructor does not help as there is a Process class that has a 
> public constructor already, so anyone can create arbitrary instances 
> of arbitrary subclass of Process which is-a ProcessHandle...
Most of the behavior of ProcessHandle (as is Process) *is* 
implementation specific due to the OS dependencies.
When every function bottoms out in OS behavior, the layers above are 
dependent too.
>
>>
>> I now see Process.getPid was previously added and it throws USO by 
>> default. So we might be stuck due to the tricky nature of this area.
>
> Unfortunately. Default methods (in publicly extendable abstract 
> classes and interfaces) can not provide new functionality. They can 
> just re-pack existing functionality. getPid() is new functionality and 
> so are all new methods of ProcessHandle that Process inherits from. So 
> we can not just simply delegate to our implementation which might be 
> incompatible (unsupported platform).
Yes, but to support source level compatibility; some implementation is 
needed; though it cannot provide the full functionality.
>
>>
>> Any sub-type of Process that does not override getPid will 
>> essentially result in that USO being propagated to many ProcessHandle 
>> methods that depend on the PID (parent, children, allChildren, info, 
>> compareTo). That effectively renders ProcessHandle almost useless for 
>> sub-types outside of our control that that not been updated.
>
> So here's some changes I propose to the tip of JDK-8046092-branch that 
> hopefully fix these issues:
>
> http://cr.openjdk.java.net/~plevart/jdk9-sandbox/JDK-8046092-branch/webrev.02/ 
>
>
> The changes are:
> - Process.getPid() is back to throwing UOE if unsupported
> - ProcessHandle is all-abstract interface (only allChildren() is a 
> default method, since it is just a utility independent of implementation)
I considered 'abstract' in the PH API to be a distraction unless the API 
was intended to be extensible.

> - ProcessHandle.compareTo() specifies that only same-implementations 
> of ProcessHandle(s) are mutually comparable otherwise 
> ClassCastException must be thrown
Yes, avoids the issue with UOE.
> - ProcessHandleImpl.onExit() and ProcessImpl.onProcessExit() propagate 
> error from waitForProcessExit0 native method as exceptional completion 
> of CompletableFuture. exitValue is set to -1 on UNIX in this case 
> (instead of 0). What's the exitStatus on Windows in this case? This 
> area needs more work, I think.
The exceptional case was removed because the waitForExit does not throw 
an exception.
The only exception from Process.waitFor is InterruptedException and 
since there might
be spurious exceptions it should be retried.

When waitForProcessExit0 returns the process is gone; and the CF can be 
completed.

> - Some tweaks to javadocs in a few places
>
>>
>> Is it common to sub-type Process? If so then perhaps Process should 
>> not extend ProcessHandle and instead there should be a way to view a 
>> Process as a ProcessHandle, whose default implementation is:
>>
>>    return ProcessHandle.of(getPid()); // throws USO if getPid does
>>
>> (java.lang.ProcessImpl could implement Processhandle thereby the 
>> implementation is "return this".)
>>
>> Thus once you have a ProcessHandle instance (from whatever source) 
>> it's possible to operate on it without fear of a USO.
>>
>>
>> A possible default implementation for Process.onProcessExit could be:
>>
>>    return CF.supplyAsync(() -> { this.waitFor(); return p}, 
>> cachedThreadPool);
>
> It could be, but this would encourage external implementations to not 
> override it and this implementation is not very efficient in terms of 
> thread stack sizes. We could use a default implementation that is 
> similar to Windows' ProcessImpl - only use waitFor() instead of 
> ProcessHandleImpl.waitForProcessExit0() native method, but on UNIX 
> waitFor() *is* implemented on top of this implementation, so I think 
> the best is to force the implementor to do it optimally from the 
> ground-up. Default methods should really be reserved for something 
> very trivial that is not only implementation independent, but also 
> equally efficient regardless of underlying implementation.
Without external implementations, the code moved up from ProcessImpl and 
ProcessHandleImpl classes
to the abstract class to avoid duplication in the subclasses.
If external implementations of PH were a factor, the duplication would 
be more reasonable.

Thanks, Roger




From Roger.Riggs at Oracle.com  Tue Mar 10 17:32:44 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 10 Mar 2015 13:32:44 -0400
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54FF202D.4060604@gmail.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>,
	<54DE1969.2040508@gmail.com> <54E393BC.4030600@Oracle.com>,
	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<BLU175-W460A71BD3351510864D3E0831C0@phx.gbl>	<54FD717C.1070500@oracle.com>
	<54FDAE15.8080606@Oracle.com>,
	<54FDB188.1000602@oracle.com>	<BLU175-W180FE85C6CA81825886349831B0@phx.gbl>
	<54FDEA81.70206@Oracle.com> <54FEB6B1.8080608@gmail.com>
	<54FEF7BC.8050702@Oracle.com> <54FF202D.4060604@gmail.com>
Message-ID: <54FF2ABC.6060107@Oracle.com>

Hi Peter,

On 3/10/2015 12:47 PM, Peter Levart wrote:
> On 03/10/2015 02:55 PM, Roger Riggs wrote:
>> ProcessHandle is designed to not to have an external implementations 
>> (the constructor is package private). 
>
> I don't see a purpose in this. You can still subclass it freely, 
> because you can subclass Process which is-a ProcessHandle. I think it 
> can be an interface (see previous post).
Creating subclasses for the purposes of Process is not an issue, but 
together
with maintaining source compatibility and avoiding UOEs to the unsuspecting
holder of a ProcessHandle it seemed prudent to keep the exposure to a 
minimum.

(The JEP was not scoped that broadly).
>
> For the same reason Process is designed to support custom/external 
> implementations (for platforms not directly supported by Oracle, for 
> example), there is a reason to support costom/external implementations 
> of ProcessHandle. But we should not stop at what we have now. Instead 
> of static factory methods creating just internal implementations, we 
> could add a Process[Handle]Spi locatable via ServiceLoader to fully 
> support external implementations for the whole API (static methods 
> too). This can be added later if it is too much work for JDK9.
Can you point me to the alternative Process implementations outside the 
JDK?
I've seen a bit of flak about it not being the right API and if its not 
right
we should not extend it.

Roger

>
> What do you think?
>
> Regards, Peter
>



From joe.darcy at oracle.com  Tue Mar 10 18:12:21 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 10 Mar 2015 11:12:21 -0700
Subject: JDK 9 RFR of JDK-8074870: Really add javax/xml/jaxp/testng/validation
	to othervm.dirs in TEST.ROOT
Message-ID: <54FF3405.606@oracle.com>

Hello,

Recently I sent out a review for

     JDK-8074714 : Add javax/xml/jaxp/testng/validation to othervm.dirs 
in TEST.ROOT
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032151.html

However, I actually added the directory in question to the 
exclusiveAccess.dirs property rather than the othervm.dirs property. (Doh!)

Please review the patch below to remove javax/xml/jaxp/testng/validation 
from exclusiveAccess.dirs and put it on othervm.dirs, as originally 
intended.

Thanks,

-Joe

--- old/test/TEST.ROOT    2015-03-10 11:07:18.027225609 -0700
+++ new/test/TEST.ROOT    2015-03-10 11:07:17.843225610 -0700
@@ -5,10 +5,10 @@
  keys=2d dnd i18n

  # Tests that must run in othervm mode
-othervm.dirs=java/awt java/beans javax/accessibility javax/imageio 
javax/sound javax/print javax/management com/sun/awt sun/awt sun/java2d 
sun/pisce
s
+othervm.dirs=java/awt java/beans javax/accessibility javax/imageio 
javax/sound javax/print javax/management com/sun/awt sun/awt sun/java2d 
sun/pisce
s javax/xml/jaxp/testng/validation

  # Tests that cannot run concurrently
-exclusiveAccess.dirs=java/rmi/Naming java/util/prefs 
sun/management/jmxremote sun/tools/jstatd sun/security/mscapi 
java/util/stream javax/xml/jaxp/t
estng/validation
+exclusiveAccess.dirs=java/rmi/Naming java/util/prefs 
sun/management/jmxremote sun/tools/jstatd sun/security/mscapi 
java/util/stream

  # Group definitions
  groups=TEST.groups [closed/TEST.groups]



From sandhya.viswanathan at intel.com  Tue Mar 10 18:39:15 2015
From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya)
Date: Tue, 10 Mar 2015 18:39:15 +0000
Subject: Compression acceleration for Java
In-Reply-To: <54FAC5A1.3020409@oracle.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B6331E0A4@FMSMSX112.amr.corp.intel.com>
	<54FAC5A1.3020409@oracle.com>
Message-ID: <02FCFB8477C4EF43A2AD8E0C60F3DA2B63320917@FMSMSX112.amr.corp.intel.com>


Yes, it will be nice if the OpenJDK and Oracle builds for Linux/Solaris used the system rather than 
the bundled zlib. In which case, there will be no need for JVM command line option. Also the HW/SW 
compression accelerators can then be used easily with Java. Is it possible to get this feature in JDK9?

Thanks,
Sandhya

-----Original Message-----
From: Alan Bateman [mailto:Alan.Bateman at oracle.com] 
Sent: Saturday, March 07, 2015 1:32 AM
To: Viswanathan, Sandhya; core-libs-dev at openjdk.java.net
Subject: Re: Compression acceleration for Java

On 07/03/2015 01:19, Viswanathan, Sandhya wrote:
> Hi All,
>
> This is a request for support in JVM to use system zlib or alternative implementations of zlib.
>
> Compression is heavily used in Java based big data, genomics and middleware applications. There are many products in market today which help in compression performance either through software or hardware acceleration. Intel has faster compression libraries as part of IPP and also there are hardware compression accelerator products from Intel. Both of these products are available in the market today and support the zlib interface as an API. Support in the JVM to use system zlib on a JVM command line option would make these acceleration capabilities available to Linux java users through java.util.zip.
> The JVM could support this on an option UseSystemZlib which can be set to false by default. When the option is set to true on command line by the user, the load_zip_library() function in classLoader.cpp can load libszip.so instead of libzip.so. Also the JVM can set the java.util.zip.UseSystemZlib property accordingly.
>
> The JDK would need to include two libraries for zip in jre/lib/amd64: libzip.so and libszip.so. The libzip.so will be built as before with statically linking system zlib with it and libszip.so will be built without statically linking system zlib with it. Also the java.lang.System.initializeSystemClass will load libzip.so or libszip.so based on the java.util.zip.UseSystemZlib property.
>
> The users can then use system zlib by including the -XX:+UseSystemZlib option on the command line and compression accelerators by setting the LD_LIBRARY_PATH and LD_PRELOAD appropriately.
>
> I am very interested to know your thoughts on this feature support.
>
You may know this already but there is a configure option to use the 
system zlib (configure --with-zlib=system). I will assume that if you 
build with this option and run with LD_* set to the IPP libraries then 
it should work.

That said, I think your mail is timely as we do need to re-examine how 
zlib is used. It would be nice if the build used the system rather than 
the bundled zlib when building on Linux and Solaris (OS X already uses 
the system zlib). Ditto for Oracle builds. That would avoid needing to 
split libzip and avoid needing to introduce a runtime option to select 
between the bundled and system zlib.

Another long standing suggestion is to just move to a pure java 
implementation, something that Sherman Shen prototyped some time ago and 
mentioned in a recent thread here on memory mapping the zip central 
directory. If we were to go down that route then use of zlib couldn't be 
dropped completely, I think it would still be needed for HotSpot to 
support -Xbootclasspath/a and the JVM TI agent equivalent (with the JEP 
220 work then rt.jar/friends go away so HotSpot only rarely needs to 
call into libzip now). Moving to a pure java implementation might nobble 
your proposal of course but it might open other opportunities for the 
compiler.

-Alan


From xueming.shen at oracle.com  Tue Mar 10 18:52:44 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 10 Mar 2015 11:52:44 -0700
Subject: Compression acceleration for Java
In-Reply-To: <02FCFB8477C4EF43A2AD8E0C60F3DA2B63320917@FMSMSX112.amr.corp.intel.com>
References: <02FCFB8477C4EF43A2AD8E0C60F3DA2B6331E0A4@FMSMSX112.amr.corp.intel.com>	<54FAC5A1.3020409@oracle.com>
	<02FCFB8477C4EF43A2AD8E0C60F3DA2B63320917@FMSMSX112.amr.corp.intel.com>
Message-ID: <54FF3D7C.5060209@oracle.com>

We can/should/will do it.

-Sherman

On 03/10/2015 11:39 AM, Viswanathan, Sandhya wrote:
> Yes, it will be nice if the OpenJDK and Oracle builds for Linux/Solaris used the system rather than
> the bundled zlib. In which case, there will be no need for JVM command line option. Also the HW/SW
> compression accelerators can then be used easily with Java. Is it possible to get this feature in JDK9?
>
> Thanks,
> Sandhya
>
> -----Original Message-----
> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
> Sent: Saturday, March 07, 2015 1:32 AM
> To: Viswanathan, Sandhya; core-libs-dev at openjdk.java.net
> Subject: Re: Compression acceleration for Java
>
> On 07/03/2015 01:19, Viswanathan, Sandhya wrote:
>> Hi All,
>>
>> This is a request for support in JVM to use system zlib or alternative implementations of zlib.
>>
>> Compression is heavily used in Java based big data, genomics and middleware applications. There are many products in market today which help in compression performance either through software or hardware acceleration. Intel has faster compression libraries as part of IPP and also there are hardware compression accelerator products from Intel. Both of these products are available in the market today and support the zlib interface as an API. Support in the JVM to use system zlib on a JVM command line option would make these acceleration capabilities available to Linux java users through java.util.zip.
>> The JVM could support this on an option UseSystemZlib which can be set to false by default. When the option is set to true on command line by the user, the load_zip_library() function in classLoader.cpp can load libszip.so instead of libzip.so. Also the JVM can set the java.util.zip.UseSystemZlib property accordingly.
>>
>> The JDK would need to include two libraries for zip in jre/lib/amd64: libzip.so and libszip.so. The libzip.so will be built as before with statically linking system zlib with it and libszip.so will be built without statically linking system zlib with it. Also the java.lang.System.initializeSystemClass will load libzip.so or libszip.so based on the java.util.zip.UseSystemZlib property.
>>
>> The users can then use system zlib by including the -XX:+UseSystemZlib option on the command line and compression accelerators by setting the LD_LIBRARY_PATH and LD_PRELOAD appropriately.
>>
>> I am very interested to know your thoughts on this feature support.
>>
> You may know this already but there is a configure option to use the
> system zlib (configure --with-zlib=system). I will assume that if you
> build with this option and run with LD_* set to the IPP libraries then
> it should work.
>
> That said, I think your mail is timely as we do need to re-examine how
> zlib is used. It would be nice if the build used the system rather than
> the bundled zlib when building on Linux and Solaris (OS X already uses
> the system zlib). Ditto for Oracle builds. That would avoid needing to
> split libzip and avoid needing to introduce a runtime option to select
> between the bundled and system zlib.
>
> Another long standing suggestion is to just move to a pure java
> implementation, something that Sherman Shen prototyped some time ago and
> mentioned in a recent thread here on memory mapping the zip central
> directory. If we were to go down that route then use of zlib couldn't be
> dropped completely, I think it would still be needed for HotSpot to
> support -Xbootclasspath/a and the JVM TI agent equivalent (with the JEP
> 220 work then rt.jar/friends go away so HotSpot only rarely needs to
> call into libzip now). Moving to a pure java implementation might nobble
> your proposal of course but it might open other opportunities for the
> compiler.
>
> -Alan



From peter.levart at gmail.com  Tue Mar 10 18:57:09 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 10 Mar 2015 19:57:09 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54FF2998.8080306@Oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>
	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>
	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>
	<54FF1DD6.90603@gmail.com> <54FF2998.8080306@Oracle.com>
Message-ID: <54FF3E85.4020701@gmail.com>

Hi Roger,

Thanks for bearing with me...

On 03/10/2015 06:27 PM, Roger Riggs wrote:
>> I think current ProcessHandle is a mix of specification and partial 
>> implementation that does not help in any way to hypothetical external 
>> implementations. It effectively disables any consistent alternative 
>> implementations. Take for example the following method in ProcessHandle:
>>
>>     public final ProcessHandle parent() {
>>         return ProcessHandleImpl.parent(getPid());
>>     }
> ProcessHandle is not intended to be *externally* extended; as an 
> interface or abstract class

But Process is, and Process inherits methods from ProcessHandle which 
means that you are limiting external implementations of Process forever 
to status-quo functionality. Why not let the implementor of external 
Process implementation decide whether it needs or wants to implement 
this new functionality or not. Are you afraid that implementations will 
emerge, but will not be of enough quality because of impedance missmatch 
between the API and the target platform? Or are you afraid that it will 
be harder to support new additions to this API if there are external 
implementations created?

>
> it can not make *any* guarantees about the implementation.
> No caller can depend on any of the behavior based on the compile time 
> type.
> With the changes proposed, the callers using ProcessHandle must be 
> prepared to handle UOE
> in addition to dealing with the normal absent or missing information 
> from the OS.

So let's say the caller is on a platform that is not supported by JDK 
internal ProcessHandle implementation. What guarantees does 
ProcessHandle implementation give him? It think he's in better position 
if he must cope with differences than he is if he can't use the API at all.

UOE from getPid() is just a form of absent information. It could be -1.

>
> We should not open up another hole like Process without fully 
> understanding
> the use cases and the requirements on extensibility.  There may be a 
> middle ground
> that leaves the door open but not to start with.

The hole is already open. Some external implementation of Process can 
already attempt to implement all the ProcessHandle instance API merely 
by subclassing the Process. Package-private constructor on ProcessHandle 
will not stop that. Final methods will though.

>>
>> There's no way an alternative implementation of ProcessHandle could 
>> be created that returned alternative implementations using method 
>> parent(). What if alternative implementation doesn't support getPid()?
> I have not considered supporting alternate implementations a goal but 
> not breaking existing ones is essential.

Well, I don't see anything existing is broken if ProcessHandle doesn't 
impose final methods.

>>
>> I think ProcessHandle should be mostly a specification and only have 
>> abstract methods. Only a method that does not depend on 
>> implementation could be concrete. I think it could be an interface. A 
>> package-private constructor does not help as there is a Process class 
>> that has a public constructor already, so anyone can create arbitrary 
>> instances of arbitrary subclass of Process which is-a ProcessHandle...
> Most of the behavior of ProcessHandle (as is Process) *is* 
> implementation specific due to the OS dependencies.
> When every function bottoms out in OS behavior, the layers above are 
> dependent too.

So this is a question of: "Is ProcessHandle API suitable for other 
implementations or is it just for supported UNIX/Windows platforms", right?

Because technically it could be exposed as externally implementable with 
no backwards compatibility problems when 1st introduced. There might be 
problems later when extending it.

>>
>>>
>>> I now see Process.getPid was previously added and it throws USO by 
>>> default. So we might be stuck due to the tricky nature of this area.
>>
>> Unfortunately. Default methods (in publicly extendable abstract 
>> classes and interfaces) can not provide new functionality. They can 
>> just re-pack existing functionality. getPid() is new functionality 
>> and so are all new methods of ProcessHandle that Process inherits 
>> from. So we can not just simply delegate to our implementation which 
>> might be incompatible (unsupported platform).
> Yes, but to support source level compatibility; some implementation is 
> needed; though it cannot provide the full functionality.

There's no source-level compatibility issue with ProcessHandle as it is 
new class or interface. Just with Process. And even with my changes, the 
source-level compatibility is maintained. Can you spot anything that is 
not source-compatible or does not behave like it used to? It actually 
behaves exactly like it behaves with your latest implementation when 
default Process.getPid() throws UOE. The only difference is that 
ProcessHandle is made extensible.

>>
>>>
>>> Any sub-type of Process that does not override getPid will 
>>> essentially result in that USO being propagated to many 
>>> ProcessHandle methods that depend on the PID (parent, children, 
>>> allChildren, info, compareTo). That effectively renders 
>>> ProcessHandle almost useless for sub-types outside of our control 
>>> that that not been updated.
>>
>> So here's some changes I propose to the tip of JDK-8046092-branch 
>> that hopefully fix these issues:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-sandbox/JDK-8046092-branch/webrev.02/ 
>>
>>
>> The changes are:
>> - Process.getPid() is back to throwing UOE if unsupported
>> - ProcessHandle is all-abstract interface (only allChildren() is a 
>> default method, since it is just a utility independent of 
>> implementation)
> I considered 'abstract' in the PH API to be a distraction unless the 
> API was intended to be extensible.

Well in that case, yes. But why is it ProcessHandle then split between 
ProcessHandle and ProcessHandleImpl? Isn't that a distraction too?

>
>> - ProcessHandle.compareTo() specifies that only same-implementations 
>> of ProcessHandle(s) are mutually comparable otherwise 
>> ClassCastException must be thrown
> Yes, avoids the issue with UOE.
>> - ProcessHandleImpl.onExit() and ProcessImpl.onProcessExit() 
>> propagate error from waitForProcessExit0 native method as exceptional 
>> completion of CompletableFuture. exitValue is set to -1 on UNIX in 
>> this case (instead of 0). What's the exitStatus on Windows in this 
>> case? This area needs more work, I think.
> The exceptional case was removed because the waitForExit does not 
> throw an exception.
> The only exception from Process.waitFor is InterruptedException and 
> since there might
> be spurious exceptions it should be retried.
>
> When waitForProcessExit0 returns the process is gone; and the CF can 
> be completed.

So there's no error condition from waitForProcessExit0() then. Any 
return *is* exitValue(). I haven't checked the native implementations 
and just relied on comments in Java code.

>
>> - Some tweaks to javadocs in a few places
>>
>>>
>>> Is it common to sub-type Process? If so then perhaps Process should 
>>> not extend ProcessHandle and instead there should be a way to view a 
>>> Process as a ProcessHandle, whose default implementation is:
>>>
>>>    return ProcessHandle.of(getPid()); // throws USO if getPid does
>>>
>>> (java.lang.ProcessImpl could implement Processhandle thereby the 
>>> implementation is "return this".)
>>>
>>> Thus once you have a ProcessHandle instance (from whatever source) 
>>> it's possible to operate on it without fear of a USO.
>>>
>>>
>>> A possible default implementation for Process.onProcessExit could be:
>>>
>>>    return CF.supplyAsync(() -> { this.waitFor(); return p}, 
>>> cachedThreadPool);
>>
>> It could be, but this would encourage external implementations to not 
>> override it and this implementation is not very efficient in terms of 
>> thread stack sizes. We could use a default implementation that is 
>> similar to Windows' ProcessImpl - only use waitFor() instead of 
>> ProcessHandleImpl.waitForProcessExit0() native method, but on UNIX 
>> waitFor() *is* implemented on top of this implementation, so I think 
>> the best is to force the implementor to do it optimally from the 
>> ground-up. Default methods should really be reserved for something 
>> very trivial that is not only implementation independent, but also 
>> equally efficient regardless of underlying implementation.
> Without external implementations, the code moved up from ProcessImpl 
> and ProcessHandleImpl classes
> to the abstract class to avoid duplication in the subclasses.

ProcesshandleImpl and Windows ProcessImpl can have same code, but UNIX 
ProcessImpl must additionally synchronize using waitFor() since on UNIX, 
extitValue() result is published by the continuation of completion() 
which can execute concurrently with asynchronous continuation of same 
completion() that completes user-visible CompletableFuture. There's no 
harm if synchronization using waitFor() is used in ProcesshandleImpl and 
Windows ProcessImpl too, but that's unneeded overhead.

Regards, Peter

> If external implementations of PH were a factor, the duplication would 
> be more reasonable.
>
> Thanks, Roger
>



From aph at redhat.com  Tue Mar 10 19:02:05 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 10 Mar 2015 19:02:05 +0000
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <54EB6DD1.4090803@redhat.com>
References: <54EB6DD1.4090803@redhat.com>
Message-ID: <54FF3FAD.5040702@redhat.com>

I've been measuring the performance after this patch, and as you
might expect it's always much better with UseUnalignedAccesses.

However, we can sometimes get performance regressions, albeit in some
fairly contrived cases.

I have a test which repeatedly loads a {long,int,short} at some random
offset in a ByteBuffer, XORs some random value into it, and stores the
result back in the same place.  This ByteBuffer is 1k long, so fits
nicely into L1 cache.

The old algorithm always loads and stores a long as 8 bytes.

The new algorithm does an N-way branch, always loading and storing
subwords according to their natural alignment.  So, if the address is
random and the size is long it will access 8 bytes 50% of the time, 4
shorts 25% of the time, 2 ints 12.5% of the time, and 1 long 12.5% of
the time.  So, for every random load/store we have a 4-way branch.

The new algorithm is slightly slower because of branch misprediction.

old:  2.17 IPC, 0.08% branch-misses, 91,965,281,215 cycles
new:  1.23 IPC, 6.11% branch-misses, 99,925,255,682 cycles

...but it executes fewer instructions so we're only talking about
some 10% slowdown.  I think this is the worst case (or something
close to the worst case) for the new algorithm.

So, I think we're OK performance-wise.


John: I'm waiting for an answer to my question here before I submit
a webrev for approval.

http://mail.openjdk.java.net/pipermail/panama-dev/2015-March/000099.html

Andrew.



From martinrb at google.com  Tue Mar 10 19:06:38 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 10 Mar 2015 12:06:38 -0700
Subject: RFR: JDK-8074578 Document memory visibility effects of some
	Unsafe methods
In-Reply-To: <54FE9DDA.8030301@redhat.com>
References: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>
	<54FCEA87.3030509@oracle.com> <54FD6767.8020506@redhat.com>
	<54FD8059.9050205@oracle.com>
	<CA+kOe0-NSsfYwDE6xzquWAe9OVhx389tX27vo5_DUpUSdTEpeQ@mail.gmail.com>
	<54FE4943.1030008@oracle.com> <54FE9DDA.8030301@redhat.com>
Message-ID: <CA+kOe08JzETEdOR0twbRc5h3RfkZL007iaBEagZYniaR3GVXbA@mail.gmail.com>

I agree with Andrew that the Unsafe API matters, and there are many
implementations of it (even multiple within openjdk itself!).

I still know of no reason why my proposed spec is wrong.  If C11 support
was good and ubiquitous, I would recommend using atomic_compare_exchange_strong
or C++ equivalent in the hotspot implementation instead of fences as is
done now.

If you think you can write a better spec, please share!

---

It occurs to me that the
Memory Consistency Properties
section of the j.u.c. package specs only talk about happens-before, but
that should be strengthened to "Synchronization actions" which have a total
order.
http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.4



On Tue, Mar 10, 2015 at 12:31 AM, Andrew Haley <aph at redhat.com> wrote:

> On 10/03/15 01:30, David Holmes wrote:
> > On 10/03/2015 2:21 AM, Martin Buchholz wrote:
> >> On Mon, Mar 9, 2015 at 4:13 AM, David Holmes <david.holmes at oracle.com
> >> <mailto:david.holmes at oracle.com>> wrote:
> >>
> >>     On 9/03/2015 7:27 PM, Andrew Haley wrote:
> >>
> >>
> >>     But who is to say that is the specification for the Unsafe API?
> >>
> >>
> >> It's for us to say!
> >
> > I meant specifically the choice of the specification, not the right to
> > suggest one.
> >
> >>     The public API's have a specification for what they provide to the
> >>     programmer. On what basis are we assigning that same specification
> >>     to Unsafe API? The Unsafe API has to meet the requirements of the
> >>     public APIs that use it, but that doesn't  mean it necessarily
> >>     should have the same specification as those APIs.
> >>
> >>
> >> We already have lots of code that implicitly depends on volatile
> >> read/write visibility, especially in j.u.c.
> >> Most obviously, how do you implement compareAndSet methods without the
> >> same visibility guarantees on the Unsafe equivalents?
> >
> > Obviously Unsafe has to be implemented in a way that satisfies the j.u.c
> > routines that use it.
> >
> >> My spec change only documents what "everyone already knows to be true".
> >> Another way of looking at it is that the Unsafe methods are a low-level
> >> optimization of the equivalent j.u.c.a. objects without requiring memory
> >> allocation.
> >
> > The public API methods specify memory ordering semantics so that the
> > end programmer can use those to reason about their use of j.u.c
> > components.
> >
> > The implementation of j.u.c has to satisfy its specified semantics.
> >
> > The current implementation of j.u.c uses Unsafe operations that in
> > turn utilize JVM operations. The JVM operations have memory
> > synchronization affects that are stronger than required by j.u.c,
> > and so satisfy them.
> >
> > So the question is: should Unsafe specify the expectations of its
> > j.u.c client (what you propose); or should it specify what the JVM
> > implementations provide; or should it not actually specify anything
> > in this regard knowing that the implementation is required to
> > correctly implement the public APIs?
>
> Unsafe is an API, so should be specified.  (Whether it's really a
> public API has been a matter of some controversy, and people certainly
> have treated it as though it were one!)  There is more than one
> implementation of some of these methods, and some architectures
> (AArch64 is the one I care about the most) have instructions which
> implement the JMM requirements perfectly but not anything stronger.
> If we were to adopt a stronger API for Unsafe that would slow down
> such platforms.
>
> > I don't see much point in pushing down the spec from the public APIs
> > to the Unsafe API. To me it suffices to say that the Unsafe methods
> > must correctly implement the requirements of the public API without
> > specifying that in specific terms of volatile read/writes (which it
> > doesn't actually use) or full bi-directional fences (which it does
> > use).
>
> It certainly can use volatile read/writes and I would very much like
> that to happen (at least on AArch64) before JDK9 is released.
>
> > It's not as if Unsafe were a public API for which we might switch in
> > implementations from different providers and hence we need a clear
> > specification for those implementors to follow.
>
> Yes it is!  There are other Java VMs which use the OpenJDK class
> library, and they will probably have their own Unsafe builtins.
>
> Andrew.
>


From Roger.Riggs at Oracle.com  Tue Mar 10 19:13:44 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 10 Mar 2015 15:13:44 -0400
Subject: JDK 9 RFR of JDK-8074870: Really add
	javax/xml/jaxp/testng/validation to othervm.dirs in TEST.ROOT
In-Reply-To: <54FF3405.606@oracle.com>
References: <54FF3405.606@oracle.com>
Message-ID: <54FF4268.6050203@Oracle.com>

Hi Joe,

Looks fine.

Roger


On 3/10/2015 2:12 PM, joe darcy wrote:
> Hello,
>
> Recently I sent out a review for
>
>     JDK-8074714 : Add javax/xml/jaxp/testng/validation to othervm.dirs 
> in TEST.ROOT
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032151.html 
>
>
> However, I actually added the directory in question to the 
> exclusiveAccess.dirs property rather than the othervm.dirs property. 
> (Doh!)
>
> Please review the patch below to remove 
> javax/xml/jaxp/testng/validation from exclusiveAccess.dirs and put it 
> on othervm.dirs, as originally intended.
>
> Thanks,
>
> -Joe
>
> --- old/test/TEST.ROOT    2015-03-10 11:07:18.027225609 -0700
> +++ new/test/TEST.ROOT    2015-03-10 11:07:17.843225610 -0700
> @@ -5,10 +5,10 @@
>  keys=2d dnd i18n
>
>  # Tests that must run in othervm mode
> -othervm.dirs=java/awt java/beans javax/accessibility javax/imageio 
> javax/sound javax/print javax/management com/sun/awt sun/awt 
> sun/java2d sun/pisce
> s
> +othervm.dirs=java/awt java/beans javax/accessibility javax/imageio 
> javax/sound javax/print javax/management com/sun/awt sun/awt 
> sun/java2d sun/pisce
> s javax/xml/jaxp/testng/validation
>
>  # Tests that cannot run concurrently
> -exclusiveAccess.dirs=java/rmi/Naming java/util/prefs 
> sun/management/jmxremote sun/tools/jstatd sun/security/mscapi 
> java/util/stream javax/xml/jaxp/t
> estng/validation
> +exclusiveAccess.dirs=java/rmi/Naming java/util/prefs 
> sun/management/jmxremote sun/tools/jstatd sun/security/mscapi 
> java/util/stream
>
>  # Group definitions
>  groups=TEST.groups [closed/TEST.groups]
>



From peter.levart at gmail.com  Tue Mar 10 19:44:37 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 10 Mar 2015 20:44:37 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54FF2ABC.6060107@Oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>,
	<54DE1969.2040508@gmail.com> <54E393BC.4030600@Oracle.com>,
	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<BLU175-W460A71BD3351510864D3E0831C0@phx.gbl>	<54FD717C.1070500@oracle.com>
	<54FDAE15.8080606@Oracle.com>,
	<54FDB188.1000602@oracle.com>	<BLU175-W180FE85C6CA81825886349831B0@phx.gbl>
	<54FDEA81.70206@Oracle.com> <54FEB6B1.8080608@gmail.com>
	<54FEF7BC.8050702@Oracle.com> <54FF202D.4060604@gmail.com>
	<54FF2ABC.6060107@Oracle.com>
Message-ID: <54FF49A5.1050309@gmail.com>

On 03/10/2015 06:32 PM, Roger Riggs wrote:
> Can you point me to the alternative Process implementations outside 
> the JDK?
> I've seen a bit of flak about it not being the right API and if its 
> not right
> we should not extend it.
>
> Roger 

This will continue to work, since it's just a wrapper around another 
Process implementation (the JDK provided one):

http://types.cs.washington.edu/plume-lib/api/plume/TimeLimitProcess.html

This one is questionable, because it seems to handle some things of 
ProcessHandle API on it's own:

http://www.phoenix-int.com/~AnalysisServer/user/com/phoenix_int/aserver/util/PHXProcess.html

Theese seem to be it's own implementations, not just a wrappers:

http://axiak.github.io/java_posix_spawn/net/axiak/runtime/SpawnedProcess.html

http://www.google.si/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&ved=0CEEQFjAG&url=http%3A%2F%2Fhelp.eclipse.org%2Fluna%2Ftopic%2Forg.eclipse.cdt.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fcdt%2Futils%2Fspawner%2FSpawner.html&ei=_ED_VIKBM-bMygP4hIHwDQ&usg=AFQjCNELKMMuCGAWMSKXCyox1xCpvOZSGA&bvm=bv.87611401,d.bGQ



I don't know. Maybe you're right. There doesn't seem to be many 
implementations that would benefit from being extended with new 
functionality. There are a few wrappers of may kinds. If they deal with 
local processes, they will continue to be compatible with new 
functionality by just delegating getPid() to wrapped Process.

This one is interesting:

https://github.com/brettwooldridge/NuProcess

It claims to be using just a "few threads" for handling 500 processes on 
Linux or MacOS X. By reading through the introduction, I can see how it 
is done. It uses non-blocking I/O on the pipes between spawned process 
and JVM. So it can wait in single thread on events happening on multiple 
pipes. When child exits, the pipe gets an event as it reaches EOF. Clever.


Regards, Peter



From Roger.Riggs at Oracle.com  Tue Mar 10 20:09:10 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 10 Mar 2015 16:09:10 -0400
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54FF3E85.4020701@gmail.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>
	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>
	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>
	<54FF1DD6.90603@gmail.com> <54FF2998.8080306@Oracle.com>
	<54FF3E85.4020701@gmail.com>
Message-ID: <54FF4F66.7060501@Oracle.com>

Hi Peter,

On 3/10/2015 2:57 PM, Peter Levart wrote:
> Hi Roger,
>
> Thanks for bearing with me...
And me, as I find the route among the language, type system, 
compatibility issues,
and os intricacies.
>
> On 03/10/2015 06:27 PM, Roger Riggs wrote:
>>> I think current ProcessHandle is a mix of specification and partial 
>>> implementation that does not help in any way to hypothetical 
>>> external implementations. It effectively disables any consistent 
>>> alternative implementations. Take for example the following method 
>>> in ProcessHandle:
>>>
>>>     public final ProcessHandle parent() {
>>>         return ProcessHandleImpl.parent(getPid());
>>>     }
>> ProcessHandle is not intended to be *externally* extended; as an 
>> interface or abstract class
>
> But Process is, and Process inherits methods from ProcessHandle which 
> means that you are limiting external implementations of Process 
> forever to status-quo functionality. Why not let the implementor of 
> external Process implementation decide whether it needs or wants to 
> implement this new functionality or not. Are you afraid that 
> implementations will emerge, but will not be of enough quality because 
> of impedance missmatch between the API and the target platform? Or are 
> you afraid that it will be harder to support new additions to this API 
> if there are external implementations created?
I'm reluctant because we're having to speculate about the details of 
what might be
with no one to speak directly to any particular target OS issues and not 
much evidence that it is needed.

>
>>
>> it can not make *any* guarantees about the implementation.
>> No caller can depend on any of the behavior based on the compile time 
>> type.
>> With the changes proposed, the callers using ProcessHandle must be 
>> prepared to handle UOE
>> in addition to dealing with the normal absent or missing information 
>> from the OS.
>
> So let's say the caller is on a platform that is not supported by JDK 
> internal ProcessHandle implementation. What guarantees does 
> ProcessHandle implementation give him? It think he's in better 
> position if he must cope with differences than he is if he can't use 
> the API at all.
Perhaps
>
> UOE from getPid() is just a form of absent information. It could be -1.
This choice goes to the design of the caller;  is it structured to 
handle exceptions
or willing to check the validity of the values.
Many have complained that code to handle exceptions makes less code 
unreadable
and should be avoided.
>
>>
>> We should not open up another hole like Process without fully 
>> understanding
>> the use cases and the requirements on extensibility.  There may be a 
>> middle ground
>> that leaves the door open but not to start with.
>
> The hole is already open. Some external implementation of Process can 
> already attempt to implement all the ProcessHandle instance API merely 
> by subclassing the Process. Package-private constructor on 
> ProcessHandle will not stop that. Final methods will though.
The argument is frequently made about making the surface area of the API 
larger
without taking into account who pays the cost and who gets the benefit.
>
>>>
>>> There's no way an alternative implementation of ProcessHandle could 
>>> be created that returned alternative implementations using method 
>>> parent(). What if alternative implementation doesn't support getPid()?
>> I have not considered supporting alternate implementations a goal but 
>> not breaking existing ones is essential.
>
> Well, I don't see anything existing is broken if ProcessHandle doesn't 
> impose final methods.
True for existing API; but then the salient discussion is about the 
semantics of the new functions
and how they can be expected to adhere to the contract if extensibility 
is supported.

>
>>>
>>> I think ProcessHandle should be mostly a specification and only have 
>>> abstract methods. Only a method that does not depend on 
>>> implementation could be concrete. I think it could be an interface. 
>>> A package-private constructor does not help as there is a Process 
>>> class that has a public constructor already, so anyone can create 
>>> arbitrary instances of arbitrary subclass of Process which is-a 
>>> ProcessHandle...
>> Most of the behavior of ProcessHandle (as is Process) *is* 
>> implementation specific due to the OS dependencies.
>> When every function bottoms out in OS behavior, the layers above are 
>> dependent too.
>
> So this is a question of: "Is ProcessHandle API suitable for other 
> implementations or is it just for supported UNIX/Windows platforms", 
> right?
>
> Because technically it could be exposed as externally implementable 
> with no backwards compatibility problems when 1st introduced. There 
> might be problems later when extending it.
That's the risk.  Can it be eliminated or avoided...   Is it a necessary 
unknown?
>
>>>
>>>>
>>>> I now see Process.getPid was previously added and it throws USO by 
>>>> default. So we might be stuck due to the tricky nature of this area.
>>>
>>> Unfortunately. Default methods (in publicly extendable abstract 
>>> classes and interfaces) can not provide new functionality. They can 
>>> just re-pack existing functionality. getPid() is new functionality 
>>> and so are all new methods of ProcessHandle that Process inherits 
>>> from. So we can not just simply delegate to our implementation which 
>>> might be incompatible (unsupported platform).
>> Yes, but to support source level compatibility; some implementation 
>> is needed; though it cannot provide the full functionality.
>
> There's no source-level compatibility issue with ProcessHandle as it 
> is new class or interface. Just with Process. And even with my 
> changes, the source-level compatibility is maintained. Can you spot 
> anything that is not source-compatible or does not behave like it used 
> to? It actually behaves exactly like it behaves with your latest 
> implementation when default Process.getPid() throws UOE. The only 
> difference is that ProcessHandle is made extensible.
Just the aforementioned risk to maintenance cost
>
>>>
>>>>
>>>> Any sub-type of Process that does not override getPid will 
>>>> essentially result in that USO being propagated to many 
>>>> ProcessHandle methods that depend on the PID (parent, children, 
>>>> allChildren, info, compareTo). That effectively renders 
>>>> ProcessHandle almost useless for sub-types outside of our control 
>>>> that that not been updated.
>>>
>>> So here's some changes I propose to the tip of JDK-8046092-branch 
>>> that hopefully fix these issues:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-sandbox/JDK-8046092-branch/webrev.02/ 
>>>
>>>
>>> The changes are:
>>> - Process.getPid() is back to throwing UOE if unsupported
>>> - ProcessHandle is all-abstract interface (only allChildren() is a 
>>> default method, since it is just a utility independent of 
>>> implementation)
>> I considered 'abstract' in the PH API to be a distraction unless the 
>> API was intended to be extensible.
>
> Well in that case, yes. But why is it ProcessHandle then split between 
> ProcessHandle and ProcessHandleImpl? Isn't that a distraction too?
It kept the bulk of the implementation details out of the API and made 
them available
to the ProcessImpls.  I'm still working on the organization of the 
implementation; there should
be a clean split between ProcessImpl's that spawn processes and 
ProcessHandleImpl for the other functions.
>
>>
>>> - ProcessHandle.compareTo() specifies that only same-implementations 
>>> of ProcessHandle(s) are mutually comparable otherwise 
>>> ClassCastException must be thrown
>> Yes, avoids the issue with UOE.
>>> - ProcessHandleImpl.onExit() and ProcessImpl.onProcessExit() 
>>> propagate error from waitForProcessExit0 native method as 
>>> exceptional completion of CompletableFuture. exitValue is set to -1 
>>> on UNIX in this case (instead of 0). What's the exitStatus on 
>>> Windows in this case? This area needs more work, I think.
>> The exceptional case was removed because the waitForExit does not 
>> throw an exception.
>> The only exception from Process.waitFor is InterruptedException and 
>> since there might
>> be spurious exceptions it should be retried.
>>
>> When waitForProcessExit0 returns the process is gone; and the CF can 
>> be completed.
>
> So there's no error condition from waitForProcessExit0() then. Any 
> return *is* exitValue(). I haven't checked the native implementations 
> and just relied on comments in Java code.
There are a variety of OS level possible error conditions but either the 
process still exists
in which case it should still wait; or it is done and the exitValue (or 
not-available value)
is returned.
>
>>
>>> - Some tweaks to javadocs in a few places
>>>
>>>>
>>>> Is it common to sub-type Process? If so then perhaps Process should 
>>>> not extend ProcessHandle and instead there should be a way to view 
>>>> a Process as a ProcessHandle, whose default implementation is:
>>>>
>>>>    return ProcessHandle.of(getPid()); // throws USO if getPid does
>>>>
>>>> (java.lang.ProcessImpl could implement Processhandle thereby the 
>>>> implementation is "return this".)
>>>>
>>>> Thus once you have a ProcessHandle instance (from whatever source) 
>>>> it's possible to operate on it without fear of a USO.
>>>>
>>>>
>>>> A possible default implementation for Process.onProcessExit could be:
>>>>
>>>>    return CF.supplyAsync(() -> { this.waitFor(); return p}, 
>>>> cachedThreadPool);
>>>
>>> It could be, but this would encourage external implementations to 
>>> not override it and this implementation is not very efficient in 
>>> terms of thread stack sizes. We could use a default implementation 
>>> that is similar to Windows' ProcessImpl - only use waitFor() instead 
>>> of ProcessHandleImpl.waitForProcessExit0() native method, but on 
>>> UNIX waitFor() *is* implemented on top of this implementation, so I 
>>> think the best is to force the implementor to do it optimally from 
>>> the ground-up. Default methods should really be reserved for 
>>> something very trivial that is not only implementation independent, 
>>> but also equally efficient regardless of underlying implementation.
>> Without external implementations, the code moved up from ProcessImpl 
>> and ProcessHandleImpl classes
>> to the abstract class to avoid duplication in the subclasses.
>
> ProcesshandleImpl and Windows ProcessImpl can have same code, but UNIX 
> ProcessImpl must additionally synchronize using waitFor() since on 
> UNIX, exitValue() result is published by the continuation of 
> completion() which can execute concurrently with asynchronous 
> continuation of same completion() that completes user-visible 
> CompletableFuture. There's no harm if synchronization using waitFor() 
> is used in ProcesshandleImpl and Windows ProcessImpl too, but that's 
> unneeded overhead.
yes, on Unix, it provides synchronization between the CF completions.
On Windows, it is redundant since by the time that code is executed, the 
process is already known to be done.

Thanks, Roger




From brent.christian at oracle.com  Tue Mar 10 23:34:49 2015
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 10 Mar 2015 16:34:49 -0700
Subject: RFC: Adding ConcurrentModificationException for
	HashMap.computeIfAbsent(), and JDK-8071667
In-Reply-To: <DCA6D762-7ECE-4346-99EA-C3099F4CC6A4@oracle.com>
References: <54D1616F.50104@oracle.com>	<54D18B9A.2020906@oracle.com>	<84AD741C-CB02-4540-B41B-8F95490FF8E4@oracle.com>	<54D2BB16.80508@oracle.com>	<77020461-FD36-41FC-9996-9B476670C20D@oracle.com>	<54D52E37.6040705@oracle.com>
	<54F9FB2D.6070908@oracle.com>
	<DCA6D762-7ECE-4346-99EA-C3099F4CC6A4@oracle.com>
Message-ID: <54FF7F99.200@oracle.com>

Hi, Paul

On 3/10/15 8:29 AM, Paul Sandoz wrote:
>
> On the Map.compute* methods.
>
> Perhaps we can reuse similar language to that we added for Matcher:
>
> * The mapping function should not modify this map during computation.
> * This method will, on a best-effort basis, throw a
> * ConcurrentModification if such modification is detected.
>
> It's tempting to place the second sentence on the @throws
> ConcurrentModificationException as i believe will not show up for
> methods on ConcurrentMap, so keeps it somewhat contained
> documentation wise.

The language in Matcher is nice, and we can use it in HashMap.  But the 
default code in Map.compute* won't throw a CME (no iteration).  For the 
compute* methods in the Map interface, I think we should stick to 
recommending against modifying the Map during the computation, and 
encouraging implementing classes to check for CME.

>> In Map/HashMap, there are already two methods that accept lambdas
>> and throw a CME: forEach(BiConsumer) replaceAll(BiFunction)
>>
>> (The default code does not throw a CME ifitems are added).
>
> Right, although the iterator might still be fail-fast.

Ahh - I needed to update my test code (if a Map only has a single entry, 
the iterator doesn't CME when items are added because a second 
"iteration" never happens to detect the changed modCount).  A Map with 
 >= 2 entries is needed for the default code to CME due to items being 
added during forEach()/replaceAll().

Thanks,
-Brent


From john.r.rose at oracle.com  Wed Mar 11 07:10:04 2015
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 11 Mar 2015 00:10:04 -0700
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <54FF3FAD.5040702@redhat.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
Message-ID: <3C8D3D08-01CA-4BFF-89D7-0566D54144A9@oracle.com>

On Mar 10, 2015, at 12:02 PM, Andrew Haley <aph at redhat.com> wrote:
> 
> The new algorithm is slightly slower because of branch misprediction.
> 
> old:  2.17 IPC, 0.08% branch-misses, 91,965,281,215 cycles
> new:  1.23 IPC, 6.11% branch-misses, 99,925,255,682 cycles
> 
> ...but it executes fewer instructions so we're only talking about
> some 10% slowdown.  I think this is the worst case (or something
> close to the worst case) for the new algorithm.
> 
> So, I think we're OK performance-wise.

I agree.

> 
> John: I'm waiting for an answer to my question here before I submit
> a webrev for approval.
> 
> http://mail.openjdk.java.net/pipermail/panama-dev/2015-March/000099.html <http://mail.openjdk.java.net/pipermail/panama-dev/2015-March/000099.html>

(Answered.)



From paul.sandoz at oracle.com  Wed Mar 11 09:05:42 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 11 Mar 2015 10:05:42 +0100
Subject: RFC: Adding ConcurrentModificationException for
	HashMap.computeIfAbsent(), and JDK-8071667
In-Reply-To: <54FF7F99.200@oracle.com>
References: <54D1616F.50104@oracle.com>	<54D18B9A.2020906@oracle.com>	<84AD741C-CB02-4540-B41B-8F95490FF8E4@oracle.com>	<54D2BB16.80508@oracle.com>	<77020461-FD36-41FC-9996-9B476670C20D@oracle.com>	<54D52E37.6040705@oracle.com>
	<54F9FB2D.6070908@oracle.com>
	<DCA6D762-7ECE-4346-99EA-C3099F4CC6A4@oracle.com>
	<54FF7F99.200@oracle.com>
Message-ID: <4C569089-0303-4E20-A27A-7C2B5A0DFDFD@oracle.com>


On Mar 11, 2015, at 12:34 AM, Brent Christian <brent.christian at oracle.com> wrote:

> Hi, Paul
> 
> On 3/10/15 8:29 AM, Paul Sandoz wrote:
>> 
>> On the Map.compute* methods.
>> 
>> Perhaps we can reuse similar language to that we added for Matcher:
>> 
>> * The mapping function should not modify this map during computation.
>> * This method will, on a best-effort basis, throw a
>> * ConcurrentModification if such modification is detected.
>> 
>> It's tempting to place the second sentence on the @throws
>> ConcurrentModificationException as i believe will not show up for
>> methods on ConcurrentMap, so keeps it somewhat contained
>> documentation wise.
> 
> The language in Matcher is nice, and we can use it in HashMap.  But the default code in Map.compute* won't throw a CME (no iteration).

That's ok, we can call that out if necessary in the @implSpec.


>  For the compute* methods in the Map interface, I think we should stick to recommending against modifying the Map during the computation,

Yes.


> and encouraging implementing classes to check for CME.
> 

Yes. My suggestion was to try and push much of the CME-related specification onto the @throws CME docs. That way less of this will appear on ConcurrentMap where CME does not make sense.


>>> In Map/HashMap, there are already two methods that accept lambdas
>>> and throw a CME: forEach(BiConsumer) replaceAll(BiFunction)
>>> 
>>> (The default code does not throw a CME ifitems are added).
>> 
>> Right, although the iterator might still be fail-fast.
> 
> Ahh - I needed to update my test code (if a Map only has a single entry, the iterator doesn't CME when items are added because a second "iteration" never happens to detect the changed modCount).  A Map with >= 2 entries is needed for the default code to CME due to items being added during forEach()/replaceAll().
> 

Yeah, it's all "best-effort".

Paul.


From paul.sandoz at oracle.com  Wed Mar 11 09:12:40 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 11 Mar 2015 10:12:40 +0100
Subject: RFR: JDK-8074578 Document memory visibility effects of some
	Unsafe methods
In-Reply-To: <CA+kOe08JzETEdOR0twbRc5h3RfkZL007iaBEagZYniaR3GVXbA@mail.gmail.com>
References: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>
	<54FCEA87.3030509@oracle.com> <54FD6767.8020506@redhat.com>
	<54FD8059.9050205@oracle.com>
	<CA+kOe0-NSsfYwDE6xzquWAe9OVhx389tX27vo5_DUpUSdTEpeQ@mail.gmail.com>
	<54FE4943.1030008@oracle.com> <54FE9DDA.8030301@redhat.com>
	<CA+kOe08JzETEdOR0twbRc5h3RfkZL007iaBEagZYniaR3GVXbA@mail.gmail.com>
Message-ID: <2608270C-BDD6-4E8F-8D1F-5E6FB0F42BFC@oracle.com>


On Mar 10, 2015, at 8:06 PM, Martin Buchholz <martinrb at google.com> wrote:

> I agree with Andrew that the Unsafe API matters, and there are many implementations of it (even multiple within openjdk itself!).
> 
> I still know of no reason why my proposed spec is wrong.  If C11 support was good and ubiquitous, I would recommend using atomic_compare_exchange_strong or C++ equivalent in the hotspot implementation instead of  fences as is done now.
> 
> If you think you can write a better spec, please share!

I am all for clearing up the language here, but think it prudent to hold off doing much until the language for JMM revisions and VarHandle is produced, then we can revisit.

Paul.


From paul.sandoz at oracle.com  Wed Mar 11 10:06:24 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 11 Mar 2015 11:06:24 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54FF10B2.4010605@Oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>
	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>
	<54FF10B2.4010605@Oracle.com>
Message-ID: <CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>


On Mar 10, 2015, at 4:41 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:

> Hi Paul,
> 
> On 3/10/2015 11:22 AM, Paul Sandoz wrote:
>> 
>>>> Any sub-type of Process that does not override getPid will essentially result in that USO being propagated to many ProcessHandle methods that depend on the PID (parent, children, allChildren, info, compareTo). That effectively renders ProcessHandle almost useless for sub-types outside of our control that that not been updated.
>>> For those methods, the default behavior can be specified, except for compareTo
>>> they already have return values that allow for the fact that the information may
>>> not be available, either due to OS restrictions (permissions) or is not provided.
>>> Empty lists for children, nulls returned from info, and even allowing for an unavailable parent.
>> That's a separate issue.
>> 
>> If i get a ProcessHandle given to me, i do not know it's source, i dunno if it's gonna barf if i operate on it.
> It can be a goal to never throw UOE, to achieve that, the behaviors of all of the methods
> (of Process) would be defined to have outputs that have to be checked by the app;
> hence the reference to nulls; empty lists, etc.
> 
> In many cases already, if the OS does not provide values or the OS permissions do not permit
> it then the values returned are empty (instead of throwing exceptions).
> That design can be extended to the external subclasses by specifying the default behavior
> of Process and then defining the behaviors of Processes created by ProcessBuilder.
> 

I still think that conflates the "OS says no" and the "Subtype of Process does not support the contract of ProcessHandle".

Process as designed feels kind of limited and we are stuck with that. ProcessHandle is then also limited by Process extending it. Thus my inclination is still for Process to not extend from ProcessHandle, let's keep then at a distance.

For arguments sake let's say we go with that approach:

  public abstract class Process {
    long getPID() throws USO { throw new USO; }

    // Not final but effectively so for subtypes outside of package since public construction of ProcessHandle
    // is not possible
    ProcessHandle toHandle() throws USO { return ProcessHandle.of(getPID()); }  

    CF<Process> onProcessExit() { ... } // crappy default
  }

  public abstract class ProcessHandle {
    ProcessHandle() {}
    public abstract long getPid();  // Does not throw USO  
  }

With such an approach if one has a ProcessHandle instance will the native PID always be available?

Paul.


From chris.hegarty at oracle.com  Wed Mar 11 10:29:53 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 11 Mar 2015 10:29:53 +0000
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>
	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>
Message-ID: <55001921.8090404@oracle.com>

On 11/03/15 10:06, Paul Sandoz wrote:
>
> On Mar 10, 2015, at 4:41 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
>
>> Hi Paul,
>>
>> On 3/10/2015 11:22 AM, Paul Sandoz wrote:
>>>
>>>>> Any sub-type of Process that does not override getPid will essentially result in that USO being propagated to many ProcessHandle methods that depend on the PID (parent, children, allChildren, info, compareTo). That effectively renders ProcessHandle almost useless for sub-types outside of our control that that not been updated.
>>>> For those methods, the default behavior can be specified, except for compareTo
>>>> they already have return values that allow for the fact that the information may
>>>> not be available, either due to OS restrictions (permissions) or is not provided.
>>>> Empty lists for children, nulls returned from info, and even allowing for an unavailable parent.
>>> That's a separate issue.
>>>
>>> If i get a ProcessHandle given to me, i do not know it's source, i dunno if it's gonna barf if i operate on it.
>> It can be a goal to never throw UOE, to achieve that, the behaviors of all of the methods
>> (of Process) would be defined to have outputs that have to be checked by the app;
>> hence the reference to nulls; empty lists, etc.
>>
>> In many cases already, if the OS does not provide values or the OS permissions do not permit
>> it then the values returned are empty (instead of throwing exceptions).
>> That design can be extended to the external subclasses by specifying the default behavior
>> of Process and then defining the behaviors of Processes created by ProcessBuilder.
>>
>
> I still think that conflates the "OS says no" and the "Subtype of Process does not support the contract of ProcessHandle".
>
> Process as designed feels kind of limited and we are stuck with that. ProcessHandle is then also limited by Process extending it. Thus my inclination is still for Process to not extend from ProcessHandle, let's keep then at a distance.

I think this design should work out cleaner. There can be just a single 
point where UOE can be thrown, from toHandle().

My inclination, with this design, is to remove Process.getPid(), since 
the pid can be retrieved from the handle. This should be possible since 
Process.getPid() is @since 1.9.

> For arguments sake let's say we go with that approach:
>
>    public abstract class Process {

can be removed, no?
>      long getPID() throws USO { throw new USO; }

I think ProcessHandle needs a protected constructor, otherwise it cannot 
be implemented outside of the platform. Or is this the intent? In which 
case Process.getPid() may need to remain.

>      // Not final but effectively so for subtypes outside of package since public construction of ProcessHandle
>      // is not possible
>      ProcessHandle toHandle() throws USO { return ProcessHandle.of(getPID()); }
>
>      CF<Process> onProcessExit() { ... } // crappy default
>    }
>
>    public abstract class ProcessHandle {
>      ProcessHandle() {}
>      public abstract long getPid();  // Does not throw USO
>    }
>
> With such an approach if one has a ProcessHandle instance will the native PID always be available?
>
> Paul.

-Chris.



From peter.levart at gmail.com  Wed Mar 11 11:12:24 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 11 Mar 2015 12:12:24 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>
	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>
Message-ID: <55002318.5040108@gmail.com>

On 03/11/2015 11:06 AM, Paul Sandoz wrote:
>> >In many cases already, if the OS does not provide values or the OS permissions do not permit
>> >it then the values returned are empty (instead of throwing exceptions).
>> >That design can be extended to the external subclasses by specifying the default behavior
>> >of Process and then defining the behaviors of Processes created by ProcessBuilder.
>> >
> I still think that conflates the "OS says no" and the "Subtype of Process does not support the contract of ProcessHandle".
>
> Process as designed feels kind of limited and we are stuck with that. ProcessHandle is then also limited by Process extending it. Thus my inclination is still for Process to not extend from ProcessHandle, let's keep then at a distance.

I too like this design better.

>
> For arguments sake let's say we go with that approach:
>
>    public abstract class Process {
>      long getPID() throws USO { throw new USO; }
>
>      // Not final but effectively so for subtypes outside of package since public construction of ProcessHandle
>      // is not possible
>      ProcessHandle toHandle() throws USO { return ProcessHandle.of(getPID()); }

Not possible to have custom implementations of ProcessHandle (the 
constructor is package-private), but possible to construct the internal 
implementation (ProecssHandle.of(pid)). Which means that external 
implementations based on local OS processes on supported platforms can 
still override Process.toHandle() and return an internal implementation. 
A quick scan on external implementations shows that they are usually 
just wrappers over JDK provided Process and even if they are not, the 
internal ProcessHandle implementation can be compatible with them as it 
doesn't do anything exclusive with the OS process it represents except 
obvious things like killing it and so, which is possible from outside 
JVM too.

>
>      CF<Process> onProcessExit() { ... } // crappy default

I don't know. There are two ways to get that behaviour then. 
Process.onProcessExit() and Process.toHandle().onExit(). If Process is 
not a subtype of ProcessHandle, we can skip this method, since you can 
always do the following:

Process p = ...
p.toHandle().onExit(ph -> { ... use captured p directly ... });

>    }
>
>    public abstract class ProcessHandle {
>      ProcessHandle() {}
>      public abstract long getPid();  // Does not throw USO
>    }
>
> With such an approach if one has a ProcessHandle instance will the native PID always be available?

I think it should be, since ProcessHandle implementation is 
internal-only and getPid() is available on supported platforms.

>
> Paul.



From paul.sandoz at oracle.com  Wed Mar 11 11:20:15 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 11 Mar 2015 12:20:15 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <55001921.8090404@oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>
	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>
	<55001921.8090404@oracle.com>
Message-ID: <89B263CE-B0FB-4571-826E-27D65D1BC572@oracle.com>

On Mar 11, 2015, at 11:29 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> 
>> I still think that conflates the "OS says no" and the "Subtype of Process does not support the contract of ProcessHandle".
>> 
>> Process as designed feels kind of limited and we are stuck with that. ProcessHandle is then also limited by Process extending it. Thus my inclination is still for Process to not extend from ProcessHandle, let's keep then at a distance.
> 
> I think this design should work out cleaner. There can be just a single point where UOE can be thrown, from toHandle().
> 
> My inclination, with this design, is to remove Process.getPid(), since the pid can be retrieved from the handle. This should be possible since Process.getPid() is @since 1.9.
> 
>> For arguments sake let's say we go with that approach:
>> 
>>   public abstract class Process {
> 
> can be removed, no?
>>     long getPID() throws USO { throw new USO; }
> 
> I think ProcessHandle needs a protected constructor, otherwise it cannot be implemented outside of the platform. Or is this the intent? In which case Process.getPid() may need to remain.

I tried to keep within certain constraints of Rodger's existing design and the existing methods (even if recently added). IIUC Roger wanted ProcessHandle impls to be under platform control.

Paul.


From paul.sandoz at oracle.com  Wed Mar 11 11:22:40 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 11 Mar 2015 12:22:40 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <55002318.5040108@gmail.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>
	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>
	<55002318.5040108@gmail.com>
Message-ID: <0F76B4A5-CC00-4C3D-BD83-41527979E20A@oracle.com>

On Mar 11, 2015, at 12:12 PM, Peter Levart <peter.levart at gmail.com> wrote:
>> 
>>     CF<Process> onProcessExit() { ... } // crappy default
> 
> I don't know. There are two ways to get that behaviour then. Process.onProcessExit() and Process.toHandle().onExit(). If Process is not a subtype of ProcessHandle, we can skip this method, since you can always do the following:
> 
> Process p = ...
> p.toHandle().onExit(ph -> { ... use captured p directly ... });
> 

That seems reasonable to me.

Paul.


From peter.levart at gmail.com  Wed Mar 11 11:34:32 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 11 Mar 2015 12:34:32 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <55001921.8090404@oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>
	<55001921.8090404@oracle.com>
Message-ID: <55002848.8010807@gmail.com>

On 03/11/2015 11:29 AM, Chris Hegarty wrote:
> can be removed, no?
>>      long getPID() throws USO { throw new USO; }
>
> I think ProcessHandle needs a protected constructor, otherwise it 
> cannot be implemented outside of the platform. Or is this the intent? 
> In which case Process.getPid() may need to remain. 

I think in majority of cases it needs not be implemented outside the 
platform. Process.getPid() can remain as a quick shortcut and by default 
it can be implemented as:

public long getPid() throws USO {
     return toHandle().getPid();
}

...and overridden in internal implementations with more optimal thing.

Ok, then the same can be said for Process.onExit() (which can now have a 
different signature than ProcessHandle.onExit()):

public abstract class Process {

     public CompletableFuture<Process> onExit() {
         return toHandle().onExit().thenApply(ph -> this);
     }

Peter



From chris.hegarty at oracle.com  Wed Mar 11 11:51:08 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 11 Mar 2015 11:51:08 +0000
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <55002848.8010807@gmail.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>
	<55001921.8090404@oracle.com> <55002848.8010807@gmail.com>
Message-ID: <55002C2C.5040302@oracle.com>

On 11/03/15 11:34, Peter Levart wrote:
> On 03/11/2015 11:29 AM, Chris Hegarty wrote:
>> can be removed, no?
>>>      long getPID() throws USO { throw new USO; }
>>
>> I think ProcessHandle needs a protected constructor, otherwise it
>> cannot be implemented outside of the platform. Or is this the intent?
>> In which case Process.getPid() may need to remain.
>
> I think in majority of cases it needs not be implemented outside the
> platform.

Is there any time where it would be required to implemented outside of 
the platform?

 > Process.getPid() can remain as a quick shortcut and by default
> it can be implemented as:
>
> public long getPid() throws USO {
>      return toHandle().getPid();
> }
>
> ...and overridden in internal implementations with more optimal thing.
>
> Ok, then the same can be said for Process.onExit() (which can now have a
> different signature than ProcessHandle.onExit()):
>
> public abstract class Process {
>
>      public CompletableFuture<Process> onExit() {
>          return toHandle().onExit().thenApply(ph -> this);
>      }

Are we not back where we started, since toHandle() can throw UOE?

-Chris.

> Peter
>


From peter.levart at gmail.com  Wed Mar 11 11:57:33 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 11 Mar 2015 12:57:33 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <55002C2C.5040302@oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>
	<55001921.8090404@oracle.com> <55002848.8010807@gmail.com>
	<55002C2C.5040302@oracle.com>
Message-ID: <55002DAD.2010804@gmail.com>

On 03/11/2015 12:51 PM, Chris Hegarty wrote:
> On 11/03/15 11:34, Peter Levart wrote:
>> On 03/11/2015 11:29 AM, Chris Hegarty wrote:
>>> can be removed, no?
>>>>      long getPID() throws USO { throw new USO; }
>>>
>>> I think ProcessHandle needs a protected constructor, otherwise it
>>> cannot be implemented outside of the platform. Or is this the intent?
>>> In which case Process.getPid() may need to remain.
>>
>> I think in majority of cases it needs not be implemented outside the
>> platform.
>
> Is there any time where it would be required to implemented outside of 
> the platform?

Only for special implementations that don't map to local processed of 
supported platforms, I think. Such as remote execution facility 
disguised as a Process API. Or a facility that breaks out of sandboxed 
environment for execution of local processes that are otherwise not 
accessible by JVM process directly. This is all hypothetical.


>
> > Process.getPid() can remain as a quick shortcut and by default
>> it can be implemented as:
>>
>> public long getPid() throws USO {
>>      return toHandle().getPid();
>> }
>>
>> ...and overridden in internal implementations with more optimal thing.
>>
>> Ok, then the same can be said for Process.onExit() (which can now have a
>> different signature than ProcessHandle.onExit()):
>>
>> public abstract class Process {
>>
>>      public CompletableFuture<Process> onExit() {
>>          return toHandle().onExit().thenApply(ph -> this);
>>      }
>
> Are we not back where we started, since toHandle() can throw UOE?

Yes, number of such methods should be minimized. Perhaps just getPid() 
since it can have much more optimal implementation in internal ProcessImpl.

Regards, Peter


>
> -Chris.
>
>> Peter
>>



From biboudis at gmail.com  Wed Mar 11 12:45:50 2015
From: biboudis at gmail.com (Aggelos Biboudis)
Date: Wed, 11 Mar 2015 14:45:50 +0200
Subject: RFR: JDK-8067969 Optimize Stream.count for SIZED Streams
Message-ID: <CAHLSyCmEPZnfe2rJe+o7con8RG1L09kQr-yL8KsC1V_1oSNhqg@mail.gmail.com>

Hi all,

Please review the patch for the count terminal operator on SIZED streams.

https://bugs.openjdk.java.net/browse/JDK-8067969
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8067969-optimize-stream-count/webrev/

Thanks Paul Sandoz for sponsoring this.

Kind regards,
Aggelos Biboudis.


From aph at redhat.com  Wed Mar 11 14:19:03 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 11 Mar 2015 14:19:03 +0000
Subject: Is a Javadoc API supposed to be imperative or not?
Message-ID: <55004ED7.1010502@redhat.com>

Javadoc API seems to be descriptive:

"Returns a string ...
"Wakes up a single thread ...
"Creates and returns ...

But sometimes it's imperative:

"Block current thread, returning when...
"Report the scale...
"Define a class...

Which is right?

Thanks,
Andrew.


From martinrb at google.com  Wed Mar 11 14:23:09 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 11 Mar 2015 07:23:09 -0700
Subject: Is a Javadoc API supposed to be imperative or not?
In-Reply-To: <55004ED7.1010502@redhat.com>
References: <55004ED7.1010502@redhat.com>
Message-ID: <CA+kOe09BUeVzM-rmpqRdyHi3syA8vRMBArhO2ze_86bBA5smbQ@mail.gmail.com>

On Wed, Mar 11, 2015 at 7:19 AM, Andrew Haley <aph at redhat.com> wrote:

> Javadoc API seems to be descriptive:
>
> "Returns a string ...
> "Wakes up a single thread ...
> "Creates and returns ...
>
> But sometimes it's imperative:
>
> "Block current thread, returning when...
> "Report the scale...
> "Define a class...
>
> Which is right?
>
>
The former!

(Switch to imperative voice for implementation comments.)


From Roger.Riggs at Oracle.com  Wed Mar 11 14:34:45 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 11 Mar 2015 10:34:45 -0400
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <55002848.8010807@gmail.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>	<55001921.8090404@oracle.com>
	<55002848.8010807@gmail.com>
Message-ID: <55005285.1070805@Oracle.com>

Hi,

I think the 'convenience' methods for onExit() and getPid() are 
useful/desirable on Process.
It should not be necessary to shuttle over to ProcessHandle to do basic 
functions on the Process.

Roger


On 3/11/2015 7:34 AM, Peter Levart wrote:
> On 03/11/2015 11:29 AM, Chris Hegarty wrote:
>> can be removed, no?
>>>      long getPID() throws USO { throw new USO; }
>>
>> I think ProcessHandle needs a protected constructor, otherwise it 
>> cannot be implemented outside of the platform. Or is this the intent? 
>> In which case Process.getPid() may need to remain. 
>
> I think in majority of cases it needs not be implemented outside the 
> platform. Process.getPid() can remain as a quick shortcut and by 
> default it can be implemented as:
>
> public long getPid() throws USO {
>     return toHandle().getPid();
> }
>
> ...and overridden in internal implementations with more optimal thing.
>
> Ok, then the same can be said for Process.onExit() (which can now have 
> a different signature than ProcessHandle.onExit()):
>
> public abstract class Process {
>
>     public CompletableFuture<Process> onExit() {
>         return toHandle().onExit().thenApply(ph -> this);
>     }
>
> Peter
>



From Roger.Riggs at Oracle.com  Wed Mar 11 14:42:28 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 11 Mar 2015 10:42:28 -0400
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <55002DAD.2010804@gmail.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>	<55001921.8090404@oracle.com>
	<55002848.8010807@gmail.com>	<55002C2C.5040302@oracle.com>
	<55002DAD.2010804@gmail.com>
Message-ID: <55005454.1050906@Oracle.com>

Hi,

Also, is there a proposal for Process.compareTo?
It can be left out for the status quo, but otherwise the issue with 
getPid()/toHandle and UOE remains.
Though the previously described artificial pid workarounds can be used.

Roger


On 3/11/2015 7:57 AM, Peter Levart wrote:
> On 03/11/2015 12:51 PM, Chris Hegarty wrote:
>> On 11/03/15 11:34, Peter Levart wrote:
>>> On 03/11/2015 11:29 AM, Chris Hegarty wrote:
>>>> can be removed, no?
>>>>>      long getPID() throws USO { throw new USO; }
>>>>
>>>> I think ProcessHandle needs a protected constructor, otherwise it
>>>> cannot be implemented outside of the platform. Or is this the intent?
>>>> In which case Process.getPid() may need to remain.
>>>
>>> I think in majority of cases it needs not be implemented outside the
>>> platform.
>>
>> Is there any time where it would be required to implemented outside 
>> of the platform?
>
> Only for special implementations that don't map to local processed of 
> supported platforms, I think. Such as remote execution facility 
> disguised as a Process API. Or a facility that breaks out of sandboxed 
> environment for execution of local processes that are otherwise not 
> accessible by JVM process directly. This is all hypothetical.
>
>
>>
>> > Process.getPid() can remain as a quick shortcut and by default
>>> it can be implemented as:
>>>
>>> public long getPid() throws USO {
>>>      return toHandle().getPid();
>>> }
>>>
>>> ...and overridden in internal implementations with more optimal thing.
>>>
>>> Ok, then the same can be said for Process.onExit() (which can now 
>>> have a
>>> different signature than ProcessHandle.onExit()):
>>>
>>> public abstract class Process {
>>>
>>>      public CompletableFuture<Process> onExit() {
>>>          return toHandle().onExit().thenApply(ph -> this);
>>>      }
>>
>> Are we not back where we started, since toHandle() can throw UOE?
>
> Yes, number of such methods should be minimized. Perhaps just getPid() 
> since it can have much more optimal implementation in internal 
> ProcessImpl.
>
> Regards, Peter
>
>
>>
>> -Chris.
>>
>>> Peter
>>>
>



From aph at redhat.com  Wed Mar 11 17:27:44 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 11 Mar 2015 17:27:44 +0000
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <3C8D3D08-01CA-4BFF-89D7-0566D54144A9@oracle.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
	<3C8D3D08-01CA-4BFF-89D7-0566D54144A9@oracle.com>
Message-ID: <55007B10.1010606@redhat.com>

On 03/11/2015 07:10 AM, John Rose wrote:
>>
>> John: I'm waiting for an answer to my question here before I submit
>> a webrev for approval.
>>
>> http://mail.openjdk.java.net/pipermail/panama-dev/2015-March/000099.html
> 
> (Answered.)

http://cr.openjdk.java.net/~aph/unaligned.jdk.5/
http://cr.openjdk.java.net/~aph/unaligned.hotspot.5/

I hope everybody is happy with this, or at least not so unhappy that
they would want to reject it altogether.

There is no bug ID for this yet.  John, would you like to create a bug
database entry?  If not, I'll do so.  Then I can go for a RFR, which
hopefully should be a shoo-in now that we've beaten this thing to
death.  :-)

Andrew.


From vitalyd at gmail.com  Wed Mar 11 17:38:37 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 11 Mar 2015 13:38:37 -0400
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <55007B10.1010606@redhat.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
	<3C8D3D08-01CA-4BFF-89D7-0566D54144A9@oracle.com>
	<55007B10.1010606@redhat.com>
Message-ID: <CAHjP37GLM0z2UiO=fv+7C2t_bp4M_N50o3mH+bpuw5JpFLfHnw@mail.gmail.com>

private static final ByteOrder byteOrder 571         =
unsafe.isBigEndian() ? ByteOrder.BIG_ENDIAN : ByteOrder.LITTLE_ENDIAN;
 572
 573     static ByteOrder byteOrder() {
 574         if (byteOrder == null)
 575             throw new Error("Unknown byte order");
 576         return byteOrder;
 577     }
 578

No need for null check in byteOrder() anymore, right?


On Wed, Mar 11, 2015 at 1:27 PM, Andrew Haley <aph at redhat.com> wrote:

> On 03/11/2015 07:10 AM, John Rose wrote:
> >>
> >> John: I'm waiting for an answer to my question here before I submit
> >> a webrev for approval.
> >>
> >>
> http://mail.openjdk.java.net/pipermail/panama-dev/2015-March/000099.html
> >
> > (Answered.)
>
> http://cr.openjdk.java.net/~aph/unaligned.jdk.5/
> http://cr.openjdk.java.net/~aph/unaligned.hotspot.5/
>
> I hope everybody is happy with this, or at least not so unhappy that
> they would want to reject it altogether.
>
> There is no bug ID for this yet.  John, would you like to create a bug
> database entry?  If not, I'll do so.  Then I can go for a RFR, which
> hopefully should be a shoo-in now that we've beaten this thing to
> death.  :-)
>
> Andrew.
>


From aph at redhat.com  Wed Mar 11 17:39:36 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 11 Mar 2015 17:39:36 +0000
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <CAHjP37GLM0z2UiO=fv+7C2t_bp4M_N50o3mH+bpuw5JpFLfHnw@mail.gmail.com>
References: <54EB6DD1.4090803@redhat.com>	<54FF3FAD.5040702@redhat.com>	<3C8D3D08-01CA-4BFF-89D7-0566D54144A9@oracle.com>	<55007B10.1010606@redhat.com>
	<CAHjP37GLM0z2UiO=fv+7C2t_bp4M_N50o3mH+bpuw5JpFLfHnw@mail.gmail.com>
Message-ID: <55007DD8.9020002@redhat.com>

On 03/11/2015 05:38 PM, Vitaly Davidovich wrote:
> private static final ByteOrder byteOrder
>  571         = unsafe.isBigEndian() ? ByteOrder.BIG_ENDIAN : ByteOrder.LITTLE_ENDIAN;
>  572 
>  573     static ByteOrder byteOrder() {
>  574         if (byteOrder == null)
>  575             throw new Error("Unknown byte order");
>  576         return byteOrder;
>  577     }
>  578 
> 
> No need for null check in byteOrder() anymore, right?

OK, thx.

Andrew.



From vitalyd at gmail.com  Wed Mar 11 17:41:01 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 11 Mar 2015 13:41:01 -0400
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <55007DD8.9020002@redhat.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
	<3C8D3D08-01CA-4BFF-89D7-0566D54144A9@oracle.com>
	<55007B10.1010606@redhat.com>
	<CAHjP37GLM0z2UiO=fv+7C2t_bp4M_N50o3mH+bpuw5JpFLfHnw@mail.gmail.com>
	<55007DD8.9020002@redhat.com>
Message-ID: <CAHjP37Hg-jo1Y-ZvbsNLi6pVR43itk3n0qk+y05sk9X8UQkhgg@mail.gmail.com>

Also,

static boolean unaligned() {
 595         if (unalignedKnown)
 596             return unaligned; 597         unaligned =
unsafe.unalignedAccess();



 598         unalignedKnown = true;
 599         return unaligned;
 600     }

I don't think we need this unalignedKnown dance anymore -- just return
unsafe.unalignedAccess() there?

On Wed, Mar 11, 2015 at 1:39 PM, Andrew Haley <aph at redhat.com> wrote:

> On 03/11/2015 05:38 PM, Vitaly Davidovich wrote:
> > private static final ByteOrder byteOrder
> >  571         = unsafe.isBigEndian() ? ByteOrder.BIG_ENDIAN :
> ByteOrder.LITTLE_ENDIAN;
> >  572
> >  573     static ByteOrder byteOrder() {
> >  574         if (byteOrder == null)
> >  575             throw new Error("Unknown byte order");
> >  576         return byteOrder;
> >  577     }
> >  578
> >
> > No need for null check in byteOrder() anymore, right?
>
> OK, thx.
>
> Andrew.
>
>


From aph at redhat.com  Wed Mar 11 17:43:04 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 11 Mar 2015 17:43:04 +0000
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <CAHjP37Hg-jo1Y-ZvbsNLi6pVR43itk3n0qk+y05sk9X8UQkhgg@mail.gmail.com>
References: <54EB6DD1.4090803@redhat.com>	<54FF3FAD.5040702@redhat.com>	<3C8D3D08-01CA-4BFF-89D7-0566D54144A9@oracle.com>	<55007B10.1010606@redhat.com>	<CAHjP37GLM0z2UiO=fv+7C2t_bp4M_N50o3mH+bpuw5JpFLfHnw@mail.gmail.com>	<55007DD8.9020002@redhat.com>
	<CAHjP37Hg-jo1Y-ZvbsNLi6pVR43itk3n0qk+y05sk9X8UQkhgg@mail.gmail.com>
Message-ID: <55007EA8.1090502@redhat.com>

On 03/11/2015 05:41 PM, Vitaly Davidovich wrote:
> I don't think we need this unalignedKnown dance anymore -- just return unsafe.unalignedAccess() there?

Yup.

Andrew.



From paul.sandoz at oracle.com  Wed Mar 11 18:00:13 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 11 Mar 2015 19:00:13 +0100
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <55007B10.1010606@redhat.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
	<3C8D3D08-01CA-4BFF-89D7-0566D54144A9@oracle.com>
	<55007B10.1010606@redhat.com>
Message-ID: <AA5ECA2E-DB3E-4887-A040-E764CDBE51F0@oracle.com>

Hi Andrew,

On Mar 11, 2015, at 6:27 PM, Andrew Haley <aph at redhat.com> wrote:

> On 03/11/2015 07:10 AM, John Rose wrote:
>>> 
>>> John: I'm waiting for an answer to my question here before I submit
>>> a webrev for approval.
>>> 
>>> http://mail.openjdk.java.net/pipermail/panama-dev/2015-March/000099.html
>> 
>> (Answered.)
> 
> http://cr.openjdk.java.net/~aph/unaligned.jdk.5/
> http://cr.openjdk.java.net/~aph/unaligned.hotspot.5/
> 
> I hope everybody is happy with this, or at least not so unhappy that
> they would want to reject it altogether.
> 

Some minor comment on the JavaDoc. 

I think it more preferable to refer to "underlying platform" or "platform" rather than "machine", at least thats the kind of language i have seen commonly used in other places.

1062      * The write will be atomic with respect to the largest power of
1063      * two that divides the GCD of the offset and the storage size.
1064      * For example, getLongUnaligned will make atomic reads of 2-, 4-,
1065      * or 8-byte storage units if the offset is zero mod 2, 4, or 8,
1066      * respectively.  There are no other guarantees of atomicity.
1067      * <p>
1068      *
1069      * @param o Java heap object in which the value resides, if any, else
1070      *        null
1071      * @param offset The offset in bytes from the start of the object
1072      * @param x the value to store
1073      * @throws RuntimeException No defined exceptions are thrown, not even
1074      *         {@link NullPointerException}
1075      * @since 1.9
1076      */
1077     public final void putLongUnaligned(Object o, long offset, long x) {

s/reads/writes.

In the example it might be worth pointing out that is for 64-bit systems?


> There is no bug ID for this yet.  John, would you like to create a bug
> database entry?  If not, I'll do so.  Then I can go for a RFR, which
> hopefully should be a shoo-in now that we've beaten this thing to
> death.  :-)
> 

We need to include some unit tests before we can push. As i said, if you like i can help you with that and also performing a JPRT run across multiple platforms.

Paul.


From aph at redhat.com  Wed Mar 11 18:23:28 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 11 Mar 2015 18:23:28 +0000
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <AA5ECA2E-DB3E-4887-A040-E764CDBE51F0@oracle.com>
References: <54EB6DD1.4090803@redhat.com>
	<54FF3FAD.5040702@redhat.com>	<3C8D3D08-01CA-4BFF-89D7-0566D54144A9@oracle.com>	<55007B10.1010606@redhat.com>
	<AA5ECA2E-DB3E-4887-A040-E764CDBE51F0@oracle.com>
Message-ID: <55008820.1040601@redhat.com>

On 03/11/2015 06:00 PM, Paul Sandoz wrote:
> We need to include some unit tests before we can push.

I have a test which I've been using.  It could be converted into
a unit test.

Andrew.



From brian.burkhalter at oracle.com  Wed Mar 11 18:25:02 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 11 Mar 2015 11:25:02 -0700
Subject: Math.pow(PING(8),
	3): [9] RFR JDK-8068373: (prefs) FileSystemPreferences writes \0 to
	XML storage, causing loss of all preferences
Message-ID: <11C49A24-36FE-4575-A943-9BFE0D22A3F8@oracle.com>

Hello,

This message is a mere reprise of this reminder

http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031848.html

from February 25. The original review thread on this topic went through to its conclusion but some alternatives arose and there has been no definitive outcome. It would be good to clear this up at last.

One option not mentioned in the above-linked message would be to resolve the issue as already approved and then file another one covering any change to the approach, such as listed in choices B and C in the foregoing.

Thanks,

Brian

From Roger.Riggs at Oracle.com  Wed Mar 11 19:58:16 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 11 Mar 2015 15:58:16 -0400
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <55005454.1050906@Oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>	<55001921.8090404@oracle.com>	<55002848.8010807@gmail.com>	<55002C2C.5040302@oracle.com>	<55002DAD.2010804@gmail.com>
	<55005454.1050906@Oracle.com>
Message-ID: <55009E58.5080500@Oracle.com>

Hi,

The recommendations have been applied to the javadoc and the sandbox 
JDK-8046092-branch.

     http://cr.openjdk.java.net/~rriggs/ph-apidraft/

Some operations on a Process take an extra dereference due to the 
delegation to ProcessHandle.
For example, getting the cputime or startTime of the process:
     Process p = ...
     Duration d = p.toHandle().info().totalCpuDuration();
     Instant start = p.toHandle().info().startInstant();

As do the listing of children; convenience methods could be introduced 
with the UOE possibility
but that is a risk only for externally defined Process subtypes.
Developers working with Processes should not have to deal with ProcessHandle
to get information about the processes they spawn.

Comments appreciated, Roger



From brent.christian at oracle.com  Thu Mar 12 00:28:43 2015
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 11 Mar 2015 17:28:43 -0700
Subject: RFC: Adding ConcurrentModificationException for
	HashMap.computeIfAbsent(), and JDK-8071667
In-Reply-To: <4C569089-0303-4E20-A27A-7C2B5A0DFDFD@oracle.com>
References: <54D1616F.50104@oracle.com>	<54D18B9A.2020906@oracle.com>	<84AD741C-CB02-4540-B41B-8F95490FF8E4@oracle.com>	<54D2BB16.80508@oracle.com>	<77020461-FD36-41FC-9996-9B476670C20D@oracle.com>	<54D52E37.6040705@oracle.com>	<54F9FB2D.6070908@oracle.com>	<DCA6D762-7ECE-4346-99EA-C3099F4CC6A4@oracle.com>	<54FF7F99.200@oracle.com>
	<4C569089-0303-4E20-A27A-7C2B5A0DFDFD@oracle.com>
Message-ID: <5500DDBB.3080808@oracle.com>

Hi,

Here is an updated treatment of computeIfAbsent():

http://cr.openjdk.java.net/~bchristi/8071667/webrev.1/

There's a webrev, as well as built docs for Map[1], ConcurrentMap[2], 
and HashMap[3] (and I now realize there should be Hashtable as well).

I've made use of @implSpec and friends in a way I thought was sensible 
(though things could be arranged differently - I can see where some 
might find the additional headings in the rendered JavaDoc a little 
distracting ).  Let me know what you think.

Thanks,
-Brent

1. 
http://cr.openjdk.java.net/~bchristi/8071667/webrev.1/docs/api/java/util/Map.html#computeIfAbsent-K-java.util.function.Function-

2. 
http://cr.openjdk.java.net/~bchristi/8071667/webrev.1/docs/api/java/util/concurrent/ConcurrentMap.html#computeIfAbsent-K-java.util.function.Function-

3. 
http://cr.openjdk.java.net/~bchristi/8071667/webrev.1/docs/api/java/util/HashMap.html#computeIfAbsent-K-java.util.function.Function-


On 3/11/15 2:05 AM, Paul Sandoz wrote:
>
> On Mar 11, 2015, at 12:34 AM, Brent Christian <brent.christian at oracle.com> wrote:
>
>> Hi, Paul
>>
>> On 3/10/15 8:29 AM, Paul Sandoz wrote:
>>>
>>> On the Map.compute* methods.
>>>
>>> Perhaps we can reuse similar language to that we added for Matcher:
>>>
>>> * The mapping function should not modify this map during computation.
>>> * This method will, on a best-effort basis, throw a
>>> * ConcurrentModification if such modification is detected.
>>>
>>> It's tempting to place the second sentence on the @throws
>>> ConcurrentModificationException as i believe will not show up for
>>> methods on ConcurrentMap, so keeps it somewhat contained
>>> documentation wise.
>>
>> The language in Matcher is nice, and we can use it in HashMap.  But the default code in Map.compute* won't throw a CME (no iteration).
>
> That's ok, we can call that out if necessary in the @implSpec.
>
>
>>   For the compute* methods in the Map interface, I think we should stick to recommending against modifying the Map during the computation,
>
> Yes.
>
>
>> and encouraging implementing classes to check for CME.
>>
>
> Yes. My suggestion was to try and push much of the CME-related specification onto the @throws CME docs. That way less of this will appear on ConcurrentMap where CME does not make sense.
>
>
>>>> In Map/HashMap, there are already two methods that accept lambdas
>>>> and throw a CME: forEach(BiConsumer) replaceAll(BiFunction)
>>>>
>>>> (The default code does not throw a CME ifitems are added).
>>>
>>> Right, although the iterator might still be fail-fast.
>>
>> Ahh - I needed to update my test code (if a Map only has a single entry, the iterator doesn't CME when items are added because a second "iteration" never happens to detect the changed modCount).  A Map with >= 2 entries is needed for the default code to CME due to items being added during forEach()/replaceAll().
>>
>
> Yeah, it's all "best-effort".
>
> Paul.
>


From paul.sandoz at oracle.com  Thu Mar 12 09:44:09 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Mar 2015 10:44:09 +0100
Subject: RFR: JDK-8067969 Optimize Stream.count for SIZED Streams
In-Reply-To: <CAHLSyCmEPZnfe2rJe+o7con8RG1L09kQr-yL8KsC1V_1oSNhqg@mail.gmail.com>
References: <CAHLSyCmEPZnfe2rJe+o7con8RG1L09kQr-yL8KsC1V_1oSNhqg@mail.gmail.com>
Message-ID: <6C765D69-B345-4660-9277-225017018B93@oracle.com>


On Mar 11, 2015, at 1:45 PM, Aggelos Biboudis <biboudis at gmail.com> wrote:

> Hi all,
> 
> Please review the patch for the count terminal operator on SIZED streams.
> 
> https://bugs.openjdk.java.net/browse/JDK-8067969
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8067969-optimize-stream-count/webrev/
> 
> Thanks Paul Sandoz for sponsoring this.
> 

This looks good. Code is nicely contained and not as much as i initially anticipated.

I am pondering adding an api note to the count methods to head off any suprises as now the stream pipeline may not be executed.

* @apiNote
* An implementation may choose to not execute the stream pipeline (either
* sequentially or in parallel) if it is capable of computing the count
* directly from the stream source.  In such cases no source elements will
* be traversed and no intermediate operations will be evaluated.
* Behavioral parameters with side-effects, which are strongly discouraged
* except for harmless cases such as debugging, may be affected.  For
* example, consider the following stream:
* <pre>{@code
*     List<String> l = ...
*     long count = l.stream().peek(System.out::println).count();
* }</pre>
* The number of elements covered by the stream source, a {@code List}, is
* known and the intermediate operation, {@code peek}, does not inject into
* or remove elements from the stream.  Thus the count is the size of the
* {@code List} and there is no need to execute the pipeline and, as a
* side-effect, print out the list elements.

WDYT?

Paul.


From paul.sandoz at oracle.com  Thu Mar 12 09:54:38 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Mar 2015 10:54:38 +0100
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <55008820.1040601@redhat.com>
References: <54EB6DD1.4090803@redhat.com>
	<54FF3FAD.5040702@redhat.com>	<3C8D3D08-01CA-4BFF-89D7-0566D54144A9@oracle.com>	<55007B10.1010606@redhat.com>
	<AA5ECA2E-DB3E-4887-A040-E764CDBE51F0@oracle.com>
	<55008820.1040601@redhat.com>
Message-ID: <BAA1C68A-6BE9-4860-BAEA-334F63A3D2D2@oracle.com>


On Mar 11, 2015, at 7:23 PM, Andrew Haley <aph at redhat.com> wrote:

> On 03/11/2015 06:00 PM, Paul Sandoz wrote:
>> We need to include some unit tests before we can push.
> 
> I have a test which I've been using.  It could be converted into
> a unit test.
> 

Ok. There are Unsafe tests in:

  hotspot/test/runtime/Unsafe

So we could place it there.

In this particular case i think we would need to run without and with the flag UseUnalignedAccesses set to false. IIUC that just means two @run entries defined for jtreg to crunch on e.g.:

/* 
 * @test 
 * @bug XXXXXXX 
 * @run TestUnalignedAccess
 * @run main/othervm -XX:-UseUnalignedAccesses TestUnalignedAccess
 */

Paul.
 


From paul.sandoz at oracle.com  Thu Mar 12 11:00:37 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Mar 2015 12:00:37 +0100
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <55007B10.1010606@redhat.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
	<3C8D3D08-01CA-4BFF-89D7-0566D54144A9@oracle.com>
	<55007B10.1010606@redhat.com>
Message-ID: <7E49E855-D22C-490B-96F3-3762EA284915@oracle.com>


On Mar 11, 2015, at 6:27 PM, Andrew Haley <aph at redhat.com> wrote:

> On 03/11/2015 07:10 AM, John Rose wrote:
>>> 
>>> John: I'm waiting for an answer to my question here before I submit
>>> a webrev for approval.
>>> 
>>> http://mail.openjdk.java.net/pipermail/panama-dev/2015-March/000099.html
>> 
>> (Answered.)
> 
> http://cr.openjdk.java.net/~aph/unaligned.jdk.5/
> http://cr.openjdk.java.net/~aph/unaligned.hotspot.5/
> 
> I hope everybody is happy with this, or at least not so unhappy that
> they would want to reject it altogether.
> 
> There is no bug ID for this yet.

We can re-use this one:

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

Paul.

>  John, would you like to create a bug
> database entry?  If not, I'll do so.  Then I can go for a RFR, which
> hopefully should be a shoo-in now that we've beaten this thing to
> death.  :-)
> 
> Andrew.



From chris.hegarty at oracle.com  Thu Mar 12 11:05:58 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 12 Mar 2015 11:05:58 +0000
Subject: RFR: JDK-8067969 Optimize Stream.count for SIZED Streams
In-Reply-To: <6C765D69-B345-4660-9277-225017018B93@oracle.com>
References: <CAHLSyCmEPZnfe2rJe+o7con8RG1L09kQr-yL8KsC1V_1oSNhqg@mail.gmail.com>
	<6C765D69-B345-4660-9277-225017018B93@oracle.com>
Message-ID: <AC3393D0-A2C9-406C-A2D9-C85E19294B80@oracle.com>


On 12 Mar 2015, at 09:44, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> 
> On Mar 11, 2015, at 1:45 PM, Aggelos Biboudis <biboudis at gmail.com> wrote:
> 
>> Hi all,
>> 
>> Please review the patch for the count terminal operator on SIZED streams.
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8067969
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8067969-optimize-stream-count/webrev/
>> 
>> Thanks Paul Sandoz for sponsoring this.
>> 
> 
> This looks good. Code is nicely contained and not as much as i initially anticipated.

This does indeed look nice.

One, trivial, question why call spliterator.getExactSizeIfKnown() and not spliterator.estimateSize() ?

> I am pondering adding an api note to the count methods to head off any suprises as now the stream pipeline may not be executed.

I think it would be good to add a note to the spec, as this could be surprising.

So really this comes down to the type if intermediate operations, right? For example, filter will always be executed:

  IntStream.of(1, 2, 3, 4).peek(System.out::println).filter(x -> true).count();

Should the note capture something about the type of the intermediate operations?

> * @apiNote
> * An implementation may choose to not execute the stream pipeline (either
> * sequentially or in parallel) if it is capable of computing the count
> * directly from the stream source.  In such cases no source elements will
> * be traversed and no intermediate operations will be evaluated.
> * Behavioral parameters with side-effects, which are strongly discouraged
> * except for harmless cases such as debugging, may be affected.  For
> * example, consider the following stream:
> * <pre>{@code
> *     List<String> l = ...
> *     long count = l.stream().peek(System.out::println).count();
> * }</pre>
> * The number of elements covered by the stream source, a {@code List}, is
> * known and the intermediate operation, {@code peek}, does not inject into
> * or remove elements from the stream.  Thus the count is the size of the
> * {@code List} and there is no need to execute the pipeline and, as a
> * side-effect, print out the list elements.
> 
> WDYT?
> 
> Paul.

-Chris.



From aph at redhat.com  Thu Mar 12 11:09:29 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 12 Mar 2015 11:09:29 +0000
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <7E49E855-D22C-490B-96F3-3762EA284915@oracle.com>
References: <54EB6DD1.4090803@redhat.com>
	<54FF3FAD.5040702@redhat.com>	<3C8D3D08-01CA-4BFF-89D7-0566D54144A9@oracle.com>	<55007B10.1010606@redhat.com>
	<7E49E855-D22C-490B-96F3-3762EA284915@oracle.com>
Message-ID: <550173E9.1040905@redhat.com>

On 03/12/2015 11:00 AM, Paul Sandoz wrote:
> We can re-use this one:
> 
>   https://bugs.openjdk.java.net/browse/JDK-8026049

Will do, thx.

Andrew.



From paul.sandoz at oracle.com  Thu Mar 12 11:25:28 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Mar 2015 12:25:28 +0100
Subject: RFR: JDK-8067969 Optimize Stream.count for SIZED Streams
In-Reply-To: <AC3393D0-A2C9-406C-A2D9-C85E19294B80@oracle.com>
References: <CAHLSyCmEPZnfe2rJe+o7con8RG1L09kQr-yL8KsC1V_1oSNhqg@mail.gmail.com>
	<6C765D69-B345-4660-9277-225017018B93@oracle.com>
	<AC3393D0-A2C9-406C-A2D9-C85E19294B80@oracle.com>
Message-ID: <F11BEA7E-C52E-453B-BE26-90184D03873D@oracle.com>


On Mar 12, 2015, at 12:05 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> 
> On 12 Mar 2015, at 09:44, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
>> 
>> On Mar 11, 2015, at 1:45 PM, Aggelos Biboudis <biboudis at gmail.com> wrote:
>> 
>>> Hi all,
>>> 
>>> Please review the patch for the count terminal operator on SIZED streams.
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8067969
>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8067969-optimize-stream-count/webrev/
>>> 
>>> Thanks Paul Sandoz for sponsoring this.
>>> 
>> 
>> This looks good. Code is nicely contained and not as much as i initially anticipated.
> 
> This does indeed look nice.
> 
> One, trivial, question why call spliterator.getExactSizeIfKnown() and not spliterator.estimateSize() ?

Because the latter might return an estimate and not the exact size. For example, say we revamp the Files.lines for UTF-8 and optimize it, the root spliterator could report the size of the file as an estimate of the number of lines but it would not know the exact number of lines.


> 
>> I am pondering adding an api note to the count methods to head off any suprises as now the stream pipeline may not be executed.
> 
> I think it would be good to add a note to the spec, as this could be surprising.
> 
> So really this comes down to the type if intermediate operations, right?

And what optimizations the implementation can do.


> For example, filter will always be executed:
> 
>  IntStream.of(1, 2, 3, 4).peek(System.out::println).filter(x -> true).count();
> 

Yes.


> Should the note capture something about the type of the intermediate operations?
> 

How about:

* @apiNote
* An implementation may choose to not execute the stream pipeline (either
* sequentially or in parallel) if it is capable of computing the count
* directly from the stream source.  In such cases no source elements will
* be traversed and no intermediate operations will be evaluated.
* Behavioral parameters with side-effects, which are strongly discouraged
* except for harmless cases such as debugging, may be affected.  For
* example, consider the following stream:
* <pre>{@code
*     List<String> l = ...
*     long count = l.stream().peek(System.out::println).count();
* }</pre>
* The number of elements covered by the stream source, a {@code List}, is
* known and the intermediate operation, {@code peek}, does not inject into
* or remove elements from the stream (as may be the case for
* {@code flatMap} or {@code filter} operations).  Thus the count is the
* size of the {@code List} and there is no need to execute the pipeline
* and, as a side-effect, print out the list elements.

I want to tread lightly here and focus on operations that might legitimately be used for harmless side-effects.

Paul.


From Alan.Bateman at oracle.com  Thu Mar 12 12:06:02 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 12 Mar 2015 12:06:02 +0000
Subject: 8068373: (prefs) FileSystemPreferences writes \0 to XML storage, 
	causing loss of all preferences
In-Reply-To: <11C49A24-36FE-4575-A943-9BFE0D22A3F8@oracle.com>
References: <11C49A24-36FE-4575-A943-9BFE0D22A3F8@oracle.com>
Message-ID: <5501812A.7010808@oracle.com>

On 11/03/2015 18:25, Brian Burkhalter wrote:
> Hello,
>
> This message is a mere reprise of this reminder
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031848.html
>
> from February 25. The original review thread on this topic went through to its conclusion but some alternatives arose and there has been no definitive outcome. It would be good to clear this up at last.
>
> One option not mentioned in the above-linked message would be to resolve the issue as already approved and then file another one covering any change to the approach, such as listed in choices B and C in the foregoing.
>
If put throws IAE for an invalid key name then having get and remove do 
the same would be consistent. As the NUL case is a corner case and 
preferences don't seem to be widely used then I would think the 
compatibility impact of the IAE in a major release wouldn't be too 
significant. I think it should be okay to do it in a follow-on bug if 
that makes it easier.

-Alan


From chris.hegarty at oracle.com  Thu Mar 12 12:07:24 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 12 Mar 2015 12:07:24 +0000
Subject: RFR: JDK-8067969 Optimize Stream.count for SIZED Streams
In-Reply-To: <F11BEA7E-C52E-453B-BE26-90184D03873D@oracle.com>
References: <CAHLSyCmEPZnfe2rJe+o7con8RG1L09kQr-yL8KsC1V_1oSNhqg@mail.gmail.com>
	<6C765D69-B345-4660-9277-225017018B93@oracle.com>
	<AC3393D0-A2C9-406C-A2D9-C85E19294B80@oracle.com>
	<F11BEA7E-C52E-453B-BE26-90184D03873D@oracle.com>
Message-ID: <C2E823DD-1F55-4622-9C1F-3BDD09D4CAB8@oracle.com>

On 12 Mar 2015, at 11:25, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> 
> On Mar 12, 2015, at 12:05 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
>> 
>> On 12 Mar 2015, at 09:44, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> 
>>> 
>>> On Mar 11, 2015, at 1:45 PM, Aggelos Biboudis <biboudis at gmail.com> wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> Please review the patch for the count terminal operator on SIZED streams.
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8067969
>>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8067969-optimize-stream-count/webrev/
>>>> 
>>>> Thanks Paul Sandoz for sponsoring this.
>>>> 
>>> 
>>> This looks good. Code is nicely contained and not as much as i initially anticipated.
>> 
>> This does indeed look nice.
>> 
>> One, trivial, question why call spliterator.getExactSizeIfKnown() and not spliterator.estimateSize() ?
> 
> Because the latter might return an estimate and not the exact size. For example, say we revamp the Files.lines for UTF-8 and optimize it, the root spliterator could report the size of the file as an estimate of the number of lines but it would not know the exact number of lines.

OK, got it.

>>> I am pondering adding an api note to the count methods to head off any suprises as now the stream pipeline may not be executed.
>> 
>> I think it would be good to add a note to the spec, as this could be surprising.
>> 
>> So really this comes down to the type if intermediate operations, right?
> 
> And what optimizations the implementation can do.
> 
> 
>> For example, filter will always be executed:
>> 
>> IntStream.of(1, 2, 3, 4).peek(System.out::println).filter(x -> true).count();
>> 
> 
> Yes.
> 
> 
>> Should the note capture something about the type of the intermediate operations?
>> 
> 
> How about:
> 
> * @apiNote
> * An implementation may choose to not execute the stream pipeline (either
> * sequentially or in parallel) if it is capable of computing the count
> * directly from the stream source.  In such cases no source elements will
> * be traversed and no intermediate operations will be evaluated.
> * Behavioral parameters with side-effects, which are strongly discouraged
> * except for harmless cases such as debugging, may be affected.  For
> * example, consider the following stream:
> * <pre>{@code
> *     List<String> l = ...
> *     long count = l.stream().peek(System.out::println).count();
> * }</pre>
> * The number of elements covered by the stream source, a {@code List}, is
> * known and the intermediate operation, {@code peek}, does not inject into
> * or remove elements from the stream (as may be the case for
> * {@code flatMap} or {@code filter} operations).  Thus the count is the
> * size of the {@code List} and there is no need to execute the pipeline
> * and, as a side-effect, print out the list elements.

Looks good to me.

> I want to tread lightly here and focus on operations that might legitimately be used for harmless side-effects.

Make sense.

-Chris.

> Paul.



From chris.hegarty at oracle.com  Thu Mar 12 13:09:26 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 12 Mar 2015 13:09:26 +0000
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <55009E58.5080500@Oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>	<55001921.8090404@oracle.com>	<55002848.8010807@gmail.com>	<55002C2C.5040302@oracle.com>	<55002DAD.2010804@gmail.com>
	<55005454.1050906@Oracle.com> <55009E58.5080500@Oracle.com>
Message-ID: <744323AE-51AE-4BBB-88D6-D3FB9B48D56E@oracle.com>

This is looking good, still looking at the detail? just a quick comment.

It may be possible to remove the UOE from Process.onExit, if you implement the ?never to be used? default without using ProcessHandle? 

diff --git a/src/java.base/share/classes/java/lang/Process.java b/src/java.base/share/classes/java/lang/Process.java
--- a/src/java.base/share/classes/java/lang/Process.java
+++ b/src/java.base/share/classes/java/lang/Process.java
@@ -360,20 +360,20 @@
      * a unique instance is returned for each call to {@code onExit}.
      *
      * @throws IllegalStateException if the process is the current process
-     * @throws UnsupportedOperationException if the Process implementation
-     *         does not support this operation
-     * @implSpec
-     * The Process instances created by {@link ProcessBuilder ProcessBuilder} return
-     * a {@code ComputableFuture<Process>} equivalent
-     * to {@code toHandle().onExit().thenApply(ph -> this)}.
      *
-     * @implNote
-     * The implementation of this method is {@link #toHandle toHandle().onExit().thenApply(ph -> this)}.
-     * Override to provide more specific onExit behavior.
      * @since 1.9
      */
     public CompletableFuture<Process> onExit() {
-        return toHandle().onExit().thenApply((ph) -> this);
+        return CompletableFuture.supplyAsync(this::wait0);
+    }
+
+    private Process wait0() {
+        while(true) {
+            try {
+                waitFor();
+                return this;
+            } catch (InterruptedException x) {}
+        }
     }
 
     /**

-Chris.

On 11 Mar 2015, at 19:58, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi,
> 
> The recommendations have been applied to the javadoc and the sandbox JDK-8046092-branch.
> 
>    http://cr.openjdk.java.net/~rriggs/ph-apidraft/
> 
> Some operations on a Process take an extra dereference due to the delegation to ProcessHandle.
> For example, getting the cputime or startTime of the process:
>    Process p = ...
>    Duration d = p.toHandle().info().totalCpuDuration();
>    Instant start = p.toHandle().info().startInstant();
> 
> As do the listing of children; convenience methods could be introduced with the UOE possibility
> but that is a risk only for externally defined Process subtypes.
> Developers working with Processes should not have to deal with ProcessHandle
> to get information about the processes they spawn.
> 
> Comments appreciated, Roger
> 



From Roger.Riggs at Oracle.com  Thu Mar 12 13:17:50 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 12 Mar 2015 09:17:50 -0400
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <744323AE-51AE-4BBB-88D6-D3FB9B48D56E@oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>	<55001921.8090404@oracle.com>	<55002848.8010807@gmail.com>	<55002C2C.5040302@oracle.com>	<55002DAD.2010804@gmail.com>
	<55005454.1050906@Oracle.com> <55009E58.5080500@Oracle.com>
	<744323AE-51AE-4BBB-88D6-D3FB9B48D56E@oracle.com>
Message-ID: <550191FE.8000900@Oracle.com>

Seems reasonable since the choice of threads that are used to achieve 
the async behavior
is an (undocumented) implementation detail.

On 3/12/2015 9:09 AM, Chris Hegarty wrote:
> This is looking good, still looking at the detail? just a quick comment.
>
> It may be possible to remove the UOE from Process.onExit, if you implement the ?never to be used? default without using ProcessHandle?
>
> diff --git a/src/java.base/share/classes/java/lang/Process.java b/src/java.base/share/classes/java/lang/Process.java
> --- a/src/java.base/share/classes/java/lang/Process.java
> +++ b/src/java.base/share/classes/java/lang/Process.java
> @@ -360,20 +360,20 @@
>        * a unique instance is returned for each call to {@code onExit}.
>        *
>        * @throws IllegalStateException if the process is the current process
> -     * @throws UnsupportedOperationException if the Process implementation
> -     *         does not support this operation
> -     * @implSpec
> -     * The Process instances created by {@link ProcessBuilder ProcessBuilder} return
> -     * a {@code ComputableFuture<Process>} equivalent
> -     * to {@code toHandle().onExit().thenApply(ph -> this)}.
>        *
> -     * @implNote
> -     * The implementation of this method is {@link #toHandle toHandle().onExit().thenApply(ph -> this)}.
> -     * Override to provide more specific onExit behavior.
>        * @since 1.9
>        */
>       public CompletableFuture<Process> onExit() {
> -        return toHandle().onExit().thenApply((ph) -> this);
> +        return CompletableFuture.supplyAsync(this::wait0);
> +    }
> +
> +    private Process wait0() {
> +        while(true) {
> +            try {
> +                waitFor();
> +                return this;
> +            } catch (InterruptedException x) {}
> +        }
>       }
>   
>       /**
>
> -Chris.
>
> On 11 Mar 2015, at 19:58, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>
>> Hi,
>>
>> The recommendations have been applied to the javadoc and the sandbox JDK-8046092-branch.
>>
>>     http://cr.openjdk.java.net/~rriggs/ph-apidraft/
>>
>> Some operations on a Process take an extra dereference due to the delegation to ProcessHandle.
>> For example, getting the cputime or startTime of the process:
>>     Process p = ...
>>     Duration d = p.toHandle().info().totalCpuDuration();
>>     Instant start = p.toHandle().info().startInstant();
>>
>> As do the listing of children; convenience methods could be introduced with the UOE possibility
>> but that is a risk only for externally defined Process subtypes.
>> Developers working with Processes should not have to deal with ProcessHandle
>> to get information about the processes they spawn.
>>
>> Comments appreciated, Roger
>>



From Roger.Riggs at Oracle.com  Thu Mar 12 13:39:49 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 12 Mar 2015 09:39:49 -0400
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <744323AE-51AE-4BBB-88D6-D3FB9B48D56E@oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>	<55001921.8090404@oracle.com>	<55002848.8010807@gmail.com>	<55002C2C.5040302@oracle.com>	<55002DAD.2010804@gmail.com>
	<55005454.1050906@Oracle.com> <55009E58.5080500@Oracle.com>
	<744323AE-51AE-4BBB-88D6-D3FB9B48D56E@oracle.com>
Message-ID: <55019725.7090502@Oracle.com>

Hi,

Just a thought, it might be useful to introduce a public subtype of 
Process that is
returned from ProcessBuilder for which the guarantees about behavior 
could be
tighter  (no UOEs).  It would also provide a place to document the 
behaviors
now spread across ProcessBuilder and Process.

$.02, Roger


On 3/12/15 9:09 AM, Chris Hegarty wrote:
> This is looking good, still looking at the detail? just a quick comment.
>
> It may be possible to remove the UOE from Process.onExit, if you implement the ?never to be used? default without using ProcessHandle?
>
> diff --git a/src/java.base/share/classes/java/lang/Process.java b/src/java.base/share/classes/java/lang/Process.java
> --- a/src/java.base/share/classes/java/lang/Process.java
> +++ b/src/java.base/share/classes/java/lang/Process.java
> @@ -360,20 +360,20 @@
>        * a unique instance is returned for each call to {@code onExit}.
>        *
>        * @throws IllegalStateException if the process is the current process
> -     * @throws UnsupportedOperationException if the Process implementation
> -     *         does not support this operation
> -     * @implSpec
> -     * The Process instances created by {@link ProcessBuilder ProcessBuilder} return
> -     * a {@code ComputableFuture<Process>} equivalent
> -     * to {@code toHandle().onExit().thenApply(ph -> this)}.
>        *
> -     * @implNote
> -     * The implementation of this method is {@link #toHandle toHandle().onExit().thenApply(ph -> this)}.
> -     * Override to provide more specific onExit behavior.
>        * @since 1.9
>        */
>       public CompletableFuture<Process> onExit() {
> -        return toHandle().onExit().thenApply((ph) -> this);
> +        return CompletableFuture.supplyAsync(this::wait0);
> +    }
> +
> +    private Process wait0() {
> +        while(true) {
> +            try {
> +                waitFor();
> +                return this;
> +            } catch (InterruptedException x) {}
> +        }
>       }
>   
>       /**
>
> -Chris.
>
> On 11 Mar 2015, at 19:58, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>
>> Hi,
>>
>> The recommendations have been applied to the javadoc and the sandbox JDK-8046092-branch.
>>
>>     http://cr.openjdk.java.net/~rriggs/ph-apidraft/
>>
>> Some operations on a Process take an extra dereference due to the delegation to ProcessHandle.
>> For example, getting the cputime or startTime of the process:
>>     Process p = ...
>>     Duration d = p.toHandle().info().totalCpuDuration();
>>     Instant start = p.toHandle().info().startInstant();
>>
>> As do the listing of children; convenience methods could be introduced with the UOE possibility
>> but that is a risk only for externally defined Process subtypes.
>> Developers working with Processes should not have to deal with ProcessHandle
>> to get information about the processes they spawn.
>>
>> Comments appreciated, Roger
>>



From peter.levart at gmail.com  Thu Mar 12 13:56:43 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Mar 2015 14:56:43 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <55009E58.5080500@Oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>	<55001921.8090404@oracle.com>	<55002848.8010807@gmail.com>	<55002C2C.5040302@oracle.com>	<55002DAD.2010804@gmail.com>	<55005454.1050906@Oracle.com>
	<55009E58.5080500@Oracle.com>
Message-ID: <55019B1B.1060806@gmail.com>

On 03/11/2015 08:58 PM, Roger Riggs wrote:
> Hi,
>
> The recommendations have been applied to the javadoc and the sandbox 
> JDK-8046092-branch.
>
>     http://cr.openjdk.java.net/~rriggs/ph-apidraft/

That's strange. Process no longer extends ProcessHandle (which is 
visible in apidraft), but ProcessHandle still lists Process as it's 
direct subclass...

Also, the implementation note of Process.onExit() says:

Implementation Note:
    The implementation of this method is
    |toHandle().onExit().thenApply(ph -> this)|
    <http://cr.openjdk.java.net/%7Erriggs/ph-apidraft/java/lang/Process.html#toHandle-->.
    Override to provide more specific onExit behavior.


...but there is no ProcessHandle.onExit() (there is a 
ProcessHandle.completableFuture()). Looks like Process and ProcessHandle 
are from different stories?


Otherwise the Process API is now in a shape that is acceptable, I think, 
except the following:

public boolean supportsDestroyForcibly()

Returns |true| if the implementation of |destroy()| 
<http://cr.openjdk.java.net/%7Erriggs/ph-apidraft/java/lang/Process.html#destroy--> 
is forcible. Forcible process destruction is defined as the immediate 
termination of a process. Returns |false| if the implementation of 
|destroy| allows a process to shut down cleanly.

Returns:
    |true| if the implementation of |destroy()|
    <http://cr.openjdk.java.net/%7Erriggs/ph-apidraft/java/lang/Process.html#destroy-->
    is forcible; otherwise |false|
Since:
    1.9


So this is a new method that reports how existing pre-JDK8 method 
(destroy()) behaves, but specification for destory() says that it may 
behave in either way (forcibly or non-forcibly). How can default 
implementation of supportsDestroyForcibly() know how existing destory() 
behaves int external implementations?

Or was it meant for supportsDestroyForcibly() to describe behaviour of 
destroyForcibly() which is @since JDK8? In that case the specification 
of supportsDestroyForcibly() can only guarantee that 'true' result is 
correct. Default implementation must return 'false' and specification 
must say that this method may return false negative. Do you agree?


Regards, Peter


>
> Some operations on a Process take an extra dereference due to the 
> delegation to ProcessHandle.
> For example, getting the cputime or startTime of the process:
>     Process p = ...
>     Duration d = p.toHandle().info().totalCpuDuration();
>     Instant start = p.toHandle().info().startInstant();
>
> As do the listing of children; convenience methods could be introduced 
> with the UOE possibility
> but that is a risk only for externally defined Process subtypes.
> Developers working with Processes should not have to deal with 
> ProcessHandle
> to get information about the processes they spawn.
>
> Comments appreciated, Roger
>



From Roger.Riggs at Oracle.com  Thu Mar 12 14:10:14 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 12 Mar 2015 10:10:14 -0400
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <55019B1B.1060806@gmail.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>	<55001921.8090404@oracle.com>	<55002848.8010807@gmail.com>	<55002C2C.5040302@oracle.com>	<55002DAD.2010804@gmail.com>	<55005454.1050906@Oracle.com>
	<55009E58.5080500@Oracle.com> <55019B1B.1060806@gmail.com>
Message-ID: <55019E46.7010000@Oracle.com>

Hi Peter,

On 3/12/2015 9:56 AM, Peter Levart wrote:
> On 03/11/2015 08:58 PM, Roger Riggs wrote:
>> Hi,
>>
>> The recommendations have been applied to the javadoc and the sandbox 
>> JDK-8046092-branch.
>>
>> http://cr.openjdk.java.net/~rriggs/ph-apidraft/
>
> That's strange. Process no longer extends ProcessHandle (which is 
> visible in apidraft), but ProcessHandle still lists Process as it's 
> direct subclass...
Perhaps, there is some stale cache or proxy interference. I don't see 
that old version.
>
> Also, the implementation note of Process.onExit() says:
>
> Implementation Note:
>     The implementation of this method is
>     |toHandle().onExit().thenApply(ph -> this)|
>     <http://cr.openjdk.java.net/%7Erriggs/ph-apidraft/java/lang/Process.html#toHandle-->.
>     Override to provide more specific onExit behavior.
>
>
> ...but there is no ProcessHandle.onExit() (there is a 
> ProcessHandle.completableFuture()). Looks like Process and 
> ProcessHandle are from different stories?
staleness;
>
>
> Otherwise the Process API is now in a shape that is acceptable, I 
> think, except the following:
>
> public boolean supportsDestroyForcibly()
> Returns |true| if the implementation of |destroy()| 
> <http://cr.openjdk.java.net/%7Erriggs/ph-apidraft/java/lang/Process.html#destroy--> 
> is forcible. Forcible process destruction is defined as the immediate 
> termination of a process. Returns |false| if the implementation of 
> |destroy| allows a process to shut down cleanly.
>
> Returns:
>     |true| if the implementation of |destroy()|
>     <http://cr.openjdk.java.net/%7Erriggs/ph-apidraft/java/lang/Process.html#destroy-->
>     is forcible; otherwise |false|
> Since:
>     1.9
>
>
> So this is a new method that reports how existing pre-JDK8 method 
> (destroy()) behaves, but specification for destroy() says that it may 
> behave in either way (forcibly or non-forcibly). How can default 
> implementation of supportsDestroyForcibly() know how existing 
> destroy() behaves int external implementations?
>
> Or was it meant for supportsDestroyForcibly() to describe behaviour of 
> destroyForcibly() which is @since JDK8? In that case the specification 
> of supportsDestroyForcibly() can only guarantee that 'true' result is 
> correct. Default implementation must return 'false' and specification 
> must say that this method may return false negative. Do you agree?
It is intended to describe the behavior of the implementation of destroy
and should limit its concrete answers to Processes returned from 
ProcessBuilder.
Though at this late stage of Process it may not be useful to anyone.
As with other extensions to the Process API without a reasonable default 
a UOE would
be more appropriate than an incorrect value.

The alternative was to introduce a destroyNormally method that would 
throw UOE
on Windows (as there is no adequate implementation).

Thanks, Roger

>
>
> Regards, Peter
>
>
>>
>> Some operations on a Process take an extra dereference due to the 
>> delegation to ProcessHandle.
>> For example, getting the cputime or startTime of the process:
>>     Process p = ...
>>     Duration d = p.toHandle().info().totalCpuDuration();
>>     Instant start = p.toHandle().info().startInstant();
>>
>> As do the listing of children; convenience methods could be 
>> introduced with the UOE possibility
>> but that is a risk only for externally defined Process subtypes.
>> Developers working with Processes should not have to deal with 
>> ProcessHandle
>> to get information about the processes they spawn.
>>
>> Comments appreciated, Roger
>>
>



From chris.hegarty at oracle.com  Thu Mar 12 14:10:39 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 12 Mar 2015 14:10:39 +0000
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <55019B1B.1060806@gmail.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>	<55001921.8090404@oracle.com>	<55002848.8010807@gmail.com>	<55002C2C.5040302@oracle.com>	<55002DAD.2010804@gmail.com>	<55005454.1050906@Oracle.com>
	<55009E58.5080500@Oracle.com> <55019B1B.1060806@gmail.com>
Message-ID: <AB66E4B7-751A-4D0A-BC1D-6EFFA1504F49@oracle.com>

On 12 Mar 2015, at 13:56, Peter Levart <peter.levart at gmail.com> wrote:

> On 03/11/2015 08:58 PM, Roger Riggs wrote:
>> Hi,
>> 
>> The recommendations have been applied to the javadoc and the sandbox JDK-8046092-branch.
>> 
>>    http://cr.openjdk.java.net/~rriggs/ph-apidraft/
> 
> That's strange. Process no longer extends ProcessHandle (which is visible in apidraft), but ProcessHandle still lists Process as it's direct subclass...
> 
> Also, the implementation note of Process.onExit() says:
> 
> Implementation Note:
>   The implementation of this method is
>   |toHandle().onExit().thenApply(ph -> this)|
>   <http://cr.openjdk.java.net/%7Erriggs/ph-apidraft/java/lang/Process.html#toHandle-->.
>   Override to provide more specific onExit behavior.
> 
> 
> ...but there is no ProcessHandle.onExit() (there is a ProcessHandle.completableFuture()). Looks like Process and ProcessHandle are from different stories?

I think you must be suffering from browser cache issues? I don?t see these problems.

-Chris.

From magnus.ihse.bursie at oracle.com  Thu Mar 12 14:13:24 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 12 Mar 2015 15:13:24 +0100
Subject: RFR(S): JDK-8073584 Native compilation warning in unpack code
In-Reply-To: <54FEA2EA.7050409@oracle.com>
References: <54E77CA2.3090304@oracle.com>
	<54EA8B75.5040406@oracle.com>	<54EB330F.1090503@oracle.com>
	<54EBE0B8.80804@oracle.com> <54FEA2EA.7050409@oracle.com>
Message-ID: <55019F04.9090802@oracle.com>

On 2015-03-10 08:53, Dmitry Samersoff wrote:
> David at all,
>
> May I consider the fix as reviewed and continue with integration?

Dmitry,

If you fix this, maybe you can also have a look at 
https://bugs.openjdk.java.net/browse/JDK-8074839? Basically, at this 
point, it would just be about verifying that all warnings are gone, and 
remove the disabled warning flags.

/Magnus


From peter.levart at gmail.com  Thu Mar 12 14:27:22 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Mar 2015 15:27:22 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <AB66E4B7-751A-4D0A-BC1D-6EFFA1504F49@oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>	<55001921.8090404@oracle.com>	<55002848.8010807@gmail.com>	<55002C2C.5040302@oracle.com>	<55002DAD.2010804@gmail.com>	<55005454.1050906@Oracle.com>
	<55009E58.5080500@Oracle.com> <55019B1B.1060806@gmail.com>
	<AB66E4B7-751A-4D0A-BC1D-6EFFA1504F49@oracle.com>
Message-ID: <5501A24A.2090305@gmail.com>

On 03/12/2015 03:10 PM, Chris Hegarty wrote:
>> >...but there is no ProcessHandle.onExit() (there is a ProcessHandle.completableFuture()). Looks like Process and ProcessHandle are from different stories?
> I think you must be suffering from browser cache issues? I don?t see these problems.

Indeed. Sorry for fuss.

Peter



From peter.levart at gmail.com  Thu Mar 12 14:38:57 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Mar 2015 15:38:57 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <55019725.7090502@Oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>	<55001921.8090404@oracle.com>	<55002848.8010807@gmail.com>	<55002C2C.5040302@oracle.com>	<55002DAD.2010804@gmail.com>	<55005454.1050906@Oracle.com>
	<55009E58.5080500@Oracle.com>	<744323AE-51AE-4BBB-88D6-D3FB9B48D56E@oracle.com>
	<55019725.7090502@Oracle.com>
Message-ID: <5501A501.4010801@gmail.com>

On 03/12/2015 02:39 PM, Roger Riggs wrote:
> Hi,
>
> Just a thought, it might be useful to introduce a public subtype of 
> Process that is
> returned from ProcessBuilder for which the guarantees about behavior 
> could be
> tighter  (no UOEs).  It would also provide a place to document the 
> behaviors
> now spread across ProcessBuilder and Process.
>
> $.02, Roger
>

That was my thinking too today. A Process2 or XProcess? If ProcessHandle 
was an interface this subtype could implement it (back to square one). I 
think it could be an interface if Process2 was not publicly extendable 
(package-protected constructor) as it would not represent part of 
extensible API.

Does that mean that we would need additional methods 
ProcessBuilder.start2() / Runtime.exec2() too?

Peter

>
> On 3/12/15 9:09 AM, Chris Hegarty wrote:
>> This is looking good, still looking at the detail? just a quick comment.
>>
>> It may be possible to remove the UOE from Process.onExit, if you 
>> implement the ?never to be used? default without using ProcessHandle?
>>
>> diff --git a/src/java.base/share/classes/java/lang/Process.java 
>> b/src/java.base/share/classes/java/lang/Process.java
>> --- a/src/java.base/share/classes/java/lang/Process.java
>> +++ b/src/java.base/share/classes/java/lang/Process.java
>> @@ -360,20 +360,20 @@
>>        * a unique instance is returned for each call to {@code onExit}.
>>        *
>>        * @throws IllegalStateException if the process is the current 
>> process
>> -     * @throws UnsupportedOperationException if the Process 
>> implementation
>> -     *         does not support this operation
>> -     * @implSpec
>> -     * The Process instances created by {@link ProcessBuilder 
>> ProcessBuilder} return
>> -     * a {@code ComputableFuture<Process>} equivalent
>> -     * to {@code toHandle().onExit().thenApply(ph -> this)}.
>>        *
>> -     * @implNote
>> -     * The implementation of this method is {@link #toHandle 
>> toHandle().onExit().thenApply(ph -> this)}.
>> -     * Override to provide more specific onExit behavior.
>>        * @since 1.9
>>        */
>>       public CompletableFuture<Process> onExit() {
>> -        return toHandle().onExit().thenApply((ph) -> this);
>> +        return CompletableFuture.supplyAsync(this::wait0);
>> +    }
>> +
>> +    private Process wait0() {
>> +        while(true) {
>> +            try {
>> +                waitFor();
>> +                return this;
>> +            } catch (InterruptedException x) {}
>> +        }
>>       }
>>         /**
>>
>> -Chris.
>>
>> On 11 Mar 2015, at 19:58, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>
>>> Hi,
>>>
>>> The recommendations have been applied to the javadoc and the sandbox 
>>> JDK-8046092-branch.
>>>
>>>     http://cr.openjdk.java.net/~rriggs/ph-apidraft/
>>>
>>> Some operations on a Process take an extra dereference due to the 
>>> delegation to ProcessHandle.
>>> For example, getting the cputime or startTime of the process:
>>>     Process p = ...
>>>     Duration d = p.toHandle().info().totalCpuDuration();
>>>     Instant start = p.toHandle().info().startInstant();
>>>
>>> As do the listing of children; convenience methods could be 
>>> introduced with the UOE possibility
>>> but that is a risk only for externally defined Process subtypes.
>>> Developers working with Processes should not have to deal with 
>>> ProcessHandle
>>> to get information about the processes they spawn.
>>>
>>> Comments appreciated, Roger
>>>
>



From brian.burkhalter at oracle.com  Thu Mar 12 15:04:27 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 12 Mar 2015 08:04:27 -0700
Subject: 8068373: (prefs) FileSystemPreferences writes \0 to XML storage,
	causing loss of all preferences
In-Reply-To: <5501812A.7010808@oracle.com>
References: <11C49A24-36FE-4575-A943-9BFE0D22A3F8@oracle.com>
	<5501812A.7010808@oracle.com>
Message-ID: <8D1B6BE4-7A2C-4C4A-91A8-04981AECC532@oracle.com>


On Mar 12, 2015, at 5:06 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> If put throws IAE for an invalid key name then having get and remove do the same would be consistent. As the NUL case is a corner case and preferences don't seem to be widely used then I would think the compatibility impact of the IAE in a major release wouldn't be too significant. I think it should be okay to do it in a follow-on bug if that makes it easier.

I am inclined to check in the approved patch and file a follow-on issue as you suggest.

Thanks,

Brian

From paul.sandoz at oracle.com  Thu Mar 12 16:35:24 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Mar 2015 17:35:24 +0100
Subject: RFR: JDK-8067969 Optimize Stream.count for SIZED Streams
In-Reply-To: <C2E823DD-1F55-4622-9C1F-3BDD09D4CAB8@oracle.com>
References: <CAHLSyCmEPZnfe2rJe+o7con8RG1L09kQr-yL8KsC1V_1oSNhqg@mail.gmail.com>
	<6C765D69-B345-4660-9277-225017018B93@oracle.com>
	<AC3393D0-A2C9-406C-A2D9-C85E19294B80@oracle.com>
	<F11BEA7E-C52E-453B-BE26-90184D03873D@oracle.com>
	<C2E823DD-1F55-4622-9C1F-3BDD09D4CAB8@oracle.com>
Message-ID: <6FC66D89-024E-4461-A8DD-3B92215C3EBD@oracle.com>

On Mar 12, 2015, at 1:07 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
>>>> I am pondering adding an api note to the count methods to head off any suprises as now the stream pipeline may not be executed.
>>> 
>>> I think it would be good to add a note to the spec, as this could be surprising.
>>> 
>>> So really this comes down to the type if intermediate operations, right?
>> 
>> And what optimizations the implementation can do.
>> 
>> 
>>> For example, filter will always be executed:
>>> 
>>> IntStream.of(1, 2, 3, 4).peek(System.out::println).filter(x -> true).count();
>>> 
>> 
>> Yes.
>> 
>> 
>>> Should the note capture something about the type of the intermediate operations?
>>> 
>> 
>> How about:
>> 
>> * @apiNote
>> * An implementation may choose to not execute the stream pipeline (either
>> * sequentially or in parallel) if it is capable of computing the count
>> * directly from the stream source.  In such cases no source elements will
>> * be traversed and no intermediate operations will be evaluated.
>> * Behavioral parameters with side-effects, which are strongly discouraged
>> * except for harmless cases such as debugging, may be affected.  For
>> * example, consider the following stream:
>> * <pre>{@code
>> *     List<String> l = ...
>> *     long count = l.stream().peek(System.out::println).count();
>> * }</pre>
>> * The number of elements covered by the stream source, a {@code List}, is
>> * known and the intermediate operation, {@code peek}, does not inject into
>> * or remove elements from the stream (as may be the case for
>> * {@code flatMap} or {@code filter} operations).  Thus the count is the
>> * size of the {@code List} and there is no need to execute the pipeline
>> * and, as a side-effect, print out the list elements.
> 
> Looks good to me.
> 

Webrev updated:

http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8067969-optimize-stream-count/webrev/

Paul.


From peter.levart at gmail.com  Thu Mar 12 16:52:31 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Mar 2015 17:52:31 +0100
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <55007B10.1010606@redhat.com>
References: <54EB6DD1.4090803@redhat.com>
	<54FF3FAD.5040702@redhat.com>	<3C8D3D08-01CA-4BFF-89D7-0566D54144A9@oracle.com>
	<55007B10.1010606@redhat.com>
Message-ID: <5501C44F.9030105@gmail.com>



On 03/11/2015 06:27 PM, Andrew Haley wrote:
> On 03/11/2015 07:10 AM, John Rose wrote:
>>> John: I'm waiting for an answer to my question here before I submit
>>> a webrev for approval.
>>>
>>> http://mail.openjdk.java.net/pipermail/panama-dev/2015-March/000099.html
>> (Answered.)
> http://cr.openjdk.java.net/~aph/unaligned.jdk.5/
> http://cr.openjdk.java.net/~aph/unaligned.hotspot.5/
>
> I hope everybody is happy with this, or at least not so unhappy that
> they would want to reject it altogether.
>
> There is no bug ID for this yet.  John, would you like to create a bug
> database entry?  If not, I'll do so.  Then I can go for a RFR, which
> hopefully should be a shoo-in now that we've beaten this thing to
> death.  :-)
>
> Andrew.

Hi Andrew,

Just an observation. In Heap-X-Buffer.java.template, you are using 
self-sufficient form of methods for integral types:

  377     public int getInt() {
  378         return unsafe.getIntUnaligned(hb, 
byteOffset(nextGetIndex(4)), bigEndian);
  379     }
  380
  381     public int getInt(int i) {
  382         return unsafe.getIntUnaligned(hb, byteOffset(checkIndex(i, 
4)), bigEndian);
  383     }

...but for floating point, you use:

  479     public float getFloat() {
  480         return getFloat(nextGetIndex(4));
  481     }
  482
  483     public float getFloat(int i) {
  484         int x = unsafe.getIntUnaligned(hb, 
byteOffset(checkIndex(i, 4)), bigEndian);
  485         return Float.intBitsToFloat(x);
  486     }

...getFloat() is calling getFloat(int) which is a virtual method with 2 
implementations. I think it would be better to in-line the the call and 
eliminate the need to execute checkIndex()...


Regards, Peter



From peter.levart at gmail.com  Thu Mar 12 17:15:09 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Mar 2015 18:15:09 +0100
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <54FF3FAD.5040702@redhat.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
Message-ID: <5501C99D.6070901@gmail.com>



On 03/10/2015 08:02 PM, Andrew Haley wrote:
> The new algorithm does an N-way branch, always loading and storing
> subwords according to their natural alignment.  So, if the address is
> random and the size is long it will access 8 bytes 50% of the time, 4
> shorts 25% of the time, 2 ints 12.5% of the time, and 1 long 12.5% of
> the time.  So, for every random load/store we have a 4-way branch.


...so do you think it would be better if the order of checks in if/else 
chain:

  972     public final long getLongUnaligned(Object o, long offset) {
  973         if ((offset & 7) == 0) {
  974             return getLong(o, offset);
  975         } else if ((offset & 3) == 0) {
  976             return makeLong(getInt(o, offset),
  977                             getInt(o, offset + 4));
  978         } else if ((offset & 1) == 0) {
  979             return makeLong(getShort(o, offset),
  980                             getShort(o, offset + 2),
  981                             getShort(o, offset + 4),
  982                             getShort(o, offset + 6));
  983         } else {
  984             return makeLong(getByte(o, offset),
  985                             getByte(o, offset + 1),
  986                             getByte(o, offset + 2),
  987                             getByte(o, offset + 3),
  988                             getByte(o, offset + 4),
  989                             getByte(o, offset + 5),
  990                             getByte(o, offset + 6),
  991                             getByte(o, offset + 7));
  992         }
  993     }


...was reversed:

if ((offset & 1) == 1) {
     // bytes
} else if ((offset & 2) == 2) {
     // shorts
} else if ((offset & 4) == 4) {
     // ints
} else {
     // longs
}


...or are JIT+CPU smart enough and there would be no difference?


Peter



From vitalyd at gmail.com  Thu Mar 12 17:30:05 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 12 Mar 2015 13:30:05 -0400
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <5501C99D.6070901@gmail.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
	<5501C99D.6070901@gmail.com>
Message-ID: <CAHjP37GdiniVvYUWCMF92bY0PwrMRHeyz+4B-OgOJHE5TMhefQ@mail.gmail.com>

Isn't the C2 intrinsic just reading the value starting at the specified
offset directly (when unaligned access is supported) and not doing the
branching?

On Thu, Mar 12, 2015 at 1:15 PM, Peter Levart <peter.levart at gmail.com>
wrote:

>
>
> On 03/10/2015 08:02 PM, Andrew Haley wrote:
>
> The new algorithm does an N-way branch, always loading and storing
> subwords according to their natural alignment.  So, if the address is
> random and the size is long it will access 8 bytes 50% of the time, 4
> shorts 25% of the time, 2 ints 12.5% of the time, and 1 long 12.5% of
> the time.  So, for every random load/store we have a 4-way branch.
>
>
>
> ...so do you think it would be better if the order of checks in if/else
> chain:
>
>  972     public final long getLongUnaligned(Object o, long offset) {
>  973         if ((offset & 7) == 0) {
>  974             return getLong(o, offset);
>  975         } else if ((offset & 3) == 0) {
>  976             return makeLong(getInt(o, offset),
>  977                             getInt(o, offset + 4));
>  978         } else if ((offset & 1) == 0) {
>  979             return makeLong(getShort(o, offset),
>  980                             getShort(o, offset + 2),
>  981                             getShort(o, offset + 4),
>  982                             getShort(o, offset + 6));
>  983         } else {
>  984             return makeLong(getByte(o, offset),
>  985                             getByte(o, offset + 1),
>  986                             getByte(o, offset + 2),
>  987                             getByte(o, offset + 3),
>  988                             getByte(o, offset + 4),
>  989                             getByte(o, offset + 5),
>  990                             getByte(o, offset + 6),
>  991                             getByte(o, offset + 7));
>  992         }
>  993     }
>
>
> ...was reversed:
>
> if ((offset & 1) == 1) {
>     // bytes
> } else if ((offset & 2) == 2) {
>     // shorts
> } else if ((offset & 4) == 4) {
>     // ints
> } else {
>     // longs
> }
>
>
> ...or are JIT+CPU smart enough and there would be no difference?
>
>
> Peter
>
>


From peter.levart at gmail.com  Thu Mar 12 18:07:03 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Mar 2015 19:07:03 +0100
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <CAHjP37GdiniVvYUWCMF92bY0PwrMRHeyz+4B-OgOJHE5TMhefQ@mail.gmail.com>
References: <54EB6DD1.4090803@redhat.com>	<54FF3FAD.5040702@redhat.com>	<5501C99D.6070901@gmail.com>
	<CAHjP37GdiniVvYUWCMF92bY0PwrMRHeyz+4B-OgOJHE5TMhefQ@mail.gmail.com>
Message-ID: <5501D5C7.8020807@gmail.com>



On 03/12/2015 06:30 PM, Vitaly Davidovich wrote:
> Isn't the C2 intrinsic just reading the value starting at the 
> specified offset directly (when unaligned access is supported) and not 
> doing the branching?

It is. This code is for those platforms not supporting unaligned accesses.

Peter

>
> On Thu, Mar 12, 2015 at 1:15 PM, Peter Levart <peter.levart at gmail.com 
> <mailto:peter.levart at gmail.com>> wrote:
>
>
>
>     On 03/10/2015 08:02 PM, Andrew Haley wrote:
>>     The new algorithm does an N-way branch, always loading and storing
>>     subwords according to their natural alignment.  So, if the address is
>>     random and the size is long it will access 8 bytes 50% of the time, 4
>>     shorts 25% of the time, 2 ints 12.5% of the time, and 1 long 12.5% of
>>     the time.  So, for every random load/store we have a 4-way branch.
>
>
>     ...so do you think it would be better if the order of checks in
>     if/else chain:
>
>      972     public final long getLongUnaligned(Object o, long offset) {
>      973         if ((offset & 7) == 0) {
>      974             return getLong(o, offset);
>      975         } else if ((offset & 3) == 0) {
>      976             return makeLong(getInt(o, offset),
>      977                             getInt(o, offset + 4));
>      978         } else if ((offset & 1) == 0) {
>      979             return makeLong(getShort(o, offset),
>      980                             getShort(o, offset + 2),
>      981                             getShort(o, offset + 4),
>      982                             getShort(o, offset + 6));
>      983         } else {
>      984             return makeLong(getByte(o, offset),
>      985                             getByte(o, offset + 1),
>      986                             getByte(o, offset + 2),
>      987                             getByte(o, offset + 3),
>      988                             getByte(o, offset + 4),
>      989                             getByte(o, offset + 5),
>      990                             getByte(o, offset + 6),
>      991                             getByte(o, offset + 7));
>      992         }
>      993     }
>
>
>     ...was reversed:
>
>     if ((offset & 1) == 1) {
>         // bytes
>     } else if ((offset & 2) == 2) {
>         // shorts
>     } else if ((offset & 4) == 4) {
>         // ints
>     } else {
>         // longs
>     }
>
>
>     ...or are JIT+CPU smart enough and there would be no difference?
>
>
>     Peter
>
>



From vitalyd at gmail.com  Thu Mar 12 18:16:49 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 12 Mar 2015 14:16:49 -0400
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <5501D5C7.8020807@gmail.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
	<5501C99D.6070901@gmail.com>
	<CAHjP37GdiniVvYUWCMF92bY0PwrMRHeyz+4B-OgOJHE5TMhefQ@mail.gmail.com>
	<5501D5C7.8020807@gmail.com>
Message-ID: <CAHjP37GtJOaGHHjPky_QQ=Z9NV2CCWWGmM36TP-N2_B15mYkng@mail.gmail.com>

Right, ok -- just wanted to make sure I wasn't missing something.  For
platforms that don't support unaligned access, is it expected that callers
will be reading/writing addresses that are unaligned to the size of the
type they're reading? My hunch is that on such platforms folks would tend
to align their data layouts so as to avoid unaligned operations, in which
case checking for "natural" alignment first makes sense.  But I don't know
if that's actually true or not.

On Thu, Mar 12, 2015 at 2:07 PM, Peter Levart <peter.levart at gmail.com>
wrote:

>
>
> On 03/12/2015 06:30 PM, Vitaly Davidovich wrote:
>
> Isn't the C2 intrinsic just reading the value starting at the specified
> offset directly (when unaligned access is supported) and not doing the
> branching?
>
>
> It is. This code is for those platforms not supporting unaligned accesses.
>
> Peter
>
>
>
> On Thu, Mar 12, 2015 at 1:15 PM, Peter Levart <peter.levart at gmail.com>
> wrote:
>
>>
>>
>> On 03/10/2015 08:02 PM, Andrew Haley wrote:
>>
>> The new algorithm does an N-way branch, always loading and storing
>> subwords according to their natural alignment.  So, if the address is
>> random and the size is long it will access 8 bytes 50% of the time, 4
>> shorts 25% of the time, 2 ints 12.5% of the time, and 1 long 12.5% of
>> the time.  So, for every random load/store we have a 4-way branch.
>>
>>
>>
>>  ...so do you think it would be better if the order of checks in if/else
>> chain:
>>
>>  972     public final long getLongUnaligned(Object o, long offset) {
>>  973         if ((offset & 7) == 0) {
>>  974             return getLong(o, offset);
>>  975         } else if ((offset & 3) == 0) {
>>  976             return makeLong(getInt(o, offset),
>>  977                             getInt(o, offset + 4));
>>  978         } else if ((offset & 1) == 0) {
>>  979             return makeLong(getShort(o, offset),
>>  980                             getShort(o, offset + 2),
>>  981                             getShort(o, offset + 4),
>>  982                             getShort(o, offset + 6));
>>  983         } else {
>>  984             return makeLong(getByte(o, offset),
>>  985                             getByte(o, offset + 1),
>>  986                             getByte(o, offset + 2),
>>  987                             getByte(o, offset + 3),
>>  988                             getByte(o, offset + 4),
>>  989                             getByte(o, offset + 5),
>>  990                             getByte(o, offset + 6),
>>  991                             getByte(o, offset + 7));
>>  992         }
>>  993     }
>>
>>
>> ...was reversed:
>>
>> if ((offset & 1) == 1) {
>>     // bytes
>> } else if ((offset & 2) == 2) {
>>     // shorts
>> } else if ((offset & 4) == 4) {
>>     // ints
>> } else {
>>     // longs
>> }
>>
>>
>> ...or are JIT+CPU smart enough and there would be no difference?
>>
>>
>> Peter
>>
>>
>
>


From aph at redhat.com  Thu Mar 12 18:35:53 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 12 Mar 2015 18:35:53 +0000
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <5501C44F.9030105@gmail.com>
References: <54EB6DD1.4090803@redhat.com>
	<54FF3FAD.5040702@redhat.com>	<3C8D3D08-01CA-4BFF-89D7-0566D54144A9@oracle.com>
	<55007B10.1010606@redhat.com> <5501C44F.9030105@gmail.com>
Message-ID: <5501DC89.8040806@redhat.com>

On 03/12/2015 04:52 PM, Peter Levart wrote:
> ...getFloat() is calling getFloat(int) which is a virtual method with 2 
> implementations. I think it would be better to in-line the the call and 
> eliminate the need to execute checkIndex()...

Okay; I guess it is more symmetrical that way.  I did have a look
at the generated code and the redundant index check was eliminated,
but you can't guarantee it always will be.

Thanks
Andrew.



From aph at redhat.com  Thu Mar 12 18:37:28 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 12 Mar 2015 18:37:28 +0000
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <5501C99D.6070901@gmail.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
	<5501C99D.6070901@gmail.com>
Message-ID: <5501DCE8.3010108@redhat.com>

On 03/12/2015 05:15 PM, Peter Levart wrote:
> ...or are JIT+CPU smart enough and there would be no difference?

C2 always orders things based on profile counts, so there is no
difference.  Your suggestion would be better for interpreted code
and I guess C1 also, so I agree it is worthwhile.

Thanks,
Andrew.



From peter.levart at gmail.com  Thu Mar 12 19:15:30 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Mar 2015 20:15:30 +0100
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <CAHjP37GtJOaGHHjPky_QQ=Z9NV2CCWWGmM36TP-N2_B15mYkng@mail.gmail.com>
References: <54EB6DD1.4090803@redhat.com>	<54FF3FAD.5040702@redhat.com>	<5501C99D.6070901@gmail.com>	<CAHjP37GdiniVvYUWCMF92bY0PwrMRHeyz+4B-OgOJHE5TMhefQ@mail.gmail.com>	<5501D5C7.8020807@gmail.com>
	<CAHjP37GtJOaGHHjPky_QQ=Z9NV2CCWWGmM36TP-N2_B15mYkng@mail.gmail.com>
Message-ID: <5501E5D2.5060206@gmail.com>



On 03/12/2015 07:16 PM, Vitaly Davidovich wrote:
> Right, ok -- just wanted to make sure I wasn't missing something.  For 
> platforms that don't support unaligned access, is it expected that 
> callers will be reading/writing addresses that are unaligned to the 
> size of the type they're reading? My hunch is that on such platforms 
> folks would tend to align their data layouts so as to avoid unaligned 
> operations, in which case checking for "natural" alignment first makes 
> sense. But I don't know if that's actually true or not.

It depends on usage yes. But "Java" is a platform-independent "Platform" 
and these Unsafe methods are meant to abstract-away the platform dependency.

Peter

>
> On Thu, Mar 12, 2015 at 2:07 PM, Peter Levart <peter.levart at gmail.com 
> <mailto:peter.levart at gmail.com>> wrote:
>
>
>
>     On 03/12/2015 06:30 PM, Vitaly Davidovich wrote:
>>     Isn't the C2 intrinsic just reading the value starting at the
>>     specified offset directly (when unaligned access is supported)
>>     and not doing the branching?
>
>     It is. This code is for those platforms not supporting unaligned
>     accesses.
>
>     Peter
>
>
>>
>>     On Thu, Mar 12, 2015 at 1:15 PM, Peter Levart
>>     <peter.levart at gmail.com <mailto:peter.levart at gmail.com>> wrote:
>>
>>
>>
>>         On 03/10/2015 08:02 PM, Andrew Haley wrote:
>>>         The new algorithm does an N-way branch, always loading and storing
>>>         subwords according to their natural alignment.  So, if the address is
>>>         random and the size is long it will access 8 bytes 50% of the time, 4
>>>         shorts 25% of the time, 2 ints 12.5% of the time, and 1 long 12.5% of
>>>         the time.  So, for every random load/store we have a 4-way branch.
>>
>>
>>         ...so do you think it would be better if the order of checks
>>         in if/else chain:
>>
>>          972     public final long getLongUnaligned(Object o, long
>>         offset) {
>>          973         if ((offset & 7) == 0) {
>>          974             return getLong(o, offset);
>>          975         } else if ((offset & 3) == 0) {
>>          976             return makeLong(getInt(o, offset),
>>          977                             getInt(o, offset + 4));
>>          978         } else if ((offset & 1) == 0) {
>>          979             return makeLong(getShort(o, offset),
>>          980                             getShort(o, offset + 2),
>>          981                             getShort(o, offset + 4),
>>          982                             getShort(o, offset + 6));
>>          983         } else {
>>          984             return makeLong(getByte(o, offset),
>>          985                             getByte(o, offset + 1),
>>          986                             getByte(o, offset + 2),
>>          987                             getByte(o, offset + 3),
>>          988                             getByte(o, offset + 4),
>>          989                             getByte(o, offset + 5),
>>          990                             getByte(o, offset + 6),
>>          991                             getByte(o, offset + 7));
>>          992         }
>>          993     }
>>
>>
>>         ...was reversed:
>>
>>         if ((offset & 1) == 1) {
>>             // bytes
>>         } else if ((offset & 2) == 2) {
>>             // shorts
>>         } else if ((offset & 4) == 4) {
>>             // ints
>>         } else {
>>             // longs
>>         }
>>
>>
>>         ...or are JIT+CPU smart enough and there would be no difference?
>>
>>
>>         Peter
>>
>>
>
>



From peter.levart at gmail.com  Thu Mar 12 19:29:19 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Mar 2015 20:29:19 +0100
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <5501DCE8.3010108@redhat.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
	<5501C99D.6070901@gmail.com> <5501DCE8.3010108@redhat.com>
Message-ID: <5501E90F.5010103@gmail.com>



On 03/12/2015 07:37 PM, Andrew Haley wrote:
> On 03/12/2015 05:15 PM, Peter Levart wrote:
>> ...or are JIT+CPU smart enough and there would be no difference?
> C2 always orders things based on profile counts, so there is no
> difference.  Your suggestion would be better for interpreted code
> and I guess C1 also, so I agree it is worthwhile.
>
> Thanks,
> Andrew.
>

What about the following variant (or similar with ifs in case switch is 
sub-optimal):

     public final long getLongUnaligned(Object o, long offset) {
         switch ((int) offset & 7) {
             case 1:
             case 5: return
                 (toUnsignedLong(getByte(o, offset)) << pickPos(56, 0)) |
                 (toUnsignedLong(getShort(o, offset + 1)) << pickPos(48, 
8)) |
                 (toUnsignedLong(getInt(o, offset + 3)) << pickPos(32, 
24)) |
                 (toUnsignedLong(getByte(o, offset + 7)) << pickPos(56, 
56));
             case 2:
             case 6: return
                 (toUnsignedLong(getShort(o, offset)) << pickPos(48, 0)) |
                 (toUnsignedLong(getInt(o, offset + 2)) << pickPos(32, 
16)) |
                 (toUnsignedLong(getShort(o, offset + 6)) << pickPos(48, 
48));
             case 3:
             case 7: return
                 (toUnsignedLong(getByte(o, offset)) << pickPos(56, 0)) |
                 (toUnsignedLong(getInt(o, offset + 1)) << pickPos(32, 8)) |
                 (toUnsignedLong(getShort(o, offset + 5)) << pickPos(48, 
40)) |
                 (toUnsignedLong(getByte(o, offset + 7)) << pickPos(56, 
56));
             case 4: return
                 (toUnsignedLong(getInt(o, offset)) << pickPos(32, 0)) |
                 (toUnsignedLong(getInt(o, offset + 4)) << pickPos(32, 32));
             case 0:
             default: return
                 getLong(o, offset);
         }
     }


...it may have more branches, but less instructions in average per call.



Peter



From Roger.Riggs at Oracle.com  Thu Mar 12 20:41:06 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 12 Mar 2015 16:41:06 -0400
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <5501A501.4010801@gmail.com>
References: <54D941D1.8000305@Oracle.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>	<55001921.8090404@oracle.com>	<55002848.8010807@gmail.com>	<55002C2C.5040302@oracle.com>	<55002DAD.2010804@gmail.com>	<55005454.1050906@Oracle.com>
	<55009E58.5080500@Oracle.com>	<744323AE-51AE-4BBB-88D6-D3FB9B48D56E@oracle.com>
	<55019725.7090502@Oracle.com> <5501A501.4010801@gmail.com>
Message-ID: <5501F9E2.1020407@Oracle.com>

Hi Peter,

Introducing a public Process subtype would not be a binary compatible 
change;
the return type of ProcessBuilder.start can not be narrowed.
As you surmised, a different start method would be needed on ProcessBuilder.
Since ProcessBuilder is the preferred mechanism to created processes, I 
would
leave Runtime.exec alone to avoid a proliferation of similar methods.

If ProcessHandle were an interface, Process would still have the 
conflict over the
return type of onExit() since CompletableFuture<Process> is not type 
compatible
with CF<ProcessHandle>.  So not quite the winning combination to enable 
polymorphism.

Roger


On 3/12/2015 10:38 AM, Peter Levart wrote:
> On 03/12/2015 02:39 PM, Roger Riggs wrote:
>> Hi,
>>
>> Just a thought, it might be useful to introduce a public subtype of 
>> Process that is
>> returned from ProcessBuilder for which the guarantees about behavior 
>> could be
>> tighter  (no UOEs).  It would also provide a place to document the 
>> behaviors
>> now spread across ProcessBuilder and Process.
>>
>> $.02, Roger
>>
>
> That was my thinking too today. A Process2 or XProcess? If 
> ProcessHandle was an interface this subtype could implement it (back 
> to square one). I think it could be an interface if Process2 was not 
> publicly extendable (package-protected constructor) as it would not 
> represent part of extensible API.
>
> Does that mean that we would need additional methods 
> ProcessBuilder.start2() / Runtime.exec2() too?
>
> Peter
>


From Alan.Bateman at oracle.com  Thu Mar 12 20:49:20 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 12 Mar 2015 20:49:20 +0000
Subject: RFR [9] 8071472: Add field access to support setting final fields
	in readObject
In-Reply-To: <3F1CE33B-5C13-4172-A78B-72F476E0654E@oracle.com>
References: <3F1CE33B-5C13-4172-A78B-72F476E0654E@oracle.com>
Message-ID: <5501FBD0.4010109@oracle.com>

On 05/03/2015 13:46, Chris Hegarty wrote:
> :
>
> Example:
>      class Stamp implements Serializable {
>          private transient final long millis;
>          Stamp() { millis = System.currentTimeMillis(); }
>          public long stamp() { return millis; }
>
>          private void readObject(java.io.ObjectInputStream in) throws Exception {
>              in.fields().set("millis", System.currentTimeMillis());
>          }
>      }
>
> We have a fully working implementation, tests, etc, in the sandbox:
>      hg clone http://hg.openjdk.java.net/jdk9/sandbox sandbox
>      cd sandbox
>      sh get_source.sh
>      sh common/bin/hgforest.sh update -r serial-exp-branch
>      
>    Webrev for convenience:
>      http://cr.openjdk.java.net/~chegar/8071472/00/webrev/
>
I've spent some time looking at this and trying it out. It's very 
simple, doesn't impact any existing readObject implementations, and 
provides a way to set final fields without restoring to Unsafe.

So if a readObject calls fields() without calling defaultReadObject() 
then it has to set every final field. On one hand that ensures that 
every final field is set, on the other hand it is a bit odd because 
omitting the call to fields() means they all get their default value.

I think serialization types with final fields that aren't in the 
serialized form will really like this. To help developers then it might 
be useful to put an example in the javadoc with final && transient field 
to show the usage.

One other thing is naming as OIS.FieldAccess in the current patch hints 
that it provides general access. It feels like it should be something 
like ObjectFieldSetter with fields() changing to something like 
fieldSetter() to make that clearer too.

-Alan.






From peter.levart at gmail.com  Thu Mar 12 21:04:50 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Mar 2015 22:04:50 +0100
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <5501E90F.5010103@gmail.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
	<5501C99D.6070901@gmail.com> <5501DCE8.3010108@redhat.com>
	<5501E90F.5010103@gmail.com>
Message-ID: <5501FF72.60004@gmail.com>



On 03/12/2015 08:29 PM, Peter Levart wrote:
>
>
> On 03/12/2015 07:37 PM, Andrew Haley wrote:
>> On 03/12/2015 05:15 PM, Peter Levart wrote:
>>> ...or are JIT+CPU smart enough and there would be no difference?
>> C2 always orders things based on profile counts, so there is no
>> difference.  Your suggestion would be better for interpreted code
>> and I guess C1 also, so I agree it is worthwhile.
>>
>> Thanks,
>> Andrew.
>>
>
> What about the following variant (or similar with ifs in case switch 
> is sub-optimal):
>
>     public final long getLongUnaligned(Object o, long offset) {
>         switch ((int) offset & 7) {
>             case 1:
>             case 5: return
>                 (toUnsignedLong(getByte(o, offset)) << pickPos(56, 0)) |
>                 (toUnsignedLong(getShort(o, offset + 1)) << 
> pickPos(48, 8)) |
>                 (toUnsignedLong(getInt(o, offset + 3)) << pickPos(32, 
> 24)) |
>                 (toUnsignedLong(getByte(o, offset + 7)) << pickPos(56, 
> 56));
>             case 2:
>             case 6: return
>                 (toUnsignedLong(getShort(o, offset)) << pickPos(48, 0)) |
>                 (toUnsignedLong(getInt(o, offset + 2)) << pickPos(32, 
> 16)) |
>                 (toUnsignedLong(getShort(o, offset + 6)) << 
> pickPos(48, 48));
>             case 3:
>             case 7: return
>                 (toUnsignedLong(getByte(o, offset)) << pickPos(56, 0)) |
>                 (toUnsignedLong(getInt(o, offset + 1)) << pickPos(32, 
> 8)) |
>                 (toUnsignedLong(getShort(o, offset + 5)) << 
> pickPos(48, 40)) |
>                 (toUnsignedLong(getByte(o, offset + 7)) << pickPos(56, 
> 56));
>             case 4: return
>                 (toUnsignedLong(getInt(o, offset)) << pickPos(32, 0)) |
>                 (toUnsignedLong(getInt(o, offset + 4)) << pickPos(32, 
> 32));
>             case 0:
>             default: return
>                 getLong(o, offset);
>         }
>     }
>
>
> ...it may have more branches, but less instructions in average per call.
>
>
>
> Peter
>

... putLongUnaligned in the style of above getLongUnaligned is more 
tricky with current code structure. But there may be a middle ground (or 
a sweet spot):


     public final void putLongUnaligned(Object o, long offset, long x) {
         if (((int) offset & 1) == 1) {
             putLongParts(o, offset,
                 (byte) (x >>> 0),
                 (short) (x >>> 8),
                 (short) (x >>> 24),
                 (short) (x >>> 40),
                 (byte) (x >>> 56));
         } else if (((int) offset & 2) == 2) {
             putLongParts(o, offset,
                 (short)(x >>> 0),
                 (int)(x >>> 16),
                 (short)(x >>> 48));
         } else if (((int) offset & 4) == 4) {
             putLongParts(o, offset,
                 (int)(x >> 0),
                 (int)(x >>> 32));
         } else {
             putLong(o, offset, x);
         }
     }


...this has the same number of branches, but less instructions. You also 
need the following two:


     private void putLongParts(Object o, long offset, byte i0, short 
i12, short i34, short i56, byte i7) {
         putByte(o, offset + 0, pick(i0, i7));
         putShort(o, offset + 1, pick(i12, i56));
         putShort(o, offset + 3, i34);
         putShort(o, offset + 5, pick(i56, i12));
         putByte(o, offset + 7, pick(i7, i0));
     }

     private void putLongParts(Object o, long offset, short i0, int i12, 
short i3) {
         putShort(o, offset + 0, pick(i0, i3));
         putInt(o, offset + 2, i12);
         putShort(o, offset + 6, pick(i3, i0));
     }



Regards, Peter



From aph at redhat.com  Thu Mar 12 21:05:50 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 12 Mar 2015 21:05:50 +0000
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <5501E90F.5010103@gmail.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
	<5501C99D.6070901@gmail.com> <5501DCE8.3010108@redhat.com>
	<5501E90F.5010103@gmail.com>
Message-ID: <5501FFAE.1030503@redhat.com>

On 03/12/2015 07:29 PM, Peter Levart wrote:
> What about the following variant (or similar with ifs in case switch is 
> sub-optimal):
> 
>      public final long getLongUnaligned(Object o, long offset) {
>          switch ((int) offset & 7)
...

I tried that already, and it wasn't really any faster, and it won't
vectorize nicely (vectorization was high on John's list).

Andrew.



From peter.levart at gmail.com  Thu Mar 12 21:17:33 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Mar 2015 22:17:33 +0100
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <5501FFAE.1030503@redhat.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
	<5501C99D.6070901@gmail.com> <5501DCE8.3010108@redhat.com>
	<5501E90F.5010103@gmail.com> <5501FFAE.1030503@redhat.com>
Message-ID: <5502026D.5030009@gmail.com>



On 03/12/2015 10:05 PM, Andrew Haley wrote:
> On 03/12/2015 07:29 PM, Peter Levart wrote:
>> What about the following variant (or similar with ifs in case switch is
>> sub-optimal):
>>
>>       public final long getLongUnaligned(Object o, long offset) {
>>           switch ((int) offset & 7)
> ...
>
> I tried that already, and it wasn't really any faster, and it won't
> vectorize nicely (vectorization was high on John's list).

Ah, I see.

> Andrew.
>



From vitalyd at gmail.com  Thu Mar 12 22:02:43 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 12 Mar 2015 18:02:43 -0400
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <5501FFAE.1030503@redhat.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
	<5501C99D.6070901@gmail.com> <5501DCE8.3010108@redhat.com>
	<5501E90F.5010103@gmail.com> <5501FFAE.1030503@redhat.com>
Message-ID: <CAHjP37FzN5UfsweOh8+XrNkC9GB9AjxVKyFTH=WP10YQeWwXRw@mail.gmail.com>

Is vectorization coming soon? AFAIK, only memory copies are vectorized
currently but not any arithmetic or the like.

sent from my phone
On Mar 12, 2015 5:06 PM, "Andrew Haley" <aph at redhat.com> wrote:

> On 03/12/2015 07:29 PM, Peter Levart wrote:
> > What about the following variant (or similar with ifs in case switch is
> > sub-optimal):
> >
> >      public final long getLongUnaligned(Object o, long offset) {
> >          switch ((int) offset & 7)
> ...
>
> I tried that already, and it wasn't really any faster, and it won't
> vectorize nicely (vectorization was high on John's list).
>
> Andrew.
>
>


From peter.levart at gmail.com  Thu Mar 12 22:05:36 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Mar 2015 23:05:36 +0100
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <5501FF72.60004@gmail.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
	<5501C99D.6070901@gmail.com> <5501DCE8.3010108@redhat.com>
	<5501E90F.5010103@gmail.com> <5501FF72.60004@gmail.com>
Message-ID: <55020DB0.8040901@gmail.com>



On 03/12/2015 10:04 PM, Peter Levart wrote:
> ... putLongUnaligned in the style of above getLongUnaligned is more 
> tricky with current code structure. But there may be a middle ground 
> (or a sweet spot):
>
>
>     public final void putLongUnaligned(Object o, long offset, long x) {
>         if (((int) offset & 1) == 1) {
>             putLongParts(o, offset,
>                 (byte) (x >>> 0),
>                 (short) (x >>> 8),
>                 (short) (x >>> 24),
>                 (short) (x >>> 40),
>                 (byte) (x >>> 56));
>         } else if (((int) offset & 2) == 2) {
>             putLongParts(o, offset,
>                 (short)(x >>> 0),
>                 (int)(x >>> 16),
>                 (short)(x >>> 48));
>         } else if (((int) offset & 4) == 4) {
>             putLongParts(o, offset,
>                 (int)(x >> 0),
>                 (int)(x >>> 32));
>         } else {
>             putLong(o, offset, x);
>         }
>     }
>
>
> ...this has the same number of branches, but less instructions. You 
> also need the following two:


At least on Intel (with -XX:-UseUnalignedAccesses) above code 
(Unaligned2) is not any faster then your code (Unaligned) according to a 
JMH random-access test. Neither is the reversal of if/else branches 
(Unaligned1). Unaligned3 is switch-based variant (just get) and is 
slowest. Your variant seems to be the fastest by a hair:

Benchmark                               Mode   Samples Score  Score 
error    Units
j.t.UnalignedTest.getLongUnaligned      avgt 5       16.375        
0.837    ns/op
j.t.UnalignedTest.getLongUnaligned1     avgt 5       18.340        
0.617    ns/op
j.t.UnalignedTest.getLongUnaligned2     avgt 5       16.784        
0.969    ns/op
j.t.UnalignedTest.getLongUnaligned3     avgt 5       19.634        
0.871    ns/op
j.t.UnalignedTest.putLongUnaligned      avgt 5       15.521        
0.589    ns/op
j.t.UnalignedTest.putLongUnaligned1     avgt 5       16.676        
1.042    ns/op
j.t.UnalignedTest.putLongUnaligned2     avgt 5       16.394        
3.028    ns/op


Regards, Peter

Peter



From vitalyd at gmail.com  Thu Mar 12 22:15:53 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 12 Mar 2015 18:15:53 -0400
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <55020DB0.8040901@gmail.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
	<5501C99D.6070901@gmail.com> <5501DCE8.3010108@redhat.com>
	<5501E90F.5010103@gmail.com> <5501FF72.60004@gmail.com>
	<55020DB0.8040901@gmail.com>
Message-ID: <CAHjP37F+7OiWTdwp8N=3AFP+AjXbL0agV6tPNBwOXAosk=3Oow@mail.gmail.com>

Switches currently don't profile well (if at all) - John can shed more
light on that as this came up on the compiler list a few weeks ago.

sent from my phone
On Mar 12, 2015 6:06 PM, "Peter Levart" <peter.levart at gmail.com> wrote:

>
>
> On 03/12/2015 10:04 PM, Peter Levart wrote:
>
> ... putLongUnaligned in the style of above getLongUnaligned is more tricky
> with current code structure. But there may be a middle ground (or a sweet
> spot):
>
>
>     public final void putLongUnaligned(Object o, long offset, long x) {
>         if (((int) offset & 1) == 1) {
>             putLongParts(o, offset,
>                 (byte) (x >>> 0),
>                 (short) (x >>> 8),
>                 (short) (x >>> 24),
>                 (short) (x >>> 40),
>                 (byte) (x >>> 56));
>         } else if (((int) offset & 2) == 2) {
>             putLongParts(o, offset,
>                 (short)(x >>> 0),
>                 (int)(x >>> 16),
>                 (short)(x >>> 48));
>         } else if (((int) offset & 4) == 4) {
>             putLongParts(o, offset,
>                 (int)(x >> 0),
>                 (int)(x >>> 32));
>         } else {
>             putLong(o, offset, x);
>         }
>     }
>
>
> ...this has the same number of branches, but less instructions. You also
> need the following two:
>
>
>
> At least on Intel (with -XX:-UseUnalignedAccesses) above code (Unaligned2)
> is not any faster then your code (Unaligned) according to a JMH
> random-access test. Neither is the reversal of if/else branches
> (Unaligned1). Unaligned3 is switch-based variant (just get) and is slowest.
> Your variant seems to be the fastest by a hair:
>
> Benchmark                               Mode   Samples        Score  Score
> error    Units
> j.t.UnalignedTest.getLongUnaligned      avgt         5       16.375
> 0.837    ns/op
> j.t.UnalignedTest.getLongUnaligned1     avgt         5       18.340
> 0.617    ns/op
> j.t.UnalignedTest.getLongUnaligned2     avgt         5       16.784
> 0.969    ns/op
> j.t.UnalignedTest.getLongUnaligned3     avgt         5       19.634
> 0.871    ns/op
> j.t.UnalignedTest.putLongUnaligned      avgt         5       15.521
> 0.589    ns/op
> j.t.UnalignedTest.putLongUnaligned1     avgt         5       16.676
> 1.042    ns/op
> j.t.UnalignedTest.putLongUnaligned2     avgt         5       16.394
> 3.028    ns/op
>
>
> Regards, Peter
>
> Peter
>
>


From peter.levart at gmail.com  Thu Mar 12 22:24:35 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Mar 2015 23:24:35 +0100
Subject: RFR [9] 8071472: Add field access to support setting final fields
	in readObject
In-Reply-To: <5501FBD0.4010109@oracle.com>
References: <3F1CE33B-5C13-4172-A78B-72F476E0654E@oracle.com>
	<5501FBD0.4010109@oracle.com>
Message-ID: <55021223.6060006@gmail.com>



On 03/12/2015 09:49 PM, Alan Bateman wrote:
> On 05/03/2015 13:46, Chris Hegarty wrote:
>> :
>>
>> Example:
>>      class Stamp implements Serializable {
>>          private transient final long millis;
>>          Stamp() { millis = System.currentTimeMillis(); }
>>          public long stamp() { return millis; }
>>
>>          private void readObject(java.io.ObjectInputStream in) throws 
>> Exception {
>>              in.fields().set("millis", System.currentTimeMillis());
>>          }
>>      }
>>
>> We have a fully working implementation, tests, etc, in the sandbox:
>>      hg clone http://hg.openjdk.java.net/jdk9/sandbox sandbox
>>      cd sandbox
>>      sh get_source.sh
>>      sh common/bin/hgforest.sh update -r serial-exp-branch
>>         Webrev for convenience:
>>      http://cr.openjdk.java.net/~chegar/8071472/00/webrev/
>>

Hi Alan,

> I've spent some time looking at this and trying it out. It's very 
> simple, doesn't impact any existing readObject implementations, and 
> provides a way to set final fields without restoring to Unsafe.

That was the plan. :-)

>
> So if a readObject calls fields() without calling defaultReadObject() 
> then it has to set every final field. On one hand that ensures that 
> every final field is set, on the other hand it is a bit odd because 
> omitting the call to fields() means they all get their default value.

If fields() is not called, we must be backwards-compatible.

But yes, this constraint is questionable. On one hand it tries to mimic 
the assignment to final fields in constructors, but it can't go all the 
way, as read access to final fields in readObject() is not limited to 
just those that have already been assigned (like it is in constructor 
with definitive assignment rules). We could add get() methods to 
FieldAccess that would constraint the reads of final fields to those 
that have already been assigned, but that is just like "advisory 
locking" - we can only advise users to use FieldAccess to read fields in 
readObject() but we can't prevent them from reading them directly.

So if this doesn't have much sense and brings confusion, it can go away.

>
> I think serialization types with final fields that aren't in the 
> serialized form will really like this. To help developers then it 
> might be useful to put an example in the javadoc with final && 
> transient field to show the usage.
>
> One other thing is naming as OIS.FieldAccess in the current patch 
> hints that it provides general access. It feels like it should be 
> something like ObjectFieldSetter with fields() changing to something 
> like fieldSetter() to make that clearer too.

Or just ObjectInputStream.FieldSetter (like it is now an inner 
interface) and fieldSetter() for method. I agree, it sounds better.

Regards, Peter

>
> -Alan.
>
>
>
>



From peter.levart at gmail.com  Thu Mar 12 22:33:25 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Mar 2015 23:33:25 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <5501F9E2.1020407@Oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54DA04D4.1060108@redhat.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>	<55001921.8090404@oracle.com>	<55002848.8010807@gmail.com>	<55002C2C.5040302@oracle.com>	<55002DAD.2010804@gmail.com>	<55005454.1050906@Oracle.com>
	<55009E58.5080500@Oracle.com>	<744323AE-51AE-4BBB-88D6-D3FB9B48D56E@oracle.com>
	<55019725.7090502@Oracle.com> <5501A501.4010801@gmail.com>
	<5501F9E2.1020407@Oracle.com>
Message-ID: <55021435.3050705@gmail.com>



On 03/12/2015 09:41 PM, Roger Riggs wrote:
> Hi Peter,
>
> Introducing a public Process subtype would not be a binary compatible 
> change;
> the return type of ProcessBuilder.start can not be narrowed.
> As you surmised, a different start method would be needed on 
> ProcessBuilder.
> Since ProcessBuilder is the preferred mechanism to created processes, 
> I would
> leave Runtime.exec alone to avoid a proliferation of similar methods.
>
> If ProcessHandle were an interface, Process would still have the 
> conflict over the
> return type of onExit() since CompletableFuture<Process> is not type 
> compatible
> with CF<ProcessHandle>.  So not quite the winning combination to 
> enable polymorphism.
>
> Roger

That's right. The delegation approach with unrelated Process / 
ProcessHandle seems to be the most clean from API perspective.

Regards, Peter

>
>
> On 3/12/2015 10:38 AM, Peter Levart wrote:
>> On 03/12/2015 02:39 PM, Roger Riggs wrote:
>>> Hi,
>>>
>>> Just a thought, it might be useful to introduce a public subtype of 
>>> Process that is
>>> returned from ProcessBuilder for which the guarantees about behavior 
>>> could be
>>> tighter  (no UOEs).  It would also provide a place to document the 
>>> behaviors
>>> now spread across ProcessBuilder and Process.
>>>
>>> $.02, Roger
>>>
>>
>> That was my thinking too today. A Process2 or XProcess? If 
>> ProcessHandle was an interface this subtype could implement it (back 
>> to square one). I think it could be an interface if Process2 was not 
>> publicly extendable (package-protected constructor) as it would not 
>> represent part of extensible API.
>>
>> Does that mean that we would need additional methods 
>> ProcessBuilder.start2() / Runtime.exec2() too?
>>
>> Peter
>>



From peter.levart at gmail.com  Fri Mar 13 07:35:03 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 13 Mar 2015 08:35:03 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <55021435.3050705@gmail.com>
References: <54D941D1.8000305@Oracle.com>	<54DBA533.8080802@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>	<55001921.8090404@oracle.com>	<55002848.8010807@gmail.com>	<55002C2C.5040302@oracle.com>	<55002DAD.2010804@gmail.com>	<55005454.1050906@Oracle.com>
	<55009E58.5080500@Oracle.com>	<744323AE-51AE-4BBB-88D6-D3FB9B48D56E@oracle.com>
	<55019725.7090502@Oracle.com> <5501A501.4010801@gmail.com>
	<5501F9E2.1020407@Oracle.com> <55021435.3050705@gmail.com>
Message-ID: <55029327.6070809@gmail.com>

Hi Rogger,

Now that the method has a non-throwing default implementation, what do 
you think of the following implementation note for Process.onExit():

      * @implNote
      * The default implementation of this method employs a thread from
      * {@link java.util.concurrent.ForkJoinPool#commonPool() common pool}
      * to {@link #waitFor() wait} for process exit, which might consume a lot
      * of memory for thread stacks if large number of processes are waited for
      * concurrently.<p>
      * External implementations are advised to override this method and provide
      * more efficient implementation, for example, if the implementation also
      * provides {@link #toHandle()} method, it can simply do the following:
      * <pre>{@code
      *    public CompletableFuture<Process> onExit() {
      *       return toHandle().onExit().thenApply(ph -> this);
      *    }
      * }</pre>
      * ...which in case of internal implementation of ProcessHandle
      * ({@link java.lang.ProcessHandle#of(long)}}), employs a more efficient
      * mechanism for waiting on process exit.



Regards, Peter


On 03/12/2015 11:33 PM, Peter Levart wrote:
>
>
> On 03/12/2015 09:41 PM, Roger Riggs wrote:
>> Hi Peter,
>>
>> Introducing a public Process subtype would not be a binary compatible 
>> change;
>> the return type of ProcessBuilder.start can not be narrowed.
>> As you surmised, a different start method would be needed on 
>> ProcessBuilder.
>> Since ProcessBuilder is the preferred mechanism to created processes, 
>> I would
>> leave Runtime.exec alone to avoid a proliferation of similar methods.
>>
>> If ProcessHandle were an interface, Process would still have the 
>> conflict over the
>> return type of onExit() since CompletableFuture<Process> is not type 
>> compatible
>> with CF<ProcessHandle>.  So not quite the winning combination to 
>> enable polymorphism.
>>
>> Roger
>
> That's right. The delegation approach with unrelated Process / 
> ProcessHandle seems to be the most clean from API perspective.
>
> Regards, Peter
>
>>
>>
>> On 3/12/2015 10:38 AM, Peter Levart wrote:
>>> On 03/12/2015 02:39 PM, Roger Riggs wrote:
>>>> Hi,
>>>>
>>>> Just a thought, it might be useful to introduce a public subtype of 
>>>> Process that is
>>>> returned from ProcessBuilder for which the guarantees about 
>>>> behavior could be
>>>> tighter  (no UOEs).  It would also provide a place to document the 
>>>> behaviors
>>>> now spread across ProcessBuilder and Process.
>>>>
>>>> $.02, Roger
>>>>
>>>
>>> That was my thinking too today. A Process2 or XProcess? If 
>>> ProcessHandle was an interface this subtype could implement it (back 
>>> to square one). I think it could be an interface if Process2 was not 
>>> publicly extendable (package-protected constructor) as it would not 
>>> represent part of extensible API.
>>>
>>> Does that mean that we would need additional methods 
>>> ProcessBuilder.start2() / Runtime.exec2() too?
>>>
>>> Peter
>>>
>
>



From peter.levart at gmail.com  Fri Mar 13 07:56:11 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 13 Mar 2015 08:56:11 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <55029327.6070809@gmail.com>
References: <54D941D1.8000305@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>	<55001921.8090404@oracle.com>	<55002848.8010807@gmail.com>	<55002C2C.5040302@oracle.com>	<55002DAD.2010804@gmail.com>	<55005454.1050906@Oracle.com>
	<55009E58.5080500@Oracle.com>	<744323AE-51AE-4BBB-88D6-D3FB9B48D56E@oracle.com>
	<55019725.7090502@Oracle.com> <5501A501.4010801@gmail.com>
	<5501F9E2.1020407@Oracle.com> <55021435.3050705@gmail.com>
	<55029327.6070809@gmail.com>
Message-ID: <5502981B.6060006@gmail.com>

...in addition, I would also try not to swallow interrupts in default 
implementation:


     public CompletableFuture<Process> onExit() {
         return CompletableFuture.supplyAsync(() -> {
             boolean interrupted = false;
             while (true) {
                 try {
                     waitFor();
                     break;
                 } catch (InterruptedException x) {
                     interrupted = true;
                 }
             }
             if (interrupted) {
                 Thread.currentThread().interrupt();
             }
             return this;
         });
     }


Peter

On 03/13/2015 08:35 AM, Peter Levart wrote:
> Hi Rogger,
>
> Now that the method has a non-throwing default implementation, what do 
> you think of the following implementation note for Process.onExit():
>
>      * @implNote
>      * The default implementation of this method employs a thread from
>      * {@link java.util.concurrent.ForkJoinPool#commonPool() common pool}
>      * to {@link #waitFor() wait} for process exit, which might 
> consume a lot
>      * of memory for thread stacks if large number of processes are 
> waited for
>      * concurrently.<p>
>      * External implementations are advised to override this method 
> and provide
>      * more efficient implementation, for example, if the 
> implementation also
>      * provides {@link #toHandle()} method, it can simply do the 
> following:
>      * <pre>{@code
>      *    public CompletableFuture<Process> onExit() {
>      *       return toHandle().onExit().thenApply(ph -> this);
>      *    }
>      * }</pre>
>      * ...which in case of internal implementation of ProcessHandle
>      * ({@link java.lang.ProcessHandle#of(long)}}), employs a more 
> efficient
>      * mechanism for waiting on process exit.
>
>
>
> Regards, Peter
>
>
> On 03/12/2015 11:33 PM, Peter Levart wrote:
>>
>>
>> On 03/12/2015 09:41 PM, Roger Riggs wrote:
>>> Hi Peter,
>>>
>>> Introducing a public Process subtype would not be a binary 
>>> compatible change;
>>> the return type of ProcessBuilder.start can not be narrowed.
>>> As you surmised, a different start method would be needed on 
>>> ProcessBuilder.
>>> Since ProcessBuilder is the preferred mechanism to created 
>>> processes, I would
>>> leave Runtime.exec alone to avoid a proliferation of similar methods.
>>>
>>> If ProcessHandle were an interface, Process would still have the 
>>> conflict over the
>>> return type of onExit() since CompletableFuture<Process> is not type 
>>> compatible
>>> with CF<ProcessHandle>.  So not quite the winning combination to 
>>> enable polymorphism.
>>>
>>> Roger
>>
>> That's right. The delegation approach with unrelated Process / 
>> ProcessHandle seems to be the most clean from API perspective.
>>
>> Regards, Peter
>>
>>>
>>>
>>> On 3/12/2015 10:38 AM, Peter Levart wrote:
>>>> On 03/12/2015 02:39 PM, Roger Riggs wrote:
>>>>> Hi,
>>>>>
>>>>> Just a thought, it might be useful to introduce a public subtype 
>>>>> of Process that is
>>>>> returned from ProcessBuilder for which the guarantees about 
>>>>> behavior could be
>>>>> tighter  (no UOEs).  It would also provide a place to document the 
>>>>> behaviors
>>>>> now spread across ProcessBuilder and Process.
>>>>>
>>>>> $.02, Roger
>>>>>
>>>>
>>>> That was my thinking too today. A Process2 or XProcess? If 
>>>> ProcessHandle was an interface this subtype could implement it 
>>>> (back to square one). I think it could be an interface if Process2 
>>>> was not publicly extendable (package-protected constructor) as it 
>>>> would not represent part of extensible API.
>>>>
>>>> Does that mean that we would need additional methods 
>>>> ProcessBuilder.start2() / Runtime.exec2() too?
>>>>
>>>> Peter
>>>>
>>
>>
>
>



From aph at redhat.com  Fri Mar 13 08:41:39 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 13 Mar 2015 08:41:39 +0000
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <CAHjP37F+7OiWTdwp8N=3AFP+AjXbL0agV6tPNBwOXAosk=3Oow@mail.gmail.com>
References: <54EB6DD1.4090803@redhat.com>	<54FF3FAD.5040702@redhat.com>	<5501C99D.6070901@gmail.com>	<5501DCE8.3010108@redhat.com>	<5501E90F.5010103@gmail.com>	<5501FF72.60004@gmail.com>	<55020DB0.8040901@gmail.com>
	<CAHjP37F+7OiWTdwp8N=3AFP+AjXbL0agV6tPNBwOXAosk=3Oow@mail.gmail.com>
Message-ID: <5502A2C3.90700@redhat.com>

On 12/03/15 22:15, Vitaly Davidovich wrote:
> Switches currently don't profile well (if at all) - John can shed more
> light on that as this came up on the compiler list a few weeks ago.

My first version used switches and the generated code was horrible.
The version I submitted generates optimal (or near-optimal) code.
There isn't much to be gained by tweaking the code at this level.

Andrew.


From aph at redhat.com  Fri Mar 13 08:54:12 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 13 Mar 2015 08:54:12 +0000
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <CAHjP37FzN5UfsweOh8+XrNkC9GB9AjxVKyFTH=WP10YQeWwXRw@mail.gmail.com>
References: <54EB6DD1.4090803@redhat.com>	<54FF3FAD.5040702@redhat.com>	<5501C99D.6070901@gmail.com>	<5501DCE8.3010108@redhat.com>	<5501E90F.5010103@gmail.com>	<5501FFAE.1030503@redhat.com>
	<CAHjP37FzN5UfsweOh8+XrNkC9GB9AjxVKyFTH=WP10YQeWwXRw@mail.gmail.com>
Message-ID: <5502A5B4.5080003@redhat.com>

On 12/03/15 22:02, Vitaly Davidovich wrote:
> Is vectorization coming soon? AFAIK, only memory copies are vectorized
> currently but not any arithmetic or the like.

That's true, but the idea is that this is future-proof and will work
well when we get vectorized scatter/gather memory accesses.

The workload is important when measuring performance, and which
approach works best depends on exactly what your benchmark looks like.
It's important not to optimize for random memory access patterns if
(as I suspect) random patterns are unlikely.  The current code is a
good compromise between complexity, efficiency, and generality, IMO.
I have tried a variety of scenarios and we get decent code quality for
all of them.

Andrew.


From amy.lu at oracle.com  Fri Mar 13 10:34:21 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Fri, 13 Mar 2015 18:34:21 +0800
Subject: JDK 9 RFR of JDK-8075111: Mark testFlatMappingClose (from
	CollectorsTest) as serialization hostile
Message-ID: <5502BD2D.6060707@oracle.com>

Testcase testFlatMappingClose was newly introduced in JDK-8071600 in 
CollectorsTest, this test should be marked as serialization-hostile 
(such tests will ignored by by lambda serialization testing framework).

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

Thanks,
Amy


From paul.sandoz at oracle.com  Fri Mar 13 10:44:09 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 13 Mar 2015 11:44:09 +0100
Subject: JDK 9 RFR of JDK-8075111: Mark testFlatMappingClose (from
	CollectorsTest) as serialization hostile
In-Reply-To: <5502BD2D.6060707@oracle.com>
References: <5502BD2D.6060707@oracle.com>
Message-ID: <A85F0455-5427-4581-A492-96FA62D1A383@oracle.com>


On Mar 13, 2015, at 11:34 AM, Amy Lu <amy.lu at oracle.com> wrote:

> Testcase testFlatMappingClose was newly introduced in JDK-8071600 in CollectorsTest, this test should be marked as serialization-hostile (such tests will ignored by by lambda serialization testing framework).
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8075111
> webrev: http://cr.openjdk.java.net/~amlu/8075111/webrev.00/
> 

+1, i can push for you.

There were also some similar tests added to FlatMapOpTest, do those need to be marked as serialization hostile?

Paul.


From amy.lu at oracle.com  Fri Mar 13 12:16:47 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Fri, 13 Mar 2015 20:16:47 +0800
Subject: JDK 9 RFR of JDK-8075111: Mark testFlatMappingClose (from
	CollectorsTest) as serialization hostile
In-Reply-To: <A85F0455-5427-4581-A492-96FA62D1A383@oracle.com>
References: <5502BD2D.6060707@oracle.com>
	<A85F0455-5427-4581-A492-96FA62D1A383@oracle.com>
Message-ID: <5502D52F.5030904@oracle.com>

On 3/13/15 6:44 PM, Paul Sandoz wrote:
> On Mar 13, 2015, at 11:34 AM, Amy Lu <amy.lu at oracle.com> wrote:
>
>> Testcase testFlatMappingClose was newly introduced in JDK-8071600 in CollectorsTest, this test should be marked as serialization-hostile (such tests will ignored by by lambda serialization testing framework).
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8075111
>> webrev: http://cr.openjdk.java.net/~amlu/8075111/webrev.00/
>>
> +1, i can push for you.
>
> There were also some similar tests added to FlatMapOpTest, do those need to be marked as serialization hostile?
>
> Paul.

Thank you Paul!

Other tests are fine, no need to be marked as serialization hostile.

Thanks,
Amy


From Roger.Riggs at Oracle.com  Fri Mar 13 13:35:06 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 13 Mar 2015 09:35:06 -0400
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <5502981B.6060006@gmail.com>
References: <54D941D1.8000305@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>	<55001921.8090404@oracle.com>	<55002848.8010807@gmail.com>	<55002C2C.5040302@oracle.com>	<55002DAD.2010804@gmail.com>	<55005454.1050906@Oracle.com>
	<55009E58.5080500@Oracle.com>	<744323AE-51AE-4BBB-88D6-D3FB9B48D56E@oracle.com>
	<55019725.7090502@Oracle.com> <5501A501.4010801@gmail.com>
	<5501F9E2.1020407@Oracle.com> <55021435.3050705@gmail.com>
	<55029327.6070809@gmail.com> <5502981B.6060006@gmail.com>
Message-ID: <5502E78A.3090406@Oracle.com>

Hi Peter,

Right, that is the preferred handling.
In this case, the forwarded interrupt will be passed back to the Thread 
from the ThreadPool
and is disregarded there.

Roger


On 3/13/2015 3:56 AM, Peter Levart wrote:
> ...in addition, I would also try not to swallow interrupts in default 
> implementation:
>
>
>     public CompletableFuture<Process> onExit() {
>         return CompletableFuture.supplyAsync(() -> {
>             boolean interrupted = false;
>             while (true) {
>                 try {
>                     waitFor();
>                     break;
>                 } catch (InterruptedException x) {
>                     interrupted = true;
>                 }
>             }
>             if (interrupted) {
>                 Thread.currentThread().interrupt();
>             }
>             return this;
>         });
>     }
>
>
> Peter
>
> On 03/13/2015 08:35 AM, Peter Levart wrote:
>> Hi Rogger,
>>
>> Now that the method has a non-throwing default implementation, what 
>> do you think of the following implementation note for Process.onExit():
>>
>>      * @implNote
>>      * The default implementation of this method employs a thread from
>>      * {@link java.util.concurrent.ForkJoinPool#commonPool() common 
>> pool}
>>      * to {@link #waitFor() wait} for process exit, which might 
>> consume a lot
>>      * of memory for thread stacks if large number of processes are 
>> waited for
>>      * concurrently.<p>
>>      * External implementations are advised to override this method 
>> and provide
>>      * more efficient implementation, for example, if the 
>> implementation also
>>      * provides {@link #toHandle()} method, it can simply do the 
>> following:
>>      * <pre>{@code
>>      *    public CompletableFuture<Process> onExit() {
>>      *       return toHandle().onExit().thenApply(ph -> this);
>>      *    }
>>      * }</pre>
>>      * ...which in case of internal implementation of ProcessHandle
>>      * ({@link java.lang.ProcessHandle#of(long)}}), employs a more 
>> efficient
>>      * mechanism for waiting on process exit.
>>
>>
>>
>> Regards, Peter
>>
>>
>> On 03/12/2015 11:33 PM, Peter Levart wrote:
>>>
>>>
>>> On 03/12/2015 09:41 PM, Roger Riggs wrote:
>>>> Hi Peter,
>>>>
>>>> Introducing a public Process subtype would not be a binary 
>>>> compatible change;
>>>> the return type of ProcessBuilder.start can not be narrowed.
>>>> As you surmised, a different start method would be needed on 
>>>> ProcessBuilder.
>>>> Since ProcessBuilder is the preferred mechanism to created 
>>>> processes, I would
>>>> leave Runtime.exec alone to avoid a proliferation of similar methods.
>>>>
>>>> If ProcessHandle were an interface, Process would still have the 
>>>> conflict over the
>>>> return type of onExit() since CompletableFuture<Process> is not 
>>>> type compatible
>>>> with CF<ProcessHandle>.  So not quite the winning combination to 
>>>> enable polymorphism.
>>>>
>>>> Roger
>>>
>>> That's right. The delegation approach with unrelated Process / 
>>> ProcessHandle seems to be the most clean from API perspective.
>>>
>>> Regards, Peter
>>>
>>>>
>>>>
>>>> On 3/12/2015 10:38 AM, Peter Levart wrote:
>>>>> On 03/12/2015 02:39 PM, Roger Riggs wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Just a thought, it might be useful to introduce a public subtype 
>>>>>> of Process that is
>>>>>> returned from ProcessBuilder for which the guarantees about 
>>>>>> behavior could be
>>>>>> tighter  (no UOEs).  It would also provide a place to document 
>>>>>> the behaviors
>>>>>> now spread across ProcessBuilder and Process.
>>>>>>
>>>>>> $.02, Roger
>>>>>>
>>>>>
>>>>> That was my thinking too today. A Process2 or XProcess? If 
>>>>> ProcessHandle was an interface this subtype could implement it 
>>>>> (back to square one). I think it could be an interface if Process2 
>>>>> was not publicly extendable (package-protected constructor) as it 
>>>>> would not represent part of extensible API.
>>>>>
>>>>> Does that mean that we would need additional methods 
>>>>> ProcessBuilder.start2() / Runtime.exec2() too?
>>>>>
>>>>> Peter
>>>>>
>>>
>>>
>>
>>
>



From Roger.Riggs at Oracle.com  Fri Mar 13 14:22:37 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 13 Mar 2015 10:22:37 -0400
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <55029327.6070809@gmail.com>
References: <54D941D1.8000305@Oracle.com>	<54DD2311.9070902@Oracle.com>	<60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>	<55001921.8090404@oracle.com>	<55002848.8010807@gmail.com>	<55002C2C.5040302@oracle.com>	<55002DAD.2010804@gmail.com>	<55005454.1050906@Oracle.com>
	<55009E58.5080500@Oracle.com>	<744323AE-51AE-4BBB-88D6-D3FB9B48D56E@oracle.com>
	<55019725.7090502@Oracle.com> <5501A501.4010801@gmail.com>
	<5501F9E2.1020407@Oracle.com> <55021435.3050705@gmail.com>
	<55029327.6070809@gmail.com>
Message-ID: <5502F2AD.6040100@Oracle.com>

Hi Peter,

If delegating to another Process and not needing to return the CF<subtype>
then the overridden implementation might be:
         public CompletableFuture<Process> onExit() {
return delegate.onExit();
         }

The .thenApply(ph -> this) would be needed only for the return value to 
be CF<subtype>.
The explanation can get lengthy if the best-practice options are described
and mentioning toHandle() reintroduces the possibility of UOE.

      * @implNote
      * The default implementation of this method employs a thread from
      * {@link java.util.concurrent.ForkJoinPool#commonPool() common pool}
      * to {@link #waitFor() wait} for process exit, which might consume a lot
      * of memory for thread stacks if large number of processes are waited for
      * concurrently.<p>
      * External implementations are advised to override this method and provide
      * more efficient implementation, for example, if the implementation also
      * provides {@link #toHandle()} method, it can simply do the following:
      * <pre>{@code
      *    public CompletableFuture<Process> onExit() {
      *       return delegate.onExit();
      *    }
      * }</pre>
      * ...which in case of implementation of the delegate is used.


A more general class level note about delegating each of the methods of the
underlying process might be sufficient but might be overlooked.

Thanks, Roger

On 3/13/2015 3:35 AM, Peter Levart wrote:
> Hi Roger,
>
> Now that the method has a non-throwing default implementation, what do 
> you think of the following implementation note for Process.onExit():
>
>       * @implNote
>       * The default implementation of this method employs a thread from
>       * {@link java.util.concurrent.ForkJoinPool#commonPool() common pool}
>       * to {@link #waitFor() wait} for process exit, which might consume a lot
>       * of memory for thread stacks if large number of processes are waited for
>       * concurrently.<p>
>       * External implementations are advised to override this method and provide
>       * more efficient implementation, for example, if the implementation also
>       * provides {@link #toHandle()} method, it can simply do the following:
>       * <pre>{@code
>       *    public CompletableFuture<Process> onExit() {
>       *       return toHandle().onExit().thenApply(ph -> this);
>       *    }
>       * }</pre>
>       * ...which in case of internal implementation of ProcessHandle
>       * ({@link java.lang.ProcessHandle#of(long)}}), employs a more efficient
>       * mechanism for waiting on process exit.
>
>
>
> Regards, Peter
>
>
> On 03/12/2015 11:33 PM, Peter Levart wrote:
>>
>>
>> On 03/12/2015 09:41 PM, Roger Riggs wrote:
>>> Hi Peter,
>>>
>>> Introducing a public Process subtype would not be a binary 
>>> compatible change;
>>> the return type of ProcessBuilder.start can not be narrowed.
>>> As you surmised, a different start method would be needed on 
>>> ProcessBuilder.
>>> Since ProcessBuilder is the preferred mechanism to created 
>>> processes, I would
>>> leave Runtime.exec alone to avoid a proliferation of similar methods.
>>>
>>> If ProcessHandle were an interface, Process would still have the 
>>> conflict over the
>>> return type of onExit() since CompletableFuture<Process> is not type 
>>> compatible
>>> with CF<ProcessHandle>.  So not quite the winning combination to 
>>> enable polymorphism.
>>>
>>> Roger
>>
>> That's right. The delegation approach with unrelated Process / 
>> ProcessHandle seems to be the most clean from API perspective.
>>
>> Regards, Peter
>>
>>>
>>>
>>> On 3/12/2015 10:38 AM, Peter Levart wrote:
>>>> On 03/12/2015 02:39 PM, Roger Riggs wrote:
>>>>> Hi,
>>>>>
>>>>> Just a thought, it might be useful to introduce a public subtype 
>>>>> of Process that is
>>>>> returned from ProcessBuilder for which the guarantees about 
>>>>> behavior could be
>>>>> tighter  (no UOEs).  It would also provide a place to document the 
>>>>> behaviors
>>>>> now spread across ProcessBuilder and Process.
>>>>>
>>>>> $.02, Roger
>>>>>
>>>>
>>>> That was my thinking too today. A Process2 or XProcess? If 
>>>> ProcessHandle was an interface this subtype could implement it 
>>>> (back to square one). I think it could be an interface if Process2 
>>>> was not publicly extendable (package-protected constructor) as it 
>>>> would not represent part of extensible API.
>>>>
>>>> Does that mean that we would need additional methods 
>>>> ProcessBuilder.start2() / Runtime.exec2() too?
>>>>
>>>> Peter
>>>>
>>
>>
>



From peter.levart at gmail.com  Fri Mar 13 14:58:27 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 13 Mar 2015 15:58:27 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <5502E78A.3090406@Oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54DDEFE0.7090108@gmail.com>	<A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>	<54DE1506.8020407@gmail.com>	<54DE15BC.7040007@redhat.com>	<54DE1969.2040508@gmail.com>	<54E393BC.4030600@Oracle.com>	<992E771A-E5A5-4EDE-AED6-3E38CC0D52C8@oracle.com>	<54F9F8E2.1020502@Oracle.com>	<01909FED-787C-4776-B3B2-0470DE15EDB0@oracle.com>	<54FEFCA6.4020107@Oracle.com>	<8936A22F-4388-4343-AE8D-79D0949D715F@oracle.com>	<54FF10B2.4010605@Oracle.com>	<CBF6E3DC-6307-4979-9386-F677DDBF3614@oracle.com>	<55001921.8090404@oracle.com>	<55002848.8010807@gmail.com>	<55002C2C.5040302@oracle.com>	<55002DAD.2010804@gmail.com>	<55005454.1050906@Oracle.com>
	<55009E58.5080500@Oracle.com>	<744323AE-51AE-4BBB-88D6-D3FB9B48D56E@oracle.com>
	<55019725.7090502@Oracle.com> <5501A501.4010801@gmail.com>
	<5501F9E2.1020407@Oracle.com> <55021435.3050705@gmail.com>
	<55029327.6070809@gmail.com> <5502981B.6060006@gmail.com>
	<5502E78A.3090406@Oracle.com>
Message-ID: <5502FB13.8010308@gmail.com>

On 03/13/2015 02:35 PM, Roger Riggs wrote:
> Hi Peter,
>
> Right, that is the preferred handling.
> In this case, the forwarded interrupt will be passed back to the 
> Thread from the ThreadPool
> and is disregarded there.

I thought that too, but is not necessarily so. For example:

Process p = ...

p.onExit().thenAccept(p1 -> {
     Thread.sleep(...); // will be thrown here!
});


Peter

>
> Roger
>
>
> On 3/13/2015 3:56 AM, Peter Levart wrote:
>> ...in addition, I would also try not to swallow interrupts in default 
>> implementation:
>>
>>
>>     public CompletableFuture<Process> onExit() {
>>         return CompletableFuture.supplyAsync(() -> {
>>             boolean interrupted = false;
>>             while (true) {
>>                 try {
>>                     waitFor();
>>                     break;
>>                 } catch (InterruptedException x) {
>>                     interrupted = true;
>>                 }
>>             }
>>             if (interrupted) {
>>                 Thread.currentThread().interrupt();
>>             }
>>             return this;
>>         });
>>     }
>>
>>
>> Peter
>>
>> On 03/13/2015 08:35 AM, Peter Levart wrote:
>>> Hi Rogger,
>>>
>>> Now that the method has a non-throwing default implementation, what 
>>> do you think of the following implementation note for Process.onExit():
>>>
>>>      * @implNote
>>>      * The default implementation of this method employs a thread from
>>>      * {@link java.util.concurrent.ForkJoinPool#commonPool() common 
>>> pool}
>>>      * to {@link #waitFor() wait} for process exit, which might 
>>> consume a lot
>>>      * of memory for thread stacks if large number of processes are 
>>> waited for
>>>      * concurrently.<p>
>>>      * External implementations are advised to override this method 
>>> and provide
>>>      * more efficient implementation, for example, if the 
>>> implementation also
>>>      * provides {@link #toHandle()} method, it can simply do the 
>>> following:
>>>      * <pre>{@code
>>>      *    public CompletableFuture<Process> onExit() {
>>>      *       return toHandle().onExit().thenApply(ph -> this);
>>>      *    }
>>>      * }</pre>
>>>      * ...which in case of internal implementation of ProcessHandle
>>>      * ({@link java.lang.ProcessHandle#of(long)}}), employs a more 
>>> efficient
>>>      * mechanism for waiting on process exit.
>>>
>>>
>>>
>>> Regards, Peter
>>>
>>>
>>> On 03/12/2015 11:33 PM, Peter Levart wrote:
>>>>
>>>>
>>>> On 03/12/2015 09:41 PM, Roger Riggs wrote:
>>>>> Hi Peter,
>>>>>
>>>>> Introducing a public Process subtype would not be a binary 
>>>>> compatible change;
>>>>> the return type of ProcessBuilder.start can not be narrowed.
>>>>> As you surmised, a different start method would be needed on 
>>>>> ProcessBuilder.
>>>>> Since ProcessBuilder is the preferred mechanism to created 
>>>>> processes, I would
>>>>> leave Runtime.exec alone to avoid a proliferation of similar methods.
>>>>>
>>>>> If ProcessHandle were an interface, Process would still have the 
>>>>> conflict over the
>>>>> return type of onExit() since CompletableFuture<Process> is not 
>>>>> type compatible
>>>>> with CF<ProcessHandle>.  So not quite the winning combination to 
>>>>> enable polymorphism.
>>>>>
>>>>> Roger
>>>>
>>>> That's right. The delegation approach with unrelated Process / 
>>>> ProcessHandle seems to be the most clean from API perspective.
>>>>
>>>> Regards, Peter
>>>>
>>>>>
>>>>>
>>>>> On 3/12/2015 10:38 AM, Peter Levart wrote:
>>>>>> On 03/12/2015 02:39 PM, Roger Riggs wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Just a thought, it might be useful to introduce a public subtype 
>>>>>>> of Process that is
>>>>>>> returned from ProcessBuilder for which the guarantees about 
>>>>>>> behavior could be
>>>>>>> tighter  (no UOEs).  It would also provide a place to document 
>>>>>>> the behaviors
>>>>>>> now spread across ProcessBuilder and Process.
>>>>>>>
>>>>>>> $.02, Roger
>>>>>>>
>>>>>>
>>>>>> That was my thinking too today. A Process2 or XProcess? If 
>>>>>> ProcessHandle was an interface this subtype could implement it 
>>>>>> (back to square one). I think it could be an interface if 
>>>>>> Process2 was not publicly extendable (package-protected 
>>>>>> constructor) as it would not represent part of extensible API.
>>>>>>
>>>>>> Does that mean that we would need additional methods 
>>>>>> ProcessBuilder.start2() / Runtime.exec2() too?
>>>>>>
>>>>>> Peter
>>>>>>
>>>>
>>>>
>>>
>>>
>>
>



From chris.hegarty at oracle.com  Fri Mar 13 16:10:13 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 13 Mar 2015 16:10:13 +0000
Subject: RFR [9] 8071472: Add field access to support setting final fields
	in readObject
In-Reply-To: <55021223.6060006@gmail.com>
References: <3F1CE33B-5C13-4172-A78B-72F476E0654E@oracle.com>
	<5501FBD0.4010109@oracle.com> <55021223.6060006@gmail.com>
Message-ID: <55030BE5.2080103@oracle.com>

Alan,

Thanks for taking the time to try this out.

On 12/03/15 22:24, Peter Levart wrote:
> ....
> Hi Alan,
>
>> I've spent some time looking at this and trying it out. It's very
>> simple, doesn't impact any existing readObject implementations, and
>> provides a way to set final fields without restoring to Unsafe.
>
> That was the plan. :-)

Yes, it works well.

>> So if a readObject calls fields() without calling defaultReadObject()
>> then it has to set every final field. On one hand that ensures that
>> every final field is set, on the other hand it is a bit odd because
>> omitting the call to fields() means they all get their default value.
>
> If fields() is not called, we must be backwards-compatible.
>
> But yes, this constraint is questionable. On one hand it tries to mimic
> the assignment to final fields in constructors, but it can't go all the
> way, as read access to final fields in readObject() is not limited to
> just those that have already been assigned (like it is in constructor
> with definitive assignment rules). We could add get() methods to
> FieldAccess that would constraint the reads of final fields to those
> that have already been assigned, but that is just like "advisory
> locking" - we can only advise users to use FieldAccess to read fields in
> readObject() but we can't prevent them from reading them directly.

Right. I think we should avoid get(..). Let's keep it simple.

> So if this doesn't have much sense and brings confusion, it can go away.

If we have consensus then I can remove this, artificial, restriction. 
Objections?

>> I think serialization types with final fields that aren't in the
>> serialized form will really like this. To help developers then it
>> might be useful to put an example in the javadoc with final &&
>> transient field to show the usage.

I added an example to the class description.

>> One other thing is naming as OIS.FieldAccess in the current patch
>> hints that it provides general access. It feels like it should be
>> something like ObjectFieldSetter with fields() changing to something
>> like fieldSetter() to make that clearer too.
>
> Or just ObjectInputStream.FieldSetter (like it is now an inner
> interface) and fieldSetter() for method. I agree, it sounds better.

I updated the sandbox based on these names.

An alternative to setter: FieldUpdater ?

    ObjectInputStream.FieldUpdater updater = in.fieldUpdater();
    updater.set(...)
           .set(...)

-Chris.


From chris.hegarty at oracle.com  Fri Mar 13 16:52:47 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 13 Mar 2015 16:52:47 +0000
Subject: RFR: JDK-8067969 Optimize Stream.count for SIZED Streams
In-Reply-To: <6FC66D89-024E-4461-A8DD-3B92215C3EBD@oracle.com>
References: <CAHLSyCmEPZnfe2rJe+o7con8RG1L09kQr-yL8KsC1V_1oSNhqg@mail.gmail.com>	<6C765D69-B345-4660-9277-225017018B93@oracle.com>	<AC3393D0-A2C9-406C-A2D9-C85E19294B80@oracle.com>	<F11BEA7E-C52E-453B-BE26-90184D03873D@oracle.com>	<C2E823DD-1F55-4622-9C1F-3BDD09D4CAB8@oracle.com>
	<6FC66D89-024E-4461-A8DD-3B92215C3EBD@oracle.com>
Message-ID: <550315DF.8070408@oracle.com>


On 12/03/15 16:35, Paul Sandoz wrote:
> ...
>
> Webrev updated:
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8067969-optimize-stream-count/webrev/

Looks good to me.

-Chris.

> Paul.
>


From joe.darcy at oracle.com  Fri Mar 13 17:40:31 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 13 Mar 2015 10:40:31 -0700
Subject: JDK 9 RFR of adding javadoc to the serialver tool class
Message-ID: <5503210F.4060805@oracle.com>

Hello,

To support stricter doclint checking for the jdk.compiler module 
(http://mail.openjdk.java.net/pipermail/build-dev/2015-March/014560.html), 
some javadoc needs to be added to a class for the serialver tool which 
is in the jdk repo. Patch below.

I'm not quite sure why serialver is the the jdk.compiler module, perhaps 
that is the least-bad alternative. A way to avoid adding javadoc here 
would be to adjust the package filter being used in the makefile. The 
current filter of

     Xdoclint/package:-com.sun.tools.*

has the advantage of checking any new packages that may come in the only 
excluding those known not to be of interest for such check.

Thanks,

-Joe

diff -r 4330ca0a31bb 
src/jdk.compiler/share/classes/sun/tools/serialver/SerialVer.java
--- a/src/jdk.compiler/share/classes/sun/tools/serialver/SerialVer.java 
Thu Feb 12 12:56:48 2015 -0800
+++ b/src/jdk.compiler/share/classes/sun/tools/serialver/SerialVer.java 
Fri Mar 13 10:34:59 2015 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2014, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2015, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -37,6 +37,9 @@
  import java.util.StringTokenizer;
  import sun.net.www.ParseUtil;

+/**
+ * Supporting class for the serialver tool.
+ */
  public class SerialVer {

      /*
@@ -117,6 +120,10 @@
          }
      }

+    /**
+     * Entry point for serialver tool.
+     * @param args the arguments
+     */
      public static void main(String[] args) {
          String envcp = null;
          int i = 0;



From lance.andersen at oracle.com  Fri Mar 13 17:43:22 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 13 Mar 2015 13:43:22 -0400
Subject: JDK 9 RFR of adding javadoc to the serialver tool class
In-Reply-To: <5503210F.4060805@oracle.com>
References: <5503210F.4060805@oracle.com>
Message-ID: <50B20241-EF91-42AF-B41E-256632C1A04B@oracle.com>

looks ok joe
On Mar 13, 2015, at 1:40 PM, joe darcy <joe.darcy at oracle.com> wrote:

> Hello,
> 
> To support stricter doclint checking for the jdk.compiler module (http://mail.openjdk.java.net/pipermail/build-dev/2015-March/014560.html), some javadoc needs to be added to a class for the serialver tool which is in the jdk repo. Patch below.
> 
> I'm not quite sure why serialver is the the jdk.compiler module, perhaps that is the least-bad alternative. A way to avoid adding javadoc here would be to adjust the package filter being used in the makefile. The current filter of
> 
>    Xdoclint/package:-com.sun.tools.*
> 
> has the advantage of checking any new packages that may come in the only excluding those known not to be of interest for such check.
> 
> Thanks,
> 
> -Joe
> 
> diff -r 4330ca0a31bb src/jdk.compiler/share/classes/sun/tools/serialver/SerialVer.java
> --- a/src/jdk.compiler/share/classes/sun/tools/serialver/SerialVer.java Thu Feb 12 12:56:48 2015 -0800
> +++ b/src/jdk.compiler/share/classes/sun/tools/serialver/SerialVer.java Fri Mar 13 10:34:59 2015 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1996, 2014, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1996, 2015, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -37,6 +37,9 @@
> import java.util.StringTokenizer;
> import sun.net.www.ParseUtil;
> 
> +/**
> + * Supporting class for the serialver tool.
> + */
> public class SerialVer {
> 
>     /*
> @@ -117,6 +120,10 @@
>         }
>     }
> 
> +    /**
> +     * Entry point for serialver tool.
> +     * @param args the arguments
> +     */
>     public static void main(String[] args) {
>         String envcp = null;
>         int i = 0;
> 



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 peter.levart at gmail.com  Fri Mar 13 17:58:12 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 13 Mar 2015 18:58:12 +0100
Subject: RFR [9] 8071472: Add field access to support setting final fields
	in readObject
In-Reply-To: <55021223.6060006@gmail.com>
References: <3F1CE33B-5C13-4172-A78B-72F476E0654E@oracle.com>
	<5501FBD0.4010109@oracle.com> <55021223.6060006@gmail.com>
Message-ID: <55032534.1040408@gmail.com>



On 03/12/2015 11:24 PM, Peter Levart wrote:
>> So if a readObject calls fields() without calling defaultReadObject() 
>> then it has to set every final field. On one hand that ensures that 
>> every final field is set, on the other hand it is a bit odd because 
>> omitting the call to fields() means they all get their default value.
>
> If fields() is not called, we must be backwards-compatible.
>
> But yes, this constraint is questionable. On one hand it tries to 
> mimic the assignment to final fields in constructors, but it can't go 
> all the way, as read access to final fields in readObject() is not 
> limited to just those that have already been assigned (like it is in 
> constructor with definitive assignment rules). We could add get() 
> methods to FieldAccess that would constraint the reads of final fields 
> to those that have already been assigned, but that is just like 
> "advisory locking" - we can only advise users to use FieldAccess to 
> read fields in readObject() but we can't prevent them from reading 
> them directly.
>
> So if this doesn't have much sense and brings confusion, it can go away.

...or it can stay in part where we check that a final field is not set 
more than once, which can help especially when use of FieldAccess API is 
combined with defaultReadObject(). The final check that all finals have 
been assigned can be made optional by an explicit call to a method 
(FieldAccess.checkAllFinalsSet() for example).

Regards, Peter



From peter.levart at gmail.com  Fri Mar 13 18:07:48 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 13 Mar 2015 19:07:48 +0100
Subject: RFR [9] 8071472: Add field access to support setting final fields
	in readObject
In-Reply-To: <55030BE5.2080103@oracle.com>
References: <3F1CE33B-5C13-4172-A78B-72F476E0654E@oracle.com>
	<5501FBD0.4010109@oracle.com> <55021223.6060006@gmail.com>
	<55030BE5.2080103@oracle.com>
Message-ID: <55032774.4040708@gmail.com>



On 03/13/2015 05:10 PM, Chris Hegarty wrote:
>> So if this doesn't have much sense and brings confusion, it can go away.
>
> If we have consensus then I can remove this, artificial, restriction. 
> Objections? 

Hi Chris,

I think the part that checks that a final field is not set more than 
once is still useful (to catch conflicts betwen defaultReadObject() and 
explicitly setting the field). And if we keep that, there's no overhead 
in keeping the FieldAccessContext.checkAllFinalsSet() method and just 
propagating it to FieldAccess (FieldUpdater) API and removing it's call 
from ObjectInputStream code. So we don't impose this on the user, but 
give him an option.

Regards, Peter



From Alan.Bateman at oracle.com  Fri Mar 13 18:37:51 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 13 Mar 2015 18:37:51 +0000
Subject: JDK 9 RFR of adding javadoc to the serialver tool class
In-Reply-To: <5503210F.4060805@oracle.com>
References: <5503210F.4060805@oracle.com>
Message-ID: <55032E7F.9060904@oracle.com>

On 13/03/2015 17:40, joe darcy wrote:
> Hello,
>
> To support stricter doclint checking for the jdk.compiler module 
> (http://mail.openjdk.java.net/pipermail/build-dev/2015-March/014560.html), 
> some javadoc needs to be added to a class for the serialver tool which 
> is in the jdk repo. Patch below.
>
> I'm not quite sure why serialver is the the jdk.compiler module, 
> perhaps that is the least-bad alternative. A way to avoid adding 
> javadoc here would be to adjust the package filter being used in the 
> makefile. The current filter of
>
The change looks okay.

It's in the jdk.compiler for now so that it's with related tools, maybe 
it should move into the langtools repo too. I could imagine the 
implementation being replaced at some point too.

-Alan


From aph at redhat.com  Fri Mar 13 18:47:42 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 13 Mar 2015 18:47:42 +0000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float,
	...} methods
Message-ID: <550330CE.3030607@redhat.com>

I've tried to address all the points that have been made.

I haven't changed the way the sub-words are read and written because
the code I'm seeing is fairly nearly optimal right now and anything
more complex runs the risk of tripping inlining limits, thus
pessimizing performance.  We need a general solution which isn't
optimized for special cases but is decent on average and often very
good.  I think it's close to the best compromise we're going to get.

I have changed the javadoc as requested and I have fixed the code in
HeapByteBuffer so that it doesn't check the index twice for floating-
point put() and get() operations.

I have added a jtreg test for HeapByteBuffer which tests it pretty
thoroughly.  It also, as a consequence, tests the underlying Unsafe
methods.  I wasn't sure what a separate test for the Unsafe methods
would achieve so I didn't write one.

OK?

http://cr.openjdk.java.net/~aph/unaligned.hotspot.6/
http://cr.openjdk.java.net/~aph/unaligned.jdk.6/

Andrew.


From aph at redhat.com  Fri Mar 13 18:48:17 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 13 Mar 2015 18:48:17 +0000
Subject: RFR: 8026049: (bf) Intrinsify ByteBuffer.put{Int,Double,Float,...}
	methods
Message-ID: <550330F1.4090604@redhat.com>

I've tried to address all the points that have been made.

I haven't changed the way the sub-words are read and written because
the code I'm seeing is fairly nearly optimal right now and anything
more complex runs the risk of tripping inlining limits, thus
pessimizing performance.  We need a general solution which isn't
optimized for special cases but is decent on average and often very
good.  I think it's close to the best compromise we're going to get.

I have changed the javadoc as requested and I have fixed the code in
HeapByteBuffer so that it doesn't check the index twice for floating-
point put() and get() operations.

I have added a jtreg test for HeapByteBuffer which tests it pretty
thoroughly.  It also, as a consequence, tests the underlying Unsafe
methods.  I wasn't sure what a separate test for the Unsafe methods
would achieve so I didn't write one.

OK?

http://cr.openjdk.java.net/~aph/unaligned.hotspot.6/
http://cr.openjdk.java.net/~aph/unaligned.jdk.6/

Andrew.


From chris.hegarty at oracle.com  Fri Mar 13 19:36:08 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 13 Mar 2015 19:36:08 +0000
Subject: RFR [9] 8071472: Add field access to support setting final fields
	in readObject
In-Reply-To: <55032534.1040408@gmail.com>
References: <3F1CE33B-5C13-4172-A78B-72F476E0654E@oracle.com>
	<5501FBD0.4010109@oracle.com> <55021223.6060006@gmail.com>
	<55032534.1040408@gmail.com>
Message-ID: <BD34A2D5-38F3-45DA-BA32-330346D2A666@oracle.com>


> On 13 Mar 2015, at 17:58, Peter Levart <peter.levart at gmail.com> wrote:
> 
> On 03/12/2015 11:24 PM, Peter Levart wrote:
>>> So if a readObject calls fields() without calling defaultReadObject() then it has to set every final field. On one hand that ensures that every final field is set, on the other hand it is a bit odd because omitting the call to fields() means they all get their default value. 
>> 
>> If fields() is not called, we must be backwards-compatible.
>> 
>> But yes, this constraint is questionable. On one hand it tries to mimic the assignment to final fields in constructors, but it can't go all the way, as read access to final fields in readObject() is not limited to just those that have already been assigned (like it is in constructor with definitive assignment rules). We could add get() methods to FieldAccess that would constraint the reads of final fields to those that have already been assigned, but that is just like "advisory locking" - we can only advise users to use FieldAccess to read fields in readObject() but we can't prevent them from reading them directly.
>> 
>> So if this doesn't have much sense and brings confusion, it can go away.
> 
> ...or it can stay in part where we check that a final field is not set more than once, which can help especially when use of FieldAccess API is combined with defaultReadObject().

Yes, that makes sense.

> The final check that all finals have been assigned can be made optional by an explicit call to a method (FieldAccess.checkAllFinalsSet() for example).

If possible, I?d rather not have any additional methods exposed on FieldSetter, other than the overloaded sets. Let see how this works if we keep it as minimal as possible. I?m going to take a run over all readObjects in the base module that use unsafe or reflection, and rewrite to use this API.

-Chris.

> Regards, Peter
> 



From brian.burkhalter at oracle.com  Fri Mar 13 20:40:47 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 13 Mar 2015 13:40:47 -0700
Subject: [9] RFR of 8073214: javadoc of Properties methods should specify
	NullPointerExceptions
Message-ID: <6A7605E8-AD70-4BEA-A632-D7D7B108B2A6@oracle.com>

Please review at your convenience.

Issue:	https://bugs.openjdk.java.net/browse/JDK-8073214
Patch:	http://cr.openjdk.java.net/~bpb/8073214/webrev.00/

Lines 316 and 342 in Properties.java are not strictly necessary but make it a little more fail-fast.

Thanks,

Brian

From joe.darcy at oracle.com  Fri Mar 13 21:08:13 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 13 Mar 2015 14:08:13 -0700
Subject: [9] RFR of 8073214: javadoc of Properties methods should specify
	NullPointerExceptions
In-Reply-To: <6A7605E8-AD70-4BEA-A632-D7D7B108B2A6@oracle.com>
References: <6A7605E8-AD70-4BEA-A632-D7D7B108B2A6@oracle.com>
Message-ID: <550351BD.8000904@oracle.com>

Looks fine Brian; thanks,

-Joe

On 3/13/2015 1:40 PM, Brian Burkhalter wrote:
> Please review at your convenience.
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8073214
> Patch:	http://cr.openjdk.java.net/~bpb/8073214/webrev.00/
>
> Lines 316 and 342 in Properties.java are not strictly necessary but make it a little more fail-fast.
>
> Thanks,
>
> Brian



From brian.burkhalter at oracle.com  Fri Mar 13 21:45:58 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 13 Mar 2015 14:45:58 -0700
Subject: [9] RFR of 8075110: (prefs) CodePointZeroPrefsTest fails on certain
	platforms 
Message-ID: <3D643EDD-3D0A-48C4-8D9D-BD7B2205E77D@oracle.com>

Please review at your convenience.

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

--- a/test/java/util/prefs/CodePointZeroPrefsTest.java
+++ b/test/java/util/prefs/CodePointZeroPrefsTest.java
@@ -27,6 +27,7 @@
 /*
  * @test
  * @bug 8068373
+ * @requires os.family == "linux" | os.family == "solaris"
  * @summary Ensure writing a code point U+0000 null control character is detected.
  */
 public class CodePointZeroPrefsTest

Suppress test from running except on Linux and Solaris OS families. I believe the @requires tag is only supported by jtreg4.1-b10 and higher.

Thanks,

Brian

From joe.darcy at oracle.com  Fri Mar 13 21:47:12 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 13 Mar 2015 14:47:12 -0700
Subject: [9] RFR of 8075110: (prefs) CodePointZeroPrefsTest fails on
	certain platforms
In-Reply-To: <3D643EDD-3D0A-48C4-8D9D-BD7B2205E77D@oracle.com>
References: <3D643EDD-3D0A-48C4-8D9D-BD7B2205E77D@oracle.com>
Message-ID: <55035AE0.2010805@oracle.com>

Looks good Brian; thanks,

-Joe

On 3/13/2015 2:45 PM, Brian Burkhalter wrote:
> Please review at your convenience.
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8075110
> Diff:
>
> --- a/test/java/util/prefs/CodePointZeroPrefsTest.java
> +++ b/test/java/util/prefs/CodePointZeroPrefsTest.java
> @@ -27,6 +27,7 @@
>   /*
>    * @test
>    * @bug 8068373
> + * @requires os.family == "linux" | os.family == "solaris"
>    * @summary Ensure writing a code point U+0000 null control character is detected.
>    */
>   public class CodePointZeroPrefsTest
>
> Suppress test from running except on Linux and Solaris OS families. I believe the @requires tag is only supported by jtreg4.1-b10 and higher.
>
> Thanks,
>
> Brian



From brian.burkhalter at oracle.com  Fri Mar 13 21:53:15 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 13 Mar 2015 14:53:15 -0700
Subject: [9] RFR of 8073214: javadoc of Properties methods should specify
	NullPointerExceptions
In-Reply-To: <550351BD.8000904@oracle.com>
References: <6A7605E8-AD70-4BEA-A632-D7D7B108B2A6@oracle.com>
	<550351BD.8000904@oracle.com>
Message-ID: <59D988AB-44D8-4CA9-BFE6-6FD3FCD0AC28@oracle.com>

This is too trivial for a CCC request, no?

Thanks,

Brian

On Mar 13, 2015, at 2:08 PM, joe darcy <joe.darcy at oracle.com> wrote:

> Looks fine Brian; thanks,
> 
> -Joe
> 
> On 3/13/2015 1:40 PM, Brian Burkhalter wrote:
>> Please review at your convenience.
>> 
>> Issue:	https://bugs.openjdk.java.net/browse/JDK-8073214
>> Patch:	http://cr.openjdk.java.net/~bpb/8073214/webrev.00/
>> 
>> Lines 316 and 342 in Properties.java are not strictly necessary but make it a little more fail-fast.
>> 
>> Thanks,
>> 
>> Brian
> 



From joe.darcy at oracle.com  Fri Mar 13 21:55:22 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 13 Mar 2015 14:55:22 -0700
Subject: [9] RFR of 8073214: javadoc of Properties methods should specify
	NullPointerExceptions
In-Reply-To: <59D988AB-44D8-4CA9-BFE6-6FD3FCD0AC28@oracle.com>
References: <6A7605E8-AD70-4BEA-A632-D7D7B108B2A6@oracle.com>
	<550351BD.8000904@oracle.com>
	<59D988AB-44D8-4CA9-BFE6-6FD3FCD0AC28@oracle.com>
Message-ID: <55035CCA.9010708@oracle.com>

If the null handling is not implied by another part of the spec, it 
should have a ccc.

Cheers,

-Joe

On 3/13/2015 2:53 PM, Brian Burkhalter wrote:
> This is too trivial for a CCC request, no?
>
> Thanks,
>
> Brian
>
> On Mar 13, 2015, at 2:08 PM, joe darcy <joe.darcy at oracle.com> wrote:
>
>> Looks fine Brian; thanks,
>>
>> -Joe
>>
>> On 3/13/2015 1:40 PM, Brian Burkhalter wrote:
>>> Please review at your convenience.
>>>
>>> Issue:	https://bugs.openjdk.java.net/browse/JDK-8073214
>>> Patch:	http://cr.openjdk.java.net/~bpb/8073214/webrev.00/
>>>
>>> Lines 316 and 342 in Properties.java are not strictly necessary but make it a little more fail-fast.
>>>
>>> Thanks,
>>>
>>> Brian



From brian.burkhalter at oracle.com  Fri Mar 13 21:56:35 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 13 Mar 2015 14:56:35 -0700
Subject: [9] RFR of 8073214: javadoc of Properties methods should specify
	NullPointerExceptions
In-Reply-To: <55035CCA.9010708@oracle.com>
References: <6A7605E8-AD70-4BEA-A632-D7D7B108B2A6@oracle.com>
	<550351BD.8000904@oracle.com>
	<59D988AB-44D8-4CA9-BFE6-6FD3FCD0AC28@oracle.com>
	<55035CCA.9010708@oracle.com>
Message-ID: <723960B3-C922-48B9-A8E8-18DF32B53247@oracle.com>

In that case I?ll verify the state of affairs and file one if needed.

Thanks,

Brian

On Mar 13, 2015, at 2:55 PM, joe darcy <joe.darcy at oracle.com> wrote:

> If the null handling is not implied by another part of the spec, it should have a ccc.
> 
> Cheers,
> 
> -Joe
> 
> On 3/13/2015 2:53 PM, Brian Burkhalter wrote:
>> This is too trivial for a CCC request, no?



From Alan.Bateman at oracle.com  Sat Mar 14 07:04:30 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 14 Mar 2015 07:04:30 +0000
Subject: [9] RFR of 8073214: javadoc of Properties methods should specify
	NullPointerExceptions
In-Reply-To: <6A7605E8-AD70-4BEA-A632-D7D7B108B2A6@oracle.com>
References: <6A7605E8-AD70-4BEA-A632-D7D7B108B2A6@oracle.com>
Message-ID: <5503DD7E.1030202@oracle.com>

On 13/03/2015 20:40, Brian Burkhalter wrote:
> Please review at your convenience.
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8073214
> Patch:	http://cr.openjdk.java.net/~bpb/8073214/webrev.00/
>
> Lines 316 and 342 in Properties.java are not strictly necessary but make it a little more fail-fast.
>
The update to Properties looks okay but the @throws is mis-aligned so 
looks inconsistent with the other @throws in the methods.

The test should probably be renamed and the @summary changed to make it 
clear that it's a test for load & store throw nulls rather than a 
complete unit test for Properties.

-Alan


From forax at univ-mlv.fr  Sat Mar 14 11:32:05 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 14 Mar 2015 12:32:05 +0100
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <550330CE.3030607@redhat.com>
References: <550330CE.3030607@redhat.com>
Message-ID: <55041C35.3070406@univ-mlv.fr>

Hi Andrew,
Looks good to me.

R?mi

On 03/13/2015 07:47 PM, Andrew Haley wrote:
> I've tried to address all the points that have been made.
>
> I haven't changed the way the sub-words are read and written because
> the code I'm seeing is fairly nearly optimal right now and anything
> more complex runs the risk of tripping inlining limits, thus
> pessimizing performance.  We need a general solution which isn't
> optimized for special cases but is decent on average and often very
> good.  I think it's close to the best compromise we're going to get.
>
> I have changed the javadoc as requested and I have fixed the code in
> HeapByteBuffer so that it doesn't check the index twice for floating-
> point put() and get() operations.
>
> I have added a jtreg test for HeapByteBuffer which tests it pretty
> thoroughly.  It also, as a consequence, tests the underlying Unsafe
> methods.  I wasn't sure what a separate test for the Unsafe methods
> would achieve so I didn't write one.
>
> OK?
>
> http://cr.openjdk.java.net/~aph/unaligned.hotspot.6/
> http://cr.openjdk.java.net/~aph/unaligned.jdk.6/
>
> Andrew.



From david.holmes at oracle.com  Mon Mar 16 00:40:20 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Mar 2015 10:40:20 +1000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <550330CE.3030607@redhat.com>
References: <550330CE.3030607@redhat.com>
Message-ID: <55062674.9020407@oracle.com>

Andrew,

Experimental options are supposed to be opt-in only via 
UnlockExperimentalVMOptions. You presently have the experimental 
UseUnalignedAccesses being turned on unconditionally on those 
architectures that support it.

David

On 14/03/2015 4:47 AM, Andrew Haley wrote:
> I've tried to address all the points that have been made.
>
> I haven't changed the way the sub-words are read and written because
> the code I'm seeing is fairly nearly optimal right now and anything
> more complex runs the risk of tripping inlining limits, thus
> pessimizing performance.  We need a general solution which isn't
> optimized for special cases but is decent on average and often very
> good.  I think it's close to the best compromise we're going to get.
>
> I have changed the javadoc as requested and I have fixed the code in
> HeapByteBuffer so that it doesn't check the index twice for floating-
> point put() and get() operations.
>
> I have added a jtreg test for HeapByteBuffer which tests it pretty
> thoroughly.  It also, as a consequence, tests the underlying Unsafe
> methods.  I wasn't sure what a separate test for the Unsafe methods
> would achieve so I didn't write one.
>
> OK?
>
> http://cr.openjdk.java.net/~aph/unaligned.hotspot.6/
> http://cr.openjdk.java.net/~aph/unaligned.jdk.6/
>
> Andrew.
>


From john.r.rose at oracle.com  Mon Mar 16 02:52:00 2015
From: john.r.rose at oracle.com (John Rose)
Date: Sun, 15 Mar 2015 19:52:00 -0700
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <5501FFAE.1030503@redhat.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
	<5501C99D.6070901@gmail.com> <5501DCE8.3010108@redhat.com>
	<5501E90F.5010103@gmail.com> <5501FFAE.1030503@redhat.com>
Message-ID: <7D61F6CA-6465-4D4D-9EA7-0B1612FBCA73@oracle.com>

On Mar 12, 2015, at 2:05 PM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 03/12/2015 07:29 PM, Peter Levart wrote:
>> What about the following variant (or similar with ifs in case switch is 
>> sub-optimal):
>> 
>>     public final long getLongUnaligned(Object o, long offset) {
>>         switch ((int) offset & 7)
> ...
> 
> I tried that already, and it wasn't really any faster, and it won't
> vectorize nicely (vectorization was high on John's list).

...and switches are low on my list.  There are known performance problems with switch optimization.  If you can code the decision tree directly you are better off, even though an equivalent switch might present the decision tree more compactly or abstractly.  Ideally, a nice, clean switch should optimize to a decision tree that's as good or better as a handroll, but it doesn't.

For Unsafe, which is highly coupled to the platform, it's just fine to tie the details of the code to known optimization characteristics of the platform.

Andrew, thanks for going the extra mile and exploring the implementation alternatives so thoroughly.

? John

From john.r.rose at oracle.com  Mon Mar 16 06:12:44 2015
From: john.r.rose at oracle.com (John Rose)
Date: Sun, 15 Mar 2015 23:12:44 -0700
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <5501DCE8.3010108@redhat.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
	<5501C99D.6070901@gmail.com> <5501DCE8.3010108@redhat.com>
Message-ID: <0D8F837E-C43B-4678-8574-FF1C4ACFC25A@oracle.com>

On Mar 12, 2015, at 11:37 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 03/12/2015 05:15 PM, Peter Levart wrote:
>> ...or are JIT+CPU smart enough and there would be no difference?
> 
> C2 always orders things based on profile counts, so there is no
> difference.  Your suggestion would be better for interpreted code
> and I guess C1 also, so I agree it is worthwhile.

Profile counts can partially reorganize decision trees,
if they are unambiguous.  The best effect from profiling
is to prune untaken branches completely (leaving a deopt).

The main caveat here is that this breaks down when the
profile is ambiguous, which can happen when multiple
users of a library routine "pollute" the profile with
divergent behaviors.  See (e.g.) slides 17-19 of:
  http://cr.openjdk.java.net/~jrose/pres/201502-JVMChallenges.pdf

The JVM currently addresses this mainly by combining local
profile data with type inference that crosses inline boundaries.
The present case can perhaps be improved by type inference
or non-local profiling on bitfields, which is partially discussed in:
  https://bugs.openjdk.java.net/browse/JDK-8001436

BTW, I like Peter's suggestion to perform localized merging of
bytes to shorts (etc.) based on exact alignment.  But, I'd rather
see it done further down the pipeline, after vectorization.

? John

From aph at redhat.com  Mon Mar 16 09:06:22 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Mar 2015 09:06:22 +0000
Subject: Unsafe.{get,put}-X-Unaligned performance
In-Reply-To: <0D8F837E-C43B-4678-8574-FF1C4ACFC25A@oracle.com>
References: <54EB6DD1.4090803@redhat.com> <54FF3FAD.5040702@redhat.com>
	<5501C99D.6070901@gmail.com> <5501DCE8.3010108@redhat.com>
	<0D8F837E-C43B-4678-8574-FF1C4ACFC25A@oracle.com>
Message-ID: <55069D0E.7080604@redhat.com>

On 16/03/15 06:12, John Rose wrote:
> BTW, I like Peter's suggestion to perform localized merging of
> bytes to shorts (etc.) based on exact alignment.  But, I'd rather
> see it done further down the pipeline, after vectorization.

That makes sense.

Thanks,
Andrew.



From aph at redhat.com  Mon Mar 16 09:29:47 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Mar 2015 09:29:47 +0000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <55062674.9020407@oracle.com>
References: <550330CE.3030607@redhat.com> <55062674.9020407@oracle.com>
Message-ID: <5506A28B.3070009@redhat.com>

On 16/03/15 00:40, David Holmes wrote:
> Experimental options are supposed to be opt-in only via 
> UnlockExperimentalVMOptions. You presently have the experimental 
> UseUnalignedAccesses being turned on unconditionally on those 
> architectures that support it.

Well, it works.  I guess this could be changed to be a product option,
but it's only really needed for testing.  And aren't product options
supposed to be properly documented for all users?

In other words: please don't say "don't do that."  Please tell me what
I should do instead.  All suggestions are welcome, really because I'm
rather stuck.

Andrew.


From paul.sandoz at oracle.com  Mon Mar 16 10:03:25 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 16 Mar 2015 11:03:25 +0100
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float,
	...} methods
In-Reply-To: <550330CE.3030607@redhat.com>
References: <550330CE.3030607@redhat.com>
Message-ID: <E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>

I am running this patch though our JPRT test system right now.

The test looks good, two comments on it:

- IMO it does not need the internal PRNG FastRandom, SplittableRandom can be used instead.

- I suspect that test needs to be located in the hotspot test area, which likely means it gets run on more "exotic" platforms. Perhaps someone with more knowledge of the test configuration and infrastructure can comment?

Paul.

On Mar 13, 2015, at 7:47 PM, Andrew Haley <aph at redhat.com> wrote:

> I've tried to address all the points that have been made.
> 
> I haven't changed the way the sub-words are read and written because
> the code I'm seeing is fairly nearly optimal right now and anything
> more complex runs the risk of tripping inlining limits, thus
> pessimizing performance.  We need a general solution which isn't
> optimized for special cases but is decent on average and often very
> good.  I think it's close to the best compromise we're going to get.
> 
> I have changed the javadoc as requested and I have fixed the code in
> HeapByteBuffer so that it doesn't check the index twice for floating-
> point put() and get() operations.
> 
> I have added a jtreg test for HeapByteBuffer which tests it pretty
> thoroughly.  It also, as a consequence, tests the underlying Unsafe
> methods.  I wasn't sure what a separate test for the Unsafe methods
> would achieve so I didn't write one.
> 
> OK?
> 
> http://cr.openjdk.java.net/~aph/unaligned.hotspot.6/
> http://cr.openjdk.java.net/~aph/unaligned.jdk.6/
> 
> Andrew.



From aph at redhat.com  Mon Mar 16 10:14:53 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Mar 2015 10:14:53 +0000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>
References: <550330CE.3030607@redhat.com>
	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>
Message-ID: <5506AD1D.1090000@redhat.com>

On 16/03/15 10:03, Paul Sandoz wrote:
> I am running this patch though our JPRT test system right now.
> 
> The test looks good, two comments on it:
> 
> - IMO it does not need the internal PRNG FastRandom,
>   SplittableRandom can be used instead.

OK.

> - I suspect that test needs to be located in the hotspot test area,
>   which likely means it gets run on more "exotic" platforms. Perhaps
>   someone with more knowledge of the test configuration and
>   infrastructure can comment?

OK.  I'll wait for an answer.

Andrew.


From paul.sandoz at oracle.com  Mon Mar 16 10:30:15 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 16 Mar 2015 11:30:15 +0100
Subject: Build error on sparc <was> Re: 8026049: (bf) Intrinsify
	ByteBuffer.put{Int, Double, Float, ...} methods
In-Reply-To: <E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>
References: <550330CE.3030607@redhat.com>
	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>
Message-ID: <E1FDCCBC-B1CC-45F3-B0BB-7542AB480D89@oracle.com>


On Mar 16, 2015, at 11:03 AM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:

> I am running this patch though our JPRT test system right now.
> 

I am getting a build error on spark:

  "... /hotspot/src/share/vm/prims/unsafe.cpp", line 335: Error: #error VM_LITTLE_ENDIAN or VM_BIG_ENDIAN must be defined.

The assumption seems to be that if VM_LITTLE_ENDIAN is not defined then the platform is implicitly VM_BIG_ENDIAN. 

Paul.


From aph at redhat.com  Mon Mar 16 10:39:20 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Mar 2015 10:39:20 +0000
Subject: Build error on sparc <was> Re: 8026049: (bf) Intrinsify
	ByteBuffer.put{Int, Double, Float, ...} methods
In-Reply-To: <E1FDCCBC-B1CC-45F3-B0BB-7542AB480D89@oracle.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>
	<E1FDCCBC-B1CC-45F3-B0BB-7542AB480D89@oracle.com>
Message-ID: <5506B2D8.3000307@redhat.com>

On 03/16/2015 10:30 AM, Paul Sandoz wrote:
> 
> On Mar 16, 2015, at 11:03 AM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
> 
>> I am running this patch though our JPRT test system right now.
>>
> 
> I am getting a build error on spark:
> 
>   "... /hotspot/src/share/vm/prims/unsafe.cpp", line 335: Error: #error VM_LITTLE_ENDIAN or VM_BIG_ENDIAN must be defined.
> 
> The assumption seems to be that if VM_LITTLE_ENDIAN is not defined then the platform is implicitly VM_BIG_ENDIAN. 

I think that we've exposed something that we should fix now.  As
John Rose put it,

    Culture of clean: Leave it nicer than you found it
      ? Budget for technical debt, expect and welcome debt removal

VM_LITTLE_ENDIAN or VM_BIG_ENDIAN should be defined on all platforms.

Andrew.



From david.holmes at oracle.com  Mon Mar 16 11:36:00 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Mar 2015 21:36:00 +1000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <5506A28B.3070009@redhat.com>
References: <550330CE.3030607@redhat.com> <55062674.9020407@oracle.com>
	<5506A28B.3070009@redhat.com>
Message-ID: <5506C020.9050703@oracle.com>

On 16/03/2015 7:29 PM, Andrew Haley wrote:
> On 16/03/15 00:40, David Holmes wrote:
>> Experimental options are supposed to be opt-in only via
>> UnlockExperimentalVMOptions. You presently have the experimental
>> UseUnalignedAccesses being turned on unconditionally on those
>> architectures that support it.
>
> Well, it works.  I guess this could be changed to be a product option,
> but it's only really needed for testing.  And aren't product options
> supposed to be properly documented for all users?
>
> In other words: please don't say "don't do that."  Please tell me what
> I should do instead.  All suggestions are welcome, really because I'm
> rather stuck.

Either it should be an experimental option, in which case the logic that 
sets the flag on should check that UnlockExperimentalVMOptions is also 
on (else do nothing). (Though this would still be a unusual use-case for 
an experimental option as the intent is that the user chooses to turn 
them on directly.)

Or it should not be an experimental option.

If it is a to be a product flag then it needs to go through the CCC process.

David
-----

> Andrew.
>


From david.holmes at oracle.com  Mon Mar 16 11:41:02 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Mar 2015 21:41:02 +1000
Subject: Build error on sparc <was> Re: 8026049: (bf) Intrinsify
	ByteBuffer.put{Int, Double, Float, ...} methods
In-Reply-To: <5506B2D8.3000307@redhat.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<E1FDCCBC-B1CC-45F3-B0BB-7542AB480D89@oracle.com>
	<5506B2D8.3000307@redhat.com>
Message-ID: <5506C14E.6010803@oracle.com>

On 16/03/2015 8:39 PM, Andrew Haley wrote:
> On 03/16/2015 10:30 AM, Paul Sandoz wrote:
>>
>> On Mar 16, 2015, at 11:03 AM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
>>
>>> I am running this patch though our JPRT test system right now.
>>>
>>
>> I am getting a build error on spark:
>>
>>    "... /hotspot/src/share/vm/prims/unsafe.cpp", line 335: Error: #error VM_LITTLE_ENDIAN or VM_BIG_ENDIAN must be defined.
>>
>> The assumption seems to be that if VM_LITTLE_ENDIAN is not defined then the platform is implicitly VM_BIG_ENDIAN.
>
> I think that we've exposed something that we should fix now.  As
> John Rose put it,
>
>      Culture of clean: Leave it nicer than you found it
>        ? Budget for technical debt, expect and welcome debt removal
>
> VM_LITTLE_ENDIAN or VM_BIG_ENDIAN should be defined on all platforms.

VM_BIG_ENDIAN does not exist in the sources. The only place it exists is in:

./bsd/makefiles/ppc.make:CFLAGS += -DVM_BIG_ENDIAN
./linux/makefiles/ppc.make:CFLAGS += -DVM_BIG_ENDIAN

The expectation is that if VM_LITTLE_ENDIAN is not defined then you are 
big endian. Given the two options are mutually-exclusive a single flag, 
defined or not, covers it.

David

> Andrew.
>


From aph at redhat.com  Mon Mar 16 11:54:37 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Mar 2015 11:54:37 +0000
Subject: Build error on sparc <was> Re: 8026049: (bf) Intrinsify
	ByteBuffer.put{Int, Double, Float, ...} methods
In-Reply-To: <5506C14E.6010803@oracle.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<E1FDCCBC-B1CC-45F3-B0BB-7542AB480D89@oracle.com>
	<5506B2D8.3000307@redhat.com> <5506C14E.6010803@oracle.com>
Message-ID: <5506C47D.8000102@redhat.com>

On 03/16/2015 11:41 AM, David Holmes wrote:
> VM_BIG_ENDIAN does not exist in the sources. The only place it exists is in:
> 
> ./bsd/makefiles/ppc.make:CFLAGS += -DVM_BIG_ENDIAN
> ./linux/makefiles/ppc.make:CFLAGS += -DVM_BIG_ENDIAN
> 
> The expectation is that if VM_LITTLE_ENDIAN is not defined then you are 
> big endian. Given the two options are mutually-exclusive a single flag, 
> defined or not, covers it.

Unless someone forgets, or there is a bug in the build files.  This
is not a theoretical possibility.  This is a bug which we have seen
in the last couple of months.

Andrew.



From aph at redhat.com  Mon Mar 16 12:23:16 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Mar 2015 12:23:16 +0000
Subject: Build error on sparc <was> Re: 8026049: (bf) Intrinsify
	ByteBuffer.put{Int, Double, Float, ...} methods
In-Reply-To: <5506C47D.8000102@redhat.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<E1FDCCBC-B1CC-45F3-B0BB-7542AB480D89@oracle.com>	<5506B2D8.3000307@redhat.com>
	<5506C14E.6010803@oracle.com> <5506C47D.8000102@redhat.com>
Message-ID: <5506CB34.7040303@redhat.com>

On 03/16/2015 11:54 AM, Andrew Haley wrote:
> On 03/16/2015 11:41 AM, David Holmes wrote:
>> VM_BIG_ENDIAN does not exist in the sources. The only place it exists is in:
>>
>> ./bsd/makefiles/ppc.make:CFLAGS += -DVM_BIG_ENDIAN
>> ./linux/makefiles/ppc.make:CFLAGS += -DVM_BIG_ENDIAN
>>
>> The expectation is that if VM_LITTLE_ENDIAN is not defined then you are 
>> big endian. Given the two options are mutually-exclusive a single flag, 
>> defined or not, covers it.
> 
> Unless someone forgets, or there is a bug in the build files.  This
> is not a theoretical possibility.  This is a bug which we have seen
> in the last couple of months.

I will change this because I really want this patch to go in, but
under protest.

Andrew.



From aph at redhat.com  Mon Mar 16 12:25:37 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Mar 2015 12:25:37 +0000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <5506C020.9050703@oracle.com>
References: <550330CE.3030607@redhat.com> <55062674.9020407@oracle.com>
	<5506A28B.3070009@redhat.com> <5506C020.9050703@oracle.com>
Message-ID: <5506CBC1.1020309@redhat.com>

On 03/16/2015 11:36 AM, David Holmes wrote:
> On 16/03/2015 7:29 PM, Andrew Haley wrote:
>> On 16/03/15 00:40, David Holmes wrote:
>>> Experimental options are supposed to be opt-in only via
>>> UnlockExperimentalVMOptions. You presently have the experimental
>>> UseUnalignedAccesses being turned on unconditionally on those
>>> architectures that support it.
>>
>> Well, it works.  I guess this could be changed to be a product option,
>> but it's only really needed for testing.  And aren't product options
>> supposed to be properly documented for all users?
>>
>> In other words: please don't say "don't do that."  Please tell me what
>> I should do instead.  All suggestions are welcome, really because I'm
>> rather stuck.
> 
> Either it should be an experimental option, in which case the logic that 
> sets the flag on should check that UnlockExperimentalVMOptions is also 
> on (else do nothing).

But UnlockExperimentalVMOptions is handled by the option processing
already.

> (Though this would still be a unusual use-case for 
> an experimental option as the intent is that the user chooses to turn 
> them on directly.)
> 
> Or it should not be an experimental option.

We need a flag which defaults to whatever is right for the platform
(so it must be set in the back ends) but can be overridden by testing.
What we have right now fits that requirement.  I can see no way to do
what I think you're asking for with the current option machinery.  I
certainly don't think this should be a product flag.

Andrew.


From peter.levart at gmail.com  Mon Mar 16 12:43:46 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 16 Mar 2015 13:43:46 +0100
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <5506CBC1.1020309@redhat.com>
References: <550330CE.3030607@redhat.com>
	<55062674.9020407@oracle.com>	<5506A28B.3070009@redhat.com>
	<5506C020.9050703@oracle.com> <5506CBC1.1020309@redhat.com>
Message-ID: <5506D002.5060609@gmail.com>

On 03/16/2015 01:25 PM, Andrew Haley wrote:
> On 03/16/2015 11:36 AM, David Holmes wrote:
>> On 16/03/2015 7:29 PM, Andrew Haley wrote:
>>> On 16/03/15 00:40, David Holmes wrote:
>>>> Experimental options are supposed to be opt-in only via
>>>> UnlockExperimentalVMOptions. You presently have the experimental
>>>> UseUnalignedAccesses being turned on unconditionally on those
>>>> architectures that support it.
>>> Well, it works.  I guess this could be changed to be a product option,
>>> but it's only really needed for testing.  And aren't product options
>>> supposed to be properly documented for all users?
>>>
>>> In other words: please don't say "don't do that."  Please tell me what
>>> I should do instead.  All suggestions are welcome, really because I'm
>>> rather stuck.
>> Either it should be an experimental option, in which case the logic that
>> sets the flag on should check that UnlockExperimentalVMOptions is also
>> on (else do nothing).
> But UnlockExperimentalVMOptions is handled by the option processing
> already.
>
>> (Though this would still be a unusual use-case for
>> an experimental option as the intent is that the user chooses to turn
>> them on directly.)
>>
>> Or it should not be an experimental option.
> We need a flag which defaults to whatever is right for the platform
> (so it must be set in the back ends) but can be overridden by testing.
> What we have right now fits that requirement.  I can see no way to do
> what I think you're asking for with the current option machinery.  I
> certainly don't think this should be a product flag.
>
> Andrew.

Hi Andrew,

I think the confusion is caused by UseUnalignedAccesses flag (part of a 
public interface unless it is experimental - the command line options) 
that is used internally to communicate the cpu default to the 
implementation of Unsafe.unalignedAccess() method. What if:

- you define an internal constant SUPPORTS_UNALIGNED_ACCESSES (I don't 
know how to do that correctly) in per-cpu vm_version_cpu.hpp files.
- rename UseUnalignedAccesses to EmulateUnalignedAccesses (reverse the 
meaning, so that default can be false which must be for experimental 
options)
- implement Unsafe.unalignedAccess() to return: 
SUPPORTS_UNALIGNED_ACCESSES && !EmulateUnalignedAccesses ...

Regards, Peter



From paul.sandoz at oracle.com  Mon Mar 16 14:04:40 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 16 Mar 2015 15:04:40 +0100
Subject: RFR 8075230 Optimized count operations incorrectly declare the stream
	shape 
Message-ID: <79987239-C036-4605-8146-0C5FB7F47117@oracle.com>

Hi,

This is a fix for a silly regression introduced with JDK-8067969 (optimized count operations) that i should have caught in review.

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8075230-count-prims-shape/webrev/

The count operations for int, long and double incorrectly declare a stream shape of reference. This causes tests to fail when assertions are enabled.

Thanks,
Paul.


From chris.hegarty at oracle.com  Mon Mar 16 14:17:51 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 16 Mar 2015 14:17:51 +0000
Subject: RFR 8075230 Optimized count operations incorrectly declare the
	stream shape
In-Reply-To: <79987239-C036-4605-8146-0C5FB7F47117@oracle.com>
References: <79987239-C036-4605-8146-0C5FB7F47117@oracle.com>
Message-ID: <5506E60F.6070806@oracle.com>


On 16/03/15 14:04, Paul Sandoz wrote:
> Hi,
>
> This is a fix for a silly regression introduced with JDK-8067969 (optimized count operations) that i should have caught in review.

I also missed it :-(

>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8075230-count-prims-shape/webrev/

Looks fine to me.

-Chris.

> The count operations for int, long and double incorrectly declare a stream shape of reference. This causes tests to fail when assertions are enabled.
>
> Thanks,
> Paul.
>


From aph at redhat.com  Mon Mar 16 14:50:01 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Mar 2015 14:50:01 +0000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <5506D002.5060609@gmail.com>
References: <550330CE.3030607@redhat.com>
	<55062674.9020407@oracle.com>	<5506A28B.3070009@redhat.com>
	<5506C020.9050703@oracle.com> <5506CBC1.1020309@redhat.com>
	<5506D002.5060609@gmail.com>
Message-ID: <5506ED99.6000408@redhat.com>

Hi,

On 03/16/2015 12:43 PM, Peter Levart wrote:
> On 03/16/2015 01:25 PM, Andrew Haley wrote:
>> We need a flag which defaults to whatever is right for the platform
>> (so it must be set in the back ends) but can be overridden by testing.
>> What we have right now fits that requirement.  I can see no way to do
>> what I think you're asking for with the current option machinery.  I
>> certainly don't think this should be a product flag.
> 
> I think the confusion is caused by UseUnalignedAccesses flag (part of a 
> public interface unless it is experimental - the command line options) 
> that is used internally to communicate the cpu default to the 
> implementation of Unsafe.unalignedAccess() method. What if:
> 
> - you define an internal constant SUPPORTS_UNALIGNED_ACCESSES (I don't 
> know how to do that correctly) in per-cpu vm_version_cpu.hpp files.

It can not be a constant: on some platforms it's something that you
read from a configuration register.  But I can do something like that.

> - rename UseUnalignedAccesses to EmulateUnalignedAccesses (reverse the 
> meaning, so that default can be false which must be for experimental 
> options)
>
> - implement Unsafe.unalignedAccess() to return: 
> SUPPORTS_UNALIGNED_ACCESSES && !EmulateUnalignedAccesses ...

I'm not sure what EmulateUnalignedAccesses means; I guess it must mean
that we don't generate code which does unaligned accesses.  But is that
what "emulate unaligned accesses" means to you?

I'm going to go with DisableUnalignedAccesses, because I at least know
what that means.  :-)

Thanks,
Andrew.


From aph at redhat.com  Mon Mar 16 17:19:57 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Mar 2015 17:19:57 +0000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>
References: <550330CE.3030607@redhat.com>
	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>
Message-ID: <550710BD.5060301@redhat.com>

On 03/16/2015 10:03 AM, Paul Sandoz wrote:
> I am running this patch though our JPRT test system right now.
> 
> The test looks good, two comments on it:
> 
> - IMO it does not need the internal PRNG FastRandom, SplittableRandom can be used instead.
> 
> - I suspect that test needs to be located in the hotspot test area, which likely means it gets run on more "exotic" platforms. Perhaps someone with more knowledge of the test configuration and infrastructure can comment?

I have a patch with all of the changes that people have asked for
except this last one.  I don't know who to ask.

Andrew.


From vladimir.x.ivanov at oracle.com  Mon Mar 16 18:47:44 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 16 Mar 2015 21:47:44 +0300
Subject: [9] RFR (S): 8075263: MHI::checkCustomized isn't eliminated for
	inlined MethodHandles
Message-ID: <55072550.9090309@oracle.com>

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

When MethodHandle is a compile-time constant and it is inlined in 
MethodHandle.invoke/invokeExact there's no need in MHI::checkCustomized 
call. It should be eliminated since it adds some overhead on fast path.

The fix is to add new intrinsic (MHI::isCompileConstant) and use it to 
prune MHI::checkCustomized logic when MethodHandle is a constant.

Testing: java/lang/invoke, nashorn, octane

Best regards,
Vladimir Ivanov


From john.r.rose at oracle.com  Mon Mar 16 19:05:23 2015
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 16 Mar 2015 12:05:23 -0700
Subject: [9] RFR (S): 8075263: MHI::checkCustomized isn't eliminated for
	inlined MethodHandles
In-Reply-To: <55072550.9090309@oracle.com>
References: <55072550.9090309@oracle.com>
Message-ID: <C315F6EF-AD18-4E44-A02C-E617BBB1513E@oracle.com>

Reviewed.  ? John

On Mar 16, 2015, at 11:47 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/hotspot
> http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/jdk
> https://bugs.openjdk.java.net/browse/JDK-8075263




From john.r.rose at oracle.com  Mon Mar 16 19:16:30 2015
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 16 Mar 2015 12:16:30 -0700
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float,
	...} methods
In-Reply-To: <5506A28B.3070009@redhat.com>
References: <550330CE.3030607@redhat.com> <55062674.9020407@oracle.com>
	<5506A28B.3070009@redhat.com>
Message-ID: <A4351E81-CACF-424D-B748-ECDFE7AD3CA6@oracle.com>

On Mar 16, 2015, at 2:29 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 16/03/15 00:40, David Holmes wrote:
>> Experimental options are supposed to be opt-in only via 
>> UnlockExperimentalVMOptions. You presently have the experimental 
>> UseUnalignedAccesses being turned on unconditionally on those 
>> architectures that support it.
> 
> Well, it works.  I guess this could be changed to be a product option,
> but it's only really needed for testing.  And aren't product options
> supposed to be properly documented for all users?
> 
> In other words: please don't say "don't do that."  Please tell me what
> I should do instead.  All suggestions are welcome, really because I'm
> rather stuck.

David has a point about experimental options; they have an opt-in sense to them.

Since the option provides control for product behavior, without an explicit opt-in, it should either be a product flag or a diagnostic flag.

I suggest keeping the more direct name (Use* not Disable*) and making it a diagnostic flag.

As a diagnostic flag it does not require a CCC request, since it is not for JVM customers to use.  Its purpose is testing and field diagnosis by implementation engineers.  Similar flags are ScavengeRootsInCode, LogEventsBufferEntries, and ParGCCardsPerStrideChunk.

Typical uses:  On platforms which support unaligned accesses, do differential performance testing to verify that the switch is correctly set for the platform.  On platforms which do not, if hardware or JIT upgrades supply a faster unaligned access, do differential regression testing with the new feature in play.

? John

From vladimir.x.ivanov at oracle.com  Mon Mar 16 19:26:32 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 16 Mar 2015 22:26:32 +0300
Subject: [9] RFR (S): 8075263: MHI::checkCustomized isn't eliminated for
	inlined MethodHandles
In-Reply-To: <C315F6EF-AD18-4E44-A02C-E617BBB1513E@oracle.com>
References: <55072550.9090309@oracle.com>
	<C315F6EF-AD18-4E44-A02C-E617BBB1513E@oracle.com>
Message-ID: <55072E68.5070203@oracle.com>

Thanks, John!

Best regards,
Vladimir Ivanov

On 3/16/15 10:05 PM, John Rose wrote:
> Reviewed.  ? John
>
> On Mar 16, 2015, at 11:47 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>>
>> http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/hotspot
>> http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/jdk
>> https://bugs.openjdk.java.net/browse/JDK-8075263
>
>


From biboudis at gmail.com  Mon Mar 16 19:34:08 2015
From: biboudis at gmail.com (Aggelos Biboudis)
Date: Mon, 16 Mar 2015 21:34:08 +0200
Subject: RFR 8075230 Optimized count operations incorrectly declare the
	stream shape
In-Reply-To: <79987239-C036-4605-8146-0C5FB7F47117@oracle.com>
References: <79987239-C036-4605-8146-0C5FB7F47117@oracle.com>
Message-ID: <CAHLSyCkgzFMZfhYxnA5nbzdrc_CRtFQofDcsWCZFUJM1ecj8Jw@mail.gmail.com>

Sry, for the incorrect shapes.

Thanks Paul!

Aggelos.


On Mon, Mar 16, 2015 at 4:04 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
>
> This is a fix for a silly regression introduced with JDK-8067969
> (optimized count operations) that i should have caught in review.
>
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8075230-count-prims-shape/webrev/
>
> The count operations for int, long and double incorrectly declare a stream
> shape of reference. This causes tests to fail when assertions are enabled.
>
> Thanks,
> Paul.
>


From brian.burkhalter at oracle.com  Mon Mar 16 19:59:50 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 16 Mar 2015 12:59:50 -0700
Subject: [9] RFR of 8075222: RandomAccessFile.getChannel changed to non-final
	in error
Message-ID: <132D97F2-8D93-43E4-9C4C-3987CF7943BA@oracle.com>

Please review at your convenience.

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

--- a/src/java.base/share/classes/java/io/RandomAccessFile.java
+++ b/src/java.base/share/classes/java/io/RandomAccessFile.java
@@ -276,7 +276,7 @@
      * @since 1.4
      * @spec JSR-51
      */
-    public FileChannel getChannel() {
+    public final FileChannel getChannel() {
         FileChannel fc = this.channel;
         if (fc == null) {
             synchronized (this) {

Reinstate ?final? in method declaration.

Thanks,

Brian



From lev.priima at oracle.com  Mon Mar 16 20:30:30 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Mon, 16 Mar 2015 23:30:30 +0300
Subject: RFR(XS): 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java heap
	space: MaxHeap shrinked by MaxRAMFraction
In-Reply-To: <54EF9FB7.7030400@oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>	<54DCDB2D.3090006@oracle.com>
	<54DD5F6F.4070105@oracle.com>	<54DE0436.5070301@oracle.com>
	<54E18636.4000600@oracle.com>	<54E1B170.1000801@oracle.com>
	<54E1D28B.7030503@oracle.com> <54E28957.1070309@oracle.com>
	<54E2D51B.8020808@oracle.com> <54E2E5F1.4070702@oracle.com>
	<54E5D060.1080409@oracle.com> <54E5E3B9.80703@oracle.com>
	<54E69B43.4000501@oracle.com> <54E704F2.1010201@oracle.com>
	<54EA88A9.2080204@oracle.com> <54EC54FA.9020503@oracle.com>
	<54EEC949.20704@oracle.com> <54EEFD16.5090009@oracle.com>
	<54EF87C4.5000407@oracle.com> <54EF99E6.4030003@oracle.com>
	<54EF9FB7.7030400@oracle.com>
Message-ID: <55073D66.1080204@oracle.com>

Please reviewand push:

Issue:https://bugs.openjdk.java.net/browse/JDK-8075071
Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/

Tested locally:
jtreg -vmoptions:"-XX:MaxRAMFraction=9223372036854775807 
-XX:-UseCompressedOops" test/java/util/Arrays/TimSortStackSize2.java
Test results: passed: 1

Lev



From Alan.Bateman at oracle.com  Mon Mar 16 20:43:44 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Mar 2015 20:43:44 +0000
Subject: [9] RFR of 8075222: RandomAccessFile.getChannel changed to
	non-final in error
In-Reply-To: <132D97F2-8D93-43E4-9C4C-3987CF7943BA@oracle.com>
References: <132D97F2-8D93-43E4-9C4C-3987CF7943BA@oracle.com>
Message-ID: <55074080.7030902@oracle.com>



On 16/03/2015 19:59, Brian Burkhalter wrote:
> Please review at your convenience.
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8075222
> Diff:
>
> --- a/src/java.base/share/classes/java/io/RandomAccessFile.java
> +++ b/src/java.base/share/classes/java/io/RandomAccessFile.java
> @@ -276,7 +276,7 @@
>        * @since 1.4
>        * @spec JSR-51
>        */
> -    public FileChannel getChannel() {
> +    public final FileChannel getChannel() {
>
Looks fine, sorry we missed this when agreeing that patch.

-Alan


From brian.burkhalter at oracle.com  Mon Mar 16 20:48:36 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 16 Mar 2015 13:48:36 -0700
Subject: [9] RFR of 8075222: RandomAccessFile.getChannel changed to
	non-final in error
In-Reply-To: <55074080.7030902@oracle.com>
References: <132D97F2-8D93-43E4-9C4C-3987CF7943BA@oracle.com>
	<55074080.7030902@oracle.com>
Message-ID: <D19F07F9-4AAE-4324-B1CB-156B806302B5@oracle.com>


On Mar 16, 2015, at 1:43 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

>> -    public FileChannel getChannel() {
>> +    public final FileChannel getChannel() {
>> 
> Looks fine, sorry we missed this when agreeing that patch.

Sorry I missed it!

Thanks,

Brian

From vladimir.kozlov at oracle.com  Mon Mar 16 21:31:05 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 16 Mar 2015 14:31:05 -0700
Subject: [9] RFR (S): 8075263: MHI::checkCustomized isn't eliminated for
	inlined MethodHandles
In-Reply-To: <C315F6EF-AD18-4E44-A02C-E617BBB1513E@oracle.com>
References: <55072550.9090309@oracle.com>
	<C315F6EF-AD18-4E44-A02C-E617BBB1513E@oracle.com>
Message-ID: <55074B99.4020503@oracle.com>

Good.

thanks,
Vladimir K

On 3/16/15 12:05 PM, John Rose wrote:
> Reviewed.  ? John
>
> On Mar 16, 2015, at 11:47 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>>
>> http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/hotspot
>> http://cr.openjdk.java.net/~vlivanov/8075263/webrev.00/jdk
>> https://bugs.openjdk.java.net/browse/JDK-8075263
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>


From xueming.shen at oracle.com  Mon Mar 16 22:00:54 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 16 Mar 2015 15:00:54 -0700
Subject: RFR JDK-8074678: JCK test api/java_util/regex/MatchResult/index.html
	starts failing after JDK-8071479
Message-ID: <55075296.1020109@oracle.com>

Please help review the change for

issue: https://bugs.openjdk.java.net/browse/JDK-8074678
webrev: http://cr.openjdk.java.net/~sherman/8074678

The proposed fix is to implement the same "whether or not there
is a match" sanity check in ImmutableMatchResult.

Thanks,
-Sherman


From david.holmes at oracle.com  Tue Mar 17 01:50:00 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Mar 2015 11:50:00 +1000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <A4351E81-CACF-424D-B748-ECDFE7AD3CA6@oracle.com>
References: <550330CE.3030607@redhat.com> <55062674.9020407@oracle.com>
	<5506A28B.3070009@redhat.com>
	<A4351E81-CACF-424D-B748-ECDFE7AD3CA6@oracle.com>
Message-ID: <55078848.1080800@oracle.com>

On 17/03/2015 5:16 AM, John Rose wrote:
> On Mar 16, 2015, at 2:29 AM, Andrew Haley <aph at redhat.com> wrote:
>>
>> On 16/03/15 00:40, David Holmes wrote:
>>> Experimental options are supposed to be opt-in only via
>>> UnlockExperimentalVMOptions. You presently have the experimental
>>> UseUnalignedAccesses being turned on unconditionally on those
>>> architectures that support it.
>>
>> Well, it works.  I guess this could be changed to be a product option,
>> but it's only really needed for testing.  And aren't product options
>> supposed to be properly documented for all users?
>>
>> In other words: please don't say "don't do that."  Please tell me what
>> I should do instead.  All suggestions are welcome, really because I'm
>> rather stuck.
>
> David has a point about experimental options; they have an opt-in sense to them.

Actually John it has been pointed out to me that my interpretation of 
experimental options is not correct. It seems we already have a number 
of "experimental" options that are on by default and the "experimental" 
aspect is the turning of them off.

> Since the option provides control for product behavior, without an explicit opt-in, it should either be a product flag or a diagnostic flag.
>
> I suggest keeping the more direct name (Use* not Disable*) and making it a diagnostic flag.
>
> As a diagnostic flag it does not require a CCC request, since it is not for JVM customers to use.  Its purpose is testing and field diagnosis by implementation engineers.  Similar flags are ScavengeRootsInCode, LogEventsBufferEntries, and ParGCCardsPerStrideChunk.

I think diagnostic works better here too.

Thanks,
David

> Typical uses:  On platforms which support unaligned accesses, do differential performance testing to verify that the switch is correctly set for the platform.  On platforms which do not, if hardware or JIT upgrades supply a faster unaligned access, do differential regression testing with the new feature in play.
>
> ? John
>


From david.holmes at oracle.com  Tue Mar 17 04:40:27 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Mar 2015 14:40:27 +1000
Subject: RFR(XS): 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java
	heap space: MaxHeap shrinked by MaxRAMFraction
In-Reply-To: <55073D66.1080204@oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>	<54DCDB2D.3090006@oracle.com>	<54DD5F6F.4070105@oracle.com>	<54DE0436.5070301@oracle.com>	<54E18636.4000600@oracle.com>	<54E1B170.1000801@oracle.com>	<54E1D28B.7030503@oracle.com>
	<54E28957.1070309@oracle.com>	<54E2D51B.8020808@oracle.com>
	<54E2E5F1.4070702@oracle.com>	<54E5D060.1080409@oracle.com>
	<54E5E3B9.80703@oracle.com>	<54E69B43.4000501@oracle.com>
	<54E704F2.1010201@oracle.com>	<54EA88A9.2080204@oracle.com>
	<54EC54FA.9020503@oracle.com>	<54EEC949.20704@oracle.com>
	<54EEFD16.5090009@oracle.com>	<54EF87C4.5000407@oracle.com>
	<54EF99E6.4030003@oracle.com>	<54EF9FB7.7030400@oracle.com>
	<55073D66.1080204@oracle.com>
Message-ID: <5507B03B.5010606@oracle.com>

Hi Lev,

On 17/03/2015 6:30 AM, Lev Priima wrote:
> Please reviewand push:
>
> Issue:https://bugs.openjdk.java.net/browse/JDK-8075071
> Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/
>
> Tested locally:
> jtreg -vmoptions:"-XX:MaxRAMFraction=9223372036854775807
> -XX:-UseCompressedOops" test/java/util/Arrays/TimSortStackSize2.java
> Test results: passed: 1

How does MaxRAMFraction interact with -Xmx?

Thanks,
David

> Lev
>


From amy.lu at oracle.com  Tue Mar 17 07:05:40 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 17 Mar 2015 15:05:40 +0800
Subject: JDK 9 RFR of JDK-8075304: Remove duplicate test: FDTest
Message-ID: <5507D244.40509@oracle.com>

This RFR proposes to remove the duplicate FDTest from ?jdk? repo.

FDTest exists in both ?jdk? and ?langtools?:
http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/test/jdk/lambda/FDTest.java
http://hg.openjdk.java.net/jdk9/dev/langtools/file/tip/test/tools/javac/lambdaShapes/org/openjdk/tests/javac/FDTest.java

So far the only diff between the two tests is that the version in 
langtools has one more teardown method to well handle the resource close
 > @AfterSuite
 > static void teardown() throws IOException {
 > fm.close();
 > }

As this test is for JavaCompiler, it makes more sense to keep the test 
in "langtools" and remove the duplicate one from "jdk?.

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


Thanks,
Amy


From Alan.Bateman at oracle.com  Tue Mar 17 09:01:09 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 17 Mar 2015 09:01:09 +0000
Subject: RFR JDK-8074678: JCK test
	api/java_util/regex/MatchResult/index.html
	starts failing after JDK-8071479
In-Reply-To: <55075296.1020109@oracle.com>
References: <55075296.1020109@oracle.com>
Message-ID: <5507ED55.3010608@oracle.com>

On 16/03/2015 22:00, Xueming Shen wrote:
> Please help review the change for
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8074678
> webrev: http://cr.openjdk.java.net/~sherman/8074678
>
> The proposed fix is to implement the same "whether or not there
> is a match" sanity check in ImmutableMatchResult.
I think this looks good.

-Alan


From aph at redhat.com  Tue Mar 17 09:02:05 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 17 Mar 2015 09:02:05 +0000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <A4351E81-CACF-424D-B748-ECDFE7AD3CA6@oracle.com>
References: <550330CE.3030607@redhat.com> <55062674.9020407@oracle.com>
	<5506A28B.3070009@redhat.com>
	<A4351E81-CACF-424D-B748-ECDFE7AD3CA6@oracle.com>
Message-ID: <5507ED8D.4080807@redhat.com>

On 16/03/15 19:16, John Rose wrote:
> On Mar 16, 2015, at 2:29 AM, Andrew Haley <aph at redhat.com> wrote:>
>
> Since the option provides control for product behavior, without an explicit opt-in, it should either be a product flag or a diagnostic flag.
> 
> I suggest keeping the more direct name (Use* not Disable*) and making it a diagnostic flag.

OK.

Andrew.



From paul.sandoz at oracle.com  Tue Mar 17 09:18:46 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 17 Mar 2015 10:18:46 +0100
Subject: RFR JDK-8074678: JCK test
	api/java_util/regex/MatchResult/index.html starts failing after
	JDK-8071479
In-Reply-To: <55075296.1020109@oracle.com>
References: <55075296.1020109@oracle.com>
Message-ID: <9C765101-34AB-4117-AF1D-AB5681A63B19@oracle.com>


On Mar 16, 2015, at 11:00 PM, Xueming Shen <xueming.shen at oracle.com> wrote:

> Please help review the change for
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8074678
> webrev: http://cr.openjdk.java.net/~sherman/8074678
> 
> The proposed fix is to implement the same "whether or not there
> is a match" sanity check in ImmutableMatchResult.
> 

+1

Paul.


From chris.hegarty at oracle.com  Tue Mar 17 09:57:05 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 17 Mar 2015 09:57:05 +0000
Subject: RFR [9] 8071472: Add field access to support setting final fields
	in readObject
In-Reply-To: <BD34A2D5-38F3-45DA-BA32-330346D2A666@oracle.com>
References: <3F1CE33B-5C13-4172-A78B-72F476E0654E@oracle.com>
	<5501FBD0.4010109@oracle.com> <55021223.6060006@gmail.com>
	<55032534.1040408@gmail.com>
	<BD34A2D5-38F3-45DA-BA32-330346D2A666@oracle.com>
Message-ID: <C03300FB-F6E3-4B70-AC26-25846E6D1A91@oracle.com>

Peter, Alan,

After further thought I think that requiring all final fields to be set is reasonable behaviour. Since there is no compile time checking, this is a reasonable runtime effort to catch what is likely to be developer errors. To address Alan?s comments, I beefed up the API docs and added examples to typical usage.

Updated specdiff (and webrev):
   http://cr.openjdk.java.net/~chegar/8071472/01/ <http://cr.openjdk.java.net/~chegar/8071472/01/>

This version also includes a number of changes to readObject implementations in the base module, to replace unsafe usage with this field setter API.

-Chris.


> On 13 Mar 2015, at 19:36, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
>> 
>> On 13 Mar 2015, at 17:58, Peter Levart <peter.levart at gmail.com> wrote:
>> 
>> On 03/12/2015 11:24 PM, Peter Levart wrote:
>>>> So if a readObject calls fields() without calling defaultReadObject() then it has to set every final field. On one hand that ensures that every final field is set, on the other hand it is a bit odd because omitting the call to fields() means they all get their default value. 
>>> 
>>> If fields() is not called, we must be backwards-compatible.
>>> 
>>> But yes, this constraint is questionable. On one hand it tries to mimic the assignment to final fields in constructors, but it can't go all the way, as read access to final fields in readObject() is not limited to just those that have already been assigned (like it is in constructor with definitive assignment rules). We could add get() methods to FieldAccess that would constraint the reads of final fields to those that have already been assigned, but that is just like "advisory locking" - we can only advise users to use FieldAccess to read fields in readObject() but we can't prevent them from reading them directly.
>>> 
>>> So if this doesn't have much sense and brings confusion, it can go away.
>> 
>> ...or it can stay in part where we check that a final field is not set more than once, which can help especially when use of FieldAccess API is combined with defaultReadObject().
> 
> Yes, that makes sense.
> 
>> The final check that all finals have been assigned can be made optional by an explicit call to a method (FieldAccess.checkAllFinalsSet() for example).
> 
> If possible, I?d rather not have any additional methods exposed on FieldSetter, other than the overloaded sets. Let see how this works if we keep it as minimal as possible. I?m going to take a run over all readObjects in the base module that use unsafe or reflection, and rewrite to use this API.
> 
> -Chris.
> 
>> Regards, Peter



From paul.sandoz at oracle.com  Tue Mar 17 10:38:33 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 17 Mar 2015 11:38:33 +0100
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float,
	...} methods
In-Reply-To: <550710BD.5060301@redhat.com>
References: <550330CE.3030607@redhat.com>
	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>
	<550710BD.5060301@redhat.com>
Message-ID: <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>


On Mar 16, 2015, at 6:19 PM, Andrew Haley <aph at redhat.com> wrote:

> On 03/16/2015 10:03 AM, Paul Sandoz wrote:
>> I am running this patch though our JPRT test system right now.
>> 
>> The test looks good, two comments on it:
>> 
>> - IMO it does not need the internal PRNG FastRandom, SplittableRandom can be used instead.
>> 
>> - I suspect that test needs to be located in the hotspot test area, which likely means it gets run on more "exotic" platforms. Perhaps someone with more knowledge of the test configuration and infrastructure can comment?
> 
> I have a patch with all of the changes that people have asked for
> except this last one.  I don't know who to ask.
> 

Including Stefan, who may know more.

Paul.



From Alan.Bateman at oracle.com  Tue Mar 17 10:39:26 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 17 Mar 2015 10:39:26 +0000
Subject: RFR [9] 8071472: Add field access to support setting final fields
	in readObject
In-Reply-To: <C03300FB-F6E3-4B70-AC26-25846E6D1A91@oracle.com>
References: <3F1CE33B-5C13-4172-A78B-72F476E0654E@oracle.com>
	<5501FBD0.4010109@oracle.com> <55021223.6060006@gmail.com>
	<55032534.1040408@gmail.com>
	<BD34A2D5-38F3-45DA-BA32-330346D2A666@oracle.com>
	<C03300FB-F6E3-4B70-AC26-25846E6D1A91@oracle.com>
Message-ID: <5508045E.4070909@oracle.com>

On 17/03/2015 09:57, Chris Hegarty wrote:
> Peter, Alan,
>
> After further thought I think that requiring all final fields to be 
> set is reasonable behaviour. Since there is no compile time checking, 
> this is a reasonable runtime effort to catch what is likely to be 
> developer errors. To address Alan?s comments, I beefed up the API docs 
> and added examples to typical usage.
>
> Updated specdiff (and webrev):
> http://cr.openjdk.java.net/~chegar/8071472/01/ 
> <http://cr.openjdk.java.net/%7Echegar/8071472/01/>
>
> This version also includes a number of changes to readObject 
> implementations in the base module, to replace unsafe usage with this 
> field setter API.
>
>
The rename to FieldSetter looks good, also good to have an example in 
the javadoc.

It is good to catch cases where final fields aren't set but the issue is 
the surprising behavior that the check is tied to whether the 
FieldSetter has been obtained or not. The other thing is that 
fieldSetter's javadoc doesn't make this clear, you need to read 
FieldSetter's javadoc to learn about this enforcement. It's hard to know 
what the right thing to do here as ideally this enforcement would be 
enabled by default. If my class with final fields has an empty 
readObject, or it has code paths that don't call defaultReadObject for 
example, then it's a bug that I'd like to know about. I realize there is 
potential compatibility, maybe performance, impact of doing this but it 
does feel like something that I should be able to opt-in or get for free 
rather than it being a side effect.

One other thing that I wonder about is the exception and whether it 
might be better to bend InvalidObjectException instead.

-Alan


From lev.priima at oracle.com  Tue Mar 17 11:15:34 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Tue, 17 Mar 2015 14:15:34 +0300
Subject: RFR(XS): 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java
	heap space: MaxHeap shrinked by MaxRAMFraction
In-Reply-To: <5507B03B.5010606@oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>	<54DCDB2D.3090006@oracle.com>	<54DD5F6F.4070105@oracle.com>	<54DE0436.5070301@oracle.com>	<54E18636.4000600@oracle.com>	<54E1B170.1000801@oracle.com>	<54E1D28B.7030503@oracle.com>
	<54E28957.1070309@oracle.com>	<54E2D51B.8020808@oracle.com>
	<54E2E5F1.4070702@oracle.com>	<54E5D060.1080409@oracle.com>
	<54E5E3B9.80703@oracle.com>	<54E69B43.4000501@oracle.com>
	<54E704F2.1010201@oracle.com>	<54EA88A9.2080204@oracle.com>
	<54EC54FA.9020503@oracle.com>	<54EEC949.20704@oracle.com>
	<54EEFD16.5090009@oracle.com>	<54EF87C4.5000407@oracle.com>
	<54EF99E6.4030003@oracle.com>	<54EF9FB7.7030400@oracle.com>
	<55073D66.1080204@oracle.com> <5507B03B.5010606@oracle.com>
Message-ID: <55080CD6.4060108@oracle.com>

Hi David,

Explicit -Xmx does not allow explicit MaxRAMFraction to shrink 
MaxHeapSize down to -Xms(or even less down to default InitialHeapSize in 
case if -Xms also wasn't set explicitly). In other words explicit -Xmx 
has priority over explicit MaxRAMFraction if both are set and contradict 
with each other.

Lev

On 03/17/2015 07:40 AM, David Holmes wrote:
> Hi Lev,
>
> On 17/03/2015 6:30 AM, Lev Priima wrote:
>> Please reviewand push:
>>
>> Issue:https://bugs.openjdk.java.net/browse/JDK-8075071
>> Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/
>>
>> Tested locally:
>> jtreg -vmoptions:"-XX:MaxRAMFraction=9223372036854775807
>> -XX:-UseCompressedOops" test/java/util/Arrays/TimSortStackSize2.java
>> Test results: passed: 1
>
> How does MaxRAMFraction interact with -Xmx?
>
> Thanks,
> David
>
>> Lev
>>



From peter.levart at gmail.com  Tue Mar 17 11:52:09 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 17 Mar 2015 12:52:09 +0100
Subject: RFR [9] 8071472: Add field access to support setting final fields
	in readObject
In-Reply-To: <C03300FB-F6E3-4B70-AC26-25846E6D1A91@oracle.com>
References: <3F1CE33B-5C13-4172-A78B-72F476E0654E@oracle.com>
	<5501FBD0.4010109@oracle.com> <55021223.6060006@gmail.com>
	<55032534.1040408@gmail.com>
	<BD34A2D5-38F3-45DA-BA32-330346D2A666@oracle.com>
	<C03300FB-F6E3-4B70-AC26-25846E6D1A91@oracle.com>
Message-ID: <55081569.8090201@gmail.com>

On 03/17/2015 10:57 AM, Chris Hegarty wrote:
> Peter, Alan,
>
> After further thought I think that requiring all final fields to be set is reasonable behaviour. Since there is no compile time checking, this is a reasonable runtime effort to catch what is likely to be developer errors. To address Alan?s comments, I beefed up the API docs and added examples to typical usage.
>
> Updated specdiff (and webrev):
>     http://cr.openjdk.java.net/~chegar/8071472/01/ <http://cr.openjdk.java.net/~chegar/8071472/01/>
>
> This version also includes a number of changes to readObject implementations in the base module, to replace unsafe usage with this field setter API.

Hi Chris,

It's good that you included changes to some readObject() implementations 
in base module as these are the 1st real-world examples of API use. This 
way we can get some experience as to whether the API is adequate. This 
experience includes subtleties of assignment checking on finals. I think 
it would be desirable that if this API is included in JDK9, more 
migration from Unsafe to this API is gradually attempted before the API 
is frozen for JDK9.

As for the changes, I went through them and I think they are OK. Just 
one nit: private static FieldSetterContext.finalInstanceFieldCount() 
helper method could be moved to inside the FieldSetterContext.FieldsMap 
nested class as it is only used from it's constructor. This way you 
avoid generating synthetic access methods.

Also in ObjectInputStream.fieldSetter() javadoc, in the following statement:

Returns the |FieldSetter| instance associated with current object and 
type being deserialized, which gives write access to the *types* 
declared instance fields, including final, during the |readObject| callback.

I think it should be changed from: "types" -> "type's" (or class' for 
that matter as only classes can have instance fields).

Regards, Peter

>
> -Chris.
>
>
>> On 13 Mar 2015, at 19:36, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>
>>> On 13 Mar 2015, at 17:58, Peter Levart <peter.levart at gmail.com> wrote:
>>>
>>> On 03/12/2015 11:24 PM, Peter Levart wrote:
>>>>> So if a readObject calls fields() without calling defaultReadObject() then it has to set every final field. On one hand that ensures that every final field is set, on the other hand it is a bit odd because omitting the call to fields() means they all get their default value.
>>>> If fields() is not called, we must be backwards-compatible.
>>>>
>>>> But yes, this constraint is questionable. On one hand it tries to mimic the assignment to final fields in constructors, but it can't go all the way, as read access to final fields in readObject() is not limited to just those that have already been assigned (like it is in constructor with definitive assignment rules). We could add get() methods to FieldAccess that would constraint the reads of final fields to those that have already been assigned, but that is just like "advisory locking" - we can only advise users to use FieldAccess to read fields in readObject() but we can't prevent them from reading them directly.
>>>>
>>>> So if this doesn't have much sense and brings confusion, it can go away.
>>> ...or it can stay in part where we check that a final field is not set more than once, which can help especially when use of FieldAccess API is combined with defaultReadObject().
>> Yes, that makes sense.
>>
>>> The final check that all finals have been assigned can be made optional by an explicit call to a method (FieldAccess.checkAllFinalsSet() for example).
>> If possible, I?d rather not have any additional methods exposed on FieldSetter, other than the overloaded sets. Let see how this works if we keep it as minimal as possible. I?m going to take a run over all readObjects in the base module that use unsafe or reflection, and rewrite to use this API.
>>
>> -Chris.
>>
>>> Regards, Peter
>



From david.holmes at oracle.com  Tue Mar 17 11:56:56 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Mar 2015 21:56:56 +1000
Subject: RFR(XS): 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java
	heap space: MaxHeap shrinked by MaxRAMFraction
In-Reply-To: <55080CD6.4060108@oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>	<54DCDB2D.3090006@oracle.com>	<54DD5F6F.4070105@oracle.com>	<54DE0436.5070301@oracle.com>	<54E18636.4000600@oracle.com>	<54E1B170.1000801@oracle.com>	<54E1D28B.7030503@oracle.com>
	<54E28957.1070309@oracle.com>	<54E2D51B.8020808@oracle.com>
	<54E2E5F1.4070702@oracle.com>	<54E5D060.1080409@oracle.com>
	<54E5E3B9.80703@oracle.com>	<54E69B43.4000501@oracle.com>
	<54E704F2.1010201@oracle.com>	<54EA88A9.2080204@oracle.com>
	<54EC54FA.9020503@oracle.com>	<54EEC949.20704@oracle.com>
	<54EEFD16.5090009@oracle.com>	<54EF87C4.5000407@oracle.com>
	<54EF99E6.4030003@oracle.com>	<54EF9FB7.7030400@oracle.com>
	<55073D66.1080204@oracle.com> <5507B03B.5010606@oracle.com>
	<55080CD6.4060108@oracle.com>
Message-ID: <55081688.6070308@oracle.com>

On 17/03/2015 9:15 PM, Lev Priima wrote:
> Hi David,
>
> Explicit -Xmx does not allow explicit MaxRAMFraction to shrink
> MaxHeapSize down to -Xms(or even less down to default InitialHeapSize in
> case if -Xms also wasn't set explicitly). In other words explicit -Xmx
> has priority over explicit MaxRAMFraction if both are set and contradict
> with each other.

Okay - that's good to know.

However the -Xmx770m is a problem - our small devices only have 512MB of 
memory. Is the 770M only needed for 64-bit with -UseCompressedOops ?

Thanks,
David


> Lev
>
> On 03/17/2015 07:40 AM, David Holmes wrote:
>> Hi Lev,
>>
>> On 17/03/2015 6:30 AM, Lev Priima wrote:
>>> Please reviewand push:
>>>
>>> Issue:https://bugs.openjdk.java.net/browse/JDK-8075071
>>> Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/
>>>
>>> Tested locally:
>>> jtreg -vmoptions:"-XX:MaxRAMFraction=9223372036854775807
>>> -XX:-UseCompressedOops" test/java/util/Arrays/TimSortStackSize2.java
>>> Test results: passed: 1
>>
>> How does MaxRAMFraction interact with -Xmx?
>>
>> Thanks,
>> David
>>
>>> Lev
>>>
>


From lev.priima at oracle.com  Tue Mar 17 12:15:18 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Tue, 17 Mar 2015 15:15:18 +0300
Subject: RFR(XS): 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java
	heap space: MaxHeap shrinked by MaxRAMFraction
In-Reply-To: <55081688.6070308@oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>	<54DCDB2D.3090006@oracle.com>	<54DD5F6F.4070105@oracle.com>	<54DE0436.5070301@oracle.com>	<54E18636.4000600@oracle.com>	<54E1B170.1000801@oracle.com>	<54E1D28B.7030503@oracle.com>
	<54E28957.1070309@oracle.com>	<54E2D51B.8020808@oracle.com>
	<54E2E5F1.4070702@oracle.com>	<54E5D060.1080409@oracle.com>
	<54E5E3B9.80703@oracle.com>	<54E69B43.4000501@oracle.com>
	<54E704F2.1010201@oracle.com>	<54EA88A9.2080204@oracle.com>
	<54EC54FA.9020503@oracle.com>	<54EEC949.20704@oracle.com>
	<54EEFD16.5090009@oracle.com>	<54EF87C4.5000407@oracle.com>
	<54EF99E6.4030003@oracle.com>	<54EF9FB7.7030400@oracle.com>
	<55073D66.1080204@oracle.com> <5507B03B.5010606@oracle.com>
	<55080CD6.4060108@oracle.com> <55081688.6070308@oracle.com>
Message-ID: <55081AD6.6010108@oracle.com>

Yes.

Lev

On 03/17/2015 02:56 PM, David Holmes wrote:
> On 17/03/2015 9:15 PM, Lev Priima wrote:
>> Hi David,
>>
>> Explicit -Xmx does not allow explicit MaxRAMFraction to shrink
>> MaxHeapSize down to -Xms(or even less down to default InitialHeapSize in
>> case if -Xms also wasn't set explicitly). In other words explicit -Xmx
>> has priority over explicit MaxRAMFraction if both are set and contradict
>> with each other.
>
> Okay - that's good to know.
>
> However the -Xmx770m is a problem - our small devices only have 512MB 
> of memory. Is the 770M only needed for 64-bit with -UseCompressedOops ?
>
> Thanks,
> David
>
>
>> Lev
>>
>> On 03/17/2015 07:40 AM, David Holmes wrote:
>>> Hi Lev,
>>>
>>> On 17/03/2015 6:30 AM, Lev Priima wrote:
>>>> Please reviewand push:
>>>>
>>>> Issue:https://bugs.openjdk.java.net/browse/JDK-8075071
>>>> Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/
>>>>
>>>> Tested locally:
>>>> jtreg -vmoptions:"-XX:MaxRAMFraction=9223372036854775807
>>>> -XX:-UseCompressedOops" test/java/util/Arrays/TimSortStackSize2.java
>>>> Test results: passed: 1
>>>
>>> How does MaxRAMFraction interact with -Xmx?
>>>
>>> Thanks,
>>> David
>>>
>>>> Lev
>>>>
>>



From peter.levart at gmail.com  Tue Mar 17 12:21:46 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 17 Mar 2015 13:21:46 +0100
Subject: RFR [9] 8071472: Add field access to support setting final fields
	in readObject
In-Reply-To: <5508045E.4070909@oracle.com>
References: <3F1CE33B-5C13-4172-A78B-72F476E0654E@oracle.com>
	<5501FBD0.4010109@oracle.com> <55021223.6060006@gmail.com>
	<55032534.1040408@gmail.com>
	<BD34A2D5-38F3-45DA-BA32-330346D2A666@oracle.com>
	<C03300FB-F6E3-4B70-AC26-25846E6D1A91@oracle.com>
	<5508045E.4070909@oracle.com>
Message-ID: <55081C5A.5090009@gmail.com>

On 03/17/2015 11:39 AM, Alan Bateman wrote:
> On 17/03/2015 09:57, Chris Hegarty wrote:
>> Peter, Alan,
>>
>> After further thought I think that requiring all final fields to be 
>> set is reasonable behaviour. Since there is no compile time checking, 
>> this is a reasonable runtime effort to catch what is likely to be 
>> developer errors. To address Alan?s comments, I beefed up the API 
>> docs and added examples to typical usage.
>>
>> Updated specdiff (and webrev):
>> http://cr.openjdk.java.net/~chegar/8071472/01/ 
>> <http://cr.openjdk.java.net/%7Echegar/8071472/01/>
>>
>> This version also includes a number of changes to readObject 
>> implementations in the base module, to replace unsafe usage with this 
>> field setter API.
>>
>>
> The rename to FieldSetter looks good, also good to have an example in 
> the javadoc.
>
> It is good to catch cases where final fields aren't set but the issue 
> is the surprising behavior that the check is tied to whether the 
> FieldSetter has been obtained or not. The other thing is that 
> fieldSetter's javadoc doesn't make this clear, you need to read 
> FieldSetter's javadoc to learn about this enforcement. It's hard to 
> know what the right thing to do here as ideally this enforcement would 
> be enabled by default. If my class with final fields has an empty 
> readObject, or it has code paths that don't call defaultReadObject for 
> example, then it's a bug that I'd like to know about. I realize there 
> is potential compatibility, maybe performance, impact of doing this 
> but it does feel like something that I should be able to opt-in or get 
> for free rather than it being a side effect.

Hi Alan,

I agree that not calling defaultReadObject() from readObject() and 
having a final field is potentially a bug. But need not be in case some 
other means of setting final fields was used (Unsafe or reflection). 
Some readObject() implementations in base module that Chris changed to 
use new API fall into this category. We can't track those usages, so to 
keep backwards compatibility, this checking has to be opt-in. Is there a 
more elegant way to opt-in? A @CheckFinalsAssignment annotation on the 
readObject() method?

Regards,

Peter

>
> One other thing that I wonder about is the exception and whether it 
> might be better to bend InvalidObjectException instead.
>
> -Alan
>



From david.holmes at oracle.com  Tue Mar 17 12:23:27 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Mar 2015 22:23:27 +1000
Subject: RFR(XS): 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java
	heap space: MaxHeap shrinked by MaxRAMFraction
In-Reply-To: <55081AD6.6010108@oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>	<54DCDB2D.3090006@oracle.com>	<54DD5F6F.4070105@oracle.com>	<54DE0436.5070301@oracle.com>	<54E18636.4000600@oracle.com>	<54E1B170.1000801@oracle.com>	<54E1D28B.7030503@oracle.com>
	<54E28957.1070309@oracle.com>	<54E2D51B.8020808@oracle.com>
	<54E2E5F1.4070702@oracle.com>	<54E5D060.1080409@oracle.com>
	<54E5E3B9.80703@oracle.com>	<54E69B43.4000501@oracle.com>
	<54E704F2.1010201@oracle.com>	<54EA88A9.2080204@oracle.com>
	<54EC54FA.9020503@oracle.com>	<54EEC949.20704@oracle.com>
	<54EEFD16.5090009@oracle.com>	<54EF87C4.5000407@oracle.com>
	<54EF99E6.4030003@oracle.com>	<54EF9FB7.7030400@oracle.com>
	<55073D66.1080204@oracle.com> <5507B03B.5010606@oracle.com>
	<55080CD6.4060108@oracle.com> <55081688.6070308@oracle.com>
	<55081AD6.6010108@oracle.com>
Message-ID: <55081CBF.7000107@oracle.com>

So this is a problem that needs to be resolved. The memory requirements 
of the test are platform dependent but can't be satisfied on all 
platforms. Though I am surprised that 770M is needed given that two 
incarnations ago we set -Xmx to 385M!

But it is appearing to be impossible to run this test in a way that can 
work on all platforms.

David

On 17/03/2015 10:15 PM, Lev Priima wrote:
> Yes.
>
> Lev
>
> On 03/17/2015 02:56 PM, David Holmes wrote:
>> On 17/03/2015 9:15 PM, Lev Priima wrote:
>>> Hi David,
>>>
>>> Explicit -Xmx does not allow explicit MaxRAMFraction to shrink
>>> MaxHeapSize down to -Xms(or even less down to default InitialHeapSize in
>>> case if -Xms also wasn't set explicitly). In other words explicit -Xmx
>>> has priority over explicit MaxRAMFraction if both are set and contradict
>>> with each other.
>>
>> Okay - that's good to know.
>>
>> However the -Xmx770m is a problem - our small devices only have 512MB
>> of memory. Is the 770M only needed for 64-bit with -UseCompressedOops ?
>>
>> Thanks,
>> David
>>
>>
>>> Lev
>>>
>>> On 03/17/2015 07:40 AM, David Holmes wrote:
>>>> Hi Lev,
>>>>
>>>> On 17/03/2015 6:30 AM, Lev Priima wrote:
>>>>> Please reviewand push:
>>>>>
>>>>> Issue:https://bugs.openjdk.java.net/browse/JDK-8075071
>>>>> Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/
>>>>>
>>>>> Tested locally:
>>>>> jtreg -vmoptions:"-XX:MaxRAMFraction=9223372036854775807
>>>>> -XX:-UseCompressedOops" test/java/util/Arrays/TimSortStackSize2.java
>>>>> Test results: passed: 1
>>>>
>>>> How does MaxRAMFraction interact with -Xmx?
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Lev
>>>>>
>>>
>


From Alan.Bateman at oracle.com  Tue Mar 17 13:42:23 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 17 Mar 2015 13:42:23 +0000
Subject: RFR [9] 8071472: Add field access to support setting final fields
	in readObject
In-Reply-To: <55081C5A.5090009@gmail.com>
References: <3F1CE33B-5C13-4172-A78B-72F476E0654E@oracle.com>
	<5501FBD0.4010109@oracle.com> <55021223.6060006@gmail.com>
	<55032534.1040408@gmail.com>
	<BD34A2D5-38F3-45DA-BA32-330346D2A666@oracle.com>
	<C03300FB-F6E3-4B70-AC26-25846E6D1A91@oracle.com>
	<5508045E.4070909@oracle.com> <55081C5A.5090009@gmail.com>
Message-ID: <55082F3F.0@oracle.com>

On 17/03/2015 12:21, Peter Levart wrote:
>
> Hi Alan,
>
> I agree that not calling defaultReadObject() from readObject() and 
> having a final field is potentially a bug. But need not be in case 
> some other means of setting final fields was used (Unsafe or 
> reflection). Some readObject() implementations in base module that 
> Chris changed to use new API fall into this category. We can't track 
> those usages, so to keep backwards compatibility, this checking has to 
> be opt-in. Is there a more elegant way to opt-in? A 
> @CheckFinalsAssignment annotation on the readObject() method?
I'm not sure that an annotation is right here. Instead then it might 
work as a method on FieldSetter to enable strict checking.

-Alan


From aph at redhat.com  Tue Mar 17 13:55:40 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 17 Mar 2015 13:55:40 +0000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>
	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>
Message-ID: <5508325C.4000108@redhat.com>

On 03/17/2015 10:38 AM, Paul Sandoz wrote:
> 
> On Mar 16, 2015, at 6:19 PM, Andrew Haley <aph at redhat.com> wrote:
> 
>> On 03/16/2015 10:03 AM, Paul Sandoz wrote:
>>> I am running this patch though our JPRT test system right now.
>>>
>>> The test looks good, two comments on it:
>>>
>>> - IMO it does not need the internal PRNG FastRandom, SplittableRandom can be used instead.
>>>
>>> - I suspect that test needs to be located in the hotspot test area, which likely means it gets run on more "exotic" platforms. Perhaps someone with more knowledge of the test configuration and infrastructure can comment?
>>
>> I have a patch with all of the changes that people have asked for
>> except this last one.  I don't know who to ask.
> 
> Including Stefan, who may know more.

Righto.  I will post a new webrev once we decide.

Thanks,
Andrew.




From brian.burkhalter at oracle.com  Tue Mar 17 19:15:59 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 17 Mar 2015 12:15:59 -0700
Subject: [9] RFR of 8075362: j.u.Properties.load() methods have misaligned
	@throws clauses
Message-ID: <F285743C-E8C9-498E-8D47-C8F7E49DD37C@oracle.com>

Follow-on to correct some insufficiencies pointed out in

http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032289.html

Please review at your convenience.

Issue:	https://bugs.openjdk.java.net/browse/JDK-8075362
Diff: 		See below (Properties.java change did not show up in webrev).

Thanks,

Brian

diff --git a/src/java.base/share/classes/java/util/Properties.java b/src/java.base/share/classes/java/util/Properties.java
--- a/src/java.base/share/classes/java/util/Properties.java
+++ b/src/java.base/share/classes/java/util/Properties.java
@@ -309,7 +309,7 @@
      *          input stream.
      * @throws  IllegalArgumentException if a malformed Unicode escape
      *          appears in the input.
-     * @throws NullPointerException if {@code reader} is null.
+     * @throws  NullPointerException if {@code reader} is null.
      * @since   1.6
      */
     public synchronized void load(Reader reader) throws IOException {
@@ -335,7 +335,7 @@
      *             input stream.
      * @throws     IllegalArgumentException if the input stream contains a
      *             malformed Unicode escape sequence.
-     * @throws NullPointerException if {@code inStream} is null.
+     * @throws     NullPointerException if {@code inStream} is null.
      * @since 1.2
      */
     public synchronized void load(InputStream inStream) throws IOException {

diff --git a/test/java/util/Properties/Basic.java b/test/java/util/Properties/LoadAndStoreNPE.java
rename from test/java/util/Properties/Basic.java
rename to test/java/util/Properties/LoadAndStoreNPE.java

--- a/test/java/util/Properties/Basic.java
+++ b/test/java/util/Properties/LoadAndStoreNPE.java
@@ -28,10 +28,10 @@
 
 /*
  * @test
- * @bug 8073214
- * @summary Basic tests of Properties methods.
+ * @bug 8073214 8075362
+ * @summary Tests to verify that load() and store() throw NPEs as advertised.
  */
-public class Basic
+public class LoadAndStoreNPE
 {
     public static void main(String[] args) throws Exception
     {
@@ -68,7 +68,7 @@
         }
 
         if (failures != 0) {
-            throw new RuntimeException("Basic failed with "
+            throw new RuntimeException("LoadAndStoreNPE failed with "
                 + failures + " errors!");
         }
     }



From lev.priima at oracle.com  Tue Mar 17 23:07:25 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Wed, 18 Mar 2015 02:07:25 +0300
Subject: RFR(XS): 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java
	heap space: MaxHeap shrinked by MaxRAMFraction
In-Reply-To: <55081CBF.7000107@oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>	<54DCDB2D.3090006@oracle.com>	<54DD5F6F.4070105@oracle.com>	<54DE0436.5070301@oracle.com>	<54E18636.4000600@oracle.com>	<54E1B170.1000801@oracle.com>	<54E1D28B.7030503@oracle.com>
	<54E28957.1070309@oracle.com>	<54E2D51B.8020808@oracle.com>
	<54E2E5F1.4070702@oracle.com>	<54E5D060.1080409@oracle.com>
	<54E5E3B9.80703@oracle.com>	<54E69B43.4000501@oracle.com>
	<54E704F2.1010201@oracle.com>	<54EA88A9.2080204@oracle.com>
	<54EC54FA.9020503@oracle.com>	<54EEC949.20704@oracle.com>
	<54EEFD16.5090009@oracle.com>	<54EF87C4.5000407@oracle.com>
	<54EF99E6.4030003@oracle.com>	<54EF9FB7.7030400@oracle.com>
	<55073D66.1080204@oracle.com> <5507B03B.5010606@oracle.com>
	<55080CD6.4060108@oracle.com> <55081688.6070308@oracle.com>
	<55081AD6.6010108@oracle.com> <55081CBF.7000107@oracle.com>
Message-ID: <5508B3AD.7030700@oracle.com>

Possible, by determining of disabled UseCompressedOops option and 
forking vm again with required minimum heap value(-Xms).
Please review update: http://cr.openjdk.java.net/~lpriima/8075071/1/webrev/

Lev

On 03/17/2015 03:23 PM, David Holmes wrote:
> So this is a problem that needs to be resolved. The memory 
> requirements of the test are platform dependent but can't be satisfied 
> on all platforms. Though I am surprised that 770M is needed given that 
> two incarnations ago we set -Xmx to 385M!
>
> But it is appearing to be impossible to run this test in a way that 
> can work on all platforms.
>
> David
>
> On 17/03/2015 10:15 PM, Lev Priima wrote:
>> Yes.
>>
>> Lev
>>
>> On 03/17/2015 02:56 PM, David Holmes wrote:
>>> On 17/03/2015 9:15 PM, Lev Priima wrote:
>>>> Hi David,
>>>>
>>>> Explicit -Xmx does not allow explicit MaxRAMFraction to shrink
>>>> MaxHeapSize down to -Xms(or even less down to default 
>>>> InitialHeapSize in
>>>> case if -Xms also wasn't set explicitly). In other words explicit -Xmx
>>>> has priority over explicit MaxRAMFraction if both are set and 
>>>> contradict
>>>> with each other.
>>>
>>> Okay - that's good to know.
>>>
>>> However the -Xmx770m is a problem - our small devices only have 512MB
>>> of memory. Is the 770M only needed for 64-bit with -UseCompressedOops ?
>>>
>>> Thanks,
>>> David
>>>
>>>
>>>> Lev
>>>>
>>>> On 03/17/2015 07:40 AM, David Holmes wrote:
>>>>> Hi Lev,
>>>>>
>>>>> On 17/03/2015 6:30 AM, Lev Priima wrote:
>>>>>> Please reviewand push:
>>>>>>
>>>>>> Issue:https://bugs.openjdk.java.net/browse/JDK-8075071
>>>>>> Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/
>>>>>>
>>>>>> Tested locally:
>>>>>> jtreg -vmoptions:"-XX:MaxRAMFraction=9223372036854775807
>>>>>> -XX:-UseCompressedOops" test/java/util/Arrays/TimSortStackSize2.java
>>>>>> Test results: passed: 1
>>>>>
>>>>> How does MaxRAMFraction interact with -Xmx?
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Lev
>>>>>>
>>>>
>>



From david.holmes at oracle.com  Wed Mar 18 01:46:10 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Mar 2015 11:46:10 +1000
Subject: RFR(XS): 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java
	heap space: MaxHeap shrinked by MaxRAMFraction
In-Reply-To: <5508B3AD.7030700@oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>	<54DCDB2D.3090006@oracle.com>	<54DD5F6F.4070105@oracle.com>	<54DE0436.5070301@oracle.com>	<54E18636.4000600@oracle.com>	<54E1B170.1000801@oracle.com>	<54E1D28B.7030503@oracle.com>
	<54E28957.1070309@oracle.com>	<54E2D51B.8020808@oracle.com>
	<54E2E5F1.4070702@oracle.com>	<54E5D060.1080409@oracle.com>
	<54E5E3B9.80703@oracle.com>	<54E69B43.4000501@oracle.com>
	<54E704F2.1010201@oracle.com>	<54EA88A9.2080204@oracle.com>
	<54EC54FA.9020503@oracle.com>	<54EEC949.20704@oracle.com>
	<54EEFD16.5090009@oracle.com>	<54EF87C4.5000407@oracle.com>
	<54EF99E6.4030003@oracle.com>	<54EF9FB7.7030400@oracle.com>
	<55073D66.1080204@oracle.com> <5507B03B.5010606@oracle.com>
	<55080CD6.4060108@oracle.com> <55081688.6070308@oracle.com>
	<55081AD6.6010108@oracle.com> <55081CBF.7000107@oracle.com>
	<5508B3AD.7030700@oracle.com>
Message-ID: <5508D8E2.7020106@oracle.com>

Hi Lev,

On 18/03/2015 9:07 AM, Lev Priima wrote:
> Possible, by determining of disabled UseCompressedOops option and
> forking vm again with required minimum heap value(-Xms).
> Please review update: http://cr.openjdk.java.net/~lpriima/8075071/1/webrev/

Yes that is the approach that is needed. But didn't you need to set Xmx 
not Xms to deal with the MaxRAMFraction problem?

Thanks,
David

> Lev
>
> On 03/17/2015 03:23 PM, David Holmes wrote:
>> So this is a problem that needs to be resolved. The memory
>> requirements of the test are platform dependent but can't be satisfied
>> on all platforms. Though I am surprised that 770M is needed given that
>> two incarnations ago we set -Xmx to 385M!
>>
>> But it is appearing to be impossible to run this test in a way that
>> can work on all platforms.
>>
>> David
>>
>> On 17/03/2015 10:15 PM, Lev Priima wrote:
>>> Yes.
>>>
>>> Lev
>>>
>>> On 03/17/2015 02:56 PM, David Holmes wrote:
>>>> On 17/03/2015 9:15 PM, Lev Priima wrote:
>>>>> Hi David,
>>>>>
>>>>> Explicit -Xmx does not allow explicit MaxRAMFraction to shrink
>>>>> MaxHeapSize down to -Xms(or even less down to default
>>>>> InitialHeapSize in
>>>>> case if -Xms also wasn't set explicitly). In other words explicit -Xmx
>>>>> has priority over explicit MaxRAMFraction if both are set and
>>>>> contradict
>>>>> with each other.
>>>>
>>>> Okay - that's good to know.
>>>>
>>>> However the -Xmx770m is a problem - our small devices only have 512MB
>>>> of memory. Is the 770M only needed for 64-bit with -UseCompressedOops ?
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>
>>>>> Lev
>>>>>
>>>>> On 03/17/2015 07:40 AM, David Holmes wrote:
>>>>>> Hi Lev,
>>>>>>
>>>>>> On 17/03/2015 6:30 AM, Lev Priima wrote:
>>>>>>> Please reviewand push:
>>>>>>>
>>>>>>> Issue:https://bugs.openjdk.java.net/browse/JDK-8075071
>>>>>>> Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/
>>>>>>>
>>>>>>> Tested locally:
>>>>>>> jtreg -vmoptions:"-XX:MaxRAMFraction=9223372036854775807
>>>>>>> -XX:-UseCompressedOops" test/java/util/Arrays/TimSortStackSize2.java
>>>>>>> Test results: passed: 1
>>>>>>
>>>>>> How does MaxRAMFraction interact with -Xmx?
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Lev
>>>>>>>
>>>>>
>>>
>


From lev.priima at oracle.com  Wed Mar 18 08:12:48 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Wed, 18 Mar 2015 11:12:48 +0300
Subject: RFR(XS): 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java
	heap space: MaxHeap shrinked by MaxRAMFraction
In-Reply-To: <5508D8E2.7020106@oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>	<54DCDB2D.3090006@oracle.com>	<54DD5F6F.4070105@oracle.com>	<54DE0436.5070301@oracle.com>	<54E18636.4000600@oracle.com>	<54E1B170.1000801@oracle.com>	<54E1D28B.7030503@oracle.com>
	<54E28957.1070309@oracle.com>	<54E2D51B.8020808@oracle.com>
	<54E2E5F1.4070702@oracle.com>	<54E5D060.1080409@oracle.com>
	<54E5E3B9.80703@oracle.com>	<54E69B43.4000501@oracle.com>
	<54E704F2.1010201@oracle.com>	<54EA88A9.2080204@oracle.com>
	<54EC54FA.9020503@oracle.com>	<54EEC949.20704@oracle.com>
	<54EEFD16.5090009@oracle.com>	<54EF87C4.5000407@oracle.com>
	<54EF99E6.4030003@oracle.com>	<54EF9FB7.7030400@oracle.com>
	<55073D66.1080204@oracle.com> <5507B03B.5010606@oracle.com>
	<55080CD6.4060108@oracle.com> <55081688.6070308@oracle.com>
	<55081AD6.6010108@oracle.com> <55081CBF.7000107@oracle.com>
	<5508B3AD.7030700@oracle.com> <5508D8E2.7020106@oracle.com>
Message-ID: <55093380.2000605@oracle.com>

On 03/18/2015 04:46 AM, David Holmes wrote:
> Hi Lev,
>
> On 18/03/2015 9:07 AM, Lev Priima wrote:
>> Possible, by determining of disabled UseCompressedOops option and
>> forking vm again with required minimum heap value(-Xms).
>> Please review update: 
>> http://cr.openjdk.java.net/~lpriima/8075071/1/webrev/
>
> Yes that is the approach that is needed. But didn't you need to set 
> Xmx not Xms to deal with the MaxRAMFraction problem?
No. As I wrote before "-Xms" has priority over MaxRAMFraction: 
MaxRAMFraction can't shrink MaxHeapSize less than specified by -Xms:

java -Xms385m -XX:+PrintFlagsFinal 
-XX:MaxRAMFraction=9223372036854775807  -version | grep MaxHeapSize
     uintx MaxHeapSize                              := 
404750336                           {product}

java -Xms770m -XX:+PrintFlagsFinal 
-XX:MaxRAMFraction=9223372036854775807  -version | grep MaxHeapSize
     uintx MaxHeapSize                              := 
807403520                           {product}

>
> Thanks,
> David
>
>> Lev
>>
>> On 03/17/2015 03:23 PM, David Holmes wrote:
>>> So this is a problem that needs to be resolved. The memory
>>> requirements of the test are platform dependent but can't be satisfied
>>> on all platforms. Though I am surprised that 770M is needed given that
>>> two incarnations ago we set -Xmx to 385M!
>>>
>>> But it is appearing to be impossible to run this test in a way that
>>> can work on all platforms.
>>>
>>> David
>>>
>>> On 17/03/2015 10:15 PM, Lev Priima wrote:
>>>> Yes.
>>>>
>>>> Lev
>>>>
>>>> On 03/17/2015 02:56 PM, David Holmes wrote:
>>>>> On 17/03/2015 9:15 PM, Lev Priima wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> Explicit -Xmx does not allow explicit MaxRAMFraction to shrink
>>>>>> MaxHeapSize down to -Xms(or even less down to default
>>>>>> InitialHeapSize in
>>>>>> case if -Xms also wasn't set explicitly). In other words explicit 
>>>>>> -Xmx
>>>>>> has priority over explicit MaxRAMFraction if both are set and
>>>>>> contradict
>>>>>> with each other.
>>>>>
>>>>> Okay - that's good to know.
>>>>>
>>>>> However the -Xmx770m is a problem - our small devices only have 512MB
>>>>> of memory. Is the 770M only needed for 64-bit with 
>>>>> -UseCompressedOops ?
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>
>>>>>> Lev
>>>>>>
>>>>>> On 03/17/2015 07:40 AM, David Holmes wrote:
>>>>>>> Hi Lev,
>>>>>>>
>>>>>>> On 17/03/2015 6:30 AM, Lev Priima wrote:
>>>>>>>> Please reviewand push:
>>>>>>>>
>>>>>>>> Issue:https://bugs.openjdk.java.net/browse/JDK-8075071
>>>>>>>> Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/
>>>>>>>>
>>>>>>>> Tested locally:
>>>>>>>> jtreg -vmoptions:"-XX:MaxRAMFraction=9223372036854775807
>>>>>>>> -XX:-UseCompressedOops" 
>>>>>>>> test/java/util/Arrays/TimSortStackSize2.java
>>>>>>>> Test results: passed: 1
>>>>>>>
>>>>>>> How does MaxRAMFraction interact with -Xmx?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>> Lev
>>>>>>>>
>>>>>>
>>>>
>>



From david.holmes at oracle.com  Wed Mar 18 10:52:50 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Mar 2015 20:52:50 +1000
Subject: RFR(XS): 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java
	heap space: MaxHeap shrinked by MaxRAMFraction
In-Reply-To: <55093380.2000605@oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>	<54DCDB2D.3090006@oracle.com>	<54DD5F6F.4070105@oracle.com>	<54DE0436.5070301@oracle.com>	<54E18636.4000600@oracle.com>	<54E1B170.1000801@oracle.com>	<54E1D28B.7030503@oracle.com>
	<54E28957.1070309@oracle.com>	<54E2D51B.8020808@oracle.com>
	<54E2E5F1.4070702@oracle.com>	<54E5D060.1080409@oracle.com>
	<54E5E3B9.80703@oracle.com>	<54E69B43.4000501@oracle.com>
	<54E704F2.1010201@oracle.com>	<54EA88A9.2080204@oracle.com>
	<54EC54FA.9020503@oracle.com>	<54EEC949.20704@oracle.com>
	<54EEFD16.5090009@oracle.com>	<54EF87C4.5000407@oracle.com>
	<54EF99E6.4030003@oracle.com>	<54EF9FB7.7030400@oracle.com>
	<55073D66.1080204@oracle.com> <5507B03B.5010606@oracle.com>
	<55080CD6.4060108@oracle.com> <55081688.6070308@oracle.com>
	<55081AD6.6010108@oracle.com> <55081CBF.7000107@oracle.com>
	<5508B3AD.7030700@oracle.com> <5508D8E2.7020106@oracle.com>
	<55093380.2000605@oracle.com>
Message-ID: <55095902.1040407@oracle.com>

On 18/03/2015 6:12 PM, Lev Priima wrote:
> On 03/18/2015 04:46 AM, David Holmes wrote:
>> Hi Lev,
>>
>> On 18/03/2015 9:07 AM, Lev Priima wrote:
>>> Possible, by determining of disabled UseCompressedOops option and
>>> forking vm again with required minimum heap value(-Xms).
>>> Please review update:
>>> http://cr.openjdk.java.net/~lpriima/8075071/1/webrev/
>>
>> Yes that is the approach that is needed. But didn't you need to set
>> Xmx not Xms to deal with the MaxRAMFraction problem?
> No. As I wrote before "-Xms" has priority over MaxRAMFraction:

No what you wrote before was that -Xmx has priority. Your original patch 
set -Xmx in addition to the existing -Xms:

!  * @run main/othervm -Xms385m -Xmx770m TimSortStackSize2 67108864

David
-----

> MaxRAMFraction can't shrink MaxHeapSize less than specified by -Xms:
>
> java -Xms385m -XX:+PrintFlagsFinal
> -XX:MaxRAMFraction=9223372036854775807  -version | grep MaxHeapSize
>      uintx MaxHeapSize                              :=
> 404750336                           {product}
>
> java -Xms770m -XX:+PrintFlagsFinal
> -XX:MaxRAMFraction=9223372036854775807  -version | grep MaxHeapSize
>      uintx MaxHeapSize                              :=
> 807403520                           {product}
>
>>
>> Thanks,
>> David
>>
>>> Lev
>>>
>>> On 03/17/2015 03:23 PM, David Holmes wrote:
>>>> So this is a problem that needs to be resolved. The memory
>>>> requirements of the test are platform dependent but can't be satisfied
>>>> on all platforms. Though I am surprised that 770M is needed given that
>>>> two incarnations ago we set -Xmx to 385M!
>>>>
>>>> But it is appearing to be impossible to run this test in a way that
>>>> can work on all platforms.
>>>>
>>>> David
>>>>
>>>> On 17/03/2015 10:15 PM, Lev Priima wrote:
>>>>> Yes.
>>>>>
>>>>> Lev
>>>>>
>>>>> On 03/17/2015 02:56 PM, David Holmes wrote:
>>>>>> On 17/03/2015 9:15 PM, Lev Priima wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> Explicit -Xmx does not allow explicit MaxRAMFraction to shrink
>>>>>>> MaxHeapSize down to -Xms(or even less down to default
>>>>>>> InitialHeapSize in
>>>>>>> case if -Xms also wasn't set explicitly). In other words explicit
>>>>>>> -Xmx
>>>>>>> has priority over explicit MaxRAMFraction if both are set and
>>>>>>> contradict
>>>>>>> with each other.
>>>>>>
>>>>>> Okay - that's good to know.
>>>>>>
>>>>>> However the -Xmx770m is a problem - our small devices only have 512MB
>>>>>> of memory. Is the 770M only needed for 64-bit with
>>>>>> -UseCompressedOops ?
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>
>>>>>>> Lev
>>>>>>>
>>>>>>> On 03/17/2015 07:40 AM, David Holmes wrote:
>>>>>>>> Hi Lev,
>>>>>>>>
>>>>>>>> On 17/03/2015 6:30 AM, Lev Priima wrote:
>>>>>>>>> Please reviewand push:
>>>>>>>>>
>>>>>>>>> Issue:https://bugs.openjdk.java.net/browse/JDK-8075071
>>>>>>>>> Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/
>>>>>>>>>
>>>>>>>>> Tested locally:
>>>>>>>>> jtreg -vmoptions:"-XX:MaxRAMFraction=9223372036854775807
>>>>>>>>> -XX:-UseCompressedOops"
>>>>>>>>> test/java/util/Arrays/TimSortStackSize2.java
>>>>>>>>> Test results: passed: 1
>>>>>>>>
>>>>>>>> How does MaxRAMFraction interact with -Xmx?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Lev
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>


From chris.hegarty at oracle.com  Wed Mar 18 11:06:56 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 18 Mar 2015 11:06:56 +0000
Subject: RFR [9] 8071472: Add field access to support setting final fields
	in readObject
In-Reply-To: <55082F3F.0@oracle.com>
References: <3F1CE33B-5C13-4172-A78B-72F476E0654E@oracle.com>
	<5501FBD0.4010109@oracle.com> <55021223.6060006@gmail.com>
	<55032534.1040408@gmail.com>
	<BD34A2D5-38F3-45DA-BA32-330346D2A666@oracle.com>
	<C03300FB-F6E3-4B70-AC26-25846E6D1A91@oracle.com>
	<5508045E.4070909@oracle.com> <55081C5A.5090009@gmail.com>
	<55082F3F.0@oracle.com>
Message-ID: <55095C50.3010605@oracle.com>

On 17/03/15 13:42, Alan Bateman wrote:
> On 17/03/2015 12:21, Peter Levart wrote:
>>
>> Hi Alan,
>>
>> I agree that not calling defaultReadObject() from readObject() and
>> having a final field is potentially a bug. But need not be in case
>> some other means of setting final fields was used (Unsafe or
>> reflection). Some readObject() implementations in base module that
>> Chris changed to use new API fall into this category. We can't track
>> those usages, so to keep backwards compatibility, this checking has to
>> be opt-in. Is there a more elegant way to opt-in? A
>> @CheckFinalsAssignment annotation on the readObject() method?
> I'm not sure that an annotation is right here. Instead then it might
> work as a method on FieldSetter to enable strict checking.

Peter suggested a method on FieldSetter to enable strict checking before 
too, and at the time I pushed back. After this discussion, I've come 
full circle, and maybe this opt-in style method is a reasonable 
compromise. Something like:

  /**
   * Checks that all final instance fields, declared by the class where
   * the {@code readObject} callback is being invoked, have been set.
   *
   * <p> This method is intended to be called as a final step after all
   * final instance fields have been set.
   *
   * @throws InvalidObjectException if one, or more, final instance
   *         fields have not been set
   */
  void checkAllFinalsSet() throws InvalidObjectException;


...and the user code would look similar to this, from java.io.File:

   s.fieldSetter().set("path", p)
                  .set("prefixLength", pLen)
                  .checkAllFinalsSet();

-Chris.




From chris.hegarty at oracle.com  Wed Mar 18 11:16:03 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 18 Mar 2015 11:16:03 +0000
Subject: RFR [9] 8071472: Add field access to support setting final fields
	in readObject
In-Reply-To: <55081569.8090201@gmail.com>
References: <3F1CE33B-5C13-4172-A78B-72F476E0654E@oracle.com>
	<5501FBD0.4010109@oracle.com> <55021223.6060006@gmail.com>
	<55032534.1040408@gmail.com>
	<BD34A2D5-38F3-45DA-BA32-330346D2A666@oracle.com>
	<C03300FB-F6E3-4B70-AC26-25846E6D1A91@oracle.com>
	<55081569.8090201@gmail.com>
Message-ID: <55095E73.2010904@oracle.com>

On 17/03/15 11:52, Peter Levart wrote:
> On 03/17/2015 10:57 AM, Chris Hegarty wrote:
>> Peter, Alan,
>>
>> After further thought I think that requiring all final fields to be set is reasonable behaviour. Since there is no compile time checking, this is a reasonable runtime effort to catch what is likely to be developer errors. To address Alan?s comments, I beefed up the API docs and added examples to typical usage.
>>
>> Updated specdiff (and webrev):
>>     http://cr.openjdk.java.net/~chegar/8071472/01/  <http://cr.openjdk.java.net/~chegar/8071472/01/>
>>
>> This version also includes a number of changes to readObject implementations in the base module, to replace unsafe usage with this field setter API.
>
> Hi Chris,
>
> It's good that you included changes to some readObject() implementations
> in base module as these are the 1st real-world examples of API use. This
> way we can get some experience as to whether the API is adequate. This
> experience includes subtleties of assignment checking on finals. I think
> it would be desirable that if this API is included in JDK9, more
> migration from Unsafe to this API is gradually attempted before the API
> is frozen for JDK9.

I think we are mainly in agreement with regard to the level of the API. 
As with all new API's, the more bake time in the release the better. If 
we accept the general approach, then further tweaks can be done before 9 
ships.

I plan to file bugs against specific component areas, or by module, to 
remove unsafe usage and replace it with this API. There should be enough 
time to do this in 9, and the experience from doing so can feedback into 
the API, if needed.

> As for the changes, I went through them and I think they are OK. Just
> one nit: private static FieldSetterContext.finalInstanceFieldCount()
> helper method could be moved to inside the FieldSetterContext.FieldsMap
> nested class as it is only used from it's constructor. This way you
> avoid generating synthetic access methods.

Thanks, done.

> Also in ObjectInputStream.fieldSetter() javadoc, in the following statement:
>
> Returns the |FieldSetter| instance associated with current object and
> type being deserialized, which gives write access to the *types*
> declared instance fields, including final, during the |readObject| callback.

Fixed.

> I think it should be changed from: "types" -> "type's" (or class' for
> that matter as only classes can have instance fields).
>
> Regards, Peter

-Chris.


From lev.priima at oracle.com  Wed Mar 18 11:46:17 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Wed, 18 Mar 2015 14:46:17 +0300
Subject: RFR(XS): 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java
	heap space: MaxHeap shrinked by MaxRAMFraction
In-Reply-To: <55095902.1040407@oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>	<54DCDB2D.3090006@oracle.com>	<54DD5F6F.4070105@oracle.com>	<54DE0436.5070301@oracle.com>	<54E18636.4000600@oracle.com>	<54E1B170.1000801@oracle.com>	<54E1D28B.7030503@oracle.com>
	<54E28957.1070309@oracle.com>	<54E2D51B.8020808@oracle.com>
	<54E2E5F1.4070702@oracle.com>	<54E5D060.1080409@oracle.com>
	<54E5E3B9.80703@oracle.com>	<54E69B43.4000501@oracle.com>
	<54E704F2.1010201@oracle.com>	<54EA88A9.2080204@oracle.com>
	<54EC54FA.9020503@oracle.com>	<54EEC949.20704@oracle.com>
	<54EEFD16.5090009@oracle.com>	<54EF87C4.5000407@oracle.com>
	<54EF99E6.4030003@oracle.com>	<54EF9FB7.7030400@oracle.com>
	<55073D66.1080204@oracle.com> <5507B03B.5010606@oracle.com>
	<55080CD6.4060108@oracle.com> <55081688.6070308@oracle.com>
	<55081AD6.6010108@oracle.com> <55081CBF.7000107@oracle.com>
	<5508B3AD.7030700@oracle.com> <5508D8E2.7020106@oracle.com>
	<55093380.2000605@oracle.com> <55095902.1040407@oracle.com>
Message-ID: <55096589.2090104@oracle.com>

On 03/18/2015 01:52 PM, David Holmes wrote:
> On 18/03/2015 6:12 PM, Lev Priima wrote:
>> On 03/18/2015 04:46 AM, David Holmes wrote:
>>> Hi Lev,
>>>
>>> On 18/03/2015 9:07 AM, Lev Priima wrote:
>>>> Possible, by determining of disabled UseCompressedOops option and
>>>> forking vm again with required minimum heap value(-Xms).
>>>> Please review update:
>>>> http://cr.openjdk.java.net/~lpriima/8075071/1/webrev/
>>>
>>> Yes that is the approach that is needed. But didn't you need to set
>>> Xmx not Xms to deal with the MaxRAMFraction problem?
>> No. As I wrote before "-Xms" has priority over MaxRAMFraction:
>
> No what you wrote before was that -Xmx has priority. Your original 
> patch set -Xmx in addition to the existing -Xms:
>
> !  * @run main/othervm -Xms385m -Xmx770m TimSortStackSize2 67108864
Yes this fix will also work. Both -Xms -Xmx have priority over 
MaxRAMFraction. MaxRAMFraction can't shrink MaxHeapSize less than either 
-Xms or -Xmx.

Explicit value of -Xmx770m with program which actually required and 
allocate less memory(385m) is not a problem on machine with 512m until 
we don't switch -XX:+UseG1GC.
That's why I had have agreed with declining this fix .

New fix will work with either -Xms or -Xms in this line:
!             final String xmsValue = "-Xms" + (WhiteBox.getWhiteBox()

-Xms makes tests more robust if jdk footprint will increase a little. 
-Xmx will be better if we also want to catch possible jdk footprint 
regression by this test.

Lev
>
> David
> -----
>
>> MaxRAMFraction can't shrink MaxHeapSize less than specified by -Xms:
>>
>> java -Xms385m -XX:+PrintFlagsFinal
>> -XX:MaxRAMFraction=9223372036854775807  -version | grep MaxHeapSize
>>      uintx MaxHeapSize                              :=
>> 404750336                           {product}
>>
>> java -Xms770m -XX:+PrintFlagsFinal
>> -XX:MaxRAMFraction=9223372036854775807  -version | grep MaxHeapSize
>>      uintx MaxHeapSize                              :=
>> 807403520                           {product}
>>
>>>
>>> Thanks,
>>> David
>>>
>>>> Lev
>>>>
>>>> On 03/17/2015 03:23 PM, David Holmes wrote:
>>>>> So this is a problem that needs to be resolved. The memory
>>>>> requirements of the test are platform dependent but can't be 
>>>>> satisfied
>>>>> on all platforms. Though I am surprised that 770M is needed given 
>>>>> that
>>>>> two incarnations ago we set -Xmx to 385M!
>>>>>
>>>>> But it is appearing to be impossible to run this test in a way that
>>>>> can work on all platforms.
>>>>>
>>>>> David
>>>>>
>>>>> On 17/03/2015 10:15 PM, Lev Priima wrote:
>>>>>> Yes.
>>>>>>
>>>>>> Lev
>>>>>>
>>>>>> On 03/17/2015 02:56 PM, David Holmes wrote:
>>>>>>> On 17/03/2015 9:15 PM, Lev Priima wrote:
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> Explicit -Xmx does not allow explicit MaxRAMFraction to shrink
>>>>>>>> MaxHeapSize down to -Xms(or even less down to default
>>>>>>>> InitialHeapSize in
>>>>>>>> case if -Xms also wasn't set explicitly). In other words explicit
>>>>>>>> -Xmx
>>>>>>>> has priority over explicit MaxRAMFraction if both are set and
>>>>>>>> contradict
>>>>>>>> with each other.
>>>>>>>
>>>>>>> Okay - that's good to know.
>>>>>>>
>>>>>>> However the -Xmx770m is a problem - our small devices only have 
>>>>>>> 512MB
>>>>>>> of memory. Is the 770M only needed for 64-bit with
>>>>>>> -UseCompressedOops ?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>
>>>>>>>> Lev
>>>>>>>>
>>>>>>>> On 03/17/2015 07:40 AM, David Holmes wrote:
>>>>>>>>> Hi Lev,
>>>>>>>>>
>>>>>>>>> On 17/03/2015 6:30 AM, Lev Priima wrote:
>>>>>>>>>> Please reviewand push:
>>>>>>>>>>
>>>>>>>>>> Issue:https://bugs.openjdk.java.net/browse/JDK-8075071
>>>>>>>>>> Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/
>>>>>>>>>>
>>>>>>>>>> Tested locally:
>>>>>>>>>> jtreg -vmoptions:"-XX:MaxRAMFraction=9223372036854775807
>>>>>>>>>> -XX:-UseCompressedOops"
>>>>>>>>>> test/java/util/Arrays/TimSortStackSize2.java
>>>>>>>>>> Test results: passed: 1
>>>>>>>>>
>>>>>>>>> How does MaxRAMFraction interact with -Xmx?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> Lev
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>



From david.holmes at oracle.com  Wed Mar 18 12:25:00 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Mar 2015 22:25:00 +1000
Subject: RFR(XS): 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java
	heap space: MaxHeap shrinked by MaxRAMFraction
In-Reply-To: <55096589.2090104@oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>	<54DCDB2D.3090006@oracle.com>	<54DD5F6F.4070105@oracle.com>	<54DE0436.5070301@oracle.com>	<54E18636.4000600@oracle.com>	<54E1B170.1000801@oracle.com>	<54E1D28B.7030503@oracle.com>
	<54E28957.1070309@oracle.com>	<54E2D51B.8020808@oracle.com>
	<54E2E5F1.4070702@oracle.com>	<54E5D060.1080409@oracle.com>
	<54E5E3B9.80703@oracle.com>	<54E69B43.4000501@oracle.com>
	<54E704F2.1010201@oracle.com>	<54EA88A9.2080204@oracle.com>
	<54EC54FA.9020503@oracle.com>	<54EEC949.20704@oracle.com>
	<54EEFD16.5090009@oracle.com>	<54EF87C4.5000407@oracle.com>
	<54EF99E6.4030003@oracle.com>	<54EF9FB7.7030400@oracle.com>
	<55073D66.1080204@oracle.com> <5507B03B.5010606@oracle.com>
	<55080CD6.4060108@oracle.com> <55081688.6070308@oracle.com>
	<55081AD6.6010108@oracle.com> <55081CBF.7000107@oracle.com>
	<5508B3AD.7030700@oracle.com> <5508D8E2.7020106@oracle.com>
	<55093380.2000605@oracle.com> <55095902.1040407@oracle.com>
	<55096589.2090104@oracle.com>
Message-ID: <55096E9C.90509@oracle.com>

On 18/03/2015 9:46 PM, Lev Priima wrote:
> On 03/18/2015 01:52 PM, David Holmes wrote:
>> On 18/03/2015 6:12 PM, Lev Priima wrote:
>>> On 03/18/2015 04:46 AM, David Holmes wrote:
>>>> Hi Lev,
>>>>
>>>> On 18/03/2015 9:07 AM, Lev Priima wrote:
>>>>> Possible, by determining of disabled UseCompressedOops option and
>>>>> forking vm again with required minimum heap value(-Xms).
>>>>> Please review update:
>>>>> http://cr.openjdk.java.net/~lpriima/8075071/1/webrev/
>>>>
>>>> Yes that is the approach that is needed. But didn't you need to set
>>>> Xmx not Xms to deal with the MaxRAMFraction problem?
>>> No. As I wrote before "-Xms" has priority over MaxRAMFraction:
>>
>> No what you wrote before was that -Xmx has priority. Your original
>> patch set -Xmx in addition to the existing -Xms:
>>
>> !  * @run main/othervm -Xms385m -Xmx770m TimSortStackSize2 67108864
> Yes this fix will also work. Both -Xms -Xmx have priority over
> MaxRAMFraction. MaxRAMFraction can't shrink MaxHeapSize less than either
> -Xms or -Xmx.

Let me see if I have this straight. With -Xms385M ergonomics will select 
a maximum heap size, and that size is adequate to run the test without 
additional flags. However if MaxRAMFraction is specified then that 
maximum heap size gets reduced and the test then fails on 64-bit when 
compressed oops are disabled. The original version of the fix set 
-Xmx770M in addition to -Xms385M and that stops the affect of 
MaxRAMFraction, and so the test passes (but seemingly using G1 can 
change that?). Alternatively we can just set -Xms770M, but that won't 
work for systems with less memory, so the current fix simply selects the 
-Xms value based on whether or not we're using compressed oops, and 
launches a new VM using that value.

Okay got it.

> Explicit value of -Xmx770m with program which actually required and
> allocate less memory(385m) is not a problem on machine with 512m until
> we don't switch -XX:+UseG1GC.
> That's why I had have agreed with declining this fix .

I originally said the -Xmx770 would be a problem for a machine with 
512MB, but as you note it won't be a problem unless > 512MB is actually 
needed - in which case there is nothing we can do. So my objection was 
unfounded - sorry for the confusion on that.

> New fix will work with either -Xms or -Xms in this line:
> !             final String xmsValue = "-Xms" + (WhiteBox.getWhiteBox()
>
> -Xms makes tests more robust if jdk footprint will increase a little.
> -Xmx will be better if we also want to catch possible jdk footprint
> regression by this test.

Okay. As long as it works on all platforms with all options. :)

Thanks,
David

> Lev
>>
>> David
>> -----
>>
>>> MaxRAMFraction can't shrink MaxHeapSize less than specified by -Xms:
>>>
>>> java -Xms385m -XX:+PrintFlagsFinal
>>> -XX:MaxRAMFraction=9223372036854775807  -version | grep MaxHeapSize
>>>      uintx MaxHeapSize                              :=
>>> 404750336                           {product}
>>>
>>> java -Xms770m -XX:+PrintFlagsFinal
>>> -XX:MaxRAMFraction=9223372036854775807  -version | grep MaxHeapSize
>>>      uintx MaxHeapSize                              :=
>>> 807403520                           {product}
>>>
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Lev
>>>>>
>>>>> On 03/17/2015 03:23 PM, David Holmes wrote:
>>>>>> So this is a problem that needs to be resolved. The memory
>>>>>> requirements of the test are platform dependent but can't be
>>>>>> satisfied
>>>>>> on all platforms. Though I am surprised that 770M is needed given
>>>>>> that
>>>>>> two incarnations ago we set -Xmx to 385M!
>>>>>>
>>>>>> But it is appearing to be impossible to run this test in a way that
>>>>>> can work on all platforms.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 17/03/2015 10:15 PM, Lev Priima wrote:
>>>>>>> Yes.
>>>>>>>
>>>>>>> Lev
>>>>>>>
>>>>>>> On 03/17/2015 02:56 PM, David Holmes wrote:
>>>>>>>> On 17/03/2015 9:15 PM, Lev Priima wrote:
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>> Explicit -Xmx does not allow explicit MaxRAMFraction to shrink
>>>>>>>>> MaxHeapSize down to -Xms(or even less down to default
>>>>>>>>> InitialHeapSize in
>>>>>>>>> case if -Xms also wasn't set explicitly). In other words explicit
>>>>>>>>> -Xmx
>>>>>>>>> has priority over explicit MaxRAMFraction if both are set and
>>>>>>>>> contradict
>>>>>>>>> with each other.
>>>>>>>>
>>>>>>>> Okay - that's good to know.
>>>>>>>>
>>>>>>>> However the -Xmx770m is a problem - our small devices only have
>>>>>>>> 512MB
>>>>>>>> of memory. Is the 770M only needed for 64-bit with
>>>>>>>> -UseCompressedOops ?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>
>>>>>>>>> Lev
>>>>>>>>>
>>>>>>>>> On 03/17/2015 07:40 AM, David Holmes wrote:
>>>>>>>>>> Hi Lev,
>>>>>>>>>>
>>>>>>>>>> On 17/03/2015 6:30 AM, Lev Priima wrote:
>>>>>>>>>>> Please reviewand push:
>>>>>>>>>>>
>>>>>>>>>>> Issue:https://bugs.openjdk.java.net/browse/JDK-8075071
>>>>>>>>>>> Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/
>>>>>>>>>>>
>>>>>>>>>>> Tested locally:
>>>>>>>>>>> jtreg -vmoptions:"-XX:MaxRAMFraction=9223372036854775807
>>>>>>>>>>> -XX:-UseCompressedOops"
>>>>>>>>>>> test/java/util/Arrays/TimSortStackSize2.java
>>>>>>>>>>> Test results: passed: 1
>>>>>>>>>>
>>>>>>>>>> How does MaxRAMFraction interact with -Xmx?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>> Lev
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>


From mikhail.cherkasov at oracle.com  Wed Mar 18 12:59:37 2015
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Wed, 18 Mar 2015 15:59:37 +0300
Subject: [8] RFR of 8066985: Java Webstart downloading packed files can result
	in Timezone set to UTC
Message-ID: <550976B9.6030503@oracle.com>

Hi all,

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

The problem is that packer/unpacker changes global state( default time 
zone ) without proper synchronization:
http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/com/sun/java/util/jar/pack/PackerImpl.java#l85 


however javadoc says that it's save to use it in concurrent way if each 
thread has it's own packer/unpacker instance:
http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/java/util/jar/Pack200.java#l149 


The fix is:
1. first packer/unpacker saves default time zone
2. the last set it back.

Webrev:
http://cr.openjdk.java.net/~mcherkas/8066985/webrev.00/

Thanks,
Mikhail.







From jason_mehrens at hotmail.com  Wed Mar 18 13:56:46 2015
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Wed, 18 Mar 2015 08:56:46 -0500
Subject: LogManager.readConfiguration doesn't document IAE and NPE.
Message-ID: <BLU175-W173C8D7A6A1C4FBA9FF71F83000@phx.gbl>

Daniel,

It occurred to me after reading Brian's patch for https://bugs.openjdk.java.net/browse/JDK-8075362  that the LogManager.readConfiguration methods do not document NPE or IAE that can be triggered by Properties.load.  Do we need to file a bug just against logging or should larger bug be filed to check all of the JDK code that is calling Properies.load?


Jason 		 	   		  

From paul.sandoz at oracle.com  Wed Mar 18 14:09:05 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 18 Mar 2015 15:09:05 +0100
Subject: RFR 8075307 Pipeline calculating inconsistent flag state for parallel
	stateful ops 
Message-ID: <9BFBFA94-A170-420A-814C-C66262F3E157@oracle.com>

Hi,

The fix for https://bugs.openjdk.java.net/browse/JDK-8067969 (optimized Stream.count()) caused a regression in the JCK tests.

A test exposed a known weakness in the way pipeline flags are prepared for parallel execution. In certain cases the pipeline may report SIZED but the source spliterator does not report the SIZE characteristic. This is because the preparation always assumed that stateful operations are a full barrier and thus inject SIZE. This is not always the case when a stateful operation is "lazy" and can wrap the source spliterator and operations.
  
For example:

  List<Integer> list = Arrays.asList(1, 2, 3);
  Stream<Integer> s = list.stream().parallel().unordered().distinct();
  long count = s.count();
  System.out.println(count);

The stateful distinct op can wrap source spliterator of the list since we don't care about order, but as a result the size of the distinct->count pipeline slice is unknown.

While i could fix the counting functionality to check for the inconsistency the right thing to do is fix the preparation of flags (a particularly sensitive area to get right) by merging that into the sourceSpliterator method (as suggested in the comments):

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8075307-stream-parallel-prepare-flags/webrev/

This also makes things marginally more efficient when there are no stateful operations. There is no need to do any work if there are no stateful ops (i needed to relax tests in UnorderedTest which were overly aggressive when there were no stateful ops present, similarly i relaxed a test in DisctinctOps that is no longer generally applicable).

Furthermore, as a consequence the terminal counting reduce ops now declare they don't care about encounter order [*], which avoid the distinct becoming a full barrier that reduces elements to a linked hash set.
 
A JPRT test run reported no relevant failures and local execution of relevant JCK tests pass.

Paul.

[*] Note that a count can also be performed with:

  LongAdder l = new LongAdder();
  Stream<T> s = ...
  s.parallel().forEach(e -> l.increment());
  long count = l.sum();

Which is a possible alternative implementation to that of reduction, but i prefer to stick with the latter for now.


From daniel.fuchs at oracle.com  Wed Mar 18 15:16:27 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 18 Mar 2015 16:16:27 +0100
Subject: LogManager.readConfiguration doesn't document IAE and NPE.
In-Reply-To: <BLU175-W173C8D7A6A1C4FBA9FF71F83000@phx.gbl>
References: <BLU175-W173C8D7A6A1C4FBA9FF71F83000@phx.gbl>
Message-ID: <550996CB.1050102@oracle.com>

On 18/03/15 14:56, Jason Mehrens wrote:
> Daniel,
>
> It occurred to me after reading Brian's patch for https://bugs.openjdk.java.net/browse/JDK-8075362  that the LogManager.readConfiguration methods do not document NPE or IAE that can be triggered by Properties.load.  Do we need to file a bug just against logging or should larger bug be filed to check all of the JDK code that is calling Properies.load?

Hi Jason,

Thanks for the heads-up!

java.util.logging has a blanket statement concerning NPE, stating that
NPE will be thrown when parameters are null, unless null is explicitly
permitted.

I am not sure that we need to document every unchecked exception
that might happen down the road. That could end up with pretty
cluttered and obscure exception clauses.

That said the case where IAE is thrown seems straightforward, so
we might consider to add it to readConfiguration. Not sure whether
that would require a CCC or not.

Do others on this list have a strong opinion on this subject?

best regards,

-- daniel

>
>
> Jason 		 	   		
>



From Roger.Riggs at Oracle.com  Wed Mar 18 17:03:32 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 18 Mar 2015 13:03:32 -0400
Subject: LogManager.readConfiguration doesn't document IAE and NPE.
In-Reply-To: <550996CB.1050102@oracle.com>
References: <BLU175-W173C8D7A6A1C4FBA9FF71F83000@phx.gbl>
	<550996CB.1050102@oracle.com>
Message-ID: <5509AFE4.8040501@Oracle.com>

Hi,

I think its up to loadConfiguration to handle (and specify) exceptions 
in methods that it calls.
IAE is not your ordinary RuntimeException.
IAE in calling Properties.load is an issue for loadConfiguration to 
handle; seems like it should
be turned into IOException in this case because it is because of a 
malformed properties file.

(I think IAE in Properties.load isn't the best choice of exception; 
though I can see how
it can identify the argument (InputStream) is at fault;  I'd have stuck 
to IOException)

$.02, Roger


On 3/18/2015 11:16 AM, Daniel Fuchs wrote:
> On 18/03/15 14:56, Jason Mehrens wrote:
>> Daniel,
>>
>> It occurred to me after reading Brian's patch for 
>> https://bugs.openjdk.java.net/browse/JDK-8075362  that the 
>> LogManager.readConfiguration methods do not document NPE or IAE that 
>> can be triggered by Properties.load.  Do we need to file a bug just 
>> against logging or should larger bug be filed to check all of the JDK 
>> code that is calling Properies.load?
>
> Hi Jason,
>
> Thanks for the heads-up!
>
> java.util.logging has a blanket statement concerning NPE, stating that
> NPE will be thrown when parameters are null, unless null is explicitly
> permitted.
>
> I am not sure that we need to document every unchecked exception
> that might happen down the road. That could end up with pretty
> cluttered and obscure exception clauses.
>
> That said the case where IAE is thrown seems straightforward, so
> we might consider to add it to readConfiguration. Not sure whether
> that would require a CCC or not.
>
> Do others on this list have a strong opinion on this subject?
>
> best regards,
>
> -- daniel
>
>>
>>
>> Jason
>>
>



From daniel.fuchs at oracle.com  Wed Mar 18 17:15:23 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 18 Mar 2015 18:15:23 +0100
Subject: LogManager.readConfiguration doesn't document IAE and NPE.
In-Reply-To: <5509AFE4.8040501@Oracle.com>
References: <BLU175-W173C8D7A6A1C4FBA9FF71F83000@phx.gbl>	<550996CB.1050102@oracle.com>
	<5509AFE4.8040501@Oracle.com>
Message-ID: <5509B2AB.8060908@oracle.com>

On 18/03/15 18:03, Roger Riggs wrote:
> Hi,
>
> I think its up to loadConfiguration to handle (and specify) exceptions
> in methods that it calls.
> IAE is not your ordinary RuntimeException.
> IAE in calling Properties.load is an issue for loadConfiguration to
> handle; seems like it should
> be turned into IOException in this case because it is because of a
> malformed properties file.

Right. I was wondering about that too. Well if we catch it and
wrap it in IOException then it conforms to the current spec but
it will be a behavior change and so we still might need a CCC.

-- daniel

> (I think IAE in Properties.load isn't the best choice of exception;
> though I can see how
> it can identify the argument (InputStream) is at fault;  I'd have stuck
> to IOException)
>
> $.02, Roger
>
>
> On 3/18/2015 11:16 AM, Daniel Fuchs wrote:
>> On 18/03/15 14:56, Jason Mehrens wrote:
>>> Daniel,
>>>
>>> It occurred to me after reading Brian's patch for
>>> https://bugs.openjdk.java.net/browse/JDK-8075362  that the
>>> LogManager.readConfiguration methods do not document NPE or IAE that
>>> can be triggered by Properties.load.  Do we need to file a bug just
>>> against logging or should larger bug be filed to check all of the JDK
>>> code that is calling Properies.load?
>>
>> Hi Jason,
>>
>> Thanks for the heads-up!
>>
>> java.util.logging has a blanket statement concerning NPE, stating that
>> NPE will be thrown when parameters are null, unless null is explicitly
>> permitted.
>>
>> I am not sure that we need to document every unchecked exception
>> that might happen down the road. That could end up with pretty
>> cluttered and obscure exception clauses.
>>
>> That said the case where IAE is thrown seems straightforward, so
>> we might consider to add it to readConfiguration. Not sure whether
>> that would require a CCC or not.
>>
>> Do others on this list have a strong opinion on this subject?
>>
>> best regards,
>>
>> -- daniel
>>
>>>
>>>
>>> Jason
>>>
>>
>



From brent.christian at oracle.com  Wed Mar 18 17:46:41 2015
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 18 Mar 2015 10:46:41 -0700
Subject: RFR 8071667 : HashMap.computeIfAbsent() adds entry that HashMap.get()
	does not find.
Message-ID: <5509BA01.6000709@oracle.com>

Hi,

Please review my changes for 8071667 : "HashMap.computeIfAbsent() adds 
entry that HashMap.get() does not find"

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

Webrev+specdiff:
http://cr.openjdk.java.net/~bchristi/8071667/webrev.2/


The fix is to detect structural changes made by the mapping functions 
passed to compute() and friends, and to throw a 
ConcurrentModificationException.  This prevents possibly adding entries 
in the wrong hash bin.

I have updated the docs based on the prior discussion [1], making use of 
the new @implSpec/etc tags, as seemed sensible to me.  Suggestions welcome.


Automated test run is clean.  If the new docs look good, I'll start a CCC.

Thanks,
-Brent

1. 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031245.html



From Alan.Bateman at oracle.com  Wed Mar 18 19:05:03 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 18 Mar 2015 19:05:03 +0000
Subject: RFR [9] 8071472: Add field access to support setting final fields
	in readObject
In-Reply-To: <55095C50.3010605@oracle.com>
References: <3F1CE33B-5C13-4172-A78B-72F476E0654E@oracle.com>
	<5501FBD0.4010109@oracle.com> <55021223.6060006@gmail.com>
	<55032534.1040408@gmail.com>
	<BD34A2D5-38F3-45DA-BA32-330346D2A666@oracle.com>
	<C03300FB-F6E3-4B70-AC26-25846E6D1A91@oracle.com>
	<5508045E.4070909@oracle.com> <55081C5A.5090009@gmail.com>
	<55082F3F.0@oracle.com> <55095C50.3010605@oracle.com>
Message-ID: <5509CC5F.3050101@oracle.com>

On 18/03/2015 11:06, Chris Hegarty wrote:
> :
>
>  /**
>   * Checks that all final instance fields, declared by the class where
>   * the {@code readObject} callback is being invoked, have been set.
>   *
>   * <p> This method is intended to be called as a final step after all
>   * final instance fields have been set.
>   *
>   * @throws InvalidObjectException if one, or more, final instance
>   *         fields have not been set
>   */
>  void checkAllFinalsSet() throws InvalidObjectException;
>
>
> ...and the user code would look similar to this, from java.io.File:
>
>   s.fieldSetter().set("path", p)
>                  .set("prefixLength", pLen)
>                  .checkAllFinalsSet();
I think this is a lot clearer as it makes it explicit and in addition it 
is less confusing to have the InvalidObjectException thrown here rather 
than somewhere in the deserialization code.

-Alan


From kumar.x.srinivasan at oracle.com  Wed Mar 18 22:07:56 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 18 Mar 2015 15:07:56 -0700
Subject: [8] RFR of 8066985: Java Webstart downloading packed files can
	result in Timezone set to UTC
In-Reply-To: <550976B9.6030503@oracle.com>
References: <550976B9.6030503@oracle.com>
Message-ID: <5509F73C.6000306@oracle.com>


Hello Mikhail,

> Hi all,
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8066985
>
> The problem is that packer/unpacker changes global state( default time 
> zone ) without proper synchronization:
> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/com/sun/java/util/jar/pack/PackerImpl.java#l85 
>
>
> however javadoc says that it's save to use it in concurrent way if 
> each thread has it's own packer/unpacker instance:
> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/java/util/jar/Pack200.java#l149 
>
>
> The fix is:
> 1. first packer/unpacker saves default time zone
> 2. the last set it back.
>
> Webrev:
> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.00/

The above link is wrong!, it takes me to webrev for 8073187,
which has only the PackerImpl changes.

I am guessing the link should be:
http://cr.openjdk.java.net/~mcherkas/8066985/webrev.00/

Kumar

>
> Thanks,
> Mikhail.
>
>
>
>
>



From brian.burkhalter at oracle.com  Wed Mar 18 22:16:27 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 18 Mar 2015 15:16:27 -0700
Subject: [9] RFR of 8074937: ServerSocket.accept() API Descriptions should
	include past tense
Message-ID: <D479B0BA-0D5F-48BF-BB45-A460A7AB0385@oracle.com>

Please review at your convenience. This a doc-only change.

Issue:	https://bugs.openjdk.java.net/browse/JDK-8074937
Patch:	http://cr.openjdk.java.net/~bpb/8074937/webrev.00/

This is in effect an amplification of extant javadoc suggested as an enhancement by an external user. I performed some testing to verify the accuracy of the suggested documentation change prior to crafting the verbiage, and the criticism does seem to be well-founded in the behavior of the APIs in question.

It would be good however if someone with a more profound knowledge of this area were to review the proposed documentation update for accuracy, especially as it is not unlikely that there might be platform-specific behavior with which these statements conflict.

Thanks,

Brian

From mikael.vidstedt at oracle.com  Wed Mar 18 23:18:31 2015
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Wed, 18 Mar 2015 16:18:31 -0700
Subject: [9] RFR 8074839: Resolve disabled warnings for libunpack and the
	unpack200 binary
Message-ID: <550A07C7.1090608@oracle.com>


Please review the following change which fixes a number of native 
compilation warnings in the jdk.pack200 code.

Bug: https://bugs.openjdk.java.net/browse/JDK-8074839
Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8074839/webrev.03/webrev/

Testing: A slightly earlier version [1] has been through a build & test 
cycle on all the OracleJDK platforms, running the core_tools jtreg tests 
as well as a number of other jtreg tests and java applications. There 
were no warnings on any of the platforms (in the files related to this 
change). I will rerun the testing, but since the differences from the 
earlier version are very small I'd like some reviews first.

Note that the warnings were temporarily disabled as part of JDK-8074096 
[2] until such time they could be fixed the proper way. Also note that 
this change supersedes the earlier change [3] Dmitry had out for review. 
The bug [4] corresponding to that webrev will be closed as a duplicate 
of this bug (JDK-8074839).

Cheers,
Mikael

[1] http://cr.openjdk.java.net/~mikael/webrevs/8074839/webrev.02/webrev
[2] https://bugs.openjdk.java.net/browse/JDK-8074096
[3] http://cr.openjdk.java.net/~dsamersoff/JDK-8073584/webrev.01/
[4] https://bugs.openjdk.java.net/browse/JDK-8073584



From david.holmes at oracle.com  Thu Mar 19 01:50:11 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 19 Mar 2015 11:50:11 +1000
Subject: [9] RFR 8074839: Resolve disabled warnings for libunpack and
	the unpack200 binary
In-Reply-To: <550A07C7.1090608@oracle.com>
References: <550A07C7.1090608@oracle.com>
Message-ID: <550A2B53.4080202@oracle.com>

Hi Mikael,

This all looks okay to me.

Thanks,
David

On 19/03/2015 9:18 AM, Mikael Vidstedt wrote:
>
> Please review the following change which fixes a number of native
> compilation warnings in the jdk.pack200 code.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074839
> Webrev:
> http://cr.openjdk.java.net/~mikael/webrevs/8074839/webrev.03/webrev/
>
> Testing: A slightly earlier version [1] has been through a build & test
> cycle on all the OracleJDK platforms, running the core_tools jtreg tests
> as well as a number of other jtreg tests and java applications. There
> were no warnings on any of the platforms (in the files related to this
> change). I will rerun the testing, but since the differences from the
> earlier version are very small I'd like some reviews first.
>
> Note that the warnings were temporarily disabled as part of JDK-8074096
> [2] until such time they could be fixed the proper way. Also note that
> this change supersedes the earlier change [3] Dmitry had out for review.
> The bug [4] corresponding to that webrev will be closed as a duplicate
> of this bug (JDK-8074839).
>
> Cheers,
> Mikael
>
> [1] http://cr.openjdk.java.net/~mikael/webrevs/8074839/webrev.02/webrev
> [2] https://bugs.openjdk.java.net/browse/JDK-8074096
> [3] http://cr.openjdk.java.net/~dsamersoff/JDK-8073584/webrev.01/
> [4] https://bugs.openjdk.java.net/browse/JDK-8073584
>


From aph at redhat.com  Thu Mar 19 09:03:10 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 19 Mar 2015 09:03:10 +0000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <5508325C.4000108@redhat.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>
	<5508325C.4000108@redhat.com>
Message-ID: <550A90CE.9080901@redhat.com>

People, please.

I have been working on this for weeks.  All I am waiting on now
is a decision about where the test case should go.  Can I have a
decision so we can get this in?

Thanks,
Andrew.



From paul.sandoz at oracle.com  Thu Mar 19 10:09:30 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 19 Mar 2015 11:09:30 +0100
Subject: RFR 8071667 : HashMap.computeIfAbsent() adds entry that
	HashMap.get() does not find.
In-Reply-To: <5509BA01.6000709@oracle.com>
References: <5509BA01.6000709@oracle.com>
Message-ID: <684AF3A3-4280-47B3-AA8D-64248C5DDA9A@oracle.com>

Hi Brent,

The implementation looks good.

Documentation-wise i think it needs some adjustment:

- the @apiNote should be promoted to "normal" documentation as we want to make a stronger statement.

- I think the @implNote on Map should be merged into the @implSpec. How about:

  <p>The default implementation makes no guarantees about detecting if the mapping function modifies 
  this map during computation and, if appropriate, reporting an error.
  Non-concurrent implementations should override this method and, on a best-effort basis, throw a 
  {@code ConcurrentModificationException} if it is detected that the mapping function modifies this 
  map during computation.
  Concurrent implementations should override this method and, on a best-effort basis, throw a
  {@code IllegalStateException} if it is detected that the mapping function modifies this map
  during computation and as a result computation would never complete.

?

- the @implSpec on HashMap etc. should be promoted to "normal" documentation:

  <p>This method will, on a best-effort basis, throw a {@link ConcurrentModificationException} if it is detected 
  that the mapping function modifies this map during computation.

?

Testing-wise can you use a TestNG data supplier? then you can separate out the larger test into the smaller tests. Meaning we test all combinations regardless of which fail, and each will be reported so there is no need to print out test info. If you need help with that i can provide an example.

Thanks,
Paul.

On Mar 18, 2015, at 6:46 PM, Brent Christian <brent.christian at oracle.com> wrote:

> Hi,
> 
> Please review my changes for 8071667 : "HashMap.computeIfAbsent() adds entry that HashMap.get() does not find"
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8071667
> 
> Webrev+specdiff:
> http://cr.openjdk.java.net/~bchristi/8071667/webrev.2/
> 
> 
> The fix is to detect structural changes made by the mapping functions passed to compute() and friends, and to throw a ConcurrentModificationException.  This prevents possibly adding entries in the wrong hash bin.
> 
> I have updated the docs based on the prior discussion [1], making use of the new @implSpec/etc tags, as seemed sensible to me.  Suggestions welcome.
> 
> 
> Automated test run is clean.  If the new docs look good, I'll start a CCC.
> 
> Thanks,
> -Brent
> 
> 1. http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031245.html
> 



From peter.firmstone at zeus.net.au  Thu Mar 19 10:35:33 2015
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 19 Mar 2015 20:35:33 +1000
Subject: RFR [9] 8071472: Add field access to support setting, final fields
	in readObject
In-Reply-To: <mailman.51751.1426676425.10816.core-libs-dev@openjdk.java.net>
References: <mailman.51751.1426676425.10816.core-libs-dev@openjdk.java.net>
Message-ID: <550AA675.7070703@zeus.net.au>

Chris / Peter,

Perhaps you could consider passing GetFields as a parameter to a static 
method (identified by an annotation) and use fieldSetter to change the 
fields before they're written?

That way it would be possible to not only avoid implementing readObject 
or writeObject, but to check invariants and be final field friendly.

Just a thought.

Peter.


> ------------------------------
>
> Message: 5
> Date: Wed, 18 Mar 2015 11:06:56 +0000
> From: Chris Hegarty<chris.hegarty at oracle.com>
> To: Alan Bateman<Alan.Bateman at oracle.com>,	Peter Levart
> 	<peter.levart at gmail.com>
> Cc: Core-Libs-Dev Libs<core-libs-dev at openjdk.java.net>
> Subject: Re: RFR [9] 8071472: Add field access to support setting
> 	final fields	in readObject
> Message-ID:<55095C50.3010605 at oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 17/03/15 13:42, Alan Bateman wrote:
>> On 17/03/2015 12:21, Peter Levart wrote:
>>> Hi Alan,
>>>
>>> I agree that not calling defaultReadObject() from readObject() and
>>> having a final field is potentially a bug. But need not be in case
>>> some other means of setting final fields was used (Unsafe or
>>> reflection). Some readObject() implementations in base module that
>>> Chris changed to use new API fall into this category. We can't track
>>> those usages, so to keep backwards compatibility, this checking has to
>>> be opt-in. Is there a more elegant way to opt-in? A
>>> @CheckFinalsAssignment annotation on the readObject() method?
>> I'm not sure that an annotation is right here. Instead then it might
>> work as a method on FieldSetter to enable strict checking.
> Peter suggested a method on FieldSetter to enable strict checking before
> too, and at the time I pushed back. After this discussion, I've come
> full circle, and maybe this opt-in style method is a reasonable
> compromise. Something like:
>
>    /**
>     * Checks that all final instance fields, declared by the class where
>     * the {@code readObject} callback is being invoked, have been set.
>     *
>     *<p>  This method is intended to be called as a final step after all
>     * final instance fields have been set.
>     *
>     * @throws InvalidObjectException if one, or more, final instance
>     *         fields have not been set
>     */
>    void checkAllFinalsSet() throws InvalidObjectException;
>
>
> ...and the user code would look similar to this, from java.io.File:
>
>     s.fieldSetter().set("path", p)
>                    .set("prefixLength", pLen)
>                    .checkAllFinalsSet();
>
> -Chris.
>
>
>
>
> End of core-libs-dev Digest, Vol 95, Issue 54
> *********************************************



From paul.sandoz at oracle.com  Thu Mar 19 11:07:25 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 19 Mar 2015 12:07:25 +0100
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float,
	...} methods
In-Reply-To: <550A90CE.9080901@redhat.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>
	<5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com>
Message-ID: <93E3554F-4BF0-4510-B4D8-7700DAB05E3C@oracle.com>

Hi Andrew,

Given no further advice, my inclination is move it to hotspot tests as i suspect the scope is at least as good, if not better.

I agree we should not be blocked on this, so it's up to you :-) If left as is, we can/should revisit.

Paul.

On Mar 19, 2015, at 10:03 AM, Andrew Haley <aph at redhat.com> wrote:

> People, please.
> 
> I have been working on this for weeks.  All I am waiting on now
> is a decision about where the test case should go.  Can I have a
> decision so we can get this in?
> 



From kumar.x.srinivasan at oracle.com  Thu Mar 19 13:53:13 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 19 Mar 2015 06:53:13 -0700
Subject: [8] RFR of 8066985: Java Webstart downloading packed files can
	result in Timezone set to UTC
In-Reply-To: <5509F73C.6000306@oracle.com>
References: <550976B9.6030503@oracle.com> <5509F73C.6000306@oracle.com>
Message-ID: <550AD4C9.9030905@oracle.com>

Mikhail,

You can move the common utilitieschangeDefaultTimeZoneToUtc and
restoreDefaultTimeZoneto Utils.java.

Also I am not sure how effective the test is ?  does it catch the issue ?
if you don't have the fix in PackerImpl and UnpackerImpl ?

Otherwise it looks good, and I can sponsor this patch for you.

Kumar


On 3/18/2015 3:07 PM, Kumar Srinivasan wrote:
>
> Hello Mikhail,
>
>> Hi all,
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066985
>>
>> The problem is that packer/unpacker changes global state( default 
>> time zone ) without proper synchronization:
>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/com/sun/java/util/jar/pack/PackerImpl.java#l85 
>>
>>
>> however javadoc says that it's save to use it in concurrent way if 
>> each thread has it's own packer/unpacker instance:
>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/java/util/jar/Pack200.java#l149 
>>
>>
>> The fix is:
>> 1. first packer/unpacker saves default time zone
>> 2. the last set it back.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.00/
>
> The above link is wrong!, it takes me to webrev for 8073187,
> which has only the PackerImpl changes.
>
> I am guessing the link should be:
> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.00/
>
> Kumar
>
>>
>> Thanks,
>> Mikhail.
>>
>>
>>
>>
>>
>



From brian.burkhalter at oracle.com  Thu Mar 19 14:43:37 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 19 Mar 2015 07:43:37 -0700
Subject: [9] RFR of 8074937: ServerSocket.accept() API Descriptions should
	include past tense
In-Reply-To: <D479B0BA-0D5F-48BF-BB45-A460A7AB0385@oracle.com>
References: <D479B0BA-0D5F-48BF-BB45-A460A7AB0385@oracle.com>
Message-ID: <BE08E6B5-751F-40E1-B987-5A5BFE8CF866@oracle.com>

This thread has been redirected here:

http://mail.openjdk.java.net/pipermail/net-dev/2015-March/008937.html

where I should have sent it initially. Please respond to the net-dev incarnation, not the core-libs-dev one.

Thanks,

Brian

On Mar 18, 2015, at 3:16 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> Please review at your convenience. This a doc-only change.
> 
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8074937
> Patch:	http://cr.openjdk.java.net/~bpb/8074937/webrev.00/



From peter.levart at gmail.com  Thu Mar 19 15:21:17 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 19 Mar 2015 16:21:17 +0100
Subject: RFR [9] 8071472: Add field access to support setting final fields
	in readObject
In-Reply-To: <550AA675.7070703@zeus.net.au>
References: <mailman.51751.1426676425.10816.core-libs-dev@openjdk.java.net>
	<550AA675.7070703@zeus.net.au>
Message-ID: <550AE96D.8010000@gmail.com>

On 03/19/2015 11:35 AM, Peter Firmstone wrote:
> Chris / Peter,
>
> Perhaps you could consider passing GetFields as a parameter to a 
> static method (identified by an annotation) and use fieldSetter to 
> change the fields before they're written?

Or change the fields *as* they are written. It actually doesn't matter 
if the method is static.

>
> That way it would be possible to not only avoid implementing 
> readObject or writeObject, but to check invariants and be final field 
> friendly.
>
> Just a thought.
>
> Peter.

So you mean something like this or a variant of it. Instead of 
readObject() instance method, a static method with an additional 
FieldAccess parameter:

@ReadObject
private static void altReadObject(ObjectInputStream in, FieldAccess 
fieldAccess) throws IOException, ClassNotFoundException {
     // the same as in readObject, but doesn't have direct access to 
instance state, so everything must go through FieldAccess API?
}


That's interesting. When operating with FieldSetter API or when calling 
ObjectInputStream methods, one actually doesn't need an instance 
context, since it is hidden behind the ObjectInputStream/FieldAccess 
objects, so the @ReadObject method could be static, which would prevent 
undesirable direct access to fields (finals in particular).

One thing you couldn't do this way is to check the invariants that 
involve superclass' state that has already been deserialized.

But if you don't need that, this could be an alrernative readObject() 
method. Very easy to implement, actually.


Regards, Peter

>
>
>> ------------------------------
>>
>> Message: 5
>> Date: Wed, 18 Mar 2015 11:06:56 +0000
>> From: Chris Hegarty<chris.hegarty at oracle.com>
>> To: Alan Bateman<Alan.Bateman at oracle.com>,    Peter Levart
>>     <peter.levart at gmail.com>
>> Cc: Core-Libs-Dev Libs<core-libs-dev at openjdk.java.net>
>> Subject: Re: RFR [9] 8071472: Add field access to support setting
>>     final fields    in readObject
>> Message-ID:<55095C50.3010605 at oracle.com>
>> Content-Type: text/plain; charset=windows-1252; format=flowed
>>
>> On 17/03/15 13:42, Alan Bateman wrote:
>>> On 17/03/2015 12:21, Peter Levart wrote:
>>>> Hi Alan,
>>>>
>>>> I agree that not calling defaultReadObject() from readObject() and
>>>> having a final field is potentially a bug. But need not be in case
>>>> some other means of setting final fields was used (Unsafe or
>>>> reflection). Some readObject() implementations in base module that
>>>> Chris changed to use new API fall into this category. We can't track
>>>> those usages, so to keep backwards compatibility, this checking has to
>>>> be opt-in. Is there a more elegant way to opt-in? A
>>>> @CheckFinalsAssignment annotation on the readObject() method?
>>> I'm not sure that an annotation is right here. Instead then it might
>>> work as a method on FieldSetter to enable strict checking.
>> Peter suggested a method on FieldSetter to enable strict checking before
>> too, and at the time I pushed back. After this discussion, I've come
>> full circle, and maybe this opt-in style method is a reasonable
>> compromise. Something like:
>>
>>    /**
>>     * Checks that all final instance fields, declared by the class where
>>     * the {@code readObject} callback is being invoked, have been set.
>>     *
>>     *<p>  This method is intended to be called as a final step after all
>>     * final instance fields have been set.
>>     *
>>     * @throws InvalidObjectException if one, or more, final instance
>>     *         fields have not been set
>>     */
>>    void checkAllFinalsSet() throws InvalidObjectException;
>>
>>
>> ...and the user code would look similar to this, from java.io.File:
>>
>>     s.fieldSetter().set("path", p)
>>                    .set("prefixLength", pLen)
>>                    .checkAllFinalsSet();
>>
>> -Chris.
>>
>>
>>
>>
>> End of core-libs-dev Digest, Vol 95, Issue 54
>> *********************************************
>



From chris.hegarty at oracle.com  Thu Mar 19 15:49:16 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 19 Mar 2015 15:49:16 +0000
Subject: RFR [9] 8071472: Add field access to support setting final fields
	in readObject
In-Reply-To: <550AE96D.8010000@gmail.com>
References: <mailman.51751.1426676425.10816.core-libs-dev@openjdk.java.net>
	<550AA675.7070703@zeus.net.au> <550AE96D.8010000@gmail.com>
Message-ID: <550AEFFC.8000600@oracle.com>

On 19/03/15 15:21, Peter Levart wrote:
> On 03/19/2015 11:35 AM, Peter Firmstone wrote:
>> Chris / Peter,
>>
>> Perhaps you could consider passing GetFields as a parameter to a
>> static method (identified by an annotation) and use fieldSetter to
>> change the fields before they're written?

Interesting idea. I'm reluctant to add confusion by mixing the concept 
of stream field values and object fields values, so I think the 
FieldSetter and GetField APIs should remain independent.

> Or change the fields *as* they are written. It actually doesn't matter
> if the method is static.
>
>>
>> That way it would be possible to not only avoid implementing
>> readObject or writeObject, but to check invariants and be final field
>> friendly.
>>
>> Just a thought.
>>
>> Peter.
>
> So you mean something like this or a variant of it. Instead of
> readObject() instance method, a static method with an additional
> FieldAccess parameter:
>
> @ReadObject
> private static void altReadObject(ObjectInputStream in, FieldAccess
> fieldAccess) throws IOException, ClassNotFoundException {
>      // the same as in readObject, but doesn't have direct access to
> instance state, so everything must go through FieldAccess API?
> }
>
>
> That's interesting. When operating with FieldSetter API or when calling
> ObjectInputStream methods, one actually doesn't need an instance
> context, since it is hidden behind the ObjectInputStream/FieldAccess
> objects, so the @ReadObject method could be static, which would prevent
> undesirable direct access to fields (finals in particular).

If this is primarily about checking invariants of stream field values, I 
am working through a proposal for a static validator method and better 
failure atomicity, and hope to have something to share soon.
Though, I think this is an orthogonal issue. Maybe FieldSetter can help 
here, I'm not sure.

What is being proposed by the FieldSetter is a very simple low-level API 
that addresses a long standing issue. Regardless of other changes to 
Serialization, I think this proposal, as it stands, is good.

> One thing you couldn't do this way is to check the invariants that
> involve superclass' state that has already been deserialized.

This is a difficult problem.

> But if you don't need that, this could be an alrernative readObject()
> method. Very easy to implement, actually.

-Chris.

>
>
> Regards, Peter
>
>>
>>
>>> ------------------------------
>>>
>>> Message: 5
>>> Date: Wed, 18 Mar 2015 11:06:56 +0000
>>> From: Chris Hegarty<chris.hegarty at oracle.com>
>>> To: Alan Bateman<Alan.Bateman at oracle.com>,    Peter Levart
>>>     <peter.levart at gmail.com>
>>> Cc: Core-Libs-Dev Libs<core-libs-dev at openjdk.java.net>
>>> Subject: Re: RFR [9] 8071472: Add field access to support setting
>>>     final fields    in readObject
>>> Message-ID:<55095C50.3010605 at oracle.com>
>>> Content-Type: text/plain; charset=windows-1252; format=flowed
>>>
>>> On 17/03/15 13:42, Alan Bateman wrote:
>>>> On 17/03/2015 12:21, Peter Levart wrote:
>>>>> Hi Alan,
>>>>>
>>>>> I agree that not calling defaultReadObject() from readObject() and
>>>>> having a final field is potentially a bug. But need not be in case
>>>>> some other means of setting final fields was used (Unsafe or
>>>>> reflection). Some readObject() implementations in base module that
>>>>> Chris changed to use new API fall into this category. We can't track
>>>>> those usages, so to keep backwards compatibility, this checking has to
>>>>> be opt-in. Is there a more elegant way to opt-in? A
>>>>> @CheckFinalsAssignment annotation on the readObject() method?
>>>> I'm not sure that an annotation is right here. Instead then it might
>>>> work as a method on FieldSetter to enable strict checking.
>>> Peter suggested a method on FieldSetter to enable strict checking before
>>> too, and at the time I pushed back. After this discussion, I've come
>>> full circle, and maybe this opt-in style method is a reasonable
>>> compromise. Something like:
>>>
>>>    /**
>>>     * Checks that all final instance fields, declared by the class where
>>>     * the {@code readObject} callback is being invoked, have been set.
>>>     *
>>>     *<p>  This method is intended to be called as a final step after all
>>>     * final instance fields have been set.
>>>     *
>>>     * @throws InvalidObjectException if one, or more, final instance
>>>     *         fields have not been set
>>>     */
>>>    void checkAllFinalsSet() throws InvalidObjectException;
>>>
>>>
>>> ...and the user code would look similar to this, from java.io.File:
>>>
>>>     s.fieldSetter().set("path", p)
>>>                    .set("prefixLength", pLen)
>>>                    .checkAllFinalsSet();
>>>
>>> -Chris.
>>>
>>>
>>>
>>>
>>> End of core-libs-dev Digest, Vol 95, Issue 54
>>> *********************************************
>>
>


From peter.levart at gmail.com  Thu Mar 19 15:46:16 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 19 Mar 2015 16:46:16 +0100
Subject: [8] RFR of 8066985: Java Webstart downloading packed files can
	result in Timezone set to UTC
In-Reply-To: <550AD4C9.9030905@oracle.com>
References: <550976B9.6030503@oracle.com> <5509F73C.6000306@oracle.com>
	<550AD4C9.9030905@oracle.com>
Message-ID: <550AEF48.4070904@gmail.com>

On 03/19/2015 02:53 PM, Kumar Srinivasan wrote:
> Mikhail,
>
> You can move the common utilitieschangeDefaultTimeZoneToUtc and
> restoreDefaultTimeZoneto Utils.java.
>
> Also I am not sure how effective the test is ?  does it catch the issue ?
> if you don't have the fix in PackerImpl and UnpackerImpl ?
>
> Otherwise it looks good, and I can sponsor this patch for you.
>
> Kumar

Hi Mikhail,

Is this code part of some utility so that it is executed exclusively in 
it's own JVM, or can it also be executed by some public API or internal 
JVM thread? It appears to be the later (used by java.util.jar.Pack200 
public API), but haven't checked.

In case of the later, I think it is very strange that the code changes 
global JVM timezone, albeit just temporarily. This could affect other 
code that needs default TZ and executes concurrently.

Even in case of the former, if the PackerImpl.pack can be executed by 
multiple concurrent threads and if UnpackerImpl.unpack can be executed 
by multiple concurrent threads, what guarantees that some 
PackerImpl.pack thread is not executed concurrently with some 
UnpackerImpl.unpack thread? You only track each method separately.


Regards, Peter

>
>
> On 3/18/2015 3:07 PM, Kumar Srinivasan wrote:
>>
>> Hello Mikhail,
>>
>>> Hi all,
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066985
>>>
>>> The problem is that packer/unpacker changes global state( default 
>>> time zone ) without proper synchronization:
>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/com/sun/java/util/jar/pack/PackerImpl.java#l85 
>>>
>>>
>>> however javadoc says that it's save to use it in concurrent way if 
>>> each thread has it's own packer/unpacker instance:
>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/java/util/jar/Pack200.java#l149 
>>>
>>>
>>> The fix is:
>>> 1. first packer/unpacker saves default time zone
>>> 2. the last set it back.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.00/
>>
>> The above link is wrong!, it takes me to webrev for 8073187,
>> which has only the PackerImpl changes.
>>
>> I am guessing the link should be:
>> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.00/
>>
>> Kumar
>>
>>>
>>> Thanks,
>>> Mikhail.
>>>
>>>
>>>
>>>
>>>
>>
>



From vladimir.kozlov at oracle.com  Thu Mar 19 15:59:59 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 19 Mar 2015 08:59:59 -0700
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <550A90CE.9080901@redhat.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>
	<550A90CE.9080901@redhat.com>
Message-ID: <550AF27F.4050305@oracle.com>

If you are asking about HeapByteBufferTest.java test put it into:

hotspot/test/compiler/intrinsics/unsafe/

Vladimir

On 3/19/15 2:03 AM, Andrew Haley wrote:
> People, please.
>
> I have been working on this for weeks.  All I am waiting on now
> is a decision about where the test case should go.  Can I have a
> decision so we can get this in?
>
> Thanks,
> Andrew.
>


From peter.levart at gmail.com  Thu Mar 19 16:29:29 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 19 Mar 2015 17:29:29 +0100
Subject: [8] RFR of 8066985: Java Webstart downloading packed files can
	result in Timezone set to UTC
In-Reply-To: <550AEF48.4070904@gmail.com>
References: <550976B9.6030503@oracle.com> <5509F73C.6000306@oracle.com>
	<550AD4C9.9030905@oracle.com> <550AEF48.4070904@gmail.com>
Message-ID: <550AF969.7070706@gmail.com>

On 03/19/2015 04:46 PM, Peter Levart wrote:
> On 03/19/2015 02:53 PM, Kumar Srinivasan wrote:
>> Mikhail,
>>
>> You can move the common utilitieschangeDefaultTimeZoneToUtc and
>> restoreDefaultTimeZoneto Utils.java.
>>
>> Also I am not sure how effective the test is ?  does it catch the 
>> issue ?
>> if you don't have the fix in PackerImpl and UnpackerImpl ?
>>
>> Otherwise it looks good, and I can sponsor this patch for you.
>>
>> Kumar
>
> Hi Mikhail,
>
> Is this code part of some utility so that it is executed exclusively 
> in it's own JVM, or can it also be executed by some public API or 
> internal JVM thread? It appears to be the later (used by 
> java.util.jar.Pack200 public API), but haven't checked.
>
> In case of the later, I think it is very strange that the code changes 
> global JVM timezone, albeit just temporarily. This could affect other 
> code that needs default TZ and executes concurrently.
>
> Even in case of the former, if the PackerImpl.pack can be executed by 
> multiple concurrent threads and if UnpackerImpl.unpack can be executed 
> by multiple concurrent threads, what guarantees that some 
> PackerImpl.pack thread is not executed concurrently with some 
> UnpackerImpl.unpack thread? You only track each method separately.
>
>
> Regards, Peter

I guess this default TZ manipulation is needed because 
JarOutputStream/JarInputStream don't provide constructors that would 
take a TZ object, but always use default TZ, right?

The cleanest way would be to add such constructors, but if this is too 
much for 8u, then perhaps some internal ThreadLocal<TZ> could be exposed 
to both PackerImpl/UnpackerImpl and Jar[Zip]Input[Output] stream 
internals. It think the use of default TZ in Jar/Zip/Streams is very 
localized. It is needed to convert local time (specified as DOS time) to 
and from epoch-based time exposed in ZipEntry. The code is located in 
package-private class java.util.zip.ZipUtils in methods dosToJavaTime 
/javaToDosTime (or equivalent extendedDosToJavaTime / 
javaToExtendedDosTime in JDK9).

Another way would be to provide a general thread-local default TZ 
override in TimeZone itself. Something like the following:

===================================================================
--- jdk/src/share/classes/java/util/TimeZone.java
+++ jdk/src/share/classes/java/util/TimeZone.java
@@ -630,8 +630,11 @@
       * method doesn't create a clone.
       */
      static TimeZone getDefaultRef() {
-        TimeZone defaultZone = defaultTimeZone;
+        TimeZone defaultZone = threadLocalTimeZone.get();
          if (defaultZone == null) {
+            defaultZone = defaultTimeZone;
+        }
+        if (defaultZone == null) {
              // Need to initialize the default time zone.
              defaultZone = setDefaultZone();
              assert defaultZone != null;
@@ -713,6 +716,20 @@
          defaultTimeZone = zone;
      }

+    public void withThreadDefaultDo(Runnable runnable) {
+        TimeZone prevZone = threadLocalTimeZone.get();
+        threadLocalTimeZone.set(this);
+        try {
+            runnable.run();
+        } finally {
+            if (prevZone == null) {
+                threadLocalTimeZone.remove();
+            } else {
+                threadLocalTimeZone.set(prevZone);
+            }
+        }
+    }
+
      /**
       * Returns true if this zone has the same rule and offset as 
another zone.
       * That is, if this zone differs only in ID, if at all.  Returns false
@@ -760,6 +777,8 @@
       */
      private String           ID;
      private static volatile TimeZone defaultTimeZone;
+    private static final ThreadLocal<TimeZone> threadLocalTimeZone =
+        new ThreadLocal<>();

      static final String         GMT_ID        = "GMT";
      private static final int    GMT_ID_LENGTH = 3;


Regards, Peter

>
>>
>>
>> On 3/18/2015 3:07 PM, Kumar Srinivasan wrote:
>>>
>>> Hello Mikhail,
>>>
>>>> Hi all,
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066985
>>>>
>>>> The problem is that packer/unpacker changes global state( default 
>>>> time zone ) without proper synchronization:
>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/com/sun/java/util/jar/pack/PackerImpl.java#l85 
>>>>
>>>>
>>>> however javadoc says that it's save to use it in concurrent way if 
>>>> each thread has it's own packer/unpacker instance:
>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/java/util/jar/Pack200.java#l149 
>>>>
>>>>
>>>> The fix is:
>>>> 1. first packer/unpacker saves default time zone
>>>> 2. the last set it back.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.00/
>>>
>>> The above link is wrong!, it takes me to webrev for 8073187,
>>> which has only the PackerImpl changes.
>>>
>>> I am guessing the link should be:
>>> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.00/
>>>
>>> Kumar
>>>
>>>>
>>>> Thanks,
>>>> Mikhail.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>



From Alan.Bateman at oracle.com  Thu Mar 19 16:33:00 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Mar 2015 16:33:00 +0000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <550AF27F.4050305@oracle.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>	<550A90CE.9080901@redhat.com>
	<550AF27F.4050305@oracle.com>
Message-ID: <550AFA3C.5030002@oracle.com>

On 19/03/2015 15:59, Vladimir Kozlov wrote:
> If you are asking about HeapByteBufferTest.java test put it into:
>
> hotspot/test/compiler/intrinsics/unsafe/
>
> Vladimir
The existing tests for buffers are in jdk/test/java/nio/Buffer and would 
nice to have all the tests for this API together if possible. So I guess 
the issue here is that it's one test serving two purposes, it feel that 
there should be a new test that exercises Unsafe directly to put into 
the hotspot/test/compiler tree.

-Alan


From aph at redhat.com  Thu Mar 19 16:43:39 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 19 Mar 2015 16:43:39 +0000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <550AFA3C.5030002@oracle.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>	<550A90CE.9080901@redhat.com>
	<550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com>
Message-ID: <550AFCBB.6080905@redhat.com>

On 03/19/2015 04:33 PM, Alan Bateman wrote:
> On 19/03/2015 15:59, Vladimir Kozlov wrote:
>> If you are asking about HeapByteBufferTest.java test put it into:
>>
>> hotspot/test/compiler/intrinsics/unsafe/
>>
>> Vladimir
> The existing tests for buffers are in jdk/test/java/nio/Buffer and would 
> nice to have all the tests for this API together if possible. So I guess 
> the issue here is that it's one test serving two purposes, it feel that 
> there should be a new test that exercises Unsafe directly to put into 
> the hotspot/test/compiler tree.

Within reason I'll do whatever you want, but I'm as sure as I can be
that this test gives the new part of Unsafe a thorough workout.  We
need HeapByteBufferTest.java because of the substantial changes to
that class.  I don't know what a test of the unsafe aligned methods
would do that is not done by HeapByteBufferTest.

Andrew.


From aph at redhat.com  Thu Mar 19 16:44:46 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 19 Mar 2015 16:44:46 +0000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <550AFCBB.6080905@redhat.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>	<550A90CE.9080901@redhat.com>	<550AF27F.4050305@oracle.com>
	<550AFA3C.5030002@oracle.com> <550AFCBB.6080905@redhat.com>
Message-ID: <550AFCFE.80500@redhat.com>

On 03/19/2015 04:43 PM, Andrew Haley wrote:
> On 03/19/2015 04:33 PM, Alan Bateman wrote:
>> On 19/03/2015 15:59, Vladimir Kozlov wrote:
>>> If you are asking about HeapByteBufferTest.java test put it into:
>>>
>>> hotspot/test/compiler/intrinsics/unsafe/
>>>
>>> Vladimir
>> The existing tests for buffers are in jdk/test/java/nio/Buffer and would 
>> nice to have all the tests for this API together if possible. So I guess 
>> the issue here is that it's one test serving two purposes, it feel that 
>> there should be a new test that exercises Unsafe directly to put into 
>> the hotspot/test/compiler tree.
> 
> Within reason I'll do whatever you want, but I'm as sure as I can be
> that this test gives the new part of Unsafe a thorough workout.  We
> need HeapByteBufferTest.java because of the substantial changes to
> that class.  I don't know what a test of the unsafe aligned methods

unaligned

> would do that is not done by HeapByteBufferTest.
> 
> Andrew.
> 



From vladimir.kozlov at oracle.com  Thu Mar 19 16:53:42 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 19 Mar 2015 09:53:42 -0700
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <550AFA3C.5030002@oracle.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>	<550A90CE.9080901@redhat.com>
	<550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com>
Message-ID: <550AFF16.9080600@oracle.com>

New code did not change API of existing X-Buffer methods. It changed 
only how they are implementation. And already existing nio/Buffer tests 
should test these methods already.

Regards,
Vladimir

On 3/19/15 9:33 AM, Alan Bateman wrote:
> On 19/03/2015 15:59, Vladimir Kozlov wrote:
>> If you are asking about HeapByteBufferTest.java test put it into:
>>
>> hotspot/test/compiler/intrinsics/unsafe/
>>
>> Vladimir
> The existing tests for buffers are in jdk/test/java/nio/Buffer and would
> nice to have all the tests for this API together if possible. So I guess
> the issue here is that it's one test serving two purposes, it feel that
> there should be a new test that exercises Unsafe directly to put into
> the hotspot/test/compiler tree.
>
> -Alan


From joe.darcy at oracle.com  Thu Mar 19 18:52:22 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 19 Mar 2015 11:52:22 -0700
Subject: JDK 9 RFR of JDK-8075544: Add tiered testing definitions to the jdk
	repo
Message-ID: <550B1AE6.6070905@oracle.com>

Hello,

For background, please see the tiered testing proposal over at

http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html

The patch below adds "tier1" and "tier2" test definitions to the jdk 
repository; webrev at

     http://cr.openjdk.java.net/~darcy/8075544.0/

One can verify the test definitions are working as intended by running 
with "jtreg -l" to just list (rather than execute) the specified tests.

Thanks,

-Joe

--- old/test/TEST.groups    2015-03-19 11:46:47.229956324 -0700
+++ new/test/TEST.groups    2015-03-19 11:46:47.053956318 -0700
@@ -20,6 +20,22 @@
  #  questions.
  #

+# Tiered testing definitions
+tier1 = \
+    :jdk_lang \
+    :jdk_util \
+    :jdk_math
+
+tier2 = \
+    :jdk_io \
+    :jdk_nio \
+    :jdk_net \
+    :jdk_rmi \
+    :jdk_time \
+    :jdk_security \
+    :jdk_text \
+    :core_tools
+
  # java.lang package and VM runtime support
  jdk_lang = \
      java/lang \



From Alan.Bateman at oracle.com  Thu Mar 19 19:04:54 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Mar 2015 19:04:54 +0000
Subject: JDK 9 RFR of JDK-8075544: Add tiered testing definitions to the
	jdk repo
In-Reply-To: <550B1AE6.6070905@oracle.com>
References: <550B1AE6.6070905@oracle.com>
Message-ID: <550B1DD6.6050603@oracle.com>



On 19/03/2015 18:52, joe darcy wrote:
> Hello,
>
> For background, please see the tiered testing proposal over at
>
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html
>
> The patch below adds "tier1" and "tier2" test definitions to the jdk 
> repository; webrev at
>
>     http://cr.openjdk.java.net/~darcy/8075544.0/
>
We previously attempt to use "########..." comments to create clear 
sections in this file, would it good to do this here as otherwise it can 
be confusing see the organization of the top-level groups (jdk_core, 
jdk_svc and jdk_desktop specifically).

-Alan


From joe.darcy at oracle.com  Thu Mar 19 19:10:24 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 19 Mar 2015 12:10:24 -0700
Subject: JDK 9 RFR of JDK-8075544: Add tiered testing definitions to the
	jdk repo
In-Reply-To: <550B1DD6.6050603@oracle.com>
References: <550B1AE6.6070905@oracle.com> <550B1DD6.6050603@oracle.com>
Message-ID: <550B1F20.1010407@oracle.com>

Hi Alan,

On 3/19/2015 12:04 PM, Alan Bateman wrote:
>
>
> On 19/03/2015 18:52, joe darcy wrote:
>> Hello,
>>
>> For background, please see the tiered testing proposal over at
>>
>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html
>>
>> The patch below adds "tier1" and "tier2" test definitions to the jdk 
>> repository; webrev at
>>
>>     http://cr.openjdk.java.net/~darcy/8075544.0/
>>
> We previously attempt to use "########..." comments to create clear 
> sections in this file, would it good to do this here as otherwise it 
> can be confusing see the organization of the top-level groups 
> (jdk_core, jdk_svc and jdk_desktop specifically).
>

Okay; how about

diff -r 41e561ceb912 test/TEST.groups
--- a/test/TEST.groups    Wed Mar 18 09:13:11 2015 +0100
+++ b/test/TEST.groups    Thu Mar 19 12:09:05 2015 -0700
@@ -20,6 +20,31 @@
  #  questions.
  #

+###############################################################################
+#
+# Tiered testing definitions
+#
+
+tier1 = \
+    :jdk_lang \
+    :jdk_util \
+    :jdk_math
+
+tier2 = \
+    :jdk_io \
+    :jdk_nio \
+    :jdk_net \
+    :jdk_rmi \
+    :jdk_time \
+    :jdk_security \
+    :jdk_text \
+    :core_tools
+
+###############################################################################
+#
+# Other test definitions; generally smaller granularity than tiers
+#
+
  # java.lang package and VM runtime support
  jdk_lang = \
      java/lang \

Thanks,

-Joe


From Alan.Bateman at oracle.com  Thu Mar 19 19:12:10 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Mar 2015 19:12:10 +0000
Subject: JDK 9 RFR of JDK-8075544: Add tiered testing definitions to the
	jdk repo
In-Reply-To: <550B1F20.1010407@oracle.com>
References: <550B1AE6.6070905@oracle.com> <550B1DD6.6050603@oracle.com>
	<550B1F20.1010407@oracle.com>
Message-ID: <550B1F8A.4070509@oracle.com>

On 19/03/2015 19:10, joe darcy wrote:
> Hi Alan,
>
> On 3/19/2015 12:04 PM, Alan Bateman wrote:
>>
>>
>> On 19/03/2015 18:52, joe darcy wrote:
>>> Hello,
>>>
>>> For background, please see the tiered testing proposal over at
>>>
>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html
>>>
>>> The patch below adds "tier1" and "tier2" test definitions to the jdk 
>>> repository; webrev at
>>>
>>>     http://cr.openjdk.java.net/~darcy/8075544.0/
>>>
>> We previously attempt to use "########..." comments to create clear 
>> sections in this file, would it good to do this here as otherwise it 
>> can be confusing see the organization of the top-level groups 
>> (jdk_core, jdk_svc and jdk_desktop specifically).
>>
>
> Okay; how about
Thanks, looks okay.

-Alan


From Alan.Bateman at oracle.com  Thu Mar 19 20:43:55 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Mar 2015 20:43:55 +0000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <550AFF16.9080600@oracle.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>	<550A90CE.9080901@redhat.com>
	<550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com>
	<550AFF16.9080600@oracle.com>
Message-ID: <550B350B.6040602@oracle.com>

On 19/03/2015 16:53, Vladimir Kozlov wrote:
> New code did not change API of existing X-Buffer methods. It changed 
> only how they are implementation. And already existing nio/Buffer 
> tests should test these methods already.
Okay, although I've made a note to check the test coverage to see that 
the existing tests cover all cases. I have no objection to this going 
into the compiler tree of course, just wondering whether the existing 
buffer tests are enough.

-Alan


From chris.hegarty at oracle.com  Thu Mar 19 21:26:57 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 19 Mar 2015 21:26:57 +0000
Subject: RFR [9] 8071474: Better failure atomicity for default read object
Message-ID: <550B3F21.6020206@oracle.com>

The current implementation of defaultReadObject sets non-primitive field 
values one at a time, without first checking that all their types are 
assignable. If, for example, the assignment of the last non-primitive 
value fails, a CCE is thrown, and the previously set fields remain set. 
The setting of field values, including primitives, can be deferred until 
after they have been "validated", at a minimum that the non-primitive 
types are assignable. This is achievable per Class in the hierarchy up 
until the first user visible affect, i.e. a readObject(NoData) method. 
Either all fields will be set, or contain their default values.

http://cr.openjdk.java.net/~chegar/8071474/webrev.00/webrev/

I think there are further improvements that can be made in this area, 
but I would like to move things forward incrementally.

-Chris.


From xueming.shen at oracle.com  Thu Mar 19 22:16:44 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 19 Mar 2015 15:16:44 -0700
Subject: [8] RFR of 8066985: Java Webstart downloading packed files can
	result in Timezone set to UTC
In-Reply-To: <550AF969.7070706@gmail.com>
References: <550976B9.6030503@oracle.com>
	<5509F73C.6000306@oracle.com>	<550AD4C9.9030905@oracle.com>
	<550AEF48.4070904@gmail.com> <550AF969.7070706@gmail.com>
Message-ID: <550B4ACC.1010507@oracle.com>

On 03/19/2015 09:29 AM, Peter Levart wrote:
> On 03/19/2015 04:46 PM, Peter Levart wrote:
>> On 03/19/2015 02:53 PM, Kumar Srinivasan wrote:
>>> Mikhail,
>>>
>>> You can move the common utilitieschangeDefaultTimeZoneToUtc and
>>> restoreDefaultTimeZoneto Utils.java.
>>>
>>> Also I am not sure how effective the test is ?  does it catch the issue ?
>>> if you don't have the fix in PackerImpl and UnpackerImpl ?
>>>
>>> Otherwise it looks good, and I can sponsor this patch for you.
>>>
>>> Kumar
>>
>> Hi Mikhail,
>>
>> Is this code part of some utility so that it is executed exclusively in it's own JVM, or can it also be executed by some public API or internal JVM thread? It appears to be the later (used by java.util.jar.Pack200 public API), but haven't checked.
>>
>> In case of the later, I think it is very strange that the code changes global JVM timezone, albeit just temporarily. This could affect other code that needs default TZ and executes concurrently.
>>
>> Even in case of the former, if the PackerImpl.pack can be executed by multiple concurrent threads and if UnpackerImpl.unpack can be executed by multiple concurrent threads, what guarantees that some PackerImpl.pack thread is not executed concurrently with some UnpackerImpl.unpack thread? You only track each method separately.
>>
>>
>> Regards, Peter
>
> I guess this default TZ manipulation is needed because JarOutputStream/JarInputStream don't provide constructors that would take a TZ object, but always use default TZ, right?
>
> The cleanest way would be to add such constructors, but if this is too much for 8u, then perhaps some internal ThreadLocal<TZ> could be exposed to both PackerImpl/UnpackerImpl and Jar[Zip]Input[Output] stream internals. It think the use of default TZ in Jar/Zip/Streams is very localized. It is needed to convert local time (specified as DOS time) to and from epoch-based time exposed in ZipEntry. The code is located in package-private class java.util.zip.ZipUtils in methods dosToJavaTime /javaToDosTime (or equivalent extendedDosToJavaTime / javaToExtendedDosTime in JDK9).
>

Default TZ manipulation is really not the preferred/good approach.

Given the timestamp in a zip entry is really a dos/local date-time, a "clean"
solution is to add a pair of ZipEntry.set/getTimeLocal() methods to free
ZipEntry from handing local date-time <-> utc millis conversion with the
default timezone.

     public void setTimeLocal(LocalDateTime ldt) {
         this.xdostime = ((ldt.getYear() - 1980) << 25 |
             ldt.getMonthValue() << 21 |
             ldt.getDayOfMonth() << 16 |
             ldt.getHour() << 11 |
             ldt.getMinute() << 5 |
             ldt.getSecond() >> 1)
             + ((long)(((ldt.getSecond() & 0x1) * 1000) +
                       ldt.getNano() / 1000_000) << 32);
         this.mtime = null;
     }


     public LocalDateTime getTimeLocal() {
         int ms = (int)(xdostime >> 32);
         return LocalDateTime.of((int)(((xdostime >> 25) & 0x7f) + 1980),
                              (int)((xdostime >> 21) & 0x0f),
                              (int)((xdostime >> 16) & 0x1f),
                              (int)((xdostime >> 11) & 0x1f),
                              (int)((xdostime >> 5) & 0x3f),
                              (int)((xdostime << 1) & 0x3e) + ms / 1000,
                              (ms % 1000) * 1000_000);
     }


For pack/unpack, as they always assume UTC, it should convert the utc
millis to/from LocalDateTime as

ZipEntry.setTimeLocale(LocalDateTime.ofEpochSecond(time / 1000, (int)(time % 1000) * 1000_000, ZoneOffset.UTC));

and

Math.multiplyExact(ZipEntry.getTimeLocal().atOffset(ZoneOffset.UTC).toEpochSecond(), 1000);


-Sherman


From brent.christian at oracle.com  Thu Mar 19 22:31:41 2015
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 19 Mar 2015 15:31:41 -0700
Subject: RFR 8071667 : HashMap.computeIfAbsent() adds entry that
	HashMap.get() does not find.
In-Reply-To: <684AF3A3-4280-47B3-AA8D-64248C5DDA9A@oracle.com>
References: <5509BA01.6000709@oracle.com>
	<684AF3A3-4280-47B3-AA8D-64248C5DDA9A@oracle.com>
Message-ID: <550B4E4D.5010500@oracle.com>

Hi, Paul

Thank you for the suggested doc adjustments.  They're applied here:
http://cr.openjdk.java.net/~bchristi/8071667/webrev.3/

TestNG test update forthcoming.

-Brent

On 3/19/15 3:09 AM, Paul Sandoz wrote:
> Hi Brent,
>
> The implementation looks good.
>
> Documentation-wise i think it needs some adjustment:
>
> - the @apiNote should be promoted to "normal" documentation as we want to make a stronger statement.
>
> - I think the @implNote on Map should be merged into the @implSpec. How about:
>
>    <p>The default implementation makes no guarantees about detecting if the mapping function modifies
>    this map during computation and, if appropriate, reporting an error.
>    Non-concurrent implementations should override this method and, on a best-effort basis, throw a
>    {@code ConcurrentModificationException} if it is detected that the mapping function modifies this
>    map during computation.
>    Concurrent implementations should override this method and, on a best-effort basis, throw a
>    {@code IllegalStateException} if it is detected that the mapping function modifies this map
>    during computation and as a result computation would never complete.
>
> ?
>
> - the @implSpec on HashMap etc. should be promoted to "normal" documentation:
>
>    <p>This method will, on a best-effort basis, throw a {@link ConcurrentModificationException} if it is detected
>    that the mapping function modifies this map during computation.
>
> ?
>
> Testing-wise can you use a TestNG data supplier? then you can separate out the larger test into the smaller tests. Meaning we test all combinations regardless of which fail, and each will be reported so there is no need to print out test info. If you need help with that i can provide an example.
>
> Thanks,
> Paul.
>
> On Mar 18, 2015, at 6:46 PM, Brent Christian <brent.christian at oracle.com> wrote:
>
>> Hi,
>>
>> Please review my changes for 8071667 : "HashMap.computeIfAbsent() adds entry that HashMap.get() does not find"
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8071667
>>
>> Webrev+specdiff:
>> http://cr.openjdk.java.net/~bchristi/8071667/webrev.2/
>>
>>
>> The fix is to detect structural changes made by the mapping functions passed to compute() and friends, and to throw a ConcurrentModificationException.  This prevents possibly adding entries in the wrong hash bin.
>>
>> I have updated the docs based on the prior discussion [1], making use of the new @implSpec/etc tags, as seemed sensible to me.  Suggestions welcome.
>>
>>
>> Automated test run is clean.  If the new docs look good, I'll start a CCC.
>>
>> Thanks,
>> -Brent
>>
>> 1. http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031245.html
>>
>


From kumar.x.srinivasan at oracle.com  Thu Mar 19 22:46:29 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 19 Mar 2015 15:46:29 -0700
Subject: [9] RFR 8074839: Resolve disabled warnings for libunpack and
	the unpack200 binary
In-Reply-To: <550A07C7.1090608@oracle.com>
References: <550A07C7.1090608@oracle.com>
Message-ID: <550B51C5.3020505@oracle.com>

Hi Mikael,

First of all, thank you so much for doing this!.

The changes look good.

Kumar

On 3/18/2015 4:18 PM, Mikael Vidstedt wrote:
>
> Please review the following change which fixes a number of native 
> compilation warnings in the jdk.pack200 code.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074839
> Webrev: 
> http://cr.openjdk.java.net/~mikael/webrevs/8074839/webrev.03/webrev/
>
> Testing: A slightly earlier version [1] has been through a build & 
> test cycle on all the OracleJDK platforms, running the core_tools 
> jtreg tests as well as a number of other jtreg tests and java 
> applications. There were no warnings on any of the platforms (in the 
> files related to this change). I will rerun the testing, but since the 
> differences from the earlier version are very small I'd like some 
> reviews first.
>
> Note that the warnings were temporarily disabled as part of 
> JDK-8074096 [2] until such time they could be fixed the proper way. 
> Also note that this change supersedes the earlier change [3] Dmitry 
> had out for review. The bug [4] corresponding to that webrev will be 
> closed as a duplicate of this bug (JDK-8074839).
>
> Cheers,
> Mikael
>
> [1] http://cr.openjdk.java.net/~mikael/webrevs/8074839/webrev.02/webrev
> [2] https://bugs.openjdk.java.net/browse/JDK-8074096
> [3] http://cr.openjdk.java.net/~dsamersoff/JDK-8073584/webrev.01/
> [4] https://bugs.openjdk.java.net/browse/JDK-8073584
>



From joe.darcy at oracle.com  Fri Mar 20 00:12:24 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 19 Mar 2015 17:12:24 -0700
Subject: JDK 9 RFR of JDK-8075565: Define @intermittent jtreg keyword and
	mark intermittently failing jdk tests
Message-ID: <550B65E8.1050209@oracle.com>

Hello,

Per recent proposals 
(http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html), please 
review the change below for

     JDK-8075565: Define @intermittent jtreg keyword and mark 
intermittently failuring jdk tests
     http://cr.openjdk.java.net/~darcy/8075565.0/

which defines an "intermittent" keyword for use in jtreg tests and then 
marks the initial rouges gallery of known or suspected intermittently 
failing tests:

     test/com/sun/jndi/ldap/LdapTimeoutTest.java
     test/java/lang/invoke/MethodHandles/CatchExceptionTest.java
     test/java/lang/ref/OOMEInReferenceHandler.java
test/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java
     test/java/net/SocketPermission/SocketPermissionTest.java
     test/java/nio/channels/AsynchronousSocketChannel/Basic.java
     test/java/nio/channels/Selector/Wakeup.java
test/java/nio/channels/ServerSocketChannel/AdaptServerSocket.java
test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh
     test/java/nio/file/FileStore/Basic.java
     test/java/nio/file/Files/InterruptCopy.java
test/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java
     test/java/rmi/registry/interfaceHash/InterfaceHash.java
test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java

I compiled the list by going through open test-related bugs in core-libs 
components and a few other components. I'll send a follow-up message to 
security-libs to get their sets marked. I generally tried to only mark 
tests as intermittent if there was recent (six months old or new) 
information about a failure. Therefore, this initial list is not 
comprehensive and tests should have the keyword added as they are 
observed to intermittently fail. Also, tests should have the keyword 
removed if they are corrected to address the cause of the intermittent 
failure!

I verified

     jtreg -l -k:intermittent

selects the right number of tests.

Full patch below.

Thanks,

-Joe

--- old/test/TEST.ROOT    2015-03-19 16:59:36.033243886 -0700
+++ new/test/TEST.ROOT    2015-03-19 16:59:35.865243880 -0700
@@ -2,7 +2,7 @@
  # It also contains test-suite configuration information.

  # The list of keywords supported in the entire test suite
-keys=2d dnd i18n
+keys=2d dnd i18n intermittent

  # Tests that must run in othervm mode
  othervm.dirs=java/awt java/beans javax/accessibility javax/imageio 
javax/sound javax/print javax/management com/sun/awt sun/awt sun/java2d 
sun/pisces javax/xml/jaxp/testng/validation
--- old/test/com/sun/jndi/ldap/LdapTimeoutTest.java    2015-03-19 
16:59:36.473243902 -0700
+++ new/test/com/sun/jndi/ldap/LdapTimeoutTest.java    2015-03-19 
16:59:36.289243896 -0700
@@ -26,6 +26,7 @@
   * @run main/othervm LdapTimeoutTest
   * @bug 7094377 8000487 6176036 7056489
   * @summary Timeout tests for ldap
+ * @key intermittent
   */

  import java.net.Socket;
--- old/test/java/lang/invoke/MethodHandles/CatchExceptionTest.java 
2015-03-19 16:59:36.909243918 -0700
+++ new/test/java/lang/invoke/MethodHandles/CatchExceptionTest.java 
2015-03-19 16:59:36.733243912 -0700
@@ -41,6 +41,7 @@
   * @library /lib/testlibrary/jsr292 /lib/testlibrary/
   * @compile CatchExceptionTest.java
   * @run main/othervm -esa 
test.java.lang.invoke.MethodHandles.CatchExceptionTest
+ * @key intermittent
   */
  public class CatchExceptionTest {
      private static final List<Class<?>> ARGS_CLASSES;
--- old/test/java/lang/ref/OOMEInReferenceHandler.java    2015-03-19 
16:59:37.353243935 -0700
+++ new/test/java/lang/ref/OOMEInReferenceHandler.java    2015-03-19 
16:59:37.177243928 -0700
@@ -27,6 +27,7 @@
   * @summary Verify that the reference handler does not die after an 
OOME allocating the InterruptedException object
   * @run main/othervm -XX:-UseGCOverheadLimit -Xmx24M -XX:-UseTLAB 
OOMEInReferenceHandler
   * @author peter.levart at gmail.com
+ * @key intermittent
   */

  import java.lang.ref.*;
--- 
old/test/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java 
2015-03-19 16:59:37.805243951 -0700
+++ 
new/test/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java 
2015-03-19 16:59:37.625243945 -0700
@@ -42,6 +42,7 @@
   * @test
   * @bug 8007373
   * @summary jdk7 backward compatibility serialization problem
+ * @key intermittent
   */

  public class Inet6AddressSerializationTest {
--- old/test/java/net/SocketPermission/SocketPermissionTest.java 
2015-03-19 16:59:38.285243969 -0700
+++ new/test/java/net/SocketPermission/SocketPermissionTest.java 
2015-03-19 16:59:38.101243962 -0700
@@ -27,6 +27,7 @@
   * @summary SocketPermission tests for legacy socket types
   * @library ../../../lib/testlibrary
   * @run testng/othervm/policy=policy SocketPermissionTest
+ * @key intermittent
   */
  import java.io.IOException;
  import java.net.DatagramPacket;
--- old/test/java/nio/channels/AsynchronousSocketChannel/Basic.java 
2015-03-19 16:59:38.741243986 -0700
+++ new/test/java/nio/channels/AsynchronousSocketChannel/Basic.java 
2015-03-19 16:59:38.557243979 -0700
@@ -25,6 +25,7 @@
   * @bug 4607272 6842687 6878369 6944810 7023403
   * @summary Unit test for AsynchronousSocketChannel
   * @run main Basic -skipSlowConnectTest
+ * @key intermittent
   */

  import java.nio.ByteBuffer;
--- old/test/java/nio/channels/Selector/Wakeup.java    2015-03-19 
16:59:39.201244003 -0700
+++ new/test/java/nio/channels/Selector/Wakeup.java    2015-03-19 
16:59:39.017243996 -0700
@@ -25,6 +25,7 @@
   * @bug 6405995
   * @summary Unit test for selector wakeup and interruption
   * @library ..
+ * @key intermittent
   */

  import java.io.*;
--- 
old/test/java/nio/channels/ServerSocketChannel/AdaptServerSocket.java 
2015-03-19 16:59:39.653244019 -0700
+++ 
new/test/java/nio/channels/ServerSocketChannel/AdaptServerSocket.java 
2015-03-19 16:59:39.473244013 -0700
@@ -23,6 +23,7 @@

  /* @test
   * @summary Unit test for server-socket-channel adaptors
+ * @key intermittent
   */

  import java.io.*;
--- 
old/test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh 
2015-03-19 16:59:40.089244035 -0700
+++ 
new/test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh 
2015-03-19 16:59:39.909244029 -0700
@@ -24,12 +24,12 @@
  #

  # @test
-# @bug 4673940
-# @bug 4930794
+# @bug 4673940 4930794
  # @summary Unit tests for inetd feature
  #
  # @build StateTest StateTestService EchoTest EchoService CloseTest 
Launcher Util
  # @run shell run_tests.sh
+# @key intermittent

  os=`uname -s`

--- old/test/java/nio/file/FileStore/Basic.java    2015-03-19 
16:59:40.541244052 -0700
+++ new/test/java/nio/file/FileStore/Basic.java    2015-03-19 
16:59:40.357244045 -0700
@@ -25,6 +25,7 @@
   * @bug 4313887 6873621 6979526 7006126 7020517
   * @summary Unit test for java.nio.file.FileStore
   * @library ..
+ * @key intermittent
   */

  import java.nio.file.*;
--- old/test/java/nio/file/Files/InterruptCopy.java    2015-03-19 
16:59:40.973244068 -0700
+++ new/test/java/nio/file/Files/InterruptCopy.java    2015-03-19 
16:59:40.793244061 -0700
@@ -25,6 +25,7 @@
   * @bug 4313887 6993267
   * @summary Unit test for Sun-specific 
ExtendedCopyOption.INTERRUPTIBLE option
   * @library ..
+ * @key intermittent
   */

  import java.nio.file.*;
--- 
old/test/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java 
2015-03-19 16:59:41.413244084 -0700
+++ 
new/test/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java 
2015-03-19 16:59:41.237244078 -0700
@@ -39,6 +39,7 @@
   * @build TestLibrary RMID ActivateMe CheckActivateRef_Stub
   * @run main/othervm/policy=security.policy/timeout=240 
-Djava.rmi.server.ignoreStubClasses=true CheckActivateRef
   * @run main/othervm/policy=security.policy/timeout=240 
-Djava.rmi.server.ignoreStubClasses=false CheckActivateRef
+ * @key intermittent
   */

  import java.io.*;
--- old/test/java/rmi/registry/interfaceHash/InterfaceHash.java 
2015-03-19 16:59:41.865244101 -0700
+++ new/test/java/rmi/registry/interfaceHash/InterfaceHash.java 
2015-03-19 16:59:41.681244094 -0700
@@ -38,6 +38,7 @@
   * @library ../../testlibrary
   * @build TestLibrary ReferenceRegistryStub
   * @run main/othervm InterfaceHash
+ * @key intermittent
   */

  import java.lang.reflect.Constructor;
--- 
old/test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java 
2015-03-19 16:59:42.325244118 -0700
+++ 
new/test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java 
2015-03-19 16:59:42.141244111 -0700
@@ -31,6 +31,7 @@
   * @summary GC'ing objects whilst being exported to RMI should not 
cause exceptions
   * @author Neil Richards <neil.richards at ngmr.net>, 
<neil_richards at uk.ibm.com>
   * @run main/othervm GcDuringExport
+ * @key intermittent
   */

  import java.rmi.Remote;



From lance.andersen at oracle.com  Fri Mar 20 00:42:27 2015
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Thu, 19 Mar 2015 20:42:27 -0400
Subject: JDK 9 RFR of JDK-8075565: Define @intermittent jtreg keyword and
	mark intermittently failing jdk tests
In-Reply-To: <550B65E8.1050209@oracle.com>
References: <550B65E8.1050209@oracle.com>
Message-ID: <85CEC82B-1EFF-4A63-A435-753145EC57EE@oracle.com>

Hi joe,

This looks fine based on your proposal.

Best
Lance


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

> On Mar 19, 2015, at 8:12 PM, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> Per recent proposals (http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html), please review the change below for
> 
>    JDK-8075565: Define @intermittent jtreg keyword and mark intermittently failuring jdk tests
>    http://cr.openjdk.java.net/~darcy/8075565.0/
> 
> which defines an "intermittent" keyword for use in jtreg tests and then marks the initial rouges gallery of known or suspected intermittently failing tests:
> 
>    test/com/sun/jndi/ldap/LdapTimeoutTest.java
>    test/java/lang/invoke/MethodHandles/CatchExceptionTest.java
>    test/java/lang/ref/OOMEInReferenceHandler.java
> test/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java
>    test/java/net/SocketPermission/SocketPermissionTest.java
>    test/java/nio/channels/AsynchronousSocketChannel/Basic.java
>    test/java/nio/channels/Selector/Wakeup.java
> test/java/nio/channels/ServerSocketChannel/AdaptServerSocket.java
> test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh
>    test/java/nio/file/FileStore/Basic.java
>    test/java/nio/file/Files/InterruptCopy.java
> test/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java
>    test/java/rmi/registry/interfaceHash/InterfaceHash.java
> test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java
> 
> I compiled the list by going through open test-related bugs in core-libs components and a few other components. I'll send a follow-up message to security-libs to get their sets marked. I generally tried to only mark tests as intermittent if there was recent (six months old or new) information about a failure. Therefore, this initial list is not comprehensive and tests should have the keyword added as they are observed to intermittently fail. Also, tests should have the keyword removed if they are corrected to address the cause of the intermittent failure!
> 
> I verified
> 
>    jtreg -l -k:intermittent
> 
> selects the right number of tests.
> 
> Full patch below.
> 
> Thanks,
> 
> -Joe
> 
> --- old/test/TEST.ROOT    2015-03-19 16:59:36.033243886 -0700
> +++ new/test/TEST.ROOT    2015-03-19 16:59:35.865243880 -0700
> @@ -2,7 +2,7 @@
> # It also contains test-suite configuration information.
> 
> # The list of keywords supported in the entire test suite
> -keys=2d dnd i18n
> +keys=2d dnd i18n intermittent
> 
> # Tests that must run in othervm mode
> othervm.dirs=java/awt java/beans javax/accessibility javax/imageio javax/sound javax/print javax/management com/sun/awt sun/awt sun/java2d sun/pisces javax/xml/jaxp/testng/validation
> --- old/test/com/sun/jndi/ldap/LdapTimeoutTest.java    2015-03-19 16:59:36.473243902 -0700
> +++ new/test/com/sun/jndi/ldap/LdapTimeoutTest.java    2015-03-19 16:59:36.289243896 -0700
> @@ -26,6 +26,7 @@
>  * @run main/othervm LdapTimeoutTest
>  * @bug 7094377 8000487 6176036 7056489
>  * @summary Timeout tests for ldap
> + * @key intermittent
>  */
> 
> import java.net.Socket;
> --- old/test/java/lang/invoke/MethodHandles/CatchExceptionTest.java 2015-03-19 16:59:36.909243918 -0700
> +++ new/test/java/lang/invoke/MethodHandles/CatchExceptionTest.java 2015-03-19 16:59:36.733243912 -0700
> @@ -41,6 +41,7 @@
>  * @library /lib/testlibrary/jsr292 /lib/testlibrary/
>  * @compile CatchExceptionTest.java
>  * @run main/othervm -esa test.java.lang.invoke.MethodHandles.CatchExceptionTest
> + * @key intermittent
>  */
> public class CatchExceptionTest {
>     private static final List<Class<?>> ARGS_CLASSES;
> --- old/test/java/lang/ref/OOMEInReferenceHandler.java    2015-03-19 16:59:37.353243935 -0700
> +++ new/test/java/lang/ref/OOMEInReferenceHandler.java    2015-03-19 16:59:37.177243928 -0700
> @@ -27,6 +27,7 @@
>  * @summary Verify that the reference handler does not die after an OOME allocating the InterruptedException object
>  * @run main/othervm -XX:-UseGCOverheadLimit -Xmx24M -XX:-UseTLAB OOMEInReferenceHandler
>  * @author peter.levart at gmail.com
> + * @key intermittent
>  */
> 
> import java.lang.ref.*;
> --- old/test/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java 2015-03-19 16:59:37.805243951 -0700
> +++ new/test/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java 2015-03-19 16:59:37.625243945 -0700
> @@ -42,6 +42,7 @@
>  * @test
>  * @bug 8007373
>  * @summary jdk7 backward compatibility serialization problem
> + * @key intermittent
>  */
> 
> public class Inet6AddressSerializationTest {
> --- old/test/java/net/SocketPermission/SocketPermissionTest.java 2015-03-19 16:59:38.285243969 -0700
> +++ new/test/java/net/SocketPermission/SocketPermissionTest.java 2015-03-19 16:59:38.101243962 -0700
> @@ -27,6 +27,7 @@
>  * @summary SocketPermission tests for legacy socket types
>  * @library ../../../lib/testlibrary
>  * @run testng/othervm/policy=policy SocketPermissionTest
> + * @key intermittent
>  */
> import java.io.IOException;
> import java.net.DatagramPacket;
> --- old/test/java/nio/channels/AsynchronousSocketChannel/Basic.java 2015-03-19 16:59:38.741243986 -0700
> +++ new/test/java/nio/channels/AsynchronousSocketChannel/Basic.java 2015-03-19 16:59:38.557243979 -0700
> @@ -25,6 +25,7 @@
>  * @bug 4607272 6842687 6878369 6944810 7023403
>  * @summary Unit test for AsynchronousSocketChannel
>  * @run main Basic -skipSlowConnectTest
> + * @key intermittent
>  */
> 
> import java.nio.ByteBuffer;
> --- old/test/java/nio/channels/Selector/Wakeup.java    2015-03-19 16:59:39.201244003 -0700
> +++ new/test/java/nio/channels/Selector/Wakeup.java    2015-03-19 16:59:39.017243996 -0700
> @@ -25,6 +25,7 @@
>  * @bug 6405995
>  * @summary Unit test for selector wakeup and interruption
>  * @library ..
> + * @key intermittent
>  */
> 
> import java.io.*;
> --- old/test/java/nio/channels/ServerSocketChannel/AdaptServerSocket.java 2015-03-19 16:59:39.653244019 -0700
> +++ new/test/java/nio/channels/ServerSocketChannel/AdaptServerSocket.java 2015-03-19 16:59:39.473244013 -0700
> @@ -23,6 +23,7 @@
> 
> /* @test
>  * @summary Unit test for server-socket-channel adaptors
> + * @key intermittent
>  */
> 
> import java.io.*;
> --- old/test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh 2015-03-19 16:59:40.089244035 -0700
> +++ new/test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh 2015-03-19 16:59:39.909244029 -0700
> @@ -24,12 +24,12 @@
> #
> 
> # @test
> -# @bug 4673940
> -# @bug 4930794
> +# @bug 4673940 4930794
> # @summary Unit tests for inetd feature
> #
> # @build StateTest StateTestService EchoTest EchoService CloseTest Launcher Util
> # @run shell run_tests.sh
> +# @key intermittent
> 
> os=`uname -s`
> 
> --- old/test/java/nio/file/FileStore/Basic.java    2015-03-19 16:59:40.541244052 -0700
> +++ new/test/java/nio/file/FileStore/Basic.java    2015-03-19 16:59:40.357244045 -0700
> @@ -25,6 +25,7 @@
>  * @bug 4313887 6873621 6979526 7006126 7020517
>  * @summary Unit test for java.nio.file.FileStore
>  * @library ..
> + * @key intermittent
>  */
> 
> import java.nio.file.*;
> --- old/test/java/nio/file/Files/InterruptCopy.java    2015-03-19 16:59:40.973244068 -0700
> +++ new/test/java/nio/file/Files/InterruptCopy.java    2015-03-19 16:59:40.793244061 -0700
> @@ -25,6 +25,7 @@
>  * @bug 4313887 6993267
>  * @summary Unit test for Sun-specific ExtendedCopyOption.INTERRUPTIBLE option
>  * @library ..
> + * @key intermittent
>  */
> 
> import java.nio.file.*;
> --- old/test/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java 2015-03-19 16:59:41.413244084 -0700
> +++ new/test/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java 2015-03-19 16:59:41.237244078 -0700
> @@ -39,6 +39,7 @@
>  * @build TestLibrary RMID ActivateMe CheckActivateRef_Stub
>  * @run main/othervm/policy=security.policy/timeout=240 -Djava.rmi.server.ignoreStubClasses=true CheckActivateRef
>  * @run main/othervm/policy=security.policy/timeout=240 -Djava.rmi.server.ignoreStubClasses=false CheckActivateRef
> + * @key intermittent
>  */
> 
> import java.io.*;
> --- old/test/java/rmi/registry/interfaceHash/InterfaceHash.java 2015-03-19 16:59:41.865244101 -0700
> +++ new/test/java/rmi/registry/interfaceHash/InterfaceHash.java 2015-03-19 16:59:41.681244094 -0700
> @@ -38,6 +38,7 @@
>  * @library ../../testlibrary
>  * @build TestLibrary ReferenceRegistryStub
>  * @run main/othervm InterfaceHash
> + * @key intermittent
>  */
> 
> import java.lang.reflect.Constructor;
> --- old/test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java 2015-03-19 16:59:42.325244118 -0700
> +++ new/test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java 2015-03-19 16:59:42.141244111 -0700
> @@ -31,6 +31,7 @@
>  * @summary GC'ing objects whilst being exported to RMI should not cause exceptions
>  * @author Neil Richards <neil.richards at ngmr.net>, <neil_richards at uk.ibm.com>
>  * @run main/othervm GcDuringExport
> + * @key intermittent
>  */
> 
> import java.rmi.Remote;
> 


From mandy.chung at oracle.com  Fri Mar 20 02:53:02 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 19 Mar 2015 19:53:02 -0700
Subject: JDK 9 RFR of JDK-8075544: Add tiered testing definitions to the
	jdk repo
In-Reply-To: <550B1AE6.6070905@oracle.com>
References: <550B1AE6.6070905@oracle.com>
Message-ID: <550B8B8E.4020706@oracle.com>



On 3/19/2015 11:52 AM, joe darcy wrote:
> Hello,
>
> For background, please see the tiered testing proposal over at
>
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html
>
> The patch below adds "tier1" and "tier2" test definitions to the jdk 
> repository; webrev at
>
>     http://cr.openjdk.java.net/~darcy/8075544.0/

This looks good.  This changeset has been pushed which is fine. Just one 
quick comment.  Currently we can do:

$ make test-only TEST=jdk_lang

as test/Makefile takes jdk_% targets.  It may be useful to add tier1 and 
tier2 targets.

Mandy


From martinrb at google.com  Fri Mar 20 03:11:38 2015
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 19 Mar 2015 20:11:38 -0700
Subject: JDK 9 RFR of JDK-8075565: Define @intermittent jtreg keyword and
	mark intermittently failing jdk tests
In-Reply-To: <550B65E8.1050209@oracle.com>
References: <550B65E8.1050209@oracle.com>
Message-ID: <CA+kOe0_La6G5DX6Z-8cHDukZkV9t-95r4A4aZhuVn6AwS_-cLw@mail.gmail.com>

Seems like a good idea (but no one really does a good job on flaky tests).
Here at Google we like the word "flaky".


From joe.darcy at oracle.com  Fri Mar 20 03:59:32 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 19 Mar 2015 20:59:32 -0700
Subject: JDK 9 RFR of JDK-8075544: Add tiered testing definitions to the
	jdk repo
In-Reply-To: <550B8B8E.4020706@oracle.com>
References: <550B1AE6.6070905@oracle.com> <550B8B8E.4020706@oracle.com>
Message-ID: <550B9B24.9080608@oracle.com>

Hi Mandy,

I've filed an RFE for

     JDK-8075571: Support tier1 and tier2 make targets

Thanks,

-Joe

On 3/19/2015 7:53 PM, Mandy Chung wrote:
>
>
> On 3/19/2015 11:52 AM, joe darcy wrote:
>> Hello,
>>
>> For background, please see the tiered testing proposal over at
>>
>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html
>>
>> The patch below adds "tier1" and "tier2" test definitions to the jdk 
>> repository; webrev at
>>
>>     http://cr.openjdk.java.net/~darcy/8075544.0/
>
> This looks good.  This changeset has been pushed which is fine. Just 
> one quick comment.  Currently we can do:
>
> $ make test-only TEST=jdk_lang
>
> as test/Makefile takes jdk_% targets.  It may be useful to add tier1 
> and tier2 targets.
>
> Mandy



From joe.darcy at oracle.com  Fri Mar 20 04:16:54 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 19 Mar 2015 21:16:54 -0700
Subject: JDK 9 RFR of JDK-8075573: Add jdk_other and jdk_svc to jdk tier 2
	test definition
Message-ID: <550B9F36.1090306@oracle.com>

Hello,

Two test groups were inadvertently omitted from the definition of tier 2 
tests:

     JDK-8075573: Add jdk_other and jdk_svc to jdk tier 2 test definition

Please review the patch below to add them in.

Thanks,

-Joe

diff -r 85c0670dbf53 test/TEST.groups
--- a/test/TEST.groups    Thu Mar 19 18:38:26 2015 -0700
+++ b/test/TEST.groups    Thu Mar 19 21:14:27 2015 -0700
@@ -38,7 +38,9 @@
      :jdk_time \
      :jdk_security \
      :jdk_text \
-    :core_tools
+    :core_tools \
+    :jdk_other \
+    :jdk_svc

  ###############################################################################
  #



From mandy.chung at oracle.com  Fri Mar 20 04:59:55 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 19 Mar 2015 21:59:55 -0700
Subject: JDK 9 RFR of JDK-8075573: Add jdk_other and jdk_svc to jdk tier
	2 test definition
In-Reply-To: <550B9F36.1090306@oracle.com>
References: <550B9F36.1090306@oracle.com>
Message-ID: <550BA94B.40108@oracle.com>

Looks fine.

Mandy

On 3/19/2015 9:16 PM, joe darcy wrote:
> Hello,
>
> Two test groups were inadvertently omitted from the definition of tier 
> 2 tests:
>
>     JDK-8075573: Add jdk_other and jdk_svc to jdk tier 2 test definition
>
> Please review the patch below to add them in.
>
> Thanks,
>
> -Joe
>
> diff -r 85c0670dbf53 test/TEST.groups
> --- a/test/TEST.groups    Thu Mar 19 18:38:26 2015 -0700
> +++ b/test/TEST.groups    Thu Mar 19 21:14:27 2015 -0700
> @@ -38,7 +38,9 @@
>      :jdk_time \
>      :jdk_security \
>      :jdk_text \
> -    :core_tools
> +    :core_tools \
> +    :jdk_other \
> +    :jdk_svc
>
>  ############################################################################### 
>
>  #
>



From Alan.Bateman at oracle.com  Fri Mar 20 06:56:41 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 20 Mar 2015 06:56:41 +0000
Subject: JDK 9 RFR of JDK-8075565: Define @intermittent jtreg keyword
	and mark intermittently failing jdk tests
In-Reply-To: <550B65E8.1050209@oracle.com>
References: <550B65E8.1050209@oracle.com>
Message-ID: <550BC4A9.2030600@oracle.com>



On 20/03/2015 00:12, Joseph D. Darcy wrote:
> Hello,
>
> Per recent proposals 
> (http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html), 
> please review the change below for
>
>     JDK-8075565: Define @intermittent jtreg keyword and mark 
> intermittently failuring jdk tests
>     http://cr.openjdk.java.net/~darcy/8075565.0/
>
> which defines an "intermittent" keyword for use in jtreg tests and 
> then marks the initial rouges gallery of known or suspected 
> intermittently failing tests:
>
>     test/com/sun/jndi/ldap/LdapTimeoutTest.java
>     test/java/lang/invoke/MethodHandles/CatchExceptionTest.java
>     test/java/lang/ref/OOMEInReferenceHandler.java
> test/java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java
>     test/java/net/SocketPermission/SocketPermissionTest.java
>     test/java/nio/channels/AsynchronousSocketChannel/Basic.java
>     test/java/nio/channels/Selector/Wakeup.java
> test/java/nio/channels/ServerSocketChannel/AdaptServerSocket.java
> test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh
>     test/java/nio/file/FileStore/Basic.java
>     test/java/nio/file/Files/InterruptCopy.java
> test/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java 
>
>     test/java/rmi/registry/interfaceHash/InterfaceHash.java
> test/java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java
>
> I compiled the list by going through open test-related bugs in 
> core-libs components and a few other components. I'll send a follow-up 
> message to security-libs to get their sets marked. I generally tried 
> to only mark tests as intermittent if there was recent (six months old 
> or new) information about a failure. Therefore, this initial list is 
> not comprehensive and tests should have the keyword added as they are 
> observed to intermittently fail. Also, tests should have the keyword 
> removed if they are corrected to address the cause of the intermittent 
> failure!
>
> I verified
>
>     jtreg -l -k:intermittent
>
> selects the right number of tests.
>
> Full patch below.
>
Please hold on on this until folks get a chance to look at the reasons 
why the tests are getting this keyword. In at least some cases then the 
issues aren't test issues but infrastructure issues.

-Alan


From paul.sandoz at oracle.com  Fri Mar 20 08:48:21 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 20 Mar 2015 09:48:21 +0100
Subject: RFR 8075560 Typo in Javadoc for java.util.Optional.equals() 
Message-ID: <06EE2622-4376-4C5A-B4EF-9E2F95677929@oracle.com>

Hi,

The patch below fixes a silly typo in the JavaDoc of the Optional*.equals methods.

Paul.

--- a/src/java.base/share/classes/java/util/Optional.java	Mon Mar 16 17:44:34 2015 +0100
+++ b/src/java.base/share/classes/java/util/Optional.java	Fri Mar 20 09:36:13 2015 +0100
@@ -346,7 +346,7 @@
      * </ul>
      *
      * @param obj an object to be tested for equality
-     * @return {code true} if the other object is "equal to" this object
+     * @return {@code true} if the other object is "equal to" this object
      * otherwise {@code false}
      */
     @Override
diff -r 145ffc3b8533 src/java.base/share/classes/java/util/OptionalDouble.java
--- a/src/java.base/share/classes/java/util/OptionalDouble.java	Mon Mar 16 17:44:34 2015 +0100
+++ b/src/java.base/share/classes/java/util/OptionalDouble.java	Fri Mar 20 09:36:13 2015 +0100
@@ -244,7 +244,7 @@
      * </ul>
      *
      * @param obj an object to be tested for equality
-     * @return {code true} if the other object is "equal to" this object
+     * @return {@code true} if the other object is "equal to" this object
      * otherwise {@code false}
      */
     @Override
diff -r 145ffc3b8533 src/java.base/share/classes/java/util/OptionalInt.java
--- a/src/java.base/share/classes/java/util/OptionalInt.java	Mon Mar 16 17:44:34 2015 +0100
+++ b/src/java.base/share/classes/java/util/OptionalInt.java	Fri Mar 20 09:36:13 2015 +0100
@@ -244,7 +244,7 @@
      * </ul>
      *
      * @param obj an object to be tested for equality
-     * @return {code true} if the other object is "equal to" this object
+     * @return {@code true} if the other object is "equal to" this object
      * otherwise {@code false}
      */
     @Override
diff -r 145ffc3b8533 src/java.base/share/classes/java/util/OptionalLong.java
--- a/src/java.base/share/classes/java/util/OptionalLong.java	Mon Mar 16 17:44:34 2015 +0100
+++ b/src/java.base/share/classes/java/util/OptionalLong.java	Fri Mar 20 09:36:13 2015 +0100
@@ -244,7 +244,7 @@
      * </ul>
      *
      * @param obj an object to be tested for equality
-     * @return {code true} if the other object is "equal to" this object
+     * @return {@code true} if the other object is "equal to" this object
      * otherwise {@code false}
      */
     @Override



From Alan.Bateman at oracle.com  Fri Mar 20 08:50:27 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 20 Mar 2015 08:50:27 +0000
Subject: RFR 8075560 Typo in Javadoc for java.util.Optional.equals()
In-Reply-To: <06EE2622-4376-4C5A-B4EF-9E2F95677929@oracle.com>
References: <06EE2622-4376-4C5A-B4EF-9E2F95677929@oracle.com>
Message-ID: <550BDF53.3010504@oracle.com>

On 20/03/2015 08:48, Paul Sandoz wrote:
> Hi,
>
> The patch below fixes a silly typo in the JavaDoc of the Optional*.equals methods.
>
Looks fine.


From Alan.Bateman at oracle.com  Fri Mar 20 08:51:34 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 20 Mar 2015 08:51:34 +0000
Subject: JDK 9 RFR of JDK-8075573: Add jdk_other and jdk_svc to jdk tier
	2 test definition
In-Reply-To: <550B9F36.1090306@oracle.com>
References: <550B9F36.1090306@oracle.com>
Message-ID: <550BDF96.7070700@oracle.com>



On 20/03/2015 04:16, joe darcy wrote:
> Hello,
>
> Two test groups were inadvertently omitted from the definition of tier 
> 2 tests:
>
>     JDK-8075573: Add jdk_other and jdk_svc to jdk tier 2 test definition
>
> Please review the patch below to add them in.
I thought it was deliberate to omit these but no issue if you put these 
into tier 2 too.

-Alan.


From tomasz.kowalczewski at gmail.com  Fri Mar 20 09:34:24 2015
From: tomasz.kowalczewski at gmail.com (Tomasz Kowalczewski)
Date: Fri, 20 Mar 2015 10:34:24 +0100
Subject: String.contains(CharSequence) calls toString on argument
Message-ID: <CANTKXYnJozaibiGxpTL5bqeotq_76En=Z33MQ3bqiKR3Z8gwsw@mail.gmail.com>

Hello!

Current implementation of String.contains that accepts CharSequence calls
toString on it and passes resulting string to indexOf(String). This IMO
defeats the purpose of using CharSequences (that is to have a mutable
character buffer and not allocate unnecessary objects).

Is changing this a desirable development? It seems pretty straightforward
to port indexOf(String) to use CharSequence.

If all you need is patch then I can work on it (I have signed OCA) just
wanted to make sure it is not a futile work.

-- 
Regards,
Tomasz Kowalczewski


From paul.sandoz at oracle.com  Fri Mar 20 09:52:17 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 20 Mar 2015 10:52:17 +0100
Subject: RFR 8071667 : HashMap.computeIfAbsent() adds entry that
	HashMap.get() does not find.
In-Reply-To: <550B4E4D.5010500@oracle.com>
References: <5509BA01.6000709@oracle.com>
	<684AF3A3-4280-47B3-AA8D-64248C5DDA9A@oracle.com>
	<550B4E4D.5010500@oracle.com>
Message-ID: <AC534548-0FE0-4763-B535-2E1B8888EF66@oracle.com>


On Mar 19, 2015, at 11:31 PM, Brent Christian <brent.christian at oracle.com> wrote:

> Hi, Paul
> 
> Thank you for the suggested doc adjustments.  They're applied here:
> http://cr.openjdk.java.net/~bchristi/8071667/webrev.3/
> 

Looking good. 

Small point. We could clear up some inconsistency over using "the function" or the "the re/mapping function" to constantly use the later and call it that in the doc of the "re/mappingFunction" parameter.


> TestNG test update forthcoming.
> 

Ok.

Paul.


From claes.redestad at oracle.com  Fri Mar 20 11:34:06 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 20 Mar 2015 12:34:06 +0100
Subject: String.contains(CharSequence) calls toString on argument
In-Reply-To: <CANTKXYnJozaibiGxpTL5bqeotq_76En=Z33MQ3bqiKR3Z8gwsw@mail.gmail.com>
References: <CANTKXYnJozaibiGxpTL5bqeotq_76En=Z33MQ3bqiKR3Z8gwsw@mail.gmail.com>
Message-ID: <550C05AE.8060203@oracle.com>

Hi!

While enabling use of CharSequence would seem desirable, there are
some drawbacks that needs to be kept in mind:

- String.indexOf(String) and friends are typically intrinsified on 
String in
ways that might not port over well to other implementations of
CharSequence - there might not even be a performance benefit in
avoiding the allocation for some cases

- Even if the intrinsic behavior can be retained, widening to take
CharSequence opens up for profile pollution, which might inadvertently
cause regressions in existing code

Adding new methods alongside ones taking String could arguably
avoid these pitfalls, so I'm not saying it's entirely futile, but it 
might be
hard to ensure and prove that it adds enough performance benefits to
be worth the effort and increased maintenance burden.

Thanks!

/Claes

On 03/20/2015 10:34 AM, Tomasz Kowalczewski wrote:
> Hello!
>
> Current implementation of String.contains that accepts CharSequence calls
> toString on it and passes resulting string to indexOf(String). This IMO
> defeats the purpose of using CharSequences (that is to have a mutable
> character buffer and not allocate unnecessary objects).
>
> Is changing this a desirable development? It seems pretty straightforward
> to port indexOf(String) to use CharSequence.
>
> If all you need is patch then I can work on it (I have signed OCA) just
> wanted to make sure it is not a futile work.
>



From chris.hegarty at oracle.com  Fri Mar 20 11:40:18 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 20 Mar 2015 11:40:18 +0000
Subject: RFR 8071667 : HashMap.computeIfAbsent() adds entry that
	HashMap.get() does not find.
In-Reply-To: <AC534548-0FE0-4763-B535-2E1B8888EF66@oracle.com>
References: <5509BA01.6000709@oracle.com>
	<684AF3A3-4280-47B3-AA8D-64248C5DDA9A@oracle.com>
	<550B4E4D.5010500@oracle.com>
	<AC534548-0FE0-4763-B535-2E1B8888EF66@oracle.com>
Message-ID: <0B55C8F5-100B-4721-A09D-FE6D7811B038@oracle.com>


On 20 Mar 2015, at 09:52, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> 
> On Mar 19, 2015, at 11:31 PM, Brent Christian <brent.christian at oracle.com> wrote:
> 
>> Hi, Paul
>> 
>> Thank you for the suggested doc adjustments.  They're applied here:
>> http://cr.openjdk.java.net/~bchristi/8071667/webrev.3/
>> 
> 
> Looking good. 

Yes, the spec changes look good.

Brent, would you mind if I assign 8062841 [1] to you, so you can bring in the CHM implementation changes? Also maybe CHM could be added to the test?

> Small point. We could clear up some inconsistency over using "the function" or the "the re/mapping function" to constantly use the later and call it that in the doc of the "re/mappingFunction" parameter.
> 
> 
>> TestNG test update forthcoming.
>> 
> 
> Ok.

-Chris.

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



From tomasz.kowalczewski at gmail.com  Fri Mar 20 12:19:16 2015
From: tomasz.kowalczewski at gmail.com (Tomasz Kowalczewski)
Date: Fri, 20 Mar 2015 13:19:16 +0100
Subject: String.contains(CharSequence) calls toString on argument
In-Reply-To: <550C05AE.8060203@oracle.com>
References: <CANTKXYnJozaibiGxpTL5bqeotq_76En=Z33MQ3bqiKR3Z8gwsw@mail.gmail.com>
	<550C05AE.8060203@oracle.com>
Message-ID: <CANTKXYmnV0HPUM=mEWw4OfrL1WM-=YVnwgdeegw5v+ck5TR+1Q@mail.gmail.com>

Thank you, that is the kind of feedback I need!

I have also asked myself this question. Changing indexOf to accept
CharSequence is the most intrusive move. Safest way is to just implement
contains in a different way (taking code from indexOf) but adding
indexOf(CharSequence) might provide more value for other use cases.

According to Aleksey Shipilev (
https://twitter.com/shipilev/status/560065173407662080)
String.indexOf(String) compiles to single asm instruction. On the other
hand this instruction is not available on most processors (citation needed)
and I would love to know what is the actual performance of it. Avoiding
this one allocation for some applications that work with text might just
make difference between well behaving application and one that is 'flaky'
due to GC. This may be viewed as the 'consistent performance' vs. 'most
time fast few times terribly slow' tradeoff.

Thanks!
Tomasz Kowalczewski

On Fri, Mar 20, 2015 at 12:34 PM, Claes Redestad <claes.redestad at oracle.com>
wrote:

> Hi!
>
> While enabling use of CharSequence would seem desirable, there are
> some drawbacks that needs to be kept in mind:
>
> - String.indexOf(String) and friends are typically intrinsified on String
> in
> ways that might not port over well to other implementations of
> CharSequence - there might not even be a performance benefit in
> avoiding the allocation for some cases
>
> - Even if the intrinsic behavior can be retained, widening to take
> CharSequence opens up for profile pollution, which might inadvertently
> cause regressions in existing code
>
> Adding new methods alongside ones taking String could arguably
> avoid these pitfalls, so I'm not saying it's entirely futile, but it might
> be
> hard to ensure and prove that it adds enough performance benefits to
> be worth the effort and increased maintenance burden.
>
> Thanks!
>
> /Claes
>
>
> On 03/20/2015 10:34 AM, Tomasz Kowalczewski wrote:
>
>> Hello!
>>
>> Current implementation of String.contains that accepts CharSequence calls
>> toString on it and passes resulting string to indexOf(String). This IMO
>> defeats the purpose of using CharSequences (that is to have a mutable
>> character buffer and not allocate unnecessary objects).
>>
>> Is changing this a desirable development? It seems pretty straightforward
>> to port indexOf(String) to use CharSequence.
>>
>> If all you need is patch then I can work on it (I have signed OCA) just
>> wanted to make sure it is not a futile work.
>>
>>
>


-- 
Tomasz Kowalczewski


From aleksey.shipilev at oracle.com  Fri Mar 20 12:28:10 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 20 Mar 2015 15:28:10 +0300
Subject: String.contains(CharSequence) calls toString on argument
In-Reply-To: <CANTKXYmnV0HPUM=mEWw4OfrL1WM-=YVnwgdeegw5v+ck5TR+1Q@mail.gmail.com>
References: <CANTKXYnJozaibiGxpTL5bqeotq_76En=Z33MQ3bqiKR3Z8gwsw@mail.gmail.com>	<550C05AE.8060203@oracle.com>
	<CANTKXYmnV0HPUM=mEWw4OfrL1WM-=YVnwgdeegw5v+ck5TR+1Q@mail.gmail.com>
Message-ID: <550C125A.40701@oracle.com>

Hi,

On 03/20/2015 03:19 PM, Tomasz Kowalczewski wrote:
> Thank you, that is the kind of feedback I need!

Claes' feedback is spot on. While the change might help, be prepared
that performance research in the area covered by compiler intrinsics is
hard.

> I have also asked myself this question. Changing indexOf to accept
> CharSequence is the most intrusive move. Safest way is to just implement
> contains in a different way (taking code from indexOf) but adding
> indexOf(CharSequence) might provide more value for other use cases.

Dunno. I think we can fold special cases of indexOf(CharSequence) into
the intrinsic as well. I wonder if the change is "only" about
specializing indexOf(CharSequence) on the Java side to shortcut to
indexOf(String) and others, like String.contentEquals(CharSequence)
already does.

> According to Aleksey Shipilev (
> https://twitter.com/shipilev/status/560065173407662080)
> String.indexOf(String) compiles to single asm instruction. 

Yes, the image prefix search is compiled down to that. With large image,
you first search the prefix with vectorized insns, and the check the rest.

-Aleksey.



From aleksey.shipilev at oracle.com  Fri Mar 20 12:31:58 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 20 Mar 2015 15:31:58 +0300
Subject: String.contains(CharSequence) calls toString on argument
In-Reply-To: <550C125A.40701@oracle.com>
References: <CANTKXYnJozaibiGxpTL5bqeotq_76En=Z33MQ3bqiKR3Z8gwsw@mail.gmail.com>	<550C05AE.8060203@oracle.com>
	<CANTKXYmnV0HPUM=mEWw4OfrL1WM-=YVnwgdeegw5v+ck5TR+1Q@mail.gmail.com>
	<550C125A.40701@oracle.com>
Message-ID: <550C133E.5070500@oracle.com>

On 03/20/2015 03:28 PM, Aleksey Shipilev wrote:
> I wonder if the change is "only" about specializing
> indexOf(CharSequence) on the Java side to shortcut to indexOf(String)
> and others, like String.contentEquals(CharSequence) already does.

Ah, sorry for the confusion, contains(CharSequence) already
"specializes" via shortcut in

  String toString() {
      return this;
  }

  public boolean contains(CharSequence s) {
     return indexOf(s.toString()) > -1;
  }

So the question is about StringBuffers/StringBuilders then?

-Aleksey.



From tomasz.kowalczewski at gmail.com  Fri Mar 20 12:41:25 2015
From: tomasz.kowalczewski at gmail.com (Tomasz Kowalczewski)
Date: Fri, 20 Mar 2015 13:41:25 +0100
Subject: String.contains(CharSequence) calls toString on argument
In-Reply-To: <550C133E.5070500@oracle.com>
References: <CANTKXYnJozaibiGxpTL5bqeotq_76En=Z33MQ3bqiKR3Z8gwsw@mail.gmail.com>
	<550C05AE.8060203@oracle.com>
	<CANTKXYmnV0HPUM=mEWw4OfrL1WM-=YVnwgdeegw5v+ck5TR+1Q@mail.gmail.com>
	<550C125A.40701@oracle.com> <550C133E.5070500@oracle.com>
Message-ID: <CANTKXYmWpsdorJMdKHKoZNsP9knr1EWzmkdyofdQ1fNvZuXgcQ@mail.gmail.com>

It is more about custom implementations of CharSuqence that may be backed
by some exotic matter and calling toString on them to create actual String
goes against purpose of CharSequence in the first place (esp. when passing
it to a method that accepts CharSequence). For JDK user it is easy to avoid
calling contains and roll his/her own implementation but it would be nice
if we can avoid such surprises.


On Fri, Mar 20, 2015 at 1:31 PM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> On 03/20/2015 03:28 PM, Aleksey Shipilev wrote:
> > I wonder if the change is "only" about specializing
> > indexOf(CharSequence) on the Java side to shortcut to indexOf(String)
> > and others, like String.contentEquals(CharSequence) already does.
>
> Ah, sorry for the confusion, contains(CharSequence) already
> "specializes" via shortcut in
>
>   String toString() {
>       return this;
>   }
>
>   public boolean contains(CharSequence s) {
>      return indexOf(s.toString()) > -1;
>   }
>
> So the question is about StringBuffers/StringBuilders then?
>
> -Aleksey.
>
>


-- 
Tomasz Kowalczewski


From vitalyd at gmail.com  Fri Mar 20 12:45:47 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 20 Mar 2015 08:45:47 -0400
Subject: String.contains(CharSequence) calls toString on argument
In-Reply-To: <CANTKXYmWpsdorJMdKHKoZNsP9knr1EWzmkdyofdQ1fNvZuXgcQ@mail.gmail.com>
References: <CANTKXYnJozaibiGxpTL5bqeotq_76En=Z33MQ3bqiKR3Z8gwsw@mail.gmail.com>
	<550C05AE.8060203@oracle.com>
	<CANTKXYmnV0HPUM=mEWw4OfrL1WM-=YVnwgdeegw5v+ck5TR+1Q@mail.gmail.com>
	<550C125A.40701@oracle.com> <550C133E.5070500@oracle.com>
	<CANTKXYmWpsdorJMdKHKoZNsP9knr1EWzmkdyofdQ1fNvZuXgcQ@mail.gmail.com>
Message-ID: <CAHjP37FVESTfKGFyS=2ZrOO8e7+R+bgmvyxD1c7jJY4H3YBrTw@mail.gmail.com>

I agree.  Adding a new method that doesn't toString the CS would be
desirable.  In these special cases, it's perfectly fine if there's no
string intrinsic that kicks in (and thus the actual operation is a bit
slower) -- the goal is to avoid the allocation.

On Fri, Mar 20, 2015 at 8:41 AM, Tomasz Kowalczewski <
tomasz.kowalczewski at gmail.com> wrote:

> It is more about custom implementations of CharSuqence that may be backed
> by some exotic matter and calling toString on them to create actual String
> goes against purpose of CharSequence in the first place (esp. when passing
> it to a method that accepts CharSequence). For JDK user it is easy to avoid
> calling contains and roll his/her own implementation but it would be nice
> if we can avoid such surprises.
>
>
> On Fri, Mar 20, 2015 at 1:31 PM, Aleksey Shipilev <
> aleksey.shipilev at oracle.com> wrote:
>
> > On 03/20/2015 03:28 PM, Aleksey Shipilev wrote:
> > > I wonder if the change is "only" about specializing
> > > indexOf(CharSequence) on the Java side to shortcut to indexOf(String)
> > > and others, like String.contentEquals(CharSequence) already does.
> >
> > Ah, sorry for the confusion, contains(CharSequence) already
> > "specializes" via shortcut in
> >
> >   String toString() {
> >       return this;
> >   }
> >
> >   public boolean contains(CharSequence s) {
> >      return indexOf(s.toString()) > -1;
> >   }
> >
> > So the question is about StringBuffers/StringBuilders then?
> >
> > -Aleksey.
> >
> >
>
>
> --
> Tomasz Kowalczewski
>


From peter.firmstone at zeus.net.au  Fri Mar 20 10:49:41 2015
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Fri, 20 Mar 2015 20:49:41 +1000
Subject: Fw: Re: RFR [9] 8071472: Add field access to support setting final
	fields in readObject
Message-ID: <1426848581.5115.5.camel@Nokia-N900>

----- Original message -----
>From Peter Levart <peter.levart at gmail.com>
Sent?  Fri, 20 Mar 2015, 01:21:17 EST
To Peter Firmstone <peter.firmstone at zeus.net.au>, core-libs-dev at openjdk.java.net
Subject Re: RFR [9] 8071472: Add field access to support setting final fields in readObject

> On 03/19/2015 11:35 AM, Peter Firmstone wrote:
> > Chris / Peter,
> > 
> > Perhaps you could consider passing GetFields as a parameter to a 
> > static method (identified by an annotation) and use fieldSetter to 
> > change the fields before they're written?
> 
> Or change the fields *as* they are written. It actually doesn't matter 
> if the method is static.
> 
> > 
> > That way it would be possible to not only avoid implementing 
> > readObject or writeObject, but to check invariants and be final field 
> > friendly.
> > 
> > Just a thought.
> > 
> > Peter.
> 
> So you mean something like this or a variant of it. Instead of 
> readObject() instance method, a static method with an additional 
> FieldAccess parameter:
> 
> @ReadObject
> private static void altReadObject(ObjectInputStream in, FieldAccess 
> fieldAccess) throws IOException, ClassNotFoundException {
>? ? ? ? ?  // the same as in readObject, but doesn't have direct access to 
> instance state, so everything must go through FieldAccess API?
> }
> 
> 

Yes.

> That's interesting. When operating with FieldSetter API or when calling 
> ObjectInputStream methods, one actually doesn't need an instance 
> context, since it is hidden behind the ObjectInputStream/FieldAccess 
> objects, so the @ReadObject method could be static, which would prevent 
> undesirable direct access to fields (finals in particular).
> 
> One thing you couldn't do this way is to check the invariants that 
> involve superclass' state that has already been deserialized.
> 
> But if you don't need that, this could be an alrernative readObject() 
> method. Very easy to implement, actually.
> 
> 
> Regards, Peter
> 

If you take it one step further, provided the superclass isn't abstract, the api can create a superclass instance that provides api access to superclass state, allowing intraclass invariants to be checked too.

This provides the same benefits as a constructor, without the implementation effort.

Peter.

> > 
> > 
> > > ------------------------------
> > > 
> > > Message: 5
> > > Date: Wed, 18 Mar 2015 11:06:56 +0000
> > > From: Chris Hegarty<chris.hegarty at oracle.com>
> > > To: Alan Bateman<Alan.Bateman at oracle.com>,? ? ?  Peter Levart
> > > <peter.levart at gmail.com>
> > > Cc: Core-Libs-Dev Libs<core-libs-dev at openjdk.java.net>
> > > Subject: Re: RFR [9] 8071472: Add field access to support setting
> > > final fields? ? ?  in readObject
> > > Message-ID:<55095C50.3010605 at oracle.com>
> > > Content-Type: text/plain; charset=windows-1252; format=flowed
> > > 
> > > On 17/03/15 13:42, Alan Bateman wrote:
> > > > On 17/03/2015 12:21, Peter Levart wrote:
> > > > > Hi Alan,
> > > > > 
> > > > > I agree that not calling defaultReadObject() from readObject() and
> > > > > having a final field is potentially a bug. But need not be in case
> > > > > some other means of setting final fields was used (Unsafe or
> > > > > reflection). Some readObject() implementations in base module that
> > > > > Chris changed to use new API fall into this category. We can't track
> > > > > those usages, so to keep backwards compatibility, this checking has to
> > > > > be opt-in. Is there a more elegant way to opt-in? A
> > > > > @CheckFinalsAssignment annotation on the readObject() method?
> > > > I'm not sure that an annotation is right here. Instead then it might
> > > > work as a method on FieldSetter to enable strict checking.
> > > Peter suggested a method on FieldSetter to enable strict checking before
> > > too, and at the time I pushed back. After this discussion, I've come
> > > full circle, and maybe this opt-in style method is a reasonable
> > > compromise. Something like:
> > > 
> > > /**
> > > * Checks that all final instance fields, declared by the class where
> > > * the {@code readObject} callback is being invoked, have been set.
> > > *
> > > *<p>?  This method is intended to be called as a final step after all
> > > * final instance fields have been set.
> > > *
> > > * @throws InvalidObjectException if one, or more, final instance
> > > *? ? ? ? ? ? ? ?  fields have not been set
> > > */
> > > void checkAllFinalsSet() throws InvalidObjectException;
> > > 
> > > 
> > > ...and the user code would look similar to this, from java.io.File:
> > > 
> > > s.fieldSetter().set("path", p)
> > > .set("prefixLength", pLen)
> > > .checkAllFinalsSet();
> > > 
> > > -Chris.
> > > 
> > > 
> > > 
> > > 
> > > End of core-libs-dev Digest, Vol 95, Issue 54
> > > *********************************************
> > 
> 



From david.lloyd at redhat.com  Fri Mar 20 13:03:49 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 20 Mar 2015 08:03:49 -0500
Subject: Fw: Re: RFR [9] 8071472: Add field access to support setting
	final fields in readObject
In-Reply-To: <1426848581.5115.5.camel@Nokia-N900>
References: <1426848581.5115.5.camel@Nokia-N900>
Message-ID: <550C1AB5.4020801@redhat.com>

On 03/20/2015 05:49 AM, Peter Firmstone wrote:
> ----- Original message -----
>  From Peter Levart <peter.levart at gmail.com>
> Sent   Fri, 20 Mar 2015, 01:21:17 EST
> To Peter Firmstone <peter.firmstone at zeus.net.au>, core-libs-dev at openjdk.java.net
> Subject Re: RFR [9] 8071472: Add field access to support setting final fields in readObject
>
>> On 03/19/2015 11:35 AM, Peter Firmstone wrote:
>>> Chris / Peter,
>>>
>>> Perhaps you could consider passing GetFields as a parameter to a
>>> static method (identified by an annotation) and use fieldSetter to
>>> change the fields before they're written?
>>
>> Or change the fields *as* they are written. It actually doesn't matter
>> if the method is static.
>>
>>>
>>> That way it would be possible to not only avoid implementing
>>> readObject or writeObject, but to check invariants and be final field
>>> friendly.
>>>
>>> Just a thought.
>>>
>>> Peter.
>>
>> So you mean something like this or a variant of it. Instead of
>> readObject() instance method, a static method with an additional
>> FieldAccess parameter:
>>
>> @ReadObject
>> private static void altReadObject(ObjectInputStream in, FieldAccess
>> fieldAccess) throws IOException, ClassNotFoundException {
>>             // the same as in readObject, but doesn't have direct access to
>> instance state, so everything must go through FieldAccess API?
>> }
>>
>>
>
> Yes.

An interesting aspect of this approach is that it deals with a problem 
in the serialization spec [1] where it specifically says that 
serializable classes should be reading/writing stream fields always, and 
before reading/writing other data:

In section 3.4: "Either ObjectInputStream's defaultReadObject or 
readFields method must be called once (and only once) before reading any 
optional data written by the corresponding writeObject method; even if 
no optional data is read, defaultReadObject or readFields must still be 
invoked once."

In section 2.3: "Either ObjectOutputStream's defaultWriteObject or 
writeFields method must be called once (and only once) before writing 
any optional data that will be needed by the corresponding readObject 
method to restore the state of the object; even if no optional data is 
written, defaultWriteObject or writeFields must still be invoked once."

But classes (even JDK classes) often disregard this requirement, relying 
on known implementation behavior and either reading/writing optional 
data before fields or just not reading/writing fields at all.  So either 
the spec should be updated (I've tried to do this but nobody seems to 
know how to modify this old content I guess) to match behavior, or the 
spec should be enforced more strictly - however doing the latter *will* 
break a lot of user code, *unless* an alternative readObject method is 
introduced with the more strict enforcement.  But I guess even in this 
case, the spec should be updated to allow the implementation behavior.

[1] 
http://docs.oracle.com/javase/8/docs/platform/serialization/spec/serialTOC.html

>> That's interesting. When operating with FieldSetter API or when calling
>> ObjectInputStream methods, one actually doesn't need an instance
>> context, since it is hidden behind the ObjectInputStream/FieldAccess
>> objects, so the @ReadObject method could be static, which would prevent
>> undesirable direct access to fields (finals in particular).
>>
>> One thing you couldn't do this way is to check the invariants that
>> involve superclass' state that has already been deserialized.
>>
>> But if you don't need that, this could be an alrernative readObject()
>> method. Very easy to implement, actually.
>>
>>
>> Regards, Peter
>>
>
> If you take it one step further, provided the superclass isn't abstract, the api can create a superclass instance that provides api access to superclass state, allowing intraclass invariants to be checked too.
>
> This provides the same benefits as a constructor, without the implementation effort.
>
> Peter.
>
>>>
>>>
>>>> ------------------------------
>>>>
>>>> Message: 5
>>>> Date: Wed, 18 Mar 2015 11:06:56 +0000
>>>> From: Chris Hegarty<chris.hegarty at oracle.com>
>>>> To: Alan Bateman<Alan.Bateman at oracle.com>,       Peter Levart
>>>> <peter.levart at gmail.com>
>>>> Cc: Core-Libs-Dev Libs<core-libs-dev at openjdk.java.net>
>>>> Subject: Re: RFR [9] 8071472: Add field access to support setting
>>>> final fields       in readObject
>>>> Message-ID:<55095C50.3010605 at oracle.com>
>>>> Content-Type: text/plain; charset=windows-1252; format=flowed
>>>>
>>>> On 17/03/15 13:42, Alan Bateman wrote:
>>>>> On 17/03/2015 12:21, Peter Levart wrote:
>>>>>> Hi Alan,
>>>>>>
>>>>>> I agree that not calling defaultReadObject() from readObject() and
>>>>>> having a final field is potentially a bug. But need not be in case
>>>>>> some other means of setting final fields was used (Unsafe or
>>>>>> reflection). Some readObject() implementations in base module that
>>>>>> Chris changed to use new API fall into this category. We can't track
>>>>>> those usages, so to keep backwards compatibility, this checking has to
>>>>>> be opt-in. Is there a more elegant way to opt-in? A
>>>>>> @CheckFinalsAssignment annotation on the readObject() method?
>>>>> I'm not sure that an annotation is right here. Instead then it might
>>>>> work as a method on FieldSetter to enable strict checking.
>>>> Peter suggested a method on FieldSetter to enable strict checking before
>>>> too, and at the time I pushed back. After this discussion, I've come
>>>> full circle, and maybe this opt-in style method is a reasonable
>>>> compromise. Something like:
>>>>
>>>> /**
>>>> * Checks that all final instance fields, declared by the class where
>>>> * the {@code readObject} callback is being invoked, have been set.
>>>> *
>>>> *<p>   This method is intended to be called as a final step after all
>>>> * final instance fields have been set.
>>>> *
>>>> * @throws InvalidObjectException if one, or more, final instance
>>>> *                 fields have not been set
>>>> */
>>>> void checkAllFinalsSet() throws InvalidObjectException;
>>>>
>>>>
>>>> ...and the user code would look similar to this, from java.io.File:
>>>>
>>>> s.fieldSetter().set("path", p)
>>>> .set("prefixLength", pLen)
>>>> .checkAllFinalsSet();
>>>>
>>>> -Chris.
>>>>
>>>>
>>>>
>>>>
>>>> End of core-libs-dev Digest, Vol 95, Issue 54
>>>> *********************************************
>>>
>>
>

-- 
- DML


From peter.levart at gmail.com  Fri Mar 20 14:06:49 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 20 Mar 2015 15:06:49 +0100
Subject: RFR [9] 8071474: Better failure atomicity for default read object
In-Reply-To: <550B3F21.6020206@oracle.com>
References: <550B3F21.6020206@oracle.com>
Message-ID: <550C2979.9090407@gmail.com>

On 03/19/2015 10:26 PM, Chris Hegarty wrote:
> The current implementation of defaultReadObject sets non-primitive 
> field values one at a time, without first checking that all their 
> types are assignable. If, for example, the assignment of the last 
> non-primitive value fails, a CCE is thrown, and the previously set 
> fields remain set. The setting of field values, including primitives, 
> can be deferred until after they have been "validated", at a minimum 
> that the non-primitive types are assignable. This is achievable per 
> Class in the hierarchy up until the first user visible affect, i.e. a 
> readObject(NoData) method. Either all fields will be set, or contain 
> their default values.
>
> http://cr.openjdk.java.net/~chegar/8071474/webrev.00/webrev/
>
> I think there are further improvements that can be made in this area, 
> but I would like to move things forward incrementally.
>
> -Chris.

Hi Chris,

I'd just ask you a few questions to confirm my understanding of the code:

In ObjectInputStream:

1886         // Best effort Failure Atomicity; Each element in 
'slotFieldValues'
1887         // contains the stream field values for the same element in 
'slots',
1888         // up to the first slot with a readObject(NoData) method ( 
a user
1889         // visible effect ).
1890         int index = 1;
1891         for (; index < slots.length; index++) {
1892             ObjectStreamClass slotDesc = slots[index].desc;
1893             if (slotDesc.hasReadObjectMethod()
1894                 || slotDesc.hasReadObjectNoDataMethod()) {
1895                 break;
1896             }
1897         }
1898         // Store, and defer setting, values for index slots, ignore 
if just one.
1899         StreamFieldValues[] slotFieldValues = null;
1900         if (index > 1 && obj != null)
1901             slotFieldValues =  new StreamFieldValues[index];


...you scan slots starting from 1 and up. Is this because slots[0] is an 
uninteresting slot that belongs to j.l.Object class?

In this loop, you scan slots from 0 and up. Is this to catch corrupted 
streams that contain data for Object slot?

1971     /** Sets slot field values in the given obj. */
1972     private void setSlotFieldValues(Object obj,
1973 ObjectStreamClass.ClassDataSlot[] slots,
1974                                     StreamFieldValues[] 
slotFieldValues) {
1975         int length = slotFieldValues.length;
1976         for (int i = 0; i < length; i++) {
1977             if (slotFieldValues[i] != null)
1978                 defaultSetFieldValues(obj, slots[i].desc, 
slotFieldValues[i]);
1979         }
1980     }

I agree that this is an incremental improvement. You buffer values read 
from stream, check their types and delay setting them in particular 
class slots for classes not declaring  readObject[NoData] methods (or a 
span of slots in hierarchy ranging from Object to one before the class 
that declares readObject[NoData] method) which guarantees either success 
or atomic failure.

But have you considered a strategy that we discussed before where you 
would allow gradual building of state in object being deserialized and 
in case this fails anywhere (even in class slots declaring 
readObject[NoData] method), you roll-back the state (setting fields to 
default values) in all class slots from the one throwing an exception 
down to the 1st non-Serializable superclass (or Object). This would 
cover failure atomicity for the whole object, not just the slots not 
declaring readObject[NoData] methods. The premise is that 
deserialization starts with an uninitialized object (just class slots 
from 1st non-Serializable superclass down to Object are initialized by 
default accessible constructor). So rolling back the object to this 
state can be achieved by setting all instance fields of Serializable 
class slots to default values. A package-private 
FieldSetterContext.FieldsMap could be reused for this purpose (by adding 
a resetAllFields(Object obj) method). The FieldsMap instance is 
obtainable from ObjectStreamClass.getFieldAccessMap() which caches it 
(although internal, these type and method need renaming).

If you think this is a promising alternative to your failure atomicity 
proposal, I volunteer to add resetAllFields() method. I understand that 
this can only be added as part or on the top of FieldSetter API proposal.

Regards, Peter



From peter.levart at gmail.com  Fri Mar 20 14:31:54 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 20 Mar 2015 15:31:54 +0100
Subject: Fw: Re: RFR [9] 8071472: Add field access to support setting
	final fields in readObject
In-Reply-To: <550C1AB5.4020801@redhat.com>
References: <1426848581.5115.5.camel@Nokia-N900> <550C1AB5.4020801@redhat.com>
Message-ID: <550C2F5A.8030407@gmail.com>

On 03/20/2015 02:03 PM, David M. Lloyd wrote:
>>>
>>> private static void altReadObject(ObjectInputStream in, FieldAccess
>>> fieldAccess) throws IOException, ClassNotFoundException {
>>>             // the same as in readObject, but doesn't have direct 
>>> access to
>>> instance state, so everything must go through FieldAccess API?
>>> }
>>>
>>>
>>
>> Yes.
>
> An interesting aspect of this approach is that it deals with a problem 
> in the serialization spec [1] where it specifically says that 
> serializable classes should be reading/writing stream fields always, 
> and before reading/writing other data:
>
> In section 3.4: "Either ObjectInputStream's defaultReadObject or 
> readFields method must be called once (and only once) before reading 
> any optional data written by the corresponding writeObject method; 
> even if no optional data is read, defaultReadObject or readFields must 
> still be invoked once."
>
> In section 2.3: "Either ObjectOutputStream's defaultWriteObject or 
> writeFields method must be called once (and only once) before writing 
> any optional data that will be needed by the corresponding readObject 
> method to restore the state of the object; even if no optional data is 
> written, defaultWriteObject or writeFields must still be invoked once."
>
> But classes (even JDK classes) often disregard this requirement, 
> relying on known implementation behavior and either reading/writing 
> optional data before fields or just not reading/writing fields at 
> all.  So either the spec should be updated (I've tried to do this but 
> nobody seems to know how to modify this old content I guess) to match 
> behavior, or the spec should be enforced more strictly - however doing 
> the latter *will* break a lot of user code, *unless* an alternative 
> readObject method is introduced with the more strict enforcement.  But 
> I guess even in this case, the spec should be updated to allow the 
> implementation behavior.
>
> [1] 
> http://docs.oracle.com/javase/8/docs/platform/serialization/spec/serialTOC.html 
>

I guess this would need an alternative writeObject method too, with more 
strict enforcement, or not?

I don't know from the top of my head, but does the order of writing 
optional data (before or after) fields, change the order of data emitted 
in stream and does that order have to be respected when reading back in 
readObject()? In that case, I guess, we would need an alternative 
writeObject method too, with more strict enforcement of order. But I 
think that having two different rules for old read/writeObject and 
alternative read/writeObject would just confuse people. If current rules 
don't present any problem (apart from being looser then specification 
requires) then perhaps just specification should be updated.

Regards, Peter


From mikhail.cherkasov at oracle.com  Fri Mar 20 15:04:29 2015
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Fri, 20 Mar 2015 18:04:29 +0300
Subject: [8] RFR of 8066985: Java Webstart downloading packed files can
	result in Timezone set to UTC
In-Reply-To: <550AF969.7070706@gmail.com>
References: <550976B9.6030503@oracle.com> <5509F73C.6000306@oracle.com>
	<550AD4C9.9030905@oracle.com> <550AEF48.4070904@gmail.com>
	<550AF969.7070706@gmail.com>
Message-ID: <550C36FD.701@oracle.com>


On 3/19/2015 7:29 PM, Peter Levart wrote:
> On 03/19/2015 04:46 PM, Peter Levart wrote:
>> On 03/19/2015 02:53 PM, Kumar Srinivasan wrote:
>>> Mikhail,
>>>
>>> You can move the common utilitieschangeDefaultTimeZoneToUtc and
>>> restoreDefaultTimeZoneto Utils.java.
>>>
>>> Also I am not sure how effective the test is ?  does it catch the 
>>> issue ?
>>> if you don't have the fix in PackerImpl and UnpackerImpl ?
>>>
>>> Otherwise it looks good, and I can sponsor this patch for you.
>>>
>>> Kumar
>>
>> Hi Mikhail,
>>
>> Is this code part of some utility so that it is executed exclusively 
>> in it's own JVM, or can it also be executed by some public API or 
>> internal JVM thread? It appears to be the later (used by 
>> java.util.jar.Pack200 public API), but haven't checked.
>>
>> In case of the later, I think it is very strange that the code 
>> changes global JVM timezone, albeit just temporarily. This could 
>> affect other code that needs default TZ and executes concurrently.
>>
>> Even in case of the former, if the PackerImpl.pack can be executed by 
>> multiple concurrent threads and if UnpackerImpl.unpack can be 
>> executed by multiple concurrent threads, what guarantees that some 
>> PackerImpl.pack thread is not executed concurrently with some 
>> UnpackerImpl.unpack thread? You only track each method separately.
Agree, I'll move changeDefaultTimeZoneToUtc and restoreDefaultTimeZone 
to Util class, so TZ changes will be managed in one place  for both 
PackerImpl and UnpackerImpl classes.

NonPack200 threads that reads/writes DTZ can collide with Pack200, but 
there's other bug that should fix this: 
https://bugs.openjdk.java.net/browse/JDK-8073187

My fix is only for jdk8 and 7, and it focused on making packer/unpacker 
safe for concurrent use,  because now applets and JNLP uses 
packer/unpacker concurrently and this can
lead to DTZ changing to UTC.

>>
>>
>> Regards, Peter
>
> I guess this default TZ manipulation is needed because 
> JarOutputStream/JarInputStream don't provide constructors that would 
> take a TZ object, but always use default TZ, right?
>
> The cleanest way would be to add such constructors, but if this is too 
> much for 8u, then perhaps some internal ThreadLocal<TZ> could be 
> exposed to both PackerImpl/UnpackerImpl and Jar[Zip]Input[Output] 
> stream internals. It think the use of default TZ in Jar/Zip/Streams is 
> very localized. It is needed to convert local time (specified as DOS 
> time) to and from epoch-based time exposed in ZipEntry. The code is 
> located in package-private class java.util.zip.ZipUtils in methods 
> dosToJavaTime /javaToDosTime (or equivalent extendedDosToJavaTime / 
> javaToExtendedDosTime in JDK9).
all solutions that you described require introducing a new API and this 
can not be done for jdk7 and 8, so that's why JDK-8073187 was created.
The main purpose of this fix is to make packed jars delivery save for 
applets/jnlp application.

>
> Another way would be to provide a general thread-local default TZ 
> override in TimeZone itself. Something like the following:
>
> ===================================================================
> --- jdk/src/share/classes/java/util/TimeZone.java
> +++ jdk/src/share/classes/java/util/TimeZone.java
> @@ -630,8 +630,11 @@
>       * method doesn't create a clone.
>       */
>      static TimeZone getDefaultRef() {
> -        TimeZone defaultZone = defaultTimeZone;
> +        TimeZone defaultZone = threadLocalTimeZone.get();
>          if (defaultZone == null) {
> +            defaultZone = defaultTimeZone;
> +        }
> +        if (defaultZone == null) {
>              // Need to initialize the default time zone.
>              defaultZone = setDefaultZone();
>              assert defaultZone != null;
> @@ -713,6 +716,20 @@
>          defaultTimeZone = zone;
>      }
>
> +    public void withThreadDefaultDo(Runnable runnable) {
> +        TimeZone prevZone = threadLocalTimeZone.get();
> +        threadLocalTimeZone.set(this);
> +        try {
> +            runnable.run();
> +        } finally {
> +            if (prevZone == null) {
> +                threadLocalTimeZone.remove();
> +            } else {
> +                threadLocalTimeZone.set(prevZone);
> +            }
> +        }
> +    }
> +
>      /**
>       * Returns true if this zone has the same rule and offset as 
> another zone.
>       * That is, if this zone differs only in ID, if at all.  Returns 
> false
> @@ -760,6 +777,8 @@
>       */
>      private String           ID;
>      private static volatile TimeZone defaultTimeZone;
> +    private static final ThreadLocal<TimeZone> threadLocalTimeZone =
> +        new ThreadLocal<>();
>
>      static final String         GMT_ID        = "GMT";
>      private static final int    GMT_ID_LENGTH = 3;
>
>
> Regards, Peter
>
>>
>>>
>>>
>>> On 3/18/2015 3:07 PM, Kumar Srinivasan wrote:
>>>>
>>>> Hello Mikhail,
>>>>
>>>>> Hi all,
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066985
>>>>>
>>>>> The problem is that packer/unpacker changes global state( default 
>>>>> time zone ) without proper synchronization:
>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/com/sun/java/util/jar/pack/PackerImpl.java#l85 
>>>>>
>>>>>
>>>>> however javadoc says that it's save to use it in concurrent way if 
>>>>> each thread has it's own packer/unpacker instance:
>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/java/util/jar/Pack200.java#l149 
>>>>>
>>>>>
>>>>> The fix is:
>>>>> 1. first packer/unpacker saves default time zone
>>>>> 2. the last set it back.
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.00/
>>>>
>>>> The above link is wrong!, it takes me to webrev for 8073187,
>>>> which has only the PackerImpl changes.
>>>>
>>>> I am guessing the link should be:
>>>> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.00/
>>>>
>>>> Kumar
>>>>
>>>>>
>>>>> Thanks,
>>>>> Mikhail.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>



From xueming.shen at oracle.com  Fri Mar 20 15:40:42 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 20 Mar 2015 08:40:42 -0700
Subject: String.contains(CharSequence) calls toString on argument
In-Reply-To: <CANTKXYnJozaibiGxpTL5bqeotq_76En=Z33MQ3bqiKR3Z8gwsw@mail.gmail.com>
References: <CANTKXYnJozaibiGxpTL5bqeotq_76En=Z33MQ3bqiKR3Z8gwsw@mail.gmail.com>
Message-ID: <550C3F7A.1020404@oracle.com>

On 03/20/2015 02:34 AM, Tomasz Kowalczewski wrote:
> Hello!
>
> Current implementation of String.contains that accepts CharSequence calls
> toString on it and passes resulting string to indexOf(String). This IMO
> defeats the purpose of using CharSequences (that is to have a mutable
> character buffer and not allocate unnecessary objects).
>

It is arguable that cs.toString() may serve the purpose of taking a snapshot of an otherwise
"mutable" character buffer?

-Sherman

> Is changing this a desirable development? It seems pretty straightforward
> to port indexOf(String) to use CharSequence.
>
> If all you need is patch then I can work on it (I have signed OCA) just
> wanted to make sure it is not a futile work.
>




From vitalyd at gmail.com  Fri Mar 20 15:48:11 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 20 Mar 2015 11:48:11 -0400
Subject: String.contains(CharSequence) calls toString on argument
In-Reply-To: <550C3F7A.1020404@oracle.com>
References: <CANTKXYnJozaibiGxpTL5bqeotq_76En=Z33MQ3bqiKR3Z8gwsw@mail.gmail.com>
	<550C3F7A.1020404@oracle.com>
Message-ID: <CAHjP37HL6Gm8eA10_Ru2qS+eJ6CiH_F7Z-jTm=6_7ymMHWjhgQ@mail.gmail.com>

Yes, but that ought to be for the caller to decide.  Also, although the
resulting String is immutable, toString() itself may observe mutation.

On Fri, Mar 20, 2015 at 11:40 AM, Xueming Shen <xueming.shen at oracle.com>
wrote:

> On 03/20/2015 02:34 AM, Tomasz Kowalczewski wrote:
>
>> Hello!
>>
>> Current implementation of String.contains that accepts CharSequence calls
>> toString on it and passes resulting string to indexOf(String). This IMO
>> defeats the purpose of using CharSequences (that is to have a mutable
>> character buffer and not allocate unnecessary objects).
>>
>>
> It is arguable that cs.toString() may serve the purpose of taking a
> snapshot of an otherwise
> "mutable" character buffer?
>
> -Sherman
>
>
>  Is changing this a desirable development? It seems pretty straightforward
>> to port indexOf(String) to use CharSequence.
>>
>> If all you need is patch then I can work on it (I have signed OCA) just
>> wanted to make sure it is not a futile work.
>>
>>
>
>


From aleksey.shipilev at oracle.com  Fri Mar 20 15:55:28 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 20 Mar 2015 18:55:28 +0300
Subject: String.contains(CharSequence) calls toString on argument
In-Reply-To: <CAHjP37HL6Gm8eA10_Ru2qS+eJ6CiH_F7Z-jTm=6_7ymMHWjhgQ@mail.gmail.com>
References: <CANTKXYnJozaibiGxpTL5bqeotq_76En=Z33MQ3bqiKR3Z8gwsw@mail.gmail.com>	<550C3F7A.1020404@oracle.com>
	<CAHjP37HL6Gm8eA10_Ru2qS+eJ6CiH_F7Z-jTm=6_7ymMHWjhgQ@mail.gmail.com>
Message-ID: <550C42F0.6010506@oracle.com>

If CharSequence is mutable and thread-safe, I would expect toString()
implementation to provide the atomic snapshot (e.g. do the
synchronization). Therefore, I find Sherman's argument interesting.

On the other hand, we don't seem to be having any details/requirements
for contains(CharSequence) w.r.t. it's own argument. What if
String.contains pulls the values one charAt at a time? The concurrency
requirements are not enforceable in CharSequence alone then, unless you
call the supposed-to-be-atomic toString() first.

-Aleksey.

On 03/20/2015 06:48 PM, Vitaly Davidovich wrote:
> Yes, but that ought to be for the caller to decide.  Also, although the
> resulting String is immutable, toString() itself may observe mutation.
> 
> On Fri, Mar 20, 2015 at 11:40 AM, Xueming Shen <xueming.shen at oracle.com>
> wrote:
> 
>> On 03/20/2015 02:34 AM, Tomasz Kowalczewski wrote:
>>
>>> Hello!
>>>
>>> Current implementation of String.contains that accepts CharSequence calls
>>> toString on it and passes resulting string to indexOf(String). This IMO
>>> defeats the purpose of using CharSequences (that is to have a mutable
>>> character buffer and not allocate unnecessary objects).
>>>
>>>
>> It is arguable that cs.toString() may serve the purpose of taking a
>> snapshot of an otherwise
>> "mutable" character buffer?
>>
>> -Sherman
>>
>>
>>  Is changing this a desirable development? It seems pretty straightforward
>>> to port indexOf(String) to use CharSequence.
>>>
>>> If all you need is patch then I can work on it (I have signed OCA) just
>>> wanted to make sure it is not a futile work.
>>>
>>>
>>
>>




From vitalyd at gmail.com  Fri Mar 20 16:05:43 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 20 Mar 2015 12:05:43 -0400
Subject: String.contains(CharSequence) calls toString on argument
In-Reply-To: <550C42F0.6010506@oracle.com>
References: <CANTKXYnJozaibiGxpTL5bqeotq_76En=Z33MQ3bqiKR3Z8gwsw@mail.gmail.com>
	<550C3F7A.1020404@oracle.com>
	<CAHjP37HL6Gm8eA10_Ru2qS+eJ6CiH_F7Z-jTm=6_7ymMHWjhgQ@mail.gmail.com>
	<550C42F0.6010506@oracle.com>
Message-ID: <CAHjP37HJEC7JTiNW-8-m4GrMYc+5F=q3pY+eNLHCGF9JxqdxbA@mail.gmail.com>

>
> If CharSequence is mutable and thread-safe, I would expect toString()
> implementation to provide the atomic snapshot (e.g. do the
> synchronization). Therefore, I find Sherman's argument interesting.


That's my point about "it ought to be up to the caller" -- they're in a
position to make this call, but String.contains() is playing defensive
because it has no clue of the context.

On Fri, Mar 20, 2015 at 11:55 AM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> If CharSequence is mutable and thread-safe, I would expect toString()
> implementation to provide the atomic snapshot (e.g. do the
> synchronization). Therefore, I find Sherman's argument interesting.
>
> On the other hand, we don't seem to be having any details/requirements
> for contains(CharSequence) w.r.t. it's own argument. What if
> String.contains pulls the values one charAt at a time? The concurrency
> requirements are not enforceable in CharSequence alone then, unless you
> call the supposed-to-be-atomic toString() first.
>
> -Aleksey.
>
> On 03/20/2015 06:48 PM, Vitaly Davidovich wrote:
> > Yes, but that ought to be for the caller to decide.  Also, although the
> > resulting String is immutable, toString() itself may observe mutation.
> >
> > On Fri, Mar 20, 2015 at 11:40 AM, Xueming Shen <xueming.shen at oracle.com>
> > wrote:
> >
> >> On 03/20/2015 02:34 AM, Tomasz Kowalczewski wrote:
> >>
> >>> Hello!
> >>>
> >>> Current implementation of String.contains that accepts CharSequence
> calls
> >>> toString on it and passes resulting string to indexOf(String). This IMO
> >>> defeats the purpose of using CharSequences (that is to have a mutable
> >>> character buffer and not allocate unnecessary objects).
> >>>
> >>>
> >> It is arguable that cs.toString() may serve the purpose of taking a
> >> snapshot of an otherwise
> >> "mutable" character buffer?
> >>
> >> -Sherman
> >>
> >>
> >>  Is changing this a desirable development? It seems pretty
> straightforward
> >>> to port indexOf(String) to use CharSequence.
> >>>
> >>> If all you need is patch then I can work on it (I have signed OCA) just
> >>> wanted to make sure it is not a futile work.
> >>>
> >>>
> >>
> >>
>
>
>


From aph at redhat.com  Fri Mar 20 16:08:47 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 20 Mar 2015 16:08:47 +0000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <550B350B.6040602@oracle.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>	<550A90CE.9080901@redhat.com>
	<550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com>
	<550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com>
Message-ID: <550C460F.1090302@redhat.com>

Webrev at

http://cr.openjdk.java.net/~aph/unaligned.hotspot.7/
http://cr.openjdk.java.net/~aph/unaligned.jdk.7/

I've moved the test case into the hotspot repo
The test case is diagnostic, not experimental

Andrew.


From brent.christian at oracle.com  Fri Mar 20 16:14:10 2015
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 20 Mar 2015 09:14:10 -0700
Subject: RFR 8071667 : HashMap.computeIfAbsent() adds entry that
	HashMap.get() does not find.
In-Reply-To: <0B55C8F5-100B-4721-A09D-FE6D7811B038@oracle.com>
References: <5509BA01.6000709@oracle.com>
	<684AF3A3-4280-47B3-AA8D-64248C5DDA9A@oracle.com>
	<550B4E4D.5010500@oracle.com>
	<AC534548-0FE0-4763-B535-2E1B8888EF66@oracle.com>
	<0B55C8F5-100B-4721-A09D-FE6D7811B038@oracle.com>
Message-ID: <550C4752.5000704@oracle.com>

On 3/20/15 4:40 AM, Chris Hegarty wrote:
>
> Yes, the spec changes look good.

Thanks.

> Brent, would you mind if I assign 8062841 [1] to you, so you can
> bring in the CHM implementation changes? Also maybe CHM could be
> added to the test?

I've assigned it to myself.

-Brent


From chris.hegarty at oracle.com  Fri Mar 20 16:30:58 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 20 Mar 2015 16:30:58 +0000
Subject: RFR [9] 8071474: Better failure atomicity for default read object
In-Reply-To: <550C2979.9090407@gmail.com>
References: <550B3F21.6020206@oracle.com> <550C2979.9090407@gmail.com>
Message-ID: <E74F6AC4-EA9A-452C-83AA-1CED002B0637@oracle.com>

Hi Peter,

On 20 Mar 2015, at 14:06, Peter Levart <peter.levart at gmail.com> wrote:

> On 03/19/2015 10:26 PM, Chris Hegarty wrote:
>> The current implementation of defaultReadObject sets non-primitive field values one at a time, without first checking that all their types are assignable. If, for example, the assignment of the last non-primitive value fails, a CCE is thrown, and the previously set fields remain set. The setting of field values, including primitives, can be deferred until after they have been "validated", at a minimum that the non-primitive types are assignable. This is achievable per Class in the hierarchy up until the first user visible affect, i.e. a readObject(NoData) method. Either all fields will be set, or contain their default values.
>> 
>> http://cr.openjdk.java.net/~chegar/8071474/webrev.00/webrev/
>> 
>> I think there are further improvements that can be made in this area, but I would like to move things forward incrementally.
>> 
>> -Chris.
> 
> Hi Chris,
> 
> I'd just ask you a few questions to confirm my understanding of the code:
> 
> In ObjectInputStream:
> 
> 1886         // Best effort Failure Atomicity; Each element in 'slotFieldValues'
> 1887         // contains the stream field values for the same element in 'slots',
> 1888         // up to the first slot with a readObject(NoData) method ( a user
> 1889         // visible effect ).
> 1890         int index = 1;
> 1891         for (; index < slots.length; index++) {
> 1892             ObjectStreamClass slotDesc = slots[index].desc;
> 1893             if (slotDesc.hasReadObjectMethod()
> 1894                 || slotDesc.hasReadObjectNoDataMethod()) {
> 1895                 break;
> 1896             }
> 1897         }
> 1898         // Store, and defer setting, values for index slots, ignore if just one.
> 1899         StreamFieldValues[] slotFieldValues = null;
> 1900         if (index > 1 && obj != null)
> 1901             slotFieldValues =  new StreamFieldValues[index];
> 
> 
> ...you scan slots starting from 1 and up. Is this because slots[0] is an uninteresting slot that belongs to j.l.Object class?

No. I should have explained.

From ObjectStreamClass.getClassDataLayout:
    * Returns array of ClassDataSlot instances representing the data layout
    * (including superclass data) for serialized objects described by this
    * class descriptor.  ClassDataSlots are ordered by inheritance with those
    * containing "higher" superclasses appearing first.  The final
    * ClassDataSlot contains a reference to this descriptor.

? so slots contains entries for only Serializable types in the hierarchy, and from superclass down.

The first entry can be skipped as its stream field values will always be read, checked, and then set, regardless of anything else in the hierarchy ( as you can see I split defaultReadFields so that is now only reads stream field vales, and they can then be ?checked?, and set separately). It only becomes ?interesting" when there are more than one level of Serializable type in the hierarchy.

> In this loop, you scan slots from 0 and up. Is this to catch corrupted streams that contain data for Object slot?
> 
> 1971     /** Sets slot field values in the given obj. */
> 1972     private void setSlotFieldValues(Object obj,
> 1973 ObjectStreamClass.ClassDataSlot[] slots,
> 1974                                     StreamFieldValues[] slotFieldValues) {
> 1975         int length = slotFieldValues.length;
> 1976         for (int i = 0; i < length; i++) {
> 1977             if (slotFieldValues[i] != null)
> 1978                 defaultSetFieldValues(obj, slots[i].desc, slotFieldValues[i]);
> 1979         }
> 1980     }

All slots can contain field values, so they will need to be set. Note to self: I need to verify that this is ok when a slot has no data ( let me check ).

> I agree that this is an incremental improvement. You buffer values read from stream, check their types and delay setting them in particular class slots for classes not declaring  readObject[NoData] methods (or a span of slots in hierarchy ranging from Object to one before the class that declares readObject[NoData] method) which guarantees either success or atomic failure.

Right. Almost everything can be delayed until the first observable effect, i.e. a readObject[NoData].  Fields from non-Serializable types in the hierarchy will remain set, as per the default no-args constructor.

> But have you considered a strategy that we discussed before where you would allow gradual building of state in object being deserialized and in case this fails anywhere (even in class slots declaring readObject[NoData] method), you roll-back the state (setting fields to default values) in all class slots from the one throwing an exception down to the 1st non-Serializable superclass (or Object). This would cover failure atomicity for the whole object, not just the slots not declaring readObject[NoData] methods. The premise is that deserialization starts with an uninitialized object (just class slots from 1st non-Serializable superclass down to Object are initialized by default accessible constructor). So rolling back the object to this state can be achieved by setting all instance fields of Serializable class slots to default values. A package-private FieldSetterContext.FieldsMap could be reused for this purpose (by adding a resetAllFields(Object obj) method). The FieldsMap instance is obtainable from ObjectStreamClass.getFieldAccessMap() which caches it (although internal, these type and method need renaming).

I agree with this. I think it could be built on top of this work. In many cases the reset/rollback can be completely avoided, but in the case where a readObject throws an Exception then the rollback could be triggered.  It will really come down to code complexity whether this proposal adds value, when the rollback/reset is implemented.

> If you think this is a promising alternative to your failure atomicity proposal, I volunteer to add resetAllFields() method. I understand that this can only be added as part or on the top of FieldSetter API proposal.

I certainly think it is worth exploring, and I will help with that myself. We can explore this in the sandbox ( where the FieldSetter API exists ), maybe a branch off serial-exp-branch ?

I would like to move the FieldSetter API forward separate to this effort. I will send mail on that later today to see if we can finalize/agree final API wording.

-Chris.

> Regards, Peter
> 



From david.lloyd at redhat.com  Fri Mar 20 16:57:04 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 20 Mar 2015 11:57:04 -0500
Subject: Fw: Re: RFR [9] 8071472: Add field access to support setting
	final fields in readObject
In-Reply-To: <550C2F5A.8030407@gmail.com>
References: <1426848581.5115.5.camel@Nokia-N900> <550C1AB5.4020801@redhat.com>
	<550C2F5A.8030407@gmail.com>
Message-ID: <550C5160.2030106@redhat.com>

On 03/20/2015 09:31 AM, Peter Levart wrote:
> On 03/20/2015 02:03 PM, David M. Lloyd wrote:
>>>>
>>>> private static void altReadObject(ObjectInputStream in, FieldAccess
>>>> fieldAccess) throws IOException, ClassNotFoundException {
>>>>             // the same as in readObject, but doesn't have direct
>>>> access to
>>>> instance state, so everything must go through FieldAccess API?
>>>> }
>>>>
>>>>
>>>
>>> Yes.
>>
>> An interesting aspect of this approach is that it deals with a problem
>> in the serialization spec [1] where it specifically says that
>> serializable classes should be reading/writing stream fields always,
>> and before reading/writing other data:
>>
>> In section 3.4: "Either ObjectInputStream's defaultReadObject or
>> readFields method must be called once (and only once) before reading
>> any optional data written by the corresponding writeObject method;
>> even if no optional data is read, defaultReadObject or readFields must
>> still be invoked once."
>>
>> In section 2.3: "Either ObjectOutputStream's defaultWriteObject or
>> writeFields method must be called once (and only once) before writing
>> any optional data that will be needed by the corresponding readObject
>> method to restore the state of the object; even if no optional data is
>> written, defaultWriteObject or writeFields must still be invoked once."
>>
>> But classes (even JDK classes) often disregard this requirement,
>> relying on known implementation behavior and either reading/writing
>> optional data before fields or just not reading/writing fields at
>> all.  So either the spec should be updated (I've tried to do this but
>> nobody seems to know how to modify this old content I guess) to match
>> behavior, or the spec should be enforced more strictly - however doing
>> the latter *will* break a lot of user code, *unless* an alternative
>> readObject method is introduced with the more strict enforcement.  But
>> I guess even in this case, the spec should be updated to allow the
>> implementation behavior.
>>
>> [1]
>> http://docs.oracle.com/javase/8/docs/platform/serialization/spec/serialTOC.html
>>
>
> I guess this would need an alternative writeObject method too, with more
> strict enforcement, or not?

Sounds fine to me...

> I don't know from the top of my head, but does the order of writing
> optional data (before or after) fields, change the order of data emitted
> in stream and does that order have to be respected when reading back in
> readObject()?

Yes.

> In that case, I guess, we would need an alternative
> writeObject method too, with more strict enforcement of order. But I
> think that having two different rules for old read/writeObject and
> alternative read/writeObject would just confuse people. If current rules
> don't present any problem (apart from being looser then specification
> requires) then perhaps just specification should be updated.

Maybe.

-- 
- DML


From chris.hegarty at oracle.com  Fri Mar 20 17:13:31 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 20 Mar 2015 17:13:31 +0000
Subject: RFR [9] 8071472: Add field access to support setting final fields
	in readObject
In-Reply-To: <550C1AB5.4020801@redhat.com>
References: <1426848581.5115.5.camel@Nokia-N900> <550C1AB5.4020801@redhat.com>
Message-ID: <0788CFD9-72AA-4CCA-B2D2-FEAA48E5F55D@oracle.com>


On 20 Mar 2015, at 13:03, David M. Lloyd <david.lloyd at redhat.com> wrote:
...
> An interesting aspect of this approach is that it deals with a problem in the serialization spec [1] where it specifically says that serializable classes should be reading/writing stream fields always, and before reading/writing other data:
> 
> In section 3.4: "Either ObjectInputStream's defaultReadObject or readFields method must be called once (and only once) before reading any optional data written by the corresponding writeObject method; even if no optional data is read, defaultReadObject or readFields must still be invoked once."
> 
> In section 2.3: "Either ObjectOutputStream's defaultWriteObject or writeFields method must be called once (and only once) before writing any optional data that will be needed by the corresponding readObject method to restore the state of the object; even if no optional data is written, defaultWriteObject or writeFields must still be invoked once."
> 
> But classes (even JDK classes) often disregard this requirement, relying on known implementation behavior and either reading/writing optional data before fields or just not reading/writing fields at all.  So either the spec should be updated (I've tried to do this but nobody seems to know how to modify this old content I guess) to match behavior, or the spec should be enforced more strictly - however doing the latter *will* break a lot of user code, *unless* an alternative readObject method is introduced with the more strict enforcement.  But I guess even in this case, the spec should be updated to allow the implementation behaviour.

I do remember the thread on this [1]. I did try to locate the source of the Serialization spec, but never got to the bottom of it.

I think we should start a new thread on this, and see if we can agree proposed wording for the spec. I will then endeavour to have these amendments applied to the spec. ( In the meantime I?ll see if I can make progress on locating the spec source ).

-Chris.

[1] http://markmail.org/message/tpyws22lklyodb7p


> [1] http://docs.oracle.com/javase/8/docs/platform/serialization/spec/serialTOC.html



From Roger.Riggs at Oracle.com  Fri Mar 20 17:19:41 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 20 Mar 2015 13:19:41 -0400
Subject: [9] RFR of 8075362: j.u.Properties.load() methods have misaligned
	@throws clauses
In-Reply-To: <F285743C-E8C9-498E-8D47-C8F7E49DD37C@oracle.com>
References: <F285743C-E8C9-498E-8D47-C8F7E49DD37C@oracle.com>
Message-ID: <550C56AD.4070401@Oracle.com>

Hi Brian,

Looks fine.

Roger


On 3/17/2015 3:15 PM, Brian Burkhalter wrote:
> Follow-on to correct some insufficiencies pointed out in
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032289.html
>
> Please review at your convenience.
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8075362
> Diff: 		See below (Properties.java change did not show up in webrev).
>
> Thanks,
>
> Brian
>
> diff --git a/src/java.base/share/classes/java/util/Properties.java b/src/java.base/share/classes/java/util/Properties.java
> --- a/src/java.base/share/classes/java/util/Properties.java
> +++ b/src/java.base/share/classes/java/util/Properties.java
> @@ -309,7 +309,7 @@
>        *          input stream.
>        * @throws  IllegalArgumentException if a malformed Unicode escape
>        *          appears in the input.
> -     * @throws NullPointerException if {@code reader} is null.
> +     * @throws  NullPointerException if {@code reader} is null.
>        * @since   1.6
>        */
>       public synchronized void load(Reader reader) throws IOException {
> @@ -335,7 +335,7 @@
>        *             input stream.
>        * @throws     IllegalArgumentException if the input stream contains a
>        *             malformed Unicode escape sequence.
> -     * @throws NullPointerException if {@code inStream} is null.
> +     * @throws     NullPointerException if {@code inStream} is null.
>        * @since 1.2
>        */
>       public synchronized void load(InputStream inStream) throws IOException {
>
> diff --git a/test/java/util/Properties/Basic.java b/test/java/util/Properties/LoadAndStoreNPE.java
> rename from test/java/util/Properties/Basic.java
> rename to test/java/util/Properties/LoadAndStoreNPE.java
>
> --- a/test/java/util/Properties/Basic.java
> +++ b/test/java/util/Properties/LoadAndStoreNPE.java
> @@ -28,10 +28,10 @@
>   
>   /*
>    * @test
> - * @bug 8073214
> - * @summary Basic tests of Properties methods.
> + * @bug 8073214 8075362
> + * @summary Tests to verify that load() and store() throw NPEs as advertised.
>    */
> -public class Basic
> +public class LoadAndStoreNPE
>   {
>       public static void main(String[] args) throws Exception
>       {
> @@ -68,7 +68,7 @@
>           }
>   
>           if (failures != 0) {
> -            throw new RuntimeException("Basic failed with "
> +            throw new RuntimeException("LoadAndStoreNPE failed with "
>                   + failures + " errors!");
>           }
>       }
>



From brian.burkhalter at oracle.com  Fri Mar 20 17:59:28 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 20 Mar 2015 10:59:28 -0700
Subject: [9] RFC on 8074467: In some cases,
	BigDecimal's  toBigInteger() produces wrong result
Message-ID: <B9960AA3-1769-4725-A222-013AFE8B1DFB@oracle.com>

Comments from the ?numerologists? on this list would be appreciated.

I investigated this issue

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

running the supplied test on JDK 8u40 and 9dev on native Mac OS 10.9.5 and VirtualBox Windows 7 Pro VM for the ?BLOCK? values 1000 and 1500, as specified in the description. For a given BLOCK value the results were the same across all four corresponding test runs. Across all eight runs, the value of toBigInteger() was the same in all cases, contrary to the issue description. For a given BLOCK size, the value of the fractional part was the same across all four corresponding runs. The fractional part differed however between the two different BLOCK sizes, which is to be expected as the precisions of the calculations differ. The pertinent portions of the output of all tests runs are attached to the issue.

This could be resolved as either ?Cannot Reproduce,? or as ?Incomplete? with a comment requesting further corroboration from the external reporter of the issue.

Does anyone have a recommendation on this latter point or any other comments?

Thanks,

Brian

From mikael.vidstedt at oracle.com  Fri Mar 20 18:02:52 2015
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Fri, 20 Mar 2015 11:02:52 -0700
Subject: [9] RFR 8074840: Resolve disabled warnings for libjli and
	libjli_static
Message-ID: <550C60CC.1080208@oracle.com>


Please review the following change which fixes a number of native 
compilation warnings in files related to libjli.

Bug: https://bugs.openjdk.java.net/browse/JDK-8074840
Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8074840/webrev.01/webrev/

I built the code across all the OracleJDK platforms and there were no 
warnings on any of the platforms (in the files related to this change). 
I'm taking suggestions on specific tests to run.

Some specifics:

Unfortunately there is no intrinsic for cpuid in Solaris Studio, so I 
had to keep the inline asm code and the corresponding flag to disable 
the related warning (E_ASM_DISABLES_OPTIMIZATION). The alternative would 
be to move it out into a dedicated assembly file, but that seems like 
more trouble than it's worth given that the warning is harmless.

I'm not entirely happy with the unsigned cast in parse_manifest.c:196, 
but unfortunately the windows prototype for read() takes an unsigned as 
its last argument, where All(tm) other platforms take a size_t. In this 
specific case 'len' will never be be more than END_MAXLEN = 0xFFFF + 
ENDHDR = 0xFFFF + 22 = 0x10015, meaning it will comfortably fit in an 
unsigned on the platforms we support. But if somebody has suggestions 
I'm all ears, doing the #ifdef dance is of course also an option.

Note that the warnings were temporarily disabled as part of JDK-8074096 
[1] until such time they could be fixed the proper way. Also note that 
this change supersedes the earlier change [2] Dmitry had out for review. 
The bug [3] corresponding to that webrev will be closed as a duplicate 
of this bug (JDK-8074839).

Cheers,
Mikael

[1] https://bugs.openjdk.java.net/browse/JDK-8074096
[2] http://cr.openjdk.java.net/~dsamersoff/JDK-8073175/webrev.01/
[3] https://bugs.openjdk.java.net/browse/JDK-8073175



From chris.hegarty at oracle.com  Fri Mar 20 18:55:59 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 20 Mar 2015 18:55:59 +0000
Subject: RFR [9] : Add default[Read|Write]Object to java.util.Date
Message-ID: <667F9AA3-CA1A-4E00-BDA8-168ED9C5500F@oracle.com>

Trivial change that came up a few months ago, and again recently, that java.util.Date should call default[Read|Write]Object to strictly conform to the Serialization spec ( even though it does not have any persistent state, which it could conceivably do at some point in the future, but probably won't ).

diff --git a/src/java.base/share/classes/java/util/Date.java b/src/java.base/share/classes/java/util/Date.java
--- a/src/java.base/share/classes/java/util/Date.java
+++ b/src/java.base/share/classes/java/util/Date.java
@@ -1317,6 +1317,7 @@
     private void writeObject(ObjectOutputStream s)
          throws IOException
     {
+        s.defaultWriteObject();
         s.writeLong(getTimeImpl());
     }
 
@@ -1326,6 +1327,7 @@
     private void readObject(ObjectInputStream s)
          throws IOException, ClassNotFoundException
     {
+        s.defaultReadObject();
         fastTime = s.readLong();
     }

-Chris.

From Roger.Riggs at Oracle.com  Fri Mar 20 19:13:16 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 20 Mar 2015 15:13:16 -0400
Subject: RFR [9] : Add default[Read|Write]Object to java.util.Date
In-Reply-To: <667F9AA3-CA1A-4E00-BDA8-168ED9C5500F@oracle.com>
References: <667F9AA3-CA1A-4E00-BDA8-168ED9C5500F@oracle.com>
Message-ID: <550C714C.1030009@Oracle.com>

+1

On 3/20/2015 2:55 PM, Chris Hegarty wrote:
> Trivial change that came up a few months ago, and again recently, that java.util.Date should call default[Read|Write]Object to strictly conform to the Serialization spec ( even though it does not have any persistent state, which it could conceivably do at some point in the future, but probably won't ).
>
> diff --git a/src/java.base/share/classes/java/util/Date.java b/src/java.base/share/classes/java/util/Date.java
> --- a/src/java.base/share/classes/java/util/Date.java
> +++ b/src/java.base/share/classes/java/util/Date.java
> @@ -1317,6 +1317,7 @@
>       private void writeObject(ObjectOutputStream s)
>            throws IOException
>       {
> +        s.defaultWriteObject();
>           s.writeLong(getTimeImpl());
>       }
>   
> @@ -1326,6 +1327,7 @@
>       private void readObject(ObjectInputStream s)
>            throws IOException, ClassNotFoundException
>       {
> +        s.defaultReadObject();
>           fastTime = s.readLong();
>       }
>
> -Chris.



From Alan.Bateman at oracle.com  Fri Mar 20 19:25:46 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 20 Mar 2015 19:25:46 +0000
Subject: RFR [9] : Add default[Read|Write]Object to java.util.Date
In-Reply-To: <667F9AA3-CA1A-4E00-BDA8-168ED9C5500F@oracle.com>
References: <667F9AA3-CA1A-4E00-BDA8-168ED9C5500F@oracle.com>
Message-ID: <550C743A.8090300@oracle.com>

On 20/03/2015 18:55, Chris Hegarty wrote:
> Trivial change that came up a few months ago, and again recently, that java.util.Date should call default[Read|Write]Object to strictly conform to the Serialization spec ( even though it does not have any persistent state, which it could conceivably do at some point in the future, but probably won't ).
>
> diff --git a/src/java.base/share/classes/java/util/Date.java b/src/java.base/share/classes/java/util/Date.java
> --- a/src/java.base/share/classes/java/util/Date.java
> +++ b/src/java.base/share/classes/java/util/Date.java
> @@ -1317,6 +1317,7 @@
>       private void writeObject(ObjectOutputStream s)
>            throws IOException
>       {
> +        s.defaultWriteObject();
>           s.writeLong(getTimeImpl());
>       }
>   
> @@ -1326,6 +1327,7 @@
>       private void readObject(ObjectInputStream s)
>            throws IOException, ClassNotFoundException
>       {
> +        s.defaultReadObject();
>           fastTime = s.readLong();
>       }
>
I think looks okay.

-Alan


From brent.christian at oracle.com  Fri Mar 20 21:23:25 2015
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 20 Mar 2015 14:23:25 -0700
Subject: RFR 8071667 : HashMap.computeIfAbsent() adds entry that
	HashMap.get() does not find.
In-Reply-To: <AC534548-0FE0-4763-B535-2E1B8888EF66@oracle.com>
References: <5509BA01.6000709@oracle.com>	<684AF3A3-4280-47B3-AA8D-64248C5DDA9A@oracle.com>	<550B4E4D.5010500@oracle.com>
	<AC534548-0FE0-4763-B535-2E1B8888EF66@oracle.com>
Message-ID: <550C8FCD.7070304@oracle.com>

Here's the latest:

http://cr.openjdk.java.net/~bchristi/8071667/webrev.4/

That should have everything.

Thanks again,
-Brent

On 3/20/15 2:52 AM, Paul Sandoz wrote:
>
> On Mar 19, 2015, at 11:31 PM, Brent Christian
> <brent.christian at oracle.com> wrote:
>
>> Hi, Paul
>>
>> Thank you for the suggested doc adjustments.  They're applied
>> here: http://cr.openjdk.java.net/~bchristi/8071667/webrev.3/
>>
>
> Looking good.
>
> Small point. We could clear up some inconsistency over using "the
> function" or the "the re/mapping function" to constantly use the
> later and call it that in the doc of the "re/mappingFunction"
> parameter.
>
>
>> TestNG test update forthcoming.
>>
>
> Ok.
>
> Paul.
>


From brian.burkhalter at oracle.com  Fri Mar 20 21:32:17 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 20 Mar 2015 14:32:17 -0700
Subject: [9] RFR of 8075655: NIO test generation scripts have incorrect path
	to Spp.java
Message-ID: <C61FFD07-EE15-418B-ADA7-D474AB8ADEB5@oracle.com>

Please review at your convenience.

Issue:	https://bugs.openjdk.java.net/browse/JDK-8075655
Patch:	http://cr.openjdk.java.net/~bpb/8075655/webrev.00/

Change is to correct the path.

Thanks,

Brian


From Roger.Riggs at Oracle.com  Fri Mar 20 21:33:41 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 20 Mar 2015 17:33:41 -0400
Subject: RFR 9: 8071480: ProcessBuilder.start spec linked to the wrong
	checkRead and checkWrite methods
Message-ID: <550C9235.6050602@Oracle.com>

Please review two javadoc updates to java.lang.ProcessBuilder.

Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-typo-8073220/

Issues:
   8071480: (process spec) ProcessBuilder.start spec linked to the wrong 
checkRead and checkWrite methods
   8073220: A typo in the documentation for class ProcessBuilder

Thanks, Roger





From Roger.Riggs at Oracle.com  Fri Mar 20 21:36:06 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 20 Mar 2015 17:36:06 -0400
Subject: [9] RFR of 8075655: NIO test generation scripts have incorrect
	path to Spp.java
In-Reply-To: <C61FFD07-EE15-418B-ADA7-D474AB8ADEB5@oracle.com>
References: <C61FFD07-EE15-418B-ADA7-D474AB8ADEB5@oracle.com>
Message-ID: <550C92C6.6020007@Oracle.com>

Hi Brian,

Look good,

Roger


On 3/20/2015 5:32 PM, Brian Burkhalter wrote:
> Please review at your convenience.
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8075655
> Patch:	http://cr.openjdk.java.net/~bpb/8075655/webrev.00/
>
> Change is to correct the path.
>
> Thanks,
>
> Brian



From Roger.Riggs at Oracle.com  Fri Mar 20 21:48:57 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 20 Mar 2015 17:48:57 -0400
Subject: RFR 9: 8067796: (process) Process.waitFor(timeout, unit) doesn't
	throw NPE if timeout is less than, or equal to zero when unit == null
Message-ID: <550C95C9.20900@Oracle.com>

Please review this change to Process.waitFor(timeout, TimeUnit)
to check for TimeUnit == null before checking for exited = true and 
timeout <= 0.
The current implementation does not throw NPE if the timeout is <= 0 or 
the Process has already
exited.  The check for the validity of the arguments should come before 
the other conditions.
This cleanup of the implementation was requested by the JCK team.

Webrev:
      ://cr.openjdk.java.net/~rriggs/webrev-npe-8067796/
Issue:
    8067796: (process) Process.waitFor(timeout, unit) doesn't throw NPE 
if timeout is less than, or equal to zero when unit == null

Thanks, Roger

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




From vladimir.kozlov at oracle.com  Fri Mar 20 22:00:58 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 20 Mar 2015 15:00:58 -0700
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <550C460F.1090302@redhat.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>	<550A90CE.9080901@redhat.com>
	<550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com>
	<550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com>
	<550C460F.1090302@redhat.com>
Message-ID: <550C989A.5010203@oracle.com>

On 3/20/15 9:08 AM, Andrew Haley wrote:
> Webrev at
>
> http://cr.openjdk.java.net/~aph/unaligned.hotspot.7/

I don't see changes to VM's makefiles to set VM_BIG_ENDIAN. Or consider 
it is set if VM_LITTLE_ENDIAN is not set in prims/unsafe.cpp code.

In globals.hpp the empty line after flag description should not have '\' 
at the end.

Otherwise it looks good.

> http://cr.openjdk.java.net/~aph/unaligned.jdk.7/

My only comment for jdk change is to use bigEndian name instead of BE in 
Unsafe.java. Someone from core libs should look on this.

>
> I've moved the test case into the hotspot repo
> The test case is diagnostic, not experimental

Good.

Thanks,
Vladimir

>
> Andrew.
>


From martinrb at google.com  Fri Mar 20 22:23:29 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 20 Mar 2015 15:23:29 -0700
Subject: RFR 9: 8067796: (process) Process.waitFor(timeout, unit) doesn't
	throw NPE if timeout is less than, or equal to zero when unit == null
In-Reply-To: <550C95C9.20900@Oracle.com>
References: <550C95C9.20900@Oracle.com>
Message-ID: <CA+kOe0_PKxN180n5OdKu74nhHo7At2MfKi_7+nbEMRoHiNHuTA@mail.gmail.com>

I probably implemented it the way it is intentionally.  I would leave it.

Pedantic changes such as this one won't make any users happy, but we're
doing this elsewhere like in java.util.concurrent so I guess it's OK.

But there's a much simpler way to implement it.

Just move

long remainingNanos = unit.toNanos(timeout);


to the beginning of the method body, as we do in java.util.concurrent.

On Fri, Mar 20, 2015 at 2:48 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Please review this change to Process.waitFor(timeout, TimeUnit)
> to check for TimeUnit == null before checking for exited = true and
> timeout <= 0.
> The current implementation does not throw NPE if the timeout is <= 0 or
> the Process has already
> exited.  The check for the validity of the arguments should come before
> the other conditions.
> This cleanup of the implementation was requested by the JCK team.
>
> Webrev:
>      ://cr.openjdk.java.net/~rriggs/webrev-npe-8067796/
> Issue:
>    8067796: (process) Process.waitFor(timeout, unit) doesn't throw NPE if
> timeout is less than, or equal to zero when unit == null
>
> Thanks, Roger
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8067796
>
>
>


From martinrb at google.com  Fri Mar 20 22:27:39 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 20 Mar 2015 15:27:39 -0700
Subject: RFR 9: 8071480: ProcessBuilder.start spec linked to the wrong
	checkRead and checkWrite methods
In-Reply-To: <550C9235.6050602@Oracle.com>
References: <550C9235.6050602@Oracle.com>
Message-ID: <CA+kOe0-HAMbyamMHMcVTA3XrR_vV_dn0KsEncVs4Xod_bgvUgw@mail.gmail.com>

Thanks! This one is a real improvement!

On Fri, Mar 20, 2015 at 2:33 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Please review two javadoc updates to java.lang.ProcessBuilder.
>
> Webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-typo-8073220/
>
> Issues:
>   8071480: (process spec) ProcessBuilder.start spec linked to the wrong
> checkRead and checkWrite methods
>   8073220: A typo in the documentation for class ProcessBuilder
>
> Thanks, Roger
>
>
>
>


From brian.burkhalter at oracle.com  Fri Mar 20 22:52:40 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 20 Mar 2015 15:52:40 -0700
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE 
Message-ID: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>

Please review at your convenience.

Issue:	https://bugs.openjdk.java.net/browse/JDK-8065556
Patch:	http://cr.openjdk.java.net/~bpb/8065556/webrev.00/

My doubts concern the changes to the test portion, viz.:

1) Is the style sufficiently consistent?
2) I have not added a ?@bug? tag like we normally would because all the affected test files are generated from a template which contains no such tag. (Should one perhaps be added to Basic.java with no other changes to that file?).

Thanks,

Brian

From martinrb at google.com  Sat Mar 21 01:36:00 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 20 Mar 2015 18:36:00 -0700
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE
In-Reply-To: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>
References: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>
Message-ID: <CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>

The message construction code takes many bytecodes, and best practice a few
years ago was to segregate cold code like this into a separate method, and
that's probably still true.  Follow the practice of other classes and define

private String outOfBoundsMsg(int position)

On Fri, Mar 20, 2015 at 3:52 PM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> Please review at your convenience.
>
> Issue:  https://bugs.openjdk.java.net/browse/JDK-8065556
> Patch:  http://cr.openjdk.java.net/~bpb/8065556/webrev.00/
>
> My doubts concern the changes to the test portion, viz.:
>
> 1) Is the style sufficiently consistent?
> 2) I have not added a ?@bug? tag like we normally would because all the
> affected test files are generated from a template which contains no such
> tag. (Should one perhaps be added to Basic.java with no other changes to
> that file?).
>
> Thanks,
>
> Brian


From peter.firmstone at zeus.net.au  Sat Mar 21 03:05:51 2015
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 21 Mar 2015 13:05:51 +1000
Subject: Fw: Re: RFR [9] 8071472: Add field access to support,	setting
	final fields in readObject
In-Reply-To: <mailman.52449.1426871986.10816.core-libs-dev@openjdk.java.net>
References: <mailman.52449.1426871986.10816.core-libs-dev@openjdk.java.net>
Message-ID: <550CE00F.40403@zeus.net.au>

The reason for this part of the spec, is backward compatible 
evolvability of serial form.

It allows an earlier implementation of a class to deserialize serial 
form from a later implementation that includes additional fields or 
values written to the stream, and allow them to be discarded by 
ObjectInputStream, when the earilier implementation doesn't read/consume 
them.

If classes deliberately break the contract / spec, then although they 
function, they limit their backward compatible evolvability; in other 
words, if a later class has additional fields or writes additional 
values to the stream, a StreamCorruptedException will occur when an 
earlier class implementation reads it.

For that reason, I'd reccommend against including it in the spec.

Regards,

Peter.


> ------------------------------
>
> Message: 4
> Date: Fri, 20 Mar 2015 11:57:04 -0500
> From: "David M. Lloyd"<david.lloyd at redhat.com>
> To: core-libs-dev at openjdk.java.net
> Subject: Re: Fw: Re: RFR [9] 8071472: Add field access to support
> 	setting	final fields in readObject
> Message-ID:<550C5160.2030106 at redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 03/20/2015 09:31 AM, Peter Levart wrote:
>> On 03/20/2015 02:03 PM, David M. Lloyd wrote:
>>>>> private static void altReadObject(ObjectInputStream in, FieldAccess
>>>>> fieldAccess) throws IOException, ClassNotFoundException {
>>>>>              // the same as in readObject, but doesn't have direct
>>>>> access to
>>>>> instance state, so everything must go through FieldAccess API?
>>>>> }
>>>>>
>>>>>
>>>> Yes.
>>> An interesting aspect of this approach is that it deals with a problem
>>> in the serialization spec [1] where it specifically says that
>>> serializable classes should be reading/writing stream fields always,
>>> and before reading/writing other data:
>>>
>>> In section 3.4: "Either ObjectInputStream's defaultReadObject or
>>> readFields method must be called once (and only once) before reading
>>> any optional data written by the corresponding writeObject method;
>>> even if no optional data is read, defaultReadObject or readFields must
>>> still be invoked once."
>>>
>>> In section 2.3: "Either ObjectOutputStream's defaultWriteObject or
>>> writeFields method must be called once (and only once) before writing
>>> any optional data that will be needed by the corresponding readObject
>>> method to restore the state of the object; even if no optional data is
>>> written, defaultWriteObject or writeFields must still be invoked once."
>>>
>>> But classes (even JDK classes) often disregard this requirement,
>>> relying on known implementation behavior and either reading/writing
>>> optional data before fields or just not reading/writing fields at
>>> all.  So either the spec should be updated (I've tried to do this but
>>> nobody seems to know how to modify this old content I guess) to match
>>> behavior, or the spec should be enforced more strictly - however doing
>>> the latter *will* break a lot of user code, *unless* an alternative
>>> readObject method is introduced with the more strict enforcement.  But
>>> I guess even in this case, the spec should be updated to allow the
>>> implementation behavior.
>>>
>>> [1]
>>> http://docs.oracle.com/javase/8/docs/platform/serialization/spec/serialTOC.html
>>>
>> I guess this would need an alternative writeObject method too, with more
>> strict enforcement, or not?
> Sounds fine to me...
>
>> I don't know from the top of my head, but does the order of writing
>> optional data (before or after) fields, change the order of data emitted
>> in stream and does that order have to be respected when reading back in
>> readObject()?
> Yes.
>
>> In that case, I guess, we would need an alternative
>> writeObject method too, with more strict enforcement of order. But I
>> think that having two different rules for old read/writeObject and
>> alternative read/writeObject would just confuse people. If current rules
>> don't present any problem (apart from being looser then specification
>> requires) then perhaps just specification should be updated.
> Maybe.
>



From john.r.rose at oracle.com  Sat Mar 21 05:09:51 2015
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 20 Mar 2015 22:09:51 -0700
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE
In-Reply-To: <CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>
References: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>
	<CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>
Message-ID: <98E4E492-9EC3-4F9B-BCCF-4AEC6A668F43@oracle.com>

Yes, that's still a good idea, until we fix JDK-6316156 <https://bugs.openjdk.java.net/browse/JDK-6316156>.  Thanks, Martin.  ? John

On Mar 20, 2015, at 6:36 PM, Martin Buchholz <martinrb at google.com> wrote:
> 
> The message construction code takes many bytecodes, and best practice a few
> years ago was to segregate cold code like this into a separate method, and
> that's probably still true.  Follow the practice of other classes and define
> 
> private String outOfBoundsMsg(int position)
> 
> On Fri, Mar 20, 2015 at 3:52 PM, Brian Burkhalter <
> brian.burkhalter at oracle.com> wrote:
> 
>> Please review at your convenience.
>> 
>> Issue:  https://bugs.openjdk.java.net/browse/JDK-8065556
>> Patch:  http://cr.openjdk.java.net/~bpb/8065556/webrev.00/
>> 
>> My doubts concern the changes to the test portion, viz.:
>> 
>> 1) Is the style sufficiently consistent?
>> 2) I have not added a ?@bug? tag like we normally would because all the
>> affected test files are generated from a template which contains no such
>> tag. (Should one perhaps be added to Basic.java with no other changes to
>> that file?).
>> 
>> Thanks,
>> 
>> Brian



From john.r.rose at oracle.com  Sat Mar 21 05:21:20 2015
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 20 Mar 2015 22:21:20 -0700
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float,
	...} methods
In-Reply-To: <550C989A.5010203@oracle.com>
References: <550330CE.3030607@redhat.com>
	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>
	<550710BD.5060301@redhat.com>
	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>
	<5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com>
	<550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com>
	<550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com>
	<550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com>
Message-ID: <EC9252DA-761C-440E-B7E4-9EC52790DFE6@oracle.com>

I'm glad to see this coming along?  The code, javadoc, and spec all look good.

On Mar 20, 2015, at 3:00 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
>> http://cr.openjdk.java.net/~aph/unaligned.jdk.7/ <http://cr.openjdk.java.net/~aph/unaligned.jdk.7/>
> 
> My only comment for jdk change is to use bigEndian name instead of BE in Unsafe.java. Someone from core libs should look on this.

Here's my take on that bit (subject of course to correction from a core-libs eng.).

BE (though short), as an upper-case acronym, is more correct than mixed-case bigEndian, according to the conventions suggested by JLS 6.1:

> Constant Names
> 
> The names of constants in interface types should be, and final variables of class types may conventionally be, a sequence of one or more words, acronyms, or abbreviations, all uppercase, with components separated by underscore "_" characters. Constant names should be descriptive and not unnecessarily abbreviated. Conventionally they may be any appropriate part of speech.
> 
> Examples of names for constants include MIN_VALUE, MAX_VALUE, MIN_RADIX, and MAX_RADIX of the class Character.

So I think it's OK as-is, especially since it is a private name.

? John

From Alan.Bateman at oracle.com  Sat Mar 21 07:02:13 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 21 Mar 2015 07:02:13 +0000
Subject: [9] RFR of 8075655: NIO test generation scripts have incorrect
	path to Spp.java
In-Reply-To: <C61FFD07-EE15-418B-ADA7-D474AB8ADEB5@oracle.com>
References: <C61FFD07-EE15-418B-ADA7-D474AB8ADEB5@oracle.com>
Message-ID: <550D1775.1010500@oracle.com>

On 20/03/2015 21:32, Brian Burkhalter wrote:
> Please review at your convenience.
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8075655
> Patch:	http://cr.openjdk.java.net/~bpb/8075655/webrev.00/
>
This looks okay to me, I think a left over that only surfaces when 
needing to re-generate these tests.

-Alan


From Alan.Bateman at oracle.com  Sat Mar 21 07:03:25 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 21 Mar 2015 07:03:25 +0000
Subject: RFR 9: 8071480: ProcessBuilder.start spec linked to the wrong
	checkRead and checkWrite methods
In-Reply-To: <550C9235.6050602@Oracle.com>
References: <550C9235.6050602@Oracle.com>
Message-ID: <550D17BD.2020303@oracle.com>

On 20/03/2015 21:33, Roger Riggs wrote:
> Please review two javadoc updates to java.lang.ProcessBuilder.
>
> Webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-typo-8073220/
>
> Issues:
>   8071480: (process spec) ProcessBuilder.start spec linked to the 
> wrong checkRead and checkWrite methods
>   8073220: A typo in the documentation for class ProcessBuilder
This looks to me too.

-Alan


From tomasz.kowalczewski at gmail.com  Sat Mar 21 08:21:24 2015
From: tomasz.kowalczewski at gmail.com (Tomasz Kowalczewski)
Date: Sat, 21 Mar 2015 09:21:24 +0100
Subject: String.contains(CharSequence) calls toString on argument
In-Reply-To: <CAHjP37HJEC7JTiNW-8-m4GrMYc+5F=q3pY+eNLHCGF9JxqdxbA@mail.gmail.com>
References: <CANTKXYnJozaibiGxpTL5bqeotq_76En=Z33MQ3bqiKR3Z8gwsw@mail.gmail.com>
	<550C3F7A.1020404@oracle.com>
	<CAHjP37HL6Gm8eA10_Ru2qS+eJ6CiH_F7Z-jTm=6_7ymMHWjhgQ@mail.gmail.com>
	<550C42F0.6010506@oracle.com>
	<CAHjP37HJEC7JTiNW-8-m4GrMYc+5F=q3pY+eNLHCGF9JxqdxbA@mail.gmail.com>
Message-ID: <CANTKXYkonpfuO+Wnq5yu8PrizHRSY50LsvS3zt60Gd4CsTkLSg@mail.gmail.com>

There are other places which accept CharSequence and iterate over it
not caring about possible concurrent modification (the only sane way
IMHO). Examples are String.contentEquals and String.join that uses
StringJoiner which iterates its argument char by char.

It looks like contains is the exception in this regard.

On 20 mar 2015, at 17:05, Vitaly Davidovich <vitalyd at gmail.com> wrote:

>>
>> If CharSequence is mutable and thread-safe, I would expect toString()
>> implementation to provide the atomic snapshot (e.g. do the
>> synchronization). Therefore, I find Sherman's argument interesting.
>
>
> That's my point about "it ought to be up to the caller" -- they're in a
> position to make this call, but String.contains() is playing defensive
> because it has no clue of the context.
>
> On Fri, Mar 20, 2015 at 11:55 AM, Aleksey Shipilev <
> aleksey.shipilev at oracle.com> wrote:
>
>> If CharSequence is mutable and thread-safe, I would expect toString()
>> implementation to provide the atomic snapshot (e.g. do the
>> synchronization). Therefore, I find Sherman's argument interesting.
>>
>> On the other hand, we don't seem to be having any details/requirements
>> for contains(CharSequence) w.r.t. it's own argument. What if
>> String.contains pulls the values one charAt at a time? The concurrency
>> requirements are not enforceable in CharSequence alone then, unless you
>> call the supposed-to-be-atomic toString() first.
>>
>> -Aleksey.
>>
>>> On 03/20/2015 06:48 PM, Vitaly Davidovich wrote:
>>> Yes, but that ought to be for the caller to decide.  Also, although the
>>> resulting String is immutable, toString() itself may observe mutation.
>>>
>>> On Fri, Mar 20, 2015 at 11:40 AM, Xueming Shen <xueming.shen at oracle.com>
>>> wrote:
>>>
>>>>> On 03/20/2015 02:34 AM, Tomasz Kowalczewski wrote:
>>>>>
>>>>> Hello!
>>>>>
>>>>> Current implementation of String.contains that accepts CharSequence
>> calls
>>>>> toString on it and passes resulting string to indexOf(String). This IMO
>>>>> defeats the purpose of using CharSequences (that is to have a mutable
>>>>> character buffer and not allocate unnecessary objects).
>>>> It is arguable that cs.toString() may serve the purpose of taking a
>>>> snapshot of an otherwise
>>>> "mutable" character buffer?
>>>>
>>>> -Sherman
>>>>
>>>>
>>>> Is changing this a desirable development? It seems pretty
>> straightforward
>>>>> to port indexOf(String) to use CharSequence.
>>>>>
>>>>> If all you need is patch then I can work on it (I have signed OCA) just
>>>>> wanted to make sure it is not a futile work.
>>
>>
>>


From aph at redhat.com  Sat Mar 21 11:36:17 2015
From: aph at redhat.com (Andrew Haley)
Date: Sat, 21 Mar 2015 11:36:17 +0000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <550C989A.5010203@oracle.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>	<550A90CE.9080901@redhat.com>
	<550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com>
	<550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com>
	<550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com>
Message-ID: <550D57B1.602@redhat.com>

On 20/03/15 22:00, Vladimir Kozlov wrote:
> On 3/20/15 9:08 AM, Andrew Haley wrote:
>> Webrev at
>>
>> http://cr.openjdk.java.net/~aph/unaligned.hotspot.7/
> 
> I don't see changes to VM's makefiles to set VM_BIG_ENDIAN. Or consider 
> it is set if VM_LITTLE_ENDIAN is not set in prims/unsafe.cpp code.

Darn, I already made that change once but missed it in this webrev.  Sorry.

> In globals.hpp the empty line after flag description should not have '\' 
> at the end.

OK.

> Otherwise it looks good.
> 
>> http://cr.openjdk.java.net/~aph/unaligned.jdk.7/
> 
> My only comment for jdk change is to use bigEndian name instead of BE in 
> Unsafe.java. Someone from core libs should look on this.

I would have used that, but I followed John Rose's suggestion.  I
don't mind making changes but having to change it back-and-forth
really is too much.

>> I've moved the test case into the hotspot repo
>> The test case is diagnostic, not experimental

Yes, is is.  I was told to do that.

Andrew.



From paul.sandoz at oracle.com  Sat Mar 21 13:43:50 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Sat, 21 Mar 2015 14:43:50 +0100
Subject: RFR 8071667 : HashMap.computeIfAbsent() adds entry that
	HashMap.get() does not find.
In-Reply-To: <550C8FCD.7070304@oracle.com>
References: <5509BA01.6000709@oracle.com>	<684AF3A3-4280-47B3-AA8D-64248C5DDA9A@oracle.com>	<550B4E4D.5010500@oracle.com>
	<AC534548-0FE0-4763-B535-2E1B8888EF66@oracle.com>
	<550C8FCD.7070304@oracle.com>
Message-ID: <3DEEDED0-74F1-4B54-9A8A-6A36B1AB1B59@oracle.com>


On Mar 20, 2015, at 10:23 PM, Brent Christian <brent.christian at oracle.com> wrote:

> Here's the latest:
> 
> http://cr.openjdk.java.net/~bchristi/8071667/webrev.4/
> 
> That should have everything.
> 

Looks good (i assumed all but the test code has remained unchanged).

I like the test. A minor comment:

 125     private static void checkCME(Consumer code, boolean expectCME) {
 126         try {
 127             code.accept(null);
 128         } catch (ConcurrentModificationException cme) {
 129             if (expectCME) { return; } else { throw cme; }
 130         }
 131         if (expectCME) {
 132             throw new RuntimeException("Expected CME, but wasn't thrown");
 133         }        
 134     }
 135 
 136     private static BiFunction<String,String,String> mkBiFunc(Map map) {
 137         return (k,v) -> {
 138             putToForceRehash(map);
 139             return "computedValue";
 140         };
 141     }

Can you avoid using raw types?

Paul.


From vladimir.kozlov at oracle.com  Sat Mar 21 16:25:25 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Sat, 21 Mar 2015 09:25:25 -0700
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <EC9252DA-761C-440E-B7E4-9EC52790DFE6@oracle.com>
References: <550330CE.3030607@redhat.com>
	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>
	<550710BD.5060301@redhat.com>
	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>
	<5508325C.4000108@redhat.com> <550A90CE.9080901@redhat.com>
	<550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com>
	<550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com>
	<550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com>
	<EC9252DA-761C-440E-B7E4-9EC52790DFE6@oracle.com>
Message-ID: <550D9B75.3000506@oracle.com>

If you say so, John, I am okay with BE.

Vladimir

On 3/20/15 10:21 PM, John Rose wrote:
> I'm glad to see this coming along?  The code, javadoc, and spec all look good.
>
> On Mar 20, 2015, at 3:00 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>
>>> http://cr.openjdk.java.net/~aph/unaligned.jdk.7/
>>
>> My only comment for jdk change is to use bigEndian name instead of BE in Unsafe.java. Someone from core libs should
>> look on this.
>
> Here's my take on that bit (subject of course to correction from a core-libs eng.).
>
> BE (though short), as an upper-case acronym, is more correct than mixed-case bigEndian, according to the conventions
> suggested by JLS 6.1:
>
>> Constant Names
>>
>> The names of constants in interface types should be, and final variables of class types may conventionally be, a
>> sequence of one or more words, acronyms, or abbreviations, all uppercase, with components separated by underscore "_"
>> characters. Constant names should be descriptive and not unnecessarily abbreviated. Conventionally they may be
>> any appropriate part of speech.
>>
>> Examples of names for constants include MIN_VALUE, MAX_VALUE, MIN_RADIX, and MAX_RADIX of the class Character.
>
> So I think it's OK as-is, especially since it is a private name.
>
> ? John


From vladimir.kozlov at oracle.com  Sat Mar 21 16:32:02 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Sat, 21 Mar 2015 09:32:02 -0700
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <550D57B1.602@redhat.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>	<550A90CE.9080901@redhat.com>
	<550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com>
	<550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com>
	<550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com>
	<550D57B1.602@redhat.com>
Message-ID: <550D9D02.1020303@oracle.com>

On 3/21/15 4:36 AM, Andrew Haley wrote:
> On 20/03/15 22:00, Vladimir Kozlov wrote:
>> On 3/20/15 9:08 AM, Andrew Haley wrote:
>>> Webrev at
>>>
>>> http://cr.openjdk.java.net/~aph/unaligned.hotspot.7/
>>
>> I don't see changes to VM's makefiles to set VM_BIG_ENDIAN. Or consider
>> it is set if VM_LITTLE_ENDIAN is not set in prims/unsafe.cpp code.
>
> Darn, I already made that change once but missed it in this webrev.  Sorry.

I will wait new webrev.

>
>> In globals.hpp the empty line after flag description should not have '\'
>> at the end.
>
> OK.
>
>> Otherwise it looks good.
>>
>>> http://cr.openjdk.java.net/~aph/unaligned.jdk.7/
>>
>> My only comment for jdk change is to use bigEndian name instead of BE in
>> Unsafe.java. Someone from core libs should look on this.
>
> I would have used that, but I followed John Rose's suggestion.  I
> don't mind making changes but having to change it back-and-forth
> really is too much.

John have more authority than me :) so be it BE.

>
>>> I've moved the test case into the hotspot repo
>>> The test case is diagnostic, not experimental
>
> Yes, is is.  I was told to do that.

I am fine with diagnostic type of flag. The sponsor from Oracle have to set the flag in our closed sources similar to 
open vm_verstion_* changes - but it is small change.

Thanks,
Vladimir

>
> Andrew.
>


From david.lloyd at redhat.com  Sat Mar 21 21:11:39 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Sat, 21 Mar 2015 16:11:39 -0500
Subject: Fw: Re: RFR [9] 8071472: Add field access to support,	setting
	final fields in readObject
In-Reply-To: <550CE00F.40403@zeus.net.au>
References: <mailman.52449.1426871986.10816.core-libs-dev@openjdk.java.net>
	<550CE00F.40403@zeus.net.au>
Message-ID: <550DDE8B.4030605@redhat.com>

I think you didn't understand the issue being discussed - it's not about 
fields that are added/removed, which is very clearly defined in the 
spec.  It's about what happens when you don't call 
defaultRead|WriteFields, which is required by spec but not always done 
in practice.

On 03/20/2015 10:05 PM, Peter Firmstone wrote:
> The reason for this part of the spec, is backward compatible
> evolvability of serial form.
>
> It allows an earlier implementation of a class to deserialize serial
> form from a later implementation that includes additional fields or
> values written to the stream, and allow them to be discarded by
> ObjectInputStream, when the earilier implementation doesn't read/consume
> them.
>
> If classes deliberately break the contract / spec, then although they
> function, they limit their backward compatible evolvability; in other
> words, if a later class has additional fields or writes additional
> values to the stream, a StreamCorruptedException will occur when an
> earlier class implementation reads it.
>
> For that reason, I'd reccommend against including it in the spec.
>
> Regards,
>
> Peter.
>
>
>> ------------------------------
>>
>> Message: 4
>> Date: Fri, 20 Mar 2015 11:57:04 -0500
>> From: "David M. Lloyd"<david.lloyd at redhat.com>
>> To: core-libs-dev at openjdk.java.net
>> Subject: Re: Fw: Re: RFR [9] 8071472: Add field access to support
>>     setting    final fields in readObject
>> Message-ID:<550C5160.2030106 at redhat.com>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> On 03/20/2015 09:31 AM, Peter Levart wrote:
>>> On 03/20/2015 02:03 PM, David M. Lloyd wrote:
>>>>>> private static void altReadObject(ObjectInputStream in, FieldAccess
>>>>>> fieldAccess) throws IOException, ClassNotFoundException {
>>>>>>              // the same as in readObject, but doesn't have direct
>>>>>> access to
>>>>>> instance state, so everything must go through FieldAccess API?
>>>>>> }
>>>>>>
>>>>>>
>>>>> Yes.
>>>> An interesting aspect of this approach is that it deals with a problem
>>>> in the serialization spec [1] where it specifically says that
>>>> serializable classes should be reading/writing stream fields always,
>>>> and before reading/writing other data:
>>>>
>>>> In section 3.4: "Either ObjectInputStream's defaultReadObject or
>>>> readFields method must be called once (and only once) before reading
>>>> any optional data written by the corresponding writeObject method;
>>>> even if no optional data is read, defaultReadObject or readFields must
>>>> still be invoked once."
>>>>
>>>> In section 2.3: "Either ObjectOutputStream's defaultWriteObject or
>>>> writeFields method must be called once (and only once) before writing
>>>> any optional data that will be needed by the corresponding readObject
>>>> method to restore the state of the object; even if no optional data is
>>>> written, defaultWriteObject or writeFields must still be invoked once."
>>>>
>>>> But classes (even JDK classes) often disregard this requirement,
>>>> relying on known implementation behavior and either reading/writing
>>>> optional data before fields or just not reading/writing fields at
>>>> all.  So either the spec should be updated (I've tried to do this but
>>>> nobody seems to know how to modify this old content I guess) to match
>>>> behavior, or the spec should be enforced more strictly - however doing
>>>> the latter *will* break a lot of user code, *unless* an alternative
>>>> readObject method is introduced with the more strict enforcement.  But
>>>> I guess even in this case, the spec should be updated to allow the
>>>> implementation behavior.
>>>>
>>>> [1]
>>>> http://docs.oracle.com/javase/8/docs/platform/serialization/spec/serialTOC.html
>>>>
>>>>
>>> I guess this would need an alternative writeObject method too, with more
>>> strict enforcement, or not?
>> Sounds fine to me...
>>
>>> I don't know from the top of my head, but does the order of writing
>>> optional data (before or after) fields, change the order of data emitted
>>> in stream and does that order have to be respected when reading back in
>>> readObject()?
>> Yes.
>>
>>> In that case, I guess, we would need an alternative
>>> writeObject method too, with more strict enforcement of order. But I
>>> think that having two different rules for old read/writeObject and
>>> alternative read/writeObject would just confuse people. If current rules
>>> don't present any problem (apart from being looser then specification
>>> requires) then perhaps just specification should be updated.
>> Maybe.
>>
>

-- 
- DML


From ecki at zusammenkunft.net  Sat Mar 21 23:54:40 2015
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sun, 22 Mar 2015 00:54:40 +0100
Subject: Javadoc nit Throwable#getStackTraceElement
Message-ID: <20150322005440.000005f2.ecki@zusammenkunft.net>

There is an typo in the javadoc, 

 * @throws IndexOutOfBoundsException if <tt>index %lt; 0 ||
 *         index &gt;= getStackTraceDepth() </tt>

Maybe using {@code index < 0 || index > getStackTraceDepth()} would be
better here?

Gruss
Bernd


From peter.firmstone at zeus.net.au  Sun Mar 22 00:39:02 2015
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sun, 22 Mar 2015 10:39:02 +1000
Subject: Fw: Re: RFR [9] 8071472: Add field access to support,	setting
	final fields in readObject
In-Reply-To: <550DDE8B.4030605@redhat.com>
References: <mailman.52449.1426871986.10816.core-libs-dev@openjdk.java.net>
	<550CE00F.40403@zeus.net.au> <550DDE8B.4030605@redhat.com>
Message-ID: <1426984742.2614.5.camel@Nokia-N900>

If an object defines readObject(), then it is responsible for reading fields.

So lets say for arguments sake that all fields are transient in the first version of an Object and it doesn't call defaultReadObject or GetFields before reading in block data.

If at some later time the developer defines a non-transient field, the earlier version cannot deserialise the later versions serial form, because the field appears in the stream, when it is expecting block data.

If the developer decided instead to call defaultReadObject even if all fields were transient, then backward compatibility is preserved because the fields are removed from the stream, before the earlier object version reads block data following the fields.

Now lets say, for the sake of another example, that an object writes block data, before writing fields.

Food for thought:

How is excess block data or an additional field discarded by the stream by earlier versions if an Object's later version adds fields or block data?

Regards,

Peter.


----- Original message -----
> I think you didn't understand the issue being discussed - it's not about 
> fields that are added/removed, which is very clearly defined in the 
> spec.?  It's about what happens when you don't call 
> defaultRead|WriteFields, which is required by spec but not always done 
> in practice.
> 
> On 03/20/2015 10:05 PM, Peter Firmstone wrote:
> > The reason for this part of the spec, is backward compatible
> > evolvability of serial form.
> > 
> > It allows an earlier implementation of a class to deserialize serial
> > form from a later implementation that includes additional fields or
> > values written to the stream, and allow them to be discarded by
> > ObjectInputStream, when the earilier implementation doesn't
> > read/consume them.
> > 
> > If classes deliberately break the contract / spec, then although they
> > function, they limit their backward compatible evolvability; in other
> > words, if a later class has additional fields or writes additional
> > values to the stream, a StreamCorruptedException will occur when an
> > earlier class implementation reads it.
> > 
> > For that reason, I'd reccommend against including it in the spec.
> > 
> > Regards,
> > 
> > Peter.
> > 
> > 
> > > ------------------------------
> > > 
> > > Message: 4
> > > Date: Fri, 20 Mar 2015 11:57:04 -0500
> > > From: "David M. Lloyd"<david.lloyd at redhat.com>
> > > To: core-libs-dev at openjdk.java.net
> > > Subject: Re: Fw: Re: RFR [9] 8071472: Add field access to support
> > > setting? ? ?  final fields in readObject
> > > Message-ID:<550C5160.2030106 at redhat.com>
> > > Content-Type: text/plain; charset=utf-8; format=flowed
> > > 
> > > On 03/20/2015 09:31 AM, Peter Levart wrote:
> > > > On 03/20/2015 02:03 PM, David M. Lloyd wrote:
> > > > > > > private static void altReadObject(ObjectInputStream in,
> > > > > > > FieldAccess fieldAccess) throws IOException,
> > > > > > > ClassNotFoundException { // the same as in readObject, but
> > > > > > > doesn't have direct access to
> > > > > > > instance state, so everything must go through FieldAccess
> > > > > > > API? }
> > > > > > > 
> > > > > > > 
> > > > > > Yes.
> > > > > An interesting aspect of this approach is that it deals with a
> > > > > problem in the serialization spec [1] where it specifically says
> > > > > that serializable classes should be reading/writing stream
> > > > > fields always, and before reading/writing other data:
> > > > > 
> > > > > In section 3.4: "Either ObjectInputStream's defaultReadObject or
> > > > > readFields method must be called once (and only once) before
> > > > > reading any optional data written by the corresponding
> > > > > writeObject method; even if no optional data is read,
> > > > > defaultReadObject or readFields must still be invoked once."
> > > > > 
> > > > > In section 2.3: "Either ObjectOutputStream's defaultWriteObject
> > > > > or writeFields method must be called once (and only once) before
> > > > > writing any optional data that will be needed by the
> > > > > corresponding readObject method to restore the state of the
> > > > > object; even if no optional data is written, defaultWriteObject
> > > > > or writeFields must still be invoked once."
> > > > > 
> > > > > But classes (even JDK classes) often disregard this requirement,
> > > > > relying on known implementation behavior and either
> > > > > reading/writing optional data before fields or just not
> > > > > reading/writing fields at all.?  So either the spec should be
> > > > > updated (I've tried to do this but nobody seems to know how to
> > > > > modify this old content I guess) to match behavior, or the spec
> > > > > should be enforced more strictly - however doing the latter
> > > > > *will* break a lot of user code, *unless* an alternative
> > > > > readObject method is introduced with the more strict
> > > > > enforcement.?  But I guess even in this case, the spec should be
> > > > > updated to allow the implementation behavior.
> > > > > 
> > > > > [1]
> > > > > http://docs.oracle.com/javase/8/docs/platform/serialization/spec/serialTOC.html
> > > > > 
> > > > > 
> > > > I guess this would need an alternative writeObject method too,
> > > > with more strict enforcement, or not?
> > > Sounds fine to me...
> > > 
> > > > I don't know from the top of my head, but does the order of writing
> > > > optional data (before or after) fields, change the order of data
> > > > emitted in stream and does that order have to be respected when
> > > > reading back in readObject()?
> > > Yes.
> > > 
> > > > In that case, I guess, we would need an alternative
> > > > writeObject method too, with more strict enforcement of order. But
> > > > I think that having two different rules for old read/writeObject
> > > > and alternative read/writeObject would just confuse people. If
> > > > current rules don't present any problem (apart from being looser
> > > > then specification requires) then perhaps just specification
> > > > should be updated.
> > > Maybe.
> > > 
> > 
> 
> -- 
> - DML



From peter.firmstone at zeus.net.au  Sun Mar 22 02:44:08 2015
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sun, 22 Mar 2015 12:44:08 +1000
Subject: Fw: Re: RFR [9] 8071472: Add field access to support,	setting
	final fields in readObject
In-Reply-To: <1426984742.2614.5.camel@Nokia-N900>
References: <mailman.52449.1426871986.10816.core-libs-dev@openjdk.java.net>
	<550CE00F.40403@zeus.net.au> <550DDE8B.4030605@redhat.com>
	<1426984742.2614.5.camel@Nokia-N900>
Message-ID: <1426992248.2869.11.camel@Nokia-N900>

What happens, to answer your question, is the fields, if any, won't appear in the stream where they are supposed to be.

Again this will affect evolvability of serial form.  In other words, incorrect implementations are locked into their current serial form.  I don't think that's something that should be encouraged.

----- Original message -----
> If an object defines readObject(), then it is responsible for reading
> fields.
> 
> So lets say for arguments sake that all fields are transient in the
> first version of an Object and it doesn't call defaultReadObject or
> GetFields before reading in block data.
> 
> If at some later time the developer defines a non-transient field, the
> earlier version cannot deserialise the later versions serial form,
> because the field appears in the stream, when it is expecting block data.
> 
> If the developer decided instead to call defaultReadObject even if all
> fields were transient, then backward compatibility is preserved because
> the fields are removed from the stream, before the earlier object
> version reads block data following the fields.
> 
> Now lets say, for the sake of another example, that an object writes
> block data, before writing fields.
> 
> Food for thought:
> 
> How is excess block data or an additional field discarded by the stream
> by earlier versions if an Object's later version adds fields or block
> data?
> 
> Regards,
> 
> Peter.
> 
> 
> ----- Original message -----
> > I think you didn't understand the issue being discussed - it's not
> > about?  fields that are added/removed, which is very clearly defined in
> > the?  spec.??  It's about what happens when you don't call 
> > defaultRead|WriteFields, which is required by spec but not always done 
> > in practice.
> > 
> > On 03/20/2015 10:05 PM, Peter Firmstone wrote:
> > > The reason for this part of the spec, is backward compatible
> > > evolvability of serial form.
> > > 
> > > It allows an earlier implementation of a class to deserialize serial
> > > form from a later implementation that includes additional fields or
> > > values written to the stream, and allow them to be discarded by
> > > ObjectInputStream, when the earilier implementation doesn't
> > > read/consume them.
> > > 
> > > If classes deliberately break the contract / spec, then although they
> > > function, they limit their backward compatible evolvability; in other
> > > words, if a later class has additional fields or writes additional
> > > values to the stream, a StreamCorruptedException will occur when an
> > > earlier class implementation reads it.
> > > 
> > > For that reason, I'd reccommend against including it in the spec.
> > > 
> > > Regards,
> > > 
> > > Peter.
> > > 
> > > 
> > > > ------------------------------
> > > > 
> > > > Message: 4
> > > > Date: Fri, 20 Mar 2015 11:57:04 -0500
> > > > From: "David M. Lloyd"<david.lloyd at redhat.com>
> > > > To: core-libs-dev at openjdk.java.net
> > > > Subject: Re: Fw: Re: RFR [9] 8071472: Add field access to support
> > > > setting? ? ??  final fields in readObject
> > > > Message-ID:<550C5160.2030106 at redhat.com>
> > > > Content-Type: text/plain; charset=utf-8; format=flowed
> > > > 
> > > > On 03/20/2015 09:31 AM, Peter Levart wrote:
> > > > > On 03/20/2015 02:03 PM, David M. Lloyd wrote:
> > > > > > > > private static void altReadObject(ObjectInputStream in,
> > > > > > > > FieldAccess fieldAccess) throws IOException,
> > > > > > > > ClassNotFoundException { // the same as in readObject, but
> > > > > > > > doesn't have direct access to
> > > > > > > > instance state, so everything must go through FieldAccess
> > > > > > > > API? }
> > > > > > > > 
> > > > > > > > 
> > > > > > > Yes.
> > > > > > An interesting aspect of this approach is that it deals with a
> > > > > > problem in the serialization spec [1] where it specifically
> > > > > > says that serializable classes should be reading/writing stream
> > > > > > fields always, and before reading/writing other data:
> > > > > > 
> > > > > > In section 3.4: "Either ObjectInputStream's defaultReadObject
> > > > > > or readFields method must be called once (and only once) before
> > > > > > reading any optional data written by the corresponding
> > > > > > writeObject method; even if no optional data is read,
> > > > > > defaultReadObject or readFields must still be invoked once."
> > > > > > 
> > > > > > In section 2.3: "Either ObjectOutputStream's defaultWriteObject
> > > > > > or writeFields method must be called once (and only once)
> > > > > > before writing any optional data that will be needed by the
> > > > > > corresponding readObject method to restore the state of the
> > > > > > object; even if no optional data is written, defaultWriteObject
> > > > > > or writeFields must still be invoked once."
> > > > > > 
> > > > > > But classes (even JDK classes) often disregard this
> > > > > > requirement, relying on known implementation behavior and
> > > > > > either reading/writing optional data before fields or just not
> > > > > > reading/writing fields at all.??  So either the spec should be
> > > > > > updated (I've tried to do this but nobody seems to know how to
> > > > > > modify this old content I guess) to match behavior, or the spec
> > > > > > should be enforced more strictly - however doing the latter
> > > > > > *will* break a lot of user code, *unless* an alternative
> > > > > > readObject method is introduced with the more strict
> > > > > > enforcement.??  But I guess even in this case, the spec should
> > > > > > be updated to allow the implementation behavior.
> > > > > > 
> > > > > > [1]
> > > > > > http://docs.oracle.com/javase/8/docs/platform/serialization/spec/serialTOC.html
> > > > > > 
> > > > > > 
> > > > > I guess this would need an alternative writeObject method too,
> > > > > with more strict enforcement, or not?
> > > > Sounds fine to me...
> > > > 
> > > > > I don't know from the top of my head, but does the order of
> > > > > writing optional data (before or after) fields, change the order
> > > > > of data emitted in stream and does that order have to be
> > > > > respected when reading back in readObject()?
> > > > Yes.
> > > > 
> > > > > In that case, I guess, we would need an alternative
> > > > > writeObject method too, with more strict enforcement of order.
> > > > > But I think that having two different rules for old
> > > > > read/writeObject and alternative read/writeObject would just
> > > > > confuse people. If current rules don't present any problem
> > > > > (apart from being looser then specification requires) then
> > > > > perhaps just specification should be updated.
> > > > Maybe.
> > > > 
> > > 
> > 
> > -- 
> > - DML
> 



From peter.firmstone at zeus.net.au  Sun Mar 22 05:53:54 2015
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sun, 22 Mar 2015 15:53:54 +1000
Subject: Fw: Re: RFR [9] 8071472: Add field access to support,	setting
	final fields in readObject
In-Reply-To: <1426992248.2869.11.camel@Nokia-N900>
References: <mailman.52449.1426871986.10816.core-libs-dev@openjdk.java.net>
	<550CE00F.40403@zeus.net.au> <550DDE8B.4030605@redhat.com>
	<1426984742.2614.5.camel@Nokia-N900>
	<1426992248.2869.11.camel@Nokia-N900>
Message-ID: <1427003634.3407.9.camel@Nokia-N900>

Was there a use you had in mind, or some other reason you thought the spec should be modified to accomodate it?

Such as improve serial form evolution flexibility, when someone's forgotten to call defaultReadObject|WriteObject?

I'm not sure how that can be implemented though, requires further thought; to see if it can be done without breaking the serialization stream protocol.

Regards,

Peter.

----- Original message -----
> What happens, to answer your question, is the fields, if any, won't
> appear in the stream where they are supposed to be.
> 
> Again this will affect evolvability of serial form.?  In other words,
> incorrect implementations are locked into their current serial form.?  I
> don't think that's something that should be encouraged.
> 
> ----- Original message -----
> > If an object defines readObject(), then it is responsible for reading
> > fields.
> > 
> > So lets say for arguments sake that all fields are transient in the
> > first version of an Object and it doesn't call defaultReadObject or
> > GetFields before reading in block data.
> > 
> > If at some later time the developer defines a non-transient field, the
> > earlier version cannot deserialise the later versions serial form,
> > because the field appears in the stream, when it is expecting block
> > data.
> > 
> > If the developer decided instead to call defaultReadObject even if all
> > fields were transient, then backward compatibility is preserved because
> > the fields are removed from the stream, before the earlier object
> > version reads block data following the fields.
> > 
> > Now lets say, for the sake of another example, that an object writes
> > block data, before writing fields.
> > 
> > Food for thought:
> > 
> > How is excess block data or an additional field discarded by the stream
> > by earlier versions if an Object's later version adds fields or block
> > data?
> > 
> > Regards,
> > 
> > Peter.
> > 
> > 
> > ----- Original message -----
> > > I think you didn't understand the issue being discussed - it's not
> > > about??  fields that are added/removed, which is very clearly defined
> > > in the??  spec.???  It's about what happens when you don't call 
> > > defaultRead|WriteFields, which is required by spec but not always
> > > done?  in practice.
> > > 
> > > On 03/20/2015 10:05 PM, Peter Firmstone wrote:
> > > > The reason for this part of the spec, is backward compatible
> > > > evolvability of serial form.
> > > > 
> > > > It allows an earlier implementation of a class to deserialize
> > > > serial form from a later implementation that includes additional
> > > > fields or values written to the stream, and allow them to be
> > > > discarded by ObjectInputStream, when the earilier implementation
> > > > doesn't read/consume them.
> > > > 
> > > > If classes deliberately break the contract / spec, then although
> > > > they function, they limit their backward compatible evolvability;
> > > > in other words, if a later class has additional fields or writes
> > > > additional values to the stream, a StreamCorruptedException will
> > > > occur when an earlier class implementation reads it.
> > > > 
> > > > For that reason, I'd reccommend against including it in the spec.
> > > > 
> > > > Regards,
> > > > 
> > > > Peter.
> > > > 
> > > > 
> > > > > ------------------------------
> > > > > 
> > > > > Message: 4
> > > > > Date: Fri, 20 Mar 2015 11:57:04 -0500
> > > > > From: "David M. Lloyd"<david.lloyd at redhat.com>
> > > > > To: core-libs-dev at openjdk.java.net
> > > > > Subject: Re: Fw: Re: RFR [9] 8071472: Add field access to support
> > > > > setting? ? ???  final fields in readObject
> > > > > Message-ID:<550C5160.2030106 at redhat.com>
> > > > > Content-Type: text/plain; charset=utf-8; format=flowed
> > > > > 
> > > > > On 03/20/2015 09:31 AM, Peter Levart wrote:
> > > > > > On 03/20/2015 02:03 PM, David M. Lloyd wrote:
> > > > > > > > > private static void altReadObject(ObjectInputStream in,
> > > > > > > > > FieldAccess fieldAccess) throws IOException,
> > > > > > > > > ClassNotFoundException { // the same as in readObject,
> > > > > > > > > but doesn't have direct access to
> > > > > > > > > instance state, so everything must go through FieldAccess
> > > > > > > > > API? }
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > Yes.
> > > > > > > An interesting aspect of this approach is that it deals with
> > > > > > > a problem in the serialization spec [1] where it specifically
> > > > > > > says that serializable classes should be reading/writing
> > > > > > > stream fields always, and before reading/writing other data:
> > > > > > > 
> > > > > > > In section 3.4: "Either ObjectInputStream's defaultReadObject
> > > > > > > or readFields method must be called once (and only once)
> > > > > > > before reading any optional data written by the corresponding
> > > > > > > writeObject method; even if no optional data is read,
> > > > > > > defaultReadObject or readFields must still be invoked once."
> > > > > > > 
> > > > > > > In section 2.3: "Either ObjectOutputStream's
> > > > > > > defaultWriteObject or writeFields method must be called once
> > > > > > > (and only once) before writing any optional data that will
> > > > > > > be needed by the corresponding readObject method to restore
> > > > > > > the state of the object; even if no optional data is
> > > > > > > written, defaultWriteObject or writeFields must still be
> > > > > > > invoked once."
> > > > > > > 
> > > > > > > But classes (even JDK classes) often disregard this
> > > > > > > requirement, relying on known implementation behavior and
> > > > > > > either reading/writing optional data before fields or just
> > > > > > > not reading/writing fields at all.???  So either the spec
> > > > > > > should be updated (I've tried to do this but nobody seems to
> > > > > > > know how to modify this old content I guess) to match
> > > > > > > behavior, or the spec should be enforced more strictly -
> > > > > > > however doing the latter *will* break a lot of user code,
> > > > > > > *unless* an alternative readObject method is introduced with
> > > > > > > the more strict enforcement.???  But I guess even in this
> > > > > > > case, the spec should be updated to allow the implementation
> > > > > > > behavior.
> > > > > > > 
> > > > > > > [1]
> > > > > > > http://docs.oracle.com/javase/8/docs/platform/serialization/spec/serialTOC.html
> > > > > > > 
> > > > > > > 
> > > > > > I guess this would need an alternative writeObject method too,
> > > > > > with more strict enforcement, or not?
> > > > > Sounds fine to me...
> > > > > 
> > > > > > I don't know from the top of my head, but does the order of
> > > > > > writing optional data (before or after) fields, change the
> > > > > > order of data emitted in stream and does that order have to be
> > > > > > respected when reading back in readObject()?
> > > > > Yes.
> > > > > 
> > > > > > In that case, I guess, we would need an alternative
> > > > > > writeObject method too, with more strict enforcement of order.
> > > > > > But I think that having two different rules for old
> > > > > > read/writeObject and alternative read/writeObject would just
> > > > > > confuse people. If current rules don't present any problem
> > > > > > (apart from being looser then specification requires) then
> > > > > > perhaps just specification should be updated.
> > > > > Maybe.
> > > > > 
> > > > 
> > > 
> > > -- 
> > > - DML
> > 
> 



From david.holmes at oracle.com  Sun Mar 22 08:37:27 2015
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 22 Mar 2015 18:37:27 +1000
Subject: Javadoc nit Throwable#getStackTraceElement
In-Reply-To: <20150322005440.000005f2.ecki@zusammenkunft.net>
References: <20150322005440.000005f2.ecki@zusammenkunft.net>
Message-ID: <550E7F47.4010302@oracle.com>

On 22/03/2015 9:54 AM, Bernd Eckenfels wrote:
> There is an typo in the javadoc,
>
>   * @throws IndexOutOfBoundsException if <tt>index %lt; 0 ||
>   *         index &gt;= getStackTraceDepth() </tt>
>
> Maybe using {@code index < 0 || index > getStackTraceDepth()} would be
> better here?

Don't we index from zero to getStackTraceDepth()-1 ? So >= would be correct.

David

> Gruss
> Bernd
>


From ecki at zusammenkunft.net  Sun Mar 22 08:47:26 2015
From: ecki at zusammenkunft.net (Bernd)
Date: Sun, 22 Mar 2015 08:47:26 +0000
Subject: Javadoc nit Throwable#getStackTraceElement
In-Reply-To: <550E7F47.4010302@oracle.com>
References: <20150322005440.000005f2.ecki@zusammenkunft.net>
	<550E7F47.4010302@oracle.com>
Message-ID: <CABOR3+y_VRLgM-kKDa-ZD330YHG5WMSA9m=dKEivc=Yh-A86DQ@mail.gmail.com>

Oh yes, sorry of course. My report was about the wrong % entity escape. The
expression should be >= like before.

Greetings
Bernd

David Holmes <david.holmes at oracle.com> schrieb am So., 22. M?r. 2015 09:37:

> On 22/03/2015 9:54 AM, Bernd Eckenfels wrote:
> > There is an typo in the javadoc,
> >
> >   * @throws IndexOutOfBoundsException if <tt>index %lt; 0 ||
> >   *         index &gt;= getStackTraceDepth() </tt>
> >
> > Maybe using {@code index < 0 || index > getStackTraceDepth()} would be
> > better here?
>
> Don't we index from zero to getStackTraceDepth()-1 ? So >= would be
> correct.
>
> David
>
> > Gruss
> > Bernd
> >
>


From david.holmes at oracle.com  Sun Mar 22 09:22:30 2015
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 22 Mar 2015 19:22:30 +1000
Subject: Javadoc nit Throwable#getStackTraceElement
In-Reply-To: <CABOR3+y_VRLgM-kKDa-ZD330YHG5WMSA9m=dKEivc=Yh-A86DQ@mail.gmail.com>
References: <20150322005440.000005f2.ecki@zusammenkunft.net>
	<550E7F47.4010302@oracle.com>
	<CABOR3+y_VRLgM-kKDa-ZD330YHG5WMSA9m=dKEivc=Yh-A86DQ@mail.gmail.com>
Message-ID: <550E89D6.1030606@oracle.com>

On 22/03/2015 6:47 PM, Bernd wrote:
> Oh yes, sorry of course. My report was about the wrong % entity escape.
> The expression should be >= like before.

I missed the % vs & :)

But I don't see this in our sources going back a long long time - where 
did you see this?

Thanks,
David


> Greetings
> Bernd
>
>
> David Holmes <david.holmes at oracle.com <mailto:david.holmes at oracle.com>>
> schrieb am So., 22. M?r. 2015 09:37:
>
>     On 22/03/2015 9:54 AM, Bernd Eckenfels wrote:
>      > There is an typo in the javadoc,
>      >
>      >   * @throws IndexOutOfBoundsException if <tt>index %lt; 0 ||
>      >   *         index &gt;= getStackTraceDepth() </tt>
>      >
>      > Maybe using {@code index < 0 || index > getStackTraceDepth()}
>      > would be 	better here?
>
>     Don't we index from zero to getStackTraceDepth()-1 ? So >= would be
>     correct.
>
>     David
>
>      > Gruss
>      > Bernd
>      >
>


From ecki at zusammenkunft.net  Sun Mar 22 13:16:31 2015
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sun, 22 Mar 2015 14:16:31 +0100
Subject: Javadoc nit Throwable#getStackTraceElement
In-Reply-To: <550E89D6.1030606@oracle.com>
References: <20150322005440.000005f2.ecki@zusammenkunft.net>
	<550E7F47.4010302@oracle.com>
	<CABOR3+y_VRLgM-kKDa-ZD330YHG5WMSA9m=dKEivc=Yh-A86DQ@mail.gmail.com>
	<550E89D6.1030606@oracle.com>
Message-ID: <20150322141631.00000353.ecki@zusammenkunft.net>

Hello David,

interesting, I thought I saw it in 8u40, however when I check more
closely it was Eclipse suggesting me the source of a 1.5 JDK (even
when the project I was working with was using 8u40). It has already a
@code element. So sorry for the false report.


BTW: speaking of Throwable, the actual reason why I was browsing this
part of the source is because I noticed that ArrayIndexOutOfBounds
exception has a (int index) constructor (which creates a nice detailed
message) but a lot of the users (including the VM code for array
overflows it seems) do not use it - which results in pretty ugly
getMessage() == "2" or "2 > 1" (or similar).

Gruss
Bernd

 Am Sun, 22 Mar
2015 19:22:30 +1000 schrieb David Holmes <david.holmes at oracle.com>:

> On 22/03/2015 6:47 PM, Bernd wrote:
> > Oh yes, sorry of course. My report was about the wrong % entity
> > escape. The expression should be >= like before.
> 
> I missed the % vs & :)
> 
> But I don't see this in our sources going back a long long time -
> where did you see this?
> 
> Thanks,
> David
> 
> 
> > Greetings
> > Bernd
> >
> >
> > David Holmes <david.holmes at oracle.com
> > <mailto:david.holmes at oracle.com>> schrieb am So., 22. M?r. 2015
> > 09:37:
> >
> >     On 22/03/2015 9:54 AM, Bernd Eckenfels wrote:
> >      > There is an typo in the javadoc,
> >      >
> >      >   * @throws IndexOutOfBoundsException if <tt>index %lt; 0 ||
> >      >   *         index &gt;= getStackTraceDepth() </tt>
> >      >
> >      > Maybe using {@code index < 0 || index > getStackTraceDepth()}
> >      > would be 	better here?
> >
> >     Don't we index from zero to getStackTraceDepth()-1 ? So >=
> > would be correct.
> >
> >     David
> >
> >      > Gruss
> >      > Bernd
> >      >
> >



From joe.darcy at oracle.com  Mon Mar 23 03:56:31 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Sun, 22 Mar 2015 20:56:31 -0700
Subject: JDK 9 RFR of JDK-8075670: Remove intermittent keyword from some tests
Message-ID: <550F8EEF.6060204@oracle.com>

Hello,

Upon closer review, some of the tests marked as failing intermittently 
in JDK-8075565 seem to just have suffered from transient infrastructure 
problems. Therefore, those tests

  test/java/nio/channels/AsynchronousSocketChannel/Basic.java
  test/java/nio/channels/Selector/Wakeup.java
  test/java/nio/file/Files/InterruptCopy.java

  should not be marked as failing intermittently. The patch to make this 
adjustment is below.

Thanks,

-Joe

diff -r 9a05a4f72827 
test/java/nio/channels/AsynchronousSocketChannel/Basic.java
--- a/test/java/nio/channels/AsynchronousSocketChannel/Basic.java Sun 
Mar 22 10:27:22 2015 -0700
+++ b/test/java/nio/channels/AsynchronousSocketChannel/Basic.java Sun 
Mar 22 20:53:29 2015 -0700
@@ -25,7 +25,6 @@
   * @bug 4607272 6842687 6878369 6944810 7023403
   * @summary Unit test for AsynchronousSocketChannel
   * @run main Basic -skipSlowConnectTest
- * @key intermittent
   */

  import java.nio.ByteBuffer;
diff -r 9a05a4f72827 test/java/nio/channels/Selector/Wakeup.java
--- a/test/java/nio/channels/Selector/Wakeup.java    Sun Mar 22 10:27:22 
2015 -0700
+++ b/test/java/nio/channels/Selector/Wakeup.java    Sun Mar 22 20:53:29 
2015 -0700
@@ -25,7 +25,6 @@
   * @bug 6405995
   * @summary Unit test for selector wakeup and interruption
   * @library ..
- * @key intermittent
   */

  import java.io.*;
diff -r 9a05a4f72827 test/java/nio/file/Files/InterruptCopy.java
--- a/test/java/nio/file/Files/InterruptCopy.java    Sun Mar 22 10:27:22 
2015 -0700
+++ b/test/java/nio/file/Files/InterruptCopy.java    Sun Mar 22 20:53:29 
2015 -0700
@@ -25,7 +25,6 @@
   * @bug 4313887 6993267
   * @summary Unit test for Sun-specific 
ExtendedCopyOption.INTERRUPTIBLE option
   * @library ..
- * @key intermittent
   */

  import java.nio.file.*;


From Alan.Bateman at oracle.com  Mon Mar 23 08:40:00 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 Mar 2015 08:40:00 +0000
Subject: JDK 9 RFR of JDK-8075670: Remove intermittent keyword from some
	tests
In-Reply-To: <550F8EEF.6060204@oracle.com>
References: <550F8EEF.6060204@oracle.com>
Message-ID: <550FD160.2070906@oracle.com>

On 23/03/2015 03:56, joe darcy wrote:
> Hello,
>
> Upon closer review, some of the tests marked as failing intermittently 
> in JDK-8075565 seem to just have suffered from transient 
> infrastructure problems. Therefore, those tests
>
>  test/java/nio/channels/AsynchronousSocketChannel/Basic.java
>  test/java/nio/channels/Selector/Wakeup.java
>  test/java/nio/file/Files/InterruptCopy.java
>
>  should not be marked as failing intermittently. The patch to make 
> this adjustment is below.
This looks okay.

One other thing is the RMI tests, there are several more than probably 
should have this keyword. Maybe they will get it in time.

-Alan


From weijun.wang at oracle.com  Mon Mar 23 09:47:51 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Mon, 23 Mar 2015 17:47:51 +0800
Subject: A PEM base64 decoder? (was: RFR 8074935: jdk8 keytool doesn't
	validate pem files for RFC 1421 correctness, as jdk7 did)
References: <550FCFCE.2060904@redhat.com>
Message-ID: <D852AAAD-9A42-49EE-8AC4-472C71D06666@oracle.com>



> Begin forwarded message:
> 
> Date: March 23, 2015 at 16:33:18 GMT+8
> From: Florian Weimer <fweimer at redhat.com>
> To: Wang Weijun <weijun.wang at oracle.com>, OpenJDK Dev list <security-dev at openjdk.java.net>
> Subject: Re: RFR 8074935: jdk8 keytool doesn't validate pem files for RFC 1421 correctness, as jdk7 did
> 
> On 03/17/2015 11:02 AM, Wang Weijun wrote:
>> Hi All
>> 
>> Please review the code change at
>> 
>>   http://cr.openjdk.java.net/~weijun/8074935/webrev.00/
>> 
>> In jdk8, we use Base64.getMimeDecoder() to parse PEM-encoded certs and it ignores every character not in the base-64 alphabet. PEM is more restricted and as I know openssl rejects PEM with illegal chars (Ex, "!" as in bug report and test). This fix will also reject them.
> 
> Shouldn't you add a Base64.getPemDecoder() with these semantics?  I
> think this decoder would be useful in other contexts as well.

Sherman, is that possible?

Thanks
Max

> 
> -- 
> Florian Weimer / Red Hat Product Security



From chris.hegarty at oracle.com  Mon Mar 23 11:16:09 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 23 Mar 2015 11:16:09 +0000
Subject: RFR 8071667 : HashMap.computeIfAbsent() adds entry that
	HashMap.get() does not find.
In-Reply-To: <3DEEDED0-74F1-4B54-9A8A-6A36B1AB1B59@oracle.com>
References: <5509BA01.6000709@oracle.com>	<684AF3A3-4280-47B3-AA8D-64248C5DDA9A@oracle.com>	<550B4E4D.5010500@oracle.com>	<AC534548-0FE0-4763-B535-2E1B8888EF66@oracle.com>	<550C8FCD.7070304@oracle.com>
	<3DEEDED0-74F1-4B54-9A8A-6A36B1AB1B59@oracle.com>
Message-ID: <550FF5F9.50305@oracle.com>

I wonder if we, optionally, pass the exception type, either CME or IAE, 
could we add CHM to the DataProvider?

On 21/03/15 13:43, Paul Sandoz wrote:
>
> On Mar 20, 2015, at 10:23 PM, Brent Christian <brent.christian at oracle.com> wrote:
>
>> Here's the latest:
>>
>> http://cr.openjdk.java.net/~bchristi/8071667/webrev.4/
>>
>> That should have everything.
>>
>
> Looks good (i assumed all but the test code has remained unchanged).
>
> I like the test. A minor comment:
>
>   125     private static void checkCME(Consumer code, boolean expectCME) {
>   126         try {
>   127             code.accept(null);
>   128         } catch (ConcurrentModificationException cme) {
>   129             if (expectCME) { return; } else { throw cme; }
>   130         }
>   131         if (expectCME) {
>   132             throw new RuntimeException("Expected CME, but wasn't thrown");
>   133         }
>   134     }
>   135
>   136     private static BiFunction<String,String,String> mkBiFunc(Map map) {
>   137         return (k,v) -> {
>   138             putToForceRehash(map);
>   139             return "computedValue";
>   140         };
>   141     }
>
> Can you avoid using raw types?

Yes, all test code should be lint free ;-) Or at least all new test code 
( where practicable ).

-Chris.

>
> Paul.
>


From chris.hegarty at oracle.com  Mon Mar 23 11:28:34 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 23 Mar 2015 11:28:34 +0000
Subject: RFR 9: 8067796: (process) Process.waitFor(timeout, unit) doesn't
	throw NPE if timeout is less than, or equal to zero when unit == null
In-Reply-To: <CA+kOe0_PKxN180n5OdKu74nhHo7At2MfKi_7+nbEMRoHiNHuTA@mail.gmail.com>
References: <550C95C9.20900@Oracle.com>
	<CA+kOe0_PKxN180n5OdKu74nhHo7At2MfKi_7+nbEMRoHiNHuTA@mail.gmail.com>
Message-ID: <550FF8E2.9060208@oracle.com>


On 20/03/15 22:23, Martin Buchholz wrote:
> I probably implemented it the way it is intentionally.  I would leave it.
> ....
>
> Just move
>
> long remainingNanos = unit.toNanos(timeout);
>
> ...
>>
>> Webrev:
>>       ://cr.openjdk.java.net/~rriggs/webrev-npe-8067796/

Either change is fine with me. I do like the explicitness of 
requiresNonNull, but I guess with the addition of the test then this is 
unlikely to creep back in.

-Chris.


From paul.sandoz at oracle.com  Mon Mar 23 11:35:46 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 23 Mar 2015 12:35:46 +0100
Subject: RFR 8071667 : HashMap.computeIfAbsent() adds entry that
	HashMap.get() does not find.
In-Reply-To: <550FF5F9.50305@oracle.com>
References: <5509BA01.6000709@oracle.com>	<684AF3A3-4280-47B3-AA8D-64248C5DDA9A@oracle.com>	<550B4E4D.5010500@oracle.com>	<AC534548-0FE0-4763-B535-2E1B8888EF66@oracle.com>	<550C8FCD.7070304@oracle.com>
	<3DEEDED0-74F1-4B54-9A8A-6A36B1AB1B59@oracle.com>
	<550FF5F9.50305@oracle.com>
Message-ID: <D17EE7E0-ECFC-489A-A206-FA4111ADE96B@oracle.com>


On Mar 23, 2015, at 12:16 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> I wonder if we, optionally, pass the exception type, either CME or IAE, could we add CHM to the DataProvider?
> 

Possibly, but I suspect any tests for CHM will be more fragile and involved. My sense is it may be premature to do that right now.

To tickle the locations where ISEs are thrown the CHM compute functions probably need to perturb the bucket where the key computed on is, or is to be, located and tests might need to perform concurrent updates to induce resizes. 

Paul.


From chris.hegarty at oracle.com  Mon Mar 23 11:46:05 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 23 Mar 2015 11:46:05 +0000
Subject: RFR 8071667 : HashMap.computeIfAbsent() adds entry that
	HashMap.get() does not find.
In-Reply-To: <D17EE7E0-ECFC-489A-A206-FA4111ADE96B@oracle.com>
References: <5509BA01.6000709@oracle.com>	<684AF3A3-4280-47B3-AA8D-64248C5DDA9A@oracle.com>	<550B4E4D.5010500@oracle.com>	<AC534548-0FE0-4763-B535-2E1B8888EF66@oracle.com>	<550C8FCD.7070304@oracle.com>	<3DEEDED0-74F1-4B54-9A8A-6A36B1AB1B59@oracle.com>	<550FF5F9.50305@oracle.com>
	<D17EE7E0-ECFC-489A-A206-FA4111ADE96B@oracle.com>
Message-ID: <550FFCFD.7020506@oracle.com>


On 23/03/15 11:35, Paul Sandoz wrote:
>
> On Mar 23, 2015, at 12:16 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>
>> I wonder if we, optionally, pass the exception type, either CME or IAE, could we add CHM to the DataProvider?
>>
>
> Possibly, but I suspect any tests for CHM will be more fragile and involved. My sense is it may be premature to do that right now.

OK, no problem. Just a thought.

> To tickle the locations where ISEs are thrown the CHM compute functions probably need to perturb the bucket where the key computed on is, or is to be, located and tests might need to perform concurrent updates to induce resizes.

-Chris.

> Paul.
>


From paul.sandoz at oracle.com  Mon Mar 23 13:16:58 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 23 Mar 2015 14:16:58 +0100
Subject: [9] RFC on 8074467: In some cases,
	BigDecimal's  toBigInteger() produces wrong result
In-Reply-To: <B9960AA3-1769-4725-A222-013AFE8B1DFB@oracle.com>
References: <B9960AA3-1769-4725-A222-013AFE8B1DFB@oracle.com>
Message-ID: <2796387B-C616-4AC2-9AC4-EC25934FDF77@oracle.com>

Hi Brian,

This seems like a "Cannot Reproduce" (the description is fuzzy about what versions of the JDK this previously worked on), and request further info.

You might want to check 8u20 and/or 8u31 (which is the version marked in the bug), rather than 8u40, just to double check if something was not inadvertently introduced that was subsequently fixed.

Paul.

On Mar 20, 2015, at 6:59 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> Comments from the ?numerologists? on this list would be appreciated.
> 
> I investigated this issue
> 
> https://bugs.openjdk.java.net/browse/JDK-8074467
> 
> running the supplied test on JDK 8u40 and 9dev on native Mac OS 10.9.5 and VirtualBox Windows 7 Pro VM for the ?BLOCK? values 1000 and 1500, as specified in the description. For a given BLOCK value the results were the same across all four corresponding test runs. Across all eight runs, the value of toBigInteger() was the same in all cases, contrary to the issue description. For a given BLOCK size, the value of the fractional part was the same across all four corresponding runs. The fractional part differed however between the two different BLOCK sizes, which is to be expected as the precisions of the calculations differ. The pertinent portions of the output of all tests runs are attached to the issue.
> 
> This could be resolved as either ?Cannot Reproduce,? or as ?Incomplete? with a comment requesting further corroboration from the external reporter of the issue.
> 
> Does anyone have a recommendation on this latter point or any other comments?
> 
> Thanks,
> 
> Brian



From Roger.Riggs at Oracle.com  Mon Mar 23 13:33:32 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 23 Mar 2015 09:33:32 -0400
Subject: RFR 9: 8067796: (process) Process.waitFor(timeout, unit) doesn't
	throw NPE if timeout is less than, or equal to zero when unit == null
In-Reply-To: <CA+kOe0_PKxN180n5OdKu74nhHo7At2MfKi_7+nbEMRoHiNHuTA@mail.gmail.com>
References: <550C95C9.20900@Oracle.com>
	<CA+kOe0_PKxN180n5OdKu74nhHo7At2MfKi_7+nbEMRoHiNHuTA@mail.gmail.com>
Message-ID: <5510162C.2070501@Oracle.com>

Hi Martin,

Thanks, I'll move the line up to be consistent with the local style.

Roger


On 3/20/2015 6:23 PM, Martin Buchholz wrote:
> I probably implemented it the way it is intentionally.  I would leave it.
>
> Pedantic changes such as this one won't make any users happy, but 
> we're doing this elsewhere like in java.util.concurrent so I guess 
> it's OK.
>
> But there's a much simpler way to implement it.
>
> Just move
>
> long remainingNanos = unit.toNanos(timeout);
> to the beginning of the method body, as we do in java.util.concurrent.
>
> On Fri, Mar 20, 2015 at 2:48 PM, Roger Riggs <Roger.Riggs at oracle.com 
> <mailto:Roger.Riggs at oracle.com>> wrote:
>
>     Please review this change to Process.waitFor(timeout, TimeUnit)
>     to check for TimeUnit == null before checking for exited = true
>     and timeout <= 0.
>     The current implementation does not throw NPE if the timeout is <=
>     0 or the Process has already
>     exited.  The check for the validity of the arguments should come
>     before the other conditions.
>     This cleanup of the implementation was requested by the JCK team.
>
>     Webrev:
>          ://cr.openjdk.java.net/~rriggs/webrev-npe-8067796/
>     <http://cr.openjdk.java.net/%7Erriggs/webrev-npe-8067796/>
>     Issue:
>        8067796: (process) Process.waitFor(timeout, unit) doesn't throw
>     NPE if timeout is less than, or equal to zero when unit == null
>
>     Thanks, Roger
>
>     [1] https://bugs.openjdk.java.net/browse/JDK-8067796
>
>
>



From chris.hegarty at oracle.com  Mon Mar 23 15:45:33 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 23 Mar 2015 15:45:33 +0000
Subject: RFR [9] 8071472: Add field setter API for setting final fields in
	readObject
Message-ID: <5510351D.1070500@oracle.com>

Here is an updated version of the FieldSetter API, with all comments to 
date incorporated.

 
http://cr.openjdk.java.net/~chegar/8071472/02/specdiff/overview-summary.html

Final spec comments welcome, after which I intend to submit a CCC request.

-Chris.


From aph at redhat.com  Mon Mar 23 18:31:38 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 23 Mar 2015 18:31:38 +0000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <550D9D02.1020303@oracle.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>	<550A90CE.9080901@redhat.com>
	<550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com>
	<550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com>
	<550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com>
	<550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com>
Message-ID: <55105C0A.8070305@redhat.com>

On 03/21/2015 04:32 PM, Vladimir Kozlov wrote:
> On 3/21/15 4:36 AM, Andrew Haley wrote:
>> On 20/03/15 22:00, Vladimir Kozlov wrote:
>>> On 3/20/15 9:08 AM, Andrew Haley wrote:
>>>> Webrev at
>>>>
>>>> http://cr.openjdk.java.net/~aph/unaligned.hotspot.7/
>>>
>>> I don't see changes to VM's makefiles to set VM_BIG_ENDIAN. Or consider
>>> it is set if VM_LITTLE_ENDIAN is not set in prims/unsafe.cpp code.
>>
>> Darn, I already made that change once but missed it in this webrev.  Sorry.
> 
> I will wait new webrev.
> 
>>
>>> In globals.hpp the empty line after flag description should not have '\'
>>> at the end.
>>
>> OK.
>>
>>> Otherwise it looks good.
>>>
>>>> http://cr.openjdk.java.net/~aph/unaligned.jdk.7/
>>>
>>> My only comment for jdk change is to use bigEndian name instead of BE in
>>> Unsafe.java. Someone from core libs should look on this.
>>
>> I would have used that, but I followed John Rose's suggestion.  I
>> don't mind making changes but having to change it back-and-forth
>> really is too much.
> 
> John have more authority than me :) so be it BE.

Ok.  Sorry for being impatient.

http://cr.openjdk.java.net/~aph/unaligned.hotspot.8/
http://cr.openjdk.java.net/~aph/unaligned.jdk.7/

Andrew.




From brent.christian at oracle.com  Mon Mar 23 19:23:37 2015
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 23 Mar 2015 12:23:37 -0700
Subject: RFR 8071667 : HashMap.computeIfAbsent() adds entry that
	HashMap.get() does not find.
In-Reply-To: <3DEEDED0-74F1-4B54-9A8A-6A36B1AB1B59@oracle.com>
References: <5509BA01.6000709@oracle.com>	<684AF3A3-4280-47B3-AA8D-64248C5DDA9A@oracle.com>	<550B4E4D.5010500@oracle.com>	<AC534548-0FE0-4763-B535-2E1B8888EF66@oracle.com>	<550C8FCD.7070304@oracle.com>
	<3DEEDED0-74F1-4B54-9A8A-6A36B1AB1B59@oracle.com>
Message-ID: <55106839.5000005@oracle.com>

On 3/21/15 6:43 AM, Paul Sandoz wrote:
> On Mar 20, 2015, at 10:23 PM, Brent Christian <brent.christian at oracle.com> wrote:
>> Here's the latest:
>>
>> http://cr.openjdk.java.net/~bchristi/8071667/webrev.4/
>>
>> That should have everything.
>
> Looks good (i assumed all but the test code has remained unchanged).

Code-wise, yes.  Doc-wise, it does include the suggested "function" -> 
"(re)mapping function" wording change.

 > Can you avoid using raw types?
> ...
>
>   125     private static void checkCME(Consumer code, boolean expectCME) {

The argument accepted by Consumer is superfluous; changed to Runnable.

>   136     private static BiFunction<String,String,String> mkBiFunc(Map map) {

Map -> Map<String,String>

Webrev updated in place.

Thanks,
-Brent



From martinrb at google.com  Mon Mar 23 20:18:01 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 23 Mar 2015 13:18:01 -0700
Subject: RFR: JDK-8073158 zip files with total entry count 0xFFFF need not be
	ZIP64 files
Message-ID: <CA+kOe0_4rGNW_9u7XdgWb=5Ox685ecC+K++b9Lh6SSpqbse=TQ@mail.gmail.com>

Hi Xueming and Alan,

I'd like you to do a code review.

https://bugs.openjdk.java.net/browse/JDK-8073158
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/0xffff-entries-zip-file/

Of course, the really correct thing is to have at most one zip
implementation per programming language, but I'm not trying to fix that
here (how many zip implementations does openjdk have?)


From martinrb at google.com  Mon Mar 23 20:24:39 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 23 Mar 2015 13:24:39 -0700
Subject: RFR: JDK-8074578 Document memory visibility effects of some
	Unsafe methods
In-Reply-To: <2608270C-BDD6-4E8F-8D1F-5E6FB0F42BFC@oracle.com>
References: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>
	<54FCEA87.3030509@oracle.com> <54FD6767.8020506@redhat.com>
	<54FD8059.9050205@oracle.com>
	<CA+kOe0-NSsfYwDE6xzquWAe9OVhx389tX27vo5_DUpUSdTEpeQ@mail.gmail.com>
	<54FE4943.1030008@oracle.com> <54FE9DDA.8030301@redhat.com>
	<CA+kOe08JzETEdOR0twbRc5h3RfkZL007iaBEagZYniaR3GVXbA@mail.gmail.com>
	<2608270C-BDD6-4E8F-8D1F-5E6FB0F42BFC@oracle.com>
Message-ID: <CA+kOe08dR8K2f9Ee2+v=DrG4zmpOjWS=_hRD6rW1JKPqLr0iwA@mail.gmail.com>

On Wed, Mar 11, 2015 at 2:12 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> I am all for clearing up the language here, but think it prudent to hold
> off doing much until the language for JMM revisions and VarHandle is
> produced, then we can revisit.
>

I'm disappointed we can't add such a small and safe doc fix now.

I agree the public docs for replacements for Unsafe methods will be much
harder (and more important) to get right.  Especially if they include
wording and API that help those familiar with C/C++11 atomics, as I would
like.


From xueming.shen at oracle.com  Mon Mar 23 20:26:56 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 23 Mar 2015 13:26:56 -0700
Subject: A PEM base64 decoder?
In-Reply-To: <D852AAAD-9A42-49EE-8AC4-472C71D06666@oracle.com>
References: <550FCFCE.2060904@redhat.com>
	<D852AAAD-9A42-49EE-8AC4-472C71D06666@oracle.com>
Message-ID: <55107710.4060201@oracle.com>

On 03/23/2015 02:47 AM, Wang Weijun wrote:
>
>> Begin forwarded message:
>>
>> Date: March 23, 2015 at 16:33:18 GMT+8
>> From: Florian Weimer<fweimer at redhat.com>
>> To: Wang Weijun<weijun.wang at oracle.com>, OpenJDK Dev list<security-dev at openjdk.java.net>
>> Subject: Re: RFR 8074935: jdk8 keytool doesn't validate pem files for RFC 1421 correctness, as jdk7 did
>>
>> On 03/17/2015 11:02 AM, Wang Weijun wrote:
>>> Hi All
>>>
>>> Please review the code change at
>>>
>>>    http://cr.openjdk.java.net/~weijun/8074935/webrev.00/
>>>
>>> In jdk8, we use Base64.getMimeDecoder() to parse PEM-encoded certs and it ignores every character not in the base-64 alphabet. PEM is more restricted and as I know openssl rejects PEM with illegal chars (Ex, "!" as in bug report and test). This fix will also reject them.
>> Shouldn't you add a Base64.getPemDecoder() with these semantics?  I
>> think this decoder would be useful in other contexts as well.
> Sherman, is that possible?
>

While it is possible personally I will be a little hesitated to add the support for a
"deprecated" rfc into the "new" Base64 class. Any evidence that PEM is still
heavily used in other contexts?

-Sherman


From brian.burkhalter at oracle.com  Mon Mar 23 20:38:04 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 23 Mar 2015 13:38:04 -0700
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE
In-Reply-To: <98E4E492-9EC3-4F9B-BCCF-4AEC6A668F43@oracle.com>
References: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>
	<CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>
	<98E4E492-9EC3-4F9B-BCCF-4AEC6A668F43@oracle.com>
Message-ID: <CD34633A-1B4E-4840-8A1C-53B3DC9D9D78@oracle.com>

Moving this thread to nio-dev where I should posted it in the first place.

Here?s an updated patch which I hope addresses the concerns:

http://cr.openjdk.java.net/~bpb/8065556/webrev.01/

It?s probably a bit of overkill in a couple of places.

One addition change might be to put the check at lines 203-205 of Buffer.java into a private method.

Thanks,

Brian

On Mar 20, 2015, at 10:09 PM, John Rose <john.r.rose at oracle.com> wrote:

> Yes, that's still a good idea, until we fix JDK-6316156.  Thanks, Martin.  ? John
> 
> On Mar 20, 2015, at 6:36 PM, Martin Buchholz <martinrb at google.com> wrote:
>> 
>> The message construction code takes many bytecodes, and best practice a few
>> years ago was to segregate cold code like this into a separate method, and
>> that's probably still true.  Follow the practice of other classes and define
>> 
>> private String outOfBoundsMsg(int position)
>> 
>> On Fri, Mar 20, 2015 at 3:52 PM, Brian Burkhalter <
>> brian.burkhalter at oracle.com> wrote:
>> 
>>> Please review at your convenience.
>>> 
>>> Issue:  https://bugs.openjdk.java.net/browse/JDK-8065556
>>> Patch:  http://cr.openjdk.java.net/~bpb/8065556/webrev.00/
>>> 
>>> My doubts concern the changes to the test portion, viz.:
>>> 
>>> 1) Is the style sufficiently consistent?
>>> 2) I have not added a ?@bug? tag like we normally would because all the
>>> affected test files are generated from a template which contains no such
>>> tag. (Should one perhaps be added to Basic.java with no other changes to
>>> that file?).
>>> 
>>> Thanks,
>>> 
>>> Brian
> 



From vladimir.kozlov at oracle.com  Mon Mar 23 21:10:08 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 23 Mar 2015 14:10:08 -0700
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <55105C0A.8070305@redhat.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>	<550A90CE.9080901@redhat.com>
	<550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com>
	<550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com>
	<550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com>
	<550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com>
	<55105C0A.8070305@redhat.com>
Message-ID: <55108130.2010207@oracle.com>

Hotspot make files changes?

Otherwise looks fine.

Vladimir

On 3/23/15 11:31 AM, Andrew Haley wrote:
> On 03/21/2015 04:32 PM, Vladimir Kozlov wrote:
>> On 3/21/15 4:36 AM, Andrew Haley wrote:
>>> On 20/03/15 22:00, Vladimir Kozlov wrote:
>>>> On 3/20/15 9:08 AM, Andrew Haley wrote:
>>>>> Webrev at
>>>>>
>>>>> http://cr.openjdk.java.net/~aph/unaligned.hotspot.7/
>>>>
>>>> I don't see changes to VM's makefiles to set VM_BIG_ENDIAN. Or consider
>>>> it is set if VM_LITTLE_ENDIAN is not set in prims/unsafe.cpp code.
>>>
>>> Darn, I already made that change once but missed it in this webrev.  Sorry.
>>
>> I will wait new webrev.
>>
>>>
>>>> In globals.hpp the empty line after flag description should not have '\'
>>>> at the end.
>>>
>>> OK.
>>>
>>>> Otherwise it looks good.
>>>>
>>>>> http://cr.openjdk.java.net/~aph/unaligned.jdk.7/
>>>>
>>>> My only comment for jdk change is to use bigEndian name instead of BE in
>>>> Unsafe.java. Someone from core libs should look on this.
>>>
>>> I would have used that, but I followed John Rose's suggestion.  I
>>> don't mind making changes but having to change it back-and-forth
>>> really is too much.
>>
>> John have more authority than me :) so be it BE.
>
> Ok.  Sorry for being impatient.
>
> http://cr.openjdk.java.net/~aph/unaligned.hotspot.8/
> http://cr.openjdk.java.net/~aph/unaligned.jdk.7/
>
> Andrew.
>
>


From mark.sheppard at oracle.com  Mon Mar 23 21:25:55 2015
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Mon, 23 Mar 2015 21:25:55 +0000
Subject: RFR: JDK-8068721 - RMI-IIOP communication fails when ConcurrentHashMap
	is passed to remote method
Message-ID: <551084E3.6050702@oracle.com>

Hi
  please oblige and review the following fix

http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev/
http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev/


which addresses the issue in
https://bugs.openjdk.java.net/browse/JDK-8068721

This relates to RMI-IIOP and the interplay between custom marshalling of 
ValueTypes and
the corresponding serialization of a Java class, in this case 
ConcurrentHashMap.

ConcurrentHashMap changed its structure in jdk8 from that used in jdk7.
This resulted in modification to the readObject and writeObject methods,
and in particular, former serial fields were removed, resulting in
writeObject using PutField and readObject using defaultReadObject.
The writeObject invokes the putFields method of an ObjectOutputStream 
multiple times, and assumes
that it will receive the same PutField object instance for each 
invocation. The spec
doesn't endorse this behaviour - but that's what the implementation of 
ObjectOutputStream
provides. However in the case of RMI-IIOP, the OutputStreamHook, a 
subclass of ObjectOutputStream, returns a new instance for each
putFields invocation. Thus, the ConcurrentHashMap writeObject results in 
improper serialization in the context
of RMI-IIOP.
In the unmarshalling flow of ConcurrentHashMap, the readObject now uses 
defaultReadObject rather than GetField
In this call flow the IIOPInputStream attempts to ignore any primitive 
field, in the serialized data, that doesn't
correspond with a reflective field of the object. However, it leaves the 
primitive in the stream.
Thus, in the case of ConcurrentHashMap, which has serialized two 
integers and
an array of Segments (subclass of ReentrantLock), this results in erroneous
deserialization, with a misinterpretation of a value tag in the stream 
as an array length
and an attempt to allocate a very large array ensues, with an exception 
being thrown.

The OutputStreamHook now returns the same instance of PutField allocated 
for each separate call of putFields method.
This highlights a need to tighten up and disambiguate the 
OutputObjectStream spec for putFields.

IIOPInputStream now removes the primitive values from the stream.

regards
Mark


From martinrb at google.com  Mon Mar 23 22:12:00 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 23 Mar 2015 15:12:00 -0700
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE
In-Reply-To: <CD34633A-1B4E-4840-8A1C-53B3DC9D9D78@oracle.com>
References: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>
	<CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>
	<98E4E492-9EC3-4F9B-BCCF-4AEC6A668F43@oracle.com>
	<CD34633A-1B4E-4840-8A1C-53B3DC9D9D78@oracle.com>
Message-ID: <CA+kOe08_2PZuxV2SYa6W2QvsAtf2DVVQGZzrwaW8ix2K4_zOFg@mail.gmail.com>

Previous maintainers were nervous about improving the error messages
because of the risk of performance loss in these performance critical
methods.

Notice that the below method contains both cold code and hot code - you
want to segregate them as I suggested in my previous message.

Because this is a critical low-level core library:
I would not have a checkPositionBounds method at all and save a branch by
using | instead of || and optimize for the current hotspot implementation:

if ((newPosition > limit) | (newPosition < 0))
  throw new IllegalArgumentException(positionOutOfBoundsMsg(newPosition));

Also, if we're going to this much trouble to craft a high quality error
message, we can figure out the "or" for the user.

 249      * Verify that {@code 0 < newPosition <= limit} 250      *
251      * @param newPosition 252      *        The new position value
253      * 254      * @throws IllegalArgumentException 255      *
   If the specified position is out of bounds. 256      */ 257
private void checkPositionBounds(int newPosition) { 258         if
((newPosition > limit) || (newPosition < 0)) { 259             throw
new IllegalArgumentException("newPosition > limit: (" 260
   + newPosition + " > " + limit + ")" 261                 + " or
newPosition < 0: (" + newPosition + " < 0)"); 262         } 263     }


From martinrb at google.com  Mon Mar 23 22:15:27 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 23 Mar 2015 15:15:27 -0700
Subject: RFR: JDK-8068721 - RMI-IIOP communication fails when
	ConcurrentHashMap is passed to remote method
In-Reply-To: <551084E3.6050702@oracle.com>
References: <551084E3.6050702@oracle.com>
Message-ID: <CA+kOe09S6o8xx8MufAHpO2e_NbhqgHHvP+Jbuwy41Y4yLqOoCw@mail.gmail.com>

Let us know if the serialization code of the collection classes can be
improved.

On Mon, Mar 23, 2015 at 2:25 PM, Mark Sheppard <mark.sheppard at oracle.com>
wrote:

> Hi
>  please oblige and review the following fix
>
> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev/
> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev/
>
>
> which addresses the issue in
> https://bugs.openjdk.java.net/browse/JDK-8068721
>
> This relates to RMI-IIOP and the interplay between custom marshalling of
> ValueTypes and
> the corresponding serialization of a Java class, in this case
> ConcurrentHashMap.
>
> ConcurrentHashMap changed its structure in jdk8 from that used in jdk7.
> This resulted in modification to the readObject and writeObject methods,
> and in particular, former serial fields were removed, resulting in
> writeObject using PutField and readObject using defaultReadObject.
> The writeObject invokes the putFields method of an ObjectOutputStream
> multiple times, and assumes
> that it will receive the same PutField object instance for each
> invocation. The spec
> doesn't endorse this behaviour - but that's what the implementation of
> ObjectOutputStream
> provides. However in the case of RMI-IIOP, the OutputStreamHook, a
> subclass of ObjectOutputStream, returns a new instance for each
> putFields invocation. Thus, the ConcurrentHashMap writeObject results in
> improper serialization in the context
> of RMI-IIOP.
> In the unmarshalling flow of ConcurrentHashMap, the readObject now uses
> defaultReadObject rather than GetField
> In this call flow the IIOPInputStream attempts to ignore any primitive
> field, in the serialized data, that doesn't
> correspond with a reflective field of the object. However, it leaves the
> primitive in the stream.
> Thus, in the case of ConcurrentHashMap, which has serialized two integers
> and
> an array of Segments (subclass of ReentrantLock), this results in erroneous
> deserialization, with a misinterpretation of a value tag in the stream as
> an array length
> and an attempt to allocate a very large array ensues, with an exception
> being thrown.
>
> The OutputStreamHook now returns the same instance of PutField allocated
> for each separate call of putFields method.
> This highlights a need to tighten up and disambiguate the
> OutputObjectStream spec for putFields.
>
> IIOPInputStream now removes the primitive values from the stream.
>
> regards
> Mark
>


From john.r.rose at oracle.com  Mon Mar 23 22:41:27 2015
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 23 Mar 2015 15:41:27 -0700
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE
In-Reply-To: <CA+kOe08_2PZuxV2SYa6W2QvsAtf2DVVQGZzrwaW8ix2K4_zOFg@mail.gmail.com>
References: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>
	<CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>
	<98E4E492-9EC3-4F9B-BCCF-4AEC6A668F43@oracle.com>
	<CD34633A-1B4E-4840-8A1C-53B3DC9D9D78@oracle.com>
	<CA+kOe08_2PZuxV2SYa6W2QvsAtf2DVVQGZzrwaW8ix2K4_zOFg@mail.gmail.com>
Message-ID: <16BDF5A7-C246-45F5-8B47-452AC556B627@oracle.com>

On Mar 23, 2015, at 3:12 PM, Martin Buchholz <martinrb at google.com> wrote:
> 
> Because this is a critical low-level core library:
> I would not have a checkPositionBounds method at all and save a branch by using | instead of || and optimize for the current hotspot implementation:
> 
> if ((newPosition > limit) | (newPosition < 0)) 
>   throw new IllegalArgumentException(positionOutOfBoundsMsg(newPosition));

I will confirm that it's best, at present, to separate hot code from cold code.

Eventually I think we'll have good enough library functions for range checks that we can avoid working with explicit range check expressions.  Even experts get them wrong when subexpressions can overflow (for subsequence range checks).

For now, I would add one more tweak to Martin's:

> if ((newPosition > limit) | (newPosition < 0)) 
>   throw positionOutOfBoundsException(newPosition);

The instance creation expression and the string formatting are both cold code which deserves to be segregated into a factory method.

The throw itself is convenient to put into the caller code, though, because (a) it doesn't increase caller bytecode complexity, and (b) it doesn't confuse javac or the code maintainer with a nonexistent fall-through of control after the error.

? John

From martinrb at google.com  Mon Mar 23 23:20:21 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 23 Mar 2015 16:20:21 -0700
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE
In-Reply-To: <16BDF5A7-C246-45F5-8B47-452AC556B627@oracle.com>
References: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>
	<CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>
	<98E4E492-9EC3-4F9B-BCCF-4AEC6A668F43@oracle.com>
	<CD34633A-1B4E-4840-8A1C-53B3DC9D9D78@oracle.com>
	<CA+kOe08_2PZuxV2SYa6W2QvsAtf2DVVQGZzrwaW8ix2K4_zOFg@mail.gmail.com>
	<16BDF5A7-C246-45F5-8B47-452AC556B627@oracle.com>
Message-ID: <CA+kOe0_V5syOwL7zmja+HdX-bMOiPFEScJKCf1MO2_ivR4CfEw@mail.gmail.com>

On Mon, Mar 23, 2015 at 3:41 PM, John Rose <john.r.rose at oracle.com> wrote:

>
> Eventually I think we'll have good enough library functions for range
> checks that we can avoid working with explicit range check expressions.
> Even experts get them wrong when subexpressions can overflow (for
> subsequence range checks).
>

Guava has Precondtions:
https://code.google.com/p/guava-libraries/wiki/PreconditionsExplained


> For now, I would add one more tweak to Martin's:
>
> > if ((newPosition > limit) | (newPosition < 0))
> >   throw positionOutOfBoundsException(newPosition);
>
> The instance creation expression and the string formatting are both cold
> code which deserves to be segregated into a factory method.
>
> The throw itself is convenient to put into the caller code, though,
> because (a) it doesn't increase caller bytecode complexity, and (b) it
> doesn't confuse javac or the code maintainer with a nonexistent
> fall-through of control after the error.
>

Many years ago I experimented with different variations.
I see that this bug is still waiting for its day:

JDK-6533165 <https://bugs.openjdk.java.net/browse/JDK-6533165> Failure to
optimize methods that unconditionally throw


From john.r.rose at oracle.com  Mon Mar 23 23:27:11 2015
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 23 Mar 2015 16:27:11 -0700
Subject: RFR: JDK-8074578 Document memory visibility effects of some
	Unsafe methods
In-Reply-To: <CA+kOe08dR8K2f9Ee2+v=DrG4zmpOjWS=_hRD6rW1JKPqLr0iwA@mail.gmail.com>
References: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>
	<54FCEA87.3030509@oracle.com> <54FD6767.8020506@redhat.com>
	<54FD8059.9050205@oracle.com>
	<CA+kOe0-NSsfYwDE6xzquWAe9OVhx389tX27vo5_DUpUSdTEpeQ@mail.gmail.com>
	<54FE4943.1030008@oracle.com> <54FE9DDA.8030301@redhat.com>
	<CA+kOe08JzETEdOR0twbRc5h3RfkZL007iaBEagZYniaR3GVXbA@mail.gmail.com>
	<2608270C-BDD6-4E8F-8D1F-5E6FB0F42BFC@oracle.com>
	<CA+kOe08dR8K2f9Ee2+v=DrG4zmpOjWS=_hRD6rW1JKPqLr0iwA@mail.gmail.com>
Message-ID: <00CDE96F-D1B3-4E5D-B254-6ED0F0A90D6B@oracle.com>

On Mar 23, 2015, at 1:24 PM, Martin Buchholz <martinrb at google.com> wrote:
> 
> On Wed, Mar 11, 2015 at 2:12 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
>> 
>> I am all for clearing up the language here, but think it prudent to hold
>> off doing much until the language for JMM revisions and VarHandle is
>> produced, then we can revisit.
>> 
> 
> I'm disappointed we can't add such a small and safe doc fix now.
> 
> I agree the public docs for replacements for Unsafe methods will be much
> harder (and more important) to get right.  Especially if they include
> wording and API that help those familiar with C/C++11 atomics, as I would
> like.

I have read this thread with interest.

If I understand it correctly, Martin is proposing that we document a semantics for Unsafe CAS that is weak enough to make it convenient to implement on many platforms, but is just strong enough to implement the (known) uses.

David is objecting that since Unsafe is just some native entry points to HotSpot internals (Atomic::cmpxchg), it should promise nothing other than the current behavior (operational semantics).  This behavior might sometimes be overly strong for known use cases, but it is what it is.

So there are standard APIs on the top and the JVM atomics at the bottom, and Unsafe in the middle, being pulled both ways.

Here's my view:  Unsafe exists to provide a reasonably understandable and platform-independent API that JDK libraries can code to.  It is not a "fully public" API in the sense of a JDK specification because although it is portable it cannot be be used securely by untrusted parties.  Of course, it is "public" in the sense of being well-known and widely-used, if not always wisely-used.

Meanwhile, Paul Sandoz is working to refactor these aspects, creating a large chunk of API that will be public, portable, and secure.  You've got to sympathize with him for not wanting to run through all the inevitable arguments about concurrency primitives once for Unsafe and once again later for VarHandles.

My position is this:  Since Unsafe is intended to be portable (though ?unsafe) Martin's proposal makes sense.  It is good to firm up the semantics of Unsafe to some portable standard, as long as it doesn't box us into a corner.  Eventually, we may wish (for performance reasons) to weaken some of its guarantees by adjusting its coupling to Atomic::* in HotSpot.

I support the cross-references to C11 semantics, as long as they are descriptive of conditions which are natural to the JMM.  If they are not, we need additional conversations about whether the JMM needs tweaking.  It is of course natural for Unsafe to make references to volatile variable semantics, since they are central to the JMM as it stands today.  And there may be some "wiggle room" matching volatiles to C11, if the fine print of the JMM allows volatiles to be implemented inconsistently from C11 memory_order_seq_cst.  In the end, if we refactor the way we do volatiles, I would expect juc.Atomic* and Unsafe to change at the same time, and it would not be harmful for Martin's javadoc to be in the mix, since we could make new Unsafe API points to reflect an enhanced understanding of what the JVM should do.

So, I think the present proposal makes sense, unless someone can point out some reason what we do (now or in the near future) is inconsistent with C11 atomic_compare_exchange_strong.

And, I applaud Martin's long-running work to firm up the semantics of the mid-layer that Unsafe occupies.

Thanks!
? John

From martinrb at google.com  Mon Mar 23 23:44:39 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 23 Mar 2015 16:44:39 -0700
Subject: RFR: JDK-8075774 Small readability and performance improvements for
	zipfs
Message-ID: <CA+kOe09-5y6rP_b75JVzfY5SYckdsxMJ+g60-RC2QDQFCAqPrQ@mail.gmail.com>

https://bugs.openjdk.java.net/browse/JDK-8075774
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/PKsig-java/


From xueming.shen at oracle.com  Mon Mar 23 23:51:15 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 23 Mar 2015 16:51:15 -0700
Subject: RFR: JDK-8075774 Small readability and performance improvements
	for zipfs
In-Reply-To: <CA+kOe09-5y6rP_b75JVzfY5SYckdsxMJ+g60-RC2QDQFCAqPrQ@mail.gmail.com>
References: <CA+kOe09-5y6rP_b75JVzfY5SYckdsxMJ+g60-RC2QDQFCAqPrQ@mail.gmail.com>
Message-ID: <5510A6F3.3040707@oracle.com>

On 03/23/2015 04:44 PM, Martin Buchholz wrote:
> https://bugs.openjdk.java.net/browse/JDK-8075774
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/PKsig-java/ <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/PKsig-java/>
looks fine.


From martinrb at google.com  Tue Mar 24 00:27:25 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 23 Mar 2015 17:27:25 -0700
Subject: String.indexOf optimization
In-Reply-To: <CA+_Mpj_gcXBJ6RXwKz2bfhjqk+ycYiUK7Fb3kESaasxhXCJaPA@mail.gmail.com>
References: <CA+_Mpj-Gm+iKj_qGaxhAHEoN0caFFe2i5XocS13zGzCPhUCmxg@mail.gmail.com>
	<CA+kOe0-mvmU2dXZOmQe_bWnj8C5+uvyJixDM7hQ=mhBAyZ0new@mail.gmail.com>
	<534D68B8.3040002@oracle.com>
	<CA+kOe08M+z32rYeOv6_RU_E41OBa7sYU1vOkDoohOs-d+uLw+Q@mail.gmail.com>
	<5350E316.2050406@oracle.com>
	<CA+kOe0__O3n-s4+fen01sCRWMsp=zJaOR_4VZAFtosqv1GDFLQ@mail.gmail.com>
	<CA+_Mpj_6TtmUKcXL3U_Cdqo+Ggr8Vspd8t7HZvXOD2oyfiHn4Q@mail.gmail.com>
	<54ABAAC2.2090502@redhat.com>
	<CA+_Mpj8+QRuV0fzVWwd6pOp_kVdmPTtYE6Jx87J+Lt-hyNYKBA@mail.gmail.com>
	<CAHjP37G1AtFNWBMZN4WrBDAt98Lh4fou5jWdRD7=qnB=gX7X3g@mail.gmail.com>
	<CA+_Mpj_Gh9yKM9HRG_KmddehUPq0=XOdihxPoz4Ce7FCbiLkbw@mail.gmail.com>
	<CA+kOe0-zMAwqOy0bK_3zmf6CHKET1+se0vTW7iQEsrVQ-xMs9g@mail.gmail.com>
	<CA+_Mpj9j7SvUici7zQqdR2j5GMFV8HY9QY9erQ0Q+87vnYr-cw@mail.gmail.com>
	<CA+kOe0_RuTJyuSjUgoFrUwm15-iB9chi3DPxYRMi=_Bz6at7QQ@mail.gmail.com>
	<CAHjP37H_-AhtLGvyaeeohZLDb40-rbb1qqnCx7UBTrXkJ0Ma9g@mail.gmail.com>
	<CA+kOe09jN_8spPwo0h9ZF8J3aGzW9A9Kji68BHsfamQwydBvVA@mail.gmail.com>
	<CA+_Mpj_gcXBJ6RXwKz2bfhjqk+ycYiUK7Fb3kESaasxhXCJaPA@mail.gmail.com>
Message-ID: <CA+kOe09x-2+HfNEr0En+LB8ziMxEAHgd930Y3ktDvc=VUEsNxw@mail.gmail.com>

On Mon, Jan 26, 2015 at 10:50 PM, Zoltan Sziladi <kissziszi at gmail.com>
wrote:

>
> By the way, can you tell me why you used named loops in your code? Isn't
> it considered bad practice as it is almost like a goto statement? Couldn't
> we refactor it in a way that we do not use named loops?
>

Here in core-libs-land, we like to do goto-oriented programming!


From weijun.wang at oracle.com  Tue Mar 24 01:19:42 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Tue, 24 Mar 2015 09:19:42 +0800
Subject: A PEM base64 decoder?
In-Reply-To: <55107710.4060201@oracle.com>
References: <550FCFCE.2060904@redhat.com>
	<D852AAAD-9A42-49EE-8AC4-472C71D06666@oracle.com>
	<55107710.4060201@oracle.com>
Message-ID: <D940C570-F754-4B1D-B97C-28A334728A07@oracle.com>

>>>> 
>>>> In jdk8, we use Base64.getMimeDecoder() to parse PEM-encoded certs and it ignores every character not in the base-64 alphabet. PEM is more restricted and as I know openssl rejects PEM with illegal chars (Ex, "!" as in bug report and test). This fix will also reject them.
>>> Shouldn't you add a Base64.getPemDecoder() with these semantics?  I
>>> think this decoder would be useful in other contexts as well.
>> Sherman, is that possible?
>> 
> 
> While it is possible personally I will be a little hesitated to add the support for a
> "deprecated" rfc into the "new" Base64 class. Any evidence that PEM is still
> heavily used in other contexts?

Not sure about usage outside the security area, it's heavily used for encoding of certificates, CRLs, private keys, etc.

I did some experiments, creating a PEM certificate including garbage characters, only Firefox accepts it, and it's rejected by IE, openssl, Mac.

--Max

> 
> -Sherman



From stuart.marks at oracle.com  Tue Mar 24 01:41:54 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 23 Mar 2015 18:41:54 -0700
Subject: RFR 8075307 Pipeline calculating inconsistent flag state for
	parallel stateful ops
In-Reply-To: <9BFBFA94-A170-420A-814C-C66262F3E157@oracle.com>
References: <9BFBFA94-A170-420A-814C-C66262F3E157@oracle.com>
Message-ID: <5510C0E2.3010900@oracle.com>

Hi Paul,

After reading your notes here, and in the bug reports, and the comments in the 
code, and banging my head against the code (before and after) for a while, I'm 
starting to see that this is on the right track. Sorry to hedge a bit but I have 
to admit that I don't fully understand the code.

However, I do see the comment you referred to (old version, line 460) and that 
the new code is essentially a merge of the old parallelPrepare() code into 
sourceSpliterator(). And I do see the crucial addition of the flag modification 
based on the spliterator's SIZED characteristic. So that seems right, and if the 
tests pass, so much the better.

A few comments for future maintenance/cleanups in this area.

* This package seems like a curious mixture of abstraction of bit-twiddling into 
small methods (e.g., combineOpFlags), and bit-twiddling in open code (evalation 
of Spliterator.SIZED into thisOpFlags, new version lines 459ff). While not 
incorrect, this is jarring.

* The loop variables over the pipeline stages are hard to follow. The variable 
'p' is used in the loop at line 413 a the "current" pipeline stage, whereas 'p' 
is used for the "next" stage in the loop at 434, and 'u' is the "current" stage. 
This is confusing, and I don't know what 'u' means.

* Also, in the same loop, 'e' is initialized to 'this' and is checked as the 
loop exit condition (I guess that's what 'e' stands for) but it's not used 
elsewhere, so it's not clear to me how much value this adds.

Stepping back from this a bit, this is clearly an area of some complexity, and 
it might benefit from some additional testing. The streams library is overall 
well-tested, but mostly from a functional level, i.e. running a bunch of streams 
in various combinations to ensure the right output is produced. For this case it 
might be helpful to assemble (but not execute) a bunch of combinations of 
pipelines and then make sure that each stage ends up with the right flags. (I 
didn't find such a test when I went looking, but I might have missed it.)

In any case I think it's reasonble to proceed with this patch as it stands 
instead of tinkering with it. Some additional cleanups are warranted at some 
point but we should keep an eye on these for the future.

s'marks

On 3/18/15 7:09 AM, Paul Sandoz wrote:
> Hi,
>
> The fix for https://bugs.openjdk.java.net/browse/JDK-8067969 (optimized Stream.count()) caused a regression in the JCK tests.
>
> A test exposed a known weakness in the way pipeline flags are prepared for parallel execution. In certain cases the pipeline may report SIZED but the source spliterator does not report the SIZE characteristic. This is because the preparation always assumed that stateful operations are a full barrier and thus inject SIZE. This is not always the case when a stateful operation is "lazy" and can wrap the source spliterator and operations.
>
> For example:
>
>    List<Integer> list = Arrays.asList(1, 2, 3);
>    Stream<Integer> s = list.stream().parallel().unordered().distinct();
>    long count = s.count();
>    System.out.println(count);
>
> The stateful distinct op can wrap source spliterator of the list since we don't care about order, but as a result the size of the distinct->count pipeline slice is unknown.
>
> While i could fix the counting functionality to check for the inconsistency the right thing to do is fix the preparation of flags (a particularly sensitive area to get right) by merging that into the sourceSpliterator method (as suggested in the comments):
>
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8075307-stream-parallel-prepare-flags/webrev/
>
> This also makes things marginally more efficient when there are no stateful operations. There is no need to do any work if there are no stateful ops (i needed to relax tests in UnorderedTest which were overly aggressive when there were no stateful ops present, similarly i relaxed a test in DisctinctOps that is no longer generally applicable).
>
> Furthermore, as a consequence the terminal counting reduce ops now declare they don't care about encounter order [*], which avoid the distinct becoming a full barrier that reduces elements to a linked hash set.
>
> A JPRT test run reported no relevant failures and local execution of relevant JCK tests pass.
>
> Paul.
>
> [*] Note that a count can also be performed with:
>
>    LongAdder l = new LongAdder();
>    Stream<T> s = ...
>    s.parallel().forEach(e -> l.increment());
>    long count = l.sum();
>
> Which is a possible alternative implementation to that of reduction, but i prefer to stick with the latter for now.
>


From lev.priima at oracle.com  Tue Mar 24 05:03:35 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Tue, 24 Mar 2015 08:03:35 +0300
Subject: RFR(XS): 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java
	heap space: MaxHeap shrinked by MaxRAMFraction
In-Reply-To: <55096E9C.90509@oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>	<54DD5F6F.4070105@oracle.com>	<54DE0436.5070301@oracle.com>	<54E18636.4000600@oracle.com>	<54E1B170.1000801@oracle.com>	<54E1D28B.7030503@oracle.com>
	<54E28957.1070309@oracle.com>	<54E2D51B.8020808@oracle.com>
	<54E2E5F1.4070702@oracle.com>	<54E5D060.1080409@oracle.com>
	<54E5E3B9.80703@oracle.com>	<54E69B43.4000501@oracle.com>
	<54E704F2.1010201@oracle.com>	<54EA88A9.2080204@oracle.com>
	<54EC54FA.9020503@oracle.com>	<54EEC949.20704@oracle.com>
	<54EEFD16.5090009@oracle.com>	<54EF87C4.5000407@oracle.com>
	<54EF99E6.4030003@oracle.com>	<54EF9FB7.7030400@oracle.com>
	<55073D66.1080204@oracle.com> <5507B03B.5010606@oracle.com>
	<55080CD6.4060108@oracle.com> <55081688.6070308@oracle.com>
	<55081AD6.6010108@oracle.com> <55081CBF.7000107@oracle.com>
	<5508B3AD.7030700@oracle.com> <5508D8E2.7020106@oracle.com>
	<55093380.2000605@oracle.com> <55095902.1040407@oracle.com>
	<55096589.2090104@oracle.com> <55096E9C.90509@oracle.com>
Message-ID: <5510F027.9050303@oracle.com>

Hi David,

Please review and push update: 
http://cr.openjdk.java.net/~lpriima/8075071/2/webrev/ .
NPE in WB happens when vm does not have requested flag. To make test run 
on 32bit vm, where is no UseCompressedOops flag, I've added additional 
null check in UseCompressedOops flag request:

   62             Boolean compessedOops = WhiteBox.getWhiteBox()
   63                 .getBooleanVMFlag("UseCompressedOops");
   64             final String xmsValue = "-Xms" +
   65                 ((compessedOops == null || compessedOops) ? "385" : "770")
   66                 + "m";

And if it's null then we are on 32bit vm, don't have big oops and can 
run test with 385m at least.

Lev

On 03/18/2015 03:25 PM, David Holmes wrote:
> On 18/03/2015 9:46 PM, Lev Priima wrote:
>> On 03/18/2015 01:52 PM, David Holmes wrote:
>>> On 18/03/2015 6:12 PM, Lev Priima wrote:
>>>> On 03/18/2015 04:46 AM, David Holmes wrote:
>>>>> Hi Lev,
>>>>>
>>>>> On 18/03/2015 9:07 AM, Lev Priima wrote:
>>>>>> Possible, by determining of disabled UseCompressedOops option and
>>>>>> forking vm again with required minimum heap value(-Xms).
>>>>>> Please review update:
>>>>>> http://cr.openjdk.java.net/~lpriima/8075071/1/webrev/
>>>>>
>>>>> Yes that is the approach that is needed. But didn't you need to set
>>>>> Xmx not Xms to deal with the MaxRAMFraction problem?
>>>> No. As I wrote before "-Xms" has priority over MaxRAMFraction:
>>>
>>> No what you wrote before was that -Xmx has priority. Your original
>>> patch set -Xmx in addition to the existing -Xms:
>>>
>>> !  * @run main/othervm -Xms385m -Xmx770m TimSortStackSize2 67108864
>> Yes this fix will also work. Both -Xms -Xmx have priority over
>> MaxRAMFraction. MaxRAMFraction can't shrink MaxHeapSize less than either
>> -Xms or -Xmx.
>
> Let me see if I have this straight. With -Xms385M ergonomics will 
> select a maximum heap size, and that size is adequate to run the test 
> without additional flags. However if MaxRAMFraction is specified then 
> that maximum heap size gets reduced and the test then fails on 64-bit 
> when compressed oops are disabled. The original version of the fix set 
> -Xmx770M in addition to -Xms385M and that stops the affect of 
> MaxRAMFraction, and so the test passes (but seemingly using G1 can 
> change that?). Alternatively we can just set -Xms770M, but that won't 
> work for systems with less memory, so the current fix simply selects 
> the -Xms value based on whether or not we're using compressed oops, 
> and launches a new VM using that value.
>
> Okay got it.
>
>> Explicit value of -Xmx770m with program which actually required and
>> allocate less memory(385m) is not a problem on machine with 512m until
>> we don't switch -XX:+UseG1GC.
>> That's why I had have agreed with declining this fix .
>
> I originally said the -Xmx770 would be a problem for a machine with 
> 512MB, but as you note it won't be a problem unless > 512MB is 
> actually needed - in which case there is nothing we can do. So my 
> objection was unfounded - sorry for the confusion on that.
>
>> New fix will work with either -Xms or -Xms in this line:
>> !             final String xmsValue = "-Xms" + (WhiteBox.getWhiteBox()
>>
>> -Xms makes tests more robust if jdk footprint will increase a little.
>> -Xmx will be better if we also want to catch possible jdk footprint
>> regression by this test.
>
> Okay. As long as it works on all platforms with all options. :)
>
> Thanks,
> David
>
>> Lev
>>>
>>> David
>>> -----
>>>
>>>> MaxRAMFraction can't shrink MaxHeapSize less than specified by -Xms:
>>>>
>>>> java -Xms385m -XX:+PrintFlagsFinal
>>>> -XX:MaxRAMFraction=9223372036854775807  -version | grep MaxHeapSize
>>>>      uintx MaxHeapSize                              :=
>>>> 404750336                           {product}
>>>>
>>>> java -Xms770m -XX:+PrintFlagsFinal
>>>> -XX:MaxRAMFraction=9223372036854775807  -version | grep MaxHeapSize
>>>>      uintx MaxHeapSize                              :=
>>>> 807403520                           {product}
>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Lev
>>>>>>
>>>>>> On 03/17/2015 03:23 PM, David Holmes wrote:
>>>>>>> So this is a problem that needs to be resolved. The memory
>>>>>>> requirements of the test are platform dependent but can't be
>>>>>>> satisfied
>>>>>>> on all platforms. Though I am surprised that 770M is needed given
>>>>>>> that
>>>>>>> two incarnations ago we set -Xmx to 385M!
>>>>>>>
>>>>>>> But it is appearing to be impossible to run this test in a way that
>>>>>>> can work on all platforms.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> On 17/03/2015 10:15 PM, Lev Priima wrote:
>>>>>>>> Yes.
>>>>>>>>
>>>>>>>> Lev
>>>>>>>>
>>>>>>>> On 03/17/2015 02:56 PM, David Holmes wrote:
>>>>>>>>> On 17/03/2015 9:15 PM, Lev Priima wrote:
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> Explicit -Xmx does not allow explicit MaxRAMFraction to shrink
>>>>>>>>>> MaxHeapSize down to -Xms(or even less down to default
>>>>>>>>>> InitialHeapSize in
>>>>>>>>>> case if -Xms also wasn't set explicitly). In other words 
>>>>>>>>>> explicit
>>>>>>>>>> -Xmx
>>>>>>>>>> has priority over explicit MaxRAMFraction if both are set and
>>>>>>>>>> contradict
>>>>>>>>>> with each other.
>>>>>>>>>
>>>>>>>>> Okay - that's good to know.
>>>>>>>>>
>>>>>>>>> However the -Xmx770m is a problem - our small devices only have
>>>>>>>>> 512MB
>>>>>>>>> of memory. Is the 770M only needed for 64-bit with
>>>>>>>>> -UseCompressedOops ?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Lev
>>>>>>>>>>
>>>>>>>>>> On 03/17/2015 07:40 AM, David Holmes wrote:
>>>>>>>>>>> Hi Lev,
>>>>>>>>>>>
>>>>>>>>>>> On 17/03/2015 6:30 AM, Lev Priima wrote:
>>>>>>>>>>>> Please reviewand push:
>>>>>>>>>>>>
>>>>>>>>>>>> Issue:https://bugs.openjdk.java.net/browse/JDK-8075071
>>>>>>>>>>>> Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/
>>>>>>>>>>>>
>>>>>>>>>>>> Tested locally:
>>>>>>>>>>>> jtreg -vmoptions:"-XX:MaxRAMFraction=9223372036854775807
>>>>>>>>>>>> -XX:-UseCompressedOops"
>>>>>>>>>>>> test/java/util/Arrays/TimSortStackSize2.java
>>>>>>>>>>>> Test results: passed: 1
>>>>>>>>>>>
>>>>>>>>>>> How does MaxRAMFraction interact with -Xmx?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>> Lev
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>



From amy.lu at oracle.com  Tue Mar 24 05:12:58 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 24 Mar 2015 13:12:58 +0800
Subject: JDK 9 RFR of JDK-8075692: jaxp/test/Makefile references (has been
	removed) win32 directory in jtreg
Message-ID: <5510F25A.4050406@oracle.com>

File structure has changed in the new jtreg distribution (4.1/b11), 
there are no platform specific bin directories any more.
This fix is for updating jaxp/test/Makefile accordingly.

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

I also need a sponsor for this fix.

Thanks,
Amy


From Alan.Bateman at oracle.com  Tue Mar 24 07:34:34 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Mar 2015 07:34:34 +0000
Subject: RFR: JDK-8068721 - RMI-IIOP communication fails when
	ConcurrentHashMap is passed to remote method
In-Reply-To: <551084E3.6050702@oracle.com>
References: <551084E3.6050702@oracle.com>
Message-ID: <5511138A.2090206@oracle.com>

On 23/03/2015 21:25, Mark Sheppard wrote:
> Hi
>  please oblige and review the following fix
>
> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev/
> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev/
>
>
> which addresses the issue in
> https://bugs.openjdk.java.net/browse/JDK-8068721
>
> This relates to RMI-IIOP and the interplay between custom marshalling 
> of ValueTypes and
> the corresponding serialization of a Java class, in this case 
> ConcurrentHashMap.
Looks like this needs a deep dive into the RMI-IIOP spec to properly 
review this. I see Sean Coffey has been looking at it too so hopefully 
he has cycles to help on this.

A few passing comments on the tests:

Should the tie and stub be generated by the test rather than checking in 
the generated code?

The test launches ordb and and an RMI-IIOP server, I wonder if the test 
library infrastructure could be used to do this instead (as we have so 
many issues with multi-VM tests). Also it's using a fixed port which 
might be a problem when running concurrently with other tests (esp. any 
test using a naming service as it will be using 1050 too).

The patch adds RMI-IIOP tests to the jdk_rmi test group. I think to date 
that we've put CORBA and RMI-IIOP tests in jdk_other. I realize this has 
implications for where the tests are placed.

-Alan.


From david.holmes at oracle.com  Tue Mar 24 07:48:21 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Mar 2015 17:48:21 +1000
Subject: RFR(XS): 8075071: [TEST_BUG] TimSortStackSize2.java: OOME: Java
	heap space: MaxHeap shrinked by MaxRAMFraction
In-Reply-To: <5510F027.9050303@oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>	<54DE0436.5070301@oracle.com>	<54E18636.4000600@oracle.com>	<54E1B170.1000801@oracle.com>	<54E1D28B.7030503@oracle.com>
	<54E28957.1070309@oracle.com>	<54E2D51B.8020808@oracle.com>
	<54E2E5F1.4070702@oracle.com>	<54E5D060.1080409@oracle.com>
	<54E5E3B9.80703@oracle.com>	<54E69B43.4000501@oracle.com>
	<54E704F2.1010201@oracle.com>	<54EA88A9.2080204@oracle.com>
	<54EC54FA.9020503@oracle.com>	<54EEC949.20704@oracle.com>
	<54EEFD16.5090009@oracle.com>	<54EF87C4.5000407@oracle.com>
	<54EF99E6.4030003@oracle.com>	<54EF9FB7.7030400@oracle.com>
	<55073D66.1080204@oracle.com> <5507B03B.5010606@oracle.com>
	<55080CD6.4060108@oracle.com> <55081688.6070308@oracle.com>
	<55081AD6.6010108@oracle.com> <55081CBF.7000107@oracle.com>
	<5508B3AD.7030700@oracle.com> <5508D8E2.7020106@oracle.com>
	<55093380.2000605@oracle.com> <55095902.1040407@oracle.com>
	<55096589.2090104@oracle.com> <55096E9C.90509@oracle.com>
	<5510F027.9050303@oracle.com>
Message-ID: <551116C5.5040800@oracle.com>

Hi Lev,

On 24/03/2015 3:03 PM, Lev Priima wrote:
> Hi David,
>
> Please review and push update:
> http://cr.openjdk.java.net/~lpriima/8075071/2/webrev/ .
> NPE in WB happens when vm does not have requested flag. To make test run
> on 32bit vm, where is no UseCompressedOops flag, I've added additional
> null check in UseCompressedOops flag request:
>
>    62             Boolean compessedOops = WhiteBox.getWhiteBox()
>    63                 .getBooleanVMFlag("UseCompressedOops");
>    64             final String xmsValue = "-Xms" +
>    65                 ((compessedOops == null || compessedOops) ? "385" : "770")
>    66                 + "m";
>
> And if it's null then we are on 32bit vm, don't have big oops and can
> run test with 385m at least.

I fixed the typo (compessedOops -> compressedOops), tested and pushed.

Thanks,
David
----


> Lev
>
> On 03/18/2015 03:25 PM, David Holmes wrote:
>> On 18/03/2015 9:46 PM, Lev Priima wrote:
>>> On 03/18/2015 01:52 PM, David Holmes wrote:
>>>> On 18/03/2015 6:12 PM, Lev Priima wrote:
>>>>> On 03/18/2015 04:46 AM, David Holmes wrote:
>>>>>> Hi Lev,
>>>>>>
>>>>>> On 18/03/2015 9:07 AM, Lev Priima wrote:
>>>>>>> Possible, by determining of disabled UseCompressedOops option and
>>>>>>> forking vm again with required minimum heap value(-Xms).
>>>>>>> Please review update:
>>>>>>> http://cr.openjdk.java.net/~lpriima/8075071/1/webrev/
>>>>>>
>>>>>> Yes that is the approach that is needed. But didn't you need to set
>>>>>> Xmx not Xms to deal with the MaxRAMFraction problem?
>>>>> No. As I wrote before "-Xms" has priority over MaxRAMFraction:
>>>>
>>>> No what you wrote before was that -Xmx has priority. Your original
>>>> patch set -Xmx in addition to the existing -Xms:
>>>>
>>>> !  * @run main/othervm -Xms385m -Xmx770m TimSortStackSize2 67108864
>>> Yes this fix will also work. Both -Xms -Xmx have priority over
>>> MaxRAMFraction. MaxRAMFraction can't shrink MaxHeapSize less than either
>>> -Xms or -Xmx.
>>
>> Let me see if I have this straight. With -Xms385M ergonomics will
>> select a maximum heap size, and that size is adequate to run the test
>> without additional flags. However if MaxRAMFraction is specified then
>> that maximum heap size gets reduced and the test then fails on 64-bit
>> when compressed oops are disabled. The original version of the fix set
>> -Xmx770M in addition to -Xms385M and that stops the affect of
>> MaxRAMFraction, and so the test passes (but seemingly using G1 can
>> change that?). Alternatively we can just set -Xms770M, but that won't
>> work for systems with less memory, so the current fix simply selects
>> the -Xms value based on whether or not we're using compressed oops,
>> and launches a new VM using that value.
>>
>> Okay got it.
>>
>>> Explicit value of -Xmx770m with program which actually required and
>>> allocate less memory(385m) is not a problem on machine with 512m until
>>> we don't switch -XX:+UseG1GC.
>>> That's why I had have agreed with declining this fix .
>>
>> I originally said the -Xmx770 would be a problem for a machine with
>> 512MB, but as you note it won't be a problem unless > 512MB is
>> actually needed - in which case there is nothing we can do. So my
>> objection was unfounded - sorry for the confusion on that.
>>
>>> New fix will work with either -Xms or -Xms in this line:
>>> !             final String xmsValue = "-Xms" + (WhiteBox.getWhiteBox()
>>>
>>> -Xms makes tests more robust if jdk footprint will increase a little.
>>> -Xmx will be better if we also want to catch possible jdk footprint
>>> regression by this test.
>>
>> Okay. As long as it works on all platforms with all options. :)
>>
>> Thanks,
>> David
>>
>>> Lev
>>>>
>>>> David
>>>> -----
>>>>
>>>>> MaxRAMFraction can't shrink MaxHeapSize less than specified by -Xms:
>>>>>
>>>>> java -Xms385m -XX:+PrintFlagsFinal
>>>>> -XX:MaxRAMFraction=9223372036854775807  -version | grep MaxHeapSize
>>>>>      uintx MaxHeapSize                              :=
>>>>> 404750336                           {product}
>>>>>
>>>>> java -Xms770m -XX:+PrintFlagsFinal
>>>>> -XX:MaxRAMFraction=9223372036854775807  -version | grep MaxHeapSize
>>>>>      uintx MaxHeapSize                              :=
>>>>> 807403520                           {product}
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Lev
>>>>>>>
>>>>>>> On 03/17/2015 03:23 PM, David Holmes wrote:
>>>>>>>> So this is a problem that needs to be resolved. The memory
>>>>>>>> requirements of the test are platform dependent but can't be
>>>>>>>> satisfied
>>>>>>>> on all platforms. Though I am surprised that 770M is needed given
>>>>>>>> that
>>>>>>>> two incarnations ago we set -Xmx to 385M!
>>>>>>>>
>>>>>>>> But it is appearing to be impossible to run this test in a way that
>>>>>>>> can work on all platforms.
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 17/03/2015 10:15 PM, Lev Priima wrote:
>>>>>>>>> Yes.
>>>>>>>>>
>>>>>>>>> Lev
>>>>>>>>>
>>>>>>>>> On 03/17/2015 02:56 PM, David Holmes wrote:
>>>>>>>>>> On 17/03/2015 9:15 PM, Lev Priima wrote:
>>>>>>>>>>> Hi David,
>>>>>>>>>>>
>>>>>>>>>>> Explicit -Xmx does not allow explicit MaxRAMFraction to shrink
>>>>>>>>>>> MaxHeapSize down to -Xms(or even less down to default
>>>>>>>>>>> InitialHeapSize in
>>>>>>>>>>> case if -Xms also wasn't set explicitly). In other words
>>>>>>>>>>> explicit
>>>>>>>>>>> -Xmx
>>>>>>>>>>> has priority over explicit MaxRAMFraction if both are set and
>>>>>>>>>>> contradict
>>>>>>>>>>> with each other.
>>>>>>>>>>
>>>>>>>>>> Okay - that's good to know.
>>>>>>>>>>
>>>>>>>>>> However the -Xmx770m is a problem - our small devices only have
>>>>>>>>>> 512MB
>>>>>>>>>> of memory. Is the 770M only needed for 64-bit with
>>>>>>>>>> -UseCompressedOops ?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Lev
>>>>>>>>>>>
>>>>>>>>>>> On 03/17/2015 07:40 AM, David Holmes wrote:
>>>>>>>>>>>> Hi Lev,
>>>>>>>>>>>>
>>>>>>>>>>>> On 17/03/2015 6:30 AM, Lev Priima wrote:
>>>>>>>>>>>>> Please reviewand push:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Issue:https://bugs.openjdk.java.net/browse/JDK-8075071
>>>>>>>>>>>>> Patch: http://cr.openjdk.java.net/~lpriima/8075071/0/webrev/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tested locally:
>>>>>>>>>>>>> jtreg -vmoptions:"-XX:MaxRAMFraction=9223372036854775807
>>>>>>>>>>>>> -XX:-UseCompressedOops"
>>>>>>>>>>>>> test/java/util/Arrays/TimSortStackSize2.java
>>>>>>>>>>>>> Test results: passed: 1
>>>>>>>>>>>>
>>>>>>>>>>>> How does MaxRAMFraction interact with -Xmx?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>>> Lev
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>


From Alan.Bateman at oracle.com  Tue Mar 24 07:49:19 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Mar 2015 07:49:19 +0000
Subject: RFR: JDK-8075774 Small readability and performance improvements
	for zipfs
In-Reply-To: <CA+kOe09-5y6rP_b75JVzfY5SYckdsxMJ+g60-RC2QDQFCAqPrQ@mail.gmail.com>
References: <CA+kOe09-5y6rP_b75JVzfY5SYckdsxMJ+g60-RC2QDQFCAqPrQ@mail.gmail.com>
Message-ID: <551116FF.8040107@oracle.com>

On 23/03/2015 23:44, Martin Buchholz wrote:
> https://bugs.openjdk.java.net/browse/JDK-8075774
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/PKsig-java/
Looks okay but it makes for mix of styles (LL vs. getSig for example).

-Alan


From amy.lu at oracle.com  Tue Mar 24 07:54:33 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 24 Mar 2015 15:54:33 +0800
Subject: JDK 9 RFR of JDK-8075304: Remove duplicate test: FDTest
In-Reply-To: <5507D244.40509@oracle.com>
References: <5507D244.40509@oracle.com>
Message-ID: <55111839.4010506@oracle.com>

Kindly reminder ...

On 3/17/15 3:05 PM, Amy Lu wrote:
> This RFR proposes to remove the duplicate FDTest from ?jdk? repo.
>
> FDTest exists in both ?jdk? and ?langtools?:
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/test/jdk/lambda/FDTest.java 
>
> http://hg.openjdk.java.net/jdk9/dev/langtools/file/tip/test/tools/javac/lambdaShapes/org/openjdk/tests/javac/FDTest.java 
>
>
> So far the only diff between the two tests is that the version in 
> langtools has one more teardown method to well handle the resource close
> > @AfterSuite
> > static void teardown() throws IOException {
> > fm.close();
> > }
>
> As this test is for JavaCompiler, it makes more sense to keep the test 
> in "langtools" and remove the duplicate one from "jdk?.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8075304
> webrev: http://cr.openjdk.java.net/~amlu/8075304/webrev.00/
>
>
> Thanks,
> Amy



From paul.sandoz at oracle.com  Tue Mar 24 07:55:30 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 24 Mar 2015 08:55:30 +0100
Subject: RFR: JDK-8074578 Document memory visibility effects of some
	Unsafe methods
In-Reply-To: <00CDE96F-D1B3-4E5D-B254-6ED0F0A90D6B@oracle.com>
References: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>
	<54FCEA87.3030509@oracle.com> <54FD6767.8020506@redhat.com>
	<54FD8059.9050205@oracle.com>
	<CA+kOe0-NSsfYwDE6xzquWAe9OVhx389tX27vo5_DUpUSdTEpeQ@mail.gmail.com>
	<54FE4943.1030008@oracle.com> <54FE9DDA.8030301@redhat.com>
	<CA+kOe08JzETEdOR0twbRc5h3RfkZL007iaBEagZYniaR3GVXbA@mail.gmail.com>
	<2608270C-BDD6-4E8F-8D1F-5E6FB0F42BFC@oracle.com>
	<CA+kOe08dR8K2f9Ee2+v=DrG4zmpOjWS=_hRD6rW1JKPqLr0iwA@mail.gmail.com>
	<00CDE96F-D1B3-4E5D-B254-6ED0F0A90D6B@oracle.com>
Message-ID: <B0BFA8C4-85B8-4DC8-84B0-EACDD8AB386F@oracle.com>

On Mar 24, 2015, at 12:27 AM, John Rose <john.r.rose at oracle.com> wrote:
> Meanwhile, Paul Sandoz is working to refactor these aspects, creating a large chunk of API that will be public, portable, and secure.  You've got to sympathize with him for not wanting to run through all the inevitable arguments about concurrency primitives once for Unsafe and once again later for VarHandles.

Yes, that's it. As i said i am all for it, but sensing disagreement thought it might be best to hold off a bit. I don't wanna block if that disagreement is resolved. In fact i wanna take a swing at some other aspects of Unsafe to clear up the naming of putOrdered* as mooted in an email to hotspot-runtime.

Paul.


From paul.sandoz at oracle.com  Tue Mar 24 07:57:30 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 24 Mar 2015 08:57:30 +0100
Subject: RFR 8075307 Pipeline calculating inconsistent flag state for
	parallel stateful ops
In-Reply-To: <5510C0E2.3010900@oracle.com>
References: <9BFBFA94-A170-420A-814C-C66262F3E157@oracle.com>
	<5510C0E2.3010900@oracle.com>
Message-ID: <FD8AAD50-7CD2-4BEE-8E0C-8CD6D23BF0C0@oracle.com>

Hi Stuart,

Many thanks for looking at this gnarly code.

On Mar 24, 2015, at 2:41 AM, Stuart Marks <stuart.marks at oracle.com> wrote:

> Hi Paul,
> 
> After reading your notes here, and in the bug reports, and the comments in the code, and banging my head against the code (before and after) for a while, I'm starting to see that this is on the right track. Sorry to hedge a bit but I have to admit that I don't fully understand the code.
> 
> However, I do see the comment you referred to (old version, line 460) and that the new code is essentially a merge of the old parallelPrepare() code into sourceSpliterator(). And I do see the crucial addition of the flag modification based on the spliterator's SIZED characteristic. So that seems right, and if the tests pass, so much the better.
> 
> A few comments for future maintenance/cleanups in this area.
> 

All good points i will add some of my own below.


> * This package seems like a curious mixture of abstraction of bit-twiddling into small methods (e.g., combineOpFlags), and bit-twiddling in open code (evalation of Spliterator.SIZED into thisOpFlags, new version lines 459ff). While not incorrect, this is jarring.
> 

Yeah, in more common cases i optimized but it is probably not necessary.


> * The loop variables over the pipeline stages are hard to follow. The variable 'p' is used in the loop at line 413 a the "current" pipeline stage, whereas 'p' is used for the "next" stage in the loop at 434, and 'u' is the "current" stage. This is confusing, and I don't know what 'u' means.
> 

"p" is consistent between both loops for initialization and the next stage, it's the termination that is different (the first loop never needs to process the source stage and keep track of the previous stage). There is a reason for this due to the optimisation in toArray.

"u" = I forget :-)


> * Also, in the same loop, 'e' is initialized to 'this' and is checked as the loop exit condition (I guess that's what 'e' stands for) but it's not used elsewhere, so it's not clear to me how much value this adds.

e == "end of pipeline".

Additionally we don't need the perform the first loop if there are no terminal flags.


> 
> Stepping back from this a bit, this is clearly an area of some complexity, and it might benefit from some additional testing. The streams library is overall well-tested, but mostly from a functional level, i.e. running a bunch of streams in various combinations to ensure the right output is produced. For this case it might be helpful to assemble (but not execute) a bunch of combinations of pipelines and then make sure that each stage ends up with the right flags. (I didn't find such a test when I went looking, but I might have missed it.)
> 

There are some. Follow the trail of StatelessTestOp. What we lack is a systematic way of performing combinatorial testing derived from a more formal description of the operations and their flag manipulation.

In this case, as per the comment in the old code, there was a deliberate limitation so testing in this case would not have helped.


> In any case I think it's reasonble to proceed with this patch as it stands instead of tinkering with it. Some additional cleanups are warranted at some point but we should keep an eye on these for the future.
> 

Thanks,
Paul.


From david.holmes at oracle.com  Tue Mar 24 08:04:08 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Mar 2015 18:04:08 +1000
Subject: RFR: JDK-8074578 Document memory visibility effects of some Unsafe
	methods
In-Reply-To: <B0BFA8C4-85B8-4DC8-84B0-EACDD8AB386F@oracle.com>
References: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>	<54FCEA87.3030509@oracle.com>
	<54FD6767.8020506@redhat.com>	<54FD8059.9050205@oracle.com>	<CA+kOe0-NSsfYwDE6xzquWAe9OVhx389tX27vo5_DUpUSdTEpeQ@mail.gmail.com>	<54FE4943.1030008@oracle.com>
	<54FE9DDA.8030301@redhat.com>	<CA+kOe08JzETEdOR0twbRc5h3RfkZL007iaBEagZYniaR3GVXbA@mail.gmail.com>	<2608270C-BDD6-4E8F-8D1F-5E6FB0F42BFC@oracle.com>	<CA+kOe08dR8K2f9Ee2+v=DrG4zmpOjWS=_hRD6rW1JKPqLr0iwA@mail.gmail.com>	<00CDE96F-D1B3-4E5D-B254-6ED0F0A90D6B@oracle.com>
	<B0BFA8C4-85B8-4DC8-84B0-EACDD8AB386F@oracle.com>
Message-ID: <55111A78.5010706@oracle.com>

On 24/03/2015 5:55 PM, Paul Sandoz wrote:
> On Mar 24, 2015, at 12:27 AM, John Rose <john.r.rose at oracle.com> wrote:
>> Meanwhile, Paul Sandoz is working to refactor these aspects, creating a large chunk of API that will be public, portable, and secure.  You've got to sympathize with him for not wanting to run through all the inevitable arguments about concurrency primitives once for Unsafe and once again later for VarHandles.
>
> Yes, that's it. As i said i am all for it, but sensing disagreement thought it might be best to hold off a bit. I don't wanna block if that disagreement is resolved. In fact i wanna take a swing at some other aspects of Unsafe to clear up the naming of putOrdered* as mooted in an email to hotspot-runtime.

I will defer to John's wisdom on this. These discussions burn a lot of 
cycles with little concrete benefit to be gained.

David

> Paul.
>


From aph at redhat.com  Tue Mar 24 08:15:29 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 24 Mar 2015 08:15:29 +0000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <55108130.2010207@oracle.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>	<550A90CE.9080901@redhat.com>
	<550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com>
	<550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com>
	<550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com>
	<550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com>
	<55105C0A.8070305@redhat.com> <55108130.2010207@oracle.com>
Message-ID: <55111D21.1020502@redhat.com>

On 23/03/15 21:10, Vladimir Kozlov wrote:
> Hotspot make files changes?

There's no need: I think we came to the conclusion that we wouldn't
define BIG_ENDIAN.

Andrew.



From chris.hegarty at oracle.com  Tue Mar 24 09:38:08 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 24 Mar 2015 09:38:08 +0000
Subject: RFR: JDK-8068721 - RMI-IIOP communication fails when
	ConcurrentHashMap is passed to remote method
In-Reply-To: <CA+kOe09S6o8xx8MufAHpO2e_NbhqgHHvP+Jbuwy41Y4yLqOoCw@mail.gmail.com>
References: <551084E3.6050702@oracle.com>
	<CA+kOe09S6o8xx8MufAHpO2e_NbhqgHHvP+Jbuwy41Y4yLqOoCw@mail.gmail.com>
Message-ID: <C6606626-61AA-48A4-A06E-5568EF37E538@oracle.com>

Martin,

On 23 Mar 2015, at 22:15, Martin Buchholz <martinrb at google.com> wrote:

> Let us know if the serialization code of the collection classes can be
> improved.

I think there are a few minor cleanups that would be beneficial in CHM:

 1) Add @serialField so that the serializable stream fields show up in the
     javadoc ( serial form ), since they are still part of the serial form, even
     though not used in the implementation. This is just documenting
     existing behaviour/form.

 2) Mark correctly identified a small hole in the putFields() spec, which
     should be fixed. A minor, benign, change in CHM writeObject
     can avoid this ( spec ambiguity ).

Please consider the following change:

diff --git a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java b/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
--- a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
+++ b/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
@@ -35,6 +35,7 @@
 
 package java.util.concurrent;
 
+import java.io.ObjectOutputStream;
 import java.io.ObjectStreamField;
 import java.io.Serializable;
 import java.lang.reflect.ParameterizedType;
@@ -599,7 +600,12 @@
     /** Number of CPUS, to place bounds on some sizings */
     static final int NCPU = Runtime.getRuntime().availableProcessors();
 
-    /** For serialization compatibility. */
+    /**
+     * For serialization compatibility.
+     * @serialField segments Segment[]
+     * @serialField segmentMask int
+     * @serialField segmentShift int
+     */
     private static final ObjectStreamField[] serialPersistentFields = {
         new ObjectStreamField("segments", Segment[].class),
         new ObjectStreamField("segmentMask", Integer.TYPE),
@@ -1400,9 +1406,10 @@
             new Segment<?,?>[DEFAULT_CONCURRENCY_LEVEL];
         for (int i = 0; i < segments.length; ++i)
             segments[i] = new Segment<K,V>(LOAD_FACTOR);
-        s.putFields().put("segments", segments);
-        s.putFields().put("segmentShift", segmentShift);
-        s.putFields().put("segmentMask", segmentMask);
+        ObjectOutputStream.PutField streamFields = s.putFields();
+        streamFields.put("segments", segments);
+        streamFields.put("segmentShift", segmentShift);
+        streamFields.put("segmentMask", segmentMask);
         s.writeFields();
 
         Node<K,V>[] t;

-Chris.

> On Mon, Mar 23, 2015 at 2:25 PM, Mark Sheppard <mark.sheppard at oracle.com>
> wrote:
> 
>> Hi
>> please oblige and review the following fix
>> 
>> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev/
>> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev/
>> 
>> 
>> which addresses the issue in
>> https://bugs.openjdk.java.net/browse/JDK-8068721
>> 
>> This relates to RMI-IIOP and the interplay between custom marshalling of
>> ValueTypes and
>> the corresponding serialization of a Java class, in this case
>> ConcurrentHashMap.
>> 
>> ConcurrentHashMap changed its structure in jdk8 from that used in jdk7.
>> This resulted in modification to the readObject and writeObject methods,
>> and in particular, former serial fields were removed, resulting in
>> writeObject using PutField and readObject using defaultReadObject.
>> The writeObject invokes the putFields method of an ObjectOutputStream
>> multiple times, and assumes
>> that it will receive the same PutField object instance for each
>> invocation. The spec
>> doesn't endorse this behaviour - but that's what the implementation of
>> ObjectOutputStream
>> provides. However in the case of RMI-IIOP, the OutputStreamHook, a
>> subclass of ObjectOutputStream, returns a new instance for each
>> putFields invocation. Thus, the ConcurrentHashMap writeObject results in
>> improper serialization in the context
>> of RMI-IIOP.
>> In the unmarshalling flow of ConcurrentHashMap, the readObject now uses
>> defaultReadObject rather than GetField
>> In this call flow the IIOPInputStream attempts to ignore any primitive
>> field, in the serialized data, that doesn't
>> correspond with a reflective field of the object. However, it leaves the
>> primitive in the stream.
>> Thus, in the case of ConcurrentHashMap, which has serialized two integers
>> and
>> an array of Segments (subclass of ReentrantLock), this results in erroneous
>> deserialization, with a misinterpretation of a value tag in the stream as
>> an array length
>> and an attempt to allocate a very large array ensues, with an exception
>> being thrown.
>> 
>> The OutputStreamHook now returns the same instance of PutField allocated
>> for each separate call of putFields method.
>> This highlights a need to tighten up and disambiguate the
>> OutputObjectStream spec for putFields.
>> 
>> IIOPInputStream now removes the primitive values from the stream.
>> 
>> regards
>> Mark
>> 



From chris.hegarty at oracle.com  Tue Mar 24 10:01:47 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 24 Mar 2015 10:01:47 +0000
Subject: RFR: JDK-8068721 - RMI-IIOP communication fails when
	ConcurrentHashMap is passed to remote method
In-Reply-To: <551084E3.6050702@oracle.com>
References: <551084E3.6050702@oracle.com>
Message-ID: <195620AF-7960-4951-9968-9BE4F0EB59A1@oracle.com>


On 23 Mar 2015, at 21:25, Mark Sheppard <mark.sheppard at oracle.com> wrote:

> ?.
> 
> ConcurrentHashMap changed its structure in jdk8 from that used in jdk7.
> This resulted in modification to the readObject and writeObject methods,
> and in particular, former serial fields were removed, resulting in

The non-transient fields were removed, but the on-the-wire serial form stayed the same. Unfortunately, serialPersistentFields is missing the description of its elements, so the serial form does not show up in the javadoc. I sent suggested changes to address this in a separate mail.

> writeObject using PutField and readObject using defaultReadObject.
> The writeObject invokes the putFields method of an ObjectOutputStream multiple times, and assumes
> that it will receive the same PutField object instance for each invocation. The spec
> doesn't endorse this behaviour - but that's what the implementation of ObjectOutputStream
> provides.

I filed the following bug to tighten up the OOS.putFields spec:
  https://bugs.openjdk.java.net/browse/JDK-8075802

> However in the case of RMI-IIOP, the OutputStreamHook, a subclass of ObjectOutputStream, returns a new instance for each
> putFields invocation. Thus, the ConcurrentHashMap writeObject results in improper serialization in the context
> of RMI-IIOP.
> In the unmarshalling flow of ConcurrentHashMap, the readObject now uses defaultReadObject rather than GetField
> In this call flow the IIOPInputStream attempts to ignore any primitive field, in the serialized data, that doesn't
> correspond with a reflective field of the object. However, it leaves the primitive in the stream.

Ouch! This looks like a nasty bug in IIOPInputStream.

> Thus, in the case of ConcurrentHashMap, which has serialized two integers and
> an array of Segments (subclass of ReentrantLock), this results in erroneous
> deserialization, with a misinterpretation of a value tag in the stream as an array length
> and an attempt to allocate a very large array ensues, with an exception being thrown.
> 
> The OutputStreamHook now returns the same instance of PutField allocated for each separate call of putFields method.

This seems reasonable to me.

> This highlights a need to tighten up and disambiguate the OutputObjectStream spec for putFields.

Yes, it does. We should address it in 8075802.

I see you have changed OutputStreamHook to return the same instance for multiple calls, so adding a spec clarification, to that affect, to OOS.putFields() would not conflict with your change.

> IIOPInputStream now removes the primitive values from the stream.

I just looked at the code changes in the corba repo, and they look ok to me.

-Chris.

> regards
> Mark



From mark.sheppard at oracle.com  Tue Mar 24 10:13:00 2015
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Tue, 24 Mar 2015 10:13:00 +0000
Subject: RFR: JDK-8068721 - RMI-IIOP communication fails when
	ConcurrentHashMap is passed to remote method
In-Reply-To: <C6606626-61AA-48A4-A06E-5568EF37E538@oracle.com>
References: <551084E3.6050702@oracle.com>
	<CA+kOe09S6o8xx8MufAHpO2e_NbhqgHHvP+Jbuwy41Y4yLqOoCw@mail.gmail.com>
	<C6606626-61AA-48A4-A06E-5568EF37E538@oracle.com>
Message-ID: <551138AC.1010209@oracle.com>

Thanks Chris
I can include the proposed changes if you wish.
my original fix had similar PutField change to writeObject, but I left 
it from this review so
that it could be addressed separately.

regards
Mark

On 24/03/2015 09:38, Chris Hegarty wrote:
> Martin,
>
> On 23 Mar 2015, at 22:15, Martin Buchholz <martinrb at google.com> wrote:
>
>> Let us know if the serialization code of the collection classes can be
>> improved.
> I think there are a few minor cleanups that would be beneficial in CHM:
>
>   1) Add @serialField so that the serializable stream fields show up in the
>       javadoc ( serial form ), since they are still part of the serial form, even
>       though not used in the implementation. This is just documenting
>       existing behaviour/form.
>
>   2) Mark correctly identified a small hole in the putFields() spec, which
>       should be fixed. A minor, benign, change in CHM writeObject
>       can avoid this ( spec ambiguity ).
>
> Please consider the following change:
>
> diff --git a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java b/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
> --- a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
> +++ b/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
> @@ -35,6 +35,7 @@
>   
>   package java.util.concurrent;
>   
> +import java.io.ObjectOutputStream;
>   import java.io.ObjectStreamField;
>   import java.io.Serializable;
>   import java.lang.reflect.ParameterizedType;
> @@ -599,7 +600,12 @@
>       /** Number of CPUS, to place bounds on some sizings */
>       static final int NCPU = Runtime.getRuntime().availableProcessors();
>   
> -    /** For serialization compatibility. */
> +    /**
> +     * For serialization compatibility.
> +     * @serialField segments Segment[]
> +     * @serialField segmentMask int
> +     * @serialField segmentShift int
> +     */
>       private static final ObjectStreamField[] serialPersistentFields = {
>           new ObjectStreamField("segments", Segment[].class),
>           new ObjectStreamField("segmentMask", Integer.TYPE),
> @@ -1400,9 +1406,10 @@
>               new Segment<?,?>[DEFAULT_CONCURRENCY_LEVEL];
>           for (int i = 0; i < segments.length; ++i)
>               segments[i] = new Segment<K,V>(LOAD_FACTOR);
> -        s.putFields().put("segments", segments);
> -        s.putFields().put("segmentShift", segmentShift);
> -        s.putFields().put("segmentMask", segmentMask);
> +        ObjectOutputStream.PutField streamFields = s.putFields();
> +        streamFields.put("segments", segments);
> +        streamFields.put("segmentShift", segmentShift);
> +        streamFields.put("segmentMask", segmentMask);
>           s.writeFields();
>   
>           Node<K,V>[] t;
>
> -Chris.
>
>> On Mon, Mar 23, 2015 at 2:25 PM, Mark Sheppard <mark.sheppard at oracle.com>
>> wrote:
>>
>>> Hi
>>> please oblige and review the following fix
>>>
>>> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev/
>>> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev/
>>>
>>>
>>> which addresses the issue in
>>> https://bugs.openjdk.java.net/browse/JDK-8068721
>>>
>>> This relates to RMI-IIOP and the interplay between custom marshalling of
>>> ValueTypes and
>>> the corresponding serialization of a Java class, in this case
>>> ConcurrentHashMap.
>>>
>>> ConcurrentHashMap changed its structure in jdk8 from that used in jdk7.
>>> This resulted in modification to the readObject and writeObject methods,
>>> and in particular, former serial fields were removed, resulting in
>>> writeObject using PutField and readObject using defaultReadObject.
>>> The writeObject invokes the putFields method of an ObjectOutputStream
>>> multiple times, and assumes
>>> that it will receive the same PutField object instance for each
>>> invocation. The spec
>>> doesn't endorse this behaviour - but that's what the implementation of
>>> ObjectOutputStream
>>> provides. However in the case of RMI-IIOP, the OutputStreamHook, a
>>> subclass of ObjectOutputStream, returns a new instance for each
>>> putFields invocation. Thus, the ConcurrentHashMap writeObject results in
>>> improper serialization in the context
>>> of RMI-IIOP.
>>> In the unmarshalling flow of ConcurrentHashMap, the readObject now uses
>>> defaultReadObject rather than GetField
>>> In this call flow the IIOPInputStream attempts to ignore any primitive
>>> field, in the serialized data, that doesn't
>>> correspond with a reflective field of the object. However, it leaves the
>>> primitive in the stream.
>>> Thus, in the case of ConcurrentHashMap, which has serialized two integers
>>> and
>>> an array of Segments (subclass of ReentrantLock), this results in erroneous
>>> deserialization, with a misinterpretation of a value tag in the stream as
>>> an array length
>>> and an attempt to allocate a very large array ensues, with an exception
>>> being thrown.
>>>
>>> The OutputStreamHook now returns the same instance of PutField allocated
>>> for each separate call of putFields method.
>>> This highlights a need to tighten up and disambiguate the
>>> OutputObjectStream spec for putFields.
>>>
>>> IIOPInputStream now removes the primitive values from the stream.
>>>
>>> regards
>>> Mark
>>>



From chris.hegarty at oracle.com  Tue Mar 24 10:26:24 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 24 Mar 2015 10:26:24 +0000
Subject: RFR: JDK-8068721 - RMI-IIOP communication fails when
	ConcurrentHashMap is passed to remote method
In-Reply-To: <551138AC.1010209@oracle.com>
References: <551084E3.6050702@oracle.com>
	<CA+kOe09S6o8xx8MufAHpO2e_NbhqgHHvP+Jbuwy41Y4yLqOoCw@mail.gmail.com>
	<C6606626-61AA-48A4-A06E-5568EF37E538@oracle.com>
	<551138AC.1010209@oracle.com>
Message-ID: <488046F9-BABC-42C8-8412-258D0750CE48@oracle.com>

On 24 Mar 2015, at 10:13, Mark Sheppard <mark.sheppard at oracle.com> wrote:

> Thanks Chris
> I can include the proposed changes if you wish.

I think it best to keep any potential changes to CHM separate, so as not to block your changes. We need to first have the CHM changes accepted by the 166 maintainers, applied upstream, then we can create a patch to bring them into OpenJDK.

I think your changes ( I have only looked at the corba repo) are perfectly good as they are, but they may be less urgent if we get the proposed CHM changes in, and of course CHM may no longer be a good candidate for testing with ;-(

-Chris.

> my original fix had similar PutField change to writeObject, but I left it from this review so
> that it could be addressed separately.
> 
> regards
> Mark
> 
> On 24/03/2015 09:38, Chris Hegarty wrote:
>> Martin,
>> 
>> On 23 Mar 2015, at 22:15, Martin Buchholz <martinrb at google.com> wrote:
>> 
>>> Let us know if the serialization code of the collection classes can be
>>> improved.
>> I think there are a few minor cleanups that would be beneficial in CHM:
>> 
>>  1) Add @serialField so that the serializable stream fields show up in the
>>      javadoc ( serial form ), since they are still part of the serial form, even
>>      though not used in the implementation. This is just documenting
>>      existing behaviour/form.
>> 
>>  2) Mark correctly identified a small hole in the putFields() spec, which
>>      should be fixed. A minor, benign, change in CHM writeObject
>>      can avoid this ( spec ambiguity ).
>> 
>> Please consider the following change:
>> 
>> diff --git a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java b/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
>> --- a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
>> +++ b/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
>> @@ -35,6 +35,7 @@
>>    package java.util.concurrent;
>>  +import java.io.ObjectOutputStream;
>>  import java.io.ObjectStreamField;
>>  import java.io.Serializable;
>>  import java.lang.reflect.ParameterizedType;
>> @@ -599,7 +600,12 @@
>>      /** Number of CPUS, to place bounds on some sizings */
>>      static final int NCPU = Runtime.getRuntime().availableProcessors();
>>  -    /** For serialization compatibility. */
>> +    /**
>> +     * For serialization compatibility.
>> +     * @serialField segments Segment[]
>> +     * @serialField segmentMask int
>> +     * @serialField segmentShift int
>> +     */
>>      private static final ObjectStreamField[] serialPersistentFields = {
>>          new ObjectStreamField("segments", Segment[].class),
>>          new ObjectStreamField("segmentMask", Integer.TYPE),
>> @@ -1400,9 +1406,10 @@
>>              new Segment<?,?>[DEFAULT_CONCURRENCY_LEVEL];
>>          for (int i = 0; i < segments.length; ++i)
>>              segments[i] = new Segment<K,V>(LOAD_FACTOR);
>> -        s.putFields().put("segments", segments);
>> -        s.putFields().put("segmentShift", segmentShift);
>> -        s.putFields().put("segmentMask", segmentMask);
>> +        ObjectOutputStream.PutField streamFields = s.putFields();
>> +        streamFields.put("segments", segments);
>> +        streamFields.put("segmentShift", segmentShift);
>> +        streamFields.put("segmentMask", segmentMask);
>>          s.writeFields();
>>            Node<K,V>[] t;
>> 
>> -Chris.
>> 
>>> On Mon, Mar 23, 2015 at 2:25 PM, Mark Sheppard <mark.sheppard at oracle.com>
>>> wrote:
>>> 
>>>> Hi
>>>> please oblige and review the following fix
>>>> 
>>>> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev/
>>>> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev/
>>>> 
>>>> 
>>>> which addresses the issue in
>>>> https://bugs.openjdk.java.net/browse/JDK-8068721
>>>> 
>>>> This relates to RMI-IIOP and the interplay between custom marshalling of
>>>> ValueTypes and
>>>> the corresponding serialization of a Java class, in this case
>>>> ConcurrentHashMap.
>>>> 
>>>> ConcurrentHashMap changed its structure in jdk8 from that used in jdk7.
>>>> This resulted in modification to the readObject and writeObject methods,
>>>> and in particular, former serial fields were removed, resulting in
>>>> writeObject using PutField and readObject using defaultReadObject.
>>>> The writeObject invokes the putFields method of an ObjectOutputStream
>>>> multiple times, and assumes
>>>> that it will receive the same PutField object instance for each
>>>> invocation. The spec
>>>> doesn't endorse this behaviour - but that's what the implementation of
>>>> ObjectOutputStream
>>>> provides. However in the case of RMI-IIOP, the OutputStreamHook, a
>>>> subclass of ObjectOutputStream, returns a new instance for each
>>>> putFields invocation. Thus, the ConcurrentHashMap writeObject results in
>>>> improper serialization in the context
>>>> of RMI-IIOP.
>>>> In the unmarshalling flow of ConcurrentHashMap, the readObject now uses
>>>> defaultReadObject rather than GetField
>>>> In this call flow the IIOPInputStream attempts to ignore any primitive
>>>> field, in the serialized data, that doesn't
>>>> correspond with a reflective field of the object. However, it leaves the
>>>> primitive in the stream.
>>>> Thus, in the case of ConcurrentHashMap, which has serialized two integers
>>>> and
>>>> an array of Segments (subclass of ReentrantLock), this results in erroneous
>>>> deserialization, with a misinterpretation of a value tag in the stream as
>>>> an array length
>>>> and an attempt to allocate a very large array ensues, with an exception
>>>> being thrown.
>>>> 
>>>> The OutputStreamHook now returns the same instance of PutField allocated
>>>> for each separate call of putFields method.
>>>> This highlights a need to tighten up and disambiguate the
>>>> OutputObjectStream spec for putFields.
>>>> 
>>>> IIOPInputStream now removes the primitive values from the stream.
>>>> 
>>>> regards
>>>> Mark
>>>> 
> 



From mark.sheppard at oracle.com  Tue Mar 24 11:11:44 2015
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Tue, 24 Mar 2015 11:11:44 +0000
Subject: RFR: JDK-8068721 - RMI-IIOP communication fails when
	ConcurrentHashMap is passed to remote method
In-Reply-To: <5511138A.2090206@oracle.com>
References: <551084E3.6050702@oracle.com> <5511138A.2090206@oracle.com>
Message-ID: <55114670.5000502@oracle.com>

Hi Alan,
    thanks for the feedback.

WRT test location, I followed what is already in place i.e. 
javax/rmi/ssl had an existing test
so as RMI-IIOP falls under javax/rmi/PortableRemoteObject, placing the 
test in this grouping seemed reasonable.
It's no bother to place it elsewhere if you wish.

WRT 1050,  this is a conundrum, and there doesn't seem to be a reliable 
way of obtaining a port to absolutely avoid a clash.
This is the orbd's standard port.
There doesn't seem to be a reliable way of obtaining a port to 
absolutely avoid a clash.
The test relies on the observation that ephemeral ports on most 
contemporary platforms are being allocated
outside the well known and application allocated port ( > 32K ).
It could use 1060 instead.
It possible that multiple concurrent  orbd may be running,  but I've run 
the regression suite many times for this issue, and
multiple orbd execution hasn't shown up, yet.

Maybe a category of tests which specify such tests are not to be run in 
parallel with other tests would be helpful?

WRT stubs and ties, I was trying to avoid use of a shell script. A once 
off generation of stub and tie was
a handy way to avoid this. I don't think jtreg has an @rmic or @idl 
similar to @build or @compile?

regards
Mark



On 24/03/2015 07:34, Alan Bateman wrote:
> On 23/03/2015 21:25, Mark Sheppard wrote:
>> Hi
>>  please oblige and review the following fix
>>
>> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev/
>> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev/
>>
>>
>> which addresses the issue in
>> https://bugs.openjdk.java.net/browse/JDK-8068721
>>
>> This relates to RMI-IIOP and the interplay between custom marshalling 
>> of ValueTypes and
>> the corresponding serialization of a Java class, in this case 
>> ConcurrentHashMap.
> Looks like this needs a deep dive into the RMI-IIOP spec to properly 
> review this. I see Sean Coffey has been looking at it too so hopefully 
> he has cycles to help on this.
>
> A few passing comments on the tests:
>
> Should the tie and stub be generated by the test rather than checking 
> in the generated code?
>
> The test launches ordb and and an RMI-IIOP server, I wonder if the 
> test library infrastructure could be used to do this instead (as we 
> have so many issues with multi-VM tests). Also it's using a fixed port 
> which might be a problem when running concurrently with other tests 
> (esp. any test using a naming service as it will be using 1050 too).
>
> The patch adds RMI-IIOP tests to the jdk_rmi test group. I think to 
> date that we've put CORBA and RMI-IIOP tests in jdk_other. I realize 
> this has implications for where the tests are placed.
>
> -Alan.



From Alan.Bateman at oracle.com  Tue Mar 24 11:27:15 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Mar 2015 11:27:15 +0000
Subject: RFR [9] 8071472: Add field setter API for setting final fields
	in readObject
In-Reply-To: <5510351D.1070500@oracle.com>
References: <5510351D.1070500@oracle.com>
Message-ID: <55114A13.9010509@oracle.com>

On 23/03/2015 15:45, Chris Hegarty wrote:
> Here is an updated version of the FieldSetter API, with all comments 
> to date incorporated.
>
>
> http://cr.openjdk.java.net/~chegar/8071472/02/specdiff/overview-summary.html 
>
>
> Final spec comments welcome, after which I intend to submit a CCC 
> request.

In fieldSetter() then a small typo "associate with current object" => 
missing "the".

Also in fieldSetter() then the first sentence might be clearer if you 
split it into two with the second sentence starting as "The FieldSetter 
gives write access ...".

In FieldSetter then the first sentence might read a bit better if you 
change "including final" to "including final fields".

A suggestion for the second sentence is to change is to: "A thread 
executing readObject gets the FieldSetter by invoking the fieldSetter() 
method. The FieldSetter can be used to set any instance field of the 
object being deserialized".

In the third sentence then it might read a bit better if you drop the 
comma before "where applicable".

I wonder if it might make sense to just drop the paragraph that lists 
the conditions for which ISE and IAE are thrown as this is repeated in 
each of the set methods.

Otherwise it looks good to me.

-Alan.









From Alan.Bateman at oracle.com  Tue Mar 24 14:08:44 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Mar 2015 14:08:44 +0000
Subject: RFR: JDK-8068721 - RMI-IIOP communication fails when
	ConcurrentHashMap is passed to remote method
In-Reply-To: <55114670.5000502@oracle.com>
References: <551084E3.6050702@oracle.com> <5511138A.2090206@oracle.com>
	<55114670.5000502@oracle.com>
Message-ID: <55116FEC.2000002@oracle.com>

On 24/03/2015 11:11, Mark Sheppard wrote:
> Hi Alan,
>    thanks for the feedback.
>
> WRT test location, I followed what is already in place i.e. 
> javax/rmi/ssl had an existing test
> so as RMI-IIOP falls under javax/rmi/PortableRemoteObject, placing the 
> test in this grouping seemed reasonable.
> It's no bother to place it elsewhere if you wish.
To date then the directories containing the CORBA and RMI-IIOP tests 
have been in the jdk_other group. I think it would be best not to have 
them split between two groups. Adding this to jdk_other should do it:

javax/rmi \
-javax/rmi/ssl

>
> WRT 1050,  this is a conundrum, and there doesn't seem to be a 
> reliable way of obtaining a port to absolutely avoid a clash.
> This is the orbd's standard port.
> There doesn't seem to be a reliable way of obtaining a port to 
> absolutely avoid a clash.
> The test relies on the observation that ephemeral ports on most 
> contemporary platforms are being allocated
> outside the well known and application allocated port ( > 32K ).
> It could use 1060 instead.
> It possible that multiple concurrent  orbd may be running,  but I've 
> run the regression suite many times for this issue, and
> multiple orbd execution hasn't shown up, yet.
You might need to look at the exclusiveAccess.dirs property in TEST.ROOT 
to avoid several tests trying to run orbd at the same time.

Stuart has been battling a bunch of issues in other areas with "address 
already in use" and may have some advice on how to approach this test. I 
do see that orbd can run on other ports and also it might be possible to 
start it via it's com.sun API rather than the launcher.


> :
>
> WRT stubs and ties, I was trying to avoid use of a shell script. A 
> once off generation of stub and tie was
> a handy way to avoid this. I don't think jtreg has an @rmic or @idl 
> similar to @build or @compile?
>
This may be something to add to the testlibrary infrastructure.

-Alan.


From chris.hegarty at oracle.com  Tue Mar 24 14:42:29 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 24 Mar 2015 14:42:29 +0000
Subject: JEP 102 Process Review
Message-ID: <52DBF819-66D8-4662-8176-526CA3987876@oracle.com>

Roger,

I think the API is looking much better now ( just a few comments below on small specific issues ), so I?ve taken a pass over the implementation changes in the sandbox. Here are some comments:

1) Some operations on ProcessHandle require RuntimePermission
    "manageProcess", but I don't see this specified in
    java.lang.RuntimePermission ( there is a table of target runtime
    permission names ). I think you just need to add it.

2) Can ProcessImpl.waitForProcessExit and its native counterpart be
    removed? ( since its function is now performed through ProcessHandleImpl )

3) "process reaper?, maybe
    ?Process-Reaper-? + monotonically increasing ID ( similar to
    ForkJoin worker threads, or other ). But I do accept that this
    is the existing name for the reaper threads.

4) Should Info.toString() print something if all fields are null,
    or -1.

5) Could the fields for Info be private final, and use a separate
    private holder for retrieving the information from native?
    Seems desirable for them to be final.

6) Process has s number of @implXXX tags, they typically appear
    before the @return in usage I?ve seen in the JDK.

7) Should ProcessHandleImpl.toString include Info, and/or other
    information about the handle? 

Subjective/Minor:

1) There are number of commented out fprintfs in native code
    that should be removed.

2) You may need to take a pass over the copyright year range.
    I understand that some of these files were created in 2014, but
    I suspect that they should all at least include 2015.

3) OnExitTest & InfoTest include the ?Classpath? exception, when
    they should not.

4) There is some duplication of javadoc in implementation
    that could be removed, e.g:
       /**
        * Returns the process ID as a decimal String.
        * @return the process ID as a decimal String
        */

    My preference is to not repeat the public API doc in
    implementation classes, but I accept that this is sometimes
    done for in-place readability.

5) There are number of lines that are greater than 80 
    characters. These can be difficult for future maintenance
    and reviews ( webrev side-by-side diffs ).

I need to spend a little more time on the native code, but the tests pass so that is a good start!

-Chris.




From daniel.fuchs at oracle.com  Tue Mar 24 14:42:31 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 24 Mar 2015 15:42:31 +0100
Subject: RFR: 8075810: LogManager.readConfiguration may throw undocumented
	IllegalArgumentException
Message-ID: <551177D7.5060203@oracle.com>

Hi,

Please find below a fix for

8075810: LogManager.readConfiguration may throw
          undocumented IllegalArgumentException

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

The proposed fix is to catch the IllegalArgumentException and
wrap it in an IOException, since LogManager.readConfiguration
is specified to throw IOException "if there are problems reading
from the stream."

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

Initial discussion around the issue can be seen here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032348.html

Question for reviewers: I will log a CCC for this - but I am wondering
       whether I should plan to backport the fix to earlier release?


best regards,

-- daniel


From lance.andersen at oracle.com  Tue Mar 24 15:01:35 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 24 Mar 2015 11:01:35 -0400
Subject: RFR: 8075810: LogManager.readConfiguration may throw undocumented
	IllegalArgumentException
In-Reply-To: <551177D7.5060203@oracle.com>
References: <551177D7.5060203@oracle.com>
Message-ID: <938960BA-2827-417B-87AE-A1994A6B2AD4@oracle.com>

Hi Daniel,

This looks OK but I might suggest clarifying that the cause could be set in the javadoc.  Now that being said, I am not sure how consistent we are across the JDK or just make the assumption people will check the cause if they desire.

As far as backporting, unless it really needed, I would probably would not as a change such as this typically should be done as part of an errata/MR (due to change of behavior and it is not that big of an issue).  

Best
Lance
On Mar 24, 2015, at 10:42 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> Hi,
> 
> Please find below a fix for
> 
> 8075810: LogManager.readConfiguration may throw
>         undocumented IllegalArgumentException
> 
> https://bugs.openjdk.java.net/browse/JDK-8075810
> 
> The proposed fix is to catch the IllegalArgumentException and
> wrap it in an IOException, since LogManager.readConfiguration
> is specified to throw IOException "if there are problems reading
> from the stream."
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8075810/webrev.00/
> 
> Initial discussion around the issue can be seen here:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032348.html
> 
> Question for reviewers: I will log a CCC for this - but I am wondering
>      whether I should plan to backport the fix to earlier release?
> 
> 
> best regards,
> 
> -- daniel



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





From daniel.fuchs at oracle.com  Tue Mar 24 15:06:47 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 24 Mar 2015 16:06:47 +0100
Subject: RFR: 8075810: LogManager.readConfiguration may throw undocumented
	IllegalArgumentException
In-Reply-To: <938960BA-2827-417B-87AE-A1994A6B2AD4@oracle.com>
References: <551177D7.5060203@oracle.com>
	<938960BA-2827-417B-87AE-A1994A6B2AD4@oracle.com>
Message-ID: <55117D87.9040708@oracle.com>

Hi Lance,

Thanks for the review!

On 24/03/15 16:01, Lance Andersen wrote:
> Hi Daniel,
>
> This looks OK but I might suggest clarifying that the cause could be set
> in the javadoc.  Now that being said, I am not sure how consistent we
> are across the JDK or just make the assumption people will check the
> cause if they desire.

Hmmm. I have the feeling that the best place for that would be i the
release notes - rather than in the API doc (which reminds me I should
plan to add some release note text to the issue).

> As far as backporting, unless it really needed, I would probably would
> not as a change such as this typically should be done as part of an
> errata/MR (due to change of behavior and it is not that big of an issue).

Right, my thinking too. Thanks for sharing your opinion!

best regards,

-- daniel

>
> Best
> Lance
> On Mar 24, 2015, at 10:42 AM, Daniel Fuchs <daniel.fuchs at oracle.com
> <mailto:daniel.fuchs at oracle.com>> wrote:
>
>> Hi,
>>
>> Please find below a fix for
>>
>> 8075810: LogManager.readConfiguration may throw
>>         undocumented IllegalArgumentException
>>
>> https://bugs.openjdk.java.net/browse/JDK-8075810
>>
>> The proposed fix is to catch the IllegalArgumentException and
>> wrap it in an IOException, since LogManager.readConfiguration
>> is specified to throw IOException "if there are problems reading
>> from the stream."
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8075810/webrev.00/
>>
>> Initial discussion around the issue can be seen here:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032348.html
>>
>> Question for reviewers: I will log a CCC for this - but I am wondering
>>      whether I should plan to backport the fix to earlier release?
>>
>>
>> best regards,
>>
>> -- daniel
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen|
> Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>



From mandy.chung at oracle.com  Tue Mar 24 15:28:42 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 24 Mar 2015 08:28:42 -0700
Subject: RFR: 8075810: LogManager.readConfiguration may throw undocumented
	IllegalArgumentException
In-Reply-To: <551177D7.5060203@oracle.com>
References: <551177D7.5060203@oracle.com>
Message-ID: <551182AA.60302@oracle.com>



On 3/24/2015 7:42 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a fix for
>
> 8075810: LogManager.readConfiguration may throw
>          undocumented IllegalArgumentException
>
> https://bugs.openjdk.java.net/browse/JDK-8075810
>
> The proposed fix is to catch the IllegalArgumentException and
> wrap it in an IOException, since LogManager.readConfiguration
> is specified to throw IOException "if there are problems reading
> from the stream."
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8075810/webrev.00/
>

Looks fine.

> Initial discussion around the issue can be seen here:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032348.html 
>
>
> Question for reviewers: I will log a CCC for this - but I am wondering
>       whether I should plan to backport the fix to earlier release?

This doesn't seem critical to backport.

Mandy



From peter.levart at gmail.com  Tue Mar 24 15:46:35 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 24 Mar 2015 16:46:35 +0100
Subject: RFR: JDK-8068721 - RMI-IIOP communication fails when
	ConcurrentHashMap is passed to remote method
In-Reply-To: <551084E3.6050702@oracle.com>
References: <551084E3.6050702@oracle.com>
Message-ID: <551186DB.1050305@gmail.com>

On 03/23/2015 10:25 PM, Mark Sheppard wrote:
> Hi
>  please oblige and review the following fix
>
> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev/
> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev/

Hi Mark,

Can an instance of ObjectStreamHook (ObjectOutputStream) be invoked from 
multiple threads concurrently? I don't see any synchronization elsewhere 
in ObjectStreamHook or ObjectOutputStream. Perhaps the synchronization 
in putFields()/writeFields() is not needed.

Also, in ObjecyOutputStream, writeFields() looks like this:

     public void writeFields() throws IOException {
         if (curPut == null) {
             throw new NotActiveException("no current PutField object");
         }
         bout.setBlockDataMode(false);
         curPut.writeFields();
         bout.setBlockDataMode(true);
     }


...meaning that NotActiveException is thrown in case user calls this 
method before invoking putFields() which initializes the PutField 
object. Should ObjectStreamHook behave the same?

Regards, Peter

>
>
> which addresses the issue in
> https://bugs.openjdk.java.net/browse/JDK-8068721
>
> This relates to RMI-IIOP and the interplay between custom marshalling 
> of ValueTypes and
> the corresponding serialization of a Java class, in this case 
> ConcurrentHashMap.
>
> ConcurrentHashMap changed its structure in jdk8 from that used in jdk7.
> This resulted in modification to the readObject and writeObject methods,
> and in particular, former serial fields were removed, resulting in
> writeObject using PutField and readObject using defaultReadObject.
> The writeObject invokes the putFields method of an ObjectOutputStream 
> multiple times, and assumes
> that it will receive the same PutField object instance for each 
> invocation. The spec
> doesn't endorse this behaviour - but that's what the implementation of 
> ObjectOutputStream
> provides. However in the case of RMI-IIOP, the OutputStreamHook, a 
> subclass of ObjectOutputStream, returns a new instance for each
> putFields invocation. Thus, the ConcurrentHashMap writeObject results 
> in improper serialization in the context
> of RMI-IIOP.
> In the unmarshalling flow of ConcurrentHashMap, the readObject now 
> uses defaultReadObject rather than GetField
> In this call flow the IIOPInputStream attempts to ignore any primitive 
> field, in the serialized data, that doesn't
> correspond with a reflective field of the object. However, it leaves 
> the primitive in the stream.
> Thus, in the case of ConcurrentHashMap, which has serialized two 
> integers and
> an array of Segments (subclass of ReentrantLock), this results in 
> erroneous
> deserialization, with a misinterpretation of a value tag in the stream 
> as an array length
> and an attempt to allocate a very large array ensues, with an 
> exception being thrown.
>
> The OutputStreamHook now returns the same instance of PutField 
> allocated for each separate call of putFields method.
> This highlights a need to tighten up and disambiguate the 
> OutputObjectStream spec for putFields.
>
> IIOPInputStream now removes the primitive values from the stream.
>
> regards
> Mark



From chris.hegarty at oracle.com  Tue Mar 24 16:07:58 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 24 Mar 2015 16:07:58 +0000
Subject: RFR [9] 8071472: Add field setter API for setting final fields in
	readObject
In-Reply-To: <55114A13.9010509@oracle.com>
References: <5510351D.1070500@oracle.com> <55114A13.9010509@oracle.com>
Message-ID: <8A941AAA-C3A0-48BA-9A19-0FD1B9B52E97@oracle.com>

Thanks for the feedback Alan.

On 24 Mar 2015, at 11:27, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 23/03/2015 15:45, Chris Hegarty wrote:
>> Here is an updated version of the FieldSetter API, with all comments to date incorporated.
>> 
>> 
>> http://cr.openjdk.java.net/~chegar/8071472/02/specdiff/overview-summary.html 
>> 
>> Final spec comments welcome, after which I intend to submit a CCC request.
> 
> In fieldSetter() then a small typo "associate with current object" => missing "the?.

Fixed.

> Also in fieldSetter() then the first sentence might be clearer if you split it into two with the second sentence starting as "The FieldSetter gives write access ...?.

Changed.

> In FieldSetter then the first sentence might read a bit better if you change "including final" to "including final fields".

Changed.

> A suggestion for the second sentence is to change is to: "A thread executing readObject gets the FieldSetter by invoking the fieldSetter() method. The FieldSetter can be used to set any instance field of the object being deserialized?.

Accepted, and changed. With the addition that it is limited to fields declared by the class where the readObject is.

> In the third sentence then it might read a bit better if you drop the comma before "where applicable?.

Changed.

> I wonder if it might make sense to just drop the paragraph that lists the conditions for which ISE and IAE are thrown as this is repeated in each of the set methods.

I did flip-flop on this a few times. It is superfluous, and now removed.

> Otherwise it looks good to me.

Thanks,

Updated:
  http://cr.openjdk.java.net/~chegar/8071472/03/specdiff/

-Chris.

> -Alan.


From jason_mehrens at hotmail.com  Tue Mar 24 17:01:47 2015
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Tue, 24 Mar 2015 12:01:47 -0500
Subject: RFR: 8075810: LogManager.readConfiguration may throw
	undocumented IllegalArgumentException
In-Reply-To: <55117D87.9040708@oracle.com>
References: <551177D7.5060203@oracle.com>,
	<938960BA-2827-417B-87AE-A1994A6B2AD4@oracle.com>,
	<55117D87.9040708@oracle.com>
Message-ID: <BLU175-W3CA9B09E1C8C11B7B6F2E830A0@phx.gbl>

Hi Daniel,
 
Looks good.  The only other alternative would be to use java.io.CharConversionException over IOException.  We could even consider dropping the cause because the subclass of I/O exception would convey the same meaning.


Minor formatting issues with a missing space after the catch keyword and missing a tab ahead of 'props.load'
 
Jason
 

----------------------------------------
> Date: Tue, 24 Mar 2015 16:06:47 +0100
> From: daniel.fuchs at oracle.com
> To: lance.andersen at oracle.com
> Subject: Re: RFR: 8075810: LogManager.readConfiguration may throw undocumented IllegalArgumentException
> CC: core-libs-dev at openjdk.java.net
>
> Hi Lance,
>
> Thanks for the review!
>
> On 24/03/15 16:01, Lance Andersen wrote:
>> Hi Daniel,
>>
>> This looks OK but I might suggest clarifying that the cause could be set
>> in the javadoc. Now that being said, I am not sure how consistent we
>> are across the JDK or just make the assumption people will check the
>> cause if they desire.
>
> Hmmm. I have the feeling that the best place for that would be i the
> release notes - rather than in the API doc (which reminds me I should
> plan to add some release note text to the issue).
>
>> As far as backporting, unless it really needed, I would probably would
>> not as a change such as this typically should be done as part of an
>> errata/MR (due to change of behavior and it is not that big of an issue).
>
> Right, my thinking too. Thanks for sharing your opinion!
>
> best regards,
>
> -- daniel
>
>>
>> Best
>> Lance
>> On Mar 24, 2015, at 10:42 AM, Daniel Fuchs <daniel.fuchs at oracle.com
>> <mailto:daniel.fuchs at oracle.com>> wrote:
>>
>>> Hi,
>>>
>>> Please find below a fix for
>>>
>>> 8075810: LogManager.readConfiguration may throw
>>> undocumented IllegalArgumentException
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8075810
>>>
>>> The proposed fix is to catch the IllegalArgumentException and
>>> wrap it in an IOException, since LogManager.readConfiguration
>>> is specified to throw IOException "if there are problems reading
>>> from the stream."
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8075810/webrev.00/
>>>
>>> Initial discussion around the issue can be seen here:
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032348.html
>>>
>>> Question for reviewers: I will log a CCC for this - but I am wondering
>>> whether I should plan to backport the fix to earlier release?
>>>
>>>
>>> best regards,
>>>
>>> -- daniel
>>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen|
>> Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>
>>
>>
> 		 	   		  

From Roger.Riggs at Oracle.com  Tue Mar 24 17:32:59 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 24 Mar 2015 13:32:59 -0400
Subject: JEP 102 Process Review
In-Reply-To: <52DBF819-66D8-4662-8176-526CA3987876@oracle.com>
References: <52DBF819-66D8-4662-8176-526CA3987876@oracle.com>
Message-ID: <55119FCB.5070609@Oracle.com>

Hi Chris,

Thanks for the review and comments.

On 3/24/2015 10:42 AM, Chris Hegarty wrote:
> Roger,
>
> I think the API is looking much better now ( just a few comments below on small specific issues ), so I?ve taken a pass over the implementation changes in the sandbox. Here are some comments:
>
> 1) Some operations on ProcessHandle require RuntimePermission
>      "manageProcess", but I don't see this specified in
>      java.lang.RuntimePermission ( there is a table of target runtime
>      permission names ). I think you just need to add it.
Yes will add
>
> 2) Can ProcessImpl.waitForProcessExit and its native counterpart be
>      removed? ( since its function is now performed through ProcessHandleImpl )
I'll look at that again; the two behaviors:
1) waiting for and reaping the exit value used by Process passes a 
pid/windows handle is one case,
2) waiting for a pid and not touching the exit value passing a pid is 
the other used by ProcessHandle.
It currently passes a flag argument but may be better as two different 
native methods,
considering that Process no longer extends ProcessHandle.
>
> 3) "process reaper?, maybe
>      ?Process-Reaper-? + monotonically increasing ID ( similar to
>      ForkJoin worker threads, or other ). But I do accept that this
>      is the existing name for the reaper threads.
Makes sense;  most thread names use mixed case;
I notice many thread names use spaces in the names instead of '-'s.
>
> 4) Should Info.toString() print something if all fields are null,
>      or -1.
ok, but  localization of any words would be an issue.
I'd propose to put '[]' brackets around the whole string so it will 
empty '[]' if none.
>
> 5) Could the fields for Info be private final, and use a separate
>      private holder for retrieving the information from native?
>      Seems desirable for them to be final.
The implementation class is package private and only exposes the Info 
interface.
What is the concern?  adding another class doesn't seem worth the overhead
or complexity.
>
> 6) Process has s number of @implXXX tags, they typically appear
>      before the @return in usage I?ve seen in the JDK.
ok
>
> 7) Should ProcessHandleImpl.toString include Info, and/or other
>      information about the handle?
The toString is just the PID, retrieving the rest of the info is 
relatively slow,
involving a native call and creating objects.  I think simple is best.

>
> Subjective/Minor:
>
> 1) There are number of commented out fprintfs in native code
>      that should be removed.
Yes, still cleaning the sandbox
>
> 2) You may need to take a pass over the copyright year range.
>      I understand that some of these files were created in 2014, but
>      I suspect that they should all at least include 2015.
ok
>
> 3) OnExitTest & InfoTest include the ?Classpath? exception, when
>      they should not.
ok
> 4) There is some duplication of javadoc in implementation
>      that could be removed, e.g:
>         /**
>          * Returns the process ID as a decimal String.
>          * @return the process ID as a decimal String
>          */
>
>      My preference is to not repeat the public API doc in
>      implementation classes, but I accept that this is sometimes
>      done for in-place readability.
ok, will cleanup the comments
> 5) There are number of lines that are greater than 80
>      characters. These can be difficult for future maintenance
>      and reviews ( webrev side-by-side diffs ).
Good point, I'll wrap them.
>
> I need to spend a little more time on the native code, but the tests pass so that is a good start!
Thanks, Roger



From vladimir.kozlov at oracle.com  Tue Mar 24 18:07:10 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 24 Mar 2015 11:07:10 -0700
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <55111D21.1020502@redhat.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>	<550A90CE.9080901@redhat.com>
	<550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com>
	<550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com>
	<550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com>
	<550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com>
	<55105C0A.8070305@redhat.com> <55108130.2010207@oracle.com>
	<55111D21.1020502@redhat.com>
Message-ID: <5511A7CE.30006@oracle.com>

Got it. I missed that you changed code in unsafe.cpp.
Let me prepare closed changes and get it reviewed before we can push this.

Thanks,
Vladimir

On 3/24/15 1:15 AM, Andrew Haley wrote:
> On 23/03/15 21:10, Vladimir Kozlov wrote:
>> Hotspot make files changes?
>
> There's no need: I think we came to the conclusion that we wouldn't
> define BIG_ENDIAN.
>
> Andrew.
>


From huizhe.wang at oracle.com  Tue Mar 24 18:18:31 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 24 Mar 2015 11:18:31 -0700
Subject: JDK 9 RFR of JDK-8075692: jaxp/test/Makefile references (has
	been removed) win32 directory in jtreg
In-Reply-To: <5510F25A.4050406@oracle.com>
References: <5510F25A.4050406@oracle.com>
Message-ID: <5511AA77.7000305@oracle.com>

Hi Amy,

Does this in any way affect how the tests are run in JPRT?

Thanks,
Joe

On 3/23/2015 10:12 PM, Amy Lu wrote:
> File structure has changed in the new jtreg distribution (4.1/b11), 
> there are no platform specific bin directories any more.
> This fix is for updating jaxp/test/Makefile accordingly.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8075692
> webrev: http://cr.openjdk.java.net/~amlu/8075692/webrev.00/
>
> I also need a sponsor for this fix.
>
> Thanks,
> Amy



From chris.hegarty at oracle.com  Tue Mar 24 18:26:16 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 24 Mar 2015 18:26:16 +0000
Subject: JEP 102 Process Review
In-Reply-To: <55119FCB.5070609@Oracle.com>
References: <52DBF819-66D8-4662-8176-526CA3987876@oracle.com>
	<55119FCB.5070609@Oracle.com>
Message-ID: <EAD7046E-E2E6-4DF2-BC77-DF67D15375F0@oracle.com>

On 24 Mar 2015, at 17:32, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
...
>> 2) Can ProcessImpl.waitForProcessExit and its native counterpart be
>>     removed? ( since its function is now performed through ProcessHandleImpl )
> I'll look at that again; the two behaviors:
> 1) waiting for and reaping the exit value used by Process passes a pid/windows handle is one case,
> 2) waiting for a pid and not touching the exit value passing a pid is the other used by ProcessHandle.
> It currently passes a flag argument but may be better as two different native methods,
> considering that Process no longer extends ProcessHandle.

Oh, I wasn?t able to find an use of ProcessImpl.waitForProcessExit, so I thought it could be removed. Not necessary, if it is being used.

>> ...
>> 5) Could the fields for Info be private final, and use a separate
>>     private holder for retrieving the information from native?
>>     Seems desirable for them to be final.
> The implementation class is package private and only exposes the Info interface.
> What is the concern?  adding another class doesn't seem worth the overhead
> or complexity.

No major concern. It just appeared that Info could be immutable. An additional private ?holder? class could be used.

-Chris.

From brian.burkhalter at oracle.com  Tue Mar 24 19:20:23 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 24 Mar 2015 12:20:23 -0700
Subject: [9] RFR of 8075156: (prefs) remove() should disallow the use of the
	null control character '\u0000' as key
Message-ID: <6AECFBD9-492F-4EA4-B126-478F1B19D5AE@oracle.com>

Please review at your convenience.

Issue:	https://bugs.openjdk.java.net/browse/JDK-8075156
Patch:	http://cr.openjdk.java.net/~bpb/8075156/webrev.00/

This is a sequel to the resolved issue https://bugs.openjdk.java.net/browse/JDK-8068373, (prefs) FileSystemPreferences writes \0 to XML storage, causing loss of all preferences, wherein the code point U+0000, the null control character, was made illegal to use as a key in the generic Unix file system-based Preferences.

The issue at hand extends disallowing U+0000 as a key in the put() method on Mac OS X and Windows, and also disallows this use to the remove() methods on these platforms and in the generic Unix file system-based Preferences.

Use of U+0000 in the corresponding get() method has not been disallowed as this method returns a default value. If it would be preferable that the behavior of get() with respect to the key U+0000 were the same as for put() and remove() then this patch may be updated to that effect.

Also, probably the constant CODE_POINT_U0000 could be moved up to a package-private constant in AbstractPreferences.

In any case, a CCC request will be filed, either for the remove() change alone, or for both remove() and get(), as the review comments shall dictate.

Thanks,

Brian

From martinrb at google.com  Tue Mar 24 19:25:20 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 24 Mar 2015 12:25:20 -0700
Subject: JEP 102 Process Review
In-Reply-To: <52DBF819-66D8-4662-8176-526CA3987876@oracle.com>
References: <52DBF819-66D8-4662-8176-526CA3987876@oracle.com>
Message-ID: <CA+kOe094X1YU-AzGo57pqjCVw4CDpMGjEdCrG4V8893q3y-bUQ@mail.gmail.com>

On Tue, Mar 24, 2015 at 7:42 AM, Chris Hegarty <chris.hegarty at oracle.com>
wrote:

>
> 3) "process reaper?, maybe
>     ?Process-Reaper-? + monotonically increasing ID ( similar to
>     ForkJoin worker threads, or other ). But I do accept that this
>     is the existing name for the reaper threads.
>

Nothing interesting is supposed to be happening in one of these process
reaper threads  ... ideally they wouldn't exist at all ..., so giving them
a more identifiable name shouldn't help - just add overhead?


From mikhail.cherkasov at oracle.com  Tue Mar 24 20:14:54 2015
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Tue, 24 Mar 2015 23:14:54 +0300
Subject: [8] RFR of 8066985: Java Webstart downloading packed files can
	result in Timezone set to UTC
In-Reply-To: <550C36FD.701@oracle.com>
References: <550976B9.6030503@oracle.com> <5509F73C.6000306@oracle.com>
	<550AD4C9.9030905@oracle.com> <550AEF48.4070904@gmail.com>
	<550AF969.7070706@gmail.com> <550C36FD.701@oracle.com>
Message-ID: <5511C5BE.2010809@oracle.com>

Hi there,

There's a new webrev: 
http://cr.openjdk.java.net/~mcherkas/8066985/webrev.02/

I reduced the a thread number in the test, because with big count of 
threads I got OOM on JPRT.
And extract common part form PackerImpl and UnpackerImpl to Utils.

Thanks,
Mikhail.


On 3/20/2015 6:04 PM, mikhail cherkasov wrote:
>
> On 3/19/2015 7:29 PM, Peter Levart wrote:
>> On 03/19/2015 04:46 PM, Peter Levart wrote:
>>> On 03/19/2015 02:53 PM, Kumar Srinivasan wrote:
>>>> Mikhail,
>>>>
>>>> You can move the common utilitieschangeDefaultTimeZoneToUtc and
>>>> restoreDefaultTimeZoneto Utils.java.
>>>>
>>>> Also I am not sure how effective the test is ?  does it catch the 
>>>> issue ?
>>>> if you don't have the fix in PackerImpl and UnpackerImpl ?
>>>>
>>>> Otherwise it looks good, and I can sponsor this patch for you.
>>>>
>>>> Kumar
>>>
>>> Hi Mikhail,
>>>
>>> Is this code part of some utility so that it is executed exclusively 
>>> in it's own JVM, or can it also be executed by some public API or 
>>> internal JVM thread? It appears to be the later (used by 
>>> java.util.jar.Pack200 public API), but haven't checked.
>>>
>>> In case of the later, I think it is very strange that the code 
>>> changes global JVM timezone, albeit just temporarily. This could 
>>> affect other code that needs default TZ and executes concurrently.
>>>
>>> Even in case of the former, if the PackerImpl.pack can be executed 
>>> by multiple concurrent threads and if UnpackerImpl.unpack can be 
>>> executed by multiple concurrent threads, what guarantees that some 
>>> PackerImpl.pack thread is not executed concurrently with some 
>>> UnpackerImpl.unpack thread? You only track each method separately.
> Agree, I'll move changeDefaultTimeZoneToUtc and restoreDefaultTimeZone 
> to Util class, so TZ changes will be managed in one place  for both 
> PackerImpl and UnpackerImpl classes.
>
> NonPack200 threads that reads/writes DTZ can collide with Pack200, but 
> there's other bug that should fix this: 
> https://bugs.openjdk.java.net/browse/JDK-8073187
>
> My fix is only for jdk8 and 7, and it focused on making 
> packer/unpacker safe for concurrent use,  because now applets and JNLP 
> uses packer/unpacker concurrently and this can
> lead to DTZ changing to UTC.
>
>>>
>>>
>>> Regards, Peter
>>
>> I guess this default TZ manipulation is needed because 
>> JarOutputStream/JarInputStream don't provide constructors that would 
>> take a TZ object, but always use default TZ, right?
>>
>> The cleanest way would be to add such constructors, but if this is 
>> too much for 8u, then perhaps some internal ThreadLocal<TZ> could be 
>> exposed to both PackerImpl/UnpackerImpl and Jar[Zip]Input[Output] 
>> stream internals. It think the use of default TZ in Jar/Zip/Streams 
>> is very localized. It is needed to convert local time (specified as 
>> DOS time) to and from epoch-based time exposed in ZipEntry. The code 
>> is located in package-private class java.util.zip.ZipUtils in methods 
>> dosToJavaTime /javaToDosTime (or equivalent extendedDosToJavaTime / 
>> javaToExtendedDosTime in JDK9).
> all solutions that you described require introducing a new API and 
> this can not be done for jdk7 and 8, so that's why JDK-8073187 was 
> created.
> The main purpose of this fix is to make packed jars delivery save for 
> applets/jnlp application.
>
>>
>> Another way would be to provide a general thread-local default TZ 
>> override in TimeZone itself. Something like the following:
>>
>> ===================================================================
>> --- jdk/src/share/classes/java/util/TimeZone.java
>> +++ jdk/src/share/classes/java/util/TimeZone.java
>> @@ -630,8 +630,11 @@
>>       * method doesn't create a clone.
>>       */
>>      static TimeZone getDefaultRef() {
>> -        TimeZone defaultZone = defaultTimeZone;
>> +        TimeZone defaultZone = threadLocalTimeZone.get();
>>          if (defaultZone == null) {
>> +            defaultZone = defaultTimeZone;
>> +        }
>> +        if (defaultZone == null) {
>>              // Need to initialize the default time zone.
>>              defaultZone = setDefaultZone();
>>              assert defaultZone != null;
>> @@ -713,6 +716,20 @@
>>          defaultTimeZone = zone;
>>      }
>>
>> +    public void withThreadDefaultDo(Runnable runnable) {
>> +        TimeZone prevZone = threadLocalTimeZone.get();
>> +        threadLocalTimeZone.set(this);
>> +        try {
>> +            runnable.run();
>> +        } finally {
>> +            if (prevZone == null) {
>> +                threadLocalTimeZone.remove();
>> +            } else {
>> +                threadLocalTimeZone.set(prevZone);
>> +            }
>> +        }
>> +    }
>> +
>>      /**
>>       * Returns true if this zone has the same rule and offset as 
>> another zone.
>>       * That is, if this zone differs only in ID, if at all.  Returns 
>> false
>> @@ -760,6 +777,8 @@
>>       */
>>      private String           ID;
>>      private static volatile TimeZone defaultTimeZone;
>> +    private static final ThreadLocal<TimeZone> threadLocalTimeZone =
>> +        new ThreadLocal<>();
>>
>>      static final String         GMT_ID        = "GMT";
>>      private static final int    GMT_ID_LENGTH = 3;
>>
>>
>> Regards, Peter
>>
>>>
>>>>
>>>>
>>>> On 3/18/2015 3:07 PM, Kumar Srinivasan wrote:
>>>>>
>>>>> Hello Mikhail,
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066985
>>>>>>
>>>>>> The problem is that packer/unpacker changes global state( default 
>>>>>> time zone ) without proper synchronization:
>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/com/sun/java/util/jar/pack/PackerImpl.java#l85 
>>>>>>
>>>>>>
>>>>>> however javadoc says that it's save to use it in concurrent way 
>>>>>> if each thread has it's own packer/unpacker instance:
>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/java/util/jar/Pack200.java#l149 
>>>>>>
>>>>>>
>>>>>> The fix is:
>>>>>> 1. first packer/unpacker saves default time zone
>>>>>> 2. the last set it back.
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.00/
>>>>>
>>>>> The above link is wrong!, it takes me to webrev for 8073187,
>>>>> which has only the PackerImpl changes.
>>>>>
>>>>> I am guessing the link should be:
>>>>> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.00/
>>>>>
>>>>> Kumar
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Mikhail.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From martinrb at google.com  Tue Mar 24 22:32:13 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 24 Mar 2015 15:32:13 -0700
Subject: RFR: JDK-8068721 - RMI-IIOP communication fails when
	ConcurrentHashMap is passed to remote method
In-Reply-To: <C6606626-61AA-48A4-A06E-5568EF37E538@oracle.com>
References: <551084E3.6050702@oracle.com>
	<CA+kOe09S6o8xx8MufAHpO2e_NbhqgHHvP+Jbuwy41Y4yLqOoCw@mail.gmail.com>
	<C6606626-61AA-48A4-A06E-5568EF37E538@oracle.com>
Message-ID: <CA+kOe0849Akkxnh2em9xNstaaPxGkxU==MNnsErVL8GTEvMxcA@mail.gmail.com>

jsr166 CVS now contains this small improvement (I verified the emitted
bytes are unchanged):

--- src/main/java/util/concurrent/ConcurrentHashMap.java 23 Mar 2015
18:48:19 -0000 1.269
+++ src/main/java/util/concurrent/ConcurrentHashMap.java 24 Mar 2015
22:28:58 -0000
@@ -1373,9 +1373,10 @@
             new Segment<?,?>[DEFAULT_CONCURRENCY_LEVEL];
         for (int i = 0; i < segments.length; ++i)
             segments[i] = new Segment<K,V>(LOAD_FACTOR);
-        s.putFields().put("segments", segments);
-        s.putFields().put("segmentShift", segmentShift);
-        s.putFields().put("segmentMask", segmentMask);
+        java.io.ObjectOutputStream.PutField streamFields = s.putFields();
+        streamFields.put("segments", segments);
+        streamFields.put("segmentShift", segmentShift);
+        streamFields.put("segmentMask", segmentMask);
         s.writeFields();

         Node<K,V>[] t;


On Tue, Mar 24, 2015 at 2:38 AM, Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> Martin,
>
> On 23 Mar 2015, at 22:15, Martin Buchholz <martinrb at google.com> wrote:
>
> > Let us know if the serialization code of the collection classes can be
> > improved.
>
> I think there are a few minor cleanups that would be beneficial in CHM:
>
>  1) Add @serialField so that the serializable stream fields show up in the
>      javadoc ( serial form ), since they are still part of the serial
> form, even
>      though not used in the implementation. This is just documenting
>      existing behaviour/form.
>
>  2) Mark correctly identified a small hole in the putFields() spec, which
>      should be fixed. A minor, benign, change in CHM writeObject
>      can avoid this ( spec ambiguity ).
>
> Please consider the following change:
>
> diff --git
> a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
> b/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
> ---
> a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
> +++
> b/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
> @@ -35,6 +35,7 @@
>
>  package java.util.concurrent;
>
> +import java.io.ObjectOutputStream;
>  import java.io.ObjectStreamField;
>  import java.io.Serializable;
>  import java.lang.reflect.ParameterizedType;
> @@ -599,7 +600,12 @@
>      /** Number of CPUS, to place bounds on some sizings */
>      static final int NCPU = Runtime.getRuntime().availableProcessors();
>
> -    /** For serialization compatibility. */
> +    /**
> +     * For serialization compatibility.
> +     * @serialField segments Segment[]
> +     * @serialField segmentMask int
> +     * @serialField segmentShift int
> +     */
>      private static final ObjectStreamField[] serialPersistentFields = {
>          new ObjectStreamField("segments", Segment[].class),
>          new ObjectStreamField("segmentMask", Integer.TYPE),
> @@ -1400,9 +1406,10 @@
>              new Segment<?,?>[DEFAULT_CONCURRENCY_LEVEL];
>          for (int i = 0; i < segments.length; ++i)
>              segments[i] = new Segment<K,V>(LOAD_FACTOR);
> -        s.putFields().put("segments", segments);
> -        s.putFields().put("segmentShift", segmentShift);
> -        s.putFields().put("segmentMask", segmentMask);
> +        ObjectOutputStream.PutField streamFields = s.putFields();
> +        streamFields.put("segments", segments);
> +        streamFields.put("segmentShift", segmentShift);
> +        streamFields.put("segmentMask", segmentMask);
>          s.writeFields();
>
>          Node<K,V>[] t;
>
> -Chris.
>
> > On Mon, Mar 23, 2015 at 2:25 PM, Mark Sheppard <mark.sheppard at oracle.com
> >
> > wrote:
> >
> >> Hi
> >> please oblige and review the following fix
> >>
> >> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev/
> >> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev/
> >>
> >>
> >> which addresses the issue in
> >> https://bugs.openjdk.java.net/browse/JDK-8068721
> >>
> >> This relates to RMI-IIOP and the interplay between custom marshalling of
> >> ValueTypes and
> >> the corresponding serialization of a Java class, in this case
> >> ConcurrentHashMap.
> >>
> >> ConcurrentHashMap changed its structure in jdk8 from that used in jdk7.
> >> This resulted in modification to the readObject and writeObject methods,
> >> and in particular, former serial fields were removed, resulting in
> >> writeObject using PutField and readObject using defaultReadObject.
> >> The writeObject invokes the putFields method of an ObjectOutputStream
> >> multiple times, and assumes
> >> that it will receive the same PutField object instance for each
> >> invocation. The spec
> >> doesn't endorse this behaviour - but that's what the implementation of
> >> ObjectOutputStream
> >> provides. However in the case of RMI-IIOP, the OutputStreamHook, a
> >> subclass of ObjectOutputStream, returns a new instance for each
> >> putFields invocation. Thus, the ConcurrentHashMap writeObject results in
> >> improper serialization in the context
> >> of RMI-IIOP.
> >> In the unmarshalling flow of ConcurrentHashMap, the readObject now uses
> >> defaultReadObject rather than GetField
> >> In this call flow the IIOPInputStream attempts to ignore any primitive
> >> field, in the serialized data, that doesn't
> >> correspond with a reflective field of the object. However, it leaves the
> >> primitive in the stream.
> >> Thus, in the case of ConcurrentHashMap, which has serialized two
> integers
> >> and
> >> an array of Segments (subclass of ReentrantLock), this results in
> erroneous
> >> deserialization, with a misinterpretation of a value tag in the stream
> as
> >> an array length
> >> and an attempt to allocate a very large array ensues, with an exception
> >> being thrown.
> >>
> >> The OutputStreamHook now returns the same instance of PutField allocated
> >> for each separate call of putFields method.
> >> This highlights a need to tighten up and disambiguate the
> >> OutputObjectStream spec for putFields.
> >>
> >> IIOPInputStream now removes the primitive values from the stream.
> >>
> >> regards
> >> Mark
> >>
>
>


From kumar.x.srinivasan at oracle.com  Tue Mar 24 22:48:43 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 24 Mar 2015 15:48:43 -0700
Subject: [8] RFR of 8066985: Java Webstart downloading packed files can
	result in Timezone set to UTC
In-Reply-To: <5511C5BE.2010809@oracle.com>
References: <550976B9.6030503@oracle.com> <5509F73C.6000306@oracle.com>
	<550AD4C9.9030905@oracle.com> <550AEF48.4070904@gmail.com>
	<550AF969.7070706@gmail.com> <550C36FD.701@oracle.com>
	<5511C5BE.2010809@oracle.com>
Message-ID: <5511E9CB.7050504@oracle.com>

Hi Mikhail,

Nit:
Utils.java:

-            // reset timezone when all the packers have terminated
+            // reset timezone when all the packer/unpacker instances have terminated

DefaultTimeZoneTest.java
What did you change between 01 and 02 revisions ? They appear to be the
same ?

Kumar


On 3/24/2015 1:14 PM, mikhail cherkasov wrote:
> Hi there,
>
> There's a new webrev: 
> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.02/
>
> I reduced the a thread number in the test, because with big count of 
> threads I got OOM on JPRT.
> And extract common part form PackerImpl and UnpackerImpl to Utils.
>
> Thanks,
> Mikhail.
>
>
> On 3/20/2015 6:04 PM, mikhail cherkasov wrote:
>>
>> On 3/19/2015 7:29 PM, Peter Levart wrote:
>>> On 03/19/2015 04:46 PM, Peter Levart wrote:
>>>> On 03/19/2015 02:53 PM, Kumar Srinivasan wrote:
>>>>> Mikhail,
>>>>>
>>>>> You can move the common utilitieschangeDefaultTimeZoneToUtc and
>>>>> restoreDefaultTimeZoneto Utils.java.
>>>>>
>>>>> Also I am not sure how effective the test is ?  does it catch the 
>>>>> issue ?
>>>>> if you don't have the fix in PackerImpl and UnpackerImpl ?
>>>>>
>>>>> Otherwise it looks good, and I can sponsor this patch for you.
>>>>>
>>>>> Kumar
>>>>
>>>> Hi Mikhail,
>>>>
>>>> Is this code part of some utility so that it is executed 
>>>> exclusively in it's own JVM, or can it also be executed by some 
>>>> public API or internal JVM thread? It appears to be the later (used 
>>>> by java.util.jar.Pack200 public API), but haven't checked.
>>>>
>>>> In case of the later, I think it is very strange that the code 
>>>> changes global JVM timezone, albeit just temporarily. This could 
>>>> affect other code that needs default TZ and executes concurrently.
>>>>
>>>> Even in case of the former, if the PackerImpl.pack can be executed 
>>>> by multiple concurrent threads and if UnpackerImpl.unpack can be 
>>>> executed by multiple concurrent threads, what guarantees that some 
>>>> PackerImpl.pack thread is not executed concurrently with some 
>>>> UnpackerImpl.unpack thread? You only track each method separately.
>> Agree, I'll move changeDefaultTimeZoneToUtc and 
>> restoreDefaultTimeZone to Util class, so TZ changes will be managed 
>> in one place  for both PackerImpl and UnpackerImpl classes.
>>
>> NonPack200 threads that reads/writes DTZ can collide with Pack200, 
>> but there's other bug that should fix this: 
>> https://bugs.openjdk.java.net/browse/JDK-8073187
>>
>> My fix is only for jdk8 and 7, and it focused on making 
>> packer/unpacker safe for concurrent use,  because now applets and 
>> JNLP uses packer/unpacker concurrently and this can
>> lead to DTZ changing to UTC.
>>
>>>>
>>>>
>>>> Regards, Peter
>>>
>>> I guess this default TZ manipulation is needed because 
>>> JarOutputStream/JarInputStream don't provide constructors that would 
>>> take a TZ object, but always use default TZ, right?
>>>
>>> The cleanest way would be to add such constructors, but if this is 
>>> too much for 8u, then perhaps some internal ThreadLocal<TZ> could be 
>>> exposed to both PackerImpl/UnpackerImpl and Jar[Zip]Input[Output] 
>>> stream internals. It think the use of default TZ in Jar/Zip/Streams 
>>> is very localized. It is needed to convert local time (specified as 
>>> DOS time) to and from epoch-based time exposed in ZipEntry. The code 
>>> is located in package-private class java.util.zip.ZipUtils in 
>>> methods dosToJavaTime /javaToDosTime (or equivalent 
>>> extendedDosToJavaTime / javaToExtendedDosTime in JDK9).
>> all solutions that you described require introducing a new API and 
>> this can not be done for jdk7 and 8, so that's why JDK-8073187 was 
>> created.
>> The main purpose of this fix is to make packed jars delivery save for 
>> applets/jnlp application.
>>
>>>
>>> Another way would be to provide a general thread-local default TZ 
>>> override in TimeZone itself. Something like the following:
>>>
>>> ===================================================================
>>> --- jdk/src/share/classes/java/util/TimeZone.java
>>> +++ jdk/src/share/classes/java/util/TimeZone.java
>>> @@ -630,8 +630,11 @@
>>>       * method doesn't create a clone.
>>>       */
>>>      static TimeZone getDefaultRef() {
>>> -        TimeZone defaultZone = defaultTimeZone;
>>> +        TimeZone defaultZone = threadLocalTimeZone.get();
>>>          if (defaultZone == null) {
>>> +            defaultZone = defaultTimeZone;
>>> +        }
>>> +        if (defaultZone == null) {
>>>              // Need to initialize the default time zone.
>>>              defaultZone = setDefaultZone();
>>>              assert defaultZone != null;
>>> @@ -713,6 +716,20 @@
>>>          defaultTimeZone = zone;
>>>      }
>>>
>>> +    public void withThreadDefaultDo(Runnable runnable) {
>>> +        TimeZone prevZone = threadLocalTimeZone.get();
>>> +        threadLocalTimeZone.set(this);
>>> +        try {
>>> +            runnable.run();
>>> +        } finally {
>>> +            if (prevZone == null) {
>>> +                threadLocalTimeZone.remove();
>>> +            } else {
>>> +                threadLocalTimeZone.set(prevZone);
>>> +            }
>>> +        }
>>> +    }
>>> +
>>>      /**
>>>       * Returns true if this zone has the same rule and offset as 
>>> another zone.
>>>       * That is, if this zone differs only in ID, if at all.  
>>> Returns false
>>> @@ -760,6 +777,8 @@
>>>       */
>>>      private String           ID;
>>>      private static volatile TimeZone defaultTimeZone;
>>> +    private static final ThreadLocal<TimeZone> threadLocalTimeZone =
>>> +        new ThreadLocal<>();
>>>
>>>      static final String         GMT_ID        = "GMT";
>>>      private static final int    GMT_ID_LENGTH = 3;
>>>
>>>
>>> Regards, Peter
>>>
>>>>
>>>>>
>>>>>
>>>>> On 3/18/2015 3:07 PM, Kumar Srinivasan wrote:
>>>>>>
>>>>>> Hello Mikhail,
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066985
>>>>>>>
>>>>>>> The problem is that packer/unpacker changes global state( 
>>>>>>> default time zone ) without proper synchronization:
>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/com/sun/java/util/jar/pack/PackerImpl.java#l85 
>>>>>>>
>>>>>>>
>>>>>>> however javadoc says that it's save to use it in concurrent way 
>>>>>>> if each thread has it's own packer/unpacker instance:
>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/java/util/jar/Pack200.java#l149 
>>>>>>>
>>>>>>>
>>>>>>> The fix is:
>>>>>>> 1. first packer/unpacker saves default time zone
>>>>>>> 2. the last set it back.
>>>>>>>
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.00/
>>>>>>
>>>>>> The above link is wrong!, it takes me to webrev for 8073187,
>>>>>> which has only the PackerImpl changes.
>>>>>>
>>>>>> I am guessing the link should be:
>>>>>> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.00/
>>>>>>
>>>>>> Kumar
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Mikhail.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From martinrb at google.com  Tue Mar 24 23:17:49 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 24 Mar 2015 16:17:49 -0700
Subject: RFR: JDK-8075774 Small readability and performance improvements
	for zipfs
In-Reply-To: <551116FF.8040107@oracle.com>
References: <CA+kOe09-5y6rP_b75JVzfY5SYckdsxMJ+g60-RC2QDQFCAqPrQ@mail.gmail.com>
	<551116FF.8040107@oracle.com>
Message-ID: <CA+kOe0_EQufOzwEJDB7EOVRLfg2YcvYvKXEYwhVg8pScbNQd=w@mail.gmail.com>

On Tue, Mar 24, 2015 at 12:49 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
>>  Looks okay but it makes for mix of styles (LL vs. getSig for example).


Yeah, C macros and Java constants are UPPER_CASE.  LL should really be
renamed to something more Javaesque.

I changed pkSigAt to not use increment, making the parallelism more obvious
to human and machine alike.

    private static boolean pkSigAt(byte[] b, int n, int b1, int b2) {
        return b[n] == 'P' & b[n + 1] == 'K' & b[n + 2] == b1 & b[n + 3] ==
b2;
    }


From vladimir.kozlov at oracle.com  Tue Mar 24 23:40:26 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 24 Mar 2015 16:40:26 -0700
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <55111D21.1020502@redhat.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>	<550A90CE.9080901@redhat.com>
	<550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com>
	<550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com>
	<550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com>
	<550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com>
	<55105C0A.8070305@redhat.com> <55108130.2010207@oracle.com>
	<55111D21.1020502@redhat.com>
Message-ID: <5511F5EA.6010102@oracle.com>

Andrew,

The test failed when run it in JPRT with 32-bit fastdebug *Client* VM (-client) on linux-x86:

java.lang.RuntimeException
	at MyByteBuffer.ck(HeapByteBufferTest.java:201)
	at MyByteBuffer.getLong(HeapByteBufferTest.java:211)
	at HeapByteBufferTest.step(HeapByteBufferTest.java:311)
	at HeapByteBufferTest.run(HeapByteBufferTest.java:347)
	at HeapByteBufferTest.main(HeapByteBufferTest.java:362)

Could be intrinsic in C1 does not work correctly? Please, look.

Thanks,
Vladimir

On 3/24/15 1:15 AM, Andrew Haley wrote:
> On 23/03/15 21:10, Vladimir Kozlov wrote:
>> Hotspot make files changes?
>
> There's no need: I think we came to the conclusion that we wouldn't
> define BIG_ENDIAN.
>
> Andrew.
>


From martinrb at google.com  Wed Mar 25 00:05:37 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 24 Mar 2015 17:05:37 -0700
Subject: RFR: JDK-8068721 - RMI-IIOP communication fails when
	ConcurrentHashMap is passed to remote method
In-Reply-To: <C6606626-61AA-48A4-A06E-5568EF37E538@oracle.com>
References: <551084E3.6050702@oracle.com>
	<CA+kOe09S6o8xx8MufAHpO2e_NbhqgHHvP+Jbuwy41Y4yLqOoCw@mail.gmail.com>
	<C6606626-61AA-48A4-A06E-5568EF37E538@oracle.com>
Message-ID: <CA+kOe0-xHVj8ZPzcz=01WiV+LG4K2o27DB+-QTcSYzaxzB_rnA@mail.gmail.com>

How about this, which resurrects the jdk7 doc strings for the legacy fields?

--- src/main/java/util/concurrent/ConcurrentHashMap.java 24 Mar 2015
22:30:53 -0000 1.270
+++ src/main/java/util/concurrent/ConcurrentHashMap.java 25 Mar 2015
00:03:43 -0000
@@ -566,7 +566,16 @@
     /** Number of CPUS, to place bounds on some sizings */
     static final int NCPU = Runtime.getRuntime().availableProcessors();

-    /** For serialization compatibility. */
+    /**
+     * Serialized pseudo-fields, provided only for jdk7 compatibility.
+     * @serialField segments Segment[]
+     *   The segments, each of which is a specialized hash table.
+     * @serialField segmentMask int
+     *   Mask value for indexing into segments. The upper bits of a
+     *   key's hash code are used to choose the segment.
+     * @serialField segmentShift int
+     *   Shift value for indexing within segments.
+     */
     private static final ObjectStreamField[] serialPersistentFields = {
         new ObjectStreamField("segments", Segment[].class),
         new ObjectStreamField("segmentMask", Integer.TYPE),


On Tue, Mar 24, 2015 at 2:38 AM, Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> Martin,
>
> On 23 Mar 2015, at 22:15, Martin Buchholz <martinrb at google.com> wrote:
>
> > Let us know if the serialization code of the collection classes can be
> > improved.
>
> I think there are a few minor cleanups that would be beneficial in CHM:
>
>  1) Add @serialField so that the serializable stream fields show up in the
>      javadoc ( serial form ), since they are still part of the serial
> form, even
>      though not used in the implementation. This is just documenting
>      existing behaviour/form.
>
>  2) Mark correctly identified a small hole in the putFields() spec, which
>      should be fixed. A minor, benign, change in CHM writeObject
>      can avoid this ( spec ambiguity ).
>
> Please consider the following change:
>
> diff --git
> a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
> b/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
> ---
> a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
> +++
> b/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
> @@ -35,6 +35,7 @@
>
>  package java.util.concurrent;
>
> +import java.io.ObjectOutputStream;
>  import java.io.ObjectStreamField;
>  import java.io.Serializable;
>  import java.lang.reflect.ParameterizedType;
> @@ -599,7 +600,12 @@
>      /** Number of CPUS, to place bounds on some sizings */
>      static final int NCPU = Runtime.getRuntime().availableProcessors();
>
> -    /** For serialization compatibility. */
> +    /**
> +     * For serialization compatibility.
> +     * @serialField segments Segment[]
> +     * @serialField segmentMask int
> +     * @serialField segmentShift int
> +     */
>      private static final ObjectStreamField[] serialPersistentFields = {
>          new ObjectStreamField("segments", Segment[].class),
>          new ObjectStreamField("segmentMask", Integer.TYPE),
> @@ -1400,9 +1406,10 @@
>              new Segment<?,?>[DEFAULT_CONCURRENCY_LEVEL];
>          for (int i = 0; i < segments.length; ++i)
>              segments[i] = new Segment<K,V>(LOAD_FACTOR);
> -        s.putFields().put("segments", segments);
> -        s.putFields().put("segmentShift", segmentShift);
> -        s.putFields().put("segmentMask", segmentMask);
> +        ObjectOutputStream.PutField streamFields = s.putFields();
> +        streamFields.put("segments", segments);
> +        streamFields.put("segmentShift", segmentShift);
> +        streamFields.put("segmentMask", segmentMask);
>          s.writeFields();
>
>          Node<K,V>[] t;
>
> -Chris.
>
> > On Mon, Mar 23, 2015 at 2:25 PM, Mark Sheppard <mark.sheppard at oracle.com
> >
> > wrote:
> >
> >> Hi
> >> please oblige and review the following fix
> >>
> >> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev/
> >> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev/
> >>
> >>
> >> which addresses the issue in
> >> https://bugs.openjdk.java.net/browse/JDK-8068721
> >>
> >> This relates to RMI-IIOP and the interplay between custom marshalling of
> >> ValueTypes and
> >> the corresponding serialization of a Java class, in this case
> >> ConcurrentHashMap.
> >>
> >> ConcurrentHashMap changed its structure in jdk8 from that used in jdk7.
> >> This resulted in modification to the readObject and writeObject methods,
> >> and in particular, former serial fields were removed, resulting in
> >> writeObject using PutField and readObject using defaultReadObject.
> >> The writeObject invokes the putFields method of an ObjectOutputStream
> >> multiple times, and assumes
> >> that it will receive the same PutField object instance for each
> >> invocation. The spec
> >> doesn't endorse this behaviour - but that's what the implementation of
> >> ObjectOutputStream
> >> provides. However in the case of RMI-IIOP, the OutputStreamHook, a
> >> subclass of ObjectOutputStream, returns a new instance for each
> >> putFields invocation. Thus, the ConcurrentHashMap writeObject results in
> >> improper serialization in the context
> >> of RMI-IIOP.
> >> In the unmarshalling flow of ConcurrentHashMap, the readObject now uses
> >> defaultReadObject rather than GetField
> >> In this call flow the IIOPInputStream attempts to ignore any primitive
> >> field, in the serialized data, that doesn't
> >> correspond with a reflective field of the object. However, it leaves the
> >> primitive in the stream.
> >> Thus, in the case of ConcurrentHashMap, which has serialized two
> integers
> >> and
> >> an array of Segments (subclass of ReentrantLock), this results in
> erroneous
> >> deserialization, with a misinterpretation of a value tag in the stream
> as
> >> an array length
> >> and an attempt to allocate a very large array ensues, with an exception
> >> being thrown.
> >>
> >> The OutputStreamHook now returns the same instance of PutField allocated
> >> for each separate call of putFields method.
> >> This highlights a need to tighten up and disambiguate the
> >> OutputObjectStream spec for putFields.
> >>
> >> IIOPInputStream now removes the primitive values from the stream.
> >>
> >> regards
> >> Mark
> >>
>
>


From amy.lu at oracle.com  Wed Mar 25 01:20:46 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 25 Mar 2015 09:20:46 +0800
Subject: JDK 9 RFR of JDK-8075692: jaxp/test/Makefile references (has
	been removed) win32 directory in jtreg
In-Reply-To: <5511AA77.7000305@oracle.com>
References: <5510F25A.4050406@oracle.com> <5511AA77.7000305@oracle.com>
Message-ID: <55120D6E.7060407@oracle.com>

Hi, Joe

Without this fix, jaxp test run in JPRT will fail because it try to use 
jtreg/win32/bin/jtreg

Thanks,
Amy

On 3/25/15 2:18 AM, huizhe wang wrote:
> Hi Amy,
>
> Does this in any way affect how the tests are run in JPRT?
>
> Thanks,
> Joe
>
> On 3/23/2015 10:12 PM, Amy Lu wrote:
>> File structure has changed in the new jtreg distribution (4.1/b11), 
>> there are no platform specific bin directories any more.
>> This fix is for updating jaxp/test/Makefile accordingly.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8075692
>> webrev: http://cr.openjdk.java.net/~amlu/8075692/webrev.00/
>>
>> I also need a sponsor for this fix.
>>
>> Thanks,
>> Amy
>



From david.holmes at oracle.com  Wed Mar 25 03:57:38 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Mar 2015 13:57:38 +1000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <5511A7CE.30006@oracle.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>	<550A90CE.9080901@redhat.com>	<550AF27F.4050305@oracle.com>
	<550AFA3C.5030002@oracle.com>	<550AFF16.9080600@oracle.com>
	<550B350B.6040602@oracle.com>	<550C460F.1090302@redhat.com>
	<550C989A.5010203@oracle.com>	<550D57B1.602@redhat.com>
	<550D9D02.1020303@oracle.com>	<55105C0A.8070305@redhat.com>
	<55108130.2010207@oracle.com>	<55111D21.1020502@redhat.com>
	<5511A7CE.30006@oracle.com>
Message-ID: <55123232.2090806@oracle.com>

On 25/03/2015 4:07 AM, Vladimir Kozlov wrote:
> Got it. I missed that you changed code in unsafe.cpp.
> Let me prepare closed changes and get it reviewed before we can push this.

Copyright notices need updating too. And the copyright dates on the test 
look like they have been copied from another file - given this is a new 
test.

Thanks,
David

>
> Thanks,
> Vladimir
>
> On 3/24/15 1:15 AM, Andrew Haley wrote:
>> On 23/03/15 21:10, Vladimir Kozlov wrote:
>>> Hotspot make files changes?
>>
>> There's no need: I think we came to the conclusion that we wouldn't
>> define BIG_ENDIAN.
>>
>> Andrew.
>>


From huizhe.wang at oracle.com  Wed Mar 25 04:13:23 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 24 Mar 2015 21:13:23 -0700
Subject: JDK 9 RFR of JDK-8075692: jaxp/test/Makefile references (has
	been removed) win32 directory in jtreg
In-Reply-To: <55120D6E.7060407@oracle.com>
References: <5510F25A.4050406@oracle.com> <5511AA77.7000305@oracle.com>
	<55120D6E.7060407@oracle.com>
Message-ID: <551235E3.5060709@oracle.com>

Ok, I pushed your change.

Thanks,
Joe

On 3/24/2015 6:20 PM, Amy Lu wrote:
> Hi, Joe
>
> Without this fix, jaxp test run in JPRT will fail because it try to 
> use jtreg/win32/bin/jtreg
>
> Thanks,
> Amy
>
> On 3/25/15 2:18 AM, huizhe wang wrote:
>> Hi Amy,
>>
>> Does this in any way affect how the tests are run in JPRT?
>>
>> Thanks,
>> Joe
>>
>> On 3/23/2015 10:12 PM, Amy Lu wrote:
>>> File structure has changed in the new jtreg distribution (4.1/b11), 
>>> there are no platform specific bin directories any more.
>>> This fix is for updating jaxp/test/Makefile accordingly.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8075692
>>> webrev: http://cr.openjdk.java.net/~amlu/8075692/webrev.00/
>>>
>>> I also need a sponsor for this fix.
>>>
>>> Thanks,
>>> Amy
>>
>



From aph at redhat.com  Wed Mar 25 09:13:25 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 25 Mar 2015 09:13:25 +0000
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <5511F5EA.6010102@oracle.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>	<550A90CE.9080901@redhat.com>
	<550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com>
	<550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com>
	<550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com>
	<550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com>
	<55105C0A.8070305@redhat.com> <55108130.2010207@oracle.com>
	<55111D21.1020502@redhat.com> <5511F5EA.6010102@oracle.com>
Message-ID: <55127C35.8000108@redhat.com>

On 24/03/15 23:40, Vladimir Kozlov wrote:

> The test failed when run it in JPRT with 32-bit fastdebug *Client* VM (-client) on linux-x86:
> 
> java.lang.RuntimeException
> 	at MyByteBuffer.ck(HeapByteBufferTest.java:201)
> 	at MyByteBuffer.getLong(HeapByteBufferTest.java:211)
> 	at HeapByteBufferTest.step(HeapByteBufferTest.java:311)
> 	at HeapByteBufferTest.run(HeapByteBufferTest.java:347)
> 	at HeapByteBufferTest.main(HeapByteBufferTest.java:362)
> 
> Could be intrinsic in C1 does not work correctly? Please, look.

I certainly will.  That is odd: there's no reason I can think of why
this might happen, and I know that the test running on a server build
runs C1 code for a while so it has been tested.  I guess it must be a
rare edge case.  Still, I'm quite pleased that the test I wrote
detected the failure.

Do you know if this was running with +UseUnalignedAccesses?

I'm not going to be able to analyse this for a few days.  Expect a
report (and hopefully a fix) next week.

Thanks,
Andrew.


From frank.yuan at oracle.com  Wed Mar 25 09:34:51 2015
From: frank.yuan at oracle.com (Frank Yuan)
Date: Wed, 25 Mar 2015 17:34:51 +0800
Subject: Review request for JDK-8051560: JAXP function astro tests conversion
Message-ID: <033901d066de$f371f8d0$da55ea70$@oracle.com>

Hi, Joe and All

 

We are working on moving internal jaxp functional tests to open jdk repo.

This is the astro suite. Would you please review these test?  Any comment
will be appreciated.

 

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

webrev: http://cr.openjdk.java.net/~fyuan/8051560/webrev.00/

 

AstroTest is the primary test in this suite, it transforms an xml file(which
includes astro data) with several xsl files, sets different filtering
condition by these xsl files and different filtering range, finally compares
the result with golden files. 

And there are 5 permutations of InputSourceFactory and FilterFactory(I uses
template method pattern for the variant FilterFactoryImpls), each
permutation will be applied to above transforming processes.

 

Thanks,

 

Frank



From frank.yuan at oracle.com  Wed Mar 25 09:46:27 2015
From: frank.yuan at oracle.com (Frank Yuan)
Date: Wed, 25 Mar 2015 17:46:27 +0800
Subject: Review request for JDK-8051559: JAXP function dom tests conversion
Message-ID: <035201d066e0$920e69f0$b62b3dd0$@oracle.com>

Hi, Joe and All

 

We are working on moving internal jaxp functional tests to open jdk repo.

This is the dom suite. Would you please review these test?  Any comment will
be appreciated.

 

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

webrev: http://cr.openjdk.java.net/~fyuan/8051559/webrev.00/

 

Thanks,

 

Frank



From mikhail.cherkasov at oracle.com  Wed Mar 25 09:51:11 2015
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Wed, 25 Mar 2015 12:51:11 +0300
Subject: [8] RFR of 8066985: Java Webstart downloading packed files can
	result in Timezone set to UTC
In-Reply-To: <5511E9CB.7050504@oracle.com>
References: <550976B9.6030503@oracle.com> <5509F73C.6000306@oracle.com>
	<550AD4C9.9030905@oracle.com> <550AEF48.4070904@gmail.com>
	<550AF969.7070706@gmail.com> <550C36FD.701@oracle.com>
	<5511C5BE.2010809@oracle.com> <5511E9CB.7050504@oracle.com>
Message-ID: <5512850F.90701@oracle.com>

On 3/25/2015 1:48 AM, Kumar Srinivasan wrote:
> Hi Mikhail,
>
> Nit:
> Utils.java:
> -            // reset timezone when all the packers have terminated
> +            // reset timezone when all the packer/unpacker instances have terminated
fixed: http://cr.openjdk.java.net/~mcherkas/8066985/webrev.03/
>
>
> DefaultTimeZoneTest.java
> What did you change between 01 and 02 revisions ? They appear to be the
> same ?
Please, see revisions 00 and 02. 01 has DefaultTimeZoneTest.java.rej, 02 
is the same but without this extra file.
>
> Kumar
>
>
> On 3/24/2015 1:14 PM, mikhail cherkasov wrote:
>> Hi there,
>>
>> There's a new webrev: 
>> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.02/
>>
>> I reduced the a thread number in the test, because with big count of 
>> threads I got OOM on JPRT.
>> And extract common part form PackerImpl and UnpackerImpl to Utils.
>>
>> Thanks,
>> Mikhail.
>>
>>
>> On 3/20/2015 6:04 PM, mikhail cherkasov wrote:
>>>
>>> On 3/19/2015 7:29 PM, Peter Levart wrote:
>>>> On 03/19/2015 04:46 PM, Peter Levart wrote:
>>>>> On 03/19/2015 02:53 PM, Kumar Srinivasan wrote:
>>>>>> Mikhail,
>>>>>>
>>>>>> You can move the common utilitieschangeDefaultTimeZoneToUtc and
>>>>>> restoreDefaultTimeZoneto Utils.java.
>>>>>>
>>>>>> Also I am not sure how effective the test is ?  does it catch the 
>>>>>> issue ?
>>>>>> if you don't have the fix in PackerImpl and UnpackerImpl ?
>>>>>>
>>>>>> Otherwise it looks good, and I can sponsor this patch for you.
>>>>>>
>>>>>> Kumar
>>>>>
>>>>> Hi Mikhail,
>>>>>
>>>>> Is this code part of some utility so that it is executed 
>>>>> exclusively in it's own JVM, or can it also be executed by some 
>>>>> public API or internal JVM thread? It appears to be the later 
>>>>> (used by java.util.jar.Pack200 public API), but haven't checked.
>>>>>
>>>>> In case of the later, I think it is very strange that the code 
>>>>> changes global JVM timezone, albeit just temporarily. This could 
>>>>> affect other code that needs default TZ and executes concurrently.
>>>>>
>>>>> Even in case of the former, if the PackerImpl.pack can be executed 
>>>>> by multiple concurrent threads and if UnpackerImpl.unpack can be 
>>>>> executed by multiple concurrent threads, what guarantees that some 
>>>>> PackerImpl.pack thread is not executed concurrently with some 
>>>>> UnpackerImpl.unpack thread? You only track each method separately.
>>> Agree, I'll move changeDefaultTimeZoneToUtc and 
>>> restoreDefaultTimeZone to Util class, so TZ changes will be managed 
>>> in one place  for both PackerImpl and UnpackerImpl classes.
>>>
>>> NonPack200 threads that reads/writes DTZ can collide with Pack200, 
>>> but there's other bug that should fix this: 
>>> https://bugs.openjdk.java.net/browse/JDK-8073187
>>>
>>> My fix is only for jdk8 and 7, and it focused on making 
>>> packer/unpacker safe for concurrent use,  because now applets and 
>>> JNLP uses packer/unpacker concurrently and this can
>>> lead to DTZ changing to UTC.
>>>
>>>>>
>>>>>
>>>>> Regards, Peter
>>>>
>>>> I guess this default TZ manipulation is needed because 
>>>> JarOutputStream/JarInputStream don't provide constructors that 
>>>> would take a TZ object, but always use default TZ, right?
>>>>
>>>> The cleanest way would be to add such constructors, but if this is 
>>>> too much for 8u, then perhaps some internal ThreadLocal<TZ> could 
>>>> be exposed to both PackerImpl/UnpackerImpl and 
>>>> Jar[Zip]Input[Output] stream internals. It think the use of default 
>>>> TZ in Jar/Zip/Streams is very localized. It is needed to convert 
>>>> local time (specified as DOS time) to and from epoch-based time 
>>>> exposed in ZipEntry. The code is located in package-private class 
>>>> java.util.zip.ZipUtils in methods dosToJavaTime /javaToDosTime (or 
>>>> equivalent extendedDosToJavaTime / javaToExtendedDosTime in JDK9).
>>> all solutions that you described require introducing a new API and 
>>> this can not be done for jdk7 and 8, so that's why JDK-8073187 was 
>>> created.
>>> The main purpose of this fix is to make packed jars delivery save 
>>> for applets/jnlp application.
>>>
>>>>
>>>> Another way would be to provide a general thread-local default TZ 
>>>> override in TimeZone itself. Something like the following:
>>>>
>>>> ===================================================================
>>>> --- jdk/src/share/classes/java/util/TimeZone.java
>>>> +++ jdk/src/share/classes/java/util/TimeZone.java
>>>> @@ -630,8 +630,11 @@
>>>>       * method doesn't create a clone.
>>>>       */
>>>>      static TimeZone getDefaultRef() {
>>>> -        TimeZone defaultZone = defaultTimeZone;
>>>> +        TimeZone defaultZone = threadLocalTimeZone.get();
>>>>          if (defaultZone == null) {
>>>> +            defaultZone = defaultTimeZone;
>>>> +        }
>>>> +        if (defaultZone == null) {
>>>>              // Need to initialize the default time zone.
>>>>              defaultZone = setDefaultZone();
>>>>              assert defaultZone != null;
>>>> @@ -713,6 +716,20 @@
>>>>          defaultTimeZone = zone;
>>>>      }
>>>>
>>>> +    public void withThreadDefaultDo(Runnable runnable) {
>>>> +        TimeZone prevZone = threadLocalTimeZone.get();
>>>> +        threadLocalTimeZone.set(this);
>>>> +        try {
>>>> +            runnable.run();
>>>> +        } finally {
>>>> +            if (prevZone == null) {
>>>> +                threadLocalTimeZone.remove();
>>>> +            } else {
>>>> +                threadLocalTimeZone.set(prevZone);
>>>> +            }
>>>> +        }
>>>> +    }
>>>> +
>>>>      /**
>>>>       * Returns true if this zone has the same rule and offset as 
>>>> another zone.
>>>>       * That is, if this zone differs only in ID, if at all.  
>>>> Returns false
>>>> @@ -760,6 +777,8 @@
>>>>       */
>>>>      private String           ID;
>>>>      private static volatile TimeZone defaultTimeZone;
>>>> +    private static final ThreadLocal<TimeZone> threadLocalTimeZone =
>>>> +        new ThreadLocal<>();
>>>>
>>>>      static final String         GMT_ID        = "GMT";
>>>>      private static final int    GMT_ID_LENGTH = 3;
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> On 3/18/2015 3:07 PM, Kumar Srinivasan wrote:
>>>>>>>
>>>>>>> Hello Mikhail,
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066985
>>>>>>>>
>>>>>>>> The problem is that packer/unpacker changes global state( 
>>>>>>>> default time zone ) without proper synchronization:
>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/com/sun/java/util/jar/pack/PackerImpl.java#l85 
>>>>>>>>
>>>>>>>>
>>>>>>>> however javadoc says that it's save to use it in concurrent way 
>>>>>>>> if each thread has it's own packer/unpacker instance:
>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/java/util/jar/Pack200.java#l149 
>>>>>>>>
>>>>>>>>
>>>>>>>> The fix is:
>>>>>>>> 1. first packer/unpacker saves default time zone
>>>>>>>> 2. the last set it back.
>>>>>>>>
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.00/
>>>>>>>
>>>>>>> The above link is wrong!, it takes me to webrev for 8073187,
>>>>>>> which has only the PackerImpl changes.
>>>>>>>
>>>>>>> I am guessing the link should be:
>>>>>>> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.00/
>>>>>>>
>>>>>>> Kumar
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Mikhail.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From daniel.fuchs at oracle.com  Wed Mar 25 11:41:26 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 25 Mar 2015 12:41:26 +0100
Subject: RFR: 8075810: LogManager.readConfiguration may throw undocumented
	IllegalArgumentException
In-Reply-To: <BLU175-W3CA9B09E1C8C11B7B6F2E830A0@phx.gbl>
References: <551177D7.5060203@oracle.com>,
	<938960BA-2827-417B-87AE-A1994A6B2AD4@oracle.com>,
	<55117D87.9040708@oracle.com>
	<BLU175-W3CA9B09E1C8C11B7B6F2E830A0@phx.gbl>
Message-ID: <55129EE6.5020407@oracle.com>

Thanks for the review Jason!

On 24/03/15 18:01, Jason Mehrens wrote:
> Hi Daniel,
>
> Looks good.  The only other alternative would be to use java.io.CharConversionException over IOException.  We could even consider dropping the cause because the subclass of I/O exception would convey the same meaning.

Here is a an updated webrev where I use
java.io.CharConversionException instead of plain IOException.

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

Note: I had a look in the JDK sources and CharConversionException
doesn't appear to be widely used. Is this the better alternative?
I'd be happy with both (webrev.01 or webrev.00).
Using CharConversionException means that we have to trust that
Properties.load will obey its spec and only throw IAE in case
of character conversion issues.

> Minor formatting issues with a missing space after the catch keyword

Done. Thanks for catching it.

> and missing a tab ahead of 'props.load'

That is an artifact of how webrev calls diff I think.
If you look at the frames version you will see that the tab is here.

best regards,

-- daniel

>
> Jason
>
>
> ----------------------------------------
>> Date: Tue, 24 Mar 2015 16:06:47 +0100
>> From: daniel.fuchs at oracle.com
>> To: lance.andersen at oracle.com
>> Subject: Re: RFR: 8075810: LogManager.readConfiguration may throw undocumented IllegalArgumentException
>> CC: core-libs-dev at openjdk.java.net
>>
>> Hi Lance,
>>
>> Thanks for the review!
>>
>> On 24/03/15 16:01, Lance Andersen wrote:
>>> Hi Daniel,
>>>
>>> This looks OK but I might suggest clarifying that the cause could be set
>>> in the javadoc. Now that being said, I am not sure how consistent we
>>> are across the JDK or just make the assumption people will check the
>>> cause if they desire.
>>
>> Hmmm. I have the feeling that the best place for that would be i the
>> release notes - rather than in the API doc (which reminds me I should
>> plan to add some release note text to the issue).
>>
>>> As far as backporting, unless it really needed, I would probably would
>>> not as a change such as this typically should be done as part of an
>>> errata/MR (due to change of behavior and it is not that big of an issue).
>>
>> Right, my thinking too. Thanks for sharing your opinion!
>>
>> best regards,
>>
>> -- daniel
>>
>>>
>>> Best
>>> Lance
>>> On Mar 24, 2015, at 10:42 AM, Daniel Fuchs <daniel.fuchs at oracle.com
>>> <mailto:daniel.fuchs at oracle.com>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Please find below a fix for
>>>>
>>>> 8075810: LogManager.readConfiguration may throw
>>>> undocumented IllegalArgumentException
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8075810
>>>>
>>>> The proposed fix is to catch the IllegalArgumentException and
>>>> wrap it in an IOException, since LogManager.readConfiguration
>>>> is specified to throw IOException "if there are problems reading
>>>> from the stream."
>>>>
>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8075810/webrev.00/
>>>>
>>>> Initial discussion around the issue can be seen here:
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032348.html
>>>>
>>>> Question for reviewers: I will log a CCC for this - but I am wondering
>>>> whether I should plan to backport the fix to earlier release?
>>>>
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen|
>>> Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>
>>>
>>>
>> 		 	   		



From chris.hegarty at oracle.com  Wed Mar 25 11:49:41 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 25 Mar 2015 11:49:41 +0000
Subject: RFR: JDK-8068721 - RMI-IIOP communication fails when
	ConcurrentHashMap is passed to remote method
In-Reply-To: <CA+kOe0-xHVj8ZPzcz=01WiV+LG4K2o27DB+-QTcSYzaxzB_rnA@mail.gmail.com>
References: <551084E3.6050702@oracle.com>	<CA+kOe09S6o8xx8MufAHpO2e_NbhqgHHvP+Jbuwy41Y4yLqOoCw@mail.gmail.com>	<C6606626-61AA-48A4-A06E-5568EF37E538@oracle.com>
	<CA+kOe0-xHVj8ZPzcz=01WiV+LG4K2o27DB+-QTcSYzaxzB_rnA@mail.gmail.com>
Message-ID: <5512A0D5.5020206@oracle.com>

On 25/03/15 00:05, Martin Buchholz wrote:
> How about this, which resurrects the jdk7 doc strings for the legacy fields?

That is fine with me, and similar to what I had at one point. I just 
wasn't sure if you wanted to stuff the descriptions back in. If they are 
still valid, then it is the best solution.

[ I think these were inadvertently dropped with the CHMv8 work. ]

-Chris.


> --- src/main/java/util/concurrent/ConcurrentHashMap.java24 Mar 2015
> 22:30:53 -00001.270
> +++ src/main/java/util/concurrent/ConcurrentHashMap.java25 Mar 2015
> 00:03:43 -0000
> @@ -566,7 +566,16 @@
>       /** Number of CPUS, to place bounds on some sizings */
>       static final int NCPU = Runtime.getRuntime().availableProcessors();
> -    /** For serialization compatibility. */
> +    /**
> +     * Serialized pseudo-fields, provided only for jdk7 compatibility.
> +     * @serialField segments Segment[]
> +     *   The segments, each of which is a specialized hash table.
> +     * @serialField segmentMask int
> +     *   Mask value for indexing into segments. The upper bits of a
> +     *   key's hash code are used to choose the segment.
> +     * @serialField segmentShift int
> +     *   Shift value for indexing within segments.
> +     */
>       private static final ObjectStreamField[] serialPersistentFields = {
>           new ObjectStreamField("segments", Segment[].class),
>           new ObjectStreamField("segmentMask", Integer.TYPE),
>
>
> On Tue, Mar 24, 2015 at 2:38 AM, Chris Hegarty <chris.hegarty at oracle.com
> <mailto:chris.hegarty at oracle.com>> wrote:
>
>     Martin,
>
>     On 23 Mar 2015, at 22:15, Martin Buchholz <martinrb at google.com
>     <mailto:martinrb at google.com>> wrote:
>
>     > Let us know if the serialization code of the collection classes can be
>     > improved.
>
>     I think there are a few minor cleanups that would be beneficial in CHM:
>
>       1) Add @serialField so that the serializable stream fields show up
>     in the
>           javadoc ( serial form ), since they are still part of the
>     serial form, even
>           though not used in the implementation. This is just documenting
>           existing behaviour/form.
>
>       2) Mark correctly identified a small hole in the putFields() spec,
>     which
>           should be fixed. A minor, benign, change in CHM writeObject
>           can avoid this ( spec ambiguity ).
>
>     Please consider the following change:
>
>     diff --git
>     a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
>     b/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
>     ---
>     a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
>     +++
>     b/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java
>     @@ -35,6 +35,7 @@
>
>       package java.util.concurrent;
>
>     +import java.io.ObjectOutputStream;
>       import java.io.ObjectStreamField;
>       import java.io.Serializable;
>       import java.lang.reflect.ParameterizedType;
>     @@ -599,7 +600,12 @@
>           /** Number of CPUS, to place bounds on some sizings */
>           static final int NCPU =
>     Runtime.getRuntime().availableProcessors();
>
>     -    /** For serialization compatibility. */
>     +    /**
>     +     * For serialization compatibility.
>     +     * @serialField segments Segment[]
>     +     * @serialField segmentMask int
>     +     * @serialField segmentShift int
>     +     */
>           private static final ObjectStreamField[]
>     serialPersistentFields = {
>               new ObjectStreamField("segments", Segment[].class),
>               new ObjectStreamField("segmentMask", Integer.TYPE),
>     @@ -1400,9 +1406,10 @@
>                   new Segment<?,?>[DEFAULT_CONCURRENCY_LEVEL];
>               for (int i = 0; i < segments.length; ++i)
>                   segments[i] = new Segment<K,V>(LOAD_FACTOR);
>     -        s.putFields().put("segments", segments);
>     -        s.putFields().put("segmentShift", segmentShift);
>     -        s.putFields().put("segmentMask", segmentMask);
>     +        ObjectOutputStream.PutField streamFields = s.putFields();
>     +        streamFields.put("segments", segments);
>     +        streamFields.put("segmentShift", segmentShift);
>     +        streamFields.put("segmentMask", segmentMask);
>               s.writeFields();
>
>               Node<K,V>[] t;
>
>     -Chris.
>
>      > On Mon, Mar 23, 2015 at 2:25 PM, Mark Sheppard
>     <mark.sheppard at oracle.com <mailto:mark.sheppard at oracle.com>>
>      > wrote:
>      >
>      >> Hi
>      >> please oblige and review the following fix
>      >>
>      >> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev/
>      >> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev/
>      >>
>      >>
>      >> which addresses the issue in
>      >> https://bugs.openjdk.java.net/browse/JDK-8068721
>      >>
>      >> This relates to RMI-IIOP and the interplay between custom
>     marshalling of
>      >> ValueTypes and
>      >> the corresponding serialization of a Java class, in this case
>      >> ConcurrentHashMap.
>      >>
>      >> ConcurrentHashMap changed its structure in jdk8 from that used
>     in jdk7.
>      >> This resulted in modification to the readObject and writeObject
>     methods,
>      >> and in particular, former serial fields were removed, resulting in
>      >> writeObject using PutField and readObject using defaultReadObject.
>      >> The writeObject invokes the putFields method of an
>     ObjectOutputStream
>      >> multiple times, and assumes
>      >> that it will receive the same PutField object instance for each
>      >> invocation. The spec
>      >> doesn't endorse this behaviour - but that's what the
>     implementation of
>      >> ObjectOutputStream
>      >> provides. However in the case of RMI-IIOP, the OutputStreamHook, a
>      >> subclass of ObjectOutputStream, returns a new instance for each
>      >> putFields invocation. Thus, the ConcurrentHashMap writeObject
>     results in
>      >> improper serialization in the context
>      >> of RMI-IIOP.
>      >> In the unmarshalling flow of ConcurrentHashMap, the readObject
>     now uses
>      >> defaultReadObject rather than GetField
>      >> In this call flow the IIOPInputStream attempts to ignore any
>     primitive
>      >> field, in the serialized data, that doesn't
>      >> correspond with a reflective field of the object. However, it
>     leaves the
>      >> primitive in the stream.
>      >> Thus, in the case of ConcurrentHashMap, which has serialized two
>     integers
>      >> and
>      >> an array of Segments (subclass of ReentrantLock), this results
>     in erroneous
>      >> deserialization, with a misinterpretation of a value tag in the
>     stream as
>      >> an array length
>      >> and an attempt to allocate a very large array ensues, with an
>     exception
>      >> being thrown.
>      >>
>      >> The OutputStreamHook now returns the same instance of PutField
>     allocated
>      >> for each separate call of putFields method.
>      >> This highlights a need to tighten up and disambiguate the
>      >> OutputObjectStream spec for putFields.
>      >>
>      >> IIOPInputStream now removes the primitive values from the stream.
>      >>
>      >> regards
>      >> Mark
>      >>
>
>


From Alan.Bateman at oracle.com  Wed Mar 25 11:59:24 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 25 Mar 2015 11:59:24 +0000
Subject: RFR [9] 8071472: Add field setter API for setting final fields
	in readObject
In-Reply-To: <8A941AAA-C3A0-48BA-9A19-0FD1B9B52E97@oracle.com>
References: <5510351D.1070500@oracle.com> <55114A13.9010509@oracle.com>
	<8A941AAA-C3A0-48BA-9A19-0FD1B9B52E97@oracle.com>
Message-ID: <5512A31C.1010200@oracle.com>

On 24/03/2015 16:07, Chris Hegarty wrote:
> Thanks for the feedback Alan.
>
> :
>
> Updated:
>    http://cr.openjdk.java.net/~chegar/8071472/03/specdiff/
>
> -Chris.
>
I think this looks good now.

-Alan


From peter.levart at gmail.com  Wed Mar 25 12:24:00 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 25 Mar 2015 13:24:00 +0100
Subject: RFR [9] 8071472: Add field setter API for setting final fields
	in readObject
In-Reply-To: <5510351D.1070500@oracle.com>
References: <5510351D.1070500@oracle.com>
Message-ID: <5512A8E0.6040303@gmail.com>

On 03/23/2015 04:45 PM, Chris Hegarty wrote:
> Here is an updated version of the FieldSetter API, with all comments 
> to date incorporated.
>
>
> http://cr.openjdk.java.net/~chegar/8071472/02/specdiff/overview-summary.html 
>
>
> Final spec comments welcome, after which I intend to submit a CCC 
> request.
>
> -Chris.

Hi Chris,

Recent bug "JDK-8068721 - RMI-IIOP communication fails when 
ConcurrentHashMap is passed to remote method" made me thinking...

ObjectInputStream is an extensible API. There are subclasses of 
ObjectInputStream out there. For example, there is an abstract 
"com.sun.corba.se.impl.io.InputStreamHook" with concrete implementation 
"com.sun.corba.se.impl.io.IIOPInputStream". The InputStreamHook 
overrides ObjectInputStream.defaultReadObject() with it's own 
implementation which doesn call ObjectInputStream.defaultReadObject(), 
which means that FieldSetterContext.checkPersistentFinalsNotSet() and 
FieldSetterContext.markPersistentFinalsSet() is not called for 
InputStreamHook based subclasses when user's readObject() calls 
defaultReadObject(), which further means that 
FieldSetter.checkAllFinalsSet() that is eventually called as last thing 
in user's readObject() method might find any persistent finals as not 
set and throw InvalidObjectException.

I have been thinking about this and I see several solutions:

1. provide protected final methods 
ObjectInputStream.checkPersistentFinalsNotSet() and 
markPersistentFinalsSet() that just delegate to FieldSetterContext for 
ObjectInputStream classes to call as part of their own overriden 
defaultReadObject() method. We should make sure those methods are called 
in JDK's corba InputStreamHook and document they should be called in 3rd 
party subclasses.

2. in ObjectInputStream constructor, detect if defaultReadObject() is 
overridden and set a flag that makes FieldSetter.checkAllFinalsSet() 
effectively a no-op.

3. 1 + 2 + enable for ObjectInputStream subclasses to declare that they 
obey the contract and that they call markPersistentFinalsSet() from 
overridden defaultReadObject() so checkAllFinalsSet() can be enabled.


What do you think?

Regards, Peter



From amy.lu at oracle.com  Wed Mar 25 12:52:14 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 25 Mar 2015 20:52:14 +0800
Subject: JDK 9 RFR of JDK-8075692: jaxp/test/Makefile references (has
	been removed) win32 directory in jtreg
In-Reply-To: <551235E3.5060709@oracle.com>
References: <5510F25A.4050406@oracle.com> <5511AA77.7000305@oracle.com>
	<55120D6E.7060407@oracle.com> <551235E3.5060709@oracle.com>
Message-ID: <5512AF7E.1030300@oracle.com>

Thank you Joe !

/Amy

On 3/25/15 12:13 PM, huizhe wang wrote:
> Ok, I pushed your change.
>
> Thanks,
> Joe
>
> On 3/24/2015 6:20 PM, Amy Lu wrote:
>> Hi, Joe
>>
>> Without this fix, jaxp test run in JPRT will fail because it try to 
>> use jtreg/win32/bin/jtreg
>>
>> Thanks,
>> Amy
>>
>> On 3/25/15 2:18 AM, huizhe wang wrote:
>>> Hi Amy,
>>>
>>> Does this in any way affect how the tests are run in JPRT?
>>>
>>> Thanks,
>>> Joe
>>>
>>> On 3/23/2015 10:12 PM, Amy Lu wrote:
>>>> File structure has changed in the new jtreg distribution (4.1/b11), 
>>>> there are no platform specific bin directories any more.
>>>> This fix is for updating jaxp/test/Makefile accordingly.
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8075692
>>>> webrev: http://cr.openjdk.java.net/~amlu/8075692/webrev.00/
>>>>
>>>> I also need a sponsor for this fix.
>>>>
>>>> Thanks,
>>>> Amy
>>>
>>
>



From david.lloyd at redhat.com  Wed Mar 25 14:24:40 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 25 Mar 2015 09:24:40 -0500
Subject: Fw: Re: RFR [9] 8071472: Add field access to support,	setting
	final fields in readObject
In-Reply-To: <1427003634.3407.9.camel@Nokia-N900>
References: <mailman.52449.1426871986.10816.core-libs-dev@openjdk.java.net>	
	<550CE00F.40403@zeus.net.au> <550DDE8B.4030605@redhat.com>	
	<1426984742.2614.5.camel@Nokia-N900>
	<1426992248.2869.11.camel@Nokia-N900>
	<1427003634.3407.9.camel@Nokia-N900>
Message-ID: <5512C528.9090809@redhat.com>

No, I don't think there's any legitimate use case for allowing 
readObject to skip reading fields or to read fields while or after 
reading data (and the same goes for writeObject).  However this doesn't 
change the fact that the JDK contains several classes which do exactly 
this, many third-party libraries also do so, and there is plenty of 
serialized data out in the wild which will therefore do this.  I 
actually enforced the spec behavior in a draconian fashion in the first 
versions of JBoss Marshalling and a shocking number of things broke, so 
now I'm considerably more lenient (still not as lenient as the JDK 
though, which still causes problems for my users in some cases).

So when I first brought this up, several months ago, I was wondering if 
the implementation could be tightened up, but in the end I was willing 
to pragmatically settle on updating the spec to reflect reality.

On 03/22/2015 12:53 AM, Peter Firmstone wrote:
> Was there a use you had in mind, or some other reason you thought the
> spec should be modified to accomodate it?
>
> Such as improve serial form evolution flexibility, when someone's
> forgotten to call defaultReadObject|WriteObject?
>
> I'm not sure how that can be implemented though, requires further
> thought; to see if it can be done without breaking the serialization
> stream protocol.
>
> Regards,
>
> Peter.
>
> ----- Original message -----
>> What happens, to answer your question, is the fields, if any, won't
>> appear in the stream where they are supposed to be.
>>
>> Again this will affect evolvability of serial form.   In other words,
>> incorrect implementations are locked into their current serial form.   I
>> don't think that's something that should be encouraged.
>>
>> ----- Original message -----
>> > If an object defines readObject(), then it is responsible for reading
>> > fields.
>> >
>> > So lets say for arguments sake that all fields are transient in the
>> > first version of an Object and it doesn't call defaultReadObject or
>> > GetFields before reading in block data.
>> >
>> > If at some later time the developer defines a non-transient field, the
>> > earlier version cannot deserialise the later versions serial form,
>> > because the field appears in the stream, when it is expecting block
>> > data.
>> >
>> > If the developer decided instead to call defaultReadObject even if all
>> > fields were transient, then backward compatibility is preserved because
>> > the fields are removed from the stream, before the earlier object
>> > version reads block data following the fields.
>> >
>> > Now lets say, for the sake of another example, that an object writes
>> > block data, before writing fields.
>> >
>> > Food for thought:
>> >
>> > How is excess block data or an additional field discarded by the stream
>> > by earlier versions if an Object's later version adds fields or block
>> > data?
>> >
>> > Regards,
>> >
>> > Peter.
>> >
>> >
>> > ----- Original message -----
>> > > I think you didn't understand the issue being discussed - it's not
>> > > about    fields that are added/removed, which is very clearly defined
>> > > in the    spec.     It's about what happens when you don't call
>> > > defaultRead|WriteFields, which is required by spec but not always
>> > > done   in practice.
>> > >
>> > > On 03/20/2015 10:05 PM, Peter Firmstone wrote:
>> > > > The reason for this part of the spec, is backward compatible
>> > > > evolvability of serial form.
>> > > >
>> > > > It allows an earlier implementation of a class to deserialize
>> > > > serial form from a later implementation that includes additional
>> > > > fields or values written to the stream, and allow them to be
>> > > > discarded by ObjectInputStream, when the earilier implementation
>> > > > doesn't read/consume them.
>> > > >
>> > > > If classes deliberately break the contract / spec, then although
>> > > > they function, they limit their backward compatible evolvability;
>> > > > in other words, if a later class has additional fields or writes
>> > > > additional values to the stream, a StreamCorruptedException will
>> > > > occur when an earlier class implementation reads it.
>> > > >
>> > > > For that reason, I'd reccommend against including it in the spec.
>> > > >
>> > > > Regards,
>> > > >
>> > > > Peter.
>> > > >
>> > > >
>> > > > > ------------------------------
>> > > > >
>> > > > > Message: 4
>> > > > > Date: Fri, 20 Mar 2015 11:57:04 -0500
>> > > > > From: "David M. Lloyd"<david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>>
>> > > > > To:core-libs-dev at openjdk.java.net <mailto:core-libs-dev at openjdk.java.net>
>> > > > > Subject: Re: Fw: Re: RFR [9] 8071472: Add field access to support
>> > > > > setting         final fields in readObject
>> > > > > Message-ID:<550C5160.2030106 at redhat.com <mailto:550C5160.2030106 at redhat.com>>
>> > > > > Content-Type: text/plain; charset=utf-8; format=flowed
>> > > > >
>> > > > > On 03/20/2015 09:31 AM, Peter Levart wrote:
>> > > > > > On 03/20/2015 02:03 PM, David M. Lloyd wrote:
>> > > > > > > > > private static void altReadObject(ObjectInputStream in,
>> > > > > > > > > FieldAccess fieldAccess) throws IOException,
>> > > > > > > > > ClassNotFoundException { // the same as in readObject,
>> > > > > > > > > but doesn't have direct access to
>> > > > > > > > > instance state, so everything must go through FieldAccess
>> > > > > > > > > API? }
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > Yes.
>> > > > > > > An interesting aspect of this approach is that it deals with
>> > > > > > > a problem in the serialization spec [1] where it specifically
>> > > > > > > says that serializable classes should be reading/writing
>> > > > > > > stream fields always, and before reading/writing other data:
>> > > > > > >
>> > > > > > > In section 3.4: "Either ObjectInputStream's defaultReadObject
>> > > > > > > or readFields method must be called once (and only once)
>> > > > > > > before reading any optional data written by the corresponding
>> > > > > > > writeObject method; even if no optional data is read,
>> > > > > > > defaultReadObject or readFields must still be invoked once."
>> > > > > > >
>> > > > > > > In section 2.3: "Either ObjectOutputStream's
>> > > > > > > defaultWriteObject or writeFields method must be called once
>> > > > > > > (and only once) before writing any optional data that will
>> > > > > > > be needed by the corresponding readObject method to restore
>> > > > > > > the state of the object; even if no optional data is
>> > > > > > > written, defaultWriteObject or writeFields must still be
>> > > > > > > invoked once."
>> > > > > > >
>> > > > > > > But classes (even JDK classes) often disregard this
>> > > > > > > requirement, relying on known implementation behavior and
>> > > > > > > either reading/writing optional data before fields or just
>> > > > > > > not reading/writing fields at all.     So either the spec
>> > > > > > > should be updated (I've tried to do this but nobody seems to
>> > > > > > > know how to modify this old content I guess) to match
>> > > > > > > behavior, or the spec should be enforced more strictly -
>> > > > > > > however doing the latter *will* break a lot of user code,
>> > > > > > > *unless* an alternative readObject method is introduced with
>> > > > > > > the more strict enforcement.     But I guess even in this
>> > > > > > > case, the spec should be updated to allow the implementation
>> > > > > > > behavior.
>> > > > > > >
>> > > > > > > [1]
>> > > > > > >http://docs.oracle.com/javase/8/docs/platform/serialization/spec/serialTOC.html
>
>> > > > > > >
>> > > > > > >
>> > > > > > I guess this would need an alternative writeObject method too,
>> > > > > > with more strict enforcement, or not?
>> > > > > Sounds fine to me...
>> > > > >
>> > > > > > I don't know from the top of my head, but does the order of
>> > > > > > writing optional data (before or after) fields, change the
>> > > > > > order of data emitted in stream and does that order have to be
>> > > > > > respected when reading back in readObject()?
>> > > > > Yes.
>> > > > >
>> > > > > > In that case, I guess, we would need an alternative
>> > > > > > writeObject method too, with more strict enforcement of order.
>> > > > > > But I think that having two different rules for old
>> > > > > > read/writeObject and alternative read/writeObject would just
>> > > > > > confuse people. If current rules don't present any problem
>> > > > > > (apart from being looser then specification requires) then
>> > > > > > perhaps just specification should be updated.
>> > > > > Maybe.
>> > > > >
>> > > >
>> > >
>> > > --
>> > > - DML
>> >
>>
>

-- 
- DML


From baiduzhyi.devel at gmail.com  Wed Mar 25 14:47:11 2015
From: baiduzhyi.devel at gmail.com (Stanislav Baiduzhyi)
Date: Wed, 25 Mar 2015 15:47:11 +0100
Subject: RFR (XS) 8074761: Empty optional parameters of LDAP query are not
	interpreted as empty
In-Reply-To: <2031750.BZlfoUzYlO@thinkpad>
References: <2031750.BZlfoUzYlO@thinkpad>
Message-ID: <2030536.zvpBUlpsvY@thinkpad>

On Tuesday 10 March 2015 17:18:06 Stanislav Baiduzhyi wrote:
> Hi All,
> 
> Please review the patch for LdapURL. Patch fixes the parsing of query part
> of LDAP URL, leaving empty optional fields as null instead of "".
> 
> Webrev:
> http://goo.gl/OO0V38
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8074761
> 
> JTreg:
> http://goo.gl/ermmoh
> 
> Details:
> 
> RFC 2255 [1] allows any of the query parameters to be empty. Current
> implementation of parsing method extracts substring without checking for
> length, leaving empty fields as "" instead of null. But the code under
> com.sun.jndi.ldap package checks only for null when handling optional
> fields. So the patch modifies the parsing method to avoid substring
> operations on empty fields and leaving them as null instead.
> 
> In proposed patch, I was not able to generalize the code, so using similar
> code blocks to make it obvious if additional changes will be required later.
> 
> It would be even better to use java.util.Optional for this, but it will be
> compatibility-breaking change, I'm not sure it worth doing even under
> com.sun.* packages.
> 
> There is wider test case in RedHat Bugzilla [2], includes OpenDS setup and
> small client app, shows the difference in results between openldap-clients
> with Java-based implementation. Proposed patch fixes the java client
> behaviour.
> 
> [1]: https://tools.ietf.org/html/rfc2255#section-3
> [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1194226

A small reminder, please review the webrev quoted above, the patch is 
extremely small, and passes the TCK.

-- 
Regards,
    Stas



From kumar.x.srinivasan at oracle.com  Wed Mar 25 15:19:41 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 25 Mar 2015 08:19:41 -0700
Subject: [8] RFR of 8066985: Java Webstart downloading packed files can
	result in Timezone set to UTC
In-Reply-To: <5512850F.90701@oracle.com>
References: <550976B9.6030503@oracle.com> <5509F73C.6000306@oracle.com>
	<550AD4C9.9030905@oracle.com> <550AEF48.4070904@gmail.com>
	<550AF969.7070706@gmail.com> <550C36FD.701@oracle.com>
	<5511C5BE.2010809@oracle.com> <5511E9CB.7050504@oracle.com>
	<5512850F.90701@oracle.com>
Message-ID: <5512D20D.4070709@oracle.com>


On 3/25/2015 2:51 AM, mikhail cherkasov wrote:
> On 3/25/2015 1:48 AM, Kumar Srinivasan wrote:
>> Hi Mikhail,
>>
>> Nit:
>> Utils.java:
>> -            // reset timezone when all the packers have terminated
>> +            // reset timezone when all the packer/unpacker instances have terminated
> fixed: http://cr.openjdk.java.net/~mcherkas/8066985/webrev.03/
>>
>>
>> DefaultTimeZoneTest.java
>> What did you change between 01 and 02 revisions ? They appear to be the
>> same ?
> Please, see revisions 00 and 02. 01 has DefaultTimeZoneTest.java.rej, 
> 02 is the same but without this extra file.

I see!, ok the changes look good, however my concern is the test,
should we throttle/adapt the test on the number of processors available
using Runtime.availableProcessors() ?

Kumar

>> Kumar
>>
>>
>> On 3/24/2015 1:14 PM, mikhail cherkasov wrote:
>>> Hi there,
>>>
>>> There's a new webrev: 
>>> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.02/
>>>
>>> I reduced the a thread number in the test, because with big count of 
>>> threads I got OOM on JPRT.
>>> And extract common part form PackerImpl and UnpackerImpl to Utils.
>>>
>>> Thanks,
>>> Mikhail.
>>>
>>>
>>> On 3/20/2015 6:04 PM, mikhail cherkasov wrote:
>>>>
>>>> On 3/19/2015 7:29 PM, Peter Levart wrote:
>>>>> On 03/19/2015 04:46 PM, Peter Levart wrote:
>>>>>> On 03/19/2015 02:53 PM, Kumar Srinivasan wrote:
>>>>>>> Mikhail,
>>>>>>>
>>>>>>> You can move the common utilitieschangeDefaultTimeZoneToUtc and
>>>>>>> restoreDefaultTimeZoneto Utils.java.
>>>>>>>
>>>>>>> Also I am not sure how effective the test is ?  does it catch 
>>>>>>> the issue ?
>>>>>>> if you don't have the fix in PackerImpl and UnpackerImpl ?
>>>>>>>
>>>>>>> Otherwise it looks good, and I can sponsor this patch for you.
>>>>>>>
>>>>>>> Kumar
>>>>>>
>>>>>> Hi Mikhail,
>>>>>>
>>>>>> Is this code part of some utility so that it is executed 
>>>>>> exclusively in it's own JVM, or can it also be executed by some 
>>>>>> public API or internal JVM thread? It appears to be the later 
>>>>>> (used by java.util.jar.Pack200 public API), but haven't checked.
>>>>>>
>>>>>> In case of the later, I think it is very strange that the code 
>>>>>> changes global JVM timezone, albeit just temporarily. This could 
>>>>>> affect other code that needs default TZ and executes concurrently.
>>>>>>
>>>>>> Even in case of the former, if the PackerImpl.pack can be 
>>>>>> executed by multiple concurrent threads and if 
>>>>>> UnpackerImpl.unpack can be executed by multiple concurrent 
>>>>>> threads, what guarantees that some PackerImpl.pack thread is not 
>>>>>> executed concurrently with some UnpackerImpl.unpack thread? You 
>>>>>> only track each method separately.
>>>> Agree, I'll move changeDefaultTimeZoneToUtc and 
>>>> restoreDefaultTimeZone to Util class, so TZ changes will be managed 
>>>> in one place  for both PackerImpl and UnpackerImpl classes.
>>>>
>>>> NonPack200 threads that reads/writes DTZ can collide with Pack200, 
>>>> but there's other bug that should fix this: 
>>>> https://bugs.openjdk.java.net/browse/JDK-8073187
>>>>
>>>> My fix is only for jdk8 and 7, and it focused on making 
>>>> packer/unpacker safe for concurrent use,  because now applets and 
>>>> JNLP uses packer/unpacker concurrently and this can
>>>> lead to DTZ changing to UTC.
>>>>
>>>>>>
>>>>>>
>>>>>> Regards, Peter
>>>>>
>>>>> I guess this default TZ manipulation is needed because 
>>>>> JarOutputStream/JarInputStream don't provide constructors that 
>>>>> would take a TZ object, but always use default TZ, right?
>>>>>
>>>>> The cleanest way would be to add such constructors, but if this is 
>>>>> too much for 8u, then perhaps some internal ThreadLocal<TZ> could 
>>>>> be exposed to both PackerImpl/UnpackerImpl and 
>>>>> Jar[Zip]Input[Output] stream internals. It think the use of 
>>>>> default TZ in Jar/Zip/Streams is very localized. It is needed to 
>>>>> convert local time (specified as DOS time) to and from epoch-based 
>>>>> time exposed in ZipEntry. The code is located in package-private 
>>>>> class java.util.zip.ZipUtils in methods dosToJavaTime 
>>>>> /javaToDosTime (or equivalent extendedDosToJavaTime / 
>>>>> javaToExtendedDosTime in JDK9).
>>>> all solutions that you described require introducing a new API and 
>>>> this can not be done for jdk7 and 8, so that's why JDK-8073187 was 
>>>> created.
>>>> The main purpose of this fix is to make packed jars delivery save 
>>>> for applets/jnlp application.
>>>>
>>>>>
>>>>> Another way would be to provide a general thread-local default TZ 
>>>>> override in TimeZone itself. Something like the following:
>>>>>
>>>>> ===================================================================
>>>>> --- jdk/src/share/classes/java/util/TimeZone.java
>>>>> +++ jdk/src/share/classes/java/util/TimeZone.java
>>>>> @@ -630,8 +630,11 @@
>>>>>       * method doesn't create a clone.
>>>>>       */
>>>>>      static TimeZone getDefaultRef() {
>>>>> -        TimeZone defaultZone = defaultTimeZone;
>>>>> +        TimeZone defaultZone = threadLocalTimeZone.get();
>>>>>          if (defaultZone == null) {
>>>>> +            defaultZone = defaultTimeZone;
>>>>> +        }
>>>>> +        if (defaultZone == null) {
>>>>>              // Need to initialize the default time zone.
>>>>>              defaultZone = setDefaultZone();
>>>>>              assert defaultZone != null;
>>>>> @@ -713,6 +716,20 @@
>>>>>          defaultTimeZone = zone;
>>>>>      }
>>>>>
>>>>> +    public void withThreadDefaultDo(Runnable runnable) {
>>>>> +        TimeZone prevZone = threadLocalTimeZone.get();
>>>>> +        threadLocalTimeZone.set(this);
>>>>> +        try {
>>>>> +            runnable.run();
>>>>> +        } finally {
>>>>> +            if (prevZone == null) {
>>>>> +                threadLocalTimeZone.remove();
>>>>> +            } else {
>>>>> + threadLocalTimeZone.set(prevZone);
>>>>> +            }
>>>>> +        }
>>>>> +    }
>>>>> +
>>>>>      /**
>>>>>       * Returns true if this zone has the same rule and offset as 
>>>>> another zone.
>>>>>       * That is, if this zone differs only in ID, if at all.  
>>>>> Returns false
>>>>> @@ -760,6 +777,8 @@
>>>>>       */
>>>>>      private String           ID;
>>>>>      private static volatile TimeZone defaultTimeZone;
>>>>> +    private static final ThreadLocal<TimeZone> threadLocalTimeZone =
>>>>> +        new ThreadLocal<>();
>>>>>
>>>>>      static final String         GMT_ID        = "GMT";
>>>>>      private static final int    GMT_ID_LENGTH = 3;
>>>>>
>>>>>
>>>>> Regards, Peter
>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 3/18/2015 3:07 PM, Kumar Srinivasan wrote:
>>>>>>>>
>>>>>>>> Hello Mikhail,
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066985
>>>>>>>>>
>>>>>>>>> The problem is that packer/unpacker changes global state( 
>>>>>>>>> default time zone ) without proper synchronization:
>>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/com/sun/java/util/jar/pack/PackerImpl.java#l85 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> however javadoc says that it's save to use it in concurrent 
>>>>>>>>> way if each thread has it's own packer/unpacker instance:
>>>>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/java/util/jar/Pack200.java#l149 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The fix is:
>>>>>>>>> 1. first packer/unpacker saves default time zone
>>>>>>>>> 2. the last set it back.
>>>>>>>>>
>>>>>>>>> Webrev:
>>>>>>>>> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.00/
>>>>>>>>
>>>>>>>> The above link is wrong!, it takes me to webrev for 8073187,
>>>>>>>> which has only the PackerImpl changes.
>>>>>>>>
>>>>>>>> I am guessing the link should be:
>>>>>>>> http://cr.openjdk.java.net/~mcherkas/8066985/webrev.00/
>>>>>>>>
>>>>>>>> Kumar
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Mikhail.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From chris.hegarty at oracle.com  Wed Mar 25 15:49:04 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 25 Mar 2015 15:49:04 +0000
Subject: RFR [9] 8071472: Add field setter API for setting final fields
	in readObject
In-Reply-To: <5512A8E0.6040303@gmail.com>
References: <5510351D.1070500@oracle.com> <5512A8E0.6040303@gmail.com>
Message-ID: <5512D8F0.5030505@oracle.com>

Peter,

On 25/03/15 12:24, Peter Levart wrote:
> On 03/23/2015 04:45 PM, Chris Hegarty wrote:
>> Here is an updated version of the FieldSetter API, with all comments
>> to date incorporated.
>>
>>
>> http://cr.openjdk.java.net/~chegar/8071472/02/specdiff/overview-summary.html
>>
>>
>> Final spec comments welcome, after which I intend to submit a CCC
>> request.
>>
>> -Chris.
>
> Hi Chris,
>
> Recent bug "JDK-8068721 - RMI-IIOP communication fails when
> ConcurrentHashMap is passed to remote method" made me thinking...
>
> ObjectInputStream is an extensible API. There are subclasses of
> ObjectInputStream out there.

I did think about this previously, but thought it ok ( I assumed that 
overridden methods would first invoke their superclass counterparts ). 
It appears that InputStreamHook does not do this.

 > For example, there is an abstract
> "com.sun.corba.se.impl.io.InputStreamHook" with concrete implementation
> "com.sun.corba.se.impl.io.IIOPInputStream". The InputStreamHook
> overrides ObjectInputStream.defaultReadObject() with it's own
> implementation which doesn call ObjectInputStream.defaultReadObject(),
> which means that FieldSetterContext.checkPersistentFinalsNotSet() and
> FieldSetterContext.markPersistentFinalsSet() is not called for
> InputStreamHook based subclasses when user's readObject() calls
> defaultReadObject(), which further means that
> FieldSetter.checkAllFinalsSet() that is eventually called as last thing
> in user's readObject() method might find any persistent finals as not
> set and throw InvalidObjectException.
>
> I have been thinking about this and I see several solutions:
>
> 1. provide protected final methods
> ObjectInputStream.checkPersistentFinalsNotSet() and
> markPersistentFinalsSet() that just delegate to FieldSetterContext for
> ObjectInputStream classes to call as part of their own overriden
> defaultReadObject() method. We should make sure those methods are called
> in JDK's corba InputStreamHook and document they should be called in 3rd
> party subclasses.

Yes, I think I agree with this, but since the FieldSetterContext is 
constructed in OIS private readSerialData, there is nothing to delegate 
to, unless InputStreamHook/IIOPInputStream creates the context.

> 2. in ObjectInputStream constructor, detect if defaultReadObject() is
> overridden and set a flag that makes FieldSetter.checkAllFinalsSet()
> effectively a no-op.

Hmm... maybe, but we I think this could fall foul of JCK. A compliant 
implementation should/must throw if all finals are not set, right?

> 3. 1 + 2 + enable for ObjectInputStream subclasses to declare that they
> obey the contract and that they call markPersistentFinalsSet() from
> overridden defaultReadObject() so checkAllFinalsSet() can be enabled.

Yes, again the problem is that they need to be able to create a field 
setter context.

> What do you think?

I am still thinking about this. I do like your suggestions, but I don't 
see how they will work ( regard to the construction of the context ).

This problem is not unique to OIS, it is a general problem with evolving 
any concrete subclassable class, but I think we do need a reasonable 
solution.

Another possibility is that a default implementation of fieldSetter(), 
in a subclass, could throw UOE, Yuck!

Even if we drop the restriction on checking final field set, or not set, 
there is still the issue of when/how the field context can be created in 
a subclass. I think we may need to expose a factory method for this, 
along with your suggestions above.

-Chris.


> Regards, Peter
>


From pavel.rappo at oracle.com  Wed Mar 25 15:53:32 2015
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 25 Mar 2015 15:53:32 +0000
Subject: RFR JDK-8075959: Change parameter names in some IOException subclasses
Message-ID: <B76A825A-3EFC-440E-84E4-B9930604B6C0@oracle.com>

Hi everyone,

Could you please review my change for JDK-8075959

http://cr.openjdk.java.net/~prappo/8075959/webrev.00/

-Pavel



From chris.hegarty at oracle.com  Wed Mar 25 15:54:02 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 25 Mar 2015 15:54:02 +0000
Subject: JEP 102 Process Review
In-Reply-To: <CA+kOe094X1YU-AzGo57pqjCVw4CDpMGjEdCrG4V8893q3y-bUQ@mail.gmail.com>
References: <52DBF819-66D8-4662-8176-526CA3987876@oracle.com>
	<CA+kOe094X1YU-AzGo57pqjCVw4CDpMGjEdCrG4V8893q3y-bUQ@mail.gmail.com>
Message-ID: <5512DA1A.4090905@oracle.com>

On 24/03/15 19:25, Martin Buchholz wrote:
>
>
> On Tue, Mar 24, 2015 at 7:42 AM, Chris Hegarty <chris.hegarty at oracle.com
> <mailto:chris.hegarty at oracle.com>> wrote:
>
>
>     3) "process reaper?, maybe
>          ?Process-Reaper-? + monotonically increasing ID ( similar to
>          ForkJoin worker threads, or other ). But I do accept that this
>          is the existing name for the reaper threads.
>
>
> Nothing interesting is supposed to be happening in one of these process
> reaper threads  ... ideally they wouldn't exist at all ..., so giving
> them a more identifiable name shouldn't help - just add overhead?

Ok, that's fine then.

-Chris.


From Roger.Riggs at Oracle.com  Wed Mar 25 16:08:21 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 25 Mar 2015 12:08:21 -0400
Subject: RFR JDK-8075959: Change parameter names in some IOException
	subclasses
In-Reply-To: <B76A825A-3EFC-440E-84E4-B9930604B6C0@oracle.com>
References: <B76A825A-3EFC-440E-84E4-B9930604B6C0@oracle.com>
Message-ID: <5512DD75.1030101@Oracle.com>

Hi Pavel,

Looks fine.

Roger


On 3/25/2015 11:53 AM, Pavel Rappo wrote:
> Hi everyone,
>
> Could you please review my change for JDK-8075959
>
> http://cr.openjdk.java.net/~prappo/8075959/webrev.00/
>
> -Pavel
>



From peter.levart at gmail.com  Wed Mar 25 16:28:57 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 25 Mar 2015 17:28:57 +0100
Subject: RFR [9] 8071472: Add field setter API for setting final fields
	in readObject
In-Reply-To: <5512D8F0.5030505@oracle.com>
References: <5510351D.1070500@oracle.com> <5512A8E0.6040303@gmail.com>
	<5512D8F0.5030505@oracle.com>
Message-ID: <5512E249.4010302@gmail.com>

On 03/25/2015 04:49 PM, Chris Hegarty wrote:
> Peter,
>
> On 25/03/15 12:24, Peter Levart wrote:
>> On 03/23/2015 04:45 PM, Chris Hegarty wrote:
>>> Here is an updated version of the FieldSetter API, with all comments
>>> to date incorporated.
>>>
>>>
>>> http://cr.openjdk.java.net/~chegar/8071472/02/specdiff/overview-summary.html 
>>>
>>>
>>>
>>> Final spec comments welcome, after which I intend to submit a CCC
>>> request.
>>>
>>> -Chris.
>>
>> Hi Chris,
>>
>> Recent bug "JDK-8068721 - RMI-IIOP communication fails when
>> ConcurrentHashMap is passed to remote method" made me thinking...
>>
>> ObjectInputStream is an extensible API. There are subclasses of
>> ObjectInputStream out there.
>
> I did think about this previously, but thought it ok ( I assumed that 
> overridden methods would first invoke their superclass counterparts ). 
> It appears that InputStreamHook does not do this.
>
> > For example, there is an abstract
>> "com.sun.corba.se.impl.io.InputStreamHook" with concrete implementation
>> "com.sun.corba.se.impl.io.IIOPInputStream". The InputStreamHook
>> overrides ObjectInputStream.defaultReadObject() with it's own
>> implementation which doesn call ObjectInputStream.defaultReadObject(),
>> which means that FieldSetterContext.checkPersistentFinalsNotSet() and
>> FieldSetterContext.markPersistentFinalsSet() is not called for
>> InputStreamHook based subclasses when user's readObject() calls
>> defaultReadObject(), which further means that
>> FieldSetter.checkAllFinalsSet() that is eventually called as last thing
>> in user's readObject() method might find any persistent finals as not
>> set and throw InvalidObjectException.
>>
>> I have been thinking about this and I see several solutions:
>>
>> 1. provide protected final methods
>> ObjectInputStream.checkPersistentFinalsNotSet() and
>> markPersistentFinalsSet() that just delegate to FieldSetterContext for
>> ObjectInputStream classes to call as part of their own overriden
>> defaultReadObject() method. We should make sure those methods are called
>> in JDK's corba InputStreamHook and document they should be called in 3rd
>> party subclasses.
>
> Yes, I think I agree with this, but since the FieldSetterContext is 
> constructed in OIS private readSerialData, there is nothing to 
> delegate to, unless InputStreamHook/IIOPInputStream creates the context.
>
>> 2. in ObjectInputStream constructor, detect if defaultReadObject() is
>> overridden and set a flag that makes FieldSetter.checkAllFinalsSet()
>> effectively a no-op.
>
> Hmm... maybe, but we I think this could fall foul of JCK. A compliant 
> implementation should/must throw if all finals are not set, right?
>
>> 3. 1 + 2 + enable for ObjectInputStream subclasses to declare that they
>> obey the contract and that they call markPersistentFinalsSet() from
>> overridden defaultReadObject() so checkAllFinalsSet() can be enabled.
>
> Yes, again the problem is that they need to be able to create a field 
> setter context.
>
>> What do you think?
>
> I am still thinking about this. I do like your suggestions, but I 
> don't see how they will work ( regard to the construction of the 
> context ).
>
> This problem is not unique to OIS, it is a general problem with 
> evolving any concrete subclassable class, but I think we do need a 
> reasonable solution.
>
> Another possibility is that a default implementation of fieldSetter(), 
> in a subclass, could throw UOE, Yuck!
>
> Even if we drop the restriction on checking final field set, or not 
> set, there is still the issue of when/how the field context can be 
> created in a subclass. I think we may need to expose a factory method 
> for this, along with your suggestions above.
>
> -Chris.

Hi Chris,

Here's how I imagined it. Idea stolen and adapted from parallel-capable 
ClassLoaders ;-) ...

http://cr.openjdk.java.net/~plevart/jdk9-sandbox/serial-exp-branch/webrev.corba.02/
http://cr.openjdk.java.net/~plevart/jdk9-sandbox/serial-exp-branch/webrev.jdk.02/


This is a variant 3 from above. For ObjectInputStream subclasses that 
don't override defaultReadObject(), everything should behave as before 
this change. Those that do override defaultReadObject() have a choice:

- they are *not* finals-tracking capable and checkAllFinalsSet() method 
only checks that non-persistent finals have been set
- they opt-int to be finals-tracking capable by registering and 
declaring that their overridden defaultReadObject() method either 
delegates to a super method which *MUST* be finals-tracking capable or 
explicitly call exposed protected methods: 
checkPersistentFinalsNotSet()/markPersistentFinalsSet().


That's it.

Haven't tested this yet. Just an idea.

Regards, Peter

>
>
>> Regards, Peter
>>



From mark.sheppard at oracle.com  Wed Mar 25 16:29:47 2015
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 25 Mar 2015 16:29:47 +0000
Subject: RFR: JDK-8068721 - RMI-IIOP communication fails when
	ConcurrentHashMap is passed to remote method
In-Reply-To: <551186DB.1050305@gmail.com>
References: <551084E3.6050702@oracle.com> <551186DB.1050305@gmail.com>
Message-ID: <5512E27B.6090101@oracle.com>

Hi Peter,
     I'll remove the synchronization ... I think your right there should 
only be a single thread of control executing
in a particular instance . Based on your prompt I ran a concurrent 
invocation test on the same remote reference and didn't
observe any conflict - separate IIOPOutputStream were used.

regards
Mark

On 24/03/2015 15:46, Peter Levart wrote:
> On 03/23/2015 10:25 PM, Mark Sheppard wrote:
>> Hi
>>  please oblige and review the following fix
>>
>> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev/
>> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev/
>
> Hi Mark,
>
> Can an instance of ObjectStreamHook (ObjectOutputStream) be invoked 
> from multiple threads concurrently? I don't see any synchronization 
> elsewhere in ObjectStreamHook or ObjectOutputStream. Perhaps the 
> synchronization in putFields()/writeFields() is not needed.
>
> Also, in ObjecyOutputStream, writeFields() looks like this:
>
>     public void writeFields() throws IOException {
>         if (curPut == null) {
>             throw new NotActiveException("no current PutField object");
>         }
>         bout.setBlockDataMode(false);
>         curPut.writeFields();
>         bout.setBlockDataMode(true);
>     }
>
>
> ...meaning that NotActiveException is thrown in case user calls this 
> method before invoking putFields() which initializes the PutField 
> object. Should ObjectStreamHook behave the same?
>
> Regards, Peter
>
>>
>>
>> which addresses the issue in
>> https://bugs.openjdk.java.net/browse/JDK-8068721
>>
>> This relates to RMI-IIOP and the interplay between custom marshalling 
>> of ValueTypes and
>> the corresponding serialization of a Java class, in this case 
>> ConcurrentHashMap.
>>
>> ConcurrentHashMap changed its structure in jdk8 from that used in jdk7.
>> This resulted in modification to the readObject and writeObject methods,
>> and in particular, former serial fields were removed, resulting in
>> writeObject using PutField and readObject using defaultReadObject.
>> The writeObject invokes the putFields method of an ObjectOutputStream 
>> multiple times, and assumes
>> that it will receive the same PutField object instance for each 
>> invocation. The spec
>> doesn't endorse this behaviour - but that's what the implementation 
>> of ObjectOutputStream
>> provides. However in the case of RMI-IIOP, the OutputStreamHook, a 
>> subclass of ObjectOutputStream, returns a new instance for each
>> putFields invocation. Thus, the ConcurrentHashMap writeObject results 
>> in improper serialization in the context
>> of RMI-IIOP.
>> In the unmarshalling flow of ConcurrentHashMap, the readObject now 
>> uses defaultReadObject rather than GetField
>> In this call flow the IIOPInputStream attempts to ignore any 
>> primitive field, in the serialized data, that doesn't
>> correspond with a reflective field of the object. However, it leaves 
>> the primitive in the stream.
>> Thus, in the case of ConcurrentHashMap, which has serialized two 
>> integers and
>> an array of Segments (subclass of ReentrantLock), this results in 
>> erroneous
>> deserialization, with a misinterpretation of a value tag in the 
>> stream as an array length
>> and an attempt to allocate a very large array ensues, with an 
>> exception being thrown.
>>
>> The OutputStreamHook now returns the same instance of PutField 
>> allocated for each separate call of putFields method.
>> This highlights a need to tighten up and disambiguate the 
>> OutputObjectStream spec for putFields.
>>
>> IIOPInputStream now removes the primitive values from the stream.
>>
>> regards
>> Mark
>



From martinrb at google.com  Wed Mar 25 16:55:09 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 25 Mar 2015 09:55:09 -0700
Subject: RFR: JDK-8073158 zip files with total entry count 0xFFFF need not
	be ZIP64 files
In-Reply-To: <CA+kOe0_4rGNW_9u7XdgWb=5Ox685ecC+K++b9Lh6SSpqbse=TQ@mail.gmail.com>
References: <CA+kOe0_4rGNW_9u7XdgWb=5Ox685ecC+K++b9Lh6SSpqbse=TQ@mail.gmail.com>
Message-ID: <CA+kOe08sjL+L3TQ30VXEgaZyCPbKE59NnYR_yAZnu0jPaMFBSw@mail.gmail.com>

Yeah, this review is kinda scary.  There's a lot of technical debt here,
and this change only addresses some of it.

A variant of this code is in use at Google.

On Mon, Mar 23, 2015 at 1:18 PM, Martin Buchholz <martinrb at google.com>
wrote:

> Hi Xueming and Alan,
>
> I'd like you to do a code review.
>
> https://bugs.openjdk.java.net/browse/JDK-8073158
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/0xffff-entries-zip-file/
>
> Of course, the really correct thing is to have at most one zip
> implementation per programming language, but I'm not trying to fix that
> here (how many zip implementations does openjdk have?)
>


From peter.levart at gmail.com  Wed Mar 25 16:55:23 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 25 Mar 2015 17:55:23 +0100
Subject: RFR [9] 8071472: Add field setter API for setting final fields
	in readObject
In-Reply-To: <5512D8F0.5030505@oracle.com>
References: <5510351D.1070500@oracle.com> <5512A8E0.6040303@gmail.com>
	<5512D8F0.5030505@oracle.com>
Message-ID: <5512E87B.7040108@gmail.com>

On 03/25/2015 04:49 PM, Chris Hegarty wrote:
>> I have been thinking about this and I see several solutions:
>>
>> 1. provide protected final methods
>> ObjectInputStream.checkPersistentFinalsNotSet() and
>> markPersistentFinalsSet() that just delegate to FieldSetterContext for
>> ObjectInputStream classes to call as part of their own overriden
>> defaultReadObject() method. We should make sure those methods are called
>> in JDK's corba InputStreamHook and document they should be called in 3rd
>> party subclasses.
>
> Yes, I think I agree with this, but since the FieldSetterContext is 
> constructed in OIS private readSerialData, there is nothing to 
> delegate to, unless InputStreamHook/IIOPInputStream creates the context. 

Ah, I see. Let me look at this in some more detail...

Regards, Peter



From peter.levart at gmail.com  Wed Mar 25 17:32:16 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 25 Mar 2015 18:32:16 +0100
Subject: RFR [9] 8071472: Add field setter API for setting final fields
	in readObject
In-Reply-To: <5512E87B.7040108@gmail.com>
References: <5510351D.1070500@oracle.com> <5512A8E0.6040303@gmail.com>
	<5512D8F0.5030505@oracle.com> <5512E87B.7040108@gmail.com>
Message-ID: <5512F120.7030604@gmail.com>

On 03/25/2015 05:55 PM, Peter Levart wrote:
> On 03/25/2015 04:49 PM, Chris Hegarty wrote:
>>> I have been thinking about this and I see several solutions:
>>>
>>> 1. provide protected final methods
>>> ObjectInputStream.checkPersistentFinalsNotSet() and
>>> markPersistentFinalsSet() that just delegate to FieldSetterContext for
>>> ObjectInputStream classes to call as part of their own overriden
>>> defaultReadObject() method. We should make sure those methods are 
>>> called
>>> in JDK's corba InputStreamHook and document they should be called in 
>>> 3rd
>>> party subclasses.
>>
>> Yes, I think I agree with this, but since the FieldSetterContext is 
>> constructed in OIS private readSerialData, there is nothing to 
>> delegate to, unless InputStreamHook/IIOPInputStream creates the context. 
>
> Ah, I see. Let me look at this in some more detail...
>
> Regards, Peter
>

Huh, this is tricky! IIOPInputStream does invoke readObject/writeObject 
methods on an object being (de)serialized, but it does it on it's own. 
So any classes using FieldSetter API will get an exception when 
attempted deserialization with corba...

We could fix IIOPInputStream to do the right thing at the right time 
(like ObjectInputStream) and provide a FieldSetter instance, but what 
about any 3rd party ObjectInputStream subclasses that might do the same? 
Suddenly classes using FieldSetter API will become incompatible with 3rd 
party OIS implementations until those implementations catch-up.

Providing a factory for FieldSetter instance to subclasses of OIS is 
giving write access to private fields of any object. Would have to be 
protected by some permission. Is this acceptable?

Regards, Peter



From xueming.shen at oracle.com  Wed Mar 25 17:55:40 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 25 Mar 2015 10:55:40 -0700
Subject: RFR: JDK-8073158 zip files with total entry count 0xFFFF need
	not be ZIP64 files
In-Reply-To: <CA+kOe08sjL+L3TQ30VXEgaZyCPbKE59NnYR_yAZnu0jPaMFBSw@mail.gmail.com>
References: <CA+kOe0_4rGNW_9u7XdgWb=5Ox685ecC+K++b9Lh6SSpqbse=TQ@mail.gmail.com>
	<CA+kOe08sjL+L3TQ30VXEgaZyCPbKE59NnYR_yAZnu0jPaMFBSw@mail.gmail.com>
Message-ID: <5512F69C.4040003@oracle.com>


It looks fine...I hope you guys also have some tests over there to bring
in more confidence :-)

It might be "easier" to simply update the original haveZIP64() with the code
we have in zip_util.c in which we also try to read the end64 to verify if we
really have one. Your choice though.

-Sherman

On 03/25/2015 09:55 AM, Martin Buchholz wrote:
> Yeah, this review is kinda scary.  There's a lot of technical debt here, and this change only addresses some of it.
>
> A variant of this code is in use at Google.
>
> On Mon, Mar 23, 2015 at 1:18 PM, Martin Buchholz <martinrb at google.com <mailto:martinrb at google.com>> wrote:
>
>     Hi Xueming and Alan,
>
>     I'd like you to do a code review.
>
>     https://bugs.openjdk.java.net/browse/JDK-8073158
>     http://cr.openjdk.java.net/~martin/webrevs/openjdk9/0xffff-entries-zip-file/ <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/0xffff-entries-zip-file/>
>
>     Of course, the really correct thing is to have at most one zip implementation per programming language, but I'm not trying to fix that here (how many zip implementations does openjdk have?)
>
>



From vladimir.kozlov at oracle.com  Wed Mar 25 18:43:10 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 25 Mar 2015 11:43:10 -0700
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <55127C35.8000108@redhat.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>	<550A90CE.9080901@redhat.com>
	<550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com>
	<550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com>
	<550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com>
	<550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com>
	<55105C0A.8070305@redhat.com> <55108130.2010207@oracle.com>
	<55111D21.1020502@redhat.com> <5511F5EA.6010102@oracle.com>
	<55127C35.8000108@redhat.com>
Message-ID: <551301BE.2000307@oracle.com>

Looks like only 32-bit is affected. Both Server (C2) and Client (C1) VMs.

64-bit VM pass all combinations: Tiered, C2 only (-TieredCompilation), 
C1 only (-XX:+TieredCompilation -XX:TieredStopAtLevel=1) with and 
without intrinsics.

32-bit Client VM (C1) fails with both, -XX:-UseUnalignedAccesses and 
-XX:+UseUnalignedAccesses.

$ bin/java -client -XX:+UnlockDiagnosticVMOptions 
-XX:-UseUnalignedAccesses HeapByteBufferTest
Exception in thread "main" java.lang.RuntimeException
	at MyByteBuffer.ck(HeapByteBufferTest.java:201)
	at MyByteBuffer.getLong(HeapByteBufferTest.java:211)
	at HeapByteBufferTest.step(HeapByteBufferTest.java:311)
	at HeapByteBufferTest.run(HeapByteBufferTest.java:347)
	at HeapByteBufferTest.main(HeapByteBufferTest.java:362)

$ bin/java -client -XX:+UnlockDiagnosticVMOptions 
-XX:+UseUnalignedAccesses HeapByteBufferTest
Exception in thread "main" java.lang.RuntimeException
	at MyByteBuffer.ck(HeapByteBufferTest.java:201)
	at MyByteBuffer.getLong(HeapByteBufferTest.java:211)
	at HeapByteBufferTest.step(HeapByteBufferTest.java:311)
	at HeapByteBufferTest.run(HeapByteBufferTest.java:347)
	at HeapByteBufferTest.main(HeapByteBufferTest.java:362)

32-bit Server VM without tiered (-TieredCompilation) FAILS too in both 
cases! Note, without intrinsics it failed in different place.

$ bin/java -server -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions 
-XX:-UseUnalignedAccesses HeapByteBufferTest
Exception in thread "main" java.lang.RuntimeException
	at MyByteBuffer.ck(HeapByteBufferTest.java:207)
	at MyByteBuffer.getDouble(HeapByteBufferTest.java:215)
	at HeapByteBufferTest.step(HeapByteBufferTest.java:329)
	at HeapByteBufferTest.run(HeapByteBufferTest.java:347)
	at HeapByteBufferTest.main(HeapByteBufferTest.java:362)

$ bin/java -server -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions 
-XX:+UseUnalignedAccesses HeapByteBufferTest
Exception in thread "main" java.lang.RuntimeException
	at MyByteBuffer.ck(HeapByteBufferTest.java:201)
	at MyByteBuffer.getLong(HeapByteBufferTest.java:211)
	at HeapByteBufferTest.step(HeapByteBufferTest.java:311)
	at HeapByteBufferTest.run(HeapByteBufferTest.java:347)
	at HeapByteBufferTest.main(HeapByteBufferTest.java:362)

For some reasons Server VM only pass when TieredCompilation is enabled.

Looking on -XX:+PrintCompilation -XX:+PrintInlining output I see that 
UseUnalignedAccesses affects intrinsics as designed.

Thanks,
Vladimir

On 3/25/15 2:13 AM, Andrew Haley wrote:
> On 24/03/15 23:40, Vladimir Kozlov wrote:
>
>> The test failed when run it in JPRT with 32-bit fastdebug *Client* VM (-client) on linux-x86:
>>
>> java.lang.RuntimeException
>> 	at MyByteBuffer.ck(HeapByteBufferTest.java:201)
>> 	at MyByteBuffer.getLong(HeapByteBufferTest.java:211)
>> 	at HeapByteBufferTest.step(HeapByteBufferTest.java:311)
>> 	at HeapByteBufferTest.run(HeapByteBufferTest.java:347)
>> 	at HeapByteBufferTest.main(HeapByteBufferTest.java:362)
>>
>> Could be intrinsic in C1 does not work correctly? Please, look.
>
> I certainly will.  That is odd: there's no reason I can think of why
> this might happen, and I know that the test running on a server build
> runs C1 code for a while so it has been tested.  I guess it must be a
> rare edge case.  Still, I'm quite pleased that the test I wrote
> detected the failure.
>
> Do you know if this was running with +UseUnalignedAccesses?
>
> I'm not going to be able to analyse this for a few days.  Expect a
> report (and hopefully a fix) next week.
>
> Thanks,
> Andrew.
>


From chris.hegarty at oracle.com  Wed Mar 25 21:58:31 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 25 Mar 2015 21:58:31 +0000
Subject: RFR [9] 8071472: Add field setter API for setting final fields in
	readObject
In-Reply-To: <5512F120.7030604@gmail.com>
References: <5510351D.1070500@oracle.com> <5512A8E0.6040303@gmail.com>
	<5512D8F0.5030505@oracle.com> <5512E87B.7040108@gmail.com>
	<5512F120.7030604@gmail.com>
Message-ID: <9F7C9799-2AD0-498E-82F5-9EC19CCA78AB@oracle.com>


> On 25 Mar 2015, at 17:32, Peter Levart <peter.levart at gmail.com> wrote:
> 
> On 03/25/2015 05:55 PM, Peter Levart wrote:
>> On 03/25/2015 04:49 PM, Chris Hegarty wrote:
>>>> I have been thinking about this and I see several solutions:
>>>> 
>>>> 1. provide protected final methods
>>>> ObjectInputStream.checkPersistentFinalsNotSet() and
>>>> markPersistentFinalsSet() that just delegate to FieldSetterContext for
>>>> ObjectInputStream classes to call as part of their own overriden
>>>> defaultReadObject() method. We should make sure those methods are called
>>>> in JDK's corba InputStreamHook and document they should be called in 3rd
>>>> party subclasses.
>>> 
>>> Yes, I think I agree with this, but since the FieldSetterContext is constructed in OIS private readSerialData, there is nothing to delegate to, unless InputStreamHook/IIOPInputStream creates the context. 
>> 
>> Ah, I see. Let me look at this in some more detail...
>> 
>> Regards, Peter
>> 
> 
> Huh, this is tricky! IIOPInputStream does invoke readObject/writeObject methods on an object being (de)serialized, but it does it on it's own. So any classes using FieldSetter API will get an exception when attempted deserialization with corba?

It will get NotActiveException, thinking that it is not in a readObject callback <sigh>.

> We could fix IIOPInputStream to do the right thing at the right time (like ObjectInputStream) and provide a FieldSetter instance, but what about any 3rd party ObjectInputStream subclasses that might do the same? Suddenly classes using FieldSetter API will become incompatible with 3rd party OIS implementations until those implementations catch-up.

Yeap.

> Providing a factory for FieldSetter instance to subclasses of OIS is giving write access to private fields of any object. Would have to be protected by some permission. Is this acceptable?

I think it needs to be protected by more than a permission check. The nice thing about the FieldSetter API as it stands ( before this ) is that it is only possible to set final fields during deserialization. I am reluctant about exposing this API further. Whatever changes we make should keep this property.

I?m looking at your previous suggestions, and giving this some thought. Nothing jumping out yet.

-Chris.

> Regards, Peter
> 



From david.lloyd at redhat.com  Wed Mar 25 22:24:03 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 25 Mar 2015 17:24:03 -0500
Subject: RFR [9] 8071472: Add field setter API for setting final fields
	in readObject
In-Reply-To: <9F7C9799-2AD0-498E-82F5-9EC19CCA78AB@oracle.com>
References: <5510351D.1070500@oracle.com>
	<5512A8E0.6040303@gmail.com>	<5512D8F0.5030505@oracle.com>
	<5512E87B.7040108@gmail.com>	<5512F120.7030604@gmail.com>
	<9F7C9799-2AD0-498E-82F5-9EC19CCA78AB@oracle.com>
Message-ID: <55133583.9080202@redhat.com>

On 03/25/2015 04:58 PM, Chris Hegarty wrote:
>
>> On 25 Mar 2015, at 17:32, Peter Levart <peter.levart at gmail.com> wrote:
>>
>> On 03/25/2015 05:55 PM, Peter Levart wrote:
>>> On 03/25/2015 04:49 PM, Chris Hegarty wrote:
>>>>> I have been thinking about this and I see several solutions:
>>>>>
>>>>> 1. provide protected final methods
>>>>> ObjectInputStream.checkPersistentFinalsNotSet() and
>>>>> markPersistentFinalsSet() that just delegate to FieldSetterContext for
>>>>> ObjectInputStream classes to call as part of their own overriden
>>>>> defaultReadObject() method. We should make sure those methods are called
>>>>> in JDK's corba InputStreamHook and document they should be called in 3rd
>>>>> party subclasses.
>>>>
>>>> Yes, I think I agree with this, but since the FieldSetterContext is constructed in OIS private readSerialData, there is nothing to delegate to, unless InputStreamHook/IIOPInputStream creates the context.
>>>
>>> Ah, I see. Let me look at this in some more detail...
>>>
>>> Regards, Peter
>>>
>>
>> Huh, this is tricky! IIOPInputStream does invoke readObject/writeObject methods on an object being (de)serialized, but it does it on it's own. So any classes using FieldSetter API will get an exception when attempted deserialization with corba?
>
> It will get NotActiveException, thinking that it is not in a readObject callback <sigh>.
>
>> We could fix IIOPInputStream to do the right thing at the right time (like ObjectInputStream) and provide a FieldSetter instance, but what about any 3rd party ObjectInputStream subclasses that might do the same? Suddenly classes using FieldSetter API will become incompatible with 3rd party OIS implementations until those implementations catch-up.
>
> Yeap.
>
>> Providing a factory for FieldSetter instance to subclasses of OIS is giving write access to private fields of any object. Would have to be protected by some permission. Is this acceptable?
>
> I think it needs to be protected by more than a permission check. The nice thing about the FieldSetter API as it stands ( before this ) is that it is only possible to set final fields during deserialization. I am reluctant about exposing this API further. Whatever changes we make should keep this property.
>
> I?m looking at your previous suggestions, and giving this some thought. Nothing jumping out yet.

I think this is a sign that this extra check isn't really appropriate, 
or maybe isn't in the appropriate place.  Having a run time check here 
is just "weird", for lack of a better word, given that the equivalent 
constructor check is compile-time.  The author of a class can already 
determine whether they are setting all the fields they want to set; it's 
not like there's generally going to be a confluence of multiple players 
contributing to the set of final fields, or some other complex situation 
like that.

Put another way - the FieldSetter API doesn't *need* this extra check in 
order to justify its existence, especially given these complications. 
If we're just looking for something to replace using reflection to hack 
in final field values, then just having a proper API to do it is already 
enough of an improvement in my mind that I believe that the extra check 
can (and should) be considered as a separate enhancement on top of it, 
if it *must* be considered at all.

-- 
- DML


From martinrb at google.com  Wed Mar 25 23:07:45 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 25 Mar 2015 16:07:45 -0700
Subject: RFR: JDK-8074578 Document memory visibility effects of some
	Unsafe methods
In-Reply-To: <55111A78.5010706@oracle.com>
References: <CA+kOe09JX3duNzd7VcWG8HjpCqwtGoP1kLz=7fdk6eWK57MMPg@mail.gmail.com>
	<54FCEA87.3030509@oracle.com> <54FD6767.8020506@redhat.com>
	<54FD8059.9050205@oracle.com>
	<CA+kOe0-NSsfYwDE6xzquWAe9OVhx389tX27vo5_DUpUSdTEpeQ@mail.gmail.com>
	<54FE4943.1030008@oracle.com> <54FE9DDA.8030301@redhat.com>
	<CA+kOe08JzETEdOR0twbRc5h3RfkZL007iaBEagZYniaR3GVXbA@mail.gmail.com>
	<2608270C-BDD6-4E8F-8D1F-5E6FB0F42BFC@oracle.com>
	<CA+kOe08dR8K2f9Ee2+v=DrG4zmpOjWS=_hRD6rW1JKPqLr0iwA@mail.gmail.com>
	<00CDE96F-D1B3-4E5D-B254-6ED0F0A90D6B@oracle.com>
	<B0BFA8C4-85B8-4DC8-84B0-EACDD8AB386F@oracle.com>
	<55111A78.5010706@oracle.com>
Message-ID: <CA+kOe0-0rmT8VO88a8NpG0s9sxPwsLQvqBScER-QmCMJKRRcLQ@mail.gmail.com>

Thanks all.

(I'm a picky reviewer myself, but sometimes I also approve changes that I
think are "Meh")

On Tue, Mar 24, 2015 at 1:04 AM, David Holmes <david.holmes at oracle.com>
wrote:

> On 24/03/2015 5:55 PM, Paul Sandoz wrote:
>
>> On Mar 24, 2015, at 12:27 AM, John Rose <john.r.rose at oracle.com> wrote:
>>
>>> Meanwhile, Paul Sandoz is working to refactor these aspects, creating a
>>> large chunk of API that will be public, portable, and secure.  You've got
>>> to sympathize with him for not wanting to run through all the inevitable
>>> arguments about concurrency primitives once for Unsafe and once again later
>>> for VarHandles.
>>>
>>
>> Yes, that's it. As i said i am all for it, but sensing disagreement
>> thought it might be best to hold off a bit. I don't wanna block if that
>> disagreement is resolved. In fact i wanna take a swing at some other
>> aspects of Unsafe to clear up the naming of putOrdered* as mooted in an
>> email to hotspot-runtime.
>>
>
> I will defer to John's wisdom on this. These discussions burn a lot of
> cycles with little concrete benefit to be gained.
>
> David
>
>  Paul.
>>
>>


From martinrb at google.com  Wed Mar 25 23:11:09 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 25 Mar 2015 16:11:09 -0700
Subject: RFR: JDK-8073158 zip files with total entry count 0xFFFF need not
	be ZIP64 files
In-Reply-To: <5512F69C.4040003@oracle.com>
References: <CA+kOe0_4rGNW_9u7XdgWb=5Ox685ecC+K++b9Lh6SSpqbse=TQ@mail.gmail.com>
	<CA+kOe08sjL+L3TQ30VXEgaZyCPbKE59NnYR_yAZnu0jPaMFBSw@mail.gmail.com>
	<5512F69C.4040003@oracle.com>
Message-ID: <CA+kOe0917yrsUWPU2SsUgyBEpy+-WCnvu0XooJgJTt7fG-sdvQ@mail.gmail.com>

The Right Thing is to have only one C Zip implementation, shared by
launcher, zip_util, and pack200.  And my change is one step towards that,
but I'm not tackling the big job right now.

On Wed, Mar 25, 2015 at 10:55 AM, Xueming Shen <xueming.shen at oracle.com>
wrote:

>
> It looks fine...I hope you guys also have some tests over there to bring
> in more confidence :-)
>
> It might be "easier" to simply update the original haveZIP64() with the
> code
> we have in zip_util.c in which we also try to read the end64 to verify if
> we
> really have one. Your choice though.
>
> -Sherman
>
>
> On 03/25/2015 09:55 AM, Martin Buchholz wrote:
>
> Yeah, this review is kinda scary.  There's a lot of technical debt here,
> and this change only addresses some of it.
>
>  A variant of this code is in use at Google.
>
> On Mon, Mar 23, 2015 at 1:18 PM, Martin Buchholz <martinrb at google.com>
> wrote:
>
>>  Hi Xueming and Alan,
>>
>>  I'd like you to do a code review.
>>
>>  https://bugs.openjdk.java.net/browse/JDK-8073158
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/0xffff-entries-zip-file/
>>
>>  Of course, the really correct thing is to have at most one zip
>> implementation per programming language, but I'm not trying to fix that
>> here (how many zip implementations does openjdk have?)
>>
>
>
>


From daniel.fuchs at oracle.com  Thu Mar 26 12:08:46 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 26 Mar 2015 13:08:46 +0100
Subject: RFR: 7113878: LogManager - namedLoggers should be ConcurrentHashMap
	instead of Hashtable
Message-ID: <5513F6CE.3040505@oracle.com>

Please find below a trivial fix for


7113878: LogManager - namedLoggers should be ConcurrentHashMap
          instead of Hashtable
https://bugs.openjdk.java.net/browse/JDK-7113878

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

best regards,

-- daniel


From lance.andersen at oracle.com  Thu Mar 26 12:18:36 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 26 Mar 2015 08:18:36 -0400
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <5513F6CE.3040505@oracle.com>
References: <5513F6CE.3040505@oracle.com>
Message-ID: <162265E1-DC28-49E2-B8AD-3E1EF63A36F4@oracle.com>

+1
On Mar 26, 2015, at 8:08 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> Please find below a trivial fix for
> 
> 
> 7113878: LogManager - namedLoggers should be ConcurrentHashMap
>         instead of Hashtable
> https://bugs.openjdk.java.net/browse/JDK-7113878
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.00
> 
> best regards,
> 
> -- daniel



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





From david.holmes at oracle.com  Thu Mar 26 12:28:39 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Mar 2015 22:28:39 +1000
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <5513F6CE.3040505@oracle.com>
References: <5513F6CE.3040505@oracle.com>
Message-ID: <5513FB77.90305@oracle.com>

Hi Daniel,

On 26/03/2015 10:08 PM, Daniel Fuchs wrote:
> Please find below a trivial fix for
>
>
> 7113878: LogManager - namedLoggers should be ConcurrentHashMap
>           instead of Hashtable

As you say in the bug report, now that the map is always accessed within 
synchronized code this serves no purpose. The map not only doesn't need 
to be concurrent, it doesn't even need to be thread-safe! So why not 
replace with a simple HashMap?

David

> https://bugs.openjdk.java.net/browse/JDK-7113878
>
> http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.00
>
> best regards,
>
> -- daniel


From daniel.fuchs at oracle.com  Thu Mar 26 13:32:23 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 26 Mar 2015 14:32:23 +0100
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <5513FB77.90305@oracle.com>
References: <5513F6CE.3040505@oracle.com> <5513FB77.90305@oracle.com>
Message-ID: <55140A67.5040208@oracle.com>

On 26/03/15 13:28, David Holmes wrote:
> Hi Daniel,
>
> On 26/03/2015 10:08 PM, Daniel Fuchs wrote:
>> Please find below a trivial fix for
>>
>>
>> 7113878: LogManager - namedLoggers should be ConcurrentHashMap
>>           instead of Hashtable
>
> As you say in the bug report, now that the map is always accessed within
> synchronized code this serves no purpose. The map not only doesn't need
> to be concurrent, it doesn't even need to be thread-safe! So why not
> replace with a simple HashMap?

You found me out ;-) I should have mentioned it.
The enumeration of keys returned from the map will be iterated
outside of any synchronized block.
ConcurrentHashMap makes this safe.

best regards,

-- daniel


>
> David
>
>> https://bugs.openjdk.java.net/browse/JDK-7113878
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.00
>>
>> best regards,
>>
>> -- daniel



From jason_mehrens at hotmail.com  Thu Mar 26 13:42:25 2015
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 26 Mar 2015 08:42:25 -0500
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <55140A67.5040208@oracle.com>
References: <5513F6CE.3040505@oracle.com>
	<5513FB77.90305@oracle.com>,<55140A67.5040208@oracle.com>
Message-ID: <BLU175-W312006BAD6FA2BC3CB28D783080@phx.gbl>

The snapshot enumeration is a welcomed change.  ConcurrentHashMap has legacy Hashtable methods so you can save a little bit by calling namedLoggers.keys() instead of wrapping the key set.


Jason

----------------------------------------
> Date: Thu, 26 Mar 2015 14:32:23 +0100
> From: daniel.fuchs at oracle.com
> To: david.holmes at oracle.com; core-libs-dev at openjdk.java.net
> Subject: Re: RFR: 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable
>
> On 26/03/15 13:28, David Holmes wrote:
>> Hi Daniel,
>>
>> On 26/03/2015 10:08 PM, Daniel Fuchs wrote:
>>> Please find below a trivial fix for
>>>
>>>
>>> 7113878: LogManager - namedLoggers should be ConcurrentHashMap
>>> instead of Hashtable
>>
>> As you say in the bug report, now that the map is always accessed within
>> synchronized code this serves no purpose. The map not only doesn't need
>> to be concurrent, it doesn't even need to be thread-safe! So why not
>> replace with a simple HashMap?
>
> You found me out ;-) I should have mentioned it.
> The enumeration of keys returned from the map will be iterated
> outside of any synchronized block.
> ConcurrentHashMap makes this safe.
>
> best regards,
>
> -- daniel
>
>
>>
>> David
>>
>>> https://bugs.openjdk.java.net/browse/JDK-7113878
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.00
>>>
>>> best regards,
>>>
>>> -- daniel
> 		 	   		  

From peter.levart at gmail.com  Thu Mar 26 13:43:34 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 26 Mar 2015 14:43:34 +0100
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <5513FB77.90305@oracle.com>
References: <5513F6CE.3040505@oracle.com> <5513FB77.90305@oracle.com>
Message-ID: <55140D06.4030201@gmail.com>

On 03/26/2015 01:28 PM, David Holmes wrote:
> Hi Daniel,
>
> On 26/03/2015 10:08 PM, Daniel Fuchs wrote:
>> Please find below a trivial fix for
>>
>>
>> 7113878: LogManager - namedLoggers should be ConcurrentHashMap
>>           instead of Hashtable
>
> As you say in the bug report, now that the map is always accessed 
> within synchronized code this serves no purpose. The map not only 
> doesn't need to be concurrent, it doesn't even need to be thread-safe! 
> So why not replace with a simple HashMap?
>
> David

Hi Daniel,

...or, if you keep CHM, you might be able to use it for a benefit.

You say that retrieving a logger by name is the most frequent operation. 
If you can prove that moving a statement in addLocalLogger method that 
publishes the Logger via CHM to the end of synchronized block without 
hurting the logic that exists in-between and initializes the Logger 
instance, then you can implement the findLogger method in a way that 
almost never needs to enter synchronized block:

http://cr.openjdk.java.net/~plevart/jdk9-dev/LogManager.CHM/webrev.01/

Regards, Peter

>
>> https://bugs.openjdk.java.net/browse/JDK-7113878
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.00
>>
>> best regards,
>>
>> -- daniel



From daniel.fuchs at oracle.com  Thu Mar 26 13:55:12 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 26 Mar 2015 14:55:12 +0100
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <55140D06.4030201@gmail.com>
References: <5513F6CE.3040505@oracle.com> <5513FB77.90305@oracle.com>
	<55140D06.4030201@gmail.com>
Message-ID: <55140FC0.4060104@oracle.com>

On 26/03/15 14:43, Peter Levart wrote:
> On 03/26/2015 01:28 PM, David Holmes wrote:
>> Hi Daniel,
>>
>> On 26/03/2015 10:08 PM, Daniel Fuchs wrote:
>>> Please find below a trivial fix for
>>>
>>>
>>> 7113878: LogManager - namedLoggers should be ConcurrentHashMap
>>>           instead of Hashtable
>>
>> As you say in the bug report, now that the map is always accessed
>> within synchronized code this serves no purpose. The map not only
>> doesn't need to be concurrent, it doesn't even need to be thread-safe!
>> So why not replace with a simple HashMap?
>>
>> David
>
> Hi Daniel,
>
> ...or, if you keep CHM, you might be able to use it for a benefit.
>
> You say that retrieving a logger by name is the most frequent operation.
> If you can prove that moving a statement in addLocalLogger method that
> publishes the Logger via CHM to the end of synchronized block without
> hurting the logic that exists in-between and initializes the Logger
> instance, then you can implement the findLogger method in a way that
> almost never needs to enter synchronized block:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/LogManager.CHM/webrev.01/

Right. I was also thinking that there may be a way to
use computeIfAbsent to rewrite some of the old logic - but I'd
rather do that in a separate change set.
This is partly why I didn't want to go much more beyond
the simple switch here. I'll keep your idea above in mind though.

Synchronization in LogManager is something that has always proved
to require careful thinking ;-)
Is it OK with you if I log a follow up RFE instead?

best regards

-- daniel
>
> Regards, Peter
>
>>
>>> https://bugs.openjdk.java.net/browse/JDK-7113878
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.00
>>>
>>> best regards,
>>>
>>> -- daniel
>



From daniel.fuchs at oracle.com  Thu Mar 26 13:48:24 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 26 Mar 2015 14:48:24 +0100
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <BLU175-W312006BAD6FA2BC3CB28D783080@phx.gbl>
References: <5513F6CE.3040505@oracle.com> <5513FB77.90305@oracle.com>,
	<55140A67.5040208@oracle.com>
	<BLU175-W312006BAD6FA2BC3CB28D783080@phx.gbl>
Message-ID: <55140E28.70708@oracle.com>

On 26/03/15 14:42, Jason Mehrens wrote:
> The snapshot enumeration is a welcomed change.  ConcurrentHashMap has legacy Hashtable methods so you can save a little bit by calling namedLoggers.keys() instead of wrapping the key set.

Yes - but the enumeration returned by ConcurrentHashMap.keys
is in fact an iterator which will let you remove keys.
I explicitly chose to use Collections.enumeration instead
to prevent providing unintended access.


best regards,

-- daniel

>
>
> Jason
>
> ----------------------------------------
>> Date: Thu, 26 Mar 2015 14:32:23 +0100
>> From: daniel.fuchs at oracle.com
>> To: david.holmes at oracle.com; core-libs-dev at openjdk.java.net
>> Subject: Re: RFR: 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable
>>
>> On 26/03/15 13:28, David Holmes wrote:
>>> Hi Daniel,
>>>
>>> On 26/03/2015 10:08 PM, Daniel Fuchs wrote:
>>>> Please find below a trivial fix for
>>>>
>>>>
>>>> 7113878: LogManager - namedLoggers should be ConcurrentHashMap
>>>> instead of Hashtable
>>>
>>> As you say in the bug report, now that the map is always accessed within
>>> synchronized code this serves no purpose. The map not only doesn't need
>>> to be concurrent, it doesn't even need to be thread-safe! So why not
>>> replace with a simple HashMap?
>>
>> You found me out ;-) I should have mentioned it.
>> The enumeration of keys returned from the map will be iterated
>> outside of any synchronized block.
>> ConcurrentHashMap makes this safe.
>>
>> best regards,
>>
>> -- daniel
>>
>>
>>>
>>> David
>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-7113878
>>>>
>>>> http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.00
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>> 		 	   		



From peter.levart at gmail.com  Thu Mar 26 14:18:40 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 26 Mar 2015 15:18:40 +0100
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <55140FC0.4060104@oracle.com>
References: <5513F6CE.3040505@oracle.com> <5513FB77.90305@oracle.com>
	<55140D06.4030201@gmail.com> <55140FC0.4060104@oracle.com>
Message-ID: <55141540.9050600@gmail.com>

On 03/26/2015 02:55 PM, Daniel Fuchs wrote:
> On 26/03/15 14:43, Peter Levart wrote:
>> On 03/26/2015 01:28 PM, David Holmes wrote:
>>> Hi Daniel,
>>>
>>> On 26/03/2015 10:08 PM, Daniel Fuchs wrote:
>>>> Please find below a trivial fix for
>>>>
>>>>
>>>> 7113878: LogManager - namedLoggers should be ConcurrentHashMap
>>>>           instead of Hashtable
>>>
>>> As you say in the bug report, now that the map is always accessed
>>> within synchronized code this serves no purpose. The map not only
>>> doesn't need to be concurrent, it doesn't even need to be thread-safe!
>>> So why not replace with a simple HashMap?
>>>
>>> David
>>
>> Hi Daniel,
>>
>> ...or, if you keep CHM, you might be able to use it for a benefit.
>>
>> You say that retrieving a logger by name is the most frequent operation.
>> If you can prove that moving a statement in addLocalLogger method that
>> publishes the Logger via CHM to the end of synchronized block without
>> hurting the logic that exists in-between and initializes the Logger
>> instance, then you can implement the findLogger method in a way that
>> almost never needs to enter synchronized block:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/LogManager.CHM/webrev.01/
>
> Right. I was also thinking that there may be a way to
> use computeIfAbsent to rewrite some of the old logic - but I'd
> rather do that in a separate change set.
> This is partly why I didn't want to go much more beyond
> the simple switch here. I'll keep your idea above in mind though.
>
> Synchronization in LogManager is something that has always proved
> to require careful thinking ;-)
> Is it OK with you if I log a follow up RFE instead?

Yes, by all means.

CHM.computeIfAbsent() does use a lock, but it's a lock on a hash-bin, so 
it's tricky if your logic is re-entrant (CHM.computIfAbsent is not 
reentrant). Just exposing a get() without synchronization like I 
proposed in findLogger() should be pretty safe if you do the publication 
of new Logger instance as the last action in addLocalLogger synchronized 
block. Those methods that change state in the context are better left 
synchronized on the context instance as they must do several mutations 
atomically involving various kinds of objects (Nodes, Loggers) that are 
interconnected. And you don't loose much by synchronizing as creating 
new Loggers is not a frequent operation and you can keep the logic plain 
and simple. I think it's only worth optimizing for common case (the 
findLogger()).

Regards, Peter

>
> best regards
>
> -- daniel
>>
>> Regards, Peter
>>
>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-7113878
>>>>
>>>> http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.00
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>
>



From daniel.fuchs at oracle.com  Thu Mar 26 14:24:07 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 26 Mar 2015 15:24:07 +0100
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <55140A67.5040208@oracle.com>
References: <5513F6CE.3040505@oracle.com> <5513FB77.90305@oracle.com>
	<55140A67.5040208@oracle.com>
Message-ID: <55141687.7020206@oracle.com>

On 26/03/15 14:32, Daniel Fuchs wrote:
> The enumeration of keys returned from the map will be iterated
> outside of any synchronized block.
> ConcurrentHashMap makes this safe.

I'm happy to report that the test in the webrev [1] fails in
ConcurrentModificationException if HashMap is used instead
of ConcurrentHashMap :-)

best regards

-- daniel

[1]
http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.00


From kumar.x.srinivasan at oracle.com  Thu Mar 26 14:49:21 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 26 Mar 2015 07:49:21 -0700
Subject: RFR: JDK-8073158 zip files with total entry count 0xFFFF need
	not be ZIP64 files
In-Reply-To: <CA+kOe0917yrsUWPU2SsUgyBEpy+-WCnvu0XooJgJTt7fG-sdvQ@mail.gmail.com>
References: <CA+kOe0_4rGNW_9u7XdgWb=5Ox685ecC+K++b9Lh6SSpqbse=TQ@mail.gmail.com>
	<CA+kOe08sjL+L3TQ30VXEgaZyCPbKE59NnYR_yAZnu0jPaMFBSw@mail.gmail.com>
	<5512F69C.4040003@oracle.com>
	<CA+kOe0917yrsUWPU2SsUgyBEpy+-WCnvu0XooJgJTt7fG-sdvQ@mail.gmail.com>
Message-ID: <55141C71.4010403@oracle.com>

Hi Martin,

In case you have missed it, jdk/test/tools/launcher/BigJar.java
has a suppressed large file test, you might want to enable it
if not already done, I think this test originally came from google
not sure, nevertheless,  a similar one also exists in:
langtools/test/tools/javac/file/zip/T6836682.java

As for the changes I glosssed over it, yea it is scary, but thanks for 
making
the changes.

> The Right Thing is to have only one C Zip implementation, shared by
> launcher, zip_util, and pack200.  And my change is one step towards that,
> but I'm not tackling the big job right now.
+1.



Kumar
>
> On Wed, Mar 25, 2015 at 10:55 AM, Xueming Shen <xueming.shen at oracle.com>
> wrote:
>
>> It looks fine...I hope you guys also have some tests over there to bring
>> in more confidence :-)
>>
>> It might be "easier" to simply update the original haveZIP64() with the
>> code
>> we have in zip_util.c in which we also try to read the end64 to verify if
>> we
>> really have one. Your choice though.
>>
>> -Sherman
>>
>>
>> On 03/25/2015 09:55 AM, Martin Buchholz wrote:
>>
>> Yeah, this review is kinda scary.  There's a lot of technical debt here,
>> and this change only addresses some of it.
>>
>>   A variant of this code is in use at Google.
>>
>> On Mon, Mar 23, 2015 at 1:18 PM, Martin Buchholz <martinrb at google.com>
>> wrote:
>>
>>>   Hi Xueming and Alan,
>>>
>>>   I'd like you to do a code review.
>>>
>>>   https://bugs.openjdk.java.net/browse/JDK-8073158
>>>
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/0xffff-entries-zip-file/
>>>
>>>   Of course, the really correct thing is to have at most one zip
>>> implementation per programming language, but I'm not trying to fix that
>>> here (how many zip implementations does openjdk have?)
>>>
>>
>>



From aleksej.efimov at oracle.com  Thu Mar 26 16:04:33 2015
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Thu, 26 Mar 2015 19:04:33 +0300
Subject: RFR: 8073385: Bad error message on parsing illegal character in XML
	attribute
Message-ID: <55142E11.8080109@oracle.com>

Hi,
Please review the fix for corrupted error messages in XML parser. When 
the XML parser encounters illegal
character the message with incorrect data is generated:
An invalid XML character (Unicode: 0x{2}) was found in the value of 
attribute "{1}" and element is "0".
But it should be like:
An invalid XML character (Unicode: 0x0) was found in the value of 
attribute "attTest" and element is "topElement".
The fix repairs the message generation and it is similar to the code in 
Apache Xerces project.
Testing: JTREG and JPRT tests (with new one) showed no failures with XML 
related tests.

Thanks,
Aleksej

[1] JBS: https://bugs.openjdk.java.net/browse/JDK-8073385
[2] Webrevs:
     jaxp: http://cr.openjdk.java.net/~aefimov/8073385/9/00/jaxp/
     jdk: http://cr.openjdk.java.net/~aefimov/8073385/9/00/jdk/


From aleksej.efimov at oracle.com  Thu Mar 26 15:47:39 2015
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Thu, 26 Mar 2015 18:47:39 +0300
Subject: RFR: 8075667: (tz) Support tzdata2015b
Message-ID: <55142A1B.1070600@oracle.com>

Hi,

Please review the fix for adding the latest tzdata2015b to JDK9.
The JTREG and JPRT tests were executed.
No failures were observed, except one:
test/sun/util/calendar/zi/TestZoneInfo310.java
The failure was caused by the following tzdb rule addition to 
make/data/tzdata/asia:
     +Rule Palestine    2015    max    -    Mar    lastFri    24:00 
  1:00    S
And it was addressed by addition of another piece of workaround code to 
src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.
After this changes the test showed the PASS result.

Thank you,
Aleksej

[1] JBS: https://bugs.openjdk.java.net/browse/JDK-8075667
[2] Webrev: http://cr.openjdk.java.net/~aefimov/tzdata/2015b/9/00


From aleksej.efimov at oracle.com  Thu Mar 26 16:20:58 2015
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Thu, 26 Mar 2015 19:20:58 +0300
Subject: RFR: 8074297: substring in XSLT returns wrong character if string
	contains supplementary chars
Message-ID: <551431EA.5090409@oracle.com>

Hello,
Please review the fix for XSLT 'substring' function that solves the 
problem when string parameter contains supplementary characters.
The 'test/javax/xml/jaxp/transform/8062923/XslSubstringTest.java' test 
was updated to include the test cases for fail behavior. Fixed function 
utilizes the
codePoint functions to calculate String offsets and length, similar to 
'string-length' XSL function.
Testing results: JTREG and JPRT shows no failures with XML related 
tests. Modified test shows no failures.

With Best Regards,
Aleksej

[1] JBS: https://bugs.openjdk.java.net/browse/JDK-8074297
[2] Webrevs:
     jaxp: http://cr.openjdk.java.net/~aefimov/8074297/9/00/jaxp/
     jdk: http://cr.openjdk.java.net/~aefimov/8074297/9/00/jdk/


From martinrb at google.com  Thu Mar 26 17:24:30 2015
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 26 Mar 2015 10:24:30 -0700
Subject: RFR: JDK-8073158 zip files with total entry count 0xFFFF need not
	be ZIP64 files
In-Reply-To: <55141C71.4010403@oracle.com>
References: <CA+kOe0_4rGNW_9u7XdgWb=5Ox685ecC+K++b9Lh6SSpqbse=TQ@mail.gmail.com>
	<CA+kOe08sjL+L3TQ30VXEgaZyCPbKE59NnYR_yAZnu0jPaMFBSw@mail.gmail.com>
	<5512F69C.4040003@oracle.com>
	<CA+kOe0917yrsUWPU2SsUgyBEpy+-WCnvu0XooJgJTt7fG-sdvQ@mail.gmail.com>
	<55141C71.4010403@oracle.com>
Message-ID: <CA+kOe0-oA3Nhy9LoHp5N=NzC+y6Y3AwD4vOvMY6V2C4dvfVfGg@mail.gmail.com>

I just tried another clean rebuild and jtreg on jar/zip and launcher tests
with -ignore:run - no problems on Linux x86.

On Thu, Mar 26, 2015 at 7:49 AM, Kumar Srinivasan <
kumar.x.srinivasan at oracle.com> wrote:

> Hi Martin,
>
> In case you have missed it, jdk/test/tools/launcher/BigJar.java
> has a suppressed large file test, you might want to enable it
> if not already done, I think this test originally came from google
> not sure, nevertheless,  a similar one also exists in:
> langtools/test/tools/javac/file/zip/T6836682.java
>
> As for the changes I glosssed over it, yea it is scary, but thanks for
> making
> the changes.
>
>  The Right Thing is to have only one C Zip implementation, shared by
>> launcher, zip_util, and pack200.  And my change is one step towards that,
>> but I'm not tackling the big job right now.
>>
> +1.
>
>
>
> Kumar
>
>
>> On Wed, Mar 25, 2015 at 10:55 AM, Xueming Shen <xueming.shen at oracle.com>
>> wrote:
>>
>>  It looks fine...I hope you guys also have some tests over there to bring
>>> in more confidence :-)
>>>
>>> It might be "easier" to simply update the original haveZIP64() with the
>>> code
>>> we have in zip_util.c in which we also try to read the end64 to verify if
>>> we
>>> really have one. Your choice though.
>>>
>>> -Sherman
>>>
>>>
>>> On 03/25/2015 09:55 AM, Martin Buchholz wrote:
>>>
>>> Yeah, this review is kinda scary.  There's a lot of technical debt here,
>>> and this change only addresses some of it.
>>>
>>>   A variant of this code is in use at Google.
>>>
>>> On Mon, Mar 23, 2015 at 1:18 PM, Martin Buchholz <martinrb at google.com>
>>> wrote:
>>>
>>>    Hi Xueming and Alan,
>>>>
>>>>   I'd like you to do a code review.
>>>>
>>>>   https://bugs.openjdk.java.net/browse/JDK-8073158
>>>>
>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/
>>>> 0xffff-entries-zip-file/
>>>>
>>>>   Of course, the really correct thing is to have at most one zip
>>>> implementation per programming language, but I'm not trying to fix that
>>>> here (how many zip implementations does openjdk have?)
>>>>
>>>>
>>>
>>>
>


From srikanth.adayapalam at oracle.com  Thu Mar 26 06:55:03 2015
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Thu, 26 Mar 2015 12:25:03 +0530
Subject: RFR 8076039: Remove the unused internal API
	sun.reflect.misc.FieldUtil.getDeclaredFields
Message-ID: <5513AD47.2080407@oracle.com>

Greetings,

Please review this patch to remove the said unused internal API - this 
has been
reviewed by a couple of engineers already and is now submitted now for 
wider
review. I have built JDK on all platforms and ran the tests to make sure 
this is safe.

JBS:        https://bugs.openjdk.java.net/browse/JDK-8076039
Webrev: http://cr.openjdk.java.net/~sadayapalam/8076039/webrev/

Thanks!
Srikanth


From mandy.chung at oracle.com  Thu Mar 26 17:51:10 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 26 Mar 2015 10:51:10 -0700
Subject: RFR 8076039: Remove the unused internal API
	sun.reflect.misc.FieldUtil.getDeclaredFields
In-Reply-To: <5513AD47.2080407@oracle.com>
References: <5513AD47.2080407@oracle.com>
Message-ID: <5514470E.7020401@oracle.com>

On 3/25/15 11:55 PM, Srikanth wrote:
> Greetings,
>
> Please review this patch to remove the said unused internal API - this 
> has been
> reviewed by a couple of engineers already and is now submitted now for 
> wider
> review. I have built JDK on all platforms and ran the tests to make 
> sure this is safe.
>
> JBS:        https://bugs.openjdk.java.net/browse/JDK-8076039
> Webrev: http://cr.openjdk.java.net/~sadayapalam/8076039/webrev/

Looks fine to me.  I can sponsor and push this patch for you.

Mandy



From daniel.fuchs at oracle.com  Thu Mar 26 18:11:36 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 26 Mar 2015 19:11:36 +0100
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <55141540.9050600@gmail.com>
References: <5513F6CE.3040505@oracle.com> <5513FB77.90305@oracle.com>
	<55140D06.4030201@gmail.com> <55140FC0.4060104@oracle.com>
	<55141540.9050600@gmail.com>
Message-ID: <55144BD8.30403@oracle.com>

On 26/03/15 15:18, Peter Levart wrote:
> On 03/26/2015 02:55 PM, Daniel Fuchs wrote:
>> On 26/03/15 14:43, Peter Levart wrote:
>>> On 03/26/2015 01:28 PM, David Holmes wrote:
>>>> Hi Daniel,
>>>>
>>>> On 26/03/2015 10:08 PM, Daniel Fuchs wrote:
>>>>> Please find below a trivial fix for
>>>>>
>>>>>
>>>>> 7113878: LogManager - namedLoggers should be ConcurrentHashMap
>>>>>           instead of Hashtable
>>>>
>>>> As you say in the bug report, now that the map is always accessed
>>>> within synchronized code this serves no purpose. The map not only
>>>> doesn't need to be concurrent, it doesn't even need to be thread-safe!
>>>> So why not replace with a simple HashMap?
>>>>
>>>> David
>>>
>>> Hi Daniel,
>>>
>>> ...or, if you keep CHM, you might be able to use it for a benefit.
>>>
>>> You say that retrieving a logger by name is the most frequent operation.
>>> If you can prove that moving a statement in addLocalLogger method that
>>> publishes the Logger via CHM to the end of synchronized block without
>>> hurting the logic that exists in-between and initializes the Logger
>>> instance, then you can implement the findLogger method in a way that
>>> almost never needs to enter synchronized block:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/LogManager.CHM/webrev.01/
>>
>> Right. I was also thinking that there may be a way to
>> use computeIfAbsent to rewrite some of the old logic - but I'd
>> rather do that in a separate change set.
>> This is partly why I didn't want to go much more beyond
>> the simple switch here. I'll keep your idea above in mind though.
>>
>> Synchronization in LogManager is something that has always proved
>> to require careful thinking ;-)
>> Is it OK with you if I log a follow up RFE instead?
>
> Yes, by all means.
>
> CHM.computeIfAbsent() does use a lock, but it's a lock on a hash-bin, so
> it's tricky if your logic is re-entrant (CHM.computIfAbsent is not
> reentrant). Just exposing a get() without synchronization like I
> proposed in findLogger() should be pretty safe if you do the publication
> of new Logger instance as the last action in addLocalLogger synchronized
> block. Those methods that change state in the context are better left
> synchronized on the context instance as they must do several mutations
> atomically involving various kinds of objects (Nodes, Loggers) that are
> interconnected. And you don't loose much by synchronizing as creating
> new Loggers is not a frequent operation and you can keep the logic plain
> and simple. I think it's only worth optimizing for common case (the
> findLogger()).


Hi Peter,

OK - you almost convinced me. I'm experimenting your idea.
There are a few tricky parts - such as moving the publication
of the logger to the last statement in addLocalLogger, but
fortunately some of the existing tests catch that if you
do it wrong ;-)

That said, the 'common' case is - I think - to call
Logger.getLogger() only once when you create the logger.
So in that common case, findLogger finds nothing - but then
addLocalLogger is called and so synchronization still has to
happen.

I'll send an updated webrev if I see that tests on all platform
succeed. We can then decide whether that's worth it :-)

Thanks for the reviews and ideas!

-- daniel


>
> Regards, Peter
>
>>
>> best regards
>>
>> -- daniel
>>>
>>> Regards, Peter
>>>
>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-7113878
>>>>>
>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.00
>>>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>
>>
>



From lance.andersen at oracle.com  Thu Mar 26 19:08:49 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 26 Mar 2015 15:08:49 -0400
Subject: Review request for JDK-8051560: JAXP function astro tests
	conversion
In-Reply-To: <033901d066de$f371f8d0$da55ea70$@oracle.com>
References: <033901d066de$f371f8d0$da55ea70$@oracle.com>
Message-ID: <DF31FB1C-5E59-4614-A401-ABD8AA217242@oracle.com>

Hi Frank,

Overall these look fine.  I would suggest adding a simple comment to describe the tests that do not have one to give a basic intent of the test to make it easier for someone to  understand if they are new.

Best
Lance
On Mar 25, 2015, at 5:34 AM, Frank Yuan <frank.yuan at oracle.com> wrote:

> Hi, Joe and All
> 
> 
> 
> We are working on moving internal jaxp functional tests to open jdk repo.
> 
> This is the astro suite. Would you please review these test?  Any comment
> will be appreciated.
> 
> 
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8051560
> 
> webrev: http://cr.openjdk.java.net/~fyuan/8051560/webrev.00/
> 
> 
> 
> AstroTest is the primary test in this suite, it transforms an xml file(which
> includes astro data) with several xsl files, sets different filtering
> condition by these xsl files and different filtering range, finally compares
> the result with golden files. 
> 
> And there are 5 permutations of InputSourceFactory and FilterFactory(I uses
> template method pattern for the variant FilterFactoryImpls), each
> permutation will be applied to above transforming processes.
> 
> 
> 
> Thanks,
> 
> 
> 
> Frank
> 



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 mikhail.cherkasov at oracle.com  Thu Mar 26 19:32:14 2015
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Thu, 26 Mar 2015 22:32:14 +0300
Subject: [8] RFR of 8066985: Java Webstart downloading packed files can
	result in Timezone set to UTC
In-Reply-To: <5512D20D.4070709@oracle.com>
References: <550976B9.6030503@oracle.com> <5509F73C.6000306@oracle.com>
	<550AD4C9.9030905@oracle.com> <550AEF48.4070904@gmail.com>
	<550AF969.7070706@gmail.com> <550C36FD.701@oracle.com>
	<5511C5BE.2010809@oracle.com> <5511E9CB.7050504@oracle.com>
	<5512850F.90701@oracle.com> <5512D20D.4070709@oracle.com>
Message-ID: <55145EBE.7070005@oracle.com>


On 3/25/2015 6:19 PM, Kumar Srinivasan wrote:
> should we throttle/adapt the test on the number of processors available
> using Runtime.availableProcessors() ?
Like this http://cr.openjdk.java.net/~mcherkas/8066985/webrev.07 ?




From huizhe.wang at oracle.com  Fri Mar 27 00:01:34 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 26 Mar 2015 17:01:34 -0700
Subject: RFR: 8074297: substring in XSLT returns wrong character if string
	contains supplementary chars
In-Reply-To: <551431EA.5090409@oracle.com>
References: <551431EA.5090409@oracle.com>
Message-ID: <55149DDE.2070204@oracle.com>

Hi Aleksej,

Looks good.

Thanks,
Joe

On 3/26/2015 9:20 AM, Aleksej Efimov wrote:
> Hello,
> Please review the fix for XSLT 'substring' function that solves the 
> problem when string parameter contains supplementary characters.
> The 'test/javax/xml/jaxp/transform/8062923/XslSubstringTest.java' test 
> was updated to include the test cases for fail behavior. Fixed 
> function utilizes the
> codePoint functions to calculate String offsets and length, similar to 
> 'string-length' XSL function.
> Testing results: JTREG and JPRT shows no failures with XML related 
> tests. Modified test shows no failures.
>
> With Best Regards,
> Aleksej
>
> [1] JBS: https://bugs.openjdk.java.net/browse/JDK-8074297
> [2] Webrevs:
>     jaxp: http://cr.openjdk.java.net/~aefimov/8074297/9/00/jaxp/
>     jdk: http://cr.openjdk.java.net/~aefimov/8074297/9/00/jdk/



From huizhe.wang at oracle.com  Fri Mar 27 01:01:31 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 26 Mar 2015 18:01:31 -0700
Subject: Review request for JDK-8051560: JAXP function astro tests
	conversion
In-Reply-To: <DF31FB1C-5E59-4614-A401-ABD8AA217242@oracle.com>
References: <033901d066de$f371f8d0$da55ea70$@oracle.com>
	<DF31FB1C-5E59-4614-A401-ABD8AA217242@oracle.com>
Message-ID: <5514ABEB.9060501@oracle.com>

I second Lance. The Main of the original astro had Javadocs and 
developer comments. Probably more important is that you've completely 
changed the main classes (TestDriver and Main), which looks good, 
however, the original classes contained a lot of information on what 
each test does and how it works that seem to have all been lost.

The suite's README and build.xml may also contain information that is 
worth keeping. Some of them may be no longer valid, in which case, it 
may be helpful to describe the change. For example, the log files 
described in README were useful for debugging. It would be good to 
explain where to find the debug info in your new design.

While scanning the test, I see that you are creating temporary output 
files under USER_DIR. Is that intended? JAXP processors do not 
necessarily open them with the DELETE_ON_CLOSE option. I thought in 
previous tests, you were creating them in the scratch directory.

Thanks,
Joe

On 3/26/2015 12:08 PM, Lance Andersen wrote:
> Hi Frank,
>
> Overall these look fine.  I would suggest adding a simple comment to 
> describe the tests that do not have one to give a basic intent of the 
> test to make it easier for someone to  understand if they are new.
>
> Best
> Lance
> On Mar 25, 2015, at 5:34 AM, Frank Yuan <frank.yuan at oracle.com 
> <mailto:frank.yuan at oracle.com>> wrote:
>
>> Hi, Joe and All
>>
>>
>>
>> We are working on moving internal jaxp functional tests to open jdk repo.
>>
>> This is the astro suite. Would you please review these test?  Any comment
>> will be appreciated.
>>
>>
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8051560
>>
>> webrev: http://cr.openjdk.java.net/~fyuan/8051560/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Efyuan/8051560/webrev.00/>
>>
>>
>>
>> AstroTest is the primary test in this suite, it transforms an xml 
>> file(which
>> includes astro data) with several xsl files, sets different filtering
>> condition by these xsl files and different filtering range, finally 
>> compares
>> the result with golden files.
>>
>> And there are 5 permutations of InputSourceFactory and 
>> FilterFactory(I uses
>> template method pattern for the variant FilterFactoryImpls), each
>> permutation will be applied to above transforming processes.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Frank
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>



From huizhe.wang at oracle.com  Fri Mar 27 01:17:40 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 26 Mar 2015 18:17:40 -0700
Subject: Review request for JDK-8051560: JAXP function astro tests
	conversion
In-Reply-To: <5514ABEB.9060501@oracle.com>
References: <033901d066de$f371f8d0$da55ea70$@oracle.com>
	<DF31FB1C-5E59-4614-A401-ABD8AA217242@oracle.com>
	<5514ABEB.9060501@oracle.com>
Message-ID: <5514AFB4.6010806@oracle.com>

Please also describe the mapping of the original tests and the new ones 
so that we are sure no test cases are lost in the transition.

Thanks,
Joe

On 3/26/2015 6:01 PM, huizhe wang wrote:
> I second Lance. The Main of the original astro had Javadocs and 
> developer comments. Probably more important is that you've completely 
> changed the main classes (TestDriver and Main), which looks good, 
> however, the original classes contained a lot of information on what 
> each test does and how it works that seem to have all been lost.
>
> The suite's README and build.xml may also contain information that is 
> worth keeping. Some of them may be no longer valid, in which case, it 
> may be helpful to describe the change. For example, the log files 
> described in README were useful for debugging. It would be good to 
> explain where to find the debug info in your new design.
>
> While scanning the test, I see that you are creating temporary output 
> files under USER_DIR. Is that intended? JAXP processors do not 
> necessarily open them with the DELETE_ON_CLOSE option. I thought in 
> previous tests, you were creating them in the scratch directory.
>
> Thanks,
> Joe
>
> On 3/26/2015 12:08 PM, Lance Andersen wrote:
>> Hi Frank,
>>
>> Overall these look fine.  I would suggest adding a simple comment to 
>> describe the tests that do not have one to give a basic intent of the 
>> test to make it easier for someone to understand if they are new.
>>
>> Best
>> Lance
>> On Mar 25, 2015, at 5:34 AM, Frank Yuan <frank.yuan at oracle.com 
>> <mailto:frank.yuan at oracle.com>> wrote:
>>
>>> Hi, Joe and All
>>>
>>>
>>>
>>> We are working on moving internal jaxp functional tests to open jdk 
>>> repo.
>>>
>>> This is the astro suite. Would you please review these test? Any 
>>> comment
>>> will be appreciated.
>>>
>>>
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8051560
>>>
>>> webrev: http://cr.openjdk.java.net/~fyuan/8051560/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Efyuan/8051560/webrev.00/>
>>>
>>>
>>>
>>> AstroTest is the primary test in this suite, it transforms an xml 
>>> file(which
>>> includes astro data) with several xsl files, sets different filtering
>>> condition by these xsl files and different filtering range, finally 
>>> compares
>>> the result with golden files.
>>>
>>> And there are 5 permutations of InputSourceFactory and 
>>> FilterFactory(I uses
>>> template method pattern for the variant FilterFactoryImpls), each
>>> permutation will be applied to above transforming processes.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Frank
>>>
>>
>> <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 masayoshi.okutsu at oracle.com  Fri Mar 27 04:13:15 2015
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 27 Mar 2015 13:13:15 +0900
Subject: <i18n dev> RFR: 8075667: (tz) Support tzdata2015b
In-Reply-To: <55142A1B.1070600@oracle.com>
References: <55142A1B.1070600@oracle.com>
Message-ID: <5514D8DB.1010204@oracle.com>

Looks good except that data changes keep requiring additional workaround 
to the run-time code. We do need a fix for JDK-8014468.

Masayoshi

On 3/27/2015 12:47 AM, Aleksej Efimov wrote:
> Hi,
>
> Please review the fix for adding the latest tzdata2015b to JDK9.
> The JTREG and JPRT tests were executed.
> No failures were observed, except one:
> test/sun/util/calendar/zi/TestZoneInfo310.java
> The failure was caused by the following tzdb rule addition to 
> make/data/tzdata/asia:
>     +Rule Palestine    2015    max    -    Mar    lastFri    24:00 
>  1:00    S
> And it was addressed by addition of another piece of workaround code 
> to src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.
> After this changes the test showed the PASS result.
>
> Thank you,
> Aleksej
>
> [1] JBS: https://bugs.openjdk.java.net/browse/JDK-8075667
> [2] Webrev: http://cr.openjdk.java.net/~aefimov/tzdata/2015b/9/00



From daniel.fuchs at oracle.com  Fri Mar 27 11:27:04 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 27 Mar 2015 12:27:04 +0100
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <55141540.9050600@gmail.com>
References: <5513F6CE.3040505@oracle.com> <5513FB77.90305@oracle.com>
	<55140D06.4030201@gmail.com> <55140FC0.4060104@oracle.com>
	<55141540.9050600@gmail.com>
Message-ID: <55153E88.7070200@oracle.com>

On 26/03/15 15:18, Peter Levart wrote:
>>> Hi Daniel,
>>>
>>> ...or, if you keep CHM, you might be able to use it for a benefit.
>>>
>>> You say that retrieving a logger by name is the most frequent operation.
>>> If you can prove that moving a statement in addLocalLogger method that
>>> publishes the Logger via CHM to the end of synchronized block without
>>> hurting the logic that exists in-between and initializes the Logger
>>> instance, then you can implement the findLogger method in a way that
>>> almost never needs to enter synchronized block:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/LogManager.CHM/webrev.01/
>>
>> Right. I was also thinking that there may be a way to
>> use computeIfAbsent to rewrite some of the old logic - but I'd
>> rather do that in a separate change set.
>> This is partly why I didn't want to go much more beyond
>> the simple switch here. I'll keep your idea above in mind though.
>>
>> Synchronization in LogManager is something that has always proved
>> to require careful thinking ;-)
>> Is it OK with you if I log a follow up RFE instead?
>
> Yes, by all means.
>
> CHM.computeIfAbsent() does use a lock, but it's a lock on a hash-bin, so
> it's tricky if your logic is re-entrant (CHM.computIfAbsent is not
> reentrant). Just exposing a get() without synchronization like I
> proposed in findLogger() should be pretty safe if you do the publication
> of new Logger instance as the last action in addLocalLogger synchronized
> block. Those methods that change state in the context are better left
> synchronized on the context instance as they must do several mutations
> atomically involving various kinds of objects (Nodes, Loggers) that are
> interconnected. And you don't loose much by synchronizing as creating
> new Loggers is not a frequent operation and you can keep the logic plain
> and simple. I think it's only worth optimizing for common case (the
> findLogger()).

Here is a new webrev - with Peter's suggestion implemented.
I also made a few tweaks to the test.

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

best regards,

-- daniel

>
> Regards, Peter
>
>>
>> best regards
>>
>> -- daniel
>>>
>>> Regards, Peter
>>>
>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-7113878
>>>>>
>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.00
>>>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>
>>



From peter.levart at gmail.com  Fri Mar 27 12:49:03 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 27 Mar 2015 13:49:03 +0100
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <55153E88.7070200@oracle.com>
References: <5513F6CE.3040505@oracle.com> <5513FB77.90305@oracle.com>
	<55140D06.4030201@gmail.com> <55140FC0.4060104@oracle.com>
	<55141540.9050600@gmail.com> <55153E88.7070200@oracle.com>
Message-ID: <551551BF.8040902@gmail.com>

On 03/27/2015 12:27 PM, Daniel Fuchs wrote:
> On 26/03/15 15:18, Peter Levart wrote:
>>>> Hi Daniel,
>>>>
>>>> ...or, if you keep CHM, you might be able to use it for a benefit.
>>>>
>>>> You say that retrieving a logger by name is the most frequent 
>>>> operation.
>>>> If you can prove that moving a statement in addLocalLogger method that
>>>> publishes the Logger via CHM to the end of synchronized block without
>>>> hurting the logic that exists in-between and initializes the Logger
>>>> instance, then you can implement the findLogger method in a way that
>>>> almost never needs to enter synchronized block:
>>>>
>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/LogManager.CHM/webrev.01/
>>>
>>> Right. I was also thinking that there may be a way to
>>> use computeIfAbsent to rewrite some of the old logic - but I'd
>>> rather do that in a separate change set.
>>> This is partly why I didn't want to go much more beyond
>>> the simple switch here. I'll keep your idea above in mind though.
>>>
>>> Synchronization in LogManager is something that has always proved
>>> to require careful thinking ;-)
>>> Is it OK with you if I log a follow up RFE instead?
>>
>> Yes, by all means.
>>
>> CHM.computeIfAbsent() does use a lock, but it's a lock on a hash-bin, so
>> it's tricky if your logic is re-entrant (CHM.computIfAbsent is not
>> reentrant). Just exposing a get() without synchronization like I
>> proposed in findLogger() should be pretty safe if you do the publication
>> of new Logger instance as the last action in addLocalLogger synchronized
>> block. Those methods that change state in the context are better left
>> synchronized on the context instance as they must do several mutations
>> atomically involving various kinds of objects (Nodes, Loggers) that are
>> interconnected. And you don't loose much by synchronizing as creating
>> new Loggers is not a frequent operation and you can keep the logic plain
>> and simple. I think it's only worth optimizing for common case (the
>> findLogger()).
>
> Here is a new webrev - with Peter's suggestion implemented.
> I also made a few tweaks to the test.
>
> http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.01/
>
> best regards,
>
> -- daniel

Hi Daniel,

This looks good.

Regarding what is most frequent use of Logger, typical use pattern is:


public class SomeClass {
     private static final Logger log = 
Logger.getLogger(SomeClass.class.getName());


...so in this case findLogger() is only called once, returns null and 
Logger is then created within a synchronized block. What we did here 
does not make much difference in this case. Loggers are numbered in 
quantities that are similar to # of classes: 10s, 100s, 1000s, not much 
more. So synchronization is only relevant for start-up performance.


But I've seen code like this too:

     Logger.getLogger(SomeClass.class.getName()).info(...);

This code was not very scalable before, but with this patch it is.


Regards, Peter



>
>>
>> Regards, Peter
>>
>>>
>>> best regards
>>>
>>> -- daniel
>>>>
>>>> Regards, Peter
>>>>
>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-7113878
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.00
>>>>>>
>>>>>> best regards,
>>>>>>
>>>>>> -- daniel
>>>>
>>>
>



From lev.priima at oracle.com  Fri Mar 27 14:56:51 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Fri, 27 Mar 2015 17:56:51 +0300
Subject: RFR: 8071571: Move substring of same string to slow path
Message-ID: <55156FB3.1080006@oracle.com>

Please review small cleanup in java.lang.String:

Issue: https://bugs.openjdk.java.net/browse/JDK-8071571
Webrev: http://cr.openjdk.java.net/~lpriima/8071571/0/webrev/

46 tests from jdk9/dev/jdk/test/java/lang/String* passed locally.

-- 
Lev



From ivan.gerasimov at oracle.com  Fri Mar 27 15:17:27 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 27 Mar 2015 18:17:27 +0300
Subject: RFR: 8071571: Move substring of same string to slow path
In-Reply-To: <55156FB3.1080006@oracle.com>
References: <55156FB3.1080006@oracle.com>
Message-ID: <55157487.10108@oracle.com>

Hi Lev!

Why don't you want to also simplify String#trim()?
-        return ((st > 0) || (len < value.length)) ? substring(st, len) 
: this;
+        return substring(st, len);

I guess, the situation when a string *is* trimmed, i.e. substring() is 
called is more common.
In that case we have a couple of duplicating condition checks (they're 
going to be performed in substring() anyways) plus the cost of a branch.

Sincerely yours,
Ivan


On 27.03.2015 17:56, Lev Priima wrote:
> Please review small cleanup in java.lang.String:
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8071571
> Webrev: http://cr.openjdk.java.net/~lpriima/8071571/0/webrev/
>
> 46 tests from jdk9/dev/jdk/test/java/lang/String* passed locally.
>



From chris.hegarty at oracle.com  Fri Mar 27 15:41:42 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 27 Mar 2015 15:41:42 +0000
Subject: RFR [9] 8071472: Add field setter API for setting final fields
	in readObject
In-Reply-To: <55133583.9080202@redhat.com>
References: <5510351D.1070500@oracle.com>	<5512A8E0.6040303@gmail.com>	<5512D8F0.5030505@oracle.com>	<5512E87B.7040108@gmail.com>	<5512F120.7030604@gmail.com>	<9F7C9799-2AD0-498E-82F5-9EC19CCA78AB@oracle.com>
	<55133583.9080202@redhat.com>
Message-ID: <55157A36.3040406@oracle.com>

Just an update on this...

Checking of final fields aside, the Field Setter API, in its current 
form, has become stuck. It falls foul of the fact that ObjectInputStream 
is subclass-able, and contains almost no final methods, or at least no 
implementation that can be counted on, or appropriate hooks that can be 
used.

In its current form, the FieldSetter context is created just before the 
readObject callback, and subsequently rendered effectively useless after 
the callback. This is an important part of the design as it limits the 
ability to setting final fields to the object currently being 
deserialized, and just during the execution of the readObject method. 
There is no, straight forward, way to create the FieldSetter context if 
a subclass of ObjectInputStream were to override all its overridable 
methods and not invoke the equivalent superclass method. This is what 
[IIOP]InputStream[Hook] does, and is a realistic possibility for any 
external third party ObjectInputStream implementation.

So, without any modification a third party ObjectInputStream could not 
retrieve the FieldSetter. The API would have to return null, or throw 
UOE ( or similar ). Therefore the API becomes optional, and cannot be 
reliable used in readObject implementations, that need to be 
reconstructible by any ObjectInputStream.

Note: it is possible to add a suitably protected mechanism to allow 
subclasses to create the FieldSetter context, but again that would be 
opt-in ( it would require third party ObjectInputStream implementations 
to change their code ).

Peter and I are still investigating other, more exotic, possibilities, 
but nothing concrete so far.

-Chris.


On 25/03/15 22:24, David M. Lloyd wrote:
> ....
>
> I think this is a sign that this extra check isn't really appropriate,
> or maybe isn't in the appropriate place.  Having a run time check here
> is just "weird", for lack of a better word, given that the equivalent
> constructor check is compile-time.  The author of a class can already
> determine whether they are setting all the fields they want to set; it's
> not like there's generally going to be a confluence of multiple players
> contributing to the set of final fields, or some other complex situation
> like that.
>
> Put another way - the FieldSetter API doesn't *need* this extra check in
> order to justify its existence, especially given these complications. If
> we're just looking for something to replace using reflection to hack in
> final field values, then just having a proper API to do it is already
> enough of an improvement in my mind that I believe that the extra check
> can (and should) be considered as a separate enhancement on top of it,
> if it *must* be considered at all.
>


From kumar.x.srinivasan at oracle.com  Fri Mar 27 15:59:01 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 27 Mar 2015 08:59:01 -0700
Subject: [8] RFR of 8066985: Java Webstart downloading packed files can
	result in Timezone set to UTC
In-Reply-To: <55145EBE.7070005@oracle.com>
References: <550976B9.6030503@oracle.com> <5509F73C.6000306@oracle.com>
	<550AD4C9.9030905@oracle.com> <550AEF48.4070904@gmail.com>
	<550AF969.7070706@gmail.com> <550C36FD.701@oracle.com>
	<5511C5BE.2010809@oracle.com> <5511E9CB.7050504@oracle.com>
	<5512850F.90701@oracle.com> <5512D20D.4070709@oracle.com>
	<55145EBE.7070005@oracle.com>
Message-ID: <55157E45.1030204@oracle.com>


On 3/26/2015 12:32 PM, mikhail cherkasov wrote:
>
> On 3/25/2015 6:19 PM, Kumar Srinivasan wrote:
>> should we throttle/adapt the test on the number of processors available
>> using Runtime.availableProcessors() ?
> Like this http://cr.openjdk.java.net/~mcherkas/8066985/webrev.07 ?
yes that will work!, also why aren't all  these final ?

   45
   46     private static TimeZone tz = TimeZone.getTimeZone("Europe/Moscow");
   47     private static final int INIT_THREAD_COUNT = Math.min(4, Runtime.getRuntime().availableProcessors());
   48     private static final int MAX_THREAD_COUNT = 4 * INIT_THREAD_COUNT;
   49     private static long MINUTE = 60 * 1000;

Once you make these changes, and post the final webrev, I will
ask for 8u approval.

Thanks

Kumar

>
>



From daniel.fuchs at oracle.com  Fri Mar 27 16:18:45 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 27 Mar 2015 17:18:45 +0100
Subject: RFR: 8075810: LogManager.readConfiguration may throw undocumented
	IllegalArgumentException
In-Reply-To: <55129EE6.5020407@oracle.com>
References: <551177D7.5060203@oracle.com>,
	<938960BA-2827-417B-87AE-A1994A6B2AD4@oracle.com>,
	<55117D87.9040708@oracle.com>	<BLU175-W3CA9B09E1C8C11B7B6F2E830A0@phx.gbl>
	<55129EE6.5020407@oracle.com>
Message-ID: <551582E5.7040100@oracle.com>

Hi,

I received private feedback that using plain IOException
might be preferable to using CharConversionException, as
that doesn't exactly reflect what is going on here.

So here is my new webrev - which includes the minor formatting
issues found by Jason, but reverts to using plain IOException:

http://cr.openjdk.java.net/~dfuchs/webrev_8075810/webrev.02

If I don't hear negative feedback that's what I'm going to
present to CCC.

best regards,

-- daniel

On 25/03/15 12:41, Daniel Fuchs wrote:
> Thanks for the review Jason!
>
> On 24/03/15 18:01, Jason Mehrens wrote:
>> Hi Daniel,
>>
>> Looks good.  The only other alternative would be to use
>> java.io.CharConversionException over IOException.  We could even
>> consider dropping the cause because the subclass of I/O exception
>> would convey the same meaning.
>
> Here is a an updated webrev where I use
> java.io.CharConversionException instead of plain IOException.
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8075810/webrev.01/
>
> Note: I had a look in the JDK sources and CharConversionException
> doesn't appear to be widely used. Is this the better alternative?
> I'd be happy with both (webrev.01 or webrev.00).
> Using CharConversionException means that we have to trust that
> Properties.load will obey its spec and only throw IAE in case
> of character conversion issues.
>
>> Minor formatting issues with a missing space after the catch keyword
>
> Done. Thanks for catching it.
>
>> and missing a tab ahead of 'props.load'
>
> That is an artifact of how webrev calls diff I think.
> If you look at the frames version you will see that the tab is here.
>
> best regards,
>
> -- daniel
>
>>
>> Jason
>>
>>
>> ----------------------------------------
>>> Date: Tue, 24 Mar 2015 16:06:47 +0100
>>> From: daniel.fuchs at oracle.com
>>> To: lance.andersen at oracle.com
>>> Subject: Re: RFR: 8075810: LogManager.readConfiguration may throw
>>> undocumented IllegalArgumentException
>>> CC: core-libs-dev at openjdk.java.net
>>>
>>> Hi Lance,
>>>
>>> Thanks for the review!
>>>
>>> On 24/03/15 16:01, Lance Andersen wrote:
>>>> Hi Daniel,
>>>>
>>>> This looks OK but I might suggest clarifying that the cause could be
>>>> set
>>>> in the javadoc. Now that being said, I am not sure how consistent we
>>>> are across the JDK or just make the assumption people will check the
>>>> cause if they desire.
>>>
>>> Hmmm. I have the feeling that the best place for that would be i the
>>> release notes - rather than in the API doc (which reminds me I should
>>> plan to add some release note text to the issue).
>>>
>>>> As far as backporting, unless it really needed, I would probably would
>>>> not as a change such as this typically should be done as part of an
>>>> errata/MR (due to change of behavior and it is not that big of an
>>>> issue).
>>>
>>> Right, my thinking too. Thanks for sharing your opinion!
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>>>
>>>> Best
>>>> Lance
>>>> On Mar 24, 2015, at 10:42 AM, Daniel Fuchs <daniel.fuchs at oracle.com
>>>> <mailto:daniel.fuchs at oracle.com>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Please find below a fix for
>>>>>
>>>>> 8075810: LogManager.readConfiguration may throw
>>>>> undocumented IllegalArgumentException
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8075810
>>>>>
>>>>> The proposed fix is to catch the IllegalArgumentException and
>>>>> wrap it in an IOException, since LogManager.readConfiguration
>>>>> is specified to throw IOException "if there are problems reading
>>>>> from the stream."
>>>>>
>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8075810/webrev.00/
>>>>>
>>>>> Initial discussion around the issue can be seen here:
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032348.html
>>>>>
>>>>>
>>>>> Question for reviewers: I will log a CCC for this - but I am wondering
>>>>> whether I should plan to backport the fix to earlier release?
>>>>>
>>>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>>
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance
>>>> Andersen|
>>>> Principal Member of Technical Staff | +1.781.442.2037
>>>> Oracle Java Engineering
>>>> 1 Network Drive
>>>> Burlington, MA 01803
>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>>
>>>>
>>>>
>>>
>



From lance.andersen at oracle.com  Fri Mar 27 16:20:16 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 27 Mar 2015 12:20:16 -0400
Subject: RFR: 8075810: LogManager.readConfiguration may throw undocumented
	IllegalArgumentException
In-Reply-To: <551582E5.7040100@oracle.com>
References: <551177D7.5060203@oracle.com>,
	<938960BA-2827-417B-87AE-A1994A6B2AD4@oracle.com>,
	<55117D87.9040708@oracle.com>	<BLU175-W3CA9B09E1C8C11B7B6F2E830A0@phx.gbl>
	<55129EE6.5020407@oracle.com> <551582E5.7040100@oracle.com>
Message-ID: <6B7025FA-C1F7-4A96-994D-7074905205F3@oracle.com>

Hi Daniel,

Looks good..  Let me know when you have your draft and I will make myself a reviewer of your ccc

Best
Lance
On Mar 27, 2015, at 12:18 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> Hi,
> 
> I received private feedback that using plain IOException
> might be preferable to using CharConversionException, as
> that doesn't exactly reflect what is going on here.
> 
> So here is my new webrev - which includes the minor formatting
> issues found by Jason, but reverts to using plain IOException:
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8075810/webrev.02
> 
> If I don't hear negative feedback that's what I'm going to
> present to CCC.
> 
> best regards,
> 
> -- daniel
> 
> On 25/03/15 12:41, Daniel Fuchs wrote:
>> Thanks for the review Jason!
>> 
>> On 24/03/15 18:01, Jason Mehrens wrote:
>>> Hi Daniel,
>>> 
>>> Looks good.  The only other alternative would be to use
>>> java.io.CharConversionException over IOException.  We could even
>>> consider dropping the cause because the subclass of I/O exception
>>> would convey the same meaning.
>> 
>> Here is a an updated webrev where I use
>> java.io.CharConversionException instead of plain IOException.
>> 
>> http://cr.openjdk.java.net/~dfuchs/webrev_8075810/webrev.01/
>> 
>> Note: I had a look in the JDK sources and CharConversionException
>> doesn't appear to be widely used. Is this the better alternative?
>> I'd be happy with both (webrev.01 or webrev.00).
>> Using CharConversionException means that we have to trust that
>> Properties.load will obey its spec and only throw IAE in case
>> of character conversion issues.
>> 
>>> Minor formatting issues with a missing space after the catch keyword
>> 
>> Done. Thanks for catching it.
>> 
>>> and missing a tab ahead of 'props.load'
>> 
>> That is an artifact of how webrev calls diff I think.
>> If you look at the frames version you will see that the tab is here.
>> 
>> best regards,
>> 
>> -- daniel
>> 
>>> 
>>> Jason
>>> 
>>> 
>>> ----------------------------------------
>>>> Date: Tue, 24 Mar 2015 16:06:47 +0100
>>>> From: daniel.fuchs at oracle.com
>>>> To: lance.andersen at oracle.com
>>>> Subject: Re: RFR: 8075810: LogManager.readConfiguration may throw
>>>> undocumented IllegalArgumentException
>>>> CC: core-libs-dev at openjdk.java.net
>>>> 
>>>> Hi Lance,
>>>> 
>>>> Thanks for the review!
>>>> 
>>>> On 24/03/15 16:01, Lance Andersen wrote:
>>>>> Hi Daniel,
>>>>> 
>>>>> This looks OK but I might suggest clarifying that the cause could be
>>>>> set
>>>>> in the javadoc. Now that being said, I am not sure how consistent we
>>>>> are across the JDK or just make the assumption people will check the
>>>>> cause if they desire.
>>>> 
>>>> Hmmm. I have the feeling that the best place for that would be i the
>>>> release notes - rather than in the API doc (which reminds me I should
>>>> plan to add some release note text to the issue).
>>>> 
>>>>> As far as backporting, unless it really needed, I would probably would
>>>>> not as a change such as this typically should be done as part of an
>>>>> errata/MR (due to change of behavior and it is not that big of an
>>>>> issue).
>>>> 
>>>> Right, my thinking too. Thanks for sharing your opinion!
>>>> 
>>>> best regards,
>>>> 
>>>> -- daniel
>>>> 
>>>>> 
>>>>> Best
>>>>> Lance
>>>>> On Mar 24, 2015, at 10:42 AM, Daniel Fuchs <daniel.fuchs at oracle.com
>>>>> <mailto:daniel.fuchs at oracle.com>> wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Please find below a fix for
>>>>>> 
>>>>>> 8075810: LogManager.readConfiguration may throw
>>>>>> undocumented IllegalArgumentException
>>>>>> 
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075810
>>>>>> 
>>>>>> The proposed fix is to catch the IllegalArgumentException and
>>>>>> wrap it in an IOException, since LogManager.readConfiguration
>>>>>> is specified to throw IOException "if there are problems reading
>>>>>> from the stream."
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8075810/webrev.00/
>>>>>> 
>>>>>> Initial discussion around the issue can be seen here:
>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032348.html
>>>>>> 
>>>>>> 
>>>>>> Question for reviewers: I will log a CCC for this - but I am wondering
>>>>>> whether I should plan to backport the fix to earlier release?
>>>>>> 
>>>>>> 
>>>>>> best regards,
>>>>>> 
>>>>>> -- daniel
>>>>> 
>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>> 
>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance
>>>>> Andersen|
>>>>> Principal Member of Technical Staff | +1.781.442.2037
>>>>> Oracle Java Engineering
>>>>> 1 Network Drive
>>>>> Burlington, MA 01803
>>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>>> 
>>>>> 
>>>>> 
>>>> 
>> 
> 



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 fgaliegue at gmail.com  Tue Mar 24 01:09:32 2015
From: fgaliegue at gmail.com (Francis Galiegue)
Date: Tue, 24 Mar 2015 02:09:32 +0100
Subject: [9] RFR of 8065556: (bf) Buffer.position and other methods should
	include detail in IAE
In-Reply-To: <CA+kOe0_V5syOwL7zmja+HdX-bMOiPFEScJKCf1MO2_ivR4CfEw@mail.gmail.com>
References: <588BCAF3-B163-4605-BA9E-AC3CEF1607EF@oracle.com>
	<CA+kOe09mmRxrA1L8SF2oeK4YY1T1Bo-Kzkrno3wYNDbwxxUZ-w@mail.gmail.com>
	<98E4E492-9EC3-4F9B-BCCF-4AEC6A668F43@oracle.com>
	<CD34633A-1B4E-4840-8A1C-53B3DC9D9D78@oracle.com>
	<CA+kOe08_2PZuxV2SYa6W2QvsAtf2DVVQGZzrwaW8ix2K4_zOFg@mail.gmail.com>
	<16BDF5A7-C246-45F5-8B47-452AC556B627@oracle.com>
	<CA+kOe0_V5syOwL7zmja+HdX-bMOiPFEScJKCf1MO2_ivR4CfEw@mail.gmail.com>
Message-ID: <CALcybBBkJTrLf4Ohwn2JsYCjAmiTK31nMn=UL_Q1RdbEgnFwUA@mail.gmail.com>

On Tue, Mar 24, 2015 at 12:20 AM, Martin Buchholz <martinrb at google.com> wrote:
>
>
> On Mon, Mar 23, 2015 at 3:41 PM, John Rose <john.r.rose at oracle.com> wrote:
>>
>>
>> Eventually I think we'll have good enough library functions for range
>> checks that we can avoid working with explicit range check expressions.
>> Even experts get them wrong when subexpressions can overflow (for
>> subsequence range checks).
>
>
> Guava has Precondtions:
> https://code.google.com/p/guava-libraries/wiki/PreconditionsExplained
>

Well, if we go this way, and since we are talking about ranges, Guava
also has Range<C>; which is pretty darn useful.

Unfortunately no IntRange, LongRange or DoubleRange though...

-- 
Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa


From Roger.Riggs at Oracle.com  Fri Mar 27 17:17:44 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 27 Mar 2015 13:17:44 -0400
Subject: RFR: 8075810: LogManager.readConfiguration may throw undocumented
	IllegalArgumentException
In-Reply-To: <551582E5.7040100@oracle.com>
References: <551177D7.5060203@oracle.com>,
	<938960BA-2827-417B-87AE-A1994A6B2AD4@oracle.com>,
	<55117D87.9040708@oracle.com>	<BLU175-W3CA9B09E1C8C11B7B6F2E830A0@phx.gbl>
	<55129EE6.5020407@oracle.com> <551582E5.7040100@oracle.com>
Message-ID: <551590B8.50000@Oracle.com>

Hi Daniel,

Looks fine.

Thanks, Roger


On 3/27/2015 12:18 PM, Daniel Fuchs wrote:
> Hi,
>
> I received private feedback that using plain IOException
> might be preferable to using CharConversionException, as
> that doesn't exactly reflect what is going on here.
>
> So here is my new webrev - which includes the minor formatting
> issues found by Jason, but reverts to using plain IOException:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8075810/webrev.02
>
> If I don't hear negative feedback that's what I'm going to
> present to CCC.
>
> best regards,
>
> -- daniel
>
> On 25/03/15 12:41, Daniel Fuchs wrote:
>> Thanks for the review Jason!
>>
>> On 24/03/15 18:01, Jason Mehrens wrote:
>>> Hi Daniel,
>>>
>>> Looks good.  The only other alternative would be to use
>>> java.io.CharConversionException over IOException.  We could even
>>> consider dropping the cause because the subclass of I/O exception
>>> would convey the same meaning.
>>
>> Here is a an updated webrev where I use
>> java.io.CharConversionException instead of plain IOException.
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8075810/webrev.01/
>>
>> Note: I had a look in the JDK sources and CharConversionException
>> doesn't appear to be widely used. Is this the better alternative?
>> I'd be happy with both (webrev.01 or webrev.00).
>> Using CharConversionException means that we have to trust that
>> Properties.load will obey its spec and only throw IAE in case
>> of character conversion issues.
>>
>>> Minor formatting issues with a missing space after the catch keyword
>>
>> Done. Thanks for catching it.
>>
>>> and missing a tab ahead of 'props.load'
>>
>> That is an artifact of how webrev calls diff I think.
>> If you look at the frames version you will see that the tab is here.
>>
>> best regards,
>>
>> -- daniel
>>
>>>
>>> Jason
>>>
>>>
>>> ----------------------------------------
>>>> Date: Tue, 24 Mar 2015 16:06:47 +0100
>>>> From: daniel.fuchs at oracle.com
>>>> To: lance.andersen at oracle.com
>>>> Subject: Re: RFR: 8075810: LogManager.readConfiguration may throw
>>>> undocumented IllegalArgumentException
>>>> CC: core-libs-dev at openjdk.java.net
>>>>
>>>> Hi Lance,
>>>>
>>>> Thanks for the review!
>>>>
>>>> On 24/03/15 16:01, Lance Andersen wrote:
>>>>> Hi Daniel,
>>>>>
>>>>> This looks OK but I might suggest clarifying that the cause could be
>>>>> set
>>>>> in the javadoc. Now that being said, I am not sure how consistent we
>>>>> are across the JDK or just make the assumption people will check the
>>>>> cause if they desire.
>>>>
>>>> Hmmm. I have the feeling that the best place for that would be i the
>>>> release notes - rather than in the API doc (which reminds me I should
>>>> plan to add some release note text to the issue).
>>>>
>>>>> As far as backporting, unless it really needed, I would probably 
>>>>> would
>>>>> not as a change such as this typically should be done as part of an
>>>>> errata/MR (due to change of behavior and it is not that big of an
>>>>> issue).
>>>>
>>>> Right, my thinking too. Thanks for sharing your opinion!
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>>
>>>>>
>>>>> Best
>>>>> Lance
>>>>> On Mar 24, 2015, at 10:42 AM, Daniel Fuchs <daniel.fuchs at oracle.com
>>>>> <mailto:daniel.fuchs at oracle.com>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Please find below a fix for
>>>>>>
>>>>>> 8075810: LogManager.readConfiguration may throw
>>>>>> undocumented IllegalArgumentException
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075810
>>>>>>
>>>>>> The proposed fix is to catch the IllegalArgumentException and
>>>>>> wrap it in an IOException, since LogManager.readConfiguration
>>>>>> is specified to throw IOException "if there are problems reading
>>>>>> from the stream."
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8075810/webrev.00/
>>>>>>
>>>>>> Initial discussion around the issue can be seen here:
>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032348.html 
>>>>>>
>>>>>>
>>>>>>
>>>>>> Question for reviewers: I will log a CCC for this - but I am 
>>>>>> wondering
>>>>>> whether I should plan to backport the fix to earlier release?
>>>>>>
>>>>>>
>>>>>> best regards,
>>>>>>
>>>>>> -- daniel
>>>>>
>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> 
>>>>>
>>>>>
>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance
>>>>> Andersen|
>>>>> Principal Member of Technical Staff | +1.781.442.2037
>>>>> Oracle Java Engineering
>>>>> 1 Network Drive
>>>>> Burlington, MA 01803
>>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>>>
>>>>>
>>>>>
>>>>
>>
>



From jason_mehrens at hotmail.com  Fri Mar 27 17:25:12 2015
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Fri, 27 Mar 2015 12:25:12 -0500
Subject: RFR: 8075810: LogManager.readConfiguration may throw
	undocumented IllegalArgumentException
In-Reply-To: <551582E5.7040100@oracle.com>
References: <551177D7.5060203@oracle.com>,
	<938960BA-2827-417B-87AE-A1994A6B2AD4@oracle.com>,
	<55117D87.9040708@oracle.com>	<BLU175-W3CA9B09E1C8C11B7B6F2E830A0@phx.gbl>
	<55129EE6.5020407@oracle.com>,<551582E5.7040100@oracle.com>
Message-ID: <BLU175-W18EBD64EF4656E6DF1CC1583090@phx.gbl>

Looks good to me.  Thanks for taking this on!


Jason

----------------------------------------
> Date: Fri, 27 Mar 2015 17:18:45 +0100
> From: daniel.fuchs at oracle.com
> To: jason_mehrens at hotmail.com; lance.andersen at oracle.com
> CC: core-libs-dev at openjdk.java.net; Roger.Riggs at oracle.com
> Subject: Re: RFR: 8075810: LogManager.readConfiguration may throw undocumented IllegalArgumentException
>
> Hi,
>
> I received private feedback that using plain IOException
> might be preferable to using CharConversionException, as
> that doesn't exactly reflect what is going on here.
>
> So here is my new webrev - which includes the minor formatting
> issues found by Jason, but reverts to using plain IOException:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8075810/webrev.02
>
> If I don't hear negative feedback that's what I'm going to
> present to CCC.
>
> best regards,
>
> -- daniel
>
> On 25/03/15 12:41, Daniel Fuchs wrote:
>> Thanks for the review Jason!
>>
>> On 24/03/15 18:01, Jason Mehrens wrote:
>>> Hi Daniel,
>>>
>>> Looks good. The only other alternative would be to use
>>> java.io.CharConversionException over IOException. We could even
>>> consider dropping the cause because the subclass of I/O exception
>>> would convey the same meaning.
>>
>> Here is a an updated webrev where I use
>> java.io.CharConversionException instead of plain IOException.
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8075810/webrev.01/
>>
>> Note: I had a look in the JDK sources and CharConversionException
>> doesn't appear to be widely used. Is this the better alternative?
>> I'd be happy with both (webrev.01 or webrev.00).
>> Using CharConversionException means that we have to trust that
>> Properties.load will obey its spec and only throw IAE in case
>> of character conversion issues.
>>
>>> Minor formatting issues with a missing space after the catch keyword
>>
>> Done. Thanks for catching it.
>>
>>> and missing a tab ahead of 'props.load'
>>
>> That is an artifact of how webrev calls diff I think.
>> If you look at the frames version you will see that the tab is here.
>>
>> best regards,
>>
>> -- daniel
>>
>>>
>>> Jason
>>>
>>>
>>> ----------------------------------------
>>>> Date: Tue, 24 Mar 2015 16:06:47 +0100
>>>> From: daniel.fuchs at oracle.com
>>>> To: lance.andersen at oracle.com
>>>> Subject: Re: RFR: 8075810: LogManager.readConfiguration may throw
>>>> undocumented IllegalArgumentException
>>>> CC: core-libs-dev at openjdk.java.net
>>>>
>>>> Hi Lance,
>>>>
>>>> Thanks for the review!
>>>>
>>>> On 24/03/15 16:01, Lance Andersen wrote:
>>>>> Hi Daniel,
>>>>>
>>>>> This looks OK but I might suggest clarifying that the cause could be
>>>>> set
>>>>> in the javadoc. Now that being said, I am not sure how consistent we
>>>>> are across the JDK or just make the assumption people will check the
>>>>> cause if they desire.
>>>>
>>>> Hmmm. I have the feeling that the best place for that would be i the
>>>> release notes - rather than in the API doc (which reminds me I should
>>>> plan to add some release note text to the issue).
>>>>
>>>>> As far as backporting, unless it really needed, I would probably would
>>>>> not as a change such as this typically should be done as part of an
>>>>> errata/MR (due to change of behavior and it is not that big of an
>>>>> issue).
>>>>
>>>> Right, my thinking too. Thanks for sharing your opinion!
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>>
>>>>>
>>>>> Best
>>>>> Lance
>>>>> On Mar 24, 2015, at 10:42 AM, Daniel Fuchs <daniel.fuchs at oracle.com
>>>>> <mailto:daniel.fuchs at oracle.com>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Please find below a fix for
>>>>>>
>>>>>> 8075810: LogManager.readConfiguration may throw
>>>>>> undocumented IllegalArgumentException
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8075810
>>>>>>
>>>>>> The proposed fix is to catch the IllegalArgumentException and
>>>>>> wrap it in an IOException, since LogManager.readConfiguration
>>>>>> is specified to throw IOException "if there are problems reading
>>>>>> from the stream."
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8075810/webrev.00/
>>>>>>
>>>>>> Initial discussion around the issue can be seen here:
>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032348.html
>>>>>>
>>>>>>
>>>>>> Question for reviewers: I will log a CCC for this - but I am wondering
>>>>>> whether I should plan to backport the fix to earlier release?
>>>>>>
>>>>>>
>>>>>> best regards,
>>>>>>
>>>>>> -- daniel
>>>>>
>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>>
>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance
>>>>> Andersen|
>>>>> Principal Member of Technical Staff | +1.781.442.2037
>>>>> Oracle Java Engineering
>>>>> 1 Network Drive
>>>>> Burlington, MA 01803
>>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>>>
>>>>>
>>>>>
>>>>
>>
> 		 	   		  

From Roger.Riggs at Oracle.com  Fri Mar 27 17:27:16 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 27 Mar 2015 13:27:16 -0400
Subject: RFR 9: 8076184 Cleanup compile/link warnings on Solaris
Message-ID: <551592F4.404@Oracle.com>

Please review minor cleanups to compile and builds on Solaris.
Some entry points had been renamed but not updated in the 
make/mapfiles/reorder-xxx files
and a compilation warning remedied by putting declarations at the top of 
the .c file.

Webrev:
     http://cr.openjdk.java.net/~rriggs/webrev-reorder-sparc-8076184/
Issue:
     https://bugs.openjdk.java.net/browse/JDK-8076184

Thanks, Roger



From mark.sheppard at oracle.com  Fri Mar 27 19:24:30 2015
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Fri, 27 Mar 2015 19:24:30 +0000
Subject: RFR: JDK-8068721 - RMI-IIOP communication fails when
	ConcurrentHashMap is passed to remote method
In-Reply-To: <551084E3.6050702@oracle.com>
References: <551084E3.6050702@oracle.com>
Message-ID: <5515AE6E.9080606@oracle.com>

Hi
     based on feedback webrev has been updated as follows:

http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev.01/
http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev.01/

regards
Mark

On 23/03/2015 21:25, Mark Sheppard wrote:
> Hi
>  please oblige and review the following fix
>
> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev/
> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev/
>
>
> which addresses the issue in
> https://bugs.openjdk.java.net/browse/JDK-8068721
>
> This relates to RMI-IIOP and the interplay between custom marshalling 
> of ValueTypes and
> the corresponding serialization of a Java class, in this case 
> ConcurrentHashMap.
>
> ConcurrentHashMap changed its structure in jdk8 from that used in jdk7.
> This resulted in modification to the readObject and writeObject methods,
> and in particular, former serial fields were removed, resulting in
> writeObject using PutField and readObject using defaultReadObject.
> The writeObject invokes the putFields method of an ObjectOutputStream 
> multiple times, and assumes
> that it will receive the same PutField object instance for each 
> invocation. The spec
> doesn't endorse this behaviour - but that's what the implementation of 
> ObjectOutputStream
> provides. However in the case of RMI-IIOP, the OutputStreamHook, a 
> subclass of ObjectOutputStream, returns a new instance for each
> putFields invocation. Thus, the ConcurrentHashMap writeObject results 
> in improper serialization in the context
> of RMI-IIOP.
> In the unmarshalling flow of ConcurrentHashMap, the readObject now 
> uses defaultReadObject rather than GetField
> In this call flow the IIOPInputStream attempts to ignore any primitive 
> field, in the serialized data, that doesn't
> correspond with a reflective field of the object. However, it leaves 
> the primitive in the stream.
> Thus, in the case of ConcurrentHashMap, which has serialized two 
> integers and
> an array of Segments (subclass of ReentrantLock), this results in 
> erroneous
> deserialization, with a misinterpretation of a value tag in the stream 
> as an array length
> and an attempt to allocate a very large array ensues, with an 
> exception being thrown.
>
> The OutputStreamHook now returns the same instance of PutField 
> allocated for each separate call of putFields method.
> This highlights a need to tighten up and disambiguate the 
> OutputObjectStream spec for putFields.
>
> IIOPInputStream now removes the primitive values from the stream.
>
> regards
> Mark



From lev.priima at oracle.com  Fri Mar 27 19:54:51 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Fri, 27 Mar 2015 22:54:51 +0300
Subject: RFR: 8071571: Move substring of same string to slow path
In-Reply-To: <55157487.10108@oracle.com>
References: <55156FB3.1080006@oracle.com> <55157487.10108@oracle.com>
Message-ID: <5515B58B.5070205@oracle.com>

Hi Ivan,

Thanks! Agree. Updated: 
http://cr.openjdk.java.net/~lpriima/8071571/1/webrev/

Lev

On 03/27/2015 06:17 PM, Ivan Gerasimov wrote:
> Hi Lev!
>
> Why don't you want to also simplify String#trim()?
> -        return ((st > 0) || (len < value.length)) ? substring(st, 
> len) : this;
> +        return substring(st, len);
>
> I guess, the situation when a string *is* trimmed, i.e. substring() is 
> called is more common.
> In that case we have a couple of duplicating condition checks (they're 
> going to be performed in substring() anyways) plus the cost of a branch.
>
> Sincerely yours,
> Ivan
>
>
> On 27.03.2015 17:56, Lev Priima wrote:
>> Please review small cleanup in java.lang.String:
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8071571
>> Webrev: http://cr.openjdk.java.net/~lpriima/8071571/0/webrev/
>>
>> 46 tests from jdk9/dev/jdk/test/java/lang/String* passed locally.
>>
>



From martinrb at google.com  Fri Mar 27 20:12:24 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 27 Mar 2015 13:12:24 -0700
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <551551BF.8040902@gmail.com>
References: <5513F6CE.3040505@oracle.com> <5513FB77.90305@oracle.com>
	<55140D06.4030201@gmail.com> <55140FC0.4060104@oracle.com>
	<55141540.9050600@gmail.com> <55153E88.7070200@oracle.com>
	<551551BF.8040902@gmail.com>
Message-ID: <CA+kOe0-Tw1+TbJQ-NX0Zu5d=QcVsbA0hd+oW+H4CDEscsXYFKA@mail.gmail.com>

Random advice - the default concurrency level of ConcurrentHashMap is 16,
and that is almost always more than needed, probably also including here.


From martinrb at google.com  Fri Mar 27 20:37:23 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 27 Mar 2015 13:37:23 -0700
Subject: RFR: 8071571: Move substring of same string to slow path
In-Reply-To: <5515B58B.5070205@oracle.com>
References: <55156FB3.1080006@oracle.com> <55157487.10108@oracle.com>
	<5515B58B.5070205@oracle.com>
Message-ID: <CA+kOe09wAOZjWjfquzKL9OgOD05B-_x3zC0hd1RN8FmDCimR9A@mail.gmail.com>

Here you copy the field into a local, but then don't make use of it to grab
the length.


2888         int len = value.length;
2889         int st = 0;
2890         char[] val = value;    /* avoid getfield opcode */

Also, 'beg' and 'end' would be much better names for the locals 'st' and
'len'.

On Fri, Mar 27, 2015 at 12:54 PM, Lev Priima <lev.priima at oracle.com> wrote:

> Hi Ivan,
>
> Thanks! Agree. Updated: http://cr.openjdk.java.net/~
> lpriima/8071571/1/webrev/
>
> Lev
>
>
> On 03/27/2015 06:17 PM, Ivan Gerasimov wrote:
>
>> Hi Lev!
>>
>> Why don't you want to also simplify String#trim()?
>> -        return ((st > 0) || (len < value.length)) ? substring(st, len) :
>> this;
>> +        return substring(st, len);
>>
>> I guess, the situation when a string *is* trimmed, i.e. substring() is
>> called is more common.
>> In that case we have a couple of duplicating condition checks (they're
>> going to be performed in substring() anyways) plus the cost of a branch.
>>
>> Sincerely yours,
>> Ivan
>>
>>
>> On 27.03.2015 17:56, Lev Priima wrote:
>>
>>> Please review small cleanup in java.lang.String:
>>>
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8071571
>>> Webrev: http://cr.openjdk.java.net/~lpriima/8071571/0/webrev/
>>>
>>> 46 tests from jdk9/dev/jdk/test/java/lang/String* passed locally.
>>>
>>>
>>
>


From lev.priima at oracle.com  Fri Mar 27 20:49:01 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Fri, 27 Mar 2015 23:49:01 +0300
Subject: RFR: 8071571: Move substring of same string to slow path
In-Reply-To: <CA+kOe09wAOZjWjfquzKL9OgOD05B-_x3zC0hd1RN8FmDCimR9A@mail.gmail.com>
References: <55156FB3.1080006@oracle.com>	<55157487.10108@oracle.com>	<5515B58B.5070205@oracle.com>
	<CA+kOe09wAOZjWjfquzKL9OgOD05B-_x3zC0hd1RN8FmDCimR9A@mail.gmail.com>
Message-ID: <5515C23D.3050906@oracle.com>

Martin,

You mean it should be like this:
         char[] val = value;    /* avoid getfield opcode */
         int end = val.length;
?

Lev

On 03/27/2015 11:37 PM, Martin Buchholz wrote:
> Here you copy the field into a local, but then don't make use of it to 
> grab the length.
> 2888         int len = value.length;
> 2889         int st = 0;
> 2890         char[] val = value;    /* avoid getfield opcode */
> Also, 'beg' and 'end' would be much better names for the locals 'st' 
> and 'len'.
>
> On Fri, Mar 27, 2015 at 12:54 PM, Lev Priima <lev.priima at oracle.com 
> <mailto:lev.priima at oracle.com>> wrote:
>
>     Hi Ivan,
>
>     Thanks! Agree. Updated:
>     http://cr.openjdk.java.net/~lpriima/8071571/1/webrev/
>     <http://cr.openjdk.java.net/%7Elpriima/8071571/1/webrev/>
>
>     Lev
>
>
>     On 03/27/2015 06:17 PM, Ivan Gerasimov wrote:
>
>         Hi Lev!
>
>         Why don't you want to also simplify String#trim()?
>         -        return ((st > 0) || (len < value.length)) ?
>         substring(st, len) : this;
>         +        return substring(st, len);
>
>         I guess, the situation when a string *is* trimmed, i.e.
>         substring() is called is more common.
>         In that case we have a couple of duplicating condition checks
>         (they're going to be performed in substring() anyways) plus
>         the cost of a branch.
>
>         Sincerely yours,
>         Ivan
>
>
>         On 27.03.2015 17 <tel:27.03.2015%2017>:56, Lev Priima wrote:
>
>             Please review small cleanup in java.lang.String:
>
>             Issue: https://bugs.openjdk.java.net/browse/JDK-8071571
>             Webrev:
>             http://cr.openjdk.java.net/~lpriima/8071571/0/webrev/
>             <http://cr.openjdk.java.net/%7Elpriima/8071571/0/webrev/>
>
>             46 tests from jdk9/dev/jdk/test/java/lang/String* passed
>             locally.
>
>
>
>



From Roger.Riggs at Oracle.com  Fri Mar 27 20:50:01 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 27 Mar 2015 16:50:01 -0400
Subject: RFR 9: 7021006: (process) Remove disabled clone-exec feature
Message-ID: <5515C279.1020305@Oracle.com>

At one time clone() was used on Unix to spawn processes but no more.
Please review the cleanup of now dead code.

Webrev:
    http://cr.openjdk.java.net/~rriggs//webrev-clone-7021006

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

Thanks, Roger



From martinrb at google.com  Fri Mar 27 20:50:06 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 27 Mar 2015 13:50:06 -0700
Subject: RFR: 8071571: Move substring of same string to slow path
In-Reply-To: <5515C23D.3050906@oracle.com>
References: <55156FB3.1080006@oracle.com> <55157487.10108@oracle.com>
	<5515B58B.5070205@oracle.com>
	<CA+kOe09wAOZjWjfquzKL9OgOD05B-_x3zC0hd1RN8FmDCimR9A@mail.gmail.com>
	<5515C23D.3050906@oracle.com>
Message-ID: <CA+kOe0_n9n0zh_wQgO-FA7DFn+xNjBZ4R-FFaj7PEHJu3o7C6w@mail.gmail.com>

On Fri, Mar 27, 2015 at 1:49 PM, Lev Priima <lev.priima at oracle.com> wrote:

>  Martin,
>
> You mean it should be like this:
>         char[] val = value;    /* avoid getfield opcode */
>         int end = val.length;
> ?
>
>
Yes.

(although I personally like to write it like this:

final char[] value = this.value;
int end = value.length;


From martinrb at google.com  Fri Mar 27 21:00:01 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 27 Mar 2015 14:00:01 -0700
Subject: RFR 9: 7021006: (process) Remove disabled clone-exec feature
In-Reply-To: <5515C279.1020305@Oracle.com>
References: <5515C279.1020305@Oracle.com>
Message-ID: <CA+kOe0-d3-jHE7r=L2Fpv5wBmgJjtAoRY8ZX07v-FPqVA2fz7A@mail.gmail.com>

clone was never used in a released jdk.

I would leave the internal docs.  I left them in on purpose, because it was
not at all obvious why we chose not to use clone.

I'm especially fond of

- *   On Linux, one might think that vfork() would be implemented using
- *   the clone system call with flag CLONE_VFORK, but in fact vfork is
- *   a separate system call (which is a good sign, suggesting that
- *   vfork will continue to be supported at least on Linux).

Deleting the implementation using clone is a better idea; it's easy to
resurrect in the unlikely case someone will want to.


On Fri, Mar 27, 2015 at 1:50 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> At one time clone() was used on Unix to spawn processes but no more.
> Please review the cleanup of now dead code.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs//webrev-clone-7021006
>
> Issue:
>   https://bugs.openjdk.java.net/browse/JDK-7021006
>
> Thanks, Roger
>
>


From Roger.Riggs at Oracle.com  Fri Mar 27 21:14:11 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 27 Mar 2015 17:14:11 -0400
Subject: RFR 9: 7021006: (process) Remove disabled clone-exec feature
In-Reply-To: <CA+kOe0-d3-jHE7r=L2Fpv5wBmgJjtAoRY8ZX07v-FPqVA2fz7A@mail.gmail.com>
References: <5515C279.1020305@Oracle.com>
	<CA+kOe0-d3-jHE7r=L2Fpv5wBmgJjtAoRY8ZX07v-FPqVA2fz7A@mail.gmail.com>
Message-ID: <5515C823.8040109@Oracle.com>

Thanks Martin,

Updated the webrev in place to restore that context.

Roger


On 3/27/2015 5:00 PM, Martin Buchholz wrote:
> clone was never used in a released jdk.
>
> I would leave the internal docs.  I left them in on purpose, because 
> it was not at all obvious why we chose not to use clone.
>
> I'm especially fond of
> - *   On Linux, one might think that vfork() would be implemented using
> - *   the clone system call with flag CLONE_VFORK, but in fact vfork is
> - *   a separate system call (which is a good sign, suggesting that
> - *   vfork will continue to be supported at least on Linux).
> Deleting the implementation using clone is a better idea; it's easy to 
> resurrect in the unlikely case someone will want to.
>
>
> On Fri, Mar 27, 2015 at 1:50 PM, Roger Riggs <Roger.Riggs at oracle.com 
> <mailto:Roger.Riggs at oracle.com>> wrote:
>
>     At one time clone() was used on Unix to spawn processes but no more.
>     Please review the cleanup of now dead code.
>
>     Webrev:
>     http://cr.openjdk.java.net/~rriggs//webrev-clone-7021006
>     <http://cr.openjdk.java.net/%7Erriggs//webrev-clone-7021006>
>
>     Issue:
>     https://bugs.openjdk.java.net/browse/JDK-7021006
>
>     Thanks, Roger
>
>



From martinrb at google.com  Fri Mar 27 21:21:58 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 27 Mar 2015 14:21:58 -0700
Subject: RFR 9: 7021006: (process) Remove disabled clone-exec feature
In-Reply-To: <5515C823.8040109@Oracle.com>
References: <5515C279.1020305@Oracle.com>
	<CA+kOe0-d3-jHE7r=L2Fpv5wBmgJjtAoRY8ZX07v-FPqVA2fz7A@mail.gmail.com>
	<5515C823.8040109@Oracle.com>
Message-ID: <CA+kOe09xRV-L_b3QFrCTJhxxMwDi8-K1jVK0q=wnPae9UAreeg@mail.gmail.com>

Please also keep (most of?) the below.  The key piece of the history is
that glibc did not consider clone a public supported interface, unlike
vfork, but that might change.  This comment and the contents of the glibc
bug are an important part of Unix lore, although I'm hearing you think
there's a better place to record the arcane history of Unix...

- * - clone() with flags CLONE_VM but not CLONE_THREAD.  clone() is
- *   Linux-specific, but this ought to work - at least the glibc
- *   sources contain code to handle different combinations of CLONE_VM
- *   and CLONE_THREAD.  However, when this was implemented, it
- *   appeared to fail on 32-bit i386 (but not 64-bit x86_64) Linux with
- *   the simple program
- *     Runtime.getRuntime().exec("/bin/true").waitFor();
- *   with:
- *     #  Internal Error (os_linux_x86.cpp:683), pid=19940, tid=2934639536
- *     #  Error: pthread_getattr_np failed with errno = 3 (ESRCH)
- *   We believe this is a glibc bug, reported here:
- *     http://sources.redhat.com/bugzilla/show_bug.cgi?id=10311
- *   but the glibc maintainers closed it as WONTFIX.
- *



On Fri, Mar 27, 2015 at 2:14 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

>  Thanks Martin,
>
> Updated the webrev in place to restore that context.
>
> Roger
>
>
>
> On 3/27/2015 5:00 PM, Martin Buchholz wrote:
>
> clone was never used in a released jdk.
>
> I would leave the internal docs.  I left them in on purpose, because it
> was not at all obvious why we chose not to use clone.
>
>  I'm especially fond of
>
> - *   On Linux, one might think that vfork() would be implemented using
> - *   the clone system call with flag CLONE_VFORK, but in fact vfork is
> - *   a separate system call (which is a good sign, suggesting that
> - *   vfork will continue to be supported at least on Linux).
>
> Deleting the implementation using clone is a better idea; it's easy to
> resurrect in the unlikely case someone will want to.
>
>
> On Fri, Mar 27, 2015 at 1:50 PM, Roger Riggs <Roger.Riggs at oracle.com>
> wrote:
>
>> At one time clone() was used on Unix to spawn processes but no more.
>> Please review the cleanup of now dead code.
>>
>> Webrev:
>>    http://cr.openjdk.java.net/~rriggs//webrev-clone-7021006
>>
>> Issue:
>>   https://bugs.openjdk.java.net/browse/JDK-7021006
>>
>> Thanks, Roger
>>
>>
>
>


From Roger.Riggs at Oracle.com  Fri Mar 27 21:28:10 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 27 Mar 2015 17:28:10 -0400
Subject: RFR 9: 7021006: (process) Remove disabled clone-exec feature
In-Reply-To: <CA+kOe09xRV-L_b3QFrCTJhxxMwDi8-K1jVK0q=wnPae9UAreeg@mail.gmail.com>
References: <5515C279.1020305@Oracle.com>	<CA+kOe0-d3-jHE7r=L2Fpv5wBmgJjtAoRY8ZX07v-FPqVA2fz7A@mail.gmail.com>	<5515C823.8040109@Oracle.com>
	<CA+kOe09xRV-L_b3QFrCTJhxxMwDi8-K1jVK0q=wnPae9UAreeg@mail.gmail.com>
Message-ID: <5515CB6A.7050608@Oracle.com>

Hi Martin,

That part seems both dated and arcane;  it will be in the mercurial history
none the less.  I can't see how it could be applied unless we go back to 
clone.

Roger


On 3/27/2015 5:21 PM, Martin Buchholz wrote:
> Please also keep (most of?) the below.  The key piece of the history 
> is that glibc did not consider clone a public supported interface, 
> unlike vfork, but that might change.  This comment and the contents of 
> the glibc bug are an important part of Unix lore, although I'm hearing 
> you think there's a better place to record the arcane history of Unix...
>
> - * - clone() with flags CLONE_VM but not CLONE_THREAD.  clone() is
> - *   Linux-specific, but this ought to work - at least the glibc
> - *   sources contain code to handle different combinations of CLONE_VM
> - *   and CLONE_THREAD.  However, when this was implemented, it
> - *   appeared to fail on 32-bit i386 (but not 64-bit x86_64) Linux with
> - *   the simple program
> - *     Runtime.getRuntime().exec("/bin/true").waitFor();
> - *   with:
> - *     #  Internal Error (os_linux_x86.cpp:683), pid=19940, tid=2934639536
> - *     #  Error: pthread_getattr_np failed with errno = 3 (ESRCH)
> - *   We believe this is a glibc bug, reported here:
> - *http://sources.redhat.com/bugzilla/show_bug.cgi?id=10311
> - *   but the glibc maintainers closed it as WONTFIX.
> - *
>
>
> On Fri, Mar 27, 2015 at 2:14 PM, Roger Riggs <Roger.Riggs at oracle.com 
> <mailto:Roger.Riggs at oracle.com>> wrote:
>
>     Thanks Martin,
>
>     Updated the webrev in place to restore that context.
>
>     Roger
>
>
>
>     On 3/27/2015 5:00 PM, Martin Buchholz wrote:
>>     clone was never used in a released jdk.
>>
>>     I would leave the internal docs.  I left them in on purpose,
>>     because it was not at all obvious why we chose not to use clone.
>>
>>     I'm especially fond of
>>     - *   On Linux, one might think that vfork() would be implemented using
>>     - *   the clone system call with flag CLONE_VFORK, but in fact vfork is
>>     - *   a separate system call (which is a good sign, suggesting that
>>     - *   vfork will continue to be supported at least on Linux).
>>     Deleting the implementation using clone is a better idea; it's
>>     easy to resurrect in the unlikely case someone will want to.
>>
>>
>>     On Fri, Mar 27, 2015 at 1:50 PM, Roger Riggs
>>     <Roger.Riggs at oracle.com <mailto:Roger.Riggs at oracle.com>> wrote:
>>
>>         At one time clone() was used on Unix to spawn processes but
>>         no more.
>>         Please review the cleanup of now dead code.
>>
>>         Webrev:
>>         http://cr.openjdk.java.net/~rriggs//webrev-clone-7021006
>>         <http://cr.openjdk.java.net/%7Erriggs//webrev-clone-7021006>
>>
>>         Issue:
>>         https://bugs.openjdk.java.net/browse/JDK-7021006
>>
>>         Thanks, Roger
>>
>>
>
>



From martinrb at google.com  Fri Mar 27 21:47:42 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 27 Mar 2015 14:47:42 -0700
Subject: RFR 9: 7021006: (process) Remove disabled clone-exec feature
In-Reply-To: <5515CB6A.7050608@Oracle.com>
References: <5515C279.1020305@Oracle.com>
	<CA+kOe0-d3-jHE7r=L2Fpv5wBmgJjtAoRY8ZX07v-FPqVA2fz7A@mail.gmail.com>
	<5515C823.8040109@Oracle.com>
	<CA+kOe09xRV-L_b3QFrCTJhxxMwDi8-K1jVK0q=wnPae9UAreeg@mail.gmail.com>
	<5515CB6A.7050608@Oracle.com>
Message-ID: <CA+kOe08s0UTqzKeVHJgaevPp6ogSTgUffxLtt9Lusz1ye19g-A@mail.gmail.com>

On Fri, Mar 27, 2015 at 2:28 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

>  Hi Martin,
>
> That part seems both dated and arcane;  it will be in the mercurial history
> none the less.  I can't see how it could be applied unless we go back to
> clone.
>
>
This is information for implementers of subprocess creation, that I still
consider useful, and I personally refer to every couple of years.  I would
be unhappy to see it go.


> Roger
>
>
>
> On 3/27/2015 5:21 PM, Martin Buchholz wrote:
>
> Please also keep (most of?) the below.  The key piece of the history is
> that glibc did not consider clone a public supported interface, unlike
> vfork, but that might change.  This comment and the contents of the glibc
> bug are an important part of Unix lore, although I'm hearing you think
> there's a better place to record the arcane history of Unix...
>
> - * - clone() with flags CLONE_VM but not CLONE_THREAD.  clone() is
> - *   Linux-specific, but this ought to work - at least the glibc
> - *   sources contain code to handle different combinations of CLONE_VM
> - *   and CLONE_THREAD.  However, when this was implemented, it
> - *   appeared to fail on 32-bit i386 (but not 64-bit x86_64) Linux with
> - *   the simple program
> - *     Runtime.getRuntime().exec("/bin/true").waitFor();
> - *   with:
> - *     #  Internal Error (os_linux_x86.cpp:683), pid=19940, tid=2934639536
> - *     #  Error: pthread_getattr_np failed with errno = 3 (ESRCH)
> - *   We believe this is a glibc bug, reported here:
> - *     http://sources.redhat.com/bugzilla/show_bug.cgi?id=10311
> - *   but the glibc maintainers closed it as WONTFIX.
> - *
>
>
>
> On Fri, Mar 27, 2015 at 2:14 PM, Roger Riggs <Roger.Riggs at oracle.com>
> wrote:
>
>>  Thanks Martin,
>>
>> Updated the webrev in place to restore that context.
>>
>> Roger
>>
>>
>>
>> On 3/27/2015 5:00 PM, Martin Buchholz wrote:
>>
>> clone was never used in a released jdk.
>>
>> I would leave the internal docs.  I left them in on purpose, because it
>> was not at all obvious why we chose not to use clone.
>>
>>  I'm especially fond of
>>
>> - *   On Linux, one might think that vfork() would be implemented using
>> - *   the clone system call with flag CLONE_VFORK, but in fact vfork is
>> - *   a separate system call (which is a good sign, suggesting that
>> - *   vfork will continue to be supported at least on Linux).
>>
>> Deleting the implementation using clone is a better idea; it's easy to
>> resurrect in the unlikely case someone will want to.
>>
>>
>> On Fri, Mar 27, 2015 at 1:50 PM, Roger Riggs <Roger.Riggs at oracle.com>
>> wrote:
>>
>>> At one time clone() was used on Unix to spawn processes but no more.
>>> Please review the cleanup of now dead code.
>>>
>>> Webrev:
>>>    http://cr.openjdk.java.net/~rriggs//webrev-clone-7021006
>>>
>>> Issue:
>>>   https://bugs.openjdk.java.net/browse/JDK-7021006
>>>
>>> Thanks, Roger
>>>
>>>
>>
>>
>
>


From mandy.chung at oracle.com  Fri Mar 27 21:47:56 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 27 Mar 2015 14:47:56 -0700
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <55153E88.7070200@oracle.com>
References: <5513F6CE.3040505@oracle.com>
	<5513FB77.90305@oracle.com>	<55140D06.4030201@gmail.com>
	<55140FC0.4060104@oracle.com>	<55141540.9050600@gmail.com>
	<55153E88.7070200@oracle.com>
Message-ID: <5515D00C.5080300@oracle.com>

On 3/27/15 4:27 AM, Daniel Fuchs wrote:
> Here is a new webrev - with Peter's suggestion implemented.
> I also made a few tweaks to the test.
>
> http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.01/


This version looks good to me.  With this change to use CHM,
we could modernize the code further and that's for some other day.

I think the removeLoggerRef andgetLoggerNames method don't
need to be synchronized either - any reason why they are
kept synchronized?

line 659: indent to the right
line 660: nit - 4-space indentation.

Mandy



From lev.priima at oracle.com  Fri Mar 27 21:51:48 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Sat, 28 Mar 2015 00:51:48 +0300
Subject: RFR: 8071571: Move substring of same string to slow path
In-Reply-To: <CA+kOe0_n9n0zh_wQgO-FA7DFn+xNjBZ4R-FFaj7PEHJu3o7C6w@mail.gmail.com>
References: <55156FB3.1080006@oracle.com>	<55157487.10108@oracle.com>	<5515B58B.5070205@oracle.com>	<CA+kOe09wAOZjWjfquzKL9OgOD05B-_x3zC0hd1RN8FmDCimR9A@mail.gmail.com>	<5515C23D.3050906@oracle.com>
	<CA+kOe0_n9n0zh_wQgO-FA7DFn+xNjBZ4R-FFaj7PEHJu3o7C6w@mail.gmail.com>
Message-ID: <5515D0F4.7040103@oracle.com>

Updated and put some more final in other(not @Deprecated) methods: 
http://cr.openjdk.java.net/~lpriima/8071571/2/

Lev

On 03/27/2015 11:50 PM, Martin Buchholz wrote:
>
>
> On Fri, Mar 27, 2015 at 1:49 PM, Lev Priima <lev.priima at oracle.com 
> <mailto:lev.priima at oracle.com>> wrote:
>
>     Martin,
>
>     You mean it should be like this:
>              char[] val = value;    /* avoid getfield opcode */
>              int end = val.length;
>     ?
>
>
> Yes.
>
> (although I personally like to write it like this:
>
> final char[] value = this.value;
> int end = value.length;
>
>



From Roger.Riggs at Oracle.com  Fri Mar 27 21:54:20 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 27 Mar 2015 17:54:20 -0400
Subject: RFR 9: 7021006: (process) Remove disabled clone-exec feature
In-Reply-To: <CA+kOe08s0UTqzKeVHJgaevPp6ogSTgUffxLtt9Lusz1ye19g-A@mail.gmail.com>
References: <5515C279.1020305@Oracle.com>	<CA+kOe0-d3-jHE7r=L2Fpv5wBmgJjtAoRY8ZX07v-FPqVA2fz7A@mail.gmail.com>	<5515C823.8040109@Oracle.com>	<CA+kOe09xRV-L_b3QFrCTJhxxMwDi8-K1jVK0q=wnPae9UAreeg@mail.gmail.com>	<5515CB6A.7050608@Oracle.com>
	<CA+kOe08s0UTqzKeVHJgaevPp6ogSTgUffxLtt9Lusz1ye19g-A@mail.gmail.com>
Message-ID: <5515D18C.1030206@Oracle.com>

ok,  restored.

I'd hope this isn't the only place that lore exists but it's 
conveniently located.

Thanks, Roger


On 3/27/2015 5:47 PM, Martin Buchholz wrote:
>
>
> On Fri, Mar 27, 2015 at 2:28 PM, Roger Riggs <Roger.Riggs at oracle.com 
> <mailto:Roger.Riggs at oracle.com>> wrote:
>
>     Hi Martin,
>
>     That part seems both dated and arcane;  it will be in the
>     mercurial history
>     none the less.  I can't see how it could be applied unless we go
>     back to clone.
>
>
> This is information for implementers of subprocess creation, that I 
> still consider useful, and I personally refer to every couple of 
> years.  I would be unhappy to see it go.
>
>     Roger
>
>
>
>     On 3/27/2015 5:21 PM, Martin Buchholz wrote:
>>     Please also keep (most of?) the below.  The key piece of the
>>     history is that glibc did not consider clone a public supported
>>     interface, unlike vfork, but that might change. This comment and
>>     the contents of the glibc bug are an important part of Unix lore,
>>     although I'm hearing you think there's a better place to record
>>     the arcane history of Unix...
>>
>>     - * - clone() with flags CLONE_VM but not CLONE_THREAD.  clone() is
>>     - *   Linux-specific, but this ought to work - at least the glibc
>>     - *   sources contain code to handle different combinations of CLONE_VM
>>     - *   and CLONE_THREAD.  However, when this was implemented, it
>>     - *   appeared to fail on 32-bit i386 (but not 64-bit x86_64) Linux with
>>     - *   the simple program
>>     - *     Runtime.getRuntime().exec("/bin/true").waitFor();
>>     - *   with:
>>     - *     #  Internal Error (os_linux_x86.cpp:683), pid=19940, tid=2934639536
>>     - *     #  Error: pthread_getattr_np failed with errno = 3 (ESRCH)
>>     - *   We believe this is a glibc bug, reported here:
>>     - *http://sources.redhat.com/bugzilla/show_bug.cgi?id=10311
>>     - *   but the glibc maintainers closed it as WONTFIX.
>>     - *
>>
>>
>>     On Fri, Mar 27, 2015 at 2:14 PM, Roger Riggs
>>     <Roger.Riggs at oracle.com <mailto:Roger.Riggs at oracle.com>> wrote:
>>
>>         Thanks Martin,
>>
>>         Updated the webrev in place to restore that context.
>>
>>         Roger
>>
>>
>>
>>         On 3/27/2015 5:00 PM, Martin Buchholz wrote:
>>>         clone was never used in a released jdk.
>>>
>>>         I would leave the internal docs.  I left them in on purpose,
>>>         because it was not at all obvious why we chose not to use clone.
>>>
>>>         I'm especially fond of
>>>         - *   On Linux, one might think that vfork() would be implemented using
>>>         - *   the clone system call with flag CLONE_VFORK, but in fact vfork is
>>>         - *   a separate system call (which is a good sign, suggesting that
>>>         - *   vfork will continue to be supported at least on Linux).
>>>         Deleting the implementation using clone is a better idea;
>>>         it's easy to resurrect in the unlikely case someone will
>>>         want to.
>>>
>>>
>>>         On Fri, Mar 27, 2015 at 1:50 PM, Roger Riggs
>>>         <Roger.Riggs at oracle.com <mailto:Roger.Riggs at oracle.com>> wrote:
>>>
>>>             At one time clone() was used on Unix to spawn processes
>>>             but no more.
>>>             Please review the cleanup of now dead code.
>>>
>>>             Webrev:
>>>             http://cr.openjdk.java.net/~rriggs//webrev-clone-7021006
>>>             <http://cr.openjdk.java.net/%7Erriggs//webrev-clone-7021006>
>>>
>>>             Issue:
>>>             https://bugs.openjdk.java.net/browse/JDK-7021006
>>>
>>>             Thanks, Roger
>>>
>>>
>>
>>
>
>



From Roger.Riggs at Oracle.com  Fri Mar 27 21:57:36 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 27 Mar 2015 17:57:36 -0400
Subject: RFR: 8071571: Move substring of same string to slow path
In-Reply-To: <5515D0F4.7040103@oracle.com>
References: <55156FB3.1080006@oracle.com>	<55157487.10108@oracle.com>	<5515B58B.5070205@oracle.com>	<CA+kOe09wAOZjWjfquzKL9OgOD05B-_x3zC0hd1RN8FmDCimR9A@mail.gmail.com>	<5515C23D.3050906@oracle.com>	<CA+kOe0_n9n0zh_wQgO-FA7DFn+xNjBZ4R-FFaj7PEHJu3o7C6w@mail.gmail.com>
	<5515D0F4.7040103@oracle.com>
Message-ID: <5515D250.10302@Oracle.com>

Hi,

@Martin: does the final have some functional reason to be present?
I see it just bulks up the source, reducing readability.  If it is 
useful to improve performance then fine.

Roger



On 3/27/2015 5:51 PM, Lev Priima wrote:
> Updated and put some more final in other(not @Deprecated) methods: 
> http://cr.openjdk.java.net/~lpriima/8071571/2/
>
> Lev
>
> On 03/27/2015 11:50 PM, Martin Buchholz wrote:
>>
>>
>> On Fri, Mar 27, 2015 at 1:49 PM, Lev Priima <lev.priima at oracle.com 
>> <mailto:lev.priima at oracle.com>> wrote:
>>
>>     Martin,
>>
>>     You mean it should be like this:
>>              char[] val = value;    /* avoid getfield opcode */
>>              int end = val.length;
>>     ?
>>
>>
>> Yes.
>>
>> (although I personally like to write it like this:
>>
>> final char[] value = this.value;
>> int end = value.length;
>>
>>
>



From Alan.Bateman at oracle.com  Fri Mar 27 21:58:22 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 27 Mar 2015 21:58:22 +0000
Subject: RFR 9: 7021006: (process) Remove disabled clone-exec feature
In-Reply-To: <5515D18C.1030206@Oracle.com>
References: <5515C279.1020305@Oracle.com>	<CA+kOe0-d3-jHE7r=L2Fpv5wBmgJjtAoRY8ZX07v-FPqVA2fz7A@mail.gmail.com>	<5515C823.8040109@Oracle.com>	<CA+kOe09xRV-L_b3QFrCTJhxxMwDi8-K1jVK0q=wnPae9UAreeg@mail.gmail.com>	<5515CB6A.7050608@Oracle.com>	<CA+kOe08s0UTqzKeVHJgaevPp6ogSTgUffxLtt9Lusz1ye19g-A@mail.gmail.com>
	<5515D18C.1030206@Oracle.com>
Message-ID: <5515D27E.8010702@oracle.com>

On 27/03/2015 21:54, Roger Riggs wrote:
> ok, restored.
>
> I'd hope this isn't the only place that lore exists but it's 
> conveniently located.
>
> Thanks, Roger
>
Is there an updated webrev? I know a number of people have been confused 
by having the comments about clone in this code so I would be happy to 
see some of this go away.

-Alan


From martinrb at google.com  Fri Mar 27 21:59:31 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 27 Mar 2015 14:59:31 -0700
Subject: RFR: 8071571: Move substring of same string to slow path
In-Reply-To: <5515D0F4.7040103@oracle.com>
References: <55156FB3.1080006@oracle.com> <55157487.10108@oracle.com>
	<5515B58B.5070205@oracle.com>
	<CA+kOe09wAOZjWjfquzKL9OgOD05B-_x3zC0hd1RN8FmDCimR9A@mail.gmail.com>
	<5515C23D.3050906@oracle.com>
	<CA+kOe0_n9n0zh_wQgO-FA7DFn+xNjBZ4R-FFaj7PEHJu3o7C6w@mail.gmail.com>
	<5515D0F4.7040103@oracle.com>
Message-ID: <CA+kOe08BgRGkqEXMu19bEiKj27K34_HbGKR=SNhcm1khGj=-Jg@mail.gmail.com>

I was only suggesting using final in the stylized

final Type foo = this.foo;

Using final for other local variables is going further than most jdk
maintainers (including myself) go.

OTOH, if you touch code that uses the denigrated

char foo[]

please change it to

char[] foo

This is yet another of those global changes to the entire jdk sources that
nobody ever gets around to.


On Fri, Mar 27, 2015 at 2:51 PM, Lev Priima <lev.priima at oracle.com> wrote:

>  Updated and put some more final in other(not @Deprecated) methods:
> http://cr.openjdk.java.net/~lpriima/8071571/2/
>
> Lev
>
> On 03/27/2015 11:50 PM, Martin Buchholz wrote:
>
>
>
> On Fri, Mar 27, 2015 at 1:49 PM, Lev Priima <lev.priima at oracle.com> wrote:
>
>>  Martin,
>>
>> You mean it should be like this:
>>         char[] val = value;    /* avoid getfield opcode */
>>         int end = val.length;
>> ?
>>
>>
>  Yes.
>
> (although I personally like to write it like this:
>
>  final char[] value = this.value;
>  int end = value.length;
>
>
>
>


From martinrb at google.com  Fri Mar 27 22:01:15 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 27 Mar 2015 15:01:15 -0700
Subject: RFR: 8071571: Move substring of same string to slow path
In-Reply-To: <5515D250.10302@Oracle.com>
References: <55156FB3.1080006@oracle.com> <55157487.10108@oracle.com>
	<5515B58B.5070205@oracle.com>
	<CA+kOe09wAOZjWjfquzKL9OgOD05B-_x3zC0hd1RN8FmDCimR9A@mail.gmail.com>
	<5515C23D.3050906@oracle.com>
	<CA+kOe0_n9n0zh_wQgO-FA7DFn+xNjBZ4R-FFaj7PEHJu3o7C6w@mail.gmail.com>
	<5515D0F4.7040103@oracle.com> <5515D250.10302@Oracle.com>
Message-ID: <CA+kOe0-Q=qwvwszuk=C+NWEncGFKent6w9OMYagZjcb9xL7aYA@mail.gmail.com>

On Fri, Mar 27, 2015 at 2:57 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi,
>
> @Martin: does the final have some functional reason to be present?
> I see it just bulks up the source, reducing readability.  If it is useful
> to improve performance then fine.
>

If you use the idiom
final Type foo = this.foo;
and leave out the final,
there is a risk of a maintainer assigning to foo and introducing a bug.
Maybe I should stop, since no one seems to understand it?


From Roger.Riggs at Oracle.com  Fri Mar 27 22:01:39 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 27 Mar 2015 18:01:39 -0400
Subject: RFR 9: 7021006: (process) Remove disabled clone-exec feature
In-Reply-To: <5515D27E.8010702@oracle.com>
References: <5515C279.1020305@Oracle.com>	<CA+kOe0-d3-jHE7r=L2Fpv5wBmgJjtAoRY8ZX07v-FPqVA2fz7A@mail.gmail.com>	<5515C823.8040109@Oracle.com>	<CA+kOe09xRV-L_b3QFrCTJhxxMwDi8-K1jVK0q=wnPae9UAreeg@mail.gmail.com>	<5515CB6A.7050608@Oracle.com>	<CA+kOe08s0UTqzKeVHJgaevPp6ogSTgUffxLtt9Lusz1ye19g-A@mail.gmail.com>
	<5515D18C.1030206@Oracle.com> <5515D27E.8010702@oracle.com>
Message-ID: <5515D343.8050807@Oracle.com>

Hi Alan,

Yes, updated in place.

http://cr.openjdk.java.net/~rriggs//webrev-clone-7021006

Roger

On 3/27/2015 5:58 PM, Alan Bateman wrote:
> On 27/03/2015 21:54, Roger Riggs wrote:
>> ok, restored.
>>
>> I'd hope this isn't the only place that lore exists but it's 
>> conveniently located.
>>
>> Thanks, Roger
>>
> Is there an updated webrev? I know a number of people have been 
> confused by having the comments about clone in this code so I would be 
> happy to see some of this go away.
>
> -Alan



From Alan.Bateman at oracle.com  Fri Mar 27 22:11:27 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 27 Mar 2015 22:11:27 +0000
Subject: RFR 9: 7021006: (process) Remove disabled clone-exec feature
In-Reply-To: <5515D343.8050807@Oracle.com>
References: <5515C279.1020305@Oracle.com>	<CA+kOe0-d3-jHE7r=L2Fpv5wBmgJjtAoRY8ZX07v-FPqVA2fz7A@mail.gmail.com>	<5515C823.8040109@Oracle.com>	<CA+kOe09xRV-L_b3QFrCTJhxxMwDi8-K1jVK0q=wnPae9UAreeg@mail.gmail.com>	<5515CB6A.7050608@Oracle.com>	<CA+kOe08s0UTqzKeVHJgaevPp6ogSTgUffxLtt9Lusz1ye19g-A@mail.gmail.com>
	<5515D18C.1030206@Oracle.com> <5515D27E.8010702@oracle.com>
	<5515D343.8050807@Oracle.com>
Message-ID: <5515D58F.40302@oracle.com>

On 27/03/2015 22:01, Roger Riggs wrote:
> Hi Alan,
>
> Yes, updated in place.
>
> http://cr.openjdk.java.net/~rriggs//webrev-clone-7021006
The changes looks okay to me. I guess I've remove most the paragraph on 
clone and it's arcane but if Martin wants to keep then that is okay (the 
main thing is that cloneChild is removed as that has caused confusion.

-Alan


From martinrb at google.com  Fri Mar 27 22:12:42 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 27 Mar 2015 15:12:42 -0700
Subject: RFR 9: 7021006: (process) Remove disabled clone-exec feature
In-Reply-To: <5515D343.8050807@Oracle.com>
References: <5515C279.1020305@Oracle.com>
	<CA+kOe0-d3-jHE7r=L2Fpv5wBmgJjtAoRY8ZX07v-FPqVA2fz7A@mail.gmail.com>
	<5515C823.8040109@Oracle.com>
	<CA+kOe09xRV-L_b3QFrCTJhxxMwDi8-K1jVK0q=wnPae9UAreeg@mail.gmail.com>
	<5515CB6A.7050608@Oracle.com>
	<CA+kOe08s0UTqzKeVHJgaevPp6ogSTgUffxLtt9Lusz1ye19g-A@mail.gmail.com>
	<5515D18C.1030206@Oracle.com> <5515D27E.8010702@oracle.com>
	<5515D343.8050807@Oracle.com>
Message-ID: <CA+kOe08kQCZfQyiruYVcqoHzzVp6_aKcv3PHVheXGW1223uanQ@mail.gmail.com>

Alright, I'm OK with the latest webrev.  Sorry for being a grump.

If you want, you can also fix what appears to be a typo below and
s/spawn/posix_spawn/


+ * Linux and spawn() on other Unix systems.


From lev.priima at oracle.com  Fri Mar 27 22:15:49 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Sat, 28 Mar 2015 01:15:49 +0300
Subject: RFR: 8071571: Move substring of same string to slow path
In-Reply-To: <CA+kOe08BgRGkqEXMu19bEiKj27K34_HbGKR=SNhcm1khGj=-Jg@mail.gmail.com>
References: <55156FB3.1080006@oracle.com>	<55157487.10108@oracle.com>	<5515B58B.5070205@oracle.com>	<CA+kOe09wAOZjWjfquzKL9OgOD05B-_x3zC0hd1RN8FmDCimR9A@mail.gmail.com>	<5515C23D.3050906@oracle.com>	<CA+kOe0_n9n0zh_wQgO-FA7DFn+xNjBZ4R-FFaj7PEHJu3o7C6w@mail.gmail.com>	<5515D0F4.7040103@oracle.com>
	<CA+kOe08BgRGkqEXMu19bEiKj27K34_HbGKR=SNhcm1khGj=-Jg@mail.gmail.com>
Message-ID: <5515D695.4070407@oracle.com>

On 03/28/2015 12:59 AM, Martin Buchholz wrote:
> I was only suggesting using final in the stylized
>
> final Type foo = this.foo;
>
> Using final for other local variables is going further than most jdk 
> maintainers (including myself) go.
I think we could start from one file.
>
> OTOH, if you touch code that uses the denigrated
>
> char foo[]
>
> please change it to
>
> char[] foo
Only for touched lines? If no, I can start from:

  118     private final char value[];

And go further to many methods signatures:

  169     public String(char value[]) {

> This is yet another of those global changes to the entire jdk sources 
> that nobody ever gets around to.
>
>
> On Fri, Mar 27, 2015 at 2:51 PM, Lev Priima <lev.priima at oracle.com 
> <mailto:lev.priima at oracle.com>> wrote:
>
>     Updated and put some more final in other(not @Deprecated) methods:
>     http://cr.openjdk.java.net/~lpriima/8071571/2/
>     <http://cr.openjdk.java.net/%7Elpriima/8071571/2/>
>
>     Lev
>
>     On 03/27/2015 11:50 PM, Martin Buchholz wrote:
>>
>>
>>     On Fri, Mar 27, 2015 at 1:49 PM, Lev Priima
>>     <lev.priima at oracle.com <mailto:lev.priima at oracle.com>> wrote:
>>
>>         Martin,
>>
>>         You mean it should be like this:
>>                  char[] val = value;    /* avoid getfield opcode */
>>                  int end = val.length;
>>         ?
>>
>>
>>     Yes.
>>
>>     (although I personally like to write it like this:
>>
>>     final char[] value = this.value;
>>     int end = value.length;
>>
>>
>
>



From david.holmes at oracle.com  Fri Mar 27 22:17:32 2015
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 28 Mar 2015 08:17:32 +1000
Subject: RFR 9: 7021006: (process) Remove disabled clone-exec feature
In-Reply-To: <CA+kOe08kQCZfQyiruYVcqoHzzVp6_aKcv3PHVheXGW1223uanQ@mail.gmail.com>
References: <5515C279.1020305@Oracle.com>	<CA+kOe0-d3-jHE7r=L2Fpv5wBmgJjtAoRY8ZX07v-FPqVA2fz7A@mail.gmail.com>	<5515C823.8040109@Oracle.com>	<CA+kOe09xRV-L_b3QFrCTJhxxMwDi8-K1jVK0q=wnPae9UAreeg@mail.gmail.com>	<5515CB6A.7050608@Oracle.com>	<CA+kOe08s0UTqzKeVHJgaevPp6ogSTgUffxLtt9Lusz1ye19g-A@mail.gmail.com>	<5515D18C.1030206@Oracle.com>
	<5515D27E.8010702@oracle.com>	<5515D343.8050807@Oracle.com>
	<CA+kOe08kQCZfQyiruYVcqoHzzVp6_aKcv3PHVheXGW1223uanQ@mail.gmail.com>
Message-ID: <5515D6FC.5000908@oracle.com>

On 28/03/2015 8:12 AM, Martin Buchholz wrote:
> Alright, I'm OK with the latest webrev.  Sorry for being a grump.

I agree with you Martin (on keeping the comments not that you are a 
grump :) ).

"They who can not remember the past are condemned to repeat it."

Cheers,
David

> If you want, you can also fix what appears to be a typo below and
> s/spawn/posix_spawn/
>
>
> + * Linux and spawn() on other Unix systems.
>


From lev.priima at oracle.com  Fri Mar 27 22:30:56 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Sat, 28 Mar 2015 01:30:56 +0300
Subject: RFR: 8071571: Move substring of same string to slow path
In-Reply-To: <CA+kOe0-Q=qwvwszuk=C+NWEncGFKent6w9OMYagZjcb9xL7aYA@mail.gmail.com>
References: <55156FB3.1080006@oracle.com>
	<55157487.10108@oracle.com>	<5515B58B.5070205@oracle.com>	<CA+kOe09wAOZjWjfquzKL9OgOD05B-_x3zC0hd1RN8FmDCimR9A@mail.gmail.com>	<5515C23D.3050906@oracle.com>	<CA+kOe0_n9n0zh_wQgO-FA7DFn+xNjBZ4R-FFaj7PEHJu3o7C6w@mail.gmail.com>	<5515D0F4.7040103@oracle.com>
	<5515D250.10302@Oracle.com>
	<CA+kOe0-Q=qwvwszuk=C+NWEncGFKent6w9OMYagZjcb9xL7aYA@mail.gmail.com>
Message-ID: <5515DA20.5020506@oracle.com>

I'm closer to Martins opinion. In my opinion, Immutability really 
improves readability of code, but longer declaration doesn't. That's why 
some contemporary languages use shorter var/val for declarations.

Lev

On 03/28/2015 01:01 AM, Martin Buchholz wrote:
> On Fri, Mar 27, 2015 at 2:57 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>
>> Hi,
>>
>> @Martin: does the final have some functional reason to be present?
>> I see it just bulks up the source, reducing readability.  If it is useful
>> to improve performance then fine.
>>
> If you use the idiom
> final Type foo = this.foo;
> and leave out the final,
> there is a risk of a maintainer assigning to foo and introducing a bug.
> Maybe I should stop, since no one seems to understand it?



From claes.redestad at oracle.com  Fri Mar 27 23:02:38 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 28 Mar 2015 00:02:38 +0100
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <CA+kOe0-Tw1+TbJQ-NX0Zu5d=QcVsbA0hd+oW+H4CDEscsXYFKA@mail.gmail.com>
References: <5513F6CE.3040505@oracle.com>
	<5513FB77.90305@oracle.com>	<55140D06.4030201@gmail.com>
	<55140FC0.4060104@oracle.com>	<55141540.9050600@gmail.com>
	<55153E88.7070200@oracle.com>	<551551BF.8040902@gmail.com>
	<CA+kOe0-Tw1+TbJQ-NX0Zu5d=QcVsbA0hd+oW+H4CDEscsXYFKA@mail.gmail.com>
Message-ID: <5515E18E.8000204@oracle.com>


On 2015-03-27 21:12, Martin Buchholz wrote:
> Random advice - the default concurrency level of ConcurrentHashMap is 16,
> and that is almost always more than needed, probably also including here.

I believe JSR-166e (JDK8 and onwards) mostly removed the concept of
concurrency level from ConcurrentHashMap (while it's still there in some
constructors to confuse things). I recall some tests showing that the
difference in footprint between CHM and regular HashMap/Hashtable is now
negligible even for empty, default-initialized instances.

/Claes


From martinrb at google.com  Fri Mar 27 23:39:41 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 27 Mar 2015 16:39:41 -0700
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <5515E18E.8000204@oracle.com>
References: <5513F6CE.3040505@oracle.com> <5513FB77.90305@oracle.com>
	<55140D06.4030201@gmail.com> <55140FC0.4060104@oracle.com>
	<55141540.9050600@gmail.com> <55153E88.7070200@oracle.com>
	<551551BF.8040902@gmail.com>
	<CA+kOe0-Tw1+TbJQ-NX0Zu5d=QcVsbA0hd+oW+H4CDEscsXYFKA@mail.gmail.com>
	<5515E18E.8000204@oracle.com>
Message-ID: <CA+kOe0-aZzccotBTbc_0-_ohF_W_Ea4ZSLSY--1yghRFCDXGFw@mail.gmail.com>

Claes,

Right you are - I stand corrected!

On Fri, Mar 27, 2015 at 4:02 PM, Claes Redestad <claes.redestad at oracle.com>
wrote:

>
> On 2015-03-27 21:12, Martin Buchholz wrote:
>
>> Random advice - the default concurrency level of ConcurrentHashMap is 16,
>> and that is almost always more than needed, probably also including here.
>>
>
> I believe JSR-166e (JDK8 and onwards) mostly removed the concept of
> concurrency level from ConcurrentHashMap (while it's still there in some
> constructors to confuse things). I recall some tests showing that the
> difference in footprint between CHM and regular HashMap/Hashtable is now
> negligible even for empty, default-initialized instances.
>
> /Claes
>


From forax at univ-mlv.fr  Sat Mar 28 08:08:04 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 28 Mar 2015 09:08:04 +0100
Subject: RFR: 8071571: Move substring of same string to slow path
In-Reply-To: <CA+kOe0-Q=qwvwszuk=C+NWEncGFKent6w9OMYagZjcb9xL7aYA@mail.gmail.com>
References: <55156FB3.1080006@oracle.com>
	<55157487.10108@oracle.com>	<5515B58B.5070205@oracle.com>	<CA+kOe09wAOZjWjfquzKL9OgOD05B-_x3zC0hd1RN8FmDCimR9A@mail.gmail.com>	<5515C23D.3050906@oracle.com>	<CA+kOe0_n9n0zh_wQgO-FA7DFn+xNjBZ4R-FFaj7PEHJu3o7C6w@mail.gmail.com>	<5515D0F4.7040103@oracle.com>
	<5515D250.10302@Oracle.com>
	<CA+kOe0-Q=qwvwszuk=C+NWEncGFKent6w9OMYagZjcb9xL7aYA@mail.gmail.com>
Message-ID: <55166164.8030000@univ-mlv.fr>


On 03/27/2015 11:01 PM, Martin Buchholz wrote:
> On Fri, Mar 27, 2015 at 2:57 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>
>> Hi,
>>
>> @Martin: does the final have some functional reason to be present?
>> I see it just bulks up the source, reducing readability.  If it is useful
>> to improve performance then fine.
>>
> If you use the idiom
> final Type foo = this.foo;
> and leave out the final,
> there is a risk of a maintainer assigning to foo and introducing a bug.
> Maybe I should stop, since no one seems to understand it?

I really dislike this style,
If you put final on foo you should also put final
on len and on all parameters because following your idea a maintainer 
may introduce a bug.
At that point, you have clutter the whole code with final everywhere for 
a bug that happens rarely.

This kind of bugs (modifying a field that was loaded in a local 
variable) should be catch by a lint tool (or/and IDEs)
and not by asking every developers to add final (randomly).

And final on a local variable has no impact on performance because it 
doesn't appear in the generated bytecode.

Historical note: final was introduce with jdk 1.1 to make explicit that 
the semantics of capturing a local variable in an anonymous class was by 
copying the local variable value and not by capturing the variable 
itself like in Lisp (Ruby, JavaScript, etc.). Since Java 8, you don't 
need to declare local variables 'final' anymore because the compiler 
enforces that captured variables are effectively final.

The other problem of final is that while final on a local variables is 
futile, it's a very important concept on fields, and a awful lot of Java 
devs doesn't make the difference between a field and a local variable 
(both are variables right ?).
And every time a discussion about final on local variable sprung, I'm 
quite sure that we (and i) just add more confusion :(

regards,
R?mi



From forax at univ-mlv.fr  Sat Mar 28 08:11:45 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 28 Mar 2015 09:11:45 +0100
Subject: RFR: 8071571: Move substring of same string to slow path
In-Reply-To: <CA+kOe08BgRGkqEXMu19bEiKj27K34_HbGKR=SNhcm1khGj=-Jg@mail.gmail.com>
References: <55156FB3.1080006@oracle.com>
	<55157487.10108@oracle.com>	<5515B58B.5070205@oracle.com>	<CA+kOe09wAOZjWjfquzKL9OgOD05B-_x3zC0hd1RN8FmDCimR9A@mail.gmail.com>	<5515C23D.3050906@oracle.com>	<CA+kOe0_n9n0zh_wQgO-FA7DFn+xNjBZ4R-FFaj7PEHJu3o7C6w@mail.gmail.com>	<5515D0F4.7040103@oracle.com>
	<CA+kOe08BgRGkqEXMu19bEiKj27K34_HbGKR=SNhcm1khGj=-Jg@mail.gmail.com>
Message-ID: <55166241.1000604@univ-mlv.fr>


On 03/27/2015 10:59 PM, Martin Buchholz wrote:

[...]

> OTOH, if you touch code that uses the denigrated
>
> char foo[]
>
> please change it to
>
> char[] foo
>
> This is yet another of those global changes to the entire jdk sources that
> nobody ever gets around to.

on the same subject, the Java grammar allows this code to compile
   class A {
    int foo() [] {
      return null;
    }
   }

cheers,
R?mi

>
>
> On Fri, Mar 27, 2015 at 2:51 PM, Lev Priima <lev.priima at oracle.com> wrote:
>
>>   Updated and put some more final in other(not @Deprecated) methods:
>> http://cr.openjdk.java.net/~lpriima/8071571/2/
>>
>> Lev
>>
>> On 03/27/2015 11:50 PM, Martin Buchholz wrote:
>>
>>
>>
>> On Fri, Mar 27, 2015 at 1:49 PM, Lev Priima <lev.priima at oracle.com> wrote:
>>
>>>   Martin,
>>>
>>> You mean it should be like this:
>>>          char[] val = value;    /* avoid getfield opcode */
>>>          int end = val.length;
>>> ?
>>>
>>>
>>   Yes.
>>
>> (although I personally like to write it like this:
>>
>>   final char[] value = this.value;
>>   int end = value.length;
>>
>>
>>
>>



From joel.franck at oracle.com  Sat Mar 28 10:24:41 2015
From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=)
Date: Sat, 28 Mar 2015 11:24:41 +0100
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <54F041C2.7040701@gmail.com>
References: <9D775E0E-16CA-43C9-AC30-A691AE7CCC0F@oracle.com>
	<E874F969-AAF8-4E6B-BF85-901088F519CC@oracle.com>
	<D74680E6-22E5-4928-B8E5-CE620DAD2870@oracle.com>
	<E47D5487-9CFD-4F39-AC85-1B8F4ED81533@oracle.com>
	<FBB79C47-AC33-463D-BFA4-6D8B1CF80C00@oracle.com>
	<54EE4A87.8050807@oracle.com>
	<19E11AB6-1504-4278-8256-154A61D7CBD9@oracle.com>
	<54EF4B2C.3000002@oracle.com> <54EF8FC0.9060501@gmail.com>
	<54EF91A8.4050303@gmail.com>
	<915E482B-4BE9-4BB1-AF9B-712C5FF12A3F@oracle.com>
	<54F041C2.7040701@gmail.com>
Message-ID: <0107D848-B42D-4E50-B782-FB314313BB4E@oracle.com>

Hi,

> On 27 Feb 2015, at 11:06, Peter Levart <peter.levart at gmail.com> wrote:
> On 02/27/2015 10:27 AM, Joel Borggr?n-Franck wrote:
>>> On 26 feb 2015, at 22:35, Peter Levart <peter.levart at gmail.com>
>>>  wrote:
>>> On 02/26/2015 10:27 PM, Peter Levart wrote:
>>> 
>>>> The m.setAccessible(true) for the methods is needed to access methods of non-public annotations, right? This call could be moved to AnnotationType constructor as there it will be performed only once per Method object.
>>>> 
>>> ...which will have the added benefit in that it will guarantee that only one MethodAccessor object per Method will ever be constructed instead of two?
>>> 
>>> 
>> I don?t see this. setAccessible sets override in AccessibleObject, I don?t see a new MethodAccessor being generated here.
> 
> My fault! I was mistakenly thinking of Field objects in the context of setAccessible(boolean). If you use a Field object in two modes it will create and retain two different FieldAccessors (because they are different implementations in case field is final).
> 
>> But I agree with you, and setting it as accessible in the AnnotationType constructor should arguably be more secure since then we know it isn?t shared since we just got our copy fresh from getDeclaredMethods().
> 
> That's a good point from maintainability perspective, yes, if someone some time decides to "optimize" the AnnotationType. I think it would be nice if AnnotationType documents that members() method returns Method objects that are pre-conditioned with setAccessible(true) and that users should not change this flag.
> 

I don?t want to do this in AnnotationType without a bigger overhaul that may be slightly incompatible and therefor should be 9 only. I do want to backport this fix to 8 however, so here is an alternative solution that should be safe and correct at the cost of extra allocation in the path for custom implementations of annotations (that should be rare).

New webrev:

http://cr.openjdk.java.net/~jfranck/8073056/webrev.02/

cheers
/Joel

From peter.levart at gmail.com  Sat Mar 28 12:42:03 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 28 Mar 2015 13:42:03 +0100
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <0107D848-B42D-4E50-B782-FB314313BB4E@oracle.com>
References: <9D775E0E-16CA-43C9-AC30-A691AE7CCC0F@oracle.com>
	<E874F969-AAF8-4E6B-BF85-901088F519CC@oracle.com>
	<D74680E6-22E5-4928-B8E5-CE620DAD2870@oracle.com>
	<E47D5487-9CFD-4F39-AC85-1B8F4ED81533@oracle.com>
	<FBB79C47-AC33-463D-BFA4-6D8B1CF80C00@oracle.com>
	<54EE4A87.8050807@oracle.com>
	<19E11AB6-1504-4278-8256-154A61D7CBD9@oracle.com>
	<54EF4B2C.3000002@oracle.com> <54EF8FC0.9060501@gmail.com>
	<54EF91A8.4050303@gmail.com>
	<915E482B-4BE9-4BB1-AF9B-712C5FF12A3F@oracle.com>
	<54F041C2.7040701@gmail.com>
	<0107D848-B42D-4E50-B782-FB314313BB4E@oracle.com>
Message-ID: <5516A19B.90502@gmail.com>



On 03/28/2015 11:24 AM, Joel Borggr?n-Franck wrote:
> Hi,
>
>> On 27 Feb 2015, at 11:06, Peter Levart <peter.levart at gmail.com> wrote:
>> On 02/27/2015 10:27 AM, Joel Borggr?n-Franck wrote:
>>>> On 26 feb 2015, at 22:35, Peter Levart <peter.levart at gmail.com>
>>>>   wrote:
>>>> On 02/26/2015 10:27 PM, Peter Levart wrote:
>>>>
>>>>> The m.setAccessible(true) for the methods is needed to access methods of non-public annotations, right? This call could be moved to AnnotationType constructor as there it will be performed only once per Method object.
>>>>>
>>>> ...which will have the added benefit in that it will guarantee that only one MethodAccessor object per Method will ever be constructed instead of two?
>>>>
>>>>
>>> I don?t see this. setAccessible sets override in AccessibleObject, I don?t see a new MethodAccessor being generated here.
>> My fault! I was mistakenly thinking of Field objects in the context of setAccessible(boolean). If you use a Field object in two modes it will create and retain two different FieldAccessors (because they are different implementations in case field is final).
>>
>>> But I agree with you, and setting it as accessible in the AnnotationType constructor should arguably be more secure since then we know it isn?t shared since we just got our copy fresh from getDeclaredMethods().
>> That's a good point from maintainability perspective, yes, if someone some time decides to "optimize" the AnnotationType. I think it would be nice if AnnotationType documents that members() method returns Method objects that are pre-conditioned with setAccessible(true) and that users should not change this flag.
>>
> I don?t want to do this in AnnotationType without a bigger overhaul that may be slightly incompatible and therefor should be 9 only. I do want to backport this fix to 8 however, so here is an alternative solution that should be safe and correct at the cost of extra allocation in the path for custom implementations of annotations (that should be rare).
>
> New webrev:
>
> http://cr.openjdk.java.net/~jfranck/8073056/webrev.02/
>
> cheers
> /Joel

Hi Joel,

If you really must add new methods to Method, ReflectAccess, 
LangReflectAccess and ReflectionFactory then you could expose a method 
called "invokeUnchecked" that would skip access checks, so you don't 
have to copy the Method object just to get a one-time access to the 
possibly inaccessible method. But this is good as it is, since the code 
path is normally not used - it's there only for consistency's sake, right?


Regards, Peter



From kumar.x.srinivasan at oracle.com  Sat Mar 28 14:06:05 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Sat, 28 Mar 2015 07:06:05 -0700
Subject: [9] RFR 8074840: Resolve disabled warnings for libjli and
	libjli_static
In-Reply-To: <550C60CC.1080208@oracle.com>
References: <550C60CC.1080208@oracle.com>
Message-ID: <5516B54D.9070502@oracle.com>

Hi Mikael,

Thank you so much for making these changes!.  Looks generally good.

ergo_i586.c: why ? MacOSX ?

cmdtoargs.c: URK!. :-[

Thanks
Kumar

On 3/20/2015 11:02 AM, Mikael Vidstedt wrote:
>
> Please review the following change which fixes a number of native 
> compilation warnings in files related to libjli.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074840
> Webrev: 
> http://cr.openjdk.java.net/~mikael/webrevs/8074840/webrev.01/webrev/
>
> I built the code across all the OracleJDK platforms and there were no 
> warnings on any of the platforms (in the files related to this 
> change). I'm taking suggestions on specific tests to run.
>
> Some specifics:
>
> Unfortunately there is no intrinsic for cpuid in Solaris Studio, so I 
> had to keep the inline asm code and the corresponding flag to disable 
> the related warning (E_ASM_DISABLES_OPTIMIZATION). The alternative 
> would be to move it out into a dedicated assembly file, but that seems 
> like more trouble than it's worth given that the warning is harmless.
>
> I'm not entirely happy with the unsigned cast in parse_manifest.c:196, 
> but unfortunately the windows prototype for read() takes an unsigned 
> as its last argument, where All(tm) other platforms take a size_t. In 
> this specific case 'len' will never be be more than END_MAXLEN = 
> 0xFFFF + ENDHDR = 0xFFFF + 22 = 0x10015, meaning it will comfortably 
> fit in an unsigned on the platforms we support. But if somebody has 
> suggestions I'm all ears, doing the #ifdef dance is of course also an 
> option.
>
> Note that the warnings were temporarily disabled as part of 
> JDK-8074096 [1] until such time they could be fixed the proper way. 
> Also note that this change supersedes the earlier change [2] Dmitry 
> had out for review. The bug [3] corresponding to that webrev will be 
> closed as a duplicate of this bug (JDK-8074839).
>
> Cheers,
> Mikael
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8074096
> [2] http://cr.openjdk.java.net/~dsamersoff/JDK-8073175/webrev.01/
> [3] https://bugs.openjdk.java.net/browse/JDK-8073175
>



From joel.franck at oracle.com  Sat Mar 28 14:13:28 2015
From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=)
Date: Sat, 28 Mar 2015 15:13:28 +0100
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <5516A19B.90502@gmail.com>
References: <9D775E0E-16CA-43C9-AC30-A691AE7CCC0F@oracle.com>
	<E874F969-AAF8-4E6B-BF85-901088F519CC@oracle.com>
	<D74680E6-22E5-4928-B8E5-CE620DAD2870@oracle.com>
	<E47D5487-9CFD-4F39-AC85-1B8F4ED81533@oracle.com>
	<FBB79C47-AC33-463D-BFA4-6D8B1CF80C00@oracle.com>
	<54EE4A87.8050807@oracle.com>
	<19E11AB6-1504-4278-8256-154A61D7CBD9@oracle.com>
	<54EF4B2C.3000002@oracle.com> <54EF8FC0.9060501@gmail.com>
	<54EF91A8.4050303@gmail.com>
	<915E482B-4BE9-4BB1-AF9B-712C5FF12A3F@oracle.com>
	<54F041C2.7040701@gmail.com>
	<0107D848-B42D-4E50-B782-FB314313BB4E@oracle.com>
	<5516A19B.90502@gmail.com>
Message-ID: <941EBDC5-2A1F-439C-8AC3-F506EEE0D4C4@oracle.com>


> On 28 Mar 2015, at 13:42, Peter Levart <peter.levart at gmail.com> wrote:
> On 03/28/2015 11:24 AM, Joel Borggr?n-Franck wrote:
>> Hi,
>> 
>> 
>>> On 27 Feb 2015, at 11:06, Peter Levart <peter.levart at gmail.com>
>>>  wrote:
>>> On 02/27/2015 10:27 AM, Joel Borggr?n-Franck wrote:
>>> 
>>>>> On 26 feb 2015, at 22:35, Peter Levart <peter.levart at gmail.com>
>>>>> 
>>>>>  wrote:
>>>>> On 02/26/2015 10:27 PM, Peter Levart wrote:
>>>>> 
>>>>> 
>>>>>> The m.setAccessible(true) for the methods is needed to access methods of non-public annotations, right? This call could be moved to AnnotationType constructor as there it will be performed only once per Method object.
>>>>>> 
>>>>>> 
>>>>> ...which will have the added benefit in that it will guarantee that only one MethodAccessor object per Method will ever be constructed instead of two?
>>>>> 
>>>>> 
>>>>> 
>>>> I don?t see this. setAccessible sets override in AccessibleObject, I don?t see a new MethodAccessor being generated here.
>>>> 
>>> My fault! I was mistakenly thinking of Field objects in the context of setAccessible(boolean). If you use a Field object in two modes it will create and retain two different FieldAccessors (because they are different implementations in case field is final).
>>> 
>>> 
>>>> But I agree with you, and setting it as accessible in the AnnotationType constructor should arguably be more secure since then we know it isn?t shared since we just got our copy fresh from getDeclaredMethods().
>>>> 
>>> That's a good point from maintainability perspective, yes, if someone some time decides to "optimize" the AnnotationType. I think it would be nice if AnnotationType documents that members() method returns Method objects that are pre-conditioned with setAccessible(true) and that users should not change this flag.
>>> 
>>> 
>> I don?t want to do this in AnnotationType without a bigger overhaul that may be slightly incompatible and therefor should be 9 only. I do want to backport this fix to 8 however, so here is an alternative solution that should be safe and correct at the cost of extra allocation in the path for custom implementations of annotations (that should be rare).
>> 
>> New webrev:
>> 
>> 
>> http://cr.openjdk.java.net/~jfranck/8073056/webrev.02/
>> 
>> 
>> cheers
>> /Joel
>> 
> 
> Hi Joel,
> 
> If you really must add new methods to Method, ReflectAccess, LangReflectAccess and ReflectionFactory then you could expose a method called "invokeUnchecked" that would skip access checks, so you don't have to copy the Method object just to get a one-time access to the possibly inaccessible method.

IMO this would require quite a lot of investment validating all the possible ways it may be a security concern. I don?t think this is worth it given the very limited use, tough I find the idea interesting.

> But this is good as it is, since the code path is normally not used - it's there only for consistency's sake, right?
> 

Yes, that is my belief. I don?t know of any AnnotatedElements needing this except in testing, of course that isn?t to say there are none.

cheers
/Joel

From martijnverburg at gmail.com  Sat Mar 28 15:40:37 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sat, 28 Mar 2015 15:40:37 +0000
Subject: Low hanging fruit in JBS for the Adoption Group Hackdays to tackle?
Message-ID: <CAP7YuATD644F0sttqNrHsQbQBoCAzuSQ7EqivN7J9NqZi7yv1g@mail.gmail.com>

Hi all,

We had a short discussion in Adoption Group about having its members
triaging issues in JBS to identify low-hanging fruit for new OpenJDK
developers to tackle.

Dalibor sensibly suggested that each project/group was far more familiar
with which issues would be appropriate and that we should simply list those
recommended issues in the Adoption Wiki.

So I'm starting by asking core-libs as I believe it covers the part of
OpenJDK that is most accessible to new OpenJDK developers (please correct
me if I'm wrong!).

FYI - Currently London runs a hackday 1/month and several other user groups
host more ad-hoc events.  We're looking to expand this programme globally,
but would like to firstly have a list of concrete JBS issue for people to
tackle.

Q:  Do some members of this group have some low hanging fruit issues they'd
like to nominate?

Cheers,
Martijn


From peter.levart at gmail.com  Sun Mar 29 11:44:53 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 29 Mar 2015 13:44:53 +0200
Subject: RFR: 8061950: Class.getMethods() exhibits quadratic time
	complexity
In-Reply-To: <CA+kOe0_D3RAJ4mS3Z6-izSVwRCWHAgguDCZKL9K5TFC=o5gnOw@mail.gmail.com>
References: <CA+kOe08YW=MG+W6sMOZS9cvLXMtVa1OX7u2P0LxEjfoeGT4CGw@mail.gmail.com>	<900D2AE3-B3A6-4B1B-B25A-C564B10334AA@oracle.com>	<54492255.3040108@gmail.com>	<EAE058BE-B5F0-4F53-A9F8-36F3BFEEA703@oracle.com>	<544D58D4.7020909@gmail.com>	<544D7B74.5060607@gmail.com>	<FF8A5786-0840-45D9-8B36-0B60BB2DBA98@oracle.com>	<5450CEE9.7060707@gmail.com>	<F81AE132-D4FE-48F6-AAA8-A3580F5194B4@oracle.com>	<545120D2.5010301@gmail.com>	<54526D10.5060101@gmail.com>	<CA+kOe0_nf-fasgbhQA8zJ60wTxpAfuOYEC2YAvtHE6-awJsBrA@mail.gmail.com>	<54551D2F.407@gmail.com>	<545A572D.3050608@gmail.com>	<F15D5F8E-2E65-4243-A7AA-C30CF4DBF935@oracle.com>	<547B90A0.1080508@gmail.com>	<CA+kOe0-bC9WwOhkb6555oxGBHbLOX5aW7H3aB4Y187Q1CTpP5g@mail.gmail.com>	<547CE713.2020905@gmail.com>
	<CA+kOe0_D3RAJ4mS3Z6-izSVwRCWHAgguDCZKL9K5TFC=o5gnOw@mail.gmail.com>
Message-ID: <5517E5B5.5000308@gmail.com>

Hi,

I'd like to resurrect a patch I did a couple of months ago. Here's a 
rebased webrev (no changes from webrev.07):

http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods/webrev.08/


Regards, Peter


On 03/23/2015 11:42 PM, Martin Buchholz wrote:
> So Peter, ... time to rebase one of your getMethods patches?
>
> On Mon, Dec 1, 2014 at 2:09 PM, Peter Levart <peter.levart at gmail.com 
> <mailto:peter.levart at gmail.com>> wrote:
>
>
>     On 12/01/2014 09:09 PM, Martin Buchholz wrote:
>>     Looking at Peter's work here is still on my long TODO list, but I was
>>     hoping first to get in my concurrency correctness fixes for core
>>     reflection, which conflicts slightly...
>
>     No problem. I can rebase the patch after your fixes are in.
>
>     Regards, Peter
>
>
>>     On Sun, Nov 30, 2014 at 1:48 PM, Peter Levart<peter.levart at gmail.com>  <mailto:peter.levart at gmail.com>  wrote:
>>>     Hi Joel,
>>>
>>>     I managed to find some time to create some tests for this patch:
>>>
>>>     http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods/webrev.07/  <http://cr.openjdk.java.net/%7Eplevart/jdk9-dev/Class.getMethods/webrev.07/>
>>>
>>>     Both MethodTable and HashArray unit tests are provided. I had to create a
>>>     special TestProxy to access package-private classes from the tests.
>>>
>>>     There are no changes to j.l.Class or j.l.r.Method from webrev.06 (I just
>>>     re-based them to current tip).
>>>
>>>     I also included the patch to StarInheritance test that I forgot to include
>>>     in webrev.06.
>>>
>>>     Comments inline...
>>>
>>>     On 11/13/2014 10:39 AM, Joel Borggr?n-Franck wrote:
>>>>     Hi Peter,
>>>>
>>>>     As always, thanks for taking a look at this,
>>>>
>>>>     This is quite big so in order to make this more approachable perhaps you
>>>>     can split the patch up into a series? If you start with creating the
>>>>     MethodTable interface, adding tests for how the interface should behave and
>>>>     refactored the current MethodArray into implementing that interface while
>>>>     also changing the lookup logic that would be easier to review.
>>>     Well, there's not much to refactor in MethodArray when implementing
>>>     MethodTable. They are two entirely different APIs with entirely different
>>>     implementations.
>>>
>>>>     Then you could add different implementations of MethodTable (with
>>>>     additional unit tests) as follow up patches.
>>>     You can view the MethodTable.SimpleArrayImpl as the basic implementation of
>>>     the MethodTable API  and a replacement for MethodArray.
>>>     MethodTable.HashArrayImpl is the alternative implementation for bigger
>>>     sizes. The same unit tests are executed against both implementations.
>>>
>>>>     I am a bit concerned about the size and scope of the implementations. In
>>>>     general I would prefer if you targeted these to the precise need of core
>>>>     reflection today. If you want to expand these to general purpose data
>>>>     structures (even internal ones) I think that is a larger effort.
>>>     I stripped HashArray and only left those methods that are needed to
>>>     implement MethodTable API and execute the tests.
>>>
>>>>     In general I think the changes to Class are sound, but there is a slight
>>>>     change in the default method pruning. The call to removeLessSpecifics was
>>>>     deliberately placed at the end, so that all default methods would be present
>>>>     (the algorithm is sensitive to the order of pair vise comparisons). Since we
>>>>     add methods in a deterministic order, I think consolidate() as you go should
>>>>     result in the same set of methods, but I haven?t 100% convinced myself of
>>>>     this just yet.
>>>     I think it results in the same methods. I haven't yet found an example where
>>>     it would result in different set of methods. All JDK classes return same
>>>     methods with current implementation as with patched one.
>>>
>>>>     Have you double checked that all methods returning root Method/Ctors are
>>>>     private?
>>>     I checked all usages of private methods that I have changed and are now
>>>     returning root objects and made sure those are copied before being exposed
>>>     to the outside or being modified.
>>>
>>>     Regards, Peter
>>>
>>>
>>>>     On 5 nov 2014, at 17:58, Peter Levart<peter.levart at gmail.com>  <mailto:peter.levart at gmail.com>  wrote:
>>>>
>>>>>     Here's new webrev:
>>>>>
>>>>>     http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods/webrev.06/  <http://cr.openjdk.java.net/%7Eplevart/jdk9-dev/Class.getMethods/webrev.06/>
>>>>>
>>>>>
>>>>>     The optimizations made from webrev.05 are:
>>>>>
>>>>>     - getMethod() skips construction of MethodTable if there are no
>>>>>     (super)interfaces.
>>>>>     - getMethods() returns just declared public methods if there are no
>>>>>     superclass and no (super)interfaces.
>>>>>     - comparing method parameter types is optimized by adding two methods to
>>>>>     Method/LangReflectAccess/ReflectionFactory.
>>>>>
>>>>>     New MethodTable implementation based on a linear-probe hash table is a
>>>>>     space/garbage improvement. I took IdentityHashMap, removed unneeded stuff
>>>>>     and modified it's API. The result is a HashArray. It's API is similar in
>>>>>     function and form to java.util.Map, but doesn't use separate keys and
>>>>>     values. An element of HashArray is a key and a value at the same time.
>>>>>     Elements are always non-null, so the method return values are unambiguous.
>>>>>     As HashArray is a linear-probe hash table and there are no Map.Entry objects
>>>>>     involved, the underlying data structure is very simple and memory efficient.
>>>>>     It is just a sparse array of elements with length that is always a power of
>>>>>     two and larger than 3 * size / 2. It also features overriddable element
>>>>>     equals/hashCode methods. I made it a separate generic class because I think
>>>>>     it can find it's usage elsewhere (for example as a cannonicalizing cache).
>>>>>
>>>>>     Since HashArray based MethodTable is more space-efficient I moved the
>>>>>     line between simple array based and HashArray based MethodTable down to 20
>>>>>     elements to minimize the worst-case scenario effect. Calling getMethods() on
>>>>>     all rt.jar classes now constructs about 3/4 simple array based and 1/4
>>>>>     HashArray based MethodTables.
>>>>>
>>>>     HashArray.java:
>>>>
>>>>     I was hoping for a decent set of unit tests for the new HashArray<T> data
>>>>     structure. I think it is reasonable to test the corner cases/non-trivial
>>>>     areas of the table (closeDeletion(), rezise() etc). Perhaps also run these
>>>>     over the simple implementation. Also, please document thread safety (there
>>>>     is none IFAICT it should just be noted).
>>>>
>>>>     Instead of using inheritance to change the behavior of equals() and hash()
>>>>     you could give it two lambdas at table creation time, a ToIntFunction<T> for
>>>>     hash() and a BiPredicate<T,T> for equals(). Might not give you the
>>>>     performance we need though.
>>>>
>>>>     Note that the file doesn?t actually compile in jdk9/dev, you have two
>>>>     unchecked casts and we build with -Werror.
>>>>
>>>>     MethodTable.java
>>>>
>>>>     HashMapImpl is missing serialVersionUID, but it looks like this class
>>>>     won?t be needed at all.
>>>>
>>>>
>>>>>     Here's also Martin's ManyMethodsBenchmark:
>>>>>
>>>>>     Original:
>>>>>
>>>>>     Base class load time: 129.95 ms
>>>>>     getDeclaredMethods: 65521 methods, 36.58 ms total time, 0.0006 ms per
>>>>>     method
>>>>>     getMethods        : 65530 methods, 47.43 ms total time, 0.0007 ms per
>>>>>     method
>>>>>     Derived class load time: 32216.09 ms
>>>>>     getDeclaredMethods: 65521 methods, 35.05 ms total time, 0.0005 ms per
>>>>>     method
>>>>>     getMethods        : 65530 methods, 8068.66 ms total time, 0.1231 ms per
>>>>>     method
>>>>>
>>>>>
>>>>>     Patched (using HashArray based MethodTable):
>>>>>
>>>>>     Base class load time: 126.00 ms
>>>>>     getDeclaredMethods: 65521 methods, 36.83 ms total time, 0.0006 ms per
>>>>>     method
>>>>>     getMethods        : 65530 methods, 45.08 ms total time, 0.0007 ms per
>>>>>     method
>>>>>     Derived class load time: 31865.27 ms
>>>>>     getDeclaredMethods: 65521 methods, 35.01 ms total time, 0.0005 ms per
>>>>>     method
>>>>>     getMethods        : 65530 methods, 78.05 ms total time, 0.0012 ms per
>>>>>     method
>>>>>
>>>>>
>>>>>     All 86 jtreg test in java.lang/Class/ and java/lang/reflect/ still pass.
>>>>>
>>>>     I have seen discussion about allocation, should we measure and compare?
>>>>     You can probably use the Hotspot impl of ThreadMXBean to get the allocation
>>>>     in the tread.
>>>>
>>>>     Also, it might be time to fix the boolean parameters:
>>>>
>>>>     2741         Method[] declaredMethods = privateGetDeclaredMethods(true);
>>>>     2742         Class<?> superclass = getSuperclass();
>>>>     2743         Class<?>[] interfaces = getInterfaces(false);
>>>>
>>>>     Perhaps just add boolean constants somewhere so that it is easier to
>>>>     decode.
>>>>
>>>>     2741         Method[] declaredMethods =
>>>>     privateGetDeclaredMethods(PUBLIC_METHOD_ONLY);
>>>>     2742         Class<?> superclass = getSuperclass();
>>>>     2743         Class<?>[] interfaces = getInterfaces(NO_COPY_RESULT);
>>>>
>>>>     or so.
>>>>
>>>>     HashArray.java:
>>>>
>>>>     155         if (lookupObj == null) throw new NullPointerException();
>>>>
>>>>     use Objects.requreNonNull() ?
>>>>
>>>>     cheers
>>>>     /Joel
>>>>
>
>



From david.holmes at oracle.com  Mon Mar 30 04:07:23 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Mar 2015 14:07:23 +1000
Subject: [9] RFR 8074840: Resolve disabled warnings for libjli and
	libjli_static
In-Reply-To: <550C60CC.1080208@oracle.com>
References: <550C60CC.1080208@oracle.com>
Message-ID: <5518CBFB.4020706@oracle.com>

Hi Mikael,

On 21/03/2015 4:02 AM, Mikael Vidstedt wrote:
>
> Please review the following change which fixes a number of native
> compilation warnings in files related to libjli.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074840
> Webrev:
> http://cr.openjdk.java.net/~mikael/webrevs/8074840/webrev.01/webrev/

Mostly looks okay, but I find some of these odd. For example:

src/java.base/share/native/libjli/java.c

if (threadStackSize < STACK_SIZE_MINIMUM)

becomes:

  if (threadStackSize < (jlong)STACK_SIZE_MINIMUM) {

but integer promotion would make that cast implicitly. And why should 
the comparison cause a warning when the subsequent assignment does not? 
What was the actual warning and on what compiler?

---

I second Kumar's query about the ergo_i586.c changes. Seems to me that 
if this is causing a problem on non Solaris/Linux then the problem is in 
the makefile (jdk/lib/CoreLibraries.gmk) because this file should be 
being excluded on platforms it is not used.

---

src/java.base/windows/native/libjli/cmdtoargs.c

Surely charLength should be a ptrdiff_t ?

---

src/java.base/windows/native/libjli/java_md.c

Aside: I find it quite bizarre that the vsnprintf family of methods take 
a size_t as the count but return an int, when on success it has to 
return the number of characters written!

---

Thanks,
David


> I built the code across all the OracleJDK platforms and there were no
> warnings on any of the platforms (in the files related to this change).
> I'm taking suggestions on specific tests to run.
>
> Some specifics:
>
> Unfortunately there is no intrinsic for cpuid in Solaris Studio, so I
> had to keep the inline asm code and the corresponding flag to disable
> the related warning (E_ASM_DISABLES_OPTIMIZATION). The alternative would
> be to move it out into a dedicated assembly file, but that seems like
> more trouble than it's worth given that the warning is harmless.
>
> I'm not entirely happy with the unsigned cast in parse_manifest.c:196,
> but unfortunately the windows prototype for read() takes an unsigned as
> its last argument, where All(tm) other platforms take a size_t. In this
> specific case 'len' will never be be more than END_MAXLEN = 0xFFFF +
> ENDHDR = 0xFFFF + 22 = 0x10015, meaning it will comfortably fit in an
> unsigned on the platforms we support. But if somebody has suggestions
> I'm all ears, doing the #ifdef dance is of course also an option.
>
> Note that the warnings were temporarily disabled as part of JDK-8074096
> [1] until such time they could be fixed the proper way. Also note that
> this change supersedes the earlier change [2] Dmitry had out for review.
> The bug [3] corresponding to that webrev will be closed as a duplicate
> of this bug (JDK-8074839).
>
> Cheers,
> Mikael
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8074096
> [2] http://cr.openjdk.java.net/~dsamersoff/JDK-8073175/webrev.01/
> [3] https://bugs.openjdk.java.net/browse/JDK-8073175
>


From erik.joelsson at oracle.com  Mon Mar 30 08:02:24 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 30 Mar 2015 10:02:24 +0200
Subject: RFR 9: 8076184 Cleanup compile/link warnings on Solaris
In-Reply-To: <551592F4.404@Oracle.com>
References: <551592F4.404@Oracle.com>
Message-ID: <55190310.3090503@oracle.com>

Looks good to me.

/Erik

On 2015-03-27 18:27, Roger Riggs wrote:
> Please review minor cleanups to compile and builds on Solaris.
> Some entry points had been renamed but not updated in the 
> make/mapfiles/reorder-xxx files
> and a compilation warning remedied by putting declarations at the top 
> of the .c file.
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-reorder-sparc-8076184/
> Issue:
>     https://bugs.openjdk.java.net/browse/JDK-8076184
>
> Thanks, Roger
>



From dmitry.samersoff at oracle.com  Mon Mar 30 08:45:53 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 30 Mar 2015 11:45:53 +0300
Subject: [9] RFR 8074840: Resolve disabled warnings for libjli and
	libjli_static
In-Reply-To: <550C60CC.1080208@oracle.com>
References: <550C60CC.1080208@oracle.com>
Message-ID: <55190D41.7040300@oracle.com>

Mikael,

Thank you for doing it!

Looks good for me (fill free to ignore comments below).


splashscreen_stubs.c
java_md_macosx.c:

855: it might be better to use rslt directly

parse_manifest.c:

196: one pf possible solution is declare len as unsigned int and cast it
to (jlong) at 192 if necessary

-Dmitry




On 2015-03-20 21:02, Mikael Vidstedt wrote:
> 
> Please review the following change which fixes a number of native
> compilation warnings in files related to libjli.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074840
> Webrev:
> http://cr.openjdk.java.net/~mikael/webrevs/8074840/webrev.01/webrev/
> 
> I built the code across all the OracleJDK platforms and there were no
> warnings on any of the platforms (in the files related to this change).
> I'm taking suggestions on specific tests to run.
> 
> Some specifics:
> 
> Unfortunately there is no intrinsic for cpuid in Solaris Studio, so I
> had to keep the inline asm code and the corresponding flag to disable
> the related warning (E_ASM_DISABLES_OPTIMIZATION). The alternative would
> be to move it out into a dedicated assembly file, but that seems like
> more trouble than it's worth given that the warning is harmless.
> 
> I'm not entirely happy with the unsigned cast in parse_manifest.c:196,
> but unfortunately the windows prototype for read() takes an unsigned as
> its last argument, where All(tm) other platforms take a size_t. In this
> specific case 'len' will never be be more than END_MAXLEN = 0xFFFF +
> ENDHDR = 0xFFFF + 22 = 0x10015, meaning it will comfortably fit in an
> unsigned on the platforms we support. But if somebody has suggestions
> I'm all ears, doing the #ifdef dance is of course also an option.
> 
> Note that the warnings were temporarily disabled as part of JDK-8074096
> [1] until such time they could be fixed the proper way. Also note that
> this change supersedes the earlier change [2] Dmitry had out for review.
> The bug [3] corresponding to that webrev will be closed as a duplicate
> of this bug (JDK-8074839).
> 
> Cheers,
> Mikael
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8074096
> [2] http://cr.openjdk.java.net/~dsamersoff/JDK-8073175/webrev.01/
> [3] https://bugs.openjdk.java.net/browse/JDK-8073175
> 


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


From chris.hegarty at oracle.com  Mon Mar 30 09:11:13 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 30 Mar 2015 10:11:13 +0100
Subject: RFR: JDK-8068721 - RMI-IIOP communication fails when
	ConcurrentHashMap is passed to remote method
In-Reply-To: <5515AE6E.9080606@oracle.com>
References: <551084E3.6050702@oracle.com> <5515AE6E.9080606@oracle.com>
Message-ID: <55191331.7080406@oracle.com>


On 27/03/15 19:24, Mark Sheppard wrote:
> Hi
>      based on feedback webrev has been updated as follows:
>
> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev.01/

The changes in the corba repo look good to me Mark.

-Chris.

> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev.01/
>
> regards
> Mark
>
> On 23/03/2015 21:25, Mark Sheppard wrote:
>> Hi
>>  please oblige and review the following fix
>>
>> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev/
>> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev/
>>
>>
>> which addresses the issue in
>> https://bugs.openjdk.java.net/browse/JDK-8068721
>>
>> This relates to RMI-IIOP and the interplay between custom marshalling
>> of ValueTypes and
>> the corresponding serialization of a Java class, in this case
>> ConcurrentHashMap.
>>
>> ConcurrentHashMap changed its structure in jdk8 from that used in jdk7.
>> This resulted in modification to the readObject and writeObject methods,
>> and in particular, former serial fields were removed, resulting in
>> writeObject using PutField and readObject using defaultReadObject.
>> The writeObject invokes the putFields method of an ObjectOutputStream
>> multiple times, and assumes
>> that it will receive the same PutField object instance for each
>> invocation. The spec
>> doesn't endorse this behaviour - but that's what the implementation of
>> ObjectOutputStream
>> provides. However in the case of RMI-IIOP, the OutputStreamHook, a
>> subclass of ObjectOutputStream, returns a new instance for each
>> putFields invocation. Thus, the ConcurrentHashMap writeObject results
>> in improper serialization in the context
>> of RMI-IIOP.
>> In the unmarshalling flow of ConcurrentHashMap, the readObject now
>> uses defaultReadObject rather than GetField
>> In this call flow the IIOPInputStream attempts to ignore any primitive
>> field, in the serialized data, that doesn't
>> correspond with a reflective field of the object. However, it leaves
>> the primitive in the stream.
>> Thus, in the case of ConcurrentHashMap, which has serialized two
>> integers and
>> an array of Segments (subclass of ReentrantLock), this results in
>> erroneous
>> deserialization, with a misinterpretation of a value tag in the stream
>> as an array length
>> and an attempt to allocate a very large array ensues, with an
>> exception being thrown.
>>
>> The OutputStreamHook now returns the same instance of PutField
>> allocated for each separate call of putFields method.
>> This highlights a need to tighten up and disambiguate the
>> OutputObjectStream spec for putFields.
>>
>> IIOPInputStream now removes the primitive values from the stream.
>>
>> regards
>> Mark
>


From daniel.fuchs at oracle.com  Mon Mar 30 09:27:21 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 30 Mar 2015 11:27:21 +0200
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <CA+kOe0-aZzccotBTbc_0-_ohF_W_Ea4ZSLSY--1yghRFCDXGFw@mail.gmail.com>
References: <5513F6CE.3040505@oracle.com>
	<5513FB77.90305@oracle.com>	<55140D06.4030201@gmail.com>
	<55140FC0.4060104@oracle.com>	<55141540.9050600@gmail.com>
	<55153E88.7070200@oracle.com>	<551551BF.8040902@gmail.com>	<CA+kOe0-Tw1+TbJQ-NX0Zu5d=QcVsbA0hd+oW+H4CDEscsXYFKA@mail.gmail.com>	<5515E18E.8000204@oracle.com>
	<CA+kOe0-aZzccotBTbc_0-_ohF_W_Ea4ZSLSY--1yghRFCDXGFw@mail.gmail.com>
Message-ID: <551916F9.1000803@oracle.com>

Thanks all for your reviews!

If I don't hear more then
http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.01/

is what I'm going to push.

best regards,

-- daniel

On 28/03/15 00:39, Martin Buchholz wrote:
> Claes,
>
> Right you are - I stand corrected!
>
> On Fri, Mar 27, 2015 at 4:02 PM, Claes Redestad <claes.redestad at oracle.com>
> wrote:
>
>>
>> On 2015-03-27 21:12, Martin Buchholz wrote:
>>
>>> Random advice - the default concurrency level of ConcurrentHashMap is 16,
>>> and that is almost always more than needed, probably also including here.
>>>
>>
>> I believe JSR-166e (JDK8 and onwards) mostly removed the concept of
>> concurrency level from ConcurrentHashMap (while it's still there in some
>> constructors to confuse things). I recall some tests showing that the
>> difference in footprint between CHM and regular HashMap/Hashtable is now
>> negligible even for empty, default-initialized instances.
>>
>> /Claes
>>



From Alan.Bateman at oracle.com  Mon Mar 30 10:07:34 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 30 Mar 2015 11:07:34 +0100
Subject: RFR 9: 8076184 Cleanup compile/link warnings on Solaris
In-Reply-To: <551592F4.404@Oracle.com>
References: <551592F4.404@Oracle.com>
Message-ID: <55192066.4050503@oracle.com>

On 27/03/2015 17:27, Roger Riggs wrote:
> Please review minor cleanups to compile and builds on Solaris.
> Some entry points had been renamed but not updated in the 
> make/mapfiles/reorder-xxx files
> and a compilation warning remedied by putting declarations at the top 
> of the .c file.
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-reorder-sparc-8076184/
> Issue:
>     https://bugs.openjdk.java.net/browse/JDK-8076184
This looks good to me too. At some point we need to see about either 
deleting or resurrecting the re-ordering as it has been rotting for many 
years.

-Alan.


From mikhail.cherkasov at oracle.com  Mon Mar 30 10:27:19 2015
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Mon, 30 Mar 2015 13:27:19 +0300
Subject: [8] RFR of 8066985: Java Webstart downloading packed files can
	result in Timezone set to UTC
In-Reply-To: <55157E45.1030204@oracle.com>
References: <550976B9.6030503@oracle.com> <5509F73C.6000306@oracle.com>
	<550AD4C9.9030905@oracle.com> <550AEF48.4070904@gmail.com>
	<550AF969.7070706@gmail.com> <550C36FD.701@oracle.com>
	<5511C5BE.2010809@oracle.com> <5511E9CB.7050504@oracle.com>
	<5512850F.90701@oracle.com> <5512D20D.4070709@oracle.com>
	<55145EBE.7070005@oracle.com> <55157E45.1030204@oracle.com>
Message-ID: <55192507.4090704@oracle.com>


On 3/27/2015 6:59 PM, Kumar Srinivasan wrote:
> yes that will work!, also why aren't all  these final ? 
fixed: http://cr.openjdk.java.net/~mcherkas/8066985/webrev.08/




From mark.sheppard at oracle.com  Mon Mar 30 10:36:57 2015
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Mon, 30 Mar 2015 11:36:57 +0100
Subject: RFR: JDK-8068721 - RMI-IIOP communication fails when
	ConcurrentHashMap is passed to remote method
In-Reply-To: <55191331.7080406@oracle.com>
References: <551084E3.6050702@oracle.com> <5515AE6E.9080606@oracle.com>
	<55191331.7080406@oracle.com>
Message-ID: <55192749.5050102@oracle.com>

Thanks Chris

M.
On 30/03/2015 10:11, Chris Hegarty wrote:
>
> On 27/03/15 19:24, Mark Sheppard wrote:
>> Hi
>>      based on feedback webrev has been updated as follows:
>>
>> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev.01/
>
> The changes in the corba repo look good to me Mark.
>
> -Chris.
>
>> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev.01/
>>
>> regards
>> Mark
>>
>> On 23/03/2015 21:25, Mark Sheppard wrote:
>>> Hi
>>>  please oblige and review the following fix
>>>
>>> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/corba/webrev/
>>> http://cr.openjdk.java.net/~msheppar/8068721/jdk9/jdk/webrev/
>>>
>>>
>>> which addresses the issue in
>>> https://bugs.openjdk.java.net/browse/JDK-8068721
>>>
>>> This relates to RMI-IIOP and the interplay between custom marshalling
>>> of ValueTypes and
>>> the corresponding serialization of a Java class, in this case
>>> ConcurrentHashMap.
>>>
>>> ConcurrentHashMap changed its structure in jdk8 from that used in jdk7.
>>> This resulted in modification to the readObject and writeObject 
>>> methods,
>>> and in particular, former serial fields were removed, resulting in
>>> writeObject using PutField and readObject using defaultReadObject.
>>> The writeObject invokes the putFields method of an ObjectOutputStream
>>> multiple times, and assumes
>>> that it will receive the same PutField object instance for each
>>> invocation. The spec
>>> doesn't endorse this behaviour - but that's what the implementation of
>>> ObjectOutputStream
>>> provides. However in the case of RMI-IIOP, the OutputStreamHook, a
>>> subclass of ObjectOutputStream, returns a new instance for each
>>> putFields invocation. Thus, the ConcurrentHashMap writeObject results
>>> in improper serialization in the context
>>> of RMI-IIOP.
>>> In the unmarshalling flow of ConcurrentHashMap, the readObject now
>>> uses defaultReadObject rather than GetField
>>> In this call flow the IIOPInputStream attempts to ignore any primitive
>>> field, in the serialized data, that doesn't
>>> correspond with a reflective field of the object. However, it leaves
>>> the primitive in the stream.
>>> Thus, in the case of ConcurrentHashMap, which has serialized two
>>> integers and
>>> an array of Segments (subclass of ReentrantLock), this results in
>>> erroneous
>>> deserialization, with a misinterpretation of a value tag in the stream
>>> as an array length
>>> and an attempt to allocate a very large array ensues, with an
>>> exception being thrown.
>>>
>>> The OutputStreamHook now returns the same instance of PutField
>>> allocated for each separate call of putFields method.
>>> This highlights a need to tighten up and disambiguate the
>>> OutputObjectStream spec for putFields.
>>>
>>> IIOPInputStream now removes the primitive values from the stream.
>>>
>>> regards
>>> Mark
>>



From aleksej.efimov at oracle.com  Mon Mar 30 12:23:36 2015
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Mon, 30 Mar 2015 15:23:36 +0300
Subject: <i18n dev> RFR: 8075667: (tz) Support tzdata2015b
In-Reply-To: <5514D8DB.1010204@oracle.com>
References: <55142A1B.1070600@oracle.com> <5514D8DB.1010204@oracle.com>
Message-ID: <55194048.5070805@oracle.com>

Thank you for the review Masayoshi. Agree that we need to avoid such 
workarounds - I will take a look at JDK-8014468 when will have some free 
cycles.

Aleksej

On 03/27/2015 07:13 AM, Masayoshi Okutsu wrote:
> Looks good except that data changes keep requiring additional 
> workaround to the run-time code. We do need a fix for JDK-8014468.
>
> Masayoshi
>
> On 3/27/2015 12:47 AM, Aleksej Efimov wrote:
>> Hi,
>>
>> Please review the fix for adding the latest tzdata2015b to JDK9.
>> The JTREG and JPRT tests were executed.
>> No failures were observed, except one:
>> test/sun/util/calendar/zi/TestZoneInfo310.java
>> The failure was caused by the following tzdb rule addition to 
>> make/data/tzdata/asia:
>>     +Rule Palestine    2015    max    -    Mar    lastFri 24:00 
>>  1:00    S
>> And it was addressed by addition of another piece of workaround code 
>> to src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.
>> After this changes the test showed the PASS result.
>>
>> Thank you,
>> Aleksej
>>
>> [1] JBS: https://bugs.openjdk.java.net/browse/JDK-8075667
>> [2] Webrev: http://cr.openjdk.java.net/~aefimov/tzdata/2015b/9/00
>



From jason_mehrens at hotmail.com  Mon Mar 30 14:18:45 2015
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Mon, 30 Mar 2015 09:18:45 -0500
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <551916F9.1000803@oracle.com>
References: <5513F6CE.3040505@oracle.com>,<5513FB77.90305@oracle.com>
	<55140D06.4030201@gmail.com>,<55140FC0.4060104@oracle.com>
	<55141540.9050600@gmail.com>,<55153E88.7070200@oracle.com>
	<551551BF.8040902@gmail.com>
	<CA+kOe0-Tw1+TbJQ-NX0Zu5d=QcVsbA0hd+oW+H4CDEscsXYFKA@mail.gmail.com>
	<5515E18E.8000204@oracle.com>,
	<CA+kOe0-aZzccotBTbc_0-_ohF_W_Ea4ZSLSY--1yghRFCDXGFw@mail.gmail.com>,
	<551916F9.1000803@oracle.com>
Message-ID: <BLU175-W48E9E2C59FFF4C9D87BDA883F50@phx.gbl>

For the test shouldn't you include a test for getLoggerNames to check that if the returned Enumeration is an instanceof Iterator then its remove method must throw an UnsupportedOperationException?  That makes it clear as to why you are using Collections.enumeration.


Jason

----------------------------------------
> Date: Mon, 30 Mar 2015 11:27:21 +0200
> From: daniel.fuchs at oracle.com
> To: martinrb at google.com; claes.redestad at oracle.com
> Subject: Re: RFR: 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable
> CC: core-libs-dev at openjdk.java.net
>
> Thanks all for your reviews!
>
> If I don't hear more then
> http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.01/
>
> is what I'm going to push.
>
> best regards,
>
> -- daniel
>
> On 28/03/15 00:39, Martin Buchholz wrote:
>> Claes,
>>
>> Right you are - I stand corrected!
>>
>> On Fri, Mar 27, 2015 at 4:02 PM, Claes Redestad <claes.redestad at oracle.com>
>> wrote:
>>
>>>
>>> On 2015-03-27 21:12, Martin Buchholz wrote:
>>>
>>>> Random advice - the default concurrency level of ConcurrentHashMap is 16,
>>>> and that is almost always more than needed, probably also including here.
>>>>
>>>
>>> I believe JSR-166e (JDK8 and onwards) mostly removed the concept of
>>> concurrency level from ConcurrentHashMap (while it's still there in some
>>> constructors to confuse things). I recall some tests showing that the
>>> difference in footprint between CHM and regular HashMap/Hashtable is now
>>> negligible even for empty, default-initialized instances.
>>>
>>> /Claes
>>>
> 		 	   		  

From daniel.fuchs at oracle.com  Mon Mar 30 14:56:27 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 30 Mar 2015 16:56:27 +0200
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <BLU175-W48E9E2C59FFF4C9D87BDA883F50@phx.gbl>
References: <5513F6CE.3040505@oracle.com>,
	<5513FB77.90305@oracle.com>	<55140D06.4030201@gmail.com>,
	<55140FC0.4060104@oracle.com>	<55141540.9050600@gmail.com>,
	<55153E88.7070200@oracle.com>	<551551BF.8040902@gmail.com>	<CA+kOe0-Tw1+TbJQ-NX0Zu5d=QcVsbA0hd+oW+H4CDEscsXYFKA@mail.gmail.com>	<5515E18E.8000204@oracle.com>,
	<CA+kOe0-aZzccotBTbc_0-_ohF_W_Ea4ZSLSY--1yghRFCDXGFw@mail.gmail.com>,
	<551916F9.1000803@oracle.com>
	<BLU175-W48E9E2C59FFF4C9D87BDA883F50@phx.gbl>
Message-ID: <5519641B.3010804@oracle.com>

On 30/03/15 16:18, Jason Mehrens wrote:
> For the test shouldn't you include a test for getLoggerNames to check that if the returned Enumeration is an instanceof Iterator then its remove method must throw an UnsupportedOperationException?  That makes it clear as to why you are using Collections.enumeration.

Good idea - it wouldn't hurt.

-- daniel

>
>
> Jason
>
> ----------------------------------------
>> Date: Mon, 30 Mar 2015 11:27:21 +0200
>> From: daniel.fuchs at oracle.com
>> To: martinrb at google.com; claes.redestad at oracle.com
>> Subject: Re: RFR: 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable
>> CC: core-libs-dev at openjdk.java.net
>>
>> Thanks all for your reviews!
>>
>> If I don't hear more then
>> http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.01/
>>
>> is what I'm going to push.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 28/03/15 00:39, Martin Buchholz wrote:
>>> Claes,
>>>
>>> Right you are - I stand corrected!
>>>
>>> On Fri, Mar 27, 2015 at 4:02 PM, Claes Redestad <claes.redestad at oracle.com>
>>> wrote:
>>>
>>>>
>>>> On 2015-03-27 21:12, Martin Buchholz wrote:
>>>>
>>>>> Random advice - the default concurrency level of ConcurrentHashMap is 16,
>>>>> and that is almost always more than needed, probably also including here.
>>>>>
>>>>
>>>> I believe JSR-166e (JDK8 and onwards) mostly removed the concept of
>>>> concurrency level from ConcurrentHashMap (while it's still there in some
>>>> constructors to confuse things). I recall some tests showing that the
>>>> difference in footprint between CHM and regular HashMap/Hashtable is now
>>>> negligible even for empty, default-initialized instances.
>>>>
>>>> /Claes
>>>>
>> 		 	   		



From huizhe.wang at oracle.com  Mon Mar 30 16:32:45 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 30 Mar 2015 09:32:45 -0700
Subject: RFR: 8073385: Bad error message on parsing illegal character
	in XML attribute
In-Reply-To: <55142E11.8080109@oracle.com>
References: <55142E11.8080109@oracle.com>
Message-ID: <55197AAD.9000203@oracle.com>

Hi Aleksej,

The change looks good.

Could you move the test to the jaxp repo instead of jdk?  You'd find the 
same package under jaxp/test/javax/xml/jaxp/unittest, and may use any of 
the javax.xml.parsers tests as an example.

Thanks,
Joe

On 3/26/2015 9:04 AM, Aleksej Efimov wrote:
> Hi,
> Please review the fix for corrupted error messages in XML parser. When 
> the XML parser encounters illegal
> character the message with incorrect data is generated:
> An invalid XML character (Unicode: 0x{2}) was found in the value of 
> attribute "{1}" and element is "0".
> But it should be like:
> An invalid XML character (Unicode: 0x0) was found in the value of 
> attribute "attTest" and element is "topElement".
> The fix repairs the message generation and it is similar to the code 
> in Apache Xerces project.
> Testing: JTREG and JPRT tests (with new one) showed no failures with 
> XML related tests.
>
> Thanks,
> Aleksej
>
> [1] JBS: https://bugs.openjdk.java.net/browse/JDK-8073385
> [2] Webrevs:
>     jaxp: http://cr.openjdk.java.net/~aefimov/8073385/9/00/jaxp/
>     jdk: http://cr.openjdk.java.net/~aefimov/8073385/9/00/jdk/



From aleksej.efimov at oracle.com  Mon Mar 30 16:47:41 2015
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Mon, 30 Mar 2015 19:47:41 +0300
Subject: RFR: 8073385: Bad error message on parsing illegal character
	in XML attribute
In-Reply-To: <55197AAD.9000203@oracle.com>
References: <55142E11.8080109@oracle.com> <55197AAD.9000203@oracle.com>
Message-ID: <55197E2D.20203@oracle.com>

Hi Joe,
Sure - I will move the test to jaxp repo and rename it to 
Bug8073385.java (to follow the naming of other test files there).
Thank you for the review.

Thank you,
Aleksej

On 03/30/2015 07:32 PM, huizhe wang wrote:
> Hi Aleksej,
>
> The change looks good.
>
> Could you move the test to the jaxp repo instead of jdk?  You'd find 
> the same package under jaxp/test/javax/xml/jaxp/unittest, and may use 
> any of the javax.xml.parsers tests as an example.
>
> Thanks,
> Joe
>
> On 3/26/2015 9:04 AM, Aleksej Efimov wrote:
>> Hi,
>> Please review the fix for corrupted error messages in XML parser. 
>> When the XML parser encounters illegal
>> character the message with incorrect data is generated:
>> An invalid XML character (Unicode: 0x{2}) was found in the value of 
>> attribute "{1}" and element is "0".
>> But it should be like:
>> An invalid XML character (Unicode: 0x0) was found in the value of 
>> attribute "attTest" and element is "topElement".
>> The fix repairs the message generation and it is similar to the code 
>> in Apache Xerces project.
>> Testing: JTREG and JPRT tests (with new one) showed no failures with 
>> XML related tests.
>>
>> Thanks,
>> Aleksej
>>
>> [1] JBS: https://bugs.openjdk.java.net/browse/JDK-8073385
>> [2] Webrevs:
>>     jaxp: http://cr.openjdk.java.net/~aefimov/8073385/9/00/jaxp/
>>     jdk: http://cr.openjdk.java.net/~aefimov/8073385/9/00/jdk/
>



From daniel.fuchs at oracle.com  Mon Mar 30 17:03:09 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 30 Mar 2015 19:03:09 +0200
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <5515D00C.5080300@oracle.com>
References: <5513F6CE.3040505@oracle.com>
	<5513FB77.90305@oracle.com>	<55140D06.4030201@gmail.com>
	<55140FC0.4060104@oracle.com>	<55141540.9050600@gmail.com>
	<55153E88.7070200@oracle.com> <5515D00C.5080300@oracle.com>
Message-ID: <551981CD.8010607@oracle.com>

On 27/03/15 22:47, Mandy Chung wrote:
> On 3/27/15 4:27 AM, Daniel Fuchs wrote:
>> Here is a new webrev - with Peter's suggestion implemented.
>> I also made a few tweaks to the test.
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.01/
>
>
> This version looks good to me.  With this change to use CHM,
> we could modernize the code further and that's for some other day.

Thanks Mandy.

> I think the removeLoggerRef andgetLoggerNames method don't
> need to be synchronized either - any reason why they are
> kept synchronized?

Yes. getLoggerNames() calls ensureInitialized().
There may be a possibility to improve synchronization
there too but that will be more complex.


removeLoggerRef is already called from within a
synchronized block on LoggerContext - so there is nothing
to gain here.

>
> line 659: indent to the right
> line 660: nit - 4-space indentation.

Well spotted! Fixed in my repository.

best regards,

-- daniel

>
> Mandy
>



From mandy.chung at oracle.com  Mon Mar 30 17:10:43 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 30 Mar 2015 10:10:43 -0700
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <551981CD.8010607@oracle.com>
References: <5513F6CE.3040505@oracle.com>
	<5513FB77.90305@oracle.com>	<55140D06.4030201@gmail.com>
	<55140FC0.4060104@oracle.com>	<55141540.9050600@gmail.com>
	<55153E88.7070200@oracle.com> <5515D00C.5080300@oracle.com>
	<551981CD.8010607@oracle.com>
Message-ID: <55198393.3000501@oracle.com>



On 3/30/2015 10:03 AM, Daniel Fuchs wrote:
> On 27/03/15 22:47, Mandy Chung wrote:
>> On 3/27/15 4:27 AM, Daniel Fuchs wrote:
>>> Here is a new webrev - with Peter's suggestion implemented.
>>> I also made a few tweaks to the test.
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.01/
>>
>>
>> This version looks good to me.  With this change to use CHM,
>> we could modernize the code further and that's for some other day.
>
> Thanks Mandy.
>
>> I think the removeLoggerRef andgetLoggerNames method don't
>> need to be synchronized either - any reason why they are
>> kept synchronized?
>
> Yes. getLoggerNames() calls ensureInitialized().
> There may be a possibility to improve synchronization
> there too but that will be more complex.
>
>
> removeLoggerRef is already called from within a
> synchronized block on LoggerContext - so there is nothing
> to gain here.

I am aware of that while that synchronize is needed for updating the 
nodes.   As synchronized on removeLoggerRef isn't needed, I'd prefer it 
be taken out.

Mandy


From lev.priima at oracle.com  Mon Mar 30 21:13:28 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Tue, 31 Mar 2015 00:13:28 +0300
Subject: RFR: 8071571: Move substring of same string to slow path
In-Reply-To: <5515D695.4070407@oracle.com>
References: <55156FB3.1080006@oracle.com>	<55157487.10108@oracle.com>	<5515B58B.5070205@oracle.com>	<CA+kOe09wAOZjWjfquzKL9OgOD05B-_x3zC0hd1RN8FmDCimR9A@mail.gmail.com>	<5515C23D.3050906@oracle.com>	<CA+kOe0_n9n0zh_wQgO-FA7DFn+xNjBZ4R-FFaj7PEHJu3o7C6w@mail.gmail.com>	<5515D0F4.7040103@oracle.com>
	<CA+kOe08BgRGkqEXMu19bEiKj27K34_HbGKR=SNhcm1khGj=-Jg@mail.gmail.com>
	<5515D695.4070407@oracle.com>
Message-ID: <5519BC78.3030303@oracle.com>

Martin,

So I've updated webrev w/o adding final everywhere: 
http://cr.openjdk.java.net/~lpriima/8071571/3/ .

Lev

On 03/28/2015 01:15 AM, Lev Priima wrote:
> On 03/28/2015 12:59 AM, Martin Buchholz wrote:
>> I was only suggesting using final in the stylized
>>
>> final Type foo = this.foo;
>>
>> Using final for other local variables is going further than most jdk 
>> maintainers (including myself) go.
> I think we could start from one file.
>>
>> OTOH, if you touch code that uses the denigrated
>>
>> char foo[]
>>
>> please change it to
>>
>> char[] foo
> Only for touched lines? If no, I can start from:
>   118     private final char value[];
> And go further to many methods signatures:
>   169     public String(char value[]) {
>> This is yet another of those global changes to the entire jdk sources 
>> that nobody ever gets around to.
>>
>>
>> On Fri, Mar 27, 2015 at 2:51 PM, Lev Priima <lev.priima at oracle.com 
>> <mailto:lev.priima at oracle.com>> wrote:
>>
>>     Updated and put some more final in other(not @Deprecated)
>>     methods: http://cr.openjdk.java.net/~lpriima/8071571/2/
>>     <http://cr.openjdk.java.net/%7Elpriima/8071571/2/>
>>
>>     Lev
>>
>>     On 03/27/2015 11:50 PM, Martin Buchholz wrote:
>>>
>>>
>>>     On Fri, Mar 27, 2015 at 1:49 PM, Lev Priima
>>>     <lev.priima at oracle.com <mailto:lev.priima at oracle.com>> wrote:
>>>
>>>         Martin,
>>>
>>>         You mean it should be like this:
>>>                  char[] val = value;    /* avoid getfield opcode */
>>>                  int end = val.length;
>>>         ?
>>>
>>>
>>>     Yes.
>>>
>>>     (although I personally like to write it like this:
>>>
>>>     final char[] value = this.value;
>>>     int end = value.length;
>>>
>>>
>>
>>
>



From mandy.chung at oracle.com  Mon Mar 30 21:37:00 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 30 Mar 2015 14:37:00 -0700
Subject: native2ascii be removed from JDK?
Message-ID: <5519C1FC.6010303@oracle.com>

There are several existing ways to do native to ascii conversion.  For 
example, IDEs like NetBeans and IntelliJ support the transparent 
native-to-ascii conversion. There is also maven native 2 ascii plugin.

JEP 226 proposes to support UTF Properties file that will address the 
original motivation of creating the native2ascii tool.

While native2ascii used to be a convenient tool for some developers to 
use, it may be time to remove it in JDK 9 and developers can use IDEs 
and Maven plugin and other build tools.

Any thought?

Mandy


From joe.darcy at oracle.com  Mon Mar 30 22:26:05 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 30 Mar 2015 15:26:05 -0700
Subject: native2ascii be removed from JDK?
In-Reply-To: <5519C1FC.6010303@oracle.com>
References: <5519C1FC.6010303@oracle.com>
Message-ID: <5519CD7D.4000703@oracle.com>

Hi Mandy,

If there is agreement on this internally, I suggest floating a trial 
balloon on jdk9-dev.

Cheers,

-Joe

On 3/30/2015 2:37 PM, Mandy Chung wrote:
> There are several existing ways to do native to ascii conversion.  For 
> example, IDEs like NetBeans and IntelliJ support the transparent 
> native-to-ascii conversion. There is also maven native 2 ascii plugin.
>
> JEP 226 proposes to support UTF Properties file that will address the 
> original motivation of creating the native2ascii tool.
>
> While native2ascii used to be a convenient tool for some developers to 
> use, it may be time to remove it in JDK 9 and developers can use IDEs 
> and Maven plugin and other build tools.
>
> Any thought?
>
> Mandy



From martinrb at google.com  Tue Mar 31 01:35:38 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 30 Mar 2015 18:35:38 -0700
Subject: RFR: 8061950: Class.getMethods() exhibits quadratic time
	complexity
In-Reply-To: <5517E5B5.5000308@gmail.com>
References: <CA+kOe08YW=MG+W6sMOZS9cvLXMtVa1OX7u2P0LxEjfoeGT4CGw@mail.gmail.com>
	<900D2AE3-B3A6-4B1B-B25A-C564B10334AA@oracle.com>
	<54492255.3040108@gmail.com>
	<EAE058BE-B5F0-4F53-A9F8-36F3BFEEA703@oracle.com>
	<544D58D4.7020909@gmail.com> <544D7B74.5060607@gmail.com>
	<FF8A5786-0840-45D9-8B36-0B60BB2DBA98@oracle.com>
	<5450CEE9.7060707@gmail.com>
	<F81AE132-D4FE-48F6-AAA8-A3580F5194B4@oracle.com>
	<545120D2.5010301@gmail.com> <54526D10.5060101@gmail.com>
	<CA+kOe0_nf-fasgbhQA8zJ60wTxpAfuOYEC2YAvtHE6-awJsBrA@mail.gmail.com>
	<54551D2F.407@gmail.com> <545A572D.3050608@gmail.com>
	<F15D5F8E-2E65-4243-A7AA-C30CF4DBF935@oracle.com>
	<547B90A0.1080508@gmail.com>
	<CA+kOe0-bC9WwOhkb6555oxGBHbLOX5aW7H3aB4Y187Q1CTpP5g@mail.gmail.com>
	<547CE713.2020905@gmail.com>
	<CA+kOe0_D3RAJ4mS3Z6-izSVwRCWHAgguDCZKL9K5TFC=o5gnOw@mail.gmail.com>
	<5517E5B5.5000308@gmail.com>
Message-ID: <CA+kOe0_wv=Z+JuNRLSxw+7OMgitQebiPdWJ1nrqJ9EtLj0yR0Q@mail.gmail.com>

Thanks, Peter.

I've started making my way through these changes.
It's too bad there's so much complexity here, but I can't come up with a
simpler solution either.
So we will probably submit something based on your latest webrev.
I've collected minor changes into an mq patch to be applied on top of yours.

http://cr.openjdk.java.net/~martin/Class.getMethods

- need @library
- it's => its
- remove end tags
- Remove => Removes

Should we switch to using testng?  I think yes.

More review later.


On Sun, Mar 29, 2015 at 4:44 AM, Peter Levart <peter.levart at gmail.com>
wrote:

>  Hi,
>
> I'd like to resurrect a patch I did a couple of months ago. Here's a
> rebased webrev (no changes from webrev.07):
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods/webrev.08/
>
>
> Regards, Peter
>
>
>
> On 03/23/2015 11:42 PM, Martin Buchholz wrote:
>
> So Peter, ... time to rebase one of your getMethods patches?
>
> On Mon, Dec 1, 2014 at 2:09 PM, Peter Levart <peter.levart at gmail.com>
> wrote:
>
>>
>> On 12/01/2014 09:09 PM, Martin Buchholz wrote:
>>
>> Looking at Peter's work here is still on my long TODO list, but I was
>> hoping first to get in my concurrency correctness fixes for core
>> reflection, which conflicts slightly...
>>
>>
>>  No problem. I can rebase the patch after your fixes are in.
>>
>> Regards, Peter
>>
>>
>>  On Sun, Nov 30, 2014 at 1:48 PM, Peter Levart <peter.levart at gmail.com> <peter.levart at gmail.com> wrote:
>>
>>  Hi Joel,
>>
>> I managed to find some time to create some tests for this patch:
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods/webrev.07/
>>
>> Both MethodTable and HashArray unit tests are provided. I had to create a
>> special TestProxy to access package-private classes from the tests.
>>
>> There are no changes to j.l.Class or j.l.r.Method from webrev.06 (I just
>> re-based them to current tip).
>>
>> I also included the patch to StarInheritance test that I forgot to include
>> in webrev.06.
>>
>> Comments inline...
>>
>> On 11/13/2014 10:39 AM, Joel Borggr?n-Franck wrote:
>>
>>  Hi Peter,
>>
>> As always, thanks for taking a look at this,
>>
>> This is quite big so in order to make this more approachable perhaps you
>> can split the patch up into a series? If you start with creating the
>> MethodTable interface, adding tests for how the interface should behave and
>> refactored the current MethodArray into implementing that interface while
>> also changing the lookup logic that would be easier to review.
>>
>>  Well, there's not much to refactor in MethodArray when implementing
>> MethodTable. They are two entirely different APIs with entirely different
>> implementations.
>>
>>
>>  Then you could add different implementations of MethodTable (with
>> additional unit tests) as follow up patches.
>>
>>  You can view the MethodTable.SimpleArrayImpl as the basic implementation of
>> the MethodTable API  and a replacement for MethodArray.
>> MethodTable.HashArrayImpl is the alternative implementation for bigger
>> sizes. The same unit tests are executed against both implementations.
>>
>>
>>  I am a bit concerned about the size and scope of the implementations. In
>> general I would prefer if you targeted these to the precise need of core
>> reflection today. If you want to expand these to general purpose data
>> structures (even internal ones) I think that is a larger effort.
>>
>>  I stripped HashArray and only left those methods that are needed to
>> implement MethodTable API and execute the tests.
>>
>>
>>  In general I think the changes to Class are sound, but there is a slight
>> change in the default method pruning. The call to removeLessSpecifics was
>> deliberately placed at the end, so that all default methods would be present
>> (the algorithm is sensitive to the order of pair vise comparisons). Since we
>> add methods in a deterministic order, I think consolidate() as you go should
>> result in the same set of methods, but I haven?t 100% convinced myself of
>> this just yet.
>>
>>  I think it results in the same methods. I haven't yet found an example where
>> it would result in different set of methods. All JDK classes return same
>> methods with current implementation as with patched one.
>>
>>
>>  Have you double checked that all methods returning root Method/Ctors are
>> private?
>>
>>  I checked all usages of private methods that I have changed and are now
>> returning root objects and made sure those are copied before being exposed
>> to the outside or being modified.
>>
>> Regards, Peter
>>
>>
>>
>>  On 5 nov 2014, at 17:58, Peter Levart <peter.levart at gmail.com> <peter.levart at gmail.com> wrote:
>>
>>
>>  Here's new webrev:
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods/webrev.06/
>>
>>
>> The optimizations made from webrev.05 are:
>>
>> - getMethod() skips construction of MethodTable if there are no
>> (super)interfaces.
>> - getMethods() returns just declared public methods if there are no
>> superclass and no (super)interfaces.
>> - comparing method parameter types is optimized by adding two methods to
>> Method/LangReflectAccess/ReflectionFactory.
>>
>> New MethodTable implementation based on a linear-probe hash table is a
>> space/garbage improvement. I took IdentityHashMap, removed unneeded stuff
>> and modified it's API. The result is a HashArray. It's API is similar in
>> function and form to java.util.Map, but doesn't use separate keys and
>> values. An element of HashArray is a key and a value at the same time.
>> Elements are always non-null, so the method return values are unambiguous.
>> As HashArray is a linear-probe hash table and there are no Map.Entry objects
>> involved, the underlying data structure is very simple and memory efficient.
>> It is just a sparse array of elements with length that is always a power of
>> two and larger than 3 * size / 2. It also features overriddable element
>> equals/hashCode methods. I made it a separate generic class because I think
>> it can find it's usage elsewhere (for example as a cannonicalizing cache).
>>
>> Since HashArray based MethodTable is more space-efficient I moved the
>> line between simple array based and HashArray based MethodTable down to 20
>> elements to minimize the worst-case scenario effect. Calling getMethods() on
>> all rt.jar classes now constructs about 3/4 simple array based and 1/4
>> HashArray based MethodTables.
>>
>>
>>  HashArray.java:
>>
>> I was hoping for a decent set of unit tests for the new HashArray<T> data
>> structure. I think it is reasonable to test the corner cases/non-trivial
>> areas of the table (closeDeletion(), rezise() etc). Perhaps also run these
>> over the simple implementation. Also, please document thread safety (there
>> is none IFAICT it should just be noted).
>>
>> Instead of using inheritance to change the behavior of equals() and hash()
>> you could give it two lambdas at table creation time, a ToIntFunction<T> for
>> hash() and a BiPredicate<T,T> for equals(). Might not give you the
>> performance we need though.
>>
>> Note that the file doesn?t actually compile in jdk9/dev, you have two
>> unchecked casts and we build with -Werror.
>>
>> MethodTable.java
>>
>> HashMapImpl is missing serialVersionUID, but it looks like this class
>> won?t be needed at all.
>>
>>
>>
>>  Here's also Martin's ManyMethodsBenchmark:
>>
>> Original:
>>
>> Base class load time: 129.95 ms
>> getDeclaredMethods: 65521 methods, 36.58 ms total time, 0.0006 ms per
>> method
>> getMethods        : 65530 methods, 47.43 ms total time, 0.0007 ms per
>> method
>> Derived class load time: 32216.09 ms
>> getDeclaredMethods: 65521 methods, 35.05 ms total time, 0.0005 ms per
>> method
>> getMethods        : 65530 methods, 8068.66 ms total time, 0.1231 ms per
>> method
>>
>>
>> Patched (using HashArray based MethodTable):
>>
>> Base class load time: 126.00 ms
>> getDeclaredMethods: 65521 methods, 36.83 ms total time, 0.0006 ms per
>> method
>> getMethods        : 65530 methods, 45.08 ms total time, 0.0007 ms per
>> method
>> Derived class load time: 31865.27 ms
>> getDeclaredMethods: 65521 methods, 35.01 ms total time, 0.0005 ms per
>> method
>> getMethods        : 65530 methods, 78.05 ms total time, 0.0012 ms per
>> method
>>
>>
>> All 86 jtreg test in java.lang/Class/ and java/lang/reflect/ still pass.
>>
>>
>>  I have seen discussion about allocation, should we measure and compare?
>> You can probably use the Hotspot impl of ThreadMXBean to get the allocation
>> in the tread.
>>
>> Also, it might be time to fix the boolean parameters:
>>
>> 2741         Method[] declaredMethods = privateGetDeclaredMethods(true);
>> 2742         Class<?> superclass = getSuperclass();
>> 2743         Class<?>[] interfaces = getInterfaces(false);
>>
>> Perhaps just add boolean constants somewhere so that it is easier to
>> decode.
>>
>> 2741         Method[] declaredMethods =
>> privateGetDeclaredMethods(PUBLIC_METHOD_ONLY);
>> 2742         Class<?> superclass = getSuperclass();
>> 2743         Class<?>[] interfaces = getInterfaces(NO_COPY_RESULT);
>>
>> or so.
>>
>> HashArray.java:
>>
>> 155         if (lookupObj == null) throw new NullPointerException();
>>
>> use Objects.requreNonNull() ?
>>
>> cheers
>> /Joel
>>
>>
>>
>>
>
>


From huizhe.wang at oracle.com  Tue Mar 31 02:14:19 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 30 Mar 2015 19:14:19 -0700
Subject: Review request for JDK-8051560: JAXP function astro tests
	conversion
In-Reply-To: <017b01d06872$72959330$57c0b990$@oracle.com>
References: <033901d066de$f371f8d0$da55ea70$@oracle.com>
	<DF31FB1C-5E59-4614-A401-ABD8AA217242@oracle.com>
	<5514ABEB.9060501@oracle.com>
	<017b01d06872$72959330$57c0b990$@oracle.com>
Message-ID: <551A02FB.5070805@oracle.com>

Hi Frank,

Looks good.

Since you've gone through the original test/the astro application, and 
refactored it into a TestNG test, you probably have other insight too. 
If so, it would be nice to add them as well.

In terms of report, yes, I can see the output files displayed along with 
process id. Thanks for doing that.  Not as good as the old test report, 
which lists test mode/query ids with status, but acceptable since it 
prints out the process and query ids that helps identifying the exact test.

I have always wondered, but thought not so important, that in its 
current (TestNG) form, the test report will show test cases (thus fewer 
tests than the original test suite). For example, the AstroApp reports 
10 tests and 39 test cases, while the new 5. Console display is quite 
different from the html report as well. For example, on the console, the 
test results are: passed: 70, but the html report shows 371 tests 
passed. What are your thoughts on this?

Thanks,
Joe

On 3/27/2015 2:43 AM, Frank Yuan wrote:
>
> Hi Joe and Lance
>
> Thank you very much for your review! It's very good comment!
>
> According to your comments, I made the following changes:
>
> 1. Rename the output file name to be easier understanding.
>
> 2. Print the output file name to be easier debugging.
>
> 3. Add comment for AstroProcessor class
>
> 4. Add comment in AstroTest to describe the test, some are from astro 
> application design document.
>
> Besides these new adding comments, there are many comments in  astro 
> classes(in libs/test/astro),  which are from the original source 
> files. And the current tests prints information to the standard out, 
> which is redirected to .jtr file by jtreg, so there is not any other 
> trace file now. USER_DIR is the scratch dir in deed, it is property 
> user.dir in jtreg. The new webrev is at 
> http://cr.openjdk.java.net/~fyuan/8051560/webrev.01/ 
> <http://cr.openjdk.java.net/%7Efyuan/8051560/webrev.01/>
>
> Btw, I also sent out review request for JDK-8051559: JAXP function dom 
> tests minutes later than this review request, I am afraid you may miss 
> it, reminder here:)
>
> Best Regards
>
> Frank
>
> *From:*huizhe wang [mailto:huizhe.wang at oracle.com]
> *Sent:* Friday, March 27, 2015 9:02 AM
> *To:* Lance Andersen
> *Cc:* Frank Yuan; 'Core-Libs-Dev'; 'Gustavo Galimberti'
> *Subject:* Re: Review request for JDK-8051560: JAXP function astro 
> tests conversion
>
> I second Lance. The Main of the original astro had Javadocs and 
> developer comments. Probably more important is that you've completely 
> changed the main classes (TestDriver and Main), which looks good, 
> however, the original classes contained a lot of information on what 
> each test does and how it works that seem to have all been lost.
>
> The suite's README and build.xml may also contain information that is 
> worth keeping. Some of them may be no longer valid, in which case, it 
> may be helpful to describe the change. For example, the log files 
> described in README were useful for debugging. It would be good to 
> explain where to find the debug info in your new design.
>
> While scanning the test, I see that you are creating temporary output 
> files under USER_DIR. Is that intended? JAXP processors do not 
> necessarily open them with the DELETE_ON_CLOSE option. I thought in 
> previous tests, you were creating them in the scratch directory.
>
> Thanks,
> Joe
>
> On 3/26/2015 12:08 PM, Lance Andersen wrote:
>
>     Hi Frank,
>
>     Overall these look fine.  I would suggest adding a simple comment
>     to describe the tests that do not have one to give a basic intent
>     of the test to make it easier for someone to  understand if they
>     are new.
>
>     Best
>
>     Lance
>
>     On Mar 25, 2015, at 5:34 AM, Frank Yuan <frank.yuan at oracle.com
>     <mailto:frank.yuan at oracle.com>> wrote:
>
>
>
>         Hi, Joe and All
>
>
>
>         We are working on moving internal jaxp functional tests to
>         open jdk repo.
>
>         This is the astro suite. Would you please review these test?
>          Any comment
>         will be appreciated.
>
>
>
>         bug: https://bugs.openjdk.java.net/browse/JDK-8051560
>
>         webrev: http://cr.openjdk.java.net/~fyuan/8051560/webrev.00/
>         <http://cr.openjdk.java.net/%7Efyuan/8051560/webrev.00/>
>
>
>
>         AstroTest is the primary test in this suite, it transforms an
>         xml file(which
>         includes astro data) with several xsl files, sets different
>         filtering
>         condition by these xsl files and different filtering range,
>         finally compares
>         the result with golden files.
>
>         And there are 5 permutations of InputSourceFactory and
>         FilterFactory(I uses
>         template method pattern for the variant FilterFactoryImpls), each
>         permutation will be applied to above transforming processes.
>
>
>
>         Thanks,
>
>
>
>         Frank
>
>     <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 amy.lu at oracle.com  Tue Mar 31 03:44:05 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 31 Mar 2015 11:44:05 +0800
Subject: JDK 9 RFR of JDK-8075304: Remove duplicate test: FDTest
In-Reply-To: <55111839.4010506@oracle.com>
References: <5507D244.40509@oracle.com> <55111839.4010506@oracle.com>
Message-ID: <551A1805.9020702@oracle.com>

Not yet got review feedback, I updated the webrev to get more cleanup 
included.

Updated webrev: http://cr.openjdk.java.net/~amlu/8075304/webrev.01/

For your reference:
For all tests proposed to be removed in this patch, here are the 
differences between the one exist in "jdk" repo and "langtools" repo:
http://cr.openjdk.java.net/~amlu/8075304/8075304_test_diff_jdk_vs_langtools.txt

Thanks,
Amy

On 3/24/15 3:54 PM, Amy Lu wrote:
> Kindly reminder ...
>
> On 3/17/15 3:05 PM, Amy Lu wrote:
>> This RFR proposes to remove the duplicate FDTest from ?jdk? repo.
>>
>> FDTest exists in both ?jdk? and ?langtools?:
>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/test/jdk/lambda/FDTest.java 
>>
>> http://hg.openjdk.java.net/jdk9/dev/langtools/file/tip/test/tools/javac/lambdaShapes/org/openjdk/tests/javac/FDTest.java 
>>
>>
>> So far the only diff between the two tests is that the version in 
>> langtools has one more teardown method to well handle the resource close
>> > @AfterSuite
>> > static void teardown() throws IOException {
>> > fm.close();
>> > }
>>
>> As this test is for JavaCompiler, it makes more sense to keep the 
>> test in "langtools" and remove the duplicate one from "jdk?.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8075304
>> webrev: http://cr.openjdk.java.net/~amlu/8075304/webrev.00/
>>
>>
>> Thanks,
>> Amy
>



From robert.field at oracle.com  Tue Mar 31 05:47:59 2015
From: robert.field at oracle.com (Robert Field)
Date: Mon, 30 Mar 2015 22:47:59 -0700
Subject: JDK 9 RFR of JDK-8075304: Remove duplicate test: FDTest
In-Reply-To: <551A1805.9020702@oracle.com>
References: <5507D244.40509@oracle.com> <55111839.4010506@oracle.com>
	<551A1805.9020702@oracle.com>
Message-ID: <551A350F.2090406@oracle.com>

Looks good.

-Robert

On 03/30/15 20:44, Amy Lu wrote:
> Not yet got review feedback, I updated the webrev to get more cleanup 
> included.
>
> Updated webrev: http://cr.openjdk.java.net/~amlu/8075304/webrev.01/
>
> For your reference:
> For all tests proposed to be removed in this patch, here are the 
> differences between the one exist in "jdk" repo and "langtools" repo:
> http://cr.openjdk.java.net/~amlu/8075304/8075304_test_diff_jdk_vs_langtools.txt 
>
>
> Thanks,
> Amy
>
> On 3/24/15 3:54 PM, Amy Lu wrote:
>> Kindly reminder ...
>>
>> On 3/17/15 3:05 PM, Amy Lu wrote:
>>> This RFR proposes to remove the duplicate FDTest from ?jdk? repo.
>>>
>>> FDTest exists in both ?jdk? and ?langtools?:
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/test/jdk/lambda/FDTest.java 
>>>
>>> http://hg.openjdk.java.net/jdk9/dev/langtools/file/tip/test/tools/javac/lambdaShapes/org/openjdk/tests/javac/FDTest.java 
>>>
>>>
>>> So far the only diff between the two tests is that the version in 
>>> langtools has one more teardown method to well handle the resource 
>>> close
>>> > @AfterSuite
>>> > static void teardown() throws IOException {
>>> > fm.close();
>>> > }
>>>
>>> As this test is for JavaCompiler, it makes more sense to keep the 
>>> test in "langtools" and remove the duplicate one from "jdk?.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8075304
>>> webrev: http://cr.openjdk.java.net/~amlu/8075304/webrev.00/
>>>
>>>
>>> Thanks,
>>> Amy
>>
>



From frank.yuan at oracle.com  Tue Mar 31 08:15:26 2015
From: frank.yuan at oracle.com (Frank Yuan)
Date: Tue, 31 Mar 2015 16:15:26 +0800
Subject: Review request for JDK-8051559: JAXP function dom tests conversion
In-Reply-To: <035701d066e0$93124560$b936d020$@oracle.com>
References: <035701d066e0$93124560$b936d020$@oracle.com>
Message-ID: <019b01d06b8a$da0abca0$8e2035e0$@oracle.com>

Hi Joe

 

Do you have any comment for dom suite co-location?

 

Best Regards

Frank

 

From: Frank Yuan [mailto:frank.yuan at oracle.com] 
Sent: Wednesday, March 25, 2015 5:46 PM
To: 'huizhe wang'; 'Core-Libs-Dev'
Cc: 'jibing chen'; 'Gustavo Galimberti'; sandeep.konchady at oracle.com;
'Alexandre (Shura) Iline'
Subject: RE: Review request for JDK-8051559: JAXP function dom tests
conversion

 

Hi, Joe and All

 

We are working on moving internal jaxp functional tests to open jdk repo.

This is the dom suite. Would you please review these test?  Any comment will
be appreciated.

 

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

webrev: http://cr.openjdk.java.net/~fyuan/8051559/webrev.00/

 

Thanks,

 

Frank



From lance.andersen at oracle.com  Tue Mar 31 11:24:35 2015
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Tue, 31 Mar 2015 07:24:35 -0400
Subject: Review request for JDK-8051559: JAXP function dom tests conversion
In-Reply-To: <019b01d06b8a$da0abca0$8e2035e0$@oracle.com>
References: <035701d066e0$93124560$b936d020$@oracle.com>
	<019b01d06b8a$da0abca0$8e2035e0$@oracle.com>
Message-ID: <0E4D09A9-8046-42AC-98B8-D2433A8D38FF@oracle.com>

Hi frank 

Can you forward the other review request as I think I thought they were the same and deleted it

I will look at this again today

Best
Lance


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

> On Mar 31, 2015, at 4:15 AM, Frank Yuan <frank.yuan at oracle.com> wrote:
> 
> Hi Joe
> 
> 
> 
> Do you have any comment for dom suite co-location?
> 
> 
> 
> Best Regards
> 
> Frank
> 
> 
> 
> From: Frank Yuan [mailto:frank.yuan at oracle.com] 
> Sent: Wednesday, March 25, 2015 5:46 PM
> To: 'huizhe wang'; 'Core-Libs-Dev'
> Cc: 'jibing chen'; 'Gustavo Galimberti'; sandeep.konchady at oracle.com;
> 'Alexandre (Shura) Iline'
> Subject: RE: Review request for JDK-8051559: JAXP function dom tests
> conversion
> 
> 
> 
> Hi, Joe and All
> 
> 
> 
> We are working on moving internal jaxp functional tests to open jdk repo.
> 
> This is the dom suite. Would you please review these test?  Any comment will
> be appreciated.
> 
> 
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8051559
> 
> webrev: http://cr.openjdk.java.net/~fyuan/8051559/webrev.00/
> 
> 
> 
> Thanks,
> 
> 
> 
> Frank
> 


From markus_keller at ch.ibm.com  Tue Mar 31 11:44:28 2015
From: markus_keller at ch.ibm.com (Markus Keller)
Date: Tue, 31 Mar 2015 13:44:28 +0200
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
References: <553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
Message-ID: <551A889C.1030309@ch.ibm.com>

I've discussed this with the Eclipse JDT team. We're very skeptic and we 
think that JEP 238 goes into a wrong direction. Eclipse JDT does not 
intend to add special support for it.

Building such MVJARs will be quite complicated, since it requires having 
separate classpaths and compiling against multiple JDKs to produce the 
release-specific class files that should end up in the same MVJAR. That 
means you either need a preprocessor that would allow to keep 
JDK-release-specific code in the same *.java file, or you need to 
maintain and sync separate *.java files in separate source folders. Both 
options are completely counter Java's "write once, run anywhere" idea, 
whose foundation is to have only one set of source files and no 
platform-specific compilation switches. This is one of the greatest 
features of Java. It's what makes reliable code analysis, dependency 
tracking, and refactoring possible.

Furthermore, the general problem is not specific to the JDK, but also 
occurs for other libraries. Therefore, a JDK-specific solution would be 
at the wrong level.

A better solution for such cases is to provide an adapter JAR that makes 
the new APIs available when running on an older JDK. That way, the 
problem is solved at the origin, and not again and again for each 
client. And with "the problem", I mean the problem that the old JDK 
release didn't offer an API for something that clients should use ASAP, 
even if they can't require the whole new JDK release right away.

Thanks,
Markus Keller
IBM Rational Zurich Research Lab
Eclipse JDT UI



From amy.lu at oracle.com  Tue Mar 31 12:09:41 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 31 Mar 2015 20:09:41 +0800
Subject: JDK 9 RFR of JDK-8075304: Remove duplicate test: FDTest
In-Reply-To: <551A350F.2090406@oracle.com>
References: <5507D244.40509@oracle.com> <55111839.4010506@oracle.com>
	<551A1805.9020702@oracle.com> <551A350F.2090406@oracle.com>
Message-ID: <551A8E85.5080603@oracle.com>

Thank you Robert for your review !

May I get your help to sponsor this change?

Thanks,
Amy

On 3/31/15 1:47 PM, Robert Field wrote:
> Looks good.
>
> -Robert
>
> On 03/30/15 20:44, Amy Lu wrote:
>> Not yet got review feedback, I updated the webrev to get more cleanup 
>> included.
>>
>> Updated webrev: http://cr.openjdk.java.net/~amlu/8075304/webrev.01/
>>
>> For your reference:
>> For all tests proposed to be removed in this patch, here are the 
>> differences between the one exist in "jdk" repo and "langtools" repo:
>> http://cr.openjdk.java.net/~amlu/8075304/8075304_test_diff_jdk_vs_langtools.txt 
>>
>>
>> Thanks,
>> Amy
>>
>> On 3/24/15 3:54 PM, Amy Lu wrote:
>>> Kindly reminder ...
>>>
>>> On 3/17/15 3:05 PM, Amy Lu wrote:
>>>> This RFR proposes to remove the duplicate FDTest from ?jdk? repo.
>>>>
>>>> FDTest exists in both ?jdk? and ?langtools?:
>>>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/test/jdk/lambda/FDTest.java 
>>>>
>>>> http://hg.openjdk.java.net/jdk9/dev/langtools/file/tip/test/tools/javac/lambdaShapes/org/openjdk/tests/javac/FDTest.java 
>>>>
>>>>
>>>> So far the only diff between the two tests is that the version in 
>>>> langtools has one more teardown method to well handle the resource 
>>>> close
>>>> > @AfterSuite
>>>> > static void teardown() throws IOException {
>>>> > fm.close();
>>>> > }
>>>>
>>>> As this test is for JavaCompiler, it makes more sense to keep the 
>>>> test in "langtools" and remove the duplicate one from "jdk?.
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8075304
>>>> webrev: http://cr.openjdk.java.net/~amlu/8075304/webrev.00/
>>>>
>>>>
>>>> Thanks,
>>>> Amy
>>>
>>
>



From aleksej.efimov at oracle.com  Tue Mar 31 13:29:54 2015
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Tue, 31 Mar 2015 16:29:54 +0300
Subject: RFR: 8076290: JCK test api/xsl/conf/string/string17 starts failing
	after JDK-8074297
Message-ID: <551AA152.6080602@oracle.com>

Hi,

Please review a fix for JCK test failure [2] that was caused by slightly 
incorrect fix for JDK-8074297 [3].
The problem is that the length of required string is incorrectly 
calculated when the start index is less or equal than zero: The pushed 
fix for JDK-8074297 assumes that length are specified from the first 
string character, but it should be counted from the specified start 
index - two added test cases for substring test illustrates it - one for 
string with supplementary characters, another one without.
All JCK xml related tests passes (including the failed one).
Tests set: api/xsl api/javax_xml api/org_xml xml_schema api/xinclude.
Test results: passed: 35,342

Thank you,
Aleksej

[1] Webrev: http://cr.openjdk.java.net/~aefimov/8076290/00/
[2] JBS: https://bugs.openjdk.java.net/browse/JDK-8076290
[3] JDK-8074297: https://bugs.openjdk.java.net/browse/JDK-8074297


From lance.andersen at oracle.com  Tue Mar 31 13:45:01 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 31 Mar 2015 09:45:01 -0400
Subject: Review request for JDK-8051560: JAXP function astro tests
	conversion
In-Reply-To: <00ff01d06b60$bd5d86c0$38189440$@oracle.com>
References: <033901d066de$f371f8d0$da55ea70$@oracle.com>
	<DF31FB1C-5E59-4614-A401-ABD8AA217242@oracle.com>
	<5514ABEB.9060501@oracle.com>
	<017b01d06872$72959330$57c0b990$@oracle.com>
	<551A02FB.5070805@oracle.com>
	<00ff01d06b60$bd5d86c0$38189440$@oracle.com>
Message-ID: <A29230D0-E82A-491A-B191-45A544DF4EC7@oracle.com>

Hi Frank,

Overall, its OK.

A couple of suggestions but they should not prevent you from pushing your changes:

I still think you should consider adding a basic comment to tests which are missing one such as in DocumentLSTest.java & NamespaceContextTest.java.

In AstroTest.java, you probably do not need the USER.DIR field as jtreg and just reference the file/directory.

Best
Lance
On Mar 30, 2015, at 11:14 PM, Frank Yuan <frank.yuan at oracle.com> wrote:

> Hi Joe
>  
> I am glad to explain your questions!
>  
> For test number, the original AstroApp has 10 test, XPath API, SAX 2.0.1, Schema Validation, Namespace, DocumentLS and Astro Test mode 1~5, one test method is reported as one test case, so there are 39. Current astro test suite has 6 tests, besides the first 5, AstroTest includes mode1 ~5. So they are same in deed. There are totally 371 test, 365 are already in repo, the 6 are astro. And 70 of them are functional test, because functional and unit test use separate TEST.properties files, you see the functional number at last, the unit number is scrolled up on the screen.
>  
> For test report, current process means original query, one original test mode connects one factories permutation. I also noticed it's not easy to identify the test mode/factories permutation, so I added "System.out.println(fFactClass.getName() +" : " + isFactClass.getName());" after I sent last webrev to you, you can check it now still at http://cr.openjdk.java.net/~fyuan/8051560/webrev.01/
>  
> I am not sure which is other insight you mentioned, would you like to explain more?
>  
> Best Regareds
> Frank
>  
> From: huizhe wang [mailto:huizhe.wang at oracle.com] 
> Sent: Tuesday, March 31, 2015 10:14 AM
> To: Frank Yuan
> Cc: 'Lance Andersen'; 'Core-Libs-Dev'; 'Gustavo Galimberti'
> Subject: Re: Review request for JDK-8051560: JAXP function astro tests conversion
>  
> Hi Frank,
> 
> Looks good. 
> 
> Since you've gone through the original test/the astro application, and refactored it into a TestNG test, you probably have other insight too. If so, it would be nice to add them as well.
> 
> In terms of report, yes, I can see the output files displayed along with process id. Thanks for doing that.  Not as good as the old test report, which lists test mode/query ids with status, but acceptable since it prints out the process and query ids that helps identifying the exact test.   
> 
> I have always wondered, but thought not so important, that in its current (TestNG) form, the test report will show test cases (thus fewer tests than the original test suite). For example, the AstroApp reports 10 tests and 39 test cases, while the new 5. Console display is quite different from the html report as well. For example, on the console, the test results are: passed: 70, but the html report shows 371 tests passed. What are your thoughts on this?
> 
> Thanks,
> Joe
> 
> On 3/27/2015 2:43 AM, Frank Yuan wrote:
> Hi Joe and Lance
>  
> Thank you very much for your review! It's very good comment!
>  
> According to your comments, I made the following changes:
> 1. Rename the output file name to be easier understanding.
> 2. Print the output file name to be easier debugging.
> 3. Add comment for AstroProcessor class
> 4. Add comment in AstroTest to describe the test, some are from astro application design document.
>  
> Besides these new adding comments, there are many comments in  astro classes(in libs/test/astro),  which are from the original source files. And the current tests prints information to the standard out, which is redirected to .jtr file by jtreg, so there is not any other trace file now. USER_DIR is the scratch dir in deed, it is property user.dir in jtreg. The new webrev is at http://cr.openjdk.java.net/~fyuan/8051560/webrev.01/
>  
> Btw, I also sent out review request for JDK-8051559: JAXP function dom tests minutes later than this review request, I am afraid you may miss it, reminder here:)
>  
> Best Regards
> Frank
>  
> From: huizhe wang [mailto:huizhe.wang at oracle.com] 
> Sent: Friday, March 27, 2015 9:02 AM
> To: Lance Andersen
> Cc: Frank Yuan; 'Core-Libs-Dev'; 'Gustavo Galimberti'
> Subject: Re: Review request for JDK-8051560: JAXP function astro tests conversion
>  
> I second Lance. The Main of the original astro had Javadocs and developer comments. Probably more important is that you've completely changed the main classes (TestDriver and Main), which looks good, however, the original classes contained a lot of information on what each test does and how it works that seem to have all been lost.
> 
> The suite's README and build.xml may also contain information that is worth keeping. Some of them may be no longer valid, in which case, it may be helpful to describe the change. For example, the log files described in README were useful for debugging. It would be good to explain where to find the debug info in your new design.
> 
> While scanning the test, I see that you are creating temporary output files under USER_DIR. Is that intended? JAXP processors do not necessarily open them with the DELETE_ON_CLOSE option. I thought in previous tests, you were creating them in the scratch directory.
> 
> Thanks,
> Joe
> 
> On 3/26/2015 12:08 PM, Lance Andersen wrote:
> Hi Frank,
>  
> Overall these look fine.  I would suggest adding a simple comment to describe the tests that do not have one to give a basic intent of the test to make it easier for someone to  understand if they are new.
>  
> Best
> Lance
> On Mar 25, 2015, at 5:34 AM, Frank Yuan <frank.yuan at oracle.com> wrote:
> 
> 
> 
> Hi, Joe and All
> 
> 
> 
> We are working on moving internal jaxp functional tests to open jdk repo.
> 
> This is the astro suite. Would you please review these test?  Any comment
> will be appreciated.
> 
> 
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8051560
> 
> webrev: http://cr.openjdk.java.net/~fyuan/8051560/webrev.00/
> 
> 
> 
> AstroTest is the primary test in this suite, it transforms an xml file(which
> includes astro data) with several xsl files, sets different filtering
> condition by these xsl files and different filtering range, finally compares
> the result with golden files. 
> 
> And there are 5 permutations of InputSourceFactory and FilterFactory(I uses
> template method pattern for the variant FilterFactoryImpls), each
> permutation will be applied to above transforming processes.
> 
> 
> 
> Thanks,
> 
> 
> 
> Frank
> 
>  
> <image001.gif>
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>  
> 
> 
> 
>  
>  



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





From lance.andersen at oracle.com  Tue Mar 31 14:10:43 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 31 Mar 2015 10:10:43 -0400
Subject: Review request for JDK-8051559: JAXP function dom tests conversion
In-Reply-To: <0E4D09A9-8046-42AC-98B8-D2433A8D38FF@oracle.com>
References: <035701d066e0$93124560$b936d020$@oracle.com>
	<019b01d06b8a$da0abca0$8e2035e0$@oracle.com>
	<0E4D09A9-8046-42AC-98B8-D2433A8D38FF@oracle.com>
Message-ID: <BCDD6F43-AF03-4A62-9F37-2780F8117586@oracle.com>

Hi Frank
On Mar 31, 2015, at 7:24 AM, Lance @ Oracle <lance.andersen at oracle.com> wrote:

> Hi frank 
> 
> Can you forward the other review request as I think I thought they were the same and deleted it

Ignore this comment, the subjects were too similar but this is what needed reviewed.
> 
> I will look at this again today

The tests overall look fine.

I still have the same comment WRT providing a simple comment describing each test.  The key point to remember is we want to make it easier for someone to  look at the test, understand what you are trying to validate, and understand the coverage of the tests.  This will help future maintainers of the code.  Comments are just as important in test code as it is in implementation IMHO.

Best
Lance
> 
> Best
> Lance
> 
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
> Sent from my iPad
> 
> On Mar 31, 2015, at 4:15 AM, Frank Yuan <frank.yuan at oracle.com> wrote:
> 
>> Hi Joe
>> 
>> 
>> 
>> Do you have any comment for dom suite co-location?
>> 
>> 
>> 
>> Best Regards
>> 
>> Frank
>> 
>> 
>> 
>> From: Frank Yuan [mailto:frank.yuan at oracle.com] 
>> Sent: Wednesday, March 25, 2015 5:46 PM
>> To: 'huizhe wang'; 'Core-Libs-Dev'
>> Cc: 'jibing chen'; 'Gustavo Galimberti'; sandeep.konchady at oracle.com;
>> 'Alexandre (Shura) Iline'
>> Subject: RE: Review request for JDK-8051559: JAXP function dom tests
>> conversion
>> 
>> 
>> 
>> Hi, Joe and All
>> 
>> 
>> 
>> We are working on moving internal jaxp functional tests to open jdk repo.
>> 
>> This is the dom suite. Would you please review these test?  Any comment will
>> be appreciated.
>> 
>> 
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8051559
>> 
>> webrev: http://cr.openjdk.java.net/~fyuan/8051559/webrev.00/
>> 
>> 
>> 
>> Thanks,
>> 
>> 
>> 
>> Frank
>> 



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





From daniel.fuchs at oracle.com  Tue Mar 31 14:29:48 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 31 Mar 2015 16:29:48 +0200
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <55198393.3000501@oracle.com>
References: <5513F6CE.3040505@oracle.com>
	<5513FB77.90305@oracle.com>	<55140D06.4030201@gmail.com>
	<55140FC0.4060104@oracle.com>	<55141540.9050600@gmail.com>
	<55153E88.7070200@oracle.com> <5515D00C.5080300@oracle.com>
	<551981CD.8010607@oracle.com> <55198393.3000501@oracle.com>
Message-ID: <551AAF5C.3010603@oracle.com>

Hi Mandy,

On 30/03/15 19:10, Mandy Chung wrote:
> I am aware of that while that synchronize is needed for updating the
> nodes.   As synchronized on removeLoggerRef isn't needed, I'd prefer it
> be taken out.

OK - the new webrev is here. I also updated the test as per
Jason's suggestion.

http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.02/

best regards,

-- daniel


From aph at redhat.com  Tue Mar 31 14:33:16 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 31 Mar 2015 15:33:16 +0100
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <55127C35.8000108@redhat.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>	<550A90CE.9080901@redhat.com>
	<550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com>
	<550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com>
	<550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com>
	<550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com>
	<55105C0A.8070305@redhat.com> <55108130.2010207@oracle.com>
	<55111D21.1020502@redhat.com> <5511F5EA.6010102@oracle.com>
	<55127C35.8000108@redhat.com>
Message-ID: <551AB02C.60202@redhat.com>

On 03/25/2015 09:13 AM, Andrew Haley wrote:
> On 24/03/15 23:40, Vladimir Kozlov wrote:
> 
>> The test failed when run it in JPRT with 32-bit fastdebug *Client* VM (-client) on linux-x86:
>>
>> java.lang.RuntimeException
>> 	at MyByteBuffer.ck(HeapByteBufferTest.java:201)
>> 	at MyByteBuffer.getLong(HeapByteBufferTest.java:211)
>> 	at HeapByteBufferTest.step(HeapByteBufferTest.java:311)
>> 	at HeapByteBufferTest.run(HeapByteBufferTest.java:347)
>> 	at HeapByteBufferTest.main(HeapByteBufferTest.java:362)
>>
>> Could be intrinsic in C1 does not work correctly? Please, look.
> 
> I certainly will.  That is odd: there's no reason I can think of why
> this might happen, and I know that the test running on a server build
> runs C1 code for a while so it has been tested.  I guess it must be a
> rare edge case.

It's not what I expected, and maybe not what you expected either.  My
test case fails on 32-bit x86 before any of my patches have been
applied.

It turns out that the problem is due to the handling of floating-point
NaNs on legacy 32-bit x86 systems.  The template interpreter uses
80x87 floating point but the compilers use XMM registers.  XMM is
transparent to all floating-point data: you can load and store any bit
pattern and it is not altered.  The same is not true of 80x87: if the
operand of an operation is a signaling NaN, the default action is to
silently convert it to a quiet NaN.

This means that interpreted and compiled code will do different things
with signaling NaNs.  While I'm not sure if this is a specification
violation, it certainly is a breach of the Write Once, Run Anywhere
principle, albeit a very unimportant one.

I've altered the test code so that when generating random bit patterns
it never generates a signaling NaN.  This makes for a clean run on
32-bit x86 systems.

http://cr.openjdk.java.net/~aph/unaligned.jdk.9/
http://cr.openjdk.java.net/~aph/unaligned.hotspot.9/

Andrew.


From mandy.chung at oracle.com  Tue Mar 31 14:52:46 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 31 Mar 2015 07:52:46 -0700
Subject: RFR: 7113878: LogManager - namedLoggers should be
	ConcurrentHashMap instead of Hashtable
In-Reply-To: <551AAF5C.3010603@oracle.com>
References: <5513F6CE.3040505@oracle.com>
	<5513FB77.90305@oracle.com>	<55140D06.4030201@gmail.com>
	<55140FC0.4060104@oracle.com>	<55141540.9050600@gmail.com>
	<55153E88.7070200@oracle.com> <5515D00C.5080300@oracle.com>
	<551981CD.8010607@oracle.com> <55198393.3000501@oracle.com>
	<551AAF5C.3010603@oracle.com>
Message-ID: <551AB4BE.7060703@oracle.com>

On 3/31/15 7:29 AM, Daniel Fuchs wrote:
> Hi Mandy,
>
> On 30/03/15 19:10, Mandy Chung wrote:
>> I am aware of that while that synchronize is needed for updating the
>> nodes.   As synchronized on removeLoggerRef isn't needed, I'd prefer it
>> be taken out.
>
> OK - the new webrev is here. I also updated the test as per
> Jason's suggestion.
>
> http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.02/

Looks good.

Thanks
Mandy


From vladimir.kozlov at oracle.com  Tue Mar 31 15:59:37 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 31 Mar 2015 08:59:37 -0700
Subject: 8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...}
	methods
In-Reply-To: <551AB02C.60202@redhat.com>
References: <550330CE.3030607@redhat.com>	<E02D38FE-A2A4-4E6C-AE6C-5913BBBEF279@oracle.com>	<550710BD.5060301@redhat.com>	<440070D1-AFBF-4D3A-9825-0659BA280ADC@oracle.com>	<5508325C.4000108@redhat.com>	<550A90CE.9080901@redhat.com>
	<550AF27F.4050305@oracle.com> <550AFA3C.5030002@oracle.com>
	<550AFF16.9080600@oracle.com> <550B350B.6040602@oracle.com>
	<550C460F.1090302@redhat.com> <550C989A.5010203@oracle.com>
	<550D57B1.602@redhat.com> <550D9D02.1020303@oracle.com>
	<55105C0A.8070305@redhat.com> <55108130.2010207@oracle.com>
	<55111D21.1020502@redhat.com> <5511F5EA.6010102@oracle.com>
	<55127C35.8000108@redhat.com> <551AB02C.60202@redhat.com>
Message-ID: <551AC469.4090502@oracle.com>

Thank you, Andrew

I will file a separate bug to address this issue - Interpreter and compiled code should produce the same result!

And I will push your changes today.

Regards,
Vladimir

On 3/31/15 7:33 AM, Andrew Haley wrote:
> On 03/25/2015 09:13 AM, Andrew Haley wrote:
>> On 24/03/15 23:40, Vladimir Kozlov wrote:
>>
>>> The test failed when run it in JPRT with 32-bit fastdebug *Client* VM (-client) on linux-x86:
>>>
>>> java.lang.RuntimeException
>>> 	at MyByteBuffer.ck(HeapByteBufferTest.java:201)
>>> 	at MyByteBuffer.getLong(HeapByteBufferTest.java:211)
>>> 	at HeapByteBufferTest.step(HeapByteBufferTest.java:311)
>>> 	at HeapByteBufferTest.run(HeapByteBufferTest.java:347)
>>> 	at HeapByteBufferTest.main(HeapByteBufferTest.java:362)
>>>
>>> Could be intrinsic in C1 does not work correctly? Please, look.
>>
>> I certainly will.  That is odd: there's no reason I can think of why
>> this might happen, and I know that the test running on a server build
>> runs C1 code for a while so it has been tested.  I guess it must be a
>> rare edge case.
>
> It's not what I expected, and maybe not what you expected either.  My
> test case fails on 32-bit x86 before any of my patches have been
> applied.
>
> It turns out that the problem is due to the handling of floating-point
> NaNs on legacy 32-bit x86 systems.  The template interpreter uses
> 80x87 floating point but the compilers use XMM registers.  XMM is
> transparent to all floating-point data: you can load and store any bit
> pattern and it is not altered.  The same is not true of 80x87: if the
> operand of an operation is a signaling NaN, the default action is to
> silently convert it to a quiet NaN.
>
> This means that interpreted and compiled code will do different things
> with signaling NaNs.  While I'm not sure if this is a specification
> violation, it certainly is a breach of the Write Once, Run Anywhere
> principle, albeit a very unimportant one.
>
> I've altered the test code so that when generating random bit patterns
> it never generates a signaling NaN.  This makes for a clean run on
> 32-bit x86 systems.
>
> http://cr.openjdk.java.net/~aph/unaligned.jdk.9/
> http://cr.openjdk.java.net/~aph/unaligned.hotspot.9/
>
> Andrew.
>


From michael.x.mcmahon at oracle.com  Tue Mar 31 16:31:54 2015
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Tue, 31 Mar 2015 17:31:54 +0100
Subject: JEP 110 HTTP 2 client API
Message-ID: <551ACBFA.7040304@oracle.com>

Hi,

[this has already been posted to net-dev]

JEP 110 HTTP 2 client

in JDK 9, is defining and implementing a new API for HTTP which also 
supports
the new HTTP version 2 that has recently been working its way through 
the IETF.
The work also includes support for websockets (RFC 6455).

In fact, the majority of the API is agnostic about the HTTP protocol 
version, with only minor
configuration settings, and support for multiple responses (Http server 
push) having any direct impact.

The HTTP API is defined around three main types (HttpClient, which is 
the central
point for configuration of SSL, executor service cookie management etc), 
HttpRequest
and HttpResponse (which should be self explanatory).

Requests are sent/received either synchronously (blocking) or in a 
non-blocking (asynchronous)
mode using java.util.future.CompletableFuture.

The API docs can be seen at the link below:

http://cr.openjdk.java.net/~michaelm/httpclient/01/

All new classes and interfaces belong to the java.net package.

A prototype implementation of this API supporting HTTP/1.1, is available
in the JDK 9 sandbox forest in JEP-110-branch.

Comments welcome!

Thanks,
Michael.


From mikhail.cherkasov at oracle.com  Tue Mar 31 19:08:01 2015
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Tue, 31 Mar 2015 22:08:01 +0300
Subject: [8] RFR of 8066985: Java Webstart downloading packed files can
	result in Timezone set to UTC
In-Reply-To: <55192507.4090704@oracle.com>
References: <550976B9.6030503@oracle.com> <5509F73C.6000306@oracle.com>
	<550AD4C9.9030905@oracle.com> <550AEF48.4070904@gmail.com>
	<550AF969.7070706@gmail.com> <550C36FD.701@oracle.com>
	<5511C5BE.2010809@oracle.com> <5511E9CB.7050504@oracle.com>
	<5512850F.90701@oracle.com> <5512D20D.4070709@oracle.com>
	<55145EBE.7070005@oracle.com> <55157E45.1030204@oracle.com>
	<55192507.4090704@oracle.com>
Message-ID: <551AF091.9060904@oracle.com>

And one more change in test.

Native packer/unpacker can throw exception during execution, but this 
issue is out of scope of this fix,
so I just disable it for test:

http://cr.openjdk.java.net/~mcherkas/8066985/webrev.09/test/tools/pack200/DefaultTimeZoneTest.java.html

On 3/30/2015 1:27 PM, mikhail cherkasov wrote:
>
> On 3/27/2015 6:59 PM, Kumar Srinivasan wrote:
>> yes that will work!, also why aren't all these final ? 
> fixed: http://cr.openjdk.java.net/~mcherkas/8066985/webrev.08/
>
>