From ecki at zusammenkunft.net  Sun Feb  1 00:14:06 2015
From: ecki at zusammenkunft.net (Bernd)
Date: Sun, 1 Feb 2015 01:14:06 +0100
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54CD6984.2040004@gmail.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>
	<54CD3043.2070709@gmail.com> <54CD4A14.2080205@oracle.com>
	<54CD6984.2040004@gmail.com>
Message-ID: <CABOR3+yDRwHt=ksV+TJqwfsBJVjbzgLXdwb6tLJ0+b0VapuaZw@mail.gmail.com>

Hello,

What about simply rejecting overlapping programmatic registrations, and for
the service loader using the natural order (class loader search order). I
guess most extensions register new schemes only, as it was not easy before
in such a central shared system component. an ordering api might not really
help. Its might be better to allow specific versions like a factory or even
something thread local? (Similar to jndi enc)

Bernd
Am 01.02.2015 00:48 schrieb "Peter Levart" <peter.levart at gmail.com>:

>  Hi Alan,
>
> On 01/31/2015 10:33 PM, Alan Bateman wrote:
>
> On 31/01/2015 19:42, Peter Levart wrote:
>
> Hi Chris,
>
> I looked at your solution to make URLStreamHandlerFactory interface a
> service provider using ServiceLoader API and in addition adding new URL
> static method to programmaticaly register  URLStreamHandlerFactories. There
> are a couple of issues with your approach I'd like to discuss.
>
> The programmatic approach using static URL method does give you some means
> of order in which registered URLStreamHandlerFactories are tried to create
> URLStreamHandler for particular protocol - the registration order. It means
> that this method should only be called by one "party" in the VM or else it
> is hard to control the order of registration.
>
> ServiceLoader is a declarative approach, but does not give you order by
> default. Also, your ServiceLoader approach gives a way for
> URLStreamHandlerFactories to register in the system without security
> checks. If a particular META-INF/services/java.net.URLStreamHandlerFactory
> is found, it's content is used to load a class and instantiate a factory
> which is used in URL constructors then. Previously, one had to have a
> "setFactory" permission to set the URLStreamHandlerFactory or appropriate
> PropertyPermission for seting the package prefix property. This can be
> fixed.
>
> :
>
> Anyway, I think there is an alternative to programmatic registration
> approach of URLStreamHandlerFactories. Using just ServiceLoader and a new
> default method on URLStreamHandlerFactory interface to provide order.
> Here's what I'm thinking about:
>
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/URLStreamHandlerFactory/webrev.01/
>
>
> I don't think we should we expose ordering values in
> URLStreamHandlerFactory, it looks a bit odd and not clear how an
> implementation can choose a useful value. There is a general issue that
> ServiceLoader doesn't currently support a means to order service providers
> but I think we can re-examine that when we move to modules and and linking.
> That is, have a consistent way to configure ordering that we can use
> everywhere that ServiceLoader is used rather than doing one-off solutions.
>
>
> I agree. Putting the order on the SPI API is not the right solution. The
> order should be configured in one place. But there needs to be some kind of
> handle each service exposes for order configuration to reference. So one
> idea how to extend the ServiceLoader mechanism is this:
>
> create a special class-scope runtime annotation...
>
> public @interface ServiceProvider {
>         String name();
> }
>
> ...with which service implementation classes can optionally be annotated.
> This could enable ServiceLoader API extension like:
>
>     public static <S> ServiceLoader<S> load(Class<S> service, String
> serviceProviderName)
>
> that would return an Iterable over implementations that are annotated with
> a particular @ServiceProvider(name = ...) annotation (similar to security
> Providers but simpler).
>
> In addition one could specify a system property with the key being
> prefixed by service interface FQ class name, like:
>
>
> java.net.URLStreamHandlerFactory.serviceLoaderOrder=providerName1,providerName2,providerName3,...
>
>
>
>
> The other thing is that it's not clear how this would work for a factory
> for the jar protocol that is itself deployed in a JAR file on the class
> path. This is important for containers that want to do their own caching
> and they want their jar protocol handler configured system-wide before
> starting any applications. It's also part of the motive for the
> addURLStreamHandlerFactory in the original proposal.
>
>
> I see. But isn't URL.setURLStreamHandlerFactory() enough for that purpose?
> It can only be set once, but there can only be *one* container that wants
> it's jar protocol handler configured system-wide.
>
> Regards, Peter
>
>
> I think you have good point with the setFactory permission, that does need
> to be looked at.
>
> -Alan.
>
>
>


From peter.levart at gmail.com  Sun Feb  1 09:25:00 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 01 Feb 2015 10:25:00 +0100
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <CABOR3+yDRwHt=ksV+TJqwfsBJVjbzgLXdwb6tLJ0+b0VapuaZw@mail.gmail.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CD3043.2070709@gmail.com>	<54CD4A14.2080205@oracle.com>	<54CD6984.2040004@gmail.com>
	<CABOR3+yDRwHt=ksV+TJqwfsBJVjbzgLXdwb6tLJ0+b0VapuaZw@mail.gmail.com>
Message-ID: <54CDF0EC.90806@gmail.com>

Hi Bernd,

On 02/01/2015 01:14 AM, Bernd wrote:
>
> Hello,
>
> What about simply rejecting overlapping programmatic registrations,
>

This can't work by registering URLStreamHandlerFactory objects as they 
don't announce their supported protocols. Perhaps registering 
URLStreamHandler objects directly would be an option as in:

public static void setURLStreamHandler(String protocol, URLStreamHandler 
urlStreamHandler) throws IllegalStateException

But this per-protocol registration (or any programmatic registration 
that overrides previous defaults) has a drawback that you can end up 
with URL instances for the same protocol but different URLStreamHandler, 
depending on when they are constructed, so it can happen that 
URL("http://www.google.com/") is not equal to 
URL("http://www.google.com/"). Sometimes you actually want that (see 
Alan's note about loading a "jar" URLStreamHandler deployed in a jar 
file), but otherwise it gives you a very fragile system that depends on 
initialization order. Programmatic registration should be reserved for 
the master of the universe (to be performed before the universe is 
born). Otherwise, special protocol handlers are better registered 
declaratively.

> and for the service loader using the natural order (class loader 
> search order). I guess most extensions register new schemes only, as 
> it was not easy before in such a central shared system component. an 
> ordering api might not really help. Its might be better to allow 
> specific versions like a factory or even something thread local? 
> (Similar to jndi enc)
>

If you want to have multiple universes in the same VM where each has 
it's own view of per-protocol URLStreamHandlers, then you must ensure 
that URL instances constructed in each universe, don't come in contact 
with each other or you will be subjected to similar issues as when two 
Class objects with same class name are not equal to each other, because 
each is loaded by different ClassLoader.

Regards, Peter

> Bernd
>
> Am 01.02.2015 00:48 schrieb "Peter Levart" <peter.levart at gmail.com 
> <mailto:peter.levart at gmail.com>>:
>
>     Hi Alan,
>
>     On 01/31/2015 10:33 PM, Alan Bateman wrote:
>>     On 31/01/2015 19:42, Peter Levart wrote:
>>>     Hi Chris,
>>>
>>>     I looked at your solution to make URLStreamHandlerFactory
>>>     interface a service provider using ServiceLoader API and in
>>>     addition adding new URL static method to programmaticaly
>>>     register URLStreamHandlerFactories. There are a couple of issues
>>>     with your approach I'd like to discuss.
>>>
>>>     The programmatic approach using static URL method does give you
>>>     some means of order in which registered
>>>     URLStreamHandlerFactories are tried to create URLStreamHandler
>>>     for particular protocol - the registration order. It means that
>>>     this method should only be called by one "party" in the VM or
>>>     else it is hard to control the order of registration.
>>>
>>>     ServiceLoader is a declarative approach, but does not give you
>>>     order by default. Also, your ServiceLoader approach gives a way
>>>     for URLStreamHandlerFactories to register in the system without
>>>     security checks. If a particular
>>>     META-INF/services/java.net.URLStreamHandlerFactory is found,
>>>     it's content is used to load a class and instantiate a factory
>>>     which is used in URL constructors then. Previously, one had to
>>>     have a "setFactory" permission to set the
>>>     URLStreamHandlerFactory or appropriate PropertyPermission for
>>>     seting the package prefix property. This can be fixed.
>>>
>>>     :
>>>
>>>     Anyway, I think there is an alternative to programmatic
>>>     registration approach of URLStreamHandlerFactories. Using just
>>>     ServiceLoader and a new default method on
>>>     URLStreamHandlerFactory interface to provide order. Here's what
>>>     I'm thinking about:
>>>
>>>     http://cr.openjdk.java.net/~plevart/jdk9-dev/URLStreamHandlerFactory/webrev.01/
>>>     <http://cr.openjdk.java.net/%7Eplevart/jdk9-dev/URLStreamHandlerFactory/webrev.01/>
>>
>>     I don't think we should we expose ordering values in
>>     URLStreamHandlerFactory, it looks a bit odd and not clear how an
>>     implementation can choose a useful value. There is a general
>>     issue that ServiceLoader doesn't currently support a means to
>>     order service providers but I think we can re-examine that when
>>     we move to modules and and linking. That is, have a consistent
>>     way to configure ordering that we can use everywhere that
>>     ServiceLoader is used rather than doing one-off solutions.
>
>     I agree. Putting the order on the SPI API is not the right
>     solution. The order should be configured in one place. But there
>     needs to be some kind of handle each service exposes for order
>     configuration to reference. So one idea how to extend the
>     ServiceLoader mechanism is this:
>
>     create a special class-scope runtime annotation...
>
>     public @interface ServiceProvider {
>             String name();
>     }
>
>     ...with which service implementation classes can optionally be
>     annotated. This could enable ServiceLoader API extension like:
>
>         public static <S> ServiceLoader<S> load(Class<S> service,
>     String serviceProviderName)
>
>     that would return an Iterable over implementations that are
>     annotated with a particular @ServiceProvider(name = ...)
>     annotation (similar to security Providers but simpler).
>
>     In addition one could specify a system property with the key being
>     prefixed by service interface FQ class name, like:
>
>     java.net.URLStreamHandlerFactory.serviceLoaderOrder=providerName1,providerName2,providerName3,...
>
>
>
>>
>>     The other thing is that it's not clear how this would work for a
>>     factory for the jar protocol that is itself deployed in a JAR
>>     file on the class path. This is important for containers that
>>     want to do their own caching and they want their jar protocol
>>     handler configured system-wide before starting any applications.
>>     It's also part of the motive for the addURLStreamHandlerFactory
>>     in the original proposal.
>
>     I see. But isn't URL.setURLStreamHandlerFactory() enough for that
>     purpose? It can only be set once, but there can only be *one*
>     container that wants it's jar protocol handler configured system-wide.
>
>     Regards, Peter
>
>>
>>     I think you have good point with the setFactory permission, that
>>     does need to be looked at.
>>
>>     -Alan.
>



From Alan.Bateman at oracle.com  Sun Feb  1 09:56:30 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 01 Feb 2015 09:56:30 +0000
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54CD6984.2040004@gmail.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>
	<54CD3043.2070709@gmail.com> <54CD4A14.2080205@oracle.com>
	<54CD6984.2040004@gmail.com>
Message-ID: <54CDF84E.7070905@oracle.com>

On 31/01/2015 23:47, Peter Levart wrote:
>
> I agree. Putting the order on the SPI API is not the right solution. 
> The order should be configured in one place. But there needs to be 
> some kind of handle each service exposes for order configuration to 
> reference. So one idea how to extend the ServiceLoader mechanism is this:
I think this is a much bigger topic and one that the URL usage isn't one 
of the better examples to explore it (the reason being that providers of 
URLStreamHandlerFactory are proposed to only be located via the system 
class loader, no proposal to allow for bundling with an application 
which is where the real scope issues come to the fore).


>
> I see. But isn't URL.setURLStreamHandlerFactory() enough for that 
> purpose? It can only be set once, but there can only be *one* 
> container that wants it's jar protocol handler configured system-wide.
>
This a good question as it brings up the scenario that Chris is trying 
to address by introducing addURLStreamHandlerFactory. The concern is 
where the container starts an application that also uses the legacy 
setURLStreamHandlerFactory. The container is trying not to cause the 
application to fail with an error. Looking at it again then I think 
addURLStreamHandlerFactory is going to be more an attractive nuisance 
that expected, despite the @apiNote and we need to drop this part of the 
solution. There are compatibility and migration concerns but I don't 
think they are significant in the overall context of a major release.

-Alan


From peter.levart at gmail.com  Sun Feb  1 10:45:38 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 01 Feb 2015 11:45:38 +0100
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54CDF84E.7070905@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>
	<54CD3043.2070709@gmail.com> <54CD4A14.2080205@oracle.com>
	<54CD6984.2040004@gmail.com> <54CDF84E.7070905@oracle.com>
Message-ID: <54CE03D2.8000706@gmail.com>


On 02/01/2015 10:56 AM, Alan Bateman wrote:
> On 31/01/2015 23:47, Peter Levart wrote:
>>
>> I agree. Putting the order on the SPI API is not the right solution. 
>> The order should be configured in one place. But there needs to be 
>> some kind of handle each service exposes for order configuration to 
>> reference. So one idea how to extend the ServiceLoader mechanism is this:
> I think this is a much bigger topic and one that the URL usage isn't 
> one of the better examples to explore it (the reason being that 
> providers of URLStreamHandlerFactory are proposed to only be located 
> via the system class loader, no proposal to allow for bundling with an 
> application which is where the real scope issues come to the fore).

I see. But if URLStreamHandlerFactories are only supposed to be located 
via the system class loader, is that different from what we have now 
when URLStreamHandlers are being located directly via class name 
construction (prefix + protocol + .Handler) and loaded via the system 
class loader? They have to be public classes with public default 
constructors, yes. But so have to be URLStreamHandlerFactories too, to 
be loadable by ServiceLoader.

Are we just trying to get rid of old mechanism or is there something I'm 
missing?

>
>
>>
>> I see. But isn't URL.setURLStreamHandlerFactory() enough for that 
>> purpose? It can only be set once, but there can only be *one* 
>> container that wants it's jar protocol handler configured system-wide.
>>
> This a good question as it brings up the scenario that Chris is trying 
> to address by introducing addURLStreamHandlerFactory. The concern is 
> where the container starts an application that also uses the legacy 
> setURLStreamHandlerFactory. The container is trying not to cause the 
> application to fail with an error. Looking at it again then I think 
> addURLStreamHandlerFactory is going to be more an attractive nuisance 
> that expected, despite the @apiNote and we need to drop this part of 
> the solution. There are compatibility and migration concerns but I 
> don't think they are significant in the overall context of a major 
> release.

If that's the reason for addURLStreamHandlerFactory (to support apps 
deployed to containers and which use setURLStreamHandlerFactory) then 
there should probably be some mechanism to allow those apps to call 
setURLStreamHandlerFactory but don't allow them to override handlers for 
protocols that container is trying to enforce (like jar). So factory set 
by setURLStreamHandlerFactory should not be evaluated 1st. What about 
the following order of evaluation:

1. default system factory if protocols are "file" or "jrt"
2. factories registered via ServiceLoader or addURLStreamHandlerFactory 
or equivalent
3. factory set by setURLStreamHandlerFactory if any
4. default system factory


Peter

> -Alan



From peter.levart at gmail.com  Sun Feb  1 15:48:35 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 01 Feb 2015 16:48:35 +0100
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54CDF84E.7070905@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>
	<54CD3043.2070709@gmail.com> <54CD4A14.2080205@oracle.com>
	<54CD6984.2040004@gmail.com> <54CDF84E.7070905@oracle.com>
Message-ID: <54CE4AD3.2070500@gmail.com>


On 02/01/2015 10:56 AM, Alan Bateman wrote:
>>
>> I see. But isn't URL.setURLStreamHandlerFactory() enough for that 
>> purpose? It can only be set once, but there can only be *one* 
>> container that wants it's jar protocol handler configured system-wide.
>>
> This a good question as it brings up the scenario that Chris is trying 
> to address by introducing addURLStreamHandlerFactory. The concern is 
> where the container starts an application that also uses the legacy 
> setURLStreamHandlerFactory. The container is trying not to cause the 
> application to fail with an error. Looking at it again then I think 
> addURLStreamHandlerFactory is going to be more an attractive nuisance 
> that expected, despite the @apiNote and we need to drop this part of 
> the solution. There are compatibility and migration concerns but I 
> don't think they are significant in the overall context of a major 
> release.
>
> -Alan

Here's another idea:

If URLStreamHandlerFactories could (optionally) announce supported 
protocols, then existing method setURLStreamHandlerFactory could allow 
setting multiple factories as long as they don't conflict. A container 
could set a factory that announces "jar" protocol only and that would 
not conflict with application deployed in container setting an 
URLStreamHandlerFactory that doesn't announce anything, so will be 
called for anything but "jar" in this situation.

Here's what I mean:

http://cr.openjdk.java.net/~plevart/jdk9-dev/URLStreamHandlerFactory/webrev.02/



Regards, Peter



From martinrb at google.com  Sun Feb  1 20:18:34 2015
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 1 Feb 2015 12:18:34 -0800
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>
References: <54CBAA39.3050004@Oracle.com> <54CBF7DB.9000909@oracle.com>
	<54CBFC10.9080502@Oracle.com>
	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>
	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>
	<54CD4305.4080607@oracle.com>
	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>
Message-ID: <CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>

More generally, it seems like an API design mistake (for the Java language
with its controversial checked exceptions) to throw UOE instead of IOE for
any operation that interacts with the environment external to the JVM.

What is the benefit for users?

On Sat, Jan 31, 2015 at 1:30 PM, Martin Buchholz <martinrb at google.com>
wrote:

> From a tck point of view, Process has always seems untestable, since any
> process creation can fail at any time for any (external) reason.  Adding
> special handling for OSes where a Process can never be created doesn't
> help... please explain.
>
> My feeling that we should consistently fail with IOException is
> hardening.  It's reasonable to throw a subclass that explains that you're
> on an OS where no subprocesses are allowed, or you can only start
> subprocesses after 7pm, or the only command you can run is { "cthulu" }.
>
> On Sat, Jan 31, 2015 at 1:03 PM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 31/01/2015 16:15, Martin Buchholz wrote:
>>
>>> It's not a big deal, but I am opposed to this change.
>>>
>> Just an FYI that Roger seems to have pushed the original patch, this new
>> patch just moves the text down so that it flows a bit better.
>>
>>  The old spec
>>>
>>>      * <p>In such cases an exception will be thrown. The exact nature
>>>      * of the exception is system-dependent, but it will always be a
>>>      * subclass of {@link IOException}.
>>>
>>> is perfectly adequate for OSes with no subprocesses.
>>> Users should be catching and handling IOException in any case.  Throwing
>>> a RuntimeException seems wrong, and breaks the above promise!
>>>
>>>  It's lack of clarity in the above text that has been causing the
>> testability issue for so long so I think it is good to make it clear how an
>> implementation that does not support processes should behave. The options
>> on the table seem to be to define a sub-type of IOE for this case, specify
>> that an IOE be thrown with an UOE as the cause, or just throw UOE when this
>> feature is not supported.
>>
>> -Alan
>>
>>
>>
>>
>


From fweimer at redhat.com  Mon Feb  2 08:09:52 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 02 Feb 2015 09:09:52 +0100
Subject: Time to retire System.runFinalizersOnExit?
In-Reply-To: <54CBB945.70908@oracle.com>
References: <54C7160D.4000802@oracle.com> <54CB6551.8040803@redhat.com>
	<54CBB945.70908@oracle.com>
Message-ID: <54CF30D0.1030403@redhat.com>

On 01/30/2015 06:03 PM, Mandy Chung wrote:
>> I see a few callers in Fedora in test suites, but only hsqldb as an
>> actual user in the installed JAR files.
> 
> Do you see any issue converting them?

I haven't tried.  I assume that any changes implemented will actually
increase resiliency of the test suite.  From that perspective, throwing
UnsupportedOperationException is better than just silently doing nothing.

-- 
Florian Weimer / Red Hat Product Security


From Alan.Bateman at oracle.com  Mon Feb  2 08:42:18 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 02 Feb 2015 08:42:18 +0000
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54CE03D2.8000706@gmail.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>
	<54CD3043.2070709@gmail.com> <54CD4A14.2080205@oracle.com>
	<54CD6984.2040004@gmail.com> <54CDF84E.7070905@oracle.com>
	<54CE03D2.8000706@gmail.com>
Message-ID: <54CF386A.9000600@oracle.com>

On 01/02/2015 10:45, Peter Levart wrote:
> :
>
> I see. But if URLStreamHandlerFactories are only supposed to be 
> located via the system class loader, is that different from what we 
> have now when URLStreamHandlers are being located directly via class 
> name construction (prefix + protocol + .Handler) and loaded via the 
> system class loader? They have to be public classes with public 
> default constructors, yes. But so have to be URLStreamHandlerFactories 
> too, to be loadable by ServiceLoader.
>
> Are we just trying to get rid of old mechanism or is there something 
> I'm missing?

The legacy mechanism isn't going to work with modules as currently 
envisaged (the protocol handler factory class may be visible and be a 
public type but it doesn't mean that it will accessible when we have 
module boundaries). The intention is that ServiceLoader will work with 
modules and so it should be possible to deploy modules that provide 
implementations of URLStreamHandlerFactory.

> :
>
> If that's the reason for addURLStreamHandlerFactory (to support apps 
> deployed to containers and which use setURLStreamHandlerFactory) then 
> there should probably be some mechanism to allow those apps to call 
> setURLStreamHandlerFactory but don't allow them to override handlers 
> for protocols that container is trying to enforce (like jar). So 
> factory set by setURLStreamHandlerFactory should not be evaluated 1st. 
> What about the following order of evaluation:
>
> 1. default system factory if protocols are "file" or "jrt"
> 2. factories registered via ServiceLoader or 
> addURLStreamHandlerFactory or equivalent
> 3. factory set by setURLStreamHandlerFactory if any
> 4. default system factory

Applications using setURLStreamHandlerFactory expect their protocol 
handler factory to be used and we don't want to break this. So I think 
this has to be called first, the only exception is the core protocols 
(file and jrt mostly) that cannot be overridden. So in your order then I 
think #2 and #3 should be reserved.

-Alan


From chris.hegarty at oracle.com  Mon Feb  2 09:15:20 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 2 Feb 2015 09:15:20 +0000
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54CF386A.9000600@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>
	<54CD3043.2070709@gmail.com> <54CD4A14.2080205@oracle.com>
	<54CD6984.2040004@gmail.com> <54CDF84E.7070905@oracle.com>
	<54CE03D2.8000706@gmail.com> <54CF386A.9000600@oracle.com>
Message-ID: <2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>

Just catching up?

On 2 Feb 2015, at 08:42, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 01/02/2015 10:45, Peter Levart wrote:
>> :
>> 
>> I see. But if URLStreamHandlerFactories are only supposed to be located via the system class loader, is that different from what we have now when URLStreamHandlers are being located directly via class name construction (prefix + protocol + .Handler) and loaded via the system class loader? They have to be public classes with public default constructors, yes. But so have to be URLStreamHandlerFactories too, to be loadable by ServiceLoader.
>> 
>> Are we just trying to get rid of old mechanism or is there something I'm missing?
> 
> The legacy mechanism isn't going to work with modules as currently envisaged (the protocol handler factory class may be visible and be a public type but it doesn't mean that it will accessible when we have module boundaries). The intention is that ServiceLoader will work with modules and so it should be possible to deploy modules that provide implementations of URLStreamHandlerFactory.

Thanks Alan. This may not have been clear from my original mail.

>> :
>> 
>> If that's the reason for addURLStreamHandlerFactory (to support apps deployed to containers and which use setURLStreamHandlerFactory) then there should probably be some mechanism to allow those apps to call setURLStreamHandlerFactory but don't allow them to override handlers for protocols that container is trying to enforce (like jar). So factory set by setURLStreamHandlerFactory should not be evaluated 1st. What about the following order of evaluation:
>> 
>> 1. default system factory if protocols are "file" or "jrt"
>> 2. factories registered via ServiceLoader or addURLStreamHandlerFactory or equivalent
>> 3. factory set by setURLStreamHandlerFactory if any
>> 4. default system factory
> 
> Applications using setURLStreamHandlerFactory expect their protocol handler factory to be used and we don't want to break this. So I think this has to be called first, the only exception is the core protocols (file and jrt mostly) that cannot be overridden. So in your order then I think #2 and #3 should be reserved.

Right, and if you reverse #2 and #3 above, you get the same ordering as in the original proposal.  I deliberately avoided any behavioural changes with setURLStreamHandlerFactory.

I hope I have not missed other comments ( please send them again, if they have not already been addressed ), but I think the only outstanding issue, with regard to the spec changes, is the permission on addURLStreamHandlerFactory. Maybe this method should define a new permission, rather than reusing setFactory, it could be RuntimePermission(?addFactory?). It would help further differentiate the addURLSHF and setURLSHF methods.

-Chris.

> -Alan



From paul.sandoz at oracle.com  Mon Feb  2 09:29:18 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 2 Feb 2015 10:29:18 +0100
Subject: RFR 8072030 Race condition in ThenComposeExceptionTest.java 
Message-ID: <69F5938F-EDAE-468D-829A-2AA39A776AC4@oracle.com>

Hi,

http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8072030-thenComposeException-test-race-condition/webrev/

I introduced a silly race condition in the test ThenComposeExceptionTest.java. This manifested itself in hotspot testing where various VM options increased the probability of failure.

Thanks,
Paul.


From patrick at reini.net  Mon Feb  2 09:58:01 2015
From: patrick at reini.net (Patrick Reinhart)
Date: Mon, 02 Feb 2015 10:58:01 +0100
Subject: Time to retire System.runFinalizersOnExit?
In-Reply-To: <54CF30D0.1030403@redhat.com>
References: <54C7160D.4000802@oracle.com>
	<54CB6551.8040803@redhat.com>	<54CBB945.70908@oracle.com>
	<54CF30D0.1030403@redhat.com>
Message-ID: <54CF4A29.10807@reini.net>

Am 2.2.2015 um 09:09 schrieb Florian Weimer:
> On 01/30/2015 06:03 PM, Mandy Chung wrote:
>>> I see a few callers in Fedora in test suites, but only hsqldb as an
>>> actual user in the installed JAR files.
>> Do you see any issue converting them?
> I haven't tried.  I assume that any changes implemented will actually
> increase resiliency of the test suite.  From that perspective, throwing
> UnsupportedOperationException is better than just silently doing nothing.
>

What about in production code that still calls this method and cannot be 
change due the lack of
source code? (Closed source software for example)

-Patrick


From chris.hegarty at oracle.com  Mon Feb  2 10:41:30 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 02 Feb 2015 10:41:30 +0000
Subject: RFR 8072030 Race condition in ThenComposeExceptionTest.java
In-Reply-To: <69F5938F-EDAE-468D-829A-2AA39A776AC4@oracle.com>
References: <69F5938F-EDAE-468D-829A-2AA39A776AC4@oracle.com>
Message-ID: <54CF545A.3060304@oracle.com>

On 02/02/15 09:29, Paul Sandoz wrote:
> Hi,
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8072030-thenComposeException-test-race-condition/webrev/
>
> I introduced a silly race condition in the test ThenComposeExceptionTest.java. This manifested itself in hotspot testing where various VM options increased the probability of failure.

The changes look fine to me Paul.

This not an issue for the 166 CVS ( test exists only in OpenJDK ).

This was a nasty race. In fact there is no guarantee that the CF, that 
sets the AtomicReference would even complete, without join/get, right ?

-Chris.


From miroslav.kos at oracle.com  Mon Feb  2 10:46:04 2015
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Mon, 02 Feb 2015 11:46:04 +0100
Subject: RFR: 8071585: Update JAX-WS RI integration to latest version
	(2.2.11-b150127.1410)
In-Reply-To: <54CA4C81.301@oracle.com>
References: <54CA48E0.8030902@oracle.com> <54CA4C81.301@oracle.com>
Message-ID: <54CF556C.10908@oracle.com>

On 29/01/15 16:06, Alan Bateman wrote:
> On 29/01/2015 14:51, Aleksej Efimov wrote:
>> Hi,
>> Can I have a review for a bulk update of JAX-B/WS from upstream 
>> projects -
>> webrev: http://cr.openjdk.java.net/~aefimov/8071585/webrev/
>> more details in JBS: https://bugs.openjdk.java.net/browse/JDK-8071585
>>
>> There is a lot of changes (947 lines) but almost all of them are 
>> minor (comments changes/(c) years)
>>
>> Thank you,
>> Aleksej
>>
> I see several changes where ">"is replaced by "&gt;" in pre-formatted 
> text (looks like < was changed to &lt; at some point in the past).
Hi Alan, thanks for catching this, we'll fix that. Is it ok to fix it in 
the next (in a month) bulk update?

Miran
>
> This is probably a question for the upstream projects but I would 
> think <pre>{@code ..}</pre> would make the source much easier to read.
>
> -Alan.
>



From paul.sandoz at oracle.com  Mon Feb  2 11:00:05 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 2 Feb 2015 12:00:05 +0100
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54CBF32F.9070603@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>
	<54CB9605.9050805@oracle.com>
	<17D44BD5-B456-40C9-A1DD-88B371052BB0@oracle.com>
	<54CBF32F.9070603@oracle.com>
Message-ID: <1B19D5DB-7053-44E9-8DD7-36BEB83821B3@oracle.com>


On Jan 30, 2015, at 10:10 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 30/01/2015 15:35, Chris Hegarty wrote:
>> :
>> 
>> Update webrev and spec diffs:
>>    http://cr.openjdk.java.net/~chegar/8064924/01/
>> 
> I think the javadoc looks much better now, thanks.
> 

Minor comments in URL:

Java doc on URL constructor:

 269      * <li>If the previous step fails to find a protocol handler, then the
 270      *     {@linkplain java.util.ServiceLoader ServiceLoader} mechanism is used
 271      *     to locate a {@code URLStreamHandlerFactory} provider using the system

"to locate {@code URLStreamHandlerFactory} providers using..."

Using the plural reads better given what follows:


 272      *     class loader. The ordering that providers are located is
 273      *     implementation specific, and an implementation is free to cache the
 274      *     located providers. A {@linkplain java.util.ServiceConfigurationError
 275      *     ServiceConfigurationError}, {@code Error} or {@code RuntimeException}
 276      *     thrown from the {@code createURLStreamHandler}, if encountered, will
 277      *     be propagated to the calling thread. The {@code
 278      *     createURLStreamHandler} method of each provider, if instantiated, is
 279      *     invoked, with the protocol string, until a provider returns non-null,
 280      *     or all providers have been exhausted.



In getURLStreamHandler method:

1313         if (handler == null) {
1314             // Try the built-in protocol handler
1315             handler = defaultFactory.createURLStreamHandler(protocol);
1316         }
1317 
1318         synchronized (streamHandlerLock) {
1319 
1320             URLStreamHandler handler2 = null;
1321 
1322             // Check again with hashtable just in case another
1323             // thread created a handler since we last checked
1324             handler2 = handlers.get(protocol);
1325 
1326             if (handler2 != null) {
1327                 return handler2;
1328             }
1329 
1330             // Check with factory if another thread set a
1331             // factory since our last check
1332             if (!checkedWithFactory) {
1333                 handler2 = handlerFromSettableFactory(protocol);
1334             }
1335 
1336             if (!(handler2 == null || handler2 == NULL_HANDLER)) {
1337                 // The handler from the factory must be given more
1338                 // importance. Discard the default handler that
1339                 // this thread created.
1340                 handler = handler2;
1341             }
1342 
1343             // Insert this handler into the hashtable
1344             if (handler != null) {
1345                 handlers.put(protocol, handler);
1346             }
1347 
1348         }


The code might read better if you place the stuff above the synchronized block within it (assuming that causes no issues):

  if (!checkedFactory) {
    handle = handlerFromSettableFactory(protocol);
    if (handle == NULL_HANDLER) handle = null;
  }
  if (handle == null) {
    handler = defaultFactory.createURLStreamHandler(protocol);
  }
  if (handle != null) {
    handlers.put(protocol, handler); 
  }

Paul.


From peter.firmstone at zeus.net.au  Mon Feb  2 11:16:22 2015
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Mon, 02 Feb 2015 21:16:22 +1000
Subject: Explicit Serialization API and Security
In-Reply-To: <54CA2581.9060906@zeus.net.au>
References: <54B0CE06.2020408@zeus.net.au>
	<54B3EEC5.5040805@oracle.com>		<1421144693.7530.20.camel@Nokia-N900>
	<54B654F6.6060207@oracle.com>	<1421240334.8856.17.camel@Nokia-N900>	<54BEB91A.4020603@gmail.com>
	<54BFD374.5080803@oracle.com>	<54C00B66.5090302@zeus.net.au>
	<54C01D71.9010901@redhat.com> <54C25DB0.4080207@oracle.com>
	<54C9F888.2040005@zeus.net.au> <54C9FBE1.1070702@zeus.net.au>
	<54CA0027.2000104@zeus.net.au> <54CA0707.5010005@zeus.net.au>
	<54CA0B6D.2050105@zeus.net.au> <54CA192A.1060404@zeus.net.au>
	<54CA2581.9060906@zeus.net.au>
Message-ID: <54CF5C86.8040505@zeus.net.au>

As mentioned I've been experimenting with an invariant validating 
ObjectInputStream, that's backward and forward compatible with Java's 
Object Serialization stream protocol.

No changes have been made to ObjectOutputStream.

ObjectInputStream has been overridden and reading from the stream has 
been completely reimplemented.

Classes are still required to implement Serializable, however readObject 
methods are not called and fields are not set reflectively after 
construction.

After considering all possibilities, I still find myself favouring 
constructors.

Definition of "Cumbersome":
     Slow or complicated and therefore inefficient.

During implementation, I've found that static invarient check methods 
are often shared with other constructors.

If another constructor already has a static invariant checking method, 
you only need call that constructor.

Performance wise, constructors significantly outperform setting every 
field using reflection, the more fields an Object has, the greater the 
performance benefit.

My experience is using constructors is often easier to understand than 
readObject methods.

Because constructors can be chained, I can perform final freezes in one 
constructor, then publish safely using another, existing readObject 
methods cannot provide this functionality.  If a final freeze occurs 
after the readObject method terminates, there is no way to fix existing 
code that uses unsafe publication.

See that attached example, this is actual production code (with the 
addition of @AtomicSerial), Java's RMI also has a DGC implementation.  
In this example using standard Serialization, because a final freeze 
occurs after readObject exits, the implementation uses unsafe 
publication, all guarantees are off.

The annotations I've used are:
@AtomicSerial - indicates serial constructor is present.
@ReadInput - provides access to a ReadObject implementation for direct 
interaction with the stream, prior to object construction, provided for 
backward compatiblility.

However the existing readObject alternative is all too often:
     Insecure and unsafely published.

The real question:

Is secure Serialization worth the additional work?

To those who would value it, I think the answer will be yes, to those 
that don't, perhaps not?

Regards,

Peter.




-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: BasicObjectEndpoint.txt
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20150202/6acd0b31/BasicObjectEndpoint.txt>

From chris.hegarty at oracle.com  Mon Feb  2 11:26:43 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 02 Feb 2015 11:26:43 +0000
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CD3043.2070709@gmail.com>
	<54CD4A14.2080205@oracle.com>	<54CD6984.2040004@gmail.com>
	<54CDF84E.7070905@oracle.com>	<54CE03D2.8000706@gmail.com>
	<54CF386A.9000600@oracle.com>
	<2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>
Message-ID: <54CF5EF3.20102@oracle.com>

I agree with Alan, addURLStreamHandlerFactory is probably an attractive 
nuisance. It is not strictly necessary to achieve the goal here; replace 
the problematic ( with modules ) system property with a service lookup.

For now, I'd like to move this issue forward without the additional new 
public method. We can have deploy use setURLSHF(), and document the 
compatibility issue if applets/Webstart apps also try to set a factory. 
We can revisit this later in 9, if it becomes an issue.

Updated specdiff:
   http://cr.openjdk.java.net/~chegar/8064924/02/specdiff/

I this revision, I omitted the implementation changes, so we can agree 
the spec changes first. They are much simpler now.

-Chris.

On 02/02/15 09:15, Chris Hegarty wrote:
> Just catching up?
>
> On 2 Feb 2015, at 08:42, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
>> On 01/02/2015 10:45, Peter Levart wrote:
>>> :
>>>
>>> I see. But if URLStreamHandlerFactories are only supposed to be located via the system class loader, is that different from what we have now when URLStreamHandlers are being located directly via class name construction (prefix + protocol + .Handler) and loaded via the system class loader? They have to be public classes with public default constructors, yes. But so have to be URLStreamHandlerFactories too, to be loadable by ServiceLoader.
>>>
>>> Are we just trying to get rid of old mechanism or is there something I'm missing?
>>
>> The legacy mechanism isn't going to work with modules as currently envisaged (the protocol handler factory class may be visible and be a public type but it doesn't mean that it will accessible when we have module boundaries). The intention is that ServiceLoader will work with modules and so it should be possible to deploy modules that provide implementations of URLStreamHandlerFactory.
>
> Thanks Alan. This may not have been clear from my original mail.
>
>>> :
>>>
>>> If that's the reason for addURLStreamHandlerFactory (to support apps deployed to containers and which use setURLStreamHandlerFactory) then there should probably be some mechanism to allow those apps to call setURLStreamHandlerFactory but don't allow them to override handlers for protocols that container is trying to enforce (like jar). So factory set by setURLStreamHandlerFactory should not be evaluated 1st. What about the following order of evaluation:
>>>
>>> 1. default system factory if protocols are "file" or "jrt"
>>> 2. factories registered via ServiceLoader or addURLStreamHandlerFactory or equivalent
>>> 3. factory set by setURLStreamHandlerFactory if any
>>> 4. default system factory
>>
>> Applications using setURLStreamHandlerFactory expect their protocol handler factory to be used and we don't want to break this. So I think this has to be called first, the only exception is the core protocols (file and jrt mostly) that cannot be overridden. So in your order then I think #2 and #3 should be reserved.
>
> Right, and if you reverse #2 and #3 above, you get the same ordering as in the original proposal.  I deliberately avoided any behavioural changes with setURLStreamHandlerFactory.
>
> I hope I have not missed other comments ( please send them again, if they have not already been addressed ), but I think the only outstanding issue, with regard to the spec changes, is the permission on addURLStreamHandlerFactory. Maybe this method should define a new permission, rather than reusing setFactory, it could be RuntimePermission(?addFactory?). It would help further differentiate the addURLSHF and setURLSHF methods.
>
> -Chris.
>
>> -Alan
>


From chris.hegarty at oracle.com  Mon Feb  2 11:34:15 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 02 Feb 2015 11:34:15 +0000
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <1B19D5DB-7053-44E9-8DD7-36BEB83821B3@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CB9605.9050805@oracle.com>	<17D44BD5-B456-40C9-A1DD-88B371052BB0@oracle.com>	<54CBF32F.9070603@oracle.com>
	<1B19D5DB-7053-44E9-8DD7-36BEB83821B3@oracle.com>
Message-ID: <54CF60B7.2010607@oracle.com>

On 02/02/15 11:00, Paul Sandoz wrote:
>
> On Jan 30, 2015, at 10:10 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
>> On 30/01/2015 15:35, Chris Hegarty wrote:
>>> :
>>>
>>> Update webrev and spec diffs:
>>>     http://cr.openjdk.java.net/~chegar/8064924/01/
>>>
>> I think the javadoc looks much better now, thanks.
>>
>
> Minor comments in URL:
>
> Java doc on URL constructor:
>
>   269      * <li>If the previous step fails to find a protocol handler, then the
>   270      *     {@linkplain java.util.ServiceLoader ServiceLoader} mechanism is used
>   271      *     to locate a {@code URLStreamHandlerFactory} provider using the system
>
> "to locate {@code URLStreamHandlerFactory} providers using..."

Thanks Paul, Updated in the latest version ( see other mail ).

> Using the plural reads better given what follows:
>
>
>   272      *     class loader. The ordering that providers are located is
>   273      *     implementation specific, and an implementation is free to cache the
>   274      *     located providers. A {@linkplain java.util.ServiceConfigurationError
>   275      *     ServiceConfigurationError}, {@code Error} or {@code RuntimeException}
>   276      *     thrown from the {@code createURLStreamHandler}, if encountered, will
>   277      *     be propagated to the calling thread. The {@code
>   278      *     createURLStreamHandler} method of each provider, if instantiated, is
>   279      *     invoked, with the protocol string, until a provider returns non-null,
>   280      *     or all providers have been exhausted.
>
>
>
> In getURLStreamHandler method:
>
> 1313         if (handler == null) {
> 1314             // Try the built-in protocol handler
> 1315             handler = defaultFactory.createURLStreamHandler(protocol);
> 1316         }
> 1317
> 1318         synchronized (streamHandlerLock) {
> 1319
> 1320             URLStreamHandler handler2 = null;
> 1321
> 1322             // Check again with hashtable just in case another
> 1323             // thread created a handler since we last checked
> 1324             handler2 = handlers.get(protocol);
> 1325
> 1326             if (handler2 != null) {
> 1327                 return handler2;
> 1328             }
> 1329
> 1330             // Check with factory if another thread set a
> 1331             // factory since our last check
> 1332             if (!checkedWithFactory) {
> 1333                 handler2 = handlerFromSettableFactory(protocol);
> 1334             }
> 1335
> 1336             if (!(handler2 == null || handler2 == NULL_HANDLER)) {
> 1337                 // The handler from the factory must be given more
> 1338                 // importance. Discard the default handler that
> 1339                 // this thread created.
> 1340                 handler = handler2;
> 1341             }
> 1342
> 1343             // Insert this handler into the hashtable
> 1344             if (handler != null) {
> 1345                 handlers.put(protocol, handler);
> 1346             }
> 1347
> 1348         }
>
>
> The code might read better if you place the stuff above the synchronized block within it (assuming that causes no issues):
>
>    if (!checkedFactory) {
>      handle = handlerFromSettableFactory(protocol);
>      if (handle == NULL_HANDLER) handle = null;
>    }
>    if (handle == null) {
>      handler = defaultFactory.createURLStreamHandler(protocol);
>    }
>    if (handle != null) {
>      handlers.put(protocol, handler);
>    }

That is a possibility, but great effort has been put into this area 
recently, by Peter, to attempt to keep the lookup of handlers lock free 
( typically a volatile read, only requiring the lock when updating the 
cache ).

We would also not want to hold the lock while performing the service 
lookup, in which case we may end up with two synchronization blocks, so 
as to keep the service lookup as lazy as possible. Or have I missed our 
point?

-Chris.


> Paul.
>


From paul.sandoz at oracle.com  Mon Feb  2 11:36:53 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 2 Feb 2015 12:36:53 +0100
Subject: RFR 8072030 Race condition in ThenComposeExceptionTest.java
In-Reply-To: <54CF545A.3060304@oracle.com>
References: <69F5938F-EDAE-468D-829A-2AA39A776AC4@oracle.com>
	<54CF545A.3060304@oracle.com>
Message-ID: <E07B8B9A-E699-421E-8681-A1C40E839132@oracle.com>


On Feb 2, 2015, at 11:41 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> On 02/02/15 09:29, Paul Sandoz wrote:
>> Hi,
>> 
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8072030-thenComposeException-test-race-condition/webrev/
>> 
>> I introduced a silly race condition in the test ThenComposeExceptionTest.java. This manifested itself in hotspot testing where various VM options increased the probability of failure.
> 
> The changes look fine to me Paul.
> 

Thanks.


> This not an issue for the 166 CVS ( test exists only in OpenJDK ).
> 

Yes.


> This was a nasty race. In fact there is no guarantee that the CF, that sets the AtomicReference would even complete, without join/get, right ?
> 

I think the async completion of the thenComposed task will trigger (in the same thread) the completion of the dependent whenCompleted task, such that one could use a count down latch (which would be an odd thing to use).
 
Paul.


From paul.sandoz at oracle.com  Mon Feb  2 11:55:36 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 2 Feb 2015 12:55:36 +0100
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54CF60B7.2010607@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CB9605.9050805@oracle.com>	<17D44BD5-B456-40C9-A1DD-88B371052BB0@oracle.com>	<54CBF32F.9070603@oracle.com>
	<1B19D5DB-7053-44E9-8DD7-36BEB83821B3@oracle.com>
	<54CF60B7.2010607@oracle.com>
Message-ID: <574D1560-1847-43F0-B0C4-5BF2E0CA38D0@oracle.com>


On Feb 2, 2015, at 12:34 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> On 02/02/15 11:00, Paul Sandoz wrote:
>> 
>> On Jan 30, 2015, at 10:10 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>>> On 30/01/2015 15:35, Chris Hegarty wrote:
>>>> :
>>>> 
>>>> Update webrev and spec diffs:
>>>>    http://cr.openjdk.java.net/~chegar/8064924/01/
>>>> 
>>> I think the javadoc looks much better now, thanks.
>>> 
>> 
>> Minor comments in URL:
>> 
>> Java doc on URL constructor:
>> 
>>  269      * <li>If the previous step fails to find a protocol handler, then the
>>  270      *     {@linkplain java.util.ServiceLoader ServiceLoader} mechanism is used
>>  271      *     to locate a {@code URLStreamHandlerFactory} provider using the system
>> 
>> "to locate {@code URLStreamHandlerFactory} providers using..."
> 
> Thanks Paul, Updated in the latest version ( see other mail ).
> 

Ok.


>> 
>> The code might read better if you place the stuff above the synchronized block within it (assuming that causes no issues):
>> 
>>   if (!checkedFactory) {
>>     handle = handlerFromSettableFactory(protocol);
>>     if (handle == NULL_HANDLER) handle = null;
>>   }
>>   if (handle == null) {
>>     handler = defaultFactory.createURLStreamHandler(protocol);
>>   }
>>   if (handle != null) {
>>     handlers.put(protocol, handler);
>>   }
> 
> That is a possibility, but great effort has been put into this area recently, by Peter, to attempt to keep the lookup of handlers lock free ( typically a volatile read, only requiring the lock when updating the cache ).
> 
> We would also not want to hold the lock while performing the service lookup, in which case we may end up with two synchronization blocks, so as to keep the service lookup as lazy as possible. Or have I missed our point?
> 

It was specifically to do with the optimistic call to defaultFactory.createURLStreamHandle the result of which might be thrown away, but probably not. The method handlerFromSettableFactory is anyway called from within the synchronized so it did not seem a big deal to pull in default factory call and simplify the logic.

Paul.


From Roger.Riggs at Oracle.com  Mon Feb  2 13:35:27 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 02 Feb 2015 08:35:27 -0500
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>
References: <54CBAA39.3050004@Oracle.com>	<54CBF7DB.9000909@oracle.com>	<54CBFC10.9080502@Oracle.com>	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>	<54CD4305.4080607@oracle.com>	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>
	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>
Message-ID: <54CF7D1F.6050101@Oracle.com>

Hi Martin,

The choice of UnsupportedOperationException specifies a complete inability
of the runtime to ever launch a Process.  IOException on the other hand
is appropriate in cases where there are configuration or OS implementation
dependencies or transient behavior.

Existing applications that expect to spawn processes are very unlikely to be
appropriate for a target platform without Process support.  For new and
retargeted applications identifying such a basic mismatch should be
immediate and conclusive.

Adding a subtype of IOException doesn't help existing applications and
adds to the already overloaded IOException.

It seems more valuable to make a clear distinction in the specification
than to add to the current vagaries of OS dependencies.

Roger



On 2/1/15 3:18 PM, Martin Buchholz wrote:
> More generally, it seems like an API design mistake (for the Java 
> language with its controversial checked exceptions) to throw UOE 
> instead of IOE for any operation that interacts with the environment 
> external to the JVM.
>
> What is the benefit for users?
>
> On Sat, Jan 31, 2015 at 1:30 PM, Martin Buchholz <martinrb at google.com 
> <mailto:martinrb at google.com>> wrote:
>
>     From a tck point of view, Process has always seems untestable,
>     since any process creation can fail at any time for any (external)
>     reason.  Adding special handling for OSes where a Process can
>     never be created doesn't help... please explain.
>
>     My feeling that we should consistently fail with IOException is
>     hardening.  It's reasonable to throw a subclass that explains that
>     you're on an OS where no subprocesses are allowed, or you can only
>     start subprocesses after 7pm, or the only command you can run is {
>     "cthulu" }.
>
>     On Sat, Jan 31, 2015 at 1:03 PM, Alan Bateman
>     <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>
>         On 31/01/2015 16:15, Martin Buchholz wrote:
>
>             It's not a big deal, but I am opposed to this change.
>
>         Just an FYI that Roger seems to have pushed the original
>         patch, this new patch just moves the text down so that it
>         flows a bit better.
>
>             The old spec
>
>                  * <p>In such cases an exception will be thrown. The
>             exact nature
>                  * of the exception is system-dependent, but it will
>             always be a
>                  * subclass of {@link IOException}.
>
>             is perfectly adequate for OSes with no subprocesses.
>             Users should be catching and handling IOException in any
>             case.  Throwing a RuntimeException seems wrong, and breaks
>             the above promise!
>
>         It's lack of clarity in the above text that has been causing
>         the testability issue for so long so I think it is good to
>         make it clear how an implementation that does not support
>         processes should behave. The options on the table seem to be
>         to define a sub-type of IOE for this case, specify that an IOE
>         be thrown with an UOE as the cause, or just throw UOE when
>         this feature is not supported.
>
>         -Alan
>
>
>
>
>



From martinrb at google.com  Mon Feb  2 16:50:17 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 2 Feb 2015 08:50:17 -0800
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <54CF7D1F.6050101@Oracle.com>
References: <54CBAA39.3050004@Oracle.com> <54CBF7DB.9000909@oracle.com>
	<54CBFC10.9080502@Oracle.com>
	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>
	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>
	<54CD4305.4080607@oracle.com>
	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>
	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>
	<54CF7D1F.6050101@Oracle.com>
Message-ID: <CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>

Hi,

Y'all seem determined to continue on this course of
UnsupportedOperationException-ization, but to me it seems the wrong
direction to take.

You are reversing the standard Java dogma of checked vs. unchecked
exceptions as explained e.g. at
http://www.javapractices.com/topic/TopicAction.do?Id=129 creating an
increasingly inconsistent and capricious platform, with no benefit to users.

Code will need to start checking both UOE and IOE for "os errors". For the
case of ProcessBuilder, this is particularly egregious, since the javadoc
goes out of its way to explicitly guarantee that catching IOE is sufficient.

There is no sharp distinction for platforms that don't support exceptions,
but CantCreateSubprocessesDuringPeakHoursException and
PleasePayYourBillException are semantically very close.

I believe that current platforms that allow absolutely no subprocess
creation will see pressure to relax that, especially for creating new
instances of the JVM itself recursively.  Not allowing process creation is
essentially a bug, that future releases of the platform are likely to fix.
I foresee a future where some carefully supervised process creation is
allowed on "locked-down systems", and I fear that other process creation
will continue to throw a now nonsensical UOE "for compatibility".




On Mon, Feb 2, 2015 at 5:35 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

>  Hi Martin,
>
> The choice of UnsupportedOperationException specifies a complete
> inability
> of the runtime to ever launch a Process.  IOException on the other hand
> is appropriate in cases where there are configuration or OS implementation
> dependencies or transient behavior.
>
> Existing applications that expect to spawn processes are very unlikely to
> be
> appropriate for a target platform without Process support.  For new and
> retargeted applications identifying such a basic mismatch should be
> immediate and conclusive.
>
> Adding a subtype of IOException doesn't help existing applications and
> adds to the already overloaded IOException.
>
> It seems more valuable to make a clear distinction in the specification
> than to add to the current vagaries of OS dependencies.
>
> Roger
>
>
>
>
> On 2/1/15 3:18 PM, Martin Buchholz wrote:
>
>  More generally, it seems like an API design mistake (for the Java
> language with its controversial checked exceptions) to throw UOE instead of
> IOE for any operation that interacts with the environment external to the
> JVM.
>
>  What is the benefit for users?
>
> On Sat, Jan 31, 2015 at 1:30 PM, Martin Buchholz <martinrb at google.com>
> wrote:
>
>>  From a tck point of view, Process has always seems untestable, since
>> any process creation can fail at any time for any (external) reason.
>> Adding special handling for OSes where a Process can never be created
>> doesn't help... please explain.
>>
>>  My feeling that we should consistently fail with IOException is
>> hardening.  It's reasonable to throw a subclass that explains that you're
>> on an OS where no subprocesses are allowed, or you can only start
>> subprocesses after 7pm, or the only command you can run is { "cthulu" }.
>>
>> On Sat, Jan 31, 2015 at 1:03 PM, Alan Bateman <Alan.Bateman at oracle.com>
>> wrote:
>>
>>> On 31/01/2015 16:15, Martin Buchholz wrote:
>>>
>>>> It's not a big deal, but I am opposed to this change.
>>>>
>>>  Just an FYI that Roger seems to have pushed the original patch, this
>>> new patch just moves the text down so that it flows a bit better.
>>>
>>>  The old spec
>>>>
>>>>      * <p>In such cases an exception will be thrown. The exact nature
>>>>      * of the exception is system-dependent, but it will always be a
>>>>      * subclass of {@link IOException}.
>>>>
>>>> is perfectly adequate for OSes with no subprocesses.
>>>> Users should be catching and handling IOException in any case.
>>>> Throwing a RuntimeException seems wrong, and breaks the above promise!
>>>>
>>>>  It's lack of clarity in the above text that has been causing the
>>> testability issue for so long so I think it is good to make it clear how an
>>> implementation that does not support processes should behave. The options
>>> on the table seem to be to define a sub-type of IOE for this case, specify
>>> that an IOE be thrown with an UOE as the cause, or just throw UOE when this
>>> feature is not supported.
>>>
>>> -Alan
>>>
>>>
>>>
>>>
>>
>
>


From joe.darcy at oracle.com  Mon Feb  2 19:56:12 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 02 Feb 2015 11:56:12 -0800
Subject: JDK 9 RFR of addition to ProblemList.txt
Message-ID: <54CFD65C.2070306@oracle.com>

Hello,

The test

     javax/xml/ws/8046817/GenerateEnumSchema.java

has been failing on windows since some recent changes. Please approve 
the patch below to put the test on the problem list while a full fix is 
investigated.

Thanks,

-Joe

diff -r 541a8cef4e0d test/ProblemList.txt
--- a/test/ProblemList.txt    Thu Jan 29 16:16:35 2015 -0800
+++ b/test/ProblemList.txt    Mon Feb 02 11:54:52 2015 -0800
@@ -162,6 +162,9 @@
  # 6988950
  demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java generic-all

+# 8071968
+javax/xml/ws/8046817/GenerateEnumSchema.java windows-all
+
  ############################################################################

  # jdk_net



From Roger.Riggs at Oracle.com  Mon Feb  2 20:05:57 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 02 Feb 2015 15:05:57 -0500
Subject: JDK 9 RFR of addition to ProblemList.txt
In-Reply-To: <54CFD65C.2070306@oracle.com>
References: <54CFD65C.2070306@oracle.com>
Message-ID: <54CFD8A5.9050201@Oracle.com>

Hi Joe,

Looks fine.

Roger

On 2/2/15 2:56 PM, joe darcy wrote:
> Hello,
>
> The test
>
>     javax/xml/ws/8046817/GenerateEnumSchema.java
>
> has been failing on windows since some recent changes. Please approve 
> the patch below to put the test on the problem list while a full fix 
> is investigated.
>
> Thanks,
>
> -Joe
>
> diff -r 541a8cef4e0d test/ProblemList.txt
> --- a/test/ProblemList.txt    Thu Jan 29 16:16:35 2015 -0800
> +++ b/test/ProblemList.txt    Mon Feb 02 11:54:52 2015 -0800
> @@ -162,6 +162,9 @@
>  # 6988950
>  demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java generic-all
>
> +# 8071968
> +javax/xml/ws/8046817/GenerateEnumSchema.java windows-all
> +
>  ############################################################################ 
>
>
>  # jdk_net
>



From Roger.Riggs at Oracle.com  Mon Feb  2 20:39:00 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 02 Feb 2015 15:39:00 -0500
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>
References: <54CBAA39.3050004@Oracle.com>	<54CBF7DB.9000909@oracle.com>	<54CBFC10.9080502@Oracle.com>	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>	<54CD4305.4080607@oracle.com>	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>	<54CF7D1F.6050101@Oracle.com>
	<CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>
Message-ID: <54CFE064.70400@Oracle.com>

Hi,

The original protagonist is on vacation this week so the resolution may 
be delayed.
I picked up what seemed like the relatively simple task of making the 
change.

On 2/2/15 11:50 AM, Martin Buchholz wrote:
> Hi,
>
> Y'all seem determined to continue on this course of 
> UnsupportedOperationException-ization, but to me it seems the wrong 
> direction to take.
>
> You are reversing the standard Java dogma of checked vs. unchecked 
> exceptions as explained e.g. at 
> http://www.javapractices.com/topic/TopicAction.do?Id=129 creating an 
> increasingly inconsistent and capricious platform, with no benefit to 
> users.
Using the phrase from Unchecked exceptions: "cannot be reasonably 
recovered from at runtime"
covers the case that the JRE does not support Process spawning.  If the 
application expects to be
able to spawn Processes and the platform unconditionally does not 
support it, there is nothing the
application can do to recover.

Citing this principle suggests there is some alternative, but what?
>
> Code will need to start checking both UOE and IOE for "os errors". For 
> the case of ProcessBuilder, this is particularly egregious, since the 
> javadoc goes out of its way to explicitly guarantee that catching IOE 
> is sufficient.
>
> There is no sharp distinction for platforms that don't support 
> exceptions, but CantCreateSubprocessesDuringPeakHoursException and 
> PleasePayYourBillException are semantically very close.
I'm not sure of the use of 'exceptions' here. IOExceptions can cover a 
whole host
of OS specific behaviors including those that might arise by way of a 
policy not of the OS
but by the operational environment. But I would expect these examples to 
be covered by the
current IOException.
>
> I believe that current platforms that allow absolutely no subprocess 
> creation will see pressure to relax that, especially for creating new 
> instances of the JVM itself recursively.  Not allowing process 
> creation is essentially a bug, that future releases of the platform 
> are likely to fix. I foresee a future where some carefully supervised 
> process creation is allowed on "locked-down systems", and I fear that 
> other process creation will continue to throw a now nonsensical UOE 
> "for compatibility".
If those platforms change their implementation from not supported ever 
to maybe-sometimes
under the right conditions then they would supply an implementation that 
reports
failures using IOException.  In some cases, policy choices should be 
reflected perhaps
in SecurityException rather than IOExceptions.

The points raised imply that there are use cases that take advantage of 
the vagaries
of the current under specified Process.

Roger

>
>
>
>
> On Mon, Feb 2, 2015 at 5:35 AM, Roger Riggs <Roger.Riggs at oracle.com 
> <mailto:Roger.Riggs at oracle.com>> wrote:
>
>     Hi Martin,
>
>     The choice of UnsupportedOperationException specifies a complete
>     inability
>     of the runtime to ever launch a Process.  IOException on the other
>     hand
>     is appropriate in cases where there are configuration or OS
>     implementation
>     dependencies or transient behavior.
>
>     Existing applications that expect to spawn processes are very
>     unlikely to be
>     appropriate for a target platform without Process support.  For
>     new and
>     retargeted applications identifying such a basic mismatch should be
>     immediate and conclusive.
>
>     Adding a subtype of IOException doesn't help existing applications and
>     adds to the already overloaded IOException.
>
>     It seems more valuable to make a clear distinction in the
>     specification
>     than to add to the current vagaries of OS dependencies.
>
>     Roger
>
>
>
>
>     On 2/1/15 3:18 PM, Martin Buchholz wrote:
>>     More generally, it seems like an API design mistake (for the Java
>>     language with its controversial checked exceptions) to throw UOE
>>     instead of IOE for any operation that interacts with the
>>     environment external to the JVM.
>>
>>     What is the benefit for users?
>>
>>     On Sat, Jan 31, 2015 at 1:30 PM, Martin Buchholz
>>     <martinrb at google.com <mailto:martinrb at google.com>> wrote:
>>
>>         From a tck point of view, Process has always seems
>>         untestable, since any process creation can fail at any time
>>         for any (external) reason.  Adding special handling for OSes
>>         where a Process can never be created doesn't help... please
>>         explain.
>>
>>         My feeling that we should consistently fail with IOException
>>         is hardening.  It's reasonable to throw a subclass that
>>         explains that you're on an OS where no subprocesses are
>>         allowed, or you can only start subprocesses after 7pm, or the
>>         only command you can run is { "cthulu" }.
>>
>>         On Sat, Jan 31, 2015 at 1:03 PM, Alan Bateman
>>         <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>>
>>             On 31/01/2015 16:15, Martin Buchholz wrote:
>>
>>                 It's not a big deal, but I am opposed to this change.
>>
>>             Just an FYI that Roger seems to have pushed the original
>>             patch, this new patch just moves the text down so that it
>>             flows a bit better.
>>
>>                 The old spec
>>
>>                      * <p>In such cases an exception will be thrown.
>>                 The exact nature
>>                      * of the exception is system-dependent, but it
>>                 will always be a
>>                      * subclass of {@link IOException}.
>>
>>                 is perfectly adequate for OSes with no subprocesses.
>>                 Users should be catching and handling IOException in
>>                 any case.  Throwing a RuntimeException seems wrong,
>>                 and breaks the above promise!
>>
>>             It's lack of clarity in the above text that has been
>>             causing the testability issue for so long so I think it
>>             is good to make it clear how an implementation that does
>>             not support processes should behave. The options on the
>>             table seem to be to define a sub-type of IOE for this
>>             case, specify that an IOE be thrown with an UOE as the
>>             cause, or just throw UOE when this feature is not supported.
>>
>>             -Alan
>>
>>
>>
>>
>>
>
>



From Alan.Bateman at oracle.com  Mon Feb  2 20:52:29 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 02 Feb 2015 20:52:29 +0000
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54CF5EF3.20102@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CD3043.2070709@gmail.com>
	<54CD4A14.2080205@oracle.com>	<54CD6984.2040004@gmail.com>
	<54CDF84E.7070905@oracle.com>	<54CE03D2.8000706@gmail.com>
	<54CF386A.9000600@oracle.com>
	<2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>
	<54CF5EF3.20102@oracle.com>
Message-ID: <54CFE38D.30400@oracle.com>

On 02/02/2015 11:26, Chris Hegarty wrote:
> I agree with Alan, addURLStreamHandlerFactory is probably an 
> attractive nuisance. It is not strictly necessary to achieve the goal 
> here; replace the problematic ( with modules ) system property with a 
> service lookup.
>
> For now, I'd like to move this issue forward without the additional 
> new public method. We can have deploy use setURLSHF(), and document 
> the compatibility issue if applets/Webstart apps also try to set a 
> factory. We can revisit this later in 9, if it becomes an issue.
>
> Updated specdiff:
>   http://cr.openjdk.java.net/~chegar/8064924/02/specdiff/
>
> I this revision, I omitted the implementation changes, so we can agree 
> the spec changes first. They are much simpler now.
I'm happy with this approach. One outstanding point from the discussion 
is whether the URLStreamHandlerFactory implementation will need to be 
granted RuntimePermission("setFactory"), if so then this will need to go 
into the javadoc.

-Alan.


From martinrb at google.com  Mon Feb  2 21:06:07 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 2 Feb 2015 13:06:07 -0800
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <54CFE064.70400@Oracle.com>
References: <54CBAA39.3050004@Oracle.com> <54CBF7DB.9000909@oracle.com>
	<54CBFC10.9080502@Oracle.com>
	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>
	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>
	<54CD4305.4080607@oracle.com>
	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>
	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>
	<54CF7D1F.6050101@Oracle.com>
	<CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>
	<54CFE064.70400@Oracle.com>
Message-ID: <CA+kOe0-zPJRpGEa0zXy6_bHgwNcnFWuSc1fbbxsc7-nc6SUjAg@mail.gmail.com>

On Mon, Feb 2, 2015 at 12:39 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> If those platforms change their implementation from not supported ever to
> maybe-sometimes
> under the right conditions then they would supply an implementation that
> reports
> failures using IOException.  In some cases, policy choices should be
> reflected perhaps
> in SecurityException rather than IOExceptions.
>
>
The historic spec allows for both SecurityException and IOException (but
not UOE).
Locked-down systems typically (but not necessarily) have a SecurityManager
that helps enforce the restrictions and so SecurityException seems vaguely
appropriate.


> The points raised imply that there are use cases that take advantage of
> the vagaries
> of the current under specified Process.
>

Creating subclasses of IOException for use by Process seems reasonable, but
too little, too late...
It's hard to get right because everything is grey and nuanced, so coming up
with good specs for useful subclasses is hard.
And in the end, will not really help users.

All of this activity won't really help users of Process in any case.  You
can't create a Process in a useful way without knowledge of the OS you're
running on.  People now do things like

if (new File("/bin/bash").isExecutable()) ...

and that will continue to be the only way to use Process in a "portable"
way.


From kumar.x.srinivasan at oracle.com  Tue Feb  3 00:38:48 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 02 Feb 2015 16:38:48 -0800
Subject: RFR: JDK-8068033: Fix Java Launcher for splash screen.
Message-ID: <54D01898.5060900@oracle.com>

Hi,

Appreciate a review of this fix for JNI correctness when dealing with 
Splash Screen
on MacOSX.

http://cr.openjdk.java.net/~ksrini/8068033/webrev.0/

Sergey, I think you took over from Anthony Petrov for SplashScreen, if
not please have someone in your team look it over.

Thanks
Kumar



From mandy.chung at oracle.com  Tue Feb  3 00:44:27 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 02 Feb 2015 16:44:27 -0800
Subject: RFR: JDK-8068033: Fix Java Launcher for splash screen.
In-Reply-To: <54D01898.5060900@oracle.com>
References: <54D01898.5060900@oracle.com>
Message-ID: <54D019EB.3020700@oracle.com>

Looks fine to me.
Mandy

On 2/2/2015 4:38 PM, Kumar Srinivasan wrote:
> Hi,
>
> Appreciate a review of this fix for JNI correctness when dealing with 
> Splash Screen
> on MacOSX.
>
> http://cr.openjdk.java.net/~ksrini/8068033/webrev.0/
>
> Sergey, I think you took over from Anthony Petrov for SplashScreen, if
> not please have someone in your team look it over.
>
> Thanks
> Kumar
>



From ydwchina at gmail.com  Tue Feb  3 07:42:19 2015
From: ydwchina at gmail.com (deven you)
Date: Tue, 3 Feb 2015 15:42:19 +0800
Subject: FilePermission Canonical path optimization
In-Reply-To: <5491CCE0.5050501@oracle.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
	<5491CCE0.5050501@oracle.com>
Message-ID: <CADsbJL=FLpZouS3J-taphoyudUXo1WGtrSfakU5Z9+b=V1kZRQ@mail.gmail.com>

Hi Sean,

The performance degradation was reported by creating an object with always
getting its canonical path and there is no degradation heard after we made
the lazy load  patch for the canonical path.

I have asked related people to give me an env to create this problem so
that I can take a close look how the application uses FilePermissions and
may report my analysis later.

However, as far as I know at present, lazy loading the canonical path
should be a relative better solution:

1. fast set up time
2. at run time, only necessary, the canonical path will be retrieved, the
best case is no canonical path used at all and the worst case is only take
almost the same effort as loading it at start up time.
3. According to FilePermissionCollection, this is also true, the implies
method won't need to iterator the whole set of permissions, it will return
as soon as a proper permission found.

Therefore, from general situation, I think this patch makes sense.

To Peter,

Even with your approach to change 'cpath' 'directory' and 'recursive' to
volatile and prepare their orders so that "directory" and "recursive"
first, "cpath" last, there is still some problem in the pattern in equals()
and impliesIgnoreMask():

if (cpath == null) initCpathDirectoryAndRecursive();
... use 'cpath' or ''directory' or 'recursive' ...

cpath could be null but initCpathDirectoryAndRecursive may be already
running in another thread therefore initCpathDirectoryAndRecursive might be
invoked twice.

To solve this problem, based on your volatile solution, but still make
initCpathDirectoryAndRecursive as synchronized method and add below
statement at the beginning of this method:
if (cpath != null) {
    return;
}

Even if there is another thread running, initCpathDirecotryAndRecursive()
will wait the completion of first thread and check cpath value and then
return. This solution ensures the initiating logic is run just once.

Thanks a lot!


Thanks a lot!

2014-12-18 2:35 GMT+08:00 Sean Mullan <sean.mullan at oracle.com>:

> Hi,
>
> Can you elaborate more on the performance degradation that you are seeing
> at startup? Are you seeing this when you are running with or without a
> SecurityManager? If without a SecurityManager, can you provide some code
> paths/examples? As far as I can see, with the proposed fix you are moving
> the performance hit to runtime, and it will be triggered the first time a
> FilePermission check is made, and at worst case it may need to canonicalize
> all the FilePermissions in the FilePermissionCollection. Also, with the
> latest proposed fix you are potentially making performance worse by
> introducing synchronized blocks (which as Peter noted, still have some race
> conditions). I can understand why you want to improve application startup,
> but I want to make sure I understand the use case(s) a little better first.
>
> Thanks,
> Sean


From peter.levart at gmail.com  Tue Feb  3 08:04:04 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 03 Feb 2015 09:04:04 +0100
Subject: FilePermission Canonical path optimization
In-Reply-To: <CADsbJL=FLpZouS3J-taphoyudUXo1WGtrSfakU5Z9+b=V1kZRQ@mail.gmail.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>	<5491CCE0.5050501@oracle.com>
	<CADsbJL=FLpZouS3J-taphoyudUXo1WGtrSfakU5Z9+b=V1kZRQ@mail.gmail.com>
Message-ID: <54D080F4.7080303@gmail.com>

Hi Deven,

On 02/03/2015 08:42 AM, deven you wrote:
> Hi Sean,
>
> The performance degradation was reported by creating an object with always
> getting its canonical path and there is no degradation heard after we made
> the lazy load  patch for the canonical path.
>
> I have asked related people to give me an env to create this problem so
> that I can take a close look how the application uses FilePermissions and
> may report my analysis later.
>
> However, as far as I know at present, lazy loading the canonical path
> should be a relative better solution:
>
> 1. fast set up time
> 2. at run time, only necessary, the canonical path will be retrieved, the
> best case is no canonical path used at all and the worst case is only take
> almost the same effort as loading it at start up time.
> 3. According to FilePermissionCollection, this is also true, the implies
> method won't need to iterator the whole set of permissions, it will return
> as soon as a proper permission found.
>
> Therefore, from general situation, I think this patch makes sense.
>
> To Peter,
>
> Even with your approach to change 'cpath' 'directory' and 'recursive' to
> volatile and prepare their orders so that "directory" and "recursive"
> first, "cpath" last, there is still some problem in the pattern in equals()
> and impliesIgnoreMask():
>
> if (cpath == null) initCpathDirectoryAndRecursive();
> ... use 'cpath' or ''directory' or 'recursive' ...
>
> cpath could be null but initCpathDirectoryAndRecursive may be already
> running in another thread therefore initCpathDirectoryAndRecursive might be
> invoked twice.

Good catch! Usually such redundant idempotent initialization is harmless 
- but it *must* be idempotent. Since it involves canonical path 
computation on the filesystem and the filesystem is a mutable "object", 
this is not guaranteed.

>
> To solve this problem, based on your volatile solution, but still make
> initCpathDirectoryAndRecursive as synchronized method and add below
> statement at the beginning of this method:
> if (cpath != null) {
>      return;
> }
>
> Even if there is another thread running, initCpathDirecotryAndRecursive()
> will wait the completion of first thread and check cpath value and then
> return. This solution ensures the initiating logic is run just once.

Right, double-checked locking (with use of volatiles and correct order 
of initialization) would be the best solution here.

Regards, Peter

>
> Thanks a lot!
>
>
> Thanks a lot!
>
> 2014-12-18 2:35 GMT+08:00 Sean Mullan <sean.mullan at oracle.com>:
>
>> Hi,
>>
>> Can you elaborate more on the performance degradation that you are seeing
>> at startup? Are you seeing this when you are running with or without a
>> SecurityManager? If without a SecurityManager, can you provide some code
>> paths/examples? As far as I can see, with the proposed fix you are moving
>> the performance hit to runtime, and it will be triggered the first time a
>> FilePermission check is made, and at worst case it may need to canonicalize
>> all the FilePermissions in the FilePermissionCollection. Also, with the
>> latest proposed fix you are potentially making performance worse by
>> introducing synchronized blocks (which as Peter noted, still have some race
>> conditions). I can understand why you want to improve application startup,
>> but I want to make sure I understand the use case(s) a little better first.
>>
>> Thanks,
>> Sean



From Alan.Bateman at oracle.com  Tue Feb  3 08:40:55 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 03 Feb 2015 08:40:55 +0000
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <CA+kOe0-zPJRpGEa0zXy6_bHgwNcnFWuSc1fbbxsc7-nc6SUjAg@mail.gmail.com>
References: <54CBAA39.3050004@Oracle.com>
	<54CBF7DB.9000909@oracle.com>	<54CBFC10.9080502@Oracle.com>	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>	<54CD4305.4080607@oracle.com>	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>	<54CF7D1F.6050101@Oracle.com>	<CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>	<54CFE064.70400@Oracle.com>
	<CA+kOe0-zPJRpGEa0zXy6_bHgwNcnFWuSc1fbbxsc7-nc6SUjAg@mail.gmail.com>
Message-ID: <54D08997.9020300@oracle.com>

On 02/02/2015 21:06, Martin Buchholz wrote:
> :
> The historic spec allows for both SecurityException and IOException (but
> not UOE).
> Locked-down systems typically (but not necessarily) have a SecurityManager
> that helps enforce the restrictions and so SecurityException seems vaguely
> appropriate.
>
There are a small number of places where SecurityException is thrown 
when not running with a security manager (defineClass, package sealing) 
but it can be confusing for developers to get this exception when there 
isn't a Java security manager. So I don't think we should be using it here.

-Alan


From staffan.larsen at oracle.com  Tue Feb  3 09:15:24 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 3 Feb 2015 10:15:24 +0100
Subject: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
Message-ID: <B5F7A180-60F2-4B08-87B1-A8479D8AC43E@oracle.com>

Hi,

Please review this patch for hiding the lambda proxy frame in stack traces:

bug: https://bugs.openjdk.java.net/browse/JDK-8025636 <https://bugs.openjdk.java.net/browse/JDK-8025636>
webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.00/ <http://cr.openjdk.java.net/~sla/8025636/webrev.00/>

This is a straightforward addition of the LambdaForm$Hidden annotation to the generated methods. What is surprising is that this works even if LambdaForm$Hidden is a package-private class in java.lang.invoke and thus not accessible from most of the generated classes. There is some discussion of and answers to this in the bug, but essentially this works because the annotation class is never resolved and the code in Hotspot that looks for the annotation amounts to nothing more than string comparisons.

Hidden stack frames can be shown by running with ?-XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames?.

For an example of what this patch does, consider this code:

       Runnable r = () -> { throw new RuntimeException(); };
       r.run();

Previously, this would output:

    java.lang.RuntimeException
	at pkg.Foo.lambda$main$0(Foo.java:5)
	at pkg.Foo$$Lambda$1/2001112025.run(<Unknown>:1000000)
	at pkg.Foo.main(Foo.java:15)

With the patch it looks like this:

    java.lang.RuntimeException
	at pkg.Foo.lambda$main$0(Foo.java:5)
	at pkg.Foo.main(Foo.java:15)


Thanks,
/Staffan



From forax at univ-mlv.fr  Tue Feb  3 09:37:28 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 03 Feb 2015 10:37:28 +0100
Subject: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
In-Reply-To: <B5F7A180-60F2-4B08-87B1-A8479D8AC43E@oracle.com>
References: <B5F7A180-60F2-4B08-87B1-A8479D8AC43E@oracle.com>
Message-ID: <3E4DB041-7B63-421A-BFF3-A61957E51003@univ-mlv.fr>

Looks good for me.

R?mi 

Le 3 f?vrier 2015 10:15:24 CET, Staffan Larsen <staffan.larsen at oracle.com> a ?crit :
>Hi,
>
>Please review this patch for hiding the lambda proxy frame in stack
>traces:
>
>bug: https://bugs.openjdk.java.net/browse/JDK-8025636
><https://bugs.openjdk.java.net/browse/JDK-8025636>
>webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.00/
><http://cr.openjdk.java.net/~sla/8025636/webrev.00/>
>
>This is a straightforward addition of the LambdaForm$Hidden annotation
>to the generated methods. What is surprising is that this works even if
>LambdaForm$Hidden is a package-private class in java.lang.invoke and
>thus not accessible from most of the generated classes. There is some
>discussion of and answers to this in the bug, but essentially this
>works because the annotation class is never resolved and the code in
>Hotspot that looks for the annotation amounts to nothing more than
>string comparisons.
>
>Hidden stack frames can be shown by running with
>?-XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames?.
>
>For an example of what this patch does, consider this code:
>
>       Runnable r = () -> { throw new RuntimeException(); };
>       r.run();
>
>Previously, this would output:
>
>    java.lang.RuntimeException
>	at pkg.Foo.lambda$main$0(Foo.java:5)
>	at pkg.Foo$$Lambda$1/2001112025.run(<Unknown>:1000000)
>	at pkg.Foo.main(Foo.java:15)
>
>With the patch it looks like this:
>
>    java.lang.RuntimeException
>	at pkg.Foo.lambda$main$0(Foo.java:5)
>	at pkg.Foo.main(Foo.java:15)
>
>
>Thanks,
>/Staffan

-- 
Envoy? de mon t?l?phone Android avec K-9 Mail. Excusez la bri?vet?.


From paul.sandoz at oracle.com  Tue Feb  3 13:48:19 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 3 Feb 2015 14:48:19 +0100
Subject: RFR 8071600: Add a flat-mapping collector
Message-ID: <517DF5B9-E3C5-4CD9-A04A-AC06EBD61517@oracle.com>

Hi,

http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping/webrev/

This patch adds a new flat mapping collector to Collectors. This can be useful if one needs to map 0 or more items into a downstream collector.

A CCC will be filed.

A following patch, which i plan to fold into the above patch, performs some renames on the collectors test to be consistent with the current naming: 

http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping-test-rename/webrev/

Thanks,
Paul.


From Sergey.Bylokhov at oracle.com  Tue Feb  3 13:52:19 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 03 Feb 2015 16:52:19 +0300
Subject: RFR: JDK-8068033: Fix Java Launcher for splash screen.
In-Reply-To: <54D01898.5060900@oracle.com>
References: <54D01898.5060900@oracle.com>
Message-ID: <54D0D293.5050103@oracle.com>

Hello,
The looks good.

On 03.02.2015 3:38, Kumar Srinivasan wrote:
> Hi,
>
> Appreciate a review of this fix for JNI correctness when dealing with 
> Splash Screen
> on MacOSX.
>
> http://cr.openjdk.java.net/~ksrini/8068033/webrev.0/
>
> Sergey, I think you took over from Anthony Petrov for SplashScreen, if
> not please have someone in your team look it over.
>
> Thanks
> Kumar
>


-- 
Best regards, Sergey.



From chris.hegarty at oracle.com  Tue Feb  3 14:14:08 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 3 Feb 2015 14:14:08 +0000
Subject: Explicit Serialization API and Security
In-Reply-To: <54CF5C86.8040505@zeus.net.au>
References: <54B0CE06.2020408@zeus.net.au>
	<54B3EEC5.5040805@oracle.com>		<1421144693.7530.20.camel@Nokia-N900>
	<54B654F6.6060207@oracle.com>	<1421240334.8856.17.camel@Nokia-N900>	<54BEB91A.4020603@gmail.com>
	<54BFD374.5080803@oracle.com>	<54C00B66.5090302@zeus.net.au>
	<54C01D71.9010901@redhat.com> <54C25DB0.4080207@oracle.com>
	<54C9F888.2040005@zeus.net.au> <54C9FBE1.1070702@zeus.net.au>
	<54CA0027.2000104@zeus.net.au> <54CA0707.5010005@zeus.net.au>
	<54CA0B6D.2050105@zeus.net.au> <54CA192A.1060404@zeus.net.au>
	<54CA2581.9060906@zeus.net.au> <54CF5C86.8040505@zeus.net.au>
Message-ID: <C8C89B55-C26A-4682-B906-A95378A0599E@oracle.com>

Hi Peter,

On 2 Feb 2015, at 11:16, Peter Firmstone <peter.firmstone at zeus.net.au> wrote:

> As mentioned I've been experimenting with an invariant validating ObjectInputStream, that's backward and forward compatible with Java's Object Serialization stream protocol.
> 
> No changes have been made to ObjectOutputStream.
> 
> ObjectInputStream has been overridden and reading from the stream has been completely reimplemented.
> 
> Classes are still required to implement Serializable, however readObject methods are not called and fields are not set reflectively after construction.
> 
> After considering all possibilities, I still find myself favouring constructors.

With the use of constructors:
 1) there is no way to reconstruct objects with truly private state
     ( not exposed through the constructor ), 
 2) there is no way to enforce constraints on mutable state which
     may have constraints enforced through the API
 3) Serializable classes are required to expose a public/protected
     single args GetArg constructor, for subclasses to call ( this is
     an issue if you do not control the whole hierarchy )
 4) Subclasses need to make assumptions about abstract
     superclasses, so they can create ?fake? instances for checking

See my, not factually correct, example below [*]

> Definition of "Cumbersome":
>    Slow or complicated and therefore inefficient.

With larger hierarchies, and abstract classes, it becomes more difficult [*].

> During implementation, I've found that static invarient check methods are often shared with other constructors.

Yes, they can be somewhat, but will most likely throw different exceptions [*].

> If another constructor already has a static invariant checking method, you only need call that constructor.
> 
> Performance wise, constructors significantly outperform setting every field using reflection, the more fields an Object has, the greater the performance benefit.

Interesting observation.

> My experience is using constructors is often easier to understand than readObject methods.

With larger hierarchies it comes complicated very quickly [*], and easy to miss a call to a check method. That said, I agree readObject methods can be hard to understand sometimes, but they can enforce invariants on truly private, or mutable, state.

> Because constructors can be chained, I can perform final freezes in one constructor, then publish safely using another, existing readObject methods cannot provide this functionality.  If a final freeze occurs after the readObject method terminates, there is no way to fix existing code that uses unsafe publication.

I think we can make the existing serialization mechanism much better when it comes to the setting of finals. Peter Levart and I are already looking at this, and hopefully will come up with a proposal soon.

> See that attached example, this is actual production code (with the addition of @AtomicSerial), Java's RMI also has a DGC implementation.  In this example using standard Serialization, because a final freeze occurs after readObject exits, the implementation uses unsafe publication, all guarantees are off.

Yes, just like the construction of any object, unsafe publication is... well unsafe.

> The annotations I've used are:
> @AtomicSerial - indicates serial constructor is present.
> @ReadInput - provides access to a ReadObject implementation for direct interaction with the stream, prior to object construction, provided for backward compatiblility.
> 
> However the existing readObject alternative is all too often:
>    Insecure and unsafely published.
> 
> The real question:
> 
> Is secure Serialization worth the additional work?

Yes, I think it is worth exploring the possibility.  We have already discussed a number of ideas/alternatives in this email thread, and work is progressing on bringing a number of them to fruition.

> To those who would value it, I think the answer will be yes, to those that don't, perhaps not?
> 
> Regards,
> 
> Peter.

-Chris.


[*]

abstract class Animal implements Serializable {
    private final String category;
    // serializable mutable state
    private long age;
    // serializable state not passed as an arg to the constructor
    private final Object ageLock = new Object();
    protected final boolean hasLegs;

    private static Void check(String category) {
        requireNonNull(category);
        return null;
    }

    public Animal(String category) {
        this(check(category), category);
    }

    private Animal(Void check, String category) {
        this.category = category;
        hasLegs = hasLegs();
    }

    private static Void checkSerial(String category) throws InvalidObjectException {
        try {
            check(category);
        } catch (Exception x) {
            InvalidObjectException e = new InvalidObjectException("Invalid Object");
            e.addSuppressed(x);
            throw e;
        }
        return null;
    }

    protected Animal(GetArg arg) throws InvalidObjectException {
        this(checkSerial(arg.get("category", null)), arg.get("category", null));
    }

    void setAge(long age) {
        if (age < 0)
            throw new IllegalArgumentException();
        synchronized(ageLock) { this.age = age; }
    }
    long getAge() { synchronized(ageLock) { return age; } }

    abstract boolean hasLegs();
}

abstract class Mammal extends Animal implements Serializable {
    private final int numberOfLegs;

    private static Void check(int numberOfLegs) {
        if (numberOfLegs <= 0)   // All mammals must have legs!
            throw new IllegalArgumentException("Invalid number of legs");
        return null;
    }

    public Mammal(String category, int numberOfLegs) {
        this(check(numberOfLegs), category, numberOfLegs);
    }

    private Mammal(Void check, String category, int numberOfLegs) {
        super(category);
        this.numberOfLegs = numberOfLegs;
        assert hasLegs() == hasLegs;
    }

    private static Void checkSerial(GetArg arg) throws InvalidObjectException {
        Animal animal = new Animal(arg) {
            @Override boolean hasLegs() { return false; /* or true, how what this will impact? * */ }
        };
        try {
            check(arg.get("numberOfLegs", -1));
        } catch (Exception x) {
            InvalidObjectException e = new InvalidObjectException("Invalid Object");
            e.addSuppressed(x);
            throw e;
        }
        return null;
    }

    protected Mammal(GetArg arg) throws InvalidObjectException {
        this(checkSerial(arg), arg.get("category", null), arg.get("numberOfLegs", -1));
    }

    @Override boolean hasLegs() { return true; }
    
    abstract boolean hasFur();
}

class Dog extends Mammal implements Serializable {
    private final String breed;

    private static Void check(String breed) {
        requireNonNull(breed); return null;
    }

    public Dog(String breed) {
        this(check(breed), breed);
    }

    private Dog(Void check, String breed) {
        super("canine", 4);
        this.breed = breed;
    }

    private static Void checkSerial(GetArg arg) throws InvalidObjectException {
        Mammal mammal = new Mammal(arg) {
            @Override boolean hasLegs() { return false; /* or true, how what this will impact? * */ }
            @Override boolean hasFur() { return false; /* or true, how what this will impact? * */ }
        };
        try {
            check(arg.get("breed", null));
        } catch (Exception x) {
            InvalidObjectException e = new InvalidObjectException("Invalid Object");
            e.addSuppressed(x);
            throw e;
        }
        return null;
    }

    protected Dog(GetArg arg) throws IOException {
        this(checkSerial(arg), arg.get("breed", null));
    }

    @Override boolean hasLegs() { return true; }
    @Override boolean hasFur() { return true; }
}



From chris.hegarty at oracle.com  Tue Feb  3 14:25:33 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 3 Feb 2015 14:25:33 +0000
Subject: RFR 8072030 Race condition in ThenComposeExceptionTest.java
In-Reply-To: <E07B8B9A-E699-421E-8681-A1C40E839132@oracle.com>
References: <69F5938F-EDAE-468D-829A-2AA39A776AC4@oracle.com>
	<54CF545A.3060304@oracle.com>
	<E07B8B9A-E699-421E-8681-A1C40E839132@oracle.com>
Message-ID: <0C51E5F5-6076-4680-939A-CDAAE75B6703@oracle.com>

On 2 Feb 2015, at 11:36, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> ...
>> This was a nasty race. In fact there is no guarantee that the CF, that sets the AtomicReference would even complete, without join/get, right ?
>> 
> 
> I think the async completion of the thenComposed task will trigger (in the same thread) the completion of the dependent whenCompleted task, such that one could use a count down latch (which would be an odd thing to use).

Ah ok. I was thinking of the chain of CF?s as a stream, where you need some action to pull the result through.  I think it depends on the sequence of async and same thread stages, maybe not, I?d need to look into the details a little more.

-Chris.

> Paul.



From peter.firmstone at zeus.net.au  Tue Feb  3 15:13:34 2015
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Wed, 04 Feb 2015 01:13:34 +1000
Subject: Explicit Serialization API and Security
In-Reply-To: <C8C89B55-C26A-4682-B906-A95378A0599E@oracle.com>
References: <54B0CE06.2020408@zeus.net.au>
	<54B3EEC5.5040805@oracle.com>		<1421144693.7530.20.camel@Nokia-N900>
	<54B654F6.6060207@oracle.com>	<1421240334.8856.17.camel@Nokia-N900>	<54BEB91A.4020603@gmail.com>
	<54BFD374.5080803@oracle.com>	<54C00B66.5090302@zeus.net.au>
	<54C01D71.9010901@redhat.com> <54C25DB0.4080207@oracle.com>
	<54C9F888.2040005@zeus.net.au> <54C9FBE1.1070702@zeus.net.au>
	<54CA0027.2000104@zeus.net.au> <54CA0707.5010005@zeus.net.au>
	<54CA0B6D.2050105@zeus.net.au> <54CA192A.1060404@zeus.net.au>
	<54CA2581.9060906@zeus.net.au> <54CF5C86.8040505@zeus.net.au>
	<C8C89B55-C26A-4682-B906-A95378A0599E@oracle.com>
Message-ID: <54D0E59E.2070602@zeus.net.au>

Thanks Chris,

see below...

On 4/02/2015 12:14 AM, Chris Hegarty wrote:
> Hi Peter,
>
> On 2 Feb 2015, at 11:16, Peter Firmstone<peter.firmstone at zeus.net.au>  wrote:
>
>> As mentioned I've been experimenting with an invariant validating ObjectInputStream, that's backward and forward compatible with Java's Object Serialization stream protocol.
>>
>> No changes have been made to ObjectOutputStream.
>>
>> ObjectInputStream has been overridden and reading from the stream has been completely reimplemented.
>>
>> Classes are still required to implement Serializable, however readObject methods are not called and fields are not set reflectively after construction.
>>
>> After considering all possibilities, I still find myself favouring constructors.
> With the use of constructors:
>   1) there is no way to reconstruct objects with truly private state
>       ( not exposed through the constructor ),

We can with caller sensitive methods, child classes don't have much 
choice other than to call a constructor.  Child classes don't have 
access to super class fields or state, unless via public api by creating 
an object instance.  Internal state is not exposed, the superclass can 
copy mutable state to ensure the child class cannot gain a reference 
using a modified stream.

Implementation of caller sensitivity:

/**
      * Dummy security manager providing access to getClassContext method.
      */
     private static class ClassContextAccess extends SecurityManager {
     /**
      * Returns caller's caller class.
      */
     Class caller() {
         return getClassContext()[2];
     }
     }

     private static final ClassContextAccess context
         = AccessController.doPrivileged(
     new PrivilegedAction<ClassContextAccess>(){

     @Override
     public ClassContextAccess run() {
         return new ClassContextAccess();
     }

     });

     private static class GetArgImpl extends AtomicSerial.GetArg {
     final Map<Class,GetField> classFields;
     final Map<Class,ReadObject> readers;
     final ObjectInput in;

     GetArgImpl(Map<Class,GetField> args, Map<Class,ReadObject> readers, 
ObjectInput in){
         super(false); // Avoids permission check.
         classFields = args;
         this.readers = readers;
         this.in = in;
     }

     @Override
     public ObjectStreamClass getObjectStreamClass() {
         return classFields.get(context.caller()).getObjectStreamClass();
     }

     @Override
     public boolean defaulted(String name) throws IOException {
         return classFields.get(context.caller()).defaulted(name);
     }

     @Override
     public boolean get(String name, boolean val) throws IOException {
         return classFields.get(context.caller()).get(name, val);
     }

     @Override
     public byte get(String name, byte val) throws IOException {
         return classFields.get(context.caller()).get(name, val);
     }

     @Override
     public char get(String name, char val) throws IOException {
         return classFields.get(context.caller()).get(name, val);
     }

     @Override
     public short get(String name, short val) throws IOException {
         return classFields.get(context.caller()).get(name, val);
     }

     @Override
     public int get(String name, int val) throws IOException {
         return classFields.get(context.caller()).get(name, val);
     }

     @Override
     public long get(String name, long val) throws IOException {
         return classFields.get(context.caller()).get(name, val);
     }

     @Override
     public float get(String name, float val) throws IOException {
         return classFields.get(context.caller()).get(name, val);
     }

     @Override
     public double get(String name, double val) throws IOException {
         return classFields.get(context.caller()).get(name, val);
     }

     @Override
     public Object get(String name, Object val) throws IOException {
         return classFields.get(context.caller()).get(name, val);
     }

     @Override
     public Collection getObjectStreamContext() {
         if (in instanceof ObjectStreamContext)
         return ((ObjectStreamContext)in).getObjectStreamContext();
         return Collections.emptyList();
     }

     @Override
     public Class[] serialClasses() {
         return classFields.keySet().toArray(new Class[classFields.size()]);
     }

     @Override
     public ReadObject getReader() { //TODO capture any Exceptions and 
rethrow here.
         Class c = context.caller();
         return readers.get(context.caller());
     }

     }


>
>   2) there is no way to enforce constraints on mutable state which
>       may have constraints enforced through the API
Can you elaborate for me please?

>   3) Serializable classes are required to expose a public/protected
>       single args GetArg constructor, for subclasses to call ( this is
>       an issue if you do not control the whole hierarchy )
Only if these classes are intended to be public api and subclassed.  A 
method serialClasses() has been provided to allow implementors to check 
the class hierarchy.  Otherwise yes, you must provide a public, default 
or protected constructor.  At present protected constructor's are not 
called by the atomic serial implementation.

To instantiate a GetArg instance requires 
SerializablePermission("enableSubclassImplementation").

The subclass can't tamper with GetArg state without permission, it can 
only call this constructor using a null reference or GetArg instance 
passed to it's constructor, otherwise it can call another constructor.  
For example it might create a superclass instance, call some getters , 
then pass these references to another superclass constructor instead of 
GetArg.

>   4) Subclasses need to make assumptions about abstract
>       superclasses, so they can create ?fake? instances for checking
>
> See my, not factually correct, example below [*]

Yes, that's true, how well this works depends on how the api is designed 
or expressed.  I find this is often much simpler in practise, after 
implementing it on a number of existing classes.
>> Definition of "Cumbersome":
>>     Slow or complicated and therefore inefficient.
> With larger hierarchies, and abstract classes, it becomes more difficult [*].

Less so if you only rely on proper encapsulation and public api.   
Duplicate method calls and invariant checks don't hurt performance.


>> During implementation, I've found that static invarient check methods are often shared with other constructors.
> Yes, they can be somewhat, but will most likely throw different exceptions [*].

Yes, I typically catch these exceptions and throw a 
IllegalObjectException with the original exception as the cause.

I see you've picked that up too :)

>> If another constructor already has a static invariant checking method, you only need call that constructor.
>>
>> Performance wise, constructors significantly outperform setting every field using reflection, the more fields an Object has, the greater the performance benefit.
> Interesting observation.
>
>> My experience is using constructors is often easier to understand than readObject methods.
> With larger hierarchies it comes complicated very quickly [*], and easy to miss a call to a check method. That said, I agree readObject methods can be hard to understand sometimes, but they can enforce invariants on truly private, or mutable, state.

Constructors provide wider and more flexible capabilities.   Invariants 
are much more difficult to enforce with readObject() methods, and it 
isn't always possible to enforce them after the object is created.

>> Because constructors can be chained, I can perform final freezes in one constructor, then publish safely using another, existing readObject methods cannot provide this functionality.  If a final freeze occurs after the readObject method terminates, there is no way to fix existing code that uses unsafe publication.
> I think we can make the existing serialization mechanism much better when it comes to the setting of finals. Peter Levart and I are already looking at this, and hopefully will come up with a proposal soon.

Yes any progress on this front is good, however constructors do provide 
more flexibility and wider scope.

>> See that attached example, this is actual production code (with the addition of @AtomicSerial), Java's RMI also has a DGC implementation.  In this example using standard Serialization, because a final freeze occurs after readObject exits, the implementation uses unsafe publication, all guarantees are off.
> Yes, just like the construction of any object, unsafe publication is... well unsafe.

Unfortunately we can't chain readObejct() methods, so can't invoke final 
freezes (like we can with constructors) to allow safe publication from 
within readObject().  Although I think it's possible in most cases to 
use a validator after the object graph has been reconstructed for 
publication, but requries additional knowledge.  I think developers are 
more familiar with constructors, final freeze behaviour and safe 
publication.

Another problem with readObject() methods arises if you need to modify 
your serial form, reflection is required to set final fields, which 
requires privileges, which places the code at risk of privilege 
escallation due to programmer errror.

>> The annotations I've used are:
>> @AtomicSerial - indicates serial constructor is present.
>> @ReadInput - provides access to a ReadObject implementation for direct interaction with the stream, prior to object construction, provided for backward compatiblility.
>>
>> However the existing readObject alternative is all too often:
>>     Insecure and unsafely published.
>>
>> The real question:
>>
>> Is secure Serialization worth the additional work?
> Yes, I think it is worth exploring the possibility.  We have already discussed a number of ideas/alternatives in this email thread, and work is progressing on bringing a number of them to fruition.

Glad to see there's interest.

>> To those who would value it, I think the answer will be yes, to those that don't, perhaps not?
>>
>> Regards,
>>
>> Peter.
> -Chris.
>
>
> [*]
>
> abstract class Animal implements Serializable {
>      private final String category;
>      // serializable mutable state
>      private long age;
>      // serializable state not passed as an arg to the constructor
>      private final Object ageLock = new Object();
>      protected final boolean hasLegs;
>
>      private static Void check(String category) {
>          requireNonNull(category);
>          return null;
>      }
>
>      public Animal(String category) {
>          this(check(category), category);
>      }
>
>      private Animal(Void check, String category) {
>          this.category = category;
>          hasLegs = hasLegs();
>      }
>
>      private static Void checkSerial(String category) throws InvalidObjectException {
>          try {
>              check(category);
>          } catch (Exception x) {
>              InvalidObjectException e = new InvalidObjectException("Invalid Object");
>              e.addSuppressed(x);
>              throw e;
>          }
>          return null;
>      }
>
>      protected Animal(GetArg arg) throws InvalidObjectException {
>          this(checkSerial(arg.get("category", null)), arg.get("category", null));
>      }
>
>      void setAge(long age) {
>          if (age<  0)
>              throw new IllegalArgumentException();
>          synchronized(ageLock) { this.age = age; }
>      }
>      long getAge() { synchronized(ageLock) { return age; } }
>
>      abstract boolean hasLegs();
> }
>
> abstract class Mammal extends Animal implements Serializable {
>      private final int numberOfLegs;
>
>      private static Void check(int numberOfLegs) {
>          if (numberOfLegs<= 0)   // All mammals must have legs!
>              throw new IllegalArgumentException("Invalid number of legs");
>          return null;
>      }
>
>      public Mammal(String category, int numberOfLegs) {
>          this(check(numberOfLegs), category, numberOfLegs);
>      }
>
>      private Mammal(Void check, String category, int numberOfLegs) {
>          super(category);
>          this.numberOfLegs = numberOfLegs;
>          assert hasLegs() == hasLegs;
>      }
>
>      private static Void checkSerial(GetArg arg) throws InvalidObjectException {
>          Animal animal = new Animal(arg) {
>              @Override boolean hasLegs() { return false; /* or true, how what this will impact? * */ }
>          };
>          try {
>              check(arg.get("numberOfLegs", -1));
>          } catch (Exception x) {
>              InvalidObjectException e = new InvalidObjectException("Invalid Object");
>              e.addSuppressed(x);
>              throw e;
>          }
>          return null;
>      }
>
>      protected Mammal(GetArg arg) throws InvalidObjectException {
>          this(checkSerial(arg), arg.get("category", null), arg.get("numberOfLegs", -1));
>      }
>
>      @Override boolean hasLegs() { return true; }
>
>      abstract boolean hasFur();
> }
>
> class Dog extends Mammal implements Serializable {
>      private final String breed;
>
>      private static Void check(String breed) {
>          requireNonNull(breed); return null;
>      }
>
>      public Dog(String breed) {
>          this(check(breed), breed);
>      }
>
>      private Dog(Void check, String breed) {
>          super("canine", 4);
>          this.breed = breed;
>      }
>
>      private static Void checkSerial(GetArg arg) throws InvalidObjectException {
>          Mammal mammal = new Mammal(arg) {
>              @Override boolean hasLegs() { return false; /* or true, how what this will impact? * */ }
>              @Override boolean hasFur() { return false; /* or true, how what this will impact? * */ }
>          };
>          try {
>              check(arg.get("breed", null));
>          } catch (Exception x) {
>              InvalidObjectException e = new InvalidObjectException("Invalid Object");
>              e.addSuppressed(x);
>              throw e;
>          }
>          return null;
>      }
>
>      protected Dog(GetArg arg) throws IOException {
>          this(checkSerial(arg), arg.get("breed", null));
>      }
>
>      @Override boolean hasLegs() { return true; }
>      @Override boolean hasFur() { return true; }
> }
>
A rather complex example (the existing validators and constructors are 
production code):

     public MethodDesc(GetArg arg) throws IOException{
         this(checkSerial(
             (String) arg.get("name", null),
             (Class []) arg.get("types", null),
             (InvocationConstraints) arg.get("constraints", null)
         ),
         (String) arg.get("name", null),
         (Class[]) arg.get("types", null),
         (InvocationConstraints) arg.get("constraints", null)
         );
     }

     /**
      * Creates a descriptor that only matches methods with exactly the
      * specified name and parameter types. The constraints can be
      * <code>null</code>, which is treated the same as an empty
      * instance. The array passed to the constructor is neither modified
      * nor retained; subsequent changes to that array have no effect on
      * the instance created.
      *
      * @param name the name of the method
      * @param types the formal parameter types of the method, in declared
      * order
      * @param constraints the constraints, or <code>null</code>
      * @throws NullPointerException if <code>name</code> or
      * <code>types</code> is <code>null</code> or any element of
      * <code>types</code> is <code>null</code>
      * @throws IllegalArgumentException if <code>name</code> is not a
      * syntactically valid method name
      */
     public MethodDesc(String name,
               Class[] types,
               InvocationConstraints constraints)
     {
         this(check(name, types),
         name,
         types,
         constraints
         );
     }

     /**
      * Creates a descriptor that matches all methods with names that
      * equal the specified name or that match the specified pattern,
      * regardless of their parameter types. If the specified name starts
      * with the character '*', then this descriptor matches all methods
      * with names that end with the rest of the specified name. If the
      * specified name ends with the character '*', then this descriptor
      * matches all methods with names that start with the rest of the
      * specified name. Otherwise, this descriptor matches all methods
      * with names that equal the specified name. The constraints can be
      * <code>null</code>, which is treated the same as an empty instance.
      *
      * @param name the name of the method, with a prefix or suffix '*'
      * permitted for pattern matching
      * @param constraints the constraints, or <code>null</code>
      * @throws NullPointerException if <code>name</code> is
      * <code>null</code>
      * @throws IllegalArgumentException if <code>name</code> does not
      * match any syntactically valid method name
      */
     public MethodDesc(String name, InvocationConstraints constraints) {
         this(check(name, null),
         name,
         null,
         constraints
         );
     }

     /**
      * Invariant checks for de-serialization.
      * @param name
      * @param types
      * @param constraints
      * @return
      * @throws InvalidObjectException
      */
     private static boolean checkSerial(
         String name,
         Class[] types,
         InvocationConstraints constraints) throws InvalidObjectException
     {
         if (name == null) {
         if (types != null) {
             throw new InvalidObjectException(
                      "cannot have types with null name");
         }
         } else {
         try {
             return check(name, types);
         } catch (RuntimeException e) {
             rethrow(e);
         }
         }
         if (constraints != null && constraints.isEmpty()) {
         throw new InvalidObjectException(
                          "constraints cannot be empty");
         }
         return true;
     }

     /**
      * Verifies that the name is a syntactically valid method name, or
      * (if types is null) if the name is a syntactically valid method name
      * with a '*' appended or could be constructed from some syntactically
      * valid method name containing more than two characters by replacing
      * the first character of that name with '*', and verifies that none
      * of the elements of types are null.
      */
     private static boolean check(String name, Class[] types) {
         boolean star = types == null;
         int len = name.length();
         if (len == 0) {
         throw new IllegalArgumentException(
                            "method name cannot be empty");
         }
         char c = name.charAt(0);
         if (!Character.isJavaIdentifierStart(c) &&
         !(star && c == '*' && len > 1))
         {
         throw new IllegalArgumentException("invalid method name");
         }
         if (star && c != '*' && name.charAt(len - 1) == '*') {
         len--;
         }
         while (--len >= 1) {
         if (!Character.isJavaIdentifierPart(name.charAt(len))) {
             throw new IllegalArgumentException("invalid method name");
         }
         }
         if (types != null) {
         for (int i = types.length; --i >= 0; ) {
             if (types[i] == null) {
             throw new NullPointerException("class cannot be null");
             }
         }
         }
         return true;
     }


From paul.sandoz at oracle.com  Tue Feb  3 15:38:50 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 3 Feb 2015 16:38:50 +0100
Subject: RFR 8071670: java.util.Optional: please add a way to specify if-else
	behavior
Message-ID: <0A89199D-AFFA-4A90-B76F-D8BFAC75748A@oracle.com>

Hi,

http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071670-Optional-ifPresentOrElse/webrev/

Here is another tweak to Optional (and primitives) that has some weight:

/**
 * If a value is present, perform the given action with the value,
 * otherwise perform the given empty-based action.
 *
 * @param action the action to be performed if a value is present
 * @param emptyAction the empty-based action to be performed if a value is
 * not present
 * @throws NullPointerException if a value is present and {@code action} is
 * null, or a value is not present and {@code emptyAction} is null.
 * @since 1.9
 */
public void ifPresentOrElse(Consumer<? super T> action, Runnable emptyAction) {
    if (value != null) {
        action.accept(value);
    } else {
        emptyAction.run();
    }
}

(In hindsight we should have been consistent and thrown NPEs regardless of the optional state. The exception throwing behaviour is consistent with ifPresent.)

Previously it was kind of awkward if one had two lambdas or method refs handy, one had to do:

  o.ifPresent(v -> ...);
  if (!o.ifPresent()) {
    ...
  }

Or just:

  if (o.ifPresent()) {
    ...
  } else {
     ... 
  }


I also updated the language of the ifPresent methods to be more consistent with Collection/Stream.forEach.

Paul.


From scolebourne at joda.org  Tue Feb  3 15:47:34 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 3 Feb 2015 15:47:34 +0000
Subject: RFR 8071670: java.util.Optional: please add a way to specify
	if-else behavior
In-Reply-To: <0A89199D-AFFA-4A90-B76F-D8BFAC75748A@oracle.com>
References: <0A89199D-AFFA-4A90-B76F-D8BFAC75748A@oracle.com>
Message-ID: <CACzrW9AMjm1porBJWfUm2h5moapSWVjr+MREJ=J9ku1=wubqSA@mail.gmail.com>

Can't say I've used isPresent() much, as map()/flatMap()/orElse() take
care of most use cases.

What is an issue is that the primitive optional classes do not have
ofNullable(), filter(), map() or flatMap(). It seems odd to be adding
an additional new method to the primitive optional classes without
rounding out the missing methods to reach feature parity. I've heard
people complaining about the missing methods on more than one
occasion....

Stephen



On 3 February 2015 at 15:38, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> Hi,
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071670-Optional-ifPresentOrElse/webrev/
>
> Here is another tweak to Optional (and primitives) that has some weight:
>
> /**
>  * If a value is present, perform the given action with the value,
>  * otherwise perform the given empty-based action.
>  *
>  * @param action the action to be performed if a value is present
>  * @param emptyAction the empty-based action to be performed if a value is
>  * not present
>  * @throws NullPointerException if a value is present and {@code action} is
>  * null, or a value is not present and {@code emptyAction} is null.
>  * @since 1.9
>  */
> public void ifPresentOrElse(Consumer<? super T> action, Runnable emptyAction) {
>     if (value != null) {
>         action.accept(value);
>     } else {
>         emptyAction.run();
>     }
> }
>
> (In hindsight we should have been consistent and thrown NPEs regardless of the optional state. The exception throwing behaviour is consistent with ifPresent.)
>
> Previously it was kind of awkward if one had two lambdas or method refs handy, one had to do:
>
>   o.ifPresent(v -> ...);
>   if (!o.ifPresent()) {
>     ...
>   }
>
> Or just:
>
>   if (o.ifPresent()) {
>     ...
>   } else {
>      ...
>   }
>
>
> I also updated the language of the ifPresent methods to be more consistent with Collection/Stream.forEach.
>
> Paul.


From aleksej.efimov at oracle.com  Tue Feb  3 15:59:33 2015
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Tue, 03 Feb 2015 18:59:33 +0300
Subject: [9] RFR: 8072042: (tz) Support tzdata2015a
Message-ID: <54D0F065.9010304@oracle.com>

Hi,

Could I have a review the latest tzdata2015a integration fix to JDK9, 
please. The regression tests run and JPRT testing (jdk_other,jdk_util, 
jdk_text, jdk_time test sets) shows no TZ related JDK9 failures.

Thank you,
Aleksej

Bug link: https://bugs.openjdk.java.net/browse/JDK-8072042
Webrev with changes: http://cr.openjdk.java.net/~aefimov/tzdata/2015a/9/00/
Regression tests executed: test/sun/util/calendar\ 
test/java/util/Calendar\ test/sun/util/resources/TimeZone\ 
test/java/util/TimeZone\ test/java/time\ test/java/util/Formatter


From paul.sandoz at oracle.com  Tue Feb  3 16:07:43 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 3 Feb 2015 17:07:43 +0100
Subject: RFR 8071670: java.util.Optional: please add a way to specify
	if-else behavior
In-Reply-To: <CACzrW9AMjm1porBJWfUm2h5moapSWVjr+MREJ=J9ku1=wubqSA@mail.gmail.com>
References: <0A89199D-AFFA-4A90-B76F-D8BFAC75748A@oracle.com>
	<CACzrW9AMjm1porBJWfUm2h5moapSWVjr+MREJ=J9ku1=wubqSA@mail.gmail.com>
Message-ID: <5FB0173C-E600-4C4D-B330-70DDD90DDD0A@oracle.com>

On Feb 3, 2015, at 4:47 PM, Stephen Colebourne <scolebourne at joda.org> wrote:
> Can't say I've used isPresent() much, as map()/flatMap()/orElse() take
> care of most use cases.
> 

Yes, i suspect terminal action-based processing is less used than value transformation. 


> What is an issue is that the primitive optional classes do not have
> ofNullable(), filter(), map() or flatMap().

I dunno about the first, that would seem a little odd to me.

Note the concept of ifPresent is already on all Optional variants. Same applies to the difficulties encountered with flatMap.


> It seems odd to be adding
> an additional new method to the primitive optional classes without
> rounding out the missing methods to reach feature parity. I've heard
> people complaining about the missing methods on more than one
> occasion....
> 

I recall the discussions around Optional consumed quite a bit of design discussion budget :-) so we tried to keep things to a minimum set.

Do you wanna log an issue for those missing methods?

Paul.


From Roger.Riggs at Oracle.com  Tue Feb  3 16:10:53 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 03 Feb 2015 11:10:53 -0500
Subject: RFR 8/9: 8068278 ArrayIndexOutOfBoundsException instead of
	DateTimeException in j.t.chrono.JapaneseChronology.eraOf()
In-Reply-To: <54CC1839.30801@oracle.com>
References: <54CC04C8.9070600@Oracle.com>
	<54CC055D.9030602@oracle.com>	<54CC06C9.2050101@Oracle.com>
	<54CC1839.30801@oracle.com>
Message-ID: <54D0F30D.4010302@Oracle.com>

Hi Mandy,

I added a test for the invalid Eras.
I do expect the additional conformance tests from the JCK team but this
will synchronize with the fix.

Webrev updated in place:
   http://cr.openjdk.java.net/~rriggs/webrev-era-8068278/

Thanks, Roger



On 1/30/2015 6:48 PM, Mandy Chung wrote:
> On 1/30/15 2:33 PM, Roger Riggs wrote:
>> Hi Mandy,
>>
>> Thanks for the review.
>>
>> I wrote the test (and it passed) but since the JCK folks are 
>> providing the tests it seemed
>> undesirable to have duplicate tests.
>
> JDK developers don't run JCK tests and I think it'd be nice to have a 
> regression test to go with a fix unless the bug is uncovered by an 
> existing test.
>
> Mandy
>>
>> Roger
>>
>> On 1/30/2015 5:27 PM, Mandy Chung wrote:
>>> On 1/30/15 2:25 PM, Roger Riggs wrote:
>>>> Please review this correction of a JapaneseEra range check in 
>>>> java.time.
>>>> The error was discovered during development of additional 
>>>> conformance tests (to be delivered separately).
>>>>
>>>> Webrev:
>>>>    http://cr.openjdk.java.net/~rriggs//webrev-era-8068278
>>>>
>>>
>>> Looks fine to me.  Is it easy to write a regression test to go along 
>>> with this fix?
>>>
>>> Mandy
>>>
>>>> Issue:
>>>> <https://bugs.openjdk.java.net/browse/JDK-8068278> 8068278 
>>>> ArrayIndexOutOfBoundsException instead of DateTimeException in 
>>>> j.t.chrono.JapaneseChronology.eraOf()
>>>>
>>>> Thanks, Roger
>>>>
>>>
>>
>



From lance.andersen at oracle.com  Tue Feb  3 16:21:31 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 3 Feb 2015 11:21:31 -0500
Subject: RFR 8/9: 8068278 ArrayIndexOutOfBoundsException instead of
	DateTimeException in j.t.chrono.JapaneseChronology.eraOf()
In-Reply-To: <54D0F30D.4010302@Oracle.com>
References: <54CC04C8.9070600@Oracle.com>
	<54CC055D.9030602@oracle.com>	<54CC06C9.2050101@Oracle.com>
	<54CC1839.30801@oracle.com> <54D0F30D.4010302@Oracle.com>
Message-ID: <B4AD036F-0640-4D63-8977-60D8A3ACFE1A@oracle.com>

Hi Roger,

Did you mean to put the @Test annotation on the class itself?

Also for the test_valueOf test, I would also add the same comment style to it as it is the only one missing a comment

I think you meant to have test_outofrange uses the values from invalidEras array (though I would use a DataProvider myself)  for the values to eraOf as it is currently

JapaneseChronology.INSTANCE.eraOf(Integer.MAX_VALUE);



Best,
Lance
On Feb 3, 2015, at 11:10 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi Mandy,
> 
> I added a test for the invalid Eras.
> I do expect the additional conformance tests from the JCK team but this
> will synchronize with the fix.
> 
> Webrev updated in place:
>  http://cr.openjdk.java.net/~rriggs/webrev-era-8068278/
> 
> Thanks, Roger
> 
> 
> 
> On 1/30/2015 6:48 PM, Mandy Chung wrote:
>> On 1/30/15 2:33 PM, Roger Riggs wrote:
>>> Hi Mandy,
>>> 
>>> Thanks for the review.
>>> 
>>> I wrote the test (and it passed) but since the JCK folks are providing the tests it seemed
>>> undesirable to have duplicate tests.
>> 
>> JDK developers don't run JCK tests and I think it'd be nice to have a regression test to go with a fix unless the bug is uncovered by an existing test.
>> 
>> Mandy
>>> 
>>> Roger
>>> 
>>> On 1/30/2015 5:27 PM, Mandy Chung wrote:
>>>> On 1/30/15 2:25 PM, Roger Riggs wrote:
>>>>> Please review this correction of a JapaneseEra range check in java.time.
>>>>> The error was discovered during development of additional conformance tests (to be delivered separately).
>>>>> 
>>>>> Webrev:
>>>>>   http://cr.openjdk.java.net/~rriggs//webrev-era-8068278
>>>>> 
>>>> 
>>>> Looks fine to me.  Is it easy to write a regression test to go along with this fix?
>>>> 
>>>> Mandy
>>>> 
>>>>> Issue:
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8068278> 8068278 ArrayIndexOutOfBoundsException instead of DateTimeException in j.t.chrono.JapaneseChronology.eraOf()
>>>>> 
>>>>> Thanks, Roger
>>>>> 
>>>> 
>>> 
>> 
> 



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





From Roger.Riggs at Oracle.com  Tue Feb  3 16:59:33 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 03 Feb 2015 11:59:33 -0500
Subject: RFR 8/9: 8068278 ArrayIndexOutOfBoundsException instead of
	DateTimeException in j.t.chrono.JapaneseChronology.eraOf()
In-Reply-To: <B4AD036F-0640-4D63-8977-60D8A3ACFE1A@oracle.com>
References: <54CC04C8.9070600@Oracle.com>
	<54CC055D.9030602@oracle.com>	<54CC06C9.2050101@Oracle.com>
	<54CC1839.30801@oracle.com> <54D0F30D.4010302@Oracle.com>
	<B4AD036F-0640-4D63-8977-60D8A3ACFE1A@oracle.com>
Message-ID: <54D0FE75.1090108@Oracle.com>

Hi Lance,

Ok, 2nd try.

    http://cr.openjdk.java.net/~rriggs/webrev-era-8068278/



On 2/3/2015 11:21 AM, Lance Andersen wrote:
> Hi Roger,
>
> Did you mean to put the @Test annotation on the class itself?
It is redundant with the @Test on individual methods but harmless and 
was there previously.
>
> Also for the test_valueOf test, I would also add the same comment 
> style to it as it is the only one missing a comment
Not part of this issue, but fixed.
>
> I think you meant to have test_outofrange uses the values from 
> invalidEras array (though I would use a DataProvider myself)  for the 
> values to eraOf as it is currently
Wow, my bad.
Replaced with a data provider.  The overhead of DataProviders is a bit 
higher; but maybe not enough to notice.

Thanks for reviewing.

Roger


>
> JapaneseChronology.INSTANCE.eraOf(Integer.MAX_VALUE);
>
>
>
> Best,
> Lance
> On Feb 3, 2015, at 11:10 AM, Roger Riggs <Roger.Riggs at oracle.com 
> <mailto:Roger.Riggs at oracle.com>> wrote:
>
>> Hi Mandy,
>>
>> I added a test for the invalid Eras.
>> I do expect the additional conformance tests from the JCK team but this
>> will synchronize with the fix.
>>
>> Webrev updated in place:
>> http://cr.openjdk.java.net/~rriggs/webrev-era-8068278/ 
>> <http://cr.openjdk.java.net/%7Erriggs/webrev-era-8068278/>
>>
>> Thanks, Roger
>>
>>
>>
>> On 1/30/2015 6:48 PM, Mandy Chung wrote:
>>> On 1/30/15 2:33 PM, Roger Riggs wrote:
>>>> Hi Mandy,
>>>>
>>>> Thanks for the review.
>>>>
>>>> I wrote the test (and it passed) but since the JCK folks are 
>>>> providing the tests it seemed
>>>> undesirable to have duplicate tests.
>>>
>>> JDK developers don't run JCK tests and I think it'd be nice to have 
>>> a regression test to go with a fix unless the bug is uncovered by an 
>>> existing test.
>>>
>>> Mandy
>>>>
>>>> Roger
>>>>
>>>> On 1/30/2015 5:27 PM, Mandy Chung wrote:
>>>>> On 1/30/15 2:25 PM, Roger Riggs wrote:
>>>>>> Please review this correction of a JapaneseEra range check in 
>>>>>> java.time.
>>>>>> The error was discovered during development of additional 
>>>>>> conformance tests (to be delivered separately).
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~rriggs//webrev-era-8068278 
>>>>>> <http://cr.openjdk.java.net/%7Erriggs//webrev-era-8068278>
>>>>>>
>>>>>
>>>>> Looks fine to me.  Is it easy to write a regression test to go 
>>>>> along with this fix?
>>>>>
>>>>> Mandy
>>>>>
>>>>>> Issue:
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8068278> 8068278 
>>>>>> ArrayIndexOutOfBoundsException instead of DateTimeException in 
>>>>>> j.t.chrono.JapaneseChronology.eraOf()
>>>>>>
>>>>>> Thanks, Roger
>>>>>>
>>>>>
>>>>
>>>
>>
>
> <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 sean.coffey at oracle.com  Tue Feb  3 17:06:49 2015
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Tue, 03 Feb 2015 17:06:49 +0000
Subject: [9] RFR: 8072042: (tz) Support tzdata2015a
In-Reply-To: <54D0F065.9010304@oracle.com>
References: <54D0F065.9010304@oracle.com>
Message-ID: <54D10029.909@oracle.com>

Looks good to me.

regards,
Sean.

On 03/02/2015 15:59, Aleksej Efimov wrote:
> Hi,
>
> Could I have a review the latest tzdata2015a integration fix to JDK9, 
> please. The regression tests run and JPRT testing (jdk_other,jdk_util, 
> jdk_text, jdk_time test sets) shows no TZ related JDK9 failures.
>
> Thank you,
> Aleksej
>
> Bug link: https://bugs.openjdk.java.net/browse/JDK-8072042
> Webrev with changes: 
> http://cr.openjdk.java.net/~aefimov/tzdata/2015a/9/00/
> Regression tests executed: test/sun/util/calendar\ 
> test/java/util/Calendar\ test/sun/util/resources/TimeZone\ 
> test/java/util/TimeZone\ test/java/time\ test/java/util/Formatter



From mandy.chung at oracle.com  Tue Feb  3 17:23:53 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 03 Feb 2015 09:23:53 -0800
Subject: RFR 8/9: 8068278 ArrayIndexOutOfBoundsException instead of
	DateTimeException in j.t.chrono.JapaneseChronology.eraOf()
In-Reply-To: <54D0FE75.1090108@Oracle.com>
References: <54CC04C8.9070600@Oracle.com>	<54CC055D.9030602@oracle.com>	<54CC06C9.2050101@Oracle.com>	<54CC1839.30801@oracle.com>
	<54D0F30D.4010302@Oracle.com>	<B4AD036F-0640-4D63-8977-60D8A3ACFE1A@oracle.com>
	<54D0FE75.1090108@Oracle.com>
Message-ID: <54D10429.9030803@oracle.com>

On 2/3/15 8:59 AM, Roger Riggs wrote:
> Ok, 2nd try.
>
> http://cr.openjdk.java.net/~rriggs/webrev-era-8068278/ 

Looks good. Thanks for adding the regression test.

Mandy



From lance.andersen at oracle.com  Tue Feb  3 18:22:01 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 3 Feb 2015 13:22:01 -0500
Subject: RFR 8/9: 8068278 ArrayIndexOutOfBoundsException instead of
	DateTimeException in j.t.chrono.JapaneseChronology.eraOf()
In-Reply-To: <54D0FE75.1090108@Oracle.com>
References: <54CC04C8.9070600@Oracle.com>
	<54CC055D.9030602@oracle.com>	<54CC06C9.2050101@Oracle.com>
	<54CC1839.30801@oracle.com> <54D0F30D.4010302@Oracle.com>
	<B4AD036F-0640-4D63-8977-60D8A3ACFE1A@oracle.com>
	<54D0FE75.1090108@Oracle.com>
Message-ID: <A68C914F-AC38-47FD-94F2-849467F5F69A@oracle.com>

Hi Roger,

Thank you. Ship it.

Best
Lance
On Feb 3, 2015, at 11:59 AM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:

> Hi Lance,
> 
> Ok, 2nd try.
> 
>    http://cr.openjdk.java.net/~rriggs/webrev-era-8068278/
> 
> 
> 
> On 2/3/2015 11:21 AM, Lance Andersen wrote:
>> Hi Roger,
>> 
>> Did you mean to put the @Test annotation on the class itself?
> It is redundant with the @Test on individual methods but harmless and was there previously.
>> 
>> Also for the test_valueOf test, I would also add the same comment style to it as it is the only one missing a comment
> Not part of this issue, but fixed.
>> 
>> I think you meant to have test_outofrange uses the values from invalidEras array (though I would use a DataProvider myself)  for the values to eraOf as it is currently
> Wow, my bad.
> Replaced with a data provider.  The overhead of DataProviders is a bit higher; but maybe not enough to notice.
> 
> Thanks for reviewing.
> 
> Roger
> 
> 
>> 
>> JapaneseChronology.INSTANCE.eraOf(Integer.MAX_VALUE);
>> 
>> 
>> 
>> Best,
>> Lance
>> On Feb 3, 2015, at 11:10 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>> 
>>> Hi Mandy,
>>> 
>>> I added a test for the invalid Eras.
>>> I do expect the additional conformance tests from the JCK team but this
>>> will synchronize with the fix.
>>> 
>>> Webrev updated in place:
>>>  http://cr.openjdk.java.net/~rriggs/webrev-era-8068278/
>>> 
>>> Thanks, Roger
>>> 
>>> 
>>> 
>>> On 1/30/2015 6:48 PM, Mandy Chung wrote:
>>>> On 1/30/15 2:33 PM, Roger Riggs wrote:
>>>>> Hi Mandy,
>>>>> 
>>>>> Thanks for the review.
>>>>> 
>>>>> I wrote the test (and it passed) but since the JCK folks are providing the tests it seemed
>>>>> undesirable to have duplicate tests.
>>>> 
>>>> JDK developers don't run JCK tests and I think it'd be nice to have a regression test to go with a fix unless the bug is uncovered by an existing test.
>>>> 
>>>> Mandy
>>>>> 
>>>>> Roger
>>>>> 
>>>>> On 1/30/2015 5:27 PM, Mandy Chung wrote:
>>>>>> On 1/30/15 2:25 PM, Roger Riggs wrote:
>>>>>>> Please review this correction of a JapaneseEra range check in java.time.
>>>>>>> The error was discovered during development of additional conformance tests (to be delivered separately).
>>>>>>> 
>>>>>>> Webrev:
>>>>>>>   http://cr.openjdk.java.net/~rriggs//webrev-era-8068278
>>>>>>> 
>>>>>> 
>>>>>> Looks fine to me.  Is it easy to write a regression test to go along with this fix?
>>>>>> 
>>>>>> Mandy
>>>>>> 
>>>>>>> Issue:
>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8068278> 8068278 ArrayIndexOutOfBoundsException instead of DateTimeException in j.t.chrono.JapaneseChronology.eraOf()
>>>>>>> 
>>>>>>> Thanks, Roger
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> <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 martinrb at google.com  Tue Feb  3 19:30:08 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 3 Feb 2015 11:30:08 -0800
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <54D08997.9020300@oracle.com>
References: <54CBAA39.3050004@Oracle.com> <54CBF7DB.9000909@oracle.com>
	<54CBFC10.9080502@Oracle.com>
	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>
	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>
	<54CD4305.4080607@oracle.com>
	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>
	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>
	<54CF7D1F.6050101@Oracle.com>
	<CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>
	<54CFE064.70400@Oracle.com>
	<CA+kOe0-zPJRpGEa0zXy6_bHgwNcnFWuSc1fbbxsc7-nc6SUjAg@mail.gmail.com>
	<54D08997.9020300@oracle.com>
Message-ID: <CA+kOe091FHtd1Mnz_eVLcP0a_fC-+nXPGjnEdYr706XguBTy=g@mail.gmail.com>

I agree that we should not be throwing SecurityException.  We should be
throwing IOException.

But given a choice between SecurityException and
UnsupportedOperationException, I would regard the former as the lesser of
two evils.

On Tue, Feb 3, 2015 at 12:40 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 02/02/2015 21:06, Martin Buchholz wrote:
>
>> :
>> The historic spec allows for both SecurityException and IOException (but
>> not UOE).
>> Locked-down systems typically (but not necessarily) have a SecurityManager
>> that helps enforce the restrictions and so SecurityException seems vaguely
>> appropriate.
>>
>>  There are a small number of places where SecurityException is thrown
> when not running with a security manager (defineClass, package sealing) but
> it can be confusing for developers to get this exception when there isn't a
> Java security manager. So I don't think we should be using it here.
>
> -Alan
>


From joel.franck at oracle.com  Tue Feb  3 19:56:40 2015
From: joel.franck at oracle.com (=?utf-8?Q?Joel_Borggr=C3=A9n-Franck?=)
Date: Tue, 3 Feb 2015 20:56:40 +0100
Subject: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
In-Reply-To: <B5F7A180-60F2-4B08-87B1-A8479D8AC43E@oracle.com>
References: <B5F7A180-60F2-4B08-87B1-A8479D8AC43E@oracle.com>
Message-ID: <A43DF4D7-742C-42BE-8345-3DC84BA09170@oracle.com>

Hi,

> On 03 Feb 2015, at 10:15, Staffan Larsen <staffan.larsen at oracle.com> wrote:
> 
> Hi,
> 
> Please review this patch for hiding the lambda proxy frame in stack traces:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8025636
> webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.00/
> 
> This is a straightforward addition of the LambdaForm$Hidden annotation to the generated methods. What is surprising is that this works even if LambdaForm$Hidden is a package-private class in java.lang.invoke and thus not accessible from most of the generated classes. There is some discussion of and answers to this in the bug, but essentially this works because the annotation class is never resolved and the code in Hotspot that looks for the annotation amounts to nothing more than string comparisons.
> 


Parsing of the annotation by core reflection can of course happen but should be fine. AnnotationParser calls into the generics machinery to get a Class instance for the annotation type, this shouldn?t be a problem since Class.forName() doesn?t care about package visibility when handing out Class instances to the best of my understanding. Also the parsing machinery is in the null loader so it will be able to find the type. The Proxy for the annotation also shouldn?t care about the package visibility since there is only one interface being proxied (again to the best of my knowledge). If someone were to access members of the parsed annotation things might start to break, but there are none.

Looks good to me, but you should probably get at reviewer that knows the invoke code better.

cheers
/Joel

From Roger.Riggs at Oracle.com  Tue Feb  3 20:45:11 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 3 Feb 2015 12:45:11 -0800 (PST)
Subject: RFR 9: 8067800: Unexpected DateTimeException in the
	java.time.chrono.HijrahChronology.isLeapYear
Message-ID: <54D13357.2090406@Oracle.com>

Please review this specification clarification of the range of Hijrah 
calendar variants.
The issue was exposed by a bug in the HijrahChronology.isLeapYear method.

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/

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

A CCC may be needed.

Thanks, Roger



From lance.andersen at oracle.com  Tue Feb  3 20:56:27 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 3 Feb 2015 15:56:27 -0500
Subject: RFR 9: 8067800: Unexpected DateTimeException in the
	java.time.chrono.HijrahChronology.isLeapYear
In-Reply-To: <54D13357.2090406@Oracle.com>
References: <54D13357.2090406@Oracle.com>
Message-ID: <6BDD077A-A4E3-4908-AC37-2C1451A8BFCC@oracle.com>

+1
On Feb 3, 2015, at 3:45 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Please review this specification clarification of the range of Hijrah calendar variants.
> The issue was exposed by a bug in the HijrahChronology.isLeapYear method.
> 
> Webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/
> 
> Issue:
>   https://bugs.openjdk.java.net/browse/JDK-8067800
> 
> A CCC may be needed.
> 
> Thanks, Roger
> 



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





From brent.christian at oracle.com  Wed Feb  4 00:01:51 2015
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 03 Feb 2015 16:01:51 -0800
Subject: RFC: Adding ConcurrentModificationException for
	HashMap.computeIfAbsent(), and JDK-8071667
Message-ID: <54D1616F.50104@oracle.com>

Hi,

The code in bug 8071667 [1] passes a mappingFunction to 
computeIfAbsent() which itself put()s a sufficient number of additional 
entries into the HashMap to cause a resize/rehash.  As a result, 
computeIfAbsent() doesn't add the new entry at the proper place in the 
HashMap.

While one should not (mis)use the mappingFunction in this way, 
HashMap.computeIfAbsent() (and similar HashMap methods which accept 
Lambda expressions) could check for and throw a 
ConcurrentModificationException on a "best-effort" basis, similar to 
iterators.  This is already done in bulk operations HashMap.forEach() 
and HashMap.replaceAll().

I think it's also worth making mention of this in the JavaDoc.

Here's an example of what might be done, using computeIfAbsent() as an 
example:

http://cr.openjdk.java.net/~bchristi/8071667/webrev.0/

I would update HashMap and Hashtable.  It looks like 
ConcurrentHashMap.computeIfAbsent() already forbids such usage, stating 
that the computation "must not attempt to update any other mappings of 
this map."


Comments on this approach?

Thanks,
-Brent

1. https://bugs.openjdk.java.net/browse/JDK-8071667
    "HashMap.computeIfAbsent() adds entry that HashMap.get() does not find."


From scolebourne at joda.org  Wed Feb  4 01:05:47 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 4 Feb 2015 01:05:47 +0000
Subject: RFR 9: 8067800: Unexpected DateTimeException in the
	java.time.chrono.HijrahChronology.isLeapYear
In-Reply-To: <6BDD077A-A4E3-4908-AC37-2C1451A8BFCC@oracle.com>
References: <54D13357.2090406@Oracle.com>
	<6BDD077A-A4E3-4908-AC37-2C1451A8BFCC@oracle.com>
Message-ID: <CACzrW9A0fnRHYvOZsjcvM8d2=2oorBu2272i-mSDF1JyTO_ssA@mail.gmail.com>

-1

As I indicated on JIRA, I don't believe that this change meets the
spec or intent of the definition on Chronology. That is specified to
not throw any exceptions and to handle all years, valid or not.

I don't foresee any significant issue where a year is not validated by
this method. Years out of range should simply return false, again
something that is within the spirit of the spec "a chronology that
does not support the concept of a year must return false."

Stephen



On 3 February 2015 at 20:56, Lance Andersen <lance.andersen at oracle.com> wrote:
> +1
> On Feb 3, 2015, at 3:45 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>
>> Please review this specification clarification of the range of Hijrah calendar variants.
>> The issue was exposed by a bug in the HijrahChronology.isLeapYear method.
>>
>> Webrev:
>>   http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/
>>
>> Issue:
>>   https://bugs.openjdk.java.net/browse/JDK-8067800
>>
>> A CCC may be needed.
>>
>> Thanks, Roger
>>
>
>
>
> 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 Feb  4 03:01:46 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 03 Feb 2015 19:01:46 -0800
Subject: RFC: Adding ConcurrentModificationException for
	HashMap.computeIfAbsent(), and JDK-8071667
In-Reply-To: <54D1616F.50104@oracle.com>
References: <54D1616F.50104@oracle.com>
Message-ID: <54D18B9A.2020906@oracle.com>

On 2/3/15 4:01 PM, Brent Christian wrote:
> The code in bug 8071667 [1] passes a mappingFunction to computeIfAbsent() which
> itself put()s a sufficient number of additional entries into the HashMap to
> cause a resize/rehash.  As a result, computeIfAbsent() doesn't add the new entry
> at the proper place in the HashMap.
>
> While one should not (mis)use the mappingFunction in this way,
> HashMap.computeIfAbsent() (and similar HashMap methods which accept Lambda
> expressions) could check for and throw a ConcurrentModificationException on a
> "best-effort" basis, similar to iterators.  This is already done in bulk
> operations HashMap.forEach() and HashMap.replaceAll().
>
> I think it's also worth making mention of this in the JavaDoc.

I think we need to have the specification discussion *first* before we decide 
what HashMap should do with side-effecty computations that are passed to 
computeIfAbsent and friends. Unfortunately the API specification for 
Map.computeIfAbsent is largely silent about what should happen. I don't know 
whether that means that the result should be undefined, or that passing a 
function with side effects is implicitly allowed and should therefore be defined.

I'd think it would be quite unpleasantly surprising to find that passing a 
mapping function with side effects -- especially on keys other than the current 
operation -- results in essentially a corrupted map. Then again, I'm surprised 
that somebody would think to pass a mapping function that does have side 
effects. However, this is what people do, and they expect the library to behave 
reasonably.

I can think of an (only moderately contrived) use case that's probably behind 
the bug report. Suppose I want to have a map that starts empty but which is 
lazily initialized, and when it's initialized, it should contain entries for all 
keys A, B, C, D, and E. Furthermore, it should be lazily initialized when any 
one of these keys is put into the map. Of course, you can write this out easily 
yourself. But hey, there's this new computeIfAbsent() method that should let me do

     map.computeIfAbsent(key, k -> {
         /* put all entries A..E except k */
         return value_for_k;
     });

Based on the @implSpec for Map.computeIfAbsent, I'd expect this to work. And if 
your map inherits the Map.computeIfAbsent default implementation, it probably 
does work. Indeed, the workaround given in the bug report is essentially to 
implement your own method that duplicates the logic of the @implSpec and the 
default method. So, I'm leaning toward specifying that side effects should be 
supported, and that ConcurrentModificationException should not be thrown.

That implies that HashMap will have to detect the concurrent modification and 
deal with it instead of throwing an exception.

If we do clarify the spec to support this case, it probably shouldn't make any 
guarantees about what should happen if the mapping function puts the *same* key. 
That is, if

     map.computeIfAbsent(key, k -> {
         put(k, value1);
         return value2;
     });

it seems reasonable that it not be defined which of value1 or value2 ends up 
getting mapped to the key.

s'marks


> Here's an example of what might be done, using computeIfAbsent() as an example:
>
> http://cr.openjdk.java.net/~bchristi/8071667/webrev.0/
>
> I would update HashMap and Hashtable.  It looks like
> ConcurrentHashMap.computeIfAbsent() already forbids such usage, stating that the
> computation "must not attempt to update any other mappings of this map."
>
>
> Comments on this approach?
>
> Thanks,
> -Brent
>
> 1. https://bugs.openjdk.java.net/browse/JDK-8071667
>     "HashMap.computeIfAbsent() adds entry that HashMap.get() does not find."


From staffan.larsen at oracle.com  Wed Feb  4 08:48:05 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 4 Feb 2015 09:48:05 +0100
Subject: RFR: JDK-8072456 @since tags missing from TimeUnit
Message-ID: <A41FBE62-0364-4F30-8DC9-B2452F4C554D@oracle.com>

The MINUTES, HOURS, and DAYS fields of TimeUnit are missing an "@since 1.6" tag.

webrev: http://cr.openjdk.java.net/~sla/8072456/webrev.00/ <http://cr.openjdk.java.net/~sla/8072456/webrev.00/>
bug: https://bugs.openjdk.java.net/browse/JDK-8072456 <https://bugs.openjdk.java.net/browse/JDK-8072456>

Thanks,
/Staffan

From staffan.larsen at oracle.com  Wed Feb  4 08:51:15 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 4 Feb 2015 09:51:15 +0100
Subject: RFR: JDK-8072458 jdk/test/Makefile references (to be removed) win32
	directory in jtreg
Message-ID: <AB546C59-95DC-4605-9888-F6AA913C1BA3@oracle.com>

The platform specific directories in jtreg are going away in favor of a platform-agnostic directory.

Small fix below.

Thanks,
/Staffan


diff --git a/test/Makefile b/test/Makefile
--- a/test/Makefile
+++ b/test/Makefile
@@ -267,8 +267,8 @@
   EXTRA_JTREG_OPTIONS += -concurrency:$(CONCURRENCY)
 endif

-# Default JTREG to run (win32 script works for everybody)
-JTREG = $(JT_HOME)/win32/bin/jtreg
+# Default JTREG to run
+JTREG = $(JT_HOME)/bin/jtreg
 # run in agentvm mode
 JTREG_BASIC_OPTIONS += -agentvm
 # Only run automatic tests

From Alan.Bateman at oracle.com  Wed Feb  4 09:05:12 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 04 Feb 2015 09:05:12 +0000
Subject: RFR: JDK-8072458 jdk/test/Makefile references (to be removed)
	win32 directory in jtreg
In-Reply-To: <AB546C59-95DC-4605-9888-F6AA913C1BA3@oracle.com>
References: <AB546C59-95DC-4605-9888-F6AA913C1BA3@oracle.com>
Message-ID: <54D1E0C8.5070507@oracle.com>

On 04/02/2015 08:51, Staffan Larsen wrote:
> The platform specific directories in jtreg are going away in favor of a platform-agnostic directory.
>
> Small fix below.
>
> Thanks,
> /Staffan
>
>
> diff --git a/test/Makefile b/test/Makefile
> --- a/test/Makefile
> +++ b/test/Makefile
> @@ -267,8 +267,8 @@
>     EXTRA_JTREG_OPTIONS += -concurrency:$(CONCURRENCY)
>   endif
>
> -# Default JTREG to run (win32 script works for everybody)
> -JTREG = $(JT_HOME)/win32/bin/jtreg
> +# Default JTREG to run
> +JTREG = $(JT_HOME)/bin/jtreg
>   # run in agentvm mode
>   JTREG_BASIC_OPTIONS += -agentvm
>   # Only run automatic tests
This looks okay to me.

-Alan.


From martinrb at google.com  Wed Feb  4 09:06:54 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 4 Feb 2015 01:06:54 -0800
Subject: RFR: JDK-8072456 @since tags missing from TimeUnit
In-Reply-To: <A41FBE62-0364-4F30-8DC9-B2452F4C554D@oracle.com>
References: <A41FBE62-0364-4F30-8DC9-B2452F4C554D@oracle.com>
Message-ID: <CA+kOe0_7dZ14dDmA0e3C5z0s_a=HtP98DhixfPj=sGrvk4S7Cg@mail.gmail.com>

Approved.  Good find.  I made an effort to automatically find all the
missing @since back in the 1.6 days, but apparently it didn't find missing
added enum values.

jsr166 CVS updated.

On Wed, Feb 4, 2015 at 12:48 AM, Staffan Larsen <staffan.larsen at oracle.com>
wrote:

> The MINUTES, HOURS, and DAYS fields of TimeUnit are missing an "@since
> 1.6" tag.
>
> webrev: http://cr.openjdk.java.net/~sla/8072456/webrev.00/ <
> http://cr.openjdk.java.net/~sla/8072456/webrev.00/>
> bug: https://bugs.openjdk.java.net/browse/JDK-8072456 <
> https://bugs.openjdk.java.net/browse/JDK-8072456>
>
> Thanks,
> /Staffan


From Alan.Bateman at oracle.com  Wed Feb  4 09:09:15 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 04 Feb 2015 09:09:15 +0000
Subject: RFR: JDK-8072456 @since tags missing from TimeUnit
In-Reply-To: <A41FBE62-0364-4F30-8DC9-B2452F4C554D@oracle.com>
References: <A41FBE62-0364-4F30-8DC9-B2452F4C554D@oracle.com>
Message-ID: <54D1E1BB.9080304@oracle.com>

On 04/02/2015 08:48, Staffan Larsen wrote:
> The MINUTES, HOURS, and DAYS fields of TimeUnit are missing an "@since 1.6" tag.
>
> webrev: http://cr.openjdk.java.net/~sla/8072456/webrev.00/ <http://cr.openjdk.java.net/~sla/8072456/webrev.00/>
> bug: https://bugs.openjdk.java.net/browse/JDK-8072456 <https://bugs.openjdk.java.net/browse/JDK-8072456>
>
This looks okay to me (and I think the first time that I've seen @since 
on enum members). I'm sure Martin will get this into the upstream CVS so 
that we are in sync.

-Alan.


From paul.sandoz at oracle.com  Wed Feb  4 10:01:06 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 4 Feb 2015 11:01:06 +0100
Subject: RFC: Adding ConcurrentModificationException for
	HashMap.computeIfAbsent(), and JDK-8071667
In-Reply-To: <54D18B9A.2020906@oracle.com>
References: <54D1616F.50104@oracle.com> <54D18B9A.2020906@oracle.com>
Message-ID: <84AD741C-CB02-4540-B41B-8F95490FF8E4@oracle.com>

Hi,

I think we should as consistent as possible about the functions being side-effect free when applied to "bulk" operations. A method such as computeIfAbsent can be viewed as a bulk operation in that it may perform two or more dependent actions (they are just not as bulky as forEach).

It's inconsistent if we state the functions should be side-effect free *but* map implementations tolerate side-effects resulting in state changes for entries other than that associated with the key under operation. I am not even sure this can be easily guaranteed with CHM in the face of resizes and keys hashing to the same bucket.

So i propose:

- the functions should be side-effect free.

- non-concurrent map implementations should, on a best-effort basis, detect comodification and fail with CME.

- concurrent map implementations should, on a best-effort basis, detect non-termination situations and fail with ISE. 

- document the best-effort behaviour and advise that implementations should override the default implementations if they want to do better.

Alas we cannot do anything about the default method implementations, but i don't think we should be constraining general behaviour based on that exact implementations (just as we do not for concurrent maps, it "behaves as if").

Paul.

On Feb 4, 2015, at 4:01 AM, Stuart Marks <stuart.marks at oracle.com> wrote:

> On 2/3/15 4:01 PM, Brent Christian wrote:
>> The code in bug 8071667 [1] passes a mappingFunction to computeIfAbsent() which
>> itself put()s a sufficient number of additional entries into the HashMap to
>> cause a resize/rehash.  As a result, computeIfAbsent() doesn't add the new entry
>> at the proper place in the HashMap.
>> 
>> While one should not (mis)use the mappingFunction in this way,
>> HashMap.computeIfAbsent() (and similar HashMap methods which accept Lambda
>> expressions) could check for and throw a ConcurrentModificationException on a
>> "best-effort" basis, similar to iterators.  This is already done in bulk
>> operations HashMap.forEach() and HashMap.replaceAll().
>> 
>> I think it's also worth making mention of this in the JavaDoc.
> 
> I think we need to have the specification discussion *first* before we decide what HashMap should do with side-effecty computations that are passed to computeIfAbsent and friends. Unfortunately the API specification for Map.computeIfAbsent is largely silent about what should happen. I don't know whether that means that the result should be undefined, or that passing a function with side effects is implicitly allowed and should therefore be defined.
> 
> I'd think it would be quite unpleasantly surprising to find that passing a mapping function with side effects -- especially on keys other than the current operation -- results in essentially a corrupted map. Then again, I'm surprised that somebody would think to pass a mapping function that does have side effects. However, this is what people do, and they expect the library to behave reasonably.
> 
> I can think of an (only moderately contrived) use case that's probably behind the bug report. Suppose I want to have a map that starts empty but which is lazily initialized, and when it's initialized, it should contain entries for all keys A, B, C, D, and E. Furthermore, it should be lazily initialized when any one of these keys is put into the map. Of course, you can write this out easily yourself. But hey, there's this new computeIfAbsent() method that should let me do
> 
>    map.computeIfAbsent(key, k -> {
>        /* put all entries A..E except k */
>        return value_for_k;
>    });
> 
> Based on the @implSpec for Map.computeIfAbsent, I'd expect this to work. And if your map inherits the Map.computeIfAbsent default implementation, it probably does work. Indeed, the workaround given in the bug report is essentially to implement your own method that duplicates the logic of the @implSpec and the default method. So, I'm leaning toward specifying that side effects should be supported, and that ConcurrentModificationException should not be thrown.
> 
> That implies that HashMap will have to detect the concurrent modification and deal with it instead of throwing an exception.
> 
> If we do clarify the spec to support this case, it probably shouldn't make any guarantees about what should happen if the mapping function puts the *same* key. That is, if
> 
>    map.computeIfAbsent(key, k -> {
>        put(k, value1);
>        return value2;
>    });
> 
> it seems reasonable that it not be defined which of value1 or value2 ends up getting mapped to the key.
> 
> s'marks
> 
> 
>> Here's an example of what might be done, using computeIfAbsent() as an example:
>> 
>> http://cr.openjdk.java.net/~bchristi/8071667/webrev.0/
>> 
>> I would update HashMap and Hashtable.  It looks like
>> ConcurrentHashMap.computeIfAbsent() already forbids such usage, stating that the
>> computation "must not attempt to update any other mappings of this map."
>> 
>> 
>> Comments on this approach?
>> 
>> Thanks,
>> -Brent
>> 
>> 1. https://bugs.openjdk.java.net/browse/JDK-8071667
>>    "HashMap.computeIfAbsent() adds entry that HashMap.get() does not find."



From daniel.fuchs at oracle.com  Wed Feb  4 11:31:13 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 04 Feb 2015 12:31:13 +0100
Subject: RFR - 8072450: 9-dev build failed on elinux-i586 and rlinux-i586
Message-ID: <54D20301.9060702@oracle.com>

Hi,

Please find below a fix for:

8072450: 9-dev build failed on elinux-i586 and rlinux-i586

My fix for JDK-8068730 which was integrated from hs-rt into jdk9-dev
yesterday is causing a build failure in the jdk9/dev nightly on two 
platforms.
It appears that these platforms have a slightly older version
of the compiler - which chokes on jvm.cpp with the following error:

hotspot/src/share/vm/prims/jvm.cpp:307: error: integer constant is too 
large for ???long??? type

Adding a LL suffix should solve the issue:

##############

diff --git a/src/share/vm/prims/jvm.cpp b/src/share/vm/prims/jvm.cpp
--- a/src/share/vm/prims/jvm.cpp
+++ b/src/share/vm/prims/jvm.cpp
@@ -304,7 +304,7 @@
  // java.lang.System, but we choose to keep it here so that it stays next
  // to JVM_CurrentTimeMillis and JVM_NanoTime

-const jlong MAX_DIFF_SECS = 0x0100000000;   //  2^32
+const jlong MAX_DIFF_SECS = 0x0100000000LL; //  2^32
  const jlong MIN_DIFF_SECS = -MAX_DIFF_SECS; // -2^32

  JVM_LEAF(jlong, JVM_GetNanoTimeAdjustment(JNIEnv *env, jclass ignored, 
jlong offset_secs))

##############

( or if you prefer here is a webrev:
   http://cr.openjdk.java.net/~dfuchs/webrev_8072450/webrev.00 )

best regards,

-- daniel



From david.holmes at oracle.com  Wed Feb  4 11:44:01 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 04 Feb 2015 21:44:01 +1000
Subject: RFR - 8072450: 9-dev build failed on elinux-i586 and rlinux-i586
In-Reply-To: <54D20301.9060702@oracle.com>
References: <54D20301.9060702@oracle.com>
Message-ID: <54D20601.6030401@oracle.com>

Reviewed!

Just to clarify for others - only nightly builds seem to be affected by 
this due to use of very old gcc version. So developers should be 
unlikely to see this. JPRT is not affected.

Thanks,
David

On 4/02/2015 9:31 PM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a fix for:
>
> 8072450: 9-dev build failed on elinux-i586 and rlinux-i586
>
> My fix for JDK-8068730 which was integrated from hs-rt into jdk9-dev
> yesterday is causing a build failure in the jdk9/dev nightly on two
> platforms.
> It appears that these platforms have a slightly older version
> of the compiler - which chokes on jvm.cpp with the following error:
>
> hotspot/src/share/vm/prims/jvm.cpp:307: error: integer constant is too
> large for ???long??? type
>
> Adding a LL suffix should solve the issue:
>
> ##############
>
> diff --git a/src/share/vm/prims/jvm.cpp b/src/share/vm/prims/jvm.cpp
> --- a/src/share/vm/prims/jvm.cpp
> +++ b/src/share/vm/prims/jvm.cpp
> @@ -304,7 +304,7 @@
>   // java.lang.System, but we choose to keep it here so that it stays next
>   // to JVM_CurrentTimeMillis and JVM_NanoTime
>
> -const jlong MAX_DIFF_SECS = 0x0100000000;   //  2^32
> +const jlong MAX_DIFF_SECS = 0x0100000000LL; //  2^32
>   const jlong MIN_DIFF_SECS = -MAX_DIFF_SECS; // -2^32
>
>   JVM_LEAF(jlong, JVM_GetNanoTimeAdjustment(JNIEnv *env, jclass ignored,
> jlong offset_secs))
>
> ##############
>
> ( or if you prefer here is a webrev:
>    http://cr.openjdk.java.net/~dfuchs/webrev_8072450/webrev.00 )
>
> best regards,
>
> -- daniel
>


From chris.hegarty at oracle.com  Wed Feb  4 13:54:38 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 04 Feb 2015 13:54:38 +0000
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54CFE38D.30400@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CD3043.2070709@gmail.com>
	<54CD4A14.2080205@oracle.com>	<54CD6984.2040004@gmail.com>
	<54CDF84E.7070905@oracle.com>	<54CE03D2.8000706@gmail.com>
	<54CF386A.9000600@oracle.com>
	<2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>
	<54CF5EF3.20102@oracle.com> <54CFE38D.30400@oracle.com>
Message-ID: <54D2249E.105@oracle.com>

On 02/02/15 20:52, Alan Bateman wrote:
> ....
> I'm happy with this approach. One outstanding point from the discussion
> is whether the URLStreamHandlerFactory implementation will need to be
> granted RuntimePermission("setFactory"), if so then this will need to go
> into the javadoc.

I think that we should check "setFactory" for providers located
by service loader. The most appropriate way to do this is with
a new public abstract type who's constructor checks this,
similar to CharsetProvider ( and others ).

The updated spec revision, link below, defines the new public
provider type in a new networking service provider interface
package, java.net.spi. Future service provider interfaces for
the java.net package should be defined into this package.

 
http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html

Note:
  The spec does no mention what happens when a SecurityException is
  thrown ( it will be the cause of the SCE ). The prototype
  implementation I have will will swallow it, and continue searching,
  as is done for CharsetProviders. A SecurityException, locating
  a provider, should not prevent the the app from making progress.
  The provider will just not be available.

-Chris.


From peter.levart at gmail.com  Wed Feb  4 14:29:26 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 04 Feb 2015 15:29:26 +0100
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54D2249E.105@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CD3043.2070709@gmail.com>	<54CD4A14.2080205@oracle.com>	<54CD6984.2040004@gmail.com>	<54CDF84E.7070905@oracle.com>	<54CE03D2.8000706@gmail.com>	<54CF386A.9000600@oracle.com>	<2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>	<54CF5EF3.20102@oracle.com>
	<54CFE38D.30400@oracle.com> <54D2249E.105@oracle.com>
Message-ID: <54D22CC6.9040405@gmail.com>

On 02/04/2015 02:54 PM, Chris Hegarty wrote:
> On 02/02/15 20:52, Alan Bateman wrote:
>> ....
>> I'm happy with this approach. One outstanding point from the discussion
>> is whether the URLStreamHandlerFactory implementation will need to be
>> granted RuntimePermission("setFactory"), if so then this will need to go
>> into the javadoc.
>
> I think that we should check "setFactory" for providers located
> by service loader. The most appropriate way to do this is with
> a new public abstract type who's constructor checks this,
> similar to CharsetProvider ( and others ).
>
> The updated spec revision, link below, defines the new public
> provider type in a new networking service provider interface
> package, java.net.spi. Future service provider interfaces for
> the java.net package should be defined into this package.
>
>
> http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html 
>
>
> Note:
>  The spec does no mention what happens when a SecurityException is
>  thrown ( it will be the cause of the SCE ). The prototype
>  implementation I have will will swallow it, and continue searching,
>  as is done for CharsetProviders. A SecurityException, locating
>  a provider, should not prevent the the app from making progress.
>  The provider will just not be available.
>
> -Chris.

Hi Chris,

I agree that this is the most appropriate way with which you can force 
some provider's class code (the constructor) in the call stack so that 
you get correct AccessControlContext to check against. But the name 
starts to sound like German words. :-)

Wouldn't URLStreamHandlerProvider be enough? Since it's a provider for 
URLStreamHandlers and not URLStreamHandlerFactories.


Regards, Peter



From peter.levart at gmail.com  Wed Feb  4 14:38:43 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 04 Feb 2015 15:38:43 +0100
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54D22CC6.9040405@gmail.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CD3043.2070709@gmail.com>	<54CD4A14.2080205@oracle.com>	<54CD6984.2040004@gmail.com>	<54CDF84E.7070905@oracle.com>	<54CE03D2.8000706@gmail.com>	<54CF386A.9000600@oracle.com>	<2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>	<54CF5EF3.20102@oracle.com>
	<54CFE38D.30400@oracle.com> <54D2249E.105@oracle.com>
	<54D22CC6.9040405@gmail.com>
Message-ID: <54D22EF3.1080007@gmail.com>

On 02/04/2015 03:29 PM, Peter Levart wrote:
> On 02/04/2015 02:54 PM, Chris Hegarty wrote:
>> On 02/02/15 20:52, Alan Bateman wrote:
>>> ....
>>> I'm happy with this approach. One outstanding point from the discussion
>>> is whether the URLStreamHandlerFactory implementation will need to be
>>> granted RuntimePermission("setFactory"), if so then this will need 
>>> to go
>>> into the javadoc.
>>
>> I think that we should check "setFactory" for providers located
>> by service loader. The most appropriate way to do this is with
>> a new public abstract type who's constructor checks this,
>> similar to CharsetProvider ( and others ).
>>
>> The updated spec revision, link below, defines the new public
>> provider type in a new networking service provider interface
>> package, java.net.spi. Future service provider interfaces for
>> the java.net package should be defined into this package.
>>
>>
>> http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html 
>>
>>
>> Note:
>>  The spec does no mention what happens when a SecurityException is
>>  thrown ( it will be the cause of the SCE ). The prototype
>>  implementation I have will will swallow it, and continue searching,
>>  as is done for CharsetProviders. A SecurityException, locating
>>  a provider, should not prevent the the app from making progress.
>>  The provider will just not be available.
>>
>> -Chris.
>
> Hi Chris,
>
> I agree that this is the most appropriate way with which you can force 
> some provider's class code (the constructor) in the call stack so that 
> you get correct AccessControlContext to check against. But the name 
> starts to sound like German words. :-)
>
> Wouldn't URLStreamHandlerProvider be enough? Since it's a provider for 
> URLStreamHandlers and not URLStreamHandlerFactories.
>
>
> Regards, Peter
>
>

Just a thought,...

Is JVM bytecode verifier checking that a constructor chains to super 
constructor? If yes, we are ok. If not, specially crafted bytecode could 
skip security checks.

Peter



From Alan.Bateman at oracle.com  Wed Feb  4 14:44:17 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 04 Feb 2015 14:44:17 +0000
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54D22CC6.9040405@gmail.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CD3043.2070709@gmail.com>	<54CD4A14.2080205@oracle.com>	<54CD6984.2040004@gmail.com>	<54CDF84E.7070905@oracle.com>	<54CE03D2.8000706@gmail.com>	<54CF386A.9000600@oracle.com>	<2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>	<54CF5EF3.20102@oracle.com>
	<54CFE38D.30400@oracle.com> <54D2249E.105@oracle.com>
	<54D22CC6.9040405@gmail.com>
Message-ID: <54D23041.1020703@oracle.com>

On 04/02/2015 14:29, Peter Levart wrote:
> :
>
> I agree that this is the most appropriate way with which you can force 
> some provider's class code (the constructor) in the call stack so that 
> you get correct AccessControlContext to check against. But the name 
> starts to sound like German words. :-)
>
> Wouldn't URLStreamHandlerProvider be enough? Since it's a provider for 
> URLStreamHandlers and not URLStreamHandlerFactories.
If URLStreamHandlerFactory were an abstract class rather than an 
interface then this would have been easy. I agree the naming is awkward 
as this abstract class is a URLStreamHandlerFactory rather than a 
provider of URLStreamHandlerFactory objects. Renaming it to 
URLStreamHandlerProvider seems a good idea.

-Alan


From staffan.larsen at oracle.com  Wed Feb  4 14:51:11 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 4 Feb 2015 15:51:11 +0100
Subject: RFR - 8072450: 9-dev build failed on elinux-i586 and rlinux-i586
In-Reply-To: <54D20301.9060702@oracle.com>
References: <54D20301.9060702@oracle.com>
Message-ID: <CD113CD5-BCE9-41FA-A8E2-C0C9C586E4F0@oracle.com>

Looks good!

Thanks,
/Staffan


> On 4 feb 2015, at 12:31, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a fix for:
> 
> 8072450: 9-dev build failed on elinux-i586 and rlinux-i586
> 
> My fix for JDK-8068730 which was integrated from hs-rt into jdk9-dev
> yesterday is causing a build failure in the jdk9/dev nightly on two platforms.
> It appears that these platforms have a slightly older version
> of the compiler - which chokes on jvm.cpp with the following error:
> 
> hotspot/src/share/vm/prims/jvm.cpp:307: error: integer constant is too large for ???long??? type
> 
> Adding a LL suffix should solve the issue:
> 
> ##############
> 
> diff --git a/src/share/vm/prims/jvm.cpp b/src/share/vm/prims/jvm.cpp
> --- a/src/share/vm/prims/jvm.cpp
> +++ b/src/share/vm/prims/jvm.cpp
> @@ -304,7 +304,7 @@
> // java.lang.System, but we choose to keep it here so that it stays next
> // to JVM_CurrentTimeMillis and JVM_NanoTime
> 
> -const jlong MAX_DIFF_SECS = 0x0100000000;   //  2^32
> +const jlong MAX_DIFF_SECS = 0x0100000000LL; //  2^32
> const jlong MIN_DIFF_SECS = -MAX_DIFF_SECS; // -2^32
> 
> JVM_LEAF(jlong, JVM_GetNanoTimeAdjustment(JNIEnv *env, jclass ignored, jlong offset_secs))
> 
> ##############
> 
> ( or if you prefer here is a webrev:
>  http://cr.openjdk.java.net/~dfuchs/webrev_8072450/webrev.00 )
> 
> best regards,
> 
> -- daniel
> 



From chris.hegarty at oracle.com  Wed Feb  4 15:11:38 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 04 Feb 2015 15:11:38 +0000
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54D23041.1020703@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CD3043.2070709@gmail.com>	<54CD4A14.2080205@oracle.com>	<54CD6984.2040004@gmail.com>	<54CDF84E.7070905@oracle.com>	<54CE03D2.8000706@gmail.com>	<54CF386A.9000600@oracle.com>	<2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>	<54CF5EF3.20102@oracle.com>
	<54CFE38D.30400@oracle.com> <54D2249E.105@oracle.com>
	<54D22CC6.9040405@gmail.com> <54D23041.1020703@oracle.com>
Message-ID: <54D236AA.4050406@oracle.com>

Agreed. Updated in-place
 
http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html

-Chris.

On 04/02/15 14:44, Alan Bateman wrote:
> On 04/02/2015 14:29, Peter Levart wrote:
>> :
>>
>> I agree that this is the most appropriate way with which you can force
>> some provider's class code (the constructor) in the call stack so that
>> you get correct AccessControlContext to check against. But the name
>> starts to sound like German words. :-)
>>
>> Wouldn't URLStreamHandlerProvider be enough? Since it's a provider for
>> URLStreamHandlers and not URLStreamHandlerFactories.
> If URLStreamHandlerFactory were an abstract class rather than an
> interface then this would have been easy. I agree the naming is awkward
> as this abstract class is a URLStreamHandlerFactory rather than a
> provider of URLStreamHandlerFactory objects. Renaming it to
> URLStreamHandlerProvider seems a good idea.
>
> -Alan


From weijun.wang at oracle.com  Wed Feb  4 15:10:03 2015
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 04 Feb 2015 23:10:03 +0800
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54D22EF3.1080007@gmail.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CD3043.2070709@gmail.com>	<54CD4A14.2080205@oracle.com>	<54CD6984.2040004@gmail.com>	<54CDF84E.7070905@oracle.com>	<54CE03D2.8000706@gmail.com>	<54CF386A.9000600@oracle.com>	<2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>	<54CF5EF3.20102@oracle.com>	<54CFE38D.30400@oracle.com>
	<54D2249E.105@oracle.com>	<54D22CC6.9040405@gmail.com>
	<54D22EF3.1080007@gmail.com>
Message-ID: <54D2364B.9080205@oracle.com>

It should be checked, otherwise a non-initialized parent object comes 
into being.

On 2/4/2015 22:38, Peter Levart wrote:
> Just a thought,...
>
> Is JVM bytecode verifier checking that a constructor chains to super
> constructor? If yes, we are ok. If not, specially crafted bytecode could
> skip security checks.


From Roger.Riggs at Oracle.com  Wed Feb  4 15:10:35 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 04 Feb 2015 10:10:35 -0500
Subject: RFR 9: 8067800: Unexpected DateTimeException in the
	java.time.chrono.HijrahChronology.isLeapYear
In-Reply-To: <CACzrW9A0fnRHYvOZsjcvM8d2=2oorBu2272i-mSDF1JyTO_ssA@mail.gmail.com>
References: <54D13357.2090406@Oracle.com>	<6BDD077A-A4E3-4908-AC37-2C1451A8BFCC@oracle.com>
	<CACzrW9A0fnRHYvOZsjcvM8d2=2oorBu2272i-mSDF1JyTO_ssA@mail.gmail.com>
Message-ID: <54D2366B.8010708@Oracle.com>

Hi Stephen,

I also indicated in the Jira comments that it is misleading and 
incorrect to return
false when it is not known that a year is or is not a leap year. All of 
the other
HijrahChronology computations throw DTE for invalid dates and the same 
may be
true for other Chronologies.

The assertion in Chronology.isLeapYear about not checking the range is 
too broad
and should be qualified by the Chronology.

Perhaps the proposed change should include a caveat in that method.

Roger



On 2/3/15 8:05 PM, Stephen Colebourne wrote:
> -1
>
> As I indicated on JIRA, I don't believe that this change meets the
> spec or intent of the definition on Chronology. That is specified to
> not throw any exceptions and to handle all years, valid or not.
>
> I don't foresee any significant issue where a year is not validated by
> this method. Years out of range should simply return false, again
> something that is within the spirit of the spec "a chronology that
> does not support the concept of a year must return false."
>
> Stephen
>
>
>
> On 3 February 2015 at 20:56, Lance Andersen <lance.andersen at oracle.com> wrote:
>> +1
>> On Feb 3, 2015, at 3:45 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>
>>> Please review this specification clarification of the range of Hijrah calendar variants.
>>> The issue was exposed by a bug in the HijrahChronology.isLeapYear method.
>>>
>>> Webrev:
>>>    http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/
>>>
>>> Issue:
>>>    https://bugs.openjdk.java.net/browse/JDK-8067800
>>>
>>> A CCC may be needed.
>>>
>>> Thanks, Roger
>>>
>>
>>
>> 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 scolebourne at joda.org  Wed Feb  4 15:43:45 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 4 Feb 2015 15:43:45 +0000
Subject: RFR 9: 8067800: Unexpected DateTimeException in the
	java.time.chrono.HijrahChronology.isLeapYear
In-Reply-To: <54D2366B.8010708@Oracle.com>
References: <54D13357.2090406@Oracle.com>
	<6BDD077A-A4E3-4908-AC37-2C1451A8BFCC@oracle.com>
	<CACzrW9A0fnRHYvOZsjcvM8d2=2oorBu2272i-mSDF1JyTO_ssA@mail.gmail.com>
	<54D2366B.8010708@Oracle.com>
Message-ID: <CACzrW9A0OpY+c+QLcB0vVxj0fD_zcARm6KAK6dgwxk=nmnbAYg@mail.gmail.com>

The java.time code generally takes a lenient approach to methods that
return a boolean. For example, they tend to accept null inputs without
throwing an exception.

Right now, this patch makes a subclass implementation incompatible
with the superclass spec. That cannot happen. Thus there are only two
options:

- change the superclass spec
- return false from the subclass

I favour the latter as being in line with the rest of the package and
less disruptive to existing users (would a CCC even pass?)

Stephen


On 4 February 2015 at 15:10, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> Hi Stephen,
>
> I also indicated in the Jira comments that it is misleading and incorrect to
> return
> false when it is not known that a year is or is not a leap year. All of the
> other
> HijrahChronology computations throw DTE for invalid dates and the same may
> be
> true for other Chronologies.
>
> The assertion in Chronology.isLeapYear about not checking the range is too
> broad
> and should be qualified by the Chronology.
>
> Perhaps the proposed change should include a caveat in that method.
>
> Roger
>
>
>
>
> On 2/3/15 8:05 PM, Stephen Colebourne wrote:
>>
>> -1
>>
>> As I indicated on JIRA, I don't believe that this change meets the
>> spec or intent of the definition on Chronology. That is specified to
>> not throw any exceptions and to handle all years, valid or not.
>>
>> I don't foresee any significant issue where a year is not validated by
>> this method. Years out of range should simply return false, again
>> something that is within the spirit of the spec "a chronology that
>> does not support the concept of a year must return false."
>>
>> Stephen
>>
>>
>>
>> On 3 February 2015 at 20:56, Lance Andersen <lance.andersen at oracle.com>
>> wrote:
>>>
>>> +1
>>> On Feb 3, 2015, at 3:45 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>
>>>> Please review this specification clarification of the range of Hijrah
>>>> calendar variants.
>>>> The issue was exposed by a bug in the HijrahChronology.isLeapYear
>>>> method.
>>>>
>>>> Webrev:
>>>>    http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/
>>>>
>>>> Issue:
>>>>    https://bugs.openjdk.java.net/browse/JDK-8067800
>>>>
>>>> A CCC may be needed.
>>>>
>>>> Thanks, Roger
>>>>
>>>
>>>
>>> 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 Alan.Bateman at oracle.com  Wed Feb  4 15:45:50 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 04 Feb 2015 15:45:50 +0000
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54D2364B.9080205@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CD3043.2070709@gmail.com>	<54CD4A14.2080205@oracle.com>	<54CD6984.2040004@gmail.com>	<54CDF84E.7070905@oracle.com>	<54CE03D2.8000706@gmail.com>	<54CF386A.9000600@oracle.com>	<2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>	<54CF5EF3.20102@oracle.com>	<54CFE38D.30400@oracle.com>
	<54D2249E.105@oracle.com>	<54D22CC6.9040405@gmail.com>
	<54D22EF3.1080007@gmail.com> <54D2364B.9080205@oracle.com>
Message-ID: <54D23EAE.4020200@oracle.com>

On 04/02/2015 15:10, Weijun Wang wrote:
> It should be checked, otherwise a non-initialized parent object comes 
> into being.
In general then permission checks in constructors are a bad idea but we 
have an established idiom that has the no-arg constructor invoking a 
static method that does the permission check.

-Alan


From peter.levart at gmail.com  Wed Feb  4 16:01:11 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 04 Feb 2015 17:01:11 +0100
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54D23EAE.4020200@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CD3043.2070709@gmail.com>	<54CD4A14.2080205@oracle.com>	<54CD6984.2040004@gmail.com>	<54CDF84E.7070905@oracle.com>	<54CE03D2.8000706@gmail.com>	<54CF386A.9000600@oracle.com>	<2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>	<54CF5EF3.20102@oracle.com>	<54CFE38D.30400@oracle.com>
	<54D2249E.105@oracle.com>	<54D22CC6.9040405@gmail.com>
	<54D22EF3.1080007@gmail.com> <54D2364B.9080205@oracle.com>
	<54D23EAE.4020200@oracle.com>
Message-ID: <54D24247.50509@gmail.com>

On 02/04/2015 04:45 PM, Alan Bateman wrote:
> On 04/02/2015 15:10, Weijun Wang wrote:
>> It should be checked, otherwise a non-initialized parent object comes 
>> into being.
> In general then permission checks in constructors are a bad idea but 
> we have an established idiom that has the no-arg constructor invoking 
> a static method that does the permission check.
>
> -Alan

There is an alternative. The 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTrustPermission(Class<?>) 
checks the permission without running any code of the class. But if 
verify-er checks constructor flow then this is as good as proposed.


Peter


From Roger.Riggs at Oracle.com  Wed Feb  4 16:05:22 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 04 Feb 2015 11:05:22 -0500
Subject: RFR 9: 8067800: Unexpected DateTimeException in the
	java.time.chrono.HijrahChronology.isLeapYear
In-Reply-To: <CACzrW9A0OpY+c+QLcB0vVxj0fD_zcARm6KAK6dgwxk=nmnbAYg@mail.gmail.com>
References: <54D13357.2090406@Oracle.com>	<6BDD077A-A4E3-4908-AC37-2C1451A8BFCC@oracle.com>	<CACzrW9A0fnRHYvOZsjcvM8d2=2oorBu2272i-mSDF1JyTO_ssA@mail.gmail.com>	<54D2366B.8010708@Oracle.com>
	<CACzrW9A0OpY+c+QLcB0vVxj0fD_zcARm6KAK6dgwxk=nmnbAYg@mail.gmail.com>
Message-ID: <54D24342.3060107@Oracle.com>

Hi Stephen,

On 2/4/15 10:43 AM, Stephen Colebourne wrote:
> The java.time code generally takes a lenient approach to methods that
> return a boolean. For example, they tend to accept null inputs without
> throwing an exception.
Seems like an odd design provision leading to some behavior that
would be inconsistent with non-boolean methods.
>
> Right now, this patch makes a subclass implementation incompatible
> with the superclass spec. That cannot happen. Thus there are only two
> options:
>
> - change the superclass spec
> - return false from the subclass
>
> I favour the latter as being in line with the rest of the package and
> less disruptive to existing users (would a CCC even pass?)
For a 'young' API with limited uptake, issues can be fixed early and in 
a major
release there is more flexibility to clarify the specification.

DTE is a runtime exception and can occur in a majority of time computations.
In the case of HijrahChronolog.isLeapYear, the implementation currently
throws a different RuntimeException and this would be a correction
to the conventional exception.

Roger

>
> Stephen
>
>
> On 4 February 2015 at 15:10, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>> Hi Stephen,
>>
>> I also indicated in the Jira comments that it is misleading and incorrect to
>> return
>> false when it is not known that a year is or is not a leap year. All of the
>> other
>> HijrahChronology computations throw DTE for invalid dates and the same may
>> be
>> true for other Chronologies.
>>
>> The assertion in Chronology.isLeapYear about not checking the range is too
>> broad
>> and should be qualified by the Chronology.
>>
>> Perhaps the proposed change should include a caveat in that method.
>>
>> Roger
>>
>>
>>
>>
>> On 2/3/15 8:05 PM, Stephen Colebourne wrote:
>>> -1
>>>
>>> As I indicated on JIRA, I don't believe that this change meets the
>>> spec or intent of the definition on Chronology. That is specified to
>>> not throw any exceptions and to handle all years, valid or not.
>>>
>>> I don't foresee any significant issue where a year is not validated by
>>> this method. Years out of range should simply return false, again
>>> something that is within the spirit of the spec "a chronology that
>>> does not support the concept of a year must return false."
>>>
>>> Stephen
>>>
>>>
>>>
>>> On 3 February 2015 at 20:56, Lance Andersen <lance.andersen at oracle.com>
>>> wrote:
>>>> +1
>>>> On Feb 3, 2015, at 3:45 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>>
>>>>> Please review this specification clarification of the range of Hijrah
>>>>> calendar variants.
>>>>> The issue was exposed by a bug in the HijrahChronology.isLeapYear
>>>>> method.
>>>>>
>>>>> Webrev:
>>>>>     http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/
>>>>>
>>>>> Issue:
>>>>>     https://bugs.openjdk.java.net/browse/JDK-8067800
>>>>>
>>>>> A CCC may be needed.
>>>>>
>>>>> Thanks, Roger
>>>>>
>>>>
>>>> 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 chris.hegarty at oracle.com  Wed Feb  4 16:19:19 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 04 Feb 2015 16:19:19 +0000
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54D24247.50509@gmail.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CD3043.2070709@gmail.com>	<54CD4A14.2080205@oracle.com>	<54CD6984.2040004@gmail.com>	<54CDF84E.7070905@oracle.com>	<54CE03D2.8000706@gmail.com>	<54CF386A.9000600@oracle.com>	<2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>	<54CF5EF3.20102@oracle.com>	<54CFE38D.30400@oracle.com>
	<54D2249E.105@oracle.com>	<54D22CC6.9040405@gmail.com>
	<54D22EF3.1080007@gmail.com> <54D2364B.9080205@oracle.com>
	<54D23EAE.4020200@oracle.com> <54D24247.50509@gmail.com>
Message-ID: <54D24687.2020704@oracle.com>

On 04/02/15 16:01, Peter Levart wrote:
> On 02/04/2015 04:45 PM, Alan Bateman wrote:
>> On 04/02/2015 15:10, Weijun Wang wrote:
>>> It should be checked, otherwise a non-initialized parent object comes
>>> into being.
>> In general then permission checks in constructors are a bad idea but
>> we have an established idiom that has the no-arg constructor invoking
>> a static method that does the permission check.
>>
>> -Alan
>
> There is an alternative. The
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTrustPermission(Class<?>)
> checks the permission without running any code of the class.

I did look at checking the permission of the impl class, but with 
service loader this would have to be done after the instance is created, 
which in itself should not be a big issue here as the provider would not 
be used by java.net.URL, but the side-effect is that we end up creating 
an instance that will not be used.

 > But if
> verify-er checks constructor flow then this is as good as proposed.

I am happy that the verifier will catch this. This is an established 
idiom that has been used in other, more sensitive, areas.

I'll see if I can prove this with an out-of-order compilation, or something.

-Chris.



From scolebourne at joda.org  Wed Feb  4 16:18:22 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 4 Feb 2015 16:18:22 +0000
Subject: RFR 9: 8067800: Unexpected DateTimeException in the
	java.time.chrono.HijrahChronology.isLeapYear
In-Reply-To: <54D24342.3060107@Oracle.com>
References: <54D13357.2090406@Oracle.com>
	<6BDD077A-A4E3-4908-AC37-2C1451A8BFCC@oracle.com>
	<CACzrW9A0fnRHYvOZsjcvM8d2=2oorBu2272i-mSDF1JyTO_ssA@mail.gmail.com>
	<54D2366B.8010708@Oracle.com>
	<CACzrW9A0OpY+c+QLcB0vVxj0fD_zcARm6KAK6dgwxk=nmnbAYg@mail.gmail.com>
	<54D24342.3060107@Oracle.com>
Message-ID: <CACzrW9BK38RFQp9nofsUV=a4Efbo118Xf4Dg5qWESPbaU_H3qg@mail.gmail.com>

The spec is pretty clear:
"the proleptic-year to check, not validated for range"

Adding an exception to the spec would cause requests to add exceptions
to all other chronologies. Doing so, would be very negative to
performance (it would require having a non-public copy of the logic
elsewhere to avoid the range checking cost.

Adding an exception to Hijrah only means that the implementation is
doing something not permitted by the spec.

The only sane choice here is to return false from Hijrah when out of
range. As intended and as specced.

Note that I don't believe that returning false will cause hardship in
any actual user code, because other methods will constrain the year to
be valid.

If necessary, the following spec clarification could be added to the
bullet points on Chronology:

<li>if the year is out of range the chronology should return a best
effort guess, or false if there is no suitable guess

Stephen


On 4 February 2015 at 16:05, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> Hi Stephen,
>
> On 2/4/15 10:43 AM, Stephen Colebourne wrote:
>>
>> The java.time code generally takes a lenient approach to methods that
>> return a boolean. For example, they tend to accept null inputs without
>> throwing an exception.
>
> Seems like an odd design provision leading to some behavior that
> would be inconsistent with non-boolean methods.
>>
>>
>> Right now, this patch makes a subclass implementation incompatible
>> with the superclass spec. That cannot happen. Thus there are only two
>> options:
>>
>> - change the superclass spec
>> - return false from the subclass
>>
>> I favour the latter as being in line with the rest of the package and
>> less disruptive to existing users (would a CCC even pass?)
>
> For a 'young' API with limited uptake, issues can be fixed early and in a
> major
> release there is more flexibility to clarify the specification.
>
> DTE is a runtime exception and can occur in a majority of time computations.
> In the case of HijrahChronolog.isLeapYear, the implementation currently
> throws a different RuntimeException and this would be a correction
> to the conventional exception.
>
> Roger
>
>
>>
>> Stephen
>>
>>
>> On 4 February 2015 at 15:10, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>
>>> Hi Stephen,
>>>
>>> I also indicated in the Jira comments that it is misleading and incorrect
>>> to
>>> return
>>> false when it is not known that a year is or is not a leap year. All of
>>> the
>>> other
>>> HijrahChronology computations throw DTE for invalid dates and the same
>>> may
>>> be
>>> true for other Chronologies.
>>>
>>> The assertion in Chronology.isLeapYear about not checking the range is
>>> too
>>> broad
>>> and should be qualified by the Chronology.
>>>
>>> Perhaps the proposed change should include a caveat in that method.
>>>
>>> Roger
>>>
>>>
>>>
>>>
>>> On 2/3/15 8:05 PM, Stephen Colebourne wrote:
>>>>
>>>> -1
>>>>
>>>> As I indicated on JIRA, I don't believe that this change meets the
>>>> spec or intent of the definition on Chronology. That is specified to
>>>> not throw any exceptions and to handle all years, valid or not.
>>>>
>>>> I don't foresee any significant issue where a year is not validated by
>>>> this method. Years out of range should simply return false, again
>>>> something that is within the spirit of the spec "a chronology that
>>>> does not support the concept of a year must return false."
>>>>
>>>> Stephen
>>>>
>>>>
>>>>
>>>> On 3 February 2015 at 20:56, Lance Andersen <lance.andersen at oracle.com>
>>>> wrote:
>>>>>
>>>>> +1
>>>>> On Feb 3, 2015, at 3:45 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>>>
>>>>>> Please review this specification clarification of the range of Hijrah
>>>>>> calendar variants.
>>>>>> The issue was exposed by a bug in the HijrahChronology.isLeapYear
>>>>>> method.
>>>>>>
>>>>>> Webrev:
>>>>>>     http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/
>>>>>>
>>>>>> Issue:
>>>>>>     https://bugs.openjdk.java.net/browse/JDK-8067800
>>>>>>
>>>>>> A CCC may be needed.
>>>>>>
>>>>>> Thanks, Roger
>>>>>>
>>>>>
>>>>> 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 christian.thalinger at oracle.com  Wed Feb  4 16:21:01 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 4 Feb 2015 08:21:01 -0800
Subject: RFR - 8072450: 9-dev build failed on elinux-i586 and rlinux-i586
In-Reply-To: <54D20301.9060702@oracle.com>
References: <54D20301.9060702@oracle.com>
Message-ID: <079734CE-1213-4AF2-8818-780024D58F49@oracle.com>


> On Feb 4, 2015, at 3:31 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a fix for:
> 
> 8072450: 9-dev build failed on elinux-i586 and rlinux-i586
> 
> My fix for JDK-8068730 which was integrated from hs-rt into jdk9-dev
> yesterday is causing a build failure in the jdk9/dev nightly on two platforms.
> It appears that these platforms have a slightly older version
> of the compiler - which chokes on jvm.cpp with the following error:
> 
> hotspot/src/share/vm/prims/jvm.cpp:307: error: integer constant is too large for ???long??? type
> 
> Adding a LL suffix should solve the issue:
> 
> ##############
> 
> diff --git a/src/share/vm/prims/jvm.cpp b/src/share/vm/prims/jvm.cpp
> --- a/src/share/vm/prims/jvm.cpp
> +++ b/src/share/vm/prims/jvm.cpp
> @@ -304,7 +304,7 @@
> // java.lang.System, but we choose to keep it here so that it stays next
> // to JVM_CurrentTimeMillis and JVM_NanoTime
> 
> -const jlong MAX_DIFF_SECS = 0x0100000000;   //  2^32
> +const jlong MAX_DIFF_SECS = 0x0100000000LL; //  2^32

Don?t use LL directly; we have a compiler-dependent macro for this:

CONST64

> const jlong MIN_DIFF_SECS = -MAX_DIFF_SECS; // -2^32
> 
> JVM_LEAF(jlong, JVM_GetNanoTimeAdjustment(JNIEnv *env, jclass ignored, jlong offset_secs))
> 
> ##############
> 
> ( or if you prefer here is a webrev:
>  http://cr.openjdk.java.net/~dfuchs/webrev_8072450/webrev.00 )
> 
> best regards,
> 
> -- daniel
> 



From daniel.fuchs at oracle.com  Wed Feb  4 17:44:41 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 04 Feb 2015 18:44:41 +0100
Subject: RFR - 8072450: 9-dev build failed on elinux-i586 and rlinux-i586
In-Reply-To: <079734CE-1213-4AF2-8818-780024D58F49@oracle.com>
References: <54D20301.9060702@oracle.com>
	<079734CE-1213-4AF2-8818-780024D58F49@oracle.com>
Message-ID: <54D25A89.7060205@oracle.com>

On 04/02/15 17:21, Christian Thalinger wrote:
>>
>> -const jlong MAX_DIFF_SECS = 0x0100000000;   //  2^32
>> +const jlong MAX_DIFF_SECS = 0x0100000000LL; //  2^32
>
> Don?t use LL directly; we have a compiler-dependent macro for this:
>
> CONST64
>

Hi Christian,

I have pushed the change as it was reviewed by David, Coleen, & Staffan.

I have logged https://bugs.openjdk.java.net/browse/JDK-8072482
(assigned to myself) as a followup bug.

best regards,

-- daniel


From Roger.Riggs at Oracle.com  Wed Feb  4 19:08:09 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 04 Feb 2015 14:08:09 -0500
Subject: RFR 9: 8067800: Unexpected DateTimeException in the
	java.time.chrono.HijrahChronology.isLeapYear
In-Reply-To: <CACzrW9BK38RFQp9nofsUV=a4Efbo118Xf4Dg5qWESPbaU_H3qg@mail.gmail.com>
References: <54D13357.2090406@Oracle.com>	<6BDD077A-A4E3-4908-AC37-2C1451A8BFCC@oracle.com>	<CACzrW9A0fnRHYvOZsjcvM8d2=2oorBu2272i-mSDF1JyTO_ssA@mail.gmail.com>	<54D2366B.8010708@Oracle.com>	<CACzrW9A0OpY+c+QLcB0vVxj0fD_zcARm6KAK6dgwxk=nmnbAYg@mail.gmail.com>	<54D24342.3060107@Oracle.com>
	<CACzrW9BK38RFQp9nofsUV=a4Efbo118Xf4Dg5qWESPbaU_H3qg@mail.gmail.com>
Message-ID: <54D26E19.4040604@Oracle.com>

Hi,

Clarifying that Chronology.isLeapYear is specified only within the range 
of the chronology
makes it possible to maintain the invariants with the calendar 
computations and methods.
Best effort isn't testable except in an implementation specific way and 
can't be relied on.

The other two constraints are testable and use 'must' in their definitions.
The new phrasing should clearly be either an exception or reinforce the 
value is
specified only within the range of the chronology.

How about:

<li>except if the year is out of range the chronology should return a best
effort guess, or false if there is no suitable guess

Roger


On 2/4/2015 11:18 AM, Stephen Colebourne wrote:
> The spec is pretty clear:
> "the proleptic-year to check, not validated for range"
>
> Adding an exception to the spec would cause requests to add exceptions
> to all other chronologies. Doing so, would be very negative to
> performance (it would require having a non-public copy of the logic
> elsewhere to avoid the range checking cost.
>
> Adding an exception to Hijrah only means that the implementation is
> doing something not permitted by the spec.
>
> The only sane choice here is to return false from Hijrah when out of
> range. As intended and as specced.
>
> Note that I don't believe that returning false will cause hardship in
> any actual user code, because other methods will constrain the year to
> be valid.
>
> If necessary, the following spec clarification could be added to the
> bullet points on Chronology:
>
> <li>if the year is out of range the chronology should return a best
> effort guess, or false if there is no suitable guess
>
> Stephen
>
>
> On 4 February 2015 at 16:05, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>> Hi Stephen,
>>
>> On 2/4/15 10:43 AM, Stephen Colebourne wrote:
>>> The java.time code generally takes a lenient approach to methods that
>>> return a boolean. For example, they tend to accept null inputs without
>>> throwing an exception.
>> Seems like an odd design provision leading to some behavior that
>> would be inconsistent with non-boolean methods.
>>>
>>> Right now, this patch makes a subclass implementation incompatible
>>> with the superclass spec. That cannot happen. Thus there are only two
>>> options:
>>>
>>> - change the superclass spec
>>> - return false from the subclass
>>>
>>> I favour the latter as being in line with the rest of the package and
>>> less disruptive to existing users (would a CCC even pass?)
>> For a 'young' API with limited uptake, issues can be fixed early and in a
>> major
>> release there is more flexibility to clarify the specification.
>>
>> DTE is a runtime exception and can occur in a majority of time computations.
>> In the case of HijrahChronolog.isLeapYear, the implementation currently
>> throws a different RuntimeException and this would be a correction
>> to the conventional exception.
>>
>> Roger
>>
>>
>>> Stephen
>>>
>>>
>>> On 4 February 2015 at 15:10, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>> Hi Stephen,
>>>>
>>>> I also indicated in the Jira comments that it is misleading and incorrect
>>>> to
>>>> return
>>>> false when it is not known that a year is or is not a leap year. All of
>>>> the
>>>> other
>>>> HijrahChronology computations throw DTE for invalid dates and the same
>>>> may
>>>> be
>>>> true for other Chronologies.
>>>>
>>>> The assertion in Chronology.isLeapYear about not checking the range is
>>>> too
>>>> broad
>>>> and should be qualified by the Chronology.
>>>>
>>>> Perhaps the proposed change should include a caveat in that method.
>>>>
>>>> Roger
>>>>
>>>>
>>>>
>>>>
>>>> On 2/3/15 8:05 PM, Stephen Colebourne wrote:
>>>>> -1
>>>>>
>>>>> As I indicated on JIRA, I don't believe that this change meets the
>>>>> spec or intent of the definition on Chronology. That is specified to
>>>>> not throw any exceptions and to handle all years, valid or not.
>>>>>
>>>>> I don't foresee any significant issue where a year is not validated by
>>>>> this method. Years out of range should simply return false, again
>>>>> something that is within the spirit of the spec "a chronology that
>>>>> does not support the concept of a year must return false."
>>>>>
>>>>> Stephen
>>>>>
>>>>>
>>>>>
>>>>> On 3 February 2015 at 20:56, Lance Andersen <lance.andersen at oracle.com>
>>>>> wrote:
>>>>>> +1
>>>>>> On Feb 3, 2015, at 3:45 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>>>>
>>>>>>> Please review this specification clarification of the range of Hijrah
>>>>>>> calendar variants.
>>>>>>> The issue was exposed by a bug in the HijrahChronology.isLeapYear
>>>>>>> method.
>>>>>>>
>>>>>>> Webrev:
>>>>>>>      http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/
>>>>>>>
>>>>>>> Issue:
>>>>>>>      https://bugs.openjdk.java.net/browse/JDK-8067800
>>>>>>>
>>>>>>> A CCC may be needed.
>>>>>>>
>>>>>>> Thanks, Roger
>>>>>>>
>>>>>> 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  Wed Feb  4 19:48:57 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 04 Feb 2015 20:48:57 +0100
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54D24687.2020704@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CD3043.2070709@gmail.com>	<54CD4A14.2080205@oracle.com>	<54CD6984.2040004@gmail.com>	<54CDF84E.7070905@oracle.com>	<54CE03D2.8000706@gmail.com>	<54CF386A.9000600@oracle.com>	<2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>	<54CF5EF3.20102@oracle.com>	<54CFE38D.30400@oracle.com>
	<54D2249E.105@oracle.com>	<54D22CC6.9040405@gmail.com>
	<54D22EF3.1080007@gmail.com> <54D2364B.9080205@oracle.com>
	<54D23EAE.4020200@oracle.com> <54D24247.50509@gmail.com>
	<54D24687.2020704@oracle.com>
Message-ID: <54D277A9.2000505@gmail.com>


On 02/04/2015 05:19 PM, Chris Hegarty wrote:
> On 04/02/15 16:01, Peter Levart wrote:
>> On 02/04/2015 04:45 PM, Alan Bateman wrote:
>>> On 04/02/2015 15:10, Weijun Wang wrote:
>>>> It should be checked, otherwise a non-initialized parent object comes
>>>> into being.
>>> In general then permission checks in constructors are a bad idea but
>>> we have an established idiom that has the no-arg constructor invoking
>>> a static method that does the permission check.
>>>
>>> -Alan
>>
>> There is an alternative. The
>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTrustPermission(Class<?>) 
>>
>> checks the permission without running any code of the class.
>
> I did look at checking the permission of the impl class, but with 
> service loader this would have to be done after the instance is 
> created, which in itself should not be a big issue here as the 
> provider would not be used by java.net.URL, but the side-effect is 
> that we end up creating an instance that will not be used.
>
> > But if
>> verify-er checks constructor flow then this is as good as proposed.
>
> I am happy that the verifier will catch this. This is an established 
> idiom that has been used in other, more sensitive, areas.
>
> I'll see if I can prove this with an out-of-order compilation, or 
> something.
>
> -Chris.
>

The idiom with constructor is also more correct from security standpoint 
as all the constructors in class hierarchy are on the call-stack when 
the check is made. If particular classes from the hierarchy have 
separate protection domains, the check covers all of them and that's 
correct since code from any or all of them could be involved in later 
URL constructions.

Peter


From christian.thalinger at oracle.com  Wed Feb  4 20:17:13 2015
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 4 Feb 2015 12:17:13 -0800
Subject: RFR - 8072450: 9-dev build failed on elinux-i586 and rlinux-i586
In-Reply-To: <54D25A89.7060205@oracle.com>
References: <54D20301.9060702@oracle.com>
	<079734CE-1213-4AF2-8818-780024D58F49@oracle.com>
	<54D25A89.7060205@oracle.com>
Message-ID: <46922D85-7A38-4F49-BD97-5ADF2A3B6F0D@oracle.com>


> On Feb 4, 2015, at 9:44 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> On 04/02/15 17:21, Christian Thalinger wrote:
>>> 
>>> -const jlong MAX_DIFF_SECS = 0x0100000000;   //  2^32
>>> +const jlong MAX_DIFF_SECS = 0x0100000000LL; //  2^32
>> 
>> Don?t use LL directly; we have a compiler-dependent macro for this:
>> 
>> CONST64
>> 
> 
> Hi Christian,
> 
> I have pushed the change as it was reviewed by David, Coleen, & Staffan.
> 
> I have logged https://bugs.openjdk.java.net/browse/JDK-8072482
> (assigned to myself) as a followup bug.

That?s fine, thanks.  Maybe you can fix a couple other places where LL-usage crept in too.

> 
> best regards,
> 
> -- daniel



From lance.andersen at oracle.com  Wed Feb  4 20:23:50 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 4 Feb 2015 15:23:50 -0500
Subject: RFR 9: 8067800: Unexpected DateTimeException in the
	java.time.chrono.HijrahChronology.isLeapYear
In-Reply-To: <54D26E19.4040604@Oracle.com>
References: <54D13357.2090406@Oracle.com>	<6BDD077A-A4E3-4908-AC37-2C1451A8BFCC@oracle.com>	<CACzrW9A0fnRHYvOZsjcvM8d2=2oorBu2272i-mSDF1JyTO_ssA@mail.gmail.com>	<54D2366B.8010708@Oracle.com>	<CACzrW9A0OpY+c+QLcB0vVxj0fD_zcARm6KAK6dgwxk=nmnbAYg@mail.gmail.com>	<54D24342.3060107@Oracle.com>
	<CACzrW9BK38RFQp9nofsUV=a4Efbo118Xf4Dg5qWESPbaU_H3qg@mail.gmail.com>
	<54D26E19.4040604@Oracle.com>
Message-ID: <5F7DC162-CD08-4B49-B3ED-B4FF065D7C3B@oracle.com>

Hi Roger,

I think I know what this is trying to say, but if possible, could you provide the revised javadoc so it is easier to see the full context?

Best
Lance
On Feb 4, 2015, at 2:08 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi,
> 
> Clarifying that Chronology.isLeapYear is specified only within the range of the chronology
> makes it possible to maintain the invariants with the calendar computations and methods.
> Best effort isn't testable except in an implementation specific way and can't be relied on.
> 
> The other two constraints are testable and use 'must' in their definitions.
> The new phrasing should clearly be either an exception or reinforce the value is
> specified only within the range of the chronology.
> 
> How about:
> 
> <li>except if the year is out of range the chronology should return a best
> effort guess, or false if there is no suitable guess
> 
> Roger
> 
> 
> On 2/4/2015 11:18 AM, Stephen Colebourne wrote:
>> The spec is pretty clear:
>> "the proleptic-year to check, not validated for range"
>> 
>> Adding an exception to the spec would cause requests to add exceptions
>> to all other chronologies. Doing so, would be very negative to
>> performance (it would require having a non-public copy of the logic
>> elsewhere to avoid the range checking cost.
>> 
>> Adding an exception to Hijrah only means that the implementation is
>> doing something not permitted by the spec.
>> 
>> The only sane choice here is to return false from Hijrah when out of
>> range. As intended and as specced.
>> 
>> Note that I don't believe that returning false will cause hardship in
>> any actual user code, because other methods will constrain the year to
>> be valid.
>> 
>> If necessary, the following spec clarification could be added to the
>> bullet points on Chronology:
>> 
>> <li>if the year is out of range the chronology should return a best
>> effort guess, or false if there is no suitable guess
>> 
>> Stephen
>> 
>> 
>> On 4 February 2015 at 16:05, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>> Hi Stephen,
>>> 
>>> On 2/4/15 10:43 AM, Stephen Colebourne wrote:
>>>> The java.time code generally takes a lenient approach to methods that
>>>> return a boolean. For example, they tend to accept null inputs without
>>>> throwing an exception.
>>> Seems like an odd design provision leading to some behavior that
>>> would be inconsistent with non-boolean methods.
>>>> 
>>>> Right now, this patch makes a subclass implementation incompatible
>>>> with the superclass spec. That cannot happen. Thus there are only two
>>>> options:
>>>> 
>>>> - change the superclass spec
>>>> - return false from the subclass
>>>> 
>>>> I favour the latter as being in line with the rest of the package and
>>>> less disruptive to existing users (would a CCC even pass?)
>>> For a 'young' API with limited uptake, issues can be fixed early and in a
>>> major
>>> release there is more flexibility to clarify the specification.
>>> 
>>> DTE is a runtime exception and can occur in a majority of time computations.
>>> In the case of HijrahChronolog.isLeapYear, the implementation currently
>>> throws a different RuntimeException and this would be a correction
>>> to the conventional exception.
>>> 
>>> Roger
>>> 
>>> 
>>>> Stephen
>>>> 
>>>> 
>>>> On 4 February 2015 at 15:10, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>>> Hi Stephen,
>>>>> 
>>>>> I also indicated in the Jira comments that it is misleading and incorrect
>>>>> to
>>>>> return
>>>>> false when it is not known that a year is or is not a leap year. All of
>>>>> the
>>>>> other
>>>>> HijrahChronology computations throw DTE for invalid dates and the same
>>>>> may
>>>>> be
>>>>> true for other Chronologies.
>>>>> 
>>>>> The assertion in Chronology.isLeapYear about not checking the range is
>>>>> too
>>>>> broad
>>>>> and should be qualified by the Chronology.
>>>>> 
>>>>> Perhaps the proposed change should include a caveat in that method.
>>>>> 
>>>>> Roger
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 2/3/15 8:05 PM, Stephen Colebourne wrote:
>>>>>> -1
>>>>>> 
>>>>>> As I indicated on JIRA, I don't believe that this change meets the
>>>>>> spec or intent of the definition on Chronology. That is specified to
>>>>>> not throw any exceptions and to handle all years, valid or not.
>>>>>> 
>>>>>> I don't foresee any significant issue where a year is not validated by
>>>>>> this method. Years out of range should simply return false, again
>>>>>> something that is within the spirit of the spec "a chronology that
>>>>>> does not support the concept of a year must return false."
>>>>>> 
>>>>>> Stephen
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 3 February 2015 at 20:56, Lance Andersen <lance.andersen at oracle.com>
>>>>>> wrote:
>>>>>>> +1
>>>>>>> On Feb 3, 2015, at 3:45 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>>>>> 
>>>>>>>> Please review this specification clarification of the range of Hijrah
>>>>>>>> calendar variants.
>>>>>>>> The issue was exposed by a bug in the HijrahChronology.isLeapYear
>>>>>>>> method.
>>>>>>>> 
>>>>>>>> Webrev:
>>>>>>>>     http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/
>>>>>>>> 
>>>>>>>> Issue:
>>>>>>>>     https://bugs.openjdk.java.net/browse/JDK-8067800
>>>>>>>> 
>>>>>>>> A CCC may be needed.
>>>>>>>> 
>>>>>>>> Thanks, Roger
>>>>>>>> 
>>>>>>> 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 scolebourne at joda.org  Wed Feb  4 20:42:02 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 4 Feb 2015 20:42:02 +0000
Subject: RFR 9: 8067800: Unexpected DateTimeException in the
	java.time.chrono.HijrahChronology.isLeapYear
In-Reply-To: <54D26E19.4040604@Oracle.com>
References: <54D13357.2090406@Oracle.com>
	<6BDD077A-A4E3-4908-AC37-2C1451A8BFCC@oracle.com>
	<CACzrW9A0fnRHYvOZsjcvM8d2=2oorBu2272i-mSDF1JyTO_ssA@mail.gmail.com>
	<54D2366B.8010708@Oracle.com>
	<CACzrW9A0OpY+c+QLcB0vVxj0fD_zcARm6KAK6dgwxk=nmnbAYg@mail.gmail.com>
	<54D24342.3060107@Oracle.com>
	<CACzrW9BK38RFQp9nofsUV=a4Efbo118Xf4Dg5qWESPbaU_H3qg@mail.gmail.com>
	<54D26E19.4040604@Oracle.com>
Message-ID: <CACzrW9CUPnq+ecvXMW90-6rA5f_i-Fe_2Fj6y4-vqNxeKNhKPA@mail.gmail.com>

I think this might be clearer:

* Checks if the specified year is a leap year.
* <p>
* A leap-year is a year of a longer length than normal.
* The exact meaning is determined by the chronology according to the
following constraints.
* <ul>
* <li>a leap-year must imply a year-length longer than a non leap-year.
* <li>a chronology that does not support the concept of a year must
return false.
* <li>the correct result must be returned for all years within the
valid range of years for the chronology
* </ul>
* Outside the range of valid years an implementation is free to return
either a best guess or false.
* An implementation must not throw an exception, even if the year is
outside the range of valid years..

Stephen



On 4 February 2015 at 19:08, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> Hi,
>
> Clarifying that Chronology.isLeapYear is specified only within the range of
> the chronology
> makes it possible to maintain the invariants with the calendar computations
> and methods.
> Best effort isn't testable except in an implementation specific way and
> can't be relied on.
>
> The other two constraints are testable and use 'must' in their definitions.
> The new phrasing should clearly be either an exception or reinforce the
> value is
> specified only within the range of the chronology.
>
> How about:
>
> <li>except if the year is out of range the chronology should return a best
> effort guess, or false if there is no suitable guess
>
> Roger
>
>
>
> On 2/4/2015 11:18 AM, Stephen Colebourne wrote:
>>
>> The spec is pretty clear:
>> "the proleptic-year to check, not validated for range"
>>
>> Adding an exception to the spec would cause requests to add exceptions
>> to all other chronologies. Doing so, would be very negative to
>> performance (it would require having a non-public copy of the logic
>> elsewhere to avoid the range checking cost.
>>
>> Adding an exception to Hijrah only means that the implementation is
>> doing something not permitted by the spec.
>>
>> The only sane choice here is to return false from Hijrah when out of
>> range. As intended and as specced.
>>
>> Note that I don't believe that returning false will cause hardship in
>> any actual user code, because other methods will constrain the year to
>> be valid.
>>
>> If necessary, the following spec clarification could be added to the
>> bullet points on Chronology:
>>
>> <li>if the year is out of range the chronology should return a best
>> effort guess, or false if there is no suitable guess
>>
>> Stephen
>>
>>
>> On 4 February 2015 at 16:05, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>
>>> Hi Stephen,
>>>
>>> On 2/4/15 10:43 AM, Stephen Colebourne wrote:
>>>>
>>>> The java.time code generally takes a lenient approach to methods that
>>>> return a boolean. For example, they tend to accept null inputs without
>>>> throwing an exception.
>>>
>>> Seems like an odd design provision leading to some behavior that
>>> would be inconsistent with non-boolean methods.
>>>>
>>>>
>>>> Right now, this patch makes a subclass implementation incompatible
>>>> with the superclass spec. That cannot happen. Thus there are only two
>>>> options:
>>>>
>>>> - change the superclass spec
>>>> - return false from the subclass
>>>>
>>>> I favour the latter as being in line with the rest of the package and
>>>> less disruptive to existing users (would a CCC even pass?)
>>>
>>> For a 'young' API with limited uptake, issues can be fixed early and in a
>>> major
>>> release there is more flexibility to clarify the specification.
>>>
>>> DTE is a runtime exception and can occur in a majority of time
>>> computations.
>>> In the case of HijrahChronolog.isLeapYear, the implementation currently
>>> throws a different RuntimeException and this would be a correction
>>> to the conventional exception.
>>>
>>> Roger
>>>
>>>
>>>> Stephen
>>>>
>>>>
>>>> On 4 February 2015 at 15:10, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>>>
>>>>> Hi Stephen,
>>>>>
>>>>> I also indicated in the Jira comments that it is misleading and
>>>>> incorrect
>>>>> to
>>>>> return
>>>>> false when it is not known that a year is or is not a leap year. All of
>>>>> the
>>>>> other
>>>>> HijrahChronology computations throw DTE for invalid dates and the same
>>>>> may
>>>>> be
>>>>> true for other Chronologies.
>>>>>
>>>>> The assertion in Chronology.isLeapYear about not checking the range is
>>>>> too
>>>>> broad
>>>>> and should be qualified by the Chronology.
>>>>>
>>>>> Perhaps the proposed change should include a caveat in that method.
>>>>>
>>>>> Roger
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2/3/15 8:05 PM, Stephen Colebourne wrote:
>>>>>>
>>>>>> -1
>>>>>>
>>>>>> As I indicated on JIRA, I don't believe that this change meets the
>>>>>> spec or intent of the definition on Chronology. That is specified to
>>>>>> not throw any exceptions and to handle all years, valid or not.
>>>>>>
>>>>>> I don't foresee any significant issue where a year is not validated by
>>>>>> this method. Years out of range should simply return false, again
>>>>>> something that is within the spirit of the spec "a chronology that
>>>>>> does not support the concept of a year must return false."
>>>>>>
>>>>>> Stephen
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 3 February 2015 at 20:56, Lance Andersen
>>>>>> <lance.andersen at oracle.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> +1
>>>>>>> On Feb 3, 2015, at 3:45 PM, Roger Riggs <Roger.Riggs at oracle.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Please review this specification clarification of the range of
>>>>>>>> Hijrah
>>>>>>>> calendar variants.
>>>>>>>> The issue was exposed by a bug in the HijrahChronology.isLeapYear
>>>>>>>> method.
>>>>>>>>
>>>>>>>> Webrev:
>>>>>>>>      http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/
>>>>>>>>
>>>>>>>> Issue:
>>>>>>>>      https://bugs.openjdk.java.net/browse/JDK-8067800
>>>>>>>>
>>>>>>>> A CCC may be needed.
>>>>>>>>
>>>>>>>> Thanks, Roger
>>>>>>>>
>>>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>>> Oracle Java Engineering
>>>>>>> 1 Network Drive
>>>>>>> Burlington, MA 01803
>>>>>>> Lance.Andersen at oracle.com
>>>>>>>
>>>>>>>
>>>>>>>
>


From Roger.Riggs at Oracle.com  Wed Feb  4 21:17:47 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 04 Feb 2015 16:17:47 -0500
Subject: RFR 9: 8067800: Unexpected DateTimeException in the
	java.time.chrono.HijrahChronology.isLeapYear
In-Reply-To: <CACzrW9CUPnq+ecvXMW90-6rA5f_i-Fe_2Fj6y4-vqNxeKNhKPA@mail.gmail.com>
References: <54D13357.2090406@Oracle.com>	<6BDD077A-A4E3-4908-AC37-2C1451A8BFCC@oracle.com>	<CACzrW9A0fnRHYvOZsjcvM8d2=2oorBu2272i-mSDF1JyTO_ssA@mail.gmail.com>	<54D2366B.8010708@Oracle.com>	<CACzrW9A0OpY+c+QLcB0vVxj0fD_zcARm6KAK6dgwxk=nmnbAYg@mail.gmail.com>	<54D24342.3060107@Oracle.com>	<CACzrW9BK38RFQp9nofsUV=a4Efbo118Xf4Dg5qWESPbaU_H3qg@mail.gmail.com>	<54D26E19.4040604@Oracle.com>
	<CACzrW9CUPnq+ecvXMW90-6rA5f_i-Fe_2Fj6y4-vqNxeKNhKPA@mail.gmail.com>
Message-ID: <54D28C7B.7040507@Oracle.com>

Hi Stephen,

That covers the cases better.

The updated javadoc is:
http://cr.openjdk.java.net/~rriggs/xx/java/time/chrono/Chronology.html
http://cr.openjdk.java.net/~rriggs/xx/java/time/chrono/HijrahChronology.html

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/

Roger



On 2/4/2015 3:42 PM, Stephen Colebourne wrote:
> I think this might be clearer:
>
> * Checks if the specified year is a leap year.
> * <p>
> * A leap-year is a year of a longer length than normal.
> * The exact meaning is determined by the chronology according to the
> following constraints.
> * <ul>
> * <li>a leap-year must imply a year-length longer than a non leap-year.
> * <li>a chronology that does not support the concept of a year must
> return false.
> * <li>the correct result must be returned for all years within the
> valid range of years for the chronology
> * </ul>
> * Outside the range of valid years an implementation is free to return
> either a best guess or false.
> * An implementation must not throw an exception, even if the year is
> outside the range of valid years..
>
> Stephen
>
>
>
> On 4 February 2015 at 19:08, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>> Hi,
>>
>> Clarifying that Chronology.isLeapYear is specified only within the range of
>> the chronology
>> makes it possible to maintain the invariants with the calendar computations
>> and methods.
>> Best effort isn't testable except in an implementation specific way and
>> can't be relied on.
>>
>> The other two constraints are testable and use 'must' in their definitions.
>> The new phrasing should clearly be either an exception or reinforce the
>> value is
>> specified only within the range of the chronology.
>>
>> How about:
>>
>> <li>except if the year is out of range the chronology should return a best
>> effort guess, or false if there is no suitable guess
>>
>> Roger
>>
>>
>>
>> On 2/4/2015 11:18 AM, Stephen Colebourne wrote:
>>> The spec is pretty clear:
>>> "the proleptic-year to check, not validated for range"
>>>
>>> Adding an exception to the spec would cause requests to add exceptions
>>> to all other chronologies. Doing so, would be very negative to
>>> performance (it would require having a non-public copy of the logic
>>> elsewhere to avoid the range checking cost.
>>>
>>> Adding an exception to Hijrah only means that the implementation is
>>> doing something not permitted by the spec.
>>>
>>> The only sane choice here is to return false from Hijrah when out of
>>> range. As intended and as specced.
>>>
>>> Note that I don't believe that returning false will cause hardship in
>>> any actual user code, because other methods will constrain the year to
>>> be valid.
>>>
>>> If necessary, the following spec clarification could be added to the
>>> bullet points on Chronology:
>>>
>>> <li>if the year is out of range the chronology should return a best
>>> effort guess, or false if there is no suitable guess
>>>
>>> Stephen
>>>
>>>
>>> On 4 February 2015 at 16:05, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>> Hi Stephen,
>>>>
>>>> On 2/4/15 10:43 AM, Stephen Colebourne wrote:
>>>>> The java.time code generally takes a lenient approach to methods that
>>>>> return a boolean. For example, they tend to accept null inputs without
>>>>> throwing an exception.
>>>> Seems like an odd design provision leading to some behavior that
>>>> would be inconsistent with non-boolean methods.
>>>>>
>>>>> Right now, this patch makes a subclass implementation incompatible
>>>>> with the superclass spec. That cannot happen. Thus there are only two
>>>>> options:
>>>>>
>>>>> - change the superclass spec
>>>>> - return false from the subclass
>>>>>
>>>>> I favour the latter as being in line with the rest of the package and
>>>>> less disruptive to existing users (would a CCC even pass?)
>>>> For a 'young' API with limited uptake, issues can be fixed early and in a
>>>> major
>>>> release there is more flexibility to clarify the specification.
>>>>
>>>> DTE is a runtime exception and can occur in a majority of time
>>>> computations.
>>>> In the case of HijrahChronolog.isLeapYear, the implementation currently
>>>> throws a different RuntimeException and this would be a correction
>>>> to the conventional exception.
>>>>
>>>> Roger
>>>>
>>>>
>>>>> Stephen
>>>>>
>>>>>
>>>>> On 4 February 2015 at 15:10, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>>>> Hi Stephen,
>>>>>>
>>>>>> I also indicated in the Jira comments that it is misleading and
>>>>>> incorrect
>>>>>> to
>>>>>> return
>>>>>> false when it is not known that a year is or is not a leap year. All of
>>>>>> the
>>>>>> other
>>>>>> HijrahChronology computations throw DTE for invalid dates and the same
>>>>>> may
>>>>>> be
>>>>>> true for other Chronologies.
>>>>>>
>>>>>> The assertion in Chronology.isLeapYear about not checking the range is
>>>>>> too
>>>>>> broad
>>>>>> and should be qualified by the Chronology.
>>>>>>
>>>>>> Perhaps the proposed change should include a caveat in that method.
>>>>>>
>>>>>> Roger
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2/3/15 8:05 PM, Stephen Colebourne wrote:
>>>>>>> -1
>>>>>>>
>>>>>>> As I indicated on JIRA, I don't believe that this change meets the
>>>>>>> spec or intent of the definition on Chronology. That is specified to
>>>>>>> not throw any exceptions and to handle all years, valid or not.
>>>>>>>
>>>>>>> I don't foresee any significant issue where a year is not validated by
>>>>>>> this method. Years out of range should simply return false, again
>>>>>>> something that is within the spirit of the spec "a chronology that
>>>>>>> does not support the concept of a year must return false."
>>>>>>>
>>>>>>> Stephen
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 3 February 2015 at 20:56, Lance Andersen
>>>>>>> <lance.andersen at oracle.com>
>>>>>>> wrote:
>>>>>>>> +1
>>>>>>>> On Feb 3, 2015, at 3:45 PM, Roger Riggs <Roger.Riggs at oracle.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Please review this specification clarification of the range of
>>>>>>>>> Hijrah
>>>>>>>>> calendar variants.
>>>>>>>>> The issue was exposed by a bug in the HijrahChronology.isLeapYear
>>>>>>>>> method.
>>>>>>>>>
>>>>>>>>> Webrev:
>>>>>>>>>       http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/
>>>>>>>>>
>>>>>>>>> Issue:
>>>>>>>>>       https://bugs.openjdk.java.net/browse/JDK-8067800
>>>>>>>>>
>>>>>>>>> A CCC may be needed.
>>>>>>>>>
>>>>>>>>> Thanks, Roger
>>>>>>>>>
>>>>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>>>> Oracle Java Engineering
>>>>>>>> 1 Network Drive
>>>>>>>> Burlington, MA 01803
>>>>>>>> Lance.Andersen at oracle.com
>>>>>>>>
>>>>>>>>
>>>>>>>>



From lance.andersen at oracle.com  Wed Feb  4 21:32:36 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 4 Feb 2015 16:32:36 -0500
Subject: RFR 9: 8067800: Unexpected DateTimeException in the
	java.time.chrono.HijrahChronology.isLeapYear
In-Reply-To: <54D28C7B.7040507@Oracle.com>
References: <54D13357.2090406@Oracle.com>	<6BDD077A-A4E3-4908-AC37-2C1451A8BFCC@oracle.com>	<CACzrW9A0fnRHYvOZsjcvM8d2=2oorBu2272i-mSDF1JyTO_ssA@mail.gmail.com>	<54D2366B.8010708@Oracle.com>	<CACzrW9A0OpY+c+QLcB0vVxj0fD_zcARm6KAK6dgwxk=nmnbAYg@mail.gmail.com>	<54D24342.3060107@Oracle.com>	<CACzrW9BK38RFQp9nofsUV=a4Efbo118Xf4Dg5qWESPbaU_H3qg@mail.gmail.com>	<54D26E19.4040604@Oracle.com>
	<CACzrW9CUPnq+ecvXMW90-6rA5f_i-Fe_2Fj6y4-vqNxeKNhKPA@mail.gmail.com>
	<54D28C7B.7040507@Oracle.com>
Message-ID: <CAF7A4E4-8D0E-4E5D-A029-0E32E94060E1@oracle.com>

Hi Roger,

I think it looks fine. 

If you wanted to and not necessary, you could use assertFalse vs assertEquals in your test (more of a style choice )


Thank you for the javadoc as it is clearer that way

Best
Lance
On Feb 4, 2015, at 4:17 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi Stephen,
> 
> That covers the cases better.
> 
> The updated javadoc is:
> http://cr.openjdk.java.net/~rriggs/xx/java/time/chrono/Chronology.html
> http://cr.openjdk.java.net/~rriggs/xx/java/time/chrono/HijrahChronology.html
> 
> Webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/
> 
> Roger
> 
> 
> 
> On 2/4/2015 3:42 PM, Stephen Colebourne wrote:
>> I think this might be clearer:
>> 
>> * Checks if the specified year is a leap year.
>> * <p>
>> * A leap-year is a year of a longer length than normal.
>> * The exact meaning is determined by the chronology according to the
>> following constraints.
>> * <ul>
>> * <li>a leap-year must imply a year-length longer than a non leap-year.
>> * <li>a chronology that does not support the concept of a year must
>> return false.
>> * <li>the correct result must be returned for all years within the
>> valid range of years for the chronology
>> * </ul>
>> * Outside the range of valid years an implementation is free to return
>> either a best guess or false.
>> * An implementation must not throw an exception, even if the year is
>> outside the range of valid years..
>> 
>> Stephen
>> 
>> 
>> 
>> On 4 February 2015 at 19:08, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>> Hi,
>>> 
>>> Clarifying that Chronology.isLeapYear is specified only within the range of
>>> the chronology
>>> makes it possible to maintain the invariants with the calendar computations
>>> and methods.
>>> Best effort isn't testable except in an implementation specific way and
>>> can't be relied on.
>>> 
>>> The other two constraints are testable and use 'must' in their definitions.
>>> The new phrasing should clearly be either an exception or reinforce the
>>> value is
>>> specified only within the range of the chronology.
>>> 
>>> How about:
>>> 
>>> <li>except if the year is out of range the chronology should return a best
>>> effort guess, or false if there is no suitable guess
>>> 
>>> Roger
>>> 
>>> 
>>> 
>>> On 2/4/2015 11:18 AM, Stephen Colebourne wrote:
>>>> The spec is pretty clear:
>>>> "the proleptic-year to check, not validated for range"
>>>> 
>>>> Adding an exception to the spec would cause requests to add exceptions
>>>> to all other chronologies. Doing so, would be very negative to
>>>> performance (it would require having a non-public copy of the logic
>>>> elsewhere to avoid the range checking cost.
>>>> 
>>>> Adding an exception to Hijrah only means that the implementation is
>>>> doing something not permitted by the spec.
>>>> 
>>>> The only sane choice here is to return false from Hijrah when out of
>>>> range. As intended and as specced.
>>>> 
>>>> Note that I don't believe that returning false will cause hardship in
>>>> any actual user code, because other methods will constrain the year to
>>>> be valid.
>>>> 
>>>> If necessary, the following spec clarification could be added to the
>>>> bullet points on Chronology:
>>>> 
>>>> <li>if the year is out of range the chronology should return a best
>>>> effort guess, or false if there is no suitable guess
>>>> 
>>>> Stephen
>>>> 
>>>> 
>>>> On 4 February 2015 at 16:05, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>>> Hi Stephen,
>>>>> 
>>>>> On 2/4/15 10:43 AM, Stephen Colebourne wrote:
>>>>>> The java.time code generally takes a lenient approach to methods that
>>>>>> return a boolean. For example, they tend to accept null inputs without
>>>>>> throwing an exception.
>>>>> Seems like an odd design provision leading to some behavior that
>>>>> would be inconsistent with non-boolean methods.
>>>>>> 
>>>>>> Right now, this patch makes a subclass implementation incompatible
>>>>>> with the superclass spec. That cannot happen. Thus there are only two
>>>>>> options:
>>>>>> 
>>>>>> - change the superclass spec
>>>>>> - return false from the subclass
>>>>>> 
>>>>>> I favour the latter as being in line with the rest of the package and
>>>>>> less disruptive to existing users (would a CCC even pass?)
>>>>> For a 'young' API with limited uptake, issues can be fixed early and in a
>>>>> major
>>>>> release there is more flexibility to clarify the specification.
>>>>> 
>>>>> DTE is a runtime exception and can occur in a majority of time
>>>>> computations.
>>>>> In the case of HijrahChronolog.isLeapYear, the implementation currently
>>>>> throws a different RuntimeException and this would be a correction
>>>>> to the conventional exception.
>>>>> 
>>>>> Roger
>>>>> 
>>>>> 
>>>>>> Stephen
>>>>>> 
>>>>>> 
>>>>>> On 4 February 2015 at 15:10, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>>>>> Hi Stephen,
>>>>>>> 
>>>>>>> I also indicated in the Jira comments that it is misleading and
>>>>>>> incorrect
>>>>>>> to
>>>>>>> return
>>>>>>> false when it is not known that a year is or is not a leap year. All of
>>>>>>> the
>>>>>>> other
>>>>>>> HijrahChronology computations throw DTE for invalid dates and the same
>>>>>>> may
>>>>>>> be
>>>>>>> true for other Chronologies.
>>>>>>> 
>>>>>>> The assertion in Chronology.isLeapYear about not checking the range is
>>>>>>> too
>>>>>>> broad
>>>>>>> and should be qualified by the Chronology.
>>>>>>> 
>>>>>>> Perhaps the proposed change should include a caveat in that method.
>>>>>>> 
>>>>>>> Roger
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 2/3/15 8:05 PM, Stephen Colebourne wrote:
>>>>>>>> -1
>>>>>>>> 
>>>>>>>> As I indicated on JIRA, I don't believe that this change meets the
>>>>>>>> spec or intent of the definition on Chronology. That is specified to
>>>>>>>> not throw any exceptions and to handle all years, valid or not.
>>>>>>>> 
>>>>>>>> I don't foresee any significant issue where a year is not validated by
>>>>>>>> this method. Years out of range should simply return false, again
>>>>>>>> something that is within the spirit of the spec "a chronology that
>>>>>>>> does not support the concept of a year must return false."
>>>>>>>> 
>>>>>>>> Stephen
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 3 February 2015 at 20:56, Lance Andersen
>>>>>>>> <lance.andersen at oracle.com>
>>>>>>>> wrote:
>>>>>>>>> +1
>>>>>>>>> On Feb 3, 2015, at 3:45 PM, Roger Riggs <Roger.Riggs at oracle.com>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Please review this specification clarification of the range of
>>>>>>>>>> Hijrah
>>>>>>>>>> calendar variants.
>>>>>>>>>> The issue was exposed by a bug in the HijrahChronology.isLeapYear
>>>>>>>>>> method.
>>>>>>>>>> 
>>>>>>>>>> Webrev:
>>>>>>>>>>      http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/
>>>>>>>>>> 
>>>>>>>>>> Issue:
>>>>>>>>>>      https://bugs.openjdk.java.net/browse/JDK-8067800
>>>>>>>>>> 
>>>>>>>>>> A CCC may be needed.
>>>>>>>>>> 
>>>>>>>>>> Thanks, Roger
>>>>>>>>>> 
>>>>>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>>>>> Oracle Java Engineering
>>>>>>>>> 1 Network Drive
>>>>>>>>> Burlington, MA 01803
>>>>>>>>> Lance.Andersen at oracle.com
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
> 



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





From Roger.Riggs at Oracle.com  Wed Feb  4 21:47:49 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 04 Feb 2015 16:47:49 -0500
Subject: RFR 9: 8067800: Unexpected DateTimeException in the
	java.time.chrono.HijrahChronology.isLeapYear
In-Reply-To: <CAF7A4E4-8D0E-4E5D-A029-0E32E94060E1@oracle.com>
References: <54D13357.2090406@Oracle.com>	<6BDD077A-A4E3-4908-AC37-2C1451A8BFCC@oracle.com>	<CACzrW9A0fnRHYvOZsjcvM8d2=2oorBu2272i-mSDF1JyTO_ssA@mail.gmail.com>	<54D2366B.8010708@Oracle.com>	<CACzrW9A0OpY+c+QLcB0vVxj0fD_zcARm6KAK6dgwxk=nmnbAYg@mail.gmail.com>	<54D24342.3060107@Oracle.com>	<CACzrW9BK38RFQp9nofsUV=a4Efbo118Xf4Dg5qWESPbaU_H3qg@mail.gmail.com>	<54D26E19.4040604@Oracle.com>
	<CACzrW9CUPnq+ecvXMW90-6rA5f_i-Fe_2Fj6y4-vqNxeKNhKPA@mail.gmail.com>
	<54D28C7B.7040507@Oracle.com>
	<CAF7A4E4-8D0E-4E5D-A029-0E32E94060E1@oracle.com>
Message-ID: <54D29385.2030506@Oracle.com>

Thanks Lance,  I updated to use assertFalse.

On 2/4/2015 4:32 PM, Lance Andersen wrote:
> Hi Roger,
>
> I think it looks fine.
>
> If you wanted to and not necessary, you could use assertFalse vs 
> assertEquals in your test (more of a style choice )
>
>
> Thank you for the javadoc as it is clearer that way
>
> Best
> Lance
> On Feb 4, 2015, at 4:17 PM, Roger Riggs <Roger.Riggs at oracle.com 
> <mailto:Roger.Riggs at oracle.com>> wrote:
>
>> Hi Stephen,
>>
>> That covers the cases better.
>>
>> The updated javadoc is:
>> http://cr.openjdk.java.net/~rriggs/xx/java/time/chrono/Chronology.html <http://cr.openjdk.java.net/%7Erriggs/xx/java/time/chrono/Chronology.html>
>> http://cr.openjdk.java.net/~rriggs/xx/java/time/chrono/HijrahChronology.html
>>
>> Webrev:
>>   http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/
>>
>> Roger
>>
>>
>>
>> On 2/4/2015 3:42 PM, Stephen Colebourne wrote:
>>> I think this might be clearer:
>>>
>>> * Checks if the specified year is a leap year.
>>> * <p>
>>> * A leap-year is a year of a longer length than normal.
>>> * The exact meaning is determined by the chronology according to the
>>> following constraints.
>>> * <ul>
>>> * <li>a leap-year must imply a year-length longer than a non leap-year.
>>> * <li>a chronology that does not support the concept of a year must
>>> return false.
>>> * <li>the correct result must be returned for all years within the
>>> valid range of years for the chronology
>>> * </ul>
>>> * Outside the range of valid years an implementation is free to return
>>> either a best guess or false.
>>> * An implementation must not throw an exception, even if the year is
>>> outside the range of valid years..
>>>
>>> Stephen
>>>
>>>
>>>
>>> On 4 February 2015 at 19:08, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>> Hi,
>>>>
>>>> Clarifying that Chronology.isLeapYear is specified only within the 
>>>> range of
>>>> the chronology
>>>> makes it possible to maintain the invariants with the calendar 
>>>> computations
>>>> and methods.
>>>> Best effort isn't testable except in an implementation specific way and
>>>> can't be relied on.
>>>>
>>>> The other two constraints are testable and use 'must' in their 
>>>> definitions.
>>>> The new phrasing should clearly be either an exception or reinforce the
>>>> value is
>>>> specified only within the range of the chronology.
>>>>
>>>> How about:
>>>>
>>>> <li>except if the year is out of range the chronology should return 
>>>> a best
>>>> effort guess, or false if there is no suitable guess
>>>>
>>>> Roger
>>>>
>>>>
>>>>
>>>> On 2/4/2015 11:18 AM, Stephen Colebourne wrote:
>>>>> The spec is pretty clear:
>>>>> "the proleptic-year to check, not validated for range"
>>>>>
>>>>> Adding an exception to the spec would cause requests to add exceptions
>>>>> to all other chronologies. Doing so, would be very negative to
>>>>> performance (it would require having a non-public copy of the logic
>>>>> elsewhere to avoid the range checking cost.
>>>>>
>>>>> Adding an exception to Hijrah only means that the implementation is
>>>>> doing something not permitted by the spec.
>>>>>
>>>>> The only sane choice here is to return false from Hijrah when out of
>>>>> range. As intended and as specced.
>>>>>
>>>>> Note that I don't believe that returning false will cause hardship in
>>>>> any actual user code, because other methods will constrain the year to
>>>>> be valid.
>>>>>
>>>>> If necessary, the following spec clarification could be added to the
>>>>> bullet points on Chronology:
>>>>>
>>>>> <li>if the year is out of range the chronology should return a best
>>>>> effort guess, or false if there is no suitable guess
>>>>>
>>>>> Stephen
>>>>>
>>>>>
>>>>> On 4 February 2015 at 16:05, Roger Riggs <Roger.Riggs at oracle.com> 
>>>>> wrote:
>>>>>> Hi Stephen,
>>>>>>
>>>>>> On 2/4/15 10:43 AM, Stephen Colebourne wrote:
>>>>>>> The java.time code generally takes a lenient approach to methods 
>>>>>>> that
>>>>>>> return a boolean. For example, they tend to accept null inputs 
>>>>>>> without
>>>>>>> throwing an exception.
>>>>>> Seems like an odd design provision leading to some behavior that
>>>>>> would be inconsistent with non-boolean methods.
>>>>>>>
>>>>>>> Right now, this patch makes a subclass implementation incompatible
>>>>>>> with the superclass spec. That cannot happen. Thus there are 
>>>>>>> only two
>>>>>>> options:
>>>>>>>
>>>>>>> - change the superclass spec
>>>>>>> - return false from the subclass
>>>>>>>
>>>>>>> I favour the latter as being in line with the rest of the 
>>>>>>> package and
>>>>>>> less disruptive to existing users (would a CCC even pass?)
>>>>>> For a 'young' API with limited uptake, issues can be fixed early 
>>>>>> and in a
>>>>>> major
>>>>>> release there is more flexibility to clarify the specification.
>>>>>>
>>>>>> DTE is a runtime exception and can occur in a majority of time
>>>>>> computations.
>>>>>> In the case of HijrahChronolog.isLeapYear, the implementation 
>>>>>> currently
>>>>>> throws a different RuntimeException and this would be a correction
>>>>>> to the conventional exception.
>>>>>>
>>>>>> Roger
>>>>>>
>>>>>>
>>>>>>> Stephen
>>>>>>>
>>>>>>>
>>>>>>> On 4 February 2015 at 15:10, Roger Riggs 
>>>>>>> <Roger.Riggs at oracle.com> wrote:
>>>>>>>> Hi Stephen,
>>>>>>>>
>>>>>>>> I also indicated in the Jira comments that it is misleading and
>>>>>>>> incorrect
>>>>>>>> to
>>>>>>>> return
>>>>>>>> false when it is not known that a year is or is not a leap 
>>>>>>>> year. All of
>>>>>>>> the
>>>>>>>> other
>>>>>>>> HijrahChronology computations throw DTE for invalid dates and 
>>>>>>>> the same
>>>>>>>> may
>>>>>>>> be
>>>>>>>> true for other Chronologies.
>>>>>>>>
>>>>>>>> The assertion in Chronology.isLeapYear about not checking the 
>>>>>>>> range is
>>>>>>>> too
>>>>>>>> broad
>>>>>>>> and should be qualified by the Chronology.
>>>>>>>>
>>>>>>>> Perhaps the proposed change should include a caveat in that method.
>>>>>>>>
>>>>>>>> Roger
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2/3/15 8:05 PM, Stephen Colebourne wrote:
>>>>>>>>> -1
>>>>>>>>>
>>>>>>>>> As I indicated on JIRA, I don't believe that this change meets the
>>>>>>>>> spec or intent of the definition on Chronology. That is 
>>>>>>>>> specified to
>>>>>>>>> not throw any exceptions and to handle all years, valid or not.
>>>>>>>>>
>>>>>>>>> I don't foresee any significant issue where a year is not 
>>>>>>>>> validated by
>>>>>>>>> this method. Years out of range should simply return false, again
>>>>>>>>> something that is within the spirit of the spec "a chronology that
>>>>>>>>> does not support the concept of a year must return false."
>>>>>>>>>
>>>>>>>>> Stephen
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 3 February 2015 at 20:56, Lance Andersen
>>>>>>>>> <lance.andersen at oracle.com>
>>>>>>>>> wrote:
>>>>>>>>>> +1
>>>>>>>>>> On Feb 3, 2015, at 3:45 PM, Roger Riggs <Roger.Riggs at oracle.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Please review this specification clarification of the range of
>>>>>>>>>>> Hijrah
>>>>>>>>>>> calendar variants.
>>>>>>>>>>> The issue was exposed by a bug in the 
>>>>>>>>>>> HijrahChronology.isLeapYear
>>>>>>>>>>> method.
>>>>>>>>>>>
>>>>>>>>>>> Webrev:
>>>>>>>>>>>      http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/
>>>>>>>>>>>
>>>>>>>>>>> Issue:
>>>>>>>>>>>      https://bugs.openjdk.java.net/browse/JDK-8067800
>>>>>>>>>>>
>>>>>>>>>>> A CCC may be needed.
>>>>>>>>>>>
>>>>>>>>>>> Thanks, Roger
>>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>
>
> <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 scolebourne at joda.org  Wed Feb  4 23:23:11 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 4 Feb 2015 23:23:11 +0000
Subject: RFR 9: 8067800: Unexpected DateTimeException in the
	java.time.chrono.HijrahChronology.isLeapYear
In-Reply-To: <54D28C7B.7040507@Oracle.com>
References: <54D13357.2090406@Oracle.com>
	<6BDD077A-A4E3-4908-AC37-2C1451A8BFCC@oracle.com>
	<CACzrW9A0fnRHYvOZsjcvM8d2=2oorBu2272i-mSDF1JyTO_ssA@mail.gmail.com>
	<54D2366B.8010708@Oracle.com>
	<CACzrW9A0OpY+c+QLcB0vVxj0fD_zcARm6KAK6dgwxk=nmnbAYg@mail.gmail.com>
	<54D24342.3060107@Oracle.com>
	<CACzrW9BK38RFQp9nofsUV=a4Efbo118Xf4Dg5qWESPbaU_H3qg@mail.gmail.com>
	<54D26E19.4040604@Oracle.com>
	<CACzrW9CUPnq+ecvXMW90-6rA5f_i-Fe_2Fj6y4-vqNxeKNhKPA@mail.gmail.com>
	<54D28C7B.7040507@Oracle.com>
Message-ID: <CACzrW9B6LRCyKK5iHESOucRt2tTeOkby1XjH_yptKTMF2yr+Xg@mail.gmail.com>

Looks good overall.
Only comment is whether there should be a <p> tag after the </ul> and
before "Outside the range". The resulting javadoc looks like it needs
it, although I don't know what the OpenJDK house rule is for that
case.

Stephen

On 4 February 2015 at 21:17, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> Hi Stephen,
>
> That covers the cases better.
>
> The updated javadoc is:
> http://cr.openjdk.java.net/~rriggs/xx/java/time/chrono/Chronology.html
> http://cr.openjdk.java.net/~rriggs/xx/java/time/chrono/HijrahChronology.html
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/
>
> Roger
>
>
>
>
> On 2/4/2015 3:42 PM, Stephen Colebourne wrote:
>>
>> I think this might be clearer:
>>
>> * Checks if the specified year is a leap year.
>> * <p>
>> * A leap-year is a year of a longer length than normal.
>> * The exact meaning is determined by the chronology according to the
>> following constraints.
>> * <ul>
>> * <li>a leap-year must imply a year-length longer than a non leap-year.
>> * <li>a chronology that does not support the concept of a year must
>> return false.
>> * <li>the correct result must be returned for all years within the
>> valid range of years for the chronology
>> * </ul>
>> * Outside the range of valid years an implementation is free to return
>> either a best guess or false.
>> * An implementation must not throw an exception, even if the year is
>> outside the range of valid years..
>>
>> Stephen
>>
>>
>>
>> On 4 February 2015 at 19:08, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> Clarifying that Chronology.isLeapYear is specified only within the range
>>> of
>>> the chronology
>>> makes it possible to maintain the invariants with the calendar
>>> computations
>>> and methods.
>>> Best effort isn't testable except in an implementation specific way and
>>> can't be relied on.
>>>
>>> The other two constraints are testable and use 'must' in their
>>> definitions.
>>> The new phrasing should clearly be either an exception or reinforce the
>>> value is
>>> specified only within the range of the chronology.
>>>
>>> How about:
>>>
>>> <li>except if the year is out of range the chronology should return a
>>> best
>>> effort guess, or false if there is no suitable guess
>>>
>>> Roger
>>>
>>>
>>>
>>> On 2/4/2015 11:18 AM, Stephen Colebourne wrote:
>>>>
>>>> The spec is pretty clear:
>>>> "the proleptic-year to check, not validated for range"
>>>>
>>>> Adding an exception to the spec would cause requests to add exceptions
>>>> to all other chronologies. Doing so, would be very negative to
>>>> performance (it would require having a non-public copy of the logic
>>>> elsewhere to avoid the range checking cost.
>>>>
>>>> Adding an exception to Hijrah only means that the implementation is
>>>> doing something not permitted by the spec.
>>>>
>>>> The only sane choice here is to return false from Hijrah when out of
>>>> range. As intended and as specced.
>>>>
>>>> Note that I don't believe that returning false will cause hardship in
>>>> any actual user code, because other methods will constrain the year to
>>>> be valid.
>>>>
>>>> If necessary, the following spec clarification could be added to the
>>>> bullet points on Chronology:
>>>>
>>>> <li>if the year is out of range the chronology should return a best
>>>> effort guess, or false if there is no suitable guess
>>>>
>>>> Stephen
>>>>
>>>>
>>>> On 4 February 2015 at 16:05, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>>>
>>>>> Hi Stephen,
>>>>>
>>>>> On 2/4/15 10:43 AM, Stephen Colebourne wrote:
>>>>>>
>>>>>> The java.time code generally takes a lenient approach to methods that
>>>>>> return a boolean. For example, they tend to accept null inputs without
>>>>>> throwing an exception.
>>>>>
>>>>> Seems like an odd design provision leading to some behavior that
>>>>> would be inconsistent with non-boolean methods.
>>>>>>
>>>>>>
>>>>>> Right now, this patch makes a subclass implementation incompatible
>>>>>> with the superclass spec. That cannot happen. Thus there are only two
>>>>>> options:
>>>>>>
>>>>>> - change the superclass spec
>>>>>> - return false from the subclass
>>>>>>
>>>>>> I favour the latter as being in line with the rest of the package and
>>>>>> less disruptive to existing users (would a CCC even pass?)
>>>>>
>>>>> For a 'young' API with limited uptake, issues can be fixed early and in
>>>>> a
>>>>> major
>>>>> release there is more flexibility to clarify the specification.
>>>>>
>>>>> DTE is a runtime exception and can occur in a majority of time
>>>>> computations.
>>>>> In the case of HijrahChronolog.isLeapYear, the implementation currently
>>>>> throws a different RuntimeException and this would be a correction
>>>>> to the conventional exception.
>>>>>
>>>>> Roger
>>>>>
>>>>>
>>>>>> Stephen
>>>>>>
>>>>>>
>>>>>> On 4 February 2015 at 15:10, Roger Riggs <Roger.Riggs at oracle.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Stephen,
>>>>>>>
>>>>>>> I also indicated in the Jira comments that it is misleading and
>>>>>>> incorrect
>>>>>>> to
>>>>>>> return
>>>>>>> false when it is not known that a year is or is not a leap year. All
>>>>>>> of
>>>>>>> the
>>>>>>> other
>>>>>>> HijrahChronology computations throw DTE for invalid dates and the
>>>>>>> same
>>>>>>> may
>>>>>>> be
>>>>>>> true for other Chronologies.
>>>>>>>
>>>>>>> The assertion in Chronology.isLeapYear about not checking the range
>>>>>>> is
>>>>>>> too
>>>>>>> broad
>>>>>>> and should be qualified by the Chronology.
>>>>>>>
>>>>>>> Perhaps the proposed change should include a caveat in that method.
>>>>>>>
>>>>>>> Roger
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2/3/15 8:05 PM, Stephen Colebourne wrote:
>>>>>>>>
>>>>>>>> -1
>>>>>>>>
>>>>>>>> As I indicated on JIRA, I don't believe that this change meets the
>>>>>>>> spec or intent of the definition on Chronology. That is specified to
>>>>>>>> not throw any exceptions and to handle all years, valid or not.
>>>>>>>>
>>>>>>>> I don't foresee any significant issue where a year is not validated
>>>>>>>> by
>>>>>>>> this method. Years out of range should simply return false, again
>>>>>>>> something that is within the spirit of the spec "a chronology that
>>>>>>>> does not support the concept of a year must return false."
>>>>>>>>
>>>>>>>> Stephen
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 3 February 2015 at 20:56, Lance Andersen
>>>>>>>> <lance.andersen at oracle.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>> On Feb 3, 2015, at 3:45 PM, Roger Riggs <Roger.Riggs at oracle.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Please review this specification clarification of the range of
>>>>>>>>>> Hijrah
>>>>>>>>>> calendar variants.
>>>>>>>>>> The issue was exposed by a bug in the HijrahChronology.isLeapYear
>>>>>>>>>> method.
>>>>>>>>>>
>>>>>>>>>> Webrev:
>>>>>>>>>>       http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/
>>>>>>>>>>
>>>>>>>>>> Issue:
>>>>>>>>>>       https://bugs.openjdk.java.net/browse/JDK-8067800
>>>>>>>>>>
>>>>>>>>>> A CCC may be needed.
>>>>>>>>>>
>>>>>>>>>> Thanks, Roger
>>>>>>>>>>
>>>>>>>>> Lance Andersen| Principal Member of Technical Staff |
>>>>>>>>> +1.781.442.2037
>>>>>>>>> Oracle Java Engineering
>>>>>>>>> 1 Network Drive
>>>>>>>>> Burlington, MA 01803
>>>>>>>>> Lance.Andersen at oracle.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>


From brent.christian at oracle.com  Thu Feb  5 00:36:38 2015
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 04 Feb 2015 16:36:38 -0800
Subject: RFC: Adding ConcurrentModificationException for
	HashMap.computeIfAbsent(), and JDK-8071667
In-Reply-To: <84AD741C-CB02-4540-B41B-8F95490FF8E4@oracle.com>
References: <54D1616F.50104@oracle.com> <54D18B9A.2020906@oracle.com>
	<84AD741C-CB02-4540-B41B-8F95490FF8E4@oracle.com>
Message-ID: <54D2BB16.80508@oracle.com>

I prefer this approach of discouraging/preventing side-effects via CME, 
rather than allowing them.  Keep the functions "functional", as it were.

If there are situations where determining the mapping for one key 
necessitates making additional changes to the Map, that should be coded 
some other way.  IMO, sneaking extra work into computeIfAbsent() is too 
big a departure from how the method is intended to be used.

Regarding the default methods:

Would we be able to make a "best-effort" detection of comodification by 
checking for a change in size before and after calling mappingFunction? 
  Or are there other reasons we "cannot do anything" about the default 
methods?

Thanks,
-Brent

On 2/4/15 2:01 AM, Paul Sandoz wrote:
> Hi,
>
> I think we should as consistent as possible about the functions being
> side-effect free when applied to "bulk" operations. A method such as
> computeIfAbsent can be viewed as a bulk operation in that it may
> perform two or more dependent actions (they are just not as bulky as
> forEach).
>
> It's inconsistent if we state the functions should be side-effect
> free *but* map implementations tolerate side-effects resulting in
> state changes for entries other than that associated with the key
> under operation. I am not even sure this can be easily guaranteed
> with CHM in the face of resizes and keys hashing to the same bucket.
>
> So i propose:
>
> - the functions should be side-effect free.
>
> - non-concurrent map implementations should, on a best-effort basis,
> detect comodification and fail with CME.
>
> - concurrent map implementations should, on a best-effort basis,
> detect non-termination situations and fail with ISE.
>
> - document the best-effort behaviour and advise that implementations
> should override the default implementations if they want to do
> better.
>
> Alas we cannot do anything about the default method implementations,
> but i don't think we should be constraining general behaviour based
> on that exact implementations (just as we do not for concurrent maps,
> it "behaves as if").
>
> Paul.
>
> On Feb 4, 2015, at 4:01 AM, Stuart Marks <stuart.marks at oracle.com>
> wrote:
>
>> On 2/3/15 4:01 PM, Brent Christian wrote:
>>> The code in bug 8071667 [1] passes a mappingFunction to
>>> computeIfAbsent() which itself put()s a sufficient number of
>>> additional entries into the HashMap to cause a resize/rehash.  As
>>> a result, computeIfAbsent() doesn't add the new entry at the
>>> proper place in the HashMap.
>>>
>>> While one should not (mis)use the mappingFunction in this way,
>>> HashMap.computeIfAbsent() (and similar HashMap methods which
>>> accept Lambda expressions) could check for and throw a
>>> ConcurrentModificationException on a "best-effort" basis, similar
>>> to iterators.  This is already done in bulk operations
>>> HashMap.forEach() and HashMap.replaceAll().
>>>
>>> I think it's also worth making mention of this in the JavaDoc.
>>
>> I think we need to have the specification discussion *first* before
>> we decide what HashMap should do with side-effecty computations
>> that are passed to computeIfAbsent and friends. Unfortunately the
>> API specification for Map.computeIfAbsent is largely silent about
>> what should happen. I don't know whether that means that the result
>> should be undefined, or that passing a function with side effects
>> is implicitly allowed and should therefore be defined.
>>
>> I'd think it would be quite unpleasantly surprising to find that
>> passing a mapping function with side effects -- especially on keys
>> other than the current operation -- results in essentially a
>> corrupted map. Then again, I'm surprised that somebody would think
>> to pass a mapping function that does have side effects. However,
>> this is what people do, and they expect the library to behave
>> reasonably.
>>
>> I can think of an (only moderately contrived) use case that's
>> probably behind the bug report. Suppose I want to have a map that
>> starts empty but which is lazily initialized, and when it's
>> initialized, it should contain entries for all keys A, B, C, D, and
>> E. Furthermore, it should be lazily initialized when any one of
>> these keys is put into the map. Of course, you can write this out
>> easily yourself. But hey, there's this new computeIfAbsent() method
>> that should let me do
>>
>> map.computeIfAbsent(key, k -> { /* put all entries A..E except k
>> */ return value_for_k; });
>>
>> Based on the @implSpec for Map.computeIfAbsent, I'd expect this to
>> work. And if your map inherits the Map.computeIfAbsent default
>> implementation, it probably does work. Indeed, the workaround given
>> in the bug report is essentially to implement your own method that
>> duplicates the logic of the @implSpec and the default method. So,
>> I'm leaning toward specifying that side effects should be
>> supported, and that ConcurrentModificationException should not be
>> thrown.
>>
>> That implies that HashMap will have to detect the concurrent
>> modification and deal with it instead of throwing an exception.
>>
>> If we do clarify the spec to support this case, it probably
>> shouldn't make any guarantees about what should happen if the
>> mapping function puts the *same* key. That is, if
>>
>> map.computeIfAbsent(key, k -> { put(k, value1); return value2; });
>>
>> it seems reasonable that it not be defined which of value1 or
>> value2 ends up getting mapped to the key.
>>
>> s'marks
>>
>>
>>> Here's an example of what might be done, using computeIfAbsent()
>>> as an example:
>>>
>>> http://cr.openjdk.java.net/~bchristi/8071667/webrev.0/
>>>
>>> I would update HashMap and Hashtable.  It looks like
>>> ConcurrentHashMap.computeIfAbsent() already forbids such usage,
>>> stating that the computation "must not attempt to update any
>>> other mappings of this map."
>>>
>>>
>>> Comments on this approach?
>>>
>>> Thanks, -Brent
>>>
>>> 1. https://bugs.openjdk.java.net/browse/JDK-8071667
>>> "HashMap.computeIfAbsent() adds entry that HashMap.get() does not
>>> find."
>


From dl at cs.oswego.edu  Thu Feb  5 00:45:33 2015
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 04 Feb 2015 19:45:33 -0500
Subject: RFC: Adding ConcurrentModificationException for
	HashMap.computeIfAbsent(), and JDK-8071667
In-Reply-To: <84AD741C-CB02-4540-B41B-8F95490FF8E4@oracle.com>
References: <54D1616F.50104@oracle.com> <54D18B9A.2020906@oracle.com>
	<84AD741C-CB02-4540-B41B-8F95490FF8E4@oracle.com>
Message-ID: <54D2BD2D.2020207@cs.oswego.edu>

On 02/04/2015 05:01 AM, Paul Sandoz wrote:

> So i propose:
>
> - the functions should be side-effect free.
>
> ...
> - concurrent map implementations should, on a best-effort basis, detect non-termination situations and fail with ISE.
>

We did this as part of changes to better detect recursive computIfAbsent in
   https://bugs.openjdk.java.net/browse/JDK-8062841
The best-effort is pretty good and catches most usage errors along
these lines. (In principle it cannot catch all possible errors though.)

-Doug



From david.holmes at oracle.com  Thu Feb  5 02:43:55 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 05 Feb 2015 12:43:55 +1000
Subject: RFR - 8072450: 9-dev build failed on elinux-i586 and rlinux-i586
In-Reply-To: <46922D85-7A38-4F49-BD97-5ADF2A3B6F0D@oracle.com>
References: <54D20301.9060702@oracle.com>	<079734CE-1213-4AF2-8818-780024D58F49@oracle.com>	<54D25A89.7060205@oracle.com>
	<46922D85-7A38-4F49-BD97-5ADF2A3B6F0D@oracle.com>
Message-ID: <54D2D8EB.4070009@oracle.com>

On 5/02/2015 6:17 AM, Christian Thalinger wrote:
>
>> On Feb 4, 2015, at 9:44 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> On 04/02/15 17:21, Christian Thalinger wrote:
>>>>
>>>> -const jlong MAX_DIFF_SECS = 0x0100000000;   //  2^32
>>>> +const jlong MAX_DIFF_SECS = 0x0100000000LL; //  2^32
>>>
>>> Don?t use LL directly; we have a compiler-dependent macro for this:

Sorry my bad - I forgot we had a macro for this. :(

>>>
>>> CONST64
>>>
>>
>> Hi Christian,
>>
>> I have pushed the change as it was reviewed by David, Coleen, & Staffan.
>>
>> I have logged https://bugs.openjdk.java.net/browse/JDK-8072482
>> (assigned to myself) as a followup bug.
>
> That?s fine, thanks.  Maybe you can fix a couple other places where LL-usage crept in too.

./cpu/zero/vm/bytecodeInterpreter_zero.inline.hpp:  if (op1 == (jlong) 
0x8000000000000000LL && op2 == -1) return op1;
./cpu/zero/vm/bytecodeInterpreter_zero.inline.hpp:  if (op1 == (jlong) 
0x8000000000000000LL && op2 == -1) return 0;
./share/vm/opto/divnode.cpp:  const uint64_t two63 = 
0x8000000000000000LL;     // 2**63.
./share/vm/gc_implementation/g1/g1CollectorPolicy.cpp: 
gclog_or_tty->print_cr("ALL PAUSES");
./os/aix/vm/os_aix.cpp:    return 0xFFFFFFFFFFFFFFFFLL;
./os/aix/vm/os_aix.cpp:      sys_time = thrdentry.ti_ru.ru_stime.tv_sec 
* 1000000000LL + thrdentry.ti_ru.ru_stime.tv_usec * 1000LL;
./os/aix/vm/os_aix.cpp:      user_time = thrdentry.ti_ru.ru_utime.tv_sec 
* 1000000000LL + thrdentry.ti_ru.ru_utime.tv_usec * 1000LL;

David
-----

>>
>> best regards,
>>
>> -- daniel
>


From masayoshi.okutsu at oracle.com  Thu Feb  5 02:50:57 2015
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 05 Feb 2015 11:50:57 +0900
Subject: <i18n dev> [9] RFR: 8072042: (tz) Support tzdata2015a
In-Reply-To: <54D0F065.9010304@oracle.com>
References: <54D0F065.9010304@oracle.com>
Message-ID: <54D2DA91.4010708@oracle.com>

Looks good to me.

Masayoshi

On 2/4/2015 12:59 AM, Aleksej Efimov wrote:
> Hi,
>
> Could I have a review the latest tzdata2015a integration fix to JDK9, 
> please. The regression tests run and JPRT testing (jdk_other,jdk_util, 
> jdk_text, jdk_time test sets) shows no TZ related JDK9 failures.
>
> Thank you,
> Aleksej
>
> Bug link: https://bugs.openjdk.java.net/browse/JDK-8072042
> Webrev with changes: 
> http://cr.openjdk.java.net/~aefimov/tzdata/2015a/9/00/
> Regression tests executed: test/sun/util/calendar\ 
> test/java/util/Calendar\ test/sun/util/resources/TimeZone\ 
> test/java/util/TimeZone\ test/java/time\ test/java/util/Formatter



From paul.sandoz at oracle.com  Thu Feb  5 08:37:26 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 5 Feb 2015 09:37:26 +0100
Subject: RFC: Adding ConcurrentModificationException for
	HashMap.computeIfAbsent(), and JDK-8071667
In-Reply-To: <54D2BD2D.2020207@cs.oswego.edu>
References: <54D1616F.50104@oracle.com> <54D18B9A.2020906@oracle.com>
	<84AD741C-CB02-4540-B41B-8F95490FF8E4@oracle.com>
	<54D2BD2D.2020207@cs.oswego.edu>
Message-ID: <27852D45-9DCB-4F5D-9E60-39ACC5129C7C@oracle.com>


On Feb 5, 2015, at 1:45 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 02/04/2015 05:01 AM, Paul Sandoz wrote:
> 
>> So i propose:
>> 
>> - the functions should be side-effect free.
>> 
>> ...
>> - concurrent map implementations should, on a best-effort basis, detect non-termination situations and fail with ISE.
>> 
> 
> We did this as part of changes to better detect recursive computIfAbsent in
>  https://bugs.openjdk.java.net/browse/JDK-8062841
> The best-effort is pretty good and catches most usage errors along
> these lines. (In principle it cannot catch all possible errors though.)
> 

Ah, thanks for the reminder, i forgot that was committed to 166:

http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ConcurrentHashMap.java?r1=1.258&r2=1.259&sortby=date

Paul.


From paul.sandoz at oracle.com  Thu Feb  5 08:46:26 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 5 Feb 2015 09:46:26 +0100
Subject: RFC: Adding ConcurrentModificationException for
	HashMap.computeIfAbsent(), and JDK-8071667
In-Reply-To: <54D2BB16.80508@oracle.com>
References: <54D1616F.50104@oracle.com> <54D18B9A.2020906@oracle.com>
	<84AD741C-CB02-4540-B41B-8F95490FF8E4@oracle.com>
	<54D2BB16.80508@oracle.com>
Message-ID: <77020461-FD36-41FC-9996-9B476670C20D@oracle.com>

On Feb 5, 2015, at 1:36 AM, Brent Christian <brent.christian at oracle.com> wrote:
> I prefer this approach of discouraging/preventing side-effects via CME, rather than allowing them.  Keep the functions "functional", as it were.
> 
> If there are situations where determining the mapping for one key necessitates making additional changes to the Map, that should be coded some other way.  IMO, sneaking extra work into computeIfAbsent() is too big a departure from how the method is intended to be used.
> 
> Regarding the default methods:
> 
> Would we be able to make a "best-effort" detection of comodification by checking for a change in size before and after calling mappingFunction?  Or are there other reasons we "cannot do anything" about the default methods?
> 

Yes, i suppose we could, of course it would not detect any aliasing when sampling the size.

My inclination is to leave these as is and focus on the most common concrete implementations.

Paul.


From paul.sandoz at oracle.com  Thu Feb  5 10:59:12 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 5 Feb 2015 11:59:12 +0100
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
Message-ID: <8890A88D-98D4-4F22-A71E-9C29A9F5545B@oracle.com>

Hi.

Please review these stream/lambda enhancements on Matcher:

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/

Two new methods are added to Matcher:

1) replaceAll(Function<MatchResult, String> ) that is more flexible than the existing replaceAll that accepts a single value.

2) Stream<MatchResult> results() that returns a stream of MatchResult for all matches.

The former does introduce a minor source incompatibility for a null argument, but then so did the new append methods accepting StringBuilder that were recently added (see JDK-8039124).
 
For the latter i opted to place the method on Matcher rather than Pattern as i think that is a better fit with current usages of Matcher and operating on a MatchResult. That marginally increases the complexity since co-modification checking is required.

I update the test PatternStreamTest to derive the expected result.


I suppose i could add another method replaceFirst(Function<MatchResult, String> ) if anyone feels strongly about that. Consistency-wise it seems the right thing to do.

Paul.


From otaviojava at java.net  Thu Feb  5 13:40:51 2015
From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=)
Date: Thu, 5 Feb 2015 11:40:51 -0200
Subject: Using StringBuilder instead StringBuffer[JAXP]
In-Reply-To: <CAPc8kR2FgvWJ2oZHhCU-_uWEOR91_mMh960qxCiAEcx=ZBnP_A@mail.gmail.com>
References: <CAPc8kR2FgvWJ2oZHhCU-_uWEOR91_mMh960qxCiAEcx=ZBnP_A@mail.gmail.com>
Message-ID: <CAPc8kR0ZjpsQHoYDzGD1vhREtvGVCC1WRf2cF1A54Oz7UBXnzA@mail.gmail.com>

On Tue, Dec 23, 2014 at 7:46 AM, Ot?vio Gon?alves de Santana <
otaviojava at java.net> wrote:

>
> *Motivation:* StringBuffer is synchronized while StringBuilder is not
> which makes StringBuilder faster than StringBuffer[1]. The strategy was
> removed the StringBuffer when it is not necessary.
>
>
> WebRev:
> https://dl.dropboxusercontent.com/u/16109193/open_jdk/jaxp/buffer2builder/index.html
>
>
> [1]
>
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.SECONDS)
> public class StringBufferBenchmark {
>
>
>     private List<String> texts;
>     @Param("10000000")
>     private int param;
>
>     @Setup
>     public void setup() {
>         texts = new LinkedList<>();
>         Random random = new Random();
>         for (int index = 0; index < param; index++) {
>             char a = (char) random.nextInt();
>             texts.add(String.valueOf(a));
>         }
>     }
>
>     @GenerateMicroBenchmark
>     public void stringBuffer(BlackHole bh) {
>         StringBuffer sb = new StringBuffer();
>         texts.stream().forEach(sb::append);
>         bh.consume(sb.toString());
>     }
>
>     @GenerateMicroBenchmark
>     public void stringBuilder(BlackHole bh) {
>         StringBuilder sb = new StringBuilder();
>         texts.stream().forEach(sb::append);
>         bh.consume(sb.toString());
>     }
>  }
>
>
> java -jar target/microbenchmarks.jar ".*StringBufferBenchmark*." -wi 20 -i
> 20 -f 1
>
> Benchmark                                (param)   Mode   Samples
> Mean   Mean error    Units
> m.StringBufferBenchmark.stringBuffer    10000000  thrpt        20
>  3.208        0.406    ops/s
> m.StringBufferBenchmark.stringBuilder   10000000  thrpt        20
>  4.795        0.037    ops/s
> --
>
> Ot?vio Gon?alves de Santana
>
> twitter: http://twitter.com/otaviojava
> site:     *http://about.me/otaviojava <http://about.me/otaviojava>*
> 55 (11) 98255-3513
>



-- 
Ot?vio Gon?alves de Santana

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


From paul.sandoz at oracle.com  Thu Feb  5 14:06:45 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 5 Feb 2015 15:06:45 +0100
Subject: [9] RFR of 8066842: java.math.BigDecimal.divide(BigDecimal,
	RoundingMode) produces incorrect result
In-Reply-To: <27F1BCB8-8160-4E82-A12C-2932C33EE9D5@oracle.com>
References: <27F1BCB8-8160-4E82-A12C-2932C33EE9D5@oracle.com>
Message-ID: <663493B4-4B15-4DFD-8E84-695F59FFC80C@oracle.com>

Hi Brian.

I don't claim to understand the fine details of these methods but i can see how the new method avoid loosing bits.

4947     private static long[] divRemNegativeLong(long n, long d) {
4948         if (n >= 0) {
4949             throw new IllegalArgumentException("Non-negative numerator");
4950         } else if (d == 1) {
4951             return new long[]{0, n};
4952         }

Why not use an assert instead of an IAE since this is an internal method. Also the case of d ==1 could be pulled out just like for the case of tmp being +ve: 

  if (v1 == 1) {
    q1 = tmp;
    r_tmp = 0;
  } else if (tmp >= 0) {
    ...
  } else {
    ...
  }

then the asserts would be:

  assert n < 0 :  n;
  assert d != 1 : d;

Paul. 

On Jan 16, 2015, at 10:18 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> Hello,
> 
> Please review at your convenience.
> 
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8066842
> Patch:	http://cr.openjdk.java.net/~bpb/8066842/webrev.00/
> 
> The problem appears to have been that at line 4941 of the old source, in the divWord() method, one or both of the long variables ?r? and ?q? overflowed the range of int so that information was lost when these variables were truncated to 32 bits. The code of divWord() seems to have been ported from a method of the same name in MutableBigInteger wherein its constraints were made explicit. In the patch, divWord() is replaced by divRemNegativeLong(), and the use of the former in divideAndRound128() replaced with inline code for the non-negative dividend cases, and by divRemNegativeLong() for the negative dividend cases.
> 
> Thanks,
> 
> Brian



From xueming.shen at oracle.com  Thu Feb  5 19:00:19 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 05 Feb 2015 11:00:19 -0800
Subject: RFR: JDK-8030179: java/nio/Buffer/Chars.java, testcases seems all
	pass but jtreg/testng failed with java.lang.AssertionError
Message-ID: <54D3BDC3.8060707@oracle.com>

Hi,

Please help review the fix for #8030179

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

This is the regression bug introduced in jdk7 when trying to optimize the single
byte encoding loop, in which the "optimization" code inappropriately updates the
"sl" (source limit) value and triggers misbehavior of the sgp parser (in which it
mistakenly returns "underflow" when it sees a high surrogate but can't see the next
low surrogate, because the "sl" is changed...)

Thanks!
-Sherman


From paul.sandoz at oracle.com  Thu Feb  5 20:47:27 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 5 Feb 2015 21:47:27 +0100
Subject: RFR: JDK-8030179: java/nio/Buffer/Chars.java,
	testcases seems all pass but jtreg/testng failed with
	java.lang.AssertionError
In-Reply-To: <54D3BDC3.8060707@oracle.com>
References: <54D3BDC3.8060707@oracle.com>
Message-ID: <D2E8E969-2A91-4C60-962F-7BD4CE74B6B5@oracle.com>


On Feb 5, 2015, at 8:00 PM, Xueming Shen <xueming.shen at oracle.com> wrote:

> Hi,
> 
> Please help review the fix for #8030179
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8030179
> webrev: http://cr.openjdk.java.net/~sherman/8030179/webrev
> 
> This is the regression bug introduced in jdk7 when trying to optimize the single
> byte encoding loop, in which the "optimization" code inappropriately updates the
> "sl" (source limit) value and triggers misbehavior of the sgp parser (in which it
> mistakenly returns "underflow" when it sees a high surrogate but can't see the next
> low surrogate, because the "sl" is changed...)
> 

The fix looks good, but i would like to suggest some changes to the test.

We can use TestNG to avoid pulling in a bunch of infrastructure methods. 

The test cases can be produced by a data provider and we can do a cross product with char sets and character input (for example i have managed to induced stack overflows by just passing sequences of high surrogates).

Using the data provider allows the test infrastrcture to report/crunch those tests individually rather than being reported via System.out.

I can send a patch to the test if that helps.

Paul.


From xueming.shen at oracle.com  Thu Feb  5 20:50:27 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 05 Feb 2015 12:50:27 -0800
Subject: RFR: JDK-8030179: java/nio/Buffer/Chars.java, testcases seems
	all pass but jtreg/testng failed with java.lang.AssertionError
In-Reply-To: <D2E8E969-2A91-4C60-962F-7BD4CE74B6B5@oracle.com>
References: <54D3BDC3.8060707@oracle.com>
	<D2E8E969-2A91-4C60-962F-7BD4CE74B6B5@oracle.com>
Message-ID: <54D3D793.1060002@oracle.com>

On 02/05/2015 12:47 PM, Paul Sandoz wrote:
> On Feb 5, 2015, at 8:00 PM, Xueming Shen<xueming.shen at oracle.com>  wrote:
>
>> Hi,
>>
>> Please help review the fix for #8030179
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8030179
>> webrev: http://cr.openjdk.java.net/~sherman/8030179/webrev
>>
>> This is the regression bug introduced in jdk7 when trying to optimize the single
>> byte encoding loop, in which the "optimization" code inappropriately updates the
>> "sl" (source limit) value and triggers misbehavior of the sgp parser (in which it
>> mistakenly returns "underflow" when it sees a high surrogate but can't see the next
>> low surrogate, because the "sl" is changed...)
>>
> The fix looks good, but i would like to suggest some changes to the test.
>
> We can use TestNG to avoid pulling in a bunch of infrastructure methods.
>
> The test cases can be produced by a data provider and we can do a cross product with char sets and character input (for example i have managed to induced stack overflows by just passing sequences of high surrogates).
>
> Using the data provider allows the test infrastrcture to report/crunch those tests individually rather than being reported via System.out.
>
> I can send a patch to the test if that helps.

That will be appreciated :-)

Thanks!
Sherman



From Alan.Bateman at oracle.com  Thu Feb  5 20:58:36 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 05 Feb 2015 20:58:36 +0000
Subject: RFR: JDK-8030179: java/nio/Buffer/Chars.java, testcases seems
	all pass but jtreg/testng failed with java.lang.AssertionError
In-Reply-To: <54D3BDC3.8060707@oracle.com>
References: <54D3BDC3.8060707@oracle.com>
Message-ID: <54D3D97C.2020604@oracle.com>

On 05/02/2015 19:00, Xueming Shen wrote:
> Hi,
>
> Please help review the fix for #8030179
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8030179
> webrev: http://cr.openjdk.java.net/~sherman/8030179/webrev
>
> This is the regression bug introduced in jdk7 when trying to optimize 
> the single
> byte encoding loop, in which the "optimization" code inappropriately 
> updates the
> "sl" (source limit) value and triggers misbehavior of the sgp parser 
> (in which it
> mistakenly returns "underflow" when it sees a high surrogate but can't 
> see the next
> low surrogate, because the "sl" is changed...)
Good to see this one tracked down. The fix looks okay.

I agree with Paul on the test, we have better infrastructure now.

-Alan.


From mandy.chung at oracle.com  Thu Feb  5 21:42:13 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 05 Feb 2015 13:42:13 -0800
Subject: Review request 8072656:
	test/java/lang/reflect/Proxy/ClassRestrictions.java
	assumes app class loader be URLClassLoader
Message-ID: <54D3E3B5.3010106@oracle.com>

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8072656/webrev.00/

This updates the test to get the classpath from "test.classes" system 
property and pass it to the custom class loader (instead of calling the 
getURLs() method of the app class loader).

Mandy


From lance.andersen at oracle.com  Thu Feb  5 21:45:33 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 5 Feb 2015 16:45:33 -0500
Subject: Review request 8072656:
	test/java/lang/reflect/Proxy/ClassRestrictions.java assumes app
	class loader be URLClassLoader
In-Reply-To: <54D3E3B5.3010106@oracle.com>
References: <54D3E3B5.3010106@oracle.com>
Message-ID: <0F658AEE-BED5-499E-94AF-3A2B7D6CDF04@oracle.com>

looks fine mandy

On Feb 5, 2015, at 4:42 PM, Mandy Chung <mandy.chung at oracle.com> wrote:

> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8072656/webrev.00/
> 
> This updates the test to get the classpath from "test.classes" system property and pass it to the custom class loader (instead of calling the getURLs() method of the app class loader).
> 
> Mandy



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





From brian.burkhalter at oracle.com  Fri Feb  6 01:43:55 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 5 Feb 2015 17:43:55 -0800
Subject: [9] RFR of 8066842: java.math.BigDecimal.divide(BigDecimal,
	RoundingMode) produces incorrect result
In-Reply-To: <663493B4-4B15-4DFD-8E84-695F59FFC80C@oracle.com>
References: <27F1BCB8-8160-4E82-A12C-2932C33EE9D5@oracle.com>
	<663493B4-4B15-4DFD-8E84-695F59FFC80C@oracle.com>
Message-ID: <F11FE936-C5A8-4FBB-B2E6-3A00D7313DFD@oracle.com>

Hi Paul,

On Feb 5, 2015, at 6:06 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> I don't claim to understand the fine details of these methods but i can see how the new method avoid loosing bits.
> 
> 4947     private static long[] divRemNegativeLong(long n, long d) {
> 4948         if (n >= 0) {
> 4949             throw new IllegalArgumentException("Non-negative numerator");
> 4950         } else if (d == 1) {
> 4951             return new long[]{0, n};
> 4952         }
> 
> Why not use an assert instead of an IAE since this is an internal method.

I had actually wondered whether this could just be a ?trusted? method since the check of the first parameter is already done in the calling code, then the if-branch could be removed altogether, but I suppose the assert is safer.

> Also the case of d ==1 could be pulled out just like for the case of tmp being +ve: 
> 
>  if (v1 == 1) {
>    q1 = tmp;
>    r_tmp = 0;
>  } else if (tmp >= 0) {
>    ...
>  } else {
>    ...
>  }
> 
> then the asserts would be:
> 
>  assert n < 0 :  n;
>  assert d != 1 : d;

Thanks for the suggestions. Please see updated patch:

http://cr.openjdk.java.net/~bpb/8066842/webrev.01/

Brian

From ydwchina at gmail.com  Fri Feb  6 06:09:33 2015
From: ydwchina at gmail.com (deven you)
Date: Fri, 6 Feb 2015 14:09:33 +0800
Subject: FilePermission Canonical path optimization
In-Reply-To: <54D080F4.7080303@gmail.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
	<5491CCE0.5050501@oracle.com>
	<CADsbJL=FLpZouS3J-taphoyudUXo1WGtrSfakU5Z9+b=V1kZRQ@mail.gmail.com>
	<54D080F4.7080303@gmail.com>
Message-ID: <CADsbJLkt-dzyoJxJoH7zFPD8O=KH1hgSPb5rS0CEdp42GEV3FQ@mail.gmail.com>

Hi All,

I have updated the patch[1] according to above discussion. Please review it.

Thanks a lot

[1] http://cr.openjdk.java.net/~youdwei/ojdk-912/webrev.03/


2015-02-03 16:04 GMT+08:00 Peter Levart <peter.levart at gmail.com>:

> Hi Deven,
>
>
> On 02/03/2015 08:42 AM, deven you wrote:
>
>> Hi Sean,
>>
>> The performance degradation was reported by creating an object with always
>> getting its canonical path and there is no degradation heard after we made
>> the lazy load  patch for the canonical path.
>>
>> I have asked related people to give me an env to create this problem so
>> that I can take a close look how the application uses FilePermissions and
>> may report my analysis later.
>>
>> However, as far as I know at present, lazy loading the canonical path
>> should be a relative better solution:
>>
>> 1. fast set up time
>> 2. at run time, only necessary, the canonical path will be retrieved, the
>> best case is no canonical path used at all and the worst case is only take
>> almost the same effort as loading it at start up time.
>> 3. According to FilePermissionCollection, this is also true, the implies
>> method won't need to iterator the whole set of permissions, it will return
>> as soon as a proper permission found.
>>
>> Therefore, from general situation, I think this patch makes sense.
>>
>> To Peter,
>>
>> Even with your approach to change 'cpath' 'directory' and 'recursive' to
>> volatile and prepare their orders so that "directory" and "recursive"
>> first, "cpath" last, there is still some problem in the pattern in
>> equals()
>> and impliesIgnoreMask():
>>
>> if (cpath == null) initCpathDirectoryAndRecursive();
>> ... use 'cpath' or ''directory' or 'recursive' ...
>>
>> cpath could be null but initCpathDirectoryAndRecursive may be already
>> running in another thread therefore initCpathDirectoryAndRecursive might
>> be
>> invoked twice.
>>
>
> Good catch! Usually such redundant idempotent initialization is harmless -
> but it *must* be idempotent. Since it involves canonical path computation
> on the filesystem and the filesystem is a mutable "object", this is not
> guaranteed.
>
>
>> To solve this problem, based on your volatile solution, but still make
>> initCpathDirectoryAndRecursive as synchronized method and add below
>> statement at the beginning of this method:
>> if (cpath != null) {
>>      return;
>> }
>>
>> Even if there is another thread running, initCpathDirecotryAndRecursive()
>> will wait the completion of first thread and check cpath value and then
>> return. This solution ensures the initiating logic is run just once.
>>
>
> Right, double-checked locking (with use of volatiles and correct order of
> initialization) would be the best solution here.
>
> Regards, Peter
>
>
>
>> Thanks a lot!
>>
>>
>> Thanks a lot!
>>
>> 2014-12-18 2:35 GMT+08:00 Sean Mullan <sean.mullan at oracle.com>:
>>
>>  Hi,
>>>
>>> Can you elaborate more on the performance degradation that you are seeing
>>> at startup? Are you seeing this when you are running with or without a
>>> SecurityManager? If without a SecurityManager, can you provide some code
>>> paths/examples? As far as I can see, with the proposed fix you are moving
>>> the performance hit to runtime, and it will be triggered the first time a
>>> FilePermission check is made, and at worst case it may need to
>>> canonicalize
>>> all the FilePermissions in the FilePermissionCollection. Also, with the
>>> latest proposed fix you are potentially making performance worse by
>>> introducing synchronized blocks (which as Peter noted, still have some
>>> race
>>> conditions). I can understand why you want to improve application
>>> startup,
>>> but I want to make sure I understand the use case(s) a little better
>>> first.
>>>
>>> Thanks,
>>> Sean
>>>
>>
>


From atealxt at gmail.com  Fri Feb  6 07:25:18 2015
From: atealxt at gmail.com (Luis Ashurei)
Date: Fri, 6 Feb 2015 15:25:18 +0800
Subject: Optimize `AbstractStringBuilder.replace`
Message-ID: <CAAwyr+HmWarTPWv71=AtLBr_U5QyCHOhAL46T2oE6mv4841=qg@mail.gmail.com>

Hello,

I'm looking into
AbstractStringBuilder java.lang.AbstractStringBuilder.replace(int start,
int end, String str)
<http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/c10fd784956c/src/share/classes/java/lang/AbstractStringBuilder.java>

There is a array copy after `ensureCapacityInternal`, it's might
unnecessary when `newCount` equals to old count (same length of
replacement).
I can see no native optimization at my box (win7+jdk1.8.0_20),
`System.arraycopy` is slow especially copy length is large.

E.g.

> StringBuilder sb = new StringBuilder();
> for (int i = 0; i < 50000; i++) {
> sb.append("sb");
> }
> char[] charArr = sb.toString().toCharArray();
> int len = charArr.length - 3;
> for (int i = 0; i < 1000000; i++) {
> sb.replace(1, 3, "xy"); // slow
> System.arraycopy(charArr, 3, charArr, 3, len); // slow
> System.arraycopy(charArr, len, charArr, len, 1); // fast
> }


Thanks,
Luis


From Alan.Bateman at oracle.com  Fri Feb  6 07:55:20 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 06 Feb 2015 07:55:20 +0000
Subject: Review request 8072656:
	test/java/lang/reflect/Proxy/ClassRestrictions.java
	assumes app class loader be URLClassLoader
In-Reply-To: <54D3E3B5.3010106@oracle.com>
References: <54D3E3B5.3010106@oracle.com>
Message-ID: <54D47368.3040107@oracle.com>

On 05/02/2015 21:42, Mandy Chung wrote:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8072656/webrev.00/
>
> This updates the test to get the classpath from "test.classes" system 
> property and pass it to the custom class loader (instead of calling 
> the getURLs() method of the app class loader).
This looks okay.

-Alan.


From miroslav.kos at oracle.com  Fri Feb  6 08:42:38 2015
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Fri, 06 Feb 2015 09:42:38 +0100
Subject: Review request 8057645: Deprivilege JAX-WS, JAXB, JAF to extension
	class loader
In-Reply-To: <54C6A9C0.1030000@oracle.com>
References: <54C69425.1040306@oracle.com> <54C6A9C0.1030000@oracle.com>
Message-ID: <54D47E7E.6060907@oracle.com>


On 26/01/15 21:55, Alan Bateman wrote:
> On 26/01/2015 19:23, Mandy Chung wrote:
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8057645/webrev.00/
>>
>> This patch proposes to move java.xml.ws, java.xml.bind, 
>> java.activation out of the boot loader and be loaded by the extension 
>> class loader.  We grant java.xml.ws and java.xml.bind the minimum set 
>> of permissions.  java.activation hasAllPermission for now and that 
>> can be revised in the future when JAF team identifies the permission 
>> set required java.activation.
>>
>> Miroslav - can you confirm if the JAX-WS and JAXB standalone tests 
>> pass with this patch?
Yes, the tests are passing with our current configuration. Looks ok to me.

Thanks
Miran

>>
>> Existing code that assumes the defining class loader of JAX-WS, JAXB, 
>> JAF classes may be impacted by this change (e.g. the class loader 
>> delegation to the bootstrap class loader skipping the extension class 
>> loader).  They are standalone technologies that used to be loaded by 
>> non-null class loader before they were included in Java SE.  It 
>> should be rare of such dependency. Callbacks may assume java.xml.ws 
>> and java.xml.bind classes to have AllPermissions so that when running 
>> with security manager, if the permission required for callback is not 
>> part of the permission set granted to java.xml.ws and java.xml.bind, 
>> SecurityException will be thrown.  We need customer testings to 
>> identify this callback permission case and revisit if they should be 
>> granted with AllPermission for JDK 9.
> The changes looks good and will be interested to see if anyone is 
> running JAX-WS and JAXB with a security manager willing to try out JDK 
> 9 builds.
>
> -Alan.



From paul.sandoz at oracle.com  Fri Feb  6 08:51:20 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 6 Feb 2015 09:51:20 +0100
Subject: [9] RFR of 8066842: java.math.BigDecimal.divide(BigDecimal,
	RoundingMode) produces incorrect result
In-Reply-To: <F11FE936-C5A8-4FBB-B2E6-3A00D7313DFD@oracle.com>
References: <27F1BCB8-8160-4E82-A12C-2932C33EE9D5@oracle.com>
	<663493B4-4B15-4DFD-8E84-695F59FFC80C@oracle.com>
	<F11FE936-C5A8-4FBB-B2E6-3A00D7313DFD@oracle.com>
Message-ID: <09E156F0-1015-47DC-8BCD-4F6CA088C7B2@oracle.com>


On Feb 6, 2015, at 2:43 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> Hi Paul,
> 
> On Feb 5, 2015, at 6:06 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
>> I don't claim to understand the fine details of these methods but i can see how the new method avoid loosing bits.
>> 
>> 4947     private static long[] divRemNegativeLong(long n, long d) {
>> 4948         if (n >= 0) {
>> 4949             throw new IllegalArgumentException("Non-negative numerator");
>> 4950         } else if (d == 1) {
>> 4951             return new long[]{0, n};
>> 4952         }
>> 
>> Why not use an assert instead of an IAE since this is an internal method.
> 
> I had actually wondered whether this could just be a ?trusted? method since the check of the first parameter is already done in the calling code, then the if-branch could be removed altogether, but I suppose the assert is safer.

Yes, asserts are good here, they will be enabled when testing.

> 
>> Also the case of d ==1 could be pulled out just like for the case of tmp being +ve: 
>> 
>>  if (v1 == 1) {
>>    q1 = tmp;
>>    r_tmp = 0;
>>  } else if (tmp >= 0) {
>>    ...
>>  } else {
>>    ...
>>  }
>> 
>> then the asserts would be:
>> 
>>  assert n < 0 :  n;
>>  assert d != 1 : d;
> 
> Thanks for the suggestions. Please see updated patch:
> 
> http://cr.openjdk.java.net/~bpb/8066842/webrev.01/
> 

+1, but you should remove the "@throws IAE" on divRemNegativeLong before you push.

Paul;.


From paul.sandoz at oracle.com  Fri Feb  6 10:03:45 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 6 Feb 2015 11:03:45 +0100
Subject: RFR: JDK-8030179: java/nio/Buffer/Chars.java,
	testcases seems all pass but jtreg/testng failed with
	java.lang.AssertionError
In-Reply-To: <54D3D793.1060002@oracle.com>
References: <54D3BDC3.8060707@oracle.com>
	<D2E8E969-2A91-4C60-962F-7BD4CE74B6B5@oracle.com>
	<54D3D793.1060002@oracle.com>
Message-ID: <C6631E1F-6B7E-4420-809D-6FC442438BED@oracle.com>


On Feb 5, 2015, at 9:50 PM, Xueming Shen <xueming.shen at oracle.com> wrote:

> On 02/05/2015 12:47 PM, Paul Sandoz wrote:
>> On Feb 5, 2015, at 8:00 PM, Xueming Shen<xueming.shen at oracle.com>  wrote:
>> 
>>> Hi,
>>> 
>>> Please help review the fix for #8030179
>>> 
>>> issue: https://bugs.openjdk.java.net/browse/JDK-8030179
>>> webrev: http://cr.openjdk.java.net/~sherman/8030179/webrev
>>> 
>>> This is the regression bug introduced in jdk7 when trying to optimize the single
>>> byte encoding loop, in which the "optimization" code inappropriately updates the
>>> "sl" (source limit) value and triggers misbehavior of the sgp parser (in which it
>>> mistakenly returns "underflow" when it sees a high surrogate but can't see the next
>>> low surrogate, because the "sl" is changed...)
>>> 
>> The fix looks good, but i would like to suggest some changes to the test.
>> 
>> We can use TestNG to avoid pulling in a bunch of infrastructure methods.
>> 
>> The test cases can be produced by a data provider and we can do a cross product with char sets and character input (for example i have managed to induced stack overflows by just passing sequences of high surrogates).
>> 
>> Using the data provider allows the test infrastrcture to report/crunch those tests individually rather than being reported via System.out.
>> 
>> I can send a patch to the test if that helps.
> 
> That will be appreciated :-)
> 

See below. On my Mac this runs 504 tests, 4 to 6 of which fail (i dunno where the non-determinism comes from).

In the jtreg reported output you will see stuff like this:

  test StreamEncoderOut.test(x-windows-iso2022jp, HIGH_LOW : '\ud834\udd1e"): success

Unfortunately because a StackOverflowException is printed out jtreg truncates the middle part of the output (and the system property jtreg says one can use to increase that output does not appear to work) so it's tricky to work out  what actually failed without explicitly catching the SOE and re-throwing as an assertion error.

(We should have a better way of printing out the stack trace of an SOE.)

So you could remove the Input.HIGH value in the test, commit, and log a another bug for the SOE, then add it back for the fix.

Paul.

/* @test
   @bug 8030179
   @summary test if the charset encoder deails with surrogate correctly
 * @run testng/othervm -esa StreamEncoderOut
 */

import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;

import java.io.IOException;
import java.io.OutputStream;
import java.io.OutputStreamWriter;
import java.nio.charset.Charset;
import java.util.stream.Stream;

import static java.util.stream.Collectors.joining;

@Test
public class StreamEncoderOut {

    enum Input {
        HIGH("\ud834"),
        LOW("\udd1e"),
        HIGH_LOW("\ud834\udd1e");

        final String value;

        Input(String value) {
            this.value = value;
        }

        @Override
        public String toString() {
            return name() + " : \'" + value + "\"";
        }
    }

    @DataProvider(name = "CharsetAndString")
    // [Charset, Input]
    public static Object[][] makeStreamTestData() {
        // Cross product of supported charsets and inputs
        return Charset.availableCharsets().values().stream().
                filter(Charset::canEncode).
                flatMap(c -> Stream.of(Input.values()).map(i -> new Object[]{c, i})).
                toArray(Object[][]::new);
    }

    private static String generate(String s, int n) {
        return Stream.generate(() -> s).limit(n).collect(joining());
    }

    static final OutputStream DEV_NULL = new OutputStream() {
        @Override
        public void write(byte b[], int off, int len) throws IOException {}

        @Override
        public void write(int b) throws IOException {}
    };

    @Test(dataProvider = "CharsetAndString")
    public void test(Charset cs, Input input) throws IOException {
        OutputStreamWriter w = new OutputStreamWriter(DEV_NULL, cs);
        String t = generate(input.value, 8193);
        for (int i = 0; i < 10; i++) {
            w.append(t);
        }
    }
}


From Alan.Bateman at oracle.com  Fri Feb  6 10:20:47 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 06 Feb 2015 10:20:47 +0000
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54D236AA.4050406@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CD3043.2070709@gmail.com>	<54CD4A14.2080205@oracle.com>	<54CD6984.2040004@gmail.com>	<54CDF84E.7070905@oracle.com>	<54CE03D2.8000706@gmail.com>	<54CF386A.9000600@oracle.com>	<2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>	<54CF5EF3.20102@oracle.com>
	<54CFE38D.30400@oracle.com> <54D2249E.105@oracle.com>
	<54D22CC6.9040405@gmail.com> <54D23041.1020703@oracle.com>
	<54D236AA.4050406@oracle.com>
Message-ID: <54D4957F.7070805@oracle.com>

On 04/02/2015 15:11, Chris Hegarty wrote:
> Agreed. Updated in-place
>
> http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html 
>
I think the approach and naming is good. A few small comments on the 
wording:

1. "used to locate URLStreamHandlerProvider providers" - the wording 
hints as further redirection, maybe it would be better as 
"URLStreamHandlerProvider implementations".

2. "the ordering that providers are located" - maybe this should be "the 
order that providers are located".

3. "Some protocol, that are fundamental ...". Here's a re-worded 
statement to consider:

"Some protocol handlers, for example those used for loading platform 
classes or classes on the class path, may not be overridden. The details 
of such restrictions, and when those restrictions apply (during 
initialization of the runtime for example), are implementation specific 
and therefore not specified".

One other thing in this area is setURLStreamHandlerFactory(null). Long 
standing behavior is to remove the system-wide URLStreamHandlerFactory, 
should this continue?

-Alan






From konstantin.shefov at oracle.com  Fri Feb  6 10:21:09 2015
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Fri, 06 Feb 2015 13:21:09 +0300
Subject: [8u-dev] Request for approval: JDK-6933879: URISyntaxException
	when non-alphanumeric characters are present in scope_id
In-Reply-To: <54C250F8.70808@oracle.com>
References: <54C24511.4020902@oracle.com> <54C250F8.70808@oracle.com>
Message-ID: <54D49595.7070404@oracle.com>

Hi Sean,

I have tried to use different symbols in networking interface name in 
Linux. I have added a comment to 
https://bugs.openjdk.java.net/browse/JDK-8071458

I am able to use symbols: "-", "+", "=", "#", "@".
I was UNABLE to use: "?", "~", "$", "*", "!", "[", "(", "&", "^", "|", 
"/", ":" and "\".

My network interface name in Linux is now "eth0.1_-+=#@55" (used 
"ifconfig" command).

On 23.01.2015 16:47, Se?n Coffey wrote:
> Konstantin,
>
> can you hold off pushing this fix to jdk8u for the moment ? It's a P4 
> and could have behavioural consequences (something we try and avoid in 
> update releases). I see JDK-8071458 was logged to track IPv6 scope 
> specifications. Let's see how this soaks into JDK 9 over coming days 
> and let's see how JDK-8071458 progresses.
>
> regards,
> Sean.
>
> On 23/01/15 12:56, Konstantin Shefov wrote:
>> Hello,
>>
>> Please approve the direct backport of the bug fix to 8u-dev
>>
>> Patch applies cleanly to JDK 8u.
>>
>> The bug:https://bugs.openjdk.java.net/browse/JDK-6933879
>> The webrev: http://cr.openjdk.java.net/~kshefov/6933879/webrev.01/
>>
>> JDK 9 changeset: 
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/801eb37fc6c4
>> Review thread: 
>> http://mail.openjdk.java.net/pipermail/net-dev/2015-January/008834.html
>>
>> Thanks
>> -Konstantin
>



From Roger.Riggs at Oracle.com  Fri Feb  6 14:55:24 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 06 Feb 2015 09:55:24 -0500
Subject: Time to remove deprecated Runtime.getLocalizedInput/OutputStream
	methods?
Message-ID: <54D4D5DC.3040303@Oracle.com>

Hi,

I propose to remove two methods; they have been deprecated for more
than a decade, do not seem to be in use anywhere, and have degenerate 
implementations.

java.lang.Runtime.getLocalizedInputStream(InputStream in)
java.lang.Runtime.getLocalizedOutputStream(OutputStream out)

I have not been able to find any use of them but would be happy to check 
further.

Comments and suggestions welcome,  Roger


From brian.burkhalter at oracle.com  Fri Feb  6 15:46:34 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 6 Feb 2015 07:46:34 -0800
Subject: [9] RFR of 8066842: java.math.BigDecimal.divide(BigDecimal,
	RoundingMode) produces incorrect result
In-Reply-To: <09E156F0-1015-47DC-8BCD-4F6CA088C7B2@oracle.com>
References: <27F1BCB8-8160-4E82-A12C-2932C33EE9D5@oracle.com>
	<663493B4-4B15-4DFD-8E84-695F59FFC80C@oracle.com>
	<F11FE936-C5A8-4FBB-B2E6-3A00D7313DFD@oracle.com>
	<09E156F0-1015-47DC-8BCD-4F6CA088C7B2@oracle.com>
Message-ID: <A1011F17-2432-4229-8077-1B57CAE02412@oracle.com>


On Feb 6, 2015, at 12:51 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> +1, but you should remove the "@throws IAE" on divRemNegativeLong before you push.

Mea culpa. Thanks for pointing out the (failure of) omission. Will remove before pushing.

Brian

From mark.sheppard at oracle.com  Fri Feb  6 18:55:28 2015
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Fri, 06 Feb 2015 18:55:28 +0000
Subject: RFR: JDK-8068682 - Deprivilege/move java.corba to the ext class loader
Message-ID: <54D50E20.8020406@oracle.com>

Hi
    please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8068682/webrev/
http://cr.openjdk.java.net/~msheppar/8068682/corba/webrev/

which address the issue in
https://bugs.openjdk.java.net/browse/JDK-8068682

this change means CORBA ORB is loaded by the extension class loader and
no longer has has its former privilege of system code.
as an interim measure corba is afforded all permissions privilege.
this will be reduced in coming iterations.

regards
Mark


From xueming.shen at oracle.com  Fri Feb  6 19:40:50 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 06 Feb 2015 11:40:50 -0800
Subject: RFR: JDK-8030179: java/nio/Buffer/Chars.java, testcases seems
	all pass but jtreg/testng failed with java.lang.AssertionError
In-Reply-To: <C6631E1F-6B7E-4420-809D-6FC442438BED@oracle.com>
References: <54D3BDC3.8060707@oracle.com>	<D2E8E969-2A91-4C60-962F-7BD4CE74B6B5@oracle.com>	<54D3D793.1060002@oracle.com>
	<C6631E1F-6B7E-4420-809D-6FC442438BED@oracle.com>
Message-ID: <54D518C2.3070807@oracle.com>

Thanks Paul!

Webrev has been updated to include your test, and to fix that stackoverflowexception, triggered
by the recursive implementation of StreamEncoder.flushLeftoverChar. The method really does
not need to be recursive (an alternative is to push the "leftover" from the input buffer back to
the buffer, but it appears the proposed change is simple)

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

-Sherman

On 02/06/2015 02:03 AM, Paul Sandoz wrote:
> On Feb 5, 2015, at 9:50 PM, Xueming Shen<xueming.shen at oracle.com>  wrote:
>
>> On 02/05/2015 12:47 PM, Paul Sandoz wrote:
>>> On Feb 5, 2015, at 8:00 PM, Xueming Shen<xueming.shen at oracle.com>   wrote:
>>>
>>>> Hi,
>>>>
>>>> Please help review the fix for #8030179
>>>>
>>>> issue: https://bugs.openjdk.java.net/browse/JDK-8030179
>>>> webrev: http://cr.openjdk.java.net/~sherman/8030179/webrev
>>>>
>>>> This is the regression bug introduced in jdk7 when trying to optimize the single
>>>> byte encoding loop, in which the "optimization" code inappropriately updates the
>>>> "sl" (source limit) value and triggers misbehavior of the sgp parser (in which it
>>>> mistakenly returns "underflow" when it sees a high surrogate but can't see the next
>>>> low surrogate, because the "sl" is changed...)
>>>>
>>> The fix looks good, but i would like to suggest some changes to the test.
>>>
>>> We can use TestNG to avoid pulling in a bunch of infrastructure methods.
>>>
>>> The test cases can be produced by a data provider and we can do a cross product with char sets and character input (for example i have managed to induced stack overflows by just passing sequences of high surrogates).
>>>
>>> Using the data provider allows the test infrastrcture to report/crunch those tests individually rather than being reported via System.out.
>>>
>>> I can send a patch to the test if that helps.
>> That will be appreciated :-)
>>
> See below. On my Mac this runs 504 tests, 4 to 6 of which fail (i dunno where the non-determinism comes from).
>
> In the jtreg reported output you will see stuff like this:
>
>    test StreamEncoderOut.test(x-windows-iso2022jp, HIGH_LOW : '\ud834\udd1e"): success
>
> Unfortunately because a StackOverflowException is printed out jtreg truncates the middle part of the output (and the system property jtreg says one can use to increase that output does not appear to work) so it's tricky to work out  what actually failed without explicitly catching the SOE and re-throwing as an assertion error.
>
> (We should have a better way of printing out the stack trace of an SOE.)
>
> So you could remove the Input.HIGH value in the test, commit, and log a another bug for the SOE, then add it back for the fix.
>
> Paul.
>
> /* @test
>     @bug 8030179
>     @summary test if the charset encoder deails with surrogate correctly
>   * @run testng/othervm -esa StreamEncoderOut
>   */
>
> import org.testng.annotations.DataProvider;
> import org.testng.annotations.Test;
>
> import java.io.IOException;
> import java.io.OutputStream;
> import java.io.OutputStreamWriter;
> import java.nio.charset.Charset;
> import java.util.stream.Stream;
>
> import static java.util.stream.Collectors.joining;
>
> @Test
> public class StreamEncoderOut {
>
>      enum Input {
>          HIGH("\ud834"),
>          LOW("\udd1e"),
>          HIGH_LOW("\ud834\udd1e");
>
>          final String value;
>
>          Input(String value) {
>              this.value = value;
>          }
>
>          @Override
>          public String toString() {
>              return name() + " : \'" + value + "\"";
>          }
>      }
>
>      @DataProvider(name = "CharsetAndString")
>      // [Charset, Input]
>      public static Object[][] makeStreamTestData() {
>          // Cross product of supported charsets and inputs
>          return Charset.availableCharsets().values().stream().
>                  filter(Charset::canEncode).
>                  flatMap(c ->  Stream.of(Input.values()).map(i ->  new Object[]{c, i})).
>                  toArray(Object[][]::new);
>      }
>
>      private static String generate(String s, int n) {
>          return Stream.generate(() ->  s).limit(n).collect(joining());
>      }
>
>      static final OutputStream DEV_NULL = new OutputStream() {
>          @Override
>          public void write(byte b[], int off, int len) throws IOException {}
>
>          @Override
>          public void write(int b) throws IOException {}
>      };
>
>      @Test(dataProvider = "CharsetAndString")
>      public void test(Charset cs, Input input) throws IOException {
>          OutputStreamWriter w = new OutputStreamWriter(DEV_NULL, cs);
>          String t = generate(input.value, 8193);
>          for (int i = 0; i<  10; i++) {
>              w.append(t);
>          }
>      }
> }



From brian.burkhalter at oracle.com  Fri Feb  6 20:29:57 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 6 Feb 2015 12:29:57 -0800
Subject: [9] RFR of 8066842: java.math.BigDecimal.divide(BigDecimal,
	RoundingMode) produces incorrect result
In-Reply-To: <A1011F17-2432-4229-8077-1B57CAE02412@oracle.com>
References: <27F1BCB8-8160-4E82-A12C-2932C33EE9D5@oracle.com>
	<663493B4-4B15-4DFD-8E84-695F59FFC80C@oracle.com>
	<F11FE936-C5A8-4FBB-B2E6-3A00D7313DFD@oracle.com>
	<09E156F0-1015-47DC-8BCD-4F6CA088C7B2@oracle.com>
	<A1011F17-2432-4229-8077-1B57CAE02412@oracle.com>
Message-ID: <3658ABE5-6BCE-4847-965C-B9937F5E15A4@oracle.com>


On Feb 6, 2015, at 7:46 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> On Feb 6, 2015, at 12:51 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
>> +1, but you should remove the "@throws IAE" on divRemNegativeLong before you push.
> 
> Mea culpa. Thanks for pointing out the (failure of) omission. Will remove before pushing.

FYI here is the updated webrev: http://cr.openjdk.java.net/~bpb/8066842/webrev.02/

Brian



From brent.christian at oracle.com  Fri Feb  6 21:12:23 2015
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 06 Feb 2015 13:12:23 -0800
Subject: RFC: Adding ConcurrentModificationException for
	HashMap.computeIfAbsent(), and JDK-8071667
In-Reply-To: <77020461-FD36-41FC-9996-9B476670C20D@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>
Message-ID: <54D52E37.6040705@oracle.com>

On 2/5/15 12:46 AM, Paul Sandoz wrote:
> On Feb 5, 2015, at 1:36 AM, Brent Christian
> <brent.christian at oracle.com> wrote:
>> I prefer this approach of discouraging/preventing side-effects via
>> CME, rather than allowing them.
>> ...
>> Regarding the default methods:
>> Would we be able to make a "best-effort" detection of
>> comodification...
 >>
> My inclination is to leave these as is and focus on the most common
> concrete implementations.

Fair enough.  So, spec-wise...

For Map, I'd like to add some "words of discouragement" regarding 
modifying the map from function code.  Maybe also encourage implementing 
classes to detect and throw CME? (The default method will not do so.)

For HashMap: update the doc to say concurrent mods will results in a 
CME, add @throws.

For ConcurrentMap: It does not discourage modifying the map from 
function code, but it should IMO.  It should not encourage subclasses to 
throw CME.

ConcurrentHashMap: Does it need any changes?  It already mentions that 
one "must not attempt to update any other mappings of this map."  FWIW, 
giving the side-effecty mappingFunction from 8071667 to a CHM hangs for 
me; I've not investigated. :\

I don't think any changes are needed for concrete Map impls that inherit 
the default Map methods (e.g. TreeMap, IdentityHashMap)

Here's an initial rough cut, for 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


Thanks,
-Brent


From Alan.Bateman at oracle.com  Fri Feb  6 21:21:41 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 06 Feb 2015 21:21:41 +0000
Subject: RFR: JDK-8068682 - Deprivilege/move java.corba to the ext class
	loader
In-Reply-To: <54D50E20.8020406@oracle.com>
References: <54D50E20.8020406@oracle.com>
Message-ID: <54D53065.2080603@oracle.com>

On 06/02/2015 18:55, Mark Sheppard wrote:
> Hi
>    please oblige and review the following changes
> http://cr.openjdk.java.net/~msheppar/8068682/webrev/
> http://cr.openjdk.java.net/~msheppar/8068682/corba/webrev/
>
> which address the issue in
> https://bugs.openjdk.java.net/browse/JDK-8068682
>
> this change means CORBA ORB is loaded by the extension class loader and
> no longer has has its former privilege of system code.
> as an interim measure corba is afforded all permissions privilege.
> this will be reduced in coming iterations.
Are the changes to ORB.java meant to be in this patch? I'm just 
wondering whether the dynamic stub code should be removed rather than 
commented out.

-Alan


From weijun.wang at oracle.com  Fri Feb  6 23:10:28 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Sat, 7 Feb 2015 07:10:28 +0800
Subject: FilePermission Canonical path optimization
In-Reply-To: <CADsbJLkt-dzyoJxJoH7zFPD8O=KH1hgSPb5rS0CEdp42GEV3FQ@mail.gmail.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
	<5491CCE0.5050501@oracle.com>
	<CADsbJL=FLpZouS3J-taphoyudUXo1WGtrSfakU5Z9+b=V1kZRQ@mail.gmail.com>
	<54D080F4.7080303@gmail.com>
	<CADsbJLkt-dzyoJxJoH7zFPD8O=KH1hgSPb5rS0CEdp42GEV3FQ@mail.gmail.com>
Message-ID: <AE760B48-6811-494E-AB00-FCFFE6A51B4B@oracle.com>

Hi Deven

Sorry for the noise, but in fact we are looking into removing the canonicalization step because of

 4141872: FilePermission makes symlinks useless
 https://bugs.openjdk.java.net/browse/JDK-4141872

This will be a very big incompatible change and we are still doing a feasibility study.

Of course, we won't touch jdk8u or earlier.

Thanks
Max

> On Feb 6, 2015, at 14:09, deven you <ydwchina at gmail.com> wrote:
> 
> Hi All,
> 
> I have updated the patch[1] according to above discussion. Please review it.
> 
> Thanks a lot
> 
> [1] http://cr.openjdk.java.net/~youdwei/ojdk-912/webrev.03/
> 



From mark.sheppard at oracle.com  Sat Feb  7 00:22:20 2015
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Sat, 07 Feb 2015 00:22:20 +0000
Subject: RFR: JDK-8068682 - Deprivilege/move java.corba to the ext class
	loader
In-Reply-To: <54D53065.2080603@oracle.com>
References: <54D50E20.8020406@oracle.com> <54D53065.2080603@oracle.com>
Message-ID: <54D55ABC.6090306@oracle.com>

Hi Alan,
    I had meant to remove the commented lines prior to generating the patch

regards
Mark

On 06/02/2015 21:21, Alan Bateman wrote:
> On 06/02/2015 18:55, Mark Sheppard wrote:
>> Hi
>>    please oblige and review the following changes
>> http://cr.openjdk.java.net/~msheppar/8068682/webrev/
>> http://cr.openjdk.java.net/~msheppar/8068682/corba/webrev/
>>
>> which address the issue in
>> https://bugs.openjdk.java.net/browse/JDK-8068682
>>
>> this change means CORBA ORB is loaded by the extension class loader and
>> no longer has has its former privilege of system code.
>> as an interim measure corba is afforded all permissions privilege.
>> this will be reduced in coming iterations.
> Are the changes to ORB.java meant to be in this patch? I'm just 
> wondering whether the dynamic stub code should be removed rather than 
> commented out.
>
> -Alan



From peter.firmstone at zeus.net.au  Sat Feb  7 02:38:52 2015
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 07 Feb 2015 12:38:52 +1000
Subject: Explicit Serialization API and Security
In-Reply-To: <54D0E59E.2070602@zeus.net.au>
References: <54B0CE06.2020408@zeus.net.au>
	<54B3EEC5.5040805@oracle.com>		<1421144693.7530.20.camel@Nokia-N900>
	<54B654F6.6060207@oracle.com>	<1421240334.8856.17.camel@Nokia-N900>	<54BEB91A.4020603@gmail.com>
	<54BFD374.5080803@oracle.com>	<54C00B66.5090302@zeus.net.au>
	<54C01D71.9010901@redhat.com> <54C25DB0.4080207@oracle.com>
	<54C9F888.2040005@zeus.net.au> <54C9FBE1.1070702@zeus.net.au>
	<54CA0027.2000104@zeus.net.au> <54CA0707.5010005@zeus.net.au>
	<54CA0B6D.2050105@zeus.net.au> <54CA192A.1060404@zeus.net.au>
	<54CA2581.9060906@zeus.net.au> <54CF5C86.8040505@zeus.net.au>
	<C8C89B55-C26A-4682-B906-A95378A0599E@oracle.com>
	<54D0E59E.2070602@zeus.net.au>
Message-ID: <54D57ABC.50301@zeus.net.au>

A simpler example of production code modified to support @AtomicSerial 
that satisfies invariants follows.  Note how we can't type check 
Generics with the static validator method, but the compiler does it for 
us with the constructor :)

I'm wondering if there's scope for secure alternatives of 
ObjectInputStream and ObjectOutputStream, that are backward and forward 
protocol compatible.

The disadvantage of using a constructor is circular links, however if 
these are delayed until after object construction, then the fact that 
the object was constructed successfully in the first case indicates that 
it is a legal object, with satisfied invariants.

classes interested in circular links could annotate a method, that 
accepts fields after construction, such as:

@Circular
private void setField(String name, Object value) throws 
InvalidObjectException

In this case, the class in question, can check if its invariants are 
still satisfed with the given field and only set it if they are.

Regards,

Peter.


/*
  * Licensed to the Apache Software Foundation (ASF) under one
  * or more contributor license agreements.  See the NOTICE file
  * distributed with this work for additional information
  * regarding copyright ownership. The ASF licenses this file
  * to you under the Apache License, Version 2.0 (the
  * "License"); you may not use this file except in compliance
  * with the License. You may obtain a copy of the License at
  *
  *      http://www.apache.org/licenses/LICENSE-2.0
  *
  * Unless required by applicable law or agreed to in writing, software
  * distributed under the License is distributed on an "AS IS" BASIS,
  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */

package com.artima.lookup.util;

import java.io.IOException;
import java.io.Serializable;
import java.util.Map;
import org.apache.river.api.io.AtomicSerial;
import org.apache.river.api.io.AtomicSerial.GetArg;

/**
  * An implementation of the <code>java.util.Map.Entry</code> interface 
that has
  * a serialized form consistent in all virtual machines. 
<code>ConsistentMapEntry</code>
  * instances are unmodifiable. The <code>setValue</code> mutator method
  * throws <code>UnsupportedOperationException</code>.  This class 
permits <code>null</code>
  * for values and keys.
  *
  * <p>
  * Although instances of this class are unmodifiable, they are not 
necessarily
  * immutable. If a client retrieves a mutable object (either a key or 
value) contained in a
  * <code>ConsistentMapEntry</code> and mutates that object, the client 
in effect
  * mutates the state of the <code>ConsistentMapEntry</code>. In this 
case, the
  * serialized form of the <code>ConsistentMapEntry</code> will most 
likely also
  * have been mutated. A <code>ConsistentMapEntry</code> that contains 
only immutable
  * objects will maintain a consistent serialized form indefinitely. But a
  * <code>ConsistentMapEntry</code> that contains mutable objects will 
maintain a
  * consistent serialized form only so long as the mutable objects are not
  * mutated.
  *
  * @author Bill Venners
  */
@AtomicSerial
final class ConsistentMapEntry<K,V> implements Map.Entry<K,V>, 
Serializable {

     private static final long serialVersionUID = -8633627011729114409L;

     /**
      * @serial An <code>Object</code> key, or <code>null</code>
      */
     private final K key;

     /**
      * @serial An <code>Object</code> value, or <code>null</code>
      */
     private final V value;

     /**
      * {@link AtomicSerial} constructor.
      * @param arg
      * @throws IOException
      * @throws ClassCastException if types don't match <K,V>
      */
     public ConsistentMapEntry(GetArg arg) throws IOException {
     this((K) arg.get("key", null), (V) arg.get("value", null));
     }

     /**
      * Constructs a new <code>ConsistentMapEntry</code> with passed
      * <code>key</code> and <code>value</code>. <code>null</code> is
      * allowed in either (or both) parameters.
      *
      * @param key the key (<code>null</code> key is OK)
      * @param value the value (<code>null</code> value is OK) 
associated with the key
      */
     public ConsistentMapEntry(K key, V value) {
         this.key = key;
         this.value = value;
     }

     /**
      * Returns the key.
      *
      * @return the key.
      */
     @Override
     public K getKey() {
         return key;
     }

     /**
      * Returns the value.
      *
      * @return the value.
      */
     @Override
     public V getValue() {
         return value;
     }

     /**
      * Replaces the value corresponding to this entry with the 
specified value. Because
      * all instances of this class are unmodifiable, this method always 
throws
      * <code>UnsupportedOperationException</code>.
      *
      * @throws UnsupportedOperationException always
      */
     @Override
     public V setValue(V value) {
         throw new UnsupportedOperationException();
     }

     /**
      * Compares the specified object (the <CODE>Object</CODE> passed
      * in <CODE>o</CODE>) with this <CODE>ConsistentMapEntry</CODE>
      * object for equality. Returns true if the specified object
      * is not <code>null</code>, if the specified object's class is
      * <CODE>ConsistentMapEntry</CODE>, if the keys of this object and
      * the specified object are either both <code>null</code> or 
semantically
      * equal, and the values of this object and the specified object 
are either
      * both <code>null</code> or semantically equal.
      *
      * @param o the object to compare against
      * @return <code>true</code> if the objects are the semantically equal,
      * <code>false</code> otherwise.
      */
     @Override
     public boolean equals(Object o) {

         if (o == null) {
             return false;
         }

         if (o == this) {
             return true;
         }

         // TODO: ASK JOSH SHOULD EQUALS CHECK FOR INSTANCEOF OR EXACT 
CLASS?
         if (o.getClass() != ConsistentMapEntry.class) {
             return false;
         }

         ConsistentMapEntry unmod = (ConsistentMapEntry) o;

         boolean keysEqual = equalsOrNull(key, unmod.key);
         boolean valsEqual = equalsOrNull(value, unmod.value);

         return keysEqual && valsEqual;
     }

     private static boolean equalsOrNull(Object o1, Object o2) {
         return (o1 == null ? o2 == null : o1.equals(o2));
     }

     /**
      * Returns the hash code value for this 
<CODE>ConsistentMapEntry</CODE> object.
      *
      * @return the hashcode for this object
      */
     @Override
     public int hashCode() {

         int keyHash = (key == null ? 0 : key.hashCode());
         int valueHash = (value == null ? 0 : value.hashCode());

         return keyHash ^ valueHash;
     }
}



On 4/02/2015 1:13 AM, Peter Firmstone wrote:
> Thanks Chris,
>
> see below...
>
> On 4/02/2015 12:14 AM, Chris Hegarty wrote:
>> Hi Peter,
>>
>> On 2 Feb 2015, at 11:16, Peter 
>> Firmstone<peter.firmstone at zeus.net.au>  wrote:
>>
>>> As mentioned I've been experimenting with an invariant validating 
>>> ObjectInputStream, that's backward and forward compatible with 
>>> Java's Object Serialization stream protocol.
>>>
>>> No changes have been made to ObjectOutputStream.
>>>
>>> ObjectInputStream has been overridden and reading from the stream 
>>> has been completely reimplemented.
>>>
>>> Classes are still required to implement Serializable, however 
>>> readObject methods are not called and fields are not set 
>>> reflectively after construction.
>>>
>>> After considering all possibilities, I still find myself favouring 
>>> constructors.
>> With the use of constructors:
>>   1) there is no way to reconstruct objects with truly private state
>>       ( not exposed through the constructor ),
>
> We can with caller sensitive methods, child classes don't have much 
> choice other than to call a constructor.  Child classes don't have 
> access to super class fields or state, unless via public api by 
> creating an object instance.  Internal state is not exposed, the 
> superclass can copy mutable state to ensure the child class cannot 
> gain a reference using a modified stream.
>
> Implementation of caller sensitivity:
>
> /**
>      * Dummy security manager providing access to getClassContext method.
>      */
>     private static class ClassContextAccess extends SecurityManager {
>     /**
>      * Returns caller's caller class.
>      */
>     Class caller() {
>         return getClassContext()[2];
>     }
>     }
>
>     private static final ClassContextAccess context
>         = AccessController.doPrivileged(
>     new PrivilegedAction<ClassContextAccess>(){
>
>     @Override
>     public ClassContextAccess run() {
>         return new ClassContextAccess();
>     }
>
>     });
>
>     private static class GetArgImpl extends AtomicSerial.GetArg {
>     final Map<Class,GetField> classFields;
>     final Map<Class,ReadObject> readers;
>     final ObjectInput in;
>
>     GetArgImpl(Map<Class,GetField> args, Map<Class,ReadObject> 
> readers, ObjectInput in){
>         super(false); // Avoids permission check.
>         classFields = args;
>         this.readers = readers;
>         this.in = in;
>     }
>
>     @Override
>     public ObjectStreamClass getObjectStreamClass() {
>         return classFields.get(context.caller()).getObjectStreamClass();
>     }
>
>     @Override
>     public boolean defaulted(String name) throws IOException {
>         return classFields.get(context.caller()).defaulted(name);
>     }
>
>     @Override
>     public boolean get(String name, boolean val) throws IOException {
>         return classFields.get(context.caller()).get(name, val);
>     }
>
>     @Override
>     public byte get(String name, byte val) throws IOException {
>         return classFields.get(context.caller()).get(name, val);
>     }
>
>     @Override
>     public char get(String name, char val) throws IOException {
>         return classFields.get(context.caller()).get(name, val);
>     }
>
>     @Override
>     public short get(String name, short val) throws IOException {
>         return classFields.get(context.caller()).get(name, val);
>     }
>
>     @Override
>     public int get(String name, int val) throws IOException {
>         return classFields.get(context.caller()).get(name, val);
>     }
>
>     @Override
>     public long get(String name, long val) throws IOException {
>         return classFields.get(context.caller()).get(name, val);
>     }
>
>     @Override
>     public float get(String name, float val) throws IOException {
>         return classFields.get(context.caller()).get(name, val);
>     }
>
>     @Override
>     public double get(String name, double val) throws IOException {
>         return classFields.get(context.caller()).get(name, val);
>     }
>
>     @Override
>     public Object get(String name, Object val) throws IOException {
>         return classFields.get(context.caller()).get(name, val);
>     }
>
>     @Override
>     public Collection getObjectStreamContext() {
>         if (in instanceof ObjectStreamContext)
>         return ((ObjectStreamContext)in).getObjectStreamContext();
>         return Collections.emptyList();
>     }
>
>     @Override
>     public Class[] serialClasses() {
>         return classFields.keySet().toArray(new 
> Class[classFields.size()]);
>     }
>
>     @Override
>     public ReadObject getReader() { //TODO capture any Exceptions and 
> rethrow here.
>         Class c = context.caller();
>         return readers.get(context.caller());
>     }
>
>     }
>
>
>>
>>   2) there is no way to enforce constraints on mutable state which
>>       may have constraints enforced through the API
> Can you elaborate for me please?
>
>>   3) Serializable classes are required to expose a public/protected
>>       single args GetArg constructor, for subclasses to call ( this is
>>       an issue if you do not control the whole hierarchy )
> Only if these classes are intended to be public api and subclassed.  A 
> method serialClasses() has been provided to allow implementors to 
> check the class hierarchy.  Otherwise yes, you must provide a public, 
> default or protected constructor.  At present protected constructor's 
> are not called by the atomic serial implementation.
>
> To instantiate a GetArg instance requires 
> SerializablePermission("enableSubclassImplementation").
>
> The subclass can't tamper with GetArg state without permission, it can 
> only call this constructor using a null reference or GetArg instance 
> passed to it's constructor, otherwise it can call another 
> constructor.  For example it might create a superclass instance, call 
> some getters , then pass these references to another superclass 
> constructor instead of GetArg.
>
>>   4) Subclasses need to make assumptions about abstract
>>       superclasses, so they can create ?fake? instances for checking
>>
>> See my, not factually correct, example below [*]
>
> Yes, that's true, how well this works depends on how the api is 
> designed or expressed.  I find this is often much simpler in practise, 
> after implementing it on a number of existing classes.
>>> Definition of "Cumbersome":
>>>     Slow or complicated and therefore inefficient.
>> With larger hierarchies, and abstract classes, it becomes more 
>> difficult [*].
>
> Less so if you only rely on proper encapsulation and public api.   
> Duplicate method calls and invariant checks don't hurt performance.
>
>
>>> During implementation, I've found that static invarient check 
>>> methods are often shared with other constructors.
>> Yes, they can be somewhat, but will most likely throw different 
>> exceptions [*].
>
> Yes, I typically catch these exceptions and throw a 
> IllegalObjectException with the original exception as the cause.
>
> I see you've picked that up too :)
>
>>> If another constructor already has a static invariant checking 
>>> method, you only need call that constructor.
>>>
>>> Performance wise, constructors significantly outperform setting 
>>> every field using reflection, the more fields an Object has, the 
>>> greater the performance benefit.
>> Interesting observation.
>>
>>> My experience is using constructors is often easier to understand 
>>> than readObject methods.
>> With larger hierarchies it comes complicated very quickly [*], and 
>> easy to miss a call to a check method. That said, I agree readObject 
>> methods can be hard to understand sometimes, but they can enforce 
>> invariants on truly private, or mutable, state.
>
> Constructors provide wider and more flexible capabilities.   
> Invariants are much more difficult to enforce with readObject() 
> methods, and it isn't always possible to enforce them after the object 
> is created.
>
>>> Because constructors can be chained, I can perform final freezes in 
>>> one constructor, then publish safely using another, existing 
>>> readObject methods cannot provide this functionality.  If a final 
>>> freeze occurs after the readObject method terminates, there is no 
>>> way to fix existing code that uses unsafe publication.
>> I think we can make the existing serialization mechanism much better 
>> when it comes to the setting of finals. Peter Levart and I are 
>> already looking at this, and hopefully will come up with a proposal 
>> soon.
>
> Yes any progress on this front is good, however constructors do 
> provide more flexibility and wider scope.
>
>>> See that attached example, this is actual production code (with the 
>>> addition of @AtomicSerial), Java's RMI also has a DGC 
>>> implementation.  In this example using standard Serialization, 
>>> because a final freeze occurs after readObject exits, the 
>>> implementation uses unsafe publication, all guarantees are off.
>> Yes, just like the construction of any object, unsafe publication 
>> is... well unsafe.
>
> Unfortunately we can't chain readObejct() methods, so can't invoke 
> final freezes (like we can with constructors) to allow safe 
> publication from within readObject().  Although I think it's possible 
> in most cases to use a validator after the object graph has been 
> reconstructed for publication, but requries additional knowledge.  I 
> think developers are more familiar with constructors, final freeze 
> behaviour and safe publication.
>
> Another problem with readObject() methods arises if you need to modify 
> your serial form, reflection is required to set final fields, which 
> requires privileges, which places the code at risk of privilege 
> escallation due to programmer errror.
>
>>> The annotations I've used are:
>>> @AtomicSerial - indicates serial constructor is present.
>>> @ReadInput - provides access to a ReadObject implementation for 
>>> direct interaction with the stream, prior to object construction, 
>>> provided for backward compatiblility.
>>>
>>> However the existing readObject alternative is all too often:
>>>     Insecure and unsafely published.
>>>
>>> The real question:
>>>
>>> Is secure Serialization worth the additional work?
>> Yes, I think it is worth exploring the possibility.  We have already 
>> discussed a number of ideas/alternatives in this email thread, and 
>> work is progressing on bringing a number of them to fruition.
>
> Glad to see there's interest.
>
>>> To those who would value it, I think the answer will be yes, to 
>>> those that don't, perhaps not?
>>>
>>> Regards,
>>>
>>> Peter.
>> -Chris.
>>
>>
>> [*]
>>
>> abstract class Animal implements Serializable {
>>      private final String category;
>>      // serializable mutable state
>>      private long age;
>>      // serializable state not passed as an arg to the constructor
>>      private final Object ageLock = new Object();
>>      protected final boolean hasLegs;
>>
>>      private static Void check(String category) {
>>          requireNonNull(category);
>>          return null;
>>      }
>>
>>      public Animal(String category) {
>>          this(check(category), category);
>>      }
>>
>>      private Animal(Void check, String category) {
>>          this.category = category;
>>          hasLegs = hasLegs();
>>      }
>>
>>      private static Void checkSerial(String category) throws 
>> InvalidObjectException {
>>          try {
>>              check(category);
>>          } catch (Exception x) {
>>              InvalidObjectException e = new 
>> InvalidObjectException("Invalid Object");
>>              e.addSuppressed(x);
>>              throw e;
>>          }
>>          return null;
>>      }
>>
>>      protected Animal(GetArg arg) throws InvalidObjectException {
>>          this(checkSerial(arg.get("category", null)), 
>> arg.get("category", null));
>>      }
>>
>>      void setAge(long age) {
>>          if (age<  0)
>>              throw new IllegalArgumentException();
>>          synchronized(ageLock) { this.age = age; }
>>      }
>>      long getAge() { synchronized(ageLock) { return age; } }
>>
>>      abstract boolean hasLegs();
>> }
>>
>> abstract class Mammal extends Animal implements Serializable {
>>      private final int numberOfLegs;
>>
>>      private static Void check(int numberOfLegs) {
>>          if (numberOfLegs<= 0)   // All mammals must have legs!
>>              throw new IllegalArgumentException("Invalid number of 
>> legs");
>>          return null;
>>      }
>>
>>      public Mammal(String category, int numberOfLegs) {
>>          this(check(numberOfLegs), category, numberOfLegs);
>>      }
>>
>>      private Mammal(Void check, String category, int numberOfLegs) {
>>          super(category);
>>          this.numberOfLegs = numberOfLegs;
>>          assert hasLegs() == hasLegs;
>>      }
>>
>>      private static Void checkSerial(GetArg arg) throws 
>> InvalidObjectException {
>>          Animal animal = new Animal(arg) {
>>              @Override boolean hasLegs() { return false; /* or true, 
>> how what this will impact? * */ }
>>          };
>>          try {
>>              check(arg.get("numberOfLegs", -1));
>>          } catch (Exception x) {
>>              InvalidObjectException e = new 
>> InvalidObjectException("Invalid Object");
>>              e.addSuppressed(x);
>>              throw e;
>>          }
>>          return null;
>>      }
>>
>>      protected Mammal(GetArg arg) throws InvalidObjectException {
>>          this(checkSerial(arg), arg.get("category", null), 
>> arg.get("numberOfLegs", -1));
>>      }
>>
>>      @Override boolean hasLegs() { return true; }
>>
>>      abstract boolean hasFur();
>> }
>>
>> class Dog extends Mammal implements Serializable {
>>      private final String breed;
>>
>>      private static Void check(String breed) {
>>          requireNonNull(breed); return null;
>>      }
>>
>>      public Dog(String breed) {
>>          this(check(breed), breed);
>>      }
>>
>>      private Dog(Void check, String breed) {
>>          super("canine", 4);
>>          this.breed = breed;
>>      }
>>
>>      private static Void checkSerial(GetArg arg) throws 
>> InvalidObjectException {
>>          Mammal mammal = new Mammal(arg) {
>>              @Override boolean hasLegs() { return false; /* or true, 
>> how what this will impact? * */ }
>>              @Override boolean hasFur() { return false; /* or true, 
>> how what this will impact? * */ }
>>          };
>>          try {
>>              check(arg.get("breed", null));
>>          } catch (Exception x) {
>>              InvalidObjectException e = new 
>> InvalidObjectException("Invalid Object");
>>              e.addSuppressed(x);
>>              throw e;
>>          }
>>          return null;
>>      }
>>
>>      protected Dog(GetArg arg) throws IOException {
>>          this(checkSerial(arg), arg.get("breed", null));
>>      }
>>
>>      @Override boolean hasLegs() { return true; }
>>      @Override boolean hasFur() { return true; }
>> }
>>
> A rather complex example (the existing validators and constructors are 
> production code):
>
>     public MethodDesc(GetArg arg) throws IOException{
>         this(checkSerial(
>             (String) arg.get("name", null),
>             (Class []) arg.get("types", null),
>             (InvocationConstraints) arg.get("constraints", null)
>         ),
>         (String) arg.get("name", null),
>         (Class[]) arg.get("types", null),
>         (InvocationConstraints) arg.get("constraints", null)
>         );
>     }
>
>     /**
>      * Creates a descriptor that only matches methods with exactly the
>      * specified name and parameter types. The constraints can be
>      * <code>null</code>, which is treated the same as an empty
>      * instance. The array passed to the constructor is neither modified
>      * nor retained; subsequent changes to that array have no effect on
>      * the instance created.
>      *
>      * @param name the name of the method
>      * @param types the formal parameter types of the method, in declared
>      * order
>      * @param constraints the constraints, or <code>null</code>
>      * @throws NullPointerException if <code>name</code> or
>      * <code>types</code> is <code>null</code> or any element of
>      * <code>types</code> is <code>null</code>
>      * @throws IllegalArgumentException if <code>name</code> is not a
>      * syntactically valid method name
>      */
>     public MethodDesc(String name,
>               Class[] types,
>               InvocationConstraints constraints)
>     {
>         this(check(name, types),
>         name,
>         types,
>         constraints
>         );
>     }
>
>     /**
>      * Creates a descriptor that matches all methods with names that
>      * equal the specified name or that match the specified pattern,
>      * regardless of their parameter types. If the specified name starts
>      * with the character '*', then this descriptor matches all methods
>      * with names that end with the rest of the specified name. If the
>      * specified name ends with the character '*', then this descriptor
>      * matches all methods with names that start with the rest of the
>      * specified name. Otherwise, this descriptor matches all methods
>      * with names that equal the specified name. The constraints can be
>      * <code>null</code>, which is treated the same as an empty instance.
>      *
>      * @param name the name of the method, with a prefix or suffix '*'
>      * permitted for pattern matching
>      * @param constraints the constraints, or <code>null</code>
>      * @throws NullPointerException if <code>name</code> is
>      * <code>null</code>
>      * @throws IllegalArgumentException if <code>name</code> does not
>      * match any syntactically valid method name
>      */
>     public MethodDesc(String name, InvocationConstraints constraints) {
>         this(check(name, null),
>         name,
>         null,
>         constraints
>         );
>     }
>
>     /**
>      * Invariant checks for de-serialization.
>      * @param name
>      * @param types
>      * @param constraints
>      * @return
>      * @throws InvalidObjectException
>      */
>     private static boolean checkSerial(
>         String name,
>         Class[] types,
>         InvocationConstraints constraints) throws InvalidObjectException
>     {
>         if (name == null) {
>         if (types != null) {
>             throw new InvalidObjectException(
>                      "cannot have types with null name");
>         }
>         } else {
>         try {
>             return check(name, types);
>         } catch (RuntimeException e) {
>             rethrow(e);
>         }
>         }
>         if (constraints != null && constraints.isEmpty()) {
>         throw new InvalidObjectException(
>                          "constraints cannot be empty");
>         }
>         return true;
>     }
>
>     /**
>      * Verifies that the name is a syntactically valid method name, or
>      * (if types is null) if the name is a syntactically valid method 
> name
>      * with a '*' appended or could be constructed from some 
> syntactically
>      * valid method name containing more than two characters by replacing
>      * the first character of that name with '*', and verifies that none
>      * of the elements of types are null.
>      */
>     private static boolean check(String name, Class[] types) {
>         boolean star = types == null;
>         int len = name.length();
>         if (len == 0) {
>         throw new IllegalArgumentException(
>                            "method name cannot be empty");
>         }
>         char c = name.charAt(0);
>         if (!Character.isJavaIdentifierStart(c) &&
>         !(star && c == '*' && len > 1))
>         {
>         throw new IllegalArgumentException("invalid method name");
>         }
>         if (star && c != '*' && name.charAt(len - 1) == '*') {
>         len--;
>         }
>         while (--len >= 1) {
>         if (!Character.isJavaIdentifierPart(name.charAt(len))) {
>             throw new IllegalArgumentException("invalid method name");
>         }
>         }
>         if (types != null) {
>         for (int i = types.length; --i >= 0; ) {
>             if (types[i] == null) {
>             throw new NullPointerException("class cannot be null");
>             }
>         }
>         }
>         return true;
>     }



From peter.firmstone at zeus.net.au  Sat Feb  7 07:20:05 2015
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 07 Feb 2015 17:20:05 +1000
Subject: Explicit Serialization API and Security
In-Reply-To: <54D57ABC.50301@zeus.net.au>
References: <54B0CE06.2020408@zeus.net.au>
	<54B3EEC5.5040805@oracle.com>		<1421144693.7530.20.camel@Nokia-N900>
	<54B654F6.6060207@oracle.com>	<1421240334.8856.17.camel@Nokia-N900>	<54BEB91A.4020603@gmail.com>
	<54BFD374.5080803@oracle.com>	<54C00B66.5090302@zeus.net.au>
	<54C01D71.9010901@redhat.com> <54C25DB0.4080207@oracle.com>
	<54C9F888.2040005@zeus.net.au> <54C9FBE1.1070702@zeus.net.au>
	<54CA0027.2000104@zeus.net.au> <54CA0707.5010005@zeus.net.au>
	<54CA0B6D.2050105@zeus.net.au> <54CA192A.1060404@zeus.net.au>
	<54CA2581.9060906@zeus.net.au> <54CF5C86.8040505@zeus.net.au>
	<C8C89B55-C26A-4682-B906-A95378A0599E@oracle.com>
	<54D0E59E.2070602@zeus.net.au> <54D57ABC.50301@zeus.net.au>
Message-ID: <54D5BCA5.4030708@zeus.net.au>

Some performance figures, atomic de-serialization using loopback local 
network sockets, codebase downloads, dynamic class loading, with 
security manager and policies in force and Jini extensible remote method 
invocation, there's communication going on between 4 different jvm 
instances, the one consuming the most cpu% shown:


"Hot Spots - Method","Self time [%]","Self time","Self time (CPU)","Samples"
"java.net.DualStackPlainSocketImpl.accept0[native]()","32.93283","835657.833 
ms","835657.833 ms","9"
"java.net.TwoStacksPlainDatagramSocketImpl.peekData[native]()","23.122272","586718.719 
ms","586718.719 ms","7"
"java.net.TwoStacksPlainDatagramSocketImpl.socketNativeSetOption[native]()","19.53974","495813.33 
ms","495813.33 ms","31"
"java.net.SocketInputStream.socketRead0[native]()","17.010353","431631.101 
ms","431631.101 ms","49"
"sun.management.ThreadImpl.dumpThreads0[native]()","5.5209646","140092.335 
ms","140092.335 ms","18"
"sun.misc.Unsafe.unpark[native]()","0.82664025","20975.676 
ms","20975.676 ms","25"
"java.io.ObjectOutputStream.writeObject()","0.2538986","6442.578 
ms","6442.578 ms","11"
"sun.reflect.Reflection.getCallerClass[native]()","0.22958349","5825.592 
ms","5825.592 ms","1"
"java.io.ObjectOutputStream$BlockDataOutputStream.getUTFLength()","0.19049801","4833.813 
ms","4833.813 ms","1"
"java.security.AccessController.doPrivileged[native]()","0.10722659","2720.833 
ms","2720.833 ms","111"
"java.net.DualStackPlainSocketImpl.connect0[native]()","0.049821686","1264.206 
ms","1264.206 ms","2"
"java.net.SocketOutputStream.socketWrite0[native]()","0.037383154","948.583 
ms","948.583 ms","3"
"java.lang.Class.isArray[native]()","0.027840897","706.452 ms","706.452 
ms","1"
"org.apache.river.api.io.AtomicObjectInputStream.readObjectOverride()","0.023234444","20588.805 
ms","589.565 ms","39"
"java.lang.Thread.interrupt0[native]()","0.019693227","499.708 
ms","499.708 ms","1"
"java.net.URLClassLoader.isSealed()","0.019693227","499.708 ms","499.708 
ms","1"
"java.util.AbstractCollection.toArray()","0.018976605","481.524 
ms","481.524 ms","1"
"sun.management.ThreadImpl.getThreadInfo1[native]()","0.01107343","280.984 
ms","280.984 ms","3"
"org.apache.river.api.security.URIGrant.implies()","0.010591452","268.754 ms","268.754 
ms","2"
"java.lang.Thread.join()","0.009474391","113558.68 ms","240.409 ms","20"
"java.lang.Class.forName0[native]()","0.007706837","195.558 ms","195.558 
ms","2"
"sun.misc.Unsafe.park[native]()","0.006058181","5991413.846 ms","153.724 
ms","166"
"sun.rmi.transport.ObjectTable.getTarget()","0.004627933","117.432 
ms","117.432 ms","1"
"javax.management.Attribute.<init>()","0.0039669964","100.661 
ms","100.661 ms","1"
"java.util.concurrent.FutureTask.get()","0.0030666084","77.814 
ms","77.814 ms","35"
"org.apache.river.api.net.Uri.constructor1()","0.002617104","66.408 
ms","66.408 ms","1"
"java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.addConditionWaiter()","0.0023084884","58.577 
ms","58.577 ms","1"
"java.lang.Thread.isInterrupted[native]()","0.0021556192","54.698 
ms","54.698 ms","3"
"java.util.concurrent.ConcurrentHashMap.get()","0.0020567013","52.188 
ms","52.188 ms","1"
"java.util.concurrent.FutureTask.awaitDone()","0.0011767274","29.859 
ms","29.859 ms","34"
"java.lang.System.identityHashCode[native]()","0.0010494348","26.629 
ms","26.629 ms","1"
"java.util.concurrent.ThreadPoolExecutor.runWorker()","8.1751E-4","20.744 ms","20.744 
ms","63"
"java.io.BufferedOutputStream.flushBuffer()","5.996545E-4","15.216 
ms","15.216 ms","4"
"java.util.concurrent.locks.LockSupport.park()","0.0","0.0 ms","0.0 
ms","143"
"java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await()","0.0","0.0 
ms","0.0 ms","117"
"java.util.concurrent.ThreadPoolExecutor.getTask()","0.0","0.0 ms","0.0 
ms","108"
"java.lang.Thread.run()","0.0","0.0 ms","0.0 ms","107"
"java.net.SocketInputStream.read()","0.0","0.0 ms","0.0 ms","101"
"java.util.concurrent.LinkedBlockingQueue.take()","0.0","0.0 ms","0.0 
ms","99"
"sun.rmi.transport.Transport$1.run()","0.0","0.0 ms","0.0 ms","76"
"sun.reflect.DelegatingMethodAccessorImpl.invoke()","0.0","0.0 ms","0.0 
ms","70"
"java.lang.reflect.Method.invoke()","0.0","0.0 ms","0.0 ms","70"
"java.util.concurrent.ThreadPoolExecutor$Worker.run()","0.0","0.0 
ms","0.0 ms","63"
"java.io.ObjectInputStream.readObject()","0.0","0.0 ms","0.0 ms","59"
"java.util.concurrent.FutureTask.run()","0.0","0.0 ms","0.0 ms","54"
"java.io.BufferedInputStream.read()","0.0","0.0 ms","0.0 ms","45"
"java.io.BufferedInputStream.fill()","0.0","0.0 ms","0.0 ms","45"
"java.io.FilterInputStream.read()","0.0","0.0 ms","0.0 ms","44"
"com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2()","0.0","0.0 
ms","0.0 ms","42"
"com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn()","0.0","0.0 
ms","0.0 ms","42"
"net.jini.discovery.AbstractLookupDiscovery$14.run()","0.0","0.0 
ms","0.0 ms","40"
"sun.rmi.transport.Transport.serviceCall()","0.0","0.0 ms","0.0 ms","40"
"net.jini.discovery.AbstractLookupDiscovery.doUnicastDiscovery()","0.0","0.0 
ms","0.0 ms","40"
"sun.rmi.server.UnicastServerRef.dispatch()","0.0","0.0 ms","0.0 ms","38"
"org.apache.river.api.io.AtomicObjectInputStream.readObject()","0.0","0.0 ms","0.0 
ms","35"
"net.jini.loader.LoadClass.forName()","0.0","0.0 ms","0.0 ms","35"
"org.apache.river.api.io.AtomicObjectInputStream.readNewObject()","0.0","0.0 
ms","0.0 ms","35"
"org.apache.river.api.io.AtomicObjectInputStream.readNonPrimitiveContent()","0.0","0.0 
ms","0.0 ms","35"
"net.jini.loader.pref.PreferredClassProvider.loadClass()","0.0","0.0 
ms","0.0 ms","34"
"java.net.AbstractPlainDatagramSocketImpl.setOption()","0.0","0.0 
ms","0.0 ms","31"
"java.net.MulticastSocket.setNetworkInterface()","0.0","0.0 ms","0.0 
ms","31"
"java.net.TwoStacksPlainDatagramSocketImpl.socketSetOption()","0.0","0.0 
ms","0.0 ms","31"
"com.sun.jini.reggie.RegistrarImpl$Announce.send()","0.0","0.0 ms","0.0 
ms","30"
"java.util.concurrent.Executors$RunnableAdapter.call()","0.0","0.0 
ms","0.0 ms","27"
"org.apache.river.api.io.AtomicObjectInputStream.readFieldValues()","0.0","0.0 
ms","0.0 ms","27"
"java.util.concurrent.locks.LockSupport.unpark()","0.0","0.0 ms","0.0 
ms","25"
"java.util.concurrent.FutureTask.finishCompletion()","0.0","0.0 ms","0.0 
ms","25"
"java.util.concurrent.FutureTask.set()","0.0","0.0 ms","0.0 ms","25"
"java.lang.Object.wait[native]()","0.0","831236.688 ms","0.0 ms","24"
"java.util.concurrent.locks.LockSupport.parkNanos()","0.0","0.0 ms","0.0 
ms","23"
"javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run()","0.0","0.0 
ms","0.0 ms","22"
"javax.management.remote.rmi.RMIConnectionImpl.access$300()","0.0","0.0 
ms","0.0 ms","22"
"javax.management.remote.rmi.RMIConnectionImpl.doOperation()","0.0","0.0 
ms","0.0 ms","22"
"javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation()","0.0","0.0 
ms","0.0 ms","22"
"java.io.ObjectOutputStream.writeObject0()","0.0","0.0 ms","0.0 ms","22"
"org.apache.river.api.io.AtomicObjectInputStream.readClassDesc()","0.0","0.0 
ms","0.0 ms","22"
"com.sun.jmx.mbeanserver.PerInterface.invoke()","0.0","0.0 ms","0.0 ms","21"
"com.sun.jmx.mbeanserver.MBeanSupport.invoke()","0.0","0.0 ms","0.0 ms","21"
"java.io.ObjectInputStream.readNonProxyDesc()","0.0","0.0 ms","0.0 ms","21"
"sun.reflect.GeneratedMethodAccessor3.invoke()","0.0","0.0 ms","0.0 ms","21"
"java.io.ObjectInputStream.readClassDesc()","0.0","0.0 ms","0.0 ms","21"
"sun.reflect.misc.MethodUtil.invoke()","0.0","0.0 ms","0.0 ms","21"
"sun.reflect.misc.Trampoline.invoke()","0.0","0.0 ms","0.0 ms","21"
"javax.management.remote.rmi.RMIConnectionImpl.invoke()","0.0","0.0 
ms","0.0 ms","21"
"javax.management.StandardMBean.invoke()","0.0","0.0 ms","0.0 ms","21"
"com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke()","0.0","0.0 
ms","0.0 ms","21"
"net.jini.security.Security.doPrivileged()","0.0","0.0 ms","0.0 ms","21"
"com.sun.jmx.mbeanserver.JmxMBeanServer.invoke()","0.0","0.0 ms","0.0 
ms","21"
"com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM()","0.0","0.0 
ms","0.0 ms","21"
"net.jini.discovery.AbstractLookupDiscovery$UnicastDiscoveryTask.doRun()","0.0","0.0 
ms","0.0 ms","20"
"java.io.ObjectInputStream.readObject0()","0.0","0.0 ms","0.0 ms","20"
"org.apache.river.api.io.AtomicObjectInputStream.instantiateAtomicly()","0.0","0.0 
ms","0.0 ms","20"
"com.sun.jini.discovery.DiscoveryV1.doUnicastDiscovery()","0.0","0.0 
ms","0.0 ms","20"
"sun.rmi.server.UnicastRef.unmarshalValue()","0.0","0.0 ms","0.0 ms","20"
"com.sun.jini.start.AggregatePolicyProvider$AggregateSecurityContext$2.run()","0.0","0.0 
ms","0.0 ms","20"
"org.apache.river.api.io.AtomicObjectInputStream.readFields()","0.0","0.0 ms","0.0 
ms","20"
"java.rmi.server.RMIClassLoader.loadClass()","0.0","0.0 ms","0.0 ms","20"
"net.jini.discovery.AbstractLookupDiscovery$UnicastDiscoveryTask$1.run()","0.0","0.0 
ms","0.0 ms","20"
"net.jini.discovery.AbstractLookupDiscovery$UnicastDiscoveryTask.access$3500()","0.0","0.0 
ms","0.0 ms","20"
"net.jini.discovery.AbstractLookupDiscovery.access$3800()","0.0","0.0 
ms","0.0 ms","20"
"net.jini.io.MarshalledInstance.get()","0.0","0.0 ms","0.0 ms","20"
"net.jini.security.Security$3.run()","0.0","0.0 ms","0.0 ms","20"
"net.jini.discovery.AbstractLookupDiscovery$UnicastDiscoveryTask.run()","0.0","0.0 
ms","0.0 ms","20"
"sun.rmi.server.MarshalInputStream.resolveClass()","0.0","0.0 ms","0.0 
ms","20"
"java.io.ObjectInputStream.readOrdinaryObject()","0.0","0.0 ms","0.0 
ms","19"
"sun.reflect.GeneratedMethodAccessor30.invoke()","0.0","0.0 ms","0.0 
ms","19"
"org.apache.river.api.io.AtomicObjectInputStream.readNewClassDesc()","0.0","0.0 
ms","0.0 ms","18"
"sun.management.ThreadImpl.dumpAllThreads()","0.0","0.0 ms","0.0 ms","18"
"com.sun.jini.reggie.RegistrarImpl$Announce.announce()","0.0","0.0 
ms","0.0 ms","15"
"sun.reflect.GeneratedMethodAccessor46.invoke()","0.0","0.0 ms","0.0 
ms","15"
"java.lang.Thread.sleep[native]()","0.0","483411.567 ms","0.0 ms","15"
"net.jini.loader.ClassLoading.loadClass()","0.0","0.0 ms","0.0 ms","14"
"net.jini.io.MarshalInputStream.resolveClass()","0.0","0.0 ms","0.0 ms","14"
"net.jini.discovery.AbstractLookupDiscovery.access$1600()","0.0","0.0 
ms","0.0 ms","13"
"net.jini.discovery.AbstractLookupDiscovery.sendPacketByNIC()","0.0","0.0 ms","0.0 
ms","13"
"java.io.ObjectOutputStream.writeOrdinaryObject()","0.0","0.0 ms","0.0 
ms","12"
"java.io.ObjectOutputStream.writeSerialData()","0.0","0.0 ms","0.0 ms","12"
"sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run()","0.0","0.0 
ms","0.0 ms","11"
"sun.rmi.transport.tcp.TCPTransport.handleMessages()","0.0","0.0 
ms","0.0 ms","11"
"sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0()","0.0","0.0 
ms","0.0 ms","11"
"java.net.ServerSocket.accept()","0.0","0.0 ms","0.0 ms","9"
"java.net.DualStackPlainSocketImpl.socketAccept()","0.0","0.0 ms","0.0 
ms","9"
"java.net.AbstractPlainSocketImpl.accept()","0.0","0.0 ms","0.0 ms","9"
"java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos()","0.0","0.0 
ms","0.0 ms","9"
"java.net.PlainSocketImpl.accept()","0.0","0.0 ms","0.0 ms","9"
"java.net.ServerSocket.implAccept()","0.0","0.0 ms","0.0 ms","9"
"sun.reflect.NativeMethodAccessorImpl.invoke0[native]()","0.0","0.0 
ms","0.0 ms","8"
"sun.reflect.NativeMethodAccessorImpl.invoke()","0.0","0.0 ms","0.0 ms","8"
"com.sun.jini.thread.ThreadPool$Worker.run()","0.0","0.0 ms","0.0 ms","8"
"java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take()","0.0","0.0 
ms","0.0 ms","8"
"org.apache.river.api.io.AtomicObjectInputStream.readHierarchy()","0.0","0.0 
ms","0.0 ms","7"
"org.apache.river.api.io.AtomicObjectInputStream.defaultReadObject()","0.0","0.0 
ms","0.0 ms","7"
"org.apache.river.api.io.AtomicObjectInputStream.readObjectForClass()","0.0","0.0 
ms","0.0 ms","7"
"java.lang.ref.ReferenceQueue.remove()","0.0","0.0 ms","0.0 ms","6"
"net.jini.loader.pref.PreferredClassProvider.loadProxyClass()","0.0","0.0 ms","0.0 
ms","6"
"java.net.DatagramSocket.receive()","0.0","0.0 ms","0.0 ms","6"
"com.sun.jini.reggie.RegistrarImpl$Announce.run()","0.0","0.0 ms","0.0 
ms","6"
"java.lang.Object.wait()","0.0","0.0 ms","0.0 ms","6"
"java.io.ObjectStreamClass.invokeWriteObject()","0.0","0.0 ms","0.0 ms","6"
"sun.reflect.GeneratedMethodAccessor27.invoke()","0.0","0.0 ms","0.0 ms","6"
"java.io.ObjectOutputStream.writeArray()","0.0","0.0 ms","0.0 ms","6"
"java.io.ObjectOutputStream.defaultWriteFields()","0.0","0.0 ms","0.0 
ms","6"
"com.sun.jini.thread.ThreadPool$Task.run()","0.0","0.0 ms","0.0 ms","6"
"java.util.TreeMap.writeObject()","0.0","0.0 ms","0.0 ms","6"
"java.util.concurrent.LinkedBlockingDeque.takeFirst()","0.0","0.0 
ms","0.0 ms","6"
"com.sun.jini.reggie.RegistrarImpl$Destroy.run()","0.0","0.0 ms","0.0 
ms","6"
"java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill()","0.0","0.0 
ms","0.0 ms","5"
"java.util.concurrent.LinkedBlockingQueue.poll()","0.0","0.0 ms","0.0 
ms","5"
"java.util.concurrent.SynchronousQueue.poll()","0.0","0.0 ms","0.0 ms","5"
"java.util.concurrent.SynchronousQueue$TransferStack.transfer()","0.0","0.0 
ms","0.0 ms","5"
"net.jini.discovery.AbstractLookupDiscovery$Requestor.run()","0.0","0.0 
ms","0.0 ms","5"
"sun.rmi.server.UnicastRef.marshalValue()","0.0","0.0 ms","0.0 ms","5"
"java.net.Socket.connect()","0.0","0.0 ms","0.0 ms","4"
"java.net.Socket.<init>()","0.0","0.0 ms","0.0 ms","4"
"net.jini.loader.LoadClass$GetClassTask.call()","0.0","0.0 ms","0.0 ms","4"
"com.sun.jini.reggie.RegistrarImpl.<init>()","0.0","0.0 ms","0.0 ms","4"
"com.sun.jini.reggie.RegistrarImpl$2.run()","0.0","0.0 ms","0.0 ms","4"
"org.apache.river.api.io.AtomicObjectInputStream.readNewProxyClassDesc()","0.0","0.0 
ms","0.0 ms","4"
"com.sun.jini.reggie.RegistrarImpl$Multicast.run()","0.0","0.0 ms","0.0 
ms","3"
"com.sun.jini.reggie.RegistrarImpl$ServiceExpire.run()","0.0","0.0 
ms","0.0 ms","3"
"com.sun.jini.reggie.RegistrarImpl$Unicast.run()","0.0","0.0 ms","0.0 
ms","3"
"com.sun.jini.reggie.RegistrarImpl.access$4600()","0.0","0.0 ms","0.0 
ms","3"
"com.sun.jini.reggie.RegistrarImpl.respond()","0.0","0.0 ms","0.0 ms","3"
"com.sun.jini.start.AggregatePolicyProvider.implies()","0.0","0.0 
ms","0.0 ms","3"
"java.io.BufferedOutputStream.flush()","0.0","0.0 ms","0.0 ms","3"
"java.io.DataInputStream.readInt()","0.0","0.0 ms","0.0 ms","3"
"java.io.ObjectOutputStream$BlockDataOutputStream.flush()","0.0","0.0 
ms","0.0 ms","3"
"java.io.ObjectOutputStream.flush()","0.0","0.0 ms","0.0 ms","3"
"java.lang.SecurityManager.checkPermission()","0.0","0.0 ms","0.0 ms","3"
"java.lang.Thread.interrupted()","0.0","0.0 ms","0.0 ms","3"
"java.net.SocketOutputStream.socketWrite()","0.0","0.0 ms","0.0 ms","3"
"java.net.SocketOutputStream.write()","0.0","0.0 ms","0.0 ms","3"
"java.security.AccessControlContext.checkPermission()","0.0","0.0 
ms","0.0 ms","3"
"java.security.AccessController.checkPermission()","0.0","0.0 ms","0.0 
ms","3"
"java.security.ProtectionDomain.implies()","0.0","0.0 ms","0.0 ms","3"
"java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly()","0.0","0.0 
ms","0.0 ms","3"
"java.util.concurrent.locks.ReentrantLock.lockInterruptibly()","0.0","0.0 ms","0.0 
ms","3"
"net.jini.discovery.AbstractLookupDiscovery$AnnouncementListener.run()","0.0","0.0 
ms","0.0 ms","3"
"net.jini.discovery.AbstractLookupDiscovery$AnnouncementTimerThread.run()","0.0","0.0 
ms","0.0 ms","3"
"net.jini.discovery.AbstractLookupDiscovery$Notifier.run()","0.0","0.0 
ms","0.0 ms","3"
"net.jini.discovery.AbstractLookupDiscovery$ResponseListener.run()","0.0","0.0 
ms","0.0 ms","3"
"net.jini.discovery.AbstractLookupLocatorDiscovery$Notifier.run()","0.0","0.0 
ms","0.0 ms","3"
"net.jini.io.MarshalInputStream.resolveProxyClass()","0.0","0.0 ms","0.0 
ms","3"
"net.jini.loader.ClassLoading.loadProxyClass()","0.0","0.0 ms","0.0 ms","3"
"net.jini.loader.pref.PreferredClassProvider.loadProxyInterfaces()","0.0","0.0 
ms","0.0 ms","3"
"org.apache.river.impl.thread.SynchronousExecutors$Distributor.run()","0.0","0.0 
ms","0.0 ms","3"
"sun.management.ThreadImpl.getThreadInfo()","0.0","0.0 ms","0.0 ms","3"
"sun.reflect.GeneratedMethodAccessor56.invoke()","0.0","0.0 ms","0.0 ms","3"
"sun.rmi.transport.StreamRemoteCall.releaseOutputStream()","0.0","0.0 
ms","0.0 ms","3"
"com.sun.jini.jeri.internal.runtime.Target.dispatch()","0.0","0.0 
ms","0.0 ms","3"
"com.sun.jini.reggie.RegistrarImpl$3$1.run()","0.0","0.0 ms","0.0 ms","3"
"com.sun.jini.reggie.RegistrarImpl$AddressTask.attemptResponse()","0.0","0.0 
ms","0.0 ms","3"
"com.sun.jini.reggie.RegistrarImpl$AddressTask.run()","0.0","0.0 
ms","0.0 ms","3"
"com.sun.jini.reggie.RegistrarImpl$DecodeRequestTask.run()","0.0","0.0 
ms","0.0 ms","3"
"com.sun.jini.reggie.RegistrarImpl$EventExpire.run()","0.0","0.0 
ms","0.0 ms","3"
"com.sun.jini.start.LoaderSplitPolicyProvider.implies()","0.0","0.0 
ms","0.0 ms","2"
"java.net.PlainSocketImpl.connect()","0.0","0.0 ms","0.0 ms","2"
"java.lang.ref.Reference$ReferenceHandler.run()","0.0","0.0 ms","0.0 ms","2"
"com.sun.jini.reggie.RegistrarImpl$1.run()","0.0","0.0 ms","0.0 ms","2"
"java.lang.ref.Finalizer$FinalizerThread.run()","0.0","0.0 ms","0.0 ms","2"
"java.lang.ClassLoader.loadClass()","0.0","0.0 ms","0.0 ms","2"
"com.sun.jini.jeri.internal.mux.StreamConnectionIO$Reader.run()","0.0","0.0 
ms","0.0 ms","2"
"com.sun.jini.jeri.internal.mux.StreamConnectionIO$Writer.run()","0.0","0.0 
ms","0.0 ms","2"
"java.lang.Class.forName()","0.0","0.0 ms","0.0 ms","2"
"java.net.AbstractPlainSocketImpl.doConnect()","0.0","0.0 ms","0.0 ms","2"
"java.lang.Thread.interrupt()","0.0","0.0 ms","0.0 ms","2"
"com.sun.jini.reggie.RegistrarImpl$Multicast.<init>()","0.0","0.0 
ms","0.0 ms","2"
"net.jini.security.policy.DynamicPolicyProvider.implies()","0.0","0.0 
ms","0.0 ms","2"
"net.jini.security.policy.PolicyFileProvider.getPermissions()","0.0","0.0 ms","0.0 
ms","2"
"org.apache.river.api.security.CertificateGrant.implies()","0.0","0.0 
ms","0.0 ms","2"
"org.apache.river.api.security.ConcurrentPolicyFile.getP()","0.0","0.0 
ms","0.0 ms","2"
"java.io.ObjectInputStream.readArray()","0.0","0.0 ms","0.0 ms","2"
"org.apache.river.api.security.ConcurrentPolicyFile.getPermissions()","0.0","0.0 
ms","0.0 ms","2"
"java.io.DataInputStream.readUTF()","0.0","0.0 ms","0.0 ms","2"
"net.jini.discovery.AbstractLookupDiscovery$2.run()","0.0","0.0 ms","0.0 
ms","2"
"java.net.DualStackPlainSocketImpl.socketConnect()","0.0","0.0 ms","0.0 
ms","2"
"com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run()","0.0","0.0 
ms","0.0 ms","2"
"java.net.AbstractPlainSocketImpl.connectToAddress()","0.0","0.0 
ms","0.0 ms","2"
"java.net.AbstractPlainSocketImpl.connect()","0.0","0.0 ms","0.0 ms","2"
"com.sun.jini.qa.harness.DestroyThread.run()","0.0","0.0 ms","0.0 ms","2"
"net.jini.discovery.AbstractLookupDiscovery$ResponseListener.interrupt()","0.0","0.0 
ms","0.0 ms","2"
"net.jini.io.MarshalledInstance$3.run()","0.0","0.0 ms","0.0 ms","2"
"sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop()","0.0","0.0 
ms","0.0 ms","2"
"sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run()","0.0","0.0 
ms","0.0 ms","2"
"com.sun.jini.thread.ThreadPool$1$1.run()","0.0","0.0 ms","0.0 ms","2"
"java.net.URLClassLoader$1.run()","0.0","0.0 ms","0.0 ms","2"
"net.jini.discovery.AbstractLookupDiscovery.<init>()","0.0","0.0 
ms","0.0 ms","2"
"java.net.SocksSocketImpl.connect()","0.0","0.0 ms","0.0 ms","2"
"sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept()","0.0","0.0 
ms","0.0 ms","2"
"org.apache.river.api.net.Uri.parseAndCreate()","0.0","0.0 ms","0.0 ms","1"
"org.apache.river.api.net.Uri.urlToUri()","0.0","0.0 ms","0.0 ms","1"
"com.sun.jini.start.AggregatePolicyProvider.getContextClassLoader()","0.0","0.0 
ms","0.0 ms","1"
"java.lang.ApplicationShutdownHooks$1.run()","0.0","0.0 ms","0.0 ms","1"
"sun.management.ThreadImpl.findDeadlockedThreads()","0.0","0.0 ms","0.0 
ms","1"
"sun.management.ThreadImpl.findDeadlockedThreads0[native]()","0.0","0.0 
ms","0.0 ms","1"
"com.sun.jini.reggie.RegistrarImpl.loginAndRun()","0.0","0.0 ms","0.0 
ms","1"
"sun.misc.Launcher$AppClassLoader.loadClass()","0.0","0.0 ms","0.0 ms","1"
"sun.net.util.IPAddressUtil.textToNumericFormatV4()","0.0","0.0 ms","0.0 
ms","1"
"sun.reflect.DelegatingConstructorAccessorImpl.newInstance()","0.0","0.0 
ms","0.0 ms","1"
"java.io.ObjectStreamClass.lookup()","0.0","0.0 ms","0.0 ms","1"
"java.io.ObjectStreamClass.initNonProxy()","0.0","0.0 ms","0.0 ms","1"
"java.io.ObjectOutputStream.writeString()","0.0","0.0 ms","0.0 ms","1"
"java.io.ObjectOutputStream$HandleTable.lookup()","0.0","0.0 ms","0.0 
ms","1"
"java.io.ObjectOutputStream$HandleTable.hash()","0.0","0.0 ms","0.0 ms","1"
"sun.reflect.NativeConstructorAccessorImpl.newInstance()","0.0","0.0 
ms","0.0 ms","1"
"sun.reflect.NativeConstructorAccessorImpl.newInstance0[native]()","0.0","0.0 
ms","0.0 ms","1"
"java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode()","0.0","0.0 
ms","0.0 ms","1"
"java.io.ObjectOutputStream$BlockDataOutputStream.drain()","0.0","0.0 
ms","0.0 ms","1"
"java.io.DataInputStream.readUnsignedShort()","0.0","0.0 ms","0.0 ms","1"
"java.io.BufferedOutputStream.write()","0.0","0.0 ms","0.0 ms","1"
"com.sun.jmx.mbeanserver.MBeanSupport.getAttributes()","0.0","0.0 
ms","0.0 ms","1"
"com.sun.jini.reggie.RegistrarImpl$Initializer.<init>()","0.0","0.0 
ms","0.0 ms","1"
"com.sun.jmx.mbeanserver.JmxMBeanServer.getAttributes()","0.0","0.0 
ms","0.0 ms","1"
"com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttributes()","0.0","0.0 
ms","0.0 ms","1"
"com.sun.jini.start.NonActivatableServiceDescriptor.create()","0.0","0.0 
ms","0.0 ms","1"
"com.sun.jini.start.AggregatePolicyProvider.getCurrentSubPolicy()","0.0","0.0 
ms","0.0 ms","1"
"com.sun.jini.jeri.internal.mux.Mux.setDown()","0.0","0.0 ms","0.0 ms","1"
"com.sun.jini.jeri.internal.mux.MuxServer$1$1.run()","0.0","0.0 ms","0.0 
ms","1"
"com.sun.jini.jeri.internal.mux.MuxServer$1.run()","0.0","0.0 ms","0.0 
ms","1"
"com.sun.jini.jeri.internal.mux.StreamConnectionIO$1.read()","0.0","0.0 
ms","0.0 ms","1"
"com.sun.jini.jeri.internal.runtime.BasicExportTable$Entry.unexport()","0.0","0.0 
ms","0.0 ms","1"
"com.sun.jini.jeri.internal.runtime.DgcRequestDispatcher.dispatch()","0.0","0.0 
ms","0.0 ms","1"
"com.sun.jini.jeri.internal.runtime.ImplRefManager$Reaper.run()","0.0","0.0 
ms","0.0 ms","1"
"com.sun.jini.jeri.internal.runtime.JvmLifeSupport$1.run()","0.0","0.0 
ms","0.0 ms","1"
"com.sun.jini.jeri.internal.runtime.JvmLifeSupport$2.run()","0.0","0.0 
ms","0.0 ms","1"
"com.sun.jini.jeri.internal.runtime.JvmLifeSupport.check()","0.0","0.0 
ms","0.0 ms","1"
"com.sun.jini.jeri.internal.runtime.JvmLifeSupport.decrementKeepAliveCount()","0.0","0.0 
ms","0.0 ms","1"
"com.sun.jini.jeri.internal.runtime.Target$1.run()","0.0","0.0 ms","0.0 
ms","1"
"javax.management.remote.rmi.RMIConnectionImpl.getAttributes()","0.0","0.0 
ms","0.0 ms","1"
"javax.management.StandardMBean.getAttributes()","0.0","0.0 ms","0.0 ms","1"
"java.security.Permission.checkGuard()","0.0","0.0 ms","0.0 ms","1"
"net.jini.discovery.AbstractLookupDiscovery$AnnouncementListener.<init>()","0.0","0.0 
ms","0.0 ms","1"
"com.sun.jini.jeri.internal.runtime.Target$2.run()","0.0","0.0 ms","0.0 
ms","1"
"com.sun.jini.jeri.internal.runtime.Target.access$000()","0.0","0.0 
ms","0.0 ms","1"
"com.sun.jini.jeri.internal.runtime.Target.decrementKeepAliveCount()","0.0","0.0 
ms","0.0 ms","1"
"java.net.URLClassLoader.getAndVerifyPackage()","0.0","0.0 ms","0.0 ms","1"
"com.sun.jini.reggie.TransientRegistrarImpl.<init>()","0.0","0.0 
ms","0.0 ms","1"
"java.net.URLClassLoader.findClass()","0.0","0.0 ms","0.0 ms","1"
"java.net.URLClassLoader.defineClass()","0.0","0.0 ms","0.0 ms","1"
"java.net.URLClassLoader.access$100()","0.0","0.0 ms","0.0 ms","1"
"java.net.SocketPermission.init()","0.0","0.0 ms","0.0 ms","1"
"java.net.SocketPermission.<init>()","0.0","0.0 ms","0.0 ms","1"
"net.jini.discovery.AbstractLookupDiscovery.sendPacket()","0.0","0.0 
ms","0.0 ms","1"
"com.sun.jini.jeri.internal.runtime.Target.unexport()","0.0","0.0 
ms","0.0 ms","1"
"net.jini.discovery.LookupDiscovery.<init>()","0.0","0.0 ms","0.0 ms","1"
"net.jini.discovery.LookupDiscoveryManager.<init>()","0.0","0.0 ms","0.0 
ms","1"
"net.jini.export.ServerContext.doWithServerContext()","0.0","0.0 
ms","0.0 ms","1"
"net.jini.io.MarshalInputStream$2.run()","0.0","0.0 ms","0.0 ms","1"
"net.jini.io.MarshalInputStream.<init>()","0.0","0.0 ms","0.0 ms","1"
"net.jini.io.MarshalInputStream.check()","0.0","0.0 ms","0.0 ms","1"
"net.jini.io.MarshalledInstance$MarshalledInstanceInputStream.<init>()","0.0","0.0 
ms","0.0 ms","1"
"java.net.DatagramSocket.send()","0.0","0.0 ms","0.0 ms","1"
"net.jini.jeri.BasicInvocationDispatcher.dispatch()","0.0","0.0 ms","0.0 
ms","1"
"net.jini.jeri.BasicInvocationDispatcher.invoke()","0.0","0.0 ms","0.0 
ms","1"
"net.jini.jeri.BasicJeriExporter.unexport()","0.0","0.0 ms","0.0 ms","1"
"net.jini.jeri.connection.ServerConnectionManager$Dispatcher.dispatch()","0.0","0.0 
ms","0.0 ms","1"
"net.jini.jeri.tcp.TcpServerEndpoint$LH$1.run()","0.0","0.0 ms","0.0 ms","1"
"net.jini.jeri.tcp.TcpServerEndpoint$LH.access$400()","0.0","0.0 
ms","0.0 ms","1"
"net.jini.jeri.tcp.TcpServerEndpoint$LH.executeAcceptLoop()","0.0","0.0 
ms","0.0 ms","1"
"com.sun.jini.qa.harness.GroupImpl.startService()","0.0","0.0 ms","0.0 
ms","1"
"net.jini.loader.pref.PreferredClassProvider.checkLoader()","0.0","0.0 
ms","0.0 ms","1"
"net.jini.loader.pref.PreferredClassProvider.getRMIContextClassLoader()","0.0","0.0 
ms","0.0 ms","1"
"java.lang.reflect.Constructor.newInstance()","0.0","0.0 ms","0.0 ms","1"
"net.jini.security.Security$4.run()","0.0","0.0 ms","0.0 ms","1"
"java.lang.Thread.getContextClassLoader()","0.0","0.0 ms","0.0 ms","1"
"java.lang.System.exit()","0.0","0.0 ms","0.0 ms","1"
"java.lang.String.split()","0.0","0.0 ms","0.0 ms","1"
"java.lang.Shutdown.sequence()","0.0","0.0 ms","0.0 ms","1"
"java.lang.Shutdown.runHooks()","0.0","0.0 ms","0.0 ms","1"
"java.lang.Shutdown.exit()","0.0","0.0 ms","0.0 ms","1"
"java.lang.SecurityManager.checkMulticast()","0.0","0.0 ms","0.0 ms","1"
"java.lang.SecurityManager.checkAccept()","0.0","0.0 ms","0.0 ms","1"
"java.lang.Runtime.exit()","0.0","0.0 ms","0.0 ms","1"
"java.lang.ApplicationShutdownHooks.runHooks()","0.0","0.0 ms","0.0 ms","1"
"org.apache.river.api.net.Uri.<init>()","0.0","0.0 ms","0.0 ms","1"



From paul.sandoz at oracle.com  Sat Feb  7 15:39:05 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Sat, 7 Feb 2015 16:39:05 +0100
Subject: RFR: JDK-8030179: java/nio/Buffer/Chars.java,
	testcases seems all pass but jtreg/testng failed with
	java.lang.AssertionError
In-Reply-To: <54D518C2.3070807@oracle.com>
References: <54D3BDC3.8060707@oracle.com>	<D2E8E969-2A91-4C60-962F-7BD4CE74B6B5@oracle.com>	<54D3D793.1060002@oracle.com>
	<C6631E1F-6B7E-4420-809D-6FC442438BED@oracle.com>
	<54D518C2.3070807@oracle.com>
Message-ID: <DCA7FE7A-55B6-4324-AB82-EBDECCE74A91@oracle.com>


On Feb 6, 2015, at 8:40 PM, Xueming Shen <xueming.shen at oracle.com> wrote:

> Thanks Paul!
> 
> Webrev has been updated to include your test, and to fix that stackoverflowexception, triggered
> by the recursive implementation of StreamEncoder.flushLeftoverChar. The method really does
> not need to be recursive (an alternative is to push the "leftover" from the input buffer back to
> the buffer, but it appears the proposed change is simple)
> 
> http://cr.openjdk.java.net/~sherman/8030179/webrev/
> 

+1

Paul.


From david.holmes at oracle.com  Sun Feb  8 01:10:04 2015
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 08 Feb 2015 11:10:04 +1000
Subject: RFR: JDK-8068682 - Deprivilege/move java.corba to the ext class
	loader
In-Reply-To: <54D50E20.8020406@oracle.com>
References: <54D50E20.8020406@oracle.com>
Message-ID: <54D6B76C.5090007@oracle.com>

On 7/02/2015 4:55 AM, Mark Sheppard wrote:
> Hi
>     please oblige and review the following changes
> http://cr.openjdk.java.net/~msheppar/8068682/webrev/
> http://cr.openjdk.java.net/~msheppar/8068682/corba/webrev/
>
> which address the issue in
> https://bugs.openjdk.java.net/browse/JDK-8068682
>
> this change means CORBA ORB is loaded by the extension class loader and
> no longer has has its former privilege of system code.

Just curious but under the pre-module extension mechanism installed 
extensions had full system privileges by default[1]:

"By default, installed optional packages in this standard directory are 
trusted. That is, they are granted the same privileges as if they were 
core platform classes (those in rt.jar). This default privilege is 
specified in the system policy file (in 
<java-home>/jre/lib/security/java.policy), but can be overridden for a 
particular optional package by adding the appropriate policy file entry 
(see Permissions in the JDK)."

Does this mean that under the module system, things associated with the 
Ext loader now need explicit policy entries in all cases?

Thanks,
David

[1] 
https://docs.oracle.com/javase/8/docs/technotes/guides/extensions/spec.html

> as an interim measure corba is afforded all permissions privilege.
> this will be reduced in coming iterations.
>
> regards
> Mark


From mandy.chung at oracle.com  Sun Feb  8 06:58:57 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sat, 07 Feb 2015 22:58:57 -0800
Subject: RFR: JDK-8068682 - Deprivilege/move java.corba to the ext class
	loader
In-Reply-To: <54D6B76C.5090007@oracle.com>
References: <54D50E20.8020406@oracle.com> <54D6B76C.5090007@oracle.com>
Message-ID: <54D70931.8050500@oracle.com>


On 2/7/2015 5:10 PM, David Holmes wrote:
> On 7/02/2015 4:55 AM, Mark Sheppard wrote:
>> Hi
>>     please oblige and review the following changes
>> http://cr.openjdk.java.net/~msheppar/8068682/webrev/
>> http://cr.openjdk.java.net/~msheppar/8068682/corba/webrev/
>>
>> which address the issue in
>> https://bugs.openjdk.java.net/browse/JDK-8068682
>>
>> this change means CORBA ORB is loaded by the extension class loader and
>> no longer has has its former privilege of system code.
>
> Just curious but under the pre-module extension mechanism installed 
> extensions had full system privileges by default[1]:
>
> "By default, installed optional packages in this standard directory 
> are trusted. That is, they are granted the same privileges as if they 
> were core platform classes (those in rt.jar). This default privilege 
> is specified in the system policy file (in 
> <java-home>/jre/lib/security/java.policy), but can be overridden for a 
> particular optional package by adding the appropriate policy file 
> entry (see Permissions in the JDK)."
>
> Does this mean that under the module system, things associated with 
> the Ext loader now need explicit policy entries in all cases?

The default policy for the extensions was changed to no permission in 
JDK 9 b14:
    https://bugs.openjdk.java.net/browse/JDK-8040059

http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026575.html

Each component can further be deprivileged to the minimum set of 
permission like the recent change to JAX-WS, JAXB modules which are now 
only granted with specific permissions rather than all permissions:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-January/031023.html

Mark's patch is first to move it out from the boot loader to the ext 
class loader.  Identifying the permissions required by corba requires 
more effort and not straight-forward.  So it's granted with 
AllPermissions for now and reduce the permission set in the future.

Mandy

>
> Thanks,
> David
>
> [1] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/extensions/spec.html
>
>> as an interim measure corba is afforded all permissions privilege.
>> this will be reduced in coming iterations.
>>
>> regards
>> Mark



From ydwchina at gmail.com  Mon Feb  9 03:22:53 2015
From: ydwchina at gmail.com (deven you)
Date: Mon, 9 Feb 2015 11:22:53 +0800
Subject: FilePermission Canonical path optimization
In-Reply-To: <AE760B48-6811-494E-AB00-FCFFE6A51B4B@oracle.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
	<5491CCE0.5050501@oracle.com>
	<CADsbJL=FLpZouS3J-taphoyudUXo1WGtrSfakU5Z9+b=V1kZRQ@mail.gmail.com>
	<54D080F4.7080303@gmail.com>
	<CADsbJLkt-dzyoJxJoH7zFPD8O=KH1hgSPb5rS0CEdp42GEV3FQ@mail.gmail.com>
	<AE760B48-6811-494E-AB00-FCFFE6A51B4B@oracle.com>
Message-ID: <CADsbJLkejcZFcTJmEMHq7TC0MKj02cuEaw8=vk7bvy0scZmPCQ@mail.gmail.com>

Hi Weijun,

I see JDK-4141872 <https://bugs.openjdk.java.net/browse/JDK-4141872> marked
as Not an Issue, is there any further task continue, or there is any link
else to track this problem to remove the canonical path?

It's a big improvement if canonical path can be totally removed but I can't
figure out how we get the result of the implies* methods without canonical
path? Any more detail?

Thanks a lot!


2015-02-07 7:10 GMT+08:00 Wang Weijun <weijun.wang at oracle.com>:

> Hi Deven
>
> Sorry for the noise, but in fact we are looking into removing the
> canonicalization step because of
>
>  4141872: FilePermission makes symlinks useless
>  https://bugs.openjdk.java.net/browse/JDK-4141872
>
> This will be a very big incompatible change and we are still doing a
> feasibility study.
>
> Of course, we won't touch jdk8u or earlier.
>
> Thanks
> Max
>
> > On Feb 6, 2015, at 14:09, deven you <ydwchina at gmail.com> wrote:
> >
> > Hi All,
> >
> > I have updated the patch[1] according to above discussion. Please review
> it.
> >
> > Thanks a lot
> >
> > [1] http://cr.openjdk.java.net/~youdwei/ojdk-912/webrev.03/
> >
>
>


From weijun.wang at oracle.com  Mon Feb  9 03:51:09 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Mon, 9 Feb 2015 11:51:09 +0800
Subject: FilePermission Canonical path optimization
In-Reply-To: <CADsbJLkejcZFcTJmEMHq7TC0MKj02cuEaw8=vk7bvy0scZmPCQ@mail.gmail.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
	<5491CCE0.5050501@oracle.com>
	<CADsbJL=FLpZouS3J-taphoyudUXo1WGtrSfakU5Z9+b=V1kZRQ@mail.gmail.com>
	<54D080F4.7080303@gmail.com>
	<CADsbJLkt-dzyoJxJoH7zFPD8O=KH1hgSPb5rS0CEdp42GEV3FQ@mail.gmail.com>
	<AE760B48-6811-494E-AB00-FCFFE6A51B4B@oracle.com>
	<CADsbJLkejcZFcTJmEMHq7TC0MKj02cuEaw8=vk7bvy0scZmPCQ@mail.gmail.com>
Message-ID: <038DEF62-2C2A-4CE1-A861-CEB65F8469EE@oracle.com>


> On Feb 9, 2015, at 11:22, deven you <ydwchina at gmail.com> wrote:
> 
> Hi Weijun,
> 
> I see JDK-4141872 marked as Not an Issue, is there any further task continue, or there is any link else to track this problem to remove the canonical path?

It was marked as Not an Issue, but we are reconsidering about it.

> 
> It's a big improvement if canonical path can be totally removed but I can't figure out how we get the result of the implies* methods without canonical path? Any more detail?

The current proposed idea is that if you want to access a file using absolute path, you should add a FilePermission line in the policy file with an absolute path. If relative, relative. The overall idea is that the implies method should be implemented without consulting the actual file system but only by looking at the names themselves.

That's why I said there is a very big incompatible change. We hope people only needs to modify their policy files and do not need to rewrite their apps, but we are still investigating if this can always be true.

Thanks
Max

> 
> Thanks a lot!



From ydwchina at gmail.com  Mon Feb  9 05:27:16 2015
From: ydwchina at gmail.com (deven you)
Date: Mon, 9 Feb 2015 13:27:16 +0800
Subject: FilePermission Canonical path optimization
In-Reply-To: <038DEF62-2C2A-4CE1-A861-CEB65F8469EE@oracle.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
	<5491CCE0.5050501@oracle.com>
	<CADsbJL=FLpZouS3J-taphoyudUXo1WGtrSfakU5Z9+b=V1kZRQ@mail.gmail.com>
	<54D080F4.7080303@gmail.com>
	<CADsbJLkt-dzyoJxJoH7zFPD8O=KH1hgSPb5rS0CEdp42GEV3FQ@mail.gmail.com>
	<AE760B48-6811-494E-AB00-FCFFE6A51B4B@oracle.com>
	<CADsbJLkejcZFcTJmEMHq7TC0MKj02cuEaw8=vk7bvy0scZmPCQ@mail.gmail.com>
	<038DEF62-2C2A-4CE1-A861-CEB65F8469EE@oracle.com>
Message-ID: <CADsbJLndn_QKkDE0ethqghn8t6jhoabtLMBQuyQqfwyUwz4Y-Q@mail.gmail.com>

Hi Weijun,

>From my understanding, the new proposal will let implies method only
depends on the absolute path in policy file, correct? So it's user's
responsibility to ensure files who want to access is relative to the
absolute path in some policy file?

I personal agree this proposal. Is there any doc or link for this new
proposal? Or if you can update the information for this proposal here, I
will be very appreciate!

Thanks a lot!

2015-02-09 11:51 GMT+08:00 Wang Weijun <weijun.wang at oracle.com>:

>
> > On Feb 9, 2015, at 11:22, deven you <ydwchina at gmail.com> wrote:
> >
> > Hi Weijun,
> >
> > I see JDK-4141872 marked as Not an Issue, is there any further task
> continue, or there is any link else to track this problem to remove the
> canonical path?
>
> It was marked as Not an Issue, but we are reconsidering about it.
>
> >
> > It's a big improvement if canonical path can be totally removed but I
> can't figure out how we get the result of the implies* methods without
> canonical path? Any more detail?
>
> The current proposed idea is that if you want to access a file using
> absolute path, you should add a FilePermission line in the policy file with
> an absolute path. If relative, relative. The overall idea is that the
> implies method should be implemented without consulting the actual file
> system but only by looking at the names themselves.
>
> That's why I said there is a very big incompatible change. We hope people
> only needs to modify their policy files and do not need to rewrite their
> apps, but we are still investigating if this can always be true.
>
> Thanks
> Max
>
> >
> > Thanks a lot!
>
>


From peter.levart at gmail.com  Mon Feb  9 06:42:07 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 09 Feb 2015 07:42:07 +0100
Subject: FilePermission Canonical path optimization
In-Reply-To: <038DEF62-2C2A-4CE1-A861-CEB65F8469EE@oracle.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
	<5491CCE0.5050501@oracle.com>
	<CADsbJL=FLpZouS3J-taphoyudUXo1WGtrSfakU5Z9+b=V1kZRQ@mail.gmail.com>
	<54D080F4.7080303@gmail.com>
	<CADsbJLkt-dzyoJxJoH7zFPD8O=KH1hgSPb5rS0CEdp42GEV3FQ@mail.gmail.com>
	<AE760B48-6811-494E-AB00-FCFFE6A51B4B@oracle.com>
	<CADsbJLkejcZFcTJmEMHq7TC0MKj02cuEaw8=vk7bvy0scZmPCQ@mail.gmail.com>
	<038DEF62-2C2A-4CE1-A861-CEB65F8469EE@oracle.com>
Message-ID: <54D856BF.8070701@gmail.com>


On 02/09/2015 04:51 AM, Wang Weijun wrote:
>> On Feb 9, 2015, at 11:22, deven you <ydwchina at gmail.com> wrote:
>>
>> Hi Weijun,
>>
>> I see JDK-4141872 marked as Not an Issue, is there any further task continue, or there is any link else to track this problem to remove the canonical path?
> It was marked as Not an Issue, but we are reconsidering about it.
>
>> It's a big improvement if canonical path can be totally removed but I can't figure out how we get the result of the implies* methods without canonical path? Any more detail?
> The current proposed idea is that if you want to access a file using absolute path, you should add a FilePermission line in the policy file with an absolute path. If relative, relative. The overall idea is that the implies method should be implemented without consulting the actual file system but only by looking at the names themselves.
>
> That's why I said there is a very big incompatible change. We hope people only needs to modify their policy files and do not need to rewrite their apps, but we are still investigating if this can always be true.

Hi Max,

Of course you are aware that by trusting the symlinks, you potentially 
give much more permission than you would hope to. Suppose that some code 
has permission to read and write into a particular directory (for 
temporary files). With this permission the code can actually read and/or 
write any file in the filesystem that OS grants access to the java 
process. Merely by creating a symlink in the read/write-able directory 
and accessing the file through it. That's why Apache HTTP Server by 
default disables "FollowSymLinks" option.

Regards, Peter

> Thanks
> Max
>
>> Thanks a lot!



From weijun.wang at oracle.com  Mon Feb  9 06:44:09 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Mon, 9 Feb 2015 14:44:09 +0800
Subject: FilePermission Canonical path optimization
In-Reply-To: <CADsbJLndn_QKkDE0ethqghn8t6jhoabtLMBQuyQqfwyUwz4Y-Q@mail.gmail.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
	<5491CCE0.5050501@oracle.com>
	<CADsbJL=FLpZouS3J-taphoyudUXo1WGtrSfakU5Z9+b=V1kZRQ@mail.gmail.com>
	<54D080F4.7080303@gmail.com>
	<CADsbJLkt-dzyoJxJoH7zFPD8O=KH1hgSPb5rS0CEdp42GEV3FQ@mail.gmail.com>
	<AE760B48-6811-494E-AB00-FCFFE6A51B4B@oracle.com>
	<CADsbJLkejcZFcTJmEMHq7TC0MKj02cuEaw8=vk7bvy0scZmPCQ@mail.gmail.com>
	<038DEF62-2C2A-4CE1-A861-CEB65F8469EE@oracle.com>
	<CADsbJLndn_QKkDE0ethqghn8t6jhoabtLMBQuyQqfwyUwz4Y-Q@mail.gmail.com>
Message-ID: <A22100BA-BCD5-4113-ABCF-058C19D19DD7@oracle.com>


> On Feb 9, 2015, at 13:27, deven you <ydwchina at gmail.com> wrote:
> 
> Hi Weijun,
> 
> From my understanding, the new proposal will let implies method only depends on the absolute path in policy file, correct? So it's user's responsibility to ensure files who want to access is relative to the absolute path in some policy file?

No, you can still add a FilePermission on a relative path, and then it only allows you accessing the file with a relative path.

For example, if the current working directory is /home/me, and the policy file has

   FilePermission doc/-, read;

You can only call new FileInputStream("doc/a.txt"), you cannot call new FileInputStream("/home/me/doc/a.txt"), because without consulting the file system (i.e. canonicalize the path), there is no way to find out /home/me/doc/a.txt is inside doc.

On the other hand, if the policy file has

   FilePermission /etc/passwd, read;

You cannot call new FileInputStream("../../etc/passwd"), although we think nobody will try that.

> 
> I personal agree this proposal. Is there any doc or link for this new proposal? Or if you can update the information for this proposal here, I will be very appreciate!

Not yet. This is just an experiment, and given the incompatibility, we are still evaluating if it is doable. As I said in my previous mail, we don't want anyone to rewrite his/her apps, and we hope it's easy to modify policy files.

Actually, since this makes FilePermission simpler, there won't be a long doc.

Thanks
Max

> 
> Thanks a lot!
> 
> 2015-02-09 11:51 GMT+08:00 Wang Weijun <weijun.wang at oracle.com>:
> 
> > On Feb 9, 2015, at 11:22, deven you <ydwchina at gmail.com> wrote:
> >
> > Hi Weijun,
> >
> > I see JDK-4141872 marked as Not an Issue, is there any further task continue, or there is any link else to track this problem to remove the canonical path?
> 
> It was marked as Not an Issue, but we are reconsidering about it.
> 
> >
> > It's a big improvement if canonical path can be totally removed but I can't figure out how we get the result of the implies* methods without canonical path? Any more detail?
> 
> The current proposed idea is that if you want to access a file using absolute path, you should add a FilePermission line in the policy file with an absolute path. If relative, relative. The overall idea is that the implies method should be implemented without consulting the actual file system but only by looking at the names themselves.
> 
> That's why I said there is a very big incompatible change. We hope people only needs to modify their policy files and do not need to rewrite their apps, but we are still investigating if this can always be true.
> 
> Thanks
> Max
> 
> >
> > Thanks a lot!
> 
> 



From weijun.wang at oracle.com  Mon Feb  9 06:50:49 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Mon, 9 Feb 2015 14:50:49 +0800
Subject: FilePermission Canonical path optimization
In-Reply-To: <54D856BF.8070701@gmail.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
	<5491CCE0.5050501@oracle.com>
	<CADsbJL=FLpZouS3J-taphoyudUXo1WGtrSfakU5Z9+b=V1kZRQ@mail.gmail.com>
	<54D080F4.7080303@gmail.com>
	<CADsbJLkt-dzyoJxJoH7zFPD8O=KH1hgSPb5rS0CEdp42GEV3FQ@mail.gmail.com>
	<AE760B48-6811-494E-AB00-FCFFE6A51B4B@oracle.com>
	<CADsbJLkejcZFcTJmEMHq7TC0MKj02cuEaw8=vk7bvy0scZmPCQ@mail.gmail.com>
	<038DEF62-2C2A-4CE1-A861-CEB65F8469EE@oracle.com>
	<54D856BF.8070701@gmail.com>
Message-ID: <CDDB8EF6-44FF-4EFA-9123-14A3EEA509AE@oracle.com>


> On Feb 9, 2015, at 14:42, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi Max,
> 
> Of course you are aware that by trusting the symlinks, you potentially give much more permission than you would hope to. Suppose that some code has permission to read and write into a particular directory (for temporary files). With this permission the code can actually read and/or write any file in the filesystem that OS grants access to the java process. Merely by creating a symlink in the read/write-able directory and accessing the file through it. That's why Apache HTTP Server by default disables "FollowSymLinks" option.

Yes, we will be careful.

In Java, a LinkPermission is needed to create a link. Of course, there might be other (existing) symlinks created by other non-Java processes. We will evaluate this possibility.

Thanks
Max



From ydwchina at gmail.com  Mon Feb  9 08:01:07 2015
From: ydwchina at gmail.com (deven you)
Date: Mon, 9 Feb 2015 16:01:07 +0800
Subject: FilePermission Canonical path optimization
In-Reply-To: <CDDB8EF6-44FF-4EFA-9123-14A3EEA509AE@oracle.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
	<5491CCE0.5050501@oracle.com>
	<CADsbJL=FLpZouS3J-taphoyudUXo1WGtrSfakU5Z9+b=V1kZRQ@mail.gmail.com>
	<54D080F4.7080303@gmail.com>
	<CADsbJLkt-dzyoJxJoH7zFPD8O=KH1hgSPb5rS0CEdp42GEV3FQ@mail.gmail.com>
	<AE760B48-6811-494E-AB00-FCFFE6A51B4B@oracle.com>
	<CADsbJLkejcZFcTJmEMHq7TC0MKj02cuEaw8=vk7bvy0scZmPCQ@mail.gmail.com>
	<038DEF62-2C2A-4CE1-A861-CEB65F8469EE@oracle.com>
	<54D856BF.8070701@gmail.com>
	<CDDB8EF6-44FF-4EFA-9123-14A3EEA509AE@oracle.com>
Message-ID: <CADsbJL=8MxzP3iT5rhRbT4W4uiFpoUcgLF_WgkW_Vni5NQa+qw@mail.gmail.com>

It sounds to me like  we need additional means to protect the file
permission without canocialization. I am looking forward to seeing the new
proposal with appropriate solution for problem Peter raised.

Thanks a lot!

2015-02-09 14:50 GMT+08:00 Wang Weijun <weijun.wang at oracle.com>:

>
> > On Feb 9, 2015, at 14:42, Peter Levart <peter.levart at gmail.com> wrote:
> >
> > Hi Max,
> >
> > Of course you are aware that by trusting the symlinks, you potentially
> give much more permission than you would hope to. Suppose that some code
> has permission to read and write into a particular directory (for temporary
> files). With this permission the code can actually read and/or write any
> file in the filesystem that OS grants access to the java process. Merely by
> creating a symlink in the read/write-able directory and accessing the file
> through it. That's why Apache HTTP Server by default disables
> "FollowSymLinks" option.
>
> Yes, we will be careful.
>
> In Java, a LinkPermission is needed to create a link. Of course, there
> might be other (existing) symlinks created by other non-Java processes. We
> will evaluate this possibility.
>
> Thanks
> Max
>
>


From Alan.Bateman at oracle.com  Mon Feb  9 10:17:56 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 09 Feb 2015 10:17:56 +0000
Subject: RFR: JDK-8068682 - Deprivilege/move java.corba to the ext class
	loader
In-Reply-To: <54D70931.8050500@oracle.com>
References: <54D50E20.8020406@oracle.com> <54D6B76C.5090007@oracle.com>
	<54D70931.8050500@oracle.com>
Message-ID: <54D88954.3070009@oracle.com>

On 08/02/2015 06:58, Mandy Chung wrote:
>
> :
>
> Mark's patch is first to move it out from the boot loader to the ext 
> class loader.  Identifying the permissions required by corba requires 
> more effort and not straight-forward.  So it's granted with 
> AllPermissions for now and reduce the permission set in the future.
Just to add to Mandy's comment then another motive for this move is to 
make it easier to support the concept of "upgradable modules" that it 
cited in JEP 220. As part of JEP 220 then we have removed the legacy 
endorsed-standards override mechanism and the proposal is to bring in a 
new mechanism that allows app servers and others to override the version 
of the EE modules that are in Java SE. One module that needs to move is 
the java.transaction module but to get there requires moving the 
java.corba module first.

-Alan.


From thomas.stuefe at gmail.com  Mon Feb  9 13:30:07 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 9 Feb 2015 14:30:07 +0100
Subject: RFR (xs): JDK-8072611: (process) ProcessBuilder redirecting output to
	file should work with long file names (win)
Message-ID: <CAA-vtUyefCr13ET1FG=SraAxU9GmpERSuLAr3x73MK0Kj5H2mg@mail.gmail.com>

Hi all,

please review this small change at your convenience:

http://cr.openjdk.java.net/~stuefe/webrevs/8072611/webrev.01/webrev/

It fixes a small issue which causes ProcessBuilder not to be able to open
files to redirect into (when using Redirect.append) on windows, if that
file name is longer than 255 chars.

Kind Regards, Thomas Stuefe


From paul.sandoz at oracle.com  Mon Feb  9 14:18:56 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 9 Feb 2015 15:18:56 +0100
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <8890A88D-98D4-4F22-A71E-9C29A9F5545B@oracle.com>
References: <8890A88D-98D4-4F22-A71E-9C29A9F5545B@oracle.com>
Message-ID: <D23B81AC-3A4A-43CD-879D-D50F4A631741@oracle.com>

Here is an alternative that pushes the methods on to Pattern instead:

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/on-Pattern/webrev/

(Whe webrev reports some files as empty, please ingore those, i have this webrev stacked on the previous one.)

I have also included replaceFirst. 

This simplifies things for streaming on the match results and also for replacing. 

Note that the existing replace* methods on Matcher reset the matcher before matching and indicate that the matcher should be reset afterwards for reuse. Thus there is no loss in functionality moving such lambda accepting methods from Matcher to Pattern. It comes down to the performance of reusing a matcher, which does not seems so compelling to me.

Paul. 

On Feb 5, 2015, at 11:59 AM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:

> Hi.
> 
> Please review these stream/lambda enhancements on Matcher:
> 
>  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/
> 
> Two new methods are added to Matcher:
> 
> 1) replaceAll(Function<MatchResult, String> ) that is more flexible than the existing replaceAll that accepts a single value.
> 
> 2) Stream<MatchResult> results() that returns a stream of MatchResult for all matches.
> 
> The former does introduce a minor source incompatibility for a null argument, but then so did the new append methods accepting StringBuilder that were recently added (see JDK-8039124).
> 
> For the latter i opted to place the method on Matcher rather than Pattern as i think that is a better fit with current usages of Matcher and operating on a MatchResult. That marginally increases the complexity since co-modification checking is required.
> 
> I update the test PatternStreamTest to derive the expected result.
> 
> 
> I suppose i could add another method replaceFirst(Function<MatchResult, String> ) if anyone feels strongly about that. Consistency-wise it seems the right thing to do.
> 
> Paul.



From volker.simonis at gmail.com  Mon Feb  9 14:27:31 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 9 Feb 2015 15:27:31 +0100
Subject: RFR(XS): 8072770: [TESTBUG] Some Introspector tests fail with a Java
	heap bigger than 4GB
Message-ID: <CA+3eh12fLjTEABf_91JgKXY30PG3CLjxeF6gQXPS58Osftv5eA@mail.gmail.com>

Hi,

the three Introspector test:

java/beans/Introspector/7064279/Test7064279.java
java/beans/Introspector/Test7172865.java
java/beans/Introspector/Test7195106.java

provoke an OutOfMemory situation by repeatedly allocating constantly
growing arrays with the following loop:

int[] array = new int[1024];
while (true) {
  array = new int[array.length << 1];
}

However if we're running on a machine with plenty of RAM the default
Java heap will be bigger than ~4GB and we will get a
NegativeArraySizeException instead of an OutOfMemoryError because the
array length which is a signed int will wrap around and become
negative.

The fix is easy - just specify a concrete -Xmx value for the test:

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

Thank you and best regards,
Volker


From chris.hegarty at oracle.com  Mon Feb  9 14:57:27 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 09 Feb 2015 14:57:27 +0000
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54D4957F.7070805@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CD3043.2070709@gmail.com>	<54CD4A14.2080205@oracle.com>	<54CD6984.2040004@gmail.com>	<54CDF84E.7070905@oracle.com>	<54CE03D2.8000706@gmail.com>	<54CF386A.9000600@oracle.com>	<2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>	<54CF5EF3.20102@oracle.com>
	<54CFE38D.30400@oracle.com> <54D2249E.105@oracle.com>
	<54D22CC6.9040405@gmail.com> <54D23041.1020703@oracle.com>
	<54D236AA.4050406@oracle.com> <54D4957F.7070805@oracle.com>
Message-ID: <54D8CAD7.50303@oracle.com>

Thank you for the comments Alan.

On 06/02/15 10:20, Alan Bateman wrote:
> On 04/02/2015 15:11, Chris Hegarty wrote:
>> Agreed. Updated in-place
>>
>> http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html
>>
> I think the approach and naming is good. A few small comments on the
> wording:
>
> 1. "used to locate URLStreamHandlerProvider providers" - the wording
> hints as further redirection, maybe it would be better as
> "URLStreamHandlerProvider implementations".

Updated. ( result of previous refactoring )

> 2. "the ordering that providers are located" - maybe this should be "the
> order that providers are located".

Updated. Thanks

> 3. "Some protocol, that are fundamental ...". Here's a re-worded
> statement to consider:
>
> "Some protocol handlers, for example those used for loading platform
> classes or classes on the class path, may not be overridden. The details
> of such restrictions, and when those restrictions apply (during
> initialization of the runtime for example), are implementation specific
> and therefore not specified".

This is better. Updated.

> One other thing in this area is setURLStreamHandlerFactory(null). Long
> standing behavior is to remove the system-wide URLStreamHandlerFactory,
> should this continue?

setURLStreamHandlerFactory can be called many times with 'null', but 
once it is called with a non-null arg then it can never be called again 
( it will throw ).

What I found was that code setting the pkg prefix property would call 
setURLStreamHandlerFactory(null) to clear the protocol handlers cache, 
and subsequent lookups would then consult the updated property. This is 
really only interesting if you plan to override existing protocols, and 
appears benign.

I have not changed this in the latest webrev. It seems like a corner 
case, and could be argued either way. The spec is less than clear about 
the expected behavior of this method when you pass it null.

Updated webrev [ spec and implementation] :
   http://cr.openjdk.java.net/~chegar/8064924/04/

Regarding jaxws, I suspect that I can simply reverse the changes in the 
webrev, and do nothing. Running on pre-JDK9 the property will continue 
to be set and used, on JDK9 and later the property will be set but 
ignored. I don't see that it is necessary anyway. Looks like technical 
debt. I'll file a separate issue for Miran to follow up and verify this.

-Chris.

>
> -Alan


From Roger.Riggs at Oracle.com  Mon Feb  9 15:45:04 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 09 Feb 2015 10:45:04 -0500
Subject: RFR (xs): JDK-8072611: (process) ProcessBuilder redirecting output
	to file should work with long file names (win)
In-Reply-To: <CAA-vtUyefCr13ET1FG=SraAxU9GmpERSuLAr3x73MK0Kj5H2mg@mail.gmail.com>
References: <CAA-vtUyefCr13ET1FG=SraAxU9GmpERSuLAr3x73MK0Kj5H2mg@mail.gmail.com>
Message-ID: <54D8D600.1050803@Oracle.com>

Hi Thomas,

Conventionally,  File.deleteOnExit is used for file cleanup in the test.
An unexpected exception could leave the file around.  An alternative is to
use try {...} finally {file.delete};

Fixed file names can sometime cause issues if they are left around by
previous test runs or with a concurrent run of the same test on the same
system.  Can File.createTempFile be used with a suitably long prefix or 
suffix?
It would ensure a unique file name.

The rest looks good.

Thanks, Roger


On 2/9/15 8:30 AM, Thomas St?fe wrote:
> Hi all,
>
> please review this small change at your convenience:
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8072611/webrev.01/webrev/
>
> It fixes a small issue which causes ProcessBuilder not to be able to open
> files to redirect into (when using Redirect.append) on windows, if that
> file name is longer than 255 chars.
>
> Kind Regards, Thomas Stuefe



From volker.simonis at gmail.com  Mon Feb  9 18:48:28 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 9 Feb 2015 19:48:28 +0100
Subject: RFR (xs): JDK-8072611: (process) ProcessBuilder redirecting
	output to file should work with long file names (win)
In-Reply-To: <CAA-vtUyefCr13ET1FG=SraAxU9GmpERSuLAr3x73MK0Kj5H2mg@mail.gmail.com>
References: <CAA-vtUyefCr13ET1FG=SraAxU9GmpERSuLAr3x73MK0Kj5H2mg@mail.gmail.com>
Message-ID: <CA+3eh10bp0qEyqWPsa10_2hW3zHvicbpnzvQKzV6QbBje0ZemA@mail.gmail.com>

Hi Thomas,

the change looks good and I can sponsor it once it is reviewed.

Just some small notes:

- it seems that "getPath()" isn't used anywhere else in
ProcessImpl_md.c and because it is static it can't be used anywhere
else. So can you please remove it completely.

- io_util_md.h has a list of files which use the prototypes like
"pathToNTPath" before the declaration of the prototypes. Could you
please also add ProcessImpl_md.c to this list

- can you pleae place the new include in ProcessImpl_md.c as follows:

 #include "io_util.h"
+#include "io_util_md.h"
 #include <windows.h>
 #include <io.h>

I saw that system and local headers are already intermixed in that
file but at I think at least we shouldn't introduce more disorder.

- is "robocopy" really available on all supported Windows system. In
http://en.wikipedia.org/wiki/Robocopy I read that it was introduced in
Server 2008. I just verified that Java 8 only supports Server 2008 and
above but just think of our internal test system:) Maybe we can use a
program which is supported in every Windows version?

Regards,
Volker


On Mon, Feb 9, 2015 at 2:30 PM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> Hi all,
>
> please review this small change at your convenience:
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8072611/webrev.01/webrev/
>
> It fixes a small issue which causes ProcessBuilder not to be able to open
> files to redirect into (when using Redirect.append) on windows, if that
> file name is longer than 255 chars.
>
> Kind Regards, Thomas Stuefe


From Roger.Riggs at Oracle.com  Mon Feb  9 23:25:05 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 09 Feb 2015 18:25:05 -0500
Subject: JEP 102 Process Updates revised API draft
Message-ID: <54D941D1.8000305@Oracle.com>

Hi,

After a protracted absence from working on JEP 102, the updated API draft
provides access to process hierarchies and individual process information;
as permitted by the OS. The relationship between Process and ProcessHandle
is clarified and the security model validated.

Both Processes and ProcessHandles can be monitored using CompletableFuture
for termination and to trigger additional actions on Process exit.
Information about processes includes the total cputime, starttime, user,
executable, and arguments.

Please review and comment:
    http://cr.openjdk.java.net/~rriggs/ph-apidraft/

Thanks, Roger






From joe.darcy at oracle.com  Mon Feb  9 23:27:52 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 09 Feb 2015 15:27:52 -0800
Subject: JDK 9 RFR of JDK-8041395: Doclint regression in java.net.SocketOption
Message-ID: <54D94278.2040003@oracle.com>

Hello,

Please review these straightforward changes to address some doclint 
issues in java.net:

     JDK-8041395: Doclint regression in java.net.SocketOption
     http://cr.openjdk.java.net/~darcy/8041395.0/

Patch below.

Thanks,

-Joe

--- old/src/java.base/share/classes/java/net/DatagramSocket.java 
2015-02-09 15:19:25.407396706 -0800
+++ new/src/java.base/share/classes/java/net/DatagramSocket.java 
2015-02-09 15:19:25.223399019 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1995, 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
@@ -1308,6 +1308,7 @@
      /**
       * Sets the value of a socket option.
       *
+     * @param <T> The type of the socket option value
       * @param name The socket option
       * @param value The value of the socket option. A value of {@code 
null}
       *              may be valid for some options.
@@ -1342,6 +1343,7 @@
      /**
       * Returns the value of a socket option.
       *
+     * @param <T> The type of the socket option value
       * @param name The socket option
       *
       * @return The value of the socket option.
--- old/src/java.base/share/classes/java/net/DatagramSocketImpl.java 
2015-02-09 15:19:25.855391074 -0800
+++ new/src/java.base/share/classes/java/net/DatagramSocketImpl.java 
2015-02-09 15:19:25.695393086 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2013, 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
@@ -267,6 +267,7 @@
      /**
       * Called to set a socket option.
       *
+     * @param <T> The type of the socket option value
       * @param name The socket option
       *
       * @param value The value of the socket option. A value of {@code 
null}
@@ -276,7 +277,7 @@
       *         support the option
       *
       * @throws NullPointerException if name is {@code null}
-     *
+     * @throws IOException if an I/O problem occurs while attempting to 
set the option
       * @since 1.9
       */
      protected <T> void setOption(SocketOption<T> name, T value) throws 
IOException {
@@ -308,12 +309,15 @@
      /**
       * Called to get a socket option.
       *
+     * @return the socket option
+     * @param <T> The type of the socket option value
       * @param name The socket option
       *
       * @throws UnsupportedOperationException if the DatagramSocketImpl 
does not
       *         support the option
       *
       * @throws NullPointerException if name is {@code null}
+     * @throws IOException if an I/O problem occurs while attempting to 
set the option
       *
       * @since 1.9
       */
--- old/src/java.base/share/classes/java/net/ServerSocket.java 
2015-02-09 15:19:26.303385442 -0800
+++ new/src/java.base/share/classes/java/net/ServerSocket.java 
2015-02-09 15:19:26.131387604 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1995, 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
@@ -924,6 +924,7 @@
      /**
       * Sets the value of a socket option.
       *
+     * @param <T> The type of the socket option value
       * @param name The socket option
       * @param value The value of the socket option. A value of {@code 
null}
       *              may be valid for some options.
@@ -957,6 +958,7 @@
      /**
       * Returns the value of a socket option.
       *
+     * @param <T> The type of the socket option value
       * @param name The socket option
       *
       * @return The value of the socket option.
--- old/src/java.base/share/classes/java/net/Socket.java 2015-02-09 
15:19:26.739379961 -0800
+++ new/src/java.base/share/classes/java/net/Socket.java 2015-02-09 
15:19:26.579381972 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1995, 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
@@ -1727,6 +1727,7 @@
      /**
       * Sets the value of a socket option.
       *
+     * @param <T> The type of the socket option value
       * @param name The socket option
       * @param value The value of the socket option. A value of {@code 
null}
       *              may be valid for some options.
@@ -1758,6 +1759,7 @@
      /**
       * Returns the value of a socket option.
       *
+     * @param <T> The type of the socket option value
       * @param name The socket option
       *
       * @return The value of the socket option.
--- old/src/java.base/share/classes/java/net/SocketImpl.java 2015-02-09 
15:19:27.191374279 -0800
+++ new/src/java.base/share/classes/java/net/SocketImpl.java 2015-02-09 
15:19:27.031376290 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1995, 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
@@ -362,6 +362,7 @@
      /**
       * Called to set a socket option.
       *
+     * @param <T> The type of the socket option value
       * @param name The socket option
       *
       * @param value The value of the socket option. A value of {@code 
null}
@@ -397,6 +398,7 @@
      /**
       * Called to get a socket option.
       *
+     * @param <T> The type of the socket option value
       * @param name The socket option
       *
       * @return the value of the named option



From lance.andersen at oracle.com  Mon Feb  9 23:30:07 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 9 Feb 2015 18:30:07 -0500
Subject: JDK 9 RFR of JDK-8041395: Doclint regression in
	java.net.SocketOption
In-Reply-To: <54D94278.2040003@oracle.com>
References: <54D94278.2040003@oracle.com>
Message-ID: <08DEE984-ADCD-43E7-B2C7-5EC306DA4FD2@oracle.com>

looks fine joe

best
lance
On Feb 9, 2015, at 6:27 PM, joe darcy <joe.darcy at oracle.com> wrote:

> Hello,
> 
> Please review these straightforward changes to address some doclint issues in java.net:
> 
>    JDK-8041395: Doclint regression in java.net.SocketOption
>    http://cr.openjdk.java.net/~darcy/8041395.0/
> 
> Patch below.
> 
> Thanks,
> 
> -Joe
> 
> --- old/src/java.base/share/classes/java/net/DatagramSocket.java 2015-02-09 15:19:25.407396706 -0800
> +++ new/src/java.base/share/classes/java/net/DatagramSocket.java 2015-02-09 15:19:25.223399019 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1995, 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
> @@ -1308,6 +1308,7 @@
>     /**
>      * Sets the value of a socket option.
>      *
> +     * @param <T> The type of the socket option value
>      * @param name The socket option
>      * @param value The value of the socket option. A value of {@code null}
>      *              may be valid for some options.
> @@ -1342,6 +1343,7 @@
>     /**
>      * Returns the value of a socket option.
>      *
> +     * @param <T> The type of the socket option value
>      * @param name The socket option
>      *
>      * @return The value of the socket option.
> --- old/src/java.base/share/classes/java/net/DatagramSocketImpl.java 2015-02-09 15:19:25.855391074 -0800
> +++ new/src/java.base/share/classes/java/net/DatagramSocketImpl.java 2015-02-09 15:19:25.695393086 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1996, 2013, 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
> @@ -267,6 +267,7 @@
>     /**
>      * Called to set a socket option.
>      *
> +     * @param <T> The type of the socket option value
>      * @param name The socket option
>      *
>      * @param value The value of the socket option. A value of {@code null}
> @@ -276,7 +277,7 @@
>      *         support the option
>      *
>      * @throws NullPointerException if name is {@code null}
> -     *
> +     * @throws IOException if an I/O problem occurs while attempting to set the option
>      * @since 1.9
>      */
>     protected <T> void setOption(SocketOption<T> name, T value) throws IOException {
> @@ -308,12 +309,15 @@
>     /**
>      * Called to get a socket option.
>      *
> +     * @return the socket option
> +     * @param <T> The type of the socket option value
>      * @param name The socket option
>      *
>      * @throws UnsupportedOperationException if the DatagramSocketImpl does not
>      *         support the option
>      *
>      * @throws NullPointerException if name is {@code null}
> +     * @throws IOException if an I/O problem occurs while attempting to set the option
>      *
>      * @since 1.9
>      */
> --- old/src/java.base/share/classes/java/net/ServerSocket.java 2015-02-09 15:19:26.303385442 -0800
> +++ new/src/java.base/share/classes/java/net/ServerSocket.java 2015-02-09 15:19:26.131387604 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1995, 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
> @@ -924,6 +924,7 @@
>     /**
>      * Sets the value of a socket option.
>      *
> +     * @param <T> The type of the socket option value
>      * @param name The socket option
>      * @param value The value of the socket option. A value of {@code null}
>      *              may be valid for some options.
> @@ -957,6 +958,7 @@
>     /**
>      * Returns the value of a socket option.
>      *
> +     * @param <T> The type of the socket option value
>      * @param name The socket option
>      *
>      * @return The value of the socket option.
> --- old/src/java.base/share/classes/java/net/Socket.java 2015-02-09 15:19:26.739379961 -0800
> +++ new/src/java.base/share/classes/java/net/Socket.java 2015-02-09 15:19:26.579381972 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1995, 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
> @@ -1727,6 +1727,7 @@
>     /**
>      * Sets the value of a socket option.
>      *
> +     * @param <T> The type of the socket option value
>      * @param name The socket option
>      * @param value The value of the socket option. A value of {@code null}
>      *              may be valid for some options.
> @@ -1758,6 +1759,7 @@
>     /**
>      * Returns the value of a socket option.
>      *
> +     * @param <T> The type of the socket option value
>      * @param name The socket option
>      *
>      * @return The value of the socket option.
> --- old/src/java.base/share/classes/java/net/SocketImpl.java 2015-02-09 15:19:27.191374279 -0800
> +++ new/src/java.base/share/classes/java/net/SocketImpl.java 2015-02-09 15:19:27.031376290 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1995, 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
> @@ -362,6 +362,7 @@
>     /**
>      * Called to set a socket option.
>      *
> +     * @param <T> The type of the socket option value
>      * @param name The socket option
>      *
>      * @param value The value of the socket option. A value of {@code null}
> @@ -397,6 +398,7 @@
>     /**
>      * Called to get a socket option.
>      *
> +     * @param <T> The type of the socket option value
>      * @param name The socket option
>      *
>      * @return the value of the named option
> 



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.lloyd at redhat.com  Mon Feb  9 23:44:37 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 09 Feb 2015 17:44:37 -0600
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54D941D1.8000305@Oracle.com>
References: <54D941D1.8000305@Oracle.com>
Message-ID: <54D94665.8020906@redhat.com>

On 02/09/2015 05:25 PM, Roger Riggs wrote:
> Hi,
>
> After a protracted absence from working on JEP 102, the updated API draft
> provides access to process hierarchies and individual process information;
> as permitted by the OS. The relationship between Process and ProcessHandle
> is clarified and the security model validated.
>
> Both Processes and ProcessHandles can be monitored using CompletableFuture
> for termination and to trigger additional actions on Process exit.
> Information about processes includes the total cputime, starttime, user,
> executable, and arguments.
>
> Please review and comment:
>     http://cr.openjdk.java.net/~rriggs/ph-apidraft/

Great, I'm glad to see this come to fruition.  I have a couple minor 
questions though.

ProcessHandle.Info provides a startTime and totalTime.  But it seems odd 
and inconsistent that startTime is an Instant, yet totalTime is a raw 
long as opposed to the arguably more consistent Duration.  Is there a 
reason you went with a raw long for this property?

Also, as a general comment, there isn't really a good explanation as to 
what the difference is between a normal destroy and a forcible destroy. 
  Given that you've added an isDestroyForcible() method, I think it 
might be a good idea to explain what it means when this method returns 
true.  There must be some criteria in the implementation to return true 
here, so at the least, that criteria should be explained.  Also the 
destroy() method now has the odd characteristic that its implementation 
*may* forcibly destroy a process, but you can't really determine that 
from the API at all.

-- 
- DML


From amy.lu at oracle.com  Tue Feb 10 01:20:24 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 10 Feb 2015 09:20:24 +0800
Subject: JDK 9 RFR of JDK-8069255: Suppress deprecation warnings in
	jdk.rmic module
In-Reply-To: <54C9A44F.6030603@oracle.com>
References: <54BCA4A5.30202@oracle.com> <54C9A44F.6030603@oracle.com>
Message-ID: <54D95CD8.6080500@oracle.com>

Kindly reminder ...

On 1/29/15 11:09 AM, Amy Lu wrote:
> I updated the webrev, suppress deprecation warnings for 
> jdk/src/jdk.rmic/share/classes/sun/tools/java/* now also covered.
>
> Please review: http://cr.openjdk.java.net/~amlu/8069255/webrev.01/
>
> Thanks,
> Amy
>
> On 1/19/15 2:31 PM, Amy Lu wrote:
>> Please review these changes to address a few stray deprecation 
>> warnings in the jdk.rmic module:
>>
>> JDK-8069255: Suppress deprecation warnings in jdk.rmic module
>> http://cr.openjdk.java.net/~amlu/8069255/webrev.00/
>>
>> I also need a sponsor for this.
>>
>> Thanks,
>> Amy
>>
>



From Roger.Riggs at Oracle.com  Tue Feb 10 01:52:06 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 09 Feb 2015 20:52:06 -0500
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54D94665.8020906@redhat.com>
References: <54D941D1.8000305@Oracle.com> <54D94665.8020906@redhat.com>
Message-ID: <54D96446.4080305@Oracle.com>

Hi David,

On 2/9/15 6:44 PM, David M. Lloyd wrote:
> On 02/09/2015 05:25 PM, Roger Riggs wrote:
>> Hi,
>>
>> After a protracted absence from working on JEP 102, the updated API 
>> draft
>> provides access to process hierarchies and individual process 
>> information;
>> as permitted by the OS. The relationship between Process and 
>> ProcessHandle
>> is clarified and the security model validated.
>>
>> Both Processes and ProcessHandles can be monitored using 
>> CompletableFuture
>> for termination and to trigger additional actions on Process exit.
>> Information about processes includes the total cputime, starttime, user,
>> executable, and arguments.
>>
>> Please review and comment:
>>     http://cr.openjdk.java.net/~rriggs/ph-apidraft/
>
> Great, I'm glad to see this come to fruition.  I have a couple minor 
> questions though.
>
> ProcessHandle.Info provides a startTime and totalTime.  But it seems 
> odd and inconsistent that startTime is an Instant, yet totalTime is a 
> raw long as opposed to the arguably more consistent Duration.  Is 
> there a reason you went with a raw long for this property?
I considered a Duration, but Duration is a relative time; it make senses 
to add it to an absolute
time to come up with another absolute time.
But it didn't seem completely correct since CPU time is not accumulated 
continuously.
For ease in formatting, Duration.ofNanos(nn) can be used.
I'm open to suggestions.
>
> Also, as a general comment, there isn't really a good explanation as 
> to what the difference is between a normal destroy and a forcible 
> destroy.  Given that you've added an isDestroyForcible() method, I 
> think it might be a good idea to explain what it means when this 
> method returns true.  There must be some criteria in the 
> implementation to return true here, so at the least, that criteria 
> should be explained.  Also the destroy() method now has the odd 
> characteristic that its implementation *may* forcibly destroy a 
> process, but you can't really determine that from the API at all.
 From an implementation perspective, for Unix it is the distinction 
between SIGTERM and SIGKILL;
one is allowed/expected to be caught and handled by the application for 
a clean shutdown,
the other is not interceptable.
But the OS variations and caveats make it hard to write anything more 
than an informative statement.
The descriptions are copied from Process, which previously did not offer 
an explanation.

Thanks, Roger





From Roger.Riggs at Oracle.com  Tue Feb 10 01:55:15 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 09 Feb 2015 20:55:15 -0500
Subject: JDK 9 RFR of JDK-8069255: Suppress deprecation warnings in
	jdk.rmic module
In-Reply-To: <54D95CD8.6080500@oracle.com>
References: <54BCA4A5.30202@oracle.com> <54C9A44F.6030603@oracle.com>
	<54D95CD8.6080500@oracle.com>
Message-ID: <54D96503.5070009@Oracle.com>

Hi Amy,

Looks fine to me; If no one already volunteered to sponsor, I can.

Roger

On 2/9/15 8:20 PM, Amy Lu wrote:
> Kindly reminder ...
>
> On 1/29/15 11:09 AM, Amy Lu wrote:
>> I updated the webrev, suppress deprecation warnings for 
>> jdk/src/jdk.rmic/share/classes/sun/tools/java/* now also covered.
>>
>> Please review: http://cr.openjdk.java.net/~amlu/8069255/webrev.01/
>>
>> Thanks,
>> Amy
>>
>> On 1/19/15 2:31 PM, Amy Lu wrote:
>>> Please review these changes to address a few stray deprecation 
>>> warnings in the jdk.rmic module:
>>>
>>> JDK-8069255: Suppress deprecation warnings in jdk.rmic module
>>> http://cr.openjdk.java.net/~amlu/8069255/webrev.00/
>>>
>>> I also need a sponsor for this.
>>>
>>> Thanks,
>>> Amy
>>>
>>
>



From amy.lu at oracle.com  Tue Feb 10 01:57:38 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 10 Feb 2015 09:57:38 +0800
Subject: JDK 9 RFR of JDK-8069255: Suppress deprecation warnings in
	jdk.rmic module
In-Reply-To: <54D96503.5070009@Oracle.com>
References: <54BCA4A5.30202@oracle.com>
	<54C9A44F.6030603@oracle.com>	<54D95CD8.6080500@oracle.com>
	<54D96503.5070009@Oracle.com>
Message-ID: <54D96592.2040205@oracle.com>

Thank you Roger!

Yes, please sponsor this.

Thanks,
Amy

On 2/10/15 9:55 AM, Roger Riggs wrote:
> Hi Amy,
>
> Looks fine to me; If no one already volunteered to sponsor, I can.
>
> Roger
>
> On 2/9/15 8:20 PM, Amy Lu wrote:
>> Kindly reminder ...
>>
>> On 1/29/15 11:09 AM, Amy Lu wrote:
>>> I updated the webrev, suppress deprecation warnings for 
>>> jdk/src/jdk.rmic/share/classes/sun/tools/java/* now also covered.
>>>
>>> Please review: http://cr.openjdk.java.net/~amlu/8069255/webrev.01/
>>>
>>> Thanks,
>>> Amy
>>>
>>> On 1/19/15 2:31 PM, Amy Lu wrote:
>>>> Please review these changes to address a few stray deprecation 
>>>> warnings in the jdk.rmic module:
>>>>
>>>> JDK-8069255: Suppress deprecation warnings in jdk.rmic module
>>>> http://cr.openjdk.java.net/~amlu/8069255/webrev.00/
>>>>
>>>> I also need a sponsor for this.
>>>>
>>>> Thanks,
>>>> Amy
>>>>
>>>
>>
>



From sundararajan.athijegannathan at oracle.com  Tue Feb 10 07:21:36 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Tue, 10 Feb 2015 12:51:36 +0530
Subject: RFR 8068587: ScriptEngineFactory.getParameter() should specify NPE
	for a null key
Message-ID: <54D9B180.8020003@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8068587/ for 
https://bugs.openjdk.java.net/browse/JDK-8068587

Thanks,
-Sundar


From scolebourne at joda.org  Tue Feb 10 07:38:29 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 10 Feb 2015 07:38:29 +0000
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54D94665.8020906@redhat.com>
References: <54D941D1.8000305@Oracle.com> <54D94665.8020906@redhat.com>
Message-ID: <CACzrW9B=KFAvOXE0+KzVPsXz-G=Kg=LtXES+acqNQuVJq=QPdg@mail.gmail.com>

On 9 February 2015 at 23:44, David M. Lloyd <david.lloyd at redhat.com> wrote:
> ProcessHandle.Info provides a startTime and totalTime.  But it seems odd and
> inconsistent that startTime is an Instant, yet totalTime is a raw long as
> opposed to the arguably more consistent Duration.  Is there a reason you
> went with a raw long for this property?

I think using Duration would be OK here, even though the CPU time was
used up in a discontinuous manner. The returned value is, in essence,
a sum of many smaller durations.

I'd also suggest adjusting the two method names:
startTime() -> startInstant()
totalTime() -> totalCpuDuration()

Those communicate the intent more clearly IMO.

Stephen


From Alan.Bateman at oracle.com  Tue Feb 10 08:03:35 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Feb 2015 08:03:35 +0000
Subject: RFR 8068587: ScriptEngineFactory.getParameter() should specify
	NPE for a null key
In-Reply-To: <54D9B180.8020003@oracle.com>
References: <54D9B180.8020003@oracle.com>
Message-ID: <54D9BB57.4030909@oracle.com>

On 10/02/2015 07:21, A. Sundararajan wrote:
> Please review http://cr.openjdk.java.net/~sundar/8068587/ for 
> https://bugs.openjdk.java.net/browse/JDK-8068587
This looks okay to me although it makes me wonder if JSR-223 will need 
to be updated.

-Alan.


From marcus.lagergren at oracle.com  Tue Feb 10 09:05:50 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Tue, 10 Feb 2015 10:05:50 +0100
Subject: RFR 8068587: ScriptEngineFactory.getParameter() should specify
	NPE for a null key
In-Reply-To: <54D9B180.8020003@oracle.com>
References: <54D9B180.8020003@oracle.com>
Message-ID: <39E34190-0710-4016-8E88-A9F4A6F1580E@oracle.com>

Looks OK to me. +1

/M

> On 10 Feb 2015, at 08:21, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8068587/ for https://bugs.openjdk.java.net/browse/JDK-8068587
> 
> Thanks,
> -Sundar



From Alan.Bateman at oracle.com  Tue Feb 10 09:14:27 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Feb 2015 09:14:27 +0000
Subject: RFR: JDK-8068682 - Deprivilege/move java.corba to the ext class
	loader
In-Reply-To: <54D55ABC.6090306@oracle.com>
References: <54D50E20.8020406@oracle.com> <54D53065.2080603@oracle.com>
	<54D55ABC.6090306@oracle.com>
Message-ID: <54D9CBF3.60005@oracle.com>

On 07/02/2015 00:22, Mark Sheppard wrote:
> Hi Alan,
>    I had meant to remove the commented lines prior to generating the 
> patch
>
Okay, so ignoring that part then the rest looks good to me. Hopefully we 
have enough tests in this area that run with a security manager to help 
find any issues.

-Alan


From staffan.larsen at oracle.com  Tue Feb 10 09:53:45 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 10 Feb 2015 10:53:45 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54D941D1.8000305@Oracle.com>
References: <54D941D1.8000305@Oracle.com>
Message-ID: <E888BD18-661D-40D0-B567-3056E0382F43@oracle.com>

Happy to see this!

In ProcessHandle.Info would it be possible to include the environment variables of the process as well?

How does ProcessHandle.allChildren() behave when process A launches B which launches C, and B terminates? Is C included in allChildren() of A?

Thanks,
/Staffan

> On 10 feb 2015, at 00:25, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
> 
> Hi,
> 
> After a protracted absence from working on JEP 102, the updated API draft
> provides access to process hierarchies and individual process information;
> as permitted by the OS. The relationship between Process and ProcessHandle
> is clarified and the security model validated.
> 
> Both Processes and ProcessHandles can be monitored using CompletableFuture
> for termination and to trigger additional actions on Process exit.
> Information about processes includes the total cputime, starttime, user,
> executable, and arguments.
> 
> Please review and comment:
>   http://cr.openjdk.java.net/~rriggs/ph-apidraft/
> 
> Thanks, Roger
> 
> 
> 
> 



From thomas.stuefe at gmail.com  Tue Feb 10 09:58:50 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 10 Feb 2015 10:58:50 +0100
Subject: RFR (xs): JDK-8072611: (process) ProcessBuilder redirecting
	output to file should work with long file names (win)
In-Reply-To: <CA+3eh10bp0qEyqWPsa10_2hW3zHvicbpnzvQKzV6QbBje0ZemA@mail.gmail.com>
References: <CAA-vtUyefCr13ET1FG=SraAxU9GmpERSuLAr3x73MK0Kj5H2mg@mail.gmail.com>
	<CA+3eh10bp0qEyqWPsa10_2hW3zHvicbpnzvQKzV6QbBje0ZemA@mail.gmail.com>
Message-ID: <CAA-vtUzWfQQ4KQphZEHgQKDS3zS9Vd=3b=JPJj6xZNMtWVP0xA@mail.gmail.com>

Hi Roger, Volker,

thanks for reviewing!

I added all requested changes:

@Roger
- use now Files.createTempDirectory to get a unique directory
- wrapped test in try/finally to cleanup afterwards
@Volker
- moved include up and added dependency to comment in io_util_md.h
- Now I use hostname.exe, which I hope is part of every Windows :)

http://cr.openjdk.java.net/~stuefe/webrevs/8072611/webrev.02/webrev/

Regards, Thomas

On Mon, Feb 9, 2015 at 7:48 PM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> Hi Thomas,
>
> the change looks good and I can sponsor it once it is reviewed.
>
> Just some small notes:
>
> - it seems that "getPath()" isn't used anywhere else in
> ProcessImpl_md.c and because it is static it can't be used anywhere
> else. So can you please remove it completely.
>
> - io_util_md.h has a list of files which use the prototypes like
> "pathToNTPath" before the declaration of the prototypes. Could you
> please also add ProcessImpl_md.c to this list
>
> - can you pleae place the new include in ProcessImpl_md.c as follows:
>
>  #include "io_util.h"
> +#include "io_util_md.h"
>  #include <windows.h>
>  #include <io.h>
>
> I saw that system and local headers are already intermixed in that
> file but at I think at least we shouldn't introduce more disorder.
>
> - is "robocopy" really available on all supported Windows system. In
> http://en.wikipedia.org/wiki/Robocopy I read that it was introduced in
> Server 2008. I just verified that Java 8 only supports Server 2008 and
> above but just think of our internal test system:) Maybe we can use a
> program which is supported in every Windows version?
>
> Regards,
> Volker
>
>
> On Mon, Feb 9, 2015 at 2:30 PM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
> > Hi all,
> >
> > please review this small change at your convenience:
> >
> > http://cr.openjdk.java.net/~stuefe/webrevs/8072611/webrev.01/webrev/
> >
> > It fixes a small issue which causes ProcessBuilder not to be able to open
> > files to redirect into (when using Redirect.append) on windows, if that
> > file name is longer than 255 chars.
> >
> > Kind Regards, Thomas Stuefe
>


From paul.sandoz at oracle.com  Tue Feb 10 09:59:47 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 10 Feb 2015 10:59:47 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54D941D1.8000305@Oracle.com>
References: <54D941D1.8000305@Oracle.com>
Message-ID: <E68EE22D-A7F8-4094-ABCB-571DA06EA260@oracle.com>


On Feb 10, 2015, at 12:25 AM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:

> Hi,
> 
> After a protracted absence from working on JEP 102, the updated API draft
> provides access to process hierarchies and individual process information;
> as permitted by the OS. The relationship between Process and ProcessHandle
> is clarified and the security model validated.
> 
> Both Processes and ProcessHandles can be monitored using CompletableFuture
> for termination and to trigger additional actions on Process exit.
> Information about processes includes the total cputime, starttime, user,
> executable, and arguments.
> 
> Please review and comment:
>   http://cr.openjdk.java.net/~rriggs/ph-apidraft/
> 

Since i have your source it's easier in some cases if i copy/paste with line numbers:
  57  * <p>
  58  * A {@link java.util.concurrent.CompletableFuture} available from {@link #completableFuture}
  59  * can be used to wait for process termination and execute a task.
  60  * The threads used to monitor the process and execute the task are pooled
  61  * using a {@link java.util.concurrent.Executors#newCachedThreadPool}.
Is that too much impl detail mentioning the use of the cached thread pool? If so seems more of an implementation note than specification.

Paul.


From paul.sandoz at oracle.com  Tue Feb 10 10:49:39 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 10 Feb 2015 11:49:39 +0100
Subject: Unsafe.park/unpark, j.u.c.LockSupport and Thread
Message-ID: <0EF3EAFA-01DF-4577-AD4F-801AD989F639@oracle.com>

Hi,

As part of the effort around Unsafe (some may have noticed some cleanup work) i have been recently looking at the park/unpark methods.

The class java.util.concurrent.locks.LockSupport [1] has some thin public wrappers around these methods:

    public static void unpark(Thread thread) {
        if (thread != null)
            U.unpark(thread);
    }

    public static void park() {
        U.park(false, 0L);
    }

    public static void parkNanos(long nanos) {
        if (nanos > 0)
            U.park(false, nanos);
    }

    public static void parkUntil(long deadline) {
        U.park(true, deadline);
    }

Is not clear to me what is exactly unsafe about park/unpark and why they were not originally placed on Thread itself given the above wrapping.

There is mention of unpark being unsafe with regards to native code and ensuring the thread has not been destroyed: 

  /**
   * Unblock the given thread blocked on <tt>park</tt>, or, if it is
   * not blocked, cause the subsequent call to <tt>park</tt> not to
   * block.  Note: this operation is "unsafe" solely because the
   * caller must somehow ensure that the thread has not been
   * destroyed. Nothing special is usually required to ensure this
   * when called from Java (in which there will ordinarily be a live
   * reference to the thread) but this is not nearly-automatically
   * so when calling from native code.
   * @param thread the thread to unpark.
   *
   */
  public native void unpark(Object thread);

However, native code is anyway inherently unsafe.


In addition this class has a cosy relationship with Thread (it wants to poke into Thread's non-public fields):

    // Hotspot implementation via intrinsics API
    private static final sun.misc.Unsafe U = sun.misc.Unsafe.getUnsafe();
    private static final long PARKBLOCKER;
    private static final long SEED;
    private static final long PROBE;
    private static final long SECONDARY;
    static {
        try {
            PARKBLOCKER = U.objectFieldOffset
                (Thread.class.getDeclaredField("parkBlocker"));
            SEED = U.objectFieldOffset
                (Thread.class.getDeclaredField("threadLocalRandomSeed"));
            PROBE = U.objectFieldOffset
                (Thread.class.getDeclaredField("threadLocalRandomProbe"));
            SECONDARY = U.objectFieldOffset
                (Thread.class.getDeclaredField("threadLocalRandomSecondarySeed"));
        } catch (ReflectiveOperationException e) {
            throw new Error(e);
        }
    }

Although only PARKBLOCKER and SECONDARY are used AFAICT.

I am sure there is some history behind all this... but in my ignorance of the past perhaps it's time to reconsider?

We could reduce the coupling on Thread and dependency on Unsafe if we consider moving park/unpark and LockSupport functionality to Thread itself.

Thoughts?

Paul.

[1] http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/locks/LockSupport.java?view=co



From mark.sheppard at oracle.com  Tue Feb 10 11:20:53 2015
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Tue, 10 Feb 2015 11:20:53 +0000
Subject: RFR: JDK-8068682 - Deprivilege/move java.corba to the ext class
	loader
In-Reply-To: <54D9CBF3.60005@oracle.com>
References: <54D50E20.8020406@oracle.com> <54D53065.2080603@oracle.com>
	<54D55ABC.6090306@oracle.com> <54D9CBF3.60005@oracle.com>
Message-ID: <54D9E995.8040508@oracle.com>

thanks Alan

the updated corba part is at

http://cr.openjdk.java.net/~msheppar/8068682/corba/webrev.02/

regards
Mark

On 10/02/2015 09:14, Alan Bateman wrote:
> On 07/02/2015 00:22, Mark Sheppard wrote:
>> Hi Alan,
>>    I had meant to remove the commented lines prior to generating the 
>> patch
>>
> Okay, so ignoring that part then the rest looks good to me. Hopefully 
> we have enough tests in this area that run with a security manager to 
> help find any issues.
>
> -Alan



From peter.levart at gmail.com  Tue Feb 10 11:35:08 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 10 Feb 2015 12:35:08 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54D941D1.8000305@Oracle.com>
References: <54D941D1.8000305@Oracle.com>
Message-ID: <54D9ECEC.4050404@gmail.com>

On 02/10/2015 12:25 AM, Roger Riggs wrote:
> Hi,
>
> After a protracted absence from working on JEP 102, the updated API draft
> provides access to process hierarchies and individual process 
> information;
> as permitted by the OS. The relationship between Process and 
> ProcessHandle
> is clarified and the security model validated.
>
> Both Processes and ProcessHandles can be monitored using 
> CompletableFuture
> for termination and to trigger additional actions on Process exit.
> Information about processes includes the total cputime, starttime, user,
> executable, and arguments.
>
> Please review and comment:
>    http://cr.openjdk.java.net/~rriggs/ph-apidraft/
>
> Thanks, Roger
>
>
>
>
Hi Roger,

Great to see progress on this.

Here are my comments:

ProcessHandle.{allProcesses,allChildren,children} return 
Stream<ProcessHandle>. This is convenient if one wants to use Stream 
API, but a little more inconvenient and perhaps with additional overhead 
if one doesn't. Since all those methods return a "snapshot", I can 
imagine that internally, there is a collection built from this snapshot. 
So it would be most appropriate to return a List<ProcessHandle>. One can 
always continue the expression by appending .stream()..., but on the 
other hand if one wants to .collect(toList()), additional copying is 
introduced.

ProcessHandle.completableFuture().cancel(true) forcibly destorys 
(destroyForcibly()) the process *and* vice versa: destory[Forcibly]() 
cancels the CompletableFuture. I don't know if this is the best way - 
can't decide yet. In particular, in the implementation it would be hard 
to achieve the atommicity of both destroying the process and canceling 
the future. Races are inevitable. So it would be better to think of a 
process (and a ProcessHandle representing it) as the 1st stage in the 
processing pipeline, where ProcessHandle.completableFuture() is it's 
dependent stage which tracks real changes of the process. Which means 
the behaviour would be something like the following:

- ProcessHandle.destroy[Forcibly]() triggers destruction of the process 
which in turn (when successful) triggers completion of 
CompletableFuture, exceptionally with CompletionException, wrapping the 
exception indicating the destruction of the process 
(ProcessDestroyedException?).

- ProcessHandle.completableFuture().cancel(true/false) just cancels the 
CompletableFuture and does not do anything to the process itself.

In that variant, then perhaps it would be more appropriate for 
ProcessHandle.completableFuture() to be a "factory" for 
CompletableFuture(s) so that each call would return new independent 
instance.

What do you think?

Regards, Peter



From Alan.Bateman at oracle.com  Tue Feb 10 11:35:13 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Feb 2015 11:35:13 +0000
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54D8CAD7.50303@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CD3043.2070709@gmail.com>	<54CD4A14.2080205@oracle.com>	<54CD6984.2040004@gmail.com>	<54CDF84E.7070905@oracle.com>	<54CE03D2.8000706@gmail.com>	<54CF386A.9000600@oracle.com>	<2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>	<54CF5EF3.20102@oracle.com>
	<54CFE38D.30400@oracle.com> <54D2249E.105@oracle.com>
	<54D22CC6.9040405@gmail.com> <54D23041.1020703@oracle.com>
	<54D236AA.4050406@oracle.com> <54D4957F.7070805@oracle.com>
	<54D8CAD7.50303@oracle.com>
Message-ID: <54D9ECF1.9090203@oracle.com>

On 09/02/2015 14:57, Chris Hegarty wrote:
> :
>
> Updated webrev [ spec and implementation] :
>   http://cr.openjdk.java.net/~chegar/8064924/04/
>
The updated javadoc looks good. I haven't had a chance yet to look at 
the implementation but I think you will need to update 
<top>/make/common/CORE_PKGS.gmk for the spi package.

-Alan.


From Alan.Bateman at oracle.com  Tue Feb 10 11:37:48 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Feb 2015 11:37:48 +0000
Subject: RFR: JDK-8068682 - Deprivilege/move java.corba to the ext class
	loader
In-Reply-To: <54D9E995.8040508@oracle.com>
References: <54D50E20.8020406@oracle.com> <54D53065.2080603@oracle.com>
	<54D55ABC.6090306@oracle.com> <54D9CBF3.60005@oracle.com>
	<54D9E995.8040508@oracle.com>
Message-ID: <54D9ED8C.1080602@oracle.com>

On 10/02/2015 11:20, Mark Sheppard wrote:
> thanks Alan
>
> the updated corba part is at
>
> http://cr.openjdk.java.net/~msheppar/8068682/corba/webrev.02/
>
I assume ORB.java isn't meant to be in this webrev (the lib->conf issue 
is separate and I think will need an @implNote in additional to checking 
for orb.properties in both lib and conf).

-Alan.


From david.holmes at oracle.com  Tue Feb 10 12:02:43 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Feb 2015 22:02:43 +1000
Subject: Unsafe.park/unpark, j.u.c.LockSupport and Thread
In-Reply-To: <0EF3EAFA-01DF-4577-AD4F-801AD989F639@oracle.com>
References: <0EF3EAFA-01DF-4577-AD4F-801AD989F639@oracle.com>
Message-ID: <54D9F363.50003@oracle.com>

Hi Paul,

When we added j.u.c there was reluctance to add these methods to Thread 
- this was the normal policy (for the time) of don't touch the core 
classes. So LockSupport is the public API and Unsafe was chosen as the 
implementation as it is a de-facto interface to the VM from JDK code 
rather then defining explicit native methods (I must admit I'm unsure 
why we went this route rather than simply hooking into jvm.cpp with 
JVM_park/JVM_unpark. I think in many ways it was/is just easier to call 
an Unsafe method and define a new unsafe.cpp native call. Plus we had a 
bunch of other Unsafe API's being used from j.u.c.)

So we can't just move things from LockSupport to Thread as we'd need to 
deprecate first etc etc. But I don't see any reason why we couldn't move 
the implementation from unsafe.cpp to jvm.cpp and invoke via a native 
method implementation of LockSupport. It would still be just as "unsafe" 
of course.

Aside: this is where the infamous "spurious wakeup" from park() can 
arise. If you just randomly unpark() a Thread there is nothing to 
guarantee that the thread doesn't terminate and free its native 
resources while you are working on it. But the ParkEvents are 
type-stable-memory, so even if the event has been disassociated from the 
target thread you can still call unpark() as it is never freed. However 
if that ParkEvent has since been reused by another thread, then that 
thread will encounter a "spurious wakeup" if it calls park().

Cheers,
David

On 10/02/2015 8:49 PM, Paul Sandoz wrote:
> Hi,
>
> As part of the effort around Unsafe (some may have noticed some cleanup work) i have been recently looking at the park/unpark methods.
>
> The class java.util.concurrent.locks.LockSupport [1] has some thin public wrappers around these methods:
>
>      public static void unpark(Thread thread) {
>          if (thread != null)
>              U.unpark(thread);
>      }
>
>      public static void park() {
>          U.park(false, 0L);
>      }
>
>      public static void parkNanos(long nanos) {
>          if (nanos > 0)
>              U.park(false, nanos);
>      }
>
>      public static void parkUntil(long deadline) {
>          U.park(true, deadline);
>      }
>
> Is not clear to me what is exactly unsafe about park/unpark and why they were not originally placed on Thread itself given the above wrapping.
>
> There is mention of unpark being unsafe with regards to native code and ensuring the thread has not been destroyed:
>
>    /**
>     * Unblock the given thread blocked on <tt>park</tt>, or, if it is
>     * not blocked, cause the subsequent call to <tt>park</tt> not to
>     * block.  Note: this operation is "unsafe" solely because the
>     * caller must somehow ensure that the thread has not been
>     * destroyed. Nothing special is usually required to ensure this
>     * when called from Java (in which there will ordinarily be a live
>     * reference to the thread) but this is not nearly-automatically
>     * so when calling from native code.
>     * @param thread the thread to unpark.
>     *
>     */
>    public native void unpark(Object thread);
>
> However, native code is anyway inherently unsafe.
>
>
> In addition this class has a cosy relationship with Thread (it wants to poke into Thread's non-public fields):
>
>      // Hotspot implementation via intrinsics API
>      private static final sun.misc.Unsafe U = sun.misc.Unsafe.getUnsafe();
>      private static final long PARKBLOCKER;
>      private static final long SEED;
>      private static final long PROBE;
>      private static final long SECONDARY;
>      static {
>          try {
>              PARKBLOCKER = U.objectFieldOffset
>                  (Thread.class.getDeclaredField("parkBlocker"));
>              SEED = U.objectFieldOffset
>                  (Thread.class.getDeclaredField("threadLocalRandomSeed"));
>              PROBE = U.objectFieldOffset
>                  (Thread.class.getDeclaredField("threadLocalRandomProbe"));
>              SECONDARY = U.objectFieldOffset
>                  (Thread.class.getDeclaredField("threadLocalRandomSecondarySeed"));
>          } catch (ReflectiveOperationException e) {
>              throw new Error(e);
>          }
>      }
>
> Although only PARKBLOCKER and SECONDARY are used AFAICT.
>
> I am sure there is some history behind all this... but in my ignorance of the past perhaps it's time to reconsider?
>
> We could reduce the coupling on Thread and dependency on Unsafe if we consider moving park/unpark and LockSupport functionality to Thread itself.
>
> Thoughts?
>
> Paul.
>
> [1] http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/locks/LockSupport.java?view=co
>


From david.holmes at oracle.com  Tue Feb 10 12:04:11 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Feb 2015 22:04:11 +1000
Subject: Unsafe.park/unpark, j.u.c.LockSupport and Thread
In-Reply-To: <54D9F363.50003@oracle.com>
References: <0EF3EAFA-01DF-4577-AD4F-801AD989F639@oracle.com>
	<54D9F363.50003@oracle.com>
Message-ID: <54D9F3BB.2090403@oracle.com>

Oh I just realized/remembered why we use Unsafe for this - it is because 
of the potential for intrinsics.

David

On 10/02/2015 10:02 PM, David Holmes wrote:
> Hi Paul,
>
> When we added j.u.c there was reluctance to add these methods to Thread
> - this was the normal policy (for the time) of don't touch the core
> classes. So LockSupport is the public API and Unsafe was chosen as the
> implementation as it is a de-facto interface to the VM from JDK code
> rather then defining explicit native methods (I must admit I'm unsure
> why we went this route rather than simply hooking into jvm.cpp with
> JVM_park/JVM_unpark. I think in many ways it was/is just easier to call
> an Unsafe method and define a new unsafe.cpp native call. Plus we had a
> bunch of other Unsafe API's being used from j.u.c.)
>
> So we can't just move things from LockSupport to Thread as we'd need to
> deprecate first etc etc. But I don't see any reason why we couldn't move
> the implementation from unsafe.cpp to jvm.cpp and invoke via a native
> method implementation of LockSupport. It would still be just as "unsafe"
> of course.
>
> Aside: this is where the infamous "spurious wakeup" from park() can
> arise. If you just randomly unpark() a Thread there is nothing to
> guarantee that the thread doesn't terminate and free its native
> resources while you are working on it. But the ParkEvents are
> type-stable-memory, so even if the event has been disassociated from the
> target thread you can still call unpark() as it is never freed. However
> if that ParkEvent has since been reused by another thread, then that
> thread will encounter a "spurious wakeup" if it calls park().
>
> Cheers,
> David
>
> On 10/02/2015 8:49 PM, Paul Sandoz wrote:
>> Hi,
>>
>> As part of the effort around Unsafe (some may have noticed some
>> cleanup work) i have been recently looking at the park/unpark methods.
>>
>> The class java.util.concurrent.locks.LockSupport [1] has some thin
>> public wrappers around these methods:
>>
>>      public static void unpark(Thread thread) {
>>          if (thread != null)
>>              U.unpark(thread);
>>      }
>>
>>      public static void park() {
>>          U.park(false, 0L);
>>      }
>>
>>      public static void parkNanos(long nanos) {
>>          if (nanos > 0)
>>              U.park(false, nanos);
>>      }
>>
>>      public static void parkUntil(long deadline) {
>>          U.park(true, deadline);
>>      }
>>
>> Is not clear to me what is exactly unsafe about park/unpark and why
>> they were not originally placed on Thread itself given the above
>> wrapping.
>>
>> There is mention of unpark being unsafe with regards to native code
>> and ensuring the thread has not been destroyed:
>>
>>    /**
>>     * Unblock the given thread blocked on <tt>park</tt>, or, if it is
>>     * not blocked, cause the subsequent call to <tt>park</tt> not to
>>     * block.  Note: this operation is "unsafe" solely because the
>>     * caller must somehow ensure that the thread has not been
>>     * destroyed. Nothing special is usually required to ensure this
>>     * when called from Java (in which there will ordinarily be a live
>>     * reference to the thread) but this is not nearly-automatically
>>     * so when calling from native code.
>>     * @param thread the thread to unpark.
>>     *
>>     */
>>    public native void unpark(Object thread);
>>
>> However, native code is anyway inherently unsafe.
>>
>>
>> In addition this class has a cosy relationship with Thread (it wants
>> to poke into Thread's non-public fields):
>>
>>      // Hotspot implementation via intrinsics API
>>      private static final sun.misc.Unsafe U =
>> sun.misc.Unsafe.getUnsafe();
>>      private static final long PARKBLOCKER;
>>      private static final long SEED;
>>      private static final long PROBE;
>>      private static final long SECONDARY;
>>      static {
>>          try {
>>              PARKBLOCKER = U.objectFieldOffset
>>                  (Thread.class.getDeclaredField("parkBlocker"));
>>              SEED = U.objectFieldOffset
>>
>> (Thread.class.getDeclaredField("threadLocalRandomSeed"));
>>              PROBE = U.objectFieldOffset
>>
>> (Thread.class.getDeclaredField("threadLocalRandomProbe"));
>>              SECONDARY = U.objectFieldOffset
>>
>> (Thread.class.getDeclaredField("threadLocalRandomSecondarySeed"));
>>          } catch (ReflectiveOperationException e) {
>>              throw new Error(e);
>>          }
>>      }
>>
>> Although only PARKBLOCKER and SECONDARY are used AFAICT.
>>
>> I am sure there is some history behind all this... but in my ignorance
>> of the past perhaps it's time to reconsider?
>>
>> We could reduce the coupling on Thread and dependency on Unsafe if we
>> consider moving park/unpark and LockSupport functionality to Thread
>> itself.
>>
>> Thoughts?
>>
>> Paul.
>>
>> [1]
>> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/locks/LockSupport.java?view=co
>>
>>


From mark.sheppard at oracle.com  Tue Feb 10 12:11:49 2015
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Tue, 10 Feb 2015 12:11:49 +0000
Subject: RFR: JDK-8068682 - Deprivilege/move java.corba to the ext class
	loader
In-Reply-To: <54D9ED8C.1080602@oracle.com>
References: <54D50E20.8020406@oracle.com> <54D53065.2080603@oracle.com>
	<54D55ABC.6090306@oracle.com> <54D9CBF3.60005@oracle.com>
	<54D9E995.8040508@oracle.com> <54D9ED8C.1080602@oracle.com>
Message-ID: <54D9F585.9060605@oracle.com>

OK I'll remove it.

I thought that property files had been migrated from lib to conf, as per 
conf/security,  so I made the change

regards
Mark

On 10/02/2015 11:37, Alan Bateman wrote:
> On 10/02/2015 11:20, Mark Sheppard wrote:
>> thanks Alan
>>
>> the updated corba part is at
>>
>> http://cr.openjdk.java.net/~msheppar/8068682/corba/webrev.02/
>>
> I assume ORB.java isn't meant to be in this webrev (the lib->conf 
> issue is separate and I think will need an @implNote in additional to 
> checking for orb.properties in both lib and conf).
>
> -Alan.



From paul.sandoz at oracle.com  Tue Feb 10 12:46:05 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 10 Feb 2015 13:46:05 +0100
Subject: Unsafe.park/unpark, j.u.c.LockSupport and Thread
In-Reply-To: <54D9F363.50003@oracle.com>
References: <0EF3EAFA-01DF-4577-AD4F-801AD989F639@oracle.com>
	<54D9F363.50003@oracle.com>
Message-ID: <17D1013C-EFF5-4AAF-8237-833AF20C3A17@oracle.com>

Hi David,

On Feb 10, 2015, at 1:02 PM, David Holmes <david.holmes at oracle.com> wrote:

> Hi Paul,
> 
> When we added j.u.c there was reluctance to add these methods to Thread - this was the normal policy (for the time) of don't touch the core classes. So LockSupport is the public API and Unsafe was chosen as the implementation as it is a de-facto interface to the VM from JDK code rather then defining explicit native methods (I must admit I'm unsure why we went this route rather than simply hooking into jvm.cpp with JVM_park/JVM_unpark. I think in many ways it was/is just easier to call an Unsafe method and define a new unsafe.cpp native call. Plus we had a bunch of other Unsafe API's being used from j.u.c.)
> 
> So we can't just move things from LockSupport to Thread as we'd need to deprecate first etc etc.

I was thinking that the implementation of LockSupport could be updated to use any new stuff we could add to java.lang.{*, Thread}.

I am trying to tease apart the internal dependencies that 166 classes have on the platform. In the case of LockSupport there are two, Unsafe and Thread.

Adding native methods to 166 classes will introduce another form of dependency on the platform that i would prefer to avoid.


> But I don't see any reason why we couldn't move the implementation from unsafe.cpp to jvm.cpp and invoke via a native method implementation of LockSupport. It would still be just as "unsafe" of course.
> 

Can you think of any reasons, beyond that of "don't touch the core classes", why we cannot copy this functionality over to java.lang.{*, Thread} ?


> Aside: this is where the infamous "spurious wakeup" from park() can arise. If you just randomly unpark() a Thread there is nothing to guarantee that the thread doesn't terminate and free its native resources while you are working on it. But the ParkEvents are type-stable-memory, so even if the event has been disassociated from the target thread you can still call unpark() as it is never freed. However if that ParkEvent has since been reused by another thread, then that thread will encounter a "spurious wakeup" if it calls park().
> 

I see, and can the same happen for Object.wait as well? I gather so from the documentation.


On Feb 10, 2015, at 1:04 PM, David Holmes <david.holmes at oracle.com> wrote:
> Oh I just realized/remembered why we use Unsafe for this - it is because of the potential for intrinsics.

I can certainly imagine it's convenient place to put things in that regard.

Paul.



From peter.levart at gmail.com  Tue Feb 10 13:02:44 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 10 Feb 2015 14:02:44 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54D9ECEC.4050404@gmail.com>
References: <54D941D1.8000305@Oracle.com> <54D9ECEC.4050404@gmail.com>
Message-ID: <54DA0174.5010709@gmail.com>

On 02/10/2015 12:35 PM, Peter Levart wrote:
> ProcessHandle.completableFuture().cancel(true) forcibly destorys 
> (destroyForcibly()) the process *and* vice versa: destory[Forcibly]() 
> cancels the CompletableFuture. I don't know if this is the best way - 
> can't decide yet. In particular, in the implementation it would be 
> hard to achieve the atommicity of both destroying the process and 
> canceling the future. Races are inevitable. So it would be better to 
> think of a process (and a ProcessHandle representing it) as the 1st 
> stage in the processing pipeline, where 
> ProcessHandle.completableFuture() is it's dependent stage which tracks 
> real changes of the process. Which means the behaviour would be 
> something like the following:
>
> - ProcessHandle.destroy[Forcibly]() triggers destruction of the 
> process which in turn (when successful) triggers completion of 
> CompletableFuture, exceptionally with CompletionException, wrapping 
> the exception indicating the destruction of the process 
> (ProcessDestroyedException?).
>
> - ProcessHandle.completableFuture().cancel(true/false) just cancels 
> the CompletableFuture and does not do anything to the process itself.
>
> In that variant, then perhaps it would be more appropriate for 
> ProcessHandle.completableFuture() to be a "factory" for 
> CompletableFuture(s) so that each call would return new independent 
> instance.
>
> What do you think? 

Contemplating on this a little more, then perhaps the singleton-per pid 
CompletionStage could be OK if it was a "mirror" of real process state. 
For that purpose then, instead of .completableFuture() the method would be:

public CompletionStage<ProcessHandle> completionStage()

Returns a CompletionStage<ProcessHandle> for the process. The 
CompletionStage provides supporting dependent functions and actions that 
are run upon process completion.

Returns:
     a CompletionStage<ProcessHandle> for the ProcessHandle; the same 
instance is returned for each unique pid.


This would provide the most clean API I think, as CompletionStage does 
not have any cancel(), complete(), obtrudeXXX() or get() methods. One 
could still obtain a CompletableFuture by calling .toCompletableFuture() 
on the CompletionStage, but that future would be a 2nd stage future 
(like calling .thenApply(x -> x)) which would not propagate cancel(true) 
to the process destruction.

The implementation could still use CompletableFuture under the hood, but 
exposed wrapped in a delegating CompletionStage proxy.

So the javadoc might be written as:


public abstract void destroy()

Kills the process. Whether the process represented by this Process 
object is forcibly terminated or not is implementation dependent. If the 
process is not alive, no action is taken.

If/when the process dies as the result of calling destroy(), the 
completionStage() completes exceptionally with CompletionException, 
wrapping ProcessDestroyedException.


public abstract ProcessHandle destroyForcibly()

Kills the process. The process represented by this ProcessHandle object 
is forcibly terminated. If the process is not alive, no action is taken.

If/when the process dies as the result of calling destroyForcibly(), the 
completionStage() completes exceptionally with CompletionException, 
wrapping ProcessDestroyedException.


But I'm still unsure of whether it would be better for the 
completionStage() to complete normally in any case. Unless the fact that 
the process died as a result of killing it could be reliably 
communicated regardless of who was responsible for the killing (either 
via ProcessHandle.destoroy() or by a KILL/TERMINATE signal originating 
from outside the VM).

Peter



From david.lloyd at redhat.com  Tue Feb 10 13:17:08 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 10 Feb 2015 07:17:08 -0600
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54D96446.4080305@Oracle.com>
References: <54D941D1.8000305@Oracle.com> <54D94665.8020906@redhat.com>
	<54D96446.4080305@Oracle.com>
Message-ID: <54DA04D4.1060108@redhat.com>

On 02/09/2015 07:52 PM, Roger Riggs wrote:
> On 2/9/15 6:44 PM, David M. Lloyd wrote:
>> Also, as a general comment, there isn't really a good explanation as
>> to what the difference is between a normal destroy and a forcible
>> destroy.  Given that you've added an isDestroyForcible() method, I
>> think it might be a good idea to explain what it means when this
>> method returns true.  There must be some criteria in the
>> implementation to return true here, so at the least, that criteria
>> should be explained.  Also the destroy() method now has the odd
>> characteristic that its implementation *may* forcibly destroy a
>> process, but you can't really determine that from the API at all.
>
> From an implementation perspective, for Unix it is the distinction
> between SIGTERM and SIGKILL;one is allowed/expected to be caught and handled by the application for
> a clean shutdown,the other is not interceptable. But the OS variations and caveats make 
it hard to write anything more
> than an informative statement.

Understood, but I'm thinking that such a statement should be added; 
something along the lines of "Forcible process destruction is defined as 
the immediate termination of a process, whereas regular destruction 
allows a process to shut down cleanly."  This gives a clear criterion as 
to what it means when isDestroyForcible returns true, since each of 
these behaviors (at least on Unix) are readily identified with SIGKILL 
and SIGTERM.

Upon rereading the API I see that isDestroyForcible() actually reflects 
the behavior of destroy(), which is opposite of my original reading of 
it, and that clarifies things a bit.  But there is still no way in the 
API to know if forcible process termination is supported; can it be 
assumed that it is supported on all platforms?

> The descriptions are copied from Process, which previously did not offer
> an explanation.

-- 
- DML


From magnus.ihse.bursie at oracle.com  Tue Feb 10 14:23:41 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 10 Feb 2015 15:23:41 +0100
Subject: RFR: JDK-8072842 Add support for building native JTReg tests
Message-ID: <54DA146D.3060904@oracle.com>

Here is an addition to the build system, that will compile native 
libraries and executables and make them available for JTReg tests 
written in Java.

This patch is the result of the work (in serial, mostly) of Staffan 
Larsen, David Simms and me. (And possible more that I don't know about.)

In it current form, the patch only provides the framework on which to 
attach real tests. To prove the concept, some initial dummy tests are 
present. These are supposed to be removed as soon as real tests starts 
to propagate into the jdk and hotspot jtreg test suites.

The behavior is based on the following design: For directories with 
native jtreg compilation enabled, the build system searches for native 
files prefixed with either "lib" or "exe", and compiles a free-standing 
library or an executable, respectively, for each such file. Since all 
compiled files are placed in a single directory (this is currently a 
requirement from the jtreg native support), there is the additional 
requirement that all files have unique names.

My personal opinion is that a better long-term approach is to compile 
all tests into a single library, if possible. (I realize some tests need 
to be separate to test library loading, etc.) For that to work, however, 
JTReg needs to be changed. The build framework in the patch is designed 
in such a way that it will be easy to add compilation to a common 
library in the future, if that restriction is lifted from JTReg.

This patch also lays the foundation for building additional tests, not 
only native jtreg tests, by the build system in the future. For 
instance, it codifies the suggested correspondence between make targets, 
intermediate test output and test image final build results. With the 
on-going test co-location project, we expect a stream of tests to be 
added to the build system in the future, and we hope this project can 
serve as an example of a suitable way of integration.

The patch modifies hotspot code, but it's mostly due to the addition of 
the new dummy tests. My preference would be to integrate this patch via 
jdk9-dev, since it modifies the build system most of all, but I'm open 
for discussion.

Bug: https://bugs.openjdk.java.net/browse/JDK-8072842
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.01

/Magnus


From paul.sandoz at oracle.com  Tue Feb 10 14:36:45 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 10 Feb 2015 15:36:45 +0100
Subject: Lexicographic array comparators
Message-ID: <79B05B7B-CC06-4C6B-A29E-F3242F9EDE34@oracle.com>

Hi,

One common use of Unsafe is boost the performance of comparing unsigned byte[] by viewing as long[] (for example as performed by Guava or Cassandra). To reduce the dependency on Unsafe we need a public and safe equivalent that works on all platforms while meeting the performance expectations.

In the past we have discussed exposing something on ByteBuffer but i think the right thing to explore are comparators for all basic types on java.util.Arrays:

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

This should be explored with the following issue in mind to expose an intrinsic that could be leveraged when implemented: 

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

Some preliminary work can be found here:

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/

The "explosion" in methods is annoying. Out of the 8 primitives 4 can be signed or unsigned. Objects can be comparable or an explicit comparator can be used. There are implicit and explicit ranges. That makes a maximum of 28 methods, but could be reduced to a minimum of 10, for all basic types.

Comparator instances, for implicit ranges, can easily be created from method refs or lambdas.

Thoughts?

Paul.


From chris.hegarty at oracle.com  Tue Feb 10 14:39:06 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 10 Feb 2015 14:39:06 +0000
Subject: Unsafe.park/unpark, j.u.c.LockSupport and Thread
In-Reply-To: <17D1013C-EFF5-4AAF-8237-833AF20C3A17@oracle.com>
References: <0EF3EAFA-01DF-4577-AD4F-801AD989F639@oracle.com>
	<54D9F363.50003@oracle.com>
	<17D1013C-EFF5-4AAF-8237-833AF20C3A17@oracle.com>
Message-ID: <B04D882C-ACCF-4278-9D91-1A99D8F50CA1@oracle.com>

On 10 Feb 2015, at 12:46, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi David,
> 
> On Feb 10, 2015, at 1:02 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
>> Hi Paul,
>> 
>> When we added j.u.c there was reluctance to add these methods to Thread - this was the normal policy (for the time) of don't touch the core classes. So LockSupport is the public API and Unsafe was chosen as the implementation as it is a de-facto interface to the VM from JDK code rather then defining explicit native methods (I must admit I'm unsure why we went this route rather than simply hooking into jvm.cpp with JVM_park/JVM_unpark. I think in many ways it was/is just easier to call an Unsafe method and define a new unsafe.cpp native call. Plus we had a bunch of other Unsafe API's being used from j.u.c.)
>> 
>> So we can't just move things from LockSupport to Thread as we'd need to deprecate first etc etc.
> 
> I was thinking that the implementation of LockSupport could be updated to use any new stuff we could add to java.lang.{*, Thread}.
> 
> I am trying to tease apart the internal dependencies that 166 classes have on the platform. In the case of LockSupport there are two, Unsafe and Thread.
> 
> Adding native methods to 166 classes will introduce another form of dependency on the platform that i would prefer to avoid.

Right. And I suspect that the separate distributable of 166, outside of the Java Platform, would not want to have to carry a separate platform specific native library.

>> But I don't see any reason why we couldn't move the implementation from unsafe.cpp to jvm.cpp and invoke via a native method implementation of LockSupport. It would still be just as "unsafe" of course.
>> 
> 
> Can you think of any reasons, beyond that of "don't touch the core classes", why we cannot copy this functionality over to java.lang.{*, Thread} ?

Would you be thinking of making the changes public, i.e. new standard API on java.lang.Thread ?

-Chris.

>> Aside: this is where the infamous "spurious wakeup" from park() can arise. If you just randomly unpark() a Thread there is nothing to guarantee that the thread doesn't terminate and free its native resources while you are working on it. But the ParkEvents are type-stable-memory, so even if the event has been disassociated from the target thread you can still call unpark() as it is never freed. However if that ParkEvent has since been reused by another thread, then that thread will encounter a "spurious wakeup" if it calls park().
>> 
> 
> I see, and can the same happen for Object.wait as well? I gather so from the documentation.
> 
> 
> On Feb 10, 2015, at 1:04 PM, David Holmes <david.holmes at oracle.com> wrote:
>> Oh I just realized/remembered why we use Unsafe for this - it is because of the potential for intrinsics.
> 
> I can certainly imagine it's convenient place to put things in that regard.
> 
> Paul.
> 



From paul.sandoz at oracle.com  Tue Feb 10 14:51:58 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 10 Feb 2015 15:51:58 +0100
Subject: Unsafe.park/unpark, j.u.c.LockSupport and Thread
In-Reply-To: <B04D882C-ACCF-4278-9D91-1A99D8F50CA1@oracle.com>
References: <0EF3EAFA-01DF-4577-AD4F-801AD989F639@oracle.com>
	<54D9F363.50003@oracle.com>
	<17D1013C-EFF5-4AAF-8237-833AF20C3A17@oracle.com>
	<B04D882C-ACCF-4278-9D91-1A99D8F50CA1@oracle.com>
Message-ID: <80D63F2C-6A19-4A6A-8AA4-3D8BF048B4D0@oracle.com>

On Feb 10, 2015, at 3:39 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> 
>> Adding native methods to 166 classes will introduce another form of dependency on the platform that i would prefer to avoid.
> 
> Right. And I suspect that the separate distributable of 166, outside of the Java Platform, would not want to have to carry a separate platform specific native library.

Yes.


> 
>>> But I don't see any reason why we couldn't move the implementation from unsafe.cpp to jvm.cpp and invoke via a native method implementation of LockSupport. It would still be just as "unsafe" of course.
>>> 
>> 
>> Can you think of any reasons, beyond that of "don't touch the core classes", why we cannot copy this functionality over to java.lang.{*, Thread} ?
> 
> Would you be thinking of making the changes public, i.e. new standard API on java.lang.Thread ?
> 

Yes, j.l.Thread seems like the ideal location :-)

Paul.


From staffan.larsen at oracle.com  Tue Feb 10 15:10:05 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 10 Feb 2015 16:10:05 +0100
Subject: RFR: JDK-8072842 Add support for building native JTReg tests
In-Reply-To: <54DA146D.3060904@oracle.com>
References: <54DA146D.3060904@oracle.com>
Message-ID: <D93A391C-0FC1-4328-BD34-5D2D804E4FEC@oracle.com>


> On 10 feb 2015, at 15:23, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> Here is an addition to the build system, that will compile native libraries and executables and make them available for JTReg tests written in Java.
> 
> This patch is the result of the work (in serial, mostly) of Staffan Larsen, David Simms and me. (And possible more that I don't know about.)
> 
> In it current form, the patch only provides the framework on which to attach real tests. To prove the concept, some initial dummy tests are present. These are supposed to be removed as soon as real tests starts to propagate into the jdk and hotspot jtreg test suites.
> 
> The behavior is based on the following design: For directories with native jtreg compilation enabled, the build system searches for native files prefixed with either "lib" or "exe", and compiles a free-standing library or an executable, respectively, for each such file. Since all compiled files are placed in a single directory (this is currently a requirement from the jtreg native support), there is the additional requirement that all files have unique names.
> 
> My personal opinion is that a better long-term approach is to compile all tests into a single library, if possible. (I realize some tests need to be separate to test library loading, etc.) For that to work, however, JTReg needs to be changed. The build framework in the patch is designed in such a way that it will be easy to add compilation to a common library in the future, if that restriction is lifted from JTReg.

To clarify: The restriction in jtreg is that all tests are loaded in separate class loaders (when running in samevm mode). A native library can only be loaded in one class loader at a time. So if two tests tries to load the same library we get errors. It would be possible to change this if samevm mode is removed from jtreg.

/Staffan

> 
> This patch also lays the foundation for building additional tests, not only native jtreg tests, by the build system in the future. For instance, it codifies the suggested correspondence between make targets, intermediate test output and test image final build results. With the on-going test co-location project, we expect a stream of tests to be added to the build system in the future, and we hope this project can serve as an example of a suitable way of integration.
> 
> The patch modifies hotspot code, but it's mostly due to the addition of the new dummy tests. My preference would be to integrate this patch via jdk9-dev, since it modifies the build system most of all, but I'm open for discussion.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8072842
> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.01
> 
> /Magnus



From magnus.ihse.bursie at oracle.com  Tue Feb 10 15:25:02 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 10 Feb 2015 16:25:02 +0100
Subject: RFR: JDK-8072842 Add support for building native JTReg tests
In-Reply-To: <D93A391C-0FC1-4328-BD34-5D2D804E4FEC@oracle.com>
References: <54DA146D.3060904@oracle.com>
	<D93A391C-0FC1-4328-BD34-5D2D804E4FEC@oracle.com>
Message-ID: <4A2737F1-60D1-4C0A-9D56-10A2C1BA661F@oracle.com>


> 10 feb 2015 kl. 16:10 skrev Staffan Larsen <staffan.larsen at oracle.com>:
> 
> 
>> On 10 feb 2015, at 15:23, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>> 
>> Here is an addition to the build system, that will compile native libraries and executables and make them available for JTReg tests written in Java.
>> 
>> This patch is the result of the work (in serial, mostly) of Staffan Larsen, David Simms and me. (And possible more that I don't know about.)
>> 
>> In it current form, the patch only provides the framework on which to attach real tests. To prove the concept, some initial dummy tests are present. These are supposed to be removed as soon as real tests starts to propagate into the jdk and hotspot jtreg test suites.
>> 
>> The behavior is based on the following design: For directories with native jtreg compilation enabled, the build system searches for native files prefixed with either "lib" or "exe", and compiles a free-standing library or an executable, respectively, for each such file. Since all compiled files are placed in a single directory (this is currently a requirement from the jtreg native support), there is the additional requirement that all files have unique names.
>> 
>> My personal opinion is that a better long-term approach is to compile all tests into a single library, if possible. (I realize some tests need to be separate to test library loading, etc.) For that to work, however, JTReg needs to be changed. The build framework in the patch is designed in such a way that it will be easy to add compilation to a common library in the future, if that restriction is lifted from JTReg.
> 
> To clarify: The restriction in jtreg is that all tests are loaded in separate class loaders (when running in samevm mode). A native library can only be loaded in one class loader at a time. So if two tests tries to load the same library we get errors. It would be possible to change this if samevm mode is removed from jtreg.

I thought the problem was that we try to load the same library multiple times by different classloaders, and that the solution was to load the library only once, e.g. by the jtreg framework before launching samevm tests. 

However, if the library has to be loaded by the class loader in which the test executes, this will not work. :(

Nevertheless, this discussion is tangential to the current review. If it is possible to add a singe-library approach to jtreg without sacrificing functionality, I believe that is a good thing, and this patch supports such an extension. If not, the current patch works anyway. 

/Magnus

> 
> /Staffan
> 
>> 
>> This patch also lays the foundation for building additional tests, not only native jtreg tests, by the build system in the future. For instance, it codifies the suggested correspondence between make targets, intermediate test output and test image final build results. With the on-going test co-location project, we expect a stream of tests to be added to the build system in the future, and we hope this project can serve as an example of a suitable way of integration.
>> 
>> The patch modifies hotspot code, but it's mostly due to the addition of the new dummy tests. My preference would be to integrate this patch via jdk9-dev, since it modifies the build system most of all, but I'm open for discussion.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8072842
>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.01
>> 
>> /Magnus
> 


From mandy.chung at oracle.com  Tue Feb 10 15:56:57 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Feb 2015 07:56:57 -0800
Subject: RFR: JDK-8068682 - Deprivilege/move java.corba to the ext class
	loader
In-Reply-To: <54D9F585.9060605@oracle.com>
References: <54D50E20.8020406@oracle.com>
	<54D53065.2080603@oracle.com>	<54D55ABC.6090306@oracle.com>
	<54D9CBF3.60005@oracle.com>	<54D9E995.8040508@oracle.com>
	<54D9ED8C.1080602@oracle.com> <54D9F585.9060605@oracle.com>
Message-ID: <54DA2A49.8060205@oracle.com>

The change without ORB.java looks okay to me.
Mandy

On 2/10/15 4:11 AM, Mark Sheppard wrote:
> OK I'll remove it.
>
> I thought that property files had been migrated from lib to conf, as 
> per conf/security,  so I made the change
>
> regards
> Mark
>
> On 10/02/2015 11:37, Alan Bateman wrote:
>> On 10/02/2015 11:20, Mark Sheppard wrote:
>>> thanks Alan
>>>
>>> the updated corba part is at
>>>
>>> http://cr.openjdk.java.net/~msheppar/8068682/corba/webrev.02/
>>>
>> I assume ORB.java isn't meant to be in this webrev (the lib->conf 
>> issue is separate and I think will need an @implNote in additional to 
>> checking for orb.properties in both lib and conf).
>>
>> -Alan.
>



From chris.hegarty at oracle.com  Tue Feb 10 16:20:29 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 10 Feb 2015 16:20:29 +0000
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54D9ECF1.9090203@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CD3043.2070709@gmail.com>	<54CD4A14.2080205@oracle.com>	<54CD6984.2040004@gmail.com>	<54CDF84E.7070905@oracle.com>	<54CE03D2.8000706@gmail.com>	<54CF386A.9000600@oracle.com>	<2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>	<54CF5EF3.20102@oracle.com>
	<54CFE38D.30400@oracle.com> <54D2249E.105@oracle.com>
	<54D22CC6.9040405@gmail.com> <54D23041.1020703@oracle.com>
	<54D236AA.4050406@oracle.com> <54D4957F.7070805@oracle.com>
	<54D8CAD7.50303@oracle.com> <54D9ECF1.9090203@oracle.com>
Message-ID: <6C6FF726-D47E-47A5-8644-AB5E6C32A468@oracle.com>

On 10 Feb 2015, at 11:35, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 09/02/2015 14:57, Chris Hegarty wrote:
>> :
>> 
>> Updated webrev [ spec and implementation] :
>>  http://cr.openjdk.java.net/~chegar/8064924/04/
>> 
> The updated javadoc looks good. I haven't had a chance yet to look at the implementation but I think you will need to update <top>/make/common/CORE_PKGS.gmk for the spi package.

Sorry, I have the change locally but forgot it. I updated the webrev with the changes to the top level repo ( below ):

$ hg diff make/common/CORE_PKGS.gmk 
diff --git a/make/common/CORE_PKGS.gmk b/make/common/CORE_PKGS.gmk
--- a/make/common/CORE_PKGS.gmk
+++ b/make/common/CORE_PKGS.gmk
@@ -103,6 +103,7 @@
     java.lang.reflect \
     java.math \
     java.net \
+    java.net.spi \
     java.nio \
     java.nio.channels \
     java.nio.channels.spi \

-Chris.

> -Alan.



From peter.levart at gmail.com  Tue Feb 10 18:17:32 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 10 Feb 2015 19:17:32 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54DA0174.5010709@gmail.com>
References: <54D941D1.8000305@Oracle.com> <54D9ECEC.4050404@gmail.com>
	<54DA0174.5010709@gmail.com>
Message-ID: <54DA4B3C.2000605@gmail.com>

On 02/10/2015 02:02 PM, Peter Levart wrote:
> On 02/10/2015 12:35 PM, Peter Levart wrote:
>> ProcessHandle.completableFuture().cancel(true) forcibly destorys 
>> (destroyForcibly()) the process *and* vice versa: destory[Forcibly]() 
>> cancels the CompletableFuture. I don't know if this is the best way - 
>> can't decide yet. In particular, in the implementation it would be 
>> hard to achieve the atommicity of both destroying the process and 
>> canceling the future. Races are inevitable. So it would be better to 
>> think of a process (and a ProcessHandle representing it) as the 1st 
>> stage in the processing pipeline, where 
>> ProcessHandle.completableFuture() is it's dependent stage which 
>> tracks real changes of the process. Which means the behaviour would 
>> be something like the following:
>>
>> - ProcessHandle.destroy[Forcibly]() triggers destruction of the 
>> process which in turn (when successful) triggers completion of 
>> CompletableFuture, exceptionally with CompletionException, wrapping 
>> the exception indicating the destruction of the process 
>> (ProcessDestroyedException?).
>>
>> - ProcessHandle.completableFuture().cancel(true/false) just cancels 
>> the CompletableFuture and does not do anything to the process itself.
>>
>> In that variant, then perhaps it would be more appropriate for 
>> ProcessHandle.completableFuture() to be a "factory" for 
>> CompletableFuture(s) so that each call would return new independent 
>> instance.
>>
>> What do you think? 
>
> Contemplating on this a little more, then perhaps the singleton-per 
> pid CompletionStage could be OK if it was a "mirror" of real process 
> state. For that purpose then, instead of .completableFuture() the 
> method would be:
>
> public CompletionStage<ProcessHandle> completionStage()
>
> Returns a CompletionStage<ProcessHandle> for the process. The 
> CompletionStage provides supporting dependent functions and actions 
> that are run upon process completion.
>
> Returns:
>     a CompletionStage<ProcessHandle> for the ProcessHandle; the same 
> instance is returned for each unique pid.
>
>
> This would provide the most clean API I think, as CompletionStage does 
> not have any cancel(), complete(), obtrudeXXX() or get() methods. One 
> could still obtain a CompletableFuture by calling 
> .toCompletableFuture() on the CompletionStage, but that future would 
> be a 2nd stage future (like calling .thenApply(x -> x)) which would 
> not propagate cancel(true) to the process destruction.
>
> The implementation could still use CompletableFuture under the hood, 
> but exposed wrapped in a delegating CompletionStage proxy.
>
> So the javadoc might be written as:
>
>
> public abstract void destroy()
>
> Kills the process. Whether the process represented by this Process 
> object is forcibly terminated or not is implementation dependent. If 
> the process is not alive, no action is taken.
>
> If/when the process dies as the result of calling destroy(), the 
> completionStage() completes exceptionally with CompletionException, 
> wrapping ProcessDestroyedException.
>
>
> public abstract ProcessHandle destroyForcibly()
>
> Kills the process. The process represented by this ProcessHandle 
> object is forcibly terminated. If the process is not alive, no action 
> is taken.
>
> If/when the process dies as the result of calling destroyForcibly(), 
> the completionStage() completes exceptionally with 
> CompletionException, wrapping ProcessDestroyedException.
>
>
> But I'm still unsure of whether it would be better for the 
> completionStage() to complete normally in any case. Unless the fact 
> that the process died as a result of killing it could be reliably 
> communicated regardless of who was responsible for the killing (either 
> via ProcessHandle.destoroy() or by a KILL/TERMINATE signal originating 
> from outside the VM).
>
> Peter
>
>

Hi Roger,

I checked out your branch in jdk9-sandbox and studied current 
implementation.

One problem with this approach (returning a singleton-per-pid 
CompletableFuture or CompletionStage) is that current 
processReaperExecutor is using threads with very small stack size (32 K) 
and the returned CompletableFuture could be instructed to append a 
continuation that executes synchronously:

     CompletionStage.thenApply(), CompletionStage.handle(), etc...

... so user code would execute by such thread and probably get 
StackOverflowException...

Also, multiple ProcessHandle objects together with a Process object for 
the same pid each return a separate CompletableFuture instance (not what 
spec. says). Each of them also spawns it's own thread to wait for 
process termination.

Here's a better approach (a diff to your branch):

http://cr.openjdk.java.net/~plevart/jdk9-sandbox/JDK-8046092-branch/webrev.01/

...it contains a global registry of internal CompletionStage(s) - one 
per pid. They are not exposed to users, just used internally (in Unix 
ProcessImpl) to execute cleanup and in .completionStage() to append an 
asynchronous stage which is returned by the method on each call. So 
users appending synchronous continuations to returned CompletionStage 
would execute them in a common FJ pool.

I haven't tested this yet. It's just an idea to share.

Regards, Peter




From anthony.vanelverdinghe at gmail.com  Tue Feb 10 19:12:23 2015
From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe)
Date: Tue, 10 Feb 2015 20:12:23 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54D941D1.8000305@Oracle.com>
References: <54D941D1.8000305@Oracle.com>
Message-ID: <54DA5817.1000301@gmail.com>

Hi Roger

This looks great already. My feedback is about process destruction:

Why isn't ProcessHandle::isDestroyForcible a static method?

For ProcessHandle::destroy and Process::destroy, I'd like to propose 
replacing
"Whether the process represented by this Process object is forcibly 
terminated or not is implementation dependent."
with:
"The process represented by this Process object is forcibly terminated 
if and only if isDestroyForcible returns true."

Process::destroyForcibly contains the following phrase: "The default 
implementation of this method invokes destroy() and so may not forcibly 
terminate the process."
Why doesn't the default implementation throw 
UnsupportedOperationException if forcible termination is not supported 
on/implemented for the current platform? If I write code like: 
process.destroyForcibly().waitFor(), I'd assume it would finish in a 
timely manner, but due to the default implementation, this may actually 
not finish at all.

Kind regards, Anthony


On 10/02/2015 0:25, Roger Riggs wrote:
> Hi,
>
> After a protracted absence from working on JEP 102, the updated API draft
> provides access to process hierarchies and individual process 
> information;
> as permitted by the OS. The relationship between Process and 
> ProcessHandle
> is clarified and the security model validated.
>
> Both Processes and ProcessHandles can be monitored using 
> CompletableFuture
> for termination and to trigger additional actions on Process exit.
> Information about processes includes the total cputime, starttime, user,
> executable, and arguments.
>
> Please review and comment:
>    http://cr.openjdk.java.net/~rriggs/ph-apidraft/
>
> Thanks, Roger
>
>
>
>
>



From martinrb at google.com  Tue Feb 10 19:14:09 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 10 Feb 2015 11:14:09 -0800
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54DA4B3C.2000605@gmail.com>
References: <54D941D1.8000305@Oracle.com> <54D9ECEC.4050404@gmail.com>
	<54DA0174.5010709@gmail.com> <54DA4B3C.2000605@gmail.com>
Message-ID: <CA+kOe08YMykHfvo7EuJwa1=JQMZW2Lbz+e7kj-CU7gJt+qv1Ag@mail.gmail.com>

(not enough time for real review)
I support Peter's approach.  I know of no way to be reliably notified of
process termination on unix without a dedicated thread per subprocess (unix
is broken!).  Given that, we want to keep its stack size small, which is
where the 32k comes from.  Maybe on 64-bit systems this becomes unimportant
- not sure - but we're not there yet this decade.  I agree that if the
reaper threads invokes CompletableFuture continuations, they should not be
run in the process reaper thread (stack too small), but run somewhere else,
probably the common pool.

On Tue, Feb 10, 2015 at 10:17 AM, Peter Levart <peter.levart at gmail.com>
wrote:

> On 02/10/2015 02:02 PM, Peter Levart wrote:
>
>> On 02/10/2015 12:35 PM, Peter Levart wrote:
>>
>>> ProcessHandle.completableFuture().cancel(true) forcibly destorys
>>> (destroyForcibly()) the process *and* vice versa: destory[Forcibly]()
>>> cancels the CompletableFuture. I don't know if this is the best way - can't
>>> decide yet. In particular, in the implementation it would be hard to
>>> achieve the atommicity of both destroying the process and canceling the
>>> future. Races are inevitable. So it would be better to think of a process
>>> (and a ProcessHandle representing it) as the 1st stage in the processing
>>> pipeline, where ProcessHandle.completableFuture() is it's dependent
>>> stage which tracks real changes of the process. Which means the behaviour
>>> would be something like the following:
>>>
>>> - ProcessHandle.destroy[Forcibly]() triggers destruction of the process
>>> which in turn (when successful) triggers completion of CompletableFuture,
>>> exceptionally with CompletionException, wrapping the exception indicating
>>> the destruction of the process (ProcessDestroyedException?).
>>>
>>> - ProcessHandle.completableFuture().cancel(true/false) just cancels the
>>> CompletableFuture and does not do anything to the process itself.
>>>
>>> In that variant, then perhaps it would be more appropriate for
>>> ProcessHandle.completableFuture() to be a "factory" for
>>> CompletableFuture(s) so that each call would return new independent
>>> instance.
>>>
>>> What do you think?
>>>
>>
>> Contemplating on this a little more, then perhaps the singleton-per pid
>> CompletionStage could be OK if it was a "mirror" of real process state. For
>> that purpose then, instead of .completableFuture() the method would be:
>>
>> public CompletionStage<ProcessHandle> completionStage()
>>
>> Returns a CompletionStage<ProcessHandle> for the process. The
>> CompletionStage provides supporting dependent functions and actions that
>> are run upon process completion.
>>
>> Returns:
>>     a CompletionStage<ProcessHandle> for the ProcessHandle; the same
>> instance is returned for each unique pid.
>>
>>
>> This would provide the most clean API I think, as CompletionStage does
>> not have any cancel(), complete(), obtrudeXXX() or get() methods. One could
>> still obtain a CompletableFuture by calling .toCompletableFuture() on the
>> CompletionStage, but that future would be a 2nd stage future (like calling
>> .thenApply(x -> x)) which would not propagate cancel(true) to the process
>> destruction.
>>
>> The implementation could still use CompletableFuture under the hood, but
>> exposed wrapped in a delegating CompletionStage proxy.
>>
>> So the javadoc might be written as:
>>
>>
>> public abstract void destroy()
>>
>> Kills the process. Whether the process represented by this Process object
>> is forcibly terminated or not is implementation dependent. If the process
>> is not alive, no action is taken.
>>
>> If/when the process dies as the result of calling destroy(), the
>> completionStage() completes exceptionally with CompletionException,
>> wrapping ProcessDestroyedException.
>>
>>
>> public abstract ProcessHandle destroyForcibly()
>>
>> Kills the process. The process represented by this ProcessHandle object
>> is forcibly terminated. If the process is not alive, no action is taken.
>>
>> If/when the process dies as the result of calling destroyForcibly(), the
>> completionStage() completes exceptionally with CompletionException,
>> wrapping ProcessDestroyedException.
>>
>>
>> But I'm still unsure of whether it would be better for the
>> completionStage() to complete normally in any case. Unless the fact that
>> the process died as a result of killing it could be reliably communicated
>> regardless of who was responsible for the killing (either via
>> ProcessHandle.destoroy() or by a KILL/TERMINATE signal originating from
>> outside the VM).
>>
>> Peter
>>
>>
>>
> Hi Roger,
>
> I checked out your branch in jdk9-sandbox and studied current
> implementation.
>
> One problem with this approach (returning a singleton-per-pid
> CompletableFuture or CompletionStage) is that current processReaperExecutor
> is using threads with very small stack size (32 K) and the returned
> CompletableFuture could be instructed to append a continuation that
> executes synchronously:
>
>     CompletionStage.thenApply(), CompletionStage.handle(), etc...
>
> ... so user code would execute by such thread and probably get
> StackOverflowException...
>
> Also, multiple ProcessHandle objects together with a Process object for
> the same pid each return a separate CompletableFuture instance (not what
> spec. says). Each of them also spawns it's own thread to wait for process
> termination.
>
> Here's a better approach (a diff to your branch):
>
> http://cr.openjdk.java.net/~plevart/jdk9-sandbox/JDK-
> 8046092-branch/webrev.01/
>
> ...it contains a global registry of internal CompletionStage(s) - one per
> pid. They are not exposed to users, just used internally (in Unix
> ProcessImpl) to execute cleanup and in .completionStage() to append an
> asynchronous stage which is returned by the method on each call. So users
> appending synchronous continuations to returned CompletionStage would
> execute them in a common FJ pool.
>
> I haven't tested this yet. It's just an idea to share.
>
> Regards, Peter
>
>
>


From joe.darcy at oracle.com  Tue Feb 10 19:25:59 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 10 Feb 2015 11:25:59 -0800
Subject: JDK 9 RFR of JDK-8072843: Typo in the description of the
	j.l.r.Executable.getAnnotatedReceiverType
Message-ID: <54DA5B47.8020906@oracle.com>

Hello,

Please review this typo fix for

      JDK-8072843: Typo in the description of the 
j.l.r.Executable.getAnnotatedReceiverType

Patch below; I spellchecked the rest of the comments and strings and 
didn't find any other problems.

Thanks,

-Joe

diff -r 30f5fa716218 
src/java.base/share/classes/java/lang/reflect/Executable.java
--- a/src/java.base/share/classes/java/lang/reflect/Executable.java Mon 
Feb 09 17:49:26 2015 -0800
+++ b/src/java.base/share/classes/java/lang/reflect/Executable.java Tue 
Feb 10 11:24:10 2015 -0800
@@ -662,7 +662,7 @@
       *
       * If this {@code Executable} object represents a static method or
       * represents a constructor of a top level, static member, local, or
-     * anoymous class, then the return value is null.
+     * anonymous class, then the return value is null.
       *
       * @return an object representing the receiver type of the method or
       * constructor represented by this {@code Executable} or {@code 
null} if



From lance.andersen at oracle.com  Tue Feb 10 19:29:04 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 10 Feb 2015 14:29:04 -0500
Subject: JDK 9 RFR of JDK-8072843: Typo in the description of the
	j.l.r.Executable.getAnnotatedReceiverType
In-Reply-To: <54DA5B47.8020906@oracle.com>
References: <54DA5B47.8020906@oracle.com>
Message-ID: <9489D9A5-0834-4225-88C4-2C97D1D0C8C1@oracle.com>

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

> Hello,
> 
> Please review this typo fix for
> 
>     JDK-8072843: Typo in the description of the j.l.r.Executable.getAnnotatedReceiverType
> 
> Patch below; I spellchecked the rest of the comments and strings and didn't find any other problems.
> 
> Thanks,
> 
> -Joe
> 
> diff -r 30f5fa716218 src/java.base/share/classes/java/lang/reflect/Executable.java
> --- a/src/java.base/share/classes/java/lang/reflect/Executable.java Mon Feb 09 17:49:26 2015 -0800
> +++ b/src/java.base/share/classes/java/lang/reflect/Executable.java Tue Feb 10 11:24:10 2015 -0800
> @@ -662,7 +662,7 @@
>      *
>      * If this {@code Executable} object represents a static method or
>      * represents a constructor of a top level, static member, local, or
> -     * anoymous class, then the return value is null.
> +     * anonymous class, then the return value is null.
>      *
>      * @return an object representing the receiver type of the method or
>      * constructor represented by this {@code Executable} or {@code null} if
> 



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





From Roger.Riggs at Oracle.com  Tue Feb 10 19:31:28 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 10 Feb 2015 14:31:28 -0500
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54D9ECEC.4050404@gmail.com>
References: <54D941D1.8000305@Oracle.com> <54D9ECEC.4050404@gmail.com>
Message-ID: <54DA5C90.3050301@Oracle.com>

Hi Peter,

On 2/10/2015 6:35 AM, Peter Levart wrote:
> On 02/10/2015 12:25 AM, Roger Riggs wrote:
>> Hi,
>>
>> After a protracted absence from working on JEP 102, the updated API 
>> draft
>> provides access to process hierarchies and individual process 
>> information;
>> as permitted by the OS. The relationship between Process and 
>> ProcessHandle
>> is clarified and the security model validated.
>>
>> Both Processes and ProcessHandles can be monitored using 
>> CompletableFuture
>> for termination and to trigger additional actions on Process exit.
>> Information about processes includes the total cputime, starttime, user,
>> executable, and arguments.
>>
>> Please review and comment:
>>    http://cr.openjdk.java.net/~rriggs/ph-apidraft/
>>
>> Thanks, Roger
>>
>>
>>
>>
> Hi Roger,
>
> Great to see progress on this.
>
> Here are my comments:
>
> ProcessHandle.{allProcesses,allChildren,children} return 
> Stream<ProcessHandle>. This is convenient if one wants to use Stream 
> API, but a little more inconvenient and perhaps with additional 
> overhead if one doesn't. Since all those methods return a "snapshot", 
> I can imagine that internally, there is a collection built from this 
> snapshot. So it would be most appropriate to return a 
> List<ProcessHandle>. One can always continue the expression by 
> appending .stream()..., but on the other hand if one wants to 
> .collect(toList()), additional copying is introduced.
I've been pulled both ways by various folks here also.
Both Streams and Collections are easily converted to the other.
The internal snapshot is an array of int pid's;  with the Stream, the 
creation of ProcessHandles can
be delayed until they are needed, if they are needed.
>
> ProcessHandle.completableFuture().cancel(true) forcibly destorys 
> (destroyForcibly()) the process *and* vice versa: destory[Forcibly]() 
> cancels the CompletableFuture. I don't know if this is the best way - 
> can't decide yet. In particular, in the implementation it would be 
> hard to achieve the atommicity of both destroying the process and 
> canceling the future. Races are inevitable.
Atomicity is provided by CompletableFuture, it handles the atomicity of 
updating its state.
If cancelled, there is no useful information or synchronization is 
needed from the (dieing) Process;
the CompletableFuture state/status is cancelled.
> So it would be better to think of a process (and a ProcessHandle 
> representing it) as the 1st stage in the processing pipeline, where 
> ProcessHandle.completableFuture() is it's dependent stage which tracks 
> real changes of the process. Which means the behaviour would be 
> something like the following:
>
> - ProcessHandle.destroy[Forcibly]() triggers destruction of the 
> process which in turn (when successful) triggers completion of 
> CompletableFuture, exceptionally with CompletionException, wrapping 
> the exception indicating the destruction of the process 
> (ProcessDestroyedException?).
Maybe thinking along the similar lines; Process and Future are loosely 
coupled;
A process exiting, regardless of whether  it was killed by some entity 
in the system
or the Java API should complete the Future.
For a Process, the exitStatus is available and could be used to modify 
the normal vs exceptional completion.
But for an arbitrary ProcessHandle, the process may not have been 
spawned by this process;
in that case the exit status is not available (see previous long 
discussions about reaping).
Also, the exit status may not be a reliable indication of success vs 
failure of the process.
So the best that can be reported is that the Process is terminated and 
the Future is completed (normally).

>
> - ProcessHandle.completableFuture().cancel(true/false) just cancels 
> the CompletableFuture and does not do anything to the process itself.

My model was that the CompletableFuture from ProcessHandle is a proxy 
for the process itself.
It is an abstraction for the Process that is independent of the 
implementation (as a Process).
It looks just like any other stage in the tree of CompletionStages.
The application that spawns the Process can control what it exposes as 
the CompletableFuture
it can expose the root or create another Completable future to hang 
other operations on.

>
> In that variant, then perhaps it would be more appropriate for 
> ProcessHandle.completableFuture() to be a "factory" for 
> CompletableFuture(s) so that each call would return new independent 
> instance.
>
> What do you think?

I'm not sure which model is more useful to the application/library.
The implementation may be simpler if it only has to keep track of a 
single CompletableFuture
instead of a set but decoupling may be simpler to model.

Thanks, Roger
>
> Regards, Peter
>



From martinrb at google.com  Tue Feb 10 19:48:36 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 10 Feb 2015 11:48:36 -0800
Subject: Lexicographic array comparators
In-Reply-To: <79B05B7B-CC06-4C6B-A29E-F3242F9EDE34@oracle.com>
References: <79B05B7B-CC06-4C6B-A29E-F3242F9EDE34@oracle.com>
Message-ID: <CA+kOe08e2ADM5yP5ZXkkf8qoNLtdLajb7Lt+fzayfSX1YeFhxg@mail.gmail.com>

People will continue to want to access byte arrays (and direct byte
buffers) with C-like performance, and are currently using Unsafe to do so.
Hard to fix for real.  Endianness and unaligned access are both
non-portable aspects.  People don't want to pay for bounds checking and
especially not for alignment checking of indexes known to be aligned.
Lexicographic comparison is only one use case (that happened to be
important performance wise for guava).

I have long thought that arrays should acquire more listesque methods (e.g.
contains, indexOf), even though arrays are unpopular.

On Tue, Feb 10, 2015 at 6:36 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
>
> One common use of Unsafe is boost the performance of comparing unsigned
> byte[] by viewing as long[] (for example as performed by Guava or
> Cassandra). To reduce the dependency on Unsafe we need a public and safe
> equivalent that works on all platforms while meeting the performance
> expectations.
>
> In the past we have discussed exposing something on ByteBuffer but i think
> the right thing to explore are comparators for all basic types on
> java.util.Arrays:
>
>  https://bugs.openjdk.java.net/browse/JDK-8033148
>
> This should be explored with the following issue in mind to expose an
> intrinsic that could be leveraged when implemented:
>
>  https://bugs.openjdk.java.net/browse/JDK-8044082
>
> Some preliminary work can be found here:
>
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/
>
> The "explosion" in methods is annoying. Out of the 8 primitives 4 can be
> signed or unsigned. Objects can be comparable or an explicit comparator can
> be used. There are implicit and explicit ranges. That makes a maximum of 28
> methods, but could be reduced to a minimum of 10, for all basic types.
>
> Comparator instances, for implicit ranges, can easily be created from
> method refs or lambdas.
>
> Thoughts?
>
> Paul.
>


From Roger.Riggs at Oracle.com  Tue Feb 10 19:52:49 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 10 Feb 2015 14:52:49 -0500
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54DA4B3C.2000605@gmail.com>
References: <54D941D1.8000305@Oracle.com> <54D9ECEC.4050404@gmail.com>
	<54DA0174.5010709@gmail.com> <54DA4B3C.2000605@gmail.com>
Message-ID: <54DA6191.60401@Oracle.com>

Hi Peter,

Yep, I hadn't gotten to improving that part of the implementation yet.
The threading needs to be revised; System threads and the limited stack 
were used currently
to monitor processes (on Linux) but are not suitable for evaluating 
CompletionStages.
Switching to some form of Executor as a source of thread is needed.
I was also trying to preserve an option to have a lightweight monitor
of thread liveness that did not require a thread to improve scalability.
That would allow the thread needed for CompletionStage to be created 
only if and
when it is needed.

On 2/10/2015 1:17 PM, Peter Levart wrote:
> On 02/10/2015 02:02 PM, Peter Levart wrote:
>> On 02/10/2015 12:35 PM, Peter Levart wrote:
>>> ProcessHandle.completableFuture().cancel(true) forcibly destorys 
>>> (destroyForcibly()) the process *and* vice versa: 
>>> destory[Forcibly]() cancels the CompletableFuture. I don't know if 
>>> this is the best way - can't decide yet. In particular, in the 
>>> implementation it would be hard to achieve the atommicity of both 
>>> destroying the process and canceling the future. Races are 
>>> inevitable. So it would be better to think of a process (and a 
>>> ProcessHandle representing it) as the 1st stage in the processing 
>>> pipeline, where ProcessHandle.completableFuture() is it's dependent 
>>> stage which tracks real changes of the process. Which means the 
>>> behaviour would be something like the following:
>>>
>>> - ProcessHandle.destroy[Forcibly]() triggers destruction of the 
>>> process which in turn (when successful) triggers completion of 
>>> CompletableFuture, exceptionally with CompletionException, wrapping 
>>> the exception indicating the destruction of the process 
>>> (ProcessDestroyedException?).
>>>
>>> - ProcessHandle.completableFuture().cancel(true/false) just cancels 
>>> the CompletableFuture and does not do anything to the process itself.
>>>
>>> In that variant, then perhaps it would be more appropriate for 
>>> ProcessHandle.completableFuture() to be a "factory" for 
>>> CompletableFuture(s) so that each call would return new independent 
>>> instance.
>>>
>>> What do you think? 
>>
>> Contemplating on this a little more, then perhaps the singleton-per 
>> pid CompletionStage could be OK if it was a "mirror" of real process 
>> state. For that purpose then, instead of .completableFuture() the 
>> method would be:
>>
>> public CompletionStage<ProcessHandle> completionStage()
>>
>> Returns a CompletionStage<ProcessHandle> for the process. The 
>> CompletionStage provides supporting dependent functions and actions 
>> that are run upon process completion.
>>
>> Returns:
>>     a CompletionStage<ProcessHandle> for the ProcessHandle; the same 
>> instance is returned for each unique pid.
>>
>>
>> This would provide the most clean API I think, as CompletionStage 
>> does not have any cancel(), complete(), obtrudeXXX() or get() 
>> methods. One could still obtain a CompletableFuture by calling 
>> .toCompletableFuture() on the CompletionStage, but that future would 
>> be a 2nd stage future (like calling .thenApply(x -> x)) which would 
>> not propagate cancel(true) to the process destruction.
>>
>> The implementation could still use CompletableFuture under the hood, 
>> but exposed wrapped in a delegating CompletionStage proxy.
>>
>> So the javadoc might be written as:
>>
>>
>> public abstract void destroy()
>>
>> Kills the process. Whether the process represented by this Process 
>> object is forcibly terminated or not is implementation dependent. If 
>> the process is not alive, no action is taken.
>>
>> If/when the process dies as the result of calling destroy(), the 
>> completionStage() completes exceptionally with CompletionException, 
>> wrapping ProcessDestroyedException.
>>
>>
>> public abstract ProcessHandle destroyForcibly()
>>
>> Kills the process. The process represented by this ProcessHandle 
>> object is forcibly terminated. If the process is not alive, no action 
>> is taken.
>>
>> If/when the process dies as the result of calling destroyForcibly(), 
>> the completionStage() completes exceptionally with 
>> CompletionException, wrapping ProcessDestroyedException.
>>
>>
>> But I'm still unsure of whether it would be better for the 
>> completionStage() to complete normally in any case. Unless the fact 
>> that the process died as a result of killing it could be reliably 
>> communicated regardless of who was responsible for the killing 
>> (either via ProcessHandle.destoroy() or by a KILL/TERMINATE signal 
>> originating from outside the VM).
>>
>> Peter
>>
>>
>
> Hi Roger,
>
> I checked out your branch in jdk9-sandbox and studied current 
> implementation.
>
> One problem with this approach (returning a singleton-per-pid 
> CompletableFuture or CompletionStage) is that current 
> processReaperExecutor is using threads with very small stack size (32 
> K) and the returned CompletableFuture could be instructed to append a 
> continuation that executes synchronously:
>
>     CompletionStage.thenApply(), CompletionStage.handle(), etc...
>
> ... so user code would execute by such thread and probably get 
> StackOverflowException...
Yes, a normal stack size is needed.
>
> Also, multiple ProcessHandle objects together with a Process object 
> for the same pid each return a separate CompletableFuture instance 
> (not what spec. says). Each of them also spawns it's own thread to 
> wait for process termination.
>
> Here's a better approach (a diff to your branch):
>
> http://cr.openjdk.java.net/~plevart/jdk9-sandbox/JDK-8046092-branch/webrev.01/ 
>
>
> ...it contains a global registry of internal CompletionStage(s) - one 
> per pid. They are not exposed to users, just used internally (in Unix 
> ProcessImpl) to execute cleanup and in .completionStage() to append an 
> asynchronous stage which is returned by the method on each call. So 
> users appending synchronous continuations to returned CompletionStage 
> would execute them in a common FJ pool.

Yep that's the idea and should be common across Windows/Unix/MacOSx and
usable with Process and ProcessHandles.  I'll take another look.

Thanks, Roger

>
> I haven't tested this yet. It's just an idea to share.
>
> Regards, Peter
>
>



From Roger.Riggs at Oracle.com  Tue Feb 10 20:03:21 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 10 Feb 2015 15:03:21 -0500
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54DA5817.1000301@gmail.com>
References: <54D941D1.8000305@Oracle.com> <54DA5817.1000301@gmail.com>
Message-ID: <54DA6409.4070207@Oracle.com>

Hi Anthony,

On 2/10/2015 2:12 PM, Anthony Vanelverdinghe wrote:
> Hi Roger
>
> This looks great already. My feedback is about process destruction:
>
> Why isn't ProcessHandle::isDestroyForcible a static method?
The Process API is subclassable and in that case the subclass
should be able to control that behavior.  When the specification refers to
implementation dependent it refers to the classes that implement Process.
The built-in ProcessBuilder and Runtime.exec that uses ProcessBuilder
define their implementation behaviors.

>
> For ProcessHandle::destroy and Process::destroy, I'd like to propose 
> replacing
> "Whether the process represented by this Process object is forcibly 
> terminated or not is implementation dependent."
> with:
> "The process represented by this Process object is forcibly terminated 
> if and only if isDestroyForcible returns true."
There is some API history to contend with and multiple implementations 
are possible.
An application library can provide a factory of Process instances with 
other kinds of behavior.

>
> Process::destroyForcibly contains the following phrase: "The default 
> implementation of this method invokes destroy() and so may not 
> forcibly terminate the process."
> Why doesn't the default implementation throw 
> UnsupportedOperationException if forcible termination is not supported 
> on/implemented for the current platform? If I write code like: 
> process.destroyForcibly().waitFor(), I'd assume it would finish in a 
> timely manner, but due to the default implementation, this may 
> actually not finish at all.
The evolution of the Process API has been long and uneven.  Destroy came 
first but was not predictable;
the destroyForcibly was added but destroy remained backward compatible 
(and still must be backward compatible).

Roger

>
> Kind regards, Anthony
>
>
> On 10/02/2015 0:25, Roger Riggs wrote:
>> Hi,
>>
>> After a protracted absence from working on JEP 102, the updated API 
>> draft
>> provides access to process hierarchies and individual process 
>> information;
>> as permitted by the OS. The relationship between Process and 
>> ProcessHandle
>> is clarified and the security model validated.
>>
>> Both Processes and ProcessHandles can be monitored using 
>> CompletableFuture
>> for termination and to trigger additional actions on Process exit.
>> Information about processes includes the total cputime, starttime, user,
>> executable, and arguments.
>>
>> Please review and comment:
>>    http://cr.openjdk.java.net/~rriggs/ph-apidraft/
>>
>> Thanks, Roger
>>
>>
>>
>>
>>
>



From paul.sandoz at oracle.com  Tue Feb 10 20:22:56 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 10 Feb 2015 21:22:56 +0100
Subject: Lexicographic array comparators
In-Reply-To: <CA+kOe08e2ADM5yP5ZXkkf8qoNLtdLajb7Lt+fzayfSX1YeFhxg@mail.gmail.com>
References: <79B05B7B-CC06-4C6B-A29E-F3242F9EDE34@oracle.com>
	<CA+kOe08e2ADM5yP5ZXkkf8qoNLtdLajb7Lt+fzayfSX1YeFhxg@mail.gmail.com>
Message-ID: <99656009-069D-4553-A0F4-0020B52E7E4C@oracle.com>

Hi Martin,

In this case i am trying to pick off one particularly common case, within the 9 time-frame, used in a number of popular libraries. In that context (including that of the intrinsic referenced in the related issue) do you think this is reasonable?


On Feb 10, 2015, at 8:48 PM, Martin Buchholz <martinrb at google.com> wrote:

> People will continue to want to access byte arrays (and direct byte buffers) with C-like performance, and are currently using Unsafe to do so.
> Hard to fix for real.

Yes, that is a much larger problem that i hope both value types and panama will address more fully.


>   Endianness and unaligned access are both non-portable aspects.  People don't want to pay for bounds checking and especially not for alignment checking of indexes known to be aligned. 

Note that as part of the VarHandles work we will try and improve the strength reduction of bounds checks for array access. If we expose an intrinsic for unsigned integer comparison that can be reused within the nio buffers.


> Lexicographic comparison is only one use case (that happened to be important performance wise for guava). I have long thought that arrays should acquire more listesque methods (e.g. contains, indexOf), even though arrays are unpopular.  

> 

Yes, i was wondering the same, there should be an interface. But i think that is an arrays 2.0 and value types thing.

Paul.



From Roger.Riggs at Oracle.com  Tue Feb 10 22:06:50 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 10 Feb 2015 17:06:50 -0500
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <E888BD18-661D-40D0-B567-3056E0382F43@oracle.com>
References: <54D941D1.8000305@Oracle.com>
	<E888BD18-661D-40D0-B567-3056E0382F43@oracle.com>
Message-ID: <54DA80FA.6090804@Oracle.com>

Hi Staffan,


On 2/10/2015 4:53 AM, Staffan Larsen wrote:
> Happy to see this!
>
> In ProcessHandle.Info would it be possible to include the environment variables of the process as well?
The API was intended to provide a degree of control over subprocesses, 
but not
be a diagnostic tool, there are better os specific tools for those 
purposes.
On some systems getting current information requires reading the 
processes memory image
and that's a fragile mechanism that I don't think it is worth coding and 
maintaining.
There is also a risk of duplicating the functions of java.lang.management.
Can access to the environment can be supported in that API?
It is easier and  more reliable to retrieve that kind of information 
from inside of the process.
>
> How does ProcessHandle.allChildren() behave when process A launches B which launches C, and B terminates? Is C included in allChildren() of A?
Whatever the OS does. The implementation makes a best effort at a 
snapshot of the processes
that exist at the time the method is called. Depending on the OS the 
snapshot may or may not
get a consistent view. For example, on Unix, /proc/nnn is read and each 
process is opened to
get its parent.  The set of processes and the parentage can change 
during that process.
And the parent/child relationships can change after that, processes can 
be created or terminate at any time.

Roger

>
> Thanks,
> /Staffan
>
>> On 10 feb 2015, at 00:25, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
>>
>> Hi,
>>
>> After a protracted absence from working on JEP 102, the updated API draft
>> provides access to process hierarchies and individual process information;
>> as permitted by the OS. The relationship between Process and ProcessHandle
>> is clarified and the security model validated.
>>
>> Both Processes and ProcessHandles can be monitored using CompletableFuture
>> for termination and to trigger additional actions on Process exit.
>> Information about processes includes the total cputime, starttime, user,
>> executable, and arguments.
>>
>> Please review and comment:
>>    http://cr.openjdk.java.net/~rriggs/ph-apidraft/
>>
>> Thanks, Roger
>>
>>
>>
>>



From stuart.marks at oracle.com  Tue Feb 10 23:02:18 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 10 Feb 2015 15:02:18 -0800
Subject: RFR 8071600: Add a flat-mapping collector
In-Reply-To: <517DF5B9-E3C5-4CD9-A04A-AC06EBD61517@oracle.com>
References: <517DF5B9-E3C5-4CD9-A04A-AC06EBD61517@oracle.com>
Message-ID: <54DA8DFA.1020706@oracle.com>

Hi Paul,

On 2/3/15 5:48 AM, Paul Sandoz wrote:
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping/webrev/
>
> This patch adds a new flat mapping collector to Collectors. This can be useful if one needs to map 0 or more items into a downstream collector.

Mostly pretty good, just a couple minor nits.

Re the comment at TabulatorsTest.java line 513, this isn't a two-level groupBy 
anymore, it's a groupByWithMapping (as the test name indicates).

Given the new tests of closing in FlatMapOpTest.java, is it necessary to have 
testFlatMappingClose() in TabulatorsTest.java?

> A following patch, which i plan to fold into the above patch, performs some renames on the collectors test to be consistent with the current naming:
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping-test-rename/webrev/

Renaming looks good and makes it easy to correlate the tests, the assertion 
classes, and the collector implementations under test. Unfortunately, the word 
for the act of collecting is "collection" which is confusing since "collection" 
already has another meaning, but oh well.

s'marks



From martinrb at google.com  Tue Feb 10 23:15:33 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 10 Feb 2015 15:15:33 -0800
Subject: Lexicographic array comparators
In-Reply-To: <79B05B7B-CC06-4C6B-A29E-F3242F9EDE34@oracle.com>
References: <79B05B7B-CC06-4C6B-A29E-F3242F9EDE34@oracle.com>
Message-ID: <CA+kOe0_r+__GO8QTRqC8sF86m-G9m9YQZMAhuEXM02feqOkLTA@mail.gmail.com>

The addition of array comparison intrinsics makes sense - I've missed them
myself on occasion.

I was surprised that System.arraycopy hasn't been specialized for every
array type.
I guess the JIT is good at specializing all callers.

I don't know whether we will someday regret the explosion of array
comparison methods.
The case for the intrinsic seems more compelling to me.

(Hopefully someone else will do the real review)

On Tue, Feb 10, 2015 at 6:36 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
>
> One common use of Unsafe is boost the performance of comparing unsigned
> byte[] by viewing as long[] (for example as performed by Guava or
> Cassandra). To reduce the dependency on Unsafe we need a public and safe
> equivalent that works on all platforms while meeting the performance
> expectations.
>
> In the past we have discussed exposing something on ByteBuffer but i think
> the right thing to explore are comparators for all basic types on
> java.util.Arrays:
>
>  https://bugs.openjdk.java.net/browse/JDK-8033148
>
> This should be explored with the following issue in mind to expose an
> intrinsic that could be leveraged when implemented:
>
>  https://bugs.openjdk.java.net/browse/JDK-8044082
>
> Some preliminary work can be found here:
>
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/
>
> The "explosion" in methods is annoying. Out of the 8 primitives 4 can be
> signed or unsigned. Objects can be comparable or an explicit comparator can
> be used. There are implicit and explicit ranges. That makes a maximum of 28
> methods, but could be reduced to a minimum of 10, for all basic types.
>
> Comparator instances, for implicit ranges, can easily be created from
> method refs or lambdas.
>
> Thoughts?
>
> Paul.
>


From john.r.rose at oracle.com  Tue Feb 10 23:26:17 2015
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 10 Feb 2015 15:26:17 -0800
Subject: Lexicographic array comparators
In-Reply-To: <CA+kOe0_r+__GO8QTRqC8sF86m-G9m9YQZMAhuEXM02feqOkLTA@mail.gmail.com>
References: <79B05B7B-CC06-4C6B-A29E-F3242F9EDE34@oracle.com>
	<CA+kOe0_r+__GO8QTRqC8sF86m-G9m9YQZMAhuEXM02feqOkLTA@mail.gmail.com>
Message-ID: <804E01BD-C9C7-4ACE-801C-C3E3F05AFFCB@oracle.com>

On Feb 10, 2015, at 3:15 PM, Martin Buchholz <martinrb at google.com> wrote:
> 
> I was surprised that System.arraycopy hasn't been specialized for every
> array type.
> I guess the JIT is good at specializing all callers.

Yes.  Usually the arguments have specific static types the JIT can see.
The Object formal type doesn't obscure this.

> I don't know whether we will someday regret the explosion of array
> comparison methods.

It's technical debt.  When we go to value types there will be an infinite number of array types.
That's why in Project Valhalla we are thinking hard, before that, about parametric polymorphism.
We need to be able to have true polymorphism over APIs in T[], where T can be ref, prim, or value.
At that point, hopefully, what we have won't be impossible to retrofit.

? John

From brian.burkhalter at oracle.com  Wed Feb 11 00:06:21 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 10 Feb 2015 16:06:21 -0800
Subject: [9] 8064562: (doc) errors in java.io.PushbackInputStream API
	documentation
Message-ID: <1E780C93-DB74-4013-A35C-59B385B0F223@oracle.com>

Please review at your convenience.

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

Thanks,

Brian


From stuart.marks at oracle.com  Wed Feb 11 01:02:13 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 10 Feb 2015 17:02:13 -0800
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <D23B81AC-3A4A-43CD-879D-D50F4A631741@oracle.com>
References: <8890A88D-98D4-4F22-A71E-9C29A9F5545B@oracle.com>
	<D23B81AC-3A4A-43CD-879D-D50F4A631741@oracle.com>
Message-ID: <54DAAA15.3080301@oracle.com>

Hi Paul,

I spent some time looking at this API. Overall it seems to me that things work a 
bit more nicely when these methods are added to Pattern instead of Matcher. 
Unfortunately there are some odd things with the existing API that make this 
tradeoff not so obvious.

First, here's what a simple replacement operation looks like when replaceAll() 
is added to Matcher:

         String input = "fooaaaabbfooabbbfoo";
         Pattern p = Pattern.compile("a*b");
         Matcher m = p.matcher(input);
         String result = m.replaceAll(mr -> mr.group().toUpperCase());

But if replaceAll() is on Pattern, we can skip a step:

         String input = "fooaaaabbfooabbbfoo";
         Pattern p = Pattern.compile("a*b");
         String result = p.replaceAll(input, mr -> mr.group().toUpperCase());

Getting stream of match results is similar. So yes, I agree that it simplifies 
things to have these be on Pattern instead of Matcher.

An advantage of having these on Pattern is that the matcher that gets created is 
encapsulated, and its state isn't exposed to being mucked about by the 
application. Thus you can avoid the additional concurrent modification checks 
that you have to do if replaceAll et. al. are on Matcher.

Unfortunately, putting these on Pattern now creates some difficulties meshing 
with the existing API.

One issue is that Matcher already has replaceAll(String) and 
replaceFirst(String). It would be strange to have these here and to have 
replaceAll(replacer) and replaceFirst(replacer) on Pattern.

Another issue is that Matcher supports matching on region (subrange) of its 
input. For example, today you can do this:

     pattern.matcher(input).region(start, end)

The region will constrain the matching for certain operations, such as find() 
(but not replaceAll or replaceFirst). If something like results() were added to 
Matcher, I'd expect that it would respect the Matcher's region, but if results() 
(or matches() as you called it) were on Pattern, the region constraint would be 
lacking.

Also note that Pattern already has this:

     static boolean matches(regex, input)

so I don't think an overload of matches() that returns a Stream would be a good 
idea. (Maybe findAll()?)

Another issue, not directly related to where the new lambda/streams methods get 
added, is that MatchResult allows references only numbered capturing groups. 
Matcher, which implements MatchResult, also supports named capturing groups, 
with the new overloaded methods group(String), start(String), and end(String). 
These were added in Java 7. Logically these also belong on MatchResult, but they 
probably weren't added because of the compatibility issue of adding methods to 
interfaces. Maybe we should add these as default methods to MatchResult.

(But what would the supported implementation be? Just throw 
UnsupportedOperationException?)

--

I'm not entirely sure where this leaves things. It certainly seems more 
convenient to have the new methods on Pattern. But given the way the existing 
API is set up, it seems like it's a better fit to add them to Matcher.

s'marks



On 2/9/15 6:18 AM, Paul Sandoz wrote:
> Here is an alternative that pushes the methods on to Pattern instead:
>
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/on-Pattern/webrev/
>
> (Whe webrev reports some files as empty, please ingore those, i have this webrev stacked on the previous one.)
>
> I have also included replaceFirst.
>
> This simplifies things for streaming on the match results and also for replacing.
>
> Note that the existing replace* methods on Matcher reset the matcher before matching and indicate that the matcher should be reset afterwards for reuse. Thus there is no loss in functionality moving such lambda accepting methods from Matcher to Pattern. It comes down to the performance of reusing a matcher, which does not seems so compelling to me.
>
> Paul.
>
> On Feb 5, 2015, at 11:59 AM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
>
>> Hi.
>>
>> Please review these stream/lambda enhancements on Matcher:
>>
>>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/
>>
>> Two new methods are added to Matcher:
>>
>> 1) replaceAll(Function<MatchResult, String> ) that is more flexible than the existing replaceAll that accepts a single value.
>>
>> 2) Stream<MatchResult> results() that returns a stream of MatchResult for all matches.
>>
>> The former does introduce a minor source incompatibility for a null argument, but then so did the new append methods accepting StringBuilder that were recently added (see JDK-8039124).
>>
>> For the latter i opted to place the method on Matcher rather than Pattern as i think that is a better fit with current usages of Matcher and operating on a MatchResult. That marginally increases the complexity since co-modification checking is required.
>>
>> I update the test PatternStreamTest to derive the expected result.
>>
>>
>> I suppose i could add another method replaceFirst(Function<MatchResult, String> ) if anyone feels strongly about that. Consistency-wise it seems the right thing to do.
>>
>> Paul.
>


From david.holmes at oracle.com  Wed Feb 11 01:35:10 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Feb 2015 11:35:10 +1000
Subject: RFR: JDK-8072842 Add support for building native JTReg tests
In-Reply-To: <54DA146D.3060904@oracle.com>
References: <54DA146D.3060904@oracle.com>
Message-ID: <54DAB1CE.70506@oracle.com>

Hi Magnus,

On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote:
> Here is an addition to the build system, that will compile native
> libraries and executables and make them available for JTReg tests
> written in Java.

Sorry I'm missing the basics here: when does this compilation take 
place? As part of a normal build? Where will the build artifacts go?

Thanks,
David H.

> This patch is the result of the work (in serial, mostly) of Staffan
> Larsen, David Simms and me. (And possible more that I don't know about.)
>
> In it current form, the patch only provides the framework on which to
> attach real tests. To prove the concept, some initial dummy tests are
> present. These are supposed to be removed as soon as real tests starts
> to propagate into the jdk and hotspot jtreg test suites.
>
> The behavior is based on the following design: For directories with
> native jtreg compilation enabled, the build system searches for native
> files prefixed with either "lib" or "exe", and compiles a free-standing
> library or an executable, respectively, for each such file. Since all
> compiled files are placed in a single directory (this is currently a
> requirement from the jtreg native support), there is the additional
> requirement that all files have unique names.
>
> My personal opinion is that a better long-term approach is to compile
> all tests into a single library, if possible. (I realize some tests need
> to be separate to test library loading, etc.) For that to work, however,
> JTReg needs to be changed. The build framework in the patch is designed
> in such a way that it will be easy to add compilation to a common
> library in the future, if that restriction is lifted from JTReg.
>
> This patch also lays the foundation for building additional tests, not
> only native jtreg tests, by the build system in the future. For
> instance, it codifies the suggested correspondence between make targets,
> intermediate test output and test image final build results. With the
> on-going test co-location project, we expect a stream of tests to be
> added to the build system in the future, and we hope this project can
> serve as an example of a suitable way of integration.
>
> The patch modifies hotspot code, but it's mostly due to the addition of
> the new dummy tests. My preference would be to integrate this patch via
> jdk9-dev, since it modifies the build system most of all, but I'm open
> for discussion.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8072842
> WebRev:
> http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.01
>
>
> /Magnus


From david.holmes at oracle.com  Wed Feb 11 01:43:41 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Feb 2015 11:43:41 +1000
Subject: Unsafe.park/unpark, j.u.c.LockSupport and Thread
In-Reply-To: <80D63F2C-6A19-4A6A-8AA4-3D8BF048B4D0@oracle.com>
References: <0EF3EAFA-01DF-4577-AD4F-801AD989F639@oracle.com>	<54D9F363.50003@oracle.com>	<17D1013C-EFF5-4AAF-8237-833AF20C3A17@oracle.com>	<B04D882C-ACCF-4278-9D91-1A99D8F50CA1@oracle.com>
	<80D63F2C-6A19-4A6A-8AA4-3D8BF048B4D0@oracle.com>
Message-ID: <54DAB3CD.8030505@oracle.com>

Adding Doug Lea.

On 11/02/2015 12:51 AM, Paul Sandoz wrote:
> On Feb 10, 2015, at 3:39 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>>
>>> Adding native methods to 166 classes will introduce another form of dependency on the platform that i would prefer to avoid.
>>
>> Right. And I suspect that the separate distributable of 166, outside of the Java Platform, would not want to have to carry a separate platform specific native library.
>
> Yes.

Right and for that reason jsr166 distribution would not want to have to 
know whether to use Thread or Unsafe.

>
>>
>>>> But I don't see any reason why we couldn't move the implementation from unsafe.cpp to jvm.cpp and invoke via a native method implementation of LockSupport. It would still be just as "unsafe" of course.
>>>>
>>>
>>> Can you think of any reasons, beyond that of "don't touch the core classes", why we cannot copy this functionality over to java.lang.{*, Thread} ?
>>
>> Would you be thinking of making the changes public, i.e. new standard API on java.lang.Thread ?
>>
>
> Yes, j.l.Thread seems like the ideal location :-)

I don't see any point in moving it to Thread now. The public supported 
API already exists in LockSupport. As I said you'd have to deprecate it 
in 9 with an intent to remove in 10 - assuming you are even allowed to 
do that.

The issue is not LockSupport versus Thread, but the use of Unsafe.

David


> Paul.
>


From david.holmes at oracle.com  Wed Feb 11 01:45:26 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Feb 2015 11:45:26 +1000
Subject: Unsafe.park/unpark, j.u.c.LockSupport and Thread
In-Reply-To: <17D1013C-EFF5-4AAF-8237-833AF20C3A17@oracle.com>
References: <0EF3EAFA-01DF-4577-AD4F-801AD989F639@oracle.com>	<54D9F363.50003@oracle.com>
	<17D1013C-EFF5-4AAF-8237-833AF20C3A17@oracle.com>
Message-ID: <54DAB436.5050501@oracle.com>

On 10/02/2015 10:46 PM, Paul Sandoz wrote:
> Hi David,
>
> On Feb 10, 2015, at 1:02 PM, David Holmes <david.holmes at oracle.com> wrote:
>
>> Hi Paul,
>>
>> When we added j.u.c there was reluctance to add these methods to Thread - this was the normal policy (for the time) of don't touch the core classes. So LockSupport is the public API and Unsafe was chosen as the implementation as it is a de-facto interface to the VM from JDK code rather then defining explicit native methods (I must admit I'm unsure why we went this route rather than simply hooking into jvm.cpp with JVM_park/JVM_unpark. I think in many ways it was/is just easier to call an Unsafe method and define a new unsafe.cpp native call. Plus we had a bunch of other Unsafe API's being used from j.u.c.)
>>
>> So we can't just move things from LockSupport to Thread as we'd need to deprecate first etc etc.
>
> I was thinking that the implementation of LockSupport could be updated to use any new stuff we could add to java.lang.{*, Thread}.
>
> I am trying to tease apart the internal dependencies that 166 classes have on the platform. In the case of LockSupport there are two, Unsafe and Thread.
>
> Adding native methods to 166 classes will introduce another form of dependency on the platform that i would prefer to avoid.
>
>
>> But I don't see any reason why we couldn't move the implementation from unsafe.cpp to jvm.cpp and invoke via a native method implementation of LockSupport. It would still be just as "unsafe" of course.
>>
>
> Can you think of any reasons, beyond that of "don't touch the core classes", why we cannot copy this functionality over to java.lang.{*, Thread} ?
>
>
>> Aside: this is where the infamous "spurious wakeup" from park() can arise. If you just randomly unpark() a Thread there is nothing to guarantee that the thread doesn't terminate and free its native resources while you are working on it. But the ParkEvents are type-stable-memory, so even if the event has been disassociated from the target thread you can still call unpark() as it is never freed. However if that ParkEvent has since been reused by another thread, then that thread will encounter a "spurious wakeup" if it calls park().
>>
>
> I see, and can the same happen for Object.wait as well? I gather so from the documentation.

Spec allows for it but it can't happen for the same reason as unpark() 
as it is based on Object monitors which can't vanish while in use.

David



>
> On Feb 10, 2015, at 1:04 PM, David Holmes <david.holmes at oracle.com> wrote:
>> Oh I just realized/remembered why we use Unsafe for this - it is because of the potential for intrinsics.
>
> I can certainly imagine it's convenient place to put things in that regard.
>
> Paul.
>


From david.holmes at oracle.com  Wed Feb 11 01:46:18 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Feb 2015 11:46:18 +1000
Subject: Unsafe.park/unpark, j.u.c.LockSupport and Thread
In-Reply-To: <54DAB3CD.8030505@oracle.com>
References: <0EF3EAFA-01DF-4577-AD4F-801AD989F639@oracle.com>	<54D9F363.50003@oracle.com>	<17D1013C-EFF5-4AAF-8237-833AF20C3A17@oracle.com>	<B04D882C-ACCF-4278-9D91-1A99D8F50CA1@oracle.com>	<80D63F2C-6A19-4A6A-8AA4-3D8BF048B4D0@oracle.com>
	<54DAB3CD.8030505@oracle.com>
Message-ID: <54DAB46A.6010501@oracle.com>

This time really adding Doug Lea :)

On 11/02/2015 11:43 AM, David Holmes wrote:
> Adding Doug Lea.
>
> On 11/02/2015 12:51 AM, Paul Sandoz wrote:
>> On Feb 10, 2015, at 3:39 PM, Chris Hegarty <chris.hegarty at oracle.com>
>> wrote:
>>>>
>>>> Adding native methods to 166 classes will introduce another form of
>>>> dependency on the platform that i would prefer to avoid.
>>>
>>> Right. And I suspect that the separate distributable of 166, outside
>>> of the Java Platform, would not want to have to carry a separate
>>> platform specific native library.
>>
>> Yes.
>
> Right and for that reason jsr166 distribution would not want to have to
> know whether to use Thread or Unsafe.
>
>>
>>>
>>>>> But I don't see any reason why we couldn't move the implementation
>>>>> from unsafe.cpp to jvm.cpp and invoke via a native method
>>>>> implementation of LockSupport. It would still be just as "unsafe"
>>>>> of course.
>>>>>
>>>>
>>>> Can you think of any reasons, beyond that of "don't touch the core
>>>> classes", why we cannot copy this functionality over to
>>>> java.lang.{*, Thread} ?
>>>
>>> Would you be thinking of making the changes public, i.e. new standard
>>> API on java.lang.Thread ?
>>>
>>
>> Yes, j.l.Thread seems like the ideal location :-)
>
> I don't see any point in moving it to Thread now. The public supported
> API already exists in LockSupport. As I said you'd have to deprecate it
> in 9 with an intent to remove in 10 - assuming you are even allowed to
> do that.
>
> The issue is not LockSupport versus Thread, but the use of Unsafe.
>
> David
>
>
>> Paul.
>>


From magnus.ihse.bursie at oracle.com  Wed Feb 11 08:09:21 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 11 Feb 2015 09:09:21 +0100
Subject: RFR: JDK-8072842 Add support for building native JTReg tests
In-Reply-To: <54DAB1CE.70506@oracle.com>
References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com>
Message-ID: <54DB0E31.3010201@oracle.com>

On 2015-02-11 02:35, David Holmes wrote:
> Hi Magnus,
>
> On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote:
>> Here is an addition to the build system, that will compile native
>> libraries and executables and make them available for JTReg tests
>> written in Java.
>
> Sorry I'm missing the basics here: when does this compilation take 
> place? As part of a normal build? Where will the build artifacts go?

This is the first application of the new test-image/product-images 
separation we discussed previously. :)

These tests are built as part of the "test-image" target. (Actually, 
they are built by individual rules like build-test-jdk-jtreg-native, and 
the relevant parts are put into the test image by 
test-image-jdk-jtreg-native, which test-image depends on.)

The test-image target, as we discussed earlier, are built as part of 
"all" or "all-images", but not the old "images" or "jdk" targets. Also, 
the "test" target depends on "test-image", so you can actually start off 
a complete build by specifying just what tests you want to run. ("test 
driven" from a makefile point of view :-))

The build artifacts go into the new test image, in 
build/$BUILD/images/test, which hitherto has only contained a 
placeholder. For Oracle engineers: This test image is built by default 
by JPRT, and some of the changes in jprt.properties allow JPRT to know 
to depend on that test image to run tests.

/Magnus

>
> Thanks,
> David H.
>
>> This patch is the result of the work (in serial, mostly) of Staffan
>> Larsen, David Simms and me. (And possible more that I don't know about.)
>>
>> In it current form, the patch only provides the framework on which to
>> attach real tests. To prove the concept, some initial dummy tests are
>> present. These are supposed to be removed as soon as real tests starts
>> to propagate into the jdk and hotspot jtreg test suites.
>>
>> The behavior is based on the following design: For directories with
>> native jtreg compilation enabled, the build system searches for native
>> files prefixed with either "lib" or "exe", and compiles a free-standing
>> library or an executable, respectively, for each such file. Since all
>> compiled files are placed in a single directory (this is currently a
>> requirement from the jtreg native support), there is the additional
>> requirement that all files have unique names.
>>
>> My personal opinion is that a better long-term approach is to compile
>> all tests into a single library, if possible. (I realize some tests need
>> to be separate to test library loading, etc.) For that to work, however,
>> JTReg needs to be changed. The build framework in the patch is designed
>> in such a way that it will be easy to add compilation to a common
>> library in the future, if that restriction is lifted from JTReg.
>>
>> This patch also lays the foundation for building additional tests, not
>> only native jtreg tests, by the build system in the future. For
>> instance, it codifies the suggested correspondence between make targets,
>> intermediate test output and test image final build results. With the
>> on-going test co-location project, we expect a stream of tests to be
>> added to the build system in the future, and we hope this project can
>> serve as an example of a suitable way of integration.
>>
>> The patch modifies hotspot code, but it's mostly due to the addition of
>> the new dummy tests. My preference would be to integrate this patch via
>> jdk9-dev, since it modifies the build system most of all, but I'm open
>> for discussion.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8072842
>> WebRev:
>> http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.01 
>>
>>
>>
>> /Magnus



From david.holmes at oracle.com  Wed Feb 11 08:23:17 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Feb 2015 18:23:17 +1000
Subject: RFR: JDK-8072842 Add support for building native JTReg tests
In-Reply-To: <54DB0E31.3010201@oracle.com>
References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com>
	<54DB0E31.3010201@oracle.com>
Message-ID: <54DB1175.6030700@oracle.com>

On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote:
> On 2015-02-11 02:35, David Holmes wrote:
>> Hi Magnus,
>>
>> On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote:
>>> Here is an addition to the build system, that will compile native
>>> libraries and executables and make them available for JTReg tests
>>> written in Java.
>>
>> Sorry I'm missing the basics here: when does this compilation take
>> place? As part of a normal build? Where will the build artifacts go?
>
> This is the first application of the new test-image/product-images
> separation we discussed previously. :)
>
> These tests are built as part of the "test-image" target. (Actually,
> they are built by individual rules like build-test-jdk-jtreg-native, and
> the relevant parts are put into the test image by
> test-image-jdk-jtreg-native, which test-image depends on.)

Okay so if I just cd into hotspot/test and use the Makefile to try and 
run some jtreg tests it looks to me that it will define an invalid 
-nativepath

David
-----

> The test-image target, as we discussed earlier, are built as part of
> "all" or "all-images", but not the old "images" or "jdk" targets. Also,
> the "test" target depends on "test-image", so you can actually start off
> a complete build by specifying just what tests you want to run. ("test
> driven" from a makefile point of view :-))
>
> The build artifacts go into the new test image, in
> build/$BUILD/images/test, which hitherto has only contained a
> placeholder. For Oracle engineers: This test image is built by default
> by JPRT, and some of the changes in jprt.properties allow JPRT to know
> to depend on that test image to run tests.
>
> /Magnus
>
>>
>> Thanks,
>> David H.
>>
>>> This patch is the result of the work (in serial, mostly) of Staffan
>>> Larsen, David Simms and me. (And possible more that I don't know about.)
>>>
>>> In it current form, the patch only provides the framework on which to
>>> attach real tests. To prove the concept, some initial dummy tests are
>>> present. These are supposed to be removed as soon as real tests starts
>>> to propagate into the jdk and hotspot jtreg test suites.
>>>
>>> The behavior is based on the following design: For directories with
>>> native jtreg compilation enabled, the build system searches for native
>>> files prefixed with either "lib" or "exe", and compiles a free-standing
>>> library or an executable, respectively, for each such file. Since all
>>> compiled files are placed in a single directory (this is currently a
>>> requirement from the jtreg native support), there is the additional
>>> requirement that all files have unique names.
>>>
>>> My personal opinion is that a better long-term approach is to compile
>>> all tests into a single library, if possible. (I realize some tests need
>>> to be separate to test library loading, etc.) For that to work, however,
>>> JTReg needs to be changed. The build framework in the patch is designed
>>> in such a way that it will be easy to add compilation to a common
>>> library in the future, if that restriction is lifted from JTReg.
>>>
>>> This patch also lays the foundation for building additional tests, not
>>> only native jtreg tests, by the build system in the future. For
>>> instance, it codifies the suggested correspondence between make targets,
>>> intermediate test output and test image final build results. With the
>>> on-going test co-location project, we expect a stream of tests to be
>>> added to the build system in the future, and we hope this project can
>>> serve as an example of a suitable way of integration.
>>>
>>> The patch modifies hotspot code, but it's mostly due to the addition of
>>> the new dummy tests. My preference would be to integrate this patch via
>>> jdk9-dev, since it modifies the build system most of all, but I'm open
>>> for discussion.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8072842
>>> WebRev:
>>> http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.01
>>>
>>>
>>>
>>> /Magnus
>


From magnus.ihse.bursie at oracle.com  Wed Feb 11 08:27:09 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 11 Feb 2015 09:27:09 +0100
Subject: RFR: JDK-8072842 Add support for building native JTReg tests
In-Reply-To: <54DB1175.6030700@oracle.com>
References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com>
	<54DB0E31.3010201@oracle.com> <54DB1175.6030700@oracle.com>
Message-ID: <54DB125D.2070706@oracle.com>

On 2015-02-11 09:23, David Holmes wrote:
> On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote:
>> On 2015-02-11 02:35, David Holmes wrote:
>>> Hi Magnus,
>>>
>>> On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote:
>>>> Here is an addition to the build system, that will compile native
>>>> libraries and executables and make them available for JTReg tests
>>>> written in Java.
>>>
>>> Sorry I'm missing the basics here: when does this compilation take
>>> place? As part of a normal build? Where will the build artifacts go?
>>
>> This is the first application of the new test-image/product-images
>> separation we discussed previously. :)
>>
>> These tests are built as part of the "test-image" target. (Actually,
>> they are built by individual rules like build-test-jdk-jtreg-native, and
>> the relevant parts are put into the test image by
>> test-image-jdk-jtreg-native, which test-image depends on.)
>
> Okay so if I just cd into hotspot/test and use the Makefile to try and 
> run some jtreg tests it looks to me that it will define an invalid 
> -nativepath

I'm not sure if that is a supported use case. David or Staffan will have 
to answer to that. I have not tested that, only the "whole forest" approach.

/Magnus



From staffan.larsen at oracle.com  Wed Feb 11 08:34:37 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 11 Feb 2015 09:34:37 +0100
Subject: RFR: JDK-8072842 Add support for building native JTReg tests
In-Reply-To: <54DB125D.2070706@oracle.com>
References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com>
	<54DB0E31.3010201@oracle.com> <54DB1175.6030700@oracle.com>
	<54DB125D.2070706@oracle.com>
Message-ID: <F27CF091-29B1-4C22-BDF7-DD1D3469F2BE@oracle.com>


> On 11 feb 2015, at 09:27, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> On 2015-02-11 09:23, David Holmes wrote:
>> On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote:
>>> On 2015-02-11 02:35, David Holmes wrote:
>>>> Hi Magnus,
>>>> 
>>>> On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote:
>>>>> Here is an addition to the build system, that will compile native
>>>>> libraries and executables and make them available for JTReg tests
>>>>> written in Java.
>>>> 
>>>> Sorry I'm missing the basics here: when does this compilation take
>>>> place? As part of a normal build? Where will the build artifacts go?
>>> 
>>> This is the first application of the new test-image/product-images
>>> separation we discussed previously. :)
>>> 
>>> These tests are built as part of the "test-image" target. (Actually,
>>> they are built by individual rules like build-test-jdk-jtreg-native, and
>>> the relevant parts are put into the test image by
>>> test-image-jdk-jtreg-native, which test-image depends on.)
>> 
>> Okay so if I just cd into hotspot/test and use the Makefile to try and run some jtreg tests it looks to me that it will define an invalid -nativepath
> 
> I'm not sure if that is a supported use case. David or Staffan will have to answer to that. I have not tested that, only the "whole forest" approach.

I?ve never done that. I?m always running all make commands from the top level. Is there a problem with that?

/Staffan

> 
> /Magnus



From david.holmes at oracle.com  Wed Feb 11 08:39:04 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Feb 2015 18:39:04 +1000
Subject: RFR: JDK-8072842 Add support for building native JTReg tests
In-Reply-To: <F27CF091-29B1-4C22-BDF7-DD1D3469F2BE@oracle.com>
References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com>
	<54DB0E31.3010201@oracle.com> <54DB1175.6030700@oracle.com>
	<54DB125D.2070706@oracle.com>
	<F27CF091-29B1-4C22-BDF7-DD1D3469F2BE@oracle.com>
Message-ID: <54DB1528.4030708@oracle.com>

On 11/02/2015 6:34 PM, Staffan Larsen wrote:
>
>> On 11 feb 2015, at 09:27, Magnus Ihse Bursie
>> <magnus.ihse.bursie at oracle.com <mailto:magnus.ihse.bursie at oracle.com>>
>> wrote:
>>
>> On 2015-02-11 09:23, David Holmes wrote:
>>> On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote:
>>>> On 2015-02-11 02:35, David Holmes wrote:
>>>>> Hi Magnus,
>>>>>
>>>>> On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote:
>>>>>> Here is an addition to the build system, that will compile native
>>>>>> libraries and executables and make them available for JTReg tests
>>>>>> written in Java.
>>>>>
>>>>> Sorry I'm missing the basics here: when does this compilation take
>>>>> place? As part of a normal build? Where will the build artifacts go?
>>>>
>>>> This is the first application of the new test-image/product-images
>>>> separation we discussed previously. :)
>>>>
>>>> These tests are built as part of the "test-image" target. (Actually,
>>>> they are built by individual rules like build-test-jdk-jtreg-native, and
>>>> the relevant parts are put into the test image by
>>>> test-image-jdk-jtreg-native, which test-image depends on.)
>>>
>>> Okay so if I just cd into hotspot/test and use the Makefile to try
>>> and run some jtreg tests it looks to me that it will define an
>>> invalid -nativepath
>>
>> I'm not sure if that is a supported use case. David or Staffan will
>> have to answer to that. I have not tested that, only the "whole
>> forest" approach.
>
> I?ve never done that. I?m always running all make commands from the top
> level. Is there a problem with that?

I must confess I also haven't done that - though I often run jtreg 
directly from there. Other hotspot engineers may use it. If nothing else 
it would be a way to test out what you expect JPRT to be running.

But perhaps we just don't add the -nativepath component if 
TESTNATIVE_DIR remains unset?

Cheers,
David

> /Staffan
>
>>
>> /Magnus
>


From paul.sandoz at oracle.com  Wed Feb 11 08:52:37 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 11 Feb 2015 09:52:37 +0100
Subject: Unsafe.park/unpark, j.u.c.LockSupport and Thread
In-Reply-To: <54DAB3CD.8030505@oracle.com>
References: <0EF3EAFA-01DF-4577-AD4F-801AD989F639@oracle.com>	<54D9F363.50003@oracle.com>	<17D1013C-EFF5-4AAF-8237-833AF20C3A17@oracle.com>	<B04D882C-ACCF-4278-9D91-1A99D8F50CA1@oracle.com>
	<80D63F2C-6A19-4A6A-8AA4-3D8BF048B4D0@oracle.com>
	<54DAB3CD.8030505@oracle.com>
Message-ID: <3FC30A41-94D0-4EF8-9EFD-728559B34FBE@oracle.com>


On Feb 11, 2015, at 2:43 AM, David Holmes <david.holmes at oracle.com> wrote:

> Adding Doug Lea.
> 
> On 11/02/2015 12:51 AM, Paul Sandoz wrote:
>> On Feb 10, 2015, at 3:39 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>>> 
>>>> Adding native methods to 166 classes will introduce another form of dependency on the platform that i would prefer to avoid.
>>> 
>>> Right. And I suspect that the separate distributable of 166, outside of the Java Platform, would not want to have to carry a separate platform specific native library.
>> 
>> Yes.
> 
> Right and for that reason jsr166 distribution would not want to have to know whether to use Thread or Unsafe.
> 

And that's why it should just be the former for the Java 9 platform and beyond.

The general strategy is to reduce dependency on Unsafe, including for 166 classes. The VarHandles effort is part of that strategy to replace Unsafe enhanced access with a public alternative that is safe and just as performant.


>> 
>>> 
>>>>> But I don't see any reason why we couldn't move the implementation from unsafe.cpp to jvm.cpp and invoke via a native method implementation of LockSupport. It would still be just as "unsafe" of course.
>>>>> 
>>>> 
>>>> Can you think of any reasons, beyond that of "don't touch the core classes", why we cannot copy this functionality over to java.lang.{*, Thread} ?
>>> 
>>> Would you be thinking of making the changes public, i.e. new standard API on java.lang.Thread ?
>>> 
>> 
>> Yes, j.l.Thread seems like the ideal location :-)
> 
> I don't see any point in moving it to Thread now. The public supported API already exists in LockSupport.

Yes, but as i said the point is to tease apart the internal dependencies between the platform and LockSupport class. (A simple solution is to copy and rename this class to java.lang.ThreadSupport :-) .)


> The issue is not LockSupport versus Thread, but the use of Unsafe.
> 

It's because LockSupport uses Unsafe to access non-public fields of Thread, and i also want to break that internal dependency.

I presume that LockSupport was created because agreement was not reached to add such core *thread*-based functionality to Thread. I dunno why such agreement was not reached, but so far i am not hearing any compelling technical reasons.

Paul.

<snip>
> As I said you'd have to deprecate it in 9 with an intent to remove in 10 - assuming you are even allowed to do that.
> 

Opinions differ but i think we should be more serious about removing stuff that has been marked deprecated for one major release if the intent to do so is made clear when deprecating.



From paul.sandoz at oracle.com  Wed Feb 11 09:17:44 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 11 Feb 2015 10:17:44 +0100
Subject: Lexicographic array comparators
In-Reply-To: <804E01BD-C9C7-4ACE-801C-C3E3F05AFFCB@oracle.com>
References: <79B05B7B-CC06-4C6B-A29E-F3242F9EDE34@oracle.com>
	<CA+kOe0_r+__GO8QTRqC8sF86m-G9m9YQZMAhuEXM02feqOkLTA@mail.gmail.com>
	<804E01BD-C9C7-4ACE-801C-C3E3F05AFFCB@oracle.com>
Message-ID: <09623FB6-11A4-42B0-A0DF-4B3082A147FF@oracle.com>

On Feb 11, 2015, at 12:26 AM, John Rose <john.r.rose at oracle.com> wrote:
> On Feb 10, 2015, at 3:15 PM, Martin Buchholz <martinrb at google.com> wrote:
>> 
>> I was surprised that System.arraycopy hasn't been specialized for every
>> array type.
>> I guess the JIT is good at specializing all callers.
> 
> Yes.  Usually the arguments have specific static types the JIT can see.
> The Object formal type doesn't obscure this.
> 
>> I don't know whether we will someday regret the explosion of array
>> comparison methods.
> 
> It's technical debt.  When we go to value types there will be an infinite number of array types.
> That's why in Project Valhalla we are thinking hard, before that, about parametric polymorphism.
> We need to be able to have true polymorphism over APIs in T[], where T can be ref, prim, or value.
> At that point, hopefully, what we have won't be impossible to retrofit.
> 

Yes, i am hoping that many of the overloaded methods on Arrays with the same code shape can be "anyfied" and reduced in a source and binary compatible way. In that respect i feel a less guilty about proposing so many methods :-)

In this case we have the interesting interaction with Comparable: 

  public static <any T extends Comparable<? super T>> int compare(T[] left, T[] right)

We certainly don't want to box for T == int when making comparisons between two ints. I presume, in this case, the intrinsic array match method will deal with that aspect.

--

An alternative solution is to leave Arrays alone and just to go with the lower level System.arrayMismatch method proposed in JDK-8044082 and then wait for value types. However, it requires significantly more work to write an intrinsic, which may put it at risk for the 9 time frame.

Paul.


From paul.sandoz at oracle.com  Wed Feb 11 09:18:57 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 11 Feb 2015 10:18:57 +0100
Subject: Lexicographic array comparators
In-Reply-To: <CA+kOe0_r+__GO8QTRqC8sF86m-G9m9YQZMAhuEXM02feqOkLTA@mail.gmail.com>
References: <79B05B7B-CC06-4C6B-A29E-F3242F9EDE34@oracle.com>
	<CA+kOe0_r+__GO8QTRqC8sF86m-G9m9YQZMAhuEXM02feqOkLTA@mail.gmail.com>
Message-ID: <A2DEAA68-625D-48DE-AD3B-2B282EC7D2FD@oracle.com>

On Feb 11, 2015, at 12:15 AM, Martin Buchholz <martinrb at google.com> wrote:
> The addition of array comparison intrinsics makes sense - I've missed them myself on occasion.
> 

Thanks.


> I was surprised that System.arraycopy hasn't been specialized for every array type.
> I guess the JIT is good at specializing all callers.
> 
> I don't know whether we will someday regret the explosion of array comparison methods.
> The case for the intrinsic seems more compelling to me.
> 
> (Hopefully someone else will do the real review)
> 

No problem. It's too early for a proper webrev review. For the moment i am seeking comments on the general direction.

Thanks,
Paul.


From paul.sandoz at oracle.com  Wed Feb 11 09:54:43 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 11 Feb 2015 10:54:43 +0100
Subject: RFR 8071600: Add a flat-mapping collector
In-Reply-To: <54DA8DFA.1020706@oracle.com>
References: <517DF5B9-E3C5-4CD9-A04A-AC06EBD61517@oracle.com>
	<54DA8DFA.1020706@oracle.com>
Message-ID: <0A906E66-52EF-4777-8951-CB90212178F8@oracle.com>


On Feb 11, 2015, at 12:02 AM, Stuart Marks <stuart.marks at oracle.com> wrote:

> Hi Paul,
> 
> On 2/3/15 5:48 AM, Paul Sandoz wrote:
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping/webrev/
>> 
>> This patch adds a new flat mapping collector to Collectors. This can be useful if one needs to map 0 or more items into a downstream collector.
> 
> Mostly pretty good, just a couple minor nits.
> 
> Re the comment at TabulatorsTest.java line 513, this isn't a two-level groupBy anymore, it's a groupByWithMapping (as the test name indicates).
> 

I removed the comment. I also added the bug id to the test. Updated in place:

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping-test-rename/webrev/


> Given the new tests of closing in FlatMapOpTest.java, is it necessary to have testFlatMappingClose() in TabulatorsTest.java?
> 

Yes, they are testing different code paths.

TabulatorsTest.testFlatMappingClose tests the closing functionality of Collectors.flatMapping:

public static <T, U, A, R>
Collector<T, ?, R> flatMapping(Function<? super T, ? extends Stream<? extends U>> mapper,
                               Collector<? super U, A, R> downstream) {
    BiConsumer<A, ? super U> downstreamAccumulator = downstream.accumulator();
    return new CollectorImpl<>(downstream.supplier(),
                        (r, t) -> {
                            try (Stream<? extends U> result = mapper.apply(t)) {
                                if (result != null)
                                    result.sequential().forEach(u -> downstreamAccumulator.accept(r, u));
                            }
                        },
                        downstream.combiner(), downstream.finisher(),
                        downstream.characteristics());
}

Where as the tests of closing in FlatMapOpTest test the closing of Stream.flatMap*:

@Override
public final <R> Stream<R> flatMap(Function<? super P_OUT, ? extends Stream<? extends R>> mapper) {
    Objects.requireNonNull(mapper);
    // We can do better than this, by polling cancellationRequested when stream is infinite
    return new StatelessOp<P_OUT, R>(this, StreamShape.REFERENCE,
                                 StreamOpFlag.NOT_SORTED | StreamOpFlag.NOT_DISTINCT | StreamOpFlag.NOT_SIZED) {
        @Override
        Sink<P_OUT> opWrapSink(int flags, Sink<R> sink) {
            return new Sink.ChainedReference<P_OUT, R>(sink) {
                @Override
                public void begin(long size) {
                    downstream.begin(-1);
                }

                @Override
                public void accept(P_OUT u) {
                    try (Stream<? extends R> result = mapper.apply(u)) {
                        // We can do better that this too; optimize for depth=0 case and just grab spliterator and forEach it
                        if (result != null)
                            result.sequential().forEach(downstream);
                    }
                }
            };
        }
    };
}


>> A following patch, which i plan to fold into the above patch, performs some renames on the collectors test to be consistent with the current naming:
>> 
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping-test-rename/webrev/
> 
> Renaming looks good and makes it easy to correlate the tests, the assertion classes, and the collector implementations under test. Unfortunately, the word for the act of collecting is "collection" which is confusing since "collection" already has another meaning, but oh well.
> 

Alas :-)

Thanks,
Paul.


From andrey.x.nazarov at oracle.com  Wed Feb 11 10:02:05 2015
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Wed, 11 Feb 2015 13:02:05 +0300
Subject: List.indexOf and List.lastIndexOf lambda version.
Message-ID: <54DB289D.7010009@oracle.com>

Hi everyone,

I there any reason why java.util.List doesn't have lambda versions of 
indexOf and lastIndexOf methods like list.indexOf(Predicate<>) ?

--Thanks, Andrey


From david.holmes at oracle.com  Wed Feb 11 10:04:16 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Feb 2015 20:04:16 +1000
Subject: Unsafe.park/unpark, j.u.c.LockSupport and Thread
In-Reply-To: <3FC30A41-94D0-4EF8-9EFD-728559B34FBE@oracle.com>
References: <0EF3EAFA-01DF-4577-AD4F-801AD989F639@oracle.com>	<54D9F363.50003@oracle.com>	<17D1013C-EFF5-4AAF-8237-833AF20C3A17@oracle.com>	<B04D882C-ACCF-4278-9D91-1A99D8F50CA1@oracle.com>	<80D63F2C-6A19-4A6A-8AA4-3D8BF048B4D0@oracle.com>	<54DAB3CD.8030505@oracle.com>
	<3FC30A41-94D0-4EF8-9EFD-728559B34FBE@oracle.com>
Message-ID: <54DB2920.4060002@oracle.com>

Paul,

I appreciate the issue with discontinuing use of Unsafe but this churn 
to the public APIs seems unwarranted. Would we have done it differently 
from day one? Sure. Does that mean we should change it all now? Not 
without a very good reason. And I'm on the fence there.

The fact that LockSupport needs access to Thread internals is something 
that modules could actually resolve :) - though I'm not up to date on 
the interaction of module access and package access.

Let's see what Doug thinks of all this too.

Cheers,
David

On 11/02/2015 6:52 PM, Paul Sandoz wrote:
>
> On Feb 11, 2015, at 2:43 AM, David Holmes <david.holmes at oracle.com> wrote:
>
>> Adding Doug Lea.
>>
>> On 11/02/2015 12:51 AM, Paul Sandoz wrote:
>>> On Feb 10, 2015, at 3:39 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>>>>
>>>>> Adding native methods to 166 classes will introduce another form of dependency on the platform that i would prefer to avoid.
>>>>
>>>> Right. And I suspect that the separate distributable of 166, outside of the Java Platform, would not want to have to carry a separate platform specific native library.
>>>
>>> Yes.
>>
>> Right and for that reason jsr166 distribution would not want to have to know whether to use Thread or Unsafe.
>>
>
> And that's why it should just be the former for the Java 9 platform and beyond.
>
> The general strategy is to reduce dependency on Unsafe, including for 166 classes. The VarHandles effort is part of that strategy to replace Unsafe enhanced access with a public alternative that is safe and just as performant.
>
>
>>>
>>>>
>>>>>> But I don't see any reason why we couldn't move the implementation from unsafe.cpp to jvm.cpp and invoke via a native method implementation of LockSupport. It would still be just as "unsafe" of course.
>>>>>>
>>>>>
>>>>> Can you think of any reasons, beyond that of "don't touch the core classes", why we cannot copy this functionality over to java.lang.{*, Thread} ?
>>>>
>>>> Would you be thinking of making the changes public, i.e. new standard API on java.lang.Thread ?
>>>>
>>>
>>> Yes, j.l.Thread seems like the ideal location :-)
>>
>> I don't see any point in moving it to Thread now. The public supported API already exists in LockSupport.
>
> Yes, but as i said the point is to tease apart the internal dependencies between the platform and LockSupport class. (A simple solution is to copy and rename this class to java.lang.ThreadSupport :-) .)
>
>
>> The issue is not LockSupport versus Thread, but the use of Unsafe.
>>
>
> It's because LockSupport uses Unsafe to access non-public fields of Thread, and i also want to break that internal dependency.
>
> I presume that LockSupport was created because agreement was not reached to add such core *thread*-based functionality to Thread. I dunno why such agreement was not reached, but so far i am not hearing any compelling technical reasons.
>
> Paul.
>
> <snip>
>> As I said you'd have to deprecate it in 9 with an intent to remove in 10 - assuming you are even allowed to do that.
>>
>
> Opinions differ but i think we should be more serious about removing stuff that has been marked deprecated for one major release if the intent to do so is made clear when deprecating.
>


From paul.sandoz at oracle.com  Wed Feb 11 10:25:32 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 11 Feb 2015 11:25:32 +0100
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <54DAAA15.3080301@oracle.com>
References: <8890A88D-98D4-4F22-A71E-9C29A9F5545B@oracle.com>
	<D23B81AC-3A4A-43CD-879D-D50F4A631741@oracle.com>
	<54DAAA15.3080301@oracle.com>
Message-ID: <05A0E203-F057-4B5B-8C47-0F190CA6D667@oracle.com>

Hi Stuart,

Thanks for the detailed review.

Here is a possible way forward:

1) Add the methods to Matcher, as proposed in the initial webrev.
1.1) Change the specification of Matcher.results to reset the stream before matching, making it consistent with the replace* methods. 

2) Add convenience methods for all replace*() and matches() on Pattern that defer to those on Matcher.

We can do that in two stages, focusing on 1) in this review.

I was not too concerned about the static method and the stream returning method having the same name as the context is quite different. For stream returning methods there is a de-facto pattern of using a plural of the stream element kind, so i prefer that to findAll. What about the name "Pattern.matchResults"? which chains well with "Pattern.match(...).results()".

--

Regarding the disparity between MatchResult and Matcher. I think that would require a new sub-interface of MatchResult from which Matcher extends from and returns. If we think it important we should do that for 9 otherwise we will be stuck for the stream-based methods.

Paul.

On Feb 11, 2015, at 2:02 AM, Stuart Marks <stuart.marks at oracle.com> wrote:

> Hi Paul,
> 
> I spent some time looking at this API. Overall it seems to me that things work a bit more nicely when these methods are added to Pattern instead of Matcher. Unfortunately there are some odd things with the existing API that make this tradeoff not so obvious.
> 
> First, here's what a simple replacement operation looks like when replaceAll() is added to Matcher:
> 
>        String input = "fooaaaabbfooabbbfoo";
>        Pattern p = Pattern.compile("a*b");
>        Matcher m = p.matcher(input);
>        String result = m.replaceAll(mr -> mr.group().toUpperCase());
> 
> But if replaceAll() is on Pattern, we can skip a step:
> 
>        String input = "fooaaaabbfooabbbfoo";
>        Pattern p = Pattern.compile("a*b");
>        String result = p.replaceAll(input, mr -> mr.group().toUpperCase());
> 
> Getting stream of match results is similar. So yes, I agree that it simplifies things to have these be on Pattern instead of Matcher.
> 
> An advantage of having these on Pattern is that the matcher that gets created is encapsulated, and its state isn't exposed to being mucked about by the application. Thus you can avoid the additional concurrent modification checks that you have to do if replaceAll et. al. are on Matcher.
> 
> Unfortunately, putting these on Pattern now creates some difficulties meshing with the existing API.
> 
> One issue is that Matcher already has replaceAll(String) and replaceFirst(String). It would be strange to have these here and to have replaceAll(replacer) and replaceFirst(replacer) on Pattern.
> 
> Another issue is that Matcher supports matching on region (subrange) of its input. For example, today you can do this:
> 
>    pattern.matcher(input).region(start, end)
> 
> The region will constrain the matching for certain operations, such as find() (but not replaceAll or replaceFirst). If something like results() were added to Matcher, I'd expect that it would respect the Matcher's region, but if results() (or matches() as you called it) were on Pattern, the region constraint would be lacking.
> 
> Also note that Pattern already has this:
> 
>    static boolean matches(regex, input)
> 
> so I don't think an overload of matches() that returns a Stream would be a good idea. (Maybe findAll()?)
> 
> Another issue, not directly related to where the new lambda/streams methods get added, is that MatchResult allows references only numbered capturing groups. Matcher, which implements MatchResult, also supports named capturing groups, with the new overloaded methods group(String), start(String), and end(String). These were added in Java 7. Logically these also belong on MatchResult, but they probably weren't added because of the compatibility issue of adding methods to interfaces. Maybe we should add these as default methods to MatchResult.
> 
> (But what would the supported implementation be? Just throw UnsupportedOperationException?)
> 
> --
> 
> I'm not entirely sure where this leaves things. It certainly seems more convenient to have the new methods on Pattern. But given the way the existing API is set up, it seems like it's a better fit to add them to Matcher.
> 
> s'marks
> 
> 
> 
> On 2/9/15 6:18 AM, Paul Sandoz wrote:
>> Here is an alternative that pushes the methods on to Pattern instead:
>> 
>>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/on-Pattern/webrev/
>> 
>> (Whe webrev reports some files as empty, please ingore those, i have this webrev stacked on the previous one.)
>> 
>> I have also included replaceFirst.
>> 
>> This simplifies things for streaming on the match results and also for replacing.
>> 
>> Note that the existing replace* methods on Matcher reset the matcher before matching and indicate that the matcher should be reset afterwards for reuse. Thus there is no loss in functionality moving such lambda accepting methods from Matcher to Pattern. It comes down to the performance of reusing a matcher, which does not seems so compelling to me.
>> 
>> Paul.
>> 
>> On Feb 5, 2015, at 11:59 AM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
>> 
>>> Hi.
>>> 
>>> Please review these stream/lambda enhancements on Matcher:
>>> 
>>>  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/
>>> 
>>> Two new methods are added to Matcher:
>>> 
>>> 1) replaceAll(Function<MatchResult, String> ) that is more flexible than the existing replaceAll that accepts a single value.
>>> 
>>> 2) Stream<MatchResult> results() that returns a stream of MatchResult for all matches.
>>> 
>>> The former does introduce a minor source incompatibility for a null argument, but then so did the new append methods accepting StringBuilder that were recently added (see JDK-8039124).
>>> 
>>> For the latter i opted to place the method on Matcher rather than Pattern as i think that is a better fit with current usages of Matcher and operating on a MatchResult. That marginally increases the complexity since co-modification checking is required.
>>> 
>>> I update the test PatternStreamTest to derive the expected result.
>>> 
>>> 
>>> I suppose i could add another method replaceFirst(Function<MatchResult, String> ) if anyone feels strongly about that. Consistency-wise it seems the right thing to do.
>>> 
>>> Paul.
>> 



From staffan.larsen at oracle.com  Wed Feb 11 10:36:15 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 11 Feb 2015 11:36:15 +0100
Subject: RFR: JDK-8072842 Add support for building native JTReg tests
In-Reply-To: <54DB1528.4030708@oracle.com>
References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com>
	<54DB0E31.3010201@oracle.com> <54DB1175.6030700@oracle.com>
	<54DB125D.2070706@oracle.com>
	<F27CF091-29B1-4C22-BDF7-DD1D3469F2BE@oracle.com>
	<54DB1528.4030708@oracle.com>
Message-ID: <324EF37C-3FD2-4B8A-A509-D7315889D8DE@oracle.com>


> On 11 feb 2015, at 09:39, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 11/02/2015 6:34 PM, Staffan Larsen wrote:
>> 
>>> On 11 feb 2015, at 09:27, Magnus Ihse Bursie
>>> <magnus.ihse.bursie at oracle.com <mailto:magnus.ihse.bursie at oracle.com>>
>>> wrote:
>>> 
>>> On 2015-02-11 09:23, David Holmes wrote:
>>>> On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote:
>>>>> On 2015-02-11 02:35, David Holmes wrote:
>>>>>> Hi Magnus,
>>>>>> 
>>>>>> On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote:
>>>>>>> Here is an addition to the build system, that will compile native
>>>>>>> libraries and executables and make them available for JTReg tests
>>>>>>> written in Java.
>>>>>> 
>>>>>> Sorry I'm missing the basics here: when does this compilation take
>>>>>> place? As part of a normal build? Where will the build artifacts go?
>>>>> 
>>>>> This is the first application of the new test-image/product-images
>>>>> separation we discussed previously. :)
>>>>> 
>>>>> These tests are built as part of the "test-image" target. (Actually,
>>>>> they are built by individual rules like build-test-jdk-jtreg-native, and
>>>>> the relevant parts are put into the test image by
>>>>> test-image-jdk-jtreg-native, which test-image depends on.)
>>>> 
>>>> Okay so if I just cd into hotspot/test and use the Makefile to try
>>>> and run some jtreg tests it looks to me that it will define an
>>>> invalid -nativepath
>>> 
>>> I'm not sure if that is a supported use case. David or Staffan will
>>> have to answer to that. I have not tested that, only the "whole
>>> forest" approach.
>> 
>> I?ve never done that. I?m always running all make commands from the top
>> level. Is there a problem with that?
> 
> I must confess I also haven't done that - though I often run jtreg directly from there. Other hotspot engineers may use it. If nothing else it would be a way to test out what you expect JPRT to be running.
> 
> But perhaps we just don't add the -nativepath component if TESTNATIVE_DIR remains unset?

Not adding -nativepath or adding it with an empty path will lead to the same errors I think: tests that need native code will fail. So it does not really matter.

/Staffan

> 
> Cheers,
> David
> 
>> /Staffan
>> 
>>> 
>>> /Magnus
>> 



From paul.sandoz at oracle.com  Wed Feb 11 10:43:22 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 11 Feb 2015 11:43:22 +0100
Subject: Unsafe.park/unpark, j.u.c.LockSupport and Thread
In-Reply-To: <54DB2920.4060002@oracle.com>
References: <0EF3EAFA-01DF-4577-AD4F-801AD989F639@oracle.com>	<54D9F363.50003@oracle.com>	<17D1013C-EFF5-4AAF-8237-833AF20C3A17@oracle.com>	<B04D882C-ACCF-4278-9D91-1A99D8F50CA1@oracle.com>	<80D63F2C-6A19-4A6A-8AA4-3D8BF048B4D0@oracle.com>	<54DAB3CD.8030505@oracle.com>
	<3FC30A41-94D0-4EF8-9EFD-728559B34FBE@oracle.com>
	<54DB2920.4060002@oracle.com>
Message-ID: <203A0432-47B6-4641-828A-0888E4A99264@oracle.com>


On Feb 11, 2015, at 11:04 AM, David Holmes <david.holmes at oracle.com> wrote:

> Paul,
> 
> I appreciate the issue with discontinuing use of Unsafe but this churn to the public APIs seems unwarranted. Would we have done it differently from day one? Sure. Does that mean we should change it all now? Not without a very good reason. And I'm on the fence there.
> 

Fair enough, i am less conservative than yourself on this matter :-)


> The fact that LockSupport needs access to Thread internals is something that modules could actually resolve :) - though I'm not up to date on the interaction of module access and package access.
> 

In this case 166 is imported into the base module. We don't want modules sitting on top of the platform to depend on internal platform classes, ideally we want to reduce the internal coupling between platform modules (via the use of qualified exports), and ideally the less Unsafe usage within the base module the better.

The particulars of 166 development and usage, in that it gets imported into the platform but also used on top of the platform, make this a tricky balancing act.


> Let's see what Doug thinks of all this too.
> 

Yes.

Paul.


From david.holmes at oracle.com  Wed Feb 11 11:15:14 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Feb 2015 21:15:14 +1000
Subject: RFR: JDK-8072842 Add support for building native JTReg tests
In-Reply-To: <324EF37C-3FD2-4B8A-A509-D7315889D8DE@oracle.com>
References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com>
	<54DB0E31.3010201@oracle.com> <54DB1175.6030700@oracle.com>
	<54DB125D.2070706@oracle.com>
	<F27CF091-29B1-4C22-BDF7-DD1D3469F2BE@oracle.com>
	<54DB1528.4030708@oracle.com>
	<324EF37C-3FD2-4B8A-A509-D7315889D8DE@oracle.com>
Message-ID: <54DB39C2.5010607@oracle.com>

On 11/02/2015 8:36 PM, Staffan Larsen wrote:
>
>> On 11 feb 2015, at 09:39, David Holmes <david.holmes at oracle.com> wrote:
>>
>> On 11/02/2015 6:34 PM, Staffan Larsen wrote:
>>>
>>>> On 11 feb 2015, at 09:27, Magnus Ihse Bursie
>>>> <magnus.ihse.bursie at oracle.com <mailto:magnus.ihse.bursie at oracle.com>>
>>>> wrote:
>>>>
>>>> On 2015-02-11 09:23, David Holmes wrote:
>>>>> On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote:
>>>>>> On 2015-02-11 02:35, David Holmes wrote:
>>>>>>> Hi Magnus,
>>>>>>>
>>>>>>> On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote:
>>>>>>>> Here is an addition to the build system, that will compile native
>>>>>>>> libraries and executables and make them available for JTReg tests
>>>>>>>> written in Java.
>>>>>>>
>>>>>>> Sorry I'm missing the basics here: when does this compilation take
>>>>>>> place? As part of a normal build? Where will the build artifacts go?
>>>>>>
>>>>>> This is the first application of the new test-image/product-images
>>>>>> separation we discussed previously. :)
>>>>>>
>>>>>> These tests are built as part of the "test-image" target. (Actually,
>>>>>> they are built by individual rules like build-test-jdk-jtreg-native, and
>>>>>> the relevant parts are put into the test image by
>>>>>> test-image-jdk-jtreg-native, which test-image depends on.)
>>>>>
>>>>> Okay so if I just cd into hotspot/test and use the Makefile to try
>>>>> and run some jtreg tests it looks to me that it will define an
>>>>> invalid -nativepath
>>>>
>>>> I'm not sure if that is a supported use case. David or Staffan will
>>>> have to answer to that. I have not tested that, only the "whole
>>>> forest" approach.
>>>
>>> I?ve never done that. I?m always running all make commands from the top
>>> level. Is there a problem with that?
>>
>> I must confess I also haven't done that - though I often run jtreg directly from there. Other hotspot engineers may use it. If nothing else it would be a way to test out what you expect JPRT to be running.
>>
>> But perhaps we just don't add the -nativepath component if TESTNATIVE_DIR remains unset?
>
> Not adding -nativepath or adding it with an empty path will lead to the same errors I think: tests that need native code will fail. So it does not really matter.

If you add it with an invalid path (won't be empty as the variable is 
only a prefix) then tests that don't need native code may also fail. 
Though I don't know how jtreg responds to a non-existent nativepath.

David

> /Staffan
>
>>
>> Cheers,
>> David
>>
>>> /Staffan
>>>
>>>>
>>>> /Magnus
>>>
>


From dl at cs.oswego.edu  Wed Feb 11 11:33:05 2015
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 11 Feb 2015 06:33:05 -0500
Subject: Unsafe.park/unpark, j.u.c.LockSupport and Thread
In-Reply-To: <54DAB46A.6010501@oracle.com>
References: <0EF3EAFA-01DF-4577-AD4F-801AD989F639@oracle.com>	<54D9F363.50003@oracle.com>	<17D1013C-EFF5-4AAF-8237-833AF20C3A17@oracle.com>	<B04D882C-ACCF-4278-9D91-1A99D8F50CA1@oracle.com>	<80D63F2C-6A19-4A6A-8AA4-3D8BF048B4D0@oracle.com>
	<54DAB3CD.8030505@oracle.com> <54DAB46A.6010501@oracle.com>
Message-ID: <54DB3DF1.5010409@cs.oswego.edu>

On 02/10/2015 08:46 PM, David Holmes wrote:
> This time really adding Doug Lea :)

I don't have very strong opinions about this. Placing
park/unpark in Thread was our initial (circa 2000)
proposal, so in that sense it's ideal, and in principle
easily done by relaying LockSupport.{park/unpark} to Thread.
But we have over time also exploited the current setup
in a couple of cases to independently deal with Unsafe
access to park and parkBlockers. These can be changed,
although doing so while remaining performance-neutral
will take some thought. (Which is similar to all the
other cases where we'd like to replace Unsafe usages
with VarHandles etc. I'm trying to keep up the attitude
that this is not merely a nuisance, but an opportunity to
revisit and improve implementations :-)

Logistically, we'll somehow cope: At some point our main 166
sources will need to be split into jdk8 vs jdk9 versions.

-Doug

>
> On 11/02/2015 11:43 AM, David Holmes wrote:
>> Adding Doug Lea.
>>
>> On 11/02/2015 12:51 AM, Paul Sandoz wrote:
>>> On Feb 10, 2015, at 3:39 PM, Chris Hegarty <chris.hegarty at oracle.com>
>>> wrote:
>>>>>
>>>>> Adding native methods to 166 classes will introduce another form of
>>>>> dependency on the platform that i would prefer to avoid.
>>>>
>>>> Right. And I suspect that the separate distributable of 166, outside
>>>> of the Java Platform, would not want to have to carry a separate
>>>> platform specific native library.
>>>
>>> Yes.
>>
>> Right and for that reason jsr166 distribution would not want to have to
>> know whether to use Thread or Unsafe.
>>
>>>
>>>>
>>>>>> But I don't see any reason why we couldn't move the implementation
>>>>>> from unsafe.cpp to jvm.cpp and invoke via a native method
>>>>>> implementation of LockSupport. It would still be just as "unsafe"
>>>>>> of course.
>>>>>>
>>>>>
>>>>> Can you think of any reasons, beyond that of "don't touch the core
>>>>> classes", why we cannot copy this functionality over to
>>>>> java.lang.{*, Thread} ?
>>>>
>>>> Would you be thinking of making the changes public, i.e. new standard
>>>> API on java.lang.Thread ?
>>>>
>>>
>>> Yes, j.l.Thread seems like the ideal location :-)
>>
>> I don't see any point in moving it to Thread now. The public supported
>> API already exists in LockSupport. As I said you'd have to deprecate it
>> in 9 with an intent to remove in 10 - assuming you are even allowed to
>> do that.
>>
>> The issue is not LockSupport versus Thread, but the use of Unsafe.
>>
>> David
>>
>>
>>> Paul.
>>>
>



From staffan.larsen at oracle.com  Wed Feb 11 12:08:16 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 11 Feb 2015 13:08:16 +0100
Subject: RFR: JDK-8072842 Add support for building native JTReg tests
In-Reply-To: <54DB39C2.5010607@oracle.com>
References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com>
	<54DB0E31.3010201@oracle.com> <54DB1175.6030700@oracle.com>
	<54DB125D.2070706@oracle.com>
	<F27CF091-29B1-4C22-BDF7-DD1D3469F2BE@oracle.com>
	<54DB1528.4030708@oracle.com>
	<324EF37C-3FD2-4B8A-A509-D7315889D8DE@oracle.com>
	<54DB39C2.5010607@oracle.com>
Message-ID: <31B825DC-DFD2-4EC2-81AD-9BF0FC3364CC@oracle.com>


> On 11 feb 2015, at 12:15, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 11/02/2015 8:36 PM, Staffan Larsen wrote:
>> 
>>> On 11 feb 2015, at 09:39, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> On 11/02/2015 6:34 PM, Staffan Larsen wrote:
>>>> 
>>>>> On 11 feb 2015, at 09:27, Magnus Ihse Bursie
>>>>> <magnus.ihse.bursie at oracle.com <mailto:magnus.ihse.bursie at oracle.com>>
>>>>> wrote:
>>>>> 
>>>>> On 2015-02-11 09:23, David Holmes wrote:
>>>>>> On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote:
>>>>>>> On 2015-02-11 02:35, David Holmes wrote:
>>>>>>>> Hi Magnus,
>>>>>>>> 
>>>>>>>> On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote:
>>>>>>>>> Here is an addition to the build system, that will compile native
>>>>>>>>> libraries and executables and make them available for JTReg tests
>>>>>>>>> written in Java.
>>>>>>>> 
>>>>>>>> Sorry I'm missing the basics here: when does this compilation take
>>>>>>>> place? As part of a normal build? Where will the build artifacts go?
>>>>>>> 
>>>>>>> This is the first application of the new test-image/product-images
>>>>>>> separation we discussed previously. :)
>>>>>>> 
>>>>>>> These tests are built as part of the "test-image" target. (Actually,
>>>>>>> they are built by individual rules like build-test-jdk-jtreg-native, and
>>>>>>> the relevant parts are put into the test image by
>>>>>>> test-image-jdk-jtreg-native, which test-image depends on.)
>>>>>> 
>>>>>> Okay so if I just cd into hotspot/test and use the Makefile to try
>>>>>> and run some jtreg tests it looks to me that it will define an
>>>>>> invalid -nativepath
>>>>> 
>>>>> I'm not sure if that is a supported use case. David or Staffan will
>>>>> have to answer to that. I have not tested that, only the "whole
>>>>> forest" approach.
>>>> 
>>>> I?ve never done that. I?m always running all make commands from the top
>>>> level. Is there a problem with that?
>>> 
>>> I must confess I also haven't done that - though I often run jtreg directly from there. Other hotspot engineers may use it. If nothing else it would be a way to test out what you expect JPRT to be running.
>>> 
>>> But perhaps we just don't add the -nativepath component if TESTNATIVE_DIR remains unset?
>> 
>> Not adding -nativepath or adding it with an empty path will lead to the same errors I think: tests that need native code will fail. So it does not really matter.
> 
> If you add it with an invalid path (won't be empty as the variable is only a prefix) then tests that don't need native code may also fail. Though I don't know how jtreg responds to a non-existent nativepath.

You are right. Jtreg validates the that the path is a directory. So better not to specify it.

/Staffan

> 
> David
> 
>> /Staffan
>> 
>>> 
>>> Cheers,
>>> David
>>> 
>>>> /Staffan
>>>> 
>>>>> 
>>>>> /Magnus



From volker.simonis at gmail.com  Wed Feb 11 13:36:58 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 11 Feb 2015 14:36:58 +0100
Subject: RFR (xs): JDK-8072611: (process) ProcessBuilder redirecting
	output to file should work with long file names (win)
In-Reply-To: <CAA-vtUzWfQQ4KQphZEHgQKDS3zS9Vd=3b=JPJj6xZNMtWVP0xA@mail.gmail.com>
References: <CAA-vtUyefCr13ET1FG=SraAxU9GmpERSuLAr3x73MK0Kj5H2mg@mail.gmail.com>
	<CA+3eh10bp0qEyqWPsa10_2hW3zHvicbpnzvQKzV6QbBje0ZemA@mail.gmail.com>
	<CAA-vtUzWfQQ4KQphZEHgQKDS3zS9Vd=3b=JPJj6xZNMtWVP0xA@mail.gmail.com>
Message-ID: <CA+3eh11=VgefjdRA4wpPXg_=zTmq55A=Ja6mVYqwub5AU1e+9g@mail.gmail.com>

Hi Thomas,

I've just notices that your test has no copyright info and is indented
with an indent width of 2 spaces instead of 4.
If you don't mind I'll fix this before pushing so there's no need for
a new webrev.

Regards,
Volker


On Tue, Feb 10, 2015 at 10:58 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>
> Hi Roger, Volker,
>
> thanks for reviewing!
>
> I added all requested changes:
>
> @Roger
> - use now Files.createTempDirectory to get a unique directory
> - wrapped test in try/finally to cleanup afterwards
> @Volker
> - moved include up and added dependency to comment in io_util_md.h
> - Now I use hostname.exe, which I hope is part of every Windows :)
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8072611/webrev.02/webrev/
>
> Regards, Thomas
>
>
> On Mon, Feb 9, 2015 at 7:48 PM, Volker Simonis <volker.simonis at gmail.com>
> wrote:
>>
>> Hi Thomas,
>>
>> the change looks good and I can sponsor it once it is reviewed.
>>
>> Just some small notes:
>>
>> - it seems that "getPath()" isn't used anywhere else in
>> ProcessImpl_md.c and because it is static it can't be used anywhere
>> else. So can you please remove it completely.
>>
>> - io_util_md.h has a list of files which use the prototypes like
>> "pathToNTPath" before the declaration of the prototypes. Could you
>> please also add ProcessImpl_md.c to this list
>>
>> - can you pleae place the new include in ProcessImpl_md.c as follows:
>>
>>  #include "io_util.h"
>> +#include "io_util_md.h"
>>  #include <windows.h>
>>  #include <io.h>
>>
>> I saw that system and local headers are already intermixed in that
>> file but at I think at least we shouldn't introduce more disorder.
>>
>> - is "robocopy" really available on all supported Windows system. In
>> http://en.wikipedia.org/wiki/Robocopy I read that it was introduced in
>> Server 2008. I just verified that Java 8 only supports Server 2008 and
>> above but just think of our internal test system:) Maybe we can use a
>> program which is supported in every Windows version?
>>
>> Regards,
>> Volker
>>
>>
>> On Mon, Feb 9, 2015 at 2:30 PM, Thomas St?fe <thomas.stuefe at gmail.com>
>> wrote:
>> > Hi all,
>> >
>> > please review this small change at your convenience:
>> >
>> > http://cr.openjdk.java.net/~stuefe/webrevs/8072611/webrev.01/webrev/
>> >
>> > It fixes a small issue which causes ProcessBuilder not to be able to
>> > open
>> > files to redirect into (when using Redirect.append) on windows, if that
>> > file name is longer than 255 chars.
>> >
>> > Kind Regards, Thomas Stuefe
>
>


From thomas.stuefe at gmail.com  Wed Feb 11 14:39:43 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 11 Feb 2015 15:39:43 +0100
Subject: RFR (xs): JDK-8072611: (process) ProcessBuilder redirecting
	output to file should work with long file names (win)
In-Reply-To: <CA+3eh11=VgefjdRA4wpPXg_=zTmq55A=Ja6mVYqwub5AU1e+9g@mail.gmail.com>
References: <CAA-vtUyefCr13ET1FG=SraAxU9GmpERSuLAr3x73MK0Kj5H2mg@mail.gmail.com>
	<CA+3eh10bp0qEyqWPsa10_2hW3zHvicbpnzvQKzV6QbBje0ZemA@mail.gmail.com>
	<CAA-vtUzWfQQ4KQphZEHgQKDS3zS9Vd=3b=JPJj6xZNMtWVP0xA@mail.gmail.com>
	<CA+3eh11=VgefjdRA4wpPXg_=zTmq55A=Ja6mVYqwub5AU1e+9g@mail.gmail.com>
Message-ID: <CAA-vtUw_1i5BJSrxGcLWtQrE+HAqG9F6+ZM=paDPoG5SHy8JUA@mail.gmail.com>

Thank you Volker :)

On Wed, Feb 11, 2015 at 2:36 PM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> Hi Thomas,
>
> I've just notices that your test has no copyright info and is indented
> with an indent width of 2 spaces instead of 4.
> If you don't mind I'll fix this before pushing so there's no need for
> a new webrev.
>
> Regards,
> Volker
>
>
> On Tue, Feb 10, 2015 at 10:58 AM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
> >
> > Hi Roger, Volker,
> >
> > thanks for reviewing!
> >
> > I added all requested changes:
> >
> > @Roger
> > - use now Files.createTempDirectory to get a unique directory
> > - wrapped test in try/finally to cleanup afterwards
> > @Volker
> > - moved include up and added dependency to comment in io_util_md.h
> > - Now I use hostname.exe, which I hope is part of every Windows :)
> >
> > http://cr.openjdk.java.net/~stuefe/webrevs/8072611/webrev.02/webrev/
> >
> > Regards, Thomas
> >
> >
> > On Mon, Feb 9, 2015 at 7:48 PM, Volker Simonis <volker.simonis at gmail.com
> >
> > wrote:
> >>
> >> Hi Thomas,
> >>
> >> the change looks good and I can sponsor it once it is reviewed.
> >>
> >> Just some small notes:
> >>
> >> - it seems that "getPath()" isn't used anywhere else in
> >> ProcessImpl_md.c and because it is static it can't be used anywhere
> >> else. So can you please remove it completely.
> >>
> >> - io_util_md.h has a list of files which use the prototypes like
> >> "pathToNTPath" before the declaration of the prototypes. Could you
> >> please also add ProcessImpl_md.c to this list
> >>
> >> - can you pleae place the new include in ProcessImpl_md.c as follows:
> >>
> >>  #include "io_util.h"
> >> +#include "io_util_md.h"
> >>  #include <windows.h>
> >>  #include <io.h>
> >>
> >> I saw that system and local headers are already intermixed in that
> >> file but at I think at least we shouldn't introduce more disorder.
> >>
> >> - is "robocopy" really available on all supported Windows system. In
> >> http://en.wikipedia.org/wiki/Robocopy I read that it was introduced in
> >> Server 2008. I just verified that Java 8 only supports Server 2008 and
> >> above but just think of our internal test system:) Maybe we can use a
> >> program which is supported in every Windows version?
> >>
> >> Regards,
> >> Volker
> >>
> >>
> >> On Mon, Feb 9, 2015 at 2:30 PM, Thomas St?fe <thomas.stuefe at gmail.com>
> >> wrote:
> >> > Hi all,
> >> >
> >> > please review this small change at your convenience:
> >> >
> >> > http://cr.openjdk.java.net/~stuefe/webrevs/8072611/webrev.01/webrev/
> >> >
> >> > It fixes a small issue which causes ProcessBuilder not to be able to
> >> > open
> >> > files to redirect into (when using Redirect.append) on windows, if
> that
> >> > file name is longer than 255 chars.
> >> >
> >> > Kind Regards, Thomas Stuefe
> >
> >
>


From Roger.Riggs at Oracle.com  Wed Feb 11 15:03:26 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 11 Feb 2015 10:03:26 -0500
Subject: [9] 8064562: (doc) errors in java.io.PushbackInputStream API
	documentation
In-Reply-To: <1E780C93-DB74-4013-A35C-59B385B0F223@oracle.com>
References: <1E780C93-DB74-4013-A35C-59B385B0F223@oracle.com>
Message-ID: <54DB6F3E.5070306@Oracle.com>

Hi Brian,

Looks good.

Thanks, Roger

On 2/10/2015 7:06 PM, Brian Burkhalter wrote:
> Please review at your convenience.
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8064562
> Patch:	http://cr.openjdk.java.net/~bpb/8064562/webrev.00/
>
> Thanks,
>
> Brian



From lance.andersen at oracle.com  Wed Feb 11 15:08:47 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 11 Feb 2015 10:08:47 -0500
Subject: [9] 8064562: (doc) errors in java.io.PushbackInputStream API
	documentation
In-Reply-To: <1E780C93-DB74-4013-A35C-59B385B0F223@oracle.com>
References: <1E780C93-DB74-4013-A35C-59B385B0F223@oracle.com>
Message-ID: <BC49389C-4A8D-43ED-88EF-EEF393844389@oracle.com>

looks fine brian, the bug did a good job of explaining the issues.

Best
Lance
On Feb 10, 2015, at 7:06 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> Please review at your convenience.
> 
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8064562
> Patch:	http://cr.openjdk.java.net/~bpb/8064562/webrev.00/
> 
> Thanks,
> 
> Brian



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





From brian.burkhalter at oracle.com  Wed Feb 11 15:23:23 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 11 Feb 2015 07:23:23 -0800
Subject: [9] 8064562: (doc) errors in java.io.PushbackInputStream API
	documentation
In-Reply-To: <BC49389C-4A8D-43ED-88EF-EEF393844389@oracle.com>
References: <1E780C93-DB74-4013-A35C-59B385B0F223@oracle.com>
	<BC49389C-4A8D-43ED-88EF-EEF393844389@oracle.com>
Message-ID: <626359BC-666D-4115-86B5-7209C961AB0D@oracle.com>

Thanks, Lance,

Indeed, I was merely the amanuensis, or more precisely, the scribe. ;-)

Cheers,

Brian

On Feb 11, 2015, at 7:08 AM, Lance Andersen <lance.andersen at oracle.com> wrote:

> looks fine brian, the bug did a good job of explaining the issues.



From brian.burkhalter at oracle.com  Wed Feb 11 15:23:56 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 11 Feb 2015 07:23:56 -0800
Subject: [9] 8064562: (doc) errors in java.io.PushbackInputStream API
	documentation
In-Reply-To: <54DB6F3E.5070306@Oracle.com>
References: <1E780C93-DB74-4013-A35C-59B385B0F223@oracle.com>
	<54DB6F3E.5070306@Oracle.com>
Message-ID: <3E3612CE-D900-4989-B9F2-CCAA36DBD3A8@oracle.com>

Thanks, Roger.

On Feb 11, 2015, at 7:03 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi Brian,
> 
> Looks good.
> 
> Thanks, Roger
> 
> On 2/10/2015 7:06 PM, Brian Burkhalter wrote:
>> Please review at your convenience.
>> 
>> Issue:	https://bugs.openjdk.java.net/browse/JDK-8064562
>> Patch:	http://cr.openjdk.java.net/~bpb/8064562/webrev.00/
>> 
>> Thanks,
>> 
>> Brian
> 



From xueming.shen at oracle.com  Wed Feb 11 15:54:59 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 11 Feb 2015 07:54:59 -0800
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <05A0E203-F057-4B5B-8C47-0F190CA6D667@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>
Message-ID: <54DB7B53.1000202@oracle.com>

Hi

It might be more consistent with the existing design to add those 
methods into Matcher. I agree the
better name for the "stream return" method is "findAll".

-sherman


On 2/11/15 2:25 AM, Paul Sandoz wrote:
> Hi Stuart,
>
> Thanks for the detailed review.
>
> Here is a possible way forward:
>
> 1) Add the methods to Matcher, as proposed in the initial webrev.
> 1.1) Change the specification of Matcher.results to reset the stream before matching, making it consistent with the replace* methods.
>
> 2) Add convenience methods for all replace*() and matches() on Pattern that defer to those on Matcher.
>
> We can do that in two stages, focusing on 1) in this review.
>
> I was not too concerned about the static method and the stream returning method having the same name as the context is quite different. For stream returning methods there is a de-facto pattern of using a plural of the stream element kind, so i prefer that to findAll. What about the name "Pattern.matchResults"? which chains well with "Pattern.match(...).results()".
>
> --
>
> Regarding the disparity between MatchResult and Matcher. I think that would require a new sub-interface of MatchResult from which Matcher extends from and returns. If we think it important we should do that for 9 otherwise we will be stuck for the stream-based methods.
>
> Paul.
>
> On Feb 11, 2015, at 2:02 AM, Stuart Marks <stuart.marks at oracle.com> wrote:
>
>> Hi Paul,
>>
>> I spent some time looking at this API. Overall it seems to me that things work a bit more nicely when these methods are added to Pattern instead of Matcher. Unfortunately there are some odd things with the existing API that make this tradeoff not so obvious.
>>
>> First, here's what a simple replacement operation looks like when replaceAll() is added to Matcher:
>>
>>         String input = "fooaaaabbfooabbbfoo";
>>         Pattern p = Pattern.compile("a*b");
>>         Matcher m = p.matcher(input);
>>         String result = m.replaceAll(mr -> mr.group().toUpperCase());
>>
>> But if replaceAll() is on Pattern, we can skip a step:
>>
>>         String input = "fooaaaabbfooabbbfoo";
>>         Pattern p = Pattern.compile("a*b");
>>         String result = p.replaceAll(input, mr -> mr.group().toUpperCase());
>>
>> Getting stream of match results is similar. So yes, I agree that it simplifies things to have these be on Pattern instead of Matcher.
>>
>> An advantage of having these on Pattern is that the matcher that gets created is encapsulated, and its state isn't exposed to being mucked about by the application. Thus you can avoid the additional concurrent modification checks that you have to do if replaceAll et. al. are on Matcher.
>>
>> Unfortunately, putting these on Pattern now creates some difficulties meshing with the existing API.
>>
>> One issue is that Matcher already has replaceAll(String) and replaceFirst(String). It would be strange to have these here and to have replaceAll(replacer) and replaceFirst(replacer) on Pattern.
>>
>> Another issue is that Matcher supports matching on region (subrange) of its input. For example, today you can do this:
>>
>>     pattern.matcher(input).region(start, end)
>>
>> The region will constrain the matching for certain operations, such as find() (but not replaceAll or replaceFirst). If something like results() were added to Matcher, I'd expect that it would respect the Matcher's region, but if results() (or matches() as you called it) were on Pattern, the region constraint would be lacking.
>>
>> Also note that Pattern already has this:
>>
>>     static boolean matches(regex, input)
>>
>> so I don't think an overload of matches() that returns a Stream would be a good idea. (Maybe findAll()?)
>>
>> Another issue, not directly related to where the new lambda/streams methods get added, is that MatchResult allows references only numbered capturing groups. Matcher, which implements MatchResult, also supports named capturing groups, with the new overloaded methods group(String), start(String), and end(String). These were added in Java 7. Logically these also belong on MatchResult, but they probably weren't added because of the compatibility issue of adding methods to interfaces. Maybe we should add these as default methods to MatchResult.
>>
>> (But what would the supported implementation be? Just throw UnsupportedOperationException?)
>>
>> --
>>
>> I'm not entirely sure where this leaves things. It certainly seems more convenient to have the new methods on Pattern. But given the way the existing API is set up, it seems like it's a better fit to add them to Matcher.
>>
>> s'marks
>>
>>
>>
>> On 2/9/15 6:18 AM, Paul Sandoz wrote:
>>> Here is an alternative that pushes the methods on to Pattern instead:
>>>
>>>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/on-Pattern/webrev/
>>>
>>> (Whe webrev reports some files as empty, please ingore those, i have this webrev stacked on the previous one.)
>>>
>>> I have also included replaceFirst.
>>>
>>> This simplifies things for streaming on the match results and also for replacing.
>>>
>>> Note that the existing replace* methods on Matcher reset the matcher before matching and indicate that the matcher should be reset afterwards for reuse. Thus there is no loss in functionality moving such lambda accepting methods from Matcher to Pattern. It comes down to the performance of reusing a matcher, which does not seems so compelling to me.
>>>
>>> Paul.
>>>
>>> On Feb 5, 2015, at 11:59 AM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
>>>
>>>> Hi.
>>>>
>>>> Please review these stream/lambda enhancements on Matcher:
>>>>
>>>>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/
>>>>
>>>> Two new methods are added to Matcher:
>>>>
>>>> 1) replaceAll(Function<MatchResult, String> ) that is more flexible than the existing replaceAll that accepts a single value.
>>>>
>>>> 2) Stream<MatchResult> results() that returns a stream of MatchResult for all matches.
>>>>
>>>> The former does introduce a minor source incompatibility for a null argument, but then so did the new append methods accepting StringBuilder that were recently added (see JDK-8039124).
>>>>
>>>> For the latter i opted to place the method on Matcher rather than Pattern as i think that is a better fit with current usages of Matcher and operating on a MatchResult. That marginally increases the complexity since co-modification checking is required.
>>>>
>>>> I update the test PatternStreamTest to derive the expected result.
>>>>
>>>>
>>>> I suppose i could add another method replaceFirst(Function<MatchResult, String> ) if anyone feels strongly about that. Consistency-wise it seems the right thing to do.
>>>>
>>>> Paul.



From aleksej.efimov at oracle.com  Wed Feb 11 16:20:31 2015
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Wed, 11 Feb 2015 19:20:31 +0300
Subject: RFR: 8071585: Update JAX-WS RI integration to latest version
	(2.2.11-b150127.1410)
In-Reply-To: <54CF556C.10908@oracle.com>
References: <54CA48E0.8030902@oracle.com> <54CA4C81.301@oracle.com>
	<54CF556C.10908@oracle.com>
Message-ID: <54DB814F.1020904@oracle.com>

Hi Alan, Miran,
If I understood correctly we can fix "&gt;" in the next bulk update (in 
early March). If it's so, can I have an approval for this fix?

Thank you,
Aleksej

On 02/02/2015 01:46 PM, Miroslav Kos wrote:
> On 29/01/15 16:06, Alan Bateman wrote:
>> On 29/01/2015 14:51, Aleksej Efimov wrote:
>>> Hi,
>>> Can I have a review for a bulk update of JAX-B/WS from upstream 
>>> projects -
>>> webrev: http://cr.openjdk.java.net/~aefimov/8071585/webrev/
>>> more details in JBS: https://bugs.openjdk.java.net/browse/JDK-8071585
>>>
>>> There is a lot of changes (947 lines) but almost all of them are 
>>> minor (comments changes/(c) years)
>>>
>>> Thank you,
>>> Aleksej
>>>
>> I see several changes where ">"is replaced by "&gt;" in pre-formatted 
>> text (looks like < was changed to &lt; at some point in the past).
> Hi Alan, thanks for catching this, we'll fix that. Is it ok to fix it 
> in the next (in a month) bulk update?
>
> Miran
>>
>> This is probably a question for the upstream projects but I would 
>> think <pre>{@code ..}</pre> would make the source much easier to read.
>>
>> -Alan.
>>
>



From lev.priima at oracle.com  Wed Feb 11 16:29:13 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Wed, 11 Feb 2015 19:29:13 +0300
Subject: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on arrays
	longer than 1073741824
Message-ID: <54DB8359.2020803@oracle.com>

Hi,

Stack length increased previously by JDK-8011944 was insufficient for 
some cases.
Please review and push:
webrev: http://cr.openjdk.java.net/~lpriima/8072909/webrev.00/
issue: https://bugs.openjdk.java.net/browse/JDK-8072909

-- 
Lev



From Alan.Bateman at oracle.com  Wed Feb 11 16:45:52 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Feb 2015 16:45:52 +0000
Subject: RFR: 8071585: Update JAX-WS RI integration to latest version
	(2.2.11-b150127.1410)
In-Reply-To: <54DB814F.1020904@oracle.com>
References: <54CA48E0.8030902@oracle.com> <54CA4C81.301@oracle.com>
	<54CF556C.10908@oracle.com> <54DB814F.1020904@oracle.com>
Message-ID: <54DB8740.4070303@oracle.com>

On 11/02/2015 16:20, Aleksej Efimov wrote:
> Hi Alan, Miran,
> If I understood correctly we can fix "&gt;" in the next bulk update 
> (in early March). If it's so, can I have an approval for this fix?
>
> Thank you,
> Aleksej
Yes, fixing at the next sync up is fine (I didn't realize my mail was 
holding this up, apologies!).

-Alan



From Roger.Riggs at Oracle.com  Wed Feb 11 17:32:54 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 11 Feb 2015 12:32:54 -0500
Subject: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on
	arrays longer than 1073741824
In-Reply-To: <54DB8359.2020803@oracle.com>
References: <54DB8359.2020803@oracle.com>
Message-ID: <54DB9246.3000206@Oracle.com>

Hi Lev,

The fix looks fine.

Did you consider the improvements suggested in the paper to reestablish 
the invariant?

Roger

On 2/11/2015 11:29 AM, Lev Priima wrote:
> Hi,
>
> Stack length increased previously by JDK-8011944 was insufficient for 
> some cases.
> Please review and push:
> webrev: http://cr.openjdk.java.net/~lpriima/8072909/webrev.00/
> issue: https://bugs.openjdk.java.net/browse/JDK-8072909
>



From Roger.Riggs at Oracle.com  Wed Feb 11 17:55:06 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 11 Feb 2015 12:55:06 -0500
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <CACzrW9B=KFAvOXE0+KzVPsXz-G=Kg=LtXES+acqNQuVJq=QPdg@mail.gmail.com>
References: <54D941D1.8000305@Oracle.com> <54D94665.8020906@redhat.com>
	<CACzrW9B=KFAvOXE0+KzVPsXz-G=Kg=LtXES+acqNQuVJq=QPdg@mail.gmail.com>
Message-ID: <54DB977A.7090303@Oracle.com>

Thanks for the suggestions and confirmation that Duration is not a misuse
of that type for this purpose.

Roger


On 2/10/2015 2:38 AM, Stephen Colebourne wrote:
> On 9 February 2015 at 23:44, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> ProcessHandle.Info provides a startTime and totalTime.  But it seems odd and
>> inconsistent that startTime is an Instant, yet totalTime is a raw long as
>> opposed to the arguably more consistent Duration.  Is there a reason you
>> went with a raw long for this property?
> I think using Duration would be OK here, even though the CPU time was
> used up in a discontinuous manner. The returned value is, in essence,
> a sum of many smaller durations.
>
> I'd also suggest adjusting the two method names:
> startTime() -> startInstant()
> totalTime() -> totalCpuDuration()
>
> Those communicate the intent more clearly IMO.
>
> Stephen



From Roger.Riggs at Oracle.com  Wed Feb 11 18:53:39 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 11 Feb 2015 13:53:39 -0500
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54DA04D4.1060108@redhat.com>
References: <54D941D1.8000305@Oracle.com>
	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>
	<54DA04D4.1060108@redhat.com>
Message-ID: <54DBA533.8080802@Oracle.com>

Hi David,

Thanks for the suggestion:

"Forcible process destruction is defined as the immediate termination of 
a process, whereas regular destruction allows a process to shut down 
cleanly."

It is very OS and application specific as to how and if an application 
does cleanly exit
but adding qualifications would make it less readable.

Roger


On 2/10/2015 8:17 AM, David M. Lloyd wrote:
> On 02/09/2015 07:52 PM, Roger Riggs wrote:
>> On 2/9/15 6:44 PM, David M. Lloyd wrote:
>>> Also, as a general comment, there isn't really a good explanation as
>>> to what the difference is between a normal destroy and a forcible
>>> destroy.  Given that you've added an isDestroyForcible() method, I
>>> think it might be a good idea to explain what it means when this
>>> method returns true.  There must be some criteria in the
>>> implementation to return true here, so at the least, that criteria
>>> should be explained.  Also the destroy() method now has the odd
>>> characteristic that its implementation *may* forcibly destroy a
>>> process, but you can't really determine that from the API at all.
>>
>> From an implementation perspective, for Unix it is the distinction
>> between SIGTERM and SIGKILL;one is allowed/expected to be caught and 
>> handled by the application for
>> a clean shutdown,the other is not interceptable. But the OS 
>> variations and caveats make 
> it hard to write anything more
>> than an informative statement.
>
> Understood, but I'm thinking that such a statement should be added; 
> something along the lines of "Forcible process destruction is defined 
> as the immediate termination of a process, whereas regular destruction 
> allows a process to shut down cleanly."  This gives a clear criterion 
> as to what it means when isDestroyForcible returns true, since each of 
> these behaviors (at least on Unix) are readily identified with SIGKILL 
> and SIGTERM.
>
> Upon rereading the API I see that isDestroyForcible() actually 
> reflects the behavior of destroy(), which is opposite of my original 
> reading of it, and that clarifies things a bit.  But there is still no 
> way in the API to know if forcible process termination is supported; 
> can it be assumed that it is supported on all platforms?
>
>> The descriptions are copied from Process, which previously did not offer
>> an explanation.
>



From lev.priima at oracle.com  Wed Feb 11 19:14:52 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Wed, 11 Feb 2015 22:14:52 +0300
Subject: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on
	arrays longer than 1073741824
In-Reply-To: <54DB9246.3000206@Oracle.com>
References: <54DB8359.2020803@oracle.com> <54DB9246.3000206@Oracle.com>
Message-ID: <54DBAA2C.6050307@oracle.com>

Just briefly looked at it, w/o evaluating formal proof. But original 
Python implementation(written on C) works on stack size even more 
simple, AFAIU it:

/* The maximum number of entries in a MergeState's pending-runs stack.
  * This is enough to sort arrays of size up to about
  *     32 * phi ** MAX_MERGE_PENDING
  * where phi ~= 1.618.  85 is ridiculouslylarge enough, good for an array
  * with 2**64 elements.
  */
#define MAX_MERGE_PENDING 85

Lev

On 02/11/2015 08:32 PM, Roger Riggs wrote:
> Hi Lev,
>
> The fix looks fine.
>
> Did you consider the improvements suggested in the paper to 
> reestablish the invariant?
>
> Roger
>
> On 2/11/2015 11:29 AM, Lev Priima wrote:
>> Hi,
>>
>> Stack length increased previously by JDK-8011944 was insufficient for 
>> some cases.
>> Please review and push:
>> webrev: http://cr.openjdk.java.net/~lpriima/8072909/webrev.00/
>> issue: https://bugs.openjdk.java.net/browse/JDK-8072909
>>
>



From stuart.marks at oracle.com  Wed Feb 11 19:23:33 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 11 Feb 2015 11:23:33 -0800
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <05A0E203-F057-4B5B-8C47-0F190CA6D667@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>
Message-ID: <54DBAC35.1060903@oracle.com>

On 2/11/15 2:25 AM, Paul Sandoz wrote:
> Hi Stuart,
>
> Thanks for the detailed review.
>
> Here is a possible way forward:
>
> 1) Add the methods to Matcher, as proposed in the initial webrev.

Yes, I think this is the way to go, and it seems that Sherman concurs.

> 1.1) Change the specification of Matcher.results to reset the stream before matching, making it consistent with the replace* methods.

I'm not sure about this. The current replaceAll/replaceFirst methods reset the 
matcher before doing any matching, so the lambda-based overloads should do the same.

However, the model for

     Stream<MatchResult> results()

seems to me to be a stream of matches that would be returned by successive calls 
to find(). (Indeed, that's how it's implemented.) The no-arg find() call doesn't 
reset the Matcher, and it respects the existing region of the Matcher. I think 
results() should do the same.

Now there's also a find(int start) overload that does reset the matcher 
(discarding the region) but starts at the given position. This suggests another 
overload,

     Stream<MatchResult> results(int start)

which also resets the matcher. I don't think this is necessary, though, since I 
believe the equivalent effect can be achieved by setting the region before 
calling the no-arg results() -- as long as it doesn't reset the matcher.

No matter what, I think results() will have to check for concurrent 
modification. It seems to be in the nature of this API, sigh.

By the way, I think Matcher.results() is a fine name. The overload of 
Pattern.matches() is what bothers me.

> 2) Add convenience methods for all replace*() and matches() on Pattern that defer to those on Matcher.

I'm not sure convenience methods are necessary. After all, there are the 
existing replaceFirst/replaceAll methods on Matcher that aren't on Pattern.

In addition, if you don't need to hang onto the Pattern or Matcher instances, my 
example from earlier can be compressed to:

     String result = Pattern.compile("a*b")
         .matcher(input).replaceAll(mr -> mr.group().toUpperCase());

which ain't too bad.


> We can do that in two stages, focusing on 1) in this review.

Yes.

> I was not too concerned about the static method and the stream returning method having the same name as the context is quite different. For stream returning methods there is a de-facto pattern of using a plural of the stream element kind, so i prefer that to findAll. What about the name "Pattern.matchResults"? which chains well with "Pattern.match(...).results()".
>
> --
>
> Regarding the disparity between MatchResult and Matcher. I think that would require a new sub-interface of MatchResult from which Matcher extends from and returns. If we think it important we should do that for 9 otherwise we will be stuck for the stream-based methods.

Why do you think we need a new sub-interface? Wouldn't it be sufficient to add 
default methods?

There is of course the possibility of existing 3rd party classes that implement 
MatchResult having conflicting methods. But I don't think MatchResult is 
implemented quite as often as the collection interfaces, where we've been 
reticent to add default methods because of so many implementations.

I did a quick web search and I did find a few implementations/extensions of 
MatchResult, but there were no obvious conflicts. This isn't definitive, of course.

The default implementations of group(String), start(String), and end(String) 
could throw IllegalArgumentException, since that's what the ones on Matcher do 
if there's no such named capture group.

I admit this is a little weird, since it's only safe to use these new methods if 
you know where the MatchResult instance came from. So logically perhaps it's a 
different type. My hunch, though, is that MatchResults aren't passed around, 
they're created from Patterns/Matchers and processed within the same code, so in 
practice this won't be a problem.

s'marks


> Paul.
>
> On Feb 11, 2015, at 2:02 AM, Stuart Marks <stuart.marks at oracle.com> wrote:
>
>> Hi Paul,
>>
>> I spent some time looking at this API. Overall it seems to me that things work a bit more nicely when these methods are added to Pattern instead of Matcher. Unfortunately there are some odd things with the existing API that make this tradeoff not so obvious.
>>
>> First, here's what a simple replacement operation looks like when replaceAll() is added to Matcher:
>>
>>         String input = "fooaaaabbfooabbbfoo";
>>         Pattern p = Pattern.compile("a*b");
>>         Matcher m = p.matcher(input);
>>         String result = m.replaceAll(mr -> mr.group().toUpperCase());
>>
>> But if replaceAll() is on Pattern, we can skip a step:
>>
>>         String input = "fooaaaabbfooabbbfoo";
>>         Pattern p = Pattern.compile("a*b");
>>         String result = p.replaceAll(input, mr -> mr.group().toUpperCase());
>>
>> Getting stream of match results is similar. So yes, I agree that it simplifies things to have these be on Pattern instead of Matcher.
>>
>> An advantage of having these on Pattern is that the matcher that gets created is encapsulated, and its state isn't exposed to being mucked about by the application. Thus you can avoid the additional concurrent modification checks that you have to do if replaceAll et. al. are on Matcher.
>>
>> Unfortunately, putting these on Pattern now creates some difficulties meshing with the existing API.
>>
>> One issue is that Matcher already has replaceAll(String) and replaceFirst(String). It would be strange to have these here and to have replaceAll(replacer) and replaceFirst(replacer) on Pattern.
>>
>> Another issue is that Matcher supports matching on region (subrange) of its input. For example, today you can do this:
>>
>>     pattern.matcher(input).region(start, end)
>>
>> The region will constrain the matching for certain operations, such as find() (but not replaceAll or replaceFirst). If something like results() were added to Matcher, I'd expect that it would respect the Matcher's region, but if results() (or matches() as you called it) were on Pattern, the region constraint would be lacking.
>>
>> Also note that Pattern already has this:
>>
>>     static boolean matches(regex, input)
>>
>> so I don't think an overload of matches() that returns a Stream would be a good idea. (Maybe findAll()?)
>>
>> Another issue, not directly related to where the new lambda/streams methods get added, is that MatchResult allows references only numbered capturing groups. Matcher, which implements MatchResult, also supports named capturing groups, with the new overloaded methods group(String), start(String), and end(String). These were added in Java 7. Logically these also belong on MatchResult, but they probably weren't added because of the compatibility issue of adding methods to interfaces. Maybe we should add these as default methods to MatchResult.
>>
>> (But what would the supported implementation be? Just throw UnsupportedOperationException?)
>>
>> --
>>
>> I'm not entirely sure where this leaves things. It certainly seems more convenient to have the new methods on Pattern. But given the way the existing API is set up, it seems like it's a better fit to add them to Matcher.
>>
>> s'marks
>>
>>
>>
>> On 2/9/15 6:18 AM, Paul Sandoz wrote:
>>> Here is an alternative that pushes the methods on to Pattern instead:
>>>
>>>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/on-Pattern/webrev/
>>>
>>> (Whe webrev reports some files as empty, please ingore those, i have this webrev stacked on the previous one.)
>>>
>>> I have also included replaceFirst.
>>>
>>> This simplifies things for streaming on the match results and also for replacing.
>>>
>>> Note that the existing replace* methods on Matcher reset the matcher before matching and indicate that the matcher should be reset afterwards for reuse. Thus there is no loss in functionality moving such lambda accepting methods from Matcher to Pattern. It comes down to the performance of reusing a matcher, which does not seems so compelling to me.
>>>
>>> Paul.
>>>
>>> On Feb 5, 2015, at 11:59 AM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
>>>
>>>> Hi.
>>>>
>>>> Please review these stream/lambda enhancements on Matcher:
>>>>
>>>>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/
>>>>
>>>> Two new methods are added to Matcher:
>>>>
>>>> 1) replaceAll(Function<MatchResult, String> ) that is more flexible than the existing replaceAll that accepts a single value.
>>>>
>>>> 2) Stream<MatchResult> results() that returns a stream of MatchResult for all matches.
>>>>
>>>> The former does introduce a minor source incompatibility for a null argument, but then so did the new append methods accepting StringBuilder that were recently added (see JDK-8039124).
>>>>
>>>> For the latter i opted to place the method on Matcher rather than Pattern as i think that is a better fit with current usages of Matcher and operating on a MatchResult. That marginally increases the complexity since co-modification checking is required.
>>>>
>>>> I update the test PatternStreamTest to derive the expected result.
>>>>
>>>>
>>>> I suppose i could add another method replaceFirst(Function<MatchResult, String> ) if anyone feels strongly about that. Consistency-wise it seems the right thing to do.
>>>>
>>>> Paul.
>>>
>


From Roger.Riggs at Oracle.com  Wed Feb 11 20:24:36 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 11 Feb 2015 15:24:36 -0500
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <CA+kOe091FHtd1Mnz_eVLcP0a_fC-+nXPGjnEdYr706XguBTy=g@mail.gmail.com>
References: <54CBAA39.3050004@Oracle.com>	<54CBF7DB.9000909@oracle.com>	<54CBFC10.9080502@Oracle.com>	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>	<54CD4305.4080607@oracle.com>	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>	<54CF7D1F.6050101@Oracle.com>	<CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>	<54CFE064.70400@Oracle.com>	<CA+kOe0-zPJRpGEa0zXy6_bHgwNcnFWuSc1fbbxsc7-nc6SUjAg@mail.gmail.com>	<54D08997.9020300@oracle.com>
	<CA+kOe091FHtd1Mnz_eVLcP0a_fC-+nXPGjnEdYr706XguBTy=g@mail.gmail.com>
Message-ID: <54DBBA84.7090108@Oracle.com>

Hi Martin,

I'm still looking for additional support for using IOException instead of
UnsupportedOperationException;  the prevailing view is that UOE is 
appropriate.

The usual definition of UnsupportedOperationException seem to fit this 
case well.
The behavior of the methods is not supported by the implementation; it 
is unconditional,
it is not a question of OS policy or Java runtime policy.

The examples cited avoid using Process if the OS dependent programs are not
available and in those cases the UOE would not be encountered so this should
not raise issues for existing programs.

Roger







On 2/3/15 2:30 PM, Martin Buchholz wrote:
> I agree that we should not be throwing SecurityException. We should be 
> throwing IOException.
>
> But given a choice between SecurityException and 
> UnsupportedOperationException, I would regard the former as the lesser 
> of two evils.
>
> On Tue, Feb 3, 2015 at 12:40 AM, Alan Bateman <Alan.Bateman at oracle.com 
> <mailto:Alan.Bateman at oracle.com>> wrote:
>
>     On 02/02/2015 21:06, Martin Buchholz wrote:
>
>         :
>         The historic spec allows for both SecurityException and
>         IOException (but
>         not UOE).
>         Locked-down systems typically (but not necessarily) have a
>         SecurityManager
>         that helps enforce the restrictions and so SecurityException
>         seems vaguely
>         appropriate.
>
>     There are a small number of places where SecurityException is
>     thrown when not running with a security manager (defineClass,
>     package sealing) but it can be confusing for developers to get
>     this exception when there isn't a Java security manager. So I
>     don't think we should be using it here.
>
>     -Alan
>
>



From paul.sandoz at oracle.com  Wed Feb 11 20:45:45 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 11 Feb 2015 21:45:45 +0100
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <54DBAC35.1060903@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>
Message-ID: <5BB0E788-9908-460E-A63F-46C5189CBCB1@oracle.com>


On Feb 11, 2015, at 8:23 PM, Stuart Marks <stuart.marks at oracle.com> wrote:

> On 2/11/15 2:25 AM, Paul Sandoz wrote:
>> Hi Stuart,
>> 
>> Thanks for the detailed review.
>> 
>> Here is a possible way forward:
>> 
>> 1) Add the methods to Matcher, as proposed in the initial webrev.
> 
> Yes, I think this is the way to go, and it seems that Sherman concurs.
> 
>> 1.1) Change the specification of Matcher.results to reset the stream before matching, making it consistent with the replace* methods.
> 
> I'm not sure about this. The current replaceAll/replaceFirst methods reset the matcher before doing any matching, so the lambda-based overloads should do the same.

Yes, we are in agreement on that.


> 
> However, the model for
> 
>    Stream<MatchResult> results()
> 
> seems to me to be a stream of matches that would be returned by successive calls to find(). (Indeed, that's how it's implemented.) The no-arg find() call doesn't reset the Matcher,

It cannot, otherwise it would not work for repeated calls to obtain subsequent matches. 


> and it respects the existing region of the Matcher. I think results() should do the same.
> 

That "matches" my original thinking on the matter and is reflected in the patch. It's very simple to support. If the method was named "findAll" then it would be misleading and imply a reset was needed.


> Now there's also a find(int start) overload that does reset the matcher (discarding the region) but starts at the given position. This suggests another overload,
> 
>    Stream<MatchResult> results(int start)
> 
> which also resets the matcher. I don't think this is necessary, though, since I believe the equivalent effect can be achieved by setting the region before calling the no-arg results() -- as long as it doesn't reset the matcher.
> 

Yes.


> No matter what, I think results() will have to check for concurrent modification.

Yes, as in the patch.


> It seems to be in the nature of this API, sigh.
> 
> By the way, I think Matcher.results() is a fine name. The overload of Pattern.matches() is what bothers me.

Ok.


> 
>> 2) Add convenience methods for all replace*() and matches() on Pattern that defer to those on Matcher.
> 
> I'm not sure convenience methods are necessary. After all, there are the existing replaceFirst/replaceAll methods on Matcher that aren't on Pattern.
> 
> In addition, if you don't need to hang onto the Pattern or Matcher instances, my example from earlier can be compressed to:
> 
>    String result = Pattern.compile("a*b")
>        .matcher(input).replaceAll(mr -> mr.group().toUpperCase());
> 
> which ain't too bad.
> 

Agreed.


> 
>> We can do that in two stages, focusing on 1) in this review.
> 
> Yes.
> 

Ok, the first webrev i sent is already implemented as agreed so lets review that code.


>> I was not too concerned about the static method and the stream returning method having the same name as the context is quite different. For stream returning methods there is a de-facto pattern of using a plural of the stream element kind, so i prefer that to findAll. What about the name "Pattern.matchResults"? which chains well with "Pattern.match(...).results()".
>> 
>> --
>> 
>> Regarding the disparity between MatchResult and Matcher. I think that would require a new sub-interface of MatchResult from which Matcher extends from and returns. If we think it important we should do that for 9 otherwise we will be stuck for the stream-based methods.
> 
> Why do you think we need a new sub-interface? Wouldn't it be sufficient to add default methods?

What would the defaults do? Throwing an exception seems a poor solution to me.

My guess it will be possible to evolve Matcher in binary and source compatible way to use the sub-type.

Paul.

> 
> There is of course the possibility of existing 3rd party classes that implement MatchResult having conflicting methods. But I don't think MatchResult is implemented quite as often as the collection interfaces, where we've been reticent to add default methods because of so many implementations.
> 
> I did a quick web search and I did find a few implementations/extensions of MatchResult, but there were no obvious conflicts. This isn't definitive, of course.
> 
> The default implementations of group(String), start(String), and end(String) could throw IllegalArgumentException, since that's what the ones on Matcher do if there's no such named capture group.
> 
> I admit this is a little weird, since it's only safe to use these new methods if you know where the MatchResult instance came from. So logically perhaps it's a different type. My hunch, though, is that MatchResults aren't passed around, they're created from Patterns/Matchers and processed within the same code, so in practice this won't be a problem.
> 
> s'marks



From david.holmes at oracle.com  Wed Feb 11 22:57:59 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Feb 2015 08:57:59 +1000
Subject: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on
	arrays longer than 1073741824
In-Reply-To: <54DBAA2C.6050307@oracle.com>
References: <54DB8359.2020803@oracle.com> <54DB9246.3000206@Oracle.com>
	<54DBAA2C.6050307@oracle.com>
Message-ID: <54DBDE77.70408@oracle.com>

On 12/02/2015 5:14 AM, Lev Priima wrote:
> Just briefly looked at it, w/o evaluating formal proof. But original
> Python implementation(written on C) works on stack size even more
> simple, AFAIU it:
>
> /* The maximum number of entries in a MergeState's pending-runs stack.
>   * This is enough to sort arrays of size up to about
>   *     32 * phi ** MAX_MERGE_PENDING
>   * where phi ~= 1.618.  85 is ridiculouslylarge enough, good for an array
>   * with 2**64 elements.
>   */
> #define MAX_MERGE_PENDING 85

So where did the new magic number 49 come from? And how do we know this 
is now "big enough"?

Thanks,
David

> Lev
>
> On 02/11/2015 08:32 PM, Roger Riggs wrote:
>> Hi Lev,
>>
>> The fix looks fine.
>>
>> Did you consider the improvements suggested in the paper to
>> reestablish the invariant?
>>
>> Roger
>>
>> On 2/11/2015 11:29 AM, Lev Priima wrote:
>>> Hi,
>>>
>>> Stack length increased previously by JDK-8011944 was insufficient for
>>> some cases.
>>> Please review and push:
>>> webrev: http://cr.openjdk.java.net/~lpriima/8072909/webrev.00/
>>> issue: https://bugs.openjdk.java.net/browse/JDK-8072909
>>>
>>
>


From Ulf.Zibis at CoSoCo.de  Thu Feb 12 00:01:49 2015
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Thu, 12 Feb 2015 01:01:49 +0100
Subject: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on
	arrays longer than 1073741824
In-Reply-To: <54DBDE77.70408@oracle.com>
References: <54DB8359.2020803@oracle.com>
	<54DB9246.3000206@Oracle.com>	<54DBAA2C.6050307@oracle.com>
	<54DBDE77.70408@oracle.com>
Message-ID: <54DBED6D.4000408@CoSoCo.de>

Am 11.02.2015 um 23:57 schrieb David Holmes:
>
> So where did the new magic number 49 come from? And how do we know this is now "big enough"?
>
> Thanks,
> David

+1
Ulf



From stuart.marks at oracle.com  Thu Feb 12 00:41:24 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 11 Feb 2015 16:41:24 -0800
Subject: RFR 8071600: Add a flat-mapping collector
In-Reply-To: <0A906E66-52EF-4777-8951-CB90212178F8@oracle.com>
References: <517DF5B9-E3C5-4CD9-A04A-AC06EBD61517@oracle.com>	<54DA8DFA.1020706@oracle.com>
	<0A906E66-52EF-4777-8951-CB90212178F8@oracle.com>
Message-ID: <54DBF6B4.9020903@oracle.com>



On 2/11/15 1:54 AM, Paul Sandoz wrote:
>
> On Feb 11, 2015, at 12:02 AM, Stuart Marks <stuart.marks at oracle.com> wrote:
>
>> Hi Paul,
>>
>> On 2/3/15 5:48 AM, Paul Sandoz wrote:
>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping/webrev/
>>>
>>> This patch adds a new flat mapping collector to Collectors. This can be useful if one needs to map 0 or more items into a downstream collector.
>>
>> Mostly pretty good, just a couple minor nits.
>>
>> Re the comment at TabulatorsTest.java line 513, this isn't a two-level groupBy anymore, it's a groupByWithMapping (as the test name indicates).
>>
>
> I removed the comment. I also added the bug id to the test. Updated in place:
>
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping-test-rename/webrev/

Thanks for the updates. I'm not sure exactly what this webrev represents now, 
but the only change I requested was to change the comment, so no big deal.

>> Given the new tests of closing in FlatMapOpTest.java, is it necessary to have testFlatMappingClose() in TabulatorsTest.java?
>>
>
> Yes, they are testing different code paths.

Thanks for the explanation.

s'marks

>
> TabulatorsTest.testFlatMappingClose tests the closing functionality of Collectors.flatMapping:
>
> public static <T, U, A, R>
> Collector<T, ?, R> flatMapping(Function<? super T, ? extends Stream<? extends U>> mapper,
>                                 Collector<? super U, A, R> downstream) {
>      BiConsumer<A, ? super U> downstreamAccumulator = downstream.accumulator();
>      return new CollectorImpl<>(downstream.supplier(),
>                          (r, t) -> {
>                              try (Stream<? extends U> result = mapper.apply(t)) {
>                                  if (result != null)
>                                      result.sequential().forEach(u -> downstreamAccumulator.accept(r, u));
>                              }
>                          },
>                          downstream.combiner(), downstream.finisher(),
>                          downstream.characteristics());
> }
>
> Where as the tests of closing in FlatMapOpTest test the closing of Stream.flatMap*:
>
> @Override
> public final <R> Stream<R> flatMap(Function<? super P_OUT, ? extends Stream<? extends R>> mapper) {
>      Objects.requireNonNull(mapper);
>      // We can do better than this, by polling cancellationRequested when stream is infinite
>      return new StatelessOp<P_OUT, R>(this, StreamShape.REFERENCE,
>                                   StreamOpFlag.NOT_SORTED | StreamOpFlag.NOT_DISTINCT | StreamOpFlag.NOT_SIZED) {
>          @Override
>          Sink<P_OUT> opWrapSink(int flags, Sink<R> sink) {
>              return new Sink.ChainedReference<P_OUT, R>(sink) {
>                  @Override
>                  public void begin(long size) {
>                      downstream.begin(-1);
>                  }
>
>                  @Override
>                  public void accept(P_OUT u) {
>                      try (Stream<? extends R> result = mapper.apply(u)) {
>                          // We can do better that this too; optimize for depth=0 case and just grab spliterator and forEach it
>                          if (result != null)
>                              result.sequential().forEach(downstream);
>                      }
>                  }
>              };
>          }
>      };
> }
>
>
>>> A following patch, which i plan to fold into the above patch, performs some renames on the collectors test to be consistent with the current naming:
>>>
>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping-test-rename/webrev/
>>
>> Renaming looks good and makes it easy to correlate the tests, the assertion classes, and the collector implementations under test. Unfortunately, the word for the act of collecting is "collection" which is confusing since "collection" already has another meaning, but oh well.
>>
>
> Alas :-)
>
> Thanks,
> Paul.
>


From joe.darcy at oracle.com  Thu Feb 12 01:08:15 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 11 Feb 2015 17:08:15 -0800
Subject: [9] RFR of 8066842: java.math.BigDecimal.divide(BigDecimal,
	RoundingMode) produces incorrect result
In-Reply-To: <3658ABE5-6BCE-4847-965C-B9937F5E15A4@oracle.com>
References: <27F1BCB8-8160-4E82-A12C-2932C33EE9D5@oracle.com>	<663493B4-4B15-4DFD-8E84-695F59FFC80C@oracle.com>	<F11FE936-C5A8-4FBB-B2E6-3A00D7313DFD@oracle.com>	<09E156F0-1015-47DC-8BCD-4F6CA088C7B2@oracle.com>	<A1011F17-2432-4229-8077-1B57CAE02412@oracle.com>
	<3658ABE5-6BCE-4847-965C-B9937F5E15A4@oracle.com>
Message-ID: <54DBFCFE.2090205@oracle.com>

Hi Brian,

Looks fine; just adjust the copyright dates before pushing.

Thanks,

-Joe

On 2/6/2015 12:29 PM, Brian Burkhalter wrote:
> On Feb 6, 2015, at 7:46 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
>
>> On Feb 6, 2015, at 12:51 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>
>>> +1, but you should remove the "@throws IAE" on divRemNegativeLong before you push.
>> Mea culpa. Thanks for pointing out the (failure of) omission. Will remove before pushing.
> FYI here is the updated webrev: http://cr.openjdk.java.net/~bpb/8066842/webrev.02/
>
> Brian
>



From brian.burkhalter at oracle.com  Thu Feb 12 01:16:00 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 11 Feb 2015 17:16:00 -0800
Subject: [9] RFR of 8066842: java.math.BigDecimal.divide(BigDecimal,
	RoundingMode) produces incorrect result
In-Reply-To: <54DBFCFE.2090205@oracle.com>
References: <27F1BCB8-8160-4E82-A12C-2932C33EE9D5@oracle.com>	<663493B4-4B15-4DFD-8E84-695F59FFC80C@oracle.com>	<F11FE936-C5A8-4FBB-B2E6-3A00D7313DFD@oracle.com>	<09E156F0-1015-47DC-8BCD-4F6CA088C7B2@oracle.com>	<A1011F17-2432-4229-8077-1B57CAE02412@oracle.com>
	<3658ABE5-6BCE-4847-965C-B9937F5E15A4@oracle.com>
	<54DBFCFE.2090205@oracle.com>
Message-ID: <75235246-EC82-4704-A508-752691C4109A@oracle.com>

Hi Joe,

All right; will do.

Thanks,

Brian

On Feb 11, 2015, at 5:08 PM, Joseph D. Darcy <joe.darcy at oracle.com> wrote:

> Hi Brian,
> 
> Looks fine; just adjust the copyright dates before pushing.
> 
> Thanks,
> 
> -Joe



From brian.burkhalter at oracle.com  Thu Feb 12 01:33:05 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 11 Feb 2015 17:33:05 -0800
Subject: [9] RFC JDK-8068373: (prefs) FileSystemPreferences writes \0 to XML
	storage, causing loss of all preferences 
Message-ID: <D0C3D711-ACF0-46AB-8B06-6BB7ECDE6FC2@oracle.com>

This is a request for comment only, at this point. There is no associated formal test but there is one in the issue description.

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

I mostly want to know how out to lunch this approach is, for the moment only in the context of FileSystemPreferences, not exporting/importing to/from XML in general from generic Preferences.

Two things should be noted here. The Preferences (and Properties) can be exported to and imported from an XML format on all platforms. In the case of Unix (Linux and Solaris, I believe) this is also the format used to store the Preferences whereas on other platforms that is not the case. Therefore for these Unix cases there is the possibility of loss if things are not losslessly round trip encoded into XML. The present issue is one such case with dire consequences.

The main problems as I see them are 1) how to maintain compatibility across Java versions, and 2) how to preserve what can be added as a Preference. With respect to the latter item, this should not be constrained because the datum happens to be cached in XML.

This particular solution is data-preserving with respect to the issue addressed if the same or later version of a JVM is used, and does not cause older Java versions reading the XML cache to fail.

Thanks,

Brian

From martinrb at google.com  Thu Feb 12 02:08:15 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 11 Feb 2015 18:08:15 -0800
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <54DBBA84.7090108@Oracle.com>
References: <54CBAA39.3050004@Oracle.com> <54CBF7DB.9000909@oracle.com>
	<54CBFC10.9080502@Oracle.com>
	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>
	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>
	<54CD4305.4080607@oracle.com>
	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>
	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>
	<54CF7D1F.6050101@Oracle.com>
	<CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>
	<54CFE064.70400@Oracle.com>
	<CA+kOe0-zPJRpGEa0zXy6_bHgwNcnFWuSc1fbbxsc7-nc6SUjAg@mail.gmail.com>
	<54D08997.9020300@oracle.com>
	<CA+kOe091FHtd1Mnz_eVLcP0a_fC-+nXPGjnEdYr706XguBTy=g@mail.gmail.com>
	<54DBBA84.7090108@Oracle.com>
Message-ID: <CA+kOe08VHA6h=6xVipyZ-xEx-XFBJ_mfd48GcnGJMaU0hQMQVA@mail.gmail.com>

Roger et al,

Whichever way we go doesn't matter much.
But I continue to think that IOE is a better choice than UOE and I have
trouble seeing the motivation for the change to use UOE.
If you wanted to provide a way to tell if subprocess support was available
at all, then it would be better to add a new static boolean method to
Process (but I wouldn't support that either).
But (Roger and Alan): feel free to outvote me.

On Wed, Feb 11, 2015 at 12:24 PM, Roger Riggs <Roger.Riggs at oracle.com>
wrote:

> Hi Martin,
>
> I'm still looking for additional support for using IOException instead of
> UnsupportedOperationException;  the prevailing view is that UOE is
> appropriate.
>
> The usual definition of UnsupportedOperationException seem to fit this
> case well.
> The behavior of the methods is not supported by the implementation; it is
> unconditional,
> it is not a question of OS policy or Java runtime policy.
>
> The examples cited avoid using Process if the OS dependent programs are not
> available and in those cases the UOE would not be encountered so this
> should
> not raise issues for existing programs.
>
> Roger
>
>
>
>
>
>
>
> On 2/3/15 2:30 PM, Martin Buchholz wrote:
>
>> I agree that we should not be throwing SecurityException. We should be
>> throwing IOException.
>>
>> But given a choice between SecurityException and
>> UnsupportedOperationException, I would regard the former as the lesser of
>> two evils.
>>
>> On Tue, Feb 3, 2015 at 12:40 AM, Alan Bateman <Alan.Bateman at oracle.com
>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>
>>     On 02/02/2015 21:06, Martin Buchholz wrote:
>>
>>         :
>>         The historic spec allows for both SecurityException and
>>         IOException (but
>>         not UOE).
>>         Locked-down systems typically (but not necessarily) have a
>>         SecurityManager
>>         that helps enforce the restrictions and so SecurityException
>>         seems vaguely
>>         appropriate.
>>
>>     There are a small number of places where SecurityException is
>>     thrown when not running with a security manager (defineClass,
>>     package sealing) but it can be confusing for developers to get
>>     this exception when there isn't a Java security manager. So I
>>     don't think we should be using it here.
>>
>>     -Alan
>>
>>
>>
>


From stuart.marks at oracle.com  Thu Feb 12 02:18:23 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 11 Feb 2015 18:18:23 -0800
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <5BB0E788-9908-460E-A63F-46C5189CBCB1@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>
Message-ID: <54DC0D6F.3000406@oracle.com>

On 2/11/15 12:45 PM, Paul Sandoz wrote:
> On Feb 11, 2015, at 8:23 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> That "matches" my original thinking on the matter and is reflected in the patch. It's very simple to support. If the method was named "findAll" then it would be misleading and imply a reset was needed.

OK, good, I see that, so it doesn't need to be changed.

> Ok, the first webrev i sent is already implemented as agreed so lets review that code.

I looked at:

 
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/

I think this was before you added Pattern.replaceFirst(), so that should be 
retrofitted here.

>>> Regarding the disparity between MatchResult and Matcher. I think that would require a new sub-interface of MatchResult from which Matcher extends from and returns. If we think it important we should do that for 9 otherwise we will be stuck for the stream-based methods.
>>
>> Why do you think we need a new sub-interface? Wouldn't it be sufficient to add default methods?
>
> What would the defaults do? Throwing an exception seems a poor solution to me.
>
> My guess it will be possible to evolve Matcher in binary and source compatible way to use the sub-type.

OK, I filed an RFE to cover this, then immediately closed it as a duplicate :-) 
because I failed to search for the existing RFE that covers this:

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

Either we add some default methods that throw exceptions (gross) or we add a 
sub-interface (also gross). It might be a matter of taste, or bike shed 
painting. Either way, I think this needs to be done.

s'marks

>
> Paul.
>
>>
>> There is of course the possibility of existing 3rd party classes that implement MatchResult having conflicting methods. But I don't think MatchResult is implemented quite as often as the collection interfaces, where we've been reticent to add default methods because of so many implementations.
>>
>> I did a quick web search and I did find a few implementations/extensions of MatchResult, but there were no obvious conflicts. This isn't definitive, of course.
>>
>> The default implementations of group(String), start(String), and end(String) could throw IllegalArgumentException, since that's what the ones on Matcher do if there's no such named capture group.
>>
>> I admit this is a little weird, since it's only safe to use these new methods if you know where the MatchResult instance came from. So logically perhaps it's a different type. My hunch, though, is that MatchResults aren't passed around, they're created from Patterns/Matchers and processed within the same code, so in practice this won't be a problem.
>>
>> s'marks
>


From brian.goetz at oracle.com  Thu Feb 12 01:06:00 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 11 Feb 2015 20:06:00 -0500
Subject: List.indexOf and List.lastIndexOf lambda version.
In-Reply-To: <54DB289D.7010009@oracle.com>
References: <54DB289D.7010009@oracle.com>
Message-ID: <C564B123-F6AC-473E-80FC-75FECB5B08FC@oracle.com>

The EG discussed these during Lambda and just couldn?t get excited about them.  

On Feb 11, 2015, at 5:02 AM, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:

> Hi everyone,
> 
> I there any reason why java.util.List doesn't have lambda versions of indexOf and lastIndexOf methods like list.indexOf(Predicate<>) ?
> 
> --Thanks, Andrey



From lev.priima at oracle.com  Thu Feb 12 09:58:29 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Thu, 12 Feb 2015 09:58:29 +0000
Subject: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on
	arrays longer than 1073741824
In-Reply-To: <54DBDE77.70408@oracle.com>
References: <54DB8359.2020803@oracle.com> <54DB9246.3000206@Oracle.com>
	<54DBAA2C.6050307@oracle.com> <54DBDE77.70408@oracle.com>
Message-ID: <54DC7945.50701@oracle.com>

"49" is also mentioned in the paper as possible solution. I've run test 
from webrev with array length 2147483644 (Integer.MAX_VALUE-4) and 
TimSort passed.

Lev

On 02/11/2015 10:57 PM, David Holmes wrote:
> On 12/02/2015 5:14 AM, Lev Priima wrote:
>> Just briefly looked at it, w/o evaluating formal proof. But original
>> Python implementation(written on C) works on stack size even more
>> simple, AFAIU it:
>>
>> /* The maximum number of entries in a MergeState's pending-runs stack.
>>   * This is enough to sort arrays of size up to about
>>   *     32 * phi ** MAX_MERGE_PENDING
>>   * where phi ~= 1.618.  85 is ridiculouslylarge enough, good for an 
>> array
>>   * with 2**64 elements.
>>   */
>> #define MAX_MERGE_PENDING 85
>
> So where did the new magic number 49 come from? And how do we know 
> this is now "big enough"?
>
> Thanks,
> David
>
>> Lev
>>
>> On 02/11/2015 08:32 PM, Roger Riggs wrote:
>>> Hi Lev,
>>>
>>> The fix looks fine.
>>>
>>> Did you consider the improvements suggested in the paper to
>>> reestablish the invariant?
>>>
>>> Roger
>>>
>>> On 2/11/2015 11:29 AM, Lev Priima wrote:
>>>> Hi,
>>>>
>>>> Stack length increased previously by JDK-8011944 was insufficient for
>>>> some cases.
>>>> Please review and push:
>>>> webrev: http://cr.openjdk.java.net/~lpriima/8072909/webrev.00/
>>>> issue: https://bugs.openjdk.java.net/browse/JDK-8072909
>>>>
>>>
>>



From peter.levart at gmail.com  Thu Feb 12 08:43:34 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Feb 2015 09:43:34 +0100
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <54DBAC35.1060903@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>
Message-ID: <54DC67B6.9040808@gmail.com>


On 02/11/2015 08:23 PM, Stuart Marks wrote:
>> 1.1) Change the specification of Matcher.results to reset the stream 
>> before matching, making it consistent with the replace* methods.
>
> I'm not sure about this. The current replaceAll/replaceFirst methods 
> reset the matcher before doing any matching, so the lambda-based 
> overloads should do the same.
>
> However, the model for
>
>     Stream<MatchResult> results()
>
> seems to me to be a stream of matches that would be returned by 
> successive calls to find(). (Indeed, that's how it's implemented.) The 
> no-arg find() call doesn't reset the Matcher, and it respects the 
> existing region of the Matcher. I think results() should do the same. 

Hi,

What about two methods?

Stream<MatchResult> remainingResults(); // doesn't reset the Matcher
Stream<MatchResult> [all]results(); // resets Matcher and calls 
remainingResults()


Peter



From Alan.Bateman at oracle.com  Thu Feb 12 09:07:23 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 12 Feb 2015 09:07:23 +0000
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <CA+kOe08VHA6h=6xVipyZ-xEx-XFBJ_mfd48GcnGJMaU0hQMQVA@mail.gmail.com>
References: <54CBAA39.3050004@Oracle.com>
	<54CBF7DB.9000909@oracle.com>	<54CBFC10.9080502@Oracle.com>	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>	<54CD4305.4080607@oracle.com>	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>	<54CF7D1F.6050101@Oracle.com>	<CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>	<54CFE064.70400@Oracle.com>	<CA+kOe0-zPJRpGEa0zXy6_bHgwNcnFWuSc1fbbxsc7-nc6SUjAg@mail.gmail.com>	<54D08997.9020300@oracle.com>	<CA+kOe091FHtd1Mnz_eVLcP0a_fC-+nXPGjnEdYr706XguBTy=g@mail.gmail.com>	<54DBBA84.7090108@Oracle.com>
	<CA+kOe08VHA6h=6xVipyZ-xEx-XFBJ_mfd48GcnGJMaU0hQMQVA@mail.gmail.com>
Message-ID: <54DC6D4B.3070902@oracle.com>

On 12/02/2015 02:08, Martin Buchholz wrote:
> Roger et al,
>
> Whichever way we go doesn't matter much.
> But I continue to think that IOE is a better choice than UOE and I have
> trouble seeing the motivation for the change to use UOE.
> If you wanted to provide a way to tell if subprocess support was available
> at all, then it would be better to add a new static boolean method to
> Process (but I wouldn't support that either).
> But (Roger and Alan): feel free to outvote me.
>
I think Roger's proposal is reasonable as this is a case where the API 
will consistently throw UOE when the underlying runtime or operating 
system doesn't support a means to start processes. It's consistent with 
what was done for RMI activiation in JDK 8 (this was also about starting 
processes). Another example that comes to mind is the GUI libraries 
where HeadlessException is thrown (HeadlessException is a UOE). In the 
file system API then UOE is also specified when trying to use optional 
features that aren't supported by the implementation. There are probably 
many counter examples as we don't have consistency everywhere. In 
practical terms then I don't think this change should have an impact, 
but could be useful for those trying to take an existing app and run it 
on something like iOS. If that app relies on Runtime.exec or 
ProcessBuilder then the UOE should make it easy to identify that this 
part of the code needs to be looked at. If someday it is possible to 
start processes on such devices then an updated port to that platform 
wouldn't throw UOE anymore.

-Alan.


From paul.sandoz at oracle.com  Thu Feb 12 11:15:27 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Feb 2015 12:15:27 +0100
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <54DC0D6F.3000406@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>
Message-ID: <4EB3EE4A-8139-41C8-A5BE-F277091EFAE8@oracle.com>

On Feb 12, 2015, at 3:18 AM, Stuart Marks <stuart.marks at oracle.com> wrote:
> On 2/11/15 12:45 PM, Paul Sandoz wrote:
>> On Feb 11, 2015, at 8:23 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
>> That "matches" my original thinking on the matter and is reflected in the patch. It's very simple to support. If the method was named "findAll" then it would be misleading and imply a reset was needed.
> 
> OK, good, I see that, so it doesn't need to be changed.
> 
>> Ok, the first webrev i sent is already implemented as agreed so lets review that code.
> 
> I looked at:
> 
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/
> 
> I think this was before you added Pattern.replaceFirst(), so that should be retrofitted here.
> 

Thanks, added in place:

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/


>>>> Regarding the disparity between MatchResult and Matcher. I think that would require a new sub-interface of MatchResult from which Matcher extends from and returns. If we think it important we should do that for 9 otherwise we will be stuck for the stream-based methods.
>>> 
>>> Why do you think we need a new sub-interface? Wouldn't it be sufficient to add default methods?
>> 
>> What would the defaults do? Throwing an exception seems a poor solution to me.
>> 
>> My guess it will be possible to evolve Matcher in binary and source compatible way to use the sub-type.
> 
> OK, I filed an RFE to cover this, then immediately closed it as a duplicate :-) because I failed to search for the existing RFE that covers this:
> 
>    https://bugs.openjdk.java.net/browse/JDK-8065554
> 
> Either we add some default methods that throw exceptions (gross) or we add a sub-interface (also gross). It might be a matter of taste, or bike shed painting.

Or a matter of how much the grossness is contained. In that respect the latter is more self-contained, the latter spreads out to all independent consumers of MatchResult.

Paul.


From paul.sandoz at oracle.com  Thu Feb 12 11:41:32 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Feb 2015 12:41:32 +0100
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <54DC67B6.9040808@gmail.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> <54DC67B6.9040808@gmail.com>
Message-ID: <888262AF-0F1F-48BF-BF55-FE5981A0ED8B@oracle.com>


On Feb 12, 2015, at 9:43 AM, Peter Levart <peter.levart at gmail.com> wrote:

> 
> On 02/11/2015 08:23 PM, Stuart Marks wrote:
>>> 1.1) Change the specification of Matcher.results to reset the stream before matching, making it consistent with the replace* methods. 
>> 
>> I'm not sure about this. The current replaceAll/replaceFirst methods reset the matcher before doing any matching, so the lambda-based overloads should do the same. 
>> 
>> However, the model for 
>> 
>>     Stream<MatchResult> results() 
>> 
>> seems to me to be a stream of matches that would be returned by successive calls to find(). (Indeed, that's how it's implemented.) The no-arg find() call doesn't reset the Matcher, and it respects the existing region of the Matcher. I think results() should do the same.
> 
> Hi,
> 
> What about two methods?
> 
> Stream<MatchResult> remainingResults(); // doesn't reset the Matcher
> Stream<MatchResult> [all]results(); // resets Matcher and calls remainingResults()
> 

I would prefer to stick with just one, given that it is very easy to reset the matcher, and the most common case is to start with a new matcher.

Paul.


From david.holmes at oracle.com  Thu Feb 12 11:57:04 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Feb 2015 21:57:04 +1000
Subject: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on
	arrays longer than 1073741824
In-Reply-To: <54DC7945.50701@oracle.com>
References: <54DB8359.2020803@oracle.com> <54DB9246.3000206@Oracle.com>
	<54DBAA2C.6050307@oracle.com> <54DBDE77.70408@oracle.com>
	<54DC7945.50701@oracle.com>
Message-ID: <54DC9510.2050904@oracle.com>

Ok - thanks Lev!

David

On 12/02/2015 7:58 PM, Lev Priima wrote:
> "49" is also mentioned in the paper as possible solution. I've run test
> from webrev with array length 2147483644 (Integer.MAX_VALUE-4) and
> TimSort passed.
>
> Lev
>
> On 02/11/2015 10:57 PM, David Holmes wrote:
>> On 12/02/2015 5:14 AM, Lev Priima wrote:
>>> Just briefly looked at it, w/o evaluating formal proof. But original
>>> Python implementation(written on C) works on stack size even more
>>> simple, AFAIU it:
>>>
>>> /* The maximum number of entries in a MergeState's pending-runs stack.
>>>   * This is enough to sort arrays of size up to about
>>>   *     32 * phi ** MAX_MERGE_PENDING
>>>   * where phi ~= 1.618.  85 is ridiculouslylarge enough, good for an
>>> array
>>>   * with 2**64 elements.
>>>   */
>>> #define MAX_MERGE_PENDING 85
>>
>> So where did the new magic number 49 come from? And how do we know
>> this is now "big enough"?
>>
>> Thanks,
>> David
>>
>>> Lev
>>>
>>> On 02/11/2015 08:32 PM, Roger Riggs wrote:
>>>> Hi Lev,
>>>>
>>>> The fix looks fine.
>>>>
>>>> Did you consider the improvements suggested in the paper to
>>>> reestablish the invariant?
>>>>
>>>> Roger
>>>>
>>>> On 2/11/2015 11:29 AM, Lev Priima wrote:
>>>>> Hi,
>>>>>
>>>>> Stack length increased previously by JDK-8011944 was insufficient for
>>>>> some cases.
>>>>> Please review and push:
>>>>> webrev: http://cr.openjdk.java.net/~lpriima/8072909/webrev.00/
>>>>> issue: https://bugs.openjdk.java.net/browse/JDK-8072909
>>>>>
>>>>
>>>
>


From paul.sandoz at oracle.com  Thu Feb 12 12:37:30 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Feb 2015 13:37:30 +0100
Subject: [9] RFC JDK-8068373: (prefs) FileSystemPreferences writes \0 to
	XML storage, causing loss of all preferences
In-Reply-To: <D0C3D711-ACF0-46AB-8B06-6BB7ECDE6FC2@oracle.com>
References: <D0C3D711-ACF0-46AB-8B06-6BB7ECDE6FC2@oracle.com>
Message-ID: <47F7C751-6C85-438E-A9A9-3FB11422691C@oracle.com>

Hi Brian,

What do existing XML APIs do?

My guess from looking at your webrev APIs such as DOM allow such invalid characters when writing and reading? If so that would seem to be more of a fundamental issue with those APIs and not specifically with preferences.

I think there should be an error if a key or value contains a the U+0000 character when writing out the set of property entries to XML, otherwise it just propagates the error to who or what is consuming that XML file.

Paul.

 
On Feb 12, 2015, at 2:33 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> This is a request for comment only, at this point. There is no associated formal test but there is one in the issue description.
> 
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8068373
> Patch:	http://cr.openjdk.java.net/~bpb/8068373/webrev.02/
> 
> I mostly want to know how out to lunch this approach is, for the moment only in the context of FileSystemPreferences, not exporting/importing to/from XML in general from generic Preferences.
> 
> Two things should be noted here. The Preferences (and Properties) can be exported to and imported from an XML format on all platforms. In the case of Unix (Linux and Solaris, I believe) this is also the format used to store the Preferences whereas on other platforms that is not the case. Therefore for these Unix cases there is the possibility of loss if things are not losslessly round trip encoded into XML. The present issue is one such case with dire consequences.
> 
> The main problems as I see them are 1) how to maintain compatibility across Java versions, and 2) how to preserve what can be added as a Preference. With respect to the latter item, this should not be constrained because the datum happens to be cached in XML.
> 
> This particular solution is data-preserving with respect to the issue addressed if the same or later version of a JVM is used, and does not cause older Java versions reading the XML cache to fail.
> 
> Thanks,
> 
> Brian



From christos at zoulas.com  Thu Feb 12 12:54:31 2015
From: christos at zoulas.com (Christos Zoulas)
Date: Thu, 12 Feb 2015 07:54:31 -0500
Subject: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on
	arrays longer than 1073741824
In-Reply-To: <54DC9510.2050904@oracle.com> from David Holmes (Feb 12,  9:57pm)
Message-ID: <20150212125431.D46DB17FDAA@rebar.astron.com>

On Feb 12,  9:57pm, david.holmes at oracle.com (David Holmes) wrote:
-- Subject: Re: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on

| Ok - thanks Lev!
| 
| David

For posterity can someone document this, and also the value for which
Integer.MAX_VALUE-4 fails?

christos


From aleksej.efimov at oracle.com  Thu Feb 12 13:23:43 2015
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Thu, 12 Feb 2015 16:23:43 +0300
Subject: RFR: 8071585: Update JAX-WS RI integration to latest version
	(2.2.11-b150127.1410)
In-Reply-To: <54DB8740.4070303@oracle.com>
References: <54CA48E0.8030902@oracle.com> <54CA4C81.301@oracle.com>
	<54CF556C.10908@oracle.com> <54DB814F.1020904@oracle.com>
	<54DB8740.4070303@oracle.com>
Message-ID: <54DCA95F.6050504@oracle.com>

Than you, Alan!
Will integrate this fix now.

-Aleksej

On 02/11/2015 07:45 PM, Alan Bateman wrote:
> On 11/02/2015 16:20, Aleksej Efimov wrote:
>> Hi Alan, Miran,
>> If I understood correctly we can fix "&gt;" in the next bulk update 
>> (in early March). If it's so, can I have an approval for this fix?
>>
>> Thank you,
>> Aleksej
> Yes, fixing at the next sync up is fine (I didn't realize my mail was 
> holding this up, apologies!).
>
> -Alan
>



From lev.priima at oracle.com  Thu Feb 12 16:56:13 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Thu, 12 Feb 2015 16:56:13 +0000
Subject: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on
	arrays longer than 1073741824
In-Reply-To: <20150212125431.D46DB17FDAA@rebar.astron.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>
Message-ID: <54DCDB2D.3090006@oracle.com>

Christos,

Test may fail on shorter arrays(page 8 of paper). For instance, on worst 
case, generated by test, it starts to fail on length 67108864.
After increasing stack size of runs to merge, Arrays.sort(T[]) works 
also on maximum possible array for HotSpot JVM.


Roger, David,
I've updated the test ( 
http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html 
) to make it more suitable for regular execution:

   27  * @run main/othervm TimSortStackSize2 67108864
   28  * not for regular execution on all platforms:
   29  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
   30  * run main/othervm -Xmx32g TimSortStackSize2 2147483644

Could you please push this:
http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
?

Lev

On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
> On Feb 12,  9:57pm, david.holmes at oracle.com (David Holmes) wrote:
> -- Subject: Re: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on
>
> | Ok - thanks Lev!
> |
> | David
>
> For posterity can someone document this, and also the value for which
> Integer.MAX_VALUE-4 fails?
>
> christos



From chris.hegarty at oracle.com  Thu Feb 12 14:33:17 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 12 Feb 2015 14:33:17 +0000
Subject: RFR 8071600: Add a flat-mapping collector
In-Reply-To: <517DF5B9-E3C5-4CD9-A04A-AC06EBD61517@oracle.com>
References: <517DF5B9-E3C5-4CD9-A04A-AC06EBD61517@oracle.com>
Message-ID: <DDE5F156-3358-4A2B-B62D-23F74F3237D5@oracle.com>

On 3 Feb 2015, at 13:48, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
> 
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping/webrev/

Looks like a useful addition.

Trivially, the handling of null caught my eye: "If a mapped stream is {@code null} an empty stream is used, instead.?  It looks like the result of the mapper function returning null is equivalent to it returning an empty stream, but I?m not sure that I see an empty stream being used in the implementation. Is this just a convenience, for implementers of the mapping function? 

-Chris.

> This patch adds a new flat mapping collector to Collectors. This can be useful if one needs to map 0 or more items into a downstream collector.
> 
> A CCC will be filed.
> 
> A following patch, which i plan to fold into the above patch, performs some renames on the collectors test to be consistent with the current naming: 
> 
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping-test-rename/webrev/
> 
> Thanks,
> Paul.



From daniel.fuchs at oracle.com  Thu Feb 12 14:50:06 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 12 Feb 2015 15:50:06 +0100
Subject: RFR 8071670: java.util.Optional: please add a way to specify
	if-else behavior
In-Reply-To: <0A89199D-AFFA-4A90-B76F-D8BFAC75748A@oracle.com>
References: <0A89199D-AFFA-4A90-B76F-D8BFAC75748A@oracle.com>
Message-ID: <54DCBD9E.9000007@oracle.com>

Hi Paul,

This looks good - I have noticed one copy/paste error in the javadoc
though:

OptionalInt.java:

looks like the throws clause of ifPresent and ifPresentOrElse have been
interverted:

  138      * @throws NullPointerException if a value is present and 
{@code action} is
  139      * null, or a value is not present and {@code emptyAction} is 
null.
  140      */
  141     public void ifPresent(IntConsumer action) {
  142         if (isPresent) {
  143             action.accept(value);
  144         }
  145     }
  146
  147     /**
  148      * If a value is present, perform the given action with the value,
  149      * otherwise perform the given empty-based action.
  150      *
  151      * @param action the action to be performed if a value is present
  152      * @param emptyAction the empty-based action to be performed 
if a value is
  153      * not present
  154      * @throws NullPointerException if value is present and {@code 
action} is
  155      * null
  156      * @since 1.9
  157      */
  158     public void ifPresentOrElse(IntConsumer action, Runnable 
emptyAction) {


Concerning the test, should there be a test that verifies that NPE
is thrown when null is passed - as specified in the javadoc?

Best regards,

-- daniel

On 03/02/15 16:38, Paul Sandoz wrote:
> Hi,
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071670-Optional-ifPresentOrElse/webrev/
>
> Here is another tweak to Optional (and primitives) that has some weight:
>
> /**
>   * If a value is present, perform the given action with the value,
>   * otherwise perform the given empty-based action.
>   *
>   * @param action the action to be performed if a value is present
>   * @param emptyAction the empty-based action to be performed if a value is
>   * not present
>   * @throws NullPointerException if a value is present and {@code action} is
>   * null, or a value is not present and {@code emptyAction} is null.
>   * @since 1.9
>   */
> public void ifPresentOrElse(Consumer<? super T> action, Runnable emptyAction) {
>      if (value != null) {
>          action.accept(value);
>      } else {
>          emptyAction.run();
>      }
> }
>
> (In hindsight we should have been consistent and thrown NPEs regardless of the optional state. The exception throwing behaviour is consistent with ifPresent.)
>
> Previously it was kind of awkward if one had two lambdas or method refs handy, one had to do:
>
>    o.ifPresent(v -> ...);
>    if (!o.ifPresent()) {
>      ...
>    }
>
> Or just:
>
>    if (o.ifPresent()) {
>      ...
>    } else {
>       ...
>    }
>
>
> I also updated the language of the ifPresent methods to be more consistent with Collection/Stream.forEach.
>
> Paul.
>



From Roger.Riggs at Oracle.com  Thu Feb 12 14:53:41 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 12 Feb 2015 09:53:41 -0500
Subject: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on
	arrays longer than 1073741824
In-Reply-To: <54DCDB2D.3090006@oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>
	<54DCDB2D.3090006@oracle.com>
Message-ID: <54DCBE75.1070600@Oracle.com>

Hi Lev,

ok, looks fine,

I'll sponsor it and push it.

Roger

On 2/12/2015 11:56 AM, Lev Priima wrote:
> Christos,
>
> Test may fail on shorter arrays(page 8 of paper). For instance, on 
> worst case, generated by test, it starts to fail on length 67108864.
> After increasing stack size of runs to merge, Arrays.sort(T[]) works 
> also on maximum possible array for HotSpot JVM.
>
>
> Roger, David,
> I've updated the test ( 
> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html 
> ) to make it more suitable for regular execution:
>    27  * @run main/othervm TimSortStackSize2 67108864
>    28  * not for regular execution on all platforms:
>    29  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>    30  * run main/othervm -Xmx32g TimSortStackSize2 2147483644
> Could you please push this:
> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
> ?
> Lev
> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>> On Feb 12,  9:57pm,david.holmes at oracle.com  (David Holmes) wrote:
>> -- Subject: Re: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on
>>
>> | Ok - thanks Lev!
>> |
>> | David
>>
>> For posterity can someone document this, and also the value for which
>> Integer.MAX_VALUE-4 fails?
>>
>> christos
>



From paul.sandoz at oracle.com  Thu Feb 12 15:06:42 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Feb 2015 16:06:42 +0100
Subject: RFR 8071600: Add a flat-mapping collector
In-Reply-To: <DDE5F156-3358-4A2B-B62D-23F74F3237D5@oracle.com>
References: <517DF5B9-E3C5-4CD9-A04A-AC06EBD61517@oracle.com>
	<DDE5F156-3358-4A2B-B62D-23F74F3237D5@oracle.com>
Message-ID: <FE45991E-4130-47FE-9773-215BB3BDC52D@oracle.com>


On Feb 12, 2015, at 3:33 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> On 3 Feb 2015, at 13:48, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
>> Hi,
>> 
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping/webrev/
> 
> Looks like a useful addition.
> 

Thanks.


> Trivially, the handling of null caught my eye: "If a mapped stream is {@code null} an empty stream is used, instead.?  It looks like the result of the mapper function returning null is equivalent to it returning an empty stream, but I?m not sure that I see an empty stream being used in the implementation.

Right, and the caller cannot tell the difference, since in either case no elements will be pushed downstream.


> Is this just a convenience, for implementers of the mapping function? 
> 

Yes, the sentence makes most sense in the context of what comes before it.

Paul.


From lev.priima at oracle.com  Thu Feb 12 18:26:32 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Thu, 12 Feb 2015 18:26:32 +0000
Subject: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on
	arrays longer than 1073741824
In-Reply-To: <54DCBE75.1070600@Oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>
	<54DCDB2D.3090006@oracle.com> <54DCBE75.1070600@Oracle.com>
Message-ID: <54DCF058.2060008@oracle.com>

Thanks!

Lev

On 02/12/2015 02:53 PM, Roger Riggs wrote:
> Hi Lev,
>
> ok, looks fine,
>
> I'll sponsor it and push it.
>
> Roger
>
> On 2/12/2015 11:56 AM, Lev Priima wrote:
>> Christos,
>>
>> Test may fail on shorter arrays(page 8 of paper). For instance, on 
>> worst case, generated by test, it starts to fail on length 67108864.
>> After increasing stack size of runs to merge, Arrays.sort(T[]) works 
>> also on maximum possible array for HotSpot JVM.
>>
>>
>> Roger, David,
>> I've updated the test ( 
>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html 
>> ) to make it more suitable for regular execution:
>>    27  * @run main/othervm TimSortStackSize2 67108864
>>    28  * not for regular execution on all platforms:
>>    29  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>    30  * run main/othervm -Xmx32g TimSortStackSize2 2147483644
>> Could you please push this:
>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>> ?
>> Lev
>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>> On Feb 12,  9:57pm,david.holmes at oracle.com  (David Holmes) wrote:
>>> -- Subject: Re: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on
>>>
>>> | Ok - thanks Lev!
>>> |
>>> | David
>>>
>>> For posterity can someone document this, and also the value for which
>>> Integer.MAX_VALUE-4 fails?
>>>
>>> christos
>>
>



From brian.burkhalter at oracle.com  Thu Feb 12 15:37:24 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 12 Feb 2015 07:37:24 -0800
Subject: [9] RFC JDK-8068373: (prefs) FileSystemPreferences writes \0 to
	XML storage, causing loss of all preferences
In-Reply-To: <47F7C751-6C85-438E-A9A9-3FB11422691C@oracle.com>
References: <D0C3D711-ACF0-46AB-8B06-6BB7ECDE6FC2@oracle.com>
	<47F7C751-6C85-438E-A9A9-3FB11422691C@oracle.com>
Message-ID: <9040AA72-E50B-48FF-905B-1BE4FABFB977@oracle.com>

Hi Paul,

On Feb 12, 2015, at 4:37 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> What do existing XML APIs do?

This is a morass and I hope that someone more apt to know it well would comment. The U+0000 null control character is always illegal though I do know that.

> My guess from looking at your webrev APIs such as DOM allow such invalid characters when writing and reading? If so that would seem to be more of a fundamental issue with those APIs and not specifically with preferences.

I tend to agree where the DOM does allow the characters: they should be handled.

> I think there should be an error if a key or value contains a the U+0000 character when writing out the set of property entries to XML, otherwise it just propagates the error to who or what is consuming that XML file.

The problem is that on OSX and Windows prefs are not stored to XML whereas on Unix they are. That would make it an error to add such a value to the prefs on some platforms but not on others.

Thanks,

Brian

From peter.levart at gmail.com  Thu Feb 12 15:51:27 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Feb 2015 16:51:27 +0100
Subject: RFR 8071600: Add a flat-mapping collector
In-Reply-To: <517DF5B9-E3C5-4CD9-A04A-AC06EBD61517@oracle.com>
References: <517DF5B9-E3C5-4CD9-A04A-AC06EBD61517@oracle.com>
Message-ID: <54DCCBFF.4090501@gmail.com>


On 02/03/2015 02:48 PM, Paul Sandoz wrote:
> Hi,
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping/webrev/
>
> This patch adds a new flat mapping collector to Collectors. This can be useful if one needs to map 0 or more items into a downstream collector.
>
> A CCC will be filed.
>
> A following patch, which i plan to fold into the above patch, performs some renames on the collectors test to be consistent with the current naming:
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping-test-rename/webrev/
>
> Thanks,
> Paul.

Hi Paul,

Would the following "optimization" make any sense?

     public static <T, U, A, R>
     Collector<T, ?, R> flatMapping(Function<? super T, ? extends 
Stream<? extends U>> mapper,
                                    Collector<? super U, A, R> downstream) {
         BiConsumer<A, ? super U> downstreamAccumulator = 
downstream.accumulator();
         return new CollectorImpl<>(downstream.supplier(),
             (r, t) -> {
                 try (Stream<? extends U> result = mapper.apply(t)) {
                     if (result != null) {
                         ((result.isParallel() &&
!downstream.characteristics().contains(Collector.Characteristics.CONCURRENT))
                             ? result.sequential() : result).forEach(u 
-> downstreamAccumulator.accept(r, u));
                     }
                 }
             },
             downstream.combiner(), downstream.finisher(),
             downstream.characteristics());
     }


Regards, Peter



From peter.levart at gmail.com  Thu Feb 12 16:05:42 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Feb 2015 17:05:42 +0100
Subject: RFR 8071600: Add a flat-mapping collector
In-Reply-To: <54DCCBFF.4090501@gmail.com>
References: <517DF5B9-E3C5-4CD9-A04A-AC06EBD61517@oracle.com>
	<54DCCBFF.4090501@gmail.com>
Message-ID: <54DCCF56.7050402@gmail.com>


On 02/12/2015 04:51 PM, Peter Levart wrote:
>
> On 02/03/2015 02:48 PM, Paul Sandoz wrote:
>> Hi,
>>
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping/webrev/
>>
>> This patch adds a new flat mapping collector to Collectors. This can be useful if one needs to map 0 or more items into a downstream collector.
>>
>> A CCC will be filed.
>>
>> A following patch, which i plan to fold into the above patch, performs some renames on the collectors test to be consistent with the current naming:
>>
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071600-Collector-flatMapping-test-rename/webrev/
>>
>> Thanks,
>> Paul.
>
> Hi Paul,
>
> Would the following "optimization" make any sense?
>
>     public static <T, U, A, R>
>     Collector<T, ?, R> flatMapping(Function<? super T, ? extends 
> Stream<? extends U>> mapper,
>                                    Collector<? super U, A, R> 
> downstream) {
>         BiConsumer<A, ? super U> downstreamAccumulator = 
> downstream.accumulator();
>         return new CollectorImpl<>(downstream.supplier(),
>             (r, t) -> {
>                 try (Stream<? extends U> result = mapper.apply(t)) {
>                     if (result != null) {
>                         ((result.isParallel() &&
> !downstream.characteristics().contains(Collector.Characteristics.CONCURRENT))
>                             ? result.sequential() : result).forEach(u 
> -> downstreamAccumulator.accept(r, u));
>                     }
>                 }
>             },
>             downstream.combiner(), downstream.finisher(),
>             downstream.characteristics());
>     }
>
>
> Regards, Peter
>

Collector does not know how it is being used by the feeding Stream in 
advance, right? I guess above "optimization" would only make sense if 
the feeding Stream was sequential and flat-mapping function returned a 
parallel stream and the downstream Collector supported CONCURRENT 
collecting. But if feeding Stream is already parallel and Collector 
supports CONCURRENT collecting, then accumulating function is already 
being invoked in multiple threads and expanding each invocation into 
separate concurrent tasks would make FJ pool execute more tasks (nested 
parallelism). I don't know if this works best currently.

Peter



From paul.sandoz at oracle.com  Thu Feb 12 16:07:55 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Feb 2015 17:07:55 +0100
Subject: RFR 8071600: Add a flat-mapping collector
In-Reply-To: <54DCCBFF.4090501@gmail.com>
References: <517DF5B9-E3C5-4CD9-A04A-AC06EBD61517@oracle.com>
	<54DCCBFF.4090501@gmail.com>
Message-ID: <FEF5C5C7-5EA7-461C-BDA2-00C207DC8003@oracle.com>

On Feb 12, 2015, at 4:51 PM, Peter Levart <peter.levart at gmail.com> wrote:
> Hi Paul,
> 
> Would the following "optimization" make any sense?
> 
>     public static <T, U, A, R>
>     Collector<T, ?, R> flatMapping(Function<? super T, ? extends Stream<? extends U>> mapper,
>                                    Collector<? super U, A, R> downstream) {
>         BiConsumer<A, ? super U> downstreamAccumulator = downstream.accumulator();
>         return new CollectorImpl<>(downstream.supplier(),
>             (r, t) -> {
>                 try (Stream<? extends U> result = mapper.apply(t)) {
>                     if (result != null) {
>                         ((result.isParallel() &&
>                             !downstream.characteristics().contains(Collector.Characteristics.CONCURRENT))
>                             ? result.sequential() : result).forEach(u -> downstreamAccumulator.accept(r, u));
>                     }
>                 }
>             },
>             downstream.combiner(), downstream.finisher(),
>             downstream.characteristics());
>     }
> 

Ah, interesting.

Possibly... i need to think thought the implications on stream and collectors (groupingByConcurrent does the right thing for a non-concurrent downstream collector and synchronizes on the accumulation).

Do you mind if i treat that as a separate issue?

Thanks,
Paul.


From peter.levart at gmail.com  Thu Feb 12 16:12:10 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Feb 2015 17:12:10 +0100
Subject: RFR 8071600: Add a flat-mapping collector
In-Reply-To: <FEF5C5C7-5EA7-461C-BDA2-00C207DC8003@oracle.com>
References: <517DF5B9-E3C5-4CD9-A04A-AC06EBD61517@oracle.com>	<54DCCBFF.4090501@gmail.com>
	<FEF5C5C7-5EA7-461C-BDA2-00C207DC8003@oracle.com>
Message-ID: <54DCD0DA.2080005@gmail.com>


On 02/12/2015 05:07 PM, Paul Sandoz wrote:
> On Feb 12, 2015, at 4:51 PM, Peter Levart <peter.levart at gmail.com> wrote:
>> Hi Paul,
>>
>> Would the following "optimization" make any sense?
>>
>>      public static <T, U, A, R>
>>      Collector<T, ?, R> flatMapping(Function<? super T, ? extends Stream<? extends U>> mapper,
>>                                     Collector<? super U, A, R> downstream) {
>>          BiConsumer<A, ? super U> downstreamAccumulator = downstream.accumulator();
>>          return new CollectorImpl<>(downstream.supplier(),
>>              (r, t) -> {
>>                  try (Stream<? extends U> result = mapper.apply(t)) {
>>                      if (result != null) {
>>                          ((result.isParallel() &&
>>                              !downstream.characteristics().contains(Collector.Characteristics.CONCURRENT))
>>                              ? result.sequential() : result).forEach(u -> downstreamAccumulator.accept(r, u));
>>                      }
>>                  }
>>              },
>>              downstream.combiner(), downstream.finisher(),
>>              downstream.characteristics());
>>      }
>>
> Ah, interesting.
>
> Possibly... i need to think thought the implications on stream and collectors (groupingByConcurrent does the right thing for a non-concurrent downstream collector and synchronizes on the accumulation).
>
> Do you mind if i treat that as a separate issue?

I don't mind, of course. It was just a thought.

Regards, Peter

> Thanks,
> Paul.



From paul.sandoz at oracle.com  Thu Feb 12 16:18:47 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Feb 2015 17:18:47 +0100
Subject: [9] RFC JDK-8068373: (prefs) FileSystemPreferences writes \0 to
	XML storage, causing loss of all preferences
In-Reply-To: <9040AA72-E50B-48FF-905B-1BE4FABFB977@oracle.com>
References: <D0C3D711-ACF0-46AB-8B06-6BB7ECDE6FC2@oracle.com>
	<47F7C751-6C85-438E-A9A9-3FB11422691C@oracle.com>
	<9040AA72-E50B-48FF-905B-1BE4FABFB977@oracle.com>
Message-ID: <BF28E4F1-A8D3-4CCB-9EC2-D47BA995D99B@oracle.com>


On Feb 12, 2015, at 4:37 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> Hi Paul,
> 
> On Feb 12, 2015, at 4:37 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
>> What do existing XML APIs do?
> 
> This is a morass and I hope that someone more apt to know it well would comment. The U+0000 null control character is always illegal though I do know that.

Yes. IIRC XML 1.1 basically allows any character except U+0000.


> 
>> My guess from looking at your webrev APIs such as DOM allow such invalid characters when writing and reading? If so that would seem to be more of a fundamental issue with those APIs and not specifically with preferences.
> 
> I tend to agree where the DOM does allow the characters: they should be handled.
> 
>> I think there should be an error if a key or value contains a the U+0000 character when writing out the set of property entries to XML, otherwise it just propagates the error to who or what is consuming that XML file.
> 
> The problem is that on OSX and Windows prefs are not stored to XML

What are they stored in? name/value pairs?


> whereas on Unix they are.

Is that a specification requirement?


> That would make it an error to add such a value to the prefs on some platforms but not on others.
> 

Yes, for an interoperable format potentially read by other tools having U+0000 is a really bad idea.

My inclination is if properties are written out to a text file then it should fail if a key/value contains U+0000 (Binary data should be base64 encoded in such cases.) Replacing just subtlety hides or defers the issue.

Paul.


From brian.burkhalter at oracle.com  Thu Feb 12 16:27:37 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 12 Feb 2015 08:27:37 -0800
Subject: [9] RFC JDK-8068373: (prefs) FileSystemPreferences writes \0 to
	XML storage, causing loss of all preferences
In-Reply-To: <BF28E4F1-A8D3-4CCB-9EC2-D47BA995D99B@oracle.com>
References: <D0C3D711-ACF0-46AB-8B06-6BB7ECDE6FC2@oracle.com>
	<47F7C751-6C85-438E-A9A9-3FB11422691C@oracle.com>
	<9040AA72-E50B-48FF-905B-1BE4FABFB977@oracle.com>
	<BF28E4F1-A8D3-4CCB-9EC2-D47BA995D99B@oracle.com>
Message-ID: <6C59E114-35DB-410E-8568-62648844BF55@oracle.com>


On Feb 12, 2015, at 8:18 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>> This is a morass and I hope that someone more apt to know it well would comment. The U+0000 null control character is always illegal though I do know that.
> 
> Yes. IIRC XML 1.1 basically allows any character except U+0000.

"Note that the code point U+0000, assigned to the null control character, is the only character encoded in Unicode and ISO/IEC 10646 that is always invalid in any XML 1.0 and 1.1 document."

http://en.wikipedia.org/wiki/Valid_characters_in_XML#Characters_allowed_but_discouraged

>> 
>> The problem is that on OSX and Windows prefs are not stored to XML
> 
> What are they stored in? name/value pairs?

Yes. On OSX I think Property List (.plist) files; on Windows I do not know yet.

>> whereas on Unix they are.
> 
> Is that a specification requirement?

No, I think it?s an artifact of no inherent DB-like facility in the system.

>> That would make it an error to add such a value to the prefs on some platforms but not on others.
> 
> Yes, for an interoperable format potentially read by other tools having U+0000 is a really bad idea.

Yep.

> My inclination is if properties are written out to a text file then it should fail if a key/value contains U+0000 (Binary data should be base64 encoded in such cases.) Replacing just subtlety hides or defers the issue.

That was my original idea  \in fact (webrev.00, unpublished). It would however require a spec update to

http://docs.oracle.com/javase/8/docs/api/java/util/prefs/Preferences.html#put-java.lang.String-java.lang.String-

to allow for an IAE in this case. This would also be a backward-incompatible change for platforms which do allow storing such values.

Note that a similar situation applies to Properties.

Thanks,

Brian

From Roger.Riggs at Oracle.com  Thu Feb 12 17:13:30 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 12 Feb 2015 12:13:30 -0500
Subject: [9] RFC JDK-8068373: (prefs) FileSystemPreferences writes \0
	to XML storage, causing loss of all preferences
In-Reply-To: <6C59E114-35DB-410E-8568-62648844BF55@oracle.com>
References: <D0C3D711-ACF0-46AB-8B06-6BB7ECDE6FC2@oracle.com>	<47F7C751-6C85-438E-A9A9-3FB11422691C@oracle.com>	<9040AA72-E50B-48FF-905B-1BE4FABFB977@oracle.com>	<BF28E4F1-A8D3-4CCB-9EC2-D47BA995D99B@oracle.com>
	<6C59E114-35DB-410E-8568-62648844BF55@oracle.com>
Message-ID: <54DCDF3A.4010108@Oracle.com>

Hi Brian,

I think its worth the overhead of cleaning up the spec and
the backward compatibility risk is low given the XML restriction.
(Though perhaps not directly back-portable to 8 without the spec change)

Roger

On 2/12/2015 11:27 AM, Brian Burkhalter wrote:
> On Feb 12, 2015, at 8:18 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>
>>> This is a morass and I hope that someone more apt to know it well would comment. The U+0000 null control character is always illegal though I do know that.
>> Yes. IIRC XML 1.1 basically allows any character except U+0000.
> "Note that the code point U+0000, assigned to the null control character, is the only character encoded in Unicode and ISO/IEC 10646 that is always invalid in any XML 1.0 and 1.1 document."
>
> http://en.wikipedia.org/wiki/Valid_characters_in_XML#Characters_allowed_but_discouraged
>
>>> The problem is that on OSX and Windows prefs are not stored to XML
>> What are they stored in? name/value pairs?
> Yes. On OSX I think Property List (.plist) files; on Windows I do not know yet.
>
>>> whereas on Unix they are.
>> Is that a specification requirement?
> No, I think it?s an artifact of no inherent DB-like facility in the system.
>
>>> That would make it an error to add such a value to the prefs on some platforms but not on others.
>> Yes, for an interoperable format potentially read by other tools having U+0000 is a really bad idea.
> Yep.
>
>> My inclination is if properties are written out to a text file then it should fail if a key/value contains U+0000 (Binary data should be base64 encoded in such cases.) Replacing just subtlety hides or defers the issue.
> That was my original idea  \in fact (webrev.00, unpublished). It would however require a spec update to
>
> http://docs.oracle.com/javase/8/docs/api/java/util/prefs/Preferences.html#put-java.lang.String-java.lang.String-
>
> to allow for an IAE in this case. This would also be a backward-incompatible change for platforms which do allow storing such values.
>
> Note that a similar situation applies to Properties.
>
> Thanks,
>
> Brian



From paul.sandoz at oracle.com  Thu Feb 12 17:29:12 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Feb 2015 18:29:12 +0100
Subject: [9] RFC JDK-8068373: (prefs) FileSystemPreferences writes \0 to
	XML storage, causing loss of all preferences
In-Reply-To: <6C59E114-35DB-410E-8568-62648844BF55@oracle.com>
References: <D0C3D711-ACF0-46AB-8B06-6BB7ECDE6FC2@oracle.com>
	<47F7C751-6C85-438E-A9A9-3FB11422691C@oracle.com>
	<9040AA72-E50B-48FF-905B-1BE4FABFB977@oracle.com>
	<BF28E4F1-A8D3-4CCB-9EC2-D47BA995D99B@oracle.com>
	<6C59E114-35DB-410E-8568-62648844BF55@oracle.com>
Message-ID: <28AA4E2C-49D2-4474-AAD9-C88145BBA096@oracle.com>


On Feb 12, 2015, at 5:27 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> 
> On Feb 12, 2015, at 8:18 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
>>> This is a morass and I hope that someone more apt to know it well would comment. The U+0000 null control character is always illegal though I do know that.
>> 
>> Yes. IIRC XML 1.1 basically allows any character except U+0000.
> 
> "Note that the code point U+0000, assigned to the null control character, is the only character encoded in Unicode and ISO/IEC 10646 that is always invalid in any XML 1.0 and 1.1 document."
> 
> http://en.wikipedia.org/wiki/Valid_characters_in_XML#Characters_allowed_but_discouraged
> 
>>> 
>>> The problem is that on OSX and Windows prefs are not stored to XML
>> 
>> What are they stored in? name/value pairs?
> 
> Yes. On OSX I think Property List (.plist) files; on Windows I do not know yet.
> 
>>> whereas on Unix they are.
>> 
>> Is that a specification requirement?
> 
> No, I think it?s an artifact of no inherent DB-like facility in the system.
> 
>>> That would make it an error to add such a value to the prefs on some platforms but not on others.
>> 
>> Yes, for an interoperable format potentially read by other tools having U+0000 is a really bad idea.
> 
> Yep.
> 

And i think that applies to plist files too.


>> My inclination is if properties are written out to a text file then it should fail if a key/value contains U+0000 (Binary data should be base64 encoded in such cases.) Replacing just subtlety hides or defers the issue.
> 
> That was my original idea  \in fact (webrev.00, unpublished). It would however require a spec update to
> 
> http://docs.oracle.com/javase/8/docs/api/java/util/prefs/Preferences.html#put-java.lang.String-java.lang.String-
> 
> to allow for an IAE in this case. This would also be a backward-incompatible change for platforms which do allow storing such values.
> 

> Note that a similar situation applies to Properties.
> 

My recommendation is serialization of properties to any textual format should barf if a U+0000 is encountered. Otherwise it's just hiding bugs. In such cases i think there is a strong justification to introduce such an incompatible change. I except it is rare to encounter in practice.

Paul.


From brian.burkhalter at oracle.com  Thu Feb 12 17:36:11 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 12 Feb 2015 09:36:11 -0800
Subject: [9] RFC JDK-8068373: (prefs) FileSystemPreferences writes \0 to
	XML storage, causing loss of all preferences
In-Reply-To: <28AA4E2C-49D2-4474-AAD9-C88145BBA096@oracle.com>
References: <D0C3D711-ACF0-46AB-8B06-6BB7ECDE6FC2@oracle.com>
	<47F7C751-6C85-438E-A9A9-3FB11422691C@oracle.com>
	<9040AA72-E50B-48FF-905B-1BE4FABFB977@oracle.com>
	<BF28E4F1-A8D3-4CCB-9EC2-D47BA995D99B@oracle.com>
	<6C59E114-35DB-410E-8568-62648844BF55@oracle.com>
	<28AA4E2C-49D2-4474-AAD9-C88145BBA096@oracle.com>
Message-ID: <102DFFA7-089B-4088-BEC5-25B97EC41DAF@oracle.com>


On Feb 12, 2015, at 9:29 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>>> Yes, for an interoperable format potentially read by other tools having U+0000 is a really bad idea.
>> 
>> Yep.
>> 
> 
> And i think that applies to plist files too.

I cannot confirm but I heard otherwise. I?ll test it.

>>> My inclination is if properties are written out to a text file then it should fail if a key/value contains U+0000 (Binary data should be base64 encoded in such cases.) Replacing just subtlety hides or defers the issue.
>> 
>> That was my original idea  \in fact (webrev.00, unpublished). It would however require a spec update to
>> 
>> http://docs.oracle.com/javase/8/docs/api/java/util/prefs/Preferences.html#put-java.lang.String-java.lang.String-
>> 
>> to allow for an IAE in this case. This would also be a backward-incompatible change for platforms which do allow storing such values.
>> 
> 
>> Note that a similar situation applies to Properties.
> 
> My recommendation is serialization of properties to any textual format should barf if a U+0000 is encountered. Otherwise it's just hiding bugs. In such cases i think there is a strong justification to introduce such an incompatible change. I except it is rare to encounter in practice.

I cannot argue with that. I will revise and re-post the patch and see what the consensus says.

Thanks for the input.

Brian

From paul.sandoz at oracle.com  Thu Feb 12 17:50:53 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Feb 2015 18:50:53 +0100
Subject: RFR 8071670: java.util.Optional: please add a way to specify
	if-else behavior
In-Reply-To: <54DCBD9E.9000007@oracle.com>
References: <0A89199D-AFFA-4A90-B76F-D8BFAC75748A@oracle.com>
	<54DCBD9E.9000007@oracle.com>
Message-ID: <5F415F66-5787-4441-A0FD-06D8B3AD61EC@oracle.com>


On Feb 12, 2015, at 3:50 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> Hi Paul,
> 
> This looks good - I have noticed one copy/paste error in the javadoc
> though:
> 
> OptionalInt.java:
> 
> looks like the throws clause of ifPresent and ifPresentOrElse have been
> interverted:
> 
> 138      * @throws NullPointerException if a value is present and {@code action} is
> 139      * null, or a value is not present and {@code emptyAction} is null.
> 140      */
> 141     public void ifPresent(IntConsumer action) {
> 142         if (isPresent) {
> 143             action.accept(value);
> 144         }
> 145     }
> 146
> 147     /**
> 148      * If a value is present, perform the given action with the value,
> 149      * otherwise perform the given empty-based action.
> 150      *
> 151      * @param action the action to be performed if a value is present
> 152      * @param emptyAction the empty-based action to be performed if a value is
> 153      * not present
> 154      * @throws NullPointerException if value is present and {@code action} is
> 155      * null
> 156      * @since 1.9
> 157      */
> 158     public void ifPresentOrElse(IntConsumer action, Runnable emptyAction) {
> 

Oops. Fixed.


> 
> Concerning the test, should there be a test that verifies that NPE
> is thrown when null is passed - as specified in the javadoc?
> 

Done.

http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071670-Optional-ifPresentOrElse/webrev/

Thanks,
Paul.


From christos at zoulas.com  Thu Feb 12 17:53:25 2015
From: christos at zoulas.com (Christos Zoulas)
Date: Thu, 12 Feb 2015 12:53:25 -0500
Subject: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on
	arrays longer than 1073741824
In-Reply-To: <54DCDB2D.3090006@oracle.com> from Lev Priima (Feb 12,  4:56pm)
Message-ID: <20150212175325.417AF17FDAA@rebar.astron.com>

On Feb 12,  4:56pm, lev.priima at oracle.com (Lev Priima) wrote:
-- Subject: Re: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on

| Christos,
| 
| Test may fail on shorter arrays(page 8 of paper). For instance, on worst 
| case, generated by test, it starts to fail on length 67108864.
| After increasing stack size of runs to merge, Arrays.sort(T[]) works 
| also on maximum possible array for HotSpot JVM.
| 
| 
| Roger, David,
| I've updated the test ( 
| http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html 
| ) to make it more suitable for regular execution:
| 
|    27  * @run main/othervm TimSortStackSize2 67108864
|    28  * not for regular execution on all platforms:
|    29  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
|    30  * run main/othervm -Xmx32g TimSortStackSize2 2147483644
| 
| Could you please push this:
| http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
| ?
| 

Thanks for the explanation Lev!

christos


From brian.burkhalter at oracle.com  Thu Feb 12 17:55:47 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 12 Feb 2015 09:55:47 -0800
Subject: [9] RFC JDK-8068373: (prefs) FileSystemPreferences writes \0 to
	XML storage, causing loss of all preferences
In-Reply-To: <54DCDF3A.4010108@Oracle.com>
References: <D0C3D711-ACF0-46AB-8B06-6BB7ECDE6FC2@oracle.com>	<47F7C751-6C85-438E-A9A9-3FB11422691C@oracle.com>	<9040AA72-E50B-48FF-905B-1BE4FABFB977@oracle.com>	<BF28E4F1-A8D3-4CCB-9EC2-D47BA995D99B@oracle.com>
	<6C59E114-35DB-410E-8568-62648844BF55@oracle.com>
	<54DCDF3A.4010108@Oracle.com>
Message-ID: <689A8782-1AC5-4796-A441-7E4BB48914C7@oracle.com>

Hi Roger,

That has been my thought all along. Dealing with the forward and backward compatibility issues and with what might be acceptable for .plist files vs. XML does not seem worth the overhead by comparison.

Thanks,

Brian

On Feb 12, 2015, at 9:13 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> I think its worth the overhead of cleaning up the spec and
> the backward compatibility risk is low given the XML restriction.
> (Though perhaps not directly back-portable to 8 without the spec change)



From lowasser at google.com  Thu Feb 12 18:00:31 2015
From: lowasser at google.com (Louis Wasserman)
Date: Thu, 12 Feb 2015 18:00:31 +0000
Subject: RFR 8071670: java.util.Optional: please add a way to specify
	if-else behavior
References: <0A89199D-AFFA-4A90-B76F-D8BFAC75748A@oracle.com>
	<54DCBD9E.9000007@oracle.com>
	<5F415F66-5787-4441-A0FD-06D8B3AD61EC@oracle.com>
Message-ID: <CAGB9EW9UpMwSaP_+M4Uqs5G+u02vQjeBu4gfXTba-gyk-Rr=BQ@mail.gmail.com>

How often does the case when you "have a lambda handy already" come up in
practice?  If this leads to people using this method instead of ifPresent,
that seems wasteful.

Guava's Optional succeeded as much for what it left out as what it had in
-- I confess this makes me nervous that j.u.Optional is becoming a kitchen
sink.

On Thu Feb 12 2015 at 9:51:23 AM Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> On Feb 12, 2015, at 3:50 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>
> > Hi Paul,
> >
> > This looks good - I have noticed one copy/paste error in the javadoc
> > though:
> >
> > OptionalInt.java:
> >
> > looks like the throws clause of ifPresent and ifPresentOrElse have been
> > interverted:
> >
> > 138      * @throws NullPointerException if a value is present and {@code
> action} is
> > 139      * null, or a value is not present and {@code emptyAction} is
> null.
> > 140      */
> > 141     public void ifPresent(IntConsumer action) {
> > 142         if (isPresent) {
> > 143             action.accept(value);
> > 144         }
> > 145     }
> > 146
> > 147     /**
> > 148      * If a value is present, perform the given action with the
> value,
> > 149      * otherwise perform the given empty-based action.
> > 150      *
> > 151      * @param action the action to be performed if a value is present
> > 152      * @param emptyAction the empty-based action to be performed if
> a value is
> > 153      * not present
> > 154      * @throws NullPointerException if value is present and {@code
> action} is
> > 155      * null
> > 156      * @since 1.9
> > 157      */
> > 158     public void ifPresentOrElse(IntConsumer action, Runnable
> emptyAction) {
> >
>
> Oops. Fixed.
>
>
> >
> > Concerning the test, should there be a test that verifies that NPE
> > is thrown when null is passed - as specified in the javadoc?
> >
>
> Done.
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071670-
> Optional-ifPresentOrElse/webrev/
>
> Thanks,
> Paul.
>


From paul.sandoz at oracle.com  Thu Feb 12 18:15:07 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Feb 2015 19:15:07 +0100
Subject: RFR 8071670: java.util.Optional: please add a way to specify
	if-else behavior
In-Reply-To: <CAGB9EW9UpMwSaP_+M4Uqs5G+u02vQjeBu4gfXTba-gyk-Rr=BQ@mail.gmail.com>
References: <0A89199D-AFFA-4A90-B76F-D8BFAC75748A@oracle.com>
	<54DCBD9E.9000007@oracle.com>
	<5F415F66-5787-4441-A0FD-06D8B3AD61EC@oracle.com>
	<CAGB9EW9UpMwSaP_+M4Uqs5G+u02vQjeBu4gfXTba-gyk-Rr=BQ@mail.gmail.com>
Message-ID: <0FFAF2C9-DB10-484F-9CE3-EBFF48547136@oracle.com>


On Feb 12, 2015, at 7:00 PM, Louis Wasserman <lowasser at google.com> wrote:

> How often does the case when you "have a lambda handy already" come up in practice?  If this leads to people using this method instead of ifPresent, that seems wasteful.
> 

A lambda bearing ifPresent is already "present" (sorry!) :-) this is just filling it out to be consistent for a terminal operation with an empty action.


> Guava's Optional succeeded as much for what it left out as what it had in -- I confess this makes me nervous that j.u.Optional is becoming a kitchen sink.
> 

Yes, i most definitely share this concern. I have already closed a few optional issues as will not fix. FWIW I don't plan on adding any more stuff.

Paul.


From lowasser at google.com  Thu Feb 12 18:27:10 2015
From: lowasser at google.com (Louis Wasserman)
Date: Thu, 12 Feb 2015 18:27:10 +0000
Subject: RFR 8071670: java.util.Optional: please add a way to specify
	if-else behavior
References: <0A89199D-AFFA-4A90-B76F-D8BFAC75748A@oracle.com>
	<54DCBD9E.9000007@oracle.com>
	<5F415F66-5787-4441-A0FD-06D8B3AD61EC@oracle.com>
	<CAGB9EW9UpMwSaP_+M4Uqs5G+u02vQjeBu4gfXTba-gyk-Rr=BQ@mail.gmail.com>
	<0FFAF2C9-DB10-484F-9CE3-EBFF48547136@oracle.com>
Message-ID: <CAGB9EW9uTaGOE8wFye+qsutFskEWUOb8eK+d4PyLkEknhcfZ+Q@mail.gmail.com>

I get that ifPresent is already available; I'm curious if you examined how
often there is actually an "if absent" case in practice, relative to the
"only do something if present" case.

If you don't have statistics, I could fairly easily get statistics on
Google's codebase for what usages of Guava's Optional look like, in terms
of how often

if (optional.isPresent()) {
   ...
} else {
   ...
}

occurs, relative to

if (optional.isPresent()) {
  ...
}
// no else

On Thu Feb 12 2015 at 10:15:45 AM Paul Sandoz <paul.sandoz at oracle.com>
wrote:

>
> On Feb 12, 2015, at 7:00 PM, Louis Wasserman <lowasser at google.com> wrote:
>
> > How often does the case when you "have a lambda handy already" come up
> in practice?  If this leads to people using this method instead of
> ifPresent, that seems wasteful.
> >
>
> A lambda bearing ifPresent is already "present" (sorry!) :-) this is just
> filling it out to be consistent for a terminal operation with an empty
> action.
>
>
> > Guava's Optional succeeded as much for what it left out as what it had
> in -- I confess this makes me nervous that j.u.Optional is becoming a
> kitchen sink.
> >
>
> Yes, i most definitely share this concern. I have already closed a few
> optional issues as will not fix. FWIW I don't plan on adding any more stuff.
>
> Paul.
>


From paul.sandoz at oracle.com  Thu Feb 12 18:34:30 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Feb 2015 19:34:30 +0100
Subject: RFR 8071670: java.util.Optional: please add a way to specify
	if-else behavior
In-Reply-To: <CAGB9EW9uTaGOE8wFye+qsutFskEWUOb8eK+d4PyLkEknhcfZ+Q@mail.gmail.com>
References: <0A89199D-AFFA-4A90-B76F-D8BFAC75748A@oracle.com>
	<54DCBD9E.9000007@oracle.com>
	<5F415F66-5787-4441-A0FD-06D8B3AD61EC@oracle.com>
	<CAGB9EW9UpMwSaP_+M4Uqs5G+u02vQjeBu4gfXTba-gyk-Rr=BQ@mail.gmail.com>
	<0FFAF2C9-DB10-484F-9CE3-EBFF48547136@oracle.com>
	<CAGB9EW9uTaGOE8wFye+qsutFskEWUOb8eK+d4PyLkEknhcfZ+Q@mail.gmail.com>
Message-ID: <1C4E8B1B-7460-4A09-8E3D-36FE3CD0E342@oracle.com>

On Feb 12, 2015, at 7:27 PM, Louis Wasserman <lowasser at google.com> wrote:
> I get that ifPresent is already available; I'm curious if you examined how often there is actually an "if absent" case in practice, relative to the "only do something if present" case.
> 
> If you don't have statistics,

No, since this is still somewhat new. The evaluation was more based on the principle when this is required it is currently rather awkward.


> I could fairly easily get statistics on Google's codebase for what usages of Guava's Optional look like, in terms of how often
> 
> if (optional.isPresent()) {
>    ...
> } else {
>    ...
> }
> 
> occurs, relative to
> 
> if (optional.isPresent()) {
>   ...
> }
> // no else
> 

Please, that would be very helpful and interesting.

Thanks,
Paul.


From daniel.fuchs at oracle.com  Thu Feb 12 18:39:45 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 12 Feb 2015 19:39:45 +0100
Subject: RFR 8071670: java.util.Optional: please add a way to specify
	if-else behavior
In-Reply-To: <5F415F66-5787-4441-A0FD-06D8B3AD61EC@oracle.com>
References: <0A89199D-AFFA-4A90-B76F-D8BFAC75748A@oracle.com>	<54DCBD9E.9000007@oracle.com>
	<5F415F66-5787-4441-A0FD-06D8B3AD61EC@oracle.com>
Message-ID: <54DCF371.2060404@oracle.com>

The new version looks good Paul!

-- daniel

On 2/12/15 6:50 PM, Paul Sandoz wrote:
> On Feb 12, 2015, at 3:50 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>
>> Hi Paul,
>>
>> This looks good - I have noticed one copy/paste error in the javadoc
>> though:
>>
>> OptionalInt.java:
>>
>> looks like the throws clause of ifPresent and ifPresentOrElse have been
>> interverted:
>>
>> 138      * @throws NullPointerException if a value is present and {@code action} is
>> 139      * null, or a value is not present and {@code emptyAction} is null.
>> 140      */
>> 141     public void ifPresent(IntConsumer action) {
>> 142         if (isPresent) {
>> 143             action.accept(value);
>> 144         }
>> 145     }
>> 146
>> 147     /**
>> 148      * If a value is present, perform the given action with the value,
>> 149      * otherwise perform the given empty-based action.
>> 150      *
>> 151      * @param action the action to be performed if a value is present
>> 152      * @param emptyAction the empty-based action to be performed if a value is
>> 153      * not present
>> 154      * @throws NullPointerException if value is present and {@code action} is
>> 155      * null
>> 156      * @since 1.9
>> 157      */
>> 158     public void ifPresentOrElse(IntConsumer action, Runnable emptyAction) {
>>
> Oops. Fixed.
>
>
>> Concerning the test, should there be a test that verifies that NPE
>> is thrown when null is passed - as specified in the javadoc?
>>
> Done.
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071670-Optional-ifPresentOrElse/webrev/
>
> Thanks,
> Paul.



From brian.burkhalter at oracle.com  Thu Feb 12 19:00:23 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 12 Feb 2015 11:00:23 -0800
Subject: [9] RFC JDK-8068373: (prefs) FileSystemPreferences writes \0 to
	XML storage, causing loss of all preferences
In-Reply-To: <6C59E114-35DB-410E-8568-62648844BF55@oracle.com>
References: <D0C3D711-ACF0-46AB-8B06-6BB7ECDE6FC2@oracle.com>
	<47F7C751-6C85-438E-A9A9-3FB11422691C@oracle.com>
	<9040AA72-E50B-48FF-905B-1BE4FABFB977@oracle.com>
	<BF28E4F1-A8D3-4CCB-9EC2-D47BA995D99B@oracle.com>
	<6C59E114-35DB-410E-8568-62648844BF55@oracle.com>
Message-ID: <64D0828A-8B0B-47CD-9DE5-A97872C18F71@oracle.com>

Paul,

I retract my statement below. My webrev.00 was this one:

http://cr.openjdk.java.net/~bpb/8068373/webrev.00/

with no API changes. It follows extant style but I do not like it that much. Please compare if you have time with the adding of the IAE to the spec.

Thanks,

Brian

On Feb 12, 2015, at 8:27 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> That was my original idea  \in fact (webrev.00, unpublished). It would however require a spec update to
> 
> http://docs.oracle.com/javase/8/docs/api/java/util/prefs/Preferences.html#put-java.lang.String-java.lang.String-
> 
> to allow for an IAE in this case. This would also be a backward-incompatible change for platforms which do allow storing such values.



From lowasser at google.com  Thu Feb 12 19:29:57 2015
From: lowasser at google.com (Louis Wasserman)
Date: Thu, 12 Feb 2015 19:29:57 +0000
Subject: RFR 8071670: java.util.Optional: please add a way to specify
	if-else behavior
Message-ID: <CAGB9EW-93ffyf6Z4ygF+aNeqJzpahOAmzNBKSXRdzRVG=dfRmw@mail.gmail.com>

I'm not sure I can share hard numbers, but the ratio of

if (optional.isPresent()) {
  // non-returning statements here
}

to

if (optional.isPresent()) { // or negated
  // non-returning statements here
} else {
  // non-returning statements here
}

is ~5.5x in favor of the no-else case.  Both patterns have large numbers of
hits, though, so I'm satisfied that this is not an unreasonable thing to do.

I can possibly try to extract statistics on how many of these cases would
be easily converted to method references and other things that might be
easier to express with functional interfaces, but I'm not sure how
necessary that actually is.


On Thu Feb 12 2015 at 10:40:23 AM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> The new version looks good Paul!
>
> -- daniel
>
> On 2/12/15 6:50 PM, Paul Sandoz wrote:
> > On Feb 12, 2015, at 3:50 PM, Daniel Fuchs <daniel.fuchs at oracle.com>
> wrote:
> >
> >> Hi Paul,
> >>
> >> This looks good - I have noticed one copy/paste error in the javadoc
> >> though:
> >>
> >> OptionalInt.java:
> >>
> >> looks like the throws clause of ifPresent and ifPresentOrElse have been
> >> interverted:
> >>
> >> 138      * @throws NullPointerException if a value is present and
> {@code action} is
> >> 139      * null, or a value is not present and {@code emptyAction} is
> null.
> >> 140      */
> >> 141     public void ifPresent(IntConsumer action) {
> >> 142         if (isPresent) {
> >> 143             action.accept(value);
> >> 144         }
> >> 145     }
> >> 146
> >> 147     /**
> >> 148      * If a value is present, perform the given action with the
> value,
> >> 149      * otherwise perform the given empty-based action.
> >> 150      *
> >> 151      * @param action the action to be performed if a value is
> present
> >> 152      * @param emptyAction the empty-based action to be performed if
> a value is
> >> 153      * not present
> >> 154      * @throws NullPointerException if value is present and {@code
> action} is
> >> 155      * null
> >> 156      * @since 1.9
> >> 157      */
> >> 158     public void ifPresentOrElse(IntConsumer action, Runnable
> emptyAction) {
> >>
> > Oops. Fixed.
> >
> >
> >> Concerning the test, should there be a test that verifies that NPE
> >> is thrown when null is passed - as specified in the javadoc?
> >>
> > Done.
> >
> > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071670-Optiona
> l-ifPresentOrElse/webrev/
> >
> > Thanks,
> > Paul.
>
>


From brian.burkhalter at oracle.com  Thu Feb 12 19:30:33 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 12 Feb 2015 11:30:33 -0800
Subject: [9] RFC JDK-8068373: (prefs) FileSystemPreferences writes \0 to
	XML storage, causing loss of all preferences 
In-Reply-To: <64D0828A-8B0B-47CD-9DE5-A97872C18F71@oracle.com>
References: <D0C3D711-ACF0-46AB-8B06-6BB7ECDE6FC2@oracle.com>
	<47F7C751-6C85-438E-A9A9-3FB11422691C@oracle.com>
	<9040AA72-E50B-48FF-905B-1BE4FABFB977@oracle.com>
	<BF28E4F1-A8D3-4CCB-9EC2-D47BA995D99B@oracle.com>
	<6C59E114-35DB-410E-8568-62648844BF55@oracle.com>
	<64D0828A-8B0B-47CD-9DE5-A97872C18F71@oracle.com>
Message-ID: <35453FF3-C40B-4278-9785-EDB9F0408218@oracle.com>

So I think this is the patch there appeared to be some consensus no in the review thread:

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

(Yeah, I know I forgot once again to update the more recent copyright year - will do before push.)

As a matter of historical (un)interest, the previous patches are available for scrutiny here:

http://cr.openjdk.java.net/~bpb/8068373/

Thanks,

Brian

On Feb 12, 2015, at 11:00 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> I retract my statement below. My webrev.00 was this one:
> 
> http://cr.openjdk.java.net/~bpb/8068373/webrev.00/
> 
> with no API changes. It follows extant style but I do not like it that much. Please compare if you have time with the adding of the IAE to the spec.



From Roger.Riggs at Oracle.com  Thu Feb 12 19:43:46 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 12 Feb 2015 14:43:46 -0500
Subject: [9] RFC JDK-8068373: (prefs) FileSystemPreferences writes \0
	to XML storage, causing loss of all preferences
In-Reply-To: <35453FF3-C40B-4278-9785-EDB9F0408218@oracle.com>
References: <D0C3D711-ACF0-46AB-8B06-6BB7ECDE6FC2@oracle.com>	<47F7C751-6C85-438E-A9A9-3FB11422691C@oracle.com>	<9040AA72-E50B-48FF-905B-1BE4FABFB977@oracle.com>	<BF28E4F1-A8D3-4CCB-9EC2-D47BA995D99B@oracle.com>	<6C59E114-35DB-410E-8568-62648844BF55@oracle.com>	<64D0828A-8B0B-47CD-9DE5-A97872C18F71@oracle.com>
	<35453FF3-C40B-4278-9785-EDB9F0408218@oracle.com>
Message-ID: <54DD0271.90204@Oracle.com>

Hi Brian,

Is there a particular reason to use the String form of contains(String) 
instead of indexOf(int) >= 0?
It seems more natural since the scan is for a single character.
If there is no performance difference then its does not matter.

Will there be a test?

Roger


On 2/12/2015 2:30 PM, Brian Burkhalter wrote:
> So I think this is the patch there appeared to be some consensus no in the review thread:
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8068373
> Patch:	http://cr.openjdk.java.net/~bpb/8068373/webrev.03/
>
> (Yeah, I know I forgot once again to update the more recent copyright year - will do before push.)
>
> As a matter of historical (un)interest, the previous patches are available for scrutiny here:
>
> http://cr.openjdk.java.net/~bpb/8068373/
>
> Thanks,
>
> Brian
>
> On Feb 12, 2015, at 11:00 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
>
>> I retract my statement below. My webrev.00 was this one:
>>
>> http://cr.openjdk.java.net/~bpb/8068373/webrev.00/
>>
>> with no API changes. It follows extant style but I do not like it that much. Please compare if you have time with the adding of the IAE to the spec.



From mark.reinhold at oracle.com  Thu Feb 12 20:41:02 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 12 Feb 2015 12:41:02 -0800 (PST)
Subject: JEP 238: Multi-Version JAR Files
Message-ID: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>

New JEP Candidate: http://openjdk.java.net/jeps/238

- Mark


From paul.sandoz at oracle.com  Thu Feb 12 20:52:26 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Feb 2015 21:52:26 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>
Message-ID: <553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>

Hi

In connection with the JEP there is also a design document to help the discussion:

  http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md

We are especially interesting in hearing feedback from library developers, tool/IDE developers, and anyone doing funky stuff with class loading and JAR files.

Paul.

On Feb 12, 2015, at 9:41 PM, mark.reinhold at oracle.com wrote:

> New JEP Candidate: http://openjdk.java.net/jeps/238
> 
> - Mark



From paul.sandoz at oracle.com  Thu Feb 12 21:01:12 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Feb 2015 22:01:12 +0100
Subject: RFR 8071670: java.util.Optional: please add a way to specify
	if-else behavior
In-Reply-To: <CAGB9EW-93ffyf6Z4ygF+aNeqJzpahOAmzNBKSXRdzRVG=dfRmw@mail.gmail.com>
References: <CAGB9EW-93ffyf6Z4ygF+aNeqJzpahOAmzNBKSXRdzRVG=dfRmw@mail.gmail.com>
Message-ID: <408582DE-C838-4957-9A5E-C3BFC3015EC5@oracle.com>


On Feb 12, 2015, at 8:29 PM, Louis Wasserman <lowasser at google.com> wrote:

> I'm not sure I can share hard numbers, but the ratio of 
> 
> if (optional.isPresent()) {
>   // non-returning statements here
> }
> 
> to 
> 
> if (optional.isPresent()) { // or negated
>   // non-returning statements here
> } else {
>   // non-returning statements here
> }
> 
> is ~5.5x in favor of the no-else case.  Both patterns have large numbers of hits, though, so I'm satisfied that this is not an unreasonable thing to do.

Many thanks, that's good to know.


> 
> I can possibly try to extract statistics on how many of these cases would be easily converted to method references and other things that might be easier to express with functional interfaces, but I'm not sure how necessary that actually is.
> 

It might be interesting, but i would be more curious about the following case:

if (!optional.isPresent()) {
...
}
// no else

would it be possible to get some numbers on that?

Thanks,
Paul.


From brian.burkhalter at oracle.com  Thu Feb 12 21:01:43 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 12 Feb 2015 13:01:43 -0800
Subject: [9] RFR JDK-8068373: (prefs) FileSystemPreferences writes \0 to XML
	storage, causing loss of all preferences 
Message-ID: <E0281603-FEA1-4B5A-9143-40E2D872D6F4@oracle.com>

Hello,

Based on previous discussions this thread which used to be an RFC is now an RFR. Thanks to Paul and Roger for comments.

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

Historical variants may be seen here: http://cr.openjdk.java.net/~bpb/8068373/

One problem (or not) with this approach is that old FileSystemPreferences caches which already contain U+0000 will still cause a failure on reading in Java 9+ but perhaps we do not care.

Thanks,

Brian




From lowasser at google.com  Thu Feb 12 21:16:28 2015
From: lowasser at google.com (Louis Wasserman)
Date: Thu, 12 Feb 2015 21:16:28 +0000
Subject: RFR 8071670: java.util.Optional: please add a way to specify
	if-else behavior
References: <CAGB9EW-93ffyf6Z4ygF+aNeqJzpahOAmzNBKSXRdzRVG=dfRmw@mail.gmail.com>
	<408582DE-C838-4957-9A5E-C3BFC3015EC5@oracle.com>
Message-ID: <CAGB9EW-+MwPL5Yd19AR6R8OUX+1hDJoq0RWOtZn3qt0fJ7Z4+Q@mail.gmail.com>

Sure.  The "if present":"if present else":"if absent" ratio is ~24:6:1.

On Thu Feb 12 2015 at 1:01:51 PM Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> On Feb 12, 2015, at 8:29 PM, Louis Wasserman <lowasser at google.com> wrote:
>
> > I'm not sure I can share hard numbers, but the ratio of
> >
> > if (optional.isPresent()) {
> >   // non-returning statements here
> > }
> >
> > to
> >
> > if (optional.isPresent()) { // or negated
> >   // non-returning statements here
> > } else {
> >   // non-returning statements here
> > }
> >
> > is ~5.5x in favor of the no-else case.  Both patterns have large numbers
> of hits, though, so I'm satisfied that this is not an unreasonable thing to
> do.
>
> Many thanks, that's good to know.
>
>
> >
> > I can possibly try to extract statistics on how many of these cases
> would be easily converted to method references and other things that might
> be easier to express with functional interfaces, but I'm not sure how
> necessary that actually is.
> >
>
> It might be interesting, but i would be more curious about the following
> case:
>
> if (!optional.isPresent()) {
> ...
> }
> // no else
>
> would it be possible to get some numbers on that?
>
> Thanks,
> Paul.
>


From Roger.Riggs at Oracle.com  Thu Feb 12 22:02:57 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 12 Feb 2015 17:02:57 -0500
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54DBA533.8080802@Oracle.com>
References: <54D941D1.8000305@Oracle.com>	<54D94665.8020906@redhat.com>	<54D96446.4080305@Oracle.com>	<54DA04D4.1060108@redhat.com>
	<54DBA533.8080802@Oracle.com>
Message-ID: <54DD2311.9070902@Oracle.com>

Hi,

The Process and ProcessHandle API javadoc has been updated with the comments
and suggestions including the loose coupling of the Process from the 
CompletableFutures
that are linked to process termination.
The improved implementation from Peter is incorporated and the method 
descriptions
updated to reflect its behavior.

Updated javadoc:   http://cr.openjdk.java.net/~rriggs/ph-apidraft/

I ran into a issue with the generics on CompletableFuture<? extends...> 
completableFuture()
in ProcessHandle and Process.
The JDK compiles fine but the javac has a problem with the assignment in 
a test.
I'll come back to it after a long weekend in a warmer climate.

Suggestions appreciated, Roger


p.s.

ws/jdk9-sandbox/jdk/test/java/lang/ProcessHandle/CompletionTest.java:67: 
error: incompatible types: CompletableFuture<CAP#1> cannot be converted 
to CompletableFuture<Process>
                 CompletableFuture<Process> future = p.completableFuture();
^
   where CAP#1 is a fresh type-variable:
     CAP#1 extends ProcessHandle from capture of ? extends ProcessHandle


From xueming.shen at oracle.com  Thu Feb 12 22:53:54 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 12 Feb 2015 14:53:54 -0800
Subject: 8069325: Pattern.splitAsStream does not return input if it is
	empty and there is no match
In-Reply-To: <722C43ED-09C0-4C77-9C6F-98A05D1134EE@oracle.com>
References: <722C43ED-09C0-4C77-9C6F-98A05D1134EE@oracle.com>
Message-ID: <54DD2F02.5090105@oracle.com>

Hi Paul, my apology for taking so long :-)

The change looks fine.

With regarding the edge case "".split(""), I am fine with the idea of discarding the
resulting empty string as one trailing empty string.

-Sherman

On 01/20/2015 08:17 AM, Paul Sandoz wrote:
> Hi,
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8069325-Pattern-splitAsStream-emptyInput/webrev/
>
> This patch fixes an edge case in Pattern.splitAsStream for matching against an empty input string, which deviated from the behaviour of Pattern.split. When there are no matches a stream containing the input string should be returned rather than an empty stream.
>
> --
>
> I have kept compatibility with Pattern.split(String ) but i noticed another an edge case.
>
> What should the following return:
>
>    Pattern.compile("").split("")
>
> [] or [""]?
>
> There is a zero-width match at the beginning and an empty remaining segment both of which should be discarded, as such i would expect the result to be [] rather than as [""], as currently produced result.
>
> If people agree that this is an issue i suggest we log a new one independent of fixing 8069325.
>
> Thanks,
> Paul.



From scolebourne at joda.org  Thu Feb 12 22:59:24 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 12 Feb 2015 22:59:24 +0000
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>
	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
Message-ID: <CACzrW9ACv0X==y0Yz_ThjFTy2Erirhr_BZ_GiNAB8X5FoEgf=g@mail.gmail.com>

Interesting direction.

Reading carefully, the goal is actually very limited in scope, by
preventing any public API changes. It doesn't help adoption of JSR-310
for example, but will be useful for Unsafe, which is clearly a
motivating factor.

I would expect IDEs to have some considerable work to do.

My biggest concern will be ensuring tools like Reflections (or other
classpath scanning tools) carry on working. Really, classpath scanning
should no longer be necessary with a module system, but since we've
heard nothing to indicate that issue is being tackled, those tools
will continue to be vital (such as to find all classes implementing an
annotation, or all implementations of an interface)

Stephen





On 12 February 2015 at 20:52, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> Hi
>
> In connection with the JEP there is also a design document to help the discussion:
>
>   http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
>
> We are especially interesting in hearing feedback from library developers, tool/IDE developers, and anyone doing funky stuff with class loading and JAR files.
>
> Paul.
>
> On Feb 12, 2015, at 9:41 PM, mark.reinhold at oracle.com wrote:
>
>> New JEP Candidate: http://openjdk.java.net/jeps/238
>>
>> - Mark
>


From stuart.marks at oracle.com  Fri Feb 13 00:20:53 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 12 Feb 2015 16:20:53 -0800
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <4EB3EE4A-8139-41C8-A5BE-F277091EFAE8@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>
Message-ID: <54DD4365.3050007@oracle.com>



On 2/12/15 3:15 AM, Paul Sandoz wrote:
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/

OK, overall looks pretty good. Two minor comments on Matcher.java:

1202       if (expectedCount >= 0 && expectedCount != matchOrResetCount)
1203           return true;

This is a concurrent modification check, so other cases that test this condition 
will throw CME. Should this also throw CME or should it indeed return true?

1224                 // Perform a first find if required
1225                 if (s < 1 && !find())
1226                     return;

If I understand this correctly, the state field can have values -1, 0, or 1; and 
's' is a local variable that's initialized from the state field.

I was confused by this code because it ends up calling find() when s == 0, which 
means "not found" ... so why is find() being called again in this case?

However, the s == 0 case is dispensed with earlier, so it actually cannot occur 
here. I think it would be clearer, and have the same behavior, if the condition 
were changed to

     if (s < 0 && !find())

s'marks




>
>
>>>>> Regarding the disparity between MatchResult and Matcher. I think that would require a new sub-interface of MatchResult from which Matcher extends from and returns. If we think it important we should do that for 9 otherwise we will be stuck for the stream-based methods.
>>>>
>>>> Why do you think we need a new sub-interface? Wouldn't it be sufficient to add default methods?
>>>
>>> What would the defaults do? Throwing an exception seems a poor solution to me.
>>>
>>> My guess it will be possible to evolve Matcher in binary and source compatible way to use the sub-type.
>>
>> OK, I filed an RFE to cover this, then immediately closed it as a duplicate :-) because I failed to search for the existing RFE that covers this:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8065554
>>
>> Either we add some default methods that throw exceptions (gross) or we add a sub-interface (also gross). It might be a matter of taste, or bike shed painting.
>
> Or a matter of how much the grossness is contained. In that respect the latter is more self-contained, the latter spreads out to all independent consumers of MatchResult.
>
> Paul.
>


From david.holmes at oracle.com  Fri Feb 13 02:20:31 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 13 Feb 2015 12:20:31 +1000
Subject: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on
	arrays longer than 1073741824
In-Reply-To: <54DCDB2D.3090006@oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>
	<54DCDB2D.3090006@oracle.com>
Message-ID: <54DD5F6F.4070105@oracle.com>

Hi Lev,

On 13/02/2015 2:56 AM, Lev Priima wrote:
> Christos,
>
> Test may fail on shorter arrays(page 8 of paper). For instance, on worst
> case, generated by test, it starts to fail on length 67108864.
> After increasing stack size of runs to merge, Arrays.sort(T[]) works
> also on maximum possible array for HotSpot JVM.

I'd also like to see this documented somewhere in the code. Presently 
there is a reference to listsort.txt but then you have to go and find it 
on the web. :( At a minimum could we please add:

  175          * computation below must be changed if MIN_MERGE is 
decreased.  See
  176          * the MIN_MERGE declaration above for more information.
+             * The maximum value of 49 allows for an array up to length
+             * Integer.MAX_VALUE-4.

> Roger, David,
> I've updated the test (
> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html
> ) to make it more suitable for regular execution:
>
>    27  * @run main/othervm TimSortStackSize2 67108864

This will still fail on small memory devices:

:~> java TimSortStackSize2 67108864
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

as the default heap ergonomics may not be large enough. I had to add a 
minimum heap of -Xmx385M to get it to run.

Thanks,
David

>    28  * not for regular execution on all platforms:
>    29  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>    30  * run main/othervm -Xmx32g TimSortStackSize2 2147483644
>
> Could you please push this:
> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
> ?
>
> Lev
>
> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>> On Feb 12,  9:57pm,david.holmes at oracle.com  (David Holmes) wrote:
>> -- Subject: Re: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on
>>
>> | Ok - thanks Lev!
>> |
>> | David
>>
>> For posterity can someone document this, and also the value for which
>> Integer.MAX_VALUE-4 fails?
>>
>> christos
>


From david.holmes at oracle.com  Fri Feb 13 02:54:55 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 13 Feb 2015 12:54:55 +1000
Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow
	a higher MaxTenuringThreshold
In-Reply-To: <54DD0992.8010308@oracle.com>
References: <54DD0992.8010308@oracle.com>
Message-ID: <54DD677F.10101@oracle.com>

Hi Tom,

If you are potentially messing with the (identity) hash of all Java 
objects in the 32-bit case then this needs a broader discussion eg on 
core-libs-dev (cc'd) as this will impact end-user code the most!

The rest seems okay but I'm still mulling over it. :)

Thanks,
David H.

On 13/02/2015 6:14 AM, Tom Benson wrote:
> Hi,
> I need reviewers and a commit sponsor for changes for bug 6764713, which
> will increase the size of the age field in an object header from 4 bits
> to 5. This will allow a maximum MaxTenuringThreshold of 31, though the
> default will remain at the current value of 15.
>
> This includes the same change to the 32-bit version, which would close
> bug 6719225 as well.  In that case, the hash field in the header is
> affected, losing one bit (25 bits -> 24), so I have asked for review
> from hotspot-runtime-dev as well as gc-dev.
>
> Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00
> JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713
> Testing:  JPRT and reference server performance tests
>
> Notes:
> Contrary to what earlier notes in the JBS entry said, this does not
> require stronger alignment for the JavaThread structure for when biased
> locking stores that pointer in the header.   The JavaThread* was already
> being aligned 1 power of 2 more strongly than it needed to be, so there
> was an unused bit that could be stolen.
>
> In the 32-bit version, it does require taking one bit from the hash
> field, which goes from 25 to 24 bits.  This is something I'd especially
> like feedback on.  Running reference server performance tests, I saw no
> impact from this change.  We *could* make this change 64-bit-only, and
> leave the age field at 4 bits for the 32-bit version.  If we did so, we
> could also decrease the alignment required for the JavaThread* to 512
> from the current 1024.
>
> The comment changes imply that the bits available for the JavaThread*
> have been reduced by 1, and that the alignment is now stronger, but
> neither is true.  The comments have been corrected to match the
> alignment that was already enforced.
>
> Three tests needed to be corrected to match the new limits.  These check
> the maximum valid values, what value represents NeverTenure, and so on.
>
> Thanks,
> Tom
>


From paul.sandoz at oracle.com  Fri Feb 13 09:17:48 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 13 Feb 2015 10:17:48 +0100
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <54DD4365.3050007@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>
Message-ID: <5D1880CE-29E9-4C7C-A88B-94566517C905@oracle.com>


On Feb 13, 2015, at 1:20 AM, Stuart Marks <stuart.marks at oracle.com> wrote:

> 
> 
> On 2/12/15 3:15 AM, Paul Sandoz wrote:
>>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/
> 
> OK, overall looks pretty good. Two minor comments on Matcher.java:
> 
> 1202       if (expectedCount >= 0 && expectedCount != matchOrResetCount)
> 1203           return true;
> 
> This is a concurrent modification check, so other cases that test this condition will throw CME. Should this also throw CME or should it indeed return true?
> 

The latter, so a CME is only thrown on data returning methods. 

I have added a comment:

// Defer throwing ConcurrentModificationException to when
// next is called.  The is consistent with other fail-fast
// implementations.
if (expectedCount >= 0 && expectedCount != matchOrResetCount)
    return true;

Given that the iterator is never exposed directly it most likely does not matter, but i wanted to be consistent.


> 1224                 // Perform a first find if required
> 1225                 if (s < 1 && !find())
> 1226                     return;
> 
> If I understand this correctly, the state field can have values -1, 0, or 1; and 's' is a local variable that's initialized from the state field.
> 
> I was confused by this code because it ends up calling find() when s == 0, which means "not found" ... so why is find() being called again in this case?
> 
> However, the s == 0 case is dispensed with earlier, so it actually cannot occur here. I think it would be clearer, and have the same behavior, if the condition were changed to
> 
>    if (s < 0 && !find())
> 

Ok.

Webrev updated in place:

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

Thanks,
Paul.


From paul.sandoz at oracle.com  Fri Feb 13 09:23:20 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 13 Feb 2015 10:23:20 +0100
Subject: RFR 8071670: java.util.Optional: please add a way to specify
	if-else behavior
In-Reply-To: <CAGB9EW-+MwPL5Yd19AR6R8OUX+1hDJoq0RWOtZn3qt0fJ7Z4+Q@mail.gmail.com>
References: <CAGB9EW-93ffyf6Z4ygF+aNeqJzpahOAmzNBKSXRdzRVG=dfRmw@mail.gmail.com>
	<408582DE-C838-4957-9A5E-C3BFC3015EC5@oracle.com>
	<CAGB9EW-+MwPL5Yd19AR6R8OUX+1hDJoq0RWOtZn3qt0fJ7Z4+Q@mail.gmail.com>
Message-ID: <316A3585-441F-4CBA-9C3B-CB3AA0F10DFC@oracle.com>


On Feb 12, 2015, at 10:16 PM, Louis Wasserman <lowasser at google.com> wrote:

> Sure.  The "if present":"if present else":"if absent" ratio is ~24:6:1.
> 

Thanks! Given those rations i think we are good with just one extra method. I have added you as a reviewer.

Paul.


From volker.simonis at gmail.com  Fri Feb 13 09:25:53 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 13 Feb 2015 10:25:53 +0100
Subject: RFR(XS): 8072770: [TESTBUG] Some Introspector tests fail with a
	Java heap bigger than 4GB
In-Reply-To: <CA+3eh12fLjTEABf_91JgKXY30PG3CLjxeF6gQXPS58Osftv5eA@mail.gmail.com>
References: <CA+3eh12fLjTEABf_91JgKXY30PG3CLjxeF6gQXPS58Osftv5eA@mail.gmail.com>
Message-ID: <CA+3eh12LC=9VmT+BQ7vqcXtJ9SQXxdxhkEuYgNRPjmRNmBUeyQ@mail.gmail.com>

Hi,

can somebody please review this small test fix.

Thanks,
Volker


On Mon, Feb 9, 2015 at 3:27 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
> Hi,
>
> the three Introspector test:
>
> java/beans/Introspector/7064279/Test7064279.java
> java/beans/Introspector/Test7172865.java
> java/beans/Introspector/Test7195106.java
>
> provoke an OutOfMemory situation by repeatedly allocating constantly
> growing arrays with the following loop:
>
> int[] array = new int[1024];
> while (true) {
>   array = new int[array.length << 1];
> }
>
> However if we're running on a machine with plenty of RAM the default
> Java heap will be bigger than ~4GB and we will get a
> NegativeArraySizeException instead of an OutOfMemoryError because the
> array length which is a signed int will wrap around and become
> negative.
>
> The fix is easy - just specify a concrete -Xmx value for the test:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8072770/
> https://bugs.openjdk.java.net/browse/JDK-8072770
>
> Thank you and best regards,
> Volker


From paul.sandoz at oracle.com  Fri Feb 13 10:02:30 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 13 Feb 2015 11:02:30 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54DD2311.9070902@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>
Message-ID: <60E65542-85CD-4165-8B9F-52B42C97F4C0@oracle.com>

Hi,

I am not sure everyone is aware of the sandbox repo that was setup, but it's rather handy to see the changes:

  http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/9a02f23ca186

On Feb 12, 2015, at 11:02 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:

> Hi,
> 
> The Process and ProcessHandle API javadoc has been updated with the comments
> and suggestions including the loose coupling of the Process from the CompletableFutures
> that are linked to process termination.
> The improved implementation from Peter is incorporated and the method descriptions
> updated to reflect its behavior.
> 
> Updated javadoc:   http://cr.openjdk.java.net/~rriggs/ph-apidraft/
> 
> I ran into a issue with the generics on CompletableFuture<? extends...> completableFuture()
> in ProcessHandle and Process.
> The JDK compiles fine but the javac has a problem with the assignment in a test.
> I'll come back to it after a long weekend in a warmer climate.
> 

The use of wild cards in this context is generally discouraged because it propagates to the caller as you have found out. You cannot do what you want for the same reasons you cannot do this:

  List<? extends Number> len = Arrays.asList(1, 2, 3);

  // As this point we do not know the lower bound of elements in len 
  // Is it Integer or is it BigInteger?
  List<Number> ln = len;  // error
  ln.add(new BigInteger(...)); // Potential heap pollution

Which means you are stuck if you want to provide CF<Process> and CF<ProcessHandle> using the same overloaded method name.

You could do:

  abstract class ProcessHandle<T extends ProcessHandle<T>> {
      CompletableFuture<T> completableFuture() { ... }
  }

  class Process extends ProcessHandle<Process> {
      CompletableFuture<Process> completableFuture() { ... }
  }

But i am not sure it's worth it, especially as it exposes the sub-type of process handle.

Paul.

> Suggestions appreciated, Roger
> 
> 
> p.s.
> 
> ws/jdk9-sandbox/jdk/test/java/lang/ProcessHandle/CompletionTest.java:67: error: incompatible types: CompletableFuture<CAP#1> cannot be converted to CompletableFuture<Process>
>                CompletableFuture<Process> future = p.completableFuture();
> ^
>  where CAP#1 is a fresh type-variable:
>    CAP#1 extends ProcessHandle from capture of ? extends ProcessHandle



From paul.sandoz at oracle.com  Fri Feb 13 10:15:40 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 13 Feb 2015 11:15:40 +0100
Subject: 8069325: Pattern.splitAsStream does not return input if it is
	empty and there is no match
In-Reply-To: <54DD2F02.5090105@oracle.com>
References: <722C43ED-09C0-4C77-9C6F-98A05D1134EE@oracle.com>
	<54DD2F02.5090105@oracle.com>
Message-ID: <E5E15F94-CBD4-4F81-8009-8C80E07304E9@oracle.com>


On Feb 12, 2015, at 11:53 PM, Xueming Shen <xueming.shen at oracle.com> wrote:

> Hi Paul, my apology for taking so long :-)
> 

No problem, thanks for putting up with me hassling you :-)


> The change looks fine.
> 

Thanks.


> With regarding the edge case "".split(""), I am fine with the idea of discarding the
> resulting empty string as one trailing empty string.
> 

Ok, something to tackle later on a very rainy day, i will log a P5 issue.

Paul.


From peter.levart at gmail.com  Fri Feb 13 12:36:48 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 13 Feb 2015 13:36:48 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <60E65542-85CD-4165-8B9F-52B42C97F4C0@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>
Message-ID: <54DDEFE0.7090108@gmail.com>

On 02/13/2015 11:02 AM, Paul Sandoz wrote:
> Hi,
>
> I am not sure everyone is aware of the sandbox repo that was setup, but it's rather handy to see the changes:
>
>    http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/9a02f23ca186
>
> On Feb 12, 2015, at 11:02 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
>
>> Hi,
>>
>> The Process and ProcessHandle API javadoc has been updated with the comments
>> and suggestions including the loose coupling of the Process from the CompletableFutures
>> that are linked to process termination.
>> The improved implementation from Peter is incorporated and the method descriptions
>> updated to reflect its behavior.
>>
>> Updated javadoc:   http://cr.openjdk.java.net/~rriggs/ph-apidraft/
>>
>> I ran into a issue with the generics on CompletableFuture<? extends...> completableFuture()
>> in ProcessHandle and Process.
>> The JDK compiles fine but the javac has a problem with the assignment in a test.
>> I'll come back to it after a long weekend in a warmer climate.
>>
> The use of wild cards in this context is generally discouraged because it propagates to the caller as you have found out. You cannot do what you want for the same reasons you cannot do this:
>
>    List<? extends Number> len = Arrays.asList(1, 2, 3);
>
>    // As this point we do not know the lower bound of elements in len
>    // Is it Integer or is it BigInteger?
>    List<Number> ln = len;  // error
>    ln.add(new BigInteger(...)); // Potential heap pollution
>
> Which means you are stuck if you want to provide CF<Process> and CF<ProcessHandle> using the same overloaded method name.


It *is* inconvenient for the user to have to use wildcards in specifying 
types:

CompletableFuture<? extends Process> cf = process.completableFuture();

...but it doesn't hinder the use of above 'cf' quite so much as 'len' in 
List example above, since 'T' in CompletableFuture<T> is used mostly in 
co-variant positions. The only methods that use it in contra-variant 
positions are:

cf.getNow(?);
cf.complete(?);
cf.obtrudeValue(?);

of which I can imagine only the 1st one to be useful in 
ProcessHandle/Process situations and even that one only with 'null' as 
the argument which is allowed.

Other methods taking functions behave correctly with CompletableFuture<? 
extends Process>, for example:

     CompletableFuture<? extends Process> cf = process.completableFuture();

     cf.handle((p, ex) -> {
         p....
     });

So it really boils down to what is less inconvenient: using wildcards in 
type specifications or casting in cases like:

     CompletableFuture<ProcessHandle> cf = process.completableFuture();

     cf.handle((ph, ex) -> {
         Process p = (Process) ph;
         p....
     });


Regards, Peter


>
> You could do:
>
>    abstract class ProcessHandle<T extends ProcessHandle<T>> {
>        CompletableFuture<T> completableFuture() { ... }
>    }
>
>    class Process extends ProcessHandle<Process> {
>        CompletableFuture<Process> completableFuture() { ... }
>    }
>
> But i am not sure it's worth it, especially as it exposes the sub-type of process handle.
>
> Paul.
>
>> Suggestions appreciated, Roger
>>
>>
>> p.s.
>>
>> ws/jdk9-sandbox/jdk/test/java/lang/ProcessHandle/CompletionTest.java:67: error: incompatible types: CompletableFuture<CAP#1> cannot be converted to CompletableFuture<Process>
>>                 CompletableFuture<Process> future = p.completableFuture();
>> ^
>>   where CAP#1 is a fresh type-variable:
>>     CAP#1 extends ProcessHandle from capture of ? extends ProcessHandle



From aph at redhat.com  Fri Feb 13 13:16:07 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 13 Feb 2015 13:16:07 +0000
Subject: Lexicographic array comparators
In-Reply-To: <CA+kOe08e2ADM5yP5ZXkkf8qoNLtdLajb7Lt+fzayfSX1YeFhxg@mail.gmail.com>
References: <79B05B7B-CC06-4C6B-A29E-F3242F9EDE34@oracle.com>
	<CA+kOe08e2ADM5yP5ZXkkf8qoNLtdLajb7Lt+fzayfSX1YeFhxg@mail.gmail.com>
Message-ID: <54DDF917.2050301@redhat.com>

On 02/10/2015 07:48 PM, Martin Buchholz wrote:

> People will continue to want to access byte arrays (and direct byte
> buffers) with C-like performance, and are currently using Unsafe to
> do so.  Hard to fix for real.  Endianness and unaligned access are
> both non-portable aspects.  People don't want to pay for bounds
> checking and especially not for alignment checking of indexes known
> to be aligned.  Lexicographic comparison is only one use case (that
> happened to be important performance wise for guava).

I've been looking at the code HotSpot generates for
DirectByteBuffer.getXXX() and it's actually pretty good.  In many
cases C2 optimizes away the endianness, alignment, and bounds checks,
and nicely inlines and unrolls everything.  Sure, HotSpot can't always
remove bounds checks, but that's a fairly small price to pay, IMO.

getXXX() methods in HeapByteBuffers, however, aren't intrinsified, so
access to data items larger than bytes is byte-at-a-time and pretty
horrible.  It wouldn't be a huge job to fix this by adding a few
Unsafe.getUnalignedX intrinsics, and then I think we'd have C-like
performance.  Whether it makes sense to do this rather than add a new
API with a bunch of array methods to do the accesses directly is hard
to say.  Doing it in HeapByteBuffer has the advantage of reqiring no
API changes.  We could get it done in the JDK9 timeframe.

Andrew.


From aph at redhat.com  Fri Feb 13 13:38:58 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 13 Feb 2015 13:38:58 +0000
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses
Message-ID: <54DDFE72.1050306@redhat.com>

java.?nio.?DirectByteBuffer.getXXX is slow for types larger than byte
because the runtime does not know that AArch64 can perform unaligned
memory accesses.

The problem is due to this code in java.nio.Bits.unaligned():

        unaligned = arch.equals("i386") || arch.equals("x86")
            || arch.equals("amd64") || arch.equals("x86_64");

If we add AArch64 to this list code quality is very much improved.

http://cr.openjdk.java.net/~aph/8073093/

Thanks,
Andrew.


From peter.levart at gmail.com  Fri Feb 13 13:47:53 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 13 Feb 2015 14:47:53 +0100
Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow
	a higher MaxTenuringThreshold
In-Reply-To: <54DD677F.10101@oracle.com>
References: <54DD0992.8010308@oracle.com> <54DD677F.10101@oracle.com>
Message-ID: <54DE0089.7000303@gmail.com>

On 02/13/2015 03:54 AM, David Holmes wrote:
> Hi Tom,
>
> If you are potentially messing with the (identity) hash of all Java 
> objects in the 32-bit case then this needs a broader discussion eg on 
> core-libs-dev (cc'd) as this will impact end-user code the most!
>
> The rest seems okay but I'm still mulling over it. :)
>
> Thanks,
> David H.

Hi,

As I understand, this will make identity hashCode have 2^24 instead of 
2^25 distinct values on 32 bit architectures, right? This will mostly 
affect java.util.IdentityHashMap performance (and any use of objects 
that don't override hashCode in other hashCode-based Maps). IHM has a 
maximum capacity of 2^29 (key, value) slots. Performance will start to 
degrade sooner - at sizes > 2^24 / 1.5 (~10M) instead of 2^25 / 1.5 
(~20M) entries.

IHM has the following hashCode -> array slot index mapping function:

     /**
      * Returns index for Object x.
      */
     private static int hash(Object x, int length) {
         int h = System.identityHashCode(x);
         // Multiply by -127, and left-shift to use least bit as part of 
hash
         return ((h << 1) - (h << 8)) & (length - 1);
     }

Left-shift is added because keys are located at even indexes and 
associated values are at odd indexes in the same array. So the function 
to map hashCode to ordinal key index is actually:

     (h - (h << 7)) & (capacity - 1)

where capacity is a power of two <= 2^29, which means that it is 
necessary that 24 hash bits from Object header be mapped to lower 24 
bits of Object.hashCode(). Object.hashCode() in range 0..2^24-1 should 
still be enough to address the whole range of 2^29 capacity table given 
the above mapping function.

So the question is, how frequent are IdentityHashMap(s) with > 10M 
entries or any other HashMaps with keys that don't override 
Object.hashCode().

Here's an JMH (http://openjdk.java.net/projects/code-tools/jmh/) 
micro-benchmark you can use to measure the impact of change on 
IdentityHashMap:

     http://cr.openjdk.java.net/~plevart/misc/IHMBench/IHMBench.java

by default it creates an IdentityHashMap with size of 2^24 entries. This 
is where the performance difference is expected to start to be different 
between 24bit vs. 25bit hash codes. You can also try to use larger (up 
to 28) 'log2size' parameter, but you might want to increate -Xmx too in 
this case.

Regards, Peter

> On 13/02/2015 6:14 AM, Tom Benson wrote:
>> Hi,
>> I need reviewers and a commit sponsor for changes for bug 6764713, which
>> will increase the size of the age field in an object header from 4 bits
>> to 5. This will allow a maximum MaxTenuringThreshold of 31, though the
>> default will remain at the current value of 15.
>>
>> This includes the same change to the 32-bit version, which would close
>> bug 6719225 as well.  In that case, the hash field in the header is
>> affected, losing one bit (25 bits -> 24), so I have asked for review
>> from hotspot-runtime-dev as well as gc-dev.
>>
>> Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00
>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713
>> Testing:  JPRT and reference server performance tests
>>
>> Notes:
>> Contrary to what earlier notes in the JBS entry said, this does not
>> require stronger alignment for the JavaThread structure for when biased
>> locking stores that pointer in the header.   The JavaThread* was already
>> being aligned 1 power of 2 more strongly than it needed to be, so there
>> was an unused bit that could be stolen.
>>
>> In the 32-bit version, it does require taking one bit from the hash
>> field, which goes from 25 to 24 bits.  This is something I'd especially
>> like feedback on.  Running reference server performance tests, I saw no
>> impact from this change.  We *could* make this change 64-bit-only, and
>> leave the age field at 4 bits for the 32-bit version.  If we did so, we
>> could also decrease the alignment required for the JavaThread* to 512
>> from the current 1024.
>>
>> The comment changes imply that the bits available for the JavaThread*
>> have been reduced by 1, and that the alignment is now stronger, but
>> neither is true.  The comments have been corrected to match the
>> alignment that was already enforced.
>>
>> Three tests needed to be corrected to match the new limits. These check
>> the maximum valid values, what value represents NeverTenure, and so on.
>>
>> Thanks,
>> Tom
>>



From paul.sandoz at oracle.com  Fri Feb 13 13:56:36 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 13 Feb 2015 14:56:36 +0100
Subject: Lexicographic array comparators
In-Reply-To: <54DDF917.2050301@redhat.com>
References: <79B05B7B-CC06-4C6B-A29E-F3242F9EDE34@oracle.com>
	<CA+kOe08e2ADM5yP5ZXkkf8qoNLtdLajb7Lt+fzayfSX1YeFhxg@mail.gmail.com>
	<54DDF917.2050301@redhat.com>
Message-ID: <1BC12CF0-3B7C-458E-9A78-F37F2C419B4D@oracle.com>


On Feb 13, 2015, at 2:16 PM, Andrew Haley <aph at redhat.com> wrote:

> On 02/10/2015 07:48 PM, Martin Buchholz wrote:
> 
>> People will continue to want to access byte arrays (and direct byte
>> buffers) with C-like performance, and are currently using Unsafe to
>> do so.  Hard to fix for real.  Endianness and unaligned access are
>> both non-portable aspects.  People don't want to pay for bounds
>> checking and especially not for alignment checking of indexes known
>> to be aligned.  Lexicographic comparison is only one use case (that
>> happened to be important performance wise for guava).
> 
> I've been looking at the code HotSpot generates for
> DirectByteBuffer.getXXX() and it's actually pretty good.  In many
> cases C2 optimizes away the endianness, alignment, and bounds checks,
> and nicely inlines and unrolls everything.  Sure, HotSpot can't always
> remove bounds checks, but that's a fairly small price to pay, IMO.
> 
> getXXX() methods in HeapByteBuffers, however, aren't intrinsified, so
> access to data items larger than bytes is byte-at-a-time and pretty
> horrible.  It wouldn't be a huge job to fix this by adding a few
> Unsafe.getUnalignedX intrinsics, and then I think we'd have C-like
> performance.  Whether it makes sense to do this rather than add a new
> API with a bunch of array methods to do the accesses directly is hard
> to say.  Doing it in HeapByteBuffer has the advantage of reqiring no
> API changes.  We could get it done in the JDK9 timeframe.
> 

John suggested that a general array mis-match method could be achieved with carefully written Java code [1], and slightly hidden within that is the comment "FIXME: Add Unsafe.getLongMisaligned to avoid this cutout".

I am inclined to keep pushing on this array mis-match functionality and it's usages for existing and new stuff in Arrays as well as trying to leverage component pieces in other areas like you suggest.

Paul.

[1] https://bugs.openjdk.java.net/browse/JDK-8044082?focusedCommentId=13608657&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13608657


From lev.priima at oracle.com  Fri Feb 13 14:03:34 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Fri, 13 Feb 2015 17:03:34 +0300
Subject: RFR 8073124: Tune test and document TimSort runs length stack size
	increase
In-Reply-To: <54DD5F6F.4070105@oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>
	<54DCDB2D.3090006@oracle.com> <54DD5F6F.4070105@oracle.com>
Message-ID: <54DE0436.5070301@oracle.com>

Please review and push: 
http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8073124

Lev

On 02/13/2015 05:20 AM, David Holmes wrote:
> Hi Lev,
>
> On 13/02/2015 2:56 AM, Lev Priima wrote:
>> Christos,
>>
>> Test may fail on shorter arrays(page 8 of paper). For instance, on worst
>> case, generated by test, it starts to fail on length 67108864.
>> After increasing stack size of runs to merge, Arrays.sort(T[]) works
>> also on maximum possible array for HotSpot JVM.
>
> I'd also like to see this documented somewhere in the code. Presently 
> there is a reference to listsort.txt but then you have to go and find 
> it on the web. :( At a minimum could we please add:
>
>  175          * computation below must be changed if MIN_MERGE is 
> decreased.  See
>  176          * the MIN_MERGE declaration above for more information.
> +             * The maximum value of 49 allows for an array up to length
> +             * Integer.MAX_VALUE-4.
>
>> Roger, David,
>> I've updated the test (
>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html 
>>
>> ) to make it more suitable for regular execution:
>>
>>    27  * @run main/othervm TimSortStackSize2 67108864
>
> This will still fail on small memory devices:
>
> :~> java TimSortStackSize2 67108864
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>
> as the default heap ergonomics may not be large enough. I had to add a 
> minimum heap of -Xmx385M to get it to run.
>
> Thanks,
> David
>
>>    28  * not for regular execution on all platforms:
>>    29  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>    30  * run main/othervm -Xmx32g TimSortStackSize2 2147483644
>>
>> Could you please push this:
>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>> ?
>>
>> Lev
>>
>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>> On Feb 12, 9:57pm,david.holmes at oracle.com  (David Holmes) wrote:
>>> -- Subject: Re: 8072909: TimSort fails with 
>>> ArrayIndexOutOfBoundsException on
>>>
>>> | Ok - thanks Lev!
>>> |
>>> | David
>>>
>>> For posterity can someone document this, and also the value for which
>>> Integer.MAX_VALUE-4 fails?
>>>
>>> christos
>>



From paul.sandoz at oracle.com  Fri Feb 13 14:22:25 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 13 Feb 2015 15:22:25 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54DDEFE0.7090108@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>
Message-ID: <A7E232DE-C83C-4973-B6E9-FB8563359BCA@oracle.com>

On Feb 13, 2015, at 1:36 PM, Peter Levart <peter.levart at gmail.com> wrote:
>>> 
>> The use of wild cards in this context is generally discouraged because it propagates to the caller as you have found out. You cannot do what you want for the same reasons you cannot do this:
>> 
>>   List<? extends Number> len = Arrays.asList(1, 2, 3);
>> 
>>   // As this point we do not know the lower bound of elements in len
>>   // Is it Integer or is it BigInteger?
>>   List<Number> ln = len;  // error
>>   ln.add(new BigInteger(...)); // Potential heap pollution
>> 
>> Which means you are stuck if you want to provide CF<Process> and CF<ProcessHandle> using the same overloaded method name.
> 
> 
> It *is* inconvenient for the user to have to use wildcards in specifying types:
> 
> CompletableFuture<? extends Process> cf = process.completableFuture();
> 
> ...but it doesn't hinder the use of above 'cf' quite so much as 'len' in List example above, since 'T' in CompletableFuture<T> is used mostly in co-variant positions. The only methods that use it in contra-variant positions are:
> 
> cf.getNow(?);
> cf.complete(?);
> cf.obtrudeValue(?);
> 

What about the methods with a parameter type of:

  CompletionStage<? extends T> 

such as applyToEither and acceptEither?

Paul.


From aph at redhat.com  Fri Feb 13 14:31:53 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 13 Feb 2015 14:31:53 +0000
Subject: Lexicographic array comparators
In-Reply-To: <1BC12CF0-3B7C-458E-9A78-F37F2C419B4D@oracle.com>
References: <79B05B7B-CC06-4C6B-A29E-F3242F9EDE34@oracle.com>	<CA+kOe08e2ADM5yP5ZXkkf8qoNLtdLajb7Lt+fzayfSX1YeFhxg@mail.gmail.com>	<54DDF917.2050301@redhat.com>
	<1BC12CF0-3B7C-458E-9A78-F37F2C419B4D@oracle.com>
Message-ID: <54DE0AD9.3080601@redhat.com>

On 02/13/2015 01:56 PM, Paul Sandoz wrote:
> John suggested that a general array mis-match method could be achieved with carefully written Java code [1], and slightly hidden within that is the comment "FIXME: Add Unsafe.getLongMisaligned to avoid this cutout".

Right, so we're definitely thinking along the same lines.  Maybe I
could do the HotSpot work for Unsafe.getUnalignedX.

Andrew.



From dl at cs.oswego.edu  Fri Feb 13 14:33:48 2015
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 13 Feb 2015 09:33:48 -0500
Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow
	a higher MaxTenuringThreshold
In-Reply-To: <54DE0089.7000303@gmail.com>
References: <54DD0992.8010308@oracle.com> <54DD677F.10101@oracle.com>
	<54DE0089.7000303@gmail.com>
Message-ID: <54DE0B4C.6010005@cs.oswego.edu>

On 02/13/2015 08:47 AM, Peter Levart wrote:
> On 02/13/2015 03:54 AM, David Holmes wrote:
>> Hi Tom,
>>
>> If you are potentially messing with the (identity) hash of all Java objects in
>> the 32-bit case then this needs a broader discussion eg on core-libs-dev
>> (cc'd) as this will impact end-user code the most!
>>
>
> As I understand, this will make identity hashCode have 2^24 instead of 2^25
> distinct values on 32 bit architectures, right? This will mostly affect
> java.util.IdentityHashMap performance (and any use of objects that don't
> override hashCode in other hashCode-based Maps). IHM has a maximum capacity of
> 2^29 (key, value) slots. Performance will start to degrade sooner - at sizes >
> 2^24 / 1.5 (~10M) instead of 2^25 / 1.5 (~20M) entries.
>


In other words, it approximately doubles the probability of a collision
for tables with more than 10 million keys. It's a sure thing that some
applications out there will see measurable slowdowns. So the justification
needed here is whether these slowdowns are more than compensated by the
benefits of adding another age bit. This seems hard to carry out,
but the fallback plan of adding age bit only on 64bit platforms that
don't impact hash bits sounds completely safe.

-Doug




From karen.kinnear at oracle.com  Fri Feb 13 14:42:06 2015
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Fri, 13 Feb 2015 09:42:06 -0500
Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow
	a higher MaxTenuringThreshold
In-Reply-To: <54DD677F.10101@oracle.com>
References: <54DD0992.8010308@oracle.com> <54DD677F.10101@oracle.com>
Message-ID: <799C5410-5CF5-4EB4-BEC7-5EF17CE79642@oracle.com>

Seconded. For the hash code, talk to Coleen and ask her who did the work in core libs recently.

In addition, those bits are fiercely sought after - we have other things we would like to do with any available bits and I am
not convinced this is more valuable. We just resisted using one for the jdk9 frozen arrays although we might want one to mark
immutable objects or value types (yes, today those don't have an identity hash but I am not yet convinced that we won't have
a design where we need to distinguish reference objects from value types underneath a common object header for jdk10).

So - hmmm. 

thanks,
Karen

On Feb 12, 2015, at 9:54 PM, David Holmes wrote:

> Hi Tom,
> 
> If you are potentially messing with the (identity) hash of all Java objects in the 32-bit case then this needs a broader discussion eg on core-libs-dev (cc'd) as this will impact end-user code the most!
> 
> The rest seems okay but I'm still mulling over it. :)
> 
> Thanks,
> David H.
> 
> On 13/02/2015 6:14 AM, Tom Benson wrote:
>> Hi,
>> I need reviewers and a commit sponsor for changes for bug 6764713, which
>> will increase the size of the age field in an object header from 4 bits
>> to 5. This will allow a maximum MaxTenuringThreshold of 31, though the
>> default will remain at the current value of 15.
>> 
>> This includes the same change to the 32-bit version, which would close
>> bug 6719225 as well.  In that case, the hash field in the header is
>> affected, losing one bit (25 bits -> 24), so I have asked for review
>> from hotspot-runtime-dev as well as gc-dev.
>> 
>> Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00
>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713
>> Testing:  JPRT and reference server performance tests
>> 
>> Notes:
>> Contrary to what earlier notes in the JBS entry said, this does not
>> require stronger alignment for the JavaThread structure for when biased
>> locking stores that pointer in the header.   The JavaThread* was already
>> being aligned 1 power of 2 more strongly than it needed to be, so there
>> was an unused bit that could be stolen.
>> 
>> In the 32-bit version, it does require taking one bit from the hash
>> field, which goes from 25 to 24 bits.  This is something I'd especially
>> like feedback on.  Running reference server performance tests, I saw no
>> impact from this change.  We *could* make this change 64-bit-only, and
>> leave the age field at 4 bits for the 32-bit version.  If we did so, we
>> could also decrease the alignment required for the JavaThread* to 512
>> from the current 1024.
>> 
>> The comment changes imply that the bits available for the JavaThread*
>> have been reduced by 1, and that the alignment is now stronger, but
>> neither is true.  The comments have been corrected to match the
>> alignment that was already enforced.
>> 
>> Three tests needed to be corrected to match the new limits.  These check
>> the maximum valid values, what value represents NeverTenure, and so on.
>> 
>> Thanks,
>> Tom
>> 



From daniel.fuchs at oracle.com  Fri Feb 13 14:56:28 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 13 Feb 2015 15:56:28 +0100
Subject: RFR: 8072645: java.util.logging should use java.time to get more
	precise time stamps
Message-ID: <54DE109C.4030307@oracle.com>

Hi,

Please find below a patch for:

8072645: java.util.logging should use java.time to get more
          precise time stamps


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

specdiff:
http://cr.openjdk.java.net/~dfuchs/webrev_8072645/specdiff-logging-time/java/util/logging/package-summary.html

Overview:
---------

The patch is made of the following pieces:

  - LogRecord uses java.time.Clock's systemClock to get an
    Instant in the best available resolution.

    The instant is split into a number of milliseconds (a long)
    and a nanosecond adjustment (an int).
    The number of milliseconds is the same than what would have
    been obtained by calling System.currentTimeMillis().

  - LogRecord acquires a new serializable int nanoAdjustement field,
    which can be used together with the number of milliseconds
    to reconstruct the instant.

  - SimpleFormatter is updated to pass a ZoneDateTime
    instance to String.format, instead of a Date.

    The effect of that is that the format string can now
    be configure to print the full instant precision, if
    needed.

  - XMLformatter will add a new <nanos> element after the
    <millis> element - if the value of the nanoAdjustment
    field is not 0.

    The <date> string will also contain the nano second
    adjustment as well as the zone offset as formatted by
    DateTimeFormatter.ISO_OFFSET_DATE_TIME

Compatibility considerations:
-----------------------------

- The serial for of log record is backward/forward compatible.
   I added a test to verify that.

- XMLFormatter has acquired a new configurable property
   '<FQCN>.printNanos' which allows to revert to the old
   XML format, should the new format cause issues in
   existing applications.

- The logger.dtd will need to be updated, to support the
   new optional <nanos> element. And for this matter,
   should we update the logger.dtd or rather define a
   logger-v2.dtd?
   See planned modification:
 
<http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-dtd/logger.dtd.frames.html>

best regards,

-- daniel


From paul.sandoz at oracle.com  Fri Feb 13 14:58:29 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 13 Feb 2015 15:58:29 +0100
Subject: Lexicographic array comparators
In-Reply-To: <54DE0AD9.3080601@redhat.com>
References: <79B05B7B-CC06-4C6B-A29E-F3242F9EDE34@oracle.com>	<CA+kOe08e2ADM5yP5ZXkkf8qoNLtdLajb7Lt+fzayfSX1YeFhxg@mail.gmail.com>	<54DDF917.2050301@redhat.com>
	<1BC12CF0-3B7C-458E-9A78-F37F2C419B4D@oracle.com>
	<54DE0AD9.3080601@redhat.com>
Message-ID: <5FB46769-CE5D-4710-84D4-8647A1AFF0EA@oracle.com>


On Feb 13, 2015, at 3:31 PM, Andrew Haley <aph at redhat.com> wrote:

> On 02/13/2015 01:56 PM, Paul Sandoz wrote:
>> John suggested that a general array mis-match method could be achieved with carefully written Java code [1], and slightly hidden within that is the comment "FIXME: Add Unsafe.getLongMisaligned to avoid this cutout".
> 
> Right, so we're definitely thinking along the same lines.  Maybe I
> could do the HotSpot work for Unsafe.getUnalignedX.
> 

Got for it! 

I would be happy to give it a test drive.

Paul.



From peter.levart at gmail.com  Fri Feb 13 15:15:18 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 13 Feb 2015 16:15:18 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <A7E232DE-C83C-4973-B6E9-FB8563359BCA@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>
Message-ID: <54DE1506.8020407@gmail.com>

On 02/13/2015 03:22 PM, Paul Sandoz wrote:
>> >It*is*  inconvenient for the user to have to use wildcards in specifying types:
>> >
>> >CompletableFuture<? extends Process> cf = process.completableFuture();
>> >
>> >...but it doesn't hinder the use of above 'cf' quite so much as 'len' in List example above, since 'T' in CompletableFuture<T> is used mostly in co-variant positions. The only methods that use it in contra-variant positions are:
>> >
>> >cf.getNow(?);
>> >cf.complete(?);
>> >cf.obtrudeValue(?);
>> >
> What about the methods with a parameter type of:
>
>    CompletionStage<? extends T>
>
> such as applyToEither and acceptEither?
>
> Paul.

Oh, I see.

That's a problem, yes. And these two methods are actually very useful in 
the context of processes - waiting for 1st of two processes to finish.

So the signature can only be the following:

     CompletableFuture<ProcessHandle> completableFuture();


Peter



From david.lloyd at redhat.com  Fri Feb 13 15:18:20 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 13 Feb 2015 09:18:20 -0600
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54DE1506.8020407@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>
Message-ID: <54DE15BC.7040007@redhat.com>

On 02/13/2015 09:15 AM, Peter Levart wrote:
> On 02/13/2015 03:22 PM, Paul Sandoz wrote:
>>> >It*is*  inconvenient for the user to have to use wildcards in specifying types:
>>> >
>>> >CompletableFuture<? extends Process> cf = process.completableFuture();
>>> >
>>> >...but it doesn't hinder the use of above 'cf' quite so much as 'len' in List example above, since 'T' in CompletableFuture<T> is used mostly in co-variant positions. The only methods that use it in contra-variant positions are:
>>> >
>>> >cf.getNow(?);
>>> >cf.complete(?);
>>> >cf.obtrudeValue(?);
>>> >
>> What about the methods with a parameter type of:
>>
>>    CompletionStage<? extends T>
>>
>> such as applyToEither and acceptEither?
>>
>> Paul.
>
> Oh, I see.
>
> That's a problem, yes. And these two methods are actually very useful in
> the context of processes - waiting for 1st of two processes to finish.
>
> So the signature can only be the following:
>
>      CompletableFuture<ProcessHandle> completableFuture();

I hesitate to mention it, but as someone who has been frustrated by this 
same problem on numerous occasions I feel I must suggest that maybe... 
having a completableFuture method should just be dropped?  A user should 
be able to implement it themselves fairly easily, right?  And they'd be 
able to sidestep problems like stack size and so on by managing their 
own threads.

-- 
- DML


From peter.levart at gmail.com  Fri Feb 13 15:34:01 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 13 Feb 2015 16:34:01 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54DE15BC.7040007@redhat.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>
Message-ID: <54DE1969.2040508@gmail.com>

On 02/13/2015 04:18 PM, David M. Lloyd wrote:
> On 02/13/2015 09:15 AM, Peter Levart wrote:
>> On 02/13/2015 03:22 PM, Paul Sandoz wrote:
>>>> >It*is*  inconvenient for the user to have to use wildcards in 
>>>> specifying types:
>>>> >
>>>> >CompletableFuture<? extends Process> cf = 
>>>> process.completableFuture();
>>>> >
>>>> >...but it doesn't hinder the use of above 'cf' quite so much as 
>>>> 'len' in List example above, since 'T' in CompletableFuture<T> is 
>>>> used mostly in co-variant positions. The only methods that use it 
>>>> in contra-variant positions are:
>>>> >
>>>> >cf.getNow(?);
>>>> >cf.complete(?);
>>>> >cf.obtrudeValue(?);
>>>> >
>>> What about the methods with a parameter type of:
>>>
>>>    CompletionStage<? extends T>
>>>
>>> such as applyToEither and acceptEither?
>>>
>>> Paul.
>>
>> Oh, I see.
>>
>> That's a problem, yes. And these two methods are actually very useful in
>> the context of processes - waiting for 1st of two processes to finish.
>>
>> So the signature can only be the following:
>>
>>      CompletableFuture<ProcessHandle> completableFuture();
>
> I hesitate to mention it, but as someone who has been frustrated by 
> this same problem on numerous occasions I feel I must suggest that 
> maybe... having a completableFuture method should just be dropped?  A 
> user should be able to implement it themselves fairly easily, right?  
> And they'd be able to sidestep problems like stack size and so on by 
> managing their own threads.
>

That's a good idea. If the following two methods were added to 
Process[Handle]:

     public class ProcessHandle {
         public ProcessHandle waitForUninterruptibly();
     }

     public class Process extends ProcessHandle {
         @Override
         public Process waitForUninterruptibly();
     }

One could get CompletableFuture(s) simply by:

         ProcessHandle ph = ...;

         CompletableFuture<ProcessHandle> phf = 
CompletableFuture.supplyAsync(ph::waitForUninterruptibly);

         Process p = ...;

         CompletableFuture<Process> pf = 
CompletableFuture.supplyAsync(p::waitForUninterruptibly);


Peter


From peter.levart at gmail.com  Fri Feb 13 16:00:37 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 13 Feb 2015 17:00:37 +0100
Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow
	a higher MaxTenuringThreshold
In-Reply-To: <54DE1A56.9080008@oracle.com>
References: <54DD0992.8010308@oracle.com>
	<54DD677F.10101@oracle.com>	<799C5410-5CF5-4EB4-BEC7-5EF17CE79642@oracle.com>
	<54DE1A56.9080008@oracle.com>
Message-ID: <54DE1FA5.7010508@gmail.com>

On 02/13/2015 04:37 PM, Tom Benson wrote:
> Hi,
> Based on comments here and elsewhere on possible future uses for this 
> unused bit (in the 64-bit version), I'm more inclined to close both 
> 6764713 and 6719225 with no change.  With a comment along the lines of 
> "evolution of the JVM since the time the age field was reduced has 
> revealed potentially more valuable uses of the bit."
>
> However, if there are supporters of a larger MaxTenuringThreshold 
> lurking, I'd like to hear their point of view as well.
> Thanks,
> Tom

Hi Tom,

This is just my uneducated thinking...

I can imagine that with G1 collector this is more complicated, but with 
standard young-gen collector where there are 2 survivor spaces, couldn't 
they be labeled "A" and "B" and when MaxTenuringThreshold > 15, the 
Object's age be incremented only when it is moved in one direction A -> 
B (and not when it is moved B -> A). For MaxTenuringThreshold of say 24, 
it would be moved to OldGen when age > 24/2 then. The resolution of 
MaxTenuringThreshold > 15 could only be specified in steps of 2 then 
(16, 18, 20, ... 30).

I guess the movement of young objects among survivor regions in G1 is 
not so regular (so that you could label half of survivor regions with 
"A" and the other half with "B" and objects would always move from A -> 
B or B -> A and never A -> A or B -> B), right?

Regards, Peter

>
> On 2/13/2015 9:42 AM, Karen Kinnear wrote:
>> Seconded. For the hash code, talk to Coleen and ask her who did the 
>> work in core libs recently.
>>
>> In addition, those bits are fiercely sought after - we have other 
>> things we would like to do with any available bits and I am
>> not convinced this is more valuable. We just resisted using one for 
>> the jdk9 frozen arrays although we might want one to mark
>> immutable objects or value types (yes, today those don't have an 
>> identity hash but I am not yet convinced that we won't have
>> a design where we need to distinguish reference objects from value 
>> types underneath a common object header for jdk10).
>>
>> So - hmmm.
>>
>> thanks,
>> Karen
>>
>> On Feb 12, 2015, at 9:54 PM, David Holmes wrote:
>>
>>> Hi Tom,
>>>
>>> If you are potentially messing with the (identity) hash of all Java 
>>> objects in the 32-bit case then this needs a broader discussion eg 
>>> on core-libs-dev (cc'd) as this will impact end-user code the most!
>>>
>>> The rest seems okay but I'm still mulling over it. :)
>>>
>>> Thanks,
>>> David H.
>>>
>>> On 13/02/2015 6:14 AM, Tom Benson wrote:
>>>> Hi,
>>>> I need reviewers and a commit sponsor for changes for bug 6764713, 
>>>> which
>>>> will increase the size of the age field in an object header from 4 
>>>> bits
>>>> to 5. This will allow a maximum MaxTenuringThreshold of 31, though the
>>>> default will remain at the current value of 15.
>>>>
>>>> This includes the same change to the 32-bit version, which would close
>>>> bug 6719225 as well.  In that case, the hash field in the header is
>>>> affected, losing one bit (25 bits -> 24), so I have asked for review
>>>> from hotspot-runtime-dev as well as gc-dev.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00
>>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713
>>>> Testing:  JPRT and reference server performance tests
>>>>
>>>> Notes:
>>>> Contrary to what earlier notes in the JBS entry said, this does not
>>>> require stronger alignment for the JavaThread structure for when 
>>>> biased
>>>> locking stores that pointer in the header.   The JavaThread* was 
>>>> already
>>>> being aligned 1 power of 2 more strongly than it needed to be, so 
>>>> there
>>>> was an unused bit that could be stolen.
>>>>
>>>> In the 32-bit version, it does require taking one bit from the hash
>>>> field, which goes from 25 to 24 bits.  This is something I'd 
>>>> especially
>>>> like feedback on.  Running reference server performance tests, I 
>>>> saw no
>>>> impact from this change.  We *could* make this change 64-bit-only, and
>>>> leave the age field at 4 bits for the 32-bit version.  If we did 
>>>> so, we
>>>> could also decrease the alignment required for the JavaThread* to 512
>>>> from the current 1024.
>>>>
>>>> The comment changes imply that the bits available for the JavaThread*
>>>> have been reduced by 1, and that the alignment is now stronger, but
>>>> neither is true.  The comments have been corrected to match the
>>>> alignment that was already enforced.
>>>>
>>>> Three tests needed to be corrected to match the new limits. These 
>>>> check
>>>> the maximum valid values, what value represents NeverTenure, and so 
>>>> on.
>>>>
>>>> Thanks,
>>>> Tom
>>>>
>



From Alan.Bateman at oracle.com  Fri Feb 13 16:05:15 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 13 Feb 2015 16:05:15 +0000
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54DDFE72.1050306@redhat.com>
References: <54DDFE72.1050306@redhat.com>
Message-ID: <54DE20BB.50302@oracle.com>

On 13/02/2015 13:38, Andrew Haley wrote:
> java.?nio.?DirectByteBuffer.getXXX is slow for types larger than byte
> because the runtime does not know that AArch64 can perform unaligned
> memory accesses.
>
> The problem is due to this code in java.nio.Bits.unaligned():
>
>          unaligned = arch.equals("i386") || arch.equals("x86")
>              || arch.equals("amd64") || arch.equals("x86_64");
>
> If we add AArch64 to this list code quality is very much improved.
>
> http://cr.openjdk.java.net/~aph/8073093/
>
Make sense, I assume this will go in when JEP 237 is pushed.

-Alan


From aph at redhat.com  Fri Feb 13 16:07:13 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 13 Feb 2015 16:07:13 +0000
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54DE20BB.50302@oracle.com>
References: <54DDFE72.1050306@redhat.com> <54DE20BB.50302@oracle.com>
Message-ID: <54DE2131.3090405@redhat.com>

On 02/13/2015 04:05 PM, Alan Bateman wrote:
> On 13/02/2015 13:38, Andrew Haley wrote:
>> java.?nio.?DirectByteBuffer.getXXX is slow for types larger than byte
>> because the runtime does not know that AArch64 can perform unaligned
>> memory accesses.
>>
>> The problem is due to this code in java.nio.Bits.unaligned():
>>
>>          unaligned = arch.equals("i386") || arch.equals("x86")
>>              || arch.equals("amd64") || arch.equals("x86_64");
>>
>> If we add AArch64 to this list code quality is very much improved.
>>
>> http://cr.openjdk.java.net/~aph/8073093/
>>
> Make sense, I assume this will go in when JEP 237 is pushed.

It will, but I need approval to push to the JEP 237 staging repo.
'Cos them's the rules.  :-)

Andrew.



From Alan.Bateman at oracle.com  Fri Feb 13 16:11:21 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 13 Feb 2015 16:11:21 +0000
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <6C6FF726-D47E-47A5-8644-AB5E6C32A468@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CD3043.2070709@gmail.com>	<54CD4A14.2080205@oracle.com>	<54CD6984.2040004@gmail.com>	<54CDF84E.7070905@oracle.com>	<54CE03D2.8000706@gmail.com>	<54CF386A.9000600@oracle.com>	<2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>	<54CF5EF3.20102@oracle.com>
	<54CFE38D.30400@oracle.com> <54D2249E.105@oracle.com>
	<54D22CC6.9040405@gmail.com> <54D23041.1020703@oracle.com>
	<54D236AA.4050406@oracle.com> <54D4957F.7070805@oracle.com>
	<54D8CAD7.50303@oracle.com> <54D9ECF1.9090203@oracle.com>
	<6C6FF726-D47E-47A5-8644-AB5E6C32A468@oracle.com>
Message-ID: <54DE2229.2090504@oracle.com>

On 10/02/2015 16:20, Chris Hegarty wrote:
> On 10 Feb 2015, at 11:35, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
>> On 09/02/2015 14:57, Chris Hegarty wrote:
>>> :
>>>
>>> Updated webrev [ spec and implementation] :
>>>   http://cr.openjdk.java.net/~chegar/8064924/04/
>>>
>> The updated javadoc looks good. I haven't had a chance yet to look at the implementation but I think you will need to update <top>/make/common/CORE_PKGS.gmk for the spi package.
> Sorry, I have the change locally but forgot it. I updated the webrev with the changes to the top level repo ( below ):
>
I think the approach is good.

One thing in the implementation is detection for recursive 
initialization. In other areas of the platforms 
(ClassLoader.getSystemClassLoader and FileSystem.getDefault) then an 
exception is thrown. I wonder if we need this here too. If the 
initialization of a URLStreamHandlerFactory is dependent on the 
deployment of another then it could be very tricky to diagnose as there 
isn't (yet) any control on the ordering.

I'd probably use isOverridable or canOverride for the method name.

In the spi package-info.java then I assume it time that the second 
paragraph will need to change as there will be other provider interfaces.

-Alan.



From peter.levart at gmail.com  Fri Feb 13 16:55:04 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 13 Feb 2015 17:55:04 +0100
Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow
	a higher MaxTenuringThreshold
In-Reply-To: <CAP_pwnXPpJds4KutvY0iNvGF3ddPi3ewNJXTv30HsS4jdMyBbw@mail.gmail.com>
References: <54DD0992.8010308@oracle.com>
	<54DD677F.10101@oracle.com>	<799C5410-5CF5-4EB4-BEC7-5EF17CE79642@oracle.com>	<54DE1A56.9080008@oracle.com>
	<CAP_pwnXPpJds4KutvY0iNvGF3ddPi3ewNJXTv30HsS4jdMyBbw@mail.gmail.com>
Message-ID: <54DE2C68.4020505@gmail.com>

On 02/13/2015 05:13 PM, Carsten Varming wrote:
> Dear Tom,
>
> If you want very large MaxTenuringThresholds, then you could add an option
> to reinterpret the value of the four bits to be a power of 2. One way is to
> only bump the age from i to i+1 when the gc count is divisible by 2^i. You
> lose granularity and precision, but gain some very large ages.
>
> Carsten

GC count, yes. Clever.

Or, 4 bit value 'x' could be reinterpreted as being multiplied by 
constant 'k', computed from MaxTenuringThreshold:

k = 1 + (MaxTenuringThreshold >> 4);
...
0 <= MaxTenuringThreshold <= 15: k = 1
16 <= MaxTenuringThreshold <= 31: k = 2
32 <= MaxTenuringThreshold <= 47: k = 3
48 <= MaxTenuringThreshold <= 63: k = 4
...

...then increment 'x' when GC count is divisible by 'k'. When 'x' > 
MaxTenuringThreshold / k, object is OLD...

Peter


>
> On Fri, Feb 13, 2015 at 10:37 AM, Tom Benson <tom.benson at oracle.com> wrote:
>
>> Hi,
>> Based on comments here and elsewhere on possible future uses for this
>> unused bit (in the 64-bit version), I'm more inclined to close both 6764713
>> and 6719225 with no change.  With a comment along the lines of "evolution
>> of the JVM since the time the age field was reduced has revealed
>> potentially more valuable uses of the bit."
>>
>> However, if there are supporters of a larger MaxTenuringThreshold lurking,
>> I'd like to hear their point of view as well.
>> Thanks,
>> Tom
>>
>>
>> On 2/13/2015 9:42 AM, Karen Kinnear wrote:
>>
>>> Seconded. For the hash code, talk to Coleen and ask her who did the work
>>> in core libs recently.
>>>
>>> In addition, those bits are fiercely sought after - we have other things
>>> we would like to do with any available bits and I am
>>> not convinced this is more valuable. We just resisted using one for the
>>> jdk9 frozen arrays although we might want one to mark
>>> immutable objects or value types (yes, today those don't have an identity
>>> hash but I am not yet convinced that we won't have
>>> a design where we need to distinguish reference objects from value types
>>> underneath a common object header for jdk10).
>>>
>>> So - hmmm.
>>>
>>> thanks,
>>> Karen
>>>
>>> On Feb 12, 2015, at 9:54 PM, David Holmes wrote:
>>>
>>>   Hi Tom,
>>>> If you are potentially messing with the (identity) hash of all Java
>>>> objects in the 32-bit case then this needs a broader discussion eg on
>>>> core-libs-dev (cc'd) as this will impact end-user code the most!
>>>>
>>>> The rest seems okay but I'm still mulling over it. :)
>>>>
>>>> Thanks,
>>>> David H.
>>>>
>>>> On 13/02/2015 6:14 AM, Tom Benson wrote:
>>>>
>>>>> Hi,
>>>>> I need reviewers and a commit sponsor for changes for bug 6764713, which
>>>>> will increase the size of the age field in an object header from 4 bits
>>>>> to 5. This will allow a maximum MaxTenuringThreshold of 31, though the
>>>>> default will remain at the current value of 15.
>>>>>
>>>>> This includes the same change to the 32-bit version, which would close
>>>>> bug 6719225 as well.  In that case, the hash field in the header is
>>>>> affected, losing one bit (25 bits -> 24), so I have asked for review
>>>>> from hotspot-runtime-dev as well as gc-dev.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00
>>>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713
>>>>> Testing:  JPRT and reference server performance tests
>>>>>
>>>>> Notes:
>>>>> Contrary to what earlier notes in the JBS entry said, this does not
>>>>> require stronger alignment for the JavaThread structure for when biased
>>>>> locking stores that pointer in the header.   The JavaThread* was already
>>>>> being aligned 1 power of 2 more strongly than it needed to be, so there
>>>>> was an unused bit that could be stolen.
>>>>>
>>>>> In the 32-bit version, it does require taking one bit from the hash
>>>>> field, which goes from 25 to 24 bits.  This is something I'd especially
>>>>> like feedback on.  Running reference server performance tests, I saw no
>>>>> impact from this change.  We *could* make this change 64-bit-only, and
>>>>> leave the age field at 4 bits for the 32-bit version.  If we did so, we
>>>>> could also decrease the alignment required for the JavaThread* to 512
>>>>> from the current 1024.
>>>>>
>>>>> The comment changes imply that the bits available for the JavaThread*
>>>>> have been reduced by 1, and that the alignment is now stronger, but
>>>>> neither is true.  The comments have been corrected to match the
>>>>> alignment that was already enforced.
>>>>>
>>>>> Three tests needed to be corrected to match the new limits.  These check
>>>>> the maximum valid values, what value represents NeverTenure, and so on.
>>>>>
>>>>> Thanks,
>>>>> Tom
>>>>>
>>>>>



From vladimir.kozlov at oracle.com  Fri Feb 13 16:56:41 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 13 Feb 2015 08:56:41 -0800
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54DE2131.3090405@redhat.com>
References: <54DDFE72.1050306@redhat.com> <54DE20BB.50302@oracle.com>
	<54DE2131.3090405@redhat.com>
Message-ID: <54DE2CC9.3050805@oracle.com>

Changes are fine.

I agree with Alan. Please, wait when we merge aarch64 stage into jdk9/dev and then push this fix into jdk9 (by sponsor). 
We should finish testing of stage repo "soon".

Thanks,
Vladimir

On 2/13/15 8:07 AM, Andrew Haley wrote:
> On 02/13/2015 04:05 PM, Alan Bateman wrote:
>> On 13/02/2015 13:38, Andrew Haley wrote:
>>> java.?nio.?DirectByteBuffer.getXXX is slow for types larger than byte
>>> because the runtime does not know that AArch64 can perform unaligned
>>> memory accesses.
>>>
>>> The problem is due to this code in java.nio.Bits.unaligned():
>>>
>>>           unaligned = arch.equals("i386") || arch.equals("x86")
>>>               || arch.equals("amd64") || arch.equals("x86_64");
>>>
>>> If we add AArch64 to this list code quality is very much improved.
>>>
>>> http://cr.openjdk.java.net/~aph/8073093/
>>>
>> Make sense, I assume this will go in when JEP 237 is pushed.
>
> It will, but I need approval to push to the JEP 237 staging repo.
> 'Cos them's the rules.  :-)
>
> Andrew.
>


From tom.benson at oracle.com  Fri Feb 13 15:37:58 2015
From: tom.benson at oracle.com (Tom Benson)
Date: Fri, 13 Feb 2015 10:37:58 -0500
Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow
	a higher MaxTenuringThreshold
In-Reply-To: <799C5410-5CF5-4EB4-BEC7-5EF17CE79642@oracle.com>
References: <54DD0992.8010308@oracle.com> <54DD677F.10101@oracle.com>
	<799C5410-5CF5-4EB4-BEC7-5EF17CE79642@oracle.com>
Message-ID: <54DE1A56.9080008@oracle.com>

Hi,
Based on comments here and elsewhere on possible future uses for this 
unused bit (in the 64-bit version), I'm more inclined to close both 
6764713 and 6719225 with no change.  With a comment along the lines of 
"evolution of the JVM since the time the age field was reduced has 
revealed potentially more valuable uses of the bit."

However, if there are supporters of a larger MaxTenuringThreshold 
lurking, I'd like to hear their point of view as well.
Thanks,
Tom

On 2/13/2015 9:42 AM, Karen Kinnear wrote:
> Seconded. For the hash code, talk to Coleen and ask her who did the work in core libs recently.
>
> In addition, those bits are fiercely sought after - we have other things we would like to do with any available bits and I am
> not convinced this is more valuable. We just resisted using one for the jdk9 frozen arrays although we might want one to mark
> immutable objects or value types (yes, today those don't have an identity hash but I am not yet convinced that we won't have
> a design where we need to distinguish reference objects from value types underneath a common object header for jdk10).
>
> So - hmmm.
>
> thanks,
> Karen
>
> On Feb 12, 2015, at 9:54 PM, David Holmes wrote:
>
>> Hi Tom,
>>
>> If you are potentially messing with the (identity) hash of all Java objects in the 32-bit case then this needs a broader discussion eg on core-libs-dev (cc'd) as this will impact end-user code the most!
>>
>> The rest seems okay but I'm still mulling over it. :)
>>
>> Thanks,
>> David H.
>>
>> On 13/02/2015 6:14 AM, Tom Benson wrote:
>>> Hi,
>>> I need reviewers and a commit sponsor for changes for bug 6764713, which
>>> will increase the size of the age field in an object header from 4 bits
>>> to 5. This will allow a maximum MaxTenuringThreshold of 31, though the
>>> default will remain at the current value of 15.
>>>
>>> This includes the same change to the 32-bit version, which would close
>>> bug 6719225 as well.  In that case, the hash field in the header is
>>> affected, losing one bit (25 bits -> 24), so I have asked for review
>>> from hotspot-runtime-dev as well as gc-dev.
>>>
>>> Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00
>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713
>>> Testing:  JPRT and reference server performance tests
>>>
>>> Notes:
>>> Contrary to what earlier notes in the JBS entry said, this does not
>>> require stronger alignment for the JavaThread structure for when biased
>>> locking stores that pointer in the header.   The JavaThread* was already
>>> being aligned 1 power of 2 more strongly than it needed to be, so there
>>> was an unused bit that could be stolen.
>>>
>>> In the 32-bit version, it does require taking one bit from the hash
>>> field, which goes from 25 to 24 bits.  This is something I'd especially
>>> like feedback on.  Running reference server performance tests, I saw no
>>> impact from this change.  We *could* make this change 64-bit-only, and
>>> leave the age field at 4 bits for the 32-bit version.  If we did so, we
>>> could also decrease the alignment required for the JavaThread* to 512
>>> from the current 1024.
>>>
>>> The comment changes imply that the bits available for the JavaThread*
>>> have been reduced by 1, and that the alignment is now stronger, but
>>> neither is true.  The comments have been corrected to match the
>>> alignment that was already enforced.
>>>
>>> Three tests needed to be corrected to match the new limits.  These check
>>> the maximum valid values, what value represents NeverTenure, and so on.
>>>
>>> Thanks,
>>> Tom
>>>



From bengt.rutisson at oracle.com  Fri Feb 13 16:37:20 2015
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 13 Feb 2015 17:37:20 +0100
Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow
	a higher MaxTenuringThreshold
In-Reply-To: <54DE1A56.9080008@oracle.com>
References: <54DD0992.8010308@oracle.com>
	<54DD677F.10101@oracle.com>	<799C5410-5CF5-4EB4-BEC7-5EF17CE79642@oracle.com>
	<54DE1A56.9080008@oracle.com>
Message-ID: <54DE2840.3000402@oracle.com>


Hi,

On 2015-02-13 16:37, Tom Benson wrote:
> Hi,
> Based on comments here and elsewhere on possible future uses for this 
> unused bit (in the 64-bit version), I'm more inclined to close both 
> 6764713 and 6719225 with no change.  With a comment along the lines of 
> "evolution of the JVM since the time the age field was reduced has 
> revealed potentially more valuable uses of the bit."

This sounds like a good approach in my view. I think we can leave the 
age at 4 bits. In my view the main issue with the aging is that our 
heuristics for adjusting the tenuring threshold are not always reliable. 
Sometimes the threshold gets stuck at the max value etc. I prefer to 
close these bug reports as suggested above and if we want to improve the 
tenuring we should work on the heuristics instead.

Thanks for digging these bug reports up, Tom! We should probably have 
brought them up for discussion and closing them a long time ago.

Thanks,
Bengt

>
> However, if there are supporters of a larger MaxTenuringThreshold 
> lurking, I'd like to hear their point of view as well.
> Thanks,
> Tom
>
> On 2/13/2015 9:42 AM, Karen Kinnear wrote:
>> Seconded. For the hash code, talk to Coleen and ask her who did the 
>> work in core libs recently.
>>
>> In addition, those bits are fiercely sought after - we have other 
>> things we would like to do with any available bits and I am
>> not convinced this is more valuable. We just resisted using one for 
>> the jdk9 frozen arrays although we might want one to mark
>> immutable objects or value types (yes, today those don't have an 
>> identity hash but I am not yet convinced that we won't have
>> a design where we need to distinguish reference objects from value 
>> types underneath a common object header for jdk10).
>>
>> So - hmmm.
>>
>> thanks,
>> Karen
>>
>> On Feb 12, 2015, at 9:54 PM, David Holmes wrote:
>>
>>> Hi Tom,
>>>
>>> If you are potentially messing with the (identity) hash of all Java 
>>> objects in the 32-bit case then this needs a broader discussion eg 
>>> on core-libs-dev (cc'd) as this will impact end-user code the most!
>>>
>>> The rest seems okay but I'm still mulling over it. :)
>>>
>>> Thanks,
>>> David H.
>>>
>>> On 13/02/2015 6:14 AM, Tom Benson wrote:
>>>> Hi,
>>>> I need reviewers and a commit sponsor for changes for bug 6764713, 
>>>> which
>>>> will increase the size of the age field in an object header from 4 
>>>> bits
>>>> to 5. This will allow a maximum MaxTenuringThreshold of 31, though the
>>>> default will remain at the current value of 15.
>>>>
>>>> This includes the same change to the 32-bit version, which would close
>>>> bug 6719225 as well.  In that case, the hash field in the header is
>>>> affected, losing one bit (25 bits -> 24), so I have asked for review
>>>> from hotspot-runtime-dev as well as gc-dev.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00
>>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713
>>>> Testing:  JPRT and reference server performance tests
>>>>
>>>> Notes:
>>>> Contrary to what earlier notes in the JBS entry said, this does not
>>>> require stronger alignment for the JavaThread structure for when 
>>>> biased
>>>> locking stores that pointer in the header.   The JavaThread* was 
>>>> already
>>>> being aligned 1 power of 2 more strongly than it needed to be, so 
>>>> there
>>>> was an unused bit that could be stolen.
>>>>
>>>> In the 32-bit version, it does require taking one bit from the hash
>>>> field, which goes from 25 to 24 bits.  This is something I'd 
>>>> especially
>>>> like feedback on.  Running reference server performance tests, I 
>>>> saw no
>>>> impact from this change.  We *could* make this change 64-bit-only, and
>>>> leave the age field at 4 bits for the 32-bit version.  If we did 
>>>> so, we
>>>> could also decrease the alignment required for the JavaThread* to 512
>>>> from the current 1024.
>>>>
>>>> The comment changes imply that the bits available for the JavaThread*
>>>> have been reduced by 1, and that the alignment is now stronger, but
>>>> neither is true.  The comments have been corrected to match the
>>>> alignment that was already enforced.
>>>>
>>>> Three tests needed to be corrected to match the new limits. These 
>>>> check
>>>> the maximum valid values, what value represents NeverTenure, and so 
>>>> on.
>>>>
>>>> Thanks,
>>>> Tom
>>>>
>



From tom.benson at oracle.com  Fri Feb 13 17:16:15 2015
From: tom.benson at oracle.com (Tom Benson)
Date: Fri, 13 Feb 2015 12:16:15 -0500
Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow
	a higher MaxTenuringThreshold
In-Reply-To: <54DE2840.3000402@oracle.com>
References: <54DD0992.8010308@oracle.com>
	<54DD677F.10101@oracle.com>	<799C5410-5CF5-4EB4-BEC7-5EF17CE79642@oracle.com>
	<54DE1A56.9080008@oracle.com> <54DE2840.3000402@oracle.com>
Message-ID: <54DE315F.5050802@oracle.com>

Hi,
Note that not taking this bit for the age field would open the door to 
reducing the alignment of the JavaThread*.  It's the fact that there was 
already an unclaimed bit there (in the 64-bit version) that made the age 
size increase seem more reasonable.

However, I'd propose not changing that, either, at least for the 64-bit 
version, so that when someone finally claims "the bit" it doesn't need 
to be undone.  For the 32-bit version, it's less clear cut, but I'd 
still lean toward leaving it as is.
Tom

On 2/13/2015 11:37 AM, Bengt Rutisson wrote:
>
> Hi,
>
> On 2015-02-13 16:37, Tom Benson wrote:
>> Hi,
>> Based on comments here and elsewhere on possible future uses for this 
>> unused bit (in the 64-bit version), I'm more inclined to close both 
>> 6764713 and 6719225 with no change.  With a comment along the lines 
>> of "evolution of the JVM since the time the age field was reduced has 
>> revealed potentially more valuable uses of the bit."
>
> This sounds like a good approach in my view. I think we can leave the 
> age at 4 bits. In my view the main issue with the aging is that our 
> heuristics for adjusting the tenuring threshold are not always 
> reliable. Sometimes the threshold gets stuck at the max value etc. I 
> prefer to close these bug reports as suggested above and if we want to 
> improve the tenuring we should work on the heuristics instead.
>
> Thanks for digging these bug reports up, Tom! We should probably have 
> brought them up for discussion and closing them a long time ago.
>
> Thanks,
> Bengt
>
>>
>> However, if there are supporters of a larger MaxTenuringThreshold 
>> lurking, I'd like to hear their point of view as well.
>> Thanks,
>> Tom
>>



From charlie.hunt at oracle.com  Fri Feb 13 16:01:45 2015
From: charlie.hunt at oracle.com (charlie hunt)
Date: Fri, 13 Feb 2015 10:01:45 -0600
Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow
	a higher MaxTenuringThreshold
In-Reply-To: <54DE1A56.9080008@oracle.com>
References: <54DD0992.8010308@oracle.com> <54DD677F.10101@oracle.com>
	<799C5410-5CF5-4EB4-BEC7-5EF17CE79642@oracle.com>
	<54DE1A56.9080008@oracle.com>
Message-ID: <437E034A-E466-4270-89B9-10278F08CA7B@oracle.com>

Hi Tom,

Some background on some observations and strategies folks have tended to take wrt GC tuning.

With both Parallel GC and CMS GC, a common approach by folks tuning GC and heap sizes is to employ a strategy of promoting as few objects as possible from young generation to old generation. In other words, keep live objects in young generation as long as possible. This is where the max tenuring threshold comes in. If you have the ability to have higher object ages, those live objects can slosh around between survivor spaces for a longer time / higher age and have a higher probability of becoming unreachable before getting promoted to old generation. Once they are in old generation, (as you know) with Parallel GC it is a bit more expensive to collect them. With CMS, promoting fewer objects to old generation implies less chance for old generation fragmentation.

However, with G1 GC, we have the ability to incrementally collect old generation and incrementally collecting old generation does not have the pain points that Parallel GC and CMS GC carry with them. So the approach of trying to avoid object promotion is not as useful with G1. Hence, the value of having a higher max tenuring threshold is not as important with G1. And, with G1 expected to one day replace Parallel GC and CMS GC, whenever that might be ;-) ? well, you get the picture.

To summarize, I suspect folks who are using Parallel GC or CMS GC could probably take advantage of a higher max tenuring threshold. But, in G1 I have not seen that having a higher max tenuring threshold as being nearly as useful.

There may be others in the community who do GC tuning on a daily basis who may be able to offer their observations and experience too.

Fwiw, from my perspective I am ok with the suggestion in your note below of closing this as ?evolution of the JVM since the time the age field was reduced has revealed potentially more valuable uses for the bit?.

hths,

charlie


> On Feb 13, 2015, at 9:37 AM, Tom Benson <tom.benson at oracle.com> wrote:
> 
> Hi,
> Based on comments here and elsewhere on possible future uses for this unused bit (in the 64-bit version), I'm more inclined to close both 6764713 and 6719225 with no change.  With a comment along the lines of "evolution of the JVM since the time the age field was reduced has revealed potentially more valuable uses of the bit."
> 
> However, if there are supporters of a larger MaxTenuringThreshold lurking, I'd like to hear their point of view as well.
> Thanks,
> Tom
> 
> On 2/13/2015 9:42 AM, Karen Kinnear wrote:
>> Seconded. For the hash code, talk to Coleen and ask her who did the work in core libs recently.
>> 
>> In addition, those bits are fiercely sought after - we have other things we would like to do with any available bits and I am
>> not convinced this is more valuable. We just resisted using one for the jdk9 frozen arrays although we might want one to mark
>> immutable objects or value types (yes, today those don't have an identity hash but I am not yet convinced that we won't have
>> a design where we need to distinguish reference objects from value types underneath a common object header for jdk10).
>> 
>> So - hmmm.
>> 
>> thanks,
>> Karen
>> 
>> On Feb 12, 2015, at 9:54 PM, David Holmes wrote:
>> 
>>> Hi Tom,
>>> 
>>> If you are potentially messing with the (identity) hash of all Java objects in the 32-bit case then this needs a broader discussion eg on core-libs-dev (cc'd) as this will impact end-user code the most!
>>> 
>>> The rest seems okay but I'm still mulling over it. :)
>>> 
>>> Thanks,
>>> David H.
>>> 
>>> On 13/02/2015 6:14 AM, Tom Benson wrote:
>>>> Hi,
>>>> I need reviewers and a commit sponsor for changes for bug 6764713, which
>>>> will increase the size of the age field in an object header from 4 bits
>>>> to 5. This will allow a maximum MaxTenuringThreshold of 31, though the
>>>> default will remain at the current value of 15.
>>>> 
>>>> This includes the same change to the 32-bit version, which would close
>>>> bug 6719225 as well.  In that case, the hash field in the header is
>>>> affected, losing one bit (25 bits -> 24), so I have asked for review
>>>> from hotspot-runtime-dev as well as gc-dev.
>>>> 
>>>> Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00
>>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713
>>>> Testing:  JPRT and reference server performance tests
>>>> 
>>>> Notes:
>>>> Contrary to what earlier notes in the JBS entry said, this does not
>>>> require stronger alignment for the JavaThread structure for when biased
>>>> locking stores that pointer in the header.   The JavaThread* was already
>>>> being aligned 1 power of 2 more strongly than it needed to be, so there
>>>> was an unused bit that could be stolen.
>>>> 
>>>> In the 32-bit version, it does require taking one bit from the hash
>>>> field, which goes from 25 to 24 bits.  This is something I'd especially
>>>> like feedback on.  Running reference server performance tests, I saw no
>>>> impact from this change.  We *could* make this change 64-bit-only, and
>>>> leave the age field at 4 bits for the 32-bit version.  If we did so, we
>>>> could also decrease the alignment required for the JavaThread* to 512
>>>> from the current 1024.
>>>> 
>>>> The comment changes imply that the bits available for the JavaThread*
>>>> have been reduced by 1, and that the alignment is now stronger, but
>>>> neither is true.  The comments have been corrected to match the
>>>> alignment that was already enforced.
>>>> 
>>>> Three tests needed to be corrected to match the new limits.  These check
>>>> the maximum valid values, what value represents NeverTenure, and so on.
>>>> 
>>>> Thanks,
>>>> Tom
>>>> 
> 



From varming at gmail.com  Fri Feb 13 16:13:56 2015
From: varming at gmail.com (Carsten Varming)
Date: Fri, 13 Feb 2015 11:13:56 -0500
Subject: RFR(s): 6764713: Enlarge the age field in object headers to allow
	a higher MaxTenuringThreshold
In-Reply-To: <54DE1A56.9080008@oracle.com>
References: <54DD0992.8010308@oracle.com> <54DD677F.10101@oracle.com>
	<799C5410-5CF5-4EB4-BEC7-5EF17CE79642@oracle.com>
	<54DE1A56.9080008@oracle.com>
Message-ID: <CAP_pwnXPpJds4KutvY0iNvGF3ddPi3ewNJXTv30HsS4jdMyBbw@mail.gmail.com>

Dear Tom,

If you want very large MaxTenuringThresholds, then you could add an option
to reinterpret the value of the four bits to be a power of 2. One way is to
only bump the age from i to i+1 when the gc count is divisible by 2^i. You
lose granularity and precision, but gain some very large ages.

Carsten

On Fri, Feb 13, 2015 at 10:37 AM, Tom Benson <tom.benson at oracle.com> wrote:

> Hi,
> Based on comments here and elsewhere on possible future uses for this
> unused bit (in the 64-bit version), I'm more inclined to close both 6764713
> and 6719225 with no change.  With a comment along the lines of "evolution
> of the JVM since the time the age field was reduced has revealed
> potentially more valuable uses of the bit."
>
> However, if there are supporters of a larger MaxTenuringThreshold lurking,
> I'd like to hear their point of view as well.
> Thanks,
> Tom
>
>
> On 2/13/2015 9:42 AM, Karen Kinnear wrote:
>
>> Seconded. For the hash code, talk to Coleen and ask her who did the work
>> in core libs recently.
>>
>> In addition, those bits are fiercely sought after - we have other things
>> we would like to do with any available bits and I am
>> not convinced this is more valuable. We just resisted using one for the
>> jdk9 frozen arrays although we might want one to mark
>> immutable objects or value types (yes, today those don't have an identity
>> hash but I am not yet convinced that we won't have
>> a design where we need to distinguish reference objects from value types
>> underneath a common object header for jdk10).
>>
>> So - hmmm.
>>
>> thanks,
>> Karen
>>
>> On Feb 12, 2015, at 9:54 PM, David Holmes wrote:
>>
>>  Hi Tom,
>>>
>>> If you are potentially messing with the (identity) hash of all Java
>>> objects in the 32-bit case then this needs a broader discussion eg on
>>> core-libs-dev (cc'd) as this will impact end-user code the most!
>>>
>>> The rest seems okay but I'm still mulling over it. :)
>>>
>>> Thanks,
>>> David H.
>>>
>>> On 13/02/2015 6:14 AM, Tom Benson wrote:
>>>
>>>> Hi,
>>>> I need reviewers and a commit sponsor for changes for bug 6764713, which
>>>> will increase the size of the age field in an object header from 4 bits
>>>> to 5. This will allow a maximum MaxTenuringThreshold of 31, though the
>>>> default will remain at the current value of 15.
>>>>
>>>> This includes the same change to the 32-bit version, which would close
>>>> bug 6719225 as well.  In that case, the hash field in the header is
>>>> affected, losing one bit (25 bits -> 24), so I have asked for review
>>>> from hotspot-runtime-dev as well as gc-dev.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~jprovino/6764713/webrev.00
>>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-6764713
>>>> Testing:  JPRT and reference server performance tests
>>>>
>>>> Notes:
>>>> Contrary to what earlier notes in the JBS entry said, this does not
>>>> require stronger alignment for the JavaThread structure for when biased
>>>> locking stores that pointer in the header.   The JavaThread* was already
>>>> being aligned 1 power of 2 more strongly than it needed to be, so there
>>>> was an unused bit that could be stolen.
>>>>
>>>> In the 32-bit version, it does require taking one bit from the hash
>>>> field, which goes from 25 to 24 bits.  This is something I'd especially
>>>> like feedback on.  Running reference server performance tests, I saw no
>>>> impact from this change.  We *could* make this change 64-bit-only, and
>>>> leave the age field at 4 bits for the 32-bit version.  If we did so, we
>>>> could also decrease the alignment required for the JavaThread* to 512
>>>> from the current 1024.
>>>>
>>>> The comment changes imply that the bits available for the JavaThread*
>>>> have been reduced by 1, and that the alignment is now stronger, but
>>>> neither is true.  The comments have been corrected to match the
>>>> alignment that was already enforced.
>>>>
>>>> Three tests needed to be corrected to match the new limits.  These check
>>>> the maximum valid values, what value represents NeverTenure, and so on.
>>>>
>>>> Thanks,
>>>> Tom
>>>>
>>>>
>


From brian.burkhalter at oracle.com  Fri Feb 13 19:08:11 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 13 Feb 2015 11:08:11 -0800
Subject: [9] RFR JDK-8068373: (prefs) FileSystemPreferences writes \0 to
	XML storage, causing loss of all preferences 
In-Reply-To: <E0281603-FEA1-4B5A-9143-40E2D872D6F4@oracle.com>
References: <E0281603-FEA1-4B5A-9143-40E2D872D6F4@oracle.com>
Message-ID: <8BEF40B0-F1E3-4F1A-8D2D-400E8B16C722@oracle.com>

Bon{jour,soir},

Are we in general happy with this approach or should some effort be put into something more elaborate (hence expensive)?

Note that the addition of lines 492-493 in j.u.prefs.Preferences will I imagine imply a CCC request, the submission of which I prefer to defer until there is consensus on the prospective change. A TCK update will also be needed, I expect.

Thanks,

Brian

On Feb 12, 2015, at 1:01 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> Based on previous discussions this thread which used to be an RFC is now an RFR. Thanks to Paul and Roger for comments.
> 
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8068373
> Patch:	http://cr.openjdk.java.net/~bpb/8068373/webrev.04/
> 
> Historical variants may be seen here:http://cr.openjdk.java.net/~bpb/8068373/
> 
> One problem (or not) with this approach is that old FileSystemPreferences caches which already contain U+0000 will still cause a failure on reading in Java 9+ but perhaps we do not care.



From stuart.marks at oracle.com  Fri Feb 13 19:26:49 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 13 Feb 2015 11:26:49 -0800
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <5D1880CE-29E9-4C7C-A88B-94566517C905@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>
Message-ID: <54DE4FF9.6050609@oracle.com>

OK, this looks great. Thanks for the updates.

There is also

     "in same order" -> "in the same order"

in the doc for the results() method, as Brian pointed out internally.

No need for another webrev.

s'marks

On 2/13/15 1:17 AM, Paul Sandoz wrote:
>
> On Feb 13, 2015, at 1:20 AM, Stuart Marks <stuart.marks at oracle.com> wrote:
>
>>
>>
>> On 2/12/15 3:15 AM, Paul Sandoz wrote:
>>>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/
>>
>> OK, overall looks pretty good. Two minor comments on Matcher.java:
>>
>> 1202       if (expectedCount >= 0 && expectedCount != matchOrResetCount)
>> 1203           return true;
>>
>> This is a concurrent modification check, so other cases that test this condition will throw CME. Should this also throw CME or should it indeed return true?
>>
>
> The latter, so a CME is only thrown on data returning methods.
>
> I have added a comment:
>
> // Defer throwing ConcurrentModificationException to when
> // next is called.  The is consistent with other fail-fast
> // implementations.
> if (expectedCount >= 0 && expectedCount != matchOrResetCount)
>      return true;
>
> Given that the iterator is never exposed directly it most likely does not matter, but i wanted to be consistent.
>
>
>> 1224                 // Perform a first find if required
>> 1225                 if (s < 1 && !find())
>> 1226                     return;
>>
>> If I understand this correctly, the state field can have values -1, 0, or 1; and 's' is a local variable that's initialized from the state field.
>>
>> I was confused by this code because it ends up calling find() when s == 0, which means "not found" ... so why is find() being called again in this case?
>>
>> However, the s == 0 case is dispensed with earlier, so it actually cannot occur here. I think it would be clearer, and have the same behavior, if the condition were changed to
>>
>>     if (s < 0 && !find())
>>
>
> Ok.
>
> Webrev updated in place:
>
> 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
>
> Thanks,
> Paul.
>


From chris.hegarty at oracle.com  Fri Feb 13 19:39:51 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 13 Feb 2015 19:39:51 +0000
Subject: RFR 8064924: Update java.net.URL to work with modules
In-Reply-To: <54DE2229.2090504@oracle.com>
References: <D2BECF70-8684-4BFB-8639-2FAD0FEFEBFA@oracle.com>	<54CD3043.2070709@gmail.com>	<54CD4A14.2080205@oracle.com>	<54CD6984.2040004@gmail.com>	<54CDF84E.7070905@oracle.com>	<54CE03D2.8000706@gmail.com>	<54CF386A.9000600@oracle.com>	<2208AA06-79FB-4CE8-AE97-A76FC14D2269@oracle.com>	<54CF5EF3.20102@oracle.com>
	<54CFE38D.30400@oracle.com> <54D2249E.105@oracle.com>
	<54D22CC6.9040405@gmail.com> <54D23041.1020703@oracle.com>
	<54D236AA.4050406@oracle.com> <54D4957F.7070805@oracle.com>
	<54D8CAD7.50303@oracle.com> <54D9ECF1.9090203@oracle.com>
	<6C6FF726-D47E-47A5-8644-AB5E6C32A468@oracle.com>
	<54DE2229.2090504@oracle.com>
Message-ID: <90618322-3C46-484D-9DAF-5E48E7E51108@oracle.com>

On 13 Feb 2015, at 16:11, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 10/02/2015 16:20, Chris Hegarty wrote:
>> On 10 Feb 2015, at 11:35, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>>> On 09/02/2015 14:57, Chris Hegarty wrote:
>>>> :
>>>> 
>>>> Updated webrev [ spec and implementation] :
>>>>  http://cr.openjdk.java.net/~chegar/8064924/04/
>>>> 
>>> The updated javadoc looks good. I haven't had a chance yet to look at the implementation but I think you will need to update <top>/make/common/CORE_PKGS.gmk for the spi package.
>> Sorry, I have the change locally but forgot it. I updated the webrev with the changes to the top level repo ( below ):
>> 
> I think the approach is good.
> 
> One thing in the implementation is detection for recursive initialization. In other areas of the platforms (ClassLoader.getSystemClassLoader and FileSystem.getDefault) then an exception is thrown.

In an earlier revision recursion detection threw an Exception, but I was inspired by the the lookup mechanism in Charset, which returns null when it encounters recursion. I chose the latter as it means that we do not need to filter out specific protocols from lookup, like ?jar?. Returning null just falls back to searching the built-in handlers.

> I wonder if we need this here too. If the initialization of a URLStreamHandlerFactory is dependent on the deployment of another then it could be very tricky to diagnose as there isn't (yet) any control on the ordering.

I had not thought of that scenario, and I?m not sure how it would work, at least with ServiceLoader. Do you think it is important ?

> I'd probably use isOverridable or canOverride for the method name.

I?ll update from overrideable(String) -> isOverridable(String)

> In the spi package-info.java then I assume it time that the second paragraph will need to change as there will be other provider interfaces.

Right. I think it is ok for now, and when additional providers are added it can be updated then.

Thanks,
-Chris.

> -Alan.
> 



From jason_mehrens at hotmail.com  Fri Feb 13 21:57:42 2015
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Fri, 13 Feb 2015 15:57:42 -0600
Subject: RFR: 8072645: java.util.logging should use java.time to get
	more precise time stamps
In-Reply-To: <54DE109C.4030307@oracle.com>
References: <54DE109C.4030307@oracle.com>
Message-ID: <BLU175-W436CC3100DC42EC016B15E83230@phx.gbl>

Daniel,


In the XMLFormatter.format you can get rid of the double call to getNanoAdjustment() since you have stored the value in the local var 'nanos'.  



For the new XMLFormatter constructor what do you think about using Properties, Function<String, String>, or perhaps a builder pattern?

That way if XMLFormatter is modified in the future to support Throwable.getCause and Throwable.getSuppressed you don't have to keep creating constructors to toggle features.



Jason



----------------------------------------
> Date: Fri, 13 Feb 2015 15:56:28 +0100
> From: daniel.fuchs at oracle.com
> To: core-libs-dev at openjdk.java.net
> Subject: RFR: 8072645: java.util.logging should use java.time to get more precise time stamps
>
> Hi,
>
> Please find below a patch for:
>
> 8072645: java.util.logging should use java.time to get more
> precise time stamps
>
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/
>
> specdiff:
> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/specdiff-logging-time/java/util/logging/package-summary.html
>
> Overview:
> ---------
>
> The patch is made of the following pieces:
>
> - LogRecord uses java.time.Clock's systemClock to get an
> Instant in the best available resolution.
>
> The instant is split into a number of milliseconds (a long)
> and a nanosecond adjustment (an int).
> The number of milliseconds is the same than what would have
> been obtained by calling System.currentTimeMillis().
>
> - LogRecord acquires a new serializable int nanoAdjustement field,
> which can be used together with the number of milliseconds
> to reconstruct the instant.
>
> - SimpleFormatter is updated to pass a ZoneDateTime
> instance to String.format, instead of a Date.
>
> The effect of that is that the format string can now
> be configure to print the full instant precision, if
> needed.
>
> - XMLformatter will add a new <nanos> element after the
> <millis> element - if the value of the nanoAdjustment
> field is not 0.
>
> The <date> string will also contain the nano second
> adjustment as well as the zone offset as formatted by
> DateTimeFormatter.ISO_OFFSET_DATE_TIME
>
> Compatibility considerations:
> -----------------------------
>
> - The serial for of log record is backward/forward compatible.
> I added a test to verify that.
>
> - XMLFormatter has acquired a new configurable property
> '<FQCN>.printNanos' which allows to revert to the old
> XML format, should the new format cause issues in
> existing applications.
>
> - The logger.dtd will need to be updated, to support the
> new optional <nanos> element. And for this matter,
> should we update the logger.dtd or rather define a
> logger-v2.dtd?
> See planned modification:
>
> <http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-dtd/logger.dtd.frames.html>
>
> best regards,
>
> -- daniel 		 	   		  

From dean.long at oracle.com  Fri Feb 13 22:52:07 2015
From: dean.long at oracle.com (Dean Long)
Date: Fri, 13 Feb 2015 14:52:07 -0800
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54DDFE72.1050306@redhat.com>
References: <54DDFE72.1050306@redhat.com>
Message-ID: <54DE8017.6080608@oracle.com>

My understanding is that whether or not aarch64 allows unaligned 
accesses is based on a
system setting, so this change is too simplistic.  I would prefer that 
this was controlled with
something more flexible, like "sun.cpu.unaligned".

dl

On 2/13/2015 5:38 AM, Andrew Haley wrote:
> java.?nio.?DirectByteBuffer.getXXX is slow for types larger than byte
> because the runtime does not know that AArch64 can perform unaligned
> memory accesses.
>
> The problem is due to this code in java.nio.Bits.unaligned():
>
>          unaligned = arch.equals("i386") || arch.equals("x86")
>              || arch.equals("amd64") || arch.equals("x86_64");
>
> If we add AArch64 to this list code quality is very much improved.
>
> http://cr.openjdk.java.net/~aph/8073093/
>
> Thanks,
> Andrew.



From christos at zoulas.com  Fri Feb 13 23:04:16 2015
From: christos at zoulas.com (Christos Zoulas)
Date: Fri, 13 Feb 2015 18:04:16 -0500
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54DE8017.6080608@oracle.com> from Dean Long (Feb 13,  2:52pm)
Message-ID: <20150213230416.5E7B617FDAA@rebar.astron.com>

On Feb 13,  2:52pm, dean.long at oracle.com (Dean Long) wrote:
-- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer 

| My understanding is that whether or not aarch64 allows unaligned=20
| accesses is based on a
| system setting, so this change is too simplistic.  I would prefer that=20
| this was controlled with
| something more flexible, like "sun.cpu.unaligned".

So does x86_64 and you can ask the CPU if it is enabled... I am not sure
if a variable setting makes sense because if alignment is required you
get a signal (BUS error -- hi linux, SEGV), or incorrect results.

christos


From dean.long at oracle.com  Fri Feb 13 23:41:43 2015
From: dean.long at oracle.com (Dean Long)
Date: Fri, 13 Feb 2015 15:41:43 -0800
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <20150213230416.5E7B617FDAA@rebar.astron.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>
Message-ID: <54DE8BB7.5050801@oracle.com>

On 2/13/2015 3:04 PM, christos at zoulas.com wrote:
> On Feb 13,  2:52pm, dean.long at oracle.com (Dean Long) wrote:
> -- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
>
> | My understanding is that whether or not aarch64 allows unaligned=20
> | accesses is based on a
> | system setting, so this change is too simplistic.  I would prefer that=20
> | this was controlled with
> | something more flexible, like "sun.cpu.unaligned".
>
> So does x86_64 and you can ask the CPU if it is enabled... I am not sure
> if a variable setting makes sense because if alignment is required you
> get a signal (BUS error -- hi linux, SEGV), or incorrect results.
>
> christos

So it sounds like we need to determine if unaligned accesses are 
supported during startup,
in a platform-specific way.  This could be exposed through a property 
like I suggested,
or perhaps a new Unsafe method.

Regarding x86_64, there may be places in the JVM that already assume 
unaligned accesses
are allowed, so disabling them may completely break the JVM until those 
assumptions
are fixed.

dl


From vladimir.kozlov at oracle.com  Sat Feb 14 00:05:20 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 13 Feb 2015 16:05:20 -0800
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54DE8BB7.5050801@oracle.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>
	<54DE8BB7.5050801@oracle.com>
Message-ID: <54DE9140.3040604@oracle.com>

x86 has flag UseUnalignedLoadStores which is set to true depending on 
which version of CPU VM runs. The CPU version is determined based on 
CPUID instruction results.

Does AARCH64 has something similar?

Regards,
Vladimir

On 2/13/15 3:41 PM, Dean Long wrote:
> On 2/13/2015 3:04 PM, christos at zoulas.com wrote:
>> On Feb 13,  2:52pm, dean.long at oracle.com (Dean Long) wrote:
>> -- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for
>> ByteBuffer
>>
>> | My understanding is that whether or not aarch64 allows unaligned=20
>> | accesses is based on a
>> | system setting, so this change is too simplistic.  I would prefer
>> that=20
>> | this was controlled with
>> | something more flexible, like "sun.cpu.unaligned".
>>
>> So does x86_64 and you can ask the CPU if it is enabled... I am not sure
>> if a variable setting makes sense because if alignment is required you
>> get a signal (BUS error -- hi linux, SEGV), or incorrect results.
>>
>> christos
>
> So it sounds like we need to determine if unaligned accesses are
> supported during startup,
> in a platform-specific way.  This could be exposed through a property
> like I suggested,
> or perhaps a new Unsafe method.
>
> Regarding x86_64, there may be places in the JVM that already assume
> unaligned accesses
> are allowed, so disabling them may completely break the JVM until those
> assumptions
> are fixed.
>
> dl


From john.r.rose at oracle.com  Sat Feb 14 00:09:17 2015
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 13 Feb 2015 16:09:17 -0800
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54DE9140.3040604@oracle.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>
	<54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com>
Message-ID: <FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>

These queries need to go into Unsafe.
We also need Unsafe.getIntMisaligned, etc., which wire through to whatever second-best mechanism the platform offers.
? John

From dean.long at oracle.com  Sat Feb 14 00:22:51 2015
From: dean.long at oracle.com (Dean Long)
Date: Fri, 13 Feb 2015 16:22:51 -0800
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54DE9140.3040604@oracle.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>
	<54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com>
Message-ID: <54DE955B.4050905@oracle.com>

There is a system register bit to read, but I don't think it can be 
accessed by an application, only the kernel.
If the OS won't provide this information, you could do something similar 
to safeFetchN and catch the
resulting SIGBUS.

dl

On 2/13/2015 4:05 PM, Vladimir Kozlov wrote:
> x86 has flag UseUnalignedLoadStores which is set to true depending on 
> which version of CPU VM runs. The CPU version is determined based on 
> CPUID instruction results.
>
> Does AARCH64 has something similar?
>
> Regards,
> Vladimir
>
> On 2/13/15 3:41 PM, Dean Long wrote:
>> On 2/13/2015 3:04 PM, christos at zoulas.com wrote:
>>> On Feb 13,  2:52pm, dean.long at oracle.com (Dean Long) wrote:
>>> -- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for
>>> ByteBuffer
>>>
>>> | My understanding is that whether or not aarch64 allows unaligned=20
>>> | accesses is based on a
>>> | system setting, so this change is too simplistic.  I would prefer
>>> that=20
>>> | this was controlled with
>>> | something more flexible, like "sun.cpu.unaligned".
>>>
>>> So does x86_64 and you can ask the CPU if it is enabled... I am not 
>>> sure
>>> if a variable setting makes sense because if alignment is required you
>>> get a signal (BUS error -- hi linux, SEGV), or incorrect results.
>>>
>>> christos
>>
>> So it sounds like we need to determine if unaligned accesses are
>> supported during startup,
>> in a platform-specific way.  This could be exposed through a property
>> like I suggested,
>> or perhaps a new Unsafe method.
>>
>> Regarding x86_64, there may be places in the JVM that already assume
>> unaligned accesses
>> are allowed, so disabling them may completely break the JVM until those
>> assumptions
>> are fixed.
>>
>> dl



From vladimir.kozlov at oracle.com  Sat Feb 14 00:29:28 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 13 Feb 2015 16:29:28 -0800
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54DE955B.4050905@oracle.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>
	<54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com>
	<54DE955B.4050905@oracle.com>
Message-ID: <54DE96E8.3030608@oracle.com>

On 2/13/15 4:22 PM, Dean Long wrote:
> There is a system register bit to read, but I don't think it can be
> accessed by an application, only the kernel.
> If the OS won't provide this information, you could do something similar
> to safeFetchN and catch the
> resulting SIGBUS.

Yes, I agree it could be done this way too.
On x86 we trigger SEGV to verify that OS's signal handler correctly 
save/restore AVX registers so we can use them.

Vladimir

>
> dl
>
> On 2/13/2015 4:05 PM, Vladimir Kozlov wrote:
>> x86 has flag UseUnalignedLoadStores which is set to true depending on
>> which version of CPU VM runs. The CPU version is determined based on
>> CPUID instruction results.
>>
>> Does AARCH64 has something similar?
>>
>> Regards,
>> Vladimir
>>
>> On 2/13/15 3:41 PM, Dean Long wrote:
>>> On 2/13/2015 3:04 PM, christos at zoulas.com wrote:
>>>> On Feb 13,  2:52pm, dean.long at oracle.com (Dean Long) wrote:
>>>> -- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for
>>>> ByteBuffer
>>>>
>>>> | My understanding is that whether or not aarch64 allows unaligned=20
>>>> | accesses is based on a
>>>> | system setting, so this change is too simplistic.  I would prefer
>>>> that=20
>>>> | this was controlled with
>>>> | something more flexible, like "sun.cpu.unaligned".
>>>>
>>>> So does x86_64 and you can ask the CPU if it is enabled... I am not
>>>> sure
>>>> if a variable setting makes sense because if alignment is required you
>>>> get a signal (BUS error -- hi linux, SEGV), or incorrect results.
>>>>
>>>> christos
>>>
>>> So it sounds like we need to determine if unaligned accesses are
>>> supported during startup,
>>> in a platform-specific way.  This could be exposed through a property
>>> like I suggested,
>>> or perhaps a new Unsafe method.
>>>
>>> Regarding x86_64, there may be places in the JVM that already assume
>>> unaligned accesses
>>> are allowed, so disabling them may completely break the JVM until those
>>> assumptions
>>> are fixed.
>>>
>>> dl
>


From ecki at zusammenkunft.net  Sat Feb 14 02:31:03 2015
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sat, 14 Feb 2015 03:31:03 +0100
Subject: RFR: 8072645: java.util.logging should use java.time to get
	more precise time stamps
In-Reply-To: <BLU175-W436CC3100DC42EC016B15E83230@phx.gbl>
References: <54DE109C.4030307@oracle.com>
	<BLU175-W436CC3100DC42EC016B15E83230@phx.gbl>
Message-ID: <20150214033103.00006277.ecki@zusammenkunft.net>

Hello,

it is good to see new features beeing used. I wonder what the
performance impact is. I think the new accesor is not yet an intrinsic
- but on the other hand it seems not so worse. In addition to that the
splitting in long+int also takes some additional time.

Gruss
Bernd

Am Fri, 13 Feb 2015
  15:57:42 -0600 schrieb Jason Mehrens <jason_mehrens at hotmail.com>:

> Daniel,
> 
> 
> In the XMLFormatter.format you can get rid of the double call to
> getNanoAdjustment() since you have stored the value in the local var
> 'nanos'.  
> 
> 
> 
> For the new XMLFormatter constructor what do you think about using
> Properties, Function<String, String>, or perhaps a builder pattern?
> 
> That way if XMLFormatter is modified in the future to support
> Throwable.getCause and Throwable.getSuppressed you don't have to keep
> creating constructors to toggle features.
> 
> 
> 
> Jason
> 
> 
> 
> ----------------------------------------
> > Date: Fri, 13 Feb 2015 15:56:28 +0100
> > From: daniel.fuchs at oracle.com
> > To: core-libs-dev at openjdk.java.net
> > Subject: RFR: 8072645: java.util.logging should use java.time to
> > get more precise time stamps
> >
> > Hi,
> >
> > Please find below a patch for:
> >
> > 8072645: java.util.logging should use java.time to get more
> > precise time stamps
> >
> >
> > http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/
> >
> > specdiff:
> > http://cr.openjdk.java.net/~dfuchs/webrev_8072645/specdiff-logging-time/java/util/logging/package-summary.html
> >
> > Overview:
> > ---------
> >
> > The patch is made of the following pieces:
> >
> > - LogRecord uses java.time.Clock's systemClock to get an
> > Instant in the best available resolution.
> >
> > The instant is split into a number of milliseconds (a long)
> > and a nanosecond adjustment (an int).
> > The number of milliseconds is the same than what would have
> > been obtained by calling System.currentTimeMillis().
> >
> > - LogRecord acquires a new serializable int nanoAdjustement field,
> > which can be used together with the number of milliseconds
> > to reconstruct the instant.
> >
> > - SimpleFormatter is updated to pass a ZoneDateTime
> > instance to String.format, instead of a Date.
> >
> > The effect of that is that the format string can now
> > be configure to print the full instant precision, if
> > needed.
> >
> > - XMLformatter will add a new <nanos> element after the
> > <millis> element - if the value of the nanoAdjustment
> > field is not 0.
> >
> > The <date> string will also contain the nano second
> > adjustment as well as the zone offset as formatted by
> > DateTimeFormatter.ISO_OFFSET_DATE_TIME
> >
> > Compatibility considerations:
> > -----------------------------
> >
> > - The serial for of log record is backward/forward compatible.
> > I added a test to verify that.
> >
> > - XMLFormatter has acquired a new configurable property
> > '<FQCN>.printNanos' which allows to revert to the old
> > XML format, should the new format cause issues in
> > existing applications.
> >
> > - The logger.dtd will need to be updated, to support the
> > new optional <nanos> element. And for this matter,
> > should we update the logger.dtd or rather define a
> > logger-v2.dtd?
> > See planned modification:
> >
> > <http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-dtd/logger.dtd.frames.html>
> >
> > best regards,
> >
> > -- daniel 		 	   		  


From christos at zoulas.com  Sat Feb 14 03:34:41 2015
From: christos at zoulas.com (Christos Zoulas)
Date: Fri, 13 Feb 2015 22:34:41 -0500
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54DE96E8.3030608@oracle.com>
	from Vladimir Kozlov (Feb 13,  4:29pm)
Message-ID: <20150214033441.8238417FDAA@rebar.astron.com>

On Feb 13,  4:29pm, vladimir.kozlov at oracle.com (Vladimir Kozlov) wrote:
-- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer 

| On 2/13/15 4:22 PM, Dean Long wrote:
| > There is a system register bit to read, but I don't think it can be
| > accessed by an application, only the kernel.
| > If the OS won't provide this information, you could do something similar
| > to safeFetchN and catch the
| > resulting SIGBUS.
| 
| Yes, I agree it could be done this way too.
| On x86 we trigger SEGV to verify that OS's signal handler correctly 
| save/restore AVX registers so we can use them.

It is PSL_AC (0x40000) and it is accessible by applications. Now
if it works or not depends on the flavor of the x86... As I mentioned
before there are implementations (for example pre-arm-v6 flavors)
where unaligned accesses don't signal (but don't work). There is
an even 3rd category where unaligned accesses trap, but the kernel
can fix them if the binary is marked specially (sparc with misaligned
for example).

The "portable" to verify what's going on is to do the misaligned
access and see if it works (dealing with SIGBUS/SIGSEGV).  Even
then (even when it works) you might not want to do it because of
performance reasons (for example when the kernel fixes it).

christos


From aph at redhat.com  Sat Feb 14 08:01:08 2015
From: aph at redhat.com (Andrew Haley)
Date: Sat, 14 Feb 2015 08:01:08 +0000
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>
	<54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com>
	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
Message-ID: <54DF00C4.7030308@redhat.com>

On 02/14/2015 12:09 AM, John Rose wrote:
> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever second-best mechanism the platform offers.

Indeed.  I'm intending to prototype a design for those next week.  OK?

Andrew.



From aph at redhat.com  Sat Feb 14 08:07:06 2015
From: aph at redhat.com (Andrew Haley)
Date: Sat, 14 Feb 2015 08:07:06 +0000
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54DE8017.6080608@oracle.com>
References: <54DDFE72.1050306@redhat.com> <54DE8017.6080608@oracle.com>
Message-ID: <54DF022A.9080707@redhat.com>

On 02/13/2015 10:52 PM, Dean Long wrote:

> My understanding is that whether or not aarch64 allows unaligned
> accesses is based on a system setting, so this change is too
> simplistic.

Disabling unaligned access would be a really perverse thing to do, and
I suspect that GCC and glibc already assume that unaligned accesses
work so it would require a recompilation of libjvm (and probably the
whole OS) to make it work.  However, if you really think there's a
point to making this a runtime flag I won't resist.

Andrew.


From peter.levart at gmail.com  Sat Feb 14 09:36:42 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 14 Feb 2015 10:36:42 +0100
Subject: RFR: 8072645: java.util.logging should use java.time to get more
	precise time stamps
In-Reply-To: <54DE109C.4030307@oracle.com>
References: <54DE109C.4030307@oracle.com>
Message-ID: <54DF172A.7000308@gmail.com>

Hi Daniel,

The "millis" property in your proposal just changes one part of 
LogRecord's notion of time (it doesn't change/reset the nanoAdjustment 
part). From compatibility standpoint, your ptoposal is changing the 
semantics of "millis" property. Previously "millis" was the sole 
property of record's notion of time, now it is only a component of it. 
Consider this legacy code:

LogRecord r = new LogRecord(...); // timestamp1
...
r.setMillis(System.currentTimeMillis()); // timestamp2

What is the record's notion of time now? It is composed of "millis" from 
timestamp2 and "nanoAdjustment" from timestamp1. Not something that one 
would want, right?

So what should be done instead is:
- deprecate "millis" writable property and document that it sets the 
record's time with the resolution of milliseconds and point to new 
"instantUTC" property as a replacement.
- add "instantUTC" writable property and document it as "the" method to 
be used to set record's time with full resolution
- optionally add read-only "nanoAdjustment" property (I don't think it 
is needed, since users should start using new time API instead of 
mangling with millis and nanos themselves)

This lends itself to also change internal storage of LogRecord's time. 
You could just replace the "millis" field with a reference to 
"instantUTC". Serialization would have to be adjusted a bit (using 
serialPersistentFields) to stay compatible.

What do you think?

Regards, Peter

On 02/13/2015 03:56 PM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a patch for:
>
> 8072645: java.util.logging should use java.time to get more
>          precise time stamps
>
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/
>
> specdiff:
> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/specdiff-logging-time/java/util/logging/package-summary.html 
>
>
> Overview:
> ---------
>
> The patch is made of the following pieces:
>
>  - LogRecord uses java.time.Clock's systemClock to get an
>    Instant in the best available resolution.
>
>    The instant is split into a number of milliseconds (a long)
>    and a nanosecond adjustment (an int).
>    The number of milliseconds is the same than what would have
>    been obtained by calling System.currentTimeMillis().
>
>  - LogRecord acquires a new serializable int nanoAdjustement field,
>    which can be used together with the number of milliseconds
>    to reconstruct the instant.
>
>  - SimpleFormatter is updated to pass a ZoneDateTime
>    instance to String.format, instead of a Date.
>
>    The effect of that is that the format string can now
>    be configure to print the full instant precision, if
>    needed.
>
>  - XMLformatter will add a new <nanos> element after the
>    <millis> element - if the value of the nanoAdjustment
>    field is not 0.
>
>    The <date> string will also contain the nano second
>    adjustment as well as the zone offset as formatted by
>    DateTimeFormatter.ISO_OFFSET_DATE_TIME
>
> Compatibility considerations:
> -----------------------------
>
> - The serial for of log record is backward/forward compatible.
>   I added a test to verify that.
>
> - XMLFormatter has acquired a new configurable property
>   '<FQCN>.printNanos' which allows to revert to the old
>   XML format, should the new format cause issues in
>   existing applications.
>
> - The logger.dtd will need to be updated, to support the
>   new optional <nanos> element. And for this matter,
>   should we update the logger.dtd or rather define a
>   logger-v2.dtd?
>   See planned modification:
>
> <http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-dtd/logger.dtd.frames.html> 
>
>
> best regards,
>
> -- daniel



From scolebourne at joda.org  Sat Feb 14 10:28:10 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sat, 14 Feb 2015 10:28:10 +0000
Subject: RFR: 8072645: java.util.logging should use java.time to get more
	precise time stamps
In-Reply-To: <54DE109C.4030307@oracle.com>
References: <54DE109C.4030307@oracle.com>
Message-ID: <CACzrW9BgsCVZvZKdd=+1rEao1V7bSg7N_QJD0BpJsaywJAj2-A@mail.gmail.com>

Elements of the date/time handling here don't really work.

Logging is essentially a UTC only problem, using a time-zone is slow and
unecessary. This indicates that all uses of ZonedDateTime should be
replaced with either Instant or an OffsetDateTime using ZoneOffset.UTC.

Any string format should have the ISO-8601 string end with "Z", and not end
with "-05:00" or any other zone offset.

(The webrev is broken wrt zones as it stores ZoneId.systemDefault() in a
static constant, but that method depends on the mutable
TimeZone.getDefault() ).


LogReecord.getInstantUTC() should be getInstant().

(An Instant is fully defined as a concept, and it cannot be in or not in
UTC).


In SimpleFormatter, you have {@code java.util.loggin} (missing a "g").


In XMLFormatter, instead of using DateTimeFormatter.ISO_LOCAL_DATE_TIME,
create a new instance of DateTimeFormatter that does not output the
fraction of a second. That way, there is no need to use
truncatedTo(SECONDS).

StringBuilder appends can be used directly with formatters:

sb.append(ZonedDateTime.ofInstant(time, zoneId).format(dtformatter));

replace with

dtformatter.formatTo(ZonedDateTime.ofInstant(time, zoneId), sb);

thanks
Stephen



On 13 Feb 2015 14:57, "Daniel Fuchs" <daniel.fuchs at oracle.com> wrote:

> Hi,
>
> Please find below a patch for:
>
> 8072645: java.util.logging should use java.time to get more
>          precise time stamps
>
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/
>
> specdiff:
> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/
> specdiff-logging-time/java/util/logging/package-summary.html
>
> Overview:
> ---------
>
> The patch is made of the following pieces:
>
>  - LogRecord uses java.time.Clock's systemClock to get an
>    Instant in the best available resolution.
>
>    The instant is split into a number of milliseconds (a long)
>    and a nanosecond adjustment (an int).
>    The number of milliseconds is the same than what would have
>    been obtained by calling System.currentTimeMillis().
>
>  - LogRecord acquires a new serializable int nanoAdjustement field,
>    which can be used together with the number of milliseconds
>    to reconstruct the instant.
>
>  - SimpleFormatter is updated to pass a ZoneDateTime
>    instance to String.format, instead of a Date.
>
>    The effect of that is that the format string can now
>    be configure to print the full instant precision, if
>    needed.
>
>  - XMLformatter will add a new <nanos> element after the
>    <millis> element - if the value of the nanoAdjustment
>    field is not 0.
>
>    The <date> string will also contain the nano second
>    adjustment as well as the zone offset as formatted by
>    DateTimeFormatter.ISO_OFFSET_DATE_TIME
>
> Compatibility considerations:
> -----------------------------
>
> - The serial for of log record is backward/forward compatible.
>   I added a test to verify that.
>
> - XMLFormatter has acquired a new configurable property
>   '<FQCN>.printNanos' which allows to revert to the old
>   XML format, should the new format cause issues in
>   existing applications.
>
> - The logger.dtd will need to be updated, to support the
>   new optional <nanos> element. And for this matter,
>   should we update the logger.dtd or rather define a
>   logger-v2.dtd?
>   See planned modification:
>
> <http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-
> dtd/logger.dtd.frames.html>
>
> best regards,
>
> -- daniel
>


From daniel.fuchs at oracle.com  Sat Feb 14 12:06:21 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Sat, 14 Feb 2015 13:06:21 +0100
Subject: RFR: 8072645: java.util.logging should use java.time to get more
	precise time stamps
In-Reply-To: <BLU175-W436CC3100DC42EC016B15E83230@phx.gbl>
References: <54DE109C.4030307@oracle.com>
	<BLU175-W436CC3100DC42EC016B15E83230@phx.gbl>
Message-ID: <54DF3A3D.8000308@oracle.com>

Hi Jason,

On 2/13/15 10:57 PM, Jason Mehrens wrote:
> Daniel,
>
>
> In the XMLFormatter.format you can get rid of the double call to getNanoAdjustment() since you have stored the value in the local var 'nanos'.

Thanks for spotting that, will do.

>
> For the new XMLFormatter constructor what do you think about using Properties, Function<String, String>, or perhaps a builder pattern?
>
> That way if XMLFormatter is modified in the future to support Throwable.getCause and Throwable.getSuppressed you don't have to keep creating constructors to toggle features.

I don't know... I added the new constructor as an after thought, to help
writing subclasses that might not want to rely on the property defined
in the configuration. If we're going to rely on property anyway, then
the correct thing to do would be to define them as configuration properties
and look for them in the LogManager.

Maybe I should just remove the new constructor.

What do you think?

best regards,

-- daniel

>
>
>
> Jason
>
>
>
> ----------------------------------------
>> Date: Fri, 13 Feb 2015 15:56:28 +0100
>> From: daniel.fuchs at oracle.com
>> To: core-libs-dev at openjdk.java.net
>> Subject: RFR: 8072645: java.util.logging should use java.time to get more precise time stamps
>>
>> Hi,
>>
>> Please find below a patch for:
>>
>> 8072645: java.util.logging should use java.time to get more
>> precise time stamps
>>
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/
>>
>> specdiff:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/specdiff-logging-time/java/util/logging/package-summary.html
>>
>> Overview:
>> ---------
>>
>> The patch is made of the following pieces:
>>
>> - LogRecord uses java.time.Clock's systemClock to get an
>> Instant in the best available resolution.
>>
>> The instant is split into a number of milliseconds (a long)
>> and a nanosecond adjustment (an int).
>> The number of milliseconds is the same than what would have
>> been obtained by calling System.currentTimeMillis().
>>
>> - LogRecord acquires a new serializable int nanoAdjustement field,
>> which can be used together with the number of milliseconds
>> to reconstruct the instant.
>>
>> - SimpleFormatter is updated to pass a ZoneDateTime
>> instance to String.format, instead of a Date.
>>
>> The effect of that is that the format string can now
>> be configure to print the full instant precision, if
>> needed.
>>
>> - XMLformatter will add a new <nanos> element after the
>> <millis> element - if the value of the nanoAdjustment
>> field is not 0.
>>
>> The <date> string will also contain the nano second
>> adjustment as well as the zone offset as formatted by
>> DateTimeFormatter.ISO_OFFSET_DATE_TIME
>>
>> Compatibility considerations:
>> -----------------------------
>>
>> - The serial for of log record is backward/forward compatible.
>> I added a test to verify that.
>>
>> - XMLFormatter has acquired a new configurable property
>> '<FQCN>.printNanos' which allows to revert to the old
>> XML format, should the new format cause issues in
>> existing applications.
>>
>> - The logger.dtd will need to be updated, to support the
>> new optional <nanos> element. And for this matter,
>> should we update the logger.dtd or rather define a
>> logger-v2.dtd?
>> See planned modification:
>>
>> <http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-dtd/logger.dtd.frames.html>
>>
>> best regards,
>>
>> -- daniel 		 	   		



From daniel.fuchs at oracle.com  Sat Feb 14 12:38:23 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Sat, 14 Feb 2015 13:38:23 +0100
Subject: RFR: 8072645: java.util.logging should use java.time to get more
	precise time stamps
In-Reply-To: <54DF172A.7000308@gmail.com>
References: <54DE109C.4030307@oracle.com> <54DF172A.7000308@gmail.com>
Message-ID: <54DF41BF.4040108@oracle.com>

Hi Peter,

On 2/14/15 10:36 AM, Peter Levart wrote:
> Hi Daniel,
>
> The "millis" property in your proposal just changes one part of 
> LogRecord's notion of time (it doesn't change/reset the nanoAdjustment 
> part). From compatibility standpoint, your ptoposal is changing the 
> semantics of "millis" property. Previously "millis" was the sole 
> property of record's notion of time, now it is only a component of it. 
> Consider this legacy code:
>
> LogRecord r = new LogRecord(...); // timestamp1
> ...
> r.setMillis(System.currentTimeMillis()); // timestamp2
>
> What is the record's notion of time now? It is composed of "millis" 
> from timestamp2 and "nanoAdjustment" from timestamp1. Not something 
> that one would want, right?

Excellent observation. I had missed that.
> So what should be done instead is:
> - deprecate "millis" writable property and document that it sets the 
> record's time with the resolution of milliseconds and point to new 
> "instantUTC" property as a replacement.
> - add "instantUTC" writable property and document it as "the" method 
> to be used to set record's time with full resolution
> - optionally add read-only "nanoAdjustment" property (I don't think it 
> is needed, since users should start using new time API instead of 
> mangling with millis and nanos themselves)
>
> This lends itself to also change internal storage of LogRecord's time. 
> You could just replace the "millis" field with a reference to 
> "instantUTC". Serialization would have to be adjusted a bit (using 
> serialPersistentFields) to stay compatible.
>
> What do you think?

setMillis should definitely set the whole time for backward compatibility
reasons. That will make it more than a simple setter, and therefore 
deprecating
it is probably the best thing to do as the method name could then become
misleading (setTimeAsMillis() would be the expected name for such a
behaviour).

That lets me think that there shouldn't be a setNanoAdjustment() either.
getMillis() and getNanoAdjustment() are OK and can stay, since they
are consistent - are needed for compatibility reasons (at least 
getMillis is),
and will help with describing the serial form.

As you noted, the only correct way to set the LogRecord time is to do it 
in a
single method:
We could have either setInstant() or setTime(long millis, int nanos) - 
setInstant
being most probably the best alternative - since we already have a 
getInstant(),
and splitting the time into millis + nanos is a bit strange anyway - since
java.time favors seconds + nanos.

For serialization - I think we will need to keep serializing a number of 
milliseconds
and a nano second adjustment. Whether the time stamp should be stored 
internally
as an Instant or as a number of milliseconds + a nano adjustment can be 
discussed.

I might favor the second as it would make serialization easier 
(especially for
documenting the serial form).

Would you agree with that?

best regards,

-- daniel

>
> Regards, Peter
>
> On 02/13/2015 03:56 PM, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a patch for:
>>
>> 8072645: java.util.logging should use java.time to get more
>>          precise time stamps
>>
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/
>>
>> specdiff:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/specdiff-logging-time/java/util/logging/package-summary.html 
>>
>>
>> Overview:
>> ---------
>>
>> The patch is made of the following pieces:
>>
>>  - LogRecord uses java.time.Clock's systemClock to get an
>>    Instant in the best available resolution.
>>
>>    The instant is split into a number of milliseconds (a long)
>>    and a nanosecond adjustment (an int).
>>    The number of milliseconds is the same than what would have
>>    been obtained by calling System.currentTimeMillis().
>>
>>  - LogRecord acquires a new serializable int nanoAdjustement field,
>>    which can be used together with the number of milliseconds
>>    to reconstruct the instant.
>>
>>  - SimpleFormatter is updated to pass a ZoneDateTime
>>    instance to String.format, instead of a Date.
>>
>>    The effect of that is that the format string can now
>>    be configure to print the full instant precision, if
>>    needed.
>>
>>  - XMLformatter will add a new <nanos> element after the
>>    <millis> element - if the value of the nanoAdjustment
>>    field is not 0.
>>
>>    The <date> string will also contain the nano second
>>    adjustment as well as the zone offset as formatted by
>>    DateTimeFormatter.ISO_OFFSET_DATE_TIME
>>
>> Compatibility considerations:
>> -----------------------------
>>
>> - The serial for of log record is backward/forward compatible.
>>   I added a test to verify that.
>>
>> - XMLFormatter has acquired a new configurable property
>>   '<FQCN>.printNanos' which allows to revert to the old
>>   XML format, should the new format cause issues in
>>   existing applications.
>>
>> - The logger.dtd will need to be updated, to support the
>>   new optional <nanos> element. And for this matter,
>>   should we update the logger.dtd or rather define a
>>   logger-v2.dtd?
>>   See planned modification:
>>
>> <http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-dtd/logger.dtd.frames.html> 
>>
>>
>> best regards,
>>
>> -- daniel
>



From daniel.fuchs at oracle.com  Sat Feb 14 12:47:27 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Sat, 14 Feb 2015 13:47:27 +0100
Subject: RFR: 8072645: java.util.logging should use java.time to get more
	precise time stamps
In-Reply-To: <20150214033103.00006277.ecki@zusammenkunft.net>
References: <54DE109C.4030307@oracle.com>	<BLU175-W436CC3100DC42EC016B15E83230@phx.gbl>
	<20150214033103.00006277.ecki@zusammenkunft.net>
Message-ID: <54DF43DF.7030400@oracle.com>

Hi Bernd,

I will make some measurements - I don't expect that the cost
of the new accessor will matter much as from my early
measurements [1] it's not that far from the cost of
System.currentTimeMillis().

best regards,

-- daniel

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


On 2/14/15 3:31 AM, Bernd Eckenfels wrote:
> Hello,
>
> it is good to see new features beeing used. I wonder what the
> performance impact is. I think the new accesor is not yet an intrinsic
> - but on the other hand it seems not so worse. In addition to that the
> splitting in long+int also takes some additional time.
>
> Gruss
> Bernd
>
> Am Fri, 13 Feb 2015
>    15:57:42 -0600 schrieb Jason Mehrens <jason_mehrens at hotmail.com>:
>
>> Daniel,
>>
>>
>> In the XMLFormatter.format you can get rid of the double call to
>> getNanoAdjustment() since you have stored the value in the local var
>> 'nanos'.
>>
>>
>>
>> For the new XMLFormatter constructor what do you think about using
>> Properties, Function<String, String>, or perhaps a builder pattern?
>>
>> That way if XMLFormatter is modified in the future to support
>> Throwable.getCause and Throwable.getSuppressed you don't have to keep
>> creating constructors to toggle features.
>>
>>
>>
>> Jason
>>
>>
>>
>> ----------------------------------------
>>> Date: Fri, 13 Feb 2015 15:56:28 +0100
>>> From: daniel.fuchs at oracle.com
>>> To: core-libs-dev at openjdk.java.net
>>> Subject: RFR: 8072645: java.util.logging should use java.time to
>>> get more precise time stamps
>>>
>>> Hi,
>>>
>>> Please find below a patch for:
>>>
>>> 8072645: java.util.logging should use java.time to get more
>>> precise time stamps
>>>
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/
>>>
>>> specdiff:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/specdiff-logging-time/java/util/logging/package-summary.html
>>>
>>> Overview:
>>> ---------
>>>
>>> The patch is made of the following pieces:
>>>
>>> - LogRecord uses java.time.Clock's systemClock to get an
>>> Instant in the best available resolution.
>>>
>>> The instant is split into a number of milliseconds (a long)
>>> and a nanosecond adjustment (an int).
>>> The number of milliseconds is the same than what would have
>>> been obtained by calling System.currentTimeMillis().
>>>
>>> - LogRecord acquires a new serializable int nanoAdjustement field,
>>> which can be used together with the number of milliseconds
>>> to reconstruct the instant.
>>>
>>> - SimpleFormatter is updated to pass a ZoneDateTime
>>> instance to String.format, instead of a Date.
>>>
>>> The effect of that is that the format string can now
>>> be configure to print the full instant precision, if
>>> needed.
>>>
>>> - XMLformatter will add a new <nanos> element after the
>>> <millis> element - if the value of the nanoAdjustment
>>> field is not 0.
>>>
>>> The <date> string will also contain the nano second
>>> adjustment as well as the zone offset as formatted by
>>> DateTimeFormatter.ISO_OFFSET_DATE_TIME
>>>
>>> Compatibility considerations:
>>> -----------------------------
>>>
>>> - The serial for of log record is backward/forward compatible.
>>> I added a test to verify that.
>>>
>>> - XMLFormatter has acquired a new configurable property
>>> '<FQCN>.printNanos' which allows to revert to the old
>>> XML format, should the new format cause issues in
>>> existing applications.
>>>
>>> - The logger.dtd will need to be updated, to support the
>>> new optional <nanos> element. And for this matter,
>>> should we update the logger.dtd or rather define a
>>> logger-v2.dtd?
>>> See planned modification:
>>>
>>> <http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-dtd/logger.dtd.frames.html>
>>>
>>> best regards,
>>>
>>> -- daniel 		 	   		



From daniel.fuchs at oracle.com  Sat Feb 14 13:03:53 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Sat, 14 Feb 2015 14:03:53 +0100
Subject: RFR: 8072645: java.util.logging should use java.time to get more
	precise time stamps
In-Reply-To: <CACzrW9BgsCVZvZKdd=+1rEao1V7bSg7N_QJD0BpJsaywJAj2-A@mail.gmail.com>
References: <54DE109C.4030307@oracle.com>
	<CACzrW9BgsCVZvZKdd=+1rEao1V7bSg7N_QJD0BpJsaywJAj2-A@mail.gmail.com>
Message-ID: <54DF47B9.4050304@oracle.com>

Hi Stephen,

Thanks a lot for your feedback, it is really helpful!

On 2/14/15 11:28 AM, Stephen Colebourne wrote:
> Elements of the date/time handling here don't really work.
>
> Logging is essentially a UTC only problem, using a time-zone is slow and
> unecessary. This indicates that all uses of ZonedDateTime should be
> replaced with either Instant or an OffsetDateTime using ZoneOffset.UTC.
>
> Any string format should have the ISO-8601 string end with "Z", and not end
> with "-05:00" or any other zone offset.

If I'm not mistaken the previous SimpleFormatter used to use java.util.Date
and printed the time in the local time zone. I have tried to keep this 
behavior.
I'm not sure we would want to change it to print the time in the UTC 
time zone
by default. A lot of developers use logging for debugging - and when reading
debug messages on the console I usually prefer to see the time in my own
time zone.

Would there be a more efficient way to keep the default formatting of 
the time
in the SimpleFormatter?

> (The webrev is broken wrt zones as it stores ZoneId.systemDefault() in a
> static constant, but that method depends on the mutable
> TimeZone.getDefault() ).

Would making it a final (non static) variable be better?
I now wonder whether there should be a way to configure the time zone for
an instance of SimpleFormatter (something like what I did with 'printNanos'
for the XMLFormatter).

> LogReecord.getInstantUTC() should be getInstant().
>
> (An Instant is fully defined as a concept, and it cannot be in or not in
> UTC).

Right. Thanks for pointing that out.
> In SimpleFormatter, you have {@code java.util.loggin} (missing a "g").

Good catch.

> In XMLFormatter, instead of using DateTimeFormatter.ISO_LOCAL_DATE_TIME,
> create a new instance of DateTimeFormatter that does not output the
> fraction of a second. That way, there is no need to use
> truncatedTo(SECONDS).
>
> StringBuilder appends can be used directly with formatters:
>
> sb.append(ZonedDateTime.ofInstant(time, zoneId).format(dtformatter));
>
> replace with
>
> dtformatter.formatTo(ZonedDateTime.ofInstant(time, zoneId), sb);

Will look into this.

Thanks again for your review! This is quite helpful.

-- daniel


>
> thanks
> Stephen
>
>
>
> On 13 Feb 2015 14:57, "Daniel Fuchs" <daniel.fuchs at oracle.com> wrote:
>
>> Hi,
>>
>> Please find below a patch for:
>>
>> 8072645: java.util.logging should use java.time to get more
>>           precise time stamps
>>
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/
>>
>> specdiff:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/
>> specdiff-logging-time/java/util/logging/package-summary.html
>>
>> Overview:
>> ---------
>>
>> The patch is made of the following pieces:
>>
>>   - LogRecord uses java.time.Clock's systemClock to get an
>>     Instant in the best available resolution.
>>
>>     The instant is split into a number of milliseconds (a long)
>>     and a nanosecond adjustment (an int).
>>     The number of milliseconds is the same than what would have
>>     been obtained by calling System.currentTimeMillis().
>>
>>   - LogRecord acquires a new serializable int nanoAdjustement field,
>>     which can be used together with the number of milliseconds
>>     to reconstruct the instant.
>>
>>   - SimpleFormatter is updated to pass a ZoneDateTime
>>     instance to String.format, instead of a Date.
>>
>>     The effect of that is that the format string can now
>>     be configure to print the full instant precision, if
>>     needed.
>>
>>   - XMLformatter will add a new <nanos> element after the
>>     <millis> element - if the value of the nanoAdjustment
>>     field is not 0.
>>
>>     The <date> string will also contain the nano second
>>     adjustment as well as the zone offset as formatted by
>>     DateTimeFormatter.ISO_OFFSET_DATE_TIME
>>
>> Compatibility considerations:
>> -----------------------------
>>
>> - The serial for of log record is backward/forward compatible.
>>    I added a test to verify that.
>>
>> - XMLFormatter has acquired a new configurable property
>>    '<FQCN>.printNanos' which allows to revert to the old
>>    XML format, should the new format cause issues in
>>    existing applications.
>>
>> - The logger.dtd will need to be updated, to support the
>>    new optional <nanos> element. And for this matter,
>>    should we update the logger.dtd or rather define a
>>    logger-v2.dtd?
>>    See planned modification:
>>
>> <http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-
>> dtd/logger.dtd.frames.html>
>>
>> best regards,
>>
>> -- daniel
>>



From peter.levart at gmail.com  Sat Feb 14 14:56:51 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 14 Feb 2015 15:56:51 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>
	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
Message-ID: <54DF6233.9070408@gmail.com>


On 02/12/2015 09:52 PM, Paul Sandoz wrote:
> Hi
>
> In connection with the JEP there is also a design document to help the discussion:
>
>    http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
>
> We are especially interesting in hearing feedback from library developers, tool/IDE developers, and anyone doing funky stuff with class loading and JAR files.
>
> Paul.
>
> On Feb 12, 2015, at 9:41 PM, mark.reinhold at oracle.com wrote:
>
>> New JEP Candidate: http://openjdk.java.net/jeps/238
>>
>> - Mark

Hi Paul,

I read through the proposal and couldn't find an explanation of how 
resources placed in versioned paths are going to be visible. For 
example, if the multi-versioned jar contains the following structure:

my.properties
META-INF/versions/8/my.properties
META-INF/versions/9/my.properties


What will the following code return, when run on JDK9:

URL[] urls = 
ClassLoader.getSystemClassLoader().getResources("my.properties");

Will we only get 1 URL: META-INF/versions/9/my.properties
or 3 URLs in order: META-INF/versions/9/my.properties, 
META-INF/versions/8/my.properties, my.properties

Class name -> .class file resolving is easy, since only the 1st one is 
used, but there can be multiple general resources for same path.

Regards, Peter



From peter.levart at gmail.com  Sat Feb 14 15:33:17 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 14 Feb 2015 16:33:17 +0100
Subject: RFR: 8072645: java.util.logging should use java.time to get more
	precise time stamps
In-Reply-To: <54DF41BF.4040108@oracle.com>
References: <54DE109C.4030307@oracle.com> <54DF172A.7000308@gmail.com>
	<54DF41BF.4040108@oracle.com>
Message-ID: <54DF6ABD.1080204@gmail.com>

Hi Daniel,

On 02/14/2015 01:38 PM, Daniel Fuchs wrote:
> Hi Peter,
>
> On 2/14/15 10:36 AM, Peter Levart wrote:
>> Hi Daniel,
>>
>> The "millis" property in your proposal just changes one part of 
>> LogRecord's notion of time (it doesn't change/reset the 
>> nanoAdjustment part). From compatibility standpoint, your ptoposal is 
>> changing the semantics of "millis" property. Previously "millis" was 
>> the sole property of record's notion of time, now it is only a 
>> component of it. Consider this legacy code:
>>
>> LogRecord r = new LogRecord(...); // timestamp1
>> ...
>> r.setMillis(System.currentTimeMillis()); // timestamp2
>>
>> What is the record's notion of time now? It is composed of "millis" 
>> from timestamp2 and "nanoAdjustment" from timestamp1. Not something 
>> that one would want, right?
>
> Excellent observation. I had missed that.
>> So what should be done instead is:
>> - deprecate "millis" writable property and document that it sets the 
>> record's time with the resolution of milliseconds and point to new 
>> "instantUTC" property as a replacement.
>> - add "instantUTC" writable property and document it as "the" method 
>> to be used to set record's time with full resolution
>> - optionally add read-only "nanoAdjustment" property (I don't think 
>> it is needed, since users should start using new time API instead of 
>> mangling with millis and nanos themselves)
>>
>> This lends itself to also change internal storage of LogRecord's 
>> time. You could just replace the "millis" field with a reference to 
>> "instantUTC". Serialization would have to be adjusted a bit (using 
>> serialPersistentFields) to stay compatible.
>>
>> What do you think?
>
> setMillis should definitely set the whole time for backward compatibility
> reasons. That will make it more than a simple setter, and therefore 
> deprecating
> it is probably the best thing to do as the method name could then become
> misleading (setTimeAsMillis() would be the expected name for such a
> behaviour).

Unfortunately. But there is javadoc to clear things out, so I don't find 
this too bad.

>
> That lets me think that there shouldn't be a setNanoAdjustment() either.

That's right. And I don't think we need a getter for nanoAdjustment 
either. See below...

> getMillis() and getNanoAdjustment() are OK and can stay, since they
> are consistent - are needed for compatibility reasons (at least 
> getMillis is),
> and will help with describing the serial form.
>
> As you noted, the only correct way to set the LogRecord time is to do 
> it in a
> single method:
> We could have either setInstant() or setTime(long millis, int nanos) - 
> setInstant
> being most probably the best alternative - since we already have a 
> getInstant(),
> and splitting the time into millis + nanos is a bit strange anyway - 
> since
> java.time favors seconds + nanos.

get/setInstant is the right name. As Stephen notes, Instant is timezone 
agnostic.


>
> For serialization - I think we will need to keep serializing a number 
> of milliseconds
> and a nano second adjustment. Whether the time stamp should be stored 
> internally
> as an Instant or as a number of milliseconds + a nano adjustment can 
> be discussed.
>
> I might favor the second as it would make serialization easier 
> (especially for
> documenting the serial form).
>
> Would you agree with that?

Well, internally I think it should be stored as an Instant. So you don't 
have to reconstruct Instant objects at each call to getInstant(). 
Serialization of LogRecord is not a frequent requirement, so the 
overhead should be moved to it, rather than to frequent code-paths. 
That's my opinion.

Documenting serializable format should be easy anyway. It doesn't have 
to be based directly on public getters/setters. For example:

The LogRecord's "instant" is serialized as two hypothetical fields to 
keep backwards compatibility:

long millis = getInstant().toEpochMilli();

int nanoOfMilli = getInstant().getNano() % 1000_000;


Regards, Peter


>
> best regards,
>
> -- daniel
>
>>
>> Regards, Peter
>>
>> On 02/13/2015 03:56 PM, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Please find below a patch for:
>>>
>>> 8072645: java.util.logging should use java.time to get more
>>>          precise time stamps
>>>
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/
>>>
>>> specdiff:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/specdiff-logging-time/java/util/logging/package-summary.html 
>>>
>>>
>>> Overview:
>>> ---------
>>>
>>> The patch is made of the following pieces:
>>>
>>>  - LogRecord uses java.time.Clock's systemClock to get an
>>>    Instant in the best available resolution.
>>>
>>>    The instant is split into a number of milliseconds (a long)
>>>    and a nanosecond adjustment (an int).
>>>    The number of milliseconds is the same than what would have
>>>    been obtained by calling System.currentTimeMillis().
>>>
>>>  - LogRecord acquires a new serializable int nanoAdjustement field,
>>>    which can be used together with the number of milliseconds
>>>    to reconstruct the instant.
>>>
>>>  - SimpleFormatter is updated to pass a ZoneDateTime
>>>    instance to String.format, instead of a Date.
>>>
>>>    The effect of that is that the format string can now
>>>    be configure to print the full instant precision, if
>>>    needed.
>>>
>>>  - XMLformatter will add a new <nanos> element after the
>>>    <millis> element - if the value of the nanoAdjustment
>>>    field is not 0.
>>>
>>>    The <date> string will also contain the nano second
>>>    adjustment as well as the zone offset as formatted by
>>>    DateTimeFormatter.ISO_OFFSET_DATE_TIME
>>>
>>> Compatibility considerations:
>>> -----------------------------
>>>
>>> - The serial for of log record is backward/forward compatible.
>>>   I added a test to verify that.
>>>
>>> - XMLFormatter has acquired a new configurable property
>>>   '<FQCN>.printNanos' which allows to revert to the old
>>>   XML format, should the new format cause issues in
>>>   existing applications.
>>>
>>> - The logger.dtd will need to be updated, to support the
>>>   new optional <nanos> element. And for this matter,
>>>   should we update the logger.dtd or rather define a
>>>   logger-v2.dtd?
>>>   See planned modification:
>>>
>>> <http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-dtd/logger.dtd.frames.html> 
>>>
>>>
>>> best regards,
>>>
>>> -- daniel
>>
>



From peter.levart at gmail.com  Sat Feb 14 17:23:40 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 14 Feb 2015 18:23:40 +0100
Subject: RFR: 8072645: java.util.logging should use java.time to get more
	precise time stamps
In-Reply-To: <54DF6ABD.1080204@gmail.com>
References: <54DE109C.4030307@oracle.com> <54DF172A.7000308@gmail.com>
	<54DF41BF.4040108@oracle.com> <54DF6ABD.1080204@gmail.com>
Message-ID: <54DF849C.30007@gmail.com>


On 02/14/2015 04:33 PM, Peter Levart wrote:
> Well, internally I think it should be stored as an Instant. So you 
> don't have to reconstruct Instant objects at each call to 
> getInstant(). Serialization of LogRecord is not a frequent 
> requirement, so the overhead should be moved to it, rather than to 
> frequent code-paths. That's my opinion.
>
> Documenting serializable format should be easy anyway. It doesn't have 
> to be based directly on public getters/setters. For example:
>
> The LogRecord's "instant" is serialized as two hypothetical fields to 
> keep backwards compatibility:
>
> long millis = getInstant().toEpochMilli();
>
> int nanoOfMilli = getInstant().getNano() % 1000_000;
>
>
> Regards, Peter

Hi Daniel,

I must admit, it's not so simple after all. I tried to do it and I had 
to do the following to get a decent javadoc:

http://cr.openjdk.java.net/~plevart/jdk9-dev/LogRecord.instant/webrev.01/


So take it if you think this isn't too much to support or leave it and 
do it your way (with just an additional @serial nanoAdjustment field).


Regards, Peter



From peter.levart at gmail.com  Sat Feb 14 19:54:54 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 14 Feb 2015 20:54:54 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>
	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
Message-ID: <54DFA80E.1000108@gmail.com>


On 02/12/2015 09:52 PM, Paul Sandoz wrote:
> Hi
>
> In connection with the JEP there is also a design document to help the discussion:
>
>    http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
>

Hi Paul,

Thinking about this proposal, I can't escape the feeling that the design 
favors JDK as the only target for which multi-version jars exist. The 
"versions" in the jar are just target JDK versions. Admittedly JDK is 
the most important "library" out there, but jar is a general format. So 
perhaps at the jar level, the facility could be more general. I'm 
thinking about profiles...

For example, taking a layout example from JEP and translating to the 
profiles idea:

jar root
   - A.class
   - B.class
   - C.class
   - D.class
   - META-INF
      - MANIFEST.MF
      - profiles
         - jdk8
            - A.class
            - B.class
         - jdk9
            - A.class


With additional metadata in MANIFEST.MF:

Profile-JDK9: jdk9 jdk8
Profile-JDK8: jdk8


A list (ordered) of profile names is associated with each jar file or 
expanded directory at runtime. The default list of profile names (if not 
specified on classpath) consists of just the platfrom profile name 
("JDK9" or "JDK8"), but additional profile names could be encoded as 
part of each classpath element.

For example, let's say I want to distribute a multi-profile library jar 
that depends on JDK7, JDK8 and JDK9 as platform and on guava 17 and 18. 
I could pack it as:

jar root
   - A.class
   - B.class
   - C.class
   - D.class
   - META-INF
      - MANIFEST.MF
      - profiles
         - jdk8
            - A.class
            - B.class
         - jdk9
            - A.class
         - guava18
            - C.class
         - jdk9-guava18
            - C.class

MANIFEST.MF:

Profile-JDK9: jdk9-guava18(GUAVA18) jdk9 jdk8
Profile-JDK8: jdk8
Profile-GUAVA18: guava18


Some example usages:

$JDK8_HOME/bin/java -cp guava-18.jar:mylib.jar?profile=+GUAVA18

...in this example, the list of profile names associated with mylib.jar 
is: (JDK8, GUAVA18), which yields the following search order inside 
mylib.jar:

- META-INF/profiles/jdk8
- META-INF/profiles/guava18
- jar root


$JDK9_HOME/bin/java -cp guava-18.jar:mylib.jar?profile=+GUAVA18

...in this example, the list of profile names associated with mylib.jar 
is : (JDK9, GUAVA18), which yields the following search order inside 
mylib.jar:

- META-INF/profiles/jdk9-guava18 - this is a conditional entry, included 
only when all profile names in brackets are also associated with the jar
- META-INF/profiles/jdk9
- META-INF/profiles/jdk8
- META-INF/profiles/guava18
- jar root


$JDK9_HOME/bin/java -cp guava-17.jar:mylib.jar

...in this example, the list of profile names associated with mylib.jar 
is : (JDK9), which yields the following search order inside mylib.jar:

- META-INF/profiles/jdk9
- META-INF/profiles/jdk8
- jar root


The "additional" profile names could be encoded in file: URL(s) as the 
the URL "query", for example:

file:/path/to/my.jar?pfofile=+GUAVA18

...so they are part of URL class-path in URLClassLoader.


The JarFile and JarInputStream would have to be extended to support 
specifying a list of profile names in addition to current arguments.

This is not much different from proposed JEP. It just adds a layer of 
resolving of the internal jar file paths through a list of profile names 
as opposed to hard-coding the layout. I know this complicates tooling 
support. In particular the additional options for "jar" tool, but 
verification part which validates that the exposed public API is same 
for all combinations of profiles would not be much more complicated.

The profiles idea is inspired loosely on Maven profiles.


Too complicated?


Regards, Peter



From xueming.shen at oracle.com  Sat Feb 14 20:30:26 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Sat, 14 Feb 2015 12:30:26 -0800
Subject: RFR:  JDK-8073152: Update Standard/ExtendedCharsets to work with
	module system
Message-ID: <54DFB062.3080008@oracle.com>

Hi,

Please help review the changes for  JDK-8073152

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

This change is to re-organize how the "standard" and "extended" charsets 
repository are
built for the jdk/jre images. Before module system, the "standard" 
charset provider is built
into rt.jar and the "extended" charsets provider is in charsets.jar, 
which is located in the
"lib/ext" directory. both are available during the system boot time. In 
jigsaw, the extended
charsets provider is in jdk.charset (vs the "standard" is in java.base) 
module and might not
be "visible" during the early phase of system classes loading, which 
might cause problem
as some of the charsets now in "extended" charsets may needed during the 
boot stage. The
proposed change here is to re-organize the way these two providers are 
built, and put in the
mechanism that enable the build system to configure which group of 
charsets need to be
moved from the "extended" charsets into the "standard" (java.base), 
based on the target
platform, during the jdk build time.

The updates are

(1) to consolidate the existing configuration files "sbcs", "dbcs", 
"extsbcs" and
      "standard-charsets" (and the aliases table originally hardcoded in 
ExtendeardCharsets.java)
       into a single configuration file "charsets" to define all 
supported charsets, with their
       name, clz name,  history name, package name and all aliases
http://cr.openjdk.java.net/~sherman/8073152/webrev/make/data/charsetmapping/charsets.html

(2) in addition to the the "standard charsets" provider, now the 
"extended charsets" provider
      class is also built during the build time based on the new 
configuration file "charsets"

(3) to add a build-time mechanism to specify individual sun.nio.cs.ext 
charset to be built into
      "standard" charsets provider (sun.nio.cs package in java.base 
module), with os-specific
       configuration file, such as stdcs-linux, stdcs-windows and 
stdcs-solaris.

(4) to move DoubleByte, HKSCS and DelegatableDecoder classes into 
sun.nio.cs, so they can be
      used/referenced by those dbcs classes that might be moved into 
sun.nio.cs

(5) to change some sun.nio.cs.ext implementation java files to be a 
".template", so the real .java
      can be generated during build-time with correct pkg name and 
aliases info.

There are two leftover, gb18030 and euc_tw, these are two charsets with 
huge mapping table. Might
need special update to better fit into sun.nio.cs later.

thanks!
-Sherman


From dean.long at oracle.com  Sat Feb 14 22:10:59 2015
From: dean.long at oracle.com (Dean Long)
Date: Sat, 14 Feb 2015 14:10:59 -0800
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54DF022A.9080707@redhat.com>
References: <54DDFE72.1050306@redhat.com> <54DE8017.6080608@oracle.com>
	<54DF022A.9080707@redhat.com>
Message-ID: <54DFC7F3.9050309@oracle.com>

On 2/14/2015 12:07 AM, Andrew Haley wrote:
> On 02/13/2015 10:52 PM, Dean Long wrote:
>
>> My understanding is that whether or not aarch64 allows unaligned
>> accesses is based on a system setting, so this change is too
>> simplistic.
> Disabling unaligned access would be a really perverse thing to do, and
> I suspect that GCC and glibc already assume that unaligned accesses
> work so it would require a recompilation of libjvm (and probably the
> whole OS) to make it work.  However, if you really think there's a
> point to making this a runtime flag I won't resist.
>
> Andrew.

Even if linux-aarch64 always allows unaligned, checking only for 
"aarch64" is not future-proof
because it doesn't take the OS into account.  However, I really don't 
like having to enumerate
all relevant platforms in multiple places in shared code, so I disagree 
with the existing code
and with perpetuating the pattern.  As long as the decision is in 
platform-specific code, a build-time
decision may be entirely appropriate.

dl


From dmitry.samersoff at oracle.com  Sun Feb 15 15:52:48 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Sun, 15 Feb 2015 18:52:48 +0300
Subject: RFR(S): JDK-8073175,
	8073174: Fix native warnings in libjli and libfdlibm
Message-ID: <54E0C0D0.4070107@oracle.com>

Hi Everyone,

It's my $0.02 to the warning cleanup work. Please review:

http://cr.openjdk.java.net/~dsamersoff/JDK-8073175/webrev.01
http://cr.openjdk.java.net/~dsamersoff/JDK-8073174/webrev.01

Notes:

1.
There are two common ways to cast pointer to int: intptr_t (perfectly
safe, more-or-less portable) and size_t (perfectly portable,
more-or-less safe)

So I use size_t in shared code, intptr_t in UNIX specific code.

2.
I didn't fix "format not a string literal" warnings. It requires to set
per-compiler pragmas.

-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 christos at zoulas.com  Sun Feb 15 16:22:18 2015
From: christos at zoulas.com (Christos Zoulas)
Date: Sun, 15 Feb 2015 11:22:18 -0500
Subject: RFR(S): JDK-8073175,
	8073174: Fix native warnings in libjli and libfdlibm
In-Reply-To: <54E0C0D0.4070107@oracle.com>
	from Dmitry Samersoff (Feb 15,  6:52pm)
Message-ID: <20150215162218.D735617FDAA@rebar.astron.com>

On Feb 15,  6:52pm, dmitry.samersoff at oracle.com (Dmitry Samersoff) wrote:
-- Subject: RFR(S): JDK-8073175, 8073174: Fix native warnings in libjli and l

| Hi Everyone,
| 
| It's my $0.02 to the warning cleanup work. Please review:
| 
| http://cr.openjdk.java.net/~dsamersoff/JDK-8073175/webrev.01
| http://cr.openjdk.java.net/~dsamersoff/JDK-8073174/webrev.01
| 
| Notes:
| 
| 1.
| There are two common ways to cast pointer to int: intptr_t (perfectly
| safe, more-or-less portable) and size_t (perfectly portable,
| more-or-less safe)
| 
| So I use size_t in shared code, intptr_t in UNIX specific code.
| 

Why are you using a signed and an unsigned type? You should probably
be using uintptr_t for consistency.

christos


From david.holmes at oracle.com  Mon Feb 16 05:55:02 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Feb 2015 15:55:02 +1000
Subject: RFR 8073124: Tune test and document TimSort runs length stack
	size increase
In-Reply-To: <54DE0436.5070301@oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>
	<54DCDB2D.3090006@oracle.com> <54DD5F6F.4070105@oracle.com>
	<54DE0436.5070301@oracle.com>
Message-ID: <54E18636.4000600@oracle.com>

On 14/02/2015 12:03 AM, Lev Priima wrote:
> Please review and push:
> http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8073124

I hadn't realized 8072909 had been pushed without final reviewer 
comments being addressed. :(

These changes seem okay. I hope they get promoted at the same time as 
the original changeset so we don't get test failures.

Thanks,
David

> Lev
>
> On 02/13/2015 05:20 AM, David Holmes wrote:
>> Hi Lev,
>>
>> On 13/02/2015 2:56 AM, Lev Priima wrote:
>>> Christos,
>>>
>>> Test may fail on shorter arrays(page 8 of paper). For instance, on worst
>>> case, generated by test, it starts to fail on length 67108864.
>>> After increasing stack size of runs to merge, Arrays.sort(T[]) works
>>> also on maximum possible array for HotSpot JVM.
>>
>> I'd also like to see this documented somewhere in the code. Presently
>> there is a reference to listsort.txt but then you have to go and find
>> it on the web. :( At a minimum could we please add:
>>
>>  175          * computation below must be changed if MIN_MERGE is
>> decreased.  See
>>  176          * the MIN_MERGE declaration above for more information.
>> +             * The maximum value of 49 allows for an array up to length
>> +             * Integer.MAX_VALUE-4.
>>
>>> Roger, David,
>>> I've updated the test (
>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html
>>>
>>> ) to make it more suitable for regular execution:
>>>
>>>    27  * @run main/othervm TimSortStackSize2 67108864
>>
>> This will still fail on small memory devices:
>>
>> :~> java TimSortStackSize2 67108864
>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>>
>> as the default heap ergonomics may not be large enough. I had to add a
>> minimum heap of -Xmx385M to get it to run.
>>
>> Thanks,
>> David
>>
>>>    28  * not for regular execution on all platforms:
>>>    29  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>    30  * run main/othervm -Xmx32g TimSortStackSize2 2147483644
>>>
>>> Could you please push this:
>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>>> ?
>>>
>>> Lev
>>>
>>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>>> On Feb 12, 9:57pm,david.holmes at oracle.com  (David Holmes) wrote:
>>>> -- Subject: Re: 8072909: TimSort fails with
>>>> ArrayIndexOutOfBoundsException on
>>>>
>>>> | Ok - thanks Lev!
>>>> |
>>>> | David
>>>>
>>>> For posterity can someone document this, and also the value for which
>>>> Integer.MAX_VALUE-4 fails?
>>>>
>>>> christos
>>>
>


From staffan.larsen at oracle.com  Mon Feb 16 07:47:45 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 16 Feb 2015 08:47:45 +0100
Subject: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
In-Reply-To: <B5F7A180-60F2-4B08-87B1-A8479D8AC43E@oracle.com>
References: <B5F7A180-60F2-4B08-87B1-A8479D8AC43E@oracle.com>
Message-ID: <BBFDE9CE-36F9-42DE-B058-B871ED7E489F@oracle.com>

Brian pointed out to me that this change missed to add the annotation to bridge methods. Here is an updated version that takes those into account. I also needed to update the test to verify that bridge methods were correctly annotated - it got a little bit more complex since I had to force bridges being used.

new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.01/ <http://cr.openjdk.java.net/~sla/8025636/webrev.01/>

Thanks,
/Staffan


> On 3 feb 2015, at 10:15, Staffan Larsen <staffan.larsen at oracle.com> wrote:
> 
> Hi,
> 
> Please review this patch for hiding the lambda proxy frame in stack traces:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8025636 <https://bugs.openjdk.java.net/browse/JDK-8025636>
> webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.00/ <http://cr.openjdk.java.net/~sla/8025636/webrev.00/>
> 
> This is a straightforward addition of the LambdaForm$Hidden annotation to the generated methods. What is surprising is that this works even if LambdaForm$Hidden is a package-private class in java.lang.invoke and thus not accessible from most of the generated classes. There is some discussion of and answers to this in the bug, but essentially this works because the annotation class is never resolved and the code in Hotspot that looks for the annotation amounts to nothing more than string comparisons.
> 
> Hidden stack frames can be shown by running with ?-XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames?.
> 
> For an example of what this patch does, consider this code:
> 
>        Runnable r = () -> { throw new RuntimeException(); };
>        r.run();
> 
> Previously, this would output:
> 
>     java.lang.RuntimeException
> 	at pkg.Foo.lambda$main$0(Foo.java:5)
> 	at pkg.Foo$$Lambda$1/2001112025.run(<Unknown>:1000000)
> 	at pkg.Foo.main(Foo.java:15)
> 
> With the patch it looks like this:
> 
>     java.lang.RuntimeException
> 	at pkg.Foo.lambda$main$0(Foo.java:5)
> 	at pkg.Foo.main(Foo.java:15)
> 
> 
> Thanks,
> /Staffan
> 



From lev.priima at oracle.com  Mon Feb 16 08:59:28 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Mon, 16 Feb 2015 11:59:28 +0300
Subject: RFR 8073124: Tune test and document TimSort runs length stack
	size increase
In-Reply-To: <54E18636.4000600@oracle.com>
References: <20150212125431.D46DB17FDAA@rebar.astron.com>
	<54DCDB2D.3090006@oracle.com> <54DD5F6F.4070105@oracle.com>
	<54DE0436.5070301@oracle.com> <54E18636.4000600@oracle.com>
Message-ID: <54E1B170.1000801@oracle.com>

Thanks, David,
Could you please push it ?

Lev

On 02/16/2015 08:55 AM, David Holmes wrote:
> On 14/02/2015 12:03 AM, Lev Priima wrote:
>> Please review and push:
>> http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8073124
>
> I hadn't realized 8072909 had been pushed without final reviewer 
> comments being addressed. :(
>
> These changes seem okay. I hope they get promoted at the same time as 
> the original changeset so we don't get test failures.
>
> Thanks,
> David
>
>> Lev
>>
>> On 02/13/2015 05:20 AM, David Holmes wrote:
>>> Hi Lev,
>>>
>>> On 13/02/2015 2:56 AM, Lev Priima wrote:
>>>> Christos,
>>>>
>>>> Test may fail on shorter arrays(page 8 of paper). For instance, on 
>>>> worst
>>>> case, generated by test, it starts to fail on length 67108864.
>>>> After increasing stack size of runs to merge, Arrays.sort(T[]) works
>>>> also on maximum possible array for HotSpot JVM.
>>>
>>> I'd also like to see this documented somewhere in the code. Presently
>>> there is a reference to listsort.txt but then you have to go and find
>>> it on the web. :( At a minimum could we please add:
>>>
>>>  175          * computation below must be changed if MIN_MERGE is
>>> decreased.  See
>>>  176          * the MIN_MERGE declaration above for more information.
>>> +             * The maximum value of 49 allows for an array up to 
>>> length
>>> +             * Integer.MAX_VALUE-4.
>>>
>>>> Roger, David,
>>>> I've updated the test (
>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html 
>>>>
>>>>
>>>> ) to make it more suitable for regular execution:
>>>>
>>>>    27  * @run main/othervm TimSortStackSize2 67108864
>>>
>>> This will still fail on small memory devices:
>>>
>>> :~> java TimSortStackSize2 67108864
>>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>>>
>>> as the default heap ergonomics may not be large enough. I had to add a
>>> minimum heap of -Xmx385M to get it to run.
>>>
>>> Thanks,
>>> David
>>>
>>>>    28  * not for regular execution on all platforms:
>>>>    29  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>    30  * run main/othervm -Xmx32g TimSortStackSize2 2147483644
>>>>
>>>> Could you please push this:
>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>>>> ?
>>>>
>>>> Lev
>>>>
>>>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>>>> On Feb 12, 9:57pm,david.holmes at oracle.com  (David Holmes) wrote:
>>>>> -- Subject: Re: 8072909: TimSort fails with
>>>>> ArrayIndexOutOfBoundsException on
>>>>>
>>>>> | Ok - thanks Lev!
>>>>> |
>>>>> | David
>>>>>
>>>>> For posterity can someone document this, and also the value for which
>>>>> Integer.MAX_VALUE-4 fails?
>>>>>
>>>>> christos
>>>>
>>



From aph at redhat.com  Mon Feb 16 09:38:29 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Feb 2015 09:38:29 +0000
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54DFC7F3.9050309@oracle.com>
References: <54DDFE72.1050306@redhat.com> <54DE8017.6080608@oracle.com>
	<54DF022A.9080707@redhat.com> <54DFC7F3.9050309@oracle.com>
Message-ID: <54E1BA95.7030806@redhat.com>

On 14/02/15 22:10, Dean Long wrote:
> On 2/14/2015 12:07 AM, Andrew Haley wrote:
>> On 02/13/2015 10:52 PM, Dean Long wrote:
>>
>>> My understanding is that whether or not aarch64 allows unaligned
>>> accesses is based on a system setting, so this change is too
>>> simplistic.
>>
>> Disabling unaligned access would be a really perverse thing to do, and
>> I suspect that GCC and glibc already assume that unaligned accesses
>> work so it would require a recompilation of libjvm (and probably the
>> whole OS) to make it work.  However, if you really think there's a
>> point to making this a runtime flag I won't resist.
> 
> Even if linux-aarch64 always allows unaligned, checking only for
> "aarch64" is not future-proof because it doesn't take the OS into
> account. 

Sure, but we can't predict all the crazy things that writers of future
operating systems might do.

> However, I really don't like having to enumerate all relevant
> platforms in multiple places in shared code, so I disagree with the
> existing code and with perpetuating the pattern.  As long as the
> decision is in platform-specific code, a build-time decision may be
> entirely appropriate.

That makes sense.  I don't like the way that the decision is hidden in
shared code either: if it had been in a more obvious place I would
have found it earlier.  I'll have a look at writing an Unsafe method
which does the right thing.

Andrew.


From erik.joelsson at oracle.com  Mon Feb 16 10:25:59 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 16 Feb 2015 11:25:59 +0100
Subject: RFR: JDK-8073152: Update Standard/ExtendedCharsets to work with
	module system
In-Reply-To: <54DFB062.3080008@oracle.com>
References: <54DFB062.3080008@oracle.com>
Message-ID: <54E1C5B7.1060303@oracle.com>

(adding build-dev)

Hello Sherman,

In Gensrc-jdk.charsets.gmk:
* The variable CHARSET_EXTENDED is defined but never used. The value is 
used in several places however. I think you should either use the 
variable or not define it at all.
* $(CHARSET_EXTENDED_DATA) is put on a prerequisite line, but the 
variable is not defined.
* The recipe for $(CHARSET_DONE_CS)-extcs uses $(CHARSET_STANDARD_OS), 
$(CHARSET_EXTENDED_JAVA_TEMPLATES) and the directory 
$(CHARSET_EXTENDED_JAVA_DIR), but none of these are listed as 
prerequisites. I should think touching any of these files (and which 
files in $(CHARSET_EXTENDED_JAVA_DIR)?) should trigger a rebuild of 
$(CHARSET_DONE_CS)-extcs so they should be added to the prerequisites.

In Gensrc-jdk.CharsetMapping.gmk:
* The same issue with prerequisites not properly defined for 
$(CHARSET_DONE_BASE)-stdcs. $(CHARSET_STANDARD_OS), 
$(CHARSET_STANDARD_JAVA_TEMPLATES) and an unknown number of files in 
$(CHARSET_EXTSRC_DIR) should be added for correct incremental build 
behavior.

/Erik

On 2015-02-14 21:30, Xueming Shen wrote:
> Hi,
>
> Please help review the changes for  JDK-8073152
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8073152
> Webrev: http://cr.openjdk.java.net/~sherman/8073152/webrev/
>
> This change is to re-organize how the "standard" and "extended" 
> charsets repository are
> built for the jdk/jre images. Before module system, the "standard" 
> charset provider is built
> into rt.jar and the "extended" charsets provider is in charsets.jar, 
> which is located in the
> "lib/ext" directory. both are available during the system boot time. 
> In jigsaw, the extended
> charsets provider is in jdk.charset (vs the "standard" is in 
> java.base) module and might not
> be "visible" during the early phase of system classes loading, which 
> might cause problem
> as some of the charsets now in "extended" charsets may needed during 
> the boot stage. The
> proposed change here is to re-organize the way these two providers are 
> built, and put in the
> mechanism that enable the build system to configure which group of 
> charsets need to be
> moved from the "extended" charsets into the "standard" (java.base), 
> based on the target
> platform, during the jdk build time.
>
> The updates are
>
> (1) to consolidate the existing configuration files "sbcs", "dbcs", 
> "extsbcs" and
>      "standard-charsets" (and the aliases table originally hardcoded 
> in ExtendeardCharsets.java)
>       into a single configuration file "charsets" to define all 
> supported charsets, with their
>       name, clz name,  history name, package name and all aliases
> http://cr.openjdk.java.net/~sherman/8073152/webrev/make/data/charsetmapping/charsets.html 
>
>
> (2) in addition to the the "standard charsets" provider, now the 
> "extended charsets" provider
>      class is also built during the build time based on the new 
> configuration file "charsets"
>
> (3) to add a build-time mechanism to specify individual sun.nio.cs.ext 
> charset to be built into
>      "standard" charsets provider (sun.nio.cs package in java.base 
> module), with os-specific
>       configuration file, such as stdcs-linux, stdcs-windows and 
> stdcs-solaris.
>
> (4) to move DoubleByte, HKSCS and DelegatableDecoder classes into 
> sun.nio.cs, so they can be
>      used/referenced by those dbcs classes that might be moved into 
> sun.nio.cs
>
> (5) to change some sun.nio.cs.ext implementation java files to be a 
> ".template", so the real .java
>      can be generated during build-time with correct pkg name and 
> aliases info.
>
> There are two leftover, gb18030 and euc_tw, these are two charsets 
> with huge mapping table. Might
> need special update to better fit into sun.nio.cs later.
>
> thanks!
> -Sherman



From Alan.Bateman at oracle.com  Mon Feb 16 11:02:19 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Feb 2015 11:02:19 +0000
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54DFC7F3.9050309@oracle.com>
References: <54DDFE72.1050306@redhat.com>
	<54DE8017.6080608@oracle.com>	<54DF022A.9080707@redhat.com>
	<54DFC7F3.9050309@oracle.com>
Message-ID: <54E1CE3B.1020707@oracle.com>

On 14/02/2015 22:10, Dean Long wrote:
>
> Even if linux-aarch64 always allows unaligned, checking only for 
> "aarch64" is not future-proof
> because it doesn't take the OS into account.  However, I really don't 
> like having to enumerate
> all relevant platforms in multiple places in shared code, so I 
> disagree with the existing code
> and with perpetuating the pattern.  As long as the decision is in 
> platform-specific code, a build-time
> decision may be entirely appropriate.
This alignment test in Bits.java has been there for a long time (JDK 
1.4). It's technical debt that hasn't surfaces very often as it's so 
rare to add architectures. If Unsafe gets a method to test the alignment 
then it would be great to get Bits changed.

-Alan


From aph at redhat.com  Mon Feb 16 11:05:18 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Feb 2015 11:05:18 +0000
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E1CE3B.1020707@oracle.com>
References: <54DDFE72.1050306@redhat.com>
	<54DE8017.6080608@oracle.com>	<54DF022A.9080707@redhat.com>
	<54DFC7F3.9050309@oracle.com> <54E1CE3B.1020707@oracle.com>
Message-ID: <54E1CEEE.8070508@redhat.com>

On 02/16/2015 11:02 AM, Alan Bateman wrote:
> On 14/02/2015 22:10, Dean Long wrote:
>>
>> Even if linux-aarch64 always allows unaligned, checking only for 
>> "aarch64" is not future-proof
>> because it doesn't take the OS into account.  However, I really don't 
>> like having to enumerate
>> all relevant platforms in multiple places in shared code, so I 
>> disagree with the existing code
>> and with perpetuating the pattern.  As long as the decision is in 
>> platform-specific code, a build-time
>> decision may be entirely appropriate.
>
> This alignment test in Bits.java has been there for a long time (JDK 
> 1.4). It's technical debt that hasn't surfaces very often as it's so 
> rare to add architectures. If Unsafe gets a method to test the alignment 
> then it would be great to get Bits changed.

Hopefully it's getting less rare to add architectures!

I'll do that as part of my patch.

Andrew.




From david.holmes at oracle.com  Mon Feb 16 11:20:43 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Feb 2015 21:20:43 +1000
Subject: RFR 8073124: Tune test and document TimSort runs length stack
	size increase
In-Reply-To: <54E1B170.1000801@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>
Message-ID: <54E1D28B.7030503@oracle.com>

On 16/02/2015 6:59 PM, Lev Priima wrote:
> Thanks, David,
> Could you please push it ?

I will if Roger doesn't get to it first. It'll be 11 hours before I can 
push it.

David

> Lev
>
> On 02/16/2015 08:55 AM, David Holmes wrote:
>> On 14/02/2015 12:03 AM, Lev Priima wrote:
>>> Please review and push:
>>> http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073124
>>
>> I hadn't realized 8072909 had been pushed without final reviewer
>> comments being addressed. :(
>>
>> These changes seem okay. I hope they get promoted at the same time as
>> the original changeset so we don't get test failures.
>>
>> Thanks,
>> David
>>
>>> Lev
>>>
>>> On 02/13/2015 05:20 AM, David Holmes wrote:
>>>> Hi Lev,
>>>>
>>>> On 13/02/2015 2:56 AM, Lev Priima wrote:
>>>>> Christos,
>>>>>
>>>>> Test may fail on shorter arrays(page 8 of paper). For instance, on
>>>>> worst
>>>>> case, generated by test, it starts to fail on length 67108864.
>>>>> After increasing stack size of runs to merge, Arrays.sort(T[]) works
>>>>> also on maximum possible array for HotSpot JVM.
>>>>
>>>> I'd also like to see this documented somewhere in the code. Presently
>>>> there is a reference to listsort.txt but then you have to go and find
>>>> it on the web. :( At a minimum could we please add:
>>>>
>>>>  175          * computation below must be changed if MIN_MERGE is
>>>> decreased.  See
>>>>  176          * the MIN_MERGE declaration above for more information.
>>>> +             * The maximum value of 49 allows for an array up to
>>>> length
>>>> +             * Integer.MAX_VALUE-4.
>>>>
>>>>> Roger, David,
>>>>> I've updated the test (
>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html
>>>>>
>>>>>
>>>>> ) to make it more suitable for regular execution:
>>>>>
>>>>>    27  * @run main/othervm TimSortStackSize2 67108864
>>>>
>>>> This will still fail on small memory devices:
>>>>
>>>> :~> java TimSortStackSize2 67108864
>>>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>>>>
>>>> as the default heap ergonomics may not be large enough. I had to add a
>>>> minimum heap of -Xmx385M to get it to run.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>>    28  * not for regular execution on all platforms:
>>>>>    29  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>    30  * run main/othervm -Xmx32g TimSortStackSize2 2147483644
>>>>>
>>>>> Could you please push this:
>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>>>>> ?
>>>>>
>>>>> Lev
>>>>>
>>>>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>>>>> On Feb 12, 9:57pm,david.holmes at oracle.com  (David Holmes) wrote:
>>>>>> -- Subject: Re: 8072909: TimSort fails with
>>>>>> ArrayIndexOutOfBoundsException on
>>>>>>
>>>>>> | Ok - thanks Lev!
>>>>>> |
>>>>>> | David
>>>>>>
>>>>>> For posterity can someone document this, and also the value for which
>>>>>> Integer.MAX_VALUE-4 fails?
>>>>>>
>>>>>> christos
>>>>>
>>>
>


From vladimir.x.ivanov at oracle.com  Mon Feb 16 11:25:47 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 16 Feb 2015 14:25:47 +0300
Subject: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
In-Reply-To: <BBFDE9CE-36F9-42DE-B058-B871ED7E489F@oracle.com>
References: <B5F7A180-60F2-4B08-87B1-A8479D8AC43E@oracle.com>
	<BBFDE9CE-36F9-42DE-B058-B871ED7E489F@oracle.com>
Message-ID: <54E1D3BB.7010408@oracle.com>

Looks good.

Best regards,
Vladimir Ivanov

On 2/16/15 10:47 AM, Staffan Larsen wrote:
> Brian pointed out to me that this change missed to add the annotation to bridge methods. Here is an updated version that takes those into account. I also needed to update the test to verify that bridge methods were correctly annotated - it got a little bit more complex since I had to force bridges being used.
>
> new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.01/ <http://cr.openjdk.java.net/~sla/8025636/webrev.01/>
>
> Thanks,
> /Staffan
>
>
>> On 3 feb 2015, at 10:15, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>>
>> Hi,
>>
>> Please review this patch for hiding the lambda proxy frame in stack traces:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8025636 <https://bugs.openjdk.java.net/browse/JDK-8025636>
>> webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.00/ <http://cr.openjdk.java.net/~sla/8025636/webrev.00/>
>>
>> This is a straightforward addition of the LambdaForm$Hidden annotation to the generated methods. What is surprising is that this works even if LambdaForm$Hidden is a package-private class in java.lang.invoke and thus not accessible from most of the generated classes. There is some discussion of and answers to this in the bug, but essentially this works because the annotation class is never resolved and the code in Hotspot that looks for the annotation amounts to nothing more than string comparisons.
>>
>> Hidden stack frames can be shown by running with ?-XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames?.
>>
>> For an example of what this patch does, consider this code:
>>
>>         Runnable r = () -> { throw new RuntimeException(); };
>>         r.run();
>>
>> Previously, this would output:
>>
>>      java.lang.RuntimeException
>> 	at pkg.Foo.lambda$main$0(Foo.java:5)
>> 	at pkg.Foo$$Lambda$1/2001112025.run(<Unknown>:1000000)
>> 	at pkg.Foo.main(Foo.java:15)
>>
>> With the patch it looks like this:
>>
>>      java.lang.RuntimeException
>> 	at pkg.Foo.lambda$main$0(Foo.java:5)
>> 	at pkg.Foo.main(Foo.java:15)
>>
>>
>> Thanks,
>> /Staffan
>>
>


From Alan.Bateman at oracle.com  Mon Feb 16 12:11:31 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Feb 2015 12:11:31 +0000
Subject: RFR: JDK-8073152: Update Standard/ExtendedCharsets to work with
	module system
In-Reply-To: <54DFB062.3080008@oracle.com>
References: <54DFB062.3080008@oracle.com>
Message-ID: <54E1DE73.8040607@oracle.com>

On 14/02/2015 20:30, Xueming Shen wrote:
> Hi,
>
> Please help review the changes for  JDK-8073152
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8073152
> Webrev: http://cr.openjdk.java.net/~sherman/8073152/webrev/
>
> This change is to re-organize how the "standard" and "extended" 
> charsets repository are
> built for the jdk/jre images. Before module system, the "standard" 
> charset provider is built
> into rt.jar and the "extended" charsets provider is in charsets.jar, 
> which is located in the
> "lib/ext" directory. both are available during the system boot time. 
> In jigsaw, the extended
> charsets provider is in jdk.charset (vs the "standard" is in 
> java.base) module and might not
> be "visible" during the early phase of system classes loading, which 
> might cause problem
> as some of the charsets now in "extended" charsets may needed during 
> the boot stage. 
Right, the overall goal is to ensure that we only execute in code 
java.base during startup (essentially until VM.isBooted returns true) so 
this means fixing a number of issues.

Another thing to say is that the compatibility impact will be that 
attempting to start with file.encoding set to a charset that remains in 
jdk.charset will not work but then again, startup up with this property 
set has never been supported anyway. The other impact for embedded 
environments is increased static footprint of java.base but I think that 
can be dealt with via filtering when creating the runtime image for the 
target platform.

So overall then I think these changes look good. At some point I think 
that the private Charset.lookupExtendedCharset should fail if 
VM.isBooted() is false. Also I think ExtendedProviderHolder should go 
away and the extended charsets loaded via ServiceLoader.

Another thing that comes to mind is the Charset.isSupported and forName 
methods, we might need to think about adding a note to their javadoc to 
say that some charsets might not be available during startup. Chris is 
penning similar text for URL protocol handlers.

A few small comments about the changes in the webrev:

1. Is list_old needed, I can't tell if this is checked in for use by 
future archaeologists.

2. Hasher.java is showing up in the webrev as a new file, was this 
build.tools.hasher.Hasher and so we know have two copies?

3. In Typo in SPI.java line 136 ("Unknow type"). As this is a built-time 
tool then it's not a big deal but it is possible to use the streams API 
in more succulent ways, for example List<String> aliasValues = 
cs.aliases().stream().map(a -> 
a.toLowerCase(Locale.ENGLISH)).collect(Collectors::toList);

4. Are there any tests that need to be updated?

Finally, I see the sun.awt.motif.** classes are changed to importing 
using wildcard, a subtle trick as the package name gets decided at build 
time. Hopefully someone in the client area can sort this dependency 
issue soon.

-Alan


From peter.levart at gmail.com  Mon Feb 16 14:11:59 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 16 Feb 2015 15:11:59 +0100
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54DE1969.2040508@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>
Message-ID: <54E1FAAF.3080906@gmail.com>

On 02/13/2015 04:34 PM, Peter Levart wrote:
> On 02/13/2015 04:18 PM, David M. Lloyd wrote:
>>
>> I hesitate to mention it, but as someone who has been frustrated by 
>> this same problem on numerous occasions I feel I must suggest that 
>> maybe... having a completableFuture method should just be dropped?  A 
>> user should be able to implement it themselves fairly easily, right?  
>> And they'd be able to sidestep problems like stack size and so on by 
>> managing their own threads.
>>
>
> That's a good idea. If the following two methods were added to 
> Process[Handle]:
>
>     public class ProcessHandle {
>         public ProcessHandle waitForUninterruptibly();
>     }
>
>     public class Process extends ProcessHandle {
>         @Override
>         public Process waitForUninterruptibly();
>     }
>
> One could get CompletableFuture(s) simply by:
>
>         ProcessHandle ph = ...;
>
>         CompletableFuture<ProcessHandle> phf = 
> CompletableFuture.supplyAsync(ph::waitForUninterruptibly);
>
>         Process p = ...;
>
>         CompletableFuture<Process> pf = 
> CompletableFuture.supplyAsync(p::waitForUninterruptibly);
>
>
> Peter

Well, the above suggestion has a drawback too. Currently (with latest 
implementation), waiting on process exit is done by a small-stack thread 
and when process exits, this thread submits a task to the system FJ pool 
executor that executes user code in normal-stack thread. With above 
suggestion, the behaviour would be different depending on platform:

- Windows: waiting on process exit would be executed by normal-stack 
thread which would also run user code afterwards.
- UNIX: waiting on process exit would be executed by small-stack thread 
+ there would be another normal-stack thread occupied with waiting on 
small-stack thread to signal completion.

Consumption of occupied threads, while waiting on process exits, would 
be doubled on UNIX and normal-stack threads would be occupied on both 
platforms for waiting.

Current code is more effective in this respect.

Peter



From staffan.larsen at oracle.com  Mon Feb 16 14:25:13 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 16 Feb 2015 15:25:13 +0100
Subject: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
In-Reply-To: <54E1D71A.1080906@univ-mlv.fr>
References: <B5F7A180-60F2-4B08-87B1-A8479D8AC43E@oracle.com>
	<BBFDE9CE-36F9-42DE-B058-B871ED7E489F@oracle.com>
	<54E1D71A.1080906@univ-mlv.fr>
Message-ID: <7AE8811E-F669-480E-AD91-8300561BD8B7@oracle.com>

Good point!

new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.02/ <http://cr.openjdk.java.net/~sla/8025636/webrev.02/>

Thanks,
/Staffan

> On 16 feb 2015, at 12:40, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Hi Staffan,
> ASM MethodVisitor API requires to call visitAnnotation before calling visitCode so
> I think you shoud call visitAnnotation before calling new ForwardingMethodGenerator(mv).generate().
> 
> cheers,
> R?mi
> 
> On 02/16/2015 08:47 AM, Staffan Larsen wrote:
>> Brian pointed out to me that this change missed to add the annotation to bridge methods. Here is an updated version that takes those into account. I also needed to update the test to verify that bridge methods were correctly annotated - it got a little bit more complex since I had to force bridges being used.
>> 
>> new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.01/ <http://cr.openjdk.java.net/%7Esla/8025636/webrev.01/>
>> 
>> Thanks,
>> /Staffan
>> 
>> 
>>> On 3 feb 2015, at 10:15, Staffan Larsen <staffan.larsen at oracle.com <mailto:staffan.larsen at oracle.com>> wrote:
>>> 
>>> Hi,
>>> 
>>> Please review this patch for hiding the lambda proxy frame in stack traces:
>>> 
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8025636 <https://bugs.openjdk.java.net/browse/JDK-8025636>
>>> webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.00/ <http://cr.openjdk.java.net/%7Esla/8025636/webrev.00/>
>>> 
>>> This is a straightforward addition of the LambdaForm$Hidden annotation to the generated methods. What is surprising is that this works even if LambdaForm$Hidden is a package-private class in java.lang.invoke and thus not accessible from most of the generated classes. There is some discussion of and answers to this in the bug, but essentially this works because the annotation class is never resolved and the code in Hotspot that looks for the annotation amounts to nothing more than string comparisons.
>>> 
>>> Hidden stack frames can be shown by running with ?-XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames?.
>>> 
>>> For an example of what this patch does, consider this code:
>>> 
>>>        Runnable r = () -> { throw new RuntimeException(); };
>>>        r.run();
>>> 
>>> Previously, this would output:
>>> 
>>>     java.lang.RuntimeException
>>>  at pkg.Foo.lambda$main$0(Foo.java:5)
>>>  at pkg.Foo$$Lambda$1/2001112025.run(<Unknown>:1000000)
>>>  at pkg.Foo.main(Foo.java:15)
>>> 
>>> With the patch it looks like this:
>>> 
>>>     java.lang.RuntimeException
>>>  at pkg.Foo.lambda$main$0(Foo.java:5)
>>>  at pkg.Foo.main(Foo.java:15)
>>> 
>>> 
>>> Thanks,
>>> /Staffan
>>> 
>> 
> 



From Alan.Bateman at oracle.com  Mon Feb 16 17:28:53 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Feb 2015 17:28:53 +0000
Subject: 8068680: Move java.transaction to the ext class loader
Message-ID: <54E228D5.10608@oracle.com>


Now that the types in the java.corba module are moved to the extension 
loader, it is time to move java.transaction and further our quest to 
move all of the EE/upgradeable modules to the ext loader. This one is 
easy as there isn't any permissions and other security adjustments 
needed. It's just re-assigning the module to the ext loader. I've used 
the opportunity to re-sort the boot.modules and ext.modules files used 
by the build as they seem to have become unsorted with recent edits.

-Alan


diff --git a/make/src/classes/build/tools/module/boot.modules 
b/make/src/classes/build/tools/module/boot.modules
--- a/make/src/classes/build/tools/module/boot.modules
+++ b/make/src/classes/build/tools/module/boot.modules
@@ -1,6 +1,6 @@
  java.base
+java.compiler
  java.desktop
-java.compiler
  java.instrument
  java.logging
  java.management
@@ -13,7 +13,6 @@
  java.smartcardio
  java.sql
  java.sql.rowset
-java.transaction
  java.xml
  java.xml.crypto
  jdk.charsets
@@ -21,9 +20,9 @@
  jdk.deploy.osx
  jdk.hprof.agent
  jdk.httpserver
+jdk.jfr
  jdk.naming.rmi
  jdk.sctp
  jdk.security.auth
  jdk.security.jgss
-jdk.jfr
  jdk.snmp
diff --git a/make/src/classes/build/tools/module/ext.modules 
b/make/src/classes/build/tools/module/ext.modules
--- a/make/src/classes/build/tools/module/ext.modules
+++ b/make/src/classes/build/tools/module/ext.modules
@@ -1,8 +1,10 @@
-java.corba
  java.activation
  java.annotations.common
+java.corba
+java.transaction
  java.xml.bind
  java.xml.ws
+jdk.accessbridge
  jdk.crypto.ec
  jdk.crypto.mscapi
  jdk.crypto.pkcs11
@@ -11,4 +13,3 @@
  jdk.naming.dns
  jdk.scripting.nashorn
  jdk.zipfs
-jdk.accessbridge


From joel.franck at oracle.com  Mon Feb 16 17:50:25 2015
From: joel.franck at oracle.com (=?utf-8?Q?Joel_Borggr=C3=A9n-Franck?=)
Date: Mon, 16 Feb 2015 18:50:25 +0100
Subject: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
In-Reply-To: <7AE8811E-F669-480E-AD91-8300561BD8B7@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>
Message-ID: <51071589-360E-4ECA-959C-FDF95AE70AB0@oracle.com>

+1

cheers
/Joel

> On 16 Feb 2015, at 15:25, Staffan Larsen <staffan.larsen at oracle.com> wrote:
> 
> Good point!
> 
> new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.02/
> 
> Thanks,
> /Staffan
> 
>> On 16 feb 2015, at 12:40, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> Hi Staffan,
>> ASM MethodVisitor API requires to call visitAnnotation before calling visitCode so
>> I think you shoud call visitAnnotation before calling new ForwardingMethodGenerator(mv).generate().
>> 
>> cheers,
>> R?mi
>> 
>> On 02/16/2015 08:47 AM, Staffan Larsen wrote:
>>> Brian pointed out to me that this change missed to add the annotation to bridge methods. Here is an updated version that takes those into account. I also needed to update the test to verify that bridge methods were correctly annotated - it got a little bit more complex since I had to force bridges being used.
>>> 
>>> new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.01/
>>> 
>>> Thanks,
>>> /Staffan
>>> 
>>> 
>>>> On 3 feb 2015, at 10:15, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Please review this patch for hiding the lambda proxy frame in stack traces:
>>>> 
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8025636
>>>> webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.00/
>>>> 
>>>> This is a straightforward addition of the LambdaForm$Hidden annotation to the generated methods. What is surprising is that this works even if LambdaForm$Hidden is a package-private class in java.lang.invoke and thus not accessible from most of the generated classes. There is some discussion of and answers to this in the bug, but essentially this works because the annotation class is never resolved and the code in Hotspot that looks for the annotation amounts to nothing more than string comparisons.
>>>> 
>>>> Hidden stack frames can be shown by running with ?-XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames?.
>>>> 
>>>> For an example of what this patch does, consider this code:
>>>> 
>>>>        Runnable r = () -> { throw new RuntimeException(); };
>>>>        r.run();
>>>> 
>>>> Previously, this would output:
>>>> 
>>>>     java.lang.RuntimeException
>>>>  at pkg.Foo.lambda$main$0(Foo.java:5)
>>>>  at pkg.Foo$$Lambda$1/2001112025.run(<Unknown>:1000000)
>>>>  at pkg.Foo.main(Foo.java:15)
>>>> 
>>>> With the patch it looks like this:
>>>> 
>>>>     java.lang.RuntimeException
>>>>  at pkg.Foo.lambda$main$0(Foo.java:5)
>>>>  at pkg.Foo.main(Foo.java:15)
>>>> 
>>>> 
>>>> Thanks,
>>>> /Staffan
>>>> 
>>> 
>> 
> 



From lance.andersen at oracle.com  Mon Feb 16 17:51:34 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 16 Feb 2015 12:51:34 -0500
Subject: 8068680: Move java.transaction to the ext class loader
In-Reply-To: <54E228D5.10608@oracle.com>
References: <54E228D5.10608@oracle.com>
Message-ID: <439A36BA-3DAF-4107-BE28-092FC1195F6D@oracle.com>

Looks fine Alan
On Feb 16, 2015, at 12:28 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> 
> Now that the types in the java.corba module are moved to the extension loader, it is time to move java.transaction and further our quest to move all of the EE/upgradeable modules to the ext loader. This one is easy as there isn't any permissions and other security adjustments needed. It's just re-assigning the module to the ext loader. I've used the opportunity to re-sort the boot.modules and ext.modules files used by the build as they seem to have become unsorted with recent edits.
> 
> -Alan
> 
> 
> diff --git a/make/src/classes/build/tools/module/boot.modules b/make/src/classes/build/tools/module/boot.modules
> --- a/make/src/classes/build/tools/module/boot.modules
> +++ b/make/src/classes/build/tools/module/boot.modules
> @@ -1,6 +1,6 @@
> java.base
> +java.compiler
> java.desktop
> -java.compiler
> java.instrument
> java.logging
> java.management
> @@ -13,7 +13,6 @@
> java.smartcardio
> java.sql
> java.sql.rowset
> -java.transaction
> java.xml
> java.xml.crypto
> jdk.charsets
> @@ -21,9 +20,9 @@
> jdk.deploy.osx
> jdk.hprof.agent
> jdk.httpserver
> +jdk.jfr
> jdk.naming.rmi
> jdk.sctp
> jdk.security.auth
> jdk.security.jgss
> -jdk.jfr
> jdk.snmp
> diff --git a/make/src/classes/build/tools/module/ext.modules b/make/src/classes/build/tools/module/ext.modules
> --- a/make/src/classes/build/tools/module/ext.modules
> +++ b/make/src/classes/build/tools/module/ext.modules
> @@ -1,8 +1,10 @@
> -java.corba
> java.activation
> java.annotations.common
> +java.corba
> +java.transaction
> java.xml.bind
> java.xml.ws
> +jdk.accessbridge
> jdk.crypto.ec
> jdk.crypto.mscapi
> jdk.crypto.pkcs11
> @@ -11,4 +13,3 @@
> jdk.naming.dns
> jdk.scripting.nashorn
> jdk.zipfs
> -jdk.accessbridge



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





From mandy.chung at oracle.com  Mon Feb 16 17:55:55 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 16 Feb 2015 09:55:55 -0800
Subject: 8068680: Move java.transaction to the ext class loader
In-Reply-To: <54E228D5.10608@oracle.com>
References: <54E228D5.10608@oracle.com>
Message-ID: <54E22F2B.1080305@oracle.com>

Looks good.  We will want to deprivilege a few more modules and move 
them to the extension loader.  That'll be something for the future.

Mandy

On 2/16/2015 9:28 AM, Alan Bateman wrote:
>
> Now that the types in the java.corba module are moved to the extension 
> loader, it is time to move java.transaction and further our quest to 
> move all of the EE/upgradeable modules to the ext loader. This one is 
> easy as there isn't any permissions and other security adjustments 
> needed. It's just re-assigning the module to the ext loader. I've used 
> the opportunity to re-sort the boot.modules and ext.modules files used 
> by the build as they seem to have become unsorted with recent edits.
>
> -Alan
>
>
> diff --git a/make/src/classes/build/tools/module/boot.modules 
> b/make/src/classes/build/tools/module/boot.modules
> --- a/make/src/classes/build/tools/module/boot.modules
> +++ b/make/src/classes/build/tools/module/boot.modules
> @@ -1,6 +1,6 @@
>  java.base
> +java.compiler
>  java.desktop
> -java.compiler
>  java.instrument
>  java.logging
>  java.management
> @@ -13,7 +13,6 @@
>  java.smartcardio
>  java.sql
>  java.sql.rowset
> -java.transaction
>  java.xml
>  java.xml.crypto
>  jdk.charsets
> @@ -21,9 +20,9 @@
>  jdk.deploy.osx
>  jdk.hprof.agent
>  jdk.httpserver
> +jdk.jfr
>  jdk.naming.rmi
>  jdk.sctp
>  jdk.security.auth
>  jdk.security.jgss
> -jdk.jfr
>  jdk.snmp
> diff --git a/make/src/classes/build/tools/module/ext.modules 
> b/make/src/classes/build/tools/module/ext.modules
> --- a/make/src/classes/build/tools/module/ext.modules
> +++ b/make/src/classes/build/tools/module/ext.modules
> @@ -1,8 +1,10 @@
> -java.corba
>  java.activation
>  java.annotations.common
> +java.corba
> +java.transaction
>  java.xml.bind
>  java.xml.ws
> +jdk.accessbridge
>  jdk.crypto.ec
>  jdk.crypto.mscapi
>  jdk.crypto.pkcs11
> @@ -11,4 +13,3 @@
>  jdk.naming.dns
>  jdk.scripting.nashorn
>  jdk.zipfs
> -jdk.accessbridge



From xueming.shen at oracle.com  Mon Feb 16 18:46:09 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 16 Feb 2015 10:46:09 -0800
Subject: RFR: JDK-8073152: Update Standard/ExtendedCharsets to work with
	module system
In-Reply-To: <54E1DE73.8040607@oracle.com>
References: <54DFB062.3080008@oracle.com> <54E1DE73.8040607@oracle.com>
Message-ID: <54E23AF1.10704@oracle.com>

On 2/16/15 4:11 AM, Alan Bateman wrote:
> On 14/02/2015 20:30, Xueming Shen wrote:
>> Hi,
>>
>> Please help review the changes for  JDK-8073152
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8073152
>> Webrev: http://cr.openjdk.java.net/~sherman/8073152/webrev/
>>
>> This change is to re-organize how the "standard" and "extended" 
>> charsets repository are
>> built for the jdk/jre images. Before module system, the "standard" 
>> charset provider is built
>> into rt.jar and the "extended" charsets provider is in charsets.jar, 
>> which is located in the
>> "lib/ext" directory. both are available during the system boot time. 
>> In jigsaw, the extended
>> charsets provider is in jdk.charset (vs the "standard" is in 
>> java.base) module and might not
>> be "visible" during the early phase of system classes loading, which 
>> might cause problem
>> as some of the charsets now in "extended" charsets may needed during 
>> the boot stage. 
> Right, the overall goal is to ensure that we only execute in code 
> java.base during startup (essentially until VM.isBooted returns true) 
> so this means fixing a number of issues.
>
> Another thing to say is that the compatibility impact will be that 
> attempting to start with file.encoding set to a charset that remains 
> in jdk.charset will not work but then again, startup up with this 
> property set has never been supported anyway. The other impact for 
> embedded environments is increased static footprint of java.base but I 
> think that can be dealt with via filtering when creating the runtime 
> image for the target platform.
>
> So overall then I think these changes look good. At some point I think 
> that the private Charset.lookupExtendedCharset should fail if 
> VM.isBooted() is false. Also I think ExtendedProviderHolder should go 
> away and the extended charsets loaded via ServiceLoader.

Yes, we have a separate P2 bug for that, will address that separately later.

>
> Another thing that comes to mind is the Charset.isSupported and 
> forName methods, we might need to think about adding a note to their 
> javadoc to say that some charsets might not be available during 
> startup. Chris is penning similar text for URL protocol handlers.
>
> A few small comments about the changes in the webrev:
>
> 1. Is list_old needed, I can't tell if this is checked in for use by 
> future archaeologists.
>
No, it's not used by any code. I just added it the last minute to be a 
reference for the future, as
I'm deleting the original list sbcs, dbcs and extsbcs.

> 2. Hasher.java is showing up in the webrev as a new file, was this 
> build.tools.hasher.Hasher and so we know have two copies?
"This" Hasher.java has a different use interface and works on a pair of 
key/value lists directly (instead
of parsing the key/value from a std in). Given the implementation is 
simple/small enough, I just copied/
pasted the parts I need from Mark's code, left the original one 
untouched (I kinda remember it is used
by other as well)

>
> 3. In Typo in SPI.java line 136 ("Unknow type"). As this is a 
> built-time tool then it's not a big deal but it is possible to use the 
> streams API in more succulent ways, for example List<String> 
> aliasValues = cs.aliases().stream().map(a -> 
> a.toLowerCase(Locale.ENGLISH)).collect(Collectors::toList);
>
Typo fixed.

The "aliasValues" and "aliasKeys" pair is a little tricky.  Two are 
supposed to collect the alias->csname pair
for all charsets, with a mapping relation but in two separate lists (to 
pass to the Hasher). While it's possible
to collect them separately (or them into a "entry" as a pair) with the 
.collect(), but it appears to me more
nature to do just in once pass.

> 4. Are there any tests that need to be updated?
>
Only NIOCharsetAvailabilityTest.java. But I believe that test should not 
stop working for a while as
it tried to "parse" the rt.jar and charsets.jar to collect the charset 
class names, which obviously
does not work in module. It need to be rewritten with the new iterating 
mechanism. (it is supposed
to be the last file in webrev. But it appears it was not there in first 
webrev)


> Finally, I see the sun.awt.motif.** classes are changed to importing 
> using wildcard, a subtle trick as the package name gets decided at 
> build time. Hopefully someone in the client area can sort this 
> dependency issue soon.

Phil is moving away from using those sun.nio.cs.ext directly. My change 
in motif should have no conflict
with his changes, in fact they probably no longer needed. Just be there 
in case I will push first :-)

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

-Sherman

>
> -Alan



From daniel.fuchs at oracle.com  Mon Feb 16 19:24:15 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 16 Feb 2015 20:24:15 +0100
Subject: RFR: 8072645: java.util.logging should use java.time to get more
	precise time stamps
In-Reply-To: <54DF47B9.4050304@oracle.com>
References: <54DE109C.4030307@oracle.com>
	<CACzrW9BgsCVZvZKdd=+1rEao1V7bSg7N_QJD0BpJsaywJAj2-A@mail.gmail.com>
	<54DF47B9.4050304@oracle.com>
Message-ID: <54E243DF.3060107@oracle.com>

Hi Stephen,

Thanks again for your support and suggestions!

On 14/02/15 14:03, Daniel Fuchs wrote:
> If I'm not mistaken the previous SimpleFormatter used to use java.util.Date
> and printed the time in the local time zone. I have tried to keep this
> behavior.
> I'm not sure we would want to change it to print the time in the UTC
> time zone
> by default. A lot of developers use logging for debugging - and when
> reading
> debug messages on the console I usually prefer to see the time in my own
> time zone.
>
> Would there be a more efficient way to keep the default formatting of
> the time
> in the SimpleFormatter?

I spent part of the day reading the documentation & trying out the
various TemporalAccessors and DateTimeFormatters...

I have also done some microbenchmark measurements (jmh) WRT
the performance  of formatting a date/time.
Results can be seen here [1]:
http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html

What it shows is that when using String.format (as the SimpleFormatter
is specified to do), then using ZonedDateTime is actually an improvement
over using Date.

Now that I have read a bit more about LocalDateTime, ZonedDateTime,
Date, and Instant, I do agree with you that for recording an event time,
printing the Instant is the better alternative.
However, since SimpleFormatter has always printed the local date,
I would tend to want to keep it that way.

So I'm going to propose to keep using ZonedDateTime in
the SimpleFormatter, as I believe it's what gives it the maximum of
flexibility - WRT to using String.format (+ we will get some
boost as bonus by no longer using Date).
If you strongly feel that java.util.logging should offer a better
alternative - then maybe we should log an RFE to explore it?

Things are - I believe - a bit different for the XMLFormatter.
First, the XMLFormatter is not specified to use String.format, so
it gives us a bit more flexibility.
In addition we already need to tweak the format in order to introduce
the new <nanos> element - (or should it be <nanoOfMilli> as Peter
suggested?).

So for the XMLFormatter, and given the results of my
microbenchmark [1], here is what I would suggest:

#1 rename the property printNanos into useInstant
#2 if useInstant is false, use the old code for formatting the
    date (the old appendISO8601() method) and omit the <nanos>
    element - so applications that specify useInstant=false should
    see the same formatting than before, without paying the
    performance cost that using ZonedDateTime would bring.
#3 if useInstant is absent - or not false, then we use the 'new'
    format. The <date> element will contain the instant printed
    using DateTimeFormatter.ISO_INSTANT, and the <nanos> element
    will be printed after <millis>

Does that sound right? If so I will include these changes in my
next webrev, once I have digested the feedback sent by Peter :-)

Best regards,

-- daniel

[1] microbenchmark:
http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html


>
>> (The webrev is broken wrt zones as it stores ZoneId.systemDefault() in a
>> static constant, but that method depends on the mutable
>> TimeZone.getDefault() ).
>
> Would making it a final (non static) variable be better?
> I now wonder whether there should be a way to configure the time zone for
> an instance of SimpleFormatter (something like what I did with 'printNanos'
> for the XMLFormatter).
>
>> LogReecord.getInstantUTC() should be getInstant().
>>
>> (An Instant is fully defined as a concept, and it cannot be in or not in
>> UTC).
>
> Right. Thanks for pointing that out.
>> In SimpleFormatter, you have {@code java.util.loggin} (missing a "g").
>
> Good catch.
>
>> In XMLFormatter, instead of using DateTimeFormatter.ISO_LOCAL_DATE_TIME,
>> create a new instance of DateTimeFormatter that does not output the
>> fraction of a second. That way, there is no need to use
>> truncatedTo(SECONDS).
>>
>> StringBuilder appends can be used directly with formatters:
>>
>> sb.append(ZonedDateTime.ofInstant(time, zoneId).format(dtformatter));
>>
>> replace with
>>
>> dtformatter.formatTo(ZonedDateTime.ofInstant(time, zoneId), sb);
>
> Will look into this.
>
> Thanks again for your review! This is quite helpful.
>
> -- daniel
>
>
>>
>> thanks
>> Stephen
>>
>>
>>
>> On 13 Feb 2015 14:57, "Daniel Fuchs" <daniel.fuchs at oracle.com> wrote:
>>
>>> Hi,
>>>
>>> Please find below a patch for:
>>>
>>> 8072645: java.util.logging should use java.time to get more
>>>           precise time stamps
>>>
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/
>>>
>>> specdiff:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/
>>> specdiff-logging-time/java/util/logging/package-summary.html
>>>
>>> Overview:
>>> ---------
>>>
>>> The patch is made of the following pieces:
>>>
>>>   - LogRecord uses java.time.Clock's systemClock to get an
>>>     Instant in the best available resolution.
>>>
>>>     The instant is split into a number of milliseconds (a long)
>>>     and a nanosecond adjustment (an int).
>>>     The number of milliseconds is the same than what would have
>>>     been obtained by calling System.currentTimeMillis().
>>>
>>>   - LogRecord acquires a new serializable int nanoAdjustement field,
>>>     which can be used together with the number of milliseconds
>>>     to reconstruct the instant.
>>>
>>>   - SimpleFormatter is updated to pass a ZoneDateTime
>>>     instance to String.format, instead of a Date.
>>>
>>>     The effect of that is that the format string can now
>>>     be configure to print the full instant precision, if
>>>     needed.
>>>
>>>   - XMLformatter will add a new <nanos> element after the
>>>     <millis> element - if the value of the nanoAdjustment
>>>     field is not 0.
>>>
>>>     The <date> string will also contain the nano second
>>>     adjustment as well as the zone offset as formatted by
>>>     DateTimeFormatter.ISO_OFFSET_DATE_TIME
>>>
>>> Compatibility considerations:
>>> -----------------------------
>>>
>>> - The serial for of log record is backward/forward compatible.
>>>    I added a test to verify that.
>>>
>>> - XMLFormatter has acquired a new configurable property
>>>    '<FQCN>.printNanos' which allows to revert to the old
>>>    XML format, should the new format cause issues in
>>>    existing applications.
>>>
>>> - The logger.dtd will need to be updated, to support the
>>>    new optional <nanos> element. And for this matter,
>>>    should we update the logger.dtd or rather define a
>>>    logger-v2.dtd?
>>>    See planned modification:
>>>
>>> <http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-
>>> dtd/logger.dtd.frames.html>
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>



From forax at univ-mlv.fr  Mon Feb 16 19:28:24 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Mon, 16 Feb 2015 20:28:24 +0100
Subject: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
In-Reply-To: <51071589-360E-4ECA-959C-FDF95AE70AB0@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>
	<51071589-360E-4ECA-959C-FDF95AE70AB0@oracle.com>
Message-ID: <8E31A5A6-FAE7-4D74-AFD4-896A0FBD466F@univ-mlv.fr>

yes,
thumb up !

R?mi 

Le 16 f?vrier 2015 18:50:25 CET, "Joel Borggr?n-Franck" <joel.franck at oracle.com> a ?crit :
>+1
>
>cheers
>/Joel
>
>> On 16 Feb 2015, at 15:25, Staffan Larsen <staffan.larsen at oracle.com>
>wrote:
>> 
>> Good point!
>> 
>> new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.02/
>> 
>> Thanks,
>> /Staffan
>> 
>>> On 16 feb 2015, at 12:40, Remi Forax <forax at univ-mlv.fr> wrote:
>>> 
>>> Hi Staffan,
>>> ASM MethodVisitor API requires to call visitAnnotation before
>calling visitCode so
>>> I think you shoud call visitAnnotation before calling new
>ForwardingMethodGenerator(mv).generate().
>>> 
>>> cheers,
>>> R?mi
>>> 
>>> On 02/16/2015 08:47 AM, Staffan Larsen wrote:
>>>> Brian pointed out to me that this change missed to add the
>annotation to bridge methods. Here is an updated version that takes
>those into account. I also needed to update the test to verify that
>bridge methods were correctly annotated - it got a little bit more
>complex since I had to force bridges being used.
>>>> 
>>>> new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.01/
>>>> 
>>>> Thanks,
>>>> /Staffan
>>>> 
>>>> 
>>>>> On 3 feb 2015, at 10:15, Staffan Larsen
><staffan.larsen at oracle.com> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> Please review this patch for hiding the lambda proxy frame in
>stack traces:
>>>>> 
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8025636
>>>>> webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.00/
>>>>> 
>>>>> This is a straightforward addition of the LambdaForm$Hidden
>annotation to the generated methods. What is surprising is that this
>works even if LambdaForm$Hidden is a package-private class in
>java.lang.invoke and thus not accessible from most of the generated
>classes. There is some discussion of and answers to this in the bug,
>but essentially this works because the annotation class is never
>resolved and the code in Hotspot that looks for the annotation amounts
>to nothing more than string comparisons.
>>>>> 
>>>>> Hidden stack frames can be shown by running with
>?-XX:+UnlockDiagnosticVMOptions -XX:+ShowHiddenFrames?.
>>>>> 
>>>>> For an example of what this patch does, consider this code:
>>>>> 
>>>>>        Runnable r = () -> { throw new RuntimeException(); };
>>>>>        r.run();
>>>>> 
>>>>> Previously, this would output:
>>>>> 
>>>>>     java.lang.RuntimeException
>>>>>  at pkg.Foo.lambda$main$0(Foo.java:5)
>>>>>  at pkg.Foo$$Lambda$1/2001112025.run(<Unknown>:1000000)
>>>>>  at pkg.Foo.main(Foo.java:15)
>>>>> 
>>>>> With the patch it looks like this:
>>>>> 
>>>>>     java.lang.RuntimeException
>>>>>  at pkg.Foo.lambda$main$0(Foo.java:5)
>>>>>  at pkg.Foo.main(Foo.java:15)
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> /Staffan
>>>>> 
>>>> 
>>> 
>> 

-- 
Envoy? de mon t?l?phone Android avec K-9 Mail. Excusez la bri?vet?.


From Alan.Bateman at oracle.com  Mon Feb 16 19:55:15 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Feb 2015 19:55:15 +0000
Subject: RFR: JDK-8073152: Update Standard/ExtendedCharsets to work with
	module system
In-Reply-To: <54E23AF1.10704@oracle.com>
References: <54DFB062.3080008@oracle.com> <54E1DE73.8040607@oracle.com>
	<54E23AF1.10704@oracle.com>
Message-ID: <54E24B23.20409@oracle.com>

On 16/02/2015 18:46, Xueming Shen wrote:

> :
>>
>> 1. Is list_old needed, I can't tell if this is checked in for use by 
>> future archaeologists.
>>
> No, it's not used by any code. I just added it the last minute to be a 
> reference for the future, as
> I'm deleting the original list sbcs, dbcs and extsbcs.
Okay, I'm just thinking of someone finding this file in 6 months or 6 
years and wondering whether it is used in the build or not.


>
>> 2. Hasher.java is showing up in the webrev as a new file, was this 
>> build.tools.hasher.Hasher and so we know have two copies?
> "This" Hasher.java has a different use interface and works on a pair 
> of key/value lists directly (instead
> of parsing the key/value from a std in). Given the implementation is 
> simple/small enough, I just copied/
> pasted the parts I need from Mark's code, left the original one 
> untouched (I kinda remember it is used
> by other as well)
Okay, just trying to reduce duplication.


> :
>
>> 4. Are there any tests that need to be updated?
>>
> Only NIOCharsetAvailabilityTest.java. But I believe that test should 
> not stop working for a while as
> it tried to "parse" the rt.jar and charsets.jar to collect the charset 
> class names, which obviously
> does not work in module. It need to be rewritten with the new 
> iterating mechanism. (it is supposed
> to be the last file in webrev. But it appears it was not there in 
> first webrev)
Thanks, I was wondering if any tests were directly referencing charsets 
that moved on some platforms.


> :
>
> Phil is moving away from using those sun.nio.cs.ext directly. My 
> change in motif should have no conflict
> with his changes, in fact they probably no longer needed. Just be 
> there in case I will push first :-)
>
> http://cr.openjdk.java.net/~sherman/8073152/webrev
I think this looks okay.

-Alan


From brian.burkhalter at oracle.com  Mon Feb 16 21:58:21 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 16 Feb 2015 13:58:21 -0800
Subject: [9] RFR of 8073207: javadoc typos in java.nio.channels.Pipe
Message-ID: <7122B986-738E-41A7-B9D2-FFE54F20FE46@oracle.com>

Please review at your convenience:

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

Simply implements what the description suggests.

Thanks,

Brian


From Ulf.Zibis at CoSoCo.de  Mon Feb 16 23:14:40 2015
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 17 Feb 2015 00:14:40 +0100
Subject: RFR: JDK-8073152: Update Standard/ExtendedCharsets to work with
	module system
In-Reply-To: <54E23AF1.10704@oracle.com>
References: <54DFB062.3080008@oracle.com> <54E1DE73.8040607@oracle.com>
	<54E23AF1.10704@oracle.com>
Message-ID: <54E279E0.3070207@CoSoCo.de>

Am 16.02.2015 um 19:46 schrieb Xueming Shen:
> On 2/16/15 4:11 AM, Alan Bateman wrote:
>> 2. Hasher.java is showing up in the webrev as a new file, was this build.tools.hasher.Hasher and 
>> so we know have two copies?
> "This" Hasher.java has a different use interface and works on a pair of key/value lists directly 
> (instead
> of parsing the key/value from a std in). Given the implementation is simple/small enough, I just 
> copied/
> pasted the parts I need from Mark's code, left the original one untouched (I kinda remember it is 
> used
> by other as well)

Maybe consider:
https://bugs.openjdk.java.net/browse/JDK-6850361
https://bugs.openjdk.java.net/browse/JDK-6862158
Here have been the patches:
https://bugs.openjdk.java.net/show_bug.cgi?id=100095
https://bugs.openjdk.java.net/show_bug.cgi?id=100098

Thanks,
-Ulf




From david.holmes at oracle.com  Tue Feb 17 00:20:39 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Feb 2015 10:20:39 +1000
Subject: RFR 8073124: Tune test and document TimSort runs length stack
	size increase
In-Reply-To: <54E1D28B.7030503@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>
Message-ID: <54E28957.1070309@oracle.com>

On 16/02/2015 9:20 PM, David Holmes wrote:
> On 16/02/2015 6:59 PM, Lev Priima wrote:
>> Thanks, David,
>> Could you please push it ?
>
> I will if Roger doesn't get to it first. It'll be 11 hours before I can
> push it.

This has been pushed but note there is a minor issue with the test. The 
jtreg tag specification doesn't terminate tags on newlines, they 
continue until the next tag is encountered or the end of the comment. 
Consequently this:

  * @run main/othervm -Xmx385m TimSortStackSize2 67108864
  * not for regular execution on all platforms:
  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
  * run main/othervm -Xmx16g TimSortStackSize2 2147483644

is processed as:

@run main/othervm -Xmx385m TimSortStackSize2 67108864 not for regular 
execution on all platforms: run main/othervm -Xmx8g TimSortStackSize2 
1073741824 run main/othervm -Xmx16g TimSortStackSize2 2147483644

and so TimSortStackSize2 is invoked with 18 arguments.

David
-----

> David
>
>> Lev
>>
>> On 02/16/2015 08:55 AM, David Holmes wrote:
>>> On 14/02/2015 12:03 AM, Lev Priima wrote:
>>>> Please review and push:
>>>> http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073124
>>>
>>> I hadn't realized 8072909 had been pushed without final reviewer
>>> comments being addressed. :(
>>>
>>> These changes seem okay. I hope they get promoted at the same time as
>>> the original changeset so we don't get test failures.
>>>
>>> Thanks,
>>> David
>>>
>>>> Lev
>>>>
>>>> On 02/13/2015 05:20 AM, David Holmes wrote:
>>>>> Hi Lev,
>>>>>
>>>>> On 13/02/2015 2:56 AM, Lev Priima wrote:
>>>>>> Christos,
>>>>>>
>>>>>> Test may fail on shorter arrays(page 8 of paper). For instance, on
>>>>>> worst
>>>>>> case, generated by test, it starts to fail on length 67108864.
>>>>>> After increasing stack size of runs to merge, Arrays.sort(T[]) works
>>>>>> also on maximum possible array for HotSpot JVM.
>>>>>
>>>>> I'd also like to see this documented somewhere in the code. Presently
>>>>> there is a reference to listsort.txt but then you have to go and find
>>>>> it on the web. :( At a minimum could we please add:
>>>>>
>>>>>  175          * computation below must be changed if MIN_MERGE is
>>>>> decreased.  See
>>>>>  176          * the MIN_MERGE declaration above for more information.
>>>>> +             * The maximum value of 49 allows for an array up to
>>>>> length
>>>>> +             * Integer.MAX_VALUE-4.
>>>>>
>>>>>> Roger, David,
>>>>>> I've updated the test (
>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> ) to make it more suitable for regular execution:
>>>>>>
>>>>>>    27  * @run main/othervm TimSortStackSize2 67108864
>>>>>
>>>>> This will still fail on small memory devices:
>>>>>
>>>>> :~> java TimSortStackSize2 67108864
>>>>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>>>>>
>>>>> as the default heap ergonomics may not be large enough. I had to add a
>>>>> minimum heap of -Xmx385M to get it to run.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>>    28  * not for regular execution on all platforms:
>>>>>>    29  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>>    30  * run main/othervm -Xmx32g TimSortStackSize2 2147483644
>>>>>>
>>>>>> Could you please push this:
>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>>>>>> ?
>>>>>>
>>>>>> Lev
>>>>>>
>>>>>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>>>>>> On Feb 12, 9:57pm,david.holmes at oracle.com  (David Holmes) wrote:
>>>>>>> -- Subject: Re: 8072909: TimSort fails with
>>>>>>> ArrayIndexOutOfBoundsException on
>>>>>>>
>>>>>>> | Ok - thanks Lev!
>>>>>>> |
>>>>>>> | David
>>>>>>>
>>>>>>> For posterity can someone document this, and also the value for
>>>>>>> which
>>>>>>> Integer.MAX_VALUE-4 fails?
>>>>>>>
>>>>>>> christos
>>>>>>
>>>>
>>


From john.r.rose at oracle.com  Tue Feb 17 01:16:38 2015
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 16 Feb 2015 17:16:38 -0800
Subject: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
In-Reply-To: <7AE8811E-F669-480E-AD91-8300561BD8B7@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>
Message-ID: <313ABEF2-036C-4E7F-A15D-F3240E417629@oracle.com>

On Feb 16, 2015, at 6:25 AM, Staffan Larsen <staffan.larsen at oracle.com> wrote:
> 
> new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.02/ <http://cr.openjdk.java.net/~sla/8025636/webrev.02/>
Looks good; ship it.

To me this fix raises more questions:

1. Are there other places where we generate ACC_SYNTHETIC that should also get @Hidden annotations?

2. Should the JVM be filtering stack frames for ACC_SYNTHETIC (or ACC_BRIDGE or ACC_MANDATED) calls?  (By default?  Or perhaps as a new option?)

3. When will we have a reasonable stack walking mechanism where we can program such policies in JDK library code, instead of hacking the JVM?

? John

P.S.  https://bugs.openjdk.java.net/browse/JDK-8043814

From jason_mehrens at hotmail.com  Tue Feb 17 03:08:36 2015
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Mon, 16 Feb 2015 21:08:36 -0600
Subject: RFR: 8072645: java.util.logging should use java.time to get
	more precise time stamps
In-Reply-To: <54DF3A3D.8000308@oracle.com>
References: <54DE109C.4030307@oracle.com>
	<BLU175-W436CC3100DC42EC016B15E83230@phx.gbl>,
	<54DF3A3D.8000308@oracle.com>
Message-ID: <BLU175-W51159BFAE0B18DA9FB50AE832F0@phx.gbl>

Daniel,


I agree with you that removing the new XMLFormatter constructor is the right thing to do in this case.


Jason

________________________________
> Date: Sat, 14 Feb 2015 13:06:21 +0100 
> From: daniel.fuchs at oracle.com 
> To: jason_mehrens at hotmail.com; core-libs-dev at openjdk.java.net 
> Subject: Re: RFR: 8072645: java.util.logging should use java.time to 
> get more precise time stamps 
> 
> Hi Jason, 
> 
> On 2/13/15 10:57 PM, Jason Mehrens wrote: 
> 
> Daniel, 
> 
> 
> In the XMLFormatter.format you can get rid of the double call to getNanoAdjustment() since you have stored the value in the local var 'nanos'. 
> 
> Thanks for spotting that, will do. 
> 
> 
> 
> 
> For the new XMLFormatter constructor what do you think about using Properties, Function<String, String>, or perhaps a builder pattern? 
> 
> That way if XMLFormatter is modified in the future to support Throwable.getCause and Throwable.getSuppressed you don't have to keep creating constructors to toggle features. 
> 
> I don't know... I added the new constructor as an after thought, to help 
> writing subclasses that might not want to rely on the property defined 
> in the configuration. If we're going to rely on property anyway, then 
> the correct thing to do would be to define them as configuration properties 
> and look for them in the LogManager. 
> 
> Maybe I should just remove the new constructor. 
> 
> What do you think? 
> 
> best regards, 
> 
> -- daniel 
> 
> 
> 
> 
> 
> 
> Jason 
> 
> 
> 
> ---------------------------------------- 
> 
> 
> Date: Fri, 13 Feb 2015 15:56:28 +0100 
> From: daniel.fuchs at oracle.com<mailto:daniel.fuchs at oracle.com> 
> To: core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net> 
> Subject: RFR: 8072645: java.util.logging should use java.time to get more precise time stamps 
> 
> Hi, 
> 
> Please find below a patch for: 
> 
> 8072645: java.util.logging should use java.time to get more 
> precise time stamps 
> 
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/ 
> 
> specdiff: 
> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/specdiff-logging-time/java/util/logging/package-summary.html 
> 
> Overview: 
> --------- 
> 
> The patch is made of the following pieces: 
> 
> - LogRecord uses java.time.Clock's systemClock to get an 
> Instant in the best available resolution. 
> 
> The instant is split into a number of milliseconds (a long) 
> and a nanosecond adjustment (an int). 
> The number of milliseconds is the same than what would have 
> been obtained by calling System.currentTimeMillis(). 
> 
> - LogRecord acquires a new serializable int nanoAdjustement field, 
> which can be used together with the number of milliseconds 
> to reconstruct the instant. 
> 
> - SimpleFormatter is updated to pass a ZoneDateTime 
> instance to String.format, instead of a Date. 
> 
> The effect of that is that the format string can now 
> be configure to print the full instant precision, if 
> needed. 
> 
> - XMLformatter will add a new <nanos> element after the 
> <millis> element - if the value of the nanoAdjustment 
> field is not 0. 
> 
> The <date> string will also contain the nano second 
> adjustment as well as the zone offset as formatted by 
> DateTimeFormatter.ISO_OFFSET_DATE_TIME 
> 
> Compatibility considerations: 
> ----------------------------- 
> 
> - The serial for of log record is backward/forward compatible. 
> I added a test to verify that. 
> 
> - XMLFormatter has acquired a new configurable property 
> '<FQCN>.printNanos' which allows to revert to the old 
> XML format, should the new format cause issues in 
> existing applications. 
> 
> - The logger.dtd will need to be updated, to support the 
> new optional <nanos> element. And for this matter, 
> should we update the logger.dtd or rather define a 
> logger-v2.dtd? 
> See planned modification: 
> 
> <http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-dtd/logger.dtd.frames.html><http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-dtd/logger.dtd.frames.html> 
> 
> best regards, 
> 
> -- daniel 
>  		 	   		  

From john.r.rose at oracle.com  Tue Feb 17 03:35:46 2015
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 16 Feb 2015 19:35:46 -0800
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54DF00C4.7030308@redhat.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>
	<54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com>
	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
	<54DF00C4.7030308@redhat.com>
Message-ID: <CE824686-FD7C-485C-B809-303A004B49D5@oracle.com>

On Feb 14, 2015, at 12:01 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 02/14/2015 12:09 AM, John Rose wrote:
>> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever second-best mechanism the platform offers.
> 
> Indeed.  I'm intending to prototype a design for those next week.  OK?

Yes, please.  ? John

From lev.priima at oracle.com  Tue Feb 17 05:43:55 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Tue, 17 Feb 2015 08:43:55 +0300
Subject: RFR 8073124: Tune test and document TimSort runs length stack
	size increase
In-Reply-To: <54E28957.1070309@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>
Message-ID: <54E2D51B.8020808@oracle.com>

Thanks David!
Is this expected behavior of this annotation ?

Lev

On 02/17/2015 03:20 AM, David Holmes wrote:
> On 16/02/2015 9:20 PM, David Holmes wrote:
>> On 16/02/2015 6:59 PM, Lev Priima wrote:
>>> Thanks, David,
>>> Could you please push it ?
>>
>> I will if Roger doesn't get to it first. It'll be 11 hours before I can
>> push it.
>
> This has been pushed but note there is a minor issue with the test. 
> The jtreg tag specification doesn't terminate tags on newlines, they 
> continue until the next tag is encountered or the end of the comment. 
> Consequently this:
>
>  * @run main/othervm -Xmx385m TimSortStackSize2 67108864
>  * not for regular execution on all platforms:
>  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>  * run main/othervm -Xmx16g TimSortStackSize2 2147483644
>
> is processed as:
>
> @run main/othervm -Xmx385m TimSortStackSize2 67108864 not for regular 
> execution on all platforms: run main/othervm -Xmx8g TimSortStackSize2 
> 1073741824 run main/othervm -Xmx16g TimSortStackSize2 2147483644
>
> and so TimSortStackSize2 is invoked with 18 arguments.
>
> David
> -----
>
>> David
>>
>>> Lev
>>>
>>> On 02/16/2015 08:55 AM, David Holmes wrote:
>>>> On 14/02/2015 12:03 AM, Lev Priima wrote:
>>>>> Please review and push:
>>>>> http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073124
>>>>
>>>> I hadn't realized 8072909 had been pushed without final reviewer
>>>> comments being addressed. :(
>>>>
>>>> These changes seem okay. I hope they get promoted at the same time as
>>>> the original changeset so we don't get test failures.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Lev
>>>>>
>>>>> On 02/13/2015 05:20 AM, David Holmes wrote:
>>>>>> Hi Lev,
>>>>>>
>>>>>> On 13/02/2015 2:56 AM, Lev Priima wrote:
>>>>>>> Christos,
>>>>>>>
>>>>>>> Test may fail on shorter arrays(page 8 of paper). For instance, on
>>>>>>> worst
>>>>>>> case, generated by test, it starts to fail on length 67108864.
>>>>>>> After increasing stack size of runs to merge, Arrays.sort(T[]) 
>>>>>>> works
>>>>>>> also on maximum possible array for HotSpot JVM.
>>>>>>
>>>>>> I'd also like to see this documented somewhere in the code. 
>>>>>> Presently
>>>>>> there is a reference to listsort.txt but then you have to go and 
>>>>>> find
>>>>>> it on the web. :( At a minimum could we please add:
>>>>>>
>>>>>>  175          * computation below must be changed if MIN_MERGE is
>>>>>> decreased.  See
>>>>>>  176          * the MIN_MERGE declaration above for more 
>>>>>> information.
>>>>>> +             * The maximum value of 49 allows for an array up to
>>>>>> length
>>>>>> +             * Integer.MAX_VALUE-4.
>>>>>>
>>>>>>> Roger, David,
>>>>>>> I've updated the test (
>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ) to make it more suitable for regular execution:
>>>>>>>
>>>>>>>    27  * @run main/othervm TimSortStackSize2 67108864
>>>>>>
>>>>>> This will still fail on small memory devices:
>>>>>>
>>>>>> :~> java TimSortStackSize2 67108864
>>>>>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap 
>>>>>> space
>>>>>>
>>>>>> as the default heap ergonomics may not be large enough. I had to 
>>>>>> add a
>>>>>> minimum heap of -Xmx385M to get it to run.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>>    28  * not for regular execution on all platforms:
>>>>>>>    29  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>>>    30  * run main/othervm -Xmx32g TimSortStackSize2 2147483644
>>>>>>>
>>>>>>> Could you please push this:
>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>>>>>>> ?
>>>>>>>
>>>>>>> Lev
>>>>>>>
>>>>>>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>>>>>>> On Feb 12, 9:57pm,david.holmes at oracle.com  (David Holmes) wrote:
>>>>>>>> -- Subject: Re: 8072909: TimSort fails with
>>>>>>>> ArrayIndexOutOfBoundsException on
>>>>>>>>
>>>>>>>> | Ok - thanks Lev!
>>>>>>>> |
>>>>>>>> | David
>>>>>>>>
>>>>>>>> For posterity can someone document this, and also the value for
>>>>>>>> which
>>>>>>>> Integer.MAX_VALUE-4 fails?
>>>>>>>>
>>>>>>>> christos
>>>>>>>
>>>>>
>>>



From staffan.larsen at oracle.com  Tue Feb 17 06:33:14 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 17 Feb 2015 07:33:14 +0100
Subject: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
In-Reply-To: <313ABEF2-036C-4E7F-A15D-F3240E417629@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>
Message-ID: <3CB05A58-C466-4F91-A405-694F2ADDA401@oracle.com>


> On 17 feb 2015, at 02:16, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Feb 16, 2015, at 6:25 AM, Staffan Larsen <staffan.larsen at oracle.com <mailto:staffan.larsen at oracle.com>> wrote:
>> 
>> new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.02/ <http://cr.openjdk.java.net/~sla/8025636/webrev.02/>
> Looks good; ship it.

Thanks.

> 
> To me this fix raises more questions:
> 
> 1. Are there other places where we generate ACC_SYNTHETIC that should also get @Hidden annotations?
> 
> 2. Should the JVM be filtering stack frames for ACC_SYNTHETIC (or ACC_BRIDGE or ACC_MANDATED) calls?  (By default?  Or perhaps as a new option?)

The first shot at fixing this bug was to filter out ACC_SYNTHETIC. The drawback was that the actual lambda method are marked ACC_SYNTHETIC, so that filtered too much.

/Staffan

> 
> 3. When will we have a reasonable stack walking mechanism where we can program such policies in JDK library code, instead of hacking the JVM?
> 
> ? John
> 
> P.S.  https://bugs.openjdk.java.net/browse/JDK-8043814 <https://bugs.openjdk.java.net/browse/JDK-8043814>


From john.r.rose at oracle.com  Tue Feb 17 06:54:20 2015
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 16 Feb 2015 22:54:20 -0800
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: <364AD047-000F-4A98-951A-9D33937DFA1E@oracle.com>

On Feb 16, 2015, at 10:33 PM, Staffan Larsen <staffan.larsen at oracle.com> wrote:
> 
> The first shot at fixing this bug was to filter out ACC_SYNTHETIC. The drawback was that the actual lambda method are marked ACC_SYNTHETIC, so that filtered too much.

OTOH it seems odd to filter out the actual interface method. 

Ideally the back trace should show the name of the interface method and the implementation code of the lambda. 

This information is divided between the two frames in question. 

From ivan.gerasimov at oracle.com  Tue Feb 17 06:54:55 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 17 Feb 2015 09:54:55 +0300
Subject: RFR 8072466: Deadlock when starting MulticastSocket and
	DatagramSocket
In-Reply-To: <54D4FE63.5090108@oracle.com>
References: <54D4FE63.5090108@oracle.com>
Message-ID: <54E2E5BF.3080304@oracle.com>

Can someone help review this fix please?

Comments/suggestions are welcome!

Sincerely yours,
Ivan

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



From david.holmes at oracle.com  Tue Feb 17 06:55:45 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Feb 2015 16:55:45 +1000
Subject: RFR 8073124: Tune test and document TimSort runs length stack
	size increase
In-Reply-To: <54E2D51B.8020808@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>
Message-ID: <54E2E5F1.4070702@oracle.com>

On 17/02/2015 3:43 PM, Lev Priima wrote:
> Thanks David!
> Is this expected behavior of this annotation ?

Yes that is the way jtreg defines tags:

http://openjdk.java.net/jtreg/tag-spec.html

"The argument tokens of a tag extend from the first token after the tag 
token to the end of the comment, the end of the file, or the next tag 
token, whichever comes first."

So everything between @run and @summary are taken to be the @run 
commands. And there's no @comment tag unfortunately.

David

> Lev
>
> On 02/17/2015 03:20 AM, David Holmes wrote:
>> On 16/02/2015 9:20 PM, David Holmes wrote:
>>> On 16/02/2015 6:59 PM, Lev Priima wrote:
>>>> Thanks, David,
>>>> Could you please push it ?
>>>
>>> I will if Roger doesn't get to it first. It'll be 11 hours before I can
>>> push it.
>>
>> This has been pushed but note there is a minor issue with the test.
>> The jtreg tag specification doesn't terminate tags on newlines, they
>> continue until the next tag is encountered or the end of the comment.
>> Consequently this:
>>
>>  * @run main/othervm -Xmx385m TimSortStackSize2 67108864
>>  * not for regular execution on all platforms:
>>  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>  * run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>
>> is processed as:
>>
>> @run main/othervm -Xmx385m TimSortStackSize2 67108864 not for regular
>> execution on all platforms: run main/othervm -Xmx8g TimSortStackSize2
>> 1073741824 run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>
>> and so TimSortStackSize2 is invoked with 18 arguments.
>>
>> David
>> -----
>>
>>> David
>>>
>>>> Lev
>>>>
>>>> On 02/16/2015 08:55 AM, David Holmes wrote:
>>>>> On 14/02/2015 12:03 AM, Lev Priima wrote:
>>>>>> Please review and push:
>>>>>> http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073124
>>>>>
>>>>> I hadn't realized 8072909 had been pushed without final reviewer
>>>>> comments being addressed. :(
>>>>>
>>>>> These changes seem okay. I hope they get promoted at the same time as
>>>>> the original changeset so we don't get test failures.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Lev
>>>>>>
>>>>>> On 02/13/2015 05:20 AM, David Holmes wrote:
>>>>>>> Hi Lev,
>>>>>>>
>>>>>>> On 13/02/2015 2:56 AM, Lev Priima wrote:
>>>>>>>> Christos,
>>>>>>>>
>>>>>>>> Test may fail on shorter arrays(page 8 of paper). For instance, on
>>>>>>>> worst
>>>>>>>> case, generated by test, it starts to fail on length 67108864.
>>>>>>>> After increasing stack size of runs to merge, Arrays.sort(T[])
>>>>>>>> works
>>>>>>>> also on maximum possible array for HotSpot JVM.
>>>>>>>
>>>>>>> I'd also like to see this documented somewhere in the code.
>>>>>>> Presently
>>>>>>> there is a reference to listsort.txt but then you have to go and
>>>>>>> find
>>>>>>> it on the web. :( At a minimum could we please add:
>>>>>>>
>>>>>>>  175          * computation below must be changed if MIN_MERGE is
>>>>>>> decreased.  See
>>>>>>>  176          * the MIN_MERGE declaration above for more
>>>>>>> information.
>>>>>>> +             * The maximum value of 49 allows for an array up to
>>>>>>> length
>>>>>>> +             * Integer.MAX_VALUE-4.
>>>>>>>
>>>>>>>> Roger, David,
>>>>>>>> I've updated the test (
>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ) to make it more suitable for regular execution:
>>>>>>>>
>>>>>>>>    27  * @run main/othervm TimSortStackSize2 67108864
>>>>>>>
>>>>>>> This will still fail on small memory devices:
>>>>>>>
>>>>>>> :~> java TimSortStackSize2 67108864
>>>>>>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap
>>>>>>> space
>>>>>>>
>>>>>>> as the default heap ergonomics may not be large enough. I had to
>>>>>>> add a
>>>>>>> minimum heap of -Xmx385M to get it to run.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>>    28  * not for regular execution on all platforms:
>>>>>>>>    29  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>>>>    30  * run main/othervm -Xmx32g TimSortStackSize2 2147483644
>>>>>>>>
>>>>>>>> Could you please push this:
>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>>>>>>>> ?
>>>>>>>>
>>>>>>>> Lev
>>>>>>>>
>>>>>>>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>>>>>>>> On Feb 12, 9:57pm,david.holmes at oracle.com  (David Holmes) wrote:
>>>>>>>>> -- Subject: Re: 8072909: TimSort fails with
>>>>>>>>> ArrayIndexOutOfBoundsException on
>>>>>>>>>
>>>>>>>>> | Ok - thanks Lev!
>>>>>>>>> |
>>>>>>>>> | David
>>>>>>>>>
>>>>>>>>> For posterity can someone document this, and also the value for
>>>>>>>>> which
>>>>>>>>> Integer.MAX_VALUE-4 fails?
>>>>>>>>>
>>>>>>>>> christos
>>>>>>>>
>>>>>>
>>>>
>


From Alan.Bateman at oracle.com  Tue Feb 17 08:54:34 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 17 Feb 2015 08:54:34 +0000
Subject: [9] RFR of 8073207: javadoc typos in java.nio.channels.Pipe
In-Reply-To: <7122B986-738E-41A7-B9D2-FFE54F20FE46@oracle.com>
References: <7122B986-738E-41A7-B9D2-FFE54F20FE46@oracle.com>
Message-ID: <54E301CA.3050801@oracle.com>

On 16/02/2015 21:58, Brian Burkhalter wrote:
> Please review at your convenience:
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8073207
> Patch:	http://cr.openjdk.java.net/~bpb/8073207/webrev.00/
>
> Simply implements what the description suggests.
>
Looks good, I don't know how long it has been there.

-Alan


From fweimer at redhat.com  Tue Feb 17 09:39:04 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 17 Feb 2015 10:39:04 +0100
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>	<54DE8BB7.5050801@oracle.com>
	<54DE9140.3040604@oracle.com>
	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
Message-ID: <54E30C38.8000303@redhat.com>

On 02/14/2015 01:09 AM, John Rose wrote:
> These queries need to go into Unsafe.
> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever second-best mechanism the platform offers.

The safe variants should go into the java.lang.Integer etc. classes
IMHO.  Even the JDK has quite a few uses for them (particularly the big
endian variant).  Putting that into Unsafe only encourages further use
of Unsafe from application code.

-- 
Florian Weimer / Red Hat Product Security


From fweimer at redhat.com  Tue Feb 17 09:41:34 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 17 Feb 2015 10:41:34 +0100
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54DFC7F3.9050309@oracle.com>
References: <54DDFE72.1050306@redhat.com>
	<54DE8017.6080608@oracle.com>	<54DF022A.9080707@redhat.com>
	<54DFC7F3.9050309@oracle.com>
Message-ID: <54E30CCE.8030608@redhat.com>

On 02/14/2015 11:10 PM, Dean Long wrote:

> Even if linux-aarch64 always allows unaligned, checking only for
> "aarch64" is not future-proof
> because it doesn't take the OS into account.

Surely a simple test case is sufficient to ensure that the platform
supports misaligned accesses?  Then new ports will see the failure
immediately and can tweak the code.

-- 
Florian Weimer / Red Hat Product Security


From aph at redhat.com  Tue Feb 17 10:00:36 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 17 Feb 2015 10:00:36 +0000
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E30C38.8000303@redhat.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>	<54DE8BB7.5050801@oracle.com>	<54DE9140.3040604@oracle.com>	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
	<54E30C38.8000303@redhat.com>
Message-ID: <54E31144.3040504@redhat.com>

On 02/17/2015 09:39 AM, Florian Weimer wrote:
> On 02/14/2015 01:09 AM, John Rose wrote:
>> These queries need to go into Unsafe.
>> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever second-best mechanism the platform offers.
> 
> The safe variants should go into the java.lang.Integer etc. classes
> IMHO.  Even the JDK has quite a few uses for them (particularly the
> big endian variant).  Putting that into Unsafe only encourages
> further use of Unsafe from application code.

They'll all be visible as ByteBuffer methods, which should be enough
for application code, shouldn't it?  I'm not sure how much sense it
makes to put them into java.lang.Integer etc.

Andrew.


From fweimer at redhat.com  Tue Feb 17 10:15:27 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 17 Feb 2015 11:15:27 +0100
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E31144.3040504@redhat.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>	<54DE8BB7.5050801@oracle.com>	<54DE9140.3040604@oracle.com>	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
	<54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com>
Message-ID: <54E314BF.3010205@redhat.com>

On 02/17/2015 11:00 AM, Andrew Haley wrote:
> On 02/17/2015 09:39 AM, Florian Weimer wrote:
>> On 02/14/2015 01:09 AM, John Rose wrote:
>>> These queries need to go into Unsafe.
>>> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever second-best mechanism the platform offers.
>>
>> The safe variants should go into the java.lang.Integer etc. classes
>> IMHO.  Even the JDK has quite a few uses for them (particularly the
>> big endian variant).  Putting that into Unsafe only encourages
>> further use of Unsafe from application code.
> 
> They'll all be visible as ByteBuffer methods, which should be enough
> for application code, shouldn't it?  I'm not sure how much sense it
> makes to put them into java.lang.Integer etc.

You'll still have to allocate a wrapping ByteBuffer object to use them.
 I expect that makes them unattractive in many cases.

Hmm, maybe I should propose a patch for DataInputStream and see how it's
received. :-)

-- 
Florian Weimer / Red Hat Product Security


From aph at redhat.com  Tue Feb 17 10:22:47 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 17 Feb 2015 10:22:47 +0000
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E314BF.3010205@redhat.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>	<54DE8BB7.5050801@oracle.com>	<54DE9140.3040604@oracle.com>	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
	<54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com>
	<54E314BF.3010205@redhat.com>
Message-ID: <54E31677.1050209@redhat.com>

On 02/17/2015 10:15 AM, Florian Weimer wrote:
> On 02/17/2015 11:00 AM, Andrew Haley wrote:
>> On 02/17/2015 09:39 AM, Florian Weimer wrote:
>>> On 02/14/2015 01:09 AM, John Rose wrote:
>>>> These queries need to go into Unsafe.
>>>> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever second-best mechanism the platform offers.
>>>
>>> The safe variants should go into the java.lang.Integer etc. classes
>>> IMHO.  Even the JDK has quite a few uses for them (particularly the
>>> big endian variant).  Putting that into Unsafe only encourages
>>> further use of Unsafe from application code.
>>
>> They'll all be visible as ByteBuffer methods, which should be enough
>> for application code, shouldn't it?  I'm not sure how much sense it
>> makes to put them into java.lang.Integer etc.
> 
> You'll still have to allocate a wrapping ByteBuffer object to use them.
>  I expect that makes them unattractive in many cases.

Hmm.  I'm having a hard time trying to understand why.  If you need to
do a lot of accesses the allocation of the ByteBuffer won't be
significant; if you don't need to do a lot of accesses it won't
matter either.

Andrew.


From fweimer at redhat.com  Tue Feb 17 10:49:10 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 17 Feb 2015 11:49:10 +0100
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E31677.1050209@redhat.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>	<54DE8BB7.5050801@oracle.com>	<54DE9140.3040604@oracle.com>	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
	<54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com>
	<54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com>
Message-ID: <54E31CA6.6030609@redhat.com>

On 02/17/2015 11:22 AM, Andrew Haley wrote:
>> You'll still have to allocate a wrapping ByteBuffer object to use them.
>>  I expect that makes them unattractive in many cases.
> 
> Hmm.  I'm having a hard time trying to understand why.  If you need to
> do a lot of accesses the allocation of the ByteBuffer won't be
> significant; if you don't need to do a lot of accesses it won't
> matter either.

The typical use case I have in mind is exemplified by
com.sun.crypto.provider.GHASH(processBlock(byte[] data, int ofs):

 174     private void processBlock(byte[] data, int ofs) {
 175         if (data.length - ofs < AES_BLOCK_SIZE) {
 176             throw new RuntimeException("need complete block");
 177         }
 178         state0 ^= getLong(data, ofs);
 179         state1 ^= getLong(data, ofs + 8);
 180         blockMult(subkeyH0, subkeyH1);
 181     }

That is, the byte array is supplied by the caller, and if we wanted to
use a ByteBuffer, we would have to allocate a fresh one on every
iteration.  In this case, neither of the two alternatives you list apply.

-- 
Florian Weimer / Red Hat Product Security


From aph at redhat.com  Tue Feb 17 10:53:20 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 17 Feb 2015 10:53:20 +0000
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E31CA6.6030609@redhat.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>	<54DE8BB7.5050801@oracle.com>	<54DE9140.3040604@oracle.com>	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
	<54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com>
	<54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com>
	<54E31CA6.6030609@redhat.com>
Message-ID: <54E31DA0.2040901@redhat.com>

On 02/17/2015 10:49 AM, Florian Weimer wrote:
> On 02/17/2015 11:22 AM, Andrew Haley wrote:
>>> You'll still have to allocate a wrapping ByteBuffer object to use them.
>>>  I expect that makes them unattractive in many cases.
>>
>> Hmm.  I'm having a hard time trying to understand why.  If you need to
>> do a lot of accesses the allocation of the ByteBuffer won't be
>> significant; if you don't need to do a lot of accesses it won't
>> matter either.
> 
> The typical use case I have in mind is exemplified by
> com.sun.crypto.provider.GHASH(processBlock(byte[] data, int ofs):
> 
>  174     private void processBlock(byte[] data, int ofs) {
>  175         if (data.length - ofs < AES_BLOCK_SIZE) {
>  176             throw new RuntimeException("need complete block");
>  177         }
>  178         state0 ^= getLong(data, ofs);
>  179         state1 ^= getLong(data, ofs + 8);
>  180         blockMult(subkeyH0, subkeyH1);
>  181     }
> 
> That is, the byte array is supplied by the caller, and if we wanted to
> use a ByteBuffer, we would have to allocate a fresh one on every
> iteration.  In this case, neither of the two alternatives you list apply.

I see.  So the question could also be whether escape analysis would
notice that a ByteBuffer does not escape.  I hope to know that soon.

Andrew.




From oss at qualeed.com  Tue Feb 17 12:53:38 2015
From: oss at qualeed.com (Dai Nakanishi)
Date: Tue, 17 Feb 2015 21:53:38 +0900
Subject: [PATCH] CipherStream produces new byte array on every update or
	doFinal operation
Message-ID: <20150217215338.5506.B5B9BC9E@qualeed.com>

Hi,

CipherInputStream and CipherOutputStream call the Cipher methods update
and doFinal which produce new byte array. It may consume a large amount
of memory.

The purpose of my patch is to avoid this. Could you review the patch?

Thanks,
Dai

--- old/src/share/classes/javax/crypto/CipherInputStream.java	Thu Feb 12 11:55:05 2015 +0900
+++ new/src/share/classes/javax/crypto/CipherInputStream.java	Tue Feb 17 17:12:08 2015 +0900
@@ -108,34 +108,50 @@
         read = true;
         if (readin == -1) {
             done = true;
+            ensureCapacity(0);
             try {
-                obuffer = cipher.doFinal();
-            } catch (IllegalBlockSizeException | BadPaddingException e) {
+                ofinish = cipher.doFinal(obuffer, 0);
+            } catch (IllegalBlockSizeException | BadPaddingException
+                    | ShortBufferException e) {
                 obuffer = null;
                 throw new IOException(e);
             }
-            if (obuffer == null)
+            if (ofinish == 0)
                 return -1;
             else {
                 ostart = 0;
-                ofinish = obuffer.length;
                 return ofinish;
             }
         }
+        ensureCapacity(readin);
         try {
-            obuffer = cipher.update(ibuffer, 0, readin);
+            ofinish = cipher.update(ibuffer, 0, readin, obuffer);
         } catch (IllegalStateException e) {
             obuffer = null;
             throw e;
+        } catch (ShortBufferException e) {
+            obuffer = null;
+            throw new IOException(e);
         }
         ostart = 0;
-        if (obuffer == null)
-            ofinish = 0;
-        else ofinish = obuffer.length;
         return ofinish;
     }
 
     /**
+     * Ensure the capacity of the output buffer for the next
+     * update or doFinal operation, given the input length
+     * <code>inputLen</code> (in bytes)
+     * 
+     * @param inputLen the input length (in bytes)
+     */
+    private void ensureCapacity(int inputLen) {
+        int outputLen = cipher.getOutputSize(inputLen);
+        if (obuffer == null || obuffer.length < outputLen) {
+            obuffer = new byte[outputLen];
+        }
+    }
+    
+    /**
      * Constructs a CipherInputStream from an InputStream and a
      * Cipher.
      * <br>Note: if the specified input stream or cipher is
@@ -311,10 +327,12 @@
         try {
             // throw away the unprocessed data
             if (!done) {
-                cipher.doFinal();
+                ensureCapacity(0);
+                cipher.doFinal(obuffer, 0);
             }
         }
-        catch (BadPaddingException | IllegalBlockSizeException ex) {
+        catch (BadPaddingException | IllegalBlockSizeException
+                | ShortBufferException ex) {
             /* If no data has been read from the stream to be en/decrypted,
                we supress any exceptions, and close quietly. */
             if (read) {


--- old/src/share/classes/javax/crypto/CipherOutputStream.java	Thu Feb 12 11:55:05 2015 +0900
+++ new/src/share/classes/javax/crypto/CipherOutputStream.java	Tue Feb 17 18:48:01 2015 +0900
@@ -74,6 +74,9 @@
     // the buffer holding data ready to be written out
     private byte[] obuffer;
 
+    // the number of bytes stored in the output buffer 
+    private int ostored = 0;
+
     // stream status
     private boolean closed = false;
 
@@ -118,10 +121,15 @@
      */
     public void write(int b) throws IOException {
         ibuffer[0] = (byte) b;
-        obuffer = cipher.update(ibuffer, 0, 1);
-        if (obuffer != null) {
-            output.write(obuffer);
-            obuffer = null;
+        ensureCapacity(1);
+        try {
+            ostored = cipher.update(ibuffer, 0, 1, obuffer);
+        } catch (ShortBufferException e) {
+            throw new IOException(e);
+        }
+        if (ostored > 0) {
+            output.write(obuffer, 0, ostored);
+            ostored = 0;
         }
     };
 
@@ -155,10 +163,15 @@
      * @since      JCE1.2
      */
     public void write(byte b[], int off, int len) throws IOException {
-        obuffer = cipher.update(b, off, len);
-        if (obuffer != null) {
-            output.write(obuffer);
-            obuffer = null;
+        ensureCapacity(len);
+        try {
+            ostored = cipher.update(b, off, len, obuffer);
+        } catch (ShortBufferException e) {
+            throw new IOException(e);
+        }
+        if (ostored > 0) {
+            output.write(obuffer, 0, ostored);
+            ostored = 0;
         }
     }
 
@@ -177,9 +190,9 @@
      * @since      JCE1.2
      */
     public void flush() throws IOException {
-        if (obuffer != null) {
-            output.write(obuffer);
-            obuffer = null;
+        if (obuffer != null && ostored > 0) {
+            output.write(obuffer, 0, ostored);
+            ostored = 0;
         }
         output.flush();
     }
@@ -206,14 +219,31 @@
         }
 
         closed = true;
+        ensureCapacity(0);
         try {
-            obuffer = cipher.doFinal();
-        } catch (IllegalBlockSizeException | BadPaddingException e) {
+            ostored = cipher.doFinal(obuffer, 0);
+        } catch (IllegalBlockSizeException | BadPaddingException
+                | ShortBufferException e) {
             obuffer = null;
+            ostored = 0;
         }
         try {
             flush();
         } catch (IOException ignored) {}
         out.close();
+    }
+
+    /**
+     * Ensure the capacity of the output buffer for the next
+     * update or doFinal operation, given the input length
+     * <code>inputLen</code> (in bytes)
+     * 
+     * @param inputLen the input length (in bytes)
+     */
+    private void ensureCapacity(int inputLen) {
+        int outputLen = cipher.getOutputSize(inputLen);
+        if (obuffer == null || obuffer.length < outputLen) {
+            obuffer = new byte[outputLen];
+        }
     }
 }



From fweimer at redhat.com  Tue Feb 17 13:21:50 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 17 Feb 2015 14:21:50 +0100
Subject: [PATCH] CipherStream produces new byte array on every update
	or doFinal operation
In-Reply-To: <20150217215338.5506.B5B9BC9E@qualeed.com>
References: <20150217215338.5506.B5B9BC9E@qualeed.com>
Message-ID: <54E3406E.7010304@redhat.com>

On 02/17/2015 01:53 PM, Dai Nakanishi wrote:
> +        } catch (ShortBufferException e) {
> +            obuffer = null;
> +            throw new IOException(e);
>          }

This doesn't look right to me.  You need to enlarge the buffer and retry.

If you really want to avoid allocations, you should use the destination
buffer passed to the read() function if the slice end is equal to the
array end.  I expect that this is the usual case.

By the way, I think such review requests should be sent to security-dev,
not core-libs-dev.

-- 
Florian Weimer / Red Hat Product Security


From Ulf.Zibis at CoSoCo.de  Tue Feb 17 13:44:40 2015
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 17 Feb 2015 14:44:40 +0100
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E31DA0.2040901@redhat.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>	<54DE8BB7.5050801@oracle.com>	<54DE9140.3040604@oracle.com>	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>	<54E30C38.8000303@redhat.com>
	<54E31144.3040504@redhat.com>	<54E314BF.3010205@redhat.com>
	<54E31677.1050209@redhat.com>	<54E31CA6.6030609@redhat.com>
	<54E31DA0.2040901@redhat.com>
Message-ID: <54E345C8.50802@CoSoCo.de>


Am 17.02.2015 um 11:53 schrieb Andrew Haley:
> On 02/17/2015 10:49 AM, Florian Weimer wrote:
>> That is, the byte array is supplied by the caller, and if we wanted to
>> use a ByteBuffer, we would have to allocate a fresh one on every
>> iteration.  In this case, neither of the two alternatives you list apply.
> I see.  So the question could also be whether escape analysis would
> notice that a ByteBuffer does not escape.  I hope to know that soon.

See:
https://bugs.openjdk.java.net/browse/JDK-6908239
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6914113

-Ulf



From vitalyd at gmail.com  Tue Feb 17 13:52:51 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 17 Feb 2015 08:52:51 -0500
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E31DA0.2040901@redhat.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>
	<54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com>
	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
	<54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com>
	<54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com>
	<54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com>
Message-ID: <CAHjP37HxZB7=DHDu6p6z8ZZc=BSorAzxr3pj500nYnC0N+q+WQ@mail.gmail.com>

FWIW, when I checked, ByteBuffer.wrap(...).getXXX() type of code didn't EA
out the BB; it seems the call chain is too complex for EA.  I checked 7u60
though, so maybe newer versions are different.

sent from my phone
On Feb 17, 2015 5:53 AM, "Andrew Haley" <aph at redhat.com> wrote:

> On 02/17/2015 10:49 AM, Florian Weimer wrote:
> > On 02/17/2015 11:22 AM, Andrew Haley wrote:
> >>> You'll still have to allocate a wrapping ByteBuffer object to use them.
> >>>  I expect that makes them unattractive in many cases.
> >>
> >> Hmm.  I'm having a hard time trying to understand why.  If you need to
> >> do a lot of accesses the allocation of the ByteBuffer won't be
> >> significant; if you don't need to do a lot of accesses it won't
> >> matter either.
> >
> > The typical use case I have in mind is exemplified by
> > com.sun.crypto.provider.GHASH(processBlock(byte[] data, int ofs):
> >
> >  174     private void processBlock(byte[] data, int ofs) {
> >  175         if (data.length - ofs < AES_BLOCK_SIZE) {
> >  176             throw new RuntimeException("need complete block");
> >  177         }
> >  178         state0 ^= getLong(data, ofs);
> >  179         state1 ^= getLong(data, ofs + 8);
> >  180         blockMult(subkeyH0, subkeyH1);
> >  181     }
> >
> > That is, the byte array is supplied by the caller, and if we wanted to
> > use a ByteBuffer, we would have to allocate a fresh one on every
> > iteration.  In this case, neither of the two alternatives you list apply.
>
> I see.  So the question could also be whether escape analysis would
> notice that a ByteBuffer does not escape.  I hope to know that soon.
>
> Andrew.
>
>
>


From Ulf.Zibis at CoSoCo.de  Tue Feb 17 13:57:12 2015
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 17 Feb 2015 14:57:12 +0100
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <CE824686-FD7C-485C-B809-303A004B49D5@oracle.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>	<54DE8BB7.5050801@oracle.com>
	<54DE9140.3040604@oracle.com>	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>	<54DF00C4.7030308@redhat.com>
	<CE824686-FD7C-485C-B809-303A004B49D5@oracle.com>
Message-ID: <54E348B8.8030601@CoSoCo.de>

Am 17.02.2015 um 04:35 schrieb John Rose:
> On Feb 14, 2015, at 12:01 AM, Andrew Haley <aph at redhat.com> wrote:
>> On 02/14/2015 12:09 AM, John Rose wrote:
>>> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever second-best mechanism the platform offers.
>> Indeed.  I'm intending to prototype a design for those next week.  OK?
> Yes, please.  ? John

+1
I guess, also sun.nio.cs coders could benefit from that.

-Ulf



From aph at redhat.com  Tue Feb 17 14:22:39 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 17 Feb 2015 14:22:39 +0000
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E31DA0.2040901@redhat.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>	<54DE8BB7.5050801@oracle.com>	<54DE9140.3040604@oracle.com>	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>	<54E30C38.8000303@redhat.com>
	<54E31144.3040504@redhat.com>	<54E314BF.3010205@redhat.com>
	<54E31677.1050209@redhat.com>	<54E31CA6.6030609@redhat.com>
	<54E31DA0.2040901@redhat.com>
Message-ID: <54E34EAF.6000802@redhat.com>

On 02/17/2015 10:53 AM, Andrew Haley wrote:
> I see.  So the question could also be whether escape analysis would
> notice that a ByteBuffer does not escape.  I hope to know that soon.

Close but no cigar.

    long getLong(byte[] bytes, int i) {
        return ByteBuffer.wrap(bytes).getLong(i);
    }

Everything gets inlined nicely and the ByteBuffer is not created, but
a store fence remains because of the final fields in HeapByteBuffer.

So the resulting code for getLong (minus the prologue and epilogue) looks like this:

  0x000003ff7426dc34: ldr	w11, [x2,#12]   ;*arraylength
                                                ; - java.nio.ByteBuffer::wrap at 3 (line 396)
                                                ; - bytebuffertests.ByteBufferTests3::getLong at 1 (line 23)
                                                ; implicit exception: dispatches to 0x000003ff7426dca4
  ;; B2: #	B5 B3 <- B1  Freq: 0.999999

  0x000003ff7426dc38: dmb	ish             ;*synchronization entry
                                                ; - java.nio.HeapByteBuffer::<init>@-1 (line 84)
                                                ; - java.nio.ByteBuffer::wrap at 7 (line 373)
                                                ; - java.nio.ByteBuffer::wrap at 4 (line 396)
                                                ; - bytebuffertests.ByteBufferTests3::getLong at 1 (line 23)

  0x000003ff7426dc3c: sub	w12, w11, w3    ;*isub
                                                ; - java.nio.Buffer::checkIndex at 10 (line 545)
                                                ; - java.nio.HeapByteBuffer::getLong at 18 (line 465)
                                                ; - bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)

  0x000003ff7426dc40: cmp	w3, #0x0
  0x000003ff7426dc44: b.lt	0x000003ff7426dc70  ;*iflt
                                                ; - java.nio.Buffer::checkIndex at 1 (line 545)
                                                ; - java.nio.HeapByteBuffer::getLong at 18 (line 465)
                                                ; - bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)

  ;; B3: #	B6 B4 <- B2  Freq: 0.999999

  0x000003ff7426dc48: cmp	w12, #0x8
  0x000003ff7426dc4c: b.lt	0x000003ff7426dc88  ;*if_icmple
                                                ; - java.nio.Buffer::checkIndex at 11 (line 545)
                                                ; - java.nio.HeapByteBuffer::getLong at 18 (line 465)
                                                ; - bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)

  ;; B4: #	N92 <- B3  Freq: 0.999998

  0x000003ff7426dc50: add	x10, x2, w3, sxtw
  0x000003ff7426dc54: ldr	x10, [x10,#16]
  0x000003ff7426dc58: rev	x0, x10         ;*invokestatic reverseBytes
                                                ; - java.nio.Bits::swap at 1 (line 61)
                                                ; - java.nio.HeapByteBuffer::getLong at 41 (line 466)
                                                ; - bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)

If it weren't for the stray DMB ISH it'd be almost perfect.

Andrew.


From oss at qualeed.com  Tue Feb 17 15:24:57 2015
From: oss at qualeed.com (Dai Nakanishi)
Date: Wed, 18 Feb 2015 00:24:57 +0900
Subject: [PATCH] CipherStream produces new byte array on every update or
	doFinal operation
In-Reply-To: <54E3406E.7010304@redhat.com>
References: <20150217215338.5506.B5B9BC9E@qualeed.com>
	<54E3406E.7010304@redhat.com>
Message-ID: <20150218002457.13D8.B5B9BC9E@qualeed.com>

Thank you for your review.
My apologies for sending an inappropriate request.

Cipher should not throw the ShortBufferException because the buffer is
enlarged before update() or doFinal(). The enlarged size is based on the
result of getOutputSize().

Even if I use the destination buffer, CipherInputStream allocates the new array.

Dai

On Tue, 17 Feb 2015 14:21:50 +0100
Florian Weimer <fweimer at redhat.com> wrote:

> On 02/17/2015 01:53 PM, Dai Nakanishi wrote:
> > +        } catch (ShortBufferException e) {
> > +            obuffer = null;
> > +            throw new IOException(e);
> >          }
> 
> This doesn't look right to me.  You need to enlarge the buffer and retry.
> 
> If you really want to avoid allocations, you should use the destination
> buffer passed to the read() function if the slice end is equal to the
> array end.  I expect that this is the usual case.
> 
> By the way, I think such review requests should be sent to security-dev,
> not core-libs-dev.
> 
> -- 
> Florian Weimer / Red Hat Product Security



From peter.levart at gmail.com  Tue Feb 17 16:27:14 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 17 Feb 2015 17:27:14 +0100
Subject: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
In-Reply-To: <364AD047-000F-4A98-951A-9D33937DFA1E@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>
	<364AD047-000F-4A98-951A-9D33937DFA1E@oracle.com>
Message-ID: <54E36BE2.7030105@gmail.com>

On 02/17/2015 07:54 AM, John Rose wrote:
> On Feb 16, 2015, at 10:33 PM, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>> The first shot at fixing this bug was to filter out ACC_SYNTHETIC. The drawback was that the actual lambda method are marked ACC_SYNTHETIC, so that filtered too much.
> OTOH it seems odd to filter out the actual interface method.
>
> Ideally the back trace should show the name of the interface method and the implementation code of the lambda.
>
> This information is divided between the two frames in question.

That's right. Lambda method is special. It is synthetic, but contains 
user code. So perhaps lambda method could be annotated with a special 
annotation (@SyntheticName) to indicate that the name of the method is 
generated and not interesting, but it's code is written by a programmer 
and is interesting. If this info was included in the StackTraceElement, 
then printing the stack trace could merge the byte code location of such 
element with the class/method name of the subsequent element and print 
both in one line...

The logic behind this is general: if a method name is generated and not 
interesting (the lambda method), then code calling such method must have 
been generated too and is consequently not interesting (the proxy method).

Peter



From john.r.rose at oracle.com  Tue Feb 17 18:42:00 2015
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 17 Feb 2015 10:42:00 -0800
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E34EAF.6000802@redhat.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>
	<54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com>
	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
	<54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com>
	<54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com>
	<54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com>
	<54E34EAF.6000802@redhat.com>
Message-ID: <0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com>

On Feb 17, 2015, at 6:22 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> Everything gets inlined nicely and the ByteBuffer is not created, but
> a store fence remains because of the final fields in HeapByteBuffer.

Wow, that got closer to the goal than I expected.  In general, the EA analysis can fail "at random" because of vagaries of inlining policy.

The remaining store fence is probably a bug.  A store fence for scalarized (lifted-out-of-memory) final fields should go away, since the fields are not actually stored in heap memory.

I filed JDK-8073358 to track.

BTW, we already elide synch. ops on scalarized (non-stored) objects.  Fence elision is a similar optimization.

? John

P.S.  Value types will come with scalarization "always-on", so even if a call goes out of line, the value's fields can be kept out of the heap.

One of the projected use cases of values is safe encapsulation for complex pointers (native or in-object).

From brian.burkhalter at oracle.com  Tue Feb 17 18:52:43 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 17 Feb 2015 10:52:43 -0800
Subject: [9] RFR of 8073347: javadoc of Formattable messed up by JDK-8019857
Message-ID: <F2A311B8-7584-43AD-99B9-152FAB738841@oracle.com>

Please review at your convenience.

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

Note the before and after versions of the HTML.

Thanks,

Brian


From aph at redhat.com  Tue Feb 17 18:58:19 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 17 Feb 2015 18:58:19 +0000
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>
	<54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com>
	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
	<54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com>
	<54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com>
	<54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com>
	<54E34EAF.6000802@redhat.com>
	<0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com>
Message-ID: <54E38F4B.7060100@redhat.com>

On 02/17/2015 06:42 PM, John Rose wrote:
> The remaining store fence is probably a bug.  A store fence for scalarized (lifted-out-of-memory) final fields should go away, since the fields are not actually stored in heap memory.

After inlining how would escape analysis know that the store fence is
associated with final fields rather than, say, an explicit
Unsafe.storeFence() ?

Andrew.



From martinrb at google.com  Tue Feb 17 19:09:10 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 17 Feb 2015 11:09:10 -0800
Subject: [9] RFR of 8073347: javadoc of Formattable messed up by
	JDK-8019857
In-Reply-To: <F2A311B8-7584-43AD-99B9-152FAB738841@oracle.com>
References: <F2A311B8-7584-43AD-99B9-152FAB738841@oracle.com>
Message-ID: <CA+kOe08sFjpYVoczNYEPVAuk3g5YsKDKEp9ND9P9k+6DwEtc6Q@mail.gmail.com>

Thanks for the prompt response.

I think there's now an unbalanced } in the javadoc.

Although this bug report was only about Formattable, I was hoping to fix
all the scrunched-up @code's.
(@code that extends over more than 2 lines should have a <pre> added, using
the standard idiom. I've gone ahead and fixed jsr166.

I would unindent the code sample body itself 2 spaces left (but that's an
independent code sample formatting issue).



On Tue, Feb 17, 2015 at 10:52 AM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> Please review at your convenience.
>
> Issue:  https://bugs.openjdk.java.net/browse/JDK-8073347
> Patch:  http://cr.openjdk.java.net/~bpb/8073347/
>
> Note the before and after versions of the HTML.
>
> Thanks,
>
> Brian
>


From vitalyd at gmail.com  Tue Feb 17 19:12:31 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 17 Feb 2015 14:12:31 -0500
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E38F4B.7060100@redhat.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>
	<54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com>
	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
	<54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com>
	<54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com>
	<54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com>
	<54E34EAF.6000802@redhat.com>
	<0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com>
	<54E38F4B.7060100@redhat.com>
Message-ID: <CAHjP37HUESG4sLD-iH-tD5JBAPrUahqW+HY3z1KF5wYnZ0USOg@mail.gmail.com>

What do you mean exactly? I don't think inlining "hides" anything, so the
explicit fence should still be there for EA to see (and preserve).

sent from my phone
On Feb 17, 2015 1:58 PM, "Andrew Haley" <aph at redhat.com> wrote:

> On 02/17/2015 06:42 PM, John Rose wrote:
> > The remaining store fence is probably a bug.  A store fence for
> scalarized (lifted-out-of-memory) final fields should go away, since the
> fields are not actually stored in heap memory.
>
> After inlining how would escape analysis know that the store fence is
> associated with final fields rather than, say, an explicit
> Unsafe.storeFence() ?
>
> Andrew.
>
>


From vladimir.kozlov at oracle.com  Tue Feb 17 19:15:48 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 17 Feb 2015 11:15:48 -0800
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E38F4B.7060100@redhat.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>
	<54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com>
	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
	<54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com>
	<54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com>
	<54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com>
	<54E34EAF.6000802@redhat.com>
	<0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com>
	<54E38F4B.7060100@redhat.com>
Message-ID: <54E39364.6030409@oracle.com>

There was discussion should we remove such barriers or not because they 
create memory operations ordering which could be different if we remove 
them.

To eliminate them we need to add 'precedent' edge to store's membar as 
we do, for example, for loads:

   if (field->is_volatile()) {
     // Memory barrier includes bogus read of value to force load BEFORE 
membar
     insert_mem_bar(Op_MemBarAcquire, ld);
   }

MemBarNode::Ideal() will do elimination.

Regards,
Vladimir

On 2/17/15 10:58 AM, Andrew Haley wrote:
> On 02/17/2015 06:42 PM, John Rose wrote:
>> The remaining store fence is probably a bug.  A store fence for scalarized (lifted-out-of-memory) final fields should go away, since the fields are not actually stored in heap memory.
>
> After inlining how would escape analysis know that the store fence is
> associated with final fields rather than, say, an explicit
> Unsafe.storeFence() ?
>
> Andrew.
>


From Roger.Riggs at Oracle.com  Tue Feb 17 19:17:16 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 17 Feb 2015 14:17:16 -0500
Subject: JEP 102 Process Updates revised API draft
In-Reply-To: <54DE1969.2040508@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>
Message-ID: <54E393BC.4030600@Oracle.com>

Hi Peter, et.al.,

I have no particular issue with adding waitForUninterruptibly but it 
does not
help with the lack of scalability when handling many processes.
It requires a thread to do the waiting whether from a specific caller or 
a thread pool

The intent of proving a Future/CF was to allow the implementation the 
choice of
how to wait for termination including those mechanisms that do not 
require dedicating
a thread to the  monitoring of termination and taking an action thereafter.
On Windows for example, WaitForMultipleObjects can be used to multiplex 
the waiting.

With Lambda providing the behavior to CF, the lambda can capture the 
reference
to the Process[Handle] without relying on the generic type of the CF.

Process p = ...;
CompletableFuture<ProcessHandle> cf = p.completableFuture();
cf.thenRunAsync(  () -> {int exitValue = p.getExitValue(); ....   })

Or using CompletableFuture<Void> would force the developer to capture 
the Process[Handle]
reference as needed.

Another alternative is a simple method 
onTermination(Consumer<ProcessHandle> consumer)
that makes it easy to use lambdas to provide the behavior.  The 
implementation
can use the same Thread pool as CF to provide the thread. It has the same
threading issues as CF but with less complexity in the interface.

An alternative without an argument would be onTerminate(Runnable 
runnable) and
it would generally be the case that the lambda would need to have a 
binding for the
reference to the Process/ProcessHandle.

Roger

On 2/13/2015 10:34 AM, Peter Levart wrote:
> On 02/13/2015 04:18 PM, David M. Lloyd wrote:
>> On 02/13/2015 09:15 AM, Peter Levart wrote:
>>> On 02/13/2015 03:22 PM, Paul Sandoz wrote:
>>>>> >It*is*  inconvenient for the user to have to use wildcards in 
>>>>> specifying types:
>>>>> >
>>>>> >CompletableFuture<? extends Process> cf = 
>>>>> process.completableFuture();
>>>>> >
>>>>> >...but it doesn't hinder the use of above 'cf' quite so much as 
>>>>> 'len' in List example above, since 'T' in CompletableFuture<T> is 
>>>>> used mostly in co-variant positions. The only methods that use it 
>>>>> in contra-variant positions are:
>>>>> >
>>>>> >cf.getNow(?);
>>>>> >cf.complete(?);
>>>>> >cf.obtrudeValue(?);
>>>>> >
>>>> What about the methods with a parameter type of:
>>>>
>>>>    CompletionStage<? extends T>
>>>>
>>>> such as applyToEither and acceptEither?
>>>>
>>>> Paul.
>>>
>>> Oh, I see.
>>>
>>> That's a problem, yes. And these two methods are actually very 
>>> useful in
>>> the context of processes - waiting for 1st of two processes to finish.
>>>
>>> So the signature can only be the following:
>>>
>>>      CompletableFuture<ProcessHandle> completableFuture();
>>
>> I hesitate to mention it, but as someone who has been frustrated by 
>> this same problem on numerous occasions I feel I must suggest that 
>> maybe... having a completableFuture method should just be dropped?  A 
>> user should be able to implement it themselves fairly easily, right?  
>> And they'd be able to sidestep problems like stack size and so on by 
>> managing their own threads.
>>
>
> That's a good idea. If the following two methods were added to 
> Process[Handle]:
>
>     public class ProcessHandle {
>         public ProcessHandle waitForUninterruptibly();
>     }
>
>     public class Process extends ProcessHandle {
>         @Override
>         public Process waitForUninterruptibly();
>     }
>
> One could get CompletableFuture(s) simply by:
>
>         ProcessHandle ph = ...;
>
>         CompletableFuture<ProcessHandle> phf = 
> CompletableFuture.supplyAsync(ph::waitForUninterruptibly);
>
>         Process p = ...;
>
>         CompletableFuture<Process> pf = 
> CompletableFuture.supplyAsync(p::waitForUninterruptibly);
>
>
> Peter



From brian.burkhalter at oracle.com  Tue Feb 17 19:17:18 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 17 Feb 2015 11:17:18 -0800
Subject: [9] RFR of 8073347: javadoc of Formattable messed up by
	JDK-8019857
In-Reply-To: <CA+kOe08sFjpYVoczNYEPVAuk3g5YsKDKEp9ND9P9k+6DwEtc6Q@mail.gmail.com>
References: <F2A311B8-7584-43AD-99B9-152FAB738841@oracle.com>
	<CA+kOe08sFjpYVoczNYEPVAuk3g5YsKDKEp9ND9P9k+6DwEtc6Q@mail.gmail.com>
Message-ID: <F8293C69-82D5-4F34-977E-BF37CD7F4BC3@oracle.com>


On Feb 17, 2015, at 11:09 AM, Martin Buchholz <martinrb at google.com> wrote:

> Thanks for the prompt response.

You?re welcome.

> I think there's now an unbalanced } in the javadoc.

I?ll look.

> Although this bug report was only about Formattable, I was hoping to fix all the scrunched-up @code's.
> (@code that extends over more than 2 lines should have a <pre> added, using the standard idiom. I've gone ahead and fixed jsr166.

I think it would be better to file a separate issue, perhaps an umbrella one with sub-tasks.

> I would unindent the code sample body itself 2 spaces left (but that's an independent code sample formatting issue).

Will post an update.

Thanks,

Brian

From vitalyd at gmail.com  Tue Feb 17 19:21:13 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 17 Feb 2015 14:21:13 -0500
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E39364.6030409@oracle.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>
	<54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com>
	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
	<54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com>
	<54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com>
	<54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com>
	<54E34EAF.6000802@redhat.com>
	<0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com>
	<54E38F4B.7060100@redhat.com> <54E39364.6030409@oracle.com>
Message-ID: <CAHjP37FWOaCk3Zt_XJYnUBn9_SKPWkKPuOyN2G3iLrUVJ+gFqw@mail.gmail.com>

IMO I don't think such barriers should be removed just because EA is able
to elide the heap allocation.

On Tue, Feb 17, 2015 at 2:15 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com
> wrote:

> There was discussion should we remove such barriers or not because they
> create memory operations ordering which could be different if we remove
> them.
>
> To eliminate them we need to add 'precedent' edge to store's membar as we
> do, for example, for loads:
>
>   if (field->is_volatile()) {
>     // Memory barrier includes bogus read of value to force load BEFORE
> membar
>     insert_mem_bar(Op_MemBarAcquire, ld);
>   }
>
> MemBarNode::Ideal() will do elimination.
>
> Regards,
> Vladimir
>
>
> On 2/17/15 10:58 AM, Andrew Haley wrote:
>
>> On 02/17/2015 06:42 PM, John Rose wrote:
>>
>>> The remaining store fence is probably a bug.  A store fence for
>>> scalarized (lifted-out-of-memory) final fields should go away, since the
>>> fields are not actually stored in heap memory.
>>>
>>
>> After inlining how would escape analysis know that the store fence is
>> associated with final fields rather than, say, an explicit
>> Unsafe.storeFence() ?
>>
>> Andrew.
>>
>>


From daniel.fuchs at oracle.com  Tue Feb 17 19:33:15 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 17 Feb 2015 20:33:15 +0100
Subject: RFR: 8072645: java.util.logging should use java.time to get more
	precise time stamps
In-Reply-To: <54E243DF.3060107@oracle.com>
References: <54DE109C.4030307@oracle.com>
	<CACzrW9BgsCVZvZKdd=+1rEao1V7bSg7N_QJD0BpJsaywJAj2-A@mail.gmail.com>
	<54DF47B9.4050304@oracle.com> <54E243DF.3060107@oracle.com>
Message-ID: <54E3977B.4060701@oracle.com>

Hi,

Here is a new webrev - which should contain all the feedback received
so far:

#1 LogRecord uses serialPersistentFields for serialization, and
    contains an Instant instead of the two fields millis +
    nanoAdjustment.
#2 getMillis/setMillis are deprecated, replaced by getInstant/setInstant
    getNanoAdjustment/setNanoAdjustment have been dropped.

[Thanks Peter for prototyping these 2 first changes!]

#3 XMLFormatter uses ISO_INSTANT to print the instant in the date field.
    new constructor has been dropped. printNanos property is renamed into
    useInstant.
#4 SimpleFormatter still uses ZonedDateTime - for compatibility and
    flexibility and because it proved to be faster than Date [1].
#5 Tests have been updated WRT to the changes above.
#6 various doc tweaks compared to last webrev

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

specdiff updated in place (unfortunately the serial form does
not show up):
http://cr.openjdk.java.net/~dfuchs/webrev_8072645/specdiff-logging-time/overview-summary.html

best regards,

-- daniel

[1] benchmarks related to formatting the date:
http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html


On 16/02/15 20:24, Daniel Fuchs wrote:
> Hi Stephen,
>
> Thanks again for your support and suggestions!
>
> On 14/02/15 14:03, Daniel Fuchs wrote:
>> If I'm not mistaken the previous SimpleFormatter used to use
>> java.util.Date
>> and printed the time in the local time zone. I have tried to keep this
>> behavior.
>> I'm not sure we would want to change it to print the time in the UTC
>> time zone
>> by default. A lot of developers use logging for debugging - and when
>> reading
>> debug messages on the console I usually prefer to see the time in my own
>> time zone.
>>
>> Would there be a more efficient way to keep the default formatting of
>> the time
>> in the SimpleFormatter?
>
> I spent part of the day reading the documentation & trying out the
> various TemporalAccessors and DateTimeFormatters...
>
> I have also done some microbenchmark measurements (jmh) WRT
> the performance  of formatting a date/time.
> Results can be seen here [1]:
> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html
>
> What it shows is that when using String.format (as the SimpleFormatter
> is specified to do), then using ZonedDateTime is actually an improvement
> over using Date.
>
> Now that I have read a bit more about LocalDateTime, ZonedDateTime,
> Date, and Instant, I do agree with you that for recording an event time,
> printing the Instant is the better alternative.
> However, since SimpleFormatter has always printed the local date,
> I would tend to want to keep it that way.
>
> So I'm going to propose to keep using ZonedDateTime in
> the SimpleFormatter, as I believe it's what gives it the maximum of
> flexibility - WRT to using String.format (+ we will get some
> boost as bonus by no longer using Date).
> If you strongly feel that java.util.logging should offer a better
> alternative - then maybe we should log an RFE to explore it?
>
> Things are - I believe - a bit different for the XMLFormatter.
> First, the XMLFormatter is not specified to use String.format, so
> it gives us a bit more flexibility.
> In addition we already need to tweak the format in order to introduce
> the new <nanos> element - (or should it be <nanoOfMilli> as Peter
> suggested?).
>
> So for the XMLFormatter, and given the results of my
> microbenchmark [1], here is what I would suggest:
>
> #1 rename the property printNanos into useInstant
> #2 if useInstant is false, use the old code for formatting the
>     date (the old appendISO8601() method) and omit the <nanos>
>     element - so applications that specify useInstant=false should
>     see the same formatting than before, without paying the
>     performance cost that using ZonedDateTime would bring.
> #3 if useInstant is absent - or not false, then we use the 'new'
>     format. The <date> element will contain the instant printed
>     using DateTimeFormatter.ISO_INSTANT, and the <nanos> element
>     will be printed after <millis>
>
> Does that sound right? If so I will include these changes in my
> next webrev, once I have digested the feedback sent by Peter :-)
>
> Best regards,
>
> -- daniel
>
> [1] microbenchmark:
> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html
>
>
>>
>>> (The webrev is broken wrt zones as it stores ZoneId.systemDefault() in a
>>> static constant, but that method depends on the mutable
>>> TimeZone.getDefault() ).
>>
>> Would making it a final (non static) variable be better?
>> I now wonder whether there should be a way to configure the time zone for
>> an instance of SimpleFormatter (something like what I did with
>> 'printNanos'
>> for the XMLFormatter).
>>
>>> LogReecord.getInstantUTC() should be getInstant().
>>>
>>> (An Instant is fully defined as a concept, and it cannot be in or not in
>>> UTC).
>>
>> Right. Thanks for pointing that out.
>>> In SimpleFormatter, you have {@code java.util.loggin} (missing a "g").
>>
>> Good catch.
>>
>>> In XMLFormatter, instead of using DateTimeFormatter.ISO_LOCAL_DATE_TIME,
>>> create a new instance of DateTimeFormatter that does not output the
>>> fraction of a second. That way, there is no need to use
>>> truncatedTo(SECONDS).
>>>
>>> StringBuilder appends can be used directly with formatters:
>>>
>>> sb.append(ZonedDateTime.ofInstant(time, zoneId).format(dtformatter));
>>>
>>> replace with
>>>
>>> dtformatter.formatTo(ZonedDateTime.ofInstant(time, zoneId), sb);
>>
>> Will look into this.
>>
>> Thanks again for your review! This is quite helpful.
>>
>> -- daniel
>>
>>
>>>
>>> thanks
>>> Stephen
>>>
>>>
>>>
>>> On 13 Feb 2015 14:57, "Daniel Fuchs" <daniel.fuchs at oracle.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Please find below a patch for:
>>>>
>>>> 8072645: java.util.logging should use java.time to get more
>>>>           precise time stamps
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/
>>>>
>>>> specdiff:
>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/
>>>> specdiff-logging-time/java/util/logging/package-summary.html
>>>>
>>>> Overview:
>>>> ---------
>>>>
>>>> The patch is made of the following pieces:
>>>>
>>>>   - LogRecord uses java.time.Clock's systemClock to get an
>>>>     Instant in the best available resolution.
>>>>
>>>>     The instant is split into a number of milliseconds (a long)
>>>>     and a nanosecond adjustment (an int).
>>>>     The number of milliseconds is the same than what would have
>>>>     been obtained by calling System.currentTimeMillis().
>>>>
>>>>   - LogRecord acquires a new serializable int nanoAdjustement field,
>>>>     which can be used together with the number of milliseconds
>>>>     to reconstruct the instant.
>>>>
>>>>   - SimpleFormatter is updated to pass a ZoneDateTime
>>>>     instance to String.format, instead of a Date.
>>>>
>>>>     The effect of that is that the format string can now
>>>>     be configure to print the full instant precision, if
>>>>     needed.
>>>>
>>>>   - XMLformatter will add a new <nanos> element after the
>>>>     <millis> element - if the value of the nanoAdjustment
>>>>     field is not 0.
>>>>
>>>>     The <date> string will also contain the nano second
>>>>     adjustment as well as the zone offset as formatted by
>>>>     DateTimeFormatter.ISO_OFFSET_DATE_TIME
>>>>
>>>> Compatibility considerations:
>>>> -----------------------------
>>>>
>>>> - The serial for of log record is backward/forward compatible.
>>>>    I added a test to verify that.
>>>>
>>>> - XMLFormatter has acquired a new configurable property
>>>>    '<FQCN>.printNanos' which allows to revert to the old
>>>>    XML format, should the new format cause issues in
>>>>    existing applications.
>>>>
>>>> - The logger.dtd will need to be updated, to support the
>>>>    new optional <nanos> element. And for this matter,
>>>>    should we update the logger.dtd or rather define a
>>>>    logger-v2.dtd?
>>>>    See planned modification:
>>>>
>>>> <http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-
>>>> dtd/logger.dtd.frames.html>
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>>
>>
>



From brian.burkhalter at oracle.com  Tue Feb 17 19:39:18 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 17 Feb 2015 11:39:18 -0800
Subject: [9] RFR of 8073347: javadoc of Formattable messed up by
	JDK-8019857
In-Reply-To: <F2A311B8-7584-43AD-99B9-152FAB738841@oracle.com>
References: <F2A311B8-7584-43AD-99B9-152FAB738841@oracle.com>
Message-ID: <0BA92869-047A-46D0-B521-30D5EA373069@oracle.com>


On Feb 17, 2015, at 10:52 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> Please review at your convenience.
> 
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8073347
> Patch:	http://cr.openjdk.java.net/~bpb/8073347/
> 
> Note the before and after versions of the HTML.

All right: round two. Patch above has updated content (webrev.01 and the HTML-after).

Thanks,

Brian

From martinrb at google.com  Tue Feb 17 19:59:08 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 17 Feb 2015 11:59:08 -0800
Subject: [9] RFR of 8073347: javadoc of Formattable messed up by
	JDK-8019857
In-Reply-To: <0BA92869-047A-46D0-B521-30D5EA373069@oracle.com>
References: <F2A311B8-7584-43AD-99B9-152FAB738841@oracle.com>
	<0BA92869-047A-46D0-B521-30D5EA373069@oracle.com>
Message-ID: <CA+kOe0_4J9_h5CMUAMoDvH4rh7KfJmkRxxTPZudZa14V30=6Kg@mail.gmail.com>

This change looks good - thanks.

On Tue, Feb 17, 2015 at 11:39 AM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

>
> On Feb 17, 2015, at 10:52 AM, Brian Burkhalter <
> brian.burkhalter at oracle.com> wrote:
>
> > Please review at your convenience.
> >
> > Issue:        https://bugs.openjdk.java.net/browse/JDK-8073347
> > Patch:        http://cr.openjdk.java.net/~bpb/8073347/
> >
> > Note the before and after versions of the HTML.
>
> All right: round two. Patch above has updated content (webrev.01 and the
> HTML-after).
>
> Thanks,
>
> Brian


From brian.burkhalter at oracle.com  Tue Feb 17 21:56:12 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 17 Feb 2015 13:56:12 -0800
Subject: {PING!} [9] RFR JDK-8068373: (prefs) FileSystemPreferences writes \0
	to XML storage, causing loss of all preferences 
References: <E0281603-FEA1-4B5A-9143-40E2D872D6F4@oracle.com>
Message-ID: <4E5D3F46-5578-41F5-AE12-6F38A32E2259@oracle.com>

http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031502.html

Begin forwarded message:

> From: Brian Burkhalter <brian.burkhalter at oracle.com>
> Subject: [9] RFR JDK-8068373: (prefs) FileSystemPreferences writes \0 to XML storage, causing loss of all preferences 
> Date: February 12, 2015 at 1:01:43 PM PST
> To: Core-Libs-Dev <core-libs-dev at openjdk.java.net>
> 
> Hello,
> 
> Based on previous discussions this thread which used to be an RFC is now an RFR. Thanks to Paul and Roger for comments.
> 
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8068373
> Patch:	http://cr.openjdk.java.net/~bpb/8068373/webrev.04/
> 
> Historical variants may be seen here: http://cr.openjdk.java.net/~bpb/8068373/
> 
> One problem (or not) with this approach is that old FileSystemPreferences caches which already contain U+0000 will still cause a failure on reading in Java 9+ but perhaps we do not care.
> 
> Thanks,
> 
> Brian



From Roger.Riggs at Oracle.com  Tue Feb 17 23:05:30 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 17 Feb 2015 18:05:30 -0500
Subject: {PING!} [9] RFR JDK-8068373: (prefs) FileSystemPreferences writes
	\0 to XML storage, causing loss of all preferences
In-Reply-To: <4E5D3F46-5578-41F5-AE12-6F38A32E2259@oracle.com>
References: <E0281603-FEA1-4B5A-9143-40E2D872D6F4@oracle.com>
	<4E5D3F46-5578-41F5-AE12-6F38A32E2259@oracle.com>
Message-ID: <54E3C93A.7080502@Oracle.com>

Hi Brian,

Makes sense to me;   simple, direct and easy to explain.

Roger

On 2/17/2015 4:56 PM, Brian Burkhalter wrote:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031502.html
>
> Begin forwarded message:
>
>> From: Brian Burkhalter <brian.burkhalter at oracle.com>
>> Subject: [9] RFR JDK-8068373: (prefs) FileSystemPreferences writes \0 to XML storage, causing loss of all preferences
>> Date: February 12, 2015 at 1:01:43 PM PST
>> To: Core-Libs-Dev <core-libs-dev at openjdk.java.net>
>>
>> Hello,
>>
>> Based on previous discussions this thread which used to be an RFC is now an RFR. Thanks to Paul and Roger for comments.
>>
>> Issue:	https://bugs.openjdk.java.net/browse/JDK-8068373
>> Patch:	http://cr.openjdk.java.net/~bpb/8068373/webrev.04/
>>
>> Historical variants may be seen here: http://cr.openjdk.java.net/~bpb/8068373/
>>
>> One problem (or not) with this approach is that old FileSystemPreferences caches which already contain U+0000 will still cause a failure on reading in Java 9+ but perhaps we do not care.
>>
>> Thanks,
>>
>> Brian



From forax at univ-mlv.fr  Tue Feb 17 23:54:15 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 18 Feb 2015 00:54:15 +0100
Subject: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
In-Reply-To: <364AD047-000F-4A98-951A-9D33937DFA1E@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>
	<364AD047-000F-4A98-951A-9D33937DFA1E@oracle.com>
Message-ID: <54E3D4A7.8080703@univ-mlv.fr>


On 02/17/2015 07:54 AM, John Rose wrote:
> On Feb 16, 2015, at 10:33 PM, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>> The first shot at fixing this bug was to filter out ACC_SYNTHETIC. The drawback was that the actual lambda method are marked ACC_SYNTHETIC, so that filtered too much.
> OTOH it seems odd to filter out the actual interface method.
>
> Ideally the back trace should show the name of the interface method and the implementation code of the lambda.
>
> This information is divided between the two frames in question.

The compiler can be changed to append the name of the interface method 
when generating the static method corresponding to the lambda but 
usually the name of the abstract method is not a useful information 
because a functional interface is more a function type than a real 
interface.

R?mi



From brian.burkhalter at oracle.com  Wed Feb 18 00:13:26 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 17 Feb 2015 16:13:26 -0800
Subject: {PING!} [9] RFR JDK-8068373: (prefs) FileSystemPreferences writes
	\0 to XML storage, causing loss of all preferences 
In-Reply-To: <54E3C93A.7080502@Oracle.com>
References: <E0281603-FEA1-4B5A-9143-40E2D872D6F4@oracle.com>
	<4E5D3F46-5578-41F5-AE12-6F38A32E2259@oracle.com>
	<54E3C93A.7080502@Oracle.com>
Message-ID: <E2B20887-B281-4645-BE54-7375FBD6BE0D@oracle.com>

Hi Roger,

Thanks. I?ll proceed with a CCC request then which I assume will be needed.

Brian

On Feb 17, 2015, at 3:05 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:

> Hi Brian,
> 
> Makes sense to me;   simple, direct and easy to explain.
> 
> Roger
> 
> On 2/17/2015 4:56 PM, Brian Burkhalter wrote:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031502.html



From maurizio.cimadamore at oracle.com  Wed Feb 18 00:17:34 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 18 Feb 2015 00:17:34 +0000
Subject: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
In-Reply-To: <54E3D4A7.8080703@univ-mlv.fr>
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>	<364AD047-000F-4A98-951A-9D33937DFA1E@oracle.com>
	<54E3D4A7.8080703@univ-mlv.fr>
Message-ID: <54E3DA1E.2010504@oracle.com>

I think this work (which is good) underlines a general there for some 
kind of pluggable logic for converting a synthetic method name into 
something more useful for the reader and/or to manipulate stack trace 
elements (i.e. remove elements, fold 2-3 elements into a new one, etc.). 
Lambda methods are special, but so are bridge methods, accessors etc. I 
bet there is a meaningful representation for some (all?) of those which 
is different from the blob of bytes generated by javac. For instance, an 
accessor could name the owner and name of the accessed symbol, a bridge 
could name the bridged call, and so forth. The manipulation on the stack 
trace should probably be optional (i.e. there should be flag to control 
it, in case one would like to use the full stack info i.e. for debugging 
purposes). Long story short, I think there's a bigger theme in here. 
Some of the work done by Charles Nutter in the JRuby land seems also 
relevant.

Maurizio

On 17/02/15 23:54, Remi Forax wrote:
>
> On 02/17/2015 07:54 AM, John Rose wrote:
>> On Feb 16, 2015, at 10:33 PM, Staffan Larsen 
>> <staffan.larsen at oracle.com> wrote:
>>> The first shot at fixing this bug was to filter out ACC_SYNTHETIC. 
>>> The drawback was that the actual lambda method are marked 
>>> ACC_SYNTHETIC, so that filtered too much.
>> OTOH it seems odd to filter out the actual interface method.
>>
>> Ideally the back trace should show the name of the interface method 
>> and the implementation code of the lambda.
>>
>> This information is divided between the two frames in question.
>
> The compiler can be changed to append the name of the interface method 
> when generating the static method corresponding to the lambda but 
> usually the name of the abstract method is not a useful information 
> because a functional interface is more a function type than a real 
> interface.
>
> R?mi
>



From Alan.Bateman at oracle.com  Wed Feb 18 08:47:46 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 18 Feb 2015 08:47:46 +0000
Subject: {PING!} [9] RFR JDK-8068373: (prefs) FileSystemPreferences writes
	\0 to XML storage, causing loss of all preferences
In-Reply-To: <4E5D3F46-5578-41F5-AE12-6F38A32E2259@oracle.com>
References: <E0281603-FEA1-4B5A-9143-40E2D872D6F4@oracle.com>
	<4E5D3F46-5578-41F5-AE12-6F38A32E2259@oracle.com>
Message-ID: <54E451B2.8050008@oracle.com>

On 17/02/2015 21:56, Brian Burkhalter wrote:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031502.html
>
>
It's good to see this changed to throw IAE. What about other methods 
that take a key (like get), do they need their javadoc updated too?

-Alan


From aph at redhat.com  Wed Feb 18 10:10:55 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 18 Feb 2015 10:10:55 +0000
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E462E1.5080009@redhat.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>	<54DE8BB7.5050801@oracle.com>	<54DE9140.3040604@oracle.com>	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>	<54E30C38.8000303@redhat.com>	<54E31144.3040504@redhat.com>	<54E314BF.3010205@redhat.com>	<54E31677.1050209@redhat.com>	<54E31CA6.6030609@redhat.com>	<54E31DA0.2040901@redhat.com>	<54E34EAF.6000802@redhat.com>	<0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com>	<54E38F4B.7060100@redhat.com>	<54E39364.6030409@oracle.com>	<CAHjP37FWOaCk3Zt_XJYnUBn9_SKPWkKPuOyN2G3iLrUVJ+gFqw@mail.gmail.com>
	<54E462E1.5080009@redhat.com>
Message-ID: <54E4652F.80600@redhat.com>

On 02/18/2015 10:01 AM, Andrew Dinn wrote:
> On 17/02/15 19:21, Vitaly Davidovich wrote:
>> IMO I don't think such barriers should be removed just because EA is able
>> to elide the heap allocation.
> 
> Why not? Are you assuming that the programmer might be relying on a
> memory barrier being implied in interpreted/JITted code by the presence
> in the source of an allocation? If so then I am not sure the Java memory
> model justifies that assumption, especially so in the case EA optimises.

It doesn't.

There are essentially two ways to prevent unsafe publication of
objects with final fields: either emit a barrier at the end of the
constructor or track the reference to the newly-constructed object
until it is stored in memory.  That store to memory can be a releasing
store.  If the object does not escape that releasing store can be
eliminated.

Andrew.


From scolebourne at joda.org  Wed Feb 18 11:11:26 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 18 Feb 2015 11:11:26 +0000
Subject: RFR: 8072645: java.util.logging should use java.time to get more
	precise time stamps
In-Reply-To: <54E3977B.4060701@oracle.com>
References: <54DE109C.4030307@oracle.com>
	<CACzrW9BgsCVZvZKdd=+1rEao1V7bSg7N_QJD0BpJsaywJAj2-A@mail.gmail.com>
	<54DF47B9.4050304@oracle.com> <54E243DF.3060107@oracle.com>
	<54E3977B.4060701@oracle.com>
Message-ID: <CACzrW9BGGELXh5ZJEc2VEA9VktzZP_4Njod1gWp5JB4dPe2K4Q@mail.gmail.com>

In LogRecord, the Javadoc of getInstant():
"Get event time."
could be
"Gets the instant that the event ocurred."

In LogRecord, the Javadoc of setInstant():
"Set event time."
could be
"Sets the instant that the event ocurred."
(matching change to @param)

I'd prefer to see the other methods in the class have their Javadoc
changed from "Get" to Gets" and from "Set" to "Sets" to conform with
Javadoc norms, but understand if this causes CCC issues.


In PlatformLogger.
There should be no need to assign to a static constant:
 private static final Clock systemUTC = Clock.systemUTC();
However, Clock.systemUTC() needs to be fixed:
https://bugs.openjdk.java.net/browse/JDK-8073394

This
 ZonedDateTime zdt = ZonedDateTime.ofInstant(systemUTC.instant(), zoneId);
can be replaced with
 ZonedDateTime zdt = ZonedDateTime.now(zoneId);
Again, the implementation of the better method isn't perfectly optimised.

The default format used in String.format does not need to time-zone,
just the local date/time. As such, in theory a LocalDateTime could be
used. But, since the format can be changed by the user, a
ZonedDateTime is needed (probably not worth being clever here).

Where you assign ZoneId.systemDefault() to a final instance variable,
it is being locked for the lifetime of that object. I cannot
immediately tell what the lifetime of the objects are. I also suspect
that few if any will want to change their time-zone half way through
logging.

XMLFormatter has a reviewer's comment that will need to be removed
before committing.

In LogRecordWithNanosAPI you check the instant contents rather than
just the instant:
 assertEquals(record.getInstant().getEpochSecond(),
record2.getInstant().getEpochSecond(),
"getInstant().getEpochSecond()");
 assertEquals(record.getInstant().getNano(),
record2.getInstant().getNano(), "getInstant().getNano()");
 assertEquals(record.getInstant().toEpochMilli(),
record2.getInstant().toEpochMilli(), "getInstant().toEpochMilli()");
could be
 assertEquals(record.getInstant(), record2.getInstant(), "getInstant()");
There are probably other instances of this point.

Hope that helps
Stephen



On 17 February 2015 at 19:33, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> Hi,
>
> Here is a new webrev - which should contain all the feedback received
> so far:
>
> #1 LogRecord uses serialPersistentFields for serialization, and
>    contains an Instant instead of the two fields millis +
>    nanoAdjustment.
> #2 getMillis/setMillis are deprecated, replaced by getInstant/setInstant
>    getNanoAdjustment/setNanoAdjustment have been dropped.
>
> [Thanks Peter for prototyping these 2 first changes!]
>
> #3 XMLFormatter uses ISO_INSTANT to print the instant in the date field.
>    new constructor has been dropped. printNanos property is renamed into
>    useInstant.
> #4 SimpleFormatter still uses ZonedDateTime - for compatibility and
>    flexibility and because it proved to be faster than Date [1].
> #5 Tests have been updated WRT to the changes above.
> #6 various doc tweaks compared to last webrev
>
> new webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.01/
>
> specdiff updated in place (unfortunately the serial form does
> not show up):
> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/specdiff-logging-time/overview-summary.html
>
> best regards,
>
> -- daniel
>
> [1] benchmarks related to formatting the date:
> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html
>
>
>
> On 16/02/15 20:24, Daniel Fuchs wrote:
>>
>> Hi Stephen,
>>
>> Thanks again for your support and suggestions!
>>
>> On 14/02/15 14:03, Daniel Fuchs wrote:
>>>
>>> If I'm not mistaken the previous SimpleFormatter used to use
>>> java.util.Date
>>> and printed the time in the local time zone. I have tried to keep this
>>> behavior.
>>> I'm not sure we would want to change it to print the time in the UTC
>>> time zone
>>> by default. A lot of developers use logging for debugging - and when
>>> reading
>>> debug messages on the console I usually prefer to see the time in my own
>>> time zone.
>>>
>>> Would there be a more efficient way to keep the default formatting of
>>> the time
>>> in the SimpleFormatter?
>>
>>
>> I spent part of the day reading the documentation & trying out the
>> various TemporalAccessors and DateTimeFormatters...
>>
>> I have also done some microbenchmark measurements (jmh) WRT
>> the performance  of formatting a date/time.
>> Results can be seen here [1]:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html
>>
>> What it shows is that when using String.format (as the SimpleFormatter
>> is specified to do), then using ZonedDateTime is actually an improvement
>> over using Date.
>>
>> Now that I have read a bit more about LocalDateTime, ZonedDateTime,
>> Date, and Instant, I do agree with you that for recording an event time,
>> printing the Instant is the better alternative.
>> However, since SimpleFormatter has always printed the local date,
>> I would tend to want to keep it that way.
>>
>> So I'm going to propose to keep using ZonedDateTime in
>> the SimpleFormatter, as I believe it's what gives it the maximum of
>> flexibility - WRT to using String.format (+ we will get some
>> boost as bonus by no longer using Date).
>> If you strongly feel that java.util.logging should offer a better
>> alternative - then maybe we should log an RFE to explore it?
>>
>> Things are - I believe - a bit different for the XMLFormatter.
>> First, the XMLFormatter is not specified to use String.format, so
>> it gives us a bit more flexibility.
>> In addition we already need to tweak the format in order to introduce
>> the new <nanos> element - (or should it be <nanoOfMilli> as Peter
>> suggested?).
>>
>> So for the XMLFormatter, and given the results of my
>> microbenchmark [1], here is what I would suggest:
>>
>> #1 rename the property printNanos into useInstant
>> #2 if useInstant is false, use the old code for formatting the
>>     date (the old appendISO8601() method) and omit the <nanos>
>>     element - so applications that specify useInstant=false should
>>     see the same formatting than before, without paying the
>>     performance cost that using ZonedDateTime would bring.
>> #3 if useInstant is absent - or not false, then we use the 'new'
>>     format. The <date> element will contain the instant printed
>>     using DateTimeFormatter.ISO_INSTANT, and the <nanos> element
>>     will be printed after <millis>
>>
>> Does that sound right? If so I will include these changes in my
>> next webrev, once I have digested the feedback sent by Peter :-)
>>
>> Best regards,
>>
>> -- daniel
>>
>> [1] microbenchmark:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html
>>
>>
>>>
>>>> (The webrev is broken wrt zones as it stores ZoneId.systemDefault() in a
>>>> static constant, but that method depends on the mutable
>>>> TimeZone.getDefault() ).
>>>
>>>
>>> Would making it a final (non static) variable be better?
>>> I now wonder whether there should be a way to configure the time zone for
>>> an instance of SimpleFormatter (something like what I did with
>>> 'printNanos'
>>> for the XMLFormatter).
>>>
>>>> LogReecord.getInstantUTC() should be getInstant().
>>>>
>>>> (An Instant is fully defined as a concept, and it cannot be in or not in
>>>> UTC).
>>>
>>>
>>> Right. Thanks for pointing that out.
>>>>
>>>> In SimpleFormatter, you have {@code java.util.loggin} (missing a "g").
>>>
>>>
>>> Good catch.
>>>
>>>> In XMLFormatter, instead of using DateTimeFormatter.ISO_LOCAL_DATE_TIME,
>>>> create a new instance of DateTimeFormatter that does not output the
>>>> fraction of a second. That way, there is no need to use
>>>> truncatedTo(SECONDS).
>>>>
>>>> StringBuilder appends can be used directly with formatters:
>>>>
>>>> sb.append(ZonedDateTime.ofInstant(time, zoneId).format(dtformatter));
>>>>
>>>> replace with
>>>>
>>>> dtformatter.formatTo(ZonedDateTime.ofInstant(time, zoneId), sb);
>>>
>>>
>>> Will look into this.
>>>
>>> Thanks again for your review! This is quite helpful.
>>>
>>> -- daniel
>>>
>>>
>>>>
>>>> thanks
>>>> Stephen
>>>>
>>>>
>>>>
>>>> On 13 Feb 2015 14:57, "Daniel Fuchs" <daniel.fuchs at oracle.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Please find below a patch for:
>>>>>
>>>>> 8072645: java.util.logging should use java.time to get more
>>>>>           precise time stamps
>>>>>
>>>>>
>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/
>>>>>
>>>>> specdiff:
>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/
>>>>> specdiff-logging-time/java/util/logging/package-summary.html
>>>>>
>>>>> Overview:
>>>>> ---------
>>>>>
>>>>> The patch is made of the following pieces:
>>>>>
>>>>>   - LogRecord uses java.time.Clock's systemClock to get an
>>>>>     Instant in the best available resolution.
>>>>>
>>>>>     The instant is split into a number of milliseconds (a long)
>>>>>     and a nanosecond adjustment (an int).
>>>>>     The number of milliseconds is the same than what would have
>>>>>     been obtained by calling System.currentTimeMillis().
>>>>>
>>>>>   - LogRecord acquires a new serializable int nanoAdjustement field,
>>>>>     which can be used together with the number of milliseconds
>>>>>     to reconstruct the instant.
>>>>>
>>>>>   - SimpleFormatter is updated to pass a ZoneDateTime
>>>>>     instance to String.format, instead of a Date.
>>>>>
>>>>>     The effect of that is that the format string can now
>>>>>     be configure to print the full instant precision, if
>>>>>     needed.
>>>>>
>>>>>   - XMLformatter will add a new <nanos> element after the
>>>>>     <millis> element - if the value of the nanoAdjustment
>>>>>     field is not 0.
>>>>>
>>>>>     The <date> string will also contain the nano second
>>>>>     adjustment as well as the zone offset as formatted by
>>>>>     DateTimeFormatter.ISO_OFFSET_DATE_TIME
>>>>>
>>>>> Compatibility considerations:
>>>>> -----------------------------
>>>>>
>>>>> - The serial for of log record is backward/forward compatible.
>>>>>    I added a test to verify that.
>>>>>
>>>>> - XMLFormatter has acquired a new configurable property
>>>>>    '<FQCN>.printNanos' which allows to revert to the old
>>>>>    XML format, should the new format cause issues in
>>>>>    existing applications.
>>>>>
>>>>> - The logger.dtd will need to be updated, to support the
>>>>>    new optional <nanos> element. And for this matter,
>>>>>    should we update the logger.dtd or rather define a
>>>>>    logger-v2.dtd?
>>>>>    See planned modification:
>>>>>
>>>>> <http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-
>>>>> dtd/logger.dtd.frames.html>
>>>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>>>
>>>
>>
>


From aph at redhat.com  Wed Feb 18 11:13:21 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 18 Feb 2015 11:13:21 +0000
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E45842.9030102@redhat.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>	<54DE8BB7.5050801@oracle.com>	<54DE9140.3040604@oracle.com>	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>	<54E30C38.8000303@redhat.com>
	<54E31144.3040504@redhat.com>	<54E314BF.3010205@redhat.com>
	<54E31677.1050209@redhat.com>	<54E31CA6.6030609@redhat.com>
	<54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com>
	<54E457E0.20408@redhat.com> <54E45842.9030102@redhat.com>
Message-ID: <54E473D1.8000506@redhat.com>

On 02/18/2015 09:15 AM, Andrew Haley wrote:
> On 18/02/15 09:14, Florian Weimer wrote:
>> Wow, looks nice.  What OpenJDK build did you use?  I want to see if this
>> happens on x86_64, too.
> 
> I'm working on JDK9.  You don't have this code yet.  I'll do an x86
> build.

  0x00007f2948acbf8c: mov    0xc(%rdx),%r10d    ;*synchronization entry
                                                ; - java.nio.HeapByteBuffer::<init>@-1 (line 84)
                                                ; - java.nio.ByteBuffer::wrap at 7 (line 373)
                                                ; - java.nio.ByteBuffer::wrap at 4 (line 396)
                                                ; - bytebuffertests.ByteBufferTests3::getLong at 1 (line 23)
                                                ; implicit exception: dispatches to 0x00007f2948acbff5
  ;; B2: #      B5 B3 <- B1  Freq: 0.999999

  ;; MEMBAR-release ! (empty encoding)

  0x00007f2948acbf90: test   %ecx,%ecx
  0x00007f2948acbf92: jl     0x00007f2948acbfb5  ;*iflt
                                                ; - java.nio.Buffer::checkIndex at 1 (line 545)
                                                ; - java.nio.HeapByteBuffer::getLong at 18 (line 465)
                                                ; - bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)

  ;; B3: #      B6 B4 <- B2  Freq: 0.999999

  0x00007f2948acbf94: mov    %r10d,%ebp
  0x00007f2948acbf97: sub    %ecx,%ebp          ;*isub
                                                ; - java.nio.Buffer::checkIndex at 10 (line 545)
                                                ; - java.nio.HeapByteBuffer::getLong at 18 (line 465)
                                                ; - bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)

  0x00007f2948acbf99: cmp    $0x8,%ebp
  0x00007f2948acbf9c: jl     0x00007f2948acbfd5  ;*if_icmple
                                                ; - java.nio.Buffer::checkIndex at 11 (line 545)
                                                ; - java.nio.HeapByteBuffer::getLong at 18 (line 465)
                                                ; - bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)

  ;; B4: #      N95 <- B3  Freq: 0.999998

  0x00007f2948acbf9e: movslq %ecx,%r10
  0x00007f2948acbfa1: mov    0x10(%rdx,%r10,1),%rax
  0x00007f2948acbfa6: bswap  %rax               ;*invokestatic reverseBytes
                                                ; - java.nio.Bits::swap at 1 (line 61)
                                                ; - java.nio.HeapByteBuffer::getLong at 41 (line 466)
                                                ; - bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)

So, just the same except that there is no explicit fence instruction
to remove.  It's a shame for AArch64 because that fence really kills
performance but it's bad for x86 too.  Even on machines that don't
emit fence instructions the fence still acts as a compiler barrier.

Andrew.


From mark.sheppard at oracle.com  Wed Feb 18 13:29:49 2015
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 18 Feb 2015 13:29:49 +0000
Subject: RFR: JDK-8051990 - Uninitialised memory in
	jdk/src/share/native/java/lang/fdlibm/src/k_standard.c
Message-ID: <54E493CD.6090905@oracle.com>

Hi
    please review the small change
http://cr.openjdk.java.net/~msheppar/8051990/webrev/

to address the parfait issue in
https://bugs.openjdk.java.net/browse/JDK-8051990

regards
Mark


From Alan.Bateman at oracle.com  Wed Feb 18 13:47:38 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 18 Feb 2015 13:47:38 +0000
Subject: RFR: JDK-8051990 - Uninitialised memory in
	jdk/src/share/native/java/lang/fdlibm/src/k_standard.c
In-Reply-To: <54E493CD.6090905@oracle.com>
References: <54E493CD.6090905@oracle.com>
Message-ID: <54E497FA.2010804@oracle.com>

On 18/02/2015 13:29, Mark Sheppard wrote:
> Hi
>    please review the small change
> http://cr.openjdk.java.net/~msheppar/8051990/webrev/
>
> to address the parfait issue in
> https://bugs.openjdk.java.net/browse/JDK-8051990
>
Is this a false positive or is there really something calling 
__kernel_standard with an invalid type? If there is then setting errno 
would be good.

The other thing that I wonder about is modifying fdlibm in OpenJDK, 
should fixes be sent upstream? I remember at one point there was a 
proposal to replace fdlibm with pure java code but I don't think this 
has bubbled up to the top of anyone's list yet.

-Alan.


From mark.sheppard at oracle.com  Wed Feb 18 14:05:23 2015
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 18 Feb 2015 14:05:23 +0000
Subject: RFR: JDK-8051990 - Uninitialised memory in
	jdk/src/share/native/java/lang/fdlibm/src/k_standard.c
In-Reply-To: <54E497FA.2010804@oracle.com>
References: <54E493CD.6090905@oracle.com> <54E497FA.2010804@oracle.com>
Message-ID: <54E49C23.4080803@oracle.com>


Hi Alan,

as I understand it,
it is a case that the switch statement doesn't have an explicit default 
case, and as such it is seen that there is the potential
for exc to return garbage as it is a local (stack) variable.
code exc.return is not explicitly initialized in that scenario

I have followed the comments 8011989 and set this to wnf

but the fix below seemed the correct thing to do  ... it is a coding 
style idiom
as to whether switch statements should have an explicit default case.

regards
Mark

On 18/02/2015 13:47, Alan Bateman wrote:
> On 18/02/2015 13:29, Mark Sheppard wrote:
>> Hi
>>    please review the small change
>> http://cr.openjdk.java.net/~msheppar/8051990/webrev/
>>
>> to address the parfait issue in
>> https://bugs.openjdk.java.net/browse/JDK-8051990
>>
> Is this a false positive or is there really something calling 
> __kernel_standard with an invalid type? If there is then setting errno 
> would be good.
>
> The other thing that I wonder about is modifying fdlibm in OpenJDK, 
> should fixes be sent upstream? I remember at one point there was a 
> proposal to replace fdlibm with pure java code but I don't think this 
> has bubbled up to the top of anyone's list yet.
>
> -Alan.



From vitalyd at gmail.com  Wed Feb 18 14:16:59 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Feb 2015 09:16:59 -0500
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E4652F.80600@redhat.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>
	<54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com>
	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
	<54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com>
	<54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com>
	<54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com>
	<54E34EAF.6000802@redhat.com>
	<0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com>
	<54E38F4B.7060100@redhat.com> <54E39364.6030409@oracle.com>
	<CAHjP37FWOaCk3Zt_XJYnUBn9_SKPWkKPuOyN2G3iLrUVJ+gFqw@mail.gmail.com>
	<54E462E1.5080009@redhat.com> <54E4652F.80600@redhat.com>
Message-ID: <CAHjP37FG8xHASLVjy3CTG5c+2m=h97+WFXXxHoeW9-bMTAr7Kg@mail.gmail.com>

I don't think explicit barriers (i.e. Unsafe.xxxFence) should be removed as
I don't think compiler can prove that it's safe to do so.  When value types
come to be and get scalarized, it may be possible to create cheap
synchronization types that are stack allocated yet are used for
synchronization control.  For example, C# has a SpinLock struct (
https://msdn.microsoft.com/en-us/library/system.threading.spinlock%28v=vs.110%29.aspx
).

Also, I don't think Unsafe induced fences are part of JMM, current or
future (at least I haven't heard that to be the case).

sent from my phone
On Feb 18, 2015 5:11 AM, "Andrew Haley" <aph at redhat.com> wrote:

> On 02/18/2015 10:01 AM, Andrew Dinn wrote:
> > On 17/02/15 19:21, Vitaly Davidovich wrote:
> >> IMO I don't think such barriers should be removed just because EA is
> able
> >> to elide the heap allocation.
> >
> > Why not? Are you assuming that the programmer might be relying on a
> > memory barrier being implied in interpreted/JITted code by the presence
> > in the source of an allocation? If so then I am not sure the Java memory
> > model justifies that assumption, especially so in the case EA optimises.
>
> It doesn't.
>
> There are essentially two ways to prevent unsafe publication of
> objects with final fields: either emit a barrier at the end of the
> constructor or track the reference to the newly-constructed object
> until it is stored in memory.  That store to memory can be a releasing
> store.  If the object does not escape that releasing store can be
> eliminated.
>
> Andrew.
>


From vitalyd at gmail.com  Wed Feb 18 14:27:21 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Feb 2015 09:27:21 -0500
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E473D1.8000506@redhat.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>
	<54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com>
	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
	<54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com>
	<54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com>
	<54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com>
	<54E34EAF.6000802@redhat.com> <54E457E0.20408@redhat.com>
	<54E45842.9030102@redhat.com> <54E473D1.8000506@redhat.com>
Message-ID: <CAHjP37F+MCjO27yNxRwAGFwhQJnt+oeg0pxgcmkeV7KqE=DYVQ@mail.gmail.com>

Indeed, that's quite nice and not what I saw in java 7 so good to see that
this case is EA'd out.  Does anyone know if there was EA work done in java
9 or is this simply inlining policy change that makes EA work (as John
alluded to)?

sent from my phone
On Feb 18, 2015 6:13 AM, "Andrew Haley" <aph at redhat.com> wrote:

> On 02/18/2015 09:15 AM, Andrew Haley wrote:
> > On 18/02/15 09:14, Florian Weimer wrote:
> >> Wow, looks nice.  What OpenJDK build did you use?  I want to see if this
> >> happens on x86_64, too.
> >
> > I'm working on JDK9.  You don't have this code yet.  I'll do an x86
> > build.
>
>   0x00007f2948acbf8c: mov    0xc(%rdx),%r10d    ;*synchronization entry
>                                                 ; -
> java.nio.HeapByteBuffer::<init>@-1 (line 84)
>                                                 ; -
> java.nio.ByteBuffer::wrap at 7 (line 373)
>                                                 ; -
> java.nio.ByteBuffer::wrap at 4 (line 396)
>                                                 ; -
> bytebuffertests.ByteBufferTests3::getLong at 1 (line 23)
>                                                 ; implicit exception:
> dispatches to 0x00007f2948acbff5
>   ;; B2: #      B5 B3 <- B1  Freq: 0.999999
>
>   ;; MEMBAR-release ! (empty encoding)
>
>   0x00007f2948acbf90: test   %ecx,%ecx
>   0x00007f2948acbf92: jl     0x00007f2948acbfb5  ;*iflt
>                                                 ; -
> java.nio.Buffer::checkIndex at 1 (line 545)
>                                                 ; -
> java.nio.HeapByteBuffer::getLong at 18 (line 465)
>                                                 ; -
> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)
>
>   ;; B3: #      B6 B4 <- B2  Freq: 0.999999
>
>   0x00007f2948acbf94: mov    %r10d,%ebp
>   0x00007f2948acbf97: sub    %ecx,%ebp          ;*isub
>                                                 ; -
> java.nio.Buffer::checkIndex at 10 (line 545)
>                                                 ; -
> java.nio.HeapByteBuffer::getLong at 18 (line 465)
>                                                 ; -
> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)
>
>   0x00007f2948acbf99: cmp    $0x8,%ebp
>   0x00007f2948acbf9c: jl     0x00007f2948acbfd5  ;*if_icmple
>                                                 ; -
> java.nio.Buffer::checkIndex at 11 (line 545)
>                                                 ; -
> java.nio.HeapByteBuffer::getLong at 18 (line 465)
>                                                 ; -
> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)
>
>   ;; B4: #      N95 <- B3  Freq: 0.999998
>
>   0x00007f2948acbf9e: movslq %ecx,%r10
>   0x00007f2948acbfa1: mov    0x10(%rdx,%r10,1),%rax
>   0x00007f2948acbfa6: bswap  %rax               ;*invokestatic reverseBytes
>                                                 ; - java.nio.Bits::swap at 1
> (line 61)
>                                                 ; -
> java.nio.HeapByteBuffer::getLong at 41 (line 466)
>                                                 ; -
> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)
>
> So, just the same except that there is no explicit fence instruction
> to remove.  It's a shame for AArch64 because that fence really kills
> performance but it's bad for x86 too.  Even on machines that don't
> emit fence instructions the fence still acts as a compiler barrier.
>
> Andrew.
>


From david.lloyd at redhat.com  Wed Feb 18 14:32:21 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 18 Feb 2015 08:32:21 -0600
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <CAHjP37FG8xHASLVjy3CTG5c+2m=h97+WFXXxHoeW9-bMTAr7Kg@mail.gmail.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>	<54DE8BB7.5050801@oracle.com>
	<54DE9140.3040604@oracle.com>	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>	<54E30C38.8000303@redhat.com>
	<54E31144.3040504@redhat.com>	<54E314BF.3010205@redhat.com>
	<54E31677.1050209@redhat.com>	<54E31CA6.6030609@redhat.com>
	<54E31DA0.2040901@redhat.com>	<54E34EAF.6000802@redhat.com>	<0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com>	<54E38F4B.7060100@redhat.com>
	<54E39364.6030409@oracle.com>	<CAHjP37FWOaCk3Zt_XJYnUBn9_SKPWkKPuOyN2G3iLrUVJ+gFqw@mail.gmail.com>	<54E462E1.5080009@redhat.com>
	<54E4652F.80600@redhat.com>
	<CAHjP37FG8xHASLVjy3CTG5c+2m=h97+WFXXxHoeW9-bMTAr7Kg@mail.gmail.com>
Message-ID: <54E4A275.9030206@redhat.com>

It's an awful lot of pain to avoid what IMO should be an obvious addition:

(Short|Character|Integer|Long).(get|put)(Little|Big)EndianBytes([value,] 
byte[] b, int offs)

This could (it seems to me) be easily intrinsified, is hugely useful 
both within and outside of the JDK, and fits perfectly well in the 
family of integral bit manipulations such as:

Integer.bitCount()
Integer.highestOneBit()
Integer.rotate*()
etc.

On 02/18/2015 08:16 AM, Vitaly Davidovich wrote:
> I don't think explicit barriers (i.e. Unsafe.xxxFence) should be removed as
> I don't think compiler can prove that it's safe to do so.  When value types
> come to be and get scalarized, it may be possible to create cheap
> synchronization types that are stack allocated yet are used for
> synchronization control.  For example, C# has a SpinLock struct (
> https://msdn.microsoft.com/en-us/library/system.threading.spinlock%28v=vs.110%29.aspx
> ).
>
> Also, I don't think Unsafe induced fences are part of JMM, current or
> future (at least I haven't heard that to be the case).
>
> sent from my phone
> On Feb 18, 2015 5:11 AM, "Andrew Haley" <aph at redhat.com> wrote:
>
>> On 02/18/2015 10:01 AM, Andrew Dinn wrote:
>>> On 17/02/15 19:21, Vitaly Davidovich wrote:
>>>> IMO I don't think such barriers should be removed just because EA is
>> able
>>>> to elide the heap allocation.
>>>
>>> Why not? Are you assuming that the programmer might be relying on a
>>> memory barrier being implied in interpreted/JITted code by the presence
>>> in the source of an allocation? If so then I am not sure the Java memory
>>> model justifies that assumption, especially so in the case EA optimises.
>>
>> It doesn't.
>>
>> There are essentially two ways to prevent unsafe publication of
>> objects with final fields: either emit a barrier at the end of the
>> constructor or track the reference to the newly-constructed object
>> until it is stored in memory.  That store to memory can be a releasing
>> store.  If the object does not escape that releasing store can be
>> eliminated.
>>
>> Andrew.
>>

-- 
- DML


From mark.sheppard at oracle.com  Wed Feb 18 14:44:54 2015
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 18 Feb 2015 14:44:54 +0000
Subject: RFR: JDK-8055204 - Memory leak in
	jdk/src/windows/native/java/lang/java_props_md.c
Message-ID: <54E4A566.603@oracle.com>

Hi
    please oblige and review the small change
http://cr.openjdk.java.net/~msheppar/8055204/webrev/

which addresses the parfait issue raised in
https://bugs.openjdk.java.net/browse/JDK-8055204

frees previously allocated memory in an error return path.

regards
Mark


From jason_mehrens at hotmail.com  Wed Feb 18 15:13:32 2015
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Wed, 18 Feb 2015 09:13:32 -0600
Subject: RFR: 8072645: java.util.logging should use java.time to get
	more precise time stamps
In-Reply-To: <54E3977B.4060701@oracle.com>
References: <54DE109C.4030307@oracle.com>,
	<CACzrW9BgsCVZvZKdd=+1rEao1V7bSg7N_QJD0BpJsaywJAj2-A@mail.gmail.com>,
	<54DF47B9.4050304@oracle.com>
	<54E243DF.3060107@oracle.com>,<54E3977B.4060701@oracle.com>
Message-ID: <BLU175-W24828E890725C61084D73C832C0@phx.gbl>

Daniel,


Was it determined if you were going to modify the existing logger.dtd or create a logger-v2.dtd?  If you are going to create a v2 then I think it might make sense to make dtd log manger property for the XMLFormatter instead of useInstant property.  So if you are using v2 then instant is enabled.  V3 would be instant enabled and foo enabled and so on.



Jason



----------------------------------------
> Date: Tue, 17 Feb 2015 20:33:15 +0100
> From: daniel.fuchs at oracle.com
> To: scolebourne at joda.org; core-libs-dev at openjdk.java.net; peter.levart at gmail.com
> Subject: Re: RFR: 8072645: java.util.logging should use java.time to get more precise time stamps
>
> Hi,
>
> Here is a new webrev - which should contain all the feedback received
> so far:
>
> #1 LogRecord uses serialPersistentFields for serialization, and
> contains an Instant instead of the two fields millis +
> nanoAdjustment.
> #2 getMillis/setMillis are deprecated, replaced by getInstant/setInstant
> getNanoAdjustment/setNanoAdjustment have been dropped.
>
> [Thanks Peter for prototyping these 2 first changes!]
>
> #3 XMLFormatter uses ISO_INSTANT to print the instant in the date field.
> new constructor has been dropped. printNanos property is renamed into
> useInstant.
> #4 SimpleFormatter still uses ZonedDateTime - for compatibility and
> flexibility and because it proved to be faster than Date [1].
> #5 Tests have been updated WRT to the changes above.
> #6 various doc tweaks compared to last webrev
>
> new webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.01/
>
> specdiff updated in place (unfortunately the serial form does
> not show up):
> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/specdiff-logging-time/overview-summary.html
>
> best regards,
>
> -- daniel
>
> [1] benchmarks related to formatting the date:
> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html
>
>
> On 16/02/15 20:24, Daniel Fuchs wrote:
>> Hi Stephen,
>>
>> Thanks again for your support and suggestions!
>>
>> On 14/02/15 14:03, Daniel Fuchs wrote:
>>> If I'm not mistaken the previous SimpleFormatter used to use
>>> java.util.Date
>>> and printed the time in the local time zone. I have tried to keep this
>>> behavior.
>>> I'm not sure we would want to change it to print the time in the UTC
>>> time zone
>>> by default. A lot of developers use logging for debugging - and when
>>> reading
>>> debug messages on the console I usually prefer to see the time in my own
>>> time zone.
>>>
>>> Would there be a more efficient way to keep the default formatting of
>>> the time
>>> in the SimpleFormatter?
>>
>> I spent part of the day reading the documentation & trying out the
>> various TemporalAccessors and DateTimeFormatters...
>>
>> I have also done some microbenchmark measurements (jmh) WRT
>> the performance of formatting a date/time.
>> Results can be seen here [1]:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html
>>
>> What it shows is that when using String.format (as the SimpleFormatter
>> is specified to do), then using ZonedDateTime is actually an improvement
>> over using Date.
>>
>> Now that I have read a bit more about LocalDateTime, ZonedDateTime,
>> Date, and Instant, I do agree with you that for recording an event time,
>> printing the Instant is the better alternative.
>> However, since SimpleFormatter has always printed the local date,
>> I would tend to want to keep it that way.
>>
>> So I'm going to propose to keep using ZonedDateTime in
>> the SimpleFormatter, as I believe it's what gives it the maximum of
>> flexibility - WRT to using String.format (+ we will get some
>> boost as bonus by no longer using Date).
>> If you strongly feel that java.util.logging should offer a better
>> alternative - then maybe we should log an RFE to explore it?
>>
>> Things are - I believe - a bit different for the XMLFormatter.
>> First, the XMLFormatter is not specified to use String.format, so
>> it gives us a bit more flexibility.
>> In addition we already need to tweak the format in order to introduce
>> the new <nanos> element - (or should it be <nanoOfMilli> as Peter
>> suggested?).
>>
>> So for the XMLFormatter, and given the results of my
>> microbenchmark [1], here is what I would suggest:
>>
>> #1 rename the property printNanos into useInstant
>> #2 if useInstant is false, use the old code for formatting the
>> date (the old appendISO8601() method) and omit the <nanos>
>> element - so applications that specify useInstant=false should
>> see the same formatting than before, without paying the
>> performance cost that using ZonedDateTime would bring.
>> #3 if useInstant is absent - or not false, then we use the 'new'
>> format. The <date> element will contain the instant printed
>> using DateTimeFormatter.ISO_INSTANT, and the <nanos> element
>> will be printed after <millis>
>>
>> Does that sound right? If so I will include these changes in my
>> next webrev, once I have digested the feedback sent by Peter :-)
>>
>> Best regards,
>>
>> -- daniel
>>
>> [1] microbenchmark:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html
>>
>>
>>>
>>>> (The webrev is broken wrt zones as it stores ZoneId.systemDefault() in a
>>>> static constant, but that method depends on the mutable
>>>> TimeZone.getDefault() ).
>>>
>>> Would making it a final (non static) variable be better?
>>> I now wonder whether there should be a way to configure the time zone for
>>> an instance of SimpleFormatter (something like what I did with
>>> 'printNanos'
>>> for the XMLFormatter).
>>>
>>>> LogReecord.getInstantUTC() should be getInstant().
>>>>
>>>> (An Instant is fully defined as a concept, and it cannot be in or not in
>>>> UTC).
>>>
>>> Right. Thanks for pointing that out.
>>>> In SimpleFormatter, you have {@code java.util.loggin} (missing a "g").
>>>
>>> Good catch.
>>>
>>>> In XMLFormatter, instead of using DateTimeFormatter.ISO_LOCAL_DATE_TIME,
>>>> create a new instance of DateTimeFormatter that does not output the
>>>> fraction of a second. That way, there is no need to use
>>>> truncatedTo(SECONDS).
>>>>
>>>> StringBuilder appends can be used directly with formatters:
>>>>
>>>> sb.append(ZonedDateTime.ofInstant(time, zoneId).format(dtformatter));
>>>>
>>>> replace with
>>>>
>>>> dtformatter.formatTo(ZonedDateTime.ofInstant(time, zoneId), sb);
>>>
>>> Will look into this.
>>>
>>> Thanks again for your review! This is quite helpful.
>>>
>>> -- daniel
>>>
>>>
>>>>
>>>> thanks
>>>> Stephen
>>>>
>>>>
>>>>
>>>> On 13 Feb 2015 14:57, "Daniel Fuchs" <daniel.fuchs at oracle.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Please find below a patch for:
>>>>>
>>>>> 8072645: java.util.logging should use java.time to get more
>>>>> precise time stamps
>>>>>
>>>>>
>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/
>>>>>
>>>>> specdiff:
>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/
>>>>> specdiff-logging-time/java/util/logging/package-summary.html
>>>>>
>>>>> Overview:
>>>>> ---------
>>>>>
>>>>> The patch is made of the following pieces:
>>>>>
>>>>> - LogRecord uses java.time.Clock's systemClock to get an
>>>>> Instant in the best available resolution.
>>>>>
>>>>> The instant is split into a number of milliseconds (a long)
>>>>> and a nanosecond adjustment (an int).
>>>>> The number of milliseconds is the same than what would have
>>>>> been obtained by calling System.currentTimeMillis().
>>>>>
>>>>> - LogRecord acquires a new serializable int nanoAdjustement field,
>>>>> which can be used together with the number of milliseconds
>>>>> to reconstruct the instant.
>>>>>
>>>>> - SimpleFormatter is updated to pass a ZoneDateTime
>>>>> instance to String.format, instead of a Date.
>>>>>
>>>>> The effect of that is that the format string can now
>>>>> be configure to print the full instant precision, if
>>>>> needed.
>>>>>
>>>>> - XMLformatter will add a new <nanos> element after the
>>>>> <millis> element - if the value of the nanoAdjustment
>>>>> field is not 0.
>>>>>
>>>>> The <date> string will also contain the nano second
>>>>> adjustment as well as the zone offset as formatted by
>>>>> DateTimeFormatter.ISO_OFFSET_DATE_TIME
>>>>>
>>>>> Compatibility considerations:
>>>>> -----------------------------
>>>>>
>>>>> - The serial for of log record is backward/forward compatible.
>>>>> I added a test to verify that.
>>>>>
>>>>> - XMLFormatter has acquired a new configurable property
>>>>> '<FQCN>.printNanos' which allows to revert to the old
>>>>> XML format, should the new format cause issues in
>>>>> existing applications.
>>>>>
>>>>> - The logger.dtd will need to be updated, to support the
>>>>> new optional <nanos> element. And for this matter,
>>>>> should we update the logger.dtd or rather define a
>>>>> logger-v2.dtd?
>>>>> See planned modification:
>>>>>
>>>>> <http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-
>>>>> dtd/logger.dtd.frames.html>
>>>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>>>
>>>
>>
> 		 	   		  

From daniel.fuchs at oracle.com  Wed Feb 18 15:20:51 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 18 Feb 2015 16:20:51 +0100
Subject: RFR: 8072645: java.util.logging should use java.time to get more
	precise time stamps
In-Reply-To: <BLU175-W24828E890725C61084D73C832C0@phx.gbl>
References: <54DE109C.4030307@oracle.com>,
	<CACzrW9BgsCVZvZKdd=+1rEao1V7bSg7N_QJD0BpJsaywJAj2-A@mail.gmail.com>,
	<54DF47B9.4050304@oracle.com> <54E243DF.3060107@oracle.com>,
	<54E3977B.4060701@oracle.com>
	<BLU175-W24828E890725C61084D73C832C0@phx.gbl>
Message-ID: <54E4ADD3.6050301@oracle.com>

Hi Jason,

On 18/02/15 16:13, Jason Mehrens wrote:
> Daniel,
>
>
> Was it determined if you were going to modify the existing logger.dtd or create a logger-v2.dtd?  If you are going to create a v2 then I think it might make sense to make dtd log manger property for the XMLFormatter instead of useInstant property.  So if you are using v2 then instant is enabled.  V3 would be instant enabled and foo enabled and so on.

I was hopping to hear from reviewers about this point.
My current plan was to update the existing logger.dtd unless I
heard otherwise.
I am not sure of what is the best strategy.

best regards,

-- daniel

>
>
>
> Jason
>
>
>
> ----------------------------------------
>> Date: Tue, 17 Feb 2015 20:33:15 +0100
>> From: daniel.fuchs at oracle.com
>> To: scolebourne at joda.org; core-libs-dev at openjdk.java.net; peter.levart at gmail.com
>> Subject: Re: RFR: 8072645: java.util.logging should use java.time to get more precise time stamps
>>
>> Hi,
>>
>> Here is a new webrev - which should contain all the feedback received
>> so far:
>>
>> #1 LogRecord uses serialPersistentFields for serialization, and
>> contains an Instant instead of the two fields millis +
>> nanoAdjustment.
>> #2 getMillis/setMillis are deprecated, replaced by getInstant/setInstant
>> getNanoAdjustment/setNanoAdjustment have been dropped.
>>
>> [Thanks Peter for prototyping these 2 first changes!]
>>
>> #3 XMLFormatter uses ISO_INSTANT to print the instant in the date field.
>> new constructor has been dropped. printNanos property is renamed into
>> useInstant.
>> #4 SimpleFormatter still uses ZonedDateTime - for compatibility and
>> flexibility and because it proved to be faster than Date [1].
>> #5 Tests have been updated WRT to the changes above.
>> #6 various doc tweaks compared to last webrev
>>
>> new webrev:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.01/
>>
>> specdiff updated in place (unfortunately the serial form does
>> not show up):
>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/specdiff-logging-time/overview-summary.html
>>
>> best regards,
>>
>> -- daniel
>>
>> [1] benchmarks related to formatting the date:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html
>>
>>
>> On 16/02/15 20:24, Daniel Fuchs wrote:
>>> Hi Stephen,
>>>
>>> Thanks again for your support and suggestions!
>>>
>>> On 14/02/15 14:03, Daniel Fuchs wrote:
>>>> If I'm not mistaken the previous SimpleFormatter used to use
>>>> java.util.Date
>>>> and printed the time in the local time zone. I have tried to keep this
>>>> behavior.
>>>> I'm not sure we would want to change it to print the time in the UTC
>>>> time zone
>>>> by default. A lot of developers use logging for debugging - and when
>>>> reading
>>>> debug messages on the console I usually prefer to see the time in my own
>>>> time zone.
>>>>
>>>> Would there be a more efficient way to keep the default formatting of
>>>> the time
>>>> in the SimpleFormatter?
>>>
>>> I spent part of the day reading the documentation & trying out the
>>> various TemporalAccessors and DateTimeFormatters...
>>>
>>> I have also done some microbenchmark measurements (jmh) WRT
>>> the performance of formatting a date/time.
>>> Results can be seen here [1]:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html
>>>
>>> What it shows is that when using String.format (as the SimpleFormatter
>>> is specified to do), then using ZonedDateTime is actually an improvement
>>> over using Date.
>>>
>>> Now that I have read a bit more about LocalDateTime, ZonedDateTime,
>>> Date, and Instant, I do agree with you that for recording an event time,
>>> printing the Instant is the better alternative.
>>> However, since SimpleFormatter has always printed the local date,
>>> I would tend to want to keep it that way.
>>>
>>> So I'm going to propose to keep using ZonedDateTime in
>>> the SimpleFormatter, as I believe it's what gives it the maximum of
>>> flexibility - WRT to using String.format (+ we will get some
>>> boost as bonus by no longer using Date).
>>> If you strongly feel that java.util.logging should offer a better
>>> alternative - then maybe we should log an RFE to explore it?
>>>
>>> Things are - I believe - a bit different for the XMLFormatter.
>>> First, the XMLFormatter is not specified to use String.format, so
>>> it gives us a bit more flexibility.
>>> In addition we already need to tweak the format in order to introduce
>>> the new <nanos> element - (or should it be <nanoOfMilli> as Peter
>>> suggested?).
>>>
>>> So for the XMLFormatter, and given the results of my
>>> microbenchmark [1], here is what I would suggest:
>>>
>>> #1 rename the property printNanos into useInstant
>>> #2 if useInstant is false, use the old code for formatting the
>>> date (the old appendISO8601() method) and omit the <nanos>
>>> element - so applications that specify useInstant=false should
>>> see the same formatting than before, without paying the
>>> performance cost that using ZonedDateTime would bring.
>>> #3 if useInstant is absent - or not false, then we use the 'new'
>>> format. The <date> element will contain the instant printed
>>> using DateTimeFormatter.ISO_INSTANT, and the <nanos> element
>>> will be printed after <millis>
>>>
>>> Does that sound right? If so I will include these changes in my
>>> next webrev, once I have digested the feedback sent by Peter :-)
>>>
>>> Best regards,
>>>
>>> -- daniel
>>>
>>> [1] microbenchmark:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html
>>>
>>>
>>>>
>>>>> (The webrev is broken wrt zones as it stores ZoneId.systemDefault() in a
>>>>> static constant, but that method depends on the mutable
>>>>> TimeZone.getDefault() ).
>>>>
>>>> Would making it a final (non static) variable be better?
>>>> I now wonder whether there should be a way to configure the time zone for
>>>> an instance of SimpleFormatter (something like what I did with
>>>> 'printNanos'
>>>> for the XMLFormatter).
>>>>
>>>>> LogReecord.getInstantUTC() should be getInstant().
>>>>>
>>>>> (An Instant is fully defined as a concept, and it cannot be in or not in
>>>>> UTC).
>>>>
>>>> Right. Thanks for pointing that out.
>>>>> In SimpleFormatter, you have {@code java.util.loggin} (missing a "g").
>>>>
>>>> Good catch.
>>>>
>>>>> In XMLFormatter, instead of using DateTimeFormatter.ISO_LOCAL_DATE_TIME,
>>>>> create a new instance of DateTimeFormatter that does not output the
>>>>> fraction of a second. That way, there is no need to use
>>>>> truncatedTo(SECONDS).
>>>>>
>>>>> StringBuilder appends can be used directly with formatters:
>>>>>
>>>>> sb.append(ZonedDateTime.ofInstant(time, zoneId).format(dtformatter));
>>>>>
>>>>> replace with
>>>>>
>>>>> dtformatter.formatTo(ZonedDateTime.ofInstant(time, zoneId), sb);
>>>>
>>>> Will look into this.
>>>>
>>>> Thanks again for your review! This is quite helpful.
>>>>
>>>> -- daniel
>>>>
>>>>
>>>>>
>>>>> thanks
>>>>> Stephen
>>>>>
>>>>>
>>>>>
>>>>> On 13 Feb 2015 14:57, "Daniel Fuchs" <daniel.fuchs at oracle.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Please find below a patch for:
>>>>>>
>>>>>> 8072645: java.util.logging should use java.time to get more
>>>>>> precise time stamps
>>>>>>
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/
>>>>>>
>>>>>> specdiff:
>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/
>>>>>> specdiff-logging-time/java/util/logging/package-summary.html
>>>>>>
>>>>>> Overview:
>>>>>> ---------
>>>>>>
>>>>>> The patch is made of the following pieces:
>>>>>>
>>>>>> - LogRecord uses java.time.Clock's systemClock to get an
>>>>>> Instant in the best available resolution.
>>>>>>
>>>>>> The instant is split into a number of milliseconds (a long)
>>>>>> and a nanosecond adjustment (an int).
>>>>>> The number of milliseconds is the same than what would have
>>>>>> been obtained by calling System.currentTimeMillis().
>>>>>>
>>>>>> - LogRecord acquires a new serializable int nanoAdjustement field,
>>>>>> which can be used together with the number of milliseconds
>>>>>> to reconstruct the instant.
>>>>>>
>>>>>> - SimpleFormatter is updated to pass a ZoneDateTime
>>>>>> instance to String.format, instead of a Date.
>>>>>>
>>>>>> The effect of that is that the format string can now
>>>>>> be configure to print the full instant precision, if
>>>>>> needed.
>>>>>>
>>>>>> - XMLformatter will add a new <nanos> element after the
>>>>>> <millis> element - if the value of the nanoAdjustment
>>>>>> field is not 0.
>>>>>>
>>>>>> The <date> string will also contain the nano second
>>>>>> adjustment as well as the zone offset as formatted by
>>>>>> DateTimeFormatter.ISO_OFFSET_DATE_TIME
>>>>>>
>>>>>> Compatibility considerations:
>>>>>> -----------------------------
>>>>>>
>>>>>> - The serial for of log record is backward/forward compatible.
>>>>>> I added a test to verify that.
>>>>>>
>>>>>> - XMLFormatter has acquired a new configurable property
>>>>>> '<FQCN>.printNanos' which allows to revert to the old
>>>>>> XML format, should the new format cause issues in
>>>>>> existing applications.
>>>>>>
>>>>>> - The logger.dtd will need to be updated, to support the
>>>>>> new optional <nanos> element. And for this matter,
>>>>>> should we update the logger.dtd or rather define a
>>>>>> logger-v2.dtd?
>>>>>> See planned modification:
>>>>>>
>>>>>> <http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-
>>>>>> dtd/logger.dtd.frames.html>
>>>>>>
>>>>>> best regards,
>>>>>>
>>>>>> -- daniel
>>>>>>
>>>>
>>>
>> 		 	   		



From aph at redhat.com  Wed Feb 18 15:26:00 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 18 Feb 2015 15:26:00 +0000
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <CAHjP37FG8xHASLVjy3CTG5c+2m=h97+WFXXxHoeW9-bMTAr7Kg@mail.gmail.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>	<54DE8BB7.5050801@oracle.com>	<54DE9140.3040604@oracle.com>	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>	<54E30C38.8000303@redhat.com>	<54E31144.3040504@redhat.com>	<54E314BF.3010205@redhat.com>	<54E31677.1050209@redhat.com>	<54E31CA6.6030609@redhat.com>	<54E31DA0.2040901@redhat.com>	<54E34EAF.6000802@redhat.com>	<0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com>	<54E38F4B.7060100@redhat.com>	<54E39364.6030409@oracle.com>	<CAHjP37FWOaCk3Zt_XJYnUBn9_SKPWkKPuOyN2G3iLrUVJ+gFqw@mail.gmail.com>	<54E462E1.5080009@redhat.com>	<54E4652F.80600@redhat.com>
	<CAHjP37FG8xHASLVjy3CTG5c+2m=h97+WFXXxHoeW9-bMTAr7Kg@mail.gmail.com>
Message-ID: <54E4AF08.5030100@redhat.com>

On 02/18/2015 02:16 PM, Vitaly Davidovich wrote:
> I don't think explicit barriers (i.e. Unsafe.xxxFence) should be removed as
> I don't think compiler can prove that it's safe to do so.

Nobody thinks that explicit barriers (i.e. Unsafe.xxxFence) should be
removed.

We're talking about fences at the end of constructors which have final
fields.  These should be removed if the object does not escape.

Andrew.



From brian.burkhalter at oracle.com  Wed Feb 18 15:27:01 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 18 Feb 2015 07:27:01 -0800
Subject: {PING!} [9] RFR JDK-8068373: (prefs) FileSystemPreferences writes
	\0 to XML storage, causing loss of all preferences 
In-Reply-To: <54E451B2.8050008@oracle.com>
References: <E0281603-FEA1-4B5A-9143-40E2D872D6F4@oracle.com>
	<4E5D3F46-5578-41F5-AE12-6F38A32E2259@oracle.com>
	<54E451B2.8050008@oracle.com>
Message-ID: <F3199BF0-BBBA-4FA2-863F-B1AD7FDFBBC6@oracle.com>


On Feb 18, 2015, at 12:47 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 17/02/2015 21:56, Brian Burkhalter wrote:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031502.html
>> 
>> 
> It's good to see this changed to throw IAE. What about other methods that take a key (like get), do they need their javadoc updated too?

That?s a good point. I?ll take a look while the push of this change is pending the outcome of the CCC request I submitted.

Thanks,

Brian

From vitalyd at gmail.com  Wed Feb 18 15:32:40 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Feb 2015 10:32:40 -0500
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E4AF08.5030100@redhat.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>
	<54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com>
	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
	<54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com>
	<54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com>
	<54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com>
	<54E34EAF.6000802@redhat.com>
	<0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com>
	<54E38F4B.7060100@redhat.com> <54E39364.6030409@oracle.com>
	<CAHjP37FWOaCk3Zt_XJYnUBn9_SKPWkKPuOyN2G3iLrUVJ+gFqw@mail.gmail.com>
	<54E462E1.5080009@redhat.com> <54E4652F.80600@redhat.com>
	<CAHjP37FG8xHASLVjy3CTG5c+2m=h97+WFXXxHoeW9-bMTAr7Kg@mail.gmail.com>
	<54E4AF08.5030100@redhat.com>
Message-ID: <CAHjP37GXsLye05eTKkh8BTWG3+4ek1pEEFebe8YqyBSFOkuq7Q@mail.gmail.com>

Ok, perhaps I misunderstood then since you mentioned Unsafe.storeFence() in
your earlier post and Vladimir said they were debating whether these fences
should be removed.  If you guys were talking only about the final field
fence, then my bad, I don't disagree with removing those if the object
doesn't escape.

On Wed, Feb 18, 2015 at 10:26 AM, Andrew Haley <aph at redhat.com> wrote:

> On 02/18/2015 02:16 PM, Vitaly Davidovich wrote:
> > I don't think explicit barriers (i.e. Unsafe.xxxFence) should be removed
> as
> > I don't think compiler can prove that it's safe to do so.
>
> Nobody thinks that explicit barriers (i.e. Unsafe.xxxFence) should be
> removed.
>
> We're talking about fences at the end of constructors which have final
> fields.  These should be removed if the object does not escape.
>
> Andrew.
>
>


From aph at redhat.com  Wed Feb 18 16:00:05 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 18 Feb 2015 16:00:05 +0000
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E4A275.9030206@redhat.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>	<54DE8BB7.5050801@oracle.com>	<54DE9140.3040604@oracle.com>	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>	<54E30C38.8000303@redhat.com>	<54E31144.3040504@redhat.com>	<54E314BF.3010205@redhat.com>	<54E31677.1050209@redhat.com>	<54E31CA6.6030609@redhat.com>	<54E31DA0.2040901@redhat.com>	<54E34EAF.6000802@redhat.com>	<0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com>	<54E38F4B.7060100@redhat.com>	<54E39364.6030409@oracle.com>	<CAHjP37FWOaCk3Zt_XJYnUBn9_SKPWkKPuOyN2G3iLrUVJ+gFqw@mail.gmail.com>	<54E462E1.5080009@redhat.com>	<54E4652F.80600@redhat.com>	<CAHjP37FG8xHASLVjy3CTG5c+2m=h97+WFXXxHoeW9-bMTAr7Kg@mail.gmail.com>
	<54E4A275.9030206@redhat.com>
Message-ID: <54E4B705.1030104@redhat.com>

On 02/18/2015 02:32 PM, David M. Lloyd wrote:
> It's an awful lot of pain to avoid what IMO should be an obvious addition:
> 
> (Short|Character|Integer|Long).(get|put)(Little|Big)EndianBytes([value,] 
> byte[] b, int offs)
> 
> This could (it seems to me) be easily intrinsified, is hugely useful 
> both within and outside of the JDK,

Sure, I get that, but it's a new API.  Once I've finished this work,
implementing such an API would be trivial.  I have no objection to it
in principle, but making ByteBuffer.map() operations work well is
worth doing too.

Andrew.


From Roger.Riggs at Oracle.com  Wed Feb 18 16:00:52 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 18 Feb 2015 11:00:52 -0500
Subject: RFR: JDK-8055204 - Memory leak in
	jdk/src/windows/native/java/lang/java_props_md.c
In-Reply-To: <54E4A566.603@oracle.com>
References: <54E4A566.603@oracle.com>
Message-ID: <54E4B734.2070206@Oracle.com>

Hi Mark,

Looks fine as is.

The malloc could also be moved inside the if (SetupI18nProps...
but that's a bigger change.

Roger


On 2/18/2015 9:44 AM, Mark Sheppard wrote:
> Hi
>    please oblige and review the small change
> http://cr.openjdk.java.net/~msheppar/8055204/webrev/
>
> which addresses the parfait issue raised in
> https://bugs.openjdk.java.net/browse/JDK-8055204
>
> frees previously allocated memory in an error return path.
>
> regards
> Mark



From ivan.st.ivanov at gmail.com  Wed Feb 18 20:17:49 2015
From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov)
Date: Wed, 18 Feb 2015 22:17:49 +0200
Subject: JAXP repo warnings fixed
Message-ID: <CACYLA9HOwJruWEq2w2w6NsACCF1MkU0MSUUwVp5JAWJUz4S1fg@mail.gmail.com>

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/

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/

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 vladimir.kozlov at oracle.com  Wed Feb 18 20:59:49 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 18 Feb 2015 12:59:49 -0800
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <CAHjP37F+MCjO27yNxRwAGFwhQJnt+oeg0pxgcmkeV7KqE=DYVQ@mail.gmail.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>	<54DE8BB7.5050801@oracle.com>
	<54DE9140.3040604@oracle.com>	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>	<54E30C38.8000303@redhat.com>
	<54E31144.3040504@redhat.com>	<54E314BF.3010205@redhat.com>
	<54E31677.1050209@redhat.com>	<54E31CA6.6030609@redhat.com>
	<54E31DA0.2040901@redhat.com>	<54E34EAF.6000802@redhat.com>
	<54E457E0.20408@redhat.com>	<54E45842.9030102@redhat.com>
	<54E473D1.8000506@redhat.com>
	<CAHjP37F+MCjO27yNxRwAGFwhQJnt+oeg0pxgcmkeV7KqE=DYVQ@mail.gmail.com>
Message-ID: <54E4FD45.5090106@oracle.com>

The code which eliminates MemBars for scalarized objects was added in jdk8:

http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6f3fd5150b67

An other store barrier change was also pushed into jdk8:

http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/fcf521c3fbc6

I don't remember we did anything special with membars in jdk9.

Regards,
Vladimir

On 2/18/15 6:27 AM, Vitaly Davidovich wrote:
> Indeed, that's quite nice and not what I saw in java 7 so good to see that
> this case is EA'd out.  Does anyone know if there was EA work done in java
> 9 or is this simply inlining policy change that makes EA work (as John
> alluded to)?
>
> sent from my phone
> On Feb 18, 2015 6:13 AM, "Andrew Haley" <aph at redhat.com> wrote:
>
>> On 02/18/2015 09:15 AM, Andrew Haley wrote:
>>> On 18/02/15 09:14, Florian Weimer wrote:
>>>> Wow, looks nice.  What OpenJDK build did you use?  I want to see if this
>>>> happens on x86_64, too.
>>>
>>> I'm working on JDK9.  You don't have this code yet.  I'll do an x86
>>> build.
>>
>>    0x00007f2948acbf8c: mov    0xc(%rdx),%r10d    ;*synchronization entry
>>                                                  ; -
>> java.nio.HeapByteBuffer::<init>@-1 (line 84)
>>                                                  ; -
>> java.nio.ByteBuffer::wrap at 7 (line 373)
>>                                                  ; -
>> java.nio.ByteBuffer::wrap at 4 (line 396)
>>                                                  ; -
>> bytebuffertests.ByteBufferTests3::getLong at 1 (line 23)
>>                                                  ; implicit exception:
>> dispatches to 0x00007f2948acbff5
>>    ;; B2: #      B5 B3 <- B1  Freq: 0.999999
>>
>>    ;; MEMBAR-release ! (empty encoding)
>>
>>    0x00007f2948acbf90: test   %ecx,%ecx
>>    0x00007f2948acbf92: jl     0x00007f2948acbfb5  ;*iflt
>>                                                  ; -
>> java.nio.Buffer::checkIndex at 1 (line 545)
>>                                                  ; -
>> java.nio.HeapByteBuffer::getLong at 18 (line 465)
>>                                                  ; -
>> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)
>>
>>    ;; B3: #      B6 B4 <- B2  Freq: 0.999999
>>
>>    0x00007f2948acbf94: mov    %r10d,%ebp
>>    0x00007f2948acbf97: sub    %ecx,%ebp          ;*isub
>>                                                  ; -
>> java.nio.Buffer::checkIndex at 10 (line 545)
>>                                                  ; -
>> java.nio.HeapByteBuffer::getLong at 18 (line 465)
>>                                                  ; -
>> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)
>>
>>    0x00007f2948acbf99: cmp    $0x8,%ebp
>>    0x00007f2948acbf9c: jl     0x00007f2948acbfd5  ;*if_icmple
>>                                                  ; -
>> java.nio.Buffer::checkIndex at 11 (line 545)
>>                                                  ; -
>> java.nio.HeapByteBuffer::getLong at 18 (line 465)
>>                                                  ; -
>> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)
>>
>>    ;; B4: #      N95 <- B3  Freq: 0.999998
>>
>>    0x00007f2948acbf9e: movslq %ecx,%r10
>>    0x00007f2948acbfa1: mov    0x10(%rdx,%r10,1),%rax
>>    0x00007f2948acbfa6: bswap  %rax               ;*invokestatic reverseBytes
>>                                                  ; - java.nio.Bits::swap at 1
>> (line 61)
>>                                                  ; -
>> java.nio.HeapByteBuffer::getLong at 41 (line 466)
>>                                                  ; -
>> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)
>>
>> So, just the same except that there is no explicit fence instruction
>> to remove.  It's a shame for AArch64 because that fence really kills
>> performance but it's bad for x86 too.  Even on machines that don't
>> emit fence instructions the fence still acts as a compiler barrier.
>>
>> Andrew.
>>


From vitalyd at gmail.com  Wed Feb 18 21:03:51 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Feb 2015 16:03:51 -0500
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E4FD45.5090106@oracle.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>
	<54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com>
	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>
	<54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com>
	<54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com>
	<54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com>
	<54E34EAF.6000802@redhat.com> <54E457E0.20408@redhat.com>
	<54E45842.9030102@redhat.com> <54E473D1.8000506@redhat.com>
	<CAHjP37F+MCjO27yNxRwAGFwhQJnt+oeg0pxgcmkeV7KqE=DYVQ@mail.gmail.com>
	<54E4FD45.5090106@oracle.com>
Message-ID: <CAHjP37EUKwA3nMjOK7P2BgZHRqnxe--tBnQLVHvOpQpvhXGGLg@mail.gmail.com>

Thanks Vladimir.  I was actually asking about the ByteBuffer elimination
itself; when I tried Andrew's example on 7u60 (i.e. a single method with a
ByteBuffer.wrap(...).getLong(...)), the ByteBuffer allocation was not
removed.

On Wed, Feb 18, 2015 at 3:59 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com
> wrote:

> The code which eliminates MemBars for scalarized objects was added in jdk8:
>
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6f3fd5150b67
>
> An other store barrier change was also pushed into jdk8:
>
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/fcf521c3fbc6
>
> I don't remember we did anything special with membars in jdk9.
>
> Regards,
> Vladimir
>
>
> On 2/18/15 6:27 AM, Vitaly Davidovich wrote:
>
>> Indeed, that's quite nice and not what I saw in java 7 so good to see that
>> this case is EA'd out.  Does anyone know if there was EA work done in java
>> 9 or is this simply inlining policy change that makes EA work (as John
>> alluded to)?
>>
>> sent from my phone
>> On Feb 18, 2015 6:13 AM, "Andrew Haley" <aph at redhat.com> wrote:
>>
>>  On 02/18/2015 09:15 AM, Andrew Haley wrote:
>>>
>>>> On 18/02/15 09:14, Florian Weimer wrote:
>>>>
>>>>> Wow, looks nice.  What OpenJDK build did you use?  I want to see if
>>>>> this
>>>>> happens on x86_64, too.
>>>>>
>>>>
>>>> I'm working on JDK9.  You don't have this code yet.  I'll do an x86
>>>> build.
>>>>
>>>
>>>    0x00007f2948acbf8c: mov    0xc(%rdx),%r10d    ;*synchronization entry
>>>                                                  ; -
>>> java.nio.HeapByteBuffer::<init>@-1 (line 84)
>>>                                                  ; -
>>> java.nio.ByteBuffer::wrap at 7 (line 373)
>>>                                                  ; -
>>> java.nio.ByteBuffer::wrap at 4 (line 396)
>>>                                                  ; -
>>> bytebuffertests.ByteBufferTests3::getLong at 1 (line 23)
>>>                                                  ; implicit exception:
>>> dispatches to 0x00007f2948acbff5
>>>    ;; B2: #      B5 B3 <- B1  Freq: 0.999999
>>>
>>>    ;; MEMBAR-release ! (empty encoding)
>>>
>>>    0x00007f2948acbf90: test   %ecx,%ecx
>>>    0x00007f2948acbf92: jl     0x00007f2948acbfb5  ;*iflt
>>>                                                  ; -
>>> java.nio.Buffer::checkIndex at 1 (line 545)
>>>                                                  ; -
>>> java.nio.HeapByteBuffer::getLong at 18 (line 465)
>>>                                                  ; -
>>> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)
>>>
>>>    ;; B3: #      B6 B4 <- B2  Freq: 0.999999
>>>
>>>    0x00007f2948acbf94: mov    %r10d,%ebp
>>>    0x00007f2948acbf97: sub    %ecx,%ebp          ;*isub
>>>                                                  ; -
>>> java.nio.Buffer::checkIndex at 10 (line 545)
>>>                                                  ; -
>>> java.nio.HeapByteBuffer::getLong at 18 (line 465)
>>>                                                  ; -
>>> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)
>>>
>>>    0x00007f2948acbf99: cmp    $0x8,%ebp
>>>    0x00007f2948acbf9c: jl     0x00007f2948acbfd5  ;*if_icmple
>>>                                                  ; -
>>> java.nio.Buffer::checkIndex at 11 (line 545)
>>>                                                  ; -
>>> java.nio.HeapByteBuffer::getLong at 18 (line 465)
>>>                                                  ; -
>>> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)
>>>
>>>    ;; B4: #      N95 <- B3  Freq: 0.999998
>>>
>>>    0x00007f2948acbf9e: movslq %ecx,%r10
>>>    0x00007f2948acbfa1: mov    0x10(%rdx,%r10,1),%rax
>>>    0x00007f2948acbfa6: bswap  %rax               ;*invokestatic
>>> reverseBytes
>>>                                                  ; -
>>> java.nio.Bits::swap at 1
>>> (line 61)
>>>                                                  ; -
>>> java.nio.HeapByteBuffer::getLong at 41 (line 466)
>>>                                                  ; -
>>> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23)
>>>
>>> So, just the same except that there is no explicit fence instruction
>>> to remove.  It's a shame for AArch64 because that fence really kills
>>> performance but it's bad for x86 too.  Even on machines that don't
>>> emit fence instructions the fence still acts as a compiler barrier.
>>>
>>> Andrew.
>>>
>>>


From kissziszi at gmail.com  Thu Feb 19 00:16:58 2015
From: kissziszi at gmail.com (Zoltan Sziladi)
Date: Wed, 18 Feb 2015 16:16:58 -0800
Subject: String.substring when beginIndex is the string's length
Message-ID: <CA+_Mpj9aJe8Q7RUiPrD9nDn98Ph95hNbrVG8_LTL0zqbVQ6qhA@mail.gmail.com>

Hi,

There are 2 things I do not understand about how substring works, hopefully
someone can shed some light on it.

1. When you call substring and you provide the string's length as
beginIndex, why does it return an empty string instead of throwing an
exception? You are effectively indexing outside of the string: you index a
character that is after the last character. Obviously this won't be changed
since probably lots of code depend on this already, but still, I just don't
get the logic behind it.

2. In this specific case (when beginIndex is the string's length) there
seem to be a lot of unnecessary method calls for returning an empty string:
    String constructor -> Arrays.copyOfRange -> System.arraycopy
All of these calls do some checks and in this case pass around 0's a lot,
even creating array of 0 length, etc.
My question is, would it make sense to include an if so that if subLen ==
0, then it would return an empty string? Or it has too much overhead if we
consider how often this case occurs and it would be better to lose on
performance on these rare occasions while keeping the general case 1 if
faster?

Thanks in advance!

Regards,
Zoltan


From claes.redestad at oracle.com  Thu Feb 19 00:51:12 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 19 Feb 2015 01:51:12 +0100
Subject: String.substring when beginIndex is the string's length
In-Reply-To: <CA+_Mpj9aJe8Q7RUiPrD9nDn98Ph95hNbrVG8_LTL0zqbVQ6qhA@mail.gmail.com>
References: <CA+_Mpj9aJe8Q7RUiPrD9nDn98Ph95hNbrVG8_LTL0zqbVQ6qhA@mail.gmail.com>
Message-ID: <54E53380.205@oracle.com>

Hi Zoltan,

1. Well, obviously, there's an empty string at the end of all Strings which
you can index into! ;-)

(I guess it was a coin toss originally. Since it'd be a bit
inconsistent if say "foo".substring(0, 0) returned "" while, say,
"".substring(0, 0) threw a tantrum, I'd like to think the current impl was
favored for good reason)

2. https://bugs.openjdk.java.net/browse/JDK-8067471 was recently discussed
and a patch which actually optimizes away the array creation was pushed
into JDK9:

http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c60cf8acabb2

Going further and removing the String allocation entirely (returning "")
might have unexpected side-effects for some code expecting a new, distinct
object. Any potential benefit might also be eaten up by increased byte 
code,
more branches etc.

HTH!

/Claes

On 2015-02-19 01:16, Zoltan Sziladi wrote:
> Hi,
>
> There are 2 things I do not understand about how substring works, hopefully
> someone can shed some light on it.
>
> 1. When you call substring and you provide the string's length as
> beginIndex, why does it return an empty string instead of throwing an
> exception? You are effectively indexing outside of the string: you index a
> character that is after the last character. Obviously this won't be changed
> since probably lots of code depend on this already, but still, I just don't
> get the logic behind it.
>
> 2. In this specific case (when beginIndex is the string's length) there
> seem to be a lot of unnecessary method calls for returning an empty string:
>      String constructor -> Arrays.copyOfRange -> System.arraycopy
> All of these calls do some checks and in this case pass around 0's a lot,
> even creating array of 0 length, etc.
> My question is, would it make sense to include an if so that if subLen ==
> 0, then it would return an empty string? Or it has too much overhead if we
> consider how often this case occurs and it would be better to lose on
> performance on these rare occasions while keeping the general case 1 if
> faster?
>
> Thanks in advance!
>
> Regards,
> Zoltan



From johnsadair at yahoo.com  Mon Feb 16 04:25:49 2015
From: johnsadair at yahoo.com (John S. Adair)
Date: Sun, 15 Feb 2015 20:25:49 -0800
Subject: Comparators.NullComparator equals/hashCode
Message-ID: <1424060749.2496.YahooMailBasic@web400203.mail.bf1.yahoo.com>

I just filed a bug report with Oracle (Review ID: JI-9019070) requesting that Comparators.NullComparator
implement equals and hashCode in a manner analogous to Collections.ReverseComparator2. It occurred
to me that my bug report failed to mention the (hopefully obvious) behavior regarding the nullsFirst flag.

Is this the right place to ask about the likelihood of action being taken on the bug/RFE?



From adinn at redhat.com  Wed Feb 18 10:01:05 2015
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 18 Feb 2015 10:01:05 +0000
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <CAHjP37FWOaCk3Zt_XJYnUBn9_SKPWkKPuOyN2G3iLrUVJ+gFqw@mail.gmail.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>	<54DE8BB7.5050801@oracle.com>
	<54DE9140.3040604@oracle.com>	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>	<54E30C38.8000303@redhat.com>
	<54E31144.3040504@redhat.com>	<54E314BF.3010205@redhat.com>
	<54E31677.1050209@redhat.com>	<54E31CA6.6030609@redhat.com>
	<54E31DA0.2040901@redhat.com>	<54E34EAF.6000802@redhat.com>	<0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com>	<54E38F4B.7060100@redhat.com>
	<54E39364.6030409@oracle.com>
	<CAHjP37FWOaCk3Zt_XJYnUBn9_SKPWkKPuOyN2G3iLrUVJ+gFqw@mail.gmail.com>
Message-ID: <54E462E1.5080009@redhat.com>

On 17/02/15 19:21, Vitaly Davidovich wrote:
> IMO I don't think such barriers should be removed just because EA is able
> to elide the heap allocation.

Why not? Are you assuming that the programmer might be relying on a
memory barrier being implied in interpreted/JITted code by the presence
in the source of an allocation? If so then I am not sure the Java memory
model justifies that assumption, especially so in the case EA optimises.

As I recall, the arguments here and on the concurrency lists for the
presence of a memory barrier at the end of allocation were only /for/ it
as a heuristic to ensure that objects which might be shared would not be
shared before all effects of construction were visible (I may be
misstating that -- you might like to reread it as "the arguments on the
concurrency lists I was convinced by" :-). In which case, if an object
cannot be shared, indeed need not even be allocated, then there appears
to be no need for such a heuristic.

n.b. if a Java programmer really wants to enforce memory ordering wrt
other threads then Java provides a very simple mechanism for that in
volatile.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Michael O'Neill (Ireland)



From kissziszi at gmail.com  Thu Feb 19 05:26:00 2015
From: kissziszi at gmail.com (Zoltan Sziladi)
Date: Wed, 18 Feb 2015 21:26:00 -0800
Subject: String.substring when beginIndex is the string's length
In-Reply-To: <54E53380.205@oracle.com>
References: <CA+_Mpj9aJe8Q7RUiPrD9nDn98Ph95hNbrVG8_LTL0zqbVQ6qhA@mail.gmail.com>
	<54E53380.205@oracle.com>
Message-ID: <CA+_Mpj-WNPaAqZ0ddaPHdL7EFe_Y2EYW2+AKhU8YCChxSzxiYg@mail.gmail.com>

Hi Claes,

Thanks a lot for the clarification! I'm glad this has been optimized in
JDK9!
Also, your example with "foo" and "" makes sense.

Thanks!

Zoltan

On Wed, Feb 18, 2015 at 4:51 PM, Claes Redestad <claes.redestad at oracle.com>
wrote:

> Hi Zoltan,
>
> 1. Well, obviously, there's an empty string at the end of all Strings which
> you can index into! ;-)
>
> (I guess it was a coin toss originally. Since it'd be a bit
> inconsistent if say "foo".substring(0, 0) returned "" while, say,
> "".substring(0, 0) threw a tantrum, I'd like to think the current impl was
> favored for good reason)
>
> 2. https://bugs.openjdk.java.net/browse/JDK-8067471 was recently discussed
> and a patch which actually optimizes away the array creation was pushed
> into JDK9:
>
> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c60cf8acabb2
>
> Going further and removing the String allocation entirely (returning "")
> might have unexpected side-effects for some code expecting a new, distinct
> object. Any potential benefit might also be eaten up by increased byte
> code,
> more branches etc.
>
> HTH!
>
> /Claes
>
>
> On 2015-02-19 01:16, Zoltan Sziladi wrote:
>
>> Hi,
>>
>> There are 2 things I do not understand about how substring works,
>> hopefully
>> someone can shed some light on it.
>>
>> 1. When you call substring and you provide the string's length as
>> beginIndex, why does it return an empty string instead of throwing an
>> exception? You are effectively indexing outside of the string: you index a
>> character that is after the last character. Obviously this won't be
>> changed
>> since probably lots of code depend on this already, but still, I just
>> don't
>> get the logic behind it.
>>
>> 2. In this specific case (when beginIndex is the string's length) there
>> seem to be a lot of unnecessary method calls for returning an empty
>> string:
>>      String constructor -> Arrays.copyOfRange -> System.arraycopy
>> All of these calls do some checks and in this case pass around 0's a lot,
>> even creating array of 0 length, etc.
>> My question is, would it make sense to include an if so that if subLen ==
>> 0, then it would return an empty string? Or it has too much overhead if we
>> consider how often this case occurs and it would be better to lose on
>> performance on these rare occasions while keeping the general case 1 if
>> faster?
>>
>> Thanks in advance!
>>
>> Regards,
>> Zoltan
>>
>
>


From martinrb at google.com  Thu Feb 19 05:41:40 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 18 Feb 2015 21:41:40 -0800
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <54DC6D4B.3070902@oracle.com>
References: <54CBAA39.3050004@Oracle.com> <54CBF7DB.9000909@oracle.com>
	<54CBFC10.9080502@Oracle.com>
	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>
	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>
	<54CD4305.4080607@oracle.com>
	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>
	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>
	<54CF7D1F.6050101@Oracle.com>
	<CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>
	<54CFE064.70400@Oracle.com>
	<CA+kOe0-zPJRpGEa0zXy6_bHgwNcnFWuSc1fbbxsc7-nc6SUjAg@mail.gmail.com>
	<54D08997.9020300@oracle.com>
	<CA+kOe091FHtd1Mnz_eVLcP0a_fC-+nXPGjnEdYr706XguBTy=g@mail.gmail.com>
	<54DBBA84.7090108@Oracle.com>
	<CA+kOe08VHA6h=6xVipyZ-xEx-XFBJ_mfd48GcnGJMaU0hQMQVA@mail.gmail.com>
	<54DC6D4B.3070902@oracle.com>
Message-ID: <CA+kOe09QDOBmNRjkJKoSxstb=+EUqWCE3PNXT7Mi_=k2hH=k0Q@mail.gmail.com>

On Thu, Feb 12, 2015 at 1:07 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 12/02/2015 02:08, Martin Buchholz wrote:
>
>> Roger et al,
>>
>> Whichever way we go doesn't matter much.
>> But I continue to think that IOE is a better choice than UOE and I have
>> trouble seeing the motivation for the change to use UOE.
>> If you wanted to provide a way to tell if subprocess support was available
>> at all, then it would be better to add a new static boolean method to
>> Process (but I wouldn't support that either).
>> But (Roger and Alan): feel free to outvote me.
>>
>>  I think Roger's proposal is reasonable as this is a case where the API
> will consistently throw UOE when the underlying runtime or operating system
> doesn't support a means to start processes. It's consistent with what was
> done for RMI activiation in JDK 8 (this was also about starting processes).
> Another example that comes to mind is the GUI libraries where
> HeadlessException is thrown (HeadlessException is a UOE). In the file
> system API then UOE is also specified when trying to use optional features
> that aren't supported by the implementation. There are probably many
> counter examples as we don't have consistency everywhere. In practical
> terms then I don't think this change should have an impact, but could be
> useful for those trying to take an existing app and run it on something
> like iOS. If that app relies on Runtime.exec or ProcessBuilder then the UOE
> should make it easy to identify that this part of the code needs to be
> looked at. If someday it is possible to start processes on such devices
> then an updated port to that platform wouldn't throw UOE anymore.
>
> -Alan.
>

If you threw a variant of UOE that was also an IOException, it would have
been equally clear to users, and no change to the contract of
ProcessBuilder would have been necessary.

You've broken users who relied on the old spec.


From ivan.gerasimov at oracle.com  Thu Feb 19 08:43:40 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 19 Feb 2015 11:43:40 +0300
Subject: Comparators.NullComparator equals/hashCode
In-Reply-To: <1424060749.2496.YahooMailBasic@web400203.mail.bf1.yahoo.com>
References: <1424060749.2496.YahooMailBasic@web400203.mail.bf1.yahoo.com>
Message-ID: <54E5A23C.8020603@oracle.com>

Hi John!

Your request was moved to the JDK project in jbs: 
https://bugs.openjdk.java.net/browse/JDK-8073332

Personally, I don't think this has to be implemented.  Please see my 
comment at the bug page.
Other people may think oppositely, so I didn't close the request.

Sincerely yours,
Ivan


On 16.02.2015 7:25, John S. Adair wrote:
> I just filed a bug report with Oracle (Review ID: JI-9019070) requesting that Comparators.NullComparator
> implement equals and hashCode in a manner analogous to Collections.ReverseComparator2. It occurred
> to me that my bug report failed to mention the (hopefully obvious) behavior regarding the nullsFirst flag.
>
> Is this the right place to ask about the likelihood of action being taken on the bug/RFE?
>
>
>



From aph at redhat.com  Thu Feb 19 08:58:13 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 19 Feb 2015 08:58:13 +0000
Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
	accesses
In-Reply-To: <54E4FD45.5090106@oracle.com>
References: <20150213230416.5E7B617FDAA@rebar.astron.com>	<54DE8BB7.5050801@oracle.com>
	<54DE9140.3040604@oracle.com>	<FEC2F45A-17CD-416D-A6DE-DB6B14356378@oracle.com>	<54E30C38.8000303@redhat.com>
	<54E31144.3040504@redhat.com>	<54E314BF.3010205@redhat.com>
	<54E31677.1050209@redhat.com>	<54E31CA6.6030609@redhat.com>
	<54E31DA0.2040901@redhat.com>	<54E34EAF.6000802@redhat.com>
	<54E457E0.20408@redhat.com>	<54E45842.9030102@redhat.com>
	<54E473D1.8000506@redhat.com>
	<CAHjP37F+MCjO27yNxRwAGFwhQJnt+oeg0pxgcmkeV7KqE=DYVQ@mail.gmail.com>
	<54E4FD45.5090106@oracle.com>
Message-ID: <54E5A5A5.1090305@redhat.com>

On 18/02/15 20:59, Vladimir Kozlov wrote:
> The code which eliminates MemBars for scalarized objects was added in jdk8:
> 
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6f3fd5150b67
> 
> An other store barrier change was also pushed into jdk8:
> 
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/fcf521c3fbc6
> 
> I don't remember we did anything special with membars in jdk9.

OK, so the question of why it isn't being removed in this case
is interesting.  We can look at that later.

Andrew.



From nobeh5 at gmail.com  Thu Feb 19 11:44:32 2015
From: nobeh5 at gmail.com (Behrooz Nobakht)
Date: Thu, 19 Feb 2015 12:44:32 +0100
Subject: Logging FileHandler: static locks and hardcoded maximum number
Message-ID: <CAEEKBgU_-i1ki3bJTBQh7Q0K7NU4xgzmn=FbaRP+TJzgbgFS4A@mail.gmail.com>

Hi,

The following describes my situation:

1. I have a long running JVM process (p1).
2. The long running process instantiate another JVM process (p2).
3. On every instantiation of p2, p1 prepares an instance of FileHandler for
p2
 (used through a redirect thread of logging) as:
new FileHandler("/path/to/log/app.stdouterr.%u.%g.log"
4. p2 is short-lived and on its JVM exit, it closes FileHandler
5. p1 can start p2 an arbitrary number of times

Our observation started with the following exception:

Caused by: java.io.IOException: Couldn't get lock for
/path/to/log/app.stdouterr.%u.%g.log
        at java.util.logging.FileHandler.openFiles(FileHandler.java:422)
        at java.util.logging.FileHandler.<init>(FileHandler.java:318)
        (...)

Then, I tried to understand why, and I used the following on the running
server:

$ lsof -uappuser | grep -E "\/path\/to\/log"

It's interesting that I see 100 files as ".lck" in generation 0
as the following shows (the results are trimmed):

===
java    14515 appuser  182wW  REG              252,0        0 109052248
/path/to/log/app.stdouterr.0.0.log.lck (deleted)
java    14515 appuser  183wW  REG              252,0        0  92274968
/path/to/log/app.stdouterr.1.0.log.lck (deleted)
java    14515 appuser  184wW  REG              252,0        0 125829396
/path/to/log/app.stdouterr.2.0.log.lck (deleted)
.
.
.
java    14515 appuser  206wW  REG              252,0        0 109052253
/path/to/log/app.stdouterr.98.0.log.lck (deleted)
java    14515 appuser  207wW  REG              252,0        0 125829401
/path/to/log/app.stdouterr.99.0.log.lck (deleted)
java    14515 appuser  168wW  REG              252,0        0   8388893
/path/to/log/app.stdouterr.100.0.log.lck
java    14515 appuser  176w   REG              252,0      367   8388894
/path/to/log/app.stdouterr.100.0.log
===

Please note that except the last two, all the *.lck files are marked as
(deleted),
which means they are not available in the file system (confirmed)
but a process has an open handle on the path.

Simply, based on (3) and (4), when p1 would reach the 100th time it wants
to
instantiate p2, we start to observe the exception.

As far as I can see the source for FileHandler:

- a static field is used to hold the lock files
- in our setup, the JVM in p1 initiates the above static field as part of
the first time preparing p2
- the (deleted) in the above, means that FileHandler#close has been called
with success.

Questions/Suggestions:

(a) The above (deleted) handles would not be released until p1 JVM goes
down, correct?
(b) If (a) is correct, is there way to ask JVM to do so on FileHandler? If
yes, where should I look into?
(c) If (b) is no, is there a chance FileHandler could introduce a new API
method to be able to perform such clean-up without having to exit p1 JVM?

Thanks,
Behrooz


From lev.priima at oracle.com  Thu Feb 19 12:00:32 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Thu, 19 Feb 2015 15:00:32 +0300
Subject: RFR 8073354: TimSortStackSize2.java: requires
	64*2^20*sizeof(reference) continues heap space
In-Reply-To: <54E2E5F1.4070702@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>
Message-ID: <54E5D060.1080409@oracle.com>

   There is also a problem, if the memory on host is highly fragmented, 
then we can't allocate continuous amount of heap for creating such big 
array. I've added catch for OOME and treat this case as skip-pass to 
make test more robust. Also I've removed explicit -Xmx385 from @run tag 
and made it start with a single argument.

Please review and push: 
http://cr.openjdk.java.net/~lpriima/8073354/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8073354

Lev

On 02/17/2015 09:55 AM, David Holmes wrote:
> On 17/02/2015 3:43 PM, Lev Priima wrote:
>> Thanks David!
>> Is this expected behavior of this annotation ?
>
> Yes that is the way jtreg defines tags:
>
> http://openjdk.java.net/jtreg/tag-spec.html
>
> "The argument tokens of a tag extend from the first token after the 
> tag token to the end of the comment, the end of the file, or the next 
> tag token, whichever comes first."
>
> So everything between @run and @summary are taken to be the @run 
> commands. And there's no @comment tag unfortunately.
>
> David
>
>> Lev
>>
>> On 02/17/2015 03:20 AM, David Holmes wrote:
>>> On 16/02/2015 9:20 PM, David Holmes wrote:
>>>> On 16/02/2015 6:59 PM, Lev Priima wrote:
>>>>> Thanks, David,
>>>>> Could you please push it ?
>>>>
>>>> I will if Roger doesn't get to it first. It'll be 11 hours before I 
>>>> can
>>>> push it.
>>>
>>> This has been pushed but note there is a minor issue with the test.
>>> The jtreg tag specification doesn't terminate tags on newlines, they
>>> continue until the next tag is encountered or the end of the comment.
>>> Consequently this:
>>>
>>>  * @run main/othervm -Xmx385m TimSortStackSize2 67108864
>>>  * not for regular execution on all platforms:
>>>  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>  * run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>
>>> is processed as:
>>>
>>> @run main/othervm -Xmx385m TimSortStackSize2 67108864 not for regular
>>> execution on all platforms: run main/othervm -Xmx8g TimSortStackSize2
>>> 1073741824 run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>
>>> and so TimSortStackSize2 is invoked with 18 arguments.
>>>
>>> David
>>> -----
>>>
>>>> David
>>>>
>>>>> Lev
>>>>>
>>>>> On 02/16/2015 08:55 AM, David Holmes wrote:
>>>>>> On 14/02/2015 12:03 AM, Lev Priima wrote:
>>>>>>> Please review and push:
>>>>>>> http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073124
>>>>>>
>>>>>> I hadn't realized 8072909 had been pushed without final reviewer
>>>>>> comments being addressed. :(
>>>>>>
>>>>>> These changes seem okay. I hope they get promoted at the same 
>>>>>> time as
>>>>>> the original changeset so we don't get test failures.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Lev
>>>>>>>
>>>>>>> On 02/13/2015 05:20 AM, David Holmes wrote:
>>>>>>>> Hi Lev,
>>>>>>>>
>>>>>>>> On 13/02/2015 2:56 AM, Lev Priima wrote:
>>>>>>>>> Christos,
>>>>>>>>>
>>>>>>>>> Test may fail on shorter arrays(page 8 of paper). For 
>>>>>>>>> instance, on
>>>>>>>>> worst
>>>>>>>>> case, generated by test, it starts to fail on length 67108864.
>>>>>>>>> After increasing stack size of runs to merge, Arrays.sort(T[])
>>>>>>>>> works
>>>>>>>>> also on maximum possible array for HotSpot JVM.
>>>>>>>>
>>>>>>>> I'd also like to see this documented somewhere in the code.
>>>>>>>> Presently
>>>>>>>> there is a reference to listsort.txt but then you have to go and
>>>>>>>> find
>>>>>>>> it on the web. :( At a minimum could we please add:
>>>>>>>>
>>>>>>>>  175          * computation below must be changed if MIN_MERGE is
>>>>>>>> decreased.  See
>>>>>>>>  176          * the MIN_MERGE declaration above for more
>>>>>>>> information.
>>>>>>>> +             * The maximum value of 49 allows for an array up to
>>>>>>>> length
>>>>>>>> +             * Integer.MAX_VALUE-4.
>>>>>>>>
>>>>>>>>> Roger, David,
>>>>>>>>> I've updated the test (
>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ) to make it more suitable for regular execution:
>>>>>>>>>
>>>>>>>>>    27  * @run main/othervm TimSortStackSize2 67108864
>>>>>>>>
>>>>>>>> This will still fail on small memory devices:
>>>>>>>>
>>>>>>>> :~> java TimSortStackSize2 67108864
>>>>>>>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap
>>>>>>>> space
>>>>>>>>
>>>>>>>> as the default heap ergonomics may not be large enough. I had to
>>>>>>>> add a
>>>>>>>> minimum heap of -Xmx385M to get it to run.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>>    28  * not for regular execution on all platforms:
>>>>>>>>>    29  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>>>>>    30  * run main/othervm -Xmx32g TimSortStackSize2 2147483644
>>>>>>>>>
>>>>>>>>> Could you please push this:
>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>>>>>>>>> ?
>>>>>>>>>
>>>>>>>>> Lev
>>>>>>>>>
>>>>>>>>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>>>>>>>>> On Feb 12, 9:57pm,david.holmes at oracle.com  (David Holmes) wrote:
>>>>>>>>>> -- Subject: Re: 8072909: TimSort fails with
>>>>>>>>>> ArrayIndexOutOfBoundsException on
>>>>>>>>>>
>>>>>>>>>> | Ok - thanks Lev!
>>>>>>>>>> |
>>>>>>>>>> | David
>>>>>>>>>>
>>>>>>>>>> For posterity can someone document this, and also the value for
>>>>>>>>>> which
>>>>>>>>>> Integer.MAX_VALUE-4 fails?
>>>>>>>>>>
>>>>>>>>>> christos
>>>>>>>>>
>>>>>>>
>>>>>
>>



From daniel.fuchs at oracle.com  Thu Feb 19 12:06:04 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 19 Feb 2015 13:06:04 +0100
Subject: Logging FileHandler: static locks and hardcoded maximum number
In-Reply-To: <CAEEKBgU_-i1ki3bJTBQh7Q0K7NU4xgzmn=FbaRP+TJzgbgFS4A@mail.gmail.com>
References: <CAEEKBgU_-i1ki3bJTBQh7Q0K7NU4xgzmn=FbaRP+TJzgbgFS4A@mail.gmail.com>
Message-ID: <54E5D1AC.7050607@oracle.com>

Hi Behrooz,

I have made several fixes WRT to lock files used by FileHandler
recently. Could you please tell us which version of java you
are using when observing this?

I'll need to analyze your issue a bit deeper - and knowing
the version (java -version) will help me in not making false
assumptions :-)

I'm not sure I understand the notion of 'preparing a FileHandler
for p2' - p1 will need to close that file handler before p2 starts,
otherwise the file that p1 uses will be locked, and p2 will have
to create a new file.

best regards,

-- daniel

On 19/02/15 12:44, Behrooz Nobakht wrote:
> Hi,
>
> The following describes my situation:
>
> 1. I have a long running JVM process (p1).
> 2. The long running process instantiate another JVM process (p2).
> 3. On every instantiation of p2, p1 prepares an instance of FileHandler for
> p2
>   (used through a redirect thread of logging) as:
> new FileHandler("/path/to/log/app.stdouterr.%u.%g.log"
> 4. p2 is short-lived and on its JVM exit, it closes FileHandler
> 5. p1 can start p2 an arbitrary number of times
>
> Our observation started with the following exception:
>
> Caused by: java.io.IOException: Couldn't get lock for
> /path/to/log/app.stdouterr.%u.%g.log
>          at java.util.logging.FileHandler.openFiles(FileHandler.java:422)
>          at java.util.logging.FileHandler.<init>(FileHandler.java:318)
>          (...)
>
> Then, I tried to understand why, and I used the following on the running
> server:
>
> $ lsof -uappuser | grep -E "\/path\/to\/log"
>
> It's interesting that I see 100 files as ".lck" in generation 0
> as the following shows (the results are trimmed):
>
> ===
> java    14515 appuser  182wW  REG              252,0        0 109052248
> /path/to/log/app.stdouterr.0.0.log.lck (deleted)
> java    14515 appuser  183wW  REG              252,0        0  92274968
> /path/to/log/app.stdouterr.1.0.log.lck (deleted)
> java    14515 appuser  184wW  REG              252,0        0 125829396
> /path/to/log/app.stdouterr.2.0.log.lck (deleted)
> .
> .
> .
> java    14515 appuser  206wW  REG              252,0        0 109052253
> /path/to/log/app.stdouterr.98.0.log.lck (deleted)
> java    14515 appuser  207wW  REG              252,0        0 125829401
> /path/to/log/app.stdouterr.99.0.log.lck (deleted)
> java    14515 appuser  168wW  REG              252,0        0   8388893
> /path/to/log/app.stdouterr.100.0.log.lck
> java    14515 appuser  176w   REG              252,0      367   8388894
> /path/to/log/app.stdouterr.100.0.log
> ===
>
> Please note that except the last two, all the *.lck files are marked as
> (deleted),
> which means they are not available in the file system (confirmed)
> but a process has an open handle on the path.
>
> Simply, based on (3) and (4), when p1 would reach the 100th time it wants
> to
> instantiate p2, we start to observe the exception.
>
> As far as I can see the source for FileHandler:
>
> - a static field is used to hold the lock files
> - in our setup, the JVM in p1 initiates the above static field as part of
> the first time preparing p2
> - the (deleted) in the above, means that FileHandler#close has been called
> with success.
>
> Questions/Suggestions:
>
> (a) The above (deleted) handles would not be released until p1 JVM goes
> down, correct?
> (b) If (a) is correct, is there way to ask JVM to do so on FileHandler? If
> yes, where should I look into?
> (c) If (b) is no, is there a chance FileHandler could introduce a new API
> method to be able to perform such clean-up without having to exit p1 JVM?
>
> Thanks,
> Behrooz
>



From nobeh5 at gmail.com  Thu Feb 19 12:46:31 2015
From: nobeh5 at gmail.com (Behrooz Nobakht)
Date: Thu, 19 Feb 2015 13:46:31 +0100
Subject: Logging FileHandler: static locks and hardcoded maximum number
In-Reply-To: <54E5D1AC.7050607@oracle.com>
References: <CAEEKBgU_-i1ki3bJTBQh7Q0K7NU4xgzmn=FbaRP+TJzgbgFS4A@mail.gmail.com>
	<54E5D1AC.7050607@oracle.com>
Message-ID: <CAEEKBgXjm71hBjhHGnDs4A2wLiBXndQFuLWEh3ScaVZcDY1TNQ@mail.gmail.com>

Hi Daniel,

Thanks for the quick reply.

On Thu, Feb 19, 2015 at 1:06 PM, Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi Behrooz,
>
> I have made several fixes WRT to lock files used by FileHandler
> recently. Could you please tell us which version of java you
> are using when observing this?
>
> I'll need to analyze your issue a bit deeper - and knowing
> the version (java -version) will help me in not making false
> assumptions :-)
>

The version of Java is irrelevant. We have tested our setup
on Java 7 and Java 8 u25/31. We observe the same exception.


>
> I'm not sure I understand the notion of 'preparing a FileHandler
> for p2' - p1 will need to close that file handler before p2 starts,
> otherwise the file that p1 uses will be locked, and p2 will have
> to create a new file.
>


The p1 JVM behaves like a Java Launcher. In one of its steps,
it creates a redirect thread for the to-be-launched process p2.
The redirect thread uses Java logging and in there, we use an
instance of FileHandler. So, actually, p2 is not aware of such
FileHandler object. FileHandler#close() is called as the result of
the launched p2 process exiting. I hope this clarifies further.
Going back to the above Java relevancy, that's why Java's version
is not relevant. Because FileHandler is initialized the first time
in p1 JVM and since p1 JVM does not exit, so after 100 times
that we try to launch p2 from p1, the maximum exceeds and
we get the exception.

Thanks,
Behrooz




>
> best regards,
>
> -- daniel
>
>
> On 19/02/15 12:44, Behrooz Nobakht wrote:
>
>> Hi,
>>
>> The following describes my situation:
>>
>> 1. I have a long running JVM process (p1).
>> 2. The long running process instantiate another JVM process (p2).
>> 3. On every instantiation of p2, p1 prepares an instance of FileHandler
>> for
>> p2
>>   (used through a redirect thread of logging) as:
>> new FileHandler("/path/to/log/app.stdouterr.%u.%g.log"
>> 4. p2 is short-lived and on its JVM exit, it closes FileHandler
>> 5. p1 can start p2 an arbitrary number of times
>>
>> Our observation started with the following exception:
>>
>> Caused by: java.io.IOException: Couldn't get lock for
>> /path/to/log/app.stdouterr.%u.%g.log
>>          at java.util.logging.FileHandler.openFiles(FileHandler.java:422)
>>          at java.util.logging.FileHandler.<init>(FileHandler.java:318)
>>          (...)
>>
>> Then, I tried to understand why, and I used the following on the running
>> server:
>>
>> $ lsof -uappuser | grep -E "\/path\/to\/log"
>>
>> It's interesting that I see 100 files as ".lck" in generation 0
>> as the following shows (the results are trimmed):
>>
>> ===
>> java    14515 appuser  182wW  REG              252,0        0 109052248
>> /path/to/log/app.stdouterr.0.0.log.lck (deleted)
>> java    14515 appuser  183wW  REG              252,0        0  92274968
>> /path/to/log/app.stdouterr.1.0.log.lck (deleted)
>> java    14515 appuser  184wW  REG              252,0        0 125829396
>> /path/to/log/app.stdouterr.2.0.log.lck (deleted)
>> .
>> .
>> .
>> java    14515 appuser  206wW  REG              252,0        0 109052253
>> /path/to/log/app.stdouterr.98.0.log.lck (deleted)
>> java    14515 appuser  207wW  REG              252,0        0 125829401
>> /path/to/log/app.stdouterr.99.0.log.lck (deleted)
>> java    14515 appuser  168wW  REG              252,0        0   8388893
>> /path/to/log/app.stdouterr.100.0.log.lck
>> java    14515 appuser  176w   REG              252,0      367   8388894
>> /path/to/log/app.stdouterr.100.0.log
>> ===
>>
>> Please note that except the last two, all the *.lck files are marked as
>> (deleted),
>> which means they are not available in the file system (confirmed)
>> but a process has an open handle on the path.
>>
>> Simply, based on (3) and (4), when p1 would reach the 100th time it wants
>> to
>> instantiate p2, we start to observe the exception.
>>
>> As far as I can see the source for FileHandler:
>>
>> - a static field is used to hold the lock files
>> - in our setup, the JVM in p1 initiates the above static field as part of
>> the first time preparing p2
>> - the (deleted) in the above, means that FileHandler#close has been called
>> with success.
>>
>> Questions/Suggestions:
>>
>> (a) The above (deleted) handles would not be released until p1 JVM goes
>> down, correct?
>> (b) If (a) is correct, is there way to ask JVM to do so on FileHandler? If
>> yes, where should I look into?
>> (c) If (b) is no, is there a chance FileHandler could introduce a new API
>> method to be able to perform such clean-up without having to exit p1 JVM?
>>
>> Thanks,
>> Behrooz
>>
>>
>


-- 
-- Behrooz Nobakht


From lev.priima at oracle.com  Thu Feb 19 13:23:05 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Thu, 19 Feb 2015 16:23:05 +0300
Subject: RFR 8073354: TimSortStackSize2.java: requires
	64*2^20*sizeof(reference) continues heap space
In-Reply-To: <54E5D060.1080409@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>
Message-ID: <54E5E3B9.80703@oracle.com>

After Jespers comments I removed catch of OOME and added minimum heap 
size required for test(-Xms385) to overcome default ergonomics for client.
Please review: http://cr.openjdk.java.net/~lpriima/8073354/webrev.01/

Lev

On 02/19/2015 03:00 PM, Lev Priima wrote:
> There is also a problem, if the memory on host is highly fragmented, 
> then we can't allocate continuous amount of heap for creating such big 
> array. I've added catch for OOME and treat this case as skip-pass to 
> make test more robust. Also I've removed explicit -Xmx385 from @run 
> tag and made it start with a single argument.
>
> Please review and push: 
> http://cr.openjdk.java.net/~lpriima/8073354/webrev.00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8073354
>
> Lev
>
> On 02/17/2015 09:55 AM, David Holmes wrote:
>> On 17/02/2015 3:43 PM, Lev Priima wrote:
>>> Thanks David!
>>> Is this expected behavior of this annotation ?
>>
>> Yes that is the way jtreg defines tags:
>>
>> http://openjdk.java.net/jtreg/tag-spec.html
>>
>> "The argument tokens of a tag extend from the first token after the 
>> tag token to the end of the comment, the end of the file, or the next 
>> tag token, whichever comes first."
>>
>> So everything between @run and @summary are taken to be the @run 
>> commands. And there's no @comment tag unfortunately.
>>
>> David
>>
>>> Lev
>>>
>>> On 02/17/2015 03:20 AM, David Holmes wrote:
>>>> On 16/02/2015 9:20 PM, David Holmes wrote:
>>>>> On 16/02/2015 6:59 PM, Lev Priima wrote:
>>>>>> Thanks, David,
>>>>>> Could you please push it ?
>>>>>
>>>>> I will if Roger doesn't get to it first. It'll be 11 hours before 
>>>>> I can
>>>>> push it.
>>>>
>>>> This has been pushed but note there is a minor issue with the test.
>>>> The jtreg tag specification doesn't terminate tags on newlines, they
>>>> continue until the next tag is encountered or the end of the comment.
>>>> Consequently this:
>>>>
>>>>  * @run main/othervm -Xmx385m TimSortStackSize2 67108864
>>>>  * not for regular execution on all platforms:
>>>>  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>  * run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>>
>>>> is processed as:
>>>>
>>>> @run main/othervm -Xmx385m TimSortStackSize2 67108864 not for regular
>>>> execution on all platforms: run main/othervm -Xmx8g TimSortStackSize2
>>>> 1073741824 run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>>
>>>> and so TimSortStackSize2 is invoked with 18 arguments.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> David
>>>>>
>>>>>> Lev
>>>>>>
>>>>>> On 02/16/2015 08:55 AM, David Holmes wrote:
>>>>>>> On 14/02/2015 12:03 AM, Lev Priima wrote:
>>>>>>>> Please review and push:
>>>>>>>> http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073124
>>>>>>>
>>>>>>> I hadn't realized 8072909 had been pushed without final reviewer
>>>>>>> comments being addressed. :(
>>>>>>>
>>>>>>> These changes seem okay. I hope they get promoted at the same 
>>>>>>> time as
>>>>>>> the original changeset so we don't get test failures.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>> Lev
>>>>>>>>
>>>>>>>> On 02/13/2015 05:20 AM, David Holmes wrote:
>>>>>>>>> Hi Lev,
>>>>>>>>>
>>>>>>>>> On 13/02/2015 2:56 AM, Lev Priima wrote:
>>>>>>>>>> Christos,
>>>>>>>>>>
>>>>>>>>>> Test may fail on shorter arrays(page 8 of paper). For 
>>>>>>>>>> instance, on
>>>>>>>>>> worst
>>>>>>>>>> case, generated by test, it starts to fail on length 67108864.
>>>>>>>>>> After increasing stack size of runs to merge, Arrays.sort(T[])
>>>>>>>>>> works
>>>>>>>>>> also on maximum possible array for HotSpot JVM.
>>>>>>>>>
>>>>>>>>> I'd also like to see this documented somewhere in the code.
>>>>>>>>> Presently
>>>>>>>>> there is a reference to listsort.txt but then you have to go and
>>>>>>>>> find
>>>>>>>>> it on the web. :( At a minimum could we please add:
>>>>>>>>>
>>>>>>>>>  175          * computation below must be changed if MIN_MERGE is
>>>>>>>>> decreased.  See
>>>>>>>>>  176          * the MIN_MERGE declaration above for more
>>>>>>>>> information.
>>>>>>>>> +             * The maximum value of 49 allows for an array up to
>>>>>>>>> length
>>>>>>>>> +             * Integer.MAX_VALUE-4.
>>>>>>>>>
>>>>>>>>>> Roger, David,
>>>>>>>>>> I've updated the test (
>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ) to make it more suitable for regular execution:
>>>>>>>>>>
>>>>>>>>>>    27  * @run main/othervm TimSortStackSize2 67108864
>>>>>>>>>
>>>>>>>>> This will still fail on small memory devices:
>>>>>>>>>
>>>>>>>>> :~> java TimSortStackSize2 67108864
>>>>>>>>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap
>>>>>>>>> space
>>>>>>>>>
>>>>>>>>> as the default heap ergonomics may not be large enough. I had to
>>>>>>>>> add a
>>>>>>>>> minimum heap of -Xmx385M to get it to run.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>>    28  * not for regular execution on all platforms:
>>>>>>>>>>    29  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>>>>>>    30  * run main/othervm -Xmx32g TimSortStackSize2 2147483644
>>>>>>>>>>
>>>>>>>>>> Could you please push this:
>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>>>>>>>>>> ?
>>>>>>>>>>
>>>>>>>>>> Lev
>>>>>>>>>>
>>>>>>>>>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>>>>>>>>>> On Feb 12, 9:57pm,david.holmes at oracle.com  (David Holmes) 
>>>>>>>>>>> wrote:
>>>>>>>>>>> -- Subject: Re: 8072909: TimSort fails with
>>>>>>>>>>> ArrayIndexOutOfBoundsException on
>>>>>>>>>>>
>>>>>>>>>>> | Ok - thanks Lev!
>>>>>>>>>>> |
>>>>>>>>>>> | David
>>>>>>>>>>>
>>>>>>>>>>> For posterity can someone document this, and also the value for
>>>>>>>>>>> which
>>>>>>>>>>> Integer.MAX_VALUE-4 fails?
>>>>>>>>>>>
>>>>>>>>>>> christos
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>
>



From daniel.fuchs at oracle.com  Thu Feb 19 14:01:18 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 19 Feb 2015 15:01:18 +0100
Subject: Logging FileHandler: static locks and hardcoded maximum number
In-Reply-To: <CAEEKBgXjm71hBjhHGnDs4A2wLiBXndQFuLWEh3ScaVZcDY1TNQ@mail.gmail.com>
References: <CAEEKBgU_-i1ki3bJTBQh7Q0K7NU4xgzmn=FbaRP+TJzgbgFS4A@mail.gmail.com>
	<54E5D1AC.7050607@oracle.com>
	<CAEEKBgXjm71hBjhHGnDs4A2wLiBXndQFuLWEh3ScaVZcDY1TNQ@mail.gmail.com>
Message-ID: <54E5ECAE.4070000@oracle.com>

Hi Behrooz,

On 19/02/15 13:46, Behrooz Nobakht wrote:
> The version of Java is irrelevant. We have tested our setup
> on Java 7 and Java 8 u25/31. We observe the same exception.
>

Ok - then the version is indeed relevant ;-)

What you are observing may be a symptom of
https://bugs.openjdk.java.net/browse/JDK-8048020
which was fixed in 8u40 build 6.

If you would like to verify that this bug is indeed
what is causing your issue, you may want to try out
your setup with an early access build of 8u40, and
see if the problem disappears.

Early access of 8u40 may be downloaded from there:
https://jdk8.java.net/download.html


best regards,

-- daniel


From nobeh5 at gmail.com  Thu Feb 19 14:29:27 2015
From: nobeh5 at gmail.com (Behrooz Nobakht)
Date: Thu, 19 Feb 2015 15:29:27 +0100
Subject: Logging FileHandler: static locks and hardcoded maximum number
In-Reply-To: <54E5ECAE.4070000@oracle.com>
References: <CAEEKBgU_-i1ki3bJTBQh7Q0K7NU4xgzmn=FbaRP+TJzgbgFS4A@mail.gmail.com>
	<54E5D1AC.7050607@oracle.com>
	<CAEEKBgXjm71hBjhHGnDs4A2wLiBXndQFuLWEh3ScaVZcDY1TNQ@mail.gmail.com>
	<54E5ECAE.4070000@oracle.com>
Message-ID: <CAEEKBgVPGjFd8kK7QVDahcxUm71dFiLoEO_B_ROAgps3e6quHw@mail.gmail.com>

Hi Daniel,

Thanks for referring to this ticket.
Here is what I did.

My Java version:

java version "1.8.0_40-ea"
Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b21)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b24, mixed mode)

So, to make this more observable.
The p1 process invokes a command with p2: start and stop.
So, with 50 pairs of start and stop, we should be able to see the problem
again.

I ran a script that invokes start from p1, gets the status of p2, stops p2
and confirms its status again.
Here's the output from run 49:

===
run 49
Invoking Start
RUNNING
Invoking Stop
STOPPED
run 49 - Done
run 50
Invoking Start
RUNNING
Invoking Stop
STOPPED
run 50 - Done
run 51
Invoking Start
RUNNING
Invoking Stop
RUNNING
run 51 - Done
run 52
Invoking Start
STOPPED
Invoking Stop
STOPPED
run 52 - Done
run 53
Invoking Start
STOPPED
Invoking Stop
STOPPED
run 53 - Done
run 54
Invoking Start
STOPPED
Invoking Stop
STOPPED
run 54 - Done
===

As the above shows, starting run 51, the expected status is violated.
And, here is what I get a lsof of the log directory on the application:

===
-rw-rw-r-- 1 appuser appuser    0 Feb 19 15:19 app.stdouterr.100.0.log.lck
-rw-rw-r-- 1 appuser appuser 3.0K Feb 19 15:19 app.stdouterr.100.0.log
-rw-rw-r-- 1 appuser appuser    0 Feb 19 15:16 app.stdouterr.0.0.log.lck
-rw-rw-r-- 1 appuser appuser  366 Feb 19 15:16 app.stdouterr.0.0.log
===

Thanks for your time on this,
Behrooz





On Thu, Feb 19, 2015 at 3:01 PM, Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi Behrooz,
>
> On 19/02/15 13:46, Behrooz Nobakht wrote:
>
>> The version of Java is irrelevant. We have tested our setup
>> on Java 7 and Java 8 u25/31. We observe the same exception.
>>
>>
> Ok - then the version is indeed relevant ;-)
>
> What you are observing may be a symptom of
> https://bugs.openjdk.java.net/browse/JDK-8048020
> which was fixed in 8u40 build 6.
>
> If you would like to verify that this bug is indeed
> what is causing your issue, you may want to try out
> your setup with an early access build of 8u40, and
> see if the problem disappears.
>
> Early access of 8u40 may be downloaded from there:
> https://jdk8.java.net/download.html
>
>
> best regards,
>
> -- daniel
>



-- 
-- Behrooz Nobakht


From aleksey.shipilev at oracle.com  Thu Feb 19 14:51:59 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 19 Feb 2015 17:51:59 +0300
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
Message-ID: <54E5F88F.6030502@oracle.com>

Hi,

Please review and sponsor this cleanup fix:
  http://cr.openjdk.java.net/~shade/8073479/webrev.00/
  https://bugs.openjdk.java.net/browse/JDK-8073479

Summary: use Objects.requireNonNull instead of object.getClass to check
for nullity.

Testing:
  - jdk9-dev build on Linux x86_64/release
  - JPRT (modulo some freetype and javac failures)

Thank you,
-Aleksey.

P.S. I am going to submit another one against langtools, should it be
reviewed on this list as well?



From daniel.fuchs at oracle.com  Thu Feb 19 14:56:30 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 19 Feb 2015 15:56:30 +0100
Subject: Logging FileHandler: static locks and hardcoded maximum number
In-Reply-To: <CAEEKBgVPGjFd8kK7QVDahcxUm71dFiLoEO_B_ROAgps3e6quHw@mail.gmail.com>
References: <CAEEKBgU_-i1ki3bJTBQh7Q0K7NU4xgzmn=FbaRP+TJzgbgFS4A@mail.gmail.com>
	<54E5D1AC.7050607@oracle.com>
	<CAEEKBgXjm71hBjhHGnDs4A2wLiBXndQFuLWEh3ScaVZcDY1TNQ@mail.gmail.com>
	<54E5ECAE.4070000@oracle.com>
	<CAEEKBgVPGjFd8kK7QVDahcxUm71dFiLoEO_B_ROAgps3e6quHw@mail.gmail.com>
Message-ID: <54E5F99E.8000404@oracle.com>

Thanks Behrooz.

Could you log an issue for this then?
If you can attach a small reproducer it will be helpful.

There are a bunch of unit tests in the JDK that verify
that FileHandler .lck files are correctly deleted - but
these tests are all mono-process. I would like to make
sure to chase down the real issue - so a small isolated
reproducer would definitely help.

best regards,

-- daniel

On 19/02/15 15:29, Behrooz Nobakht wrote:
> Hi Daniel,
>
> Thanks for referring to this ticket.
> Here is what I did.
>
> My Java version:
>
> java version "1.8.0_40-ea"
> Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b21)
> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b24, mixed mode)
>
> So, to make this more observable.
> The p1 process invokes a command with p2: start and stop.
> So, with 50 pairs of start and stop, we should be able to see the
> problem again.
>
> I ran a script that invokes start from p1, gets the status of p2, stops
> p2 and confirms its status again.
> Here's the output from run 49:
>
> ===
> run 49
> Invoking Start
> RUNNING
> Invoking Stop
> STOPPED
> run 49 - Done
> run 50
> Invoking Start
> RUNNING
> Invoking Stop
> STOPPED
> run 50 - Done
> run 51
> Invoking Start
> RUNNING
> Invoking Stop
> RUNNING
> run 51 - Done
> run 52
> Invoking Start
> STOPPED
> Invoking Stop
> STOPPED
> run 52 - Done
> run 53
> Invoking Start
> STOPPED
> Invoking Stop
> STOPPED
> run 53 - Done
> run 54
> Invoking Start
> STOPPED
> Invoking Stop
> STOPPED
> run 54 - Done
> ===
>
> As the above shows, starting run 51, the expected status is violated.
> And, here is what I get a lsof of the log directory on the application:
>
> ===
> -rw-rw-r-- 1 appuser appuser    0 Feb 19 15:19 app.stdouterr.100.0.log.lck
> -rw-rw-r-- 1 appuser appuser 3.0K Feb 19 15:19 app.stdouterr.100.0.log
> -rw-rw-r-- 1 appuser appuser    0 Feb 19 15:16 app.stdouterr.0.0.log.lck
> -rw-rw-r-- 1 appuser appuser  366 Feb 19 15:16 app.stdouterr.0.0.log
> ===
>
> Thanks for your time on this,
> Behrooz
>
>
>
>
>
> On Thu, Feb 19, 2015 at 3:01 PM, Daniel Fuchs <daniel.fuchs at oracle.com
> <mailto:daniel.fuchs at oracle.com>> wrote:
>
>     Hi Behrooz,
>
>     On 19/02/15 13:46, Behrooz Nobakht wrote:
>
>         The version of Java is irrelevant. We have tested our setup
>         on Java 7 and Java 8 u25/31. We observe the same exception.
>
>
>     Ok - then the version is indeed relevant ;-)
>
>     What you are observing may be a symptom of
>     https://bugs.openjdk.java.net/__browse/JDK-8048020
>     <https://bugs.openjdk.java.net/browse/JDK-8048020>
>     which was fixed in 8u40 build 6.
>
>     If you would like to verify that this bug is indeed
>     what is causing your issue, you may want to try out
>     your setup with an early access build of 8u40, and
>     see if the problem disappears.
>
>     Early access of 8u40 may be downloaded from there:
>     https://jdk8.java.net/__download.html
>     <https://jdk8.java.net/download.html>
>
>
>     best regards,
>
>     -- daniel
>
>
>
>
> --
> -- Behrooz Nobakht



From peter.levart at gmail.com  Thu Feb 19 14:59:02 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 19 Feb 2015 15:59:02 +0100
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E5F88F.6030502@oracle.com>
References: <54E5F88F.6030502@oracle.com>
Message-ID: <54E5FA36.7030206@gmail.com>

On 02/19/2015 03:51 PM, Aleksey Shipilev wrote:
> Hi,
>
> Please review and sponsor this cleanup fix:
>    http://cr.openjdk.java.net/~shade/8073479/webrev.00/
>    https://bugs.openjdk.java.net/browse/JDK-8073479
>
> Summary: use Objects.requireNonNull instead of object.getClass to check
> for nullity.
>
> Testing:
>    - jdk9-dev build on Linux x86_64/release
>    - JPRT (modulo some freetype and javac failures)
>
> Thank you,
> -Aleksey.
>
> P.S. I am going to submit another one against langtools, should it be
> reviewed on this list as well?
>

Hi Aleksey,

Is profile pollution problem already fixed? Can Objects.requireNonNull 
be used in performance critical code without fear of performance regression?

Peter



From aleksey.shipilev at oracle.com  Thu Feb 19 15:02:31 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 19 Feb 2015 18:02:31 +0300
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E5FA36.7030206@gmail.com>
References: <54E5F88F.6030502@oracle.com> <54E5FA36.7030206@gmail.com>
Message-ID: <54E5FB07.6030400@oracle.com>

Hi Peter,

On 02/19/2015 05:59 PM, Peter Levart wrote:
> On 02/19/2015 03:51 PM, Aleksey Shipilev wrote:
>> Hi,
>>
>> Please review and sponsor this cleanup fix:
>>    http://cr.openjdk.java.net/~shade/8073479/webrev.00/
>>    https://bugs.openjdk.java.net/browse/JDK-8073479
>>
>> Summary: use Objects.requireNonNull instead of object.getClass to check
>> for nullity.
>>
>> Testing:
>>    - jdk9-dev build on Linux x86_64/release
>>    - JPRT (modulo some freetype and javac failures)
>>
>> Thank you,
>> -Aleksey.
>>
>> P.S. I am going to submit another one against langtools, should it be
>> reviewed on this list as well?
>>
> 
> Hi Aleksey,
> 
> Is profile pollution problem already fixed? Can Objects.requireNonNull
> be used in performance critical code without fear of performance
> regression?

What profile pollution? Objects.requireNonNull is a static method. See
also the link in bug description:
  http://cr.openjdk.java.net/~shade/scratch/NullChecks.java

-Aleksey.



From daniel.fuchs at oracle.com  Thu Feb 19 15:03:41 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 19 Feb 2015 16:03:41 +0100
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E5F88F.6030502@oracle.com>
References: <54E5F88F.6030502@oracle.com>
Message-ID: <54E5FB4D.1040402@oracle.com>

Hi Aleksey,

+1 for the java.logging changes :-)

I wonder whether there was a subtle reason for calling
.getClass() in java.lang.invoke? Maybe class initialization
or whatever?

best regards,

-- daniel

On 19/02/15 15:51, Aleksey Shipilev wrote:
> Hi,
>
> Please review and sponsor this cleanup fix:
>    http://cr.openjdk.java.net/~shade/8073479/webrev.00/
>    https://bugs.openjdk.java.net/browse/JDK-8073479
>
> Summary: use Objects.requireNonNull instead of object.getClass to check
> for nullity.
>
> Testing:
>    - jdk9-dev build on Linux x86_64/release
>    - JPRT (modulo some freetype and javac failures)
>
> Thank you,
> -Aleksey.
>
> P.S. I am going to submit another one against langtools, should it be
> reviewed on this list as well?
>



From vitalyd at gmail.com  Thu Feb 19 15:05:56 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 19 Feb 2015 10:05:56 -0500
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E5FB07.6030400@oracle.com>
References: <54E5F88F.6030502@oracle.com> <54E5FA36.7030206@gmail.com>
	<54E5FB07.6030400@oracle.com>
Message-ID: <CAHjP37Ej-taQq+LJ68w0xGvPmwXGT7vSMO20oDkTz=3gQ7UdFg@mail.gmail.com>

There was a thread some months back on this and I think it was shown that
profile pollution does impact this.  If the requireNonNull sees nulls it
won't use implicit null check.

sent from my phone
On Feb 19, 2015 10:03 AM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
wrote:

> Hi Peter,
>
> On 02/19/2015 05:59 PM, Peter Levart wrote:
> > On 02/19/2015 03:51 PM, Aleksey Shipilev wrote:
> >> Hi,
> >>
> >> Please review and sponsor this cleanup fix:
> >>    http://cr.openjdk.java.net/~shade/8073479/webrev.00/
> >>    https://bugs.openjdk.java.net/browse/JDK-8073479
> >>
> >> Summary: use Objects.requireNonNull instead of object.getClass to check
> >> for nullity.
> >>
> >> Testing:
> >>    - jdk9-dev build on Linux x86_64/release
> >>    - JPRT (modulo some freetype and javac failures)
> >>
> >> Thank you,
> >> -Aleksey.
> >>
> >> P.S. I am going to submit another one against langtools, should it be
> >> reviewed on this list as well?
> >>
> >
> > Hi Aleksey,
> >
> > Is profile pollution problem already fixed? Can Objects.requireNonNull
> > be used in performance critical code without fear of performance
> > regression?
>
> What profile pollution? Objects.requireNonNull is a static method. See
> also the link in bug description:
>   http://cr.openjdk.java.net/~shade/scratch/NullChecks.java
>
> -Aleksey.
>
>


From dmitry.samersoff at oracle.com  Thu Feb 19 15:15:19 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 19 Feb 2015 18:15:19 +0300
Subject: RFR(S): JDK-8073175,
	8073174: Fix native warnings in libjli and libfdlibm
Message-ID: <54E5FE07.8000501@oracle.com>

(PING) Hi Everyone,

It's my $0.02 to the warning cleanup work. Please review:

http://cr.openjdk.java.net/~dsamersoff/JDK-8073175/webrev.01
http://cr.openjdk.java.net/~dsamersoff/JDK-8073174/webrev.01

Notes:

1.
There are two common ways to cast pointer to int: intptr_t (perfectly
safe, more-or-less portable) and size_t (perfectly portable,
more-or-less safe)

Use intptr_t everywhere but it costs explicit #ifdef __WINDOWS__ in
splashscreen_stubs.c

2.
I didn't fix "format not a string literal" warnings. It requires to set
per-compiler pragmas.

-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 aleksey.shipilev at oracle.com  Thu Feb 19 15:16:29 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 19 Feb 2015 18:16:29 +0300
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <CAHjP37Ej-taQq+LJ68w0xGvPmwXGT7vSMO20oDkTz=3gQ7UdFg@mail.gmail.com>
References: <54E5F88F.6030502@oracle.com>	<54E5FA36.7030206@gmail.com>	<54E5FB07.6030400@oracle.com>
	<CAHjP37Ej-taQq+LJ68w0xGvPmwXGT7vSMO20oDkTz=3gQ7UdFg@mail.gmail.com>
Message-ID: <54E5FE4D.2090207@oracle.com>

Okay, I see
 https://bugs.openjdk.java.net/browse/JDK-8042127

...but there is no analysis what's actually going on, so I tend to doubt
what the issue is about. Let me quickly follow up there.

-Aleksey.

On 02/19/2015 06:05 PM, Vitaly Davidovich wrote:
> There was a thread some months back on this and I think it was shown
> that profile pollution does impact this.  If the requireNonNull sees
> nulls it won't use implicit null check.
> 
> sent from my phone
> 
> On Feb 19, 2015 10:03 AM, "Aleksey Shipilev"
> <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>> wrote:
> 
>     Hi Peter,
> 
>     On 02/19/2015 05:59 PM, Peter Levart wrote:
>     > On 02/19/2015 03:51 PM, Aleksey Shipilev wrote:
>     >> Hi,
>     >>
>     >> Please review and sponsor this cleanup fix:
>     >>    http://cr.openjdk.java.net/~shade/8073479/webrev.00/
>     <http://cr.openjdk.java.net/%7Eshade/8073479/webrev.00/>
>     >>    https://bugs.openjdk.java.net/browse/JDK-8073479
>     >>
>     >> Summary: use Objects.requireNonNull instead of object.getClass to
>     check
>     >> for nullity.
>     >>
>     >> Testing:
>     >>    - jdk9-dev build on Linux x86_64/release
>     >>    - JPRT (modulo some freetype and javac failures)
>     >>
>     >> Thank you,
>     >> -Aleksey.
>     >>
>     >> P.S. I am going to submit another one against langtools, should it be
>     >> reviewed on this list as well?
>     >>
>     >
>     > Hi Aleksey,
>     >
>     > Is profile pollution problem already fixed? Can Objects.requireNonNull
>     > be used in performance critical code without fear of performance
>     > regression?
> 
>     What profile pollution? Objects.requireNonNull is a static method. See
>     also the link in bug description:
>       http://cr.openjdk.java.net/~shade/scratch/NullChecks.java
>     <http://cr.openjdk.java.net/%7Eshade/scratch/NullChecks.java>
> 
>     -Aleksey.
> 




From aleksey.shipilev at oracle.com  Thu Feb 19 15:17:20 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 19 Feb 2015 18:17:20 +0300
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E5FB4D.1040402@oracle.com>
References: <54E5F88F.6030502@oracle.com> <54E5FB4D.1040402@oracle.com>
Message-ID: <54E5FE80.8030806@oracle.com>

Hi Daniel,

On 02/19/2015 06:03 PM, Daniel Fuchs wrote:
> +1 for the java.logging changes :-)

Good, thank you!

> I wonder whether there was a subtle reason for calling
> .getClass() in java.lang.invoke? Maybe class initialization
> or whatever?

As far as I understand, if you are checking the argument, then it means
you are being handed over the object instance, then somebody already did
the instantiation, which means the class representing the object is
already initialized.

I think getClass() is just a trick employed in the absence of
Objects.requireNonNull.

Thanks,
-Aleksey.



From peter.levart at gmail.com  Thu Feb 19 15:17:28 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 19 Feb 2015 16:17:28 +0100
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E5FB07.6030400@oracle.com>
References: <54E5F88F.6030502@oracle.com> <54E5FA36.7030206@gmail.com>
	<54E5FB07.6030400@oracle.com>
Message-ID: <54E5FE88.4000705@gmail.com>

On 02/19/2015 04:02 PM, Aleksey Shipilev wrote:
>> >Hi Aleksey,
>> >
>> >Is profile pollution problem already fixed? Can Objects.requireNonNull
>> >be used in performance critical code without fear of performance
>> >regression?
> What profile pollution? Objects.requireNonNull is a static method. See
> also the link in bug description:
>    http://cr.openjdk.java.net/~shade/scratch/NullChecks.java
>
> -Aleksey.
>

Remi described it here:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026669.html


Peter



From daniel.fuchs at oracle.com  Thu Feb 19 15:19:26 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 19 Feb 2015 16:19:26 +0100
Subject: RFR: 8072645: java.util.logging should use java.time to get more
	precise time stamps
In-Reply-To: <CACzrW9BGGELXh5ZJEc2VEA9VktzZP_4Njod1gWp5JB4dPe2K4Q@mail.gmail.com>
References: <54DE109C.4030307@oracle.com>	<CACzrW9BgsCVZvZKdd=+1rEao1V7bSg7N_QJD0BpJsaywJAj2-A@mail.gmail.com>	<54DF47B9.4050304@oracle.com>
	<54E243DF.3060107@oracle.com>	<54E3977B.4060701@oracle.com>
	<CACzrW9BGGELXh5ZJEc2VEA9VktzZP_4Njod1gWp5JB4dPe2K4Q@mail.gmail.com>
Message-ID: <54E5FEFE.5040109@oracle.com>

On 18/02/15 12:11, Stephen Colebourne wrote:
> In LogRecord, the Javadoc of getInstant():
> "Get event time."
> could be
> "Gets the instant that the event ocurred."

done.

> In LogRecord, the Javadoc of setInstant():
> "Set event time."
> could be
> "Sets the instant that the event ocurred."
> (matching change to @param)

done.


> I'd prefer to see the other methods in the class have their Javadoc
> changed from "Get" to Gets" and from "Set" to "Sets" to conform with
> Javadoc norms, but understand if this causes CCC issues.

Agreed - but I will need to obtain a CCC approval for this change,
and I'd prefer to leave the specdiff uncluttered.
I will log an RFE for a doc cleanup.


> In PlatformLogger.
> There should be no need to assign to a static constant:
>   private static final Clock systemUTC = Clock.systemUTC();
> However, Clock.systemUTC() needs to be fixed:
> https://bugs.openjdk.java.net/browse/JDK-8073394

Ahah. I hadn't seen this RFE. Thanks for pointing it out.
This RFE (JDK-8073394) won't need any CCC so it should be an easy
quick fix. Given that, I agree that it's better to remove the
static systemUTC fields (removed from PlatformLogger and LogRecord).
I will also take care of JDK-8073394 later on then.


> This
>   ZonedDateTime zdt = ZonedDateTime.ofInstant(systemUTC.instant(), zoneId);
> can be replaced with
>   ZonedDateTime zdt = ZonedDateTime.now(zoneId);

done.

> Again, the implementation of the better method isn't perfectly optimised.
>
> The default format used in String.format does not need to time-zone,
> just the local date/time. As such, in theory a LocalDateTime could be
> used. But, since the format can be changed by the user, a
> ZonedDateTime is needed (probably not worth being clever here).

Yes - that was my reasoning too. ZonedDateTime seems to be the
more resilient to format changes.

> Where you assign ZoneId.systemDefault() to a final instance variable,
> it is being locked for the lifetime of that object. I cannot
> immediately tell what the lifetime of the objects are. I also suspect
> that few if any will want to change their time-zone half way through
> logging.

I don't think we should bother with this possibility.

The PlatformLogger's simple logger may either never be
released (if JUL is not used - meaning, if there is no user
specified logging.properties file and if nobody calls
LogManager.getLogManager()) - or it will be replaced by a
plain logger - in which case the j.u.l.Formatter will
be used - and the j.u.l.Formatter will usually have the
same life-time than the Handler on which it is set.
(usually, until reset() or readConfiguration() is called).


> XMLFormatter has a reviewer's comment that will need to be removed
> before committing.

Will do before pushing. At the moment I'm still hoping it will catch
the eye of an XML/DTD expert :-)

> In LogRecordWithNanosAPI you check the instant contents rather than
> just the instant:
>   assertEquals(record.getInstant().getEpochSecond(),
> record2.getInstant().getEpochSecond(),
> "getInstant().getEpochSecond()");
>   assertEquals(record.getInstant().getNano(),
> record2.getInstant().getNano(), "getInstant().getNano()");
>   assertEquals(record.getInstant().toEpochMilli(),
> record2.getInstant().toEpochMilli(), "getInstant().toEpochMilli()");
> could be
>   assertEquals(record.getInstant(), record2.getInstant(), "getInstant()");
> There are probably other instances of this point.

Right. I'm not very motivated to change the LogRecord* tests.
What happened is that I wrote these tests based on the use of
LogRecord.setMillis/getMillis and
LogRecord.getNanoAdjustment/setNanoAdjustment - and then had to
update them when we decided to drop
LogRecord.getNanoAdjustment/setNanoAdjustment and changed the
implementation of getMillis/setMillis to work on top of instant.

As a consequence, the test have probably become a bit more complex
and cluttered than they would have been if I had written them
directly against the later version of the API.

However I believe they still do the job - I have been careful
to add some additional tests to verify the new implementation of
getMillis/setMillis - I don't believe I left any cracks.

The important point is to verify the consistency of getMillis/getInstant
and setMillis/setInstant as well as checking that nothing is lost
in the serialization - I believe the tests are good enough in that
respect.

> Hope that helps

It does! I am grateful :-)

Here is the updated webrev.
http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.02/

best regards,

-- daniel

> Stephen
>
>
>
> On 17 February 2015 at 19:33, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>> Hi,
>>
>> Here is a new webrev - which should contain all the feedback received
>> so far:
>>
>> #1 LogRecord uses serialPersistentFields for serialization, and
>>     contains an Instant instead of the two fields millis +
>>     nanoAdjustment.
>> #2 getMillis/setMillis are deprecated, replaced by getInstant/setInstant
>>     getNanoAdjustment/setNanoAdjustment have been dropped.
>>
>> [Thanks Peter for prototyping these 2 first changes!]
>>
>> #3 XMLFormatter uses ISO_INSTANT to print the instant in the date field.
>>     new constructor has been dropped. printNanos property is renamed into
>>     useInstant.
>> #4 SimpleFormatter still uses ZonedDateTime - for compatibility and
>>     flexibility and because it proved to be faster than Date [1].
>> #5 Tests have been updated WRT to the changes above.
>> #6 various doc tweaks compared to last webrev
>>
>> new webrev:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.01/
>>
>> specdiff updated in place (unfortunately the serial form does
>> not show up):
>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/specdiff-logging-time/overview-summary.html
>>
>> best regards,
>>
>> -- daniel
>>
>> [1] benchmarks related to formatting the date:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html
>>
>>
>>
>> On 16/02/15 20:24, Daniel Fuchs wrote:
>>>
>>> Hi Stephen,
>>>
>>> Thanks again for your support and suggestions!
>>>
>>> On 14/02/15 14:03, Daniel Fuchs wrote:
>>>>
>>>> If I'm not mistaken the previous SimpleFormatter used to use
>>>> java.util.Date
>>>> and printed the time in the local time zone. I have tried to keep this
>>>> behavior.
>>>> I'm not sure we would want to change it to print the time in the UTC
>>>> time zone
>>>> by default. A lot of developers use logging for debugging - and when
>>>> reading
>>>> debug messages on the console I usually prefer to see the time in my own
>>>> time zone.
>>>>
>>>> Would there be a more efficient way to keep the default formatting of
>>>> the time
>>>> in the SimpleFormatter?
>>>
>>>
>>> I spent part of the day reading the documentation & trying out the
>>> various TemporalAccessors and DateTimeFormatters...
>>>
>>> I have also done some microbenchmark measurements (jmh) WRT
>>> the performance  of formatting a date/time.
>>> Results can be seen here [1]:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html
>>>
>>> What it shows is that when using String.format (as the SimpleFormatter
>>> is specified to do), then using ZonedDateTime is actually an improvement
>>> over using Date.
>>>
>>> Now that I have read a bit more about LocalDateTime, ZonedDateTime,
>>> Date, and Instant, I do agree with you that for recording an event time,
>>> printing the Instant is the better alternative.
>>> However, since SimpleFormatter has always printed the local date,
>>> I would tend to want to keep it that way.
>>>
>>> So I'm going to propose to keep using ZonedDateTime in
>>> the SimpleFormatter, as I believe it's what gives it the maximum of
>>> flexibility - WRT to using String.format (+ we will get some
>>> boost as bonus by no longer using Date).
>>> If you strongly feel that java.util.logging should offer a better
>>> alternative - then maybe we should log an RFE to explore it?
>>>
>>> Things are - I believe - a bit different for the XMLFormatter.
>>> First, the XMLFormatter is not specified to use String.format, so
>>> it gives us a bit more flexibility.
>>> In addition we already need to tweak the format in order to introduce
>>> the new <nanos> element - (or should it be <nanoOfMilli> as Peter
>>> suggested?).
>>>
>>> So for the XMLFormatter, and given the results of my
>>> microbenchmark [1], here is what I would suggest:
>>>
>>> #1 rename the property printNanos into useInstant
>>> #2 if useInstant is false, use the old code for formatting the
>>>      date (the old appendISO8601() method) and omit the <nanos>
>>>      element - so applications that specify useInstant=false should
>>>      see the same formatting than before, without paying the
>>>      performance cost that using ZonedDateTime would bring.
>>> #3 if useInstant is absent - or not false, then we use the 'new'
>>>      format. The <date> element will contain the instant printed
>>>      using DateTimeFormatter.ISO_INSTANT, and the <nanos> element
>>>      will be printed after <millis>
>>>
>>> Does that sound right? If so I will include these changes in my
>>> next webrev, once I have digested the feedback sent by Peter :-)
>>>
>>> Best regards,
>>>
>>> -- daniel
>>>
>>> [1] microbenchmark:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html
>>>
>>>
>>>>
>>>>> (The webrev is broken wrt zones as it stores ZoneId.systemDefault() in a
>>>>> static constant, but that method depends on the mutable
>>>>> TimeZone.getDefault() ).
>>>>
>>>>
>>>> Would making it a final (non static) variable be better?
>>>> I now wonder whether there should be a way to configure the time zone for
>>>> an instance of SimpleFormatter (something like what I did with
>>>> 'printNanos'
>>>> for the XMLFormatter).
>>>>
>>>>> LogReecord.getInstantUTC() should be getInstant().
>>>>>
>>>>> (An Instant is fully defined as a concept, and it cannot be in or not in
>>>>> UTC).
>>>>
>>>>
>>>> Right. Thanks for pointing that out.
>>>>>
>>>>> In SimpleFormatter, you have {@code java.util.loggin} (missing a "g").
>>>>
>>>>
>>>> Good catch.
>>>>
>>>>> In XMLFormatter, instead of using DateTimeFormatter.ISO_LOCAL_DATE_TIME,
>>>>> create a new instance of DateTimeFormatter that does not output the
>>>>> fraction of a second. That way, there is no need to use
>>>>> truncatedTo(SECONDS).
>>>>>
>>>>> StringBuilder appends can be used directly with formatters:
>>>>>
>>>>> sb.append(ZonedDateTime.ofInstant(time, zoneId).format(dtformatter));
>>>>>
>>>>> replace with
>>>>>
>>>>> dtformatter.formatTo(ZonedDateTime.ofInstant(time, zoneId), sb);
>>>>
>>>>
>>>> Will look into this.
>>>>
>>>> Thanks again for your review! This is quite helpful.
>>>>
>>>> -- daniel
>>>>
>>>>
>>>>>
>>>>> thanks
>>>>> Stephen
>>>>>
>>>>>
>>>>>
>>>>> On 13 Feb 2015 14:57, "Daniel Fuchs" <daniel.fuchs at oracle.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Please find below a patch for:
>>>>>>
>>>>>> 8072645: java.util.logging should use java.time to get more
>>>>>>            precise time stamps
>>>>>>
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/
>>>>>>
>>>>>> specdiff:
>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/
>>>>>> specdiff-logging-time/java/util/logging/package-summary.html
>>>>>>
>>>>>> Overview:
>>>>>> ---------
>>>>>>
>>>>>> The patch is made of the following pieces:
>>>>>>
>>>>>>    - LogRecord uses java.time.Clock's systemClock to get an
>>>>>>      Instant in the best available resolution.
>>>>>>
>>>>>>      The instant is split into a number of milliseconds (a long)
>>>>>>      and a nanosecond adjustment (an int).
>>>>>>      The number of milliseconds is the same than what would have
>>>>>>      been obtained by calling System.currentTimeMillis().
>>>>>>
>>>>>>    - LogRecord acquires a new serializable int nanoAdjustement field,
>>>>>>      which can be used together with the number of milliseconds
>>>>>>      to reconstruct the instant.
>>>>>>
>>>>>>    - SimpleFormatter is updated to pass a ZoneDateTime
>>>>>>      instance to String.format, instead of a Date.
>>>>>>
>>>>>>      The effect of that is that the format string can now
>>>>>>      be configure to print the full instant precision, if
>>>>>>      needed.
>>>>>>
>>>>>>    - XMLformatter will add a new <nanos> element after the
>>>>>>      <millis> element - if the value of the nanoAdjustment
>>>>>>      field is not 0.
>>>>>>
>>>>>>      The <date> string will also contain the nano second
>>>>>>      adjustment as well as the zone offset as formatted by
>>>>>>      DateTimeFormatter.ISO_OFFSET_DATE_TIME
>>>>>>
>>>>>> Compatibility considerations:
>>>>>> -----------------------------
>>>>>>
>>>>>> - The serial for of log record is backward/forward compatible.
>>>>>>     I added a test to verify that.
>>>>>>
>>>>>> - XMLFormatter has acquired a new configurable property
>>>>>>     '<FQCN>.printNanos' which allows to revert to the old
>>>>>>     XML format, should the new format cause issues in
>>>>>>     existing applications.
>>>>>>
>>>>>> - The logger.dtd will need to be updated, to support the
>>>>>>     new optional <nanos> element. And for this matter,
>>>>>>     should we update the logger.dtd or rather define a
>>>>>>     logger-v2.dtd?
>>>>>>     See planned modification:
>>>>>>
>>>>>> <http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-
>>>>>> dtd/logger.dtd.frames.html>
>>>>>>
>>>>>> best regards,
>>>>>>
>>>>>> -- daniel
>>>>>>
>>>>
>>>
>>



From vitalyd at gmail.com  Thu Feb 19 15:21:31 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 19 Feb 2015 10:21:31 -0500
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E5FE88.4000705@gmail.com>
References: <54E5F88F.6030502@oracle.com> <54E5FA36.7030206@gmail.com>
	<54E5FB07.6030400@oracle.com> <54E5FE88.4000705@gmail.com>
Message-ID: <CAHjP37HGq_sQ1UVyHum8bz3pRQmqzB8m-fxMe6LXJifzaYvSig@mail.gmail.com>

Does anyone know which changesets Remi was referring to in jdk9 that
fix/mitigate this?

On Thu, Feb 19, 2015 at 10:17 AM, Peter Levart <peter.levart at gmail.com>
wrote:

> On 02/19/2015 04:02 PM, Aleksey Shipilev wrote:
>
>> >Hi Aleksey,
>>> >
>>> >Is profile pollution problem already fixed? Can Objects.requireNonNull
>>> >be used in performance critical code without fear of performance
>>> >regression?
>>>
>> What profile pollution? Objects.requireNonNull is a static method. See
>> also the link in bug description:
>>    http://cr.openjdk.java.net/~shade/scratch/NullChecks.java
>>
>> -Aleksey.
>>
>>
> Remi described it here:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-
> April/026669.html
>
>
> Peter
>
>


From nobeh5 at gmail.com  Thu Feb 19 15:30:34 2015
From: nobeh5 at gmail.com (Behrooz Nobakht)
Date: Thu, 19 Feb 2015 16:30:34 +0100
Subject: Logging FileHandler: static locks and hardcoded maximum number
In-Reply-To: <54E5F99E.8000404@oracle.com>
References: <CAEEKBgU_-i1ki3bJTBQh7Q0K7NU4xgzmn=FbaRP+TJzgbgFS4A@mail.gmail.com>
	<54E5D1AC.7050607@oracle.com>
	<CAEEKBgXjm71hBjhHGnDs4A2wLiBXndQFuLWEh3ScaVZcDY1TNQ@mail.gmail.com>
	<54E5ECAE.4070000@oracle.com>
	<CAEEKBgVPGjFd8kK7QVDahcxUm71dFiLoEO_B_ROAgps3e6quHw@mail.gmail.com>
	<54E5F99E.8000404@oracle.com>
Message-ID: <CAEEKBgXjkxvmDkp1-zUmBRSpE=xoJKKShewiRUh5G5z87zfEoQ@mail.gmail.com>

I'd be very happy to introduce an issue. But,
I've always failed to be able to create an account on
https://bugs.openjdk.java.net/secure/Dashboard.jspa
so, for me, the starting point is where I should do this?!

On Thu, Feb 19, 2015 at 3:56 PM, Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Thanks Behrooz.
>
> Could you log an issue for this then?
> If you can attach a small reproducer it will be helpful.
>
> There are a bunch of unit tests in the JDK that verify
> that FileHandler .lck files are correctly deleted - but
> these tests are all mono-process. I would like to make
> sure to chase down the real issue - so a small isolated
> reproducer would definitely help.
>
> best regards,
>
> -- daniel
>
>
> On 19/02/15 15:29, Behrooz Nobakht wrote:
>
>> Hi Daniel,
>>
>> Thanks for referring to this ticket.
>> Here is what I did.
>>
>> My Java version:
>>
>> java version "1.8.0_40-ea"
>> Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b21)
>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b24, mixed mode)
>>
>> So, to make this more observable.
>> The p1 process invokes a command with p2: start and stop.
>> So, with 50 pairs of start and stop, we should be able to see the
>> problem again.
>>
>> I ran a script that invokes start from p1, gets the status of p2, stops
>> p2 and confirms its status again.
>> Here's the output from run 49:
>>
>> ===
>> run 49
>> Invoking Start
>> RUNNING
>> Invoking Stop
>> STOPPED
>> run 49 - Done
>> run 50
>> Invoking Start
>> RUNNING
>> Invoking Stop
>> STOPPED
>> run 50 - Done
>> run 51
>> Invoking Start
>> RUNNING
>> Invoking Stop
>> RUNNING
>> run 51 - Done
>> run 52
>> Invoking Start
>> STOPPED
>> Invoking Stop
>> STOPPED
>> run 52 - Done
>> run 53
>> Invoking Start
>> STOPPED
>> Invoking Stop
>> STOPPED
>> run 53 - Done
>> run 54
>> Invoking Start
>> STOPPED
>> Invoking Stop
>> STOPPED
>> run 54 - Done
>> ===
>>
>> As the above shows, starting run 51, the expected status is violated.
>> And, here is what I get a lsof of the log directory on the application:
>>
>> ===
>> -rw-rw-r-- 1 appuser appuser    0 Feb 19 15:19 app.stdouterr.100.0.log.lck
>> -rw-rw-r-- 1 appuser appuser 3.0K Feb 19 15:19 app.stdouterr.100.0.log
>> -rw-rw-r-- 1 appuser appuser    0 Feb 19 15:16 app.stdouterr.0.0.log.lck
>> -rw-rw-r-- 1 appuser appuser  366 Feb 19 15:16 app.stdouterr.0.0.log
>> ===
>>
>> Thanks for your time on this,
>> Behrooz
>>
>>
>>
>>
>>
>> On Thu, Feb 19, 2015 at 3:01 PM, Daniel Fuchs <daniel.fuchs at oracle.com
>> <mailto:daniel.fuchs at oracle.com>> wrote:
>>
>>     Hi Behrooz,
>>
>>     On 19/02/15 13:46, Behrooz Nobakht wrote:
>>
>>         The version of Java is irrelevant. We have tested our setup
>>         on Java 7 and Java 8 u25/31. We observe the same exception.
>>
>>
>>     Ok - then the version is indeed relevant ;-)
>>
>>     What you are observing may be a symptom of
>>     https://bugs.openjdk.java.net/__browse/JDK-8048020
>>     <https://bugs.openjdk.java.net/browse/JDK-8048020>
>>     which was fixed in 8u40 build 6.
>>
>>     If you would like to verify that this bug is indeed
>>     what is causing your issue, you may want to try out
>>     your setup with an early access build of 8u40, and
>>     see if the problem disappears.
>>
>>     Early access of 8u40 may be downloaded from there:
>>     https://jdk8.java.net/__download.html
>>     <https://jdk8.java.net/download.html>
>>
>>
>>     best regards,
>>
>>     -- daniel
>>
>>
>>
>>
>> --
>> -- Behrooz Nobakht
>>
>
>


-- 
-- Behrooz Nobakht


From scolebourne at joda.org  Thu Feb 19 15:31:52 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 19 Feb 2015 15:31:52 +0000
Subject: RFR: 8072645: java.util.logging should use java.time to get more
	precise time stamps
In-Reply-To: <54E5FEFE.5040109@oracle.com>
References: <54DE109C.4030307@oracle.com>
	<CACzrW9BgsCVZvZKdd=+1rEao1V7bSg7N_QJD0BpJsaywJAj2-A@mail.gmail.com>
	<54DF47B9.4050304@oracle.com> <54E243DF.3060107@oracle.com>
	<54E3977B.4060701@oracle.com>
	<CACzrW9BGGELXh5ZJEc2VEA9VktzZP_4Njod1gWp5JB4dPe2K4Q@mail.gmail.com>
	<54E5FEFE.5040109@oracle.com>
Message-ID: <CACzrW9BU_7wYr6m6Lv-4OsuA5rp9W+Y_BOa=TOjgxLdE=xG2Mg@mail.gmail.com>

A good improvement and ready to go from my perspective,
thanks
Stephen


On 19 February 2015 at 15:19, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> On 18/02/15 12:11, Stephen Colebourne wrote:
>>
>> In LogRecord, the Javadoc of getInstant():
>> "Get event time."
>> could be
>> "Gets the instant that the event ocurred."
>
>
> done.
>
>> In LogRecord, the Javadoc of setInstant():
>> "Set event time."
>> could be
>> "Sets the instant that the event ocurred."
>> (matching change to @param)
>
>
> done.
>
>
>> I'd prefer to see the other methods in the class have their Javadoc
>> changed from "Get" to Gets" and from "Set" to "Sets" to conform with
>> Javadoc norms, but understand if this causes CCC issues.
>
>
> Agreed - but I will need to obtain a CCC approval for this change,
> and I'd prefer to leave the specdiff uncluttered.
> I will log an RFE for a doc cleanup.
>
>
>> In PlatformLogger.
>> There should be no need to assign to a static constant:
>>   private static final Clock systemUTC = Clock.systemUTC();
>> However, Clock.systemUTC() needs to be fixed:
>> https://bugs.openjdk.java.net/browse/JDK-8073394
>
>
> Ahah. I hadn't seen this RFE. Thanks for pointing it out.
> This RFE (JDK-8073394) won't need any CCC so it should be an easy
> quick fix. Given that, I agree that it's better to remove the
> static systemUTC fields (removed from PlatformLogger and LogRecord).
> I will also take care of JDK-8073394 later on then.
>
>
>> This
>>   ZonedDateTime zdt = ZonedDateTime.ofInstant(systemUTC.instant(),
>> zoneId);
>> can be replaced with
>>   ZonedDateTime zdt = ZonedDateTime.now(zoneId);
>
>
> done.
>
>> Again, the implementation of the better method isn't perfectly optimised.
>>
>> The default format used in String.format does not need to time-zone,
>> just the local date/time. As such, in theory a LocalDateTime could be
>> used. But, since the format can be changed by the user, a
>> ZonedDateTime is needed (probably not worth being clever here).
>
>
> Yes - that was my reasoning too. ZonedDateTime seems to be the
> more resilient to format changes.
>
>> Where you assign ZoneId.systemDefault() to a final instance variable,
>> it is being locked for the lifetime of that object. I cannot
>> immediately tell what the lifetime of the objects are. I also suspect
>> that few if any will want to change their time-zone half way through
>> logging.
>
>
> I don't think we should bother with this possibility.
>
> The PlatformLogger's simple logger may either never be
> released (if JUL is not used - meaning, if there is no user
> specified logging.properties file and if nobody calls
> LogManager.getLogManager()) - or it will be replaced by a
> plain logger - in which case the j.u.l.Formatter will
> be used - and the j.u.l.Formatter will usually have the
> same life-time than the Handler on which it is set.
> (usually, until reset() or readConfiguration() is called).
>
>
>> XMLFormatter has a reviewer's comment that will need to be removed
>> before committing.
>
>
> Will do before pushing. At the moment I'm still hoping it will catch
> the eye of an XML/DTD expert :-)
>
>> In LogRecordWithNanosAPI you check the instant contents rather than
>> just the instant:
>>   assertEquals(record.getInstant().getEpochSecond(),
>> record2.getInstant().getEpochSecond(),
>> "getInstant().getEpochSecond()");
>>   assertEquals(record.getInstant().getNano(),
>> record2.getInstant().getNano(), "getInstant().getNano()");
>>   assertEquals(record.getInstant().toEpochMilli(),
>> record2.getInstant().toEpochMilli(), "getInstant().toEpochMilli()");
>> could be
>>   assertEquals(record.getInstant(), record2.getInstant(), "getInstant()");
>> There are probably other instances of this point.
>
>
> Right. I'm not very motivated to change the LogRecord* tests.
> What happened is that I wrote these tests based on the use of
> LogRecord.setMillis/getMillis and
> LogRecord.getNanoAdjustment/setNanoAdjustment - and then had to
> update them when we decided to drop
> LogRecord.getNanoAdjustment/setNanoAdjustment and changed the
> implementation of getMillis/setMillis to work on top of instant.
>
> As a consequence, the test have probably become a bit more complex
> and cluttered than they would have been if I had written them
> directly against the later version of the API.
>
> However I believe they still do the job - I have been careful
> to add some additional tests to verify the new implementation of
> getMillis/setMillis - I don't believe I left any cracks.
>
> The important point is to verify the consistency of getMillis/getInstant
> and setMillis/setInstant as well as checking that nothing is lost
> in the serialization - I believe the tests are good enough in that
> respect.
>
>> Hope that helps
>
>
> It does! I am grateful :-)
>
> Here is the updated webrev.
> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.02/
>
> best regards,
>
> -- daniel
>
>
>> Stephen
>>
>>
>>
>> On 17 February 2015 at 19:33, Daniel Fuchs <daniel.fuchs at oracle.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> Here is a new webrev - which should contain all the feedback received
>>> so far:
>>>
>>> #1 LogRecord uses serialPersistentFields for serialization, and
>>>     contains an Instant instead of the two fields millis +
>>>     nanoAdjustment.
>>> #2 getMillis/setMillis are deprecated, replaced by getInstant/setInstant
>>>     getNanoAdjustment/setNanoAdjustment have been dropped.
>>>
>>> [Thanks Peter for prototyping these 2 first changes!]
>>>
>>> #3 XMLFormatter uses ISO_INSTANT to print the instant in the date field.
>>>     new constructor has been dropped. printNanos property is renamed into
>>>     useInstant.
>>> #4 SimpleFormatter still uses ZonedDateTime - for compatibility and
>>>     flexibility and because it proved to be faster than Date [1].
>>> #5 Tests have been updated WRT to the changes above.
>>> #6 various doc tweaks compared to last webrev
>>>
>>> new webrev:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.01/
>>>
>>> specdiff updated in place (unfortunately the serial form does
>>> not show up):
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/specdiff-logging-time/overview-summary.html
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> [1] benchmarks related to formatting the date:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html
>>>
>>>
>>>
>>> On 16/02/15 20:24, Daniel Fuchs wrote:
>>>>
>>>>
>>>> Hi Stephen,
>>>>
>>>> Thanks again for your support and suggestions!
>>>>
>>>> On 14/02/15 14:03, Daniel Fuchs wrote:
>>>>>
>>>>>
>>>>> If I'm not mistaken the previous SimpleFormatter used to use
>>>>> java.util.Date
>>>>> and printed the time in the local time zone. I have tried to keep this
>>>>> behavior.
>>>>> I'm not sure we would want to change it to print the time in the UTC
>>>>> time zone
>>>>> by default. A lot of developers use logging for debugging - and when
>>>>> reading
>>>>> debug messages on the console I usually prefer to see the time in my
>>>>> own
>>>>> time zone.
>>>>>
>>>>> Would there be a more efficient way to keep the default formatting of
>>>>> the time
>>>>> in the SimpleFormatter?
>>>>
>>>>
>>>>
>>>> I spent part of the day reading the documentation & trying out the
>>>> various TemporalAccessors and DateTimeFormatters...
>>>>
>>>> I have also done some microbenchmark measurements (jmh) WRT
>>>> the performance  of formatting a date/time.
>>>> Results can be seen here [1]:
>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html
>>>>
>>>> What it shows is that when using String.format (as the SimpleFormatter
>>>> is specified to do), then using ZonedDateTime is actually an improvement
>>>> over using Date.
>>>>
>>>> Now that I have read a bit more about LocalDateTime, ZonedDateTime,
>>>> Date, and Instant, I do agree with you that for recording an event time,
>>>> printing the Instant is the better alternative.
>>>> However, since SimpleFormatter has always printed the local date,
>>>> I would tend to want to keep it that way.
>>>>
>>>> So I'm going to propose to keep using ZonedDateTime in
>>>> the SimpleFormatter, as I believe it's what gives it the maximum of
>>>> flexibility - WRT to using String.format (+ we will get some
>>>> boost as bonus by no longer using Date).
>>>> If you strongly feel that java.util.logging should offer a better
>>>> alternative - then maybe we should log an RFE to explore it?
>>>>
>>>> Things are - I believe - a bit different for the XMLFormatter.
>>>> First, the XMLFormatter is not specified to use String.format, so
>>>> it gives us a bit more flexibility.
>>>> In addition we already need to tweak the format in order to introduce
>>>> the new <nanos> element - (or should it be <nanoOfMilli> as Peter
>>>> suggested?).
>>>>
>>>> So for the XMLFormatter, and given the results of my
>>>> microbenchmark [1], here is what I would suggest:
>>>>
>>>> #1 rename the property printNanos into useInstant
>>>> #2 if useInstant is false, use the old code for formatting the
>>>>      date (the old appendISO8601() method) and omit the <nanos>
>>>>      element - so applications that specify useInstant=false should
>>>>      see the same formatting than before, without paying the
>>>>      performance cost that using ZonedDateTime would bring.
>>>> #3 if useInstant is absent - or not false, then we use the 'new'
>>>>      format. The <date> element will contain the instant printed
>>>>      using DateTimeFormatter.ISO_INSTANT, and the <nanos> element
>>>>      will be printed after <millis>
>>>>
>>>> Does that sound right? If so I will include these changes in my
>>>> next webrev, once I have digested the feedback sent by Peter :-)
>>>>
>>>> Best regards,
>>>>
>>>> -- daniel
>>>>
>>>> [1] microbenchmark:
>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/benchmarks.html
>>>>
>>>>
>>>>>
>>>>>> (The webrev is broken wrt zones as it stores ZoneId.systemDefault() in
>>>>>> a
>>>>>> static constant, but that method depends on the mutable
>>>>>> TimeZone.getDefault() ).
>>>>>
>>>>>
>>>>>
>>>>> Would making it a final (non static) variable be better?
>>>>> I now wonder whether there should be a way to configure the time zone
>>>>> for
>>>>> an instance of SimpleFormatter (something like what I did with
>>>>> 'printNanos'
>>>>> for the XMLFormatter).
>>>>>
>>>>>> LogReecord.getInstantUTC() should be getInstant().
>>>>>>
>>>>>> (An Instant is fully defined as a concept, and it cannot be in or not
>>>>>> in
>>>>>> UTC).
>>>>>
>>>>>
>>>>>
>>>>> Right. Thanks for pointing that out.
>>>>>>
>>>>>>
>>>>>> In SimpleFormatter, you have {@code java.util.loggin} (missing a "g").
>>>>>
>>>>>
>>>>>
>>>>> Good catch.
>>>>>
>>>>>> In XMLFormatter, instead of using
>>>>>> DateTimeFormatter.ISO_LOCAL_DATE_TIME,
>>>>>> create a new instance of DateTimeFormatter that does not output the
>>>>>> fraction of a second. That way, there is no need to use
>>>>>> truncatedTo(SECONDS).
>>>>>>
>>>>>> StringBuilder appends can be used directly with formatters:
>>>>>>
>>>>>> sb.append(ZonedDateTime.ofInstant(time, zoneId).format(dtformatter));
>>>>>>
>>>>>> replace with
>>>>>>
>>>>>> dtformatter.formatTo(ZonedDateTime.ofInstant(time, zoneId), sb);
>>>>>
>>>>>
>>>>>
>>>>> Will look into this.
>>>>>
>>>>> Thanks again for your review! This is quite helpful.
>>>>>
>>>>> -- daniel
>>>>>
>>>>>
>>>>>>
>>>>>> thanks
>>>>>> Stephen
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 13 Feb 2015 14:57, "Daniel Fuchs" <daniel.fuchs at oracle.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please find below a patch for:
>>>>>>>
>>>>>>> 8072645: java.util.logging should use java.time to get more
>>>>>>>            precise time stamps
>>>>>>>
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.00/
>>>>>>>
>>>>>>> specdiff:
>>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8072645/
>>>>>>> specdiff-logging-time/java/util/logging/package-summary.html
>>>>>>>
>>>>>>> Overview:
>>>>>>> ---------
>>>>>>>
>>>>>>> The patch is made of the following pieces:
>>>>>>>
>>>>>>>    - LogRecord uses java.time.Clock's systemClock to get an
>>>>>>>      Instant in the best available resolution.
>>>>>>>
>>>>>>>      The instant is split into a number of milliseconds (a long)
>>>>>>>      and a nanosecond adjustment (an int).
>>>>>>>      The number of milliseconds is the same than what would have
>>>>>>>      been obtained by calling System.currentTimeMillis().
>>>>>>>
>>>>>>>    - LogRecord acquires a new serializable int nanoAdjustement field,
>>>>>>>      which can be used together with the number of milliseconds
>>>>>>>      to reconstruct the instant.
>>>>>>>
>>>>>>>    - SimpleFormatter is updated to pass a ZoneDateTime
>>>>>>>      instance to String.format, instead of a Date.
>>>>>>>
>>>>>>>      The effect of that is that the format string can now
>>>>>>>      be configure to print the full instant precision, if
>>>>>>>      needed.
>>>>>>>
>>>>>>>    - XMLformatter will add a new <nanos> element after the
>>>>>>>      <millis> element - if the value of the nanoAdjustment
>>>>>>>      field is not 0.
>>>>>>>
>>>>>>>      The <date> string will also contain the nano second
>>>>>>>      adjustment as well as the zone offset as formatted by
>>>>>>>      DateTimeFormatter.ISO_OFFSET_DATE_TIME
>>>>>>>
>>>>>>> Compatibility considerations:
>>>>>>> -----------------------------
>>>>>>>
>>>>>>> - The serial for of log record is backward/forward compatible.
>>>>>>>     I added a test to verify that.
>>>>>>>
>>>>>>> - XMLFormatter has acquired a new configurable property
>>>>>>>     '<FQCN>.printNanos' which allows to revert to the old
>>>>>>>     XML format, should the new format cause issues in
>>>>>>>     existing applications.
>>>>>>>
>>>>>>> - The logger.dtd will need to be updated, to support the
>>>>>>>     new optional <nanos> element. And for this matter,
>>>>>>>     should we update the logger.dtd or rather define a
>>>>>>>     logger-v2.dtd?
>>>>>>>     See planned modification:
>>>>>>>
>>>>>>> <http://cr.openjdk.java.net/~dfuchs/webrev_8072645/logger-
>>>>>>> dtd/logger.dtd.frames.html>
>>>>>>>
>>>>>>> best regards,
>>>>>>>
>>>>>>> -- daniel
>>>>>>>
>>>>>
>>>>
>>>
>


From daniel.fuchs at oracle.com  Thu Feb 19 16:18:16 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 19 Feb 2015 17:18:16 +0100
Subject: Logging FileHandler: static locks and hardcoded maximum number
In-Reply-To: <CAEEKBgXjkxvmDkp1-zUmBRSpE=xoJKKShewiRUh5G5z87zfEoQ@mail.gmail.com>
References: <CAEEKBgU_-i1ki3bJTBQh7Q0K7NU4xgzmn=FbaRP+TJzgbgFS4A@mail.gmail.com>
	<54E5D1AC.7050607@oracle.com>
	<CAEEKBgXjm71hBjhHGnDs4A2wLiBXndQFuLWEh3ScaVZcDY1TNQ@mail.gmail.com>
	<54E5ECAE.4070000@oracle.com>
	<CAEEKBgVPGjFd8kK7QVDahcxUm71dFiLoEO_B_ROAgps3e6quHw@mail.gmail.com>
	<54E5F99E.8000404@oracle.com>
	<CAEEKBgXjkxvmDkp1-zUmBRSpE=xoJKKShewiRUh5G5z87zfEoQ@mail.gmail.com>
Message-ID: <54E60CC8.6030409@oracle.com>

Hi,

On 19/02/15 16:30, Behrooz Nobakht wrote:
> I'd be very happy to introduce an issue. But,
> I've always failed to be able to create an account on
> https://bugs.openjdk.java.net/secure/Dashboard.jspa
> so, for me, the starting point is where I should do this?!

If you are not an OpenJDK member then I guess you should
use http://bugs.java.com/ - and at some point this issue will
be transferred to https://bugs.openjdk.java.net/
where it (hopefully) will come in my inbox :-)

You might want to refer to this email thread in your issue
description.
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031624.html


best regards,

-- daniel

>
> On Thu, Feb 19, 2015 at 3:56 PM, Daniel Fuchs <daniel.fuchs at oracle.com
> <mailto:daniel.fuchs at oracle.com>> wrote:
>
>     Thanks Behrooz.
>
>     Could you log an issue for this then?
>     If you can attach a small reproducer it will be helpful.
>
>     There are a bunch of unit tests in the JDK that verify
>     that FileHandler .lck files are correctly deleted - but
>     these tests are all mono-process. I would like to make
>     sure to chase down the real issue - so a small isolated
>     reproducer would definitely help.
>
>     best regards,
>
>     -- daniel
>
>
>     On 19/02/15 15:29, Behrooz Nobakht wrote:
>
>         Hi Daniel,
>
>         Thanks for referring to this ticket.
>         Here is what I did.
>
>         My Java version:
>
>         java version "1.8.0_40-ea"
>         Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b21)
>         Java HotSpot(TM) 64-Bit Server VM (build 25.40-b24, mixed mode)
>
>         So, to make this more observable.
>         The p1 process invokes a command with p2: start and stop.
>         So, with 50 pairs of start and stop, we should be able to see the
>         problem again.
>
>         I ran a script that invokes start from p1, gets the status of
>         p2, stops
>         p2 and confirms its status again.
>         Here's the output from run 49:
>
>         ===
>         run 49
>         Invoking Start
>         RUNNING
>         Invoking Stop
>         STOPPED
>         run 49 - Done
>         run 50
>         Invoking Start
>         RUNNING
>         Invoking Stop
>         STOPPED
>         run 50 - Done
>         run 51
>         Invoking Start
>         RUNNING
>         Invoking Stop
>         RUNNING
>         run 51 - Done
>         run 52
>         Invoking Start
>         STOPPED
>         Invoking Stop
>         STOPPED
>         run 52 - Done
>         run 53
>         Invoking Start
>         STOPPED
>         Invoking Stop
>         STOPPED
>         run 53 - Done
>         run 54
>         Invoking Start
>         STOPPED
>         Invoking Stop
>         STOPPED
>         run 54 - Done
>         ===
>
>         As the above shows, starting run 51, the expected status is
>         violated.
>         And, here is what I get a lsof of the log directory on the
>         application:
>
>         ===
>         -rw-rw-r-- 1 appuser appuser    0 Feb 19 15:19
>         app.stdouterr.100.0.log.lck
>         -rw-rw-r-- 1 appuser appuser 3.0K Feb 19 15:19
>         app.stdouterr.100.0.log
>         -rw-rw-r-- 1 appuser appuser    0 Feb 19 15:16
>         app.stdouterr.0.0.log.lck
>         -rw-rw-r-- 1 appuser appuser  366 Feb 19 15:16 app.stdouterr.0.0.log
>         ===
>
>         Thanks for your time on this,
>         Behrooz
>
>
>
>
>
>         On Thu, Feb 19, 2015 at 3:01 PM, Daniel Fuchs
>         <daniel.fuchs at oracle.com <mailto:daniel.fuchs at oracle.com>
>         <mailto:daniel.fuchs at oracle.__com
>         <mailto:daniel.fuchs at oracle.com>>> wrote:
>
>              Hi Behrooz,
>
>              On 19/02/15 13:46, Behrooz Nobakht wrote:
>
>                  The version of Java is irrelevant. We have tested our setup
>                  on Java 7 and Java 8 u25/31. We observe the same exception.
>
>
>              Ok - then the version is indeed relevant ;-)
>
>              What you are observing may be a symptom of
>         https://bugs.openjdk.java.net/____browse/JDK-8048020
>         <https://bugs.openjdk.java.net/__browse/JDK-8048020>
>              <https://bugs.openjdk.java.__net/browse/JDK-8048020
>         <https://bugs.openjdk.java.net/browse/JDK-8048020>>
>              which was fixed in 8u40 build 6.
>
>              If you would like to verify that this bug is indeed
>              what is causing your issue, you may want to try out
>              your setup with an early access build of 8u40, and
>              see if the problem disappears.
>
>              Early access of 8u40 may be downloaded from there:
>         https://jdk8.java.net/____download.html
>         <https://jdk8.java.net/__download.html>
>              <https://jdk8.java.net/__download.html
>         <https://jdk8.java.net/download.html>>
>
>
>              best regards,
>
>              -- daniel
>
>
>
>
>         --
>         -- Behrooz Nobakht
>
>
>
>
>
> --
> -- Behrooz Nobakht



From chris.hegarty at oracle.com  Thu Feb 19 16:25:05 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 19 Feb 2015 16:25:05 +0000
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
Message-ID: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>

A number of years ago there was a proposal to use Unsafe.put*Volatile methods to set final fields during default deserialisation [1][2], but it never made it due to concerns about the potential negative impact of the additional fences. Now we have a, private, fences API in the platform, I think it is time to revisit this.

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

Note: 
  - Section 17.5.3 in the JLS [3], ?Freezes of a final field occur both
    at the end of the constructor in which the final field is set, and
    immediately after each modification of a final field via reflection
    or other special mechanism.? I believe this is a consequence of
    the way in which setting of final fields is supported in the public
    API, Field.setAccessible(), ( as defined by JSR 133 ) and should
    not restrict an implementation from using a more performant
    means, as is suggested here.  The statement in the JLS should
    be revisited.
 
 - Default Serialization already has a dependency on Unsafe, and
   I don?t see this additional dependency as making that any worse. 

 - Open question, should we include volatile fields as well as final?

 - The changes in the webrev will issue a fence even if custom
   deserialization is performed. I think this is ok, as it will be more
   consuming to try to determine if a custom readObject set a final
   through reflection, or not.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-6647361
[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-November/005292.html
     http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-December/005456.html
[3] http://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.5.3

From chris.hegarty at oracle.com  Thu Feb 19 16:32:22 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 19 Feb 2015 16:32:22 +0000
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>
Message-ID: <7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>

Additional note ( forgotten from original mail):

The fence is needed for "final-freeze" is a one-off barrier at the end of deserialization, similar that of constructors . Under normal circumstances the object being deserialized is not visible until deserialization completes, so you don't need a "freeze" until deserialization completes.

-Chris.

On 19 Feb 2015, at 16:25, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> A number of years ago there was a proposal to use Unsafe.put*Volatile methods to set final fields during default deserialisation [1][2], but it never made it due to concerns about the potential negative impact of the additional fences. Now we have a, private, fences API in the platform, I think it is time to revisit this.
> 
> Webrev:
>  http://cr.openjdk.java.net/~chegar/deserialFence/webrev.00/webrev/  
> 
> Note: 
>  - Section 17.5.3 in the JLS [3], ?Freezes of a final field occur both
>    at the end of the constructor in which the final field is set, and
>    immediately after each modification of a final field via reflection
>    or other special mechanism.? I believe this is a consequence of
>    the way in which setting of final fields is supported in the public
>    API, Field.setAccessible(), ( as defined by JSR 133 ) and should
>    not restrict an implementation from using a more performant
>    means, as is suggested here.  The statement in the JLS should
>    be revisited.
> 
> - Default Serialization already has a dependency on Unsafe, and
>   I don?t see this additional dependency as making that any worse. 
> 
> - Open question, should we include volatile fields as well as final?
> 
> - The changes in the webrev will issue a fence even if custom
>   deserialization is performed. I think this is ok, as it will be more
>   consuming to try to determine if a custom readObject set a final
>   through reflection, or not.
> 
> -Chris.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-6647361
> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-November/005292.html
>     http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-December/005456.html
> [3] http://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.5.3



From peter.levart at gmail.com  Thu Feb 19 17:15:31 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 19 Feb 2015 18:15:31 +0100
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>
	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
Message-ID: <54E61A33.3060309@gmail.com>

Hi Chris,

Would it be possible to track the "needsFence" flag throughout the whole 
object graph deserialization, and only issue one single fence for the 
whole object graph? This would minimize the number of fences issued.

Peter

On 02/19/2015 05:32 PM, Chris Hegarty wrote:
> Additional note ( forgotten from original mail):
>
> The fence is needed for "final-freeze" is a one-off barrier at the end of deserialization, similar that of constructors . Under normal circumstances the object being deserialized is not visible until deserialization completes, so you don't need a "freeze" until deserialization completes.
>
> -Chris.
>
> On 19 Feb 2015, at 16:25, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>
>> A number of years ago there was a proposal to use Unsafe.put*Volatile methods to set final fields during default deserialisation [1][2], but it never made it due to concerns about the potential negative impact of the additional fences. Now we have a, private, fences API in the platform, I think it is time to revisit this.
>>
>> Webrev:
>>   http://cr.openjdk.java.net/~chegar/deserialFence/webrev.00/webrev/
>>
>> Note:
>>   - Section 17.5.3 in the JLS [3], ?Freezes of a final field occur both
>>     at the end of the constructor in which the final field is set, and
>>     immediately after each modification of a final field via reflection
>>     or other special mechanism.? I believe this is a consequence of
>>     the way in which setting of final fields is supported in the public
>>     API, Field.setAccessible(), ( as defined by JSR 133 ) and should
>>     not restrict an implementation from using a more performant
>>     means, as is suggested here.  The statement in the JLS should
>>     be revisited.
>>
>> - Default Serialization already has a dependency on Unsafe, and
>>    I don?t see this additional dependency as making that any worse.
>>
>> - Open question, should we include volatile fields as well as final?
>>
>> - The changes in the webrev will issue a fence even if custom
>>    deserialization is performed. I think this is ok, as it will be more
>>    consuming to try to determine if a custom readObject set a final
>>    through reflection, or not.
>>
>> -Chris.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-6647361
>> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-November/005292.html
>>      http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-December/005456.html
>> [3] http://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.5.3



From chris.hegarty at oracle.com  Thu Feb 19 17:33:36 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 19 Feb 2015 17:33:36 +0000
Subject: j.u.Arrays setAll and parallelSetAll subrange note
Message-ID: <ACD70EB0-6A49-4DA9-80CA-C8B68BCB2736@oracle.com>

It came up recently that java.util.Arrays was missing subrange overloads for setAll and parallelSetAll. These methods can be easily written with IntStream.range. Rather than adding eight new methods for this, it makes sense to point developers to IntStream.range. It seems reasonable to add a small note to these methods, promoting the use of IntStream. If someone is hunting around for a subrange setAll, then they will inevitable end up seeing this note.

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

-Chris.

From mandy.chung at oracle.com  Thu Feb 19 18:24:36 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 19 Feb 2015 10:24:36 -0800
Subject: Review request: 8073374: Re-examine jdk.xml.ws dependency on
	java.xml.ws SOAPNamespaceConstants
Message-ID: <54E62A64.8020406@oracle.com>

This eliminates the dependency from jdk.xml.ws to
com.sun.xml.internal.ws.encoding.soap.streaming.SOAPNamespaceConstants
from java.xml.ws.

I chatted with Miran offline who confirms that it's okay to define
the constant value directly.

diff --git a/src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPConstants.java b/src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPConstants.java
--- a/src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPConstants.java
+++ b/src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPConstants.java
@@ -25,8 +25,6 @@
  
  package com.sun.tools.internal.ws.wsdl.document.soap;
  
-import com.sun.xml.internal.ws.encoding.soap.streaming.SOAPNamespaceConstants;
-
  import javax.xml.namespace.QName;
  
  /**
@@ -37,7 +35,9 @@
  public interface SOAPConstants {
  
      // namespace URIs
-    public static final String URI_ENVELOPE = SOAPNamespaceConstants.ENVELOPE;
+    public static final String URI_ENVELOPE =
+        "http://schemas.xmlsoap.org/soap/envelope/";
+
      public static final String NS_WSDL_SOAP =
          "http://schemas.xmlsoap.org/wsdl/soap/";
      public static final String NS_SOAP_ENCODING = "http://schemas.xmlsoap.org/soap/encoding/";


Mandy



From aleksey.shipilev at oracle.com  Thu Feb 19 18:26:36 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 19 Feb 2015 21:26:36 +0300
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E5FE88.4000705@gmail.com>
References: <54E5F88F.6030502@oracle.com> <54E5FA36.7030206@gmail.com>
	<54E5FB07.6030400@oracle.com> <54E5FE88.4000705@gmail.com>
Message-ID: <54E62ADC.1070501@oracle.com>

On 02/19/2015 06:17 PM, Peter Levart wrote:
> On 02/19/2015 04:02 PM, Aleksey Shipilev wrote:
>>> >Hi Aleksey,
>>> >
>>> >Is profile pollution problem already fixed? Can Objects.requireNonNull
>>> >be used in performance critical code without fear of performance
>>> >regression?
>> What profile pollution? Objects.requireNonNull is a static method. See
>> also the link in bug description:
>>    http://cr.openjdk.java.net/~shade/scratch/NullChecks.java
>>
>> -Aleksey.
>>
> 
> Remi described it here:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026669.html

Okay, Remi's premise is that implicit null check is much cheaper than an
explicit one when it's not tripped. It's then seem to extend to mean
that pessimistically inflating the nullcheck into the explicit one costs
performance, and therefore one should avoid requireNonNull.

But then we all got confused with benchmarks and whatnot. The benchmark
from JDK-8047127 actually measures the cost of raising the exceptions,
where getClass and friends are profoundly cheating:
  https://bugs.openjdk.java.net/browse/JDK-8042127#comment-13611255
  http://cr.openjdk.java.net/~shade/8042127/NullCheckMix.java

However, if you do the actual benchmark that compares explicit NP checks
vs implicit NP checks (that benchmark is very tricky to get right):
 http://cr.openjdk.java.net/~shade/scratch/NullCheckPollution.java

Benchmark         (count)  (pollute)  Mode  Cnt  Score   Error  Units
NCP.testExplicit   100000      false  avgt   50  1.813 ? 0.004  ns/op
NCP.testExplicit   100000       true  avgt   50  1.891 ? 0.029  ns/op
NCP.testImplicit   100000      false  avgt   50  1.812 ? 0.003  ns/op
NCP.testImplicit   100000       true  avgt   50  1.811 ? 0.001  ns/op

There, testExplicit with pollution is the only one that has explicit
test+branch. The difference is minuscule (< 1/3 of CPU cycle), and I
would choose not to care, even for JDK code.

That test is crafted specifically so that compiler could not
disambiguate different callers. In real life, a Sufficiently Smart
Compiler may inline the callees and reprofile in the context of caller.
But even in the absence of that, the performance hit would be buried in
everything else.

In the places where you *need* the every last bit of performance, you
can do the by-hand explicit nullcheck. (Note that it is not a good idea
to do getClass anyway, because of JDK-8073432).

Thanks,
-Aleksey.



From vitalyd at gmail.com  Thu Feb 19 18:36:11 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 19 Feb 2015 13:36:11 -0500
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E62ADC.1070501@oracle.com>
References: <54E5F88F.6030502@oracle.com> <54E5FA36.7030206@gmail.com>
	<54E5FB07.6030400@oracle.com> <54E5FE88.4000705@gmail.com>
	<54E62ADC.1070501@oracle.com>
Message-ID: <CAHjP37H5VXcZzUYDMJFJ6URiUzSGe8YthhE2KHuLi9dunbT8NQ@mail.gmail.com>

The problem is microbenchmarking this may not tell the true story (like all
microbenchmarks).  In this case the explicit test and branch is probably
perfectly predicted because there's not much code.  In a bigger
application, where the history fell out of the buffer, it'll depend on what
static prediction is used.  Or, this branch will evict another useful one
from the history buffer.  Not saying you're wrong in your suggestion to go
ahead with this change, but something to keep in mind.

sent from my phone
On Feb 19, 2015 1:27 PM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
wrote:

> On 02/19/2015 06:17 PM, Peter Levart wrote:
> > On 02/19/2015 04:02 PM, Aleksey Shipilev wrote:
> >>> >Hi Aleksey,
> >>> >
> >>> >Is profile pollution problem already fixed? Can Objects.requireNonNull
> >>> >be used in performance critical code without fear of performance
> >>> >regression?
> >> What profile pollution? Objects.requireNonNull is a static method. See
> >> also the link in bug description:
> >>    http://cr.openjdk.java.net/~shade/scratch/NullChecks.java
> >>
> >> -Aleksey.
> >>
> >
> > Remi described it here:
> >
> >
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026669.html
>
> Okay, Remi's premise is that implicit null check is much cheaper than an
> explicit one when it's not tripped. It's then seem to extend to mean
> that pessimistically inflating the nullcheck into the explicit one costs
> performance, and therefore one should avoid requireNonNull.
>
> But then we all got confused with benchmarks and whatnot. The benchmark
> from JDK-8047127 actually measures the cost of raising the exceptions,
> where getClass and friends are profoundly cheating:
>   https://bugs.openjdk.java.net/browse/JDK-8042127#comment-13611255
>   http://cr.openjdk.java.net/~shade/8042127/NullCheckMix.java
>
> However, if you do the actual benchmark that compares explicit NP checks
> vs implicit NP checks (that benchmark is very tricky to get right):
>  http://cr.openjdk.java.net/~shade/scratch/NullCheckPollution.java
>
> Benchmark         (count)  (pollute)  Mode  Cnt  Score   Error  Units
> NCP.testExplicit   100000      false  avgt   50  1.813 ? 0.004  ns/op
> NCP.testExplicit   100000       true  avgt   50  1.891 ? 0.029  ns/op
> NCP.testImplicit   100000      false  avgt   50  1.812 ? 0.003  ns/op
> NCP.testImplicit   100000       true  avgt   50  1.811 ? 0.001  ns/op
>
> There, testExplicit with pollution is the only one that has explicit
> test+branch. The difference is minuscule (< 1/3 of CPU cycle), and I
> would choose not to care, even for JDK code.
>
> That test is crafted specifically so that compiler could not
> disambiguate different callers. In real life, a Sufficiently Smart
> Compiler may inline the callees and reprofile in the context of caller.
> But even in the absence of that, the performance hit would be buried in
> everything else.
>
> In the places where you *need* the every last bit of performance, you
> can do the by-hand explicit nullcheck. (Note that it is not a good idea
> to do getClass anyway, because of JDK-8073432).
>
> Thanks,
> -Aleksey.
>
>


From lance.andersen at oracle.com  Thu Feb 19 19:33:47 2015
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Thu, 19 Feb 2015 14:33:47 -0500
Subject: Review request: 8073374: Re-examine jdk.xml.ws dependency on
	java.xml.ws SOAPNamespaceConstants
In-Reply-To: <54E62A64.8020406@oracle.com>
References: <54E62A64.8020406@oracle.com>
Message-ID: <2FEA1DF6-08B9-492C-AF19-49124BC2FCDB@oracle.com>

+1


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 Feb 19, 2015, at 1:24 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> This eliminates the dependency from jdk.xml.ws to
> com.sun.xml.internal.ws.encoding.soap.streaming.SOAPNamespaceConstants
> from java.xml.ws.
> 
> I chatted with Miran offline who confirms that it's okay to define
> the constant value directly.
> 
> diff --git a/src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPConstants.java b/src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPConstants.java
> --- a/src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPConstants.java
> +++ b/src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/document/soap/SOAPConstants.java
> @@ -25,8 +25,6 @@
>  package com.sun.tools.internal.ws.wsdl.document.soap;
> -import com.sun.xml.internal.ws.encoding.soap.streaming.SOAPNamespaceConstants;
> -
> import javax.xml.namespace.QName;
>  /**
> @@ -37,7 +35,9 @@
> public interface SOAPConstants {
>      // namespace URIs
> -    public static final String URI_ENVELOPE = SOAPNamespaceConstants.ENVELOPE;
> +    public static final String URI_ENVELOPE =
> +        "http://schemas.xmlsoap.org/soap/envelope/";
> +
>     public static final String NS_WSDL_SOAP =
>         "http://schemas.xmlsoap.org/wsdl/soap/";
>     public static final String NS_SOAP_ENCODING = "http://schemas.xmlsoap.org/soap/encoding/";
> 
> 
> Mandy
> 


From jason_mehrens at hotmail.com  Thu Feb 19 21:54:01 2015
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 19 Feb 2015 15:54:01 -0600
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <CA+kOe09QDOBmNRjkJKoSxstb=+EUqWCE3PNXT7Mi_=k2hH=k0Q@mail.gmail.com>
References: <54CBAA39.3050004@Oracle.com>, <54CBF7DB.9000909@oracle.com>,
	<54CBFC10.9080502@Oracle.com>,
	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>,
	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>,
	<54CD4305.4080607@oracle.com>,
	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>,
	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>,
	<54CF7D1F.6050101@Oracle.com>,
	<CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>,
	<54CFE064.70400@Oracle.com>,
	<CA+kOe0-zPJRpGEa0zXy6_bHgwNcnFWuSc1fbbxsc7-nc6SUjAg@mail.gmail.com>,
	<54D08997.9020300@oracle.com>,
	<CA+kOe091FHtd1Mnz_eVLcP0a_fC-+nXPGjnEdYr706XguBTy=g@mail.gmail.com>,
	<54DBBA84.7090108@Oracle.com>,
	<CA+kOe08VHA6h=6xVipyZ-xEx-XFBJ_mfd48GcnGJMaU0hQMQVA@mail.gmail.com>,
	<54DC6D4B.3070902@oracle.com>,
	<CA+kOe09QDOBmNRjkJKoSxstb=+EUqWCE3PNXT7Mi_=k2hH=k0Q@mail.gmail.com>
Message-ID: <BLU175-W160A859502935C3D2894B2832D0@phx.gbl>

Standing with Martin on this, I wanted to note the following from the ProcessBuilder docs:
"The exact nature of the exception is system-dependent, but it will always be a subclass of IOException"

The type of exception thrown is the one thing that is defined in the spec.  The rest may be vague or have wiggle room but not the exception type.


I do appreciate the arguments on both sides but, I'm assuming that compatibility is given more weight vs. correcting choices made in the original design.


Jason



----------------------------------------
> Date: Wed, 18 Feb 2015 21:41:40 -0800
> Subject: Re: RFR 9 8055330: (process spec) ProcessBuilder.start and Runtime.exec should throw UnsupportedOperationException ...
> From: martinrb at google.com
> To: Alan.Bateman at oracle.com
> CC: core-libs-dev at openjdk.java.net
>
> On Thu, Feb 12, 2015 at 1:07 AM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 12/02/2015 02:08, Martin Buchholz wrote:
>>
>>> Roger et al,
>>>
>>> Whichever way we go doesn't matter much.
>>> But I continue to think that IOE is a better choice than UOE and I have
>>> trouble seeing the motivation for the change to use UOE.
>>> If you wanted to provide a way to tell if subprocess support was available
>>> at all, then it would be better to add a new static boolean method to
>>> Process (but I wouldn't support that either).
>>> But (Roger and Alan): feel free to outvote me.
>>>
>>> I think Roger's proposal is reasonable as this is a case where the API
>> will consistently throw UOE when the underlying runtime or operating system
>> doesn't support a means to start processes. It's consistent with what was
>> done for RMI activiation in JDK 8 (this was also about starting processes).
>> Another example that comes to mind is the GUI libraries where
>> HeadlessException is thrown (HeadlessException is a UOE). In the file
>> system API then UOE is also specified when trying to use optional features
>> that aren't supported by the implementation. There are probably many
>> counter examples as we don't have consistency everywhere. In practical
>> terms then I don't think this change should have an impact, but could be
>> useful for those trying to take an existing app and run it on something
>> like iOS. If that app relies on Runtime.exec or ProcessBuilder then the UOE
>> should make it easy to identify that this part of the code needs to be
>> looked at. If someday it is possible to start processes on such devices
>> then an updated port to that platform wouldn't throw UOE anymore.
>>
>> -Alan.
>>
>
> If you threw a variant of UOE that was also an IOException, it would have
> been equally clear to users, and no change to the contract of
> ProcessBuilder would have been necessary.
>
> You've broken users who relied on the old spec. 		 	   		  

From david.holmes at oracle.com  Thu Feb 19 22:14:37 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Feb 2015 08:14:37 +1000
Subject: RFR 8073354: TimSortStackSize2.java: requires
	64*2^20*sizeof(reference) continues heap space
In-Reply-To: <54E5D060.1080409@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>
Message-ID: <54E6604D.10805@oracle.com>

On 19/02/2015 10:00 PM, Lev Priima wrote:
>    There is also a problem, if the memory on host is highly fragmented,
> then we can't allocate continuous amount of heap for creating such big
> array. I've added catch for OOME and treat this case as skip-pass to
> make test more robust. Also I've removed explicit -Xmx385 from @run tag

But by doing that you have ensured it will skip-pass on a lot of smaller 
systems! So now the test will skip-pass on low-memory systems, and 
skip-pass of big-memory-but-fragmented systems!

I recommend restoring the -Xmx385.

David

> and made it start with a single argument.
>
> Please review and push:
> http://cr.openjdk.java.net/~lpriima/8073354/webrev.00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8073354
>
> Lev
>
> On 02/17/2015 09:55 AM, David Holmes wrote:
>> On 17/02/2015 3:43 PM, Lev Priima wrote:
>>> Thanks David!
>>> Is this expected behavior of this annotation ?
>>
>> Yes that is the way jtreg defines tags:
>>
>> http://openjdk.java.net/jtreg/tag-spec.html
>>
>> "The argument tokens of a tag extend from the first token after the
>> tag token to the end of the comment, the end of the file, or the next
>> tag token, whichever comes first."
>>
>> So everything between @run and @summary are taken to be the @run
>> commands. And there's no @comment tag unfortunately.
>>
>> David
>>
>>> Lev
>>>
>>> On 02/17/2015 03:20 AM, David Holmes wrote:
>>>> On 16/02/2015 9:20 PM, David Holmes wrote:
>>>>> On 16/02/2015 6:59 PM, Lev Priima wrote:
>>>>>> Thanks, David,
>>>>>> Could you please push it ?
>>>>>
>>>>> I will if Roger doesn't get to it first. It'll be 11 hours before I
>>>>> can
>>>>> push it.
>>>>
>>>> This has been pushed but note there is a minor issue with the test.
>>>> The jtreg tag specification doesn't terminate tags on newlines, they
>>>> continue until the next tag is encountered or the end of the comment.
>>>> Consequently this:
>>>>
>>>>  * @run main/othervm -Xmx385m TimSortStackSize2 67108864
>>>>  * not for regular execution on all platforms:
>>>>  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>  * run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>>
>>>> is processed as:
>>>>
>>>> @run main/othervm -Xmx385m TimSortStackSize2 67108864 not for regular
>>>> execution on all platforms: run main/othervm -Xmx8g TimSortStackSize2
>>>> 1073741824 run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>>
>>>> and so TimSortStackSize2 is invoked with 18 arguments.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> David
>>>>>
>>>>>> Lev
>>>>>>
>>>>>> On 02/16/2015 08:55 AM, David Holmes wrote:
>>>>>>> On 14/02/2015 12:03 AM, Lev Priima wrote:
>>>>>>>> Please review and push:
>>>>>>>> http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073124
>>>>>>>
>>>>>>> I hadn't realized 8072909 had been pushed without final reviewer
>>>>>>> comments being addressed. :(
>>>>>>>
>>>>>>> These changes seem okay. I hope they get promoted at the same
>>>>>>> time as
>>>>>>> the original changeset so we don't get test failures.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>> Lev
>>>>>>>>
>>>>>>>> On 02/13/2015 05:20 AM, David Holmes wrote:
>>>>>>>>> Hi Lev,
>>>>>>>>>
>>>>>>>>> On 13/02/2015 2:56 AM, Lev Priima wrote:
>>>>>>>>>> Christos,
>>>>>>>>>>
>>>>>>>>>> Test may fail on shorter arrays(page 8 of paper). For
>>>>>>>>>> instance, on
>>>>>>>>>> worst
>>>>>>>>>> case, generated by test, it starts to fail on length 67108864.
>>>>>>>>>> After increasing stack size of runs to merge, Arrays.sort(T[])
>>>>>>>>>> works
>>>>>>>>>> also on maximum possible array for HotSpot JVM.
>>>>>>>>>
>>>>>>>>> I'd also like to see this documented somewhere in the code.
>>>>>>>>> Presently
>>>>>>>>> there is a reference to listsort.txt but then you have to go and
>>>>>>>>> find
>>>>>>>>> it on the web. :( At a minimum could we please add:
>>>>>>>>>
>>>>>>>>>  175          * computation below must be changed if MIN_MERGE is
>>>>>>>>> decreased.  See
>>>>>>>>>  176          * the MIN_MERGE declaration above for more
>>>>>>>>> information.
>>>>>>>>> +             * The maximum value of 49 allows for an array up to
>>>>>>>>> length
>>>>>>>>> +             * Integer.MAX_VALUE-4.
>>>>>>>>>
>>>>>>>>>> Roger, David,
>>>>>>>>>> I've updated the test (
>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ) to make it more suitable for regular execution:
>>>>>>>>>>
>>>>>>>>>>    27  * @run main/othervm TimSortStackSize2 67108864
>>>>>>>>>
>>>>>>>>> This will still fail on small memory devices:
>>>>>>>>>
>>>>>>>>> :~> java TimSortStackSize2 67108864
>>>>>>>>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap
>>>>>>>>> space
>>>>>>>>>
>>>>>>>>> as the default heap ergonomics may not be large enough. I had to
>>>>>>>>> add a
>>>>>>>>> minimum heap of -Xmx385M to get it to run.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>>    28  * not for regular execution on all platforms:
>>>>>>>>>>    29  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>>>>>>    30  * run main/othervm -Xmx32g TimSortStackSize2 2147483644
>>>>>>>>>>
>>>>>>>>>> Could you please push this:
>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>>>>>>>>>> ?
>>>>>>>>>>
>>>>>>>>>> Lev
>>>>>>>>>>
>>>>>>>>>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>>>>>>>>>> On Feb 12, 9:57pm,david.holmes at oracle.com  (David Holmes) wrote:
>>>>>>>>>>> -- Subject: Re: 8072909: TimSort fails with
>>>>>>>>>>> ArrayIndexOutOfBoundsException on
>>>>>>>>>>>
>>>>>>>>>>> | Ok - thanks Lev!
>>>>>>>>>>> |
>>>>>>>>>>> | David
>>>>>>>>>>>
>>>>>>>>>>> For posterity can someone document this, and also the value for
>>>>>>>>>>> which
>>>>>>>>>>> Integer.MAX_VALUE-4 fails?
>>>>>>>>>>>
>>>>>>>>>>> christos
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>
>


From Roger.Riggs at Oracle.com  Thu Feb 19 22:31:37 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 19 Feb 2015 17:31:37 -0500
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <BLU175-W160A859502935C3D2894B2832D0@phx.gbl>
References: <54CBAA39.3050004@Oracle.com>, <54CBF7DB.9000909@oracle.com>,
	<54CBFC10.9080502@Oracle.com>,
	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>,
	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>,
	<54CD4305.4080607@oracle.com>,
	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>,
	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>,
	<54CF7D1F.6050101@Oracle.com>,
	<CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>,
	<54CFE064.70400@Oracle.com>,
	<CA+kOe0-zPJRpGEa0zXy6_bHgwNcnFWuSc1fbbxsc7-nc6SUjAg@mail.gmail.com>,
	<54D08997.9020300@oracle.com>,
	<CA+kOe091FHtd1Mnz_eVLcP0a_fC-+nXPGjnEdYr706XguBTy=g@mail.gmail.com>,
	<54DBBA84.7090108@Oracle.com>,
	<CA+kOe08VHA6h=6xVipyZ-xEx-XFBJ_mfd48GcnGJMaU0hQMQVA@mail.gmail.com>,
	<54DC6D4B.3070902@oracle.com>,
	<CA+kOe09QDOBmNRjkJKoSxstb=+EUqWCE3PNXT7Mi_=k2hH=k0Q@mail.gmail.com>
	<BLU175-W160A859502935C3D2894B2832D0@phx.gbl>
Message-ID: <54E66449.6040509@Oracle.com>

Hi Jason,

In the case where there is *any* implementation of Process, IOException is
the right way to expose OS dependencies.  But in the case where there is 
never
going to be a successful Process, UOE is by far the more conventional and
understandable exception.  Backward compatibility is not an absolute
requirement.  I have no expectation that any existing application will run
on the target device/OS combinations that this change is intended to support
even without taking processes into account.
No one has offered a use case or example to the contrary.  If this is not an
academic or theoretical question, I'd appreciate a concrete example.

Thanks, Roger

On 2/19/2015 4:54 PM, Jason Mehrens wrote:
> Standing with Martin on this, I wanted to note the following from the ProcessBuilder docs:
> "The exact nature of the exception is system-dependent, but it will always be a subclass of IOException"
>
> The type of exception thrown is the one thing that is defined in the spec.  The rest may be vague or have wiggle room but not the exception type.
>
>
> I do appreciate the arguments on both sides but, I'm assuming that compatibility is given more weight vs. correcting choices made in the original design.
>
>
> Jason
>
>
>
> ----------------------------------------
>> Date: Wed, 18 Feb 2015 21:41:40 -0800
>> Subject: Re: RFR 9 8055330: (process spec) ProcessBuilder.start and Runtime.exec should throw UnsupportedOperationException ...
>> From: martinrb at google.com
>> To: Alan.Bateman at oracle.com
>> CC: core-libs-dev at openjdk.java.net
>>
>> On Thu, Feb 12, 2015 at 1:07 AM, Alan Bateman <Alan.Bateman at oracle.com>
>> wrote:
>>
>>> On 12/02/2015 02:08, Martin Buchholz wrote:
>>>
>>>> Roger et al,
>>>>
>>>> Whichever way we go doesn't matter much.
>>>> But I continue to think that IOE is a better choice than UOE and I have
>>>> trouble seeing the motivation for the change to use UOE.
>>>> If you wanted to provide a way to tell if subprocess support was available
>>>> at all, then it would be better to add a new static boolean method to
>>>> Process (but I wouldn't support that either).
>>>> But (Roger and Alan): feel free to outvote me.
>>>>
>>>> I think Roger's proposal is reasonable as this is a case where the API
>>> will consistently throw UOE when the underlying runtime or operating system
>>> doesn't support a means to start processes. It's consistent with what was
>>> done for RMI activiation in JDK 8 (this was also about starting processes).
>>> Another example that comes to mind is the GUI libraries where
>>> HeadlessException is thrown (HeadlessException is a UOE). In the file
>>> system API then UOE is also specified when trying to use optional features
>>> that aren't supported by the implementation. There are probably many
>>> counter examples as we don't have consistency everywhere. In practical
>>> terms then I don't think this change should have an impact, but could be
>>> useful for those trying to take an existing app and run it on something
>>> like iOS. If that app relies on Runtime.exec or ProcessBuilder then the UOE
>>> should make it easy to identify that this part of the code needs to be
>>> looked at. If someday it is possible to start processes on such devices
>>> then an updated port to that platform wouldn't throw UOE anymore.
>>>
>>> -Alan.
>>>
>> If you threw a variant of UOE that was also an IOException, it would have
>> been equally clear to users, and no change to the contract of
>> ProcessBuilder would have been necessary.
>>
>> You've broken users who relied on the old spec. 		 	   		



From martinrb at google.com  Thu Feb 19 23:10:33 2015
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 19 Feb 2015 15:10:33 -0800
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <54E66449.6040509@Oracle.com>
References: <54CBAA39.3050004@Oracle.com> <54CBF7DB.9000909@oracle.com>
	<54CBFC10.9080502@Oracle.com>
	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>
	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>
	<54CD4305.4080607@oracle.com>
	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>
	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>
	<54CF7D1F.6050101@Oracle.com>
	<CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>
	<54CFE064.70400@Oracle.com>
	<CA+kOe0-zPJRpGEa0zXy6_bHgwNcnFWuSc1fbbxsc7-nc6SUjAg@mail.gmail.com>
	<54D08997.9020300@oracle.com>
	<CA+kOe091FHtd1Mnz_eVLcP0a_fC-+nXPGjnEdYr706XguBTy=g@mail.gmail.com>
	<54DBBA84.7090108@Oracle.com>
	<CA+kOe08VHA6h=6xVipyZ-xEx-XFBJ_mfd48GcnGJMaU0hQMQVA@mail.gmail.com>
	<54DC6D4B.3070902@oracle.com>
	<CA+kOe09QDOBmNRjkJKoSxstb=+EUqWCE3PNXT7Mi_=k2hH=k0Q@mail.gmail.com>
	<BLU175-W160A859502935C3D2894B2832D0@phx.gbl>
	<54E66449.6040509@Oracle.com>
Message-ID: <CA+kOe0_w_3spOtO-gnRvPeG4zZ=Oxd2BP5eKuauTHMT6fawXSw@mail.gmail.com>

The following kind of code is broken by the change to UOE:

boolean haveTrue = false;
try {
  new ProcessBuilder("/bin/true").start();
  haveTrue = true;
} catch (IOException e) { haveTrue = false; }

On Thu, Feb 19, 2015 at 2:31 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi Jason,
>
> In the case where there is *any* implementation of Process, IOException is
> the right way to expose OS dependencies.  But in the case where there is
> never
> going to be a successful Process, UOE is by far the more conventional and
> understandable exception.  Backward compatibility is not an absolute
> requirement.  I have no expectation that any existing application will run
> on the target device/OS combinations that this change is intended to
> support
> even without taking processes into account.
> No one has offered a use case or example to the contrary.  If this is not
> an
> academic or theoretical question, I'd appreciate a concrete example.
>
> Thanks, Roger
>
>
> On 2/19/2015 4:54 PM, Jason Mehrens wrote:
>
>> Standing with Martin on this, I wanted to note the following from the
>> ProcessBuilder docs:
>> "The exact nature of the exception is system-dependent, but it will
>> always be a subclass of IOException"
>>
>> The type of exception thrown is the one thing that is defined in the
>> spec.  The rest may be vague or have wiggle room but not the exception type.
>>
>>
>> I do appreciate the arguments on both sides but, I'm assuming that
>> compatibility is given more weight vs. correcting choices made in the
>> original design.
>>
>>
>> Jason
>>
>>
>>
>> ----------------------------------------
>>
>>> Date: Wed, 18 Feb 2015 21:41:40 -0800
>>> Subject: Re: RFR 9 8055330: (process spec) ProcessBuilder.start and
>>> Runtime.exec should throw UnsupportedOperationException ...
>>> From: martinrb at google.com
>>> To: Alan.Bateman at oracle.com
>>> CC: core-libs-dev at openjdk.java.net
>>>
>>> On Thu, Feb 12, 2015 at 1:07 AM, Alan Bateman <Alan.Bateman at oracle.com>
>>> wrote:
>>>
>>>  On 12/02/2015 02:08, Martin Buchholz wrote:
>>>>
>>>>  Roger et al,
>>>>>
>>>>> Whichever way we go doesn't matter much.
>>>>> But I continue to think that IOE is a better choice than UOE and I have
>>>>> trouble seeing the motivation for the change to use UOE.
>>>>> If you wanted to provide a way to tell if subprocess support was
>>>>> available
>>>>> at all, then it would be better to add a new static boolean method to
>>>>> Process (but I wouldn't support that either).
>>>>> But (Roger and Alan): feel free to outvote me.
>>>>>
>>>>> I think Roger's proposal is reasonable as this is a case where the API
>>>>>
>>>> will consistently throw UOE when the underlying runtime or operating
>>>> system
>>>> doesn't support a means to start processes. It's consistent with what
>>>> was
>>>> done for RMI activiation in JDK 8 (this was also about starting
>>>> processes).
>>>> Another example that comes to mind is the GUI libraries where
>>>> HeadlessException is thrown (HeadlessException is a UOE). In the file
>>>> system API then UOE is also specified when trying to use optional
>>>> features
>>>> that aren't supported by the implementation. There are probably many
>>>> counter examples as we don't have consistency everywhere. In practical
>>>> terms then I don't think this change should have an impact, but could be
>>>> useful for those trying to take an existing app and run it on something
>>>> like iOS. If that app relies on Runtime.exec or ProcessBuilder then the
>>>> UOE
>>>> should make it easy to identify that this part of the code needs to be
>>>> looked at. If someday it is possible to start processes on such devices
>>>> then an updated port to that platform wouldn't throw UOE anymore.
>>>>
>>>> -Alan.
>>>>
>>>>  If you threw a variant of UOE that was also an IOException, it would
>>> have
>>> been equally clear to users, and no change to the contract of
>>> ProcessBuilder would have been necessary.
>>>
>>> You've broken users who relied on the old spec.
>>>
>>>
>>
>


From vitalyd at gmail.com  Fri Feb 20 00:13:45 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 19 Feb 2015 19:13:45 -0500
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>
	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
Message-ID: <CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>

In addition to Peter's comment, full fence seems unnecessarily strong and
will cause performance issues (especially if the fence is per object in the
graph).  A storeFence should be sufficient here, no?

sent from my phone
On Feb 19, 2015 11:32 AM, "Chris Hegarty" <chris.hegarty at oracle.com> wrote:

> Additional note ( forgotten from original mail):
>
> The fence is needed for "final-freeze" is a one-off barrier at the end of
> deserialization, similar that of constructors . Under normal circumstances
> the object being deserialized is not visible until deserialization
> completes, so you don't need a "freeze" until deserialization completes.
>
> -Chris.
>
> On 19 Feb 2015, at 16:25, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>
> > A number of years ago there was a proposal to use Unsafe.put*Volatile
> methods to set final fields during default deserialisation [1][2], but it
> never made it due to concerns about the potential negative impact of the
> additional fences. Now we have a, private, fences API in the platform, I
> think it is time to revisit this.
> >
> > Webrev:
> >  http://cr.openjdk.java.net/~chegar/deserialFence/webrev.00/webrev/
> >
> > Note:
> >  - Section 17.5.3 in the JLS [3], ?Freezes of a final field occur both
> >    at the end of the constructor in which the final field is set, and
> >    immediately after each modification of a final field via reflection
> >    or other special mechanism.? I believe this is a consequence of
> >    the way in which setting of final fields is supported in the public
> >    API, Field.setAccessible(), ( as defined by JSR 133 ) and should
> >    not restrict an implementation from using a more performant
> >    means, as is suggested here.  The statement in the JLS should
> >    be revisited.
> >
> > - Default Serialization already has a dependency on Unsafe, and
> >   I don?t see this additional dependency as making that any worse.
> >
> > - Open question, should we include volatile fields as well as final?
> >
> > - The changes in the webrev will issue a fence even if custom
> >   deserialization is performed. I think this is ok, as it will be more
> >   consuming to try to determine if a custom readObject set a final
> >   through reflection, or not.
> >
> > -Chris.
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-6647361
> > [2]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-November/005292.html
> >
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-December/005456.html
> > [3]
> http://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.5.3
>
>


From david.holmes at oracle.com  Fri Feb 20 00:27:34 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Feb 2015 10:27:34 +1000
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
Message-ID: <54E67F76.8030104@oracle.com>

On 20/02/2015 10:13 AM, Vitaly Davidovich wrote:
> In addition to Peter's comment, full fence seems unnecessarily strong and
> will cause performance issues (especially if the fence is per object in the
> graph).  A storeFence should be sufficient here, no?

It should be a fence per graph, or perhaps branches thereof, not per object.

But yes a storeFence (horrible terminology :( ) would suffice given that 
the freeze action in constructors is only OrderAccess::storestore(). And 
Unsafe.storeFence() is OrderAccess::release() which is a 
storestore|storeload barrier.

David

>
> sent from my phone
> On Feb 19, 2015 11:32 AM, "Chris Hegarty" <chris.hegarty at oracle.com> wrote:
>
>> Additional note ( forgotten from original mail):
>>
>> The fence is needed for "final-freeze" is a one-off barrier at the end of
>> deserialization, similar that of constructors . Under normal circumstances
>> the object being deserialized is not visible until deserialization
>> completes, so you don't need a "freeze" until deserialization completes.
>>
>> -Chris.
>>
>> On 19 Feb 2015, at 16:25, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>
>>> A number of years ago there was a proposal to use Unsafe.put*Volatile
>> methods to set final fields during default deserialisation [1][2], but it
>> never made it due to concerns about the potential negative impact of the
>> additional fences. Now we have a, private, fences API in the platform, I
>> think it is time to revisit this.
>>>
>>> Webrev:
>>>   http://cr.openjdk.java.net/~chegar/deserialFence/webrev.00/webrev/
>>>
>>> Note:
>>>   - Section 17.5.3 in the JLS [3], ?Freezes of a final field occur both
>>>     at the end of the constructor in which the final field is set, and
>>>     immediately after each modification of a final field via reflection
>>>     or other special mechanism.? I believe this is a consequence of
>>>     the way in which setting of final fields is supported in the public
>>>     API, Field.setAccessible(), ( as defined by JSR 133 ) and should
>>>     not restrict an implementation from using a more performant
>>>     means, as is suggested here.  The statement in the JLS should
>>>     be revisited.
>>>
>>> - Default Serialization already has a dependency on Unsafe, and
>>>    I don?t see this additional dependency as making that any worse.
>>>
>>> - Open question, should we include volatile fields as well as final?
>>>
>>> - The changes in the webrev will issue a fence even if custom
>>>    deserialization is performed. I think this is ok, as it will be more
>>>    consuming to try to determine if a custom readObject set a final
>>>    through reflection, or not.
>>>
>>> -Chris.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-6647361
>>> [2]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-November/005292.html
>>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-December/005456.html
>>> [3]
>> http://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.5.3
>>
>>


From david.holmes at oracle.com  Fri Feb 20 02:26:11 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Feb 2015 12:26:11 +1000
Subject: RFR 8073354: TimSortStackSize2.java: requires
	64*2^20*sizeof(reference) continues heap space
In-Reply-To: <54E5E3B9.80703@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>
Message-ID: <54E69B43.4000501@oracle.com>

On 19/02/2015 11:23 PM, Lev Priima wrote:
> After Jespers comments I removed catch of OOME and added minimum heap
> size required for test(-Xms385) to overcome default ergonomics for client.
> Please review: http://cr.openjdk.java.net/~lpriima/8073354/webrev.01/

Didn't see this before sending my previous reply.

I'm confused now. What functional change is now being made here ??

Thanks,
David

> Lev
>
> On 02/19/2015 03:00 PM, Lev Priima wrote:
>> There is also a problem, if the memory on host is highly fragmented,
>> then we can't allocate continuous amount of heap for creating such big
>> array. I've added catch for OOME and treat this case as skip-pass to
>> make test more robust. Also I've removed explicit -Xmx385 from @run
>> tag and made it start with a single argument.
>>
>> Please review and push:
>> http://cr.openjdk.java.net/~lpriima/8073354/webrev.00/
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8073354
>>
>> Lev
>>
>> On 02/17/2015 09:55 AM, David Holmes wrote:
>>> On 17/02/2015 3:43 PM, Lev Priima wrote:
>>>> Thanks David!
>>>> Is this expected behavior of this annotation ?
>>>
>>> Yes that is the way jtreg defines tags:
>>>
>>> http://openjdk.java.net/jtreg/tag-spec.html
>>>
>>> "The argument tokens of a tag extend from the first token after the
>>> tag token to the end of the comment, the end of the file, or the next
>>> tag token, whichever comes first."
>>>
>>> So everything between @run and @summary are taken to be the @run
>>> commands. And there's no @comment tag unfortunately.
>>>
>>> David
>>>
>>>> Lev
>>>>
>>>> On 02/17/2015 03:20 AM, David Holmes wrote:
>>>>> On 16/02/2015 9:20 PM, David Holmes wrote:
>>>>>> On 16/02/2015 6:59 PM, Lev Priima wrote:
>>>>>>> Thanks, David,
>>>>>>> Could you please push it ?
>>>>>>
>>>>>> I will if Roger doesn't get to it first. It'll be 11 hours before
>>>>>> I can
>>>>>> push it.
>>>>>
>>>>> This has been pushed but note there is a minor issue with the test.
>>>>> The jtreg tag specification doesn't terminate tags on newlines, they
>>>>> continue until the next tag is encountered or the end of the comment.
>>>>> Consequently this:
>>>>>
>>>>>  * @run main/othervm -Xmx385m TimSortStackSize2 67108864
>>>>>  * not for regular execution on all platforms:
>>>>>  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>  * run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>>>
>>>>> is processed as:
>>>>>
>>>>> @run main/othervm -Xmx385m TimSortStackSize2 67108864 not for regular
>>>>> execution on all platforms: run main/othervm -Xmx8g TimSortStackSize2
>>>>> 1073741824 run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>>>
>>>>> and so TimSortStackSize2 is invoked with 18 arguments.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> David
>>>>>>
>>>>>>> Lev
>>>>>>>
>>>>>>> On 02/16/2015 08:55 AM, David Holmes wrote:
>>>>>>>> On 14/02/2015 12:03 AM, Lev Priima wrote:
>>>>>>>>> Please review and push:
>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073124
>>>>>>>>
>>>>>>>> I hadn't realized 8072909 had been pushed without final reviewer
>>>>>>>> comments being addressed. :(
>>>>>>>>
>>>>>>>> These changes seem okay. I hope they get promoted at the same
>>>>>>>> time as
>>>>>>>> the original changeset so we don't get test failures.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Lev
>>>>>>>>>
>>>>>>>>> On 02/13/2015 05:20 AM, David Holmes wrote:
>>>>>>>>>> Hi Lev,
>>>>>>>>>>
>>>>>>>>>> On 13/02/2015 2:56 AM, Lev Priima wrote:
>>>>>>>>>>> Christos,
>>>>>>>>>>>
>>>>>>>>>>> Test may fail on shorter arrays(page 8 of paper). For
>>>>>>>>>>> instance, on
>>>>>>>>>>> worst
>>>>>>>>>>> case, generated by test, it starts to fail on length 67108864.
>>>>>>>>>>> After increasing stack size of runs to merge, Arrays.sort(T[])
>>>>>>>>>>> works
>>>>>>>>>>> also on maximum possible array for HotSpot JVM.
>>>>>>>>>>
>>>>>>>>>> I'd also like to see this documented somewhere in the code.
>>>>>>>>>> Presently
>>>>>>>>>> there is a reference to listsort.txt but then you have to go and
>>>>>>>>>> find
>>>>>>>>>> it on the web. :( At a minimum could we please add:
>>>>>>>>>>
>>>>>>>>>>  175          * computation below must be changed if MIN_MERGE is
>>>>>>>>>> decreased.  See
>>>>>>>>>>  176          * the MIN_MERGE declaration above for more
>>>>>>>>>> information.
>>>>>>>>>> +             * The maximum value of 49 allows for an array up to
>>>>>>>>>> length
>>>>>>>>>> +             * Integer.MAX_VALUE-4.
>>>>>>>>>>
>>>>>>>>>>> Roger, David,
>>>>>>>>>>> I've updated the test (
>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ) to make it more suitable for regular execution:
>>>>>>>>>>>
>>>>>>>>>>>    27  * @run main/othervm TimSortStackSize2 67108864
>>>>>>>>>>
>>>>>>>>>> This will still fail on small memory devices:
>>>>>>>>>>
>>>>>>>>>> :~> java TimSortStackSize2 67108864
>>>>>>>>>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap
>>>>>>>>>> space
>>>>>>>>>>
>>>>>>>>>> as the default heap ergonomics may not be large enough. I had to
>>>>>>>>>> add a
>>>>>>>>>> minimum heap of -Xmx385M to get it to run.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>>    28  * not for regular execution on all platforms:
>>>>>>>>>>>    29  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>>>>>>>    30  * run main/othervm -Xmx32g TimSortStackSize2 2147483644
>>>>>>>>>>>
>>>>>>>>>>> Could you please push this:
>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>>>>>>>>>>> ?
>>>>>>>>>>>
>>>>>>>>>>> Lev
>>>>>>>>>>>
>>>>>>>>>>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>>>>>>>>>>> On Feb 12, 9:57pm,david.holmes at oracle.com  (David Holmes)
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> -- Subject: Re: 8072909: TimSort fails with
>>>>>>>>>>>> ArrayIndexOutOfBoundsException on
>>>>>>>>>>>>
>>>>>>>>>>>> | Ok - thanks Lev!
>>>>>>>>>>>> |
>>>>>>>>>>>> | David
>>>>>>>>>>>>
>>>>>>>>>>>> For posterity can someone document this, and also the value for
>>>>>>>>>>>> which
>>>>>>>>>>>> Integer.MAX_VALUE-4 fails?
>>>>>>>>>>>>
>>>>>>>>>>>> christos
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>>
>


From nobeh5 at gmail.com  Fri Feb 20 03:15:10 2015
From: nobeh5 at gmail.com (Behrooz Nobakht)
Date: Fri, 20 Feb 2015 04:15:10 +0100
Subject: Logging FileHandler: static locks and hardcoded maximum number
In-Reply-To: <54E60CC8.6030409@oracle.com>
References: <CAEEKBgU_-i1ki3bJTBQh7Q0K7NU4xgzmn=FbaRP+TJzgbgFS4A@mail.gmail.com>
	<54E5D1AC.7050607@oracle.com>
	<CAEEKBgXjm71hBjhHGnDs4A2wLiBXndQFuLWEh3ScaVZcDY1TNQ@mail.gmail.com>
	<54E5ECAE.4070000@oracle.com>
	<CAEEKBgVPGjFd8kK7QVDahcxUm71dFiLoEO_B_ROAgps3e6quHw@mail.gmail.com>
	<54E5F99E.8000404@oracle.com>
	<CAEEKBgXjkxvmDkp1-zUmBRSpE=xoJKKShewiRUh5G5z87zfEoQ@mail.gmail.com>
	<54E60CC8.6030409@oracle.com>
Message-ID: <CAEEKBgUoTXBkA+yRZnzCmTyaH0aA-jvU0zeSD+JJDyERHyaa-w@mail.gmail.com>

Hi Daniel,

Starting to create a minimal reproduction case for the
observations and the discussion, I think I have been
able to pin point a bug in our application. Basically,
it is a corner case for *properly* closing the FileHandler
instance in the end of p2 process. I have a minimal example,
with which actually I can confirm that all 8u25, 8u31, and 8u40ea
are working as expected. In this minimal example, if the FileHandler#close
is not properly used, then the same observations exist in regards with p1
and p2. If it is of interest for you, I can upload the showcase somewhere
such as GitHub.

Thanks,
Behrooz


On Thu, Feb 19, 2015 at 5:18 PM, Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi,
>
> On 19/02/15 16:30, Behrooz Nobakht wrote:
>
>> I'd be very happy to introduce an issue. But,
>> I've always failed to be able to create an account on
>> https://bugs.openjdk.java.net/secure/Dashboard.jspa
>> so, for me, the starting point is where I should do this?!
>>
>
> If you are not an OpenJDK member then I guess you should
> use http://bugs.java.com/ - and at some point this issue will
> be transferred to https://bugs.openjdk.java.net/
> where it (hopefully) will come in my inbox :-)
>
> You might want to refer to this email thread in your issue
> description.
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-
> February/031624.html
>
>
> best regards,
>
> -- daniel
>
>
>> On Thu, Feb 19, 2015 at 3:56 PM, Daniel Fuchs <daniel.fuchs at oracle.com
>> <mailto:daniel.fuchs at oracle.com>> wrote:
>>
>>     Thanks Behrooz.
>>
>>     Could you log an issue for this then?
>>     If you can attach a small reproducer it will be helpful.
>>
>>     There are a bunch of unit tests in the JDK that verify
>>     that FileHandler .lck files are correctly deleted - but
>>     these tests are all mono-process. I would like to make
>>     sure to chase down the real issue - so a small isolated
>>     reproducer would definitely help.
>>
>>     best regards,
>>
>>     -- daniel
>>
>>
>>     On 19/02/15 15:29, Behrooz Nobakht wrote:
>>
>>         Hi Daniel,
>>
>>         Thanks for referring to this ticket.
>>         Here is what I did.
>>
>>         My Java version:
>>
>>         java version "1.8.0_40-ea"
>>         Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b21)
>>         Java HotSpot(TM) 64-Bit Server VM (build 25.40-b24, mixed mode)
>>
>>         So, to make this more observable.
>>         The p1 process invokes a command with p2: start and stop.
>>         So, with 50 pairs of start and stop, we should be able to see the
>>         problem again.
>>
>>         I ran a script that invokes start from p1, gets the status of
>>         p2, stops
>>         p2 and confirms its status again.
>>         Here's the output from run 49:
>>
>>         ===
>>         run 49
>>         Invoking Start
>>         RUNNING
>>         Invoking Stop
>>         STOPPED
>>         run 49 - Done
>>         run 50
>>         Invoking Start
>>         RUNNING
>>         Invoking Stop
>>         STOPPED
>>         run 50 - Done
>>         run 51
>>         Invoking Start
>>         RUNNING
>>         Invoking Stop
>>         RUNNING
>>         run 51 - Done
>>         run 52
>>         Invoking Start
>>         STOPPED
>>         Invoking Stop
>>         STOPPED
>>         run 52 - Done
>>         run 53
>>         Invoking Start
>>         STOPPED
>>         Invoking Stop
>>         STOPPED
>>         run 53 - Done
>>         run 54
>>         Invoking Start
>>         STOPPED
>>         Invoking Stop
>>         STOPPED
>>         run 54 - Done
>>         ===
>>
>>         As the above shows, starting run 51, the expected status is
>>         violated.
>>         And, here is what I get a lsof of the log directory on the
>>         application:
>>
>>         ===
>>         -rw-rw-r-- 1 appuser appuser    0 Feb 19 15:19
>>         app.stdouterr.100.0.log.lck
>>         -rw-rw-r-- 1 appuser appuser 3.0K Feb 19 15:19
>>         app.stdouterr.100.0.log
>>         -rw-rw-r-- 1 appuser appuser    0 Feb 19 15:16
>>         app.stdouterr.0.0.log.lck
>>         -rw-rw-r-- 1 appuser appuser  366 Feb 19 15:16
>> app.stdouterr.0.0.log
>>         ===
>>
>>         Thanks for your time on this,
>>         Behrooz
>>
>>
>>
>>
>>
>>         On Thu, Feb 19, 2015 at 3:01 PM, Daniel Fuchs
>>         <daniel.fuchs at oracle.com <mailto:daniel.fuchs at oracle.com>
>>         <mailto:daniel.fuchs at oracle.__com
>>         <mailto:daniel.fuchs at oracle.com>>> wrote:
>>
>>              Hi Behrooz,
>>
>>              On 19/02/15 13:46, Behrooz Nobakht wrote:
>>
>>                  The version of Java is irrelevant. We have tested our
>> setup
>>                  on Java 7 and Java 8 u25/31. We observe the same
>> exception.
>>
>>
>>              Ok - then the version is indeed relevant ;-)
>>
>>              What you are observing may be a symptom of
>>         https://bugs.openjdk.java.net/____browse/JDK-8048020
>>         <https://bugs.openjdk.java.net/__browse/JDK-8048020>
>>              <https://bugs.openjdk.java.__net/browse/JDK-8048020
>>         <https://bugs.openjdk.java.net/browse/JDK-8048020>>
>>              which was fixed in 8u40 build 6.
>>
>>              If you would like to verify that this bug is indeed
>>              what is causing your issue, you may want to try out
>>              your setup with an early access build of 8u40, and
>>              see if the problem disappears.
>>
>>              Early access of 8u40 may be downloaded from there:
>>         https://jdk8.java.net/____download.html
>>         <https://jdk8.java.net/__download.html>
>>              <https://jdk8.java.net/__download.html
>>         <https://jdk8.java.net/download.html>>
>>
>>
>>              best regards,
>>
>>              -- daniel
>>
>>
>>
>>
>>         --
>>         -- Behrooz Nobakht
>>
>>
>>
>>
>>
>> --
>> -- Behrooz Nobakht
>>
>
>


-- 
-- Behrooz Nobakht


From mikhail.cherkasov at oracle.com  Fri Feb 20 06:58:21 2015
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Fri, 20 Feb 2015 09:58:21 +0300
Subject: [9] RFR of 8073187: Unexpected side effect in Pack200
Message-ID: <54E6DB0D.8020804@oracle.com>

Hi all,

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

The problem is that packer 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 instance:
http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/java/util/jar/Pack200.java#l149

The fix isn't perfect but it the only possible solution:
1. first packer saves default time zone
2. the last set it back.

Webrev:
http://cr.openjdk.java.net/~mcherkas/8073187/webrev/src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java.udiff.html

Thanks,
Mikhail.




From mikhail.cherkasov at oracle.com  Fri Feb 20 07:19:14 2015
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Fri, 20 Feb 2015 10:19:14 +0300
Subject: [9] RFR of 8073187: Unexpected side effect in Pack200
In-Reply-To: <54E6DB0D.8020804@oracle.com>
References: <54E6DB0D.8020804@oracle.com>
Message-ID: <54E6DFF2.6030405@oracle.com>

Sorry, I sent link to the old webrev, this is correct one:

http://cr.openjdk.java.net/~mcherkas/8073187/webrev.01/src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java.udiff.html

On 2/20/2015 9:58 AM, mikhail cherkasov wrote:
> Hi all,
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8073187
>
> The problem is that packer 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 instance:
> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/java/util/jar/Pack200.java#l149 
>
>
> The fix isn't perfect but it the only possible solution:
> 1. first packer saves default time zone
> 2. the last set it back.
>
> Webrev:
> http://cr.openjdk.java.net/~mcherkas/8073187/webrev/src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java.udiff.html 
>
>
> Thanks,
> Mikhail.
>
>



From daniel.fuchs at oracle.com  Fri Feb 20 09:22:54 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 20 Feb 2015 10:22:54 +0100
Subject: Logging FileHandler: static locks and hardcoded maximum number
In-Reply-To: <CAEEKBgUoTXBkA+yRZnzCmTyaH0aA-jvU0zeSD+JJDyERHyaa-w@mail.gmail.com>
References: <CAEEKBgU_-i1ki3bJTBQh7Q0K7NU4xgzmn=FbaRP+TJzgbgFS4A@mail.gmail.com>
	<54E5D1AC.7050607@oracle.com>
	<CAEEKBgXjm71hBjhHGnDs4A2wLiBXndQFuLWEh3ScaVZcDY1TNQ@mail.gmail.com>
	<54E5ECAE.4070000@oracle.com>
	<CAEEKBgVPGjFd8kK7QVDahcxUm71dFiLoEO_B_ROAgps3e6quHw@mail.gmail.com>
	<54E5F99E.8000404@oracle.com>
	<CAEEKBgXjkxvmDkp1-zUmBRSpE=xoJKKShewiRUh5G5z87zfEoQ@mail.gmail.com>
	<54E60CC8.6030409@oracle.com>
	<CAEEKBgUoTXBkA+yRZnzCmTyaH0aA-jvU0zeSD+JJDyERHyaa-w@mail.gmail.com>
Message-ID: <54E6FCEE.7040803@oracle.com>

On 2/20/15 4:15 AM, Behrooz Nobakht wrote:
> Hi Daniel,
>
> Starting to create a minimal reproduction case for the
> observations and the discussion, I think I have been
> able to pin point a bug in our application. Basically,
> it is a corner case for *properly* closing the FileHandler
> instance in the end of p2 process.

Hi Behrooz,

I'm glad you were able to pinpoint the issue - and relieved it
wasn't in the JDK after all :-)

> I have a minimal example,
> with which actually I can confirm that all 8u25, 8u31, and 8u40ea
> are working as expected. In this minimal example, if the FileHandler#close
> is not properly used, then the same observations exist in regards with p1
> and p2.

That makes sense - it's what I would have expected. But since file locking
implementation is essentially platform dependent there was always the
risk that something unusual had happened.

> If it is of interest for you, I can upload the showcase somewhere such 
> as GitHub.

Don't bother with that. Thanks for working on this test case and finding
out the actual issue!

best regards,

-- daniel

>
> Thanks,
> Behrooz
>
>
> On Thu, Feb 19, 2015 at 5:18 PM, Daniel Fuchs <daniel.fuchs at oracle.com 
> <mailto:daniel.fuchs at oracle.com>> wrote:
>
>     Hi,
>
>     On 19/02/15 16:30, Behrooz Nobakht wrote:
>
>         I'd be very happy to introduce an issue. But,
>         I've always failed to be able to create an account on
>         https://bugs.openjdk.java.net/secure/Dashboard.jspa
>         so, for me, the starting point is where I should do this?!
>
>
>     If you are not an OpenJDK member then I guess you should
>     use http://bugs.java.com/ - and at some point this issue will
>     be transferred to https://bugs.openjdk.java.net/
>     where it (hopefully) will come in my inbox :-)
>
>     You might want to refer to this email thread in your issue
>     description.
>     http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031624.html
>
>
>     best regards,
>
>     -- daniel
>
>
>         On Thu, Feb 19, 2015 at 3:56 PM, Daniel Fuchs
>         <daniel.fuchs at oracle.com <mailto:daniel.fuchs at oracle.com>
>         <mailto:daniel.fuchs at oracle.com
>         <mailto:daniel.fuchs at oracle.com>>> wrote:
>
>             Thanks Behrooz.
>
>             Could you log an issue for this then?
>             If you can attach a small reproducer it will be helpful.
>
>             There are a bunch of unit tests in the JDK that verify
>             that FileHandler .lck files are correctly deleted - but
>             these tests are all mono-process. I would like to make
>             sure to chase down the real issue - so a small isolated
>             reproducer would definitely help.
>
>             best regards,
>
>             -- daniel
>
>
>             On 19/02/15 15:29, Behrooz Nobakht wrote:
>
>                 Hi Daniel,
>
>                 Thanks for referring to this ticket.
>                 Here is what I did.
>
>                 My Java version:
>
>                 java version "1.8.0_40-ea"
>                 Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b21)
>                 Java HotSpot(TM) 64-Bit Server VM (build 25.40-b24,
>         mixed mode)
>
>                 So, to make this more observable.
>                 The p1 process invokes a command with p2: start and stop.
>                 So, with 50 pairs of start and stop, we should be able
>         to see the
>                 problem again.
>
>                 I ran a script that invokes start from p1, gets the
>         status of
>                 p2, stops
>                 p2 and confirms its status again.
>                 Here's the output from run 49:
>
>                 ===
>                 run 49
>                 Invoking Start
>                 RUNNING
>                 Invoking Stop
>                 STOPPED
>                 run 49 - Done
>                 run 50
>                 Invoking Start
>                 RUNNING
>                 Invoking Stop
>                 STOPPED
>                 run 50 - Done
>                 run 51
>                 Invoking Start
>                 RUNNING
>                 Invoking Stop
>                 RUNNING
>                 run 51 - Done
>                 run 52
>                 Invoking Start
>                 STOPPED
>                 Invoking Stop
>                 STOPPED
>                 run 52 - Done
>                 run 53
>                 Invoking Start
>                 STOPPED
>                 Invoking Stop
>                 STOPPED
>                 run 53 - Done
>                 run 54
>                 Invoking Start
>                 STOPPED
>                 Invoking Stop
>                 STOPPED
>                 run 54 - Done
>                 ===
>
>                 As the above shows, starting run 51, the expected
>         status is
>                 violated.
>                 And, here is what I get a lsof of the log directory on the
>                 application:
>
>                 ===
>                 -rw-rw-r-- 1 appuser appuser    0 Feb 19 15:19
>                 app.stdouterr.100.0.log.lck
>                 -rw-rw-r-- 1 appuser appuser 3.0K Feb 19 15:19
>                 app.stdouterr.100.0.log
>                 -rw-rw-r-- 1 appuser appuser    0 Feb 19 15:16
>                 app.stdouterr.0.0.log.lck
>                 -rw-rw-r-- 1 appuser appuser  366 Feb 19 15:16
>         app.stdouterr.0.0.log
>                 ===
>
>                 Thanks for your time on this,
>                 Behrooz
>
>
>
>
>
>                 On Thu, Feb 19, 2015 at 3:01 PM, Daniel Fuchs
>                 <daniel.fuchs at oracle.com
>         <mailto:daniel.fuchs at oracle.com>
>         <mailto:daniel.fuchs at oracle.com <mailto:daniel.fuchs at oracle.com>>
>                 <mailto:daniel.fuchs at oracle.
>         <mailto:daniel.fuchs at oracle.>__com
>                 <mailto:daniel.fuchs at oracle.com
>         <mailto:daniel.fuchs at oracle.com>>>> wrote:
>
>                      Hi Behrooz,
>
>                      On 19/02/15 13:46, Behrooz Nobakht wrote:
>
>                          The version of Java is irrelevant. We have
>         tested our setup
>                          on Java 7 and Java 8 u25/31. We observe the
>         same exception.
>
>
>                      Ok - then the version is indeed relevant ;-)
>
>                      What you are observing may be a symptom of
>         https://bugs.openjdk.java.net/____browse/JDK-8048020
>                 <https://bugs.openjdk.java.net/__browse/JDK-8048020>
>                      <https://bugs.openjdk.java.__net/browse/JDK-8048020
>                 <https://bugs.openjdk.java.net/browse/JDK-8048020>>
>                      which was fixed in 8u40 build 6.
>
>                      If you would like to verify that this bug is indeed
>                      what is causing your issue, you may want to try out
>                      your setup with an early access build of 8u40, and
>                      see if the problem disappears.
>
>                      Early access of 8u40 may be downloaded from there:
>         https://jdk8.java.net/____download.html
>                 <https://jdk8.java.net/__download.html>
>                      <https://jdk8.java.net/__download.html
>                 <https://jdk8.java.net/download.html>>
>
>
>                      best regards,
>
>                      -- daniel
>
>
>
>
>                 --
>                 -- Behrooz Nobakht
>
>
>
>
>
>         --
>         -- Behrooz Nobakht
>
>
>
>
>
> -- 
> -- Behrooz Nobakht



From lev.priima at oracle.com  Fri Feb 20 09:57:06 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Fri, 20 Feb 2015 12:57:06 +0300
Subject: RFR 8073354: TimSortStackSize2.java: requires
	64*2^20*sizeof(reference) continues heap space
In-Reply-To: <54E69B43.4000501@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>
Message-ID: <54E704F2.1010201@oracle.com>

Functional is pretty same, but:
  - make it run with a single argument '67108864' by moving @summary tag 
strait down to line after the @run tag
  - '-Xmx385' ->'-Xms385' in run command. MaxHeapSize will adjust a 
accordingly.
  - spaces and code style.

Of course this issue may be closed as dup of JDK-8073354 and test will 
pass after applying JDK-8073354. But I just want to use this RFE ID to 
make test run with a single argument ( as you noticed previously ).

Lev

On 02/20/2015 05:26 AM, David Holmes wrote:
> On 19/02/2015 11:23 PM, Lev Priima wrote:
>> After Jespers comments I removed catch of OOME and added minimum heap
>> size required for test(-Xms385) to overcome default ergonomics for 
>> client.
>> Please review: http://cr.openjdk.java.net/~lpriima/8073354/webrev.01/
>
> Didn't see this before sending my previous reply.
>
> I'm confused now. What functional change is now being made here ??
>
> Thanks,
> David
>
>> Lev
>>
>> On 02/19/2015 03:00 PM, Lev Priima wrote:
>>> There is also a problem, if the memory on host is highly fragmented,
>>> then we can't allocate continuous amount of heap for creating such big
>>> array. I've added catch for OOME and treat this case as skip-pass to
>>> make test more robust. Also I've removed explicit -Xmx385 from @run
>>> tag and made it start with a single argument.
>>>
>>> Please review and push:
>>> http://cr.openjdk.java.net/~lpriima/8073354/webrev.00/
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8073354
>>>
>>> Lev
>>>
>>> On 02/17/2015 09:55 AM, David Holmes wrote:
>>>> On 17/02/2015 3:43 PM, Lev Priima wrote:
>>>>> Thanks David!
>>>>> Is this expected behavior of this annotation ?
>>>>
>>>> Yes that is the way jtreg defines tags:
>>>>
>>>> http://openjdk.java.net/jtreg/tag-spec.html
>>>>
>>>> "The argument tokens of a tag extend from the first token after the
>>>> tag token to the end of the comment, the end of the file, or the next
>>>> tag token, whichever comes first."
>>>>
>>>> So everything between @run and @summary are taken to be the @run
>>>> commands. And there's no @comment tag unfortunately.
>>>>
>>>> David
>>>>
>>>>> Lev
>>>>>
>>>>> On 02/17/2015 03:20 AM, David Holmes wrote:
>>>>>> On 16/02/2015 9:20 PM, David Holmes wrote:
>>>>>>> On 16/02/2015 6:59 PM, Lev Priima wrote:
>>>>>>>> Thanks, David,
>>>>>>>> Could you please push it ?
>>>>>>>
>>>>>>> I will if Roger doesn't get to it first. It'll be 11 hours before
>>>>>>> I can
>>>>>>> push it.
>>>>>>
>>>>>> This has been pushed but note there is a minor issue with the test.
>>>>>> The jtreg tag specification doesn't terminate tags on newlines, they
>>>>>> continue until the next tag is encountered or the end of the 
>>>>>> comment.
>>>>>> Consequently this:
>>>>>>
>>>>>>  * @run main/othervm -Xmx385m TimSortStackSize2 67108864
>>>>>>  * not for regular execution on all platforms:
>>>>>>  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>>  * run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>>>>
>>>>>> is processed as:
>>>>>>
>>>>>> @run main/othervm -Xmx385m TimSortStackSize2 67108864 not for 
>>>>>> regular
>>>>>> execution on all platforms: run main/othervm -Xmx8g 
>>>>>> TimSortStackSize2
>>>>>> 1073741824 run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>>>>
>>>>>> and so TimSortStackSize2 is invoked with 18 arguments.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>> Lev
>>>>>>>>
>>>>>>>> On 02/16/2015 08:55 AM, David Holmes wrote:
>>>>>>>>> On 14/02/2015 12:03 AM, Lev Priima wrote:
>>>>>>>>>> Please review and push:
>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073124
>>>>>>>>>
>>>>>>>>> I hadn't realized 8072909 had been pushed without final reviewer
>>>>>>>>> comments being addressed. :(
>>>>>>>>>
>>>>>>>>> These changes seem okay. I hope they get promoted at the same
>>>>>>>>> time as
>>>>>>>>> the original changeset so we don't get test failures.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> Lev
>>>>>>>>>>
>>>>>>>>>> On 02/13/2015 05:20 AM, David Holmes wrote:
>>>>>>>>>>> Hi Lev,
>>>>>>>>>>>
>>>>>>>>>>> On 13/02/2015 2:56 AM, Lev Priima wrote:
>>>>>>>>>>>> Christos,
>>>>>>>>>>>>
>>>>>>>>>>>> Test may fail on shorter arrays(page 8 of paper). For
>>>>>>>>>>>> instance, on
>>>>>>>>>>>> worst
>>>>>>>>>>>> case, generated by test, it starts to fail on length 67108864.
>>>>>>>>>>>> After increasing stack size of runs to merge, Arrays.sort(T[])
>>>>>>>>>>>> works
>>>>>>>>>>>> also on maximum possible array for HotSpot JVM.
>>>>>>>>>>>
>>>>>>>>>>> I'd also like to see this documented somewhere in the code.
>>>>>>>>>>> Presently
>>>>>>>>>>> there is a reference to listsort.txt but then you have to go 
>>>>>>>>>>> and
>>>>>>>>>>> find
>>>>>>>>>>> it on the web. :( At a minimum could we please add:
>>>>>>>>>>>
>>>>>>>>>>>  175          * computation below must be changed if 
>>>>>>>>>>> MIN_MERGE is
>>>>>>>>>>> decreased.  See
>>>>>>>>>>>  176          * the MIN_MERGE declaration above for more
>>>>>>>>>>> information.
>>>>>>>>>>> +             * The maximum value of 49 allows for an array 
>>>>>>>>>>> up to
>>>>>>>>>>> length
>>>>>>>>>>> +             * Integer.MAX_VALUE-4.
>>>>>>>>>>>
>>>>>>>>>>>> Roger, David,
>>>>>>>>>>>> I've updated the test (
>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html 
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ) to make it more suitable for regular execution:
>>>>>>>>>>>>
>>>>>>>>>>>>    27  * @run main/othervm TimSortStackSize2 67108864
>>>>>>>>>>>
>>>>>>>>>>> This will still fail on small memory devices:
>>>>>>>>>>>
>>>>>>>>>>> :~> java TimSortStackSize2 67108864
>>>>>>>>>>> Exception in thread "main" java.lang.OutOfMemoryError: Java 
>>>>>>>>>>> heap
>>>>>>>>>>> space
>>>>>>>>>>>
>>>>>>>>>>> as the default heap ergonomics may not be large enough. I 
>>>>>>>>>>> had to
>>>>>>>>>>> add a
>>>>>>>>>>> minimum heap of -Xmx385M to get it to run.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>>    28  * not for regular execution on all platforms:
>>>>>>>>>>>>    29  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>>>>>>>>    30  * run main/othervm -Xmx32g TimSortStackSize2 2147483644
>>>>>>>>>>>>
>>>>>>>>>>>> Could you please push this:
>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>>>>>>>>>>>> ?
>>>>>>>>>>>>
>>>>>>>>>>>> Lev
>>>>>>>>>>>>
>>>>>>>>>>>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>>>>>>>>>>>> On Feb 12, 9:57pm,david.holmes at oracle.com  (David Holmes)
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> -- Subject: Re: 8072909: TimSort fails with
>>>>>>>>>>>>> ArrayIndexOutOfBoundsException on
>>>>>>>>>>>>>
>>>>>>>>>>>>> | Ok - thanks Lev!
>>>>>>>>>>>>> |
>>>>>>>>>>>>> | David
>>>>>>>>>>>>>
>>>>>>>>>>>>> For posterity can someone document this, and also the 
>>>>>>>>>>>>> value for
>>>>>>>>>>>>> which
>>>>>>>>>>>>> Integer.MAX_VALUE-4 fails?
>>>>>>>>>>>>>
>>>>>>>>>>>>> christos
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>
>>>
>>



From chris.hegarty at oracle.com  Fri Feb 20 11:34:27 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 20 Feb 2015 11:34:27 +0000
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <54E67F76.8030104@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com>
Message-ID: <54E71BC3.30403@oracle.com>

On 20/02/15 00:27, David Holmes wrote:
> On 20/02/2015 10:13 AM, Vitaly Davidovich wrote:
>> In addition to Peter's comment, full fence seems unnecessarily strong and
>> will cause performance issues (especially if the fence is per object
>> in the
>> graph).  A storeFence should be sufficient here, no?
>
> It should be a fence per graph, or perhaps branches thereof, not per
> object.

My original intent was to replicate the final-freeze action as performed 
by constructors. What I am hearing is that we do better, without any 
visible side-effect. Since the graph is not published until 
readObject/Unshared returns, the fence can be added there.

That said, it may be possible for one leaf in the graph to reference 
another, but to observe this ( in readObject ), there would have an 
implicit dependency on re-constructor order, which is fragile, at best.

> But yes a storeFence (horrible terminology :( ) would suffice given that
> the freeze action in constructors is only OrderAccess::storestore(). And
> Unsafe.storeFence() is OrderAccess::release() which is a
> storestore|storeload barrier.

Thanks, updated.

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

Note, the changes in this webrev are overly defensive in the face of 
recursive calls to readObject/Unshared. This should be ok, but probably 
not strictly necessary.

-Chris.


> David
>
>>
>> sent from my phone
>> On Feb 19, 2015 11:32 AM, "Chris Hegarty" <chris.hegarty at oracle.com>
>> wrote:
>>
>>> Additional note ( forgotten from original mail):
>>>
>>> The fence is needed for "final-freeze" is a one-off barrier at the
>>> end of
>>> deserialization, similar that of constructors . Under normal
>>> circumstances
>>> the object being deserialized is not visible until deserialization
>>> completes, so you don't need a "freeze" until deserialization completes.
>>>
>>> -Chris.
>>>
>>> On 19 Feb 2015, at 16:25, Chris Hegarty <chris.hegarty at oracle.com>
>>> wrote:
>>>
>>>> A number of years ago there was a proposal to use Unsafe.put*Volatile
>>> methods to set final fields during default deserialisation [1][2],
>>> but it
>>> never made it due to concerns about the potential negative impact of the
>>> additional fences. Now we have a, private, fences API in the platform, I
>>> think it is time to revisit this.
>>>>
>>>> Webrev:
>>>>   http://cr.openjdk.java.net/~chegar/deserialFence/webrev.00/webrev/
>>>>
>>>> Note:
>>>>   - Section 17.5.3 in the JLS [3], ?Freezes of a final field occur both
>>>>     at the end of the constructor in which the final field is set, and
>>>>     immediately after each modification of a final field via reflection
>>>>     or other special mechanism.? I believe this is a consequence of
>>>>     the way in which setting of final fields is supported in the public
>>>>     API, Field.setAccessible(), ( as defined by JSR 133 ) and should
>>>>     not restrict an implementation from using a more performant
>>>>     means, as is suggested here.  The statement in the JLS should
>>>>     be revisited.
>>>>
>>>> - Default Serialization already has a dependency on Unsafe, and
>>>>    I don?t see this additional dependency as making that any worse.
>>>>
>>>> - Open question, should we include volatile fields as well as final?
>>>>
>>>> - The changes in the webrev will issue a fence even if custom
>>>>    deserialization is performed. I think this is ok, as it will be more
>>>>    consuming to try to determine if a custom readObject set a final
>>>>    through reflection, or not.
>>>>
>>>> -Chris.
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-6647361
>>>> [2]
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-November/005292.html
>>>
>>>>
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-December/005456.html
>>>
>>>> [3]
>>> http://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.5.3
>>>
>>>


From Alan.Bateman at oracle.com  Fri Feb 20 11:49:47 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 20 Feb 2015 11:49:47 +0000
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <BLU175-W160A859502935C3D2894B2832D0@phx.gbl>
References: <54CBAA39.3050004@Oracle.com>, <54CBF7DB.9000909@oracle.com>,
	<54CBFC10.9080502@Oracle.com>,
	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>,
	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>,
	<54CD4305.4080607@oracle.com>,
	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>,
	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>,
	<54CF7D1F.6050101@Oracle.com>,
	<CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>,
	<54CFE064.70400@Oracle.com>,
	<CA+kOe0-zPJRpGEa0zXy6_bHgwNcnFWuSc1fbbxsc7-nc6SUjAg@mail.gmail.com>,
	<54D08997.9020300@oracle.com>,
	<CA+kOe091FHtd1Mnz_eVLcP0a_fC-+nXPGjnEdYr706XguBTy=g@mail.gmail.com>,
	<54DBBA84.7090108@Oracle.com>,
	<CA+kOe08VHA6h=6xVipyZ-xEx-XFBJ_mfd48GcnGJMaU0hQMQVA@mail.gmail.com>,
	<54DC6D4B.3070902@oracle.com>,
	<CA+kOe09QDOBmNRjkJKoSxstb=+EUqWCE3PNXT7Mi_=k2hH=k0Q@mail.gmail.com>
	<BLU175-W160A859502935C3D2894B2832D0@phx.gbl>
Message-ID: <54E71F5B.8060909@oracle.com>

On 19/02/2015 21:54, Jason Mehrens wrote:
> I'm assuming that compatibility is given more weight vs. correcting choices made in the original design.
>
Yes, I think we've spent more than enough time on it. In this case it's 
for a major release only and the compatibility impact seems to be only 
platforms or implementations that don't support launching of processes 
today but are running applications that attempt to start processes 
anyway. So overall it doesn't seem to be something to be overly 
concerned with.

-Alan


From aleksey.shipilev at oracle.com  Fri Feb 20 12:27:17 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 20 Feb 2015 15:27:17 +0300
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <CAHjP37H5VXcZzUYDMJFJ6URiUzSGe8YthhE2KHuLi9dunbT8NQ@mail.gmail.com>
References: <54E5F88F.6030502@oracle.com>	<54E5FA36.7030206@gmail.com>	<54E5FB07.6030400@oracle.com>	<54E5FE88.4000705@gmail.com>	<54E62ADC.1070501@oracle.com>
	<CAHjP37H5VXcZzUYDMJFJ6URiUzSGe8YthhE2KHuLi9dunbT8NQ@mail.gmail.com>
Message-ID: <54E72825.4020002@oracle.com>

On 02/19/2015 09:36 PM, Vitaly Davidovich wrote:
> The problem is microbenchmarking this may not tell the true story (like
> all microbenchmarks).  In this case the explicit test and branch is
> probably perfectly predicted because there's not much code.  In a bigger
> application, where the history fell out of the buffer, it'll depend on
> what static prediction is used.  Or, this branch will evict another
> useful one from the history buffer.  Not saying you're wrong in your
> suggestion to go ahead with this change, but something to keep in mind.

Noted, however the argument can be made that:
 a) that the same thing applies to getClass()-style checks for public
APIs. Once anybody calls the API method with nulls, the getClass() check
would inflate into explicit branch, and then you face the same branch
predictor behavior;
 b) the branch misprediction for otherwise stable branch is by
construction transient, and CPUs should re-learn quickly if we keep on
calling the method. If we don't, then the cost of branch mispredict is
not important to begin with. This should be taken with a grain of salt,
because only a selected few (definitely not me, quite probably no one
except HW engineers) know how exactly branch predictors work.

That said, the reasonable way you can address these (micro)things in
compiler is to intrinsify Object.requireNonNull to resist the profile
pollution and emit the implicit null check unconditionally. But I submit
that class library should not care about low-probability mispredict, and
do the thing that clearly declares intent. The performance cost of
profile pollution, is negligible for our cases.

-Aleksey.




From peter.levart at gmail.com  Fri Feb 20 12:48:07 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 20 Feb 2015 13:48:07 +0100
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E62ADC.1070501@oracle.com>
References: <54E5F88F.6030502@oracle.com> <54E5FA36.7030206@gmail.com>
	<54E5FB07.6030400@oracle.com> <54E5FE88.4000705@gmail.com>
	<54E62ADC.1070501@oracle.com>
Message-ID: <54E72D07.2020707@gmail.com>

On 02/19/2015 07:26 PM, Aleksey Shipilev wrote:
> However, if you do the actual benchmark that compares explicit NP checks
> vs implicit NP checks (that benchmark is very tricky to get right):
>   http://cr.openjdk.java.net/~shade/scratch/NullCheckPollution.java
>
> Benchmark         (count)  (pollute)  Mode  Cnt  Score   Error  Units
> NCP.testExplicit   100000      false  avgt   50  1.813 ? 0.004  ns/op
> NCP.testExplicit   100000       true  avgt   50  1.891 ? 0.029  ns/op
> NCP.testImplicit   100000      false  avgt   50  1.812 ? 0.003  ns/op
> NCP.testImplicit   100000       true  avgt   50  1.811 ? 0.001  ns/op
>
> There, testExplicit with pollution is the only one that has explicit
> test+branch. The difference is minuscule (< 1/3 of CPU cycle), and I
> would choose not to care, even for JDK code.

Hi Aleksey,

Good to know that requireNonNull is mostly not an issue after all. 
Thanks for taking time to create a real microbenchmark for it. I too 
have tried, but couldn't get it to show any difference between polluted 
and non-polluted test case (probably because I didn't use 
CompilerControl.Mode.DONT_INLINE ). Running your test on my hw (i7-2600K 
CPU) gives a little different result though (this is with 64bit JDK 8u20):


Benchmark                              (count)  (pollute)  Mode 
Samples   Score   Error  Units
j.t.NullCheckPollution.testExplicit     100000      false avgt       
50   1.908 ? 0.052  ns/op
j.t.NullCheckPollution.testExplicit     100000       true avgt       
50   2.291 ? 0.036  ns/op
j.t.NullCheckPollution.testImplicit     100000      false avgt       
50   1.906 ? 0.048  ns/op
j.t.NullCheckPollution.testImplicit     100000       true avgt       
50   1.865 ? 0.025  ns/op


...and with recent build of JDK9:


Benchmark                              (count)  (pollute)  Mode Samples  
Score   Error  Units
j.t.NullCheckPollution.testExplicit     100000      false avgt       50  
1.871 ? 0.056  ns/op
j.t.NullCheckPollution.testExplicit     100000       true avgt       50  
2.278 ? 0.022  ns/op
j.t.NullCheckPollution.testImplicit     100000      false avgt       50  
1.867 ? 0.025  ns/op
j.t.NullCheckPollution.testImplicit     100000       true avgt       50  
1.899 ? 0.058  ns/op


Perhaps my CPU is too old (4 years!) to be smart enough (like yours)? I 
checked on a Sparc-T5 CPU (JDK 8u40b23) too:


Benchmark                              (count)  (pollute)  Mode Samples  
Score   Error  Units
j.t.NullCheckPollution.testExplicit     100000      false avgt       50  
3.089 ? 0.062  ns/op
j.t.NullCheckPollution.testExplicit     100000       true avgt       50  
3.596 ? 0.090  ns/op
j.t.NullCheckPollution.testImplicit     100000      false avgt       50  
3.100 ? 0.060  ns/op
j.t.NullCheckPollution.testImplicit     100000       true avgt       50  
3.211 ? 0.204  ns/op


...but this only happens if the method doing explicit null check is not 
inlined into the test method. If I change DONT_INLINE -> INLINE, the 
difference is hidden within noise (i7-2600K, JDK9):


Benchmark                              (count)  (pollute)  Mode Samples  
Score   Error  Units
j.t.NullCheckPollution.testExplicit     100000      false avgt       50  
0.456 ? 0.005  ns/op
j.t.NullCheckPollution.testExplicit     100000       true avgt       50  
0.482 ? 0.024  ns/op
j.t.NullCheckPollution.testImplicit     100000      false avgt       50  
0.457 ? 0.006  ns/op
j.t.NullCheckPollution.testImplicit     100000       true avgt       50  
0.456 ? 0.004  ns/op


So we hope for Objects.requireNonNull to be inlined most of the times. 
It would be nice if @ForceInline annotation was accessible outside 
java.lang.invoke package, so methods like requireNonNull could benefit 
from it too. With modules, such platform annotations could be made 
public and put into a package (java.lang.internal) that is not exported 
to the world.


Regards, Peter





From claes.redestad at oracle.com  Fri Feb 20 12:54:03 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 20 Feb 2015 13:54:03 +0100
Subject: RFR: 8068790: ZipEntry/JarEntry.setCreation/LastAccessTime(null)
	don't throw NPE as specified
Message-ID: <54E72E6B.1000206@oracle.com>

Hi all,

please review this simple fix to do the right null checks in a few 
ZipEntry methods.

bug: https://bugs.openjdk.java.net/browse/JDK-8068790
webrev: http://cr.openjdk.java.net/~redestad/jdk9/8068790/webrev.0/

/Claes


From vladimir.x.ivanov at oracle.com  Fri Feb 20 13:15:30 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 20 Feb 2015 16:15:30 +0300
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E72D07.2020707@gmail.com>
References: <54E5F88F.6030502@oracle.com>
	<54E5FA36.7030206@gmail.com>	<54E5FB07.6030400@oracle.com>
	<54E5FE88.4000705@gmail.com>	<54E62ADC.1070501@oracle.com>
	<54E72D07.2020707@gmail.com>
Message-ID: <54E73372.3050603@oracle.com>

> So we hope for Objects.requireNonNull to be inlined most of the times.
> It would be nice if @ForceInline annotation was accessible outside
> java.lang.invoke package, so methods like requireNonNull could benefit
> from it too. With modules, such platform annotations could be made
> public and put into a package (java.lang.internal) that is not exported
> to the world.
I don't think @ForceInline is the right solution here.
I'd be happy to get rid of it in java.lang.invoke code as well :-)
Instead, JIT inlining heuristics should be tuned to favor inlining 
trivial and small methods.

There's -XX:MaxInlineSize(=35) flag in HotSpot. With current inlining 
heuristics, C1 & C2 should almost always inline the method.

Best regards,
Vladimir Ivanov


From aleksey.shipilev at oracle.com  Fri Feb 20 13:17:37 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 20 Feb 2015 16:17:37 +0300
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E72D07.2020707@gmail.com>
References: <54E5F88F.6030502@oracle.com> <54E5FA36.7030206@gmail.com>
	<54E5FB07.6030400@oracle.com> <54E5FE88.4000705@gmail.com>
	<54E62ADC.1070501@oracle.com> <54E72D07.2020707@gmail.com>
Message-ID: <54E733F1.7080705@oracle.com>

Hi Peter,

Thanks for additional testing!

On 02/20/2015 03:48 PM, Peter Levart wrote:
> So we hope for Objects.requireNonNull to be inlined most of the times.

Yes, I think so, otherwise it is a platform bug :) And, as I said in
reply to Vitaly, the ultimate answer would be to intrinsify
Objects.requireNonNull to unconditionally bias it towards the non-null
case and implicit NP checks.

The test is actually specifically crafted to amplify the costs of the
pollution. The side effect of that method is excessive method calls.
It's not a surprise CPUs can execute the dense code oblivious of minor
code differences. (Speculation: CPUs need to re-adjust their pipelines
after the real call, so non-inlined version would pay some extra)

Thanks,
-Aleksey




From vitalyd at gmail.com  Fri Feb 20 13:55:48 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 20 Feb 2015 08:55:48 -0500
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E73372.3050603@oracle.com>
References: <54E5F88F.6030502@oracle.com> <54E5FA36.7030206@gmail.com>
	<54E5FB07.6030400@oracle.com> <54E5FE88.4000705@gmail.com>
	<54E62ADC.1070501@oracle.com> <54E72D07.2020707@gmail.com>
	<54E73372.3050603@oracle.com>
Message-ID: <CAHjP37Guj-kT_xU7LTRkW2T-ur1Teq7P6WwF3+pn_3iXdXy6fA@mail.gmail.com>

Besides that, there's also FreqInlineSize with a much larger size threshold
if this method gets very hot.

sent from my phone
On Feb 20, 2015 8:16 AM, "Vladimir Ivanov" <vladimir.x.ivanov at oracle.com>
wrote:

> So we hope for Objects.requireNonNull to be inlined most of the times.
>> It would be nice if @ForceInline annotation was accessible outside
>> java.lang.invoke package, so methods like requireNonNull could benefit
>> from it too. With modules, such platform annotations could be made
>> public and put into a package (java.lang.internal) that is not exported
>> to the world.
>>
> I don't think @ForceInline is the right solution here.
> I'd be happy to get rid of it in java.lang.invoke code as well :-)
> Instead, JIT inlining heuristics should be tuned to favor inlining trivial
> and small methods.
>
> There's -XX:MaxInlineSize(=35) flag in HotSpot. With current inlining
> heuristics, C1 & C2 should almost always inline the method.
>
> Best regards,
> Vladimir Ivanov
>


From vitalyd at gmail.com  Fri Feb 20 14:01:59 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 20 Feb 2015 09:01:59 -0500
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E72825.4020002@oracle.com>
References: <54E5F88F.6030502@oracle.com> <54E5FA36.7030206@gmail.com>
	<54E5FB07.6030400@oracle.com> <54E5FE88.4000705@gmail.com>
	<54E62ADC.1070501@oracle.com>
	<CAHjP37H5VXcZzUYDMJFJ6URiUzSGe8YthhE2KHuLi9dunbT8NQ@mail.gmail.com>
	<54E72825.4020002@oracle.com>
Message-ID: <CAHjP37FWc1RABgSUNnYMf6b2cTwrQpxZxswOZDi72HS8dntwJA@mail.gmail.com>

So I'm in agreement with you as a whole.  The profile pollution issue is a
bigger concern than just requireNonNull; it means the generally useful (and
seemingly benign) practice of refactoring common code into a single place
can lead to performance regressions.  I do hope that's rectified somehow.

sent from my phone
On Feb 20, 2015 7:27 AM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
wrote:

> On 02/19/2015 09:36 PM, Vitaly Davidovich wrote:
> > The problem is microbenchmarking this may not tell the true story (like
> > all microbenchmarks).  In this case the explicit test and branch is
> > probably perfectly predicted because there's not much code.  In a bigger
> > application, where the history fell out of the buffer, it'll depend on
> > what static prediction is used.  Or, this branch will evict another
> > useful one from the history buffer.  Not saying you're wrong in your
> > suggestion to go ahead with this change, but something to keep in mind.
>
> Noted, however the argument can be made that:
>  a) that the same thing applies to getClass()-style checks for public
> APIs. Once anybody calls the API method with nulls, the getClass() check
> would inflate into explicit branch, and then you face the same branch
> predictor behavior;
>  b) the branch misprediction for otherwise stable branch is by
> construction transient, and CPUs should re-learn quickly if we keep on
> calling the method. If we don't, then the cost of branch mispredict is
> not important to begin with. This should be taken with a grain of salt,
> because only a selected few (definitely not me, quite probably no one
> except HW engineers) know how exactly branch predictors work.
>
> That said, the reasonable way you can address these (micro)things in
> compiler is to intrinsify Object.requireNonNull to resist the profile
> pollution and emit the implicit null check unconditionally. But I submit
> that class library should not care about low-probability mispredict, and
> do the thing that clearly declares intent. The performance cost of
> profile pollution, is negligible for our cases.
>
> -Aleksey.
>
>
>


From vitalyd at gmail.com  Fri Feb 20 14:20:08 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 20 Feb 2015 09:20:08 -0500
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E733F1.7080705@oracle.com>
References: <54E5F88F.6030502@oracle.com> <54E5FA36.7030206@gmail.com>
	<54E5FB07.6030400@oracle.com> <54E5FE88.4000705@gmail.com>
	<54E62ADC.1070501@oracle.com> <54E72D07.2020707@gmail.com>
	<54E733F1.7080705@oracle.com>
Message-ID: <CAHjP37GdqvSNT8u-oevHda7d76WEU1gOVwr6Rg+hOw0G9Am6zA@mail.gmail.com>

I really hope this doesn't require intrinsifying requireNonNull since, as
mentioned before, this is a general issue.  I'm almost tempted to say that
JIT should always treat a null check followed by an explicit NPE as being
an uncommon path, despite what profile may say.

sent from my phone
On Feb 20, 2015 8:18 AM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
wrote:

> Hi Peter,
>
> Thanks for additional testing!
>
> On 02/20/2015 03:48 PM, Peter Levart wrote:
> > So we hope for Objects.requireNonNull to be inlined most of the times.
>
> Yes, I think so, otherwise it is a platform bug :) And, as I said in
> reply to Vitaly, the ultimate answer would be to intrinsify
> Objects.requireNonNull to unconditionally bias it towards the non-null
> case and implicit NP checks.
>
> The test is actually specifically crafted to amplify the costs of the
> pollution. The side effect of that method is excessive method calls.
> It's not a surprise CPUs can execute the dense code oblivious of minor
> code differences. (Speculation: CPUs need to re-adjust their pipelines
> after the real call, so non-inlined version would pay some extra)
>
> Thanks,
> -Aleksey
>
>
>


From vitalyd at gmail.com  Fri Feb 20 14:25:44 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 20 Feb 2015 09:25:44 -0500
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <54E71BC3.30403@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>
	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com> <54E71BC3.30403@oracle.com>
Message-ID: <CAHjP37FBgwMwwYacnrDXhvFDhkeWhFE1aWWcGNQ5MBqAnvq7KQ@mail.gmail.com>

Chris,

I think it's fine if there are intra graph object references during
deserialization - nothing unexpected should happen since intra thread
semantics will be preserved.  The freeze action is only a concern once
deserialization completes and user code may publish an object from the
graph unsafely to another thread; that's the only place where the fence is
needed, I think.

sent from my phone
On Feb 20, 2015 6:28 AM, "Chris Hegarty" <chris.hegarty at oracle.com> wrote:

> On 20/02/15 00:27, David Holmes wrote:
>
>> On 20/02/2015 10:13 AM, Vitaly Davidovich wrote:
>>
>>> In addition to Peter's comment, full fence seems unnecessarily strong and
>>> will cause performance issues (especially if the fence is per object
>>> in the
>>> graph).  A storeFence should be sufficient here, no?
>>>
>>
>> It should be a fence per graph, or perhaps branches thereof, not per
>> object.
>>
>
> My original intent was to replicate the final-freeze action as performed
> by constructors. What I am hearing is that we do better, without any
> visible side-effect. Since the graph is not published until
> readObject/Unshared returns, the fence can be added there.
>
> That said, it may be possible for one leaf in the graph to reference
> another, but to observe this ( in readObject ), there would have an
> implicit dependency on re-constructor order, which is fragile, at best.
>
>  But yes a storeFence (horrible terminology :( ) would suffice given that
>> the freeze action in constructors is only OrderAccess::storestore(). And
>> Unsafe.storeFence() is OrderAccess::release() which is a
>> storestore|storeload barrier.
>>
>
> Thanks, updated.
>
> Updated Webrev:
>   http://cr.openjdk.java.net/~chegar/deserialFence/webrev.01/webrev/
>
> Note, the changes in this webrev are overly defensive in the face of
> recursive calls to readObject/Unshared. This should be ok, but probably not
> strictly necessary.
>
> -Chris.
>
>
>  David
>>
>>
>>> sent from my phone
>>> On Feb 19, 2015 11:32 AM, "Chris Hegarty" <chris.hegarty at oracle.com>
>>> wrote:
>>>
>>>  Additional note ( forgotten from original mail):
>>>>
>>>> The fence is needed for "final-freeze" is a one-off barrier at the
>>>> end of
>>>> deserialization, similar that of constructors . Under normal
>>>> circumstances
>>>> the object being deserialized is not visible until deserialization
>>>> completes, so you don't need a "freeze" until deserialization completes.
>>>>
>>>> -Chris.
>>>>
>>>> On 19 Feb 2015, at 16:25, Chris Hegarty <chris.hegarty at oracle.com>
>>>> wrote:
>>>>
>>>>  A number of years ago there was a proposal to use Unsafe.put*Volatile
>>>>>
>>>> methods to set final fields during default deserialisation [1][2],
>>>> but it
>>>> never made it due to concerns about the potential negative impact of the
>>>> additional fences. Now we have a, private, fences API in the platform, I
>>>> think it is time to revisit this.
>>>>
>>>>>
>>>>> Webrev:
>>>>>   http://cr.openjdk.java.net/~chegar/deserialFence/webrev.00/webrev/
>>>>>
>>>>> Note:
>>>>>   - Section 17.5.3 in the JLS [3], ?Freezes of a final field occur both
>>>>>     at the end of the constructor in which the final field is set, and
>>>>>     immediately after each modification of a final field via reflection
>>>>>     or other special mechanism.? I believe this is a consequence of
>>>>>     the way in which setting of final fields is supported in the public
>>>>>     API, Field.setAccessible(), ( as defined by JSR 133 ) and should
>>>>>     not restrict an implementation from using a more performant
>>>>>     means, as is suggested here.  The statement in the JLS should
>>>>>     be revisited.
>>>>>
>>>>> - Default Serialization already has a dependency on Unsafe, and
>>>>>    I don?t see this additional dependency as making that any worse.
>>>>>
>>>>> - Open question, should we include volatile fields as well as final?
>>>>>
>>>>> - The changes in the webrev will issue a fence even if custom
>>>>>    deserialization is performed. I think this is ok, as it will be more
>>>>>    consuming to try to determine if a custom readObject set a final
>>>>>    through reflection, or not.
>>>>>
>>>>> -Chris.
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-6647361
>>>>> [2]
>>>>>
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-
>>>> November/005292.html
>>>>
>>>>
>>>>>  http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-
>>>> December/005456.html
>>>>
>>>>  [3]
>>>>>
>>>> http://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.5.3
>>>>
>>>>
>>>>


From chris.hegarty at oracle.com  Fri Feb 20 14:35:44 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 20 Feb 2015 14:35:44 +0000
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <CAHjP37FBgwMwwYacnrDXhvFDhkeWhFE1aWWcGNQ5MBqAnvq7KQ@mail.gmail.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>	<54E67F76.8030104@oracle.com>	<54E71BC3.30403@oracle.com>
	<CAHjP37FBgwMwwYacnrDXhvFDhkeWhFE1aWWcGNQ5MBqAnvq7KQ@mail.gmail.com>
Message-ID: <54E74640.5000701@oracle.com>

On 20/02/15 14:25, Vitaly Davidovich wrote:
> Chris,
>
> I think it's fine if there are intra graph object references during
> deserialization - nothing unexpected should happen since intra thread
> semantics will be preserved.  The freeze action is only a concern once
> deserialization completes and user code may publish an object from the
> graph unsafely to another thread; that's the only place where the fence
> is needed, I think.

Agreed.

I'm happy the way this has turned out. The changes are minimal are 
resolve an issue that has been outstanding for some time now.

Thanks,
-Chris.

> sent from my phone
>
> On Feb 20, 2015 6:28 AM, "Chris Hegarty" <chris.hegarty at oracle.com
> <mailto:chris.hegarty at oracle.com>> wrote:
>
>     On 20/02/15 00:27, David Holmes wrote:
>
>         On 20/02/2015 10:13 AM, Vitaly Davidovich wrote:
>
>             In addition to Peter's comment, full fence seems
>             unnecessarily strong and
>             will cause performance issues (especially if the fence is
>             per object
>             in the
>             graph).  A storeFence should be sufficient here, no?
>
>
>         It should be a fence per graph, or perhaps branches thereof, not per
>         object.
>
>
>     My original intent was to replicate the final-freeze action as
>     performed by constructors. What I am hearing is that we do better,
>     without any visible side-effect. Since the graph is not published
>     until readObject/Unshared returns, the fence can be added there.
>
>     That said, it may be possible for one leaf in the graph to reference
>     another, but to observe this ( in readObject ), there would have an
>     implicit dependency on re-constructor order, which is fragile, at best.
>
>         But yes a storeFence (horrible terminology :( ) would suffice
>         given that
>         the freeze action in constructors is only
>         OrderAccess::storestore(). And
>         Unsafe.storeFence() is OrderAccess::release() which is a
>         storestore|storeload barrier.
>
>
>     Thanks, updated.
>
>     Updated Webrev:
>     http://cr.openjdk.java.net/~__chegar/deserialFence/webrev.__01/webrev/
>     <http://cr.openjdk.java.net/~chegar/deserialFence/webrev.01/webrev/>
>
>     Note, the changes in this webrev are overly defensive in the face of
>     recursive calls to readObject/Unshared. This should be ok, but
>     probably not strictly necessary.
>
>     -Chris.
>
>
>         David
>
>
>             sent from my phone
>             On Feb 19, 2015 11:32 AM, "Chris Hegarty"
>             <chris.hegarty at oracle.com <mailto:chris.hegarty at oracle.com>>
>             wrote:
>
>                 Additional note ( forgotten from original mail):
>
>                 The fence is needed for "final-freeze" is a one-off
>                 barrier at the
>                 end of
>                 deserialization, similar that of constructors . Under normal
>                 circumstances
>                 the object being deserialized is not visible until
>                 deserialization
>                 completes, so you don't need a "freeze" until
>                 deserialization completes.
>
>                 -Chris.
>
>                 On 19 Feb 2015, at 16:25, Chris Hegarty
>                 <chris.hegarty at oracle.com <mailto:chris.hegarty at oracle.com>>
>                 wrote:
>
>                     A number of years ago there was a proposal to use
>                     Unsafe.put*Volatile
>
>                 methods to set final fields during default
>                 deserialisation [1][2],
>                 but it
>                 never made it due to concerns about the potential
>                 negative impact of the
>                 additional fences. Now we have a, private, fences API in
>                 the platform, I
>                 think it is time to revisit this.
>
>
>                     Webrev:
>                     http://cr.openjdk.java.net/~__chegar/deserialFence/webrev.__00/webrev/
>                     <http://cr.openjdk.java.net/~chegar/deserialFence/webrev.00/webrev/>
>
>                     Note:
>                        - Section 17.5.3 in the JLS [3], ?Freezes of a
>                     final field occur both
>                          at the end of the constructor in which the
>                     final field is set, and
>                          immediately after each modification of a final
>                     field via reflection
>                          or other special mechanism.? I believe this is
>                     a consequence of
>                          the way in which setting of final fields is
>                     supported in the public
>                          API, Field.setAccessible(), ( as defined by JSR
>                     133 ) and should
>                          not restrict an implementation from using a
>                     more performant
>                          means, as is suggested here.  The statement in
>                     the JLS should
>                          be revisited.
>
>                     - Default Serialization already has a dependency on
>                     Unsafe, and
>                         I don?t see this additional dependency as making
>                     that any worse.
>
>                     - Open question, should we include volatile fields
>                     as well as final?
>
>                     - The changes in the webrev will issue a fence even
>                     if custom
>                         deserialization is performed. I think this is
>                     ok, as it will be more
>                         consuming to try to determine if a custom
>                     readObject set a final
>                         through reflection, or not.
>
>                     -Chris.
>
>                     [1]
>                     https://bugs.openjdk.java.net/__browse/JDK-6647361
>                     <https://bugs.openjdk.java.net/browse/JDK-6647361>
>                     [2]
>
>                 http://mail.openjdk.java.net/__pipermail/core-libs-dev/2010-__November/005292.html
>                 <http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-November/005292.html>
>
>
>                 http://mail.openjdk.java.net/__pipermail/core-libs-dev/2010-__December/005456.html
>                 <http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-December/005456.html>
>
>                     [3]
>
>                 http://docs.oracle.com/javase/__specs/jls/se8/html/jls-17.__html#jls-17.5.3
>                 <http://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.5.3>
>
>


From aleksey.shipilev at oracle.com  Fri Feb 20 14:43:20 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 20 Feb 2015 17:43:20 +0300
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E73372.3050603@oracle.com>
References: <54E5F88F.6030502@oracle.com>
	<54E5FA36.7030206@gmail.com>	<54E5FB07.6030400@oracle.com>
	<54E5FE88.4000705@gmail.com>	<54E62ADC.1070501@oracle.com>
	<54E72D07.2020707@gmail.com> <54E73372.3050603@oracle.com>
Message-ID: <54E74808.1010006@oracle.com>

On 02/20/2015 04:15 PM, Vladimir Ivanov wrote:
>> So we hope for Objects.requireNonNull to be inlined most of the times.
>> It would be nice if @ForceInline annotation was accessible outside
>> java.lang.invoke package, so methods like requireNonNull could benefit
>> from it too. With modules, such platform annotations could be made
>> public and put into a package (java.lang.internal) that is not exported
>> to the world.
> I don't think @ForceInline is the right solution here.
> I'd be happy to get rid of it in java.lang.invoke code as well :-)

Vladimir,

Can you take a look if java.lang.invoke.* changes look good for you?
  http://cr.openjdk.java.net/~shade/8073479/webrev.00/

Thanks,
-Aleksey.





From vladimir.x.ivanov at oracle.com  Fri Feb 20 14:51:46 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 20 Feb 2015 17:51:46 +0300
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E74808.1010006@oracle.com>
References: <54E5F88F.6030502@oracle.com>
	<54E5FA36.7030206@gmail.com>	<54E5FB07.6030400@oracle.com>
	<54E5FE88.4000705@gmail.com>	<54E62ADC.1070501@oracle.com>
	<54E72D07.2020707@gmail.com> <54E73372.3050603@oracle.com>
	<54E74808.1010006@oracle.com>
Message-ID: <54E74A02.5010401@oracle.com>

> Vladimir,
>
> Can you take a look if java.lang.invoke.* changes look good for you?
>    http://cr.openjdk.java.net/~shade/8073479/webrev.00/
Looks good.

Best regards,
Vladimir Ivanov


From aleksey.shipilev at oracle.com  Fri Feb 20 14:56:14 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 20 Feb 2015 17:56:14 +0300
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E74A02.5010401@oracle.com>
References: <54E5F88F.6030502@oracle.com>
	<54E5FA36.7030206@gmail.com>	<54E5FB07.6030400@oracle.com>
	<54E5FE88.4000705@gmail.com>	<54E62ADC.1070501@oracle.com>
	<54E72D07.2020707@gmail.com> <54E73372.3050603@oracle.com>
	<54E74808.1010006@oracle.com> <54E74A02.5010401@oracle.com>
Message-ID: <54E74B0E.5080309@oracle.com>

On 02/20/2015 05:51 PM, Vladimir Ivanov wrote:
>> Vladimir,
>>
>> Can you take a look if java.lang.invoke.* changes look good for you?
>>    http://cr.openjdk.java.net/~shade/8073479/webrev.00/
> Looks good.

Thank you for review!

-Aleksey.




From aleksey.shipilev at oracle.com  Fri Feb 20 15:01:18 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 20 Feb 2015 18:01:18 +0300
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E72D07.2020707@gmail.com>
References: <54E5F88F.6030502@oracle.com> <54E5FA36.7030206@gmail.com>
	<54E5FB07.6030400@oracle.com> <54E5FE88.4000705@gmail.com>
	<54E62ADC.1070501@oracle.com> <54E72D07.2020707@gmail.com>
Message-ID: <54E74C3E.9030308@oracle.com>

On 02/20/2015 03:48 PM, Peter Levart wrote:
> Good to know that requireNonNull is mostly not an issue after all.

Double-checking: you're OK to push the change, right?

-Aleksey.




From sean.coffey at oracle.com  Fri Feb 20 15:04:15 2015
From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=)
Date: Fri, 20 Feb 2015 15:04:15 +0000
Subject: RFR: 8068790: ZipEntry/JarEntry.setCreation/LastAccessTime(null)
	don't throw NPE as specified
In-Reply-To: <54E72E6B.1000206@oracle.com>
References: <54E72E6B.1000206@oracle.com>
Message-ID: <54E74CEF.4030702@oracle.com>

Looks fine to me Claes. From a supportability point of view, could I 
suggest that the exception string be made more informative ? (for cases 
where the stack may not be present - logs etc.)
i.e. "lastModifiedTime", "lastAccessTime", "creationTime".

Will you be porting this to jdk8u-dev also ?

regards,
Sean.

On 20/02/15 12:54, Claes Redestad wrote:
> Hi all,
>
> please review this simple fix to do the right null checks in a few 
> ZipEntry methods.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8068790
> webrev: http://cr.openjdk.java.net/~redestad/jdk9/8068790/webrev.0/
>
> /Claes



From peter.levart at gmail.com  Fri Feb 20 15:09:29 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 20 Feb 2015 16:09:29 +0100
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <54E71BC3.30403@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com> <54E71BC3.30403@oracle.com>
Message-ID: <54E74E29.2060806@gmail.com>

On 02/20/2015 12:34 PM, Chris Hegarty wrote:
>
>
> Updated Webrev:
> http://cr.openjdk.java.net/~chegar/deserialFence/webrev.01/webrev/
>
> Note, the changes in this webrev are overly defensive in the face of 
> recursive calls to readObject/Unshared. This should be ok, but 
> probably not strictly necessary.
>
> -Chris.
>

Hi Chris,

This looks good now. But I wonder if issuing fences after nested calls 
to readObject() makes much sense. If cycles are present in a subgraph 
deserialized by nested call to readObject(), a field pointing back to an 
object not part of the subgraph stream will point to the object that 
will not be fully initialized yet, so nested calls to readObject() 
should not be expected to return a reference to a fully constructed 
subgraph anyway. Only top-level call is guaranteed to return a fully 
constructed graph.

If you optimize this and only issue one fence for top-level call to 
readObject(), tracking of 'requiresFence' (I would call it 
requiresFreeze to be in line with JMM terminology - the fence is just a 
way to achieve freeze) can also be micro-optimized. You currently do it 
like this:

1900             requiresFence |= slotDesc.hasFinalField();

which is a shortcut for:

requiresFence = requiresFence | slotDesc.hasFinalField();

...which means that the field is overwritten multiple times 
unnecessarily and slotDesc.hasFinalField() is called every time. You can 
write the same logic as:

if (!requiresFence && slotDesc.hasFinalField()) {
     requiresFence = true;
}

There will be at most one write to the field and potentially less calls 
to slotDesc.hasFinalField().


Regards, Peter



From peter.levart at gmail.com  Fri Feb 20 15:11:41 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 20 Feb 2015 16:11:41 +0100
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E74C3E.9030308@oracle.com>
References: <54E5F88F.6030502@oracle.com> <54E5FA36.7030206@gmail.com>
	<54E5FB07.6030400@oracle.com> <54E5FE88.4000705@gmail.com>
	<54E62ADC.1070501@oracle.com> <54E72D07.2020707@gmail.com>
	<54E74C3E.9030308@oracle.com>
Message-ID: <54E74EAD.9040709@gmail.com>

On 02/20/2015 04:01 PM, Aleksey Shipilev wrote:
> On 02/20/2015 03:48 PM, Peter Levart wrote:
>> Good to know that requireNonNull is mostly not an issue after all.
> Double-checking: you're OK to push the change, right?
>
> -Aleksey.
>
>

OK!

Regards, Peter



From claes.redestad at oracle.com  Fri Feb 20 15:24:53 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 20 Feb 2015 16:24:53 +0100
Subject: RFR: 8068790: ZipEntry/JarEntry.setCreation/LastAccessTime(null)
	don't throw NPE as specified
In-Reply-To: <54E74CEF.4030702@oracle.com>
References: <54E72E6B.1000206@oracle.com> <54E74CEF.4030702@oracle.com>
Message-ID: <54E751C5.80807@oracle.com>

On 2015-02-20 16:04, Se?n Coffey wrote:
> Looks fine to me Claes. From a supportability point of view, could I 
> suggest that the exception string be made more informative ? (for 
> cases where the stack may not be present - logs etc.)
> i.e. "lastModifiedTime", "lastAccessTime", "creationTime".

Thanks!

Updated webrev: http://cr.openjdk.java.net/~redestad/jdk9/8068790/webrev.1/

>
> Will you be porting this to jdk8u-dev also ?

That seems appropriate. I'm not a JDK8 committer, though.

/Claes


From aleksey.shipilev at oracle.com  Fri Feb 20 15:33:54 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 20 Feb 2015 18:33:54 +0300
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E5F88F.6030502@oracle.com>
References: <54E5F88F.6030502@oracle.com>
Message-ID: <54E753E2.6030802@oracle.com>

On 02/19/2015 05:51 PM, Aleksey Shipilev wrote:
> Hi,
> 
> Please review and sponsor this cleanup fix:
>   http://cr.openjdk.java.net/~shade/8073479/webrev.00/
>   https://bugs.openjdk.java.net/browse/JDK-8073479
> 
> Summary: use Objects.requireNonNull instead of object.getClass to check
> for nullity.

Okay, the same webrev:
  http://cr.openjdk.java.net/~shade/8073479/webrev.00/

Now we have a few reviews, here is a changeset:
  http://cr.openjdk.java.net/~shade/8073479/8073479.changeset

Please sponsor!

Thanks,
-Aleksey.





From aph at redhat.com  Fri Feb 20 16:01:03 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 20 Feb 2015 16:01:03 +0000
Subject: Lexicographic array comparators
In-Reply-To: <5FB46769-CE5D-4710-84D4-8647A1AFF0EA@oracle.com>
References: <79B05B7B-CC06-4C6B-A29E-F3242F9EDE34@oracle.com>	<CA+kOe08e2ADM5yP5ZXkkf8qoNLtdLajb7Lt+fzayfSX1YeFhxg@mail.gmail.com>	<54DDF917.2050301@redhat.com>	<1BC12CF0-3B7C-458E-9A78-F37F2C419B4D@oracle.com>	<54DE0AD9.3080601@redhat.com>
	<5FB46769-CE5D-4710-84D4-8647A1AFF0EA@oracle.com>
Message-ID: <54E75A3F.1000707@redhat.com>

On 02/13/2015 02:58 PM, Paul Sandoz wrote:
> 
> On Feb 13, 2015, at 3:31 PM, Andrew Haley <aph at redhat.com> wrote:
> 
>> On 02/13/2015 01:56 PM, Paul Sandoz wrote:
>>> John suggested that a general array mis-match method could be achieved with carefully written Java code [1], and slightly hidden within that is the comment "FIXME: Add Unsafe.getLongMisaligned to avoid this cutout".
>>
>> Right, so we're definitely thinking along the same lines.  Maybe I
>> could do the HotSpot work for Unsafe.getUnalignedX.
> 
> Got for it! 
> 
> I would be happy to give it a test drive.

I have a patch that seems to work, but it's still rather raw.  It'll
need a lot of testing, I guess.  Do you want to try it now?

Andrew.




From sean.coffey at oracle.com  Fri Feb 20 16:34:00 2015
From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=)
Date: Fri, 20 Feb 2015 16:34:00 +0000
Subject: RFR: 8068790: ZipEntry/JarEntry.setCreation/LastAccessTime(null)
	don't throw NPE as specified
In-Reply-To: <54E751C5.80807@oracle.com>
References: <54E72E6B.1000206@oracle.com> <54E74CEF.4030702@oracle.com>
	<54E751C5.80807@oracle.com>
Message-ID: <54E761F8.4060603@oracle.com>


On 20/02/15 15:24, Claes Redestad wrote:
> On 2015-02-20 16:04, Se?n Coffey wrote:
>> Looks fine to me Claes. From a supportability point of view, could I 
>> suggest that the exception string be made more informative ? (for 
>> cases where the stack may not be present - logs etc.)
>> i.e. "lastModifiedTime", "lastAccessTime", "creationTime".
>
> Thanks!
>
> Updated webrev: 
> http://cr.openjdk.java.net/~redestad/jdk9/8068790/webrev.1/
>
>>
>> Will you be porting this to jdk8u-dev also ?
>
> That seems appropriate. I'm not a JDK8 committer, though.
Thanks for updating. I guess JDK-8065536 can be closed out as a 
duplicate now also. I've created a backport record for jdk8u and can 
pull this one back once you've pushed to JDK 9.

regards,
Sean.
>
> /Claes



From xueming.shen at oracle.com  Fri Feb 20 16:51:17 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 20 Feb 2015 08:51:17 -0800
Subject: RFR: 8068790: ZipEntry/JarEntry.setCreation/LastAccessTime(null)
	don't throw NPE as specified
In-Reply-To: <54E751C5.80807@oracle.com>
References: <54E72E6B.1000206@oracle.com> <54E74CEF.4030702@oracle.com>
	<54E751C5.80807@oracle.com>
Message-ID: <54E76605.1010303@oracle.com>

Hi Claes, thanks for working on this one!

The change looks fine. The msg indeed is more informative now, the most 
of the usages
of requireNonNull in jdk source code appears to pass in the name of the 
offending parameter.

-Sherman

On 2/20/15 7:24 AM, Claes Redestad wrote:
> On 2015-02-20 16:04, Se?n Coffey wrote:
>> Looks fine to me Claes. From a supportability point of view, could I 
>> suggest that the exception string be made more informative ? (for 
>> cases where the stack may not be present - logs etc.)
>> i.e. "lastModifiedTime", "lastAccessTime", "creationTime".
>
> Thanks!
>
> Updated webrev: 
> http://cr.openjdk.java.net/~redestad/jdk9/8068790/webrev.1/
>
>>
>> Will you be porting this to jdk8u-dev also ?
>
> That seems appropriate. I'm not a JDK8 committer, though.
>
> /Claes



From peter.levart at gmail.com  Fri Feb 20 17:00:53 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 20 Feb 2015 18:00:53 +0100
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E753E2.6030802@oracle.com>
References: <54E5F88F.6030502@oracle.com> <54E753E2.6030802@oracle.com>
Message-ID: <54E76845.3020905@gmail.com>


On 02/20/2015 04:33 PM, Aleksey Shipilev wrote:
> On 02/19/2015 05:51 PM, Aleksey Shipilev wrote:
>> Hi,
>>
>> Please review and sponsor this cleanup fix:
>>    http://cr.openjdk.java.net/~shade/8073479/webrev.00/
>>    https://bugs.openjdk.java.net/browse/JDK-8073479
>>
>> Summary: use Objects.requireNonNull instead of object.getClass to check
>> for nullity.
> Okay, the same webrev:
>    http://cr.openjdk.java.net/~shade/8073479/webrev.00/
>
> Now we have a few reviews, here is a changeset:
>    http://cr.openjdk.java.net/~shade/8073479/8073479.changeset
>
> Please sponsor!

I can sponsor this change (I haven't realized at first that you need a 
sponsor, sorry).

Regards, Peter


> Thanks,
> -Aleksey.
>
>
>



From dmitry.samersoff at oracle.com  Fri Feb 20 18:27:46 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Fri, 20 Feb 2015 21:27:46 +0300
Subject: RFR(S): JDK-8073584 Native compilation warning in unpack code
Message-ID: <54E77CA2.3090304@oracle.com>

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.


-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 martinrb at google.com  Fri Feb 20 18:34:43 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 20 Feb 2015 10:34:43 -0800
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <54E71F5B.8060909@oracle.com>
References: <54CBAA39.3050004@Oracle.com> <54CBF7DB.9000909@oracle.com>
	<54CBFC10.9080502@Oracle.com>
	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>
	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>
	<54CD4305.4080607@oracle.com>
	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>
	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>
	<54CF7D1F.6050101@Oracle.com>
	<CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>
	<54CFE064.70400@Oracle.com>
	<CA+kOe0-zPJRpGEa0zXy6_bHgwNcnFWuSc1fbbxsc7-nc6SUjAg@mail.gmail.com>
	<54D08997.9020300@oracle.com>
	<CA+kOe091FHtd1Mnz_eVLcP0a_fC-+nXPGjnEdYr706XguBTy=g@mail.gmail.com>
	<54DBBA84.7090108@Oracle.com>
	<CA+kOe08VHA6h=6xVipyZ-xEx-XFBJ_mfd48GcnGJMaU0hQMQVA@mail.gmail.com>
	<54DC6D4B.3070902@oracle.com>
	<CA+kOe09QDOBmNRjkJKoSxstb=+EUqWCE3PNXT7Mi_=k2hH=k0Q@mail.gmail.com>
	<BLU175-W160A859502935C3D2894B2832D0@phx.gbl>
	<54E71F5B.8060909@oracle.com>
Message-ID: <CA+kOe0--qCdqK=x8fKa5afY=GCOOtejMJ7O9YLnDRpDerj4z5A@mail.gmail.com>

One reason I keep pouring salt on this tiny wound is that throwing
(unchecked) UOE for system-dependent failures when normally IOE is thrown
is a fundamental design mistake for java and its checked exception design.
I think it violates Josh's Effective Java Item 58: Use checked exceptions
for recoverable conditions and runtime exceptions for programming errors.
I don't think it's worth fixing places in jdk8 where this small mistake was
made, but we can at least stop the incompatible worsening of existing APIs.

On Fri, Feb 20, 2015 at 3:49 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 19/02/2015 21:54, Jason Mehrens wrote:
>
>> I'm assuming that compatibility is given more weight vs. correcting
>> choices made in the original design.
>>
>>  Yes, I think we've spent more than enough time on it. In this case it's
> for a major release only and the compatibility impact seems to be only
> platforms or implementations that don't support launching of processes
> today but are running applications that attempt to start processes anyway.
> So overall it doesn't seem to be something to be overly concerned with.
>
> -Alan
>


From mandy.chung at oracle.com  Fri Feb 20 18:54:55 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 20 Feb 2015 10:54:55 -0800
Subject: Review Request: 8073361: Missing doPrivileged in
	com.sun.xml.internal.bind.v2.ClassFactory
Message-ID: <54E782FF.9010801@oracle.com>

This fixes a regression due to JDK-8057645 moving JAXB to ext loader
that was tested before the fix for JDK-8054367 went in jdk9.  This
was uncovered after JDK-8057645and JDK-8054367 met.

The fix is simple.  Class.getDeclaredConstructor on a class defined
by the null loader will require RuntimePermission("accessDeclaredMembers")
check that needs to be wrapped with doPrivileged block.

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8073361/webrev.00/

It doesn't change the behavior as previously when JAXB was loaded
by the null class loader that it always has access to any declared
member of any class (it's the ancestor of all class loaders).

Mandy
[1] http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/ef93f7aa0d2f


From daniel.fuchs at oracle.com  Fri Feb 20 19:40:13 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 20 Feb 2015 20:40:13 +0100
Subject: Review Request: 8073361: Missing doPrivileged in
	com.sun.xml.internal.bind.v2.ClassFactory
In-Reply-To: <54E782FF.9010801@oracle.com>
References: <54E782FF.9010801@oracle.com>
Message-ID: <54E78D9D.2050208@oracle.com>

Hi Mandy,

On 20/02/15 19:54, Mandy Chung wrote:
 > This fixes a regression due to JDK-8057645 moving JAXB to ext loader
 > that was tested before the fix for JDK-8054367 went in jdk9.  This
 > was uncovered after JDK-8057645and JDK-8054367 met.
 >
 > The fix is simple.  Class.getDeclaredConstructor on a class defined
 > by the null loader will require 
RuntimePermission("accessDeclaredMembers")
 > check that needs to be wrapped with doPrivileged block.
 >
 > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8073361/webrev.00/

The change looks OK - given that the call would have succeeded
when ClassFactory was in the boot.
You could have used limited doPrivileged but it is probably not
unnecessary.

best regards,

-- daniel

 > It doesn't change the behavior as previously when JAXB was loaded
 > by the null class loader that it always has access to any declared
 > member of any class (it's the ancestor of all class loaders).
 >
 > Mandy
 > [1] http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/ef93f7aa0d2f



From Roger.Riggs at Oracle.com  Fri Feb 20 19:58:00 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 20 Feb 2015 14:58:00 -0500
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <CA+kOe0--qCdqK=x8fKa5afY=GCOOtejMJ7O9YLnDRpDerj4z5A@mail.gmail.com>
References: <54CBAA39.3050004@Oracle.com>
	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>	<54CD4305.4080607@oracle.com>	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>	<54CF7D1F.6050101@Oracle.com>	<CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>	<54CFE064.70400@Oracle.com>	<CA+kOe0-zPJRpGEa0zXy6_bHgwNcnFWuSc1fbbxsc7-nc6SUjAg@mail.gmail.com>	<54D08997.9020300@oracle.com>	<CA+kOe091FHtd1Mnz_eVLcP0a_fC-+nXPGjnEdYr706XguBTy=g@mail.gmail.com>	<54DBBA84.7090108@Oracle.com>	<CA+kOe08VHA6h=6xVipyZ-xEx-XFBJ_mfd48GcnGJMaU0hQMQVA@mail.gmail.com>	<54DC6D4B.3070902@oracle.com>	<CA+kOe09QDOBmNRjkJKoSxstb=+EUqWCE3PNXT7Mi_=k2hH=k0Q@mail.gmail.com>	<BLU175-W160A859502935C3D2894B2832D0@phx.gbl>	<54E71F5B.8060909@oracle.com>
	<CA+kOe0--qCdqK=x8fKa5afY=GCOOtejMJ7O9YLnDRpDerj4z5A@mail.gmail.com>
Message-ID: <54E791C8.1080106@Oracle.com>

Hi Martin,

As I said earlier, launching a Process when process is not implemented
is not a recoverable condition; there are no conditions under which it will
succeed.  If the application is probing to determine what
is supported on a platform then it should be prepared to handle UOE
or using a test for the specific capability it requires.

Roger


On 2/20/2015 1:34 PM, Martin Buchholz wrote:
> One reason I keep pouring salt on this tiny wound is that throwing
> (unchecked) UOE for system-dependent failures when normally IOE is thrown
> is a fundamental design mistake for java and its checked exception design.
> I think it violates Josh's Effective Java Item 58: Use checked exceptions
> for recoverable conditions and runtime exceptions for programming errors.
> I don't think it's worth fixing places in jdk8 where this small mistake was
> made, but we can at least stop the incompatible worsening of existing APIs.
>
> On Fri, Feb 20, 2015 at 3:49 AM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 19/02/2015 21:54, Jason Mehrens wrote:
>>
>>> I'm assuming that compatibility is given more weight vs. correcting
>>> choices made in the original design.
>>>
>>>   Yes, I think we've spent more than enough time on it. In this case it's
>> for a major release only and the compatibility impact seems to be only
>> platforms or implementations that don't support launching of processes
>> today but are running applications that attempt to start processes anyway.
>> So overall it doesn't seem to be something to be overly concerned with.
>>
>> -Alan
>>



From martinrb at google.com  Fri Feb 20 21:06:05 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 20 Feb 2015 13:06:05 -0800
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <54E791C8.1080106@Oracle.com>
References: <54CBAA39.3050004@Oracle.com>
	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>
	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>
	<54CD4305.4080607@oracle.com>
	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>
	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>
	<54CF7D1F.6050101@Oracle.com>
	<CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>
	<54CFE064.70400@Oracle.com>
	<CA+kOe0-zPJRpGEa0zXy6_bHgwNcnFWuSc1fbbxsc7-nc6SUjAg@mail.gmail.com>
	<54D08997.9020300@oracle.com>
	<CA+kOe091FHtd1Mnz_eVLcP0a_fC-+nXPGjnEdYr706XguBTy=g@mail.gmail.com>
	<54DBBA84.7090108@Oracle.com>
	<CA+kOe08VHA6h=6xVipyZ-xEx-XFBJ_mfd48GcnGJMaU0hQMQVA@mail.gmail.com>
	<54DC6D4B.3070902@oracle.com>
	<CA+kOe09QDOBmNRjkJKoSxstb=+EUqWCE3PNXT7Mi_=k2hH=k0Q@mail.gmail.com>
	<BLU175-W160A859502935C3D2894B2832D0@phx.gbl>
	<54E71F5B.8060909@oracle.com>
	<CA+kOe0--qCdqK=x8fKa5afY=GCOOtejMJ7O9YLnDRpDerj4z5A@mail.gmail.com>
	<54E791C8.1080106@Oracle.com>
Message-ID: <CA+kOe084OgYxKw3URx04uriKZZ=ioaAsWh7775Emo1PbTODQYw@mail.gmail.com>

I totally disagree about "recoverable condition".  Instead of thinking
about "recovering", think instead about whether it ever makes sense to
catch the resulting exception.  See my sample code broken by the switch to
UOE.

On Fri, Feb 20, 2015 at 11:58 AM, Roger Riggs <Roger.Riggs at oracle.com>
wrote:

> Hi Martin,
>
> As I said earlier, launching a Process when process is not implemented
> is not a recoverable condition; there are no conditions under which it will
> succeed.  If the application is probing to determine what
> is supported on a platform then it should be prepared to handle UOE
> or using a test for the specific capability it requires.
>
> Roger
>
>
>
> On 2/20/2015 1:34 PM, Martin Buchholz wrote:
>
>> One reason I keep pouring salt on this tiny wound is that throwing
>> (unchecked) UOE for system-dependent failures when normally IOE is thrown
>> is a fundamental design mistake for java and its checked exception design.
>> I think it violates Josh's Effective Java Item 58: Use checked exceptions
>> for recoverable conditions and runtime exceptions for programming errors.
>> I don't think it's worth fixing places in jdk8 where this small mistake
>> was
>> made, but we can at least stop the incompatible worsening of existing
>> APIs.
>>
>> On Fri, Feb 20, 2015 at 3:49 AM, Alan Bateman <Alan.Bateman at oracle.com>
>> wrote:
>>
>>  On 19/02/2015 21:54, Jason Mehrens wrote:
>>>
>>>  I'm assuming that compatibility is given more weight vs. correcting
>>>> choices made in the original design.
>>>>
>>>>   Yes, I think we've spent more than enough time on it. In this case
>>>> it's
>>>>
>>> for a major release only and the compatibility impact seems to be only
>>> platforms or implementations that don't support launching of processes
>>> today but are running applications that attempt to start processes
>>> anyway.
>>> So overall it doesn't seem to be something to be overly concerned with.
>>>
>>> -Alan
>>>
>>>
>


From brian.burkhalter at oracle.com  Fri Feb 20 21:41:28 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 20 Feb 2015 13:41:28 -0800
Subject: {PING!} [9] RFR JDK-8068373: (prefs) FileSystemPreferences writes
	\0 to XML storage, causing loss of all preferences 
In-Reply-To: <F3199BF0-BBBA-4FA2-863F-B1AD7FDFBBC6@oracle.com>
References: <E0281603-FEA1-4B5A-9143-40E2D872D6F4@oracle.com>
	<4E5D3F46-5578-41F5-AE12-6F38A32E2259@oracle.com>
	<54E451B2.8050008@oracle.com>
	<F3199BF0-BBBA-4FA2-863F-B1AD7FDFBBC6@oracle.com>
Message-ID: <729FD4ED-8D78-4680-BFD2-71527E118DD3@oracle.com>

On Feb 18, 2015, at 7:27 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> On Feb 18, 2015, at 12:47 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
>> On 17/02/2015 21:56, Brian Burkhalter wrote:
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031502.html
>>> 
>>> 
>> It's good to see this changed to throw IAE. What about other methods that take a key (like get), do they need their javadoc updated too?
> 
> That?s a good point. I?ll take a look while the push of this change is pending the outcome of the CCC request I submitted.

Well the CCC request for this change to the put() method has been approved so now I return to the topic addressing the point above and noting an alternate possible approach.

1) Current Approach

If the present approach is maintained, the get(String,String) and remove(String) methods should also throw IAEs if any of their parameters are code point U+0000. This would require an updated patch and a re-spin of the review and CCC processes.

2) Alternate Approach

Reviewing the documentation in j.u.prefs.AbstractPreferences suggested to me an alternate approach perhaps more consistent with the extant specification. To be specific, consider these excerpts from the class documentation of AbstractPreferences:

<classDoc>
A. The SPI methods fall into three groups concerning exception behavior. The getSpi method should never throw exceptions, [?]

B. The remaining SPI methods putSpi(String,String), removeSpi(String) and childSpi(String) have more complicated exception behavior. They are not specified to throw BackingStoreException, as they can generally obey their contracts even if the backing store is unavailable. This is true because they return no information and their effects are not required to become permanent until a subsequent call to Preferences.flush() or Preferences.sync(). Generally speaking, these SPI methods should not throw exceptions. In some implementations, there may be circumstances under which these calls cannot even enqueue the requested operation for later processing. Even under these circumstances it is generally better to simply ignore the invocation and return, rather than throwing an exception. Under these circumstances, however, all subsequent invocations of flush() and sync should return false, as returning true would imply that all previous operations had successfully been made permanent.
</classDoc>

Note that the last sentence of the second paragraph above is in fact incorrect as both flush() and sync() are declared to ?return? void. Another bug ...
 
Considering the foregoing it seems to make some sense to make the following changes instead of those suggested in the currently approved approach:

i. getSpi(?\u0000?), putSpi(?\u0000?, ?\u0000?) and removeSpi(?\u0000?) are no-ops and throw no exception
ii. childSpi(U+0000) does something TBD

At your convenience any comments  you might be able to provide on these alternatives would be appreciated.

Thanks,

Brian

From brian.burkhalter at oracle.com  Fri Feb 20 22:30:29 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 20 Feb 2015 14:30:29 -0800
Subject: [8u60] RFR of 8071599: (so) Socket adapter sendUrgentData throws
	IllegalBlockingMode when channel configured non-blocking 
Message-ID: <FB2F0F9D-1CAC-4F58-97BA-EA8041B3FD77@oracle.com>

Please review at your convenience.

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

Summary: allow MSG_OOB (out-of-band byte) to be sent on the Socket associated with a SocketChannel when the Socket is in non-blocking mode. All JPRT tests pass as well as does a test which verifies that the intended objective of the change has been achieved.

Yes, I am aware that the copyright years need to be updated.

This request is being made directly to the JDK-8u60 project but is intended to be ported forward to the JDK 9 project in short order.

Thanks,

Brian

From joe.darcy at oracle.com  Sat Feb 21 00:59:57 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 20 Feb 2015 16:59:57 -0800
Subject: RFR: JDK-8051990 - Uninitialised memory in
	jdk/src/share/native/java/lang/fdlibm/src/k_standard.c
In-Reply-To: <54E49C23.4080803@oracle.com>
References: <54E493CD.6090905@oracle.com> <54E497FA.2010804@oracle.com>
	<54E49C23.4080803@oracle.com>
Message-ID: <54E7D88D.8050607@oracle.com>

Hello,

There is an upstream of sorts for fdlibm, but the code changes extremely 
rarely and I'm doubtful is these sorts of changes would be accepted.

I (still) plan to port fdlibm from C to Java these release (this time 
for sure!), but haven't done so yet.

Cheers,

-Joe

On 2/18/2015 6:05 AM, Mark Sheppard wrote:
>
> Hi Alan,
>
> as I understand it,
> it is a case that the switch statement doesn't have an explicit 
> default case, and as such it is seen that there is the potential
> for exc to return garbage as it is a local (stack) variable.
> code exc.return is not explicitly initialized in that scenario
>
> I have followed the comments 8011989 and set this to wnf
>
> but the fix below seemed the correct thing to do  ... it is a coding 
> style idiom
> as to whether switch statements should have an explicit default case.
>
> regards
> Mark
>
> On 18/02/2015 13:47, Alan Bateman wrote:
>> On 18/02/2015 13:29, Mark Sheppard wrote:
>>> Hi
>>>    please review the small change
>>> http://cr.openjdk.java.net/~msheppar/8051990/webrev/
>>>
>>> to address the parfait issue in
>>> https://bugs.openjdk.java.net/browse/JDK-8051990
>>>
>> Is this a false positive or is there really something calling 
>> __kernel_standard with an invalid type? If there is then setting 
>> errno would be good.
>>
>> The other thing that I wonder about is modifying fdlibm in OpenJDK, 
>> should fixes be sent upstream? I remember at one point there was a 
>> proposal to replace fdlibm with pure java code but I don't think this 
>> has bubbled up to the top of anyone's list yet.
>>
>> -Alan.
>



From richard.warburton at gmail.com  Sat Feb 21 12:12:41 2015
From: richard.warburton at gmail.com (Richard Warburton)
Date: Sat, 21 Feb 2015 12:12:41 +0000
Subject: Lower overhead String encoding/decoding
In-Reply-To: <54A458DE.1010204@oracle.com>
References: <CAMaYbvKQhUiQef06Av36m4U1DTWaDBoOyUe9SajnHJr0jHU=NA@mail.gmail.com>
	<54200F07.4070604@oracle.com>
	<CAMaYbv+Jc_98x7P2gGVEHJLsQq8kiSOx5EmmMjucwMhgKfNV7Q@mail.gmail.com>
	<542441BB.600@oracle.com>
	<CAMaYbvLhyVo7y_d7CFA6Vmg5vxUzCRyaKN2sNm2VRax=pd_1EA@mail.gmail.com>
	<5444BB17.8080708@oracle.com>
	<CAMaYbvJ63xVobqsywsafi+_dRzCVXtYDX9SCO5FAYbAGD_xz6Q@mail.gmail.com>
	<544FADA5.7000403@oracle.com> <544FB0F7.8080909@univ-mlv.fr>
	<CAMaYbvKcoX1renaBynPkdSRXCV9UT0CpE_opu6bbQyOoPOnaQQ@mail.gmail.com>
	<CAMaYbvKbAsFH3x6bHfngXzgLbj-y9sHgJiYy7h3i2NDAUcM-Kw@mail.gmail.com>
	<54737BC3.9010508@oracle.com> <5473A167.5040703@oracle.com>
	<CAMaYbvL1j+-6M_ZrAPjcTZo7FSYb6a+eOA_OFmT5_6J6PNCQtg@mail.gmail.com>
	<CAMaYbvLiJr32LsGMNG+CcTMQsu6N2sE1e5O5C_XnowQOfV5iuQ@mail.gmail.com>
	<54A458DE.1010204@oracle.com>
Message-ID: <CAMaYbvKYq0rzr3A7pLqsqj82=9+9qsG9bSG7gGV2qm9cwraTPw@mail.gmail.com>

Hi Xueming,

My apology for the delay, things are little slow during this period of the
> year:-)
> I will sponsor the rfe and prepare for the CCC (internally). We may need
> go through
> the api and the implementation one more time.
>

I was just wondering if there was any news on the CCC for this patch?

regards,

  Richard Warburton

  http://insightfullogic.com
  @RichardWarburto <http://twitter.com/richardwarburto>


From claes.redestad at oracle.com  Sat Feb 21 12:58:42 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 21 Feb 2015 13:58:42 +0100
Subject: RFR: 8068790: ZipEntry/JarEntry.setCreation/LastAccessTime(null)
	don't throw NPE as specified
In-Reply-To: <54E76605.1010303@oracle.com>
References: <54E72E6B.1000206@oracle.com>
	<54E74CEF.4030702@oracle.com>	<54E751C5.80807@oracle.com>
	<54E76605.1010303@oracle.com>
Message-ID: <54E88102.5080007@oracle.com>

Hi Sherman,

On 2015-02-20 17:51, Xueming Shen wrote:
> Hi Claes, thanks for working on this one!
>
> The change looks fine. The msg indeed is more informative now, the 
> most of the usages
> of requireNonNull in jdk source code appears to pass in the name of 
> the offending parameter.

no problem, and thanks for reviewing!

/Claes
>
> -Sherman
>
> On 2/20/15 7:24 AM, Claes Redestad wrote:
>> On 2015-02-20 16:04, Se?n Coffey wrote:
>>> Looks fine to me Claes. From a supportability point of view, could I 
>>> suggest that the exception string be made more informative ? (for 
>>> cases where the stack may not be present - logs etc.)
>>> i.e. "lastModifiedTime", "lastAccessTime", "creationTime".
>>
>> Thanks!
>>
>> Updated webrev: 
>> http://cr.openjdk.java.net/~redestad/jdk9/8068790/webrev.1/
>>
>>>
>>> Will you be porting this to jdk8u-dev also ?
>>
>> That seems appropriate. I'm not a JDK8 committer, though.
>>
>> /Claes
>



From claes.redestad at oracle.com  Sat Feb 21 13:04:11 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 21 Feb 2015 14:04:11 +0100
Subject: RFR: 8068790: ZipEntry/JarEntry.setCreation/LastAccessTime(null)
	don't throw NPE as specified
In-Reply-To: <54E761F8.4060603@oracle.com>
References: <54E72E6B.1000206@oracle.com> <54E74CEF.4030702@oracle.com>
	<54E751C5.80807@oracle.com> <54E761F8.4060603@oracle.com>
Message-ID: <54E8824B.5040201@oracle.com>

On 2015-02-20 17:34, Se?n Coffey wrote:
>
> On 20/02/15 15:24, Claes Redestad wrote:
>> On 2015-02-20 16:04, Se?n Coffey wrote:
>>> Looks fine to me Claes. From a supportability point of view, could I 
>>> suggest that the exception string be made more informative ? (for 
>>> cases where the stack may not be present - logs etc.)
>>> i.e. "lastModifiedTime", "lastAccessTime", "creationTime".
>>
>> Thanks!
>>
>> Updated webrev: 
>> http://cr.openjdk.java.net/~redestad/jdk9/8068790/webrev.1/
>>
>>>
>>> Will you be porting this to jdk8u-dev also ?
>>
>> That seems appropriate. I'm not a JDK8 committer, though.
> Thanks for updating. I guess JDK-8065536 can be closed out as a 
> duplicate now also. I've created a backport record for jdk8u and can 
> pull this one back once you've pushed to JDK 9.

Thanks for reviewing! Pushed and closed JDK-8065536 as a duplicate of this.

/Claes

>
> regards,
> Sean.
>>
>> /Claes
>



From claes.redestad at oracle.com  Sat Feb 21 14:34:19 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 21 Feb 2015 15:34:19 +0100
Subject: RFR(S): 8073497: Lazy conversion of ZipEntry time
Message-ID: <54E8976B.8050104@oracle.com>

Hi all,

please review this patch to re-introduce laziness in the java-to-dos time
conversions for the ZipEntry.time field.

Webrev: http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.0/
Bug: https://bugs.openjdk.java.net/browse/JDK-8073497

See bug for more details.

This behavior was actually the case before 8-b94, when the time field
was removed in favor of a set of FileTime fields, but when it was later
re-introduced to address some compatibility issues the conversion was
implemented in an eager fashion. This inadvertently affects VM startup
ever so little, since for every entry read via a ZipFile or ZipInputStream
we'll do a relatively expensive call creating a Date and doing timezone
conversion.

Some gains from loading fewer classes during VM startup, as well.

Thanks!

/Claes


From xueming.shen at oracle.com  Sat Feb 21 18:49:48 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Sat, 21 Feb 2015 10:49:48 -0800
Subject: RFR(S): 8073497: Lazy conversion of ZipEntry time
In-Reply-To: <54E8976B.8050104@oracle.com>
References: <54E8976B.8050104@oracle.com>
Message-ID: <54E8D34C.7000805@oracle.com>

Hi Claes,

This change basically undo the "fix" for 4759491 [1], for better 
performance ...

If we go with this change, I think we should also update the field 
comment back to the
original one to clearly indicates the "time" is "in DOS time".

-    long time = -1;     // modification time (in DOS time)
+    long mtime = -1;    // last modification time


The set/getLastModifiedTime() pair also need update to set/get the 
"time" field
correctly to/from the dos time.

-Sherman

[1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/90df6756406f

On 2/21/15 6:34 AM, Claes Redestad wrote:
> Hi all,
>
> please review this patch to re-introduce laziness in the java-to-dos time
> conversions for the ZipEntry.time field.
>
> Webrev: http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.0/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8073497
>
> See bug for more details.
>
> This behavior was actually the case before 8-b94, when the time field
> was removed in favor of a set of FileTime fields, but when it was later
> re-introduced to address some compatibility issues the conversion was
> implemented in an eager fashion. This inadvertently affects VM startup
> ever so little, since for every entry read via a ZipFile or 
> ZipInputStream
> we'll do a relatively expensive call creating a Date and doing timezone
> conversion.
>
> Some gains from loading fewer classes during VM startup, as well.
>
> Thanks!
>
> /Claes



From scolebourne at joda.org  Sat Feb 21 21:55:27 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sat, 21 Feb 2015 21:55:27 +0000
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <CA+kOe084OgYxKw3URx04uriKZZ=ioaAsWh7775Emo1PbTODQYw@mail.gmail.com>
References: <54CBAA39.3050004@Oracle.com>
	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>
	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>
	<54CD4305.4080607@oracle.com>
	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>
	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>
	<54CF7D1F.6050101@Oracle.com>
	<CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>
	<54CFE064.70400@Oracle.com>
	<CA+kOe0-zPJRpGEa0zXy6_bHgwNcnFWuSc1fbbxsc7-nc6SUjAg@mail.gmail.com>
	<54D08997.9020300@oracle.com>
	<CA+kOe091FHtd1Mnz_eVLcP0a_fC-+nXPGjnEdYr706XguBTy=g@mail.gmail.com>
	<54DBBA84.7090108@Oracle.com>
	<CA+kOe08VHA6h=6xVipyZ-xEx-XFBJ_mfd48GcnGJMaU0hQMQVA@mail.gmail.com>
	<54DC6D4B.3070902@oracle.com>
	<CA+kOe09QDOBmNRjkJKoSxstb=+EUqWCE3PNXT7Mi_=k2hH=k0Q@mail.gmail.com>
	<BLU175-W160A859502935C3D2894B2832D0@phx.gbl>
	<54E71F5B.8060909@oracle.com>
	<CA+kOe0--qCdqK=x8fKa5afY=GCOOtejMJ7O9YLnDRpDerj4z5A@mail.gmail.com>
	<54E791C8.1080106@Oracle.com>
	<CA+kOe084OgYxKw3URx04uriKZZ=ioaAsWh7775Emo1PbTODQYw@mail.gmail.com>
Message-ID: <CACzrW9A42U33s8Op-7eGuDMjH5AytqrwYUEDauEF+RZ0imNb0Q@mail.gmail.com>

FWIW, I think UOE is clearly the right exception for a method that is
unsupported. An IOExeption is very much associated with the actual IO
system.
Stephen

On 20 February 2015 at 21:06, Martin Buchholz <martinrb at google.com> wrote:
> I totally disagree about "recoverable condition".  Instead of thinking
> about "recovering", think instead about whether it ever makes sense to
> catch the resulting exception.  See my sample code broken by the switch to
> UOE.
>
> On Fri, Feb 20, 2015 at 11:58 AM, Roger Riggs <Roger.Riggs at oracle.com>
> wrote:
>
>> Hi Martin,
>>
>> As I said earlier, launching a Process when process is not implemented
>> is not a recoverable condition; there are no conditions under which it will
>> succeed.  If the application is probing to determine what
>> is supported on a platform then it should be prepared to handle UOE
>> or using a test for the specific capability it requires.
>>
>> Roger
>>
>>
>>
>> On 2/20/2015 1:34 PM, Martin Buchholz wrote:
>>
>>> One reason I keep pouring salt on this tiny wound is that throwing
>>> (unchecked) UOE for system-dependent failures when normally IOE is thrown
>>> is a fundamental design mistake for java and its checked exception design.
>>> I think it violates Josh's Effective Java Item 58: Use checked exceptions
>>> for recoverable conditions and runtime exceptions for programming errors.
>>> I don't think it's worth fixing places in jdk8 where this small mistake
>>> was
>>> made, but we can at least stop the incompatible worsening of existing
>>> APIs.
>>>
>>> On Fri, Feb 20, 2015 at 3:49 AM, Alan Bateman <Alan.Bateman at oracle.com>
>>> wrote:
>>>
>>>  On 19/02/2015 21:54, Jason Mehrens wrote:
>>>>
>>>>  I'm assuming that compatibility is given more weight vs. correcting
>>>>> choices made in the original design.
>>>>>
>>>>>   Yes, I think we've spent more than enough time on it. In this case
>>>>> it's
>>>>>
>>>> for a major release only and the compatibility impact seems to be only
>>>> platforms or implementations that don't support launching of processes
>>>> today but are running applications that attempt to start processes
>>>> anyway.
>>>> So overall it doesn't seem to be something to be overly concerned with.
>>>>
>>>> -Alan
>>>>
>>>>
>>


From jason_mehrens at hotmail.com  Sat Feb 21 22:03:46 2015
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Sat, 21 Feb 2015 16:03:46 -0600
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <CA+kOe084OgYxKw3URx04uriKZZ=ioaAsWh7775Emo1PbTODQYw@mail.gmail.com>
References: <54CBAA39.3050004@Oracle.com>,
	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>,
	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>,
	<54CD4305.4080607@oracle.com>,
	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>,
	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>,
	<54CF7D1F.6050101@Oracle.com>,
	<CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>,
	<54CFE064.70400@Oracle.com>,
	<CA+kOe0-zPJRpGEa0zXy6_bHgwNcnFWuSc1fbbxsc7-nc6SUjAg@mail.gmail.com>,
	<54D08997.9020300@oracle.com>,
	<CA+kOe091FHtd1Mnz_eVLcP0a_fC-+nXPGjnEdYr706XguBTy=g@mail.gmail.com>,
	<54DBBA84.7090108@Oracle.com>,
	<CA+kOe08VHA6h=6xVipyZ-xEx-XFBJ_mfd48GcnGJMaU0hQMQVA@mail.gmail.com>,
	<54DC6D4B.3070902@oracle.com>,
	<CA+kOe09QDOBmNRjkJKoSxstb=+EUqWCE3PNXT7Mi_=k2hH=k0Q@mail.gmail.com>,
	<BLU175-W160A859502935C3D2894B2832D0@phx.gbl>,
	<54E71F5B.8060909@oracle.com>,
	<CA+kOe0--qCdqK=x8fKa5afY=GCOOtejMJ7O9YLnDRpDerj4z5A@mail.gmail.com>,
	<54E791C8.1080106@Oracl , e.com>,
	<CA+kOe084OgYxKw3URx04uriKZZ=ioaAsWh7775Emo1PbTODQYw@mail.gmail.com>
Message-ID: <BLU175-W52F51DB26CB33B714F056E832B0@phx.gbl>

Hi Roger,

For what it is worth, the most common production use case for me is:

1. Generate output from some source to a temp file.
2. Use ProcessBuilder to launch process (native or JVM) for using temp file.
3. If that fails with IOException fallback to opening a save dialog.
4. The end user will use #2 or #3 to save the file to a known location.
5. The end user will finish final product or get it to a machine that works then finish the final product.
6. (non)Profit.


So in this case you wait around for #1 to get done and as long as #2 or #3 work then #1 wasn't a wasted effort. In the UOE case 3 through 6 are skipped which is a bad deal for the end user.  This is 15+ years still in production code where the steps were crafted by a natural evolution of the Murphy's Law based environment that it exists in.  End of life for this code is not in sight.


Save your health and don't think too hard about the example, try to apply logic to it, or tear it down.  It is not my intent to hold this example up as 'the best counter argument', 'sky is falling' or to drag this thread out.  The point is, no where in the example does the calling code or user care about the distinction between never being able to create a process or creating a process failed this time.  For this code, throwing UOE is a breaking feature not a bug fix.  The only known thing was the API contract.  Everything else was assumed to be broken.


I do appreciate your time, Alan's time, the time you have spent on this issue, and your arguments as they are logical.  We just differ on applying the logic to this case.  I also understand the decision has been made and that will be the future.  I'll just have to be prepared for it and Murphy.


Respectfully,


Jason


----------------------------------------
> Date: Fri, 20 Feb 2015 13:06:05 -0800
> Subject: Re: RFR 9 8055330: (process spec) ProcessBuilder.start and Runtime.exec should throw UnsupportedOperationException ...
> From: martinrb at google.com
> To: Roger.Riggs at oracle.com
> CC: core-libs-dev at openjdk.java.net
>
> I totally disagree about "recoverable condition". Instead of thinking
> about "recovering", think instead about whether it ever makes sense to
> catch the resulting exception. See my sample code broken by the switch to
> UOE.
>
> On Fri, Feb 20, 2015 at 11:58 AM, Roger Riggs <Roger.Riggs at oracle.com>
> wrote:
>
>> Hi Martin,
>>
>> As I said earlier, launching a Process when process is not implemented
>> is not a recoverable condition; there are no conditions under which it will
>> succeed. If the application is probing to determine what
>> is supported on a platform then it should be prepared to handle UOE
>> or using a test for the specific capability it requires.
>>
>> Roger
>>
>>
>>
>> On 2/20/2015 1:34 PM, Martin Buchholz wrote:
>>
>>> One reason I keep pouring salt on this tiny wound is that throwing
>>> (unchecked) UOE for system-dependent failures when normally IOE is thrown
>>> is a fundamental design mistake for java and its checked exception design.
>>> I think it violates Josh's Effective Java Item 58: Use checked exceptions
>>> for recoverable conditions and runtime exceptions for programming errors.
>>> I don't think it's worth fixing places in jdk8 where this small mistake
>>> was
>>> made, but we can at least stop the incompatible worsening of existing
>>> APIs.
>>>
>>> On Fri, Feb 20, 2015 at 3:49 AM, Alan Bateman <Alan.Bateman at oracle.com>
>>> wrote:
>>>
>>> On 19/02/2015 21:54, Jason Mehrens wrote:
>>>>
>>>> I'm assuming that compatibility is given more weight vs. correcting
>>>>> choices made in the original design.
>>>>>
>>>>> Yes, I think we've spent more than enough time on it. In this case
>>>>> it's
>>>>>
>>>> for a major release only and the compatibility impact seems to be only
>>>> platforms or implementations that don't support launching of processes
>>>> today but are running applications that attempt to start processes
>>>> anyway.
>>>> So overall it doesn't seem to be something to be overly concerned with.
>>>>
>>>> -Alan
>>>>
>>>>
>> 		 	   		  

From john.r.rose at oracle.com  Sun Feb 22 00:11:15 2015
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 21 Feb 2015 16:11:15 -0800
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <54E74A02.5010401@oracle.com>
References: <54E5F88F.6030502@oracle.com> <54E5FA36.7030206@gmail.com>
	<54E5FB07.6030400@oracle.com> <54E5FE88.4000705@gmail.com>
	<54E62ADC.1070501@oracle.com> <54E72D07.2020707@gmail.com>
	<54E73372.3050603@oracle.com> <54E74808.1010006@oracle.com>
	<54E74A02.5010401@oracle.com>
Message-ID: <1B4F3C2E-597F-41F8-9342-8DA70067750D@oracle.com>

That's fine, as long as we have a plan to make progress on the requireNonNull profile pollution issue.  ? John

P.S.  Yes, I think it's a real issue, despite hopeful noises elsewhere on this thread.

On Feb 20, 2015, at 6:51 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
>> Vladimir,
>> 
>> Can you take a look if java.lang.invoke.* changes look good for you?
>>   http://cr.openjdk.java.net/~shade/8073479/webrev.00/
> Looks good.
> 
> Best regards,
> Vladimir Ivanov



From john.r.rose at oracle.com  Sun Feb 22 00:58:02 2015
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 21 Feb 2015 16:58:02 -0800
Subject: RFR (S) 8073479: Replace obj.getClass hacks with
	Objects.requireNonNull
In-Reply-To: <CAHjP37GdqvSNT8u-oevHda7d76WEU1gOVwr6Rg+hOw0G9Am6zA@mail.gmail.com>
References: <54E5F88F.6030502@oracle.com> <54E5FA36.7030206@gmail.com>
	<54E5FB07.6030400@oracle.com> <54E5FE88.4000705@gmail.com>
	<54E62ADC.1070501@oracle.com> <54E72D07.2020707@gmail.com>
	<54E733F1.7080705@oracle.com>
	<CAHjP37GdqvSNT8u-oevHda7d76WEU1gOVwr6Rg+hOw0G9Am6zA@mail.gmail.com>
Message-ID: <D08DF39A-BB1F-4534-B2E7-0517934F8690@oracle.com>

All of the proposed tweaks to null checks fall down for somebody, some time.

The reason Object.getClass was being used in that twisty way is to get early placement of the null check.  Receiver null checks are performed at the call site, instead of inside the shared callee method.  So the trick of getClass is that you get to use the per-call-site profiling (of the receiver null check).

There are several possible ways to "fix" Objects.requireNonNull so that it resists profile pollution.

1. Special pleading:  Assume if the internal profile for O.rNN says "nulls have appeared here", that's uniquely ignorable.  A dirty hack, perhaps justifiable.  This could be done a couple of ways:

1.1 Compiler intrinsic:  Make O.rNN into a compiler intrinsic.  Then we have our way with it.

1.2 Profile injection:  Modify the JDK code of O.rNN to declare that the profile should be special-cased.  It would be something like a "NOTREACHED" pragma.  We used this technique in JDK-8063137.  A simpler form could apply here also.  This technique is better, since it leaves a clear "footprint" in the Java code that something is happening.

2. Adopt ignorance:  Keep the implicit null check optimization (using OS traps, as Remi described).  But, stop using nullness profiles to disable this optimization, for some general class of methods which includes O.rNN.  The problem with this there are 0.001% places where null check exceptions are on warm paths, and those customers will get trap storms.

3. Stop optimizing:  Ditch the implicit null check optimization; use explicitly coded null checks.  This is a straw man, since the code density and path length would degrade for no particular benefit.  (Some null checks are elidable based on local type inference, but a stubborn percentage are not.  PrintOptoStatistics tracks these numbers.)

4. Stop optimizing when the profile is polluted, which is the status quo.  Aleksey has some evidence we lose a mere 1/3 of a machine cycle on some machines, with a polluted O.rNN.  I assume this requires good branch prediction and prefetch.  The HotSpot project includes optimizations to assist machines with poor branch prediction or prefetch, for various reasons I won't go into.  The implicit null checks are such optimizations.  If O.rNN is going to be a full replacement for explicit null checks, we need to make sure it can't suddenly change its performance characteristics, because one client has fed it nulls.

5. Refine profiling:  Somehow gather profile information (at least nullness) on the operand to O.rNN, before it leaves user code and arrives in the shared (profile-pollutable) code of O.rNN.  There are several ways to do this, including:

5.1 Perform profiling in Tier One code, including inlined copies of O.rNN and any other trivial-enough function.  Use the context-specific profiles in Tier Two.  We have not developed this very far.

5.2 Perform argument profiling.  Set TypeProfileLevel=2 by default, or use some other logic that enhances argument profiling of calls to O.rNN.  This probably also needs more work.

I think 1.2 and 5.2 are worth working on.

? John

On Feb 20, 2015, at 6:20 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> I really hope this doesn't require intrinsifying requireNonNull since, as
> mentioned before, this is a general issue.  I'm almost tempted to say that
> JIT should always treat a null check followed by an explicit NPE as being
> an uncommon path, despite what profile may say.
> 
> sent from my phone
> On Feb 20, 2015 8:18 AM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
> wrote:
> 
>> Hi Peter,
>> 
>> Thanks for additional testing!
>> 
>> On 02/20/2015 03:48 PM, Peter Levart wrote:
>>> So we hope for Objects.requireNonNull to be inlined most of the times.
>> 
>> Yes, I think so, otherwise it is a platform bug :) And, as I said in
>> reply to Vitaly, the ultimate answer would be to intrinsify
>> Objects.requireNonNull to unconditionally bias it towards the non-null
>> case and implicit NP checks.
>> 
>> The test is actually specifically crafted to amplify the costs of the
>> pollution. The side effect of that method is excessive method calls.
>> It's not a surprise CPUs can execute the dense code oblivious of minor
>> code differences. (Speculation: CPUs need to re-adjust their pipelines
>> after the real call, so non-inlined version would pay some extra)
>> 
>> Thanks,
>> -Aleksey
>> 
>> 
>> 



From kumar.x.srinivasan at oracle.com  Sun Feb 22 01:38:59 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Sat, 21 Feb 2015 17:38:59 -0800
Subject: RFR(S): JDK-8073584 Native compilation warning in unpack code
In-Reply-To: <54E77CA2.3090304@oracle.com>
References: <54E77CA2.3090304@oracle.com>
Message-ID: <54E93333.4050300@oracle.com>

Hi Dmitry,

adding John on this.

unpack.cpp
What is wrong with the  unary operator ? Does this emit a compiler warning ?

-  sprintf(buf, ((uint)e.tag < CONSTANT_Limit)? TAG_NAME[e.tag]: "%d", e.tag);
+  if ((uint)e.tag < CONSTANT_Limit) {
+    sprintf(buf, "%s", TAG_NAME[e.tag]);
+  }
+  else {
+    sprintf(buf, "%d", e.tag);
+  }

If you are eliminating the unary operator then, the formatting should be

if (.....)
    ......
else
    ......
or
if (.....) {
  ....
else {  <--- note, please don't introduce new formatting/conventions.
    ....
}

main.cpp:

+      (void) (fread(&filecrc, sizeof(filecrc), 1, u.infileptr) + 1);

UGH. What about other compilers are they ok with this ? This may very well
get suppressed for gcc, but might emit warnings on MSVC or SunStudio.

I take it you have run all the open and internal regression tests.

Thanks

Kumar


> 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.
>
>
> -Dmitry
>
>



From claes.redestad at oracle.com  Sun Feb 22 02:11:48 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sun, 22 Feb 2015 03:11:48 +0100
Subject: RFR(S): 8073497: Lazy conversion of ZipEntry time
In-Reply-To: <54E8D34C.7000805@oracle.com>
References: <54E8976B.8050104@oracle.com> <54E8D34C.7000805@oracle.com>
Message-ID: <54E93AE4.1030301@oracle.com>

Hi Sherman,

On 2015-02-21 19:49, Xueming Shen wrote:
> Hi Claes,
>
> This change basically undo the "fix" for 4759491 [1], for better 
> performance ...
>

my intent was never to break current behavior, but that mistake can be 
rectified
without missing out on the startup benefit of laziness:

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

The time/mtime getters now use the mtime field if it exists, while the 
setters will
update both fields. Since getLastModified already fell back to 
converting the
time field rather than null if mtime wasn't set, setting mtime to a 
FileTime when
calling setTime seems consistent and a cheap way to preserve the time 
precision.

I guess a range check to skip the FileTime creation in setTime if the 
time is within
the DOS time bounds would be a valid optimization, since that will typically
always be the case.

> If we go with this change, I think we should also update the field 
> comment back to the
> original one to clearly indicates the "time" is "in DOS time".
>
> -    long time = -1;     // modification time (in DOS time)
> +    long mtime = -1;    // last modification time
>

Done.

>
> The set/getLastModifiedTime() pair also need update to set/get the 
> "time" field
> correctly to/from the dos time.

Done.

Thanks!

/Claes

>
> -Sherman
>
> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/90df6756406f
>
> On 2/21/15 6:34 AM, Claes Redestad wrote:
>> Hi all,
>>
>> please review this patch to re-introduce laziness in the java-to-dos 
>> time
>> conversions for the ZipEntry.time field.
>>
>> Webrev: http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.0/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073497
>>
>> See bug for more details.
>>
>> This behavior was actually the case before 8-b94, when the time field
>> was removed in favor of a set of FileTime fields, but when it was later
>> re-introduced to address some compatibility issues the conversion was
>> implemented in an eager fashion. This inadvertently affects VM startup
>> ever so little, since for every entry read via a ZipFile or 
>> ZipInputStream
>> we'll do a relatively expensive call creating a Date and doing timezone
>> conversion.
>>
>> Some gains from loading fewer classes during VM startup, as well.
>>
>> Thanks!
>>
>> /Claes
>



From john.r.rose at oracle.com  Sun Feb 22 03:20:57 2015
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 21 Feb 2015 19:20:57 -0800
Subject: RFR(S): JDK-8073584 Native compilation warning in unpack code
In-Reply-To: <54E93333.4050300@oracle.com>
References: <54E77CA2.3090304@oracle.com> <54E93333.4050300@oracle.com>
Message-ID: <C0355DB0-A505-4D32-A565-93B27DD37C9E@oracle.com>

On Feb 21, 2015, at 5:38 PM, Kumar Srinivasan <kumar.x.srinivasan at oracle.com> wrote:
> 
> Hi Dmitry,
> 
> adding John on this.
> 
> unpack.cpp
> What is wrong with the  unary operator ? Does this emit a compiler warning ?

(It's the ternary operator right?)  The problem is that the format string (oh, the cleverness!!) is non-constant.

> -  sprintf(buf, ((uint)e.tag < CONSTANT_Limit)? TAG_NAME[e.tag]: "%d", e.tag);
> +  if ((uint)e.tag < CONSTANT_Limit) {
> +    sprintf(buf, "%s", TAG_NAME[e.tag]);
> +  }
> +  else {
> +    sprintf(buf, "%d", e.tag);
> +  }
> 
> If you are eliminating the unary operator then, the formatting should be
> 
> if (.....)
>   ......
> else
>   ......
> or
> if (.....) {
> ....
> else {  <--- note, please don't introduce new formatting/conventions.

I agree on that.  Let's be whitespace chameleons.

>   ....
> }
> 
> main.cpp:
> 
> +      (void) (fread(&filecrc, sizeof(filecrc), 1, u.infileptr) + 1);
> 
> UGH. What about other compilers are they ok with this ? This may very well
> get suppressed for gcc, but might emit warnings on MSVC or SunStudio.

Surely it would be better to bind the result of fread to a throwaway variable, if there's a warning about unused return value.
    void* fread_result_ignored =
         fread(&filecrc, sizeof(filecrc), 1, u.infileptr);

? John

From dmitry.samersoff at oracle.com  Sun Feb 22 08:53:30 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Sun, 22 Feb 2015 11:53:30 +0300
Subject: RFR(S): JDK-8073584 Native compilation warning in unpack code
In-Reply-To: <C0355DB0-A505-4D32-A565-93B27DD37C9E@oracle.com>
References: <54E77CA2.3090304@oracle.com> <54E93333.4050300@oracle.com>
	<C0355DB0-A505-4D32-A565-93B27DD37C9E@oracle.com>
Message-ID: <54E9990A.1090808@oracle.com>

John,

Generally speaking, we should select warnings carefully - not just turn
all of it on.

For instance, I don't see any value of "format is not a string literal"
warning for JDK code.

Please, see also below.


On 2015-02-22 06:20, John Rose wrote:
> On Feb 21, 2015, at 5:38 PM, Kumar Srinivasan <kumar.x.srinivasan at oracle.com> wrote:
>>
>> Hi Dmitry,
>>
>> adding John on this.
>>
>> unpack.cpp
>> What is wrong with the  unary operator ? Does this emit a compiler warning ?
> 
> (It's the ternary operator right?)  


> The problem is that the format string (oh, the cleverness!!) is non-constant.

Yes. Actually sprintf here could be replaced with just a strcpy.

>> -  sprintf(buf, ((uint)e.tag < CONSTANT_Limit)? TAG_NAME[e.tag]: "%d", e.tag);
>> +  if ((uint)e.tag < CONSTANT_Limit) {
>> +    sprintf(buf, "%s", TAG_NAME[e.tag]);
>> +  }
>> +  else {
>> +    sprintf(buf, "%d", e.tag);
>> +  }
>>
>> If you are eliminating the unary operator then, the formatting should be
>>
>> if (.....)
>>   ......
>> else
>>   ......
>> or
>> if (.....) {
>> ....
>> else {  <--- note, please don't introduce new formatting/conventions.
> 
> I agree on that.  Let's be whitespace chameleons.

I'll change it.

> 
>>   ....
>> }
>>
>> main.cpp:
>>
>> +      (void) (fread(&filecrc, sizeof(filecrc), 1, u.infileptr) + 1);
>>
>> UGH. What about other compilers are they ok with this ? This may very well
>> get suppressed for gcc, but might emit warnings on MSVC or SunStudio.

It works for all JDK compilers.

> 
> Surely it would be better to bind the result of fread to a throwaway variable, if there's a warning about unused return value.
>     void* fread_result_ignored =
>          fread(&filecrc, sizeof(filecrc), 1, u.infileptr);


It causes "assigned but unused variable" warning.

-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  Sun Feb 22 09:50:56 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 22 Feb 2015 10:50:56 +0100
Subject: RFR(S): 8073497: Lazy conversion of ZipEntry time
In-Reply-To: <54E93AE4.1030301@oracle.com>
References: <54E8976B.8050104@oracle.com> <54E8D34C.7000805@oracle.com>
	<54E93AE4.1030301@oracle.com>
Message-ID: <54E9A680.1000403@gmail.com>

Hi Claes,

On 02/22/2015 03:11 AM, Claes Redestad wrote:
> Hi Sherman,
>
> On 2015-02-21 19:49, Xueming Shen wrote:
>> Hi Claes,
>>
>> This change basically undo the "fix" for 4759491 [1], for better 
>> performance ...
>>
>
> my intent was never to break current behavior, but that mistake can be 
> rectified
> without missing out on the startup benefit of laziness:
>
> http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.1/

In getLastModifiedTime():


  207     public FileTime getLastModifiedTime() {
  208         if (mtime != null)
  209             return mtime;
  210         if (time == -1)
  211             return null;
  212         return FileTime.from(dosToJavaTime(time), 
TimeUnit.MILLISECONDS);
  213     }


...you could also save the result of expression in line 212 to 'mtime' 
so repeated calls would return cached instance of FileTime instead of 
constructing new instance each time.

I would also rename 'time' field to 'dosTime' to aid in code readability.


Regards, Peter

>
> The time/mtime getters now use the mtime field if it exists, while the 
> setters will
> update both fields. Since getLastModified already fell back to 
> converting the
> time field rather than null if mtime wasn't set, setting mtime to a 
> FileTime when
> calling setTime seems consistent and a cheap way to preserve the time 
> precision.
>
> I guess a range check to skip the FileTime creation in setTime if the 
> time is within
> the DOS time bounds would be a valid optimization, since that will 
> typically
> always be the case.
>
>> If we go with this change, I think we should also update the field 
>> comment back to the
>> original one to clearly indicates the "time" is "in DOS time".
>>
>> -    long time = -1;     // modification time (in DOS time)
>> +    long mtime = -1;    // last modification time
>>
>
> Done.
>
>>
>> The set/getLastModifiedTime() pair also need update to set/get the 
>> "time" field
>> correctly to/from the dos time.
>
> Done.
>
> Thanks!
>
> /Claes
>
>>
>> -Sherman
>>
>> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/90df6756406f
>>
>> On 2/21/15 6:34 AM, Claes Redestad wrote:
>>> Hi all,
>>>
>>> please review this patch to re-introduce laziness in the java-to-dos 
>>> time
>>> conversions for the ZipEntry.time field.
>>>
>>> Webrev: http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.0/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073497
>>>
>>> See bug for more details.
>>>
>>> This behavior was actually the case before 8-b94, when the time field
>>> was removed in favor of a set of FileTime fields, but when it was later
>>> re-introduced to address some compatibility issues the conversion was
>>> implemented in an eager fashion. This inadvertently affects VM startup
>>> ever so little, since for every entry read via a ZipFile or 
>>> ZipInputStream
>>> we'll do a relatively expensive call creating a Date and doing timezone
>>> conversion.
>>>
>>> Some gains from loading fewer classes during VM startup, as well.
>>>
>>> Thanks!
>>>
>>> /Claes
>>
>



From peter.levart at gmail.com  Sun Feb 22 20:21:21 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 22 Feb 2015 21:21:21 +0100
Subject: java.time.ZoneId.systemDefalut() overhead
Message-ID: <54EA3A41.9000309@gmail.com>

Hi,

I noticed internal JDK class java.util.zip.ZipUtils uses deprecated 
java.util.Date API for implementing two methods for converting DOS to 
Java time and back. I thought I'd try translating them to use new 
java.time API. Translation was straightforward, but I noticed that new 
implementations are not on par with speed to old java.util.Date 
versions. Here's a JMH benchmark implementing those two conversion 
methods with java.util.Date and java.time.ZonedDateTime APIs:

http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/ZipUtilsTest.java

The results show the following:

Benchmark                               Mode   Samples Score  Score 
error    Units
j.t.ZipUtilsTest.dosToJavaTime_Date     avgt         5 101.890       
17.570    ns/op
j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt         5 137.587       
13.533    ns/op
j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       67.114       
10.382    ns/op
j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt         5 143.739       
15.243    ns/op


Quick sampling with jvisualvm shows that a substantial time is spent 
repeatedly obtaining ZoneId.systemDefault() instance. I checked the 
implementation and came up with the following optimization:

http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.01/

TimeZone is a mutable object and has to be defensively cloned when 
TimeZone.getDefault() is invoked. So there's no point in caching a 
ZoneId instance inside TimeZone instance if we cache it on a clone that 
is thrown away each time ZoneId.systemDefault() is invoked. I use 
SharedSecrets to access the uncloned TimeZone.defaultTimeZone instance 
where caching of ZoneId pays of.

I think that it was never meant to change TimeZone's ID 
(TimeZone.setID()) after such instance was put into operation (for 
example installed as default time zone with TimeZone.setDefault()). Such 
use is unintended and buggy. So I also changed the implementation of 
TimeZone.setDefault() to save a defensive copy of TimeZone object as 
default time zone instead of a reference to it.

With this patch, the DOS/Java time conversion benchmark shows an 
improvement:

Benchmark                               Mode   Samples Score  Score 
error    Units
j.t.ZipUtilsTest.dosToJavaTime_Date     avgt 5       97.986       
18.379    ns/op
j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt 5       85.010       
10.863    ns/op
j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       71.073       
25.408    ns/op
j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt 5       95.298       
17.620    ns/op


Is this patch correct or did I miss something from the internals of 
java.time API that does not permit such caching?


Regards, Peter



From xueming.shen at oracle.com  Sun Feb 22 21:16:52 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Sun, 22 Feb 2015 13:16:52 -0800
Subject: RFR(S): 8073497: Lazy conversion of ZipEntry time
In-Reply-To: <54E93AE4.1030301@oracle.com>
References: <54E8976B.8050104@oracle.com> <54E8D34C.7000805@oracle.com>
	<54E93AE4.1030301@oracle.com>
Message-ID: <54EA4744.1090703@oracle.com>

On 2/21/15 6:11 PM, Claes Redestad wrote:
> Hi Sherman,
>
> On 2015-02-21 19:49, Xueming Shen wrote:
>> Hi Claes,
>>
>> This change basically undo the "fix" for 4759491 [1], for better 
>> performance ...
>>
>
> my intent was never to break current behavior, but that mistake can be 
> rectified
> without missing out on the startup benefit of laziness:
>
> http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.1/
>
> The time/mtime getters now use the mtime field if it exists, while the 
> setters will
> update both fields. Since getLastModified already fell back to 
> converting the
> time field rather than null if mtime wasn't set, setting mtime to a 
> FileTime when
> calling setTime seems consistent and a cheap way to preserve the time 
> precision.
>
> I guess a range check to skip the FileTime creation in setTime if the 
> time is within
> the DOS time bounds would be a valid optimization, since that will 
> typically
> always be the case.


It's a reasonable solution. I would assume we probably need that "range 
check" optimization
to avoid setting the "mtime" field in normal use scenario. ZOS now 
outputs the more accurate
"mtime" to the zip file using "extend timestamp" if it's not null (the 
entry gets bigger). The
assumption now is that we only output the extended timestamp if the time 
stamps set
via the setXYZTime() explicitly.

ZOS.java

...

  432         int elenEXTT = 0;               // info-zip extended timestamp
  433         int flagEXTT = 0;
  434         if (e.mtime != null) {
  435             elenEXTT += 4;
  436             flagEXTT |= EXTT_FLAG_LMT;
  437         }
  438         if (e.atime != null) {
  439             elenEXTT += 4;
  440             flagEXTT |= EXTT_FLAG_LAT;
  441         }
  442         if (e.ctime != null) {
  443             elenEXTT += 4;
  444             flagEXTT |= EXTT_FLAT_CT;
  445         }
  446         if (flagEXTT != 0)
  447             elen += (elenEXTT + 5);    // headid(2) + size(2) + flag(1) + data
  448         writeShort(elen);

...

-Sherman


>> If we go with this change, I think we should also update the field 
>> comment back to the
>> original one to clearly indicates the "time" is "in DOS time".
>>
>> -    long time = -1;     // modification time (in DOS time)
>> +    long mtime = -1;    // last modification time
>>
>
> Done.
>
>>
>> The set/getLastModifiedTime() pair also need update to set/get the 
>> "time" field
>> correctly to/from the dos time.
>
> Done.
>
> Thanks!
>
> /Claes
>
>>
>> -Sherman
>>
>> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/90df6756406f
>>
>> On 2/21/15 6:34 AM, Claes Redestad wrote:
>>> Hi all,
>>>
>>> please review this patch to re-introduce laziness in the java-to-dos 
>>> time
>>> conversions for the ZipEntry.time field.
>>>
>>> Webrev: http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.0/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073497
>>>
>>> See bug for more details.
>>>
>>> This behavior was actually the case before 8-b94, when the time field
>>> was removed in favor of a set of FileTime fields, but when it was later
>>> re-introduced to address some compatibility issues the conversion was
>>> implemented in an eager fashion. This inadvertently affects VM startup
>>> ever so little, since for every entry read via a ZipFile or 
>>> ZipInputStream
>>> we'll do a relatively expensive call creating a Date and doing timezone
>>> conversion.
>>>
>>> Some gains from loading fewer classes during VM startup, as well.
>>>
>>> Thanks!
>>>
>>> /Claes
>>
>



From claes.redestad at oracle.com  Sun Feb 22 21:21:43 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sun, 22 Feb 2015 22:21:43 +0100
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EA3A41.9000309@gmail.com>
References: <54EA3A41.9000309@gmail.com>
Message-ID: <54EA4867.30105@oracle.com>

Hi Peter,

On 2015-02-22 21:21, Peter Levart wrote:
> Hi,
>
> I noticed internal JDK class java.util.zip.ZipUtils uses deprecated 
> java.util.Date API for implementing two methods for converting DOS to 
> Java time and back. I thought I'd try translating them to use new 
> java.time API. Translation was straightforward, but I noticed that new 
> implementations are not on par with speed to old java.util.Date 
> versions. Here's a JMH benchmark implementing those two conversion 
> methods with java.util.Date and java.time.ZonedDateTime APIs:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/ZipUtilsTest.java 
>

https://bugs.openjdk.java.net/browse/JDK-8066644 was filed to fix the 
deprecation warnings of practically identical code in 
jdk/nio/zipfs/ZipUtils.java, maybe this could be fixed at the same time?

I did a similar experiment recently and think I saw better throughput 
going from LocalDateTime to the sufficient second precision via 
toEpochSecond:

-    @SuppressWarnings("deprecation")
      public static long dosToJavaTime(long dtime) {
-        Date d = new Date((int)(((dtime >> 25) & 0x7f) + 80),
-                          (int)(((dtime >> 21) & 0x0f) - 1),
-                          (int)((dtime >> 16) & 0x1f),
-                          (int)((dtime >> 11) & 0x1f),
-                          (int)((dtime >> 5) & 0x3f),
-                          (int)((dtime << 1) & 0x3e));
-        return d.getTime();
+        LocalDateTime time = LocalDateTime.of((int) (((dtime >> 25) & 
0x7f) + 1980),
+                (int) ((dtime >> 21) & 0x0f),
+                (int) ((dtime >> 16) & 0x1f),
+                (int) ((dtime >> 11) & 0x1f),
+                (int) ((dtime >> 5) & 0x3f),
+                (int) ((dtime << 1) & 0x3e));
+        return 
time.toEpochSecond(ZoneId.systemDefault().getRules().getOffset(time)) * 
1000L;
      }

This avoids a few allocations.

Similarly for the javaToDos case going from an Instant to LocalDateTime 
with a ZoneOffset seemed to win out:

+        Instant instant = Instant.ofEpochMilli(time);
+        LocalDateTime d = LocalDateTime.ofInstant(instant,
+ ZoneOffset.systemDefault().getRules().getOffset(instant));

>
> The results show the following:
>
> Benchmark                               Mode   Samples Score Score 
> error    Units
> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt         5 101.890       
> 17.570    ns/op
> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt         5 137.587       
> 13.533    ns/op
> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       67.114 10.382    
> ns/op
> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt         5 143.739       
> 15.243    ns/op
>
>
> Quick sampling with jvisualvm shows that a substantial time is spent 
> repeatedly obtaining ZoneId.systemDefault() instance. I checked the 
> implementation and came up with the following optimization:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.01/ 
>
>
> TimeZone is a mutable object and has to be defensively cloned when 
> TimeZone.getDefault() is invoked. So there's no point in caching a 
> ZoneId instance inside TimeZone instance if we cache it on a clone 
> that is thrown away each time ZoneId.systemDefault() is invoked. I use 
> SharedSecrets to access the uncloned TimeZone.defaultTimeZone instance 
> where caching of ZoneId pays of.
>
> I think that it was never meant to change TimeZone's ID 
> (TimeZone.setID()) after such instance was put into operation (for 
> example installed as default time zone with TimeZone.setDefault()). 
> Such use is unintended and buggy. So I also changed the implementation 
> of TimeZone.setDefault() to save a defensive copy of TimeZone object 
> as default time zone instead of a reference to it.
>
> With this patch, the DOS/Java time conversion benchmark shows an 
> improvement:
>
> Benchmark                               Mode   Samples Score Score 
> error    Units
> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt 5       97.986 18.379    
> ns/op
> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt 5       85.010 10.863    
> ns/op
> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       71.073 25.408    
> ns/op
> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt 5       95.298 17.620    
> ns/op
>
>
> Is this patch correct or did I miss something from the internals of 
> java.time API that does not permit such caching?
>

Seems OK to me - perhaps an alternative would be to add a public static 
ZoneId getDefaultZoneId() on TimeZone rather than adding backdoors to 
the getDefaultRef? The caching seems sound, and I guess we don't have to 
worry about making it volatile.

The defensive copy in TimeZone.setDefault() seems like maybe it should 
be a separate bug.

Thanks!

/Claes

>
> Regards, Peter
>



From david.holmes at oracle.com  Mon Feb 23 01:55:53 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 23 Feb 2015 11:55:53 +1000
Subject: RFR 8073354: TimSortStackSize2.java: requires
	64*2^20*sizeof(reference) continues heap space
In-Reply-To: <54E704F2.1010201@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>
Message-ID: <54EA88A9.2080204@oracle.com>

On 20/02/2015 7:57 PM, Lev Priima wrote:
> Functional is pretty same, but:
>   - make it run with a single argument '67108864' by moving @summary tag
> strait down to line after the @run tag
>   - '-Xmx385' ->'-Xms385' in run command. MaxHeapSize will adjust a
> accordingly.
>   - spaces and code style.
>
> Of course this issue may be closed as dup of JDK-8073354 and test will
> pass after applying JDK-8073354. But I just want to use this RFE ID to
> make test run with a single argument ( as you noticed previously ).

So this is all just cleanup - which is fine in itself but seems to have 
no bearing on the issue reported/described in the bug report. If you 
want to use this bug ID then I think you need to change the bug report 
substantially else it will just be confusing.

Thanks,
David


> Lev
>
> On 02/20/2015 05:26 AM, David Holmes wrote:
>> On 19/02/2015 11:23 PM, Lev Priima wrote:
>>> After Jespers comments I removed catch of OOME and added minimum heap
>>> size required for test(-Xms385) to overcome default ergonomics for
>>> client.
>>> Please review: http://cr.openjdk.java.net/~lpriima/8073354/webrev.01/
>>
>> Didn't see this before sending my previous reply.
>>
>> I'm confused now. What functional change is now being made here ??
>>
>> Thanks,
>> David
>>
>>> Lev
>>>
>>> On 02/19/2015 03:00 PM, Lev Priima wrote:
>>>> There is also a problem, if the memory on host is highly fragmented,
>>>> then we can't allocate continuous amount of heap for creating such big
>>>> array. I've added catch for OOME and treat this case as skip-pass to
>>>> make test more robust. Also I've removed explicit -Xmx385 from @run
>>>> tag and made it start with a single argument.
>>>>
>>>> Please review and push:
>>>> http://cr.openjdk.java.net/~lpriima/8073354/webrev.00/
>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8073354
>>>>
>>>> Lev
>>>>
>>>> On 02/17/2015 09:55 AM, David Holmes wrote:
>>>>> On 17/02/2015 3:43 PM, Lev Priima wrote:
>>>>>> Thanks David!
>>>>>> Is this expected behavior of this annotation ?
>>>>>
>>>>> Yes that is the way jtreg defines tags:
>>>>>
>>>>> http://openjdk.java.net/jtreg/tag-spec.html
>>>>>
>>>>> "The argument tokens of a tag extend from the first token after the
>>>>> tag token to the end of the comment, the end of the file, or the next
>>>>> tag token, whichever comes first."
>>>>>
>>>>> So everything between @run and @summary are taken to be the @run
>>>>> commands. And there's no @comment tag unfortunately.
>>>>>
>>>>> David
>>>>>
>>>>>> Lev
>>>>>>
>>>>>> On 02/17/2015 03:20 AM, David Holmes wrote:
>>>>>>> On 16/02/2015 9:20 PM, David Holmes wrote:
>>>>>>>> On 16/02/2015 6:59 PM, Lev Priima wrote:
>>>>>>>>> Thanks, David,
>>>>>>>>> Could you please push it ?
>>>>>>>>
>>>>>>>> I will if Roger doesn't get to it first. It'll be 11 hours before
>>>>>>>> I can
>>>>>>>> push it.
>>>>>>>
>>>>>>> This has been pushed but note there is a minor issue with the test.
>>>>>>> The jtreg tag specification doesn't terminate tags on newlines, they
>>>>>>> continue until the next tag is encountered or the end of the
>>>>>>> comment.
>>>>>>> Consequently this:
>>>>>>>
>>>>>>>  * @run main/othervm -Xmx385m TimSortStackSize2 67108864
>>>>>>>  * not for regular execution on all platforms:
>>>>>>>  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>>>  * run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>>>>>
>>>>>>> is processed as:
>>>>>>>
>>>>>>> @run main/othervm -Xmx385m TimSortStackSize2 67108864 not for
>>>>>>> regular
>>>>>>> execution on all platforms: run main/othervm -Xmx8g
>>>>>>> TimSortStackSize2
>>>>>>> 1073741824 run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>>>>>
>>>>>>> and so TimSortStackSize2 is invoked with 18 arguments.
>>>>>>>
>>>>>>> David
>>>>>>> -----
>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Lev
>>>>>>>>>
>>>>>>>>> On 02/16/2015 08:55 AM, David Holmes wrote:
>>>>>>>>>> On 14/02/2015 12:03 AM, Lev Priima wrote:
>>>>>>>>>>> Please review and push:
>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073124
>>>>>>>>>>
>>>>>>>>>> I hadn't realized 8072909 had been pushed without final reviewer
>>>>>>>>>> comments being addressed. :(
>>>>>>>>>>
>>>>>>>>>> These changes seem okay. I hope they get promoted at the same
>>>>>>>>>> time as
>>>>>>>>>> the original changeset so we don't get test failures.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>> Lev
>>>>>>>>>>>
>>>>>>>>>>> On 02/13/2015 05:20 AM, David Holmes wrote:
>>>>>>>>>>>> Hi Lev,
>>>>>>>>>>>>
>>>>>>>>>>>> On 13/02/2015 2:56 AM, Lev Priima wrote:
>>>>>>>>>>>>> Christos,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Test may fail on shorter arrays(page 8 of paper). For
>>>>>>>>>>>>> instance, on
>>>>>>>>>>>>> worst
>>>>>>>>>>>>> case, generated by test, it starts to fail on length 67108864.
>>>>>>>>>>>>> After increasing stack size of runs to merge, Arrays.sort(T[])
>>>>>>>>>>>>> works
>>>>>>>>>>>>> also on maximum possible array for HotSpot JVM.
>>>>>>>>>>>>
>>>>>>>>>>>> I'd also like to see this documented somewhere in the code.
>>>>>>>>>>>> Presently
>>>>>>>>>>>> there is a reference to listsort.txt but then you have to go
>>>>>>>>>>>> and
>>>>>>>>>>>> find
>>>>>>>>>>>> it on the web. :( At a minimum could we please add:
>>>>>>>>>>>>
>>>>>>>>>>>>  175          * computation below must be changed if
>>>>>>>>>>>> MIN_MERGE is
>>>>>>>>>>>> decreased.  See
>>>>>>>>>>>>  176          * the MIN_MERGE declaration above for more
>>>>>>>>>>>> information.
>>>>>>>>>>>> +             * The maximum value of 49 allows for an array
>>>>>>>>>>>> up to
>>>>>>>>>>>> length
>>>>>>>>>>>> +             * Integer.MAX_VALUE-4.
>>>>>>>>>>>>
>>>>>>>>>>>>> Roger, David,
>>>>>>>>>>>>> I've updated the test (
>>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ) to make it more suitable for regular execution:
>>>>>>>>>>>>>
>>>>>>>>>>>>>    27  * @run main/othervm TimSortStackSize2 67108864
>>>>>>>>>>>>
>>>>>>>>>>>> This will still fail on small memory devices:
>>>>>>>>>>>>
>>>>>>>>>>>> :~> java TimSortStackSize2 67108864
>>>>>>>>>>>> Exception in thread "main" java.lang.OutOfMemoryError: Java
>>>>>>>>>>>> heap
>>>>>>>>>>>> space
>>>>>>>>>>>>
>>>>>>>>>>>> as the default heap ergonomics may not be large enough. I
>>>>>>>>>>>> had to
>>>>>>>>>>>> add a
>>>>>>>>>>>> minimum heap of -Xmx385M to get it to run.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>>>    28  * not for regular execution on all platforms:
>>>>>>>>>>>>>    29  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>>>>>>>>>    30  * run main/othervm -Xmx32g TimSortStackSize2 2147483644
>>>>>>>>>>>>>
>>>>>>>>>>>>> Could you please push this:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>>>>>>>>>>>>> ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Lev
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>>>>>>>>>>>>> On Feb 12, 9:57pm,david.holmes at oracle.com  (David Holmes)
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> -- Subject: Re: 8072909: TimSort fails with
>>>>>>>>>>>>>> ArrayIndexOutOfBoundsException on
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> | Ok - thanks Lev!
>>>>>>>>>>>>>> |
>>>>>>>>>>>>>> | David
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For posterity can someone document this, and also the
>>>>>>>>>>>>>> value for
>>>>>>>>>>>>>> which
>>>>>>>>>>>>>> Integer.MAX_VALUE-4 fails?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> christos
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>
>>>
>


From david.holmes at oracle.com  Mon Feb 23 02:07:49 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 23 Feb 2015 12:07:49 +1000
Subject: RFR(S): JDK-8073584 Native compilation warning in unpack code
In-Reply-To: <54E77CA2.3090304@oracle.com>
References: <54E77CA2.3090304@oracle.com>
Message-ID: <54EA8B75.5040406@oracle.com>

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 daniel.fuchs at oracle.com  Mon Feb 23 09:50:28 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 23 Feb 2015 10:50:28 +0100
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EA3A41.9000309@gmail.com>
References: <54EA3A41.9000309@gmail.com>
Message-ID: <54EAF7E4.40706@oracle.com>

Hi Peter,

On 22/02/15 21:21, Peter Levart wrote:
> Hi,
>
> I noticed internal JDK class java.util.zip.ZipUtils uses deprecated
> java.util.Date API for implementing two methods for converting DOS to
> Java time and back. I thought I'd try translating them to use new
> java.time API. Translation was straightforward, but I noticed that new
> implementations are not on par with speed to old java.util.Date
> versions. Here's a JMH benchmark implementing those two conversion
> methods with java.util.Date and java.time.ZonedDateTime APIs:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/ZipUtilsTest.java
>
>
> The results show the following:
>
> Benchmark                               Mode   Samples Score  Score
> error    Units
> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt         5 101.890 17.570
> ns/op
> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt         5 137.587 13.533
> ns/op
> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       67.114 10.382    ns/op
> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt         5 143.739 15.243
> ns/op
>
>
> Quick sampling with jvisualvm shows that a substantial time is spent
> repeatedly obtaining ZoneId.systemDefault() instance. I checked the
> implementation and came up with the following optimization:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.01/

It will be good to hear what Stephen will have to say about this.
Also I see that Claes is suggesting using LocalDateTime.

If there's no undesirable side effect then caching zoneId
inside TimeZone looks reasonable to me - however I'm not an expert
of the field, and I got to learn that time/date can be more complex
than what I first thought ;-)

The use of SharedSecrets seems rather ugly though - and its only
purpose seems to avoid a clone(). I have to wonder whether there
is a significant performance gain in this. I mean - if you simply
cached zoneId in TimeZone and called TimeZone.getDefault() directly,
how worse would that be?

Finally, I also wonder whether a better idea would be to add
a variant of dosToJavaTime/javaToDosTime that would take an
additional zoneId as parameter.

You probably don't want to support changing the time zone in
the middle of a Zip. Do you?

best regards,

-- daniel

>
>
> TimeZone is a mutable object and has to be defensively cloned when
> TimeZone.getDefault() is invoked. So there's no point in caching a
> ZoneId instance inside TimeZone instance if we cache it on a clone that
> is thrown away each time ZoneId.systemDefault() is invoked. I use
> SharedSecrets to access the uncloned TimeZone.defaultTimeZone instance
> where caching of ZoneId pays of.
>
> I think that it was never meant to change TimeZone's ID
> (TimeZone.setID()) after such instance was put into operation (for
> example installed as default time zone with TimeZone.setDefault()). Such
> use is unintended and buggy. So I also changed the implementation of
> TimeZone.setDefault() to save a defensive copy of TimeZone object as
> default time zone instead of a reference to it.
>
> With this patch, the DOS/Java time conversion benchmark shows an
> improvement:
>
> Benchmark                               Mode   Samples Score  Score
> error    Units
> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt 5       97.986 18.379    ns/op
> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt 5       85.010 10.863    ns/op
> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       71.073 25.408    ns/op
> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt 5       95.298 17.620    ns/op
>
>
> Is this patch correct or did I miss something from the internals of
> java.time API that does not permit such caching?
>
>
> Regards, Peter
>



From peter.levart at gmail.com  Mon Feb 23 10:29:32 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 23 Feb 2015 11:29:32 +0100
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EAF7E4.40706@oracle.com>
References: <54EA3A41.9000309@gmail.com> <54EAF7E4.40706@oracle.com>
Message-ID: <54EB010C.6030903@gmail.com>

Hi Daniel,

On 02/23/2015 10:50 AM, Daniel Fuchs wrote:
> Hi Peter,
>
> On 22/02/15 21:21, Peter Levart wrote:
>> Hi,
>>
>> I noticed internal JDK class java.util.zip.ZipUtils uses deprecated
>> java.util.Date API for implementing two methods for converting DOS to
>> Java time and back. I thought I'd try translating them to use new
>> java.time API. Translation was straightforward, but I noticed that new
>> implementations are not on par with speed to old java.util.Date
>> versions. Here's a JMH benchmark implementing those two conversion
>> methods with java.util.Date and java.time.ZonedDateTime APIs:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/ZipUtilsTest.java 
>>
>>
>>
>> The results show the following:
>>
>> Benchmark                               Mode   Samples Score Score
>> error    Units
>> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt         5 101.890 17.570
>> ns/op
>> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt         5 137.587 13.533
>> ns/op
>> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       67.114 10.382    
>> ns/op
>> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt         5 143.739 15.243
>> ns/op
>>
>>
>> Quick sampling with jvisualvm shows that a substantial time is spent
>> repeatedly obtaining ZoneId.systemDefault() instance. I checked the
>> implementation and came up with the following optimization:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.01/ 
>>
>
> It will be good to hear what Stephen will have to say about this.
> Also I see that Claes is suggesting using LocalDateTime.

I'll compare LocalDateTime based approach too, but the conversion logic 
needs to take into account ZoneId.systemDefault(). Most zip utilities 
interpret DOS time in zip entries (when it is not specified in extra 
field data) in the local time zone and so does ZipEntry. This is 
unfortunate, as interpreting it in fixed (GMT) time zone would be more 
appropriate and less troublesome. So speeding-up ZoneId.systemDefault() 
is needed anyway.

>
> If there's no undesirable side effect then caching zoneId
> inside TimeZone looks reasonable to me - however I'm not an expert
> of the field, and I got to learn that time/date can be more complex
> than what I first thought ;-)

One thing I noticed is that there are two kinds of ZoneRulesProvider(s): 
those that are static and allow their rules to be cached and the dynamic 
ones, that can provide dynamic view on rules and therefore don't allow 
caching of rules. But this aspect is encapsulated in ZoneRegion class 
(an implementation of ZoneId). So I think an instance to ZoneRegion (or 
any ZoneId) can be cached for indefinite time as long as it's id is the 
one that we are looking for.

>
> The use of SharedSecrets seems rather ugly though - and its only
> purpose seems to avoid a clone(). I have to wonder whether there
> is a significant performance gain in this. I mean - if you simply
> cached zoneId in TimeZone and called TimeZone.getDefault() directly,
> how worse would that be?

Caching of ZoneId in the defensive clone of defualt TimeZone object 
would not have a desired effect as the clone is thrown away in each call 
to ZoneId.systemDefault(). We must get hold of the TimeZone instance 
that is cached. Another way to do that would be to take the route of 
reflection objects (Field, Method, Constructor) and put a pointer to 
'root' TimeZone instance in the clones, so it would be accessible 
through the clone.

>
> Finally, I also wonder whether a better idea would be to add
> a variant of dosToJavaTime/javaToDosTime that would take an
> additional zoneId as parameter.

For ZipEntry it would not make much sense as there's only one time value 
that has to be converted only once in each ZipEntry.

>
> You probably don't want to support changing the time zone in
> the middle of a Zip. Do you?

Ok, in that case the ZoneId would have to be attached to ZipFile and 
passed to each ZipEntry. I agree that per ZipFile default zone atomicity 
is a desired property. Speeding up ZoneId.systemDefault() retrieval is 
also generally desirable, don't you think?


Regards, Peter

>
> best regards,
>
> -- daniel
>
>>
>>
>> TimeZone is a mutable object and has to be defensively cloned when
>> TimeZone.getDefault() is invoked. So there's no point in caching a
>> ZoneId instance inside TimeZone instance if we cache it on a clone that
>> is thrown away each time ZoneId.systemDefault() is invoked. I use
>> SharedSecrets to access the uncloned TimeZone.defaultTimeZone instance
>> where caching of ZoneId pays of.
>>
>> I think that it was never meant to change TimeZone's ID
>> (TimeZone.setID()) after such instance was put into operation (for
>> example installed as default time zone with TimeZone.setDefault()). Such
>> use is unintended and buggy. So I also changed the implementation of
>> TimeZone.setDefault() to save a defensive copy of TimeZone object as
>> default time zone instead of a reference to it.
>>
>> With this patch, the DOS/Java time conversion benchmark shows an
>> improvement:
>>
>> Benchmark                               Mode   Samples Score Score
>> error    Units
>> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt 5       97.986 18.379    
>> ns/op
>> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt 5       85.010 10.863    
>> ns/op
>> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       71.073 25.408    
>> ns/op
>> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt 5       95.298 17.620    
>> ns/op
>>
>>
>> Is this patch correct or did I miss something from the internals of
>> java.time API that does not permit such caching?
>>
>>
>> Regards, Peter
>>
>



From chris.hegarty at oracle.com  Mon Feb 23 11:01:57 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 23 Feb 2015 11:01:57 +0000
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <54E74E29.2060806@gmail.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com> <54E71BC3.30403@oracle.com>
	<54E74E29.2060806@gmail.com>
Message-ID: <54EB08A5.4000905@oracle.com>

Peter, David, Vitaly,

Can you please take a look at the latest version of this change:

   http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/

On 20/02/15 15:09, Peter Levart wrote:
>...
> This looks good now. But I wonder if issuing fences after nested calls
> to readObject() makes much sense. If cycles are present in a subgraph
> deserialized by nested call to readObject(), a field pointing back to an
> object not part of the subgraph stream will point to the object that
> will not be fully initialized yet, so nested calls to readObject()
> should not be expected to return a reference to a fully constructed
> subgraph anyway. Only top-level call is guaranteed to return a fully
> constructed graph.

Right. I was never convinced of this myself either. Removed. Unnecessary 
complication.

> If you optimize this and only issue one fence for top-level call to
> readObject(), tracking of 'requiresFence' (I would call it
> requiresFreeze to be in line with JMM terminology - the fence is just a

'requiresFreeze' is better. Updated

> way to achieve freeze) can also be micro-optimized. You currently do it
> like this:
>
> 1900             requiresFence |= slotDesc.hasFinalField();
>
> which is a shortcut for:
>
> requiresFence = requiresFence | slotDesc.hasFinalField();
>
> ...which means that the field is overwritten multiple times
> unnecessarily and slotDesc.hasFinalField() is called every time. You can
> write the same logic as:
>
> if (!requiresFence && slotDesc.hasFinalField()) {
>      requiresFence = true;
> }

... and it is more readable. Updated.

> There will be at most one write to the field and potentially less calls
> to slotDesc.hasFinalField().

-Chris.


From daniel.fuchs at oracle.com  Mon Feb 23 11:24:48 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 23 Feb 2015 12:24:48 +0100
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EB010C.6030903@gmail.com>
References: <54EA3A41.9000309@gmail.com> <54EAF7E4.40706@oracle.com>
	<54EB010C.6030903@gmail.com>
Message-ID: <54EB0E00.1050108@oracle.com>

Hi Peter,

On 23/02/15 11:29, Peter Levart wrote:
> Caching of ZoneId in the defensive clone of defualt TimeZone object
> would not have a desired effect as the clone is thrown away in each call
> to ZoneId.systemDefault(). We must get hold of the TimeZone instance
> that is cached. Another way to do that would be to take the route of
> reflection objects (Field, Method, Constructor) and put a pointer to
> 'root' TimeZone instance in the clones, so it would be accessible
> through the clone.

Ah I see. You would have to initialize the zoneId field in the
root object, i.e. in setDefaultZone - and possibly in
TimeZone.setDefault as well. So that might not be as good an
idea after all...

>> Finally, I also wonder whether a better idea would be to add
>> a variant of dosToJavaTime/javaToDosTime that would take an
>> additional zoneId as parameter.
>
> For ZipEntry it would not make much sense as there's only one time value
> that has to be converted only once in each ZipEntry.

If I'm not mistaken dosToJavaTime is only called from ZipFile
and ZipInputStream, and javaToDosTime from ZipOutputStream.

>> You probably don't want to support changing the time zone in
>> the middle of a Zip. Do you?
>
> Ok, in that case the ZoneId would have to be attached to ZipFile and
> passed to each ZipEntry. I agree that per ZipFile default zone atomicity
> is a desired property. Speeding up ZoneId.systemDefault() retrieval is
> also generally desirable, don't you think?

Agreed. I'm just not a big fan of using SharedSecrets if that can
be helped. I just wanted to see if there was other alternatives to
explore.

best regards,

-- daniel

>



From peter.levart at gmail.com  Mon Feb 23 11:45:09 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 23 Feb 2015 12:45:09 +0100
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EB0E00.1050108@oracle.com>
References: <54EA3A41.9000309@gmail.com> <54EAF7E4.40706@oracle.com>
	<54EB010C.6030903@gmail.com> <54EB0E00.1050108@oracle.com>
Message-ID: <54EB12C5.8020503@gmail.com>

On 02/23/2015 12:24 PM, Daniel Fuchs wrote:
> Hi Peter,
>
> On 23/02/15 11:29, Peter Levart wrote:
>> Caching of ZoneId in the defensive clone of defualt TimeZone object
>> would not have a desired effect as the clone is thrown away in each call
>> to ZoneId.systemDefault(). We must get hold of the TimeZone instance
>> that is cached. Another way to do that would be to take the route of
>> reflection objects (Field, Method, Constructor) and put a pointer to
>> 'root' TimeZone instance in the clones, so it would be accessible
>> through the clone.
>
> Ah I see. You would have to initialize the zoneId field in the
> root object, i.e. in setDefaultZone - and possibly in
> TimeZone.setDefault as well. So that might not be as good an
> idea after all...

I think the logic stays more or less the same, just one dereference more 
('root' if not null) is needed to get to the TimeZone instance that 
caches ZoneId. I would still initialize it lazily.

>
>>> Finally, I also wonder whether a better idea would be to add
>>> a variant of dosToJavaTime/javaToDosTime that would take an
>>> additional zoneId as parameter.
>>
>> For ZipEntry it would not make much sense as there's only one time value
>> that has to be converted only once in each ZipEntry.
>
> If I'm not mistaken dosToJavaTime is only called from ZipFile
> and ZipInputStream, and javaToDosTime from ZipOutputStream.

It is as of now, but it will not be any more (see Claes' RFR(S): 
8073497: Lazy conversion of ZipEntry time) that is just being reviewed.

>
>>> You probably don't want to support changing the time zone in
>>> the middle of a Zip. Do you?
>>
>> Ok, in that case the ZoneId would have to be attached to ZipFile and
>> passed to each ZipEntry. I agree that per ZipFile default zone atomicity
>> is a desired property. Speeding up ZoneId.systemDefault() retrieval is
>> also generally desirable, don't you think?

In case we go with LocalDateTime (most probably), to support atomicity 
for the whole ZipFile/ZipInput(Output)Stream, we actually need to get 
hold of ZoneRules object - not ZoneId. With dynamic ZoneRulesProvider(s) 
the rules can still change dynamically underneath the same ZoneId 
instance...

>
> Agreed. I'm just not a big fan of using SharedSecrets if that can
> be helped. I just wanted to see if there was other alternatives to
> explore.

There is this 'root' pointer alternative. We still do a clone 
unnecessarily in this case, but the allocation will hopefully be 
optimized away as the methods are in-lined and analyzed for clone's escape.

Regards, Peter

>
> best regards,
>
> -- daniel
>
>>
>



From scolebourne at joda.org  Mon Feb 23 11:50:23 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 23 Feb 2015 11:50:23 +0000
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EA3A41.9000309@gmail.com>
References: <54EA3A41.9000309@gmail.com>
Message-ID: <CACzrW9AAzCce5D9k20GZz8XHnZ3QpRD5z_+Pv3HcquaNzK2u4Q@mail.gmail.com>

Having recently spent time on performance myself, I know that there
are a number of things in the java.time package that need some work.

Improving ZoneId.systemDefault() is definitely an improvement I
welcome. The change is along the lines of that I would have made,
involving a "secret" location to allow data to be exchanged (this code
needs to avoid the clone). The idea of adding a public method
TimeZone.getDefaultZoneId() is also one I'd be interested in if it
works.

On the patch, in TimeZone::toZoneId() I would use two methods:

public ZoneId toZoneId() {
 ZoneId zId = zoneId;
 if (zId == null) {
  zoneId = zId = toZoneId0();
 }
return zId;
}

private ZoneId toZoneId0() {
 String id = getID();
 if (ZoneInfoFile.useOldMapping() && id.length() == 3) {
  if ("EST".equals(id)) {
   zId = ZoneId.of("America/New_York");
  } else if ("MST".equals(id)) {
   zId = ZoneId.of("America/Denver");
  } else if ("HST".equals(id)) {
   zId = ZoneId.of("America/Honolulu");
  } else {
   zId = ZoneId.of(id, ZoneId.SHORT_IDS);
  }
 }
}

This should aid hotspot inlining (removing uncommon paths from main flow).

Does the code properly handle the static setDefault() method? I
suspect so, but will be worth a test.

>> If there's no undesirable side effect then caching zoneId
>> inside TimeZone looks reasonable to me - however I'm not an expert
>> of the field, and I got to learn that time/date can be more complex
>> than what I first thought ;-)
>
> One thing I noticed is that there are two kinds of ZoneRulesProvider(s):
> those that are static and allow their rules to be cached and the dynamic
> ones, that can provide dynamic view on rules and therefore don't allow
> caching of rules. But this aspect is encapsulated in ZoneRegion class (an
> implementation of ZoneId). So I think an instance to ZoneRegion (or any
> ZoneId) can be cached for indefinite time as long as it's id is the one that
> we are looking for.

Yes, ZoneId can be safely cached as an immutable object (probably
never going to be a value type BTW). All current ZoneRegion instances
have static, not dynamic, rules.


As a final possibility, it might be possible to add a new subclass of
TimeZone that works directly off ZoneId. (sourcing the offset rules
from ZoneId instead of direct from the underlying data). However, the
mutable API of TimeZone probably makes it quite hard to get right.

On the specific ZIP code, using LocalDateTime rather than
ZonedDateTime may be faster as there are less objects to create.Claes'
code looks OK at first glance.

To get more performance, effort needs to be spent on LocalDate.of()
and LocalTime.of(). Both use very clean code, but it calls out to a
general routine that has to lookup boundary numbers. Because they are
general, they have quite deep call stacks, and inlining sometimes
fails to reach them due to inlining depth limits. For those two
critical pieces of code, the limits need to be inlined, something like
this:

public static LocalDate of(int year, int month, int dayOfMonth) {
 if (year < Year.MIN_VALUE || year > Year.MAX_VALUE) {
  throw new DateTimeException(genInvalidFieldMessage(YEAR, year))
 }
 if (month < 1 || month > 12) {
  throw new DateTimeException(genInvalidFieldMessage(MONTH_OF_YEAR, month))
 }
 if (dayOfMonth < 1 || dayOfMonth > 31) {
  throw new DateTimeException(genInvalidFieldMessage(DAY_OF_MONTH, dayOfMonth))
 }
 return create(year, month, dayOfMonth);
}
private String genInvalidFieldMessage(TemporalField field, long value) {
 return "Invalid value for " + field + " (valid values " + this + "): " + value;
}

I've not tested if this is faster, but I'd be surprised if it wasn't.

Stephen



On 22 February 2015 at 20:21, Peter Levart <peter.levart at gmail.com> wrote:
> Hi,
>
> I noticed internal JDK class java.util.zip.ZipUtils uses deprecated
> java.util.Date API for implementing two methods for converting DOS to Java
> time and back. I thought I'd try translating them to use new java.time API.
> Translation was straightforward, but I noticed that new implementations are
> not on par with speed to old java.util.Date versions. Here's a JMH benchmark
> implementing those two conversion methods with java.util.Date and
> java.time.ZonedDateTime APIs:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/ZipUtilsTest.java
>
> The results show the following:
>
> Benchmark                               Mode   Samples Score  Score error
> Units
> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt         5 101.890       17.570
> ns/op
> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt         5 137.587       13.533
> ns/op
> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       67.114       10.382
> ns/op
> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt         5 143.739       15.243
> ns/op
>
>
> Quick sampling with jvisualvm shows that a substantial time is spent
> repeatedly obtaining ZoneId.systemDefault() instance. I checked the
> implementation and came up with the following optimization:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.01/
>
> TimeZone is a mutable object and has to be defensively cloned when
> TimeZone.getDefault() is invoked. So there's no point in caching a ZoneId
> instance inside TimeZone instance if we cache it on a clone that is thrown
> away each time ZoneId.systemDefault() is invoked. I use SharedSecrets to
> access the uncloned TimeZone.defaultTimeZone instance where caching of
> ZoneId pays of.
>
> I think that it was never meant to change TimeZone's ID (TimeZone.setID())
> after such instance was put into operation (for example installed as default
> time zone with TimeZone.setDefault()). Such use is unintended and buggy. So
> I also changed the implementation of TimeZone.setDefault() to save a
> defensive copy of TimeZone object as default time zone instead of a
> reference to it.
>
> With this patch, the DOS/Java time conversion benchmark shows an
> improvement:
>
> Benchmark                               Mode   Samples Score  Score error
> Units
> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt 5       97.986       18.379
> ns/op
> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt 5       85.010       10.863
> ns/op
> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       71.073       25.408
> ns/op
> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt 5       95.298       17.620
> ns/op
>
>
> Is this patch correct or did I miss something from the internals of
> java.time API that does not permit such caching?
>
>
> Regards, Peter
>


From david.holmes at oracle.com  Mon Feb 23 12:30:11 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 23 Feb 2015 22:30:11 +1000
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <54EB08A5.4000905@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com> <54E71BC3.30403@oracle.com>
	<54E74E29.2060806@gmail.com> <54EB08A5.4000905@oracle.com>
Message-ID: <54EB1D53.90203@oracle.com>

Hi Chris,

On 23/02/2015 9:01 PM, Chris Hegarty wrote:
> Peter, David, Vitaly,
>
> Can you please take a look at the latest version of this change:
>
>    http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/

It seems reasonable but I don't have a clear picture of the connection 
between readObject and readSerialData.

David

> On 20/02/15 15:09, Peter Levart wrote:
>> ...
>> This looks good now. But I wonder if issuing fences after nested calls
>> to readObject() makes much sense. If cycles are present in a subgraph
>> deserialized by nested call to readObject(), a field pointing back to an
>> object not part of the subgraph stream will point to the object that
>> will not be fully initialized yet, so nested calls to readObject()
>> should not be expected to return a reference to a fully constructed
>> subgraph anyway. Only top-level call is guaranteed to return a fully
>> constructed graph.
>
> Right. I was never convinced of this myself either. Removed. Unnecessary
> complication.
>
>> If you optimize this and only issue one fence for top-level call to
>> readObject(), tracking of 'requiresFence' (I would call it
>> requiresFreeze to be in line with JMM terminology - the fence is just a
>
> 'requiresFreeze' is better. Updated
>
>> way to achieve freeze) can also be micro-optimized. You currently do it
>> like this:
>>
>> 1900             requiresFence |= slotDesc.hasFinalField();
>>
>> which is a shortcut for:
>>
>> requiresFence = requiresFence | slotDesc.hasFinalField();
>>
>> ...which means that the field is overwritten multiple times
>> unnecessarily and slotDesc.hasFinalField() is called every time. You can
>> write the same logic as:
>>
>> if (!requiresFence && slotDesc.hasFinalField()) {
>>      requiresFence = true;
>> }
>
> ... and it is more readable. Updated.
>
>> There will be at most one write to the field and potentially less calls
>> to slotDesc.hasFinalField().
>
> -Chris.


From dmitry.samersoff at oracle.com  Mon Feb 23 14:02:55 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 23 Feb 2015 17:02:55 +0300
Subject: RFR(S): JDK-8073584 Native compilation warning in unpack code
In-Reply-To: <54EA8B75.5040406@oracle.com>
References: <54E77CA2.3090304@oracle.com> <54EA8B75.5040406@oracle.com>
Message-ID: <54EB330F.1090503@oracle.com>

Hi Everyone,

Webrev updated in-place (press shift-reload)

http://cr.openjdk.java.net/~dsamersoff/JDK-8073584/webrev.01/

Updated formatting.

Hack in main.cpp replaced with true error check.

-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 vitalyd at gmail.com  Mon Feb 23 14:08:25 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Mon, 23 Feb 2015 09:08:25 -0500
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <54EB1D53.90203@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>
	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com> <54E71BC3.30403@oracle.com>
	<54E74E29.2060806@gmail.com> <54EB08A5.4000905@oracle.com>
	<54EB1D53.90203@oracle.com>
Message-ID: <CAHjP37EMU3xHntTNUAYhNr4oCr-7zTpRG84nzKW-EuAmP8kkLQ@mail.gmail.com>

Likewise, seems fine.   By the way, is there a reason not to call freeze()
right before returning obj? Is there something special about the place it's
invoked at now?

Also, hasFinal field can be final, unless I missed some context in the
webrev.

sent from my phone
On Feb 23, 2015 7:30 AM, "David Holmes" <david.holmes at oracle.com> wrote:

> Hi Chris,
>
> On 23/02/2015 9:01 PM, Chris Hegarty wrote:
>
>> Peter, David, Vitaly,
>>
>> Can you please take a look at the latest version of this change:
>>
>>    http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/
>>
>
> It seems reasonable but I don't have a clear picture of the connection
> between readObject and readSerialData.
>
> David
>
>  On 20/02/15 15:09, Peter Levart wrote:
>>
>>> ...
>>> This looks good now. But I wonder if issuing fences after nested calls
>>> to readObject() makes much sense. If cycles are present in a subgraph
>>> deserialized by nested call to readObject(), a field pointing back to an
>>> object not part of the subgraph stream will point to the object that
>>> will not be fully initialized yet, so nested calls to readObject()
>>> should not be expected to return a reference to a fully constructed
>>> subgraph anyway. Only top-level call is guaranteed to return a fully
>>> constructed graph.
>>>
>>
>> Right. I was never convinced of this myself either. Removed. Unnecessary
>> complication.
>>
>>  If you optimize this and only issue one fence for top-level call to
>>> readObject(), tracking of 'requiresFence' (I would call it
>>> requiresFreeze to be in line with JMM terminology - the fence is just a
>>>
>>
>> 'requiresFreeze' is better. Updated
>>
>>  way to achieve freeze) can also be micro-optimized. You currently do it
>>> like this:
>>>
>>> 1900             requiresFence |= slotDesc.hasFinalField();
>>>
>>> which is a shortcut for:
>>>
>>> requiresFence = requiresFence | slotDesc.hasFinalField();
>>>
>>> ...which means that the field is overwritten multiple times
>>> unnecessarily and slotDesc.hasFinalField() is called every time. You can
>>> write the same logic as:
>>>
>>> if (!requiresFence && slotDesc.hasFinalField()) {
>>>      requiresFence = true;
>>> }
>>>
>>
>> ... and it is more readable. Updated.
>>
>>  There will be at most one write to the field and potentially less calls
>>> to slotDesc.hasFinalField().
>>>
>>
>> -Chris.
>>
>


From martin.desruisseaux at geomatys.fr  Mon Feb 23 14:20:27 2015
From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux)
Date: Mon, 23 Feb 2015 15:20:27 +0100
Subject: ConcurrentModificationException in java.util.ServiceLoader (not a
	multi-thread issue)
Message-ID: <54EB372B.401@geomatys.fr>

Hello all

java.util.ServiceLoader does not seem to support usage of a second
Iterator in the middle of a previous iteration. The attached Java file
provides two simple tests with a ServiceLoader iterating over two
elements. The first test creates two iterators and invokes their
hasNext() / next() methods in the following order:

  * Iterator 1
  * Iterator 2
  * Iterator 1
  * Iterator 2  -  unexpected end of iteration here.

The second test creates two iterators and invoke the hasNext() methods
on both iterators before to invoke their next() methods. This result is
the following exception (tested on 1.8.0_31-b13):

    Exception in thread "main" java.util.ConcurrentModificationException
    	at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711)
    	at java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:744)
    	at java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:742)
    	at java.util.ServiceLoader$1.next(ServiceLoader.java:479)
    	at test.ServiceLoaderTest.test2(ServiceLoaderTest.java:47)
    	at test.ServiceLoaderTest.main(ServiceLoaderTest.java:12)

(note: to run the test, the attached test.ServiceLoaderTest file needs
to be in the META-INF/services/ directory). I found a Stackoverflow
thread mentioning this issue 4 years ago [1], but apparently without
solution. Should I look for a patch, or is the current behaviour
considered okay (in which case I would suggest to warn the users in the
Javadoc)?


    Martin


[1] http://stackoverflow.com/questions/2593777/serviceloader-double-iterator-issues


-------------- next part --------------
test.ServiceLoaderTest$I1
test.ServiceLoaderTest$I2

From Roger.Riggs at Oracle.com  Mon Feb 23 14:32:20 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 23 Feb 2015 09:32:20 -0500
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EB0E00.1050108@oracle.com>
References: <54EA3A41.9000309@gmail.com>
	<54EAF7E4.40706@oracle.com>	<54EB010C.6030903@gmail.com>
	<54EB0E00.1050108@oracle.com>
Message-ID: <54EB39F4.6090504@Oracle.com>

Hi,

Does it make sense that the shared secret mechanism may no longer be 
needed in JDK 9,
at least within modules, since the module access controls should provide 
the desired scoping.

Roger

On 2/23/2015 6:24 AM, Daniel Fuchs wrote:
>
> Agreed. I'm just not a big fan of using SharedSecrets if that can
> be helped. I just wanted to see if there was other alternatives to
> explore. 



From chris.hegarty at oracle.com  Mon Feb 23 15:22:12 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 23 Feb 2015 15:22:12 +0000
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <54EB1D53.90203@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com> <54E71BC3.30403@oracle.com>
	<54E74E29.2060806@gmail.com> <54EB08A5.4000905@oracle.com>
	<54EB1D53.90203@oracle.com>
Message-ID: <54EB45A4.5070108@oracle.com>

On 23/02/15 12:30, David Holmes wrote:
> Hi Chris,
>
> On 23/02/2015 9:01 PM, Chris Hegarty wrote:
>> Peter, David, Vitaly,
>>
>> Can you please take a look at the latest version of this change:
>>
>>    http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/
>
> It seems reasonable

Thanks.

> but I don't have a clear picture of the connection
> between readObject and readSerialData.

readObject() is the public entry point to re-constructing an object from 
the stream. readSerialData is responsible for reading, from the stream, 
and setting the objects field values. readSerialData is currently the 
only way, without the use of reflection and a custom 
readObject(ObjectInputStream), that the Serialization implementation can 
set final fields.

Thanks for your review and comments.

-Chris.

> David
>
>> On 20/02/15 15:09, Peter Levart wrote:
>>> ...
>>> This looks good now. But I wonder if issuing fences after nested calls
>>> to readObject() makes much sense. If cycles are present in a subgraph
>>> deserialized by nested call to readObject(), a field pointing back to an
>>> object not part of the subgraph stream will point to the object that
>>> will not be fully initialized yet, so nested calls to readObject()
>>> should not be expected to return a reference to a fully constructed
>>> subgraph anyway. Only top-level call is guaranteed to return a fully
>>> constructed graph.
>>
>> Right. I was never convinced of this myself either. Removed. Unnecessary
>> complication.
>>
>>> If you optimize this and only issue one fence for top-level call to
>>> readObject(), tracking of 'requiresFence' (I would call it
>>> requiresFreeze to be in line with JMM terminology - the fence is just a
>>
>> 'requiresFreeze' is better. Updated
>>
>>> way to achieve freeze) can also be micro-optimized. You currently do it
>>> like this:
>>>
>>> 1900             requiresFence |= slotDesc.hasFinalField();
>>>
>>> which is a shortcut for:
>>>
>>> requiresFence = requiresFence | slotDesc.hasFinalField();
>>>
>>> ...which means that the field is overwritten multiple times
>>> unnecessarily and slotDesc.hasFinalField() is called every time. You can
>>> write the same logic as:
>>>
>>> if (!requiresFence && slotDesc.hasFinalField()) {
>>>      requiresFence = true;
>>> }
>>
>> ... and it is more readable. Updated.
>>
>>> There will be at most one write to the field and potentially less calls
>>> to slotDesc.hasFinalField().
>>
>> -Chris.


From chris.hegarty at oracle.com  Mon Feb 23 15:32:45 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 23 Feb 2015 15:32:45 +0000
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <CAHjP37EMU3xHntTNUAYhNr4oCr-7zTpRG84nzKW-EuAmP8kkLQ@mail.gmail.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>	<54E67F76.8030104@oracle.com>	<54E71BC3.30403@oracle.com>	<54E74E29.2060806@gmail.com>	<54EB08A5.4000905@oracle.com>	<54EB1D53.90203@oracle.com>
	<CAHjP37EMU3xHntTNUAYhNr4oCr-7zTpRG84nzKW-EuAmP8kkLQ@mail.gmail.com>
Message-ID: <54EB481D.4050408@oracle.com>

On 23/02/15 14:08, Vitaly Davidovich wrote:
> Likewise, seems fine.

Thanks Vitaly.

>  By the way, is there a reason not to call
> freeze() right before returning obj? Is there something special about
> the place it's invoked at now?

Probably not. The freeze should probably happen before the 
ObjectInputValidation callback, as this justs opens another opportunity 
for early publication of the object, but probably after the handle 
update and check.

> Also, hasFinal field can be final, unless I missed some context in the
> webrev.

It could be, but I omitted it as it requires a pesky explicit assignment 
of false in the case where there are not final fields!

For completeness, updated webrev in-place, which I intend to push, 
unless there are further comments:
   http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/

-Chris.

> sent from my phone
>
> On Feb 23, 2015 7:30 AM, "David Holmes" <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi Chris,
>
>     On 23/02/2015 9:01 PM, Chris Hegarty wrote:
>
>         Peter, David, Vitaly,
>
>         Can you please take a look at the latest version of this change:
>
>         http://cr.openjdk.java.net/~__chegar/deserialFence/webrev.__02/webrev/
>         <http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/>
>
>
>     It seems reasonable but I don't have a clear picture of the
>     connection between readObject and readSerialData.
>
>     David
>
>         On 20/02/15 15:09, Peter Levart wrote:
>
>             ...
>             This looks good now. But I wonder if issuing fences after
>             nested calls
>             to readObject() makes much sense. If cycles are present in a
>             subgraph
>             deserialized by nested call to readObject(), a field
>             pointing back to an
>             object not part of the subgraph stream will point to the
>             object that
>             will not be fully initialized yet, so nested calls to
>             readObject()
>             should not be expected to return a reference to a fully
>             constructed
>             subgraph anyway. Only top-level call is guaranteed to return
>             a fully
>             constructed graph.
>
>
>         Right. I was never convinced of this myself either. Removed.
>         Unnecessary
>         complication.
>
>             If you optimize this and only issue one fence for top-level
>             call to
>             readObject(), tracking of 'requiresFence' (I would call it
>             requiresFreeze to be in line with JMM terminology - the
>             fence is just a
>
>
>         'requiresFreeze' is better. Updated
>
>             way to achieve freeze) can also be micro-optimized. You
>             currently do it
>             like this:
>
>             1900             requiresFence |= slotDesc.hasFinalField();
>
>             which is a shortcut for:
>
>             requiresFence = requiresFence | slotDesc.hasFinalField();
>
>             ...which means that the field is overwritten multiple times
>             unnecessarily and slotDesc.hasFinalField() is called every
>             time. You can
>             write the same logic as:
>
>             if (!requiresFence && slotDesc.hasFinalField()) {
>                   requiresFence = true;
>             }
>
>
>         ... and it is more readable. Updated.
>
>             There will be at most one write to the field and potentially
>             less calls
>             to slotDesc.hasFinalField().
>
>
>         -Chris.
>


From vitalyd at gmail.com  Mon Feb 23 15:30:39 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Mon, 23 Feb 2015 10:30:39 -0500
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <54EB481D.4050408@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>
	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com> <54E71BC3.30403@oracle.com>
	<54E74E29.2060806@gmail.com> <54EB08A5.4000905@oracle.com>
	<54EB1D53.90203@oracle.com>
	<CAHjP37EMU3xHntTNUAYhNr4oCr-7zTpRG84nzKW-EuAmP8kkLQ@mail.gmail.com>
	<54EB481D.4050408@oracle.com>
Message-ID: <CAHjP37EH5vBtXwSN4e0f989aKwbHwD585M0bsUyOWLp-iXBvcQ@mail.gmail.com>

Ok Chris, sounds good.

It could be, but I omitted it as it requires a pesky explicit assignment of
> false in the case where there are not final fields!


You could use a local (non-final) boolean to track this state (assigned
with false), and then set the field with it after the looping is over.
Anyway, your call.

On Mon, Feb 23, 2015 at 10:32 AM, Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> On 23/02/15 14:08, Vitaly Davidovich wrote:
>
>> Likewise, seems fine.
>>
>
> Thanks Vitaly.
>
>   By the way, is there a reason not to call
>> freeze() right before returning obj? Is there something special about
>> the place it's invoked at now?
>>
>
> Probably not. The freeze should probably happen before the
> ObjectInputValidation callback, as this justs opens another opportunity for
> early publication of the object, but probably after the handle update and
> check.
>
>  Also, hasFinal field can be final, unless I missed some context in the
>> webrev.
>>
>
> It could be, but I omitted it as it requires a pesky explicit assignment
> of false in the case where there are not final fields!
>
> For completeness, updated webrev in-place, which I intend to push, unless
> there are further comments:
>   http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/
>
> -Chris.
>
>  sent from my phone
>>
>> On Feb 23, 2015 7:30 AM, "David Holmes" <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi Chris,
>>
>>     On 23/02/2015 9:01 PM, Chris Hegarty wrote:
>>
>>         Peter, David, Vitaly,
>>
>>         Can you please take a look at the latest version of this change:
>>
>>         http://cr.openjdk.java.net/~__chegar/deserialFence/webrev.__
>> 02/webrev/
>>
>>         <http://cr.openjdk.java.net/~chegar/deserialFence/webrev.
>> 02/webrev/>
>>
>>
>>     It seems reasonable but I don't have a clear picture of the
>>     connection between readObject and readSerialData.
>>
>>     David
>>
>>         On 20/02/15 15:09, Peter Levart wrote:
>>
>>             ...
>>             This looks good now. But I wonder if issuing fences after
>>             nested calls
>>             to readObject() makes much sense. If cycles are present in a
>>             subgraph
>>             deserialized by nested call to readObject(), a field
>>             pointing back to an
>>             object not part of the subgraph stream will point to the
>>             object that
>>             will not be fully initialized yet, so nested calls to
>>             readObject()
>>             should not be expected to return a reference to a fully
>>             constructed
>>             subgraph anyway. Only top-level call is guaranteed to return
>>             a fully
>>             constructed graph.
>>
>>
>>         Right. I was never convinced of this myself either. Removed.
>>         Unnecessary
>>         complication.
>>
>>             If you optimize this and only issue one fence for top-level
>>             call to
>>             readObject(), tracking of 'requiresFence' (I would call it
>>             requiresFreeze to be in line with JMM terminology - the
>>             fence is just a
>>
>>
>>         'requiresFreeze' is better. Updated
>>
>>             way to achieve freeze) can also be micro-optimized. You
>>             currently do it
>>             like this:
>>
>>             1900             requiresFence |= slotDesc.hasFinalField();
>>
>>             which is a shortcut for:
>>
>>             requiresFence = requiresFence | slotDesc.hasFinalField();
>>
>>             ...which means that the field is overwritten multiple times
>>             unnecessarily and slotDesc.hasFinalField() is called every
>>             time. You can
>>             write the same logic as:
>>
>>             if (!requiresFence && slotDesc.hasFinalField()) {
>>                   requiresFence = true;
>>             }
>>
>>
>>         ... and it is more readable. Updated.
>>
>>             There will be at most one write to the field and potentially
>>             less calls
>>             to slotDesc.hasFinalField().
>>
>>
>>         -Chris.
>>
>>


From chris.hegarty at oracle.com  Mon Feb 23 15:40:22 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 23 Feb 2015 15:40:22 +0000
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <CAHjP37EH5vBtXwSN4e0f989aKwbHwD585M0bsUyOWLp-iXBvcQ@mail.gmail.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>	<54E67F76.8030104@oracle.com>	<54E71BC3.30403@oracle.com>	<54E74E29.2060806@gmail.com>	<54EB08A5.4000905@oracle.com>	<54EB1D53.90203@oracle.com>	<CAHjP37EMU3xHntTNUAYhNr4oCr-7zTpRG84nzKW-EuAmP8kkLQ@mail.gmail.com>	<54EB481D.4050408@oracle.com>
	<CAHjP37EH5vBtXwSN4e0f989aKwbHwD585M0bsUyOWLp-iXBvcQ@mail.gmail.com>
Message-ID: <54EB49E6.90200@oracle.com>

On 23/02/15 15:30, Vitaly Davidovich wrote:
> Ok Chris, sounds good.
>
>     It could be, but I omitted it as it requires a pesky explicit
>     assignment of false in the case where there are not final fields!
>
>
> You could use a local (non-final) boolean to track this state (assigned
> with false), and then set the field with it after the looping is over.
> Anyway, your call.

That is better. Done.

Thanks,
-Chris.

> On Mon, Feb 23, 2015 at 10:32 AM, Chris Hegarty
> <chris.hegarty at oracle.com <mailto:chris.hegarty at oracle.com>> wrote:
>
>     On 23/02/15 14:08, Vitaly Davidovich wrote:
>
>         Likewise, seems fine.
>
>
>     Thanks Vitaly.
>
>           By the way, is there a reason not to call
>         freeze() right before returning obj? Is there something special
>         about
>         the place it's invoked at now?
>
>
>     Probably not. The freeze should probably happen before the
>     ObjectInputValidation callback, as this justs opens another
>     opportunity for early publication of the object, but probably after
>     the handle update and check.
>
>         Also, hasFinal field can be final, unless I missed some context
>         in the
>         webrev.
>
>
>     It could be, but I omitted it as it requires a pesky explicit
>     assignment of false in the case where there are not final fields!
>
>     For completeness, updated webrev in-place, which I intend to push,
>     unless there are further comments:
>     http://cr.openjdk.java.net/~__chegar/deserialFence/webrev.__02/webrev/
>     <http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/>
>
>     -Chris.
>
>         sent from my phone
>
>         On Feb 23, 2015 7:30 AM, "David Holmes" <david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>
>         <mailto:david.holmes at oracle.__com
>         <mailto:david.holmes at oracle.com>>> wrote:
>
>              Hi Chris,
>
>              On 23/02/2015 9:01 PM, Chris Hegarty wrote:
>
>                  Peter, David, Vitaly,
>
>                  Can you please take a look at the latest version of
>         this change:
>
>         http://cr.openjdk.java.net/~____chegar/deserialFence/webrev.____02/webrev/
>         <http://cr.openjdk.java.net/~__chegar/deserialFence/webrev.__02/webrev/>
>
>
>         <http://cr.openjdk.java.net/~__chegar/deserialFence/webrev.__02/webrev/
>         <http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/>>
>
>
>              It seems reasonable but I don't have a clear picture of the
>              connection between readObject and readSerialData.
>
>              David
>
>                  On 20/02/15 15:09, Peter Levart wrote:
>
>                      ...
>                      This looks good now. But I wonder if issuing fences
>         after
>                      nested calls
>                      to readObject() makes much sense. If cycles are
>         present in a
>                      subgraph
>                      deserialized by nested call to readObject(), a field
>                      pointing back to an
>                      object not part of the subgraph stream will point
>         to the
>                      object that
>                      will not be fully initialized yet, so nested calls to
>                      readObject()
>                      should not be expected to return a reference to a fully
>                      constructed
>                      subgraph anyway. Only top-level call is guaranteed
>         to return
>                      a fully
>                      constructed graph.
>
>
>                  Right. I was never convinced of this myself either.
>         Removed.
>                  Unnecessary
>                  complication.
>
>                      If you optimize this and only issue one fence for
>         top-level
>                      call to
>                      readObject(), tracking of 'requiresFence' (I would
>         call it
>                      requiresFreeze to be in line with JMM terminology - the
>                      fence is just a
>
>
>                  'requiresFreeze' is better. Updated
>
>                      way to achieve freeze) can also be micro-optimized. You
>                      currently do it
>                      like this:
>
>                      1900             requiresFence |=
>         slotDesc.hasFinalField();
>
>                      which is a shortcut for:
>
>                      requiresFence = requiresFence |
>         slotDesc.hasFinalField();
>
>                      ...which means that the field is overwritten
>         multiple times
>                      unnecessarily and slotDesc.hasFinalField() is
>         called every
>                      time. You can
>                      write the same logic as:
>
>                      if (!requiresFence && slotDesc.hasFinalField()) {
>                            requiresFence = true;
>                      }
>
>
>                  ... and it is more readable. Updated.
>
>                      There will be at most one write to the field and
>         potentially
>                      less calls
>                      to slotDesc.hasFinalField().
>
>
>                  -Chris.
>
>


From claes.redestad at oracle.com  Mon Feb 23 15:41:48 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 23 Feb 2015 16:41:48 +0100
Subject: RFR(S): 8073497: Lazy conversion of ZipEntry time
In-Reply-To: <54EA4744.1090703@oracle.com>
References: <54E8976B.8050104@oracle.com> <54E8D34C.7000805@oracle.com>
	<54E93AE4.1030301@oracle.com> <54EA4744.1090703@oracle.com>
Message-ID: <54EB4A3C.7030308@oracle.com>

On 02/22/2015 10:16 PM, Xueming Shen wrote:
> On 2/21/15 6:11 PM, Claes Redestad wrote:
>> Hi Sherman,
>>
>> On 2015-02-21 19:49, Xueming Shen wrote:
>>> Hi Claes,
>>>
>>> This change basically undo the "fix" for 4759491 [1], for better 
>>> performance ...
>>>
>>
>> my intent was never to break current behavior, but that mistake can 
>> be rectified
>> without missing out on the startup benefit of laziness:
>>
>> http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.1/
>>
>> The time/mtime getters now use the mtime field if it exists, while 
>> the setters will
>> update both fields. Since getLastModified already fell back to 
>> converting the
>> time field rather than null if mtime wasn't set, setting mtime to a 
>> FileTime when
>> calling setTime seems consistent and a cheap way to preserve the time 
>> precision.
>>
>> I guess a range check to skip the FileTime creation in setTime if the 
>> time is within
>> the DOS time bounds would be a valid optimization, since that will 
>> typically
>> always be the case.
>
>
> It's a reasonable solution. I would assume we probably need that 
> "range check" optimization
> to avoid setting the "mtime" field in normal use scenario. ZOS now 
> outputs the more accurate
> "mtime" to the zip file using "extend timestamp" if it's not null (the 
> entry gets bigger). The
> assumption now is that we only output the extended timestamp if the 
> time stamps set
> via the setXYZTime() explicitly.
>
> ZOS.java
>
> ...
>   432         int elenEXTT = 0;               // info-zip extended timestamp
>   433         int flagEXTT = 0;
>   434         if (e.mtime != null) {
>   435             elenEXTT += 4;
>   436             flagEXTT |= EXTT_FLAG_LMT;
>   437         }
>   438         if (e.atime != null) {
>   439             elenEXTT += 4;
>   440             flagEXTT |= EXTT_FLAG_LAT;
>   441         }
>   442         if (e.ctime != null) {
>   443             elenEXTT += 4;
>   444             flagEXTT |= EXTT_FLAT_CT;
>   445         }
>   446         if (flagEXTT != 0)
>   447             elen += (elenEXTT + 5);    // headid(2) + size(2) + flag(1) + data
>   448         writeShort(elen);
> ...

Here's my attempt to resolve this:

webrev: http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.2/
incremental: 
http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.1_to_2/

Calculating exact upper and lower bounds would only make sense for the 
current timezone
and would have to be recalculated, while approximate bounds should 
suffice for the practical
purpose of avoiding the FileTime creation in the typical case for 
performance reasons.

I rather arbitrarily chose an upper bound around 2098. Lower bound check 
could test for
some value near 1980, but since there's already code to check if 
Date.getYear() is less
than 1980 I figured that might suffice...

... that's when I stumbled on a few subtle bugs in the 
dosToJava/javaToDos conversion methods,
first and foremost that a Date representing times before the era 
(typically year 1), getYear
returns positive years. While a pretty artificial scenario, this is a 
bug in the javaToDosTime
conversion which breaks some tests. A simple check that millisecond long 
is larger than 0
is sufficient to resolve this negative-year-overflow for the current 
implementation.

We also don't check for year overflow for instants after 2107 in the 
local time: these will start
over at 1980. The old behavior is to simply accept the overflow. I've 
kept the behavior for the
dostime conversion, while the upper bound check ensure that the mtime 
will be calculated in
these cases, which seems reasonable.

This code does come with loss of some precision when setting time via 
setTime(long) in the
valid DOS time range (it will be rounded to 2-second precision), but 
with setLastModifiedTime
available to get the better precision this might be an acceptable 
behavioral regression of
setTime (while slightly weird, it doesn't seem to violate the 
specification).

/Claes

>
> -Sherman
>
>
>>> If we go with this change, I think we should also update the field 
>>> comment back to the
>>> original one to clearly indicates the "time" is "in DOS time".
>>>
>>> -    long time = -1;     // modification time (in DOS time)
>>> +    long mtime = -1;    // last modification time
>>>
>>
>> Done.
>>
>>>
>>> The set/getLastModifiedTime() pair also need update to set/get the 
>>> "time" field
>>> correctly to/from the dos time.
>>
>> Done.
>>
>> Thanks!
>>
>> /Claes
>>
>>>
>>> -Sherman
>>>
>>> [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/90df6756406f
>>>
>>> On 2/21/15 6:34 AM, Claes Redestad wrote:
>>>> Hi all,
>>>>
>>>> please review this patch to re-introduce laziness in the 
>>>> java-to-dos time
>>>> conversions for the ZipEntry.time field.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.0/
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073497
>>>>
>>>> See bug for more details.
>>>>
>>>> This behavior was actually the case before 8-b94, when the time field
>>>> was removed in favor of a set of FileTime fields, but when it was 
>>>> later
>>>> re-introduced to address some compatibility issues the conversion was
>>>> implemented in an eager fashion. This inadvertently affects VM startup
>>>> ever so little, since for every entry read via a ZipFile or 
>>>> ZipInputStream
>>>> we'll do a relatively expensive call creating a Date and doing 
>>>> timezone
>>>> conversion.
>>>>
>>>> Some gains from loading fewer classes during VM startup, as well.
>>>>
>>>> Thanks!
>>>>
>>>> /Claes
>>>
>>
>



From peter.levart at gmail.com  Mon Feb 23 15:54:58 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 23 Feb 2015 16:54:58 +0100
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EB39F4.6090504@Oracle.com>
References: <54EA3A41.9000309@gmail.com>	<54EAF7E4.40706@oracle.com>	<54EB010C.6030903@gmail.com>	<54EB0E00.1050108@oracle.com>
	<54EB39F4.6090504@Oracle.com>
Message-ID: <54EB4D52.5070609@gmail.com>

On 02/23/2015 03:32 PM, Roger Riggs wrote:
> Hi,
>
> Does it make sense that the shared secret mechanism may no longer be 
> needed in JDK 9,
> at least within modules, since the module access controls should 
> provide the desired scoping.
>
> Roger

Will there be a language-level "module" access modifier for 
classes/fields/methods that will allow only intra-module access?

Regards, Peter

>
> On 2/23/2015 6:24 AM, Daniel Fuchs wrote:
>>
>> Agreed. I'm just not a big fan of using SharedSecrets if that can
>> be helped. I just wanted to see if there was other alternatives to
>> explore. 
>



From paul.sandoz at oracle.com  Mon Feb 23 15:59:56 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 23 Feb 2015 16:59:56 +0100
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <54EB49E6.90200@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>	<54E67F76.8030104@oracle.com>	<54E71BC3.30403@oracle.com>	<54E74E29.2060806@gmail.com>	<54EB08A5.4000905@oracle.com>	<54EB1D53.90203@oracle.com>	<CAHjP37EMU3xHntTNUAYhNr4oCr-7zTpRG84nzKW-EuAmP8kkLQ@mail.gmail.com>	<54EB481D.4050408@oracle.com>
	<CAHjP37EH5vBtXwSN4e0f989aKwbHwD585M0bsUyOWLp-iXBvcQ@mail.gmail.com>
	<54EB49E6.90200@oracle.com>
Message-ID: <C9ADB759-DFCA-4C18-A466-8F621E2C1195@oracle.com>


On Feb 23, 2015, at 4:40 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> On 23/02/15 15:30, Vitaly Davidovich wrote:
>> Ok Chris, sounds good.
>> 
>>    It could be, but I omitted it as it requires a pesky explicit
>>    assignment of false in the case where there are not final fields!
>> 
>> 
>> You could use a local (non-final) boolean to track this state (assigned
>> with false), and then set the field with it after the looping is over.
>> Anyway, your call.
> 
> That is better. Done.
> 

This looks good. I think it would be useful to have a comment in the freeze method that this stamps in a storestore|storeload barrier (since that is the closest we have here) where as hotspot for construction stamps in just the necessary a storestore barrier. 

Two follow ups:

1) How can we test this? Is there anything in the HotSpot-related white box class that could be used? I suspect there is probably not and it will be tricky to test.

2) What about existing code in the JDK that uses UNSAFE.setVolatile or explicit fence calls? Such code should be updated. For example, i recall there might be stuff in BigInteger/Decimal. We can do a search for classes that are serializable with final fields.

Paul.



From Roger.Riggs at Oracle.com  Mon Feb 23 16:13:26 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 23 Feb 2015 11:13:26 -0500
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EB4D52.5070609@gmail.com>
References: <54EA3A41.9000309@gmail.com>	<54EAF7E4.40706@oracle.com>	<54EB010C.6030903@gmail.com>	<54EB0E00.1050108@oracle.com>
	<54EB39F4.6090504@Oracle.com> <54EB4D52.5070609@gmail.com>
Message-ID: <54EB51A6.9040502@Oracle.com>

Hi,

My understanding is that only whole classes can be explicitly exported 
from a module.
If not exported, they are module private.

Roger

On 2/23/2015 10:54 AM, Peter Levart wrote:
> On 02/23/2015 03:32 PM, Roger Riggs wrote:
>> Hi,
>>
>> Does it make sense that the shared secret mechanism may no longer be 
>> needed in JDK 9,
>> at least within modules, since the module access controls should 
>> provide the desired scoping.
>>
>> Roger
>
> Will there be a language-level "module" access modifier for 
> classes/fields/methods that will allow only intra-module access?
>
> Regards, Peter
>
>>
>> On 2/23/2015 6:24 AM, Daniel Fuchs wrote:
>>>
>>> Agreed. I'm just not a big fan of using SharedSecrets if that can
>>> be helped. I just wanted to see if there was other alternatives to
>>> explore. 
>>
>



From chris.hegarty at oracle.com  Mon Feb 23 16:27:26 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 23 Feb 2015 16:27:26 +0000
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <C9ADB759-DFCA-4C18-A466-8F621E2C1195@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>	<54E67F76.8030104@oracle.com>	<54E71BC3.30403@oracle.com>	<54E74E29.2060806@gmail.com>	<54EB08A5.4000905@oracle.com>	<54EB1D53.90203@oracle.com>	<CAHjP37EMU3xHntTNUAYhNr4oCr-7zTpRG84nzKW-EuAmP8kkLQ@mail.gmail.com>	<54EB481D.4050408@oracle.com>	<CAHjP37EH5vBtXwSN4e0f989aKwbHwD585M0bsUyOWLp-iXBvcQ@mail.gmail.com>	<54EB49E6.90200@oracle.com>
	<C9ADB759-DFCA-4C18-A466-8F621E2C1195@oracle.com>
Message-ID: <54EB54EE.3010802@oracle.com>

On 23/02/15 15:59, Paul Sandoz wrote:
>
> On Feb 23, 2015, at 4:40 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>
>> On 23/02/15 15:30, Vitaly Davidovich wrote:
>>> Ok Chris, sounds good.
>>>
>>>     It could be, but I omitted it as it requires a pesky explicit
>>>     assignment of false in the case where there are not final fields!
>>>
>>>
>>> You could use a local (non-final) boolean to track this state (assigned
>>> with false), and then set the field with it after the looping is over.
>>> Anyway, your call.
>>
>> That is better. Done.
>>
>
> This looks good. I think it would be useful to have a comment in the freeze method that this stamps in a storestore|storeload barrier (since that is the closest we have here) where as hotspot for construction stamps in just the necessary a storestore barrier.

Comment added.
   http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/

> Two follow ups:
>
> 1) How can we test this? Is there anything in the HotSpot-related white box class that could be used? I suspect there is probably not and it will be tricky to test.

I am not aware of any such framework in Hotspot, but I'll see if I can 
write something that may have the ability replicate this, on some platforms.

> 2) What about existing code in the JDK that uses UNSAFE.setVolatile or explicit fence calls? Such code should be updated. For example, i recall there might be stuff in BigInteger/Decimal. We can do a search for classes that are serializable with final fields.

Ah yes, BigDecimal and BigInteger can be updated now ( there are no 
doubt others too ). I've included BigDecimal and BigInteger in the 
latest in-place updated webrev, to see if we might want to update them 
as part of this change.

-Chris.

> Paul.
>


From Alan.Bateman at oracle.com  Mon Feb 23 16:51:30 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 Feb 2015 16:51:30 +0000
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EB51A6.9040502@Oracle.com>
References: <54EA3A41.9000309@gmail.com>	<54EAF7E4.40706@oracle.com>	<54EB010C.6030903@gmail.com>	<54EB0E00.1050108@oracle.com>	<54EB39F4.6090504@Oracle.com>
	<54EB4D52.5070609@gmail.com> <54EB51A6.9040502@Oracle.com>
Message-ID: <54EB5A92.6040805@oracle.com>

On 23/02/2015 16:13, Roger Riggs wrote:
> Hi,
>
> My understanding is that only whole classes can be explicitly exported 
> from a module.
> If not exported, they are module private.
The assumption that we have in JEP 200 is that modules will be able to 
export all public types in an API package (so at the granularity of API 
package rather than class). Ultimately it is for JSR 376 to define.

So for now at least, the SharedSecrets usage in Peter's patch seems okay.

-Alan


From Roger.Riggs at Oracle.com  Mon Feb 23 16:57:53 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 23 Feb 2015 11:57:53 -0500
Subject: Time to remove deprecated Runtime.getLocalizedInput/OutputStream
	methods?
In-Reply-To: <54D4D5DC.3040303@Oracle.com>
References: <54D4D5DC.3040303@Oracle.com>
Message-ID: <54EB5C11.8060302@Oracle.com>

Hi,

I propose to remove two methods; they have been deprecated for more than 
a decade,
do not seem to be in use anywhere, and have degenerate implementations.

java.lang.Runtime.getLocalizedInputStream(InputStream in) 
java.lang.Runtime.getLocalizedOutputStream(OutputStream out)

I have not been able to find any use of them but would be happy to check 
further.

Comments and suggestions welcome, Roger




From kumar.x.srinivasan at oracle.com  Mon Feb 23 17:05:01 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 23 Feb 2015 09:05:01 -0800
Subject: RFR(S): JDK-8073584 Native compilation warning in unpack code
In-Reply-To: <54EB330F.1090503@oracle.com>
References: <54E77CA2.3090304@oracle.com> <54EA8B75.5040406@oracle.com>
	<54EB330F.1090503@oracle.com>
Message-ID: <54EB5DBD.9030503@oracle.com>

Much nicer  and thanks for making these changes!.

Kumar

On 2/23/2015 6:02 AM, Dmitry Samersoff wrote:
> Hi Everyone,
>
> Webrev updated in-place (press shift-reload)
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8073584/webrev.01/
>
> Updated formatting.
>
> Hack in main.cpp replaced with true error check.
>
> -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  Mon Feb 23 17:29:08 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 23 Feb 2015 18:29:08 +0100
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <54EB54EE.3010802@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>	<54E67F76.8030104@oracle.com>	<54E71BC3.30403@oracle.com>	<54E74E29.2060806@gmail.com>	<54EB08A5.4000905@oracle.com>	<54EB1D53.90203@oracle.com>	<CAHjP37EMU3xHntTNUAYhNr4oCr-7zTpRG84nzKW-EuAmP8kkLQ@mail.gmail.com>	<54EB481D.4050408@oracle.com>	<CAHjP37EH5vBtXwSN4e0f989aKwbHwD585M0bsUyOWLp-iXBvcQ@mail.gmail.com>	<54EB49E6.90200@oracle.com>
	<C9ADB759-DFCA-4C18-A466-8F621E2C1195@oracle.com>
	<54EB54EE.3010802@oracle.com>
Message-ID: <BF3BADAD-86CA-4DA9-84B6-B99D7A0D0E66@oracle.com>


On Feb 23, 2015, at 5:27 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> On 23/02/15 15:59, Paul Sandoz wrote:
>> 
>> On Feb 23, 2015, at 4:40 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> 
>>> On 23/02/15 15:30, Vitaly Davidovich wrote:
>>>> Ok Chris, sounds good.
>>>> 
>>>>    It could be, but I omitted it as it requires a pesky explicit
>>>>    assignment of false in the case where there are not final fields!
>>>> 
>>>> 
>>>> You could use a local (non-final) boolean to track this state (assigned
>>>> with false), and then set the field with it after the looping is over.
>>>> Anyway, your call.
>>> 
>>> That is better. Done.
>>> 
>> 
>> This looks good. I think it would be useful to have a comment in the freeze method that this stamps in a storestore|storeload barrier (since that is the closest we have here) where as hotspot for construction stamps in just the necessary a storestore barrier.
> 
> Comment added.

>  http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/
> 

Looks good.


>> Two follow ups:
>> 
>> 1) How can we test this? Is there anything in the HotSpot-related white box class that could be used? I suspect there is probably not and it will be tricky to test.
> 
> I am not aware of any such framework in Hotspot, but I'll see if I can write something that may have the ability replicate this, on some platforms.
> 

I suppose one could write a jc-stress-test. But i don't wanna block the review on this aspect.


>> 2) What about existing code in the JDK that uses UNSAFE.setVolatile or explicit fence calls? Such code should be updated. For example, i recall there might be stuff in BigInteger/Decimal. We can do a search for classes that are serializable with final fields.
> 
> Ah yes, BigDecimal and BigInteger can be updated now ( there are no doubt others too ). I've included BigDecimal and BigInteger in the latest in-place updated webrev, to see if we might want to update them as part of this change.
> 

Those seem fine to me. Alas we cannot use direct assignments in some kind of larval phase :-)

Paul.


From daniel.fuchs at oracle.com  Mon Feb 23 17:41:15 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 23 Feb 2015 18:41:15 +0100
Subject: RFR: 8073394: Clock.systemUTC() should return a constant
Message-ID: <54EB663B.70000@oracle.com>

Hi,

Please find below a small patch for
8073394: Clock.systemUTC() should return a constant

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

best regards,

-- daniel


From martin.desruisseaux at geomatys.fr  Mon Feb 23 18:05:55 2015
From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux)
Date: Mon, 23 Feb 2015 19:05:55 +0100
Subject: ConcurrentModificationException in java.util.ServiceLoader (not
	a multi-thread issue)
In-Reply-To: <54EB372B.401@geomatys.fr>
References: <54EB372B.401@geomatys.fr>
Message-ID: <54EB6C03.8010504@geomatys.fr>

Apparently the test case that I attached to my previous email was list.
There is a copy-and-paste of the 2 tests reproducing the ServiceLoader
issue:

package test;

import java.util.Iterator;
import java.util.ServiceLoader;

public class ServiceLoaderTest {
    public static class I1 extends ServiceLoaderTest {}
    public static class I2 extends ServiceLoaderTest {}

    public static void main(String[] args) {
        test1();
        test2();
    }

    private static void test1() {
        System.out.println();
        System.out.println("---- TEST 1 ----");
        ServiceLoader<ServiceLoaderTest> loader = ServiceLoader.load(ServiceLoaderTest.class);

        Iterator<ServiceLoaderTest> it1 = loader.iterator();
        System.out.println("it1.hasNext() = " + it1.hasNext());
        System.out.println("it1.next()    = " + it1.next());

        Iterator<ServiceLoaderTest> it2 = loader.iterator();
        System.out.println("it2.hasNext() = " + it2.hasNext());
        System.out.println("it2.next()    = " + it2.next());

        System.out.println("it1.hasNext() = " + it1.hasNext());
        System.out.println("it1.next()    = " + it1.next());

        System.out.println("it2.hasNext() = " + it2.hasNext());  // Expected "true" here, but get "false".
    }

    private static void test2() {
        System.out.println();
        System.out.println("---- TEST 2 ----");
        ServiceLoader<ServiceLoaderTest> loader = ServiceLoader.load(ServiceLoaderTest.class);

        Iterator<ServiceLoaderTest> it1 = loader.iterator();
        System.out.println("it1.hasNext() = " + it1.hasNext());
        System.out.println("it1.next()    = " + it1.next());

        Iterator<ServiceLoaderTest> it2 = loader.iterator();
        System.out.println("it1.hasNext() = " + it1.hasNext());
        System.out.println("it2.hasNext() = " + it2.hasNext());
        System.out.println("it1.next()    = " + it1.next());
        System.out.println("it2.next()    = " + it2.next());  // ConcurrentModificationException here.
    }
}



Martin


Le 23/02/15 15:20, Martin Desruisseaux a ?crit :
> Hello all
>
> java.util.ServiceLoader does not seem to support usage of a second
> Iterator in the middle of a previous iteration. The attached Java file
> provides two simple tests with a ServiceLoader iterating over two
> elements. The first test creates two iterators and invokes their
> hasNext() / next() methods in the following order:
>
>   * Iterator 1
>   * Iterator 2
>   * Iterator 1
>   * Iterator 2  -  unexpected end of iteration here.
>
> The second test creates two iterators and invoke the hasNext() methods
> on both iterators before to invoke their next() methods. This result is
> the following exception (tested on 1.8.0_31-b13):
>
>     Exception in thread "main" java.util.ConcurrentModificationException
>     	at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711)
>     	at java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:744)
>     	at java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:742)
>     	at java.util.ServiceLoader$1.next(ServiceLoader.java:479)
>     	at test.ServiceLoaderTest.test2(ServiceLoaderTest.java:47)
>     	at test.ServiceLoaderTest.main(ServiceLoaderTest.java:12)
>
> (note: to run the test, the attached test.ServiceLoaderTest file needs
> to be in the META-INF/services/ directory). I found a Stackoverflow
> thread mentioning this issue 4 years ago [1], but apparently without
> solution. Should I look for a patch, or is the current behaviour
> considered okay (in which case I would suggest to warn the users in the
> Javadoc)?
>
>
>     Martin
>
>
> [1] http://stackoverflow.com/questions/2593777/serviceloader-double-iterator-issues
>
>



From scolebourne at joda.org  Mon Feb 23 18:13:04 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 23 Feb 2015 18:13:04 +0000
Subject: RFR: 8073394: Clock.systemUTC() should return a constant
In-Reply-To: <54EB663B.70000@oracle.com>
References: <54EB663B.70000@oracle.com>
Message-ID: <CACzrW9BF=JtAgZwJa18AB40Tk=bLiDso8wsYpfq9hXh-GY1VJg@mail.gmail.com>

Looks OK to me, thanks for that.

Stephen



On 23 February 2015 at 17:41, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> Hi,
>
> Please find below a small patch for
> 8073394: Clock.systemUTC() should return a constant
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.00/
>
> best regards,
>
> -- daniel


From aph at redhat.com  Mon Feb 23 18:13:37 2015
From: aph at redhat.com (Andrew Haley)
Date: Mon, 23 Feb 2015 18:13:37 +0000
Subject: Unsafe.{get,put}-X-Unaligned; Efficient array comparison intrinsics
Message-ID: <54EB6DD1.4090803@redhat.com>

I've been kicking around a few ideas for Unsafe access methods for
unaligned access to byte arrays and buffers in order to provide
"whatever second-best mechanism the platform offers".  These would
provide the base for fast lexicographic array comparisons, etc.

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

If the platform supports unaligned memory accesses, the implementation
of {get,put}-X-Unaligned is obvious and trivial for both C1 and C2.
It gets interesting when we want to provide efficient unaligned
methods on machines with no hardware support.

We could provide compiler intrinsics which do when we need on such
machines.  However, I think this wouldn't deliver the best results.
>From the experiments I've done, the best implementation is to write
the access methods in Java and allow HotSpot to optimize them.  While
this seemed a bit counter-intuitive to me, it's best because C2 has
profile data that it can work on.  In many cases I suspect that data
read and written from a byte array will be aligned for their type and
C2 will take advantage of this, relegating the misaligned access to an
out-of-line code path as appropriate.  Also, these methods have the
additional benefit that they are always atomic as long as the data are
naturally aligned.

This does result in rather a lot of code for the methods for all sizes
and endiannesses, but none of it will be used on machines with
unaligned hardware support except in the interpreter.  (Perhaps the
interpreter too could have intrinsics?)

I have changed HeapByteBuffer to use these methods, with a major
performance improvement.  I've also provided Unsafe methods to query
endianness and alignment support.

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

Andrew.


From peter.levart at gmail.com  Mon Feb 23 18:41:01 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 23 Feb 2015 19:41:01 +0100
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <54EB08A5.4000905@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com> <54E71BC3.30403@oracle.com>
	<54E74E29.2060806@gmail.com> <54EB08A5.4000905@oracle.com>
Message-ID: <54EB743D.4010505@gmail.com>

Hi Chris,

I'm writing a comment. Don't push this just yet. Wait a minute...

Peter

On 02/23/2015 12:01 PM, Chris Hegarty wrote:
> Peter, David, Vitaly,
>
> Can you please take a look at the latest version of this change:
>
> http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/
>
> On 20/02/15 15:09, Peter Levart wrote:
>> ...
>> This looks good now. But I wonder if issuing fences after nested calls
>> to readObject() makes much sense. If cycles are present in a subgraph
>> deserialized by nested call to readObject(), a field pointing back to an
>> object not part of the subgraph stream will point to the object that
>> will not be fully initialized yet, so nested calls to readObject()
>> should not be expected to return a reference to a fully constructed
>> subgraph anyway. Only top-level call is guaranteed to return a fully
>> constructed graph.
>
> Right. I was never convinced of this myself either. Removed. 
> Unnecessary complication.
>
>> If you optimize this and only issue one fence for top-level call to
>> readObject(), tracking of 'requiresFence' (I would call it
>> requiresFreeze to be in line with JMM terminology - the fence is just a
>
> 'requiresFreeze' is better. Updated
>
>> way to achieve freeze) can also be micro-optimized. You currently do it
>> like this:
>>
>> 1900             requiresFence |= slotDesc.hasFinalField();
>>
>> which is a shortcut for:
>>
>> requiresFence = requiresFence | slotDesc.hasFinalField();
>>
>> ...which means that the field is overwritten multiple times
>> unnecessarily and slotDesc.hasFinalField() is called every time. You can
>> write the same logic as:
>>
>> if (!requiresFence && slotDesc.hasFinalField()) {
>>      requiresFence = true;
>> }
>
> ... and it is more readable. Updated.
>
>> There will be at most one write to the field and potentially less calls
>> to slotDesc.hasFinalField().
>
> -Chris.



From Roger.Riggs at Oracle.com  Mon Feb 23 18:50:14 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 23 Feb 2015 13:50:14 -0500
Subject: RFR: 8073394: Clock.systemUTC() should return a constant
In-Reply-To: <54EB663B.70000@oracle.com>
References: <54EB663B.70000@oracle.com>
Message-ID: <54EB7666.2010401@Oracle.com>

Hi Daniel,

Typically, a TestNG DataProvider would have been used to supply the case 
data
instead of an internal Map.

The rest looks fine.

Thanks, Roger

On 2/23/2015 12:41 PM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a small patch for
> 8073394: Clock.systemUTC() should return a constant
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.00/
>
> best regards,
>
> -- daniel



From xueming.shen at oracle.com  Mon Feb 23 19:24:27 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 23 Feb 2015 11:24:27 -0800
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EA3A41.9000309@gmail.com>
References: <54EA3A41.9000309@gmail.com>
Message-ID: <54EB7E6B.60402@oracle.com>

I think I did have a j.time version somewhere when working on JSR310 and measured
the difference of the performance . If my memory serves me correctly one of the issues
back then is that it has an impact to the startup time, because using the JSR310 LDT
and its timezone implementation means to load and initialize LOTS of the java.time
classes and initialize the JSR310 tz data. We did lots of rounds of implementation of
using the JSR310 tzdata for the java.util.TimeZone implementation in jdk8 (so the
JSR310 and j.u.TimeZone share the same tz data) and tried the best to use as less
JSR310 classes as possible to limit the startup "regression".  It's true that it might not
matter if the app is going to use the new JSR310 anyway, but for most of existing
applications, you will see a slowdown of the startup without too much benefit. That
was the consideration back to jdk8, in which the zip/jar was a must for anything to
startup, if it's no longer true for jdk9 module system, then it might no longer be an
concern.

-Sherman

On 02/22/2015 12:21 PM, Peter Levart wrote:
> Hi,
>
> I noticed internal JDK class java.util.zip.ZipUtils uses deprecated java.util.Date API for implementing two methods for converting DOS to Java time and back. I thought I'd try translating them to use new java.time API. Translation was straightforward, but I noticed that new implementations are not on par with speed to old java.util.Date versions. Here's a JMH benchmark implementing those two conversion methods with java.util.Date and java.time.ZonedDateTime APIs:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/ZipUtilsTest.java
>
> The results show the following:
>
> Benchmark                               Mode   Samples Score  Score error    Units
> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt         5 101.890       17.570    ns/op
> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt         5 137.587       13.533    ns/op
> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       67.114       10.382    ns/op
> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt         5 143.739       15.243    ns/op
>
>
> Quick sampling with jvisualvm shows that a substantial time is spent repeatedly obtaining ZoneId.systemDefault() instance. I checked the implementation and came up with the following optimization:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.01/
>
> TimeZone is a mutable object and has to be defensively cloned when TimeZone.getDefault() is invoked. So there's no point in caching a ZoneId instance inside TimeZone instance if we cache it on a clone that is thrown away each time ZoneId.systemDefault() is invoked. I use SharedSecrets to access the uncloned TimeZone.defaultTimeZone instance where caching of ZoneId pays of.
>
> I think that it was never meant to change TimeZone's ID (TimeZone.setID()) after such instance was put into operation (for example installed as default time zone with TimeZone.setDefault()). Such use is unintended and buggy. So I also changed the implementation of TimeZone.setDefault() to save a defensive copy of TimeZone object as default time zone instead of a reference to it.
>
> With this patch, the DOS/Java time conversion benchmark shows an improvement:
>
> Benchmark                               Mode   Samples Score  Score error    Units
> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt 5       97.986       18.379    ns/op
> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt 5       85.010       10.863    ns/op
> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       71.073       25.408    ns/op
> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt 5       95.298       17.620    ns/op
>
>
> Is this patch correct or did I miss something from the internals of java.time API that does not permit such caching?
>
>
> Regards, Peter
>



From Ulf.Zibis at CoSoCo.de  Mon Feb 23 19:32:40 2015
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Mon, 23 Feb 2015 20:32:40 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54EB6DD1.4090803@redhat.com>
References: <54EB6DD1.4090803@redhat.com>
Message-ID: <54EB8058.7080901@CoSoCo.de>

Hi Andrew,

I like this approach very much. Since long time I had a similar idea on my ToDo list.

Thanks,
-Ulf

Am 23.02.2015 um 19:13 schrieb Andrew Haley:
> I've been kicking around a few ideas for Unsafe access methods for
> unaligned access to byte arrays and buffers in order to provide
> "whatever second-best mechanism the platform offers".  These would
> provide the base for fast lexicographic array comparisons, etc.
>
> https://bugs.openjdk.java.net/browse/JDK-8044082
>
> If the platform supports unaligned memory accesses, the implementation
> of {get,put}-X-Unaligned is obvious and trivial for both C1 and C2.
> It gets interesting when we want to provide efficient unaligned
> methods on machines with no hardware support.
>
> We could provide compiler intrinsics which do when we need on such
> machines.  However, I think this wouldn't deliver the best results.
> >From the experiments I've done, the best implementation is to write
> the access methods in Java and allow HotSpot to optimize them.  While
> this seemed a bit counter-intuitive to me, it's best because C2 has
> profile data that it can work on.  In many cases I suspect that data
> read and written from a byte array will be aligned for their type and
> C2 will take advantage of this, relegating the misaligned access to an
> out-of-line code path as appropriate.  Also, these methods have the
> additional benefit that they are always atomic as long as the data are
> naturally aligned.
>
> This does result in rather a lot of code for the methods for all sizes
> and endiannesses, but none of it will be used on machines with
> unaligned hardware support except in the interpreter.  (Perhaps the
> interpreter too could have intrinsics?)
>
> I have changed HeapByteBuffer to use these methods, with a major
> performance improvement.  I've also provided Unsafe methods to query
> endianness and alignment support.
>
> Webrevs at http://cr.openjdk.java.net/~aph/unaligned.hotspot.1/
> http://cr.openjdk.java.net/~aph/unaligned.jdk.1/
>
> Andrew.
>



From scolebourne at joda.org  Mon Feb 23 19:36:27 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 23 Feb 2015 19:36:27 +0000
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EB7E6B.60402@oracle.com>
References: <54EA3A41.9000309@gmail.com> <54EB7E6B.60402@oracle.com>
Message-ID: <CACzrW9A+-XKWgiZ46VUyGRb5RLjL6sRAJqT2TqKmsZhYq0e82w@mail.gmail.com>

Looking at the patch, all that may be needed is to change the type of
the instance variable used for the cache from ZoneId to Object, and
cast where necessary. Adds the cost of the cast to the main flow, but
that is pretty minimal.

Stephen



On 23 February 2015 at 19:24, Xueming Shen <xueming.shen at oracle.com> wrote:
> I think I did have a j.time version somewhere when working on JSR310 and
> measured
> the difference of the performance . If my memory serves me correctly one of
> the issues
> back then is that it has an impact to the startup time, because using the
> JSR310 LDT
> and its timezone implementation means to load and initialize LOTS of the
> java.time
> classes and initialize the JSR310 tz data. We did lots of rounds of
> implementation of
> using the JSR310 tzdata for the java.util.TimeZone implementation in jdk8
> (so the
> JSR310 and j.u.TimeZone share the same tz data) and tried the best to use as
> less
> JSR310 classes as possible to limit the startup "regression".  It's true
> that it might not
> matter if the app is going to use the new JSR310 anyway, but for most of
> existing
> applications, you will see a slowdown of the startup without too much
> benefit. That
> was the consideration back to jdk8, in which the zip/jar was a must for
> anything to
> startup, if it's no longer true for jdk9 module system, then it might no
> longer be an
> concern.
>
> -Sherman
>
>
> On 02/22/2015 12:21 PM, Peter Levart wrote:
>>
>> Hi,
>>
>> I noticed internal JDK class java.util.zip.ZipUtils uses deprecated
>> java.util.Date API for implementing two methods for converting DOS to Java
>> time and back. I thought I'd try translating them to use new java.time API.
>> Translation was straightforward, but I noticed that new implementations are
>> not on par with speed to old java.util.Date versions. Here's a JMH benchmark
>> implementing those two conversion methods with java.util.Date and
>> java.time.ZonedDateTime APIs:
>>
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/ZipUtilsTest.java
>>
>> The results show the following:
>>
>> Benchmark                               Mode   Samples Score  Score error
>> Units
>> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt         5 101.890
>> 17.570    ns/op
>> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt         5 137.587
>> 13.533    ns/op
>> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       67.114       10.382
>> ns/op
>> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt         5 143.739
>> 15.243    ns/op
>>
>>
>> Quick sampling with jvisualvm shows that a substantial time is spent
>> repeatedly obtaining ZoneId.systemDefault() instance. I checked the
>> implementation and came up with the following optimization:
>>
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.01/
>>
>> TimeZone is a mutable object and has to be defensively cloned when
>> TimeZone.getDefault() is invoked. So there's no point in caching a ZoneId
>> instance inside TimeZone instance if we cache it on a clone that is thrown
>> away each time ZoneId.systemDefault() is invoked. I use SharedSecrets to
>> access the uncloned TimeZone.defaultTimeZone instance where caching of
>> ZoneId pays of.
>>
>> I think that it was never meant to change TimeZone's ID (TimeZone.setID())
>> after such instance was put into operation (for example installed as default
>> time zone with TimeZone.setDefault()). Such use is unintended and buggy. So
>> I also changed the implementation of TimeZone.setDefault() to save a
>> defensive copy of TimeZone object as default time zone instead of a
>> reference to it.
>>
>> With this patch, the DOS/Java time conversion benchmark shows an
>> improvement:
>>
>> Benchmark                               Mode   Samples Score  Score error
>> Units
>> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt 5       97.986       18.379
>> ns/op
>> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt 5       85.010       10.863
>> ns/op
>> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       71.073       25.408
>> ns/op
>> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt 5       95.298       17.620
>> ns/op
>>
>>
>> Is this patch correct or did I miss something from the internals of
>> java.time API that does not permit such caching?
>>
>>
>> Regards, Peter
>>
>


From daniel.fuchs at oracle.com  Mon Feb 23 20:02:11 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 23 Feb 2015 21:02:11 +0100
Subject: RFR: 8073394: Clock.systemUTC() should return a constant
In-Reply-To: <54EB7666.2010401@Oracle.com>
References: <54EB663B.70000@oracle.com> <54EB7666.2010401@Oracle.com>
Message-ID: <54EB8743.9000507@oracle.com>

On 23/02/15 19:50, Roger Riggs wrote:
> Hi Daniel,
>
> Typically, a TestNG DataProvider would have been used to supply the case
> data
> instead of an internal Map.

Thanks Roger. I should take some time to learn more about TestNG.

Here is the new webrev:

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

-- daniel

>
> The rest looks fine.
>
> Thanks, Roger
>
> On 2/23/2015 12:41 PM, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a small patch for
>> 8073394: Clock.systemUTC() should return a constant
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.00/
>>
>> best regards,
>>
>> -- daniel
>



From scolebourne at joda.org  Mon Feb 23 20:40:01 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 23 Feb 2015 20:40:01 +0000
Subject: RFR: 8073394: Clock.systemUTC() should return a constant
In-Reply-To: <54EB8743.9000507@oracle.com>
References: <54EB663B.70000@oracle.com> <54EB7666.2010401@Oracle.com>
	<54EB8743.9000507@oracle.com>
Message-ID: <CACzrW9Cz3JcCrgrzX7zwddOrCJ1wpLO2_M=RQOK59p0c396dXA@mail.gmail.com>

The rest of the java.time code tends to put the data provider method
before the test, and mostly uses a naming convention of
"data_systemClocks". Neither of which are particularly important
things.

Stephen


On 23 February 2015 at 20:02, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> On 23/02/15 19:50, Roger Riggs wrote:
>>
>> Hi Daniel,
>>
>> Typically, a TestNG DataProvider would have been used to supply the case
>> data
>> instead of an internal Map.
>
>
> Thanks Roger. I should take some time to learn more about TestNG.
>
> Here is the new webrev:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.01/
>
> -- daniel
>
>
>>
>> The rest looks fine.
>>
>> Thanks, Roger
>>
>> On 2/23/2015 12:41 PM, Daniel Fuchs wrote:
>>>
>>> Hi,
>>>
>>> Please find below a small patch for
>>> 8073394: Clock.systemUTC() should return a constant
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.00/
>>>
>>> best regards,
>>>
>>> -- daniel
>>
>>
>


From peter.levart at gmail.com  Mon Feb 23 21:08:08 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 23 Feb 2015 22:08:08 +0100
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <54EB08A5.4000905@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com> <54E71BC3.30403@oracle.com>
	<54E74E29.2060806@gmail.com> <54EB08A5.4000905@oracle.com>
Message-ID: <54EB96B8.30304@gmail.com>

Hi Chris,

On 02/23/2015 12:01 PM, Chris Hegarty wrote:
> Peter, David, Vitaly,
>
> Can you please take a look at the latest version of this change:
>
> http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/

There are still a couple of issues with this version:

- You are issuing freeze action as soon as any readObject() invocation 
is complete (including nested invocations) when the invocation itself 
has set the requiresFreeze flag, which is cleared when freeze() is 
called, but can be set again for any other nested (sibling, ...) call to 
readObject(). So many freeze(s) can potentialy be issued. This can be 
fixed by checking for (level == 0) condition before calling freeze.

- You are tracking the requiresFreeze flag in readSerialData() method 
for each class slot the deserialized object is composed of. This can be 
optimized and the 'hasFinalField' flag pre-computed for the whole object 
(all slots) and stored in ObjestStreamClass as such.

- We have to be careful with "loosening" of volatile writes to final 
fields in custom readObject() methods (BigDecimal.intCompact for 
example) especialy if they are writes to fields that are not serial 
fields in ObjectStreamClass (either they are transient or not listed in 
serialPersistentFields). By doing that, you are relying on the fact that 
default deserialization (defaultReadObject() call in case of BigDecimal) 
tracks at least one other final field that is also serial field. This is 
the case with BigDecimal and BigInteger, but in general it is not. It 
will be interesting how tracking will be implemented most efficiently 
when FieldAccess API appears, but that's another story...

So I propose the following variant for now (including just 
ObjectInputStream and ObjectStreamClass) that fixes 1st two issues 
above. I suggest waiting with BigDecimal/BigInteger changes until 
FieldAccess API is available and throw away Unsafe usage alltogether at 
that point:

http://cr.openjdk.java.net/~plevart/jdk9-dev/ObjectInputStream.freeze/webrev.01/


Regards, Peter


>
> On 20/02/15 15:09, Peter Levart wrote:
>> ...
>> This looks good now. But I wonder if issuing fences after nested calls
>> to readObject() makes much sense. If cycles are present in a subgraph
>> deserialized by nested call to readObject(), a field pointing back to an
>> object not part of the subgraph stream will point to the object that
>> will not be fully initialized yet, so nested calls to readObject()
>> should not be expected to return a reference to a fully constructed
>> subgraph anyway. Only top-level call is guaranteed to return a fully
>> constructed graph.
>
> Right. I was never convinced of this myself either. Removed. 
> Unnecessary complication.
>
>> If you optimize this and only issue one fence for top-level call to
>> readObject(), tracking of 'requiresFence' (I would call it
>> requiresFreeze to be in line with JMM terminology - the fence is just a
>
> 'requiresFreeze' is better. Updated
>
>> way to achieve freeze) can also be micro-optimized. You currently do it
>> like this:
>>
>> 1900             requiresFence |= slotDesc.hasFinalField();
>>
>> which is a shortcut for:
>>
>> requiresFence = requiresFence | slotDesc.hasFinalField();
>>
>> ...which means that the field is overwritten multiple times
>> unnecessarily and slotDesc.hasFinalField() is called every time. You can
>> write the same logic as:
>>
>> if (!requiresFence && slotDesc.hasFinalField()) {
>>      requiresFence = true;
>> }
>
> ... and it is more readable. Updated.
>
>> There will be at most one write to the field and potentially less calls
>> to slotDesc.hasFinalField().
>
> -Chris.



From peter.levart at gmail.com  Mon Feb 23 21:44:26 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 23 Feb 2015 22:44:26 +0100
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <CACzrW9A+-XKWgiZ46VUyGRb5RLjL6sRAJqT2TqKmsZhYq0e82w@mail.gmail.com>
References: <54EA3A41.9000309@gmail.com> <54EB7E6B.60402@oracle.com>
	<CACzrW9A+-XKWgiZ46VUyGRb5RLjL6sRAJqT2TqKmsZhYq0e82w@mail.gmail.com>
Message-ID: <54EB9F3A.3090105@gmail.com>


On 02/23/2015 08:36 PM, Stephen Colebourne wrote:
> Looking at the patch, all that may be needed is to change the type of
> the instance variable used for the cache from ZoneId to Object, and
> cast where necessary. Adds the cost of the cast to the main flow, but
> that is pretty minimal.
>
> Stephen

Having an instance variable in a class does not trigger loading of the 
class for the type of instance variable just yet.  Try the following 
with -verbose:class and you'll see that only Test.A is loaded...

public class Test {

     static class A {
         B b;

         B toB() {
             if (b == null) {
                 b = new B();
             }
             return b;
         }
     }

     static class B {
     }

     public static void main(String[] args) throws Exception {
         A a = new A();
     }
}


If we're talking about using java.time from ZipEntry, then that's 
another story. I belive that VM startup does not need the conversion 
from DOS time to Java time in ZipEntry, but that should be checked to be 
sure...

Regards, Peter

>
>
> On 23 February 2015 at 19:24, Xueming Shen <xueming.shen at oracle.com> wrote:
>> I think I did have a j.time version somewhere when working on JSR310 and
>> measured
>> the difference of the performance . If my memory serves me correctly one of
>> the issues
>> back then is that it has an impact to the startup time, because using the
>> JSR310 LDT
>> and its timezone implementation means to load and initialize LOTS of the
>> java.time
>> classes and initialize the JSR310 tz data. We did lots of rounds of
>> implementation of
>> using the JSR310 tzdata for the java.util.TimeZone implementation in jdk8
>> (so the
>> JSR310 and j.u.TimeZone share the same tz data) and tried the best to use as
>> less
>> JSR310 classes as possible to limit the startup "regression".  It's true
>> that it might not
>> matter if the app is going to use the new JSR310 anyway, but for most of
>> existing
>> applications, you will see a slowdown of the startup without too much
>> benefit. That
>> was the consideration back to jdk8, in which the zip/jar was a must for
>> anything to
>> startup, if it's no longer true for jdk9 module system, then it might no
>> longer be an
>> concern.
>>
>> -Sherman
>>
>>
>> On 02/22/2015 12:21 PM, Peter Levart wrote:
>>> Hi,
>>>
>>> I noticed internal JDK class java.util.zip.ZipUtils uses deprecated
>>> java.util.Date API for implementing two methods for converting DOS to Java
>>> time and back. I thought I'd try translating them to use new java.time API.
>>> Translation was straightforward, but I noticed that new implementations are
>>> not on par with speed to old java.util.Date versions. Here's a JMH benchmark
>>> implementing those two conversion methods with java.util.Date and
>>> java.time.ZonedDateTime APIs:
>>>
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/ZipUtilsTest.java
>>>
>>> The results show the following:
>>>
>>> Benchmark                               Mode   Samples Score  Score error
>>> Units
>>> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt         5 101.890
>>> 17.570    ns/op
>>> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt         5 137.587
>>> 13.533    ns/op
>>> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       67.114       10.382
>>> ns/op
>>> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt         5 143.739
>>> 15.243    ns/op
>>>
>>>
>>> Quick sampling with jvisualvm shows that a substantial time is spent
>>> repeatedly obtaining ZoneId.systemDefault() instance. I checked the
>>> implementation and came up with the following optimization:
>>>
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.01/
>>>
>>> TimeZone is a mutable object and has to be defensively cloned when
>>> TimeZone.getDefault() is invoked. So there's no point in caching a ZoneId
>>> instance inside TimeZone instance if we cache it on a clone that is thrown
>>> away each time ZoneId.systemDefault() is invoked. I use SharedSecrets to
>>> access the uncloned TimeZone.defaultTimeZone instance where caching of
>>> ZoneId pays of.
>>>
>>> I think that it was never meant to change TimeZone's ID (TimeZone.setID())
>>> after such instance was put into operation (for example installed as default
>>> time zone with TimeZone.setDefault()). Such use is unintended and buggy. So
>>> I also changed the implementation of TimeZone.setDefault() to save a
>>> defensive copy of TimeZone object as default time zone instead of a
>>> reference to it.
>>>
>>> With this patch, the DOS/Java time conversion benchmark shows an
>>> improvement:
>>>
>>> Benchmark                               Mode   Samples Score  Score error
>>> Units
>>> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt 5       97.986       18.379
>>> ns/op
>>> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt 5       85.010       10.863
>>> ns/op
>>> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       71.073       25.408
>>> ns/op
>>> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt 5       95.298       17.620
>>> ns/op
>>>
>>>
>>> Is this patch correct or did I miss something from the internals of
>>> java.time API that does not permit such caching?
>>>
>>>
>>> Regards, Peter
>>>



From xueming.shen at oracle.com  Mon Feb 23 21:55:51 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 23 Feb 2015 13:55:51 -0800
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EB9F3A.3090105@gmail.com>
References: <54EA3A41.9000309@gmail.com>
	<54EB7E6B.60402@oracle.com>	<CACzrW9A+-XKWgiZ46VUyGRb5RLjL6sRAJqT2TqKmsZhYq0e82w@mail.gmail.com>
	<54EB9F3A.3090105@gmail.com>
Message-ID: <54EBA1E7.7080701@oracle.com>

On 02/23/2015 01:44 PM, Peter Levart wrote:
>
> On 02/23/2015 08:36 PM, Stephen Colebourne wrote:
>> Looking at the patch, all that may be needed is to change the type of
>> the instance variable used for the cache from ZoneId to Object, and
>> cast where necessary. Adds the cost of the cast to the main flow, but
>> that is pretty minimal.
>>
>> Stephen
>
> Having an instance variable in a class does not trigger loading of the class for the type of instance variable just yet.  Try the following with -verbose:class and you'll see that only Test.A is loaded...
>
> public class Test {
>
>     static class A {
>         B b;
>
>         B toB() {
>             if (b == null) {
>                 b = new B();
>             }
>             return b;
>         }
>     }
>
>     static class B {
>     }
>
>     public static void main(String[] args) throws Exception {
>         A a = new A();
>     }
> }
>
>
> If we're talking about using java.time from ZipEntry, then that's another story. I belive that VM startup does not need the conversion from DOS time to Java time in ZipEntry, but that should be checked to be sure...

I was talking about to use j.time for the dos<-> conversion, I would assume that
was the original optimization you were talking about. With Claes's change, it is
possible the j.u.zip code no longer needs to the dos->java time conversion during
startup.  The dos timestamp in Zip spec is indeed a j.time.LocalDateTime.


>
> Regards, Peter
>
>>
>>
>> On 23 February 2015 at 19:24, Xueming Shen <xueming.shen at oracle.com> wrote:
>>> I think I did have a j.time version somewhere when working on JSR310 and
>>> measured
>>> the difference of the performance . If my memory serves me correctly one of
>>> the issues
>>> back then is that it has an impact to the startup time, because using the
>>> JSR310 LDT
>>> and its timezone implementation means to load and initialize LOTS of the
>>> java.time
>>> classes and initialize the JSR310 tz data. We did lots of rounds of
>>> implementation of
>>> using the JSR310 tzdata for the java.util.TimeZone implementation in jdk8
>>> (so the
>>> JSR310 and j.u.TimeZone share the same tz data) and tried the best to use as
>>> less
>>> JSR310 classes as possible to limit the startup "regression".  It's true
>>> that it might not
>>> matter if the app is going to use the new JSR310 anyway, but for most of
>>> existing
>>> applications, you will see a slowdown of the startup without too much
>>> benefit. That
>>> was the consideration back to jdk8, in which the zip/jar was a must for
>>> anything to
>>> startup, if it's no longer true for jdk9 module system, then it might no
>>> longer be an
>>> concern.
>>>
>>> -Sherman
>>>
>>>
>>> On 02/22/2015 12:21 PM, Peter Levart wrote:
>>>> Hi,
>>>>
>>>> I noticed internal JDK class java.util.zip.ZipUtils uses deprecated
>>>> java.util.Date API for implementing two methods for converting DOS to Java
>>>> time and back. I thought I'd try translating them to use new java.time API.
>>>> Translation was straightforward, but I noticed that new implementations are
>>>> not on par with speed to old java.util.Date versions. Here's a JMH benchmark
>>>> implementing those two conversion methods with java.util.Date and
>>>> java.time.ZonedDateTime APIs:
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/ZipUtilsTest.java
>>>>
>>>> The results show the following:
>>>>
>>>> Benchmark                               Mode   Samples Score  Score error
>>>> Units
>>>> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt         5 101.890
>>>> 17.570    ns/op
>>>> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt         5 137.587
>>>> 13.533    ns/op
>>>> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       67.114       10.382
>>>> ns/op
>>>> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt         5 143.739
>>>> 15.243    ns/op
>>>>
>>>>
>>>> Quick sampling with jvisualvm shows that a substantial time is spent
>>>> repeatedly obtaining ZoneId.systemDefault() instance. I checked the
>>>> implementation and came up with the following optimization:
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.01/
>>>>
>>>> TimeZone is a mutable object and has to be defensively cloned when
>>>> TimeZone.getDefault() is invoked. So there's no point in caching a ZoneId
>>>> instance inside TimeZone instance if we cache it on a clone that is thrown
>>>> away each time ZoneId.systemDefault() is invoked. I use SharedSecrets to
>>>> access the uncloned TimeZone.defaultTimeZone instance where caching of
>>>> ZoneId pays of.
>>>>
>>>> I think that it was never meant to change TimeZone's ID (TimeZone.setID())
>>>> after such instance was put into operation (for example installed as default
>>>> time zone with TimeZone.setDefault()). Such use is unintended and buggy. So
>>>> I also changed the implementation of TimeZone.setDefault() to save a
>>>> defensive copy of TimeZone object as default time zone instead of a
>>>> reference to it.
>>>>
>>>> With this patch, the DOS/Java time conversion benchmark shows an
>>>> improvement:
>>>>
>>>> Benchmark                               Mode   Samples Score  Score error
>>>> Units
>>>> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt 5       97.986       18.379
>>>> ns/op
>>>> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt 5       85.010       10.863
>>>> ns/op
>>>> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       71.073       25.408
>>>> ns/op
>>>> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt 5       95.298       17.620
>>>> ns/op
>>>>
>>>>
>>>> Is this patch correct or did I miss something from the internals of
>>>> java.time API that does not permit such caching?
>>>>
>>>>
>>>> Regards, Peter
>>>>
>



From peter.levart at gmail.com  Mon Feb 23 21:58:29 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 23 Feb 2015 22:58:29 +0100
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EBA1E7.7080701@oracle.com>
References: <54EA3A41.9000309@gmail.com>	<54EB7E6B.60402@oracle.com>	<CACzrW9A+-XKWgiZ46VUyGRb5RLjL6sRAJqT2TqKmsZhYq0e82w@mail.gmail.com>	<54EB9F3A.3090105@gmail.com>
	<54EBA1E7.7080701@oracle.com>
Message-ID: <54EBA285.5000108@gmail.com>


On 02/23/2015 10:55 PM, Xueming Shen wrote:
>> If we're talking about using java.time from ZipEntry, then that's 
>> another story. I belive that VM startup does not need the conversion 
>> from DOS time to Java time in ZipEntry, but that should be checked to 
>> be sure...
>
> I was talking about to use j.time for the dos<-> conversion, I would 
> assume that
> was the original optimization you were talking about. With Claes's 
> change, it is
> possible the j.u.zip code no longer needs to the dos->java time 
> conversion during
> startup.  The dos timestamp in Zip spec is indeed a j.time.LocalDateTime.

You're right. I'm thinking of new proposed code which does lazy DOS -> 
Java conversion. Previously (or currently, to be precise), constructing 
ZipEntry already triggered conversion.

Peter



From kumar.x.srinivasan at oracle.com  Mon Feb 23 22:14:48 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 23 Feb 2015 14:14:48 -0800
Subject: Please review: 8066185: VM crashed with SIGSEGV
	VirtualMemoryTracker::add_reserved_region
Message-ID: <54EBA658.6020001@oracle.com>

Hello,

Please review the fix for the above issue.

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

The fix is self explanatory, as for the test I have done the following:
a. refactored it from a single longish test to sub-tests for readability.
b. added new sub-test for NMT Argument Processing checks.

Thanks
Kumar



From peter.levart at gmail.com  Mon Feb 23 22:27:59 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 23 Feb 2015 23:27:59 +0100
Subject: RFR: 8073394: Clock.systemUTC() should return a constant
In-Reply-To: <54EB663B.70000@oracle.com>
References: <54EB663B.70000@oracle.com>
Message-ID: <54EBA96F.9060708@gmail.com>

Hi Daniel,

On 02/23/2015 06:41 PM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a small patch for
> 8073394: Clock.systemUTC() should return a constant
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.00/
>
> best regards,
>
> -- daniel


What about the following idea:

- create a (maybe still package-private) instance method 
ZoneId.getSystemClock() and cache the per-ZoneId Clock instance inside 
the ZoneId.
- Clock.system(ZoneId) static method is then just delegating to 
ZoneId.getSystemClock().
- Similarly Clock.systemDefaultZone() can just return 
ZoneId.defaultSystem().getSystemClock().
- Similarly Clock.systemUTC() can just return 
ZoneOffset.UTC.getSystemClock().

Or do we just want to cache systemUTC() Clock here?

Peter



From david.holmes at oracle.com  Mon Feb 23 22:31:23 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Feb 2015 08:31:23 +1000
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <54EB96B8.30304@gmail.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com> <54E71BC3.30403@oracle.com>
	<54E74E29.2060806@gmail.com> <54EB08A5.4000905@oracle.com>
	<54EB96B8.30304@gmail.com>
Message-ID: <54EBAA3B.3080308@oracle.com>

On 24/02/2015 7:08 AM, Peter Levart wrote:
> Hi Chris,
>
> On 02/23/2015 12:01 PM, Chris Hegarty wrote:
>> Peter, David, Vitaly,
>>
>> Can you please take a look at the latest version of this change:
>>
>> http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/
>
> There are still a couple of issues with this version:
>
> - You are issuing freeze action as soon as any readObject() invocation
> is complete (including nested invocations) when the invocation itself
> has set the requiresFreeze flag, which is cleared when freeze() is
> called, but can be set again for any other nested (sibling, ...) call to
> readObject(). So many freeze(s) can potentialy be issued. This can be
> fixed by checking for (level == 0) condition before calling freeze.
>
> - You are tracking the requiresFreeze flag in readSerialData() method
> for each class slot the deserialized object is composed of. This can be
> optimized and the 'hasFinalField' flag pre-computed for the whole object
> (all slots) and stored in ObjestStreamClass as such.
>
> - We have to be careful with "loosening" of volatile writes to final
> fields in custom readObject() methods (BigDecimal.intCompact for
> example) especialy if they are writes to fields that are not serial
> fields in ObjectStreamClass (either they are transient or not listed in
> serialPersistentFields). By doing that, you are relying on the fact that
> default deserialization (defaultReadObject() call in case of BigDecimal)
> tracks at least one other final field that is also serial field. This is
> the case with BigDecimal and BigInteger, but in general it is not. It
> will be interesting how tracking will be implemented most efficiently
> when FieldAccess API appears, but that's another story...
>
> So I propose the following variant for now (including just
> ObjectInputStream and ObjectStreamClass) that fixes 1st two issues
> above. I suggest waiting with BigDecimal/BigInteger changes until
> FieldAccess API is available and throw away Unsafe usage alltogether at
> that point:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ObjectInputStream.freeze/webrev.01/

1183             hasFinal |= d.fieldRefl.hasFinal();

Didn't you suggest not using this form previously due to its inefficiency.

David


>
> Regards, Peter
>
>
>>
>> On 20/02/15 15:09, Peter Levart wrote:
>>> ...
>>> This looks good now. But I wonder if issuing fences after nested calls
>>> to readObject() makes much sense. If cycles are present in a subgraph
>>> deserialized by nested call to readObject(), a field pointing back to an
>>> object not part of the subgraph stream will point to the object that
>>> will not be fully initialized yet, so nested calls to readObject()
>>> should not be expected to return a reference to a fully constructed
>>> subgraph anyway. Only top-level call is guaranteed to return a fully
>>> constructed graph.
>>
>> Right. I was never convinced of this myself either. Removed.
>> Unnecessary complication.
>>
>>> If you optimize this and only issue one fence for top-level call to
>>> readObject(), tracking of 'requiresFence' (I would call it
>>> requiresFreeze to be in line with JMM terminology - the fence is just a
>>
>> 'requiresFreeze' is better. Updated
>>
>>> way to achieve freeze) can also be micro-optimized. You currently do it
>>> like this:
>>>
>>> 1900             requiresFence |= slotDesc.hasFinalField();
>>>
>>> which is a shortcut for:
>>>
>>> requiresFence = requiresFence | slotDesc.hasFinalField();
>>>
>>> ...which means that the field is overwritten multiple times
>>> unnecessarily and slotDesc.hasFinalField() is called every time. You can
>>> write the same logic as:
>>>
>>> if (!requiresFence && slotDesc.hasFinalField()) {
>>>      requiresFence = true;
>>> }
>>
>> ... and it is more readable. Updated.
>>
>>> There will be at most one write to the field and potentially less calls
>>> to slotDesc.hasFinalField().
>>
>> -Chris.
>


From claes.redestad at oracle.com  Mon Feb 23 23:15:18 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 24 Feb 2015 00:15:18 +0100
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EBA285.5000108@gmail.com>
References: <54EA3A41.9000309@gmail.com>	<54EB7E6B.60402@oracle.com>	<CACzrW9A+-XKWgiZ46VUyGRb5RLjL6sRAJqT2TqKmsZhYq0e82w@mail.gmail.com>	<54EB9F3A.3090105@gmail.com>	<54EBA1E7.7080701@oracle.com>
	<54EBA285.5000108@gmail.com>
Message-ID: <54EBB486.1070709@oracle.com>


On 2015-02-23 22:58, Peter Levart wrote:
>
> On 02/23/2015 10:55 PM, Xueming Shen wrote:
>>> If we're talking about using java.time from ZipEntry, then that's 
>>> another story. I belive that VM startup does not need the conversion 
>>> from DOS time to Java time in ZipEntry, but that should be checked 
>>> to be sure...
>>
>> I was talking about to use j.time for the dos<-> conversion, I would 
>> assume that
>> was the original optimization you were talking about. With Claes's 
>> change, it is
>> possible the j.u.zip code no longer needs to the dos->java time 
>> conversion during
>> startup.  The dos timestamp in Zip spec is indeed a 
>> j.time.LocalDateTime.
>
> You're right. I'm thinking of new proposed code which does lazy DOS -> 
> Java conversion. Previously (or currently, to be precise), 
> constructing ZipEntry already triggered conversion.
>
> Peter
>

Testing using both a "Hello world"-style application and some slightly 
more realistic applications, I can verify that the j.u.zip.ZipUtils 
class does not get loaded during VM startup with my patch for 8073497 
applied. Further applying Peter's patch to cache ZoneId's in 
j.u.TimeZone on top of that does not add any java.time classes, even 
when java.util.TimeZone is loaded (the new 
sun.misc.JavaUtilTimeZoneAccess class gets loaded in these scenarios, 
though).

/Claes


From kumar.x.srinivasan at oracle.com  Tue Feb 24 00:32:37 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 23 Feb 2015 16:32:37 -0800
Subject: [9] RFR of 8073187: Unexpected side effect in Pack200
In-Reply-To: <54E6DFF2.6030405@oracle.com>
References: <54E6DB0D.8020804@oracle.com> <54E6DFF2.6030405@oracle.com>
Message-ID: <54EBC6A5.7030205@oracle.com>

I reject this. Not enough justification.

Kumar

On 2/19/2015 11:19 PM, mikhail cherkasov wrote:
> Sorry, I sent link to the old webrev, this is correct one:
>
> http://cr.openjdk.java.net/~mcherkas/8073187/webrev.01/src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java.udiff.html 
>
>
> On 2/20/2015 9:58 AM, mikhail cherkasov wrote:
>> Hi all,
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073187
>>
>> The problem is that packer 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 instance:
>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a159e5358e25/src/java.base/share/classes/java/util/jar/Pack200.java#l149 
>>
>>
>> The fix isn't perfect but it the only possible solution:
>> 1. first packer saves default time zone
>> 2. the last set it back.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mcherkas/8073187/webrev/src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java.udiff.html 
>>
>>
>> Thanks,
>> Mikhail.
>>
>>
>



From mandy.chung at oracle.com  Tue Feb 24 00:49:36 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 23 Feb 2015 16:49:36 -0800
Subject: Review Request for 8073696: Remove redundant import from
	javax/rmi/CORBA/GetORBPropertiesFileAction.java
Message-ID: <54EBCAA0.5090605@oracle.com>

diff --git 
a/src/java.corba/share/classes/javax/rmi/CORBA/GetORBPropertiesFileAction.java 
b/src/java.corba/share/classes/javax/rmi/CORBA/GetORBPropertiesFileAction.java
--- 
a/src/java.corba/share/classes/javax/rmi/CORBA/GetORBPropertiesFileAction.java
+++ 
b/src/java.corba/share/classes/javax/rmi/CORBA/GetORBPropertiesFileAction.java
@@ -43,7 +43,6 @@

  import java.security.AccessController;
  import java.security.PrivilegedAction;
-import sun.security.action.GetPropertyAction;
  import java.util.Properties;

  class GetORBPropertiesFileAction implements PrivilegedAction {

Mandy


From mandy.chung at oracle.com  Tue Feb 24 00:58:40 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 23 Feb 2015 16:58:40 -0800
Subject: Review Request for 8073696: Remove redundant import from
	javax/rmi/CORBA/GetORBPropertiesFileAction.java
In-Reply-To: <54EBCAA0.5090605@oracle.com>
References: <54EBCAA0.5090605@oracle.com>
Message-ID: <54EBCCC0.2000406@oracle.com>

In fact, find another redundant in jdk.httpserver.   I have updated the 
synopsis of JDK-8073696 to remove redundant imports in java.corba and 
jdk.httpserver

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8073696/webrev.00/

Mandy





From david.holmes at oracle.com  Tue Feb 24 01:32:03 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Feb 2015 11:32:03 +1000
Subject: ConcurrentModificationException in java.util.ServiceLoader (not
	a multi-thread issue)
In-Reply-To: <54EB372B.401@geomatys.fr>
References: <54EB372B.401@geomatys.fr>
Message-ID: <54EBD493.7000001@oracle.com>

On 24/02/2015 12:20 AM, Martin Desruisseaux wrote:
> Hello all
>
> java.util.ServiceLoader does not seem to support usage of a second
> Iterator in the middle of a previous iteration.

Nope it doesn't. At a minimum this should be documented. The distinct 
Iterator instances returned by iterator() share the same lazy-lookup 
iterator.

David
-----

  The attached Java file
> provides two simple tests with a ServiceLoader iterating over two
> elements. The first test creates two iterators and invokes their
> hasNext() / next() methods in the following order:
>
>    * Iterator 1
>    * Iterator 2
>    * Iterator 1
>    * Iterator 2  -  unexpected end of iteration here.
>
> The second test creates two iterators and invoke the hasNext() methods
> on both iterators before to invoke their next() methods. This result is
> the following exception (tested on 1.8.0_31-b13):
>
>      Exception in thread "main" java.util.ConcurrentModificationException
>      	at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711)
>      	at java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:744)
>      	at java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:742)
>      	at java.util.ServiceLoader$1.next(ServiceLoader.java:479)
>      	at test.ServiceLoaderTest.test2(ServiceLoaderTest.java:47)
>      	at test.ServiceLoaderTest.main(ServiceLoaderTest.java:12)
>
> (note: to run the test, the attached test.ServiceLoaderTest file needs
> to be in the META-INF/services/ directory). I found a Stackoverflow
> thread mentioning this issue 4 years ago [1], but apparently without
> solution. Should I look for a patch, or is the current behaviour
> considered okay (in which case I would suggest to warn the users in the
> Javadoc)?
>
>
>      Martin
>
>
> [1] http://stackoverflow.com/questions/2593777/serviceloader-double-iterator-issues
>
>


From david.holmes at oracle.com  Tue Feb 24 02:09:47 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Feb 2015 12:09:47 +1000
Subject: Please review: 8066185: VM crashed with SIGSEGV
	VirtualMemoryTracker::add_reserved_region
In-Reply-To: <54EBA658.6020001@oracle.com>
References: <54EBA658.6020001@oracle.com>
Message-ID: <54EBDD6B.5070404@oracle.com>

Hi Kumar,

On 24/02/2015 8:14 AM, Kumar Srinivasan wrote:
> Hello,
>
> Please review the fix for the above issue.
>
> Webrev:
> http://cr.openjdk.java.net/~ksrini/8066185/webrev.00/
>
> The fix is self explanatory, as for the test I have done the following:

I found the comment:

           /*
+          * Since this is a VM flag, we need to ensure it is not an
+          * application argument, meaning the argument must precede
+          * the main class or those flags that invoke the VM directly.
+          */

a bit confusing - specifically the "or those flags that invoke the VM 
directly". Took me while to realize that all the args you treat 
specially (-version, -h, -jar etc) are all "terminal" arguments - either 
the launcher stops looking at args after the given arg, or all following 
args must be for the application, not the launcher or VM. I would have 
expressed this as:

   /*
    * Since this must be a VM flag we stop processing once we see
    * an argument the launcher would not have processed beyond (such
    * as -version or -h), or an argument that indicates the following
    * arguments are for the application (i.e. the main class name, or
    * the -jar argument).
    */


> a. refactored it from a single longish test to sub-tests for readability.
> b. added new sub-test for NMT Argument Processing checks.

Can you please update the @summary for that test. It seems the OSX 
specific test was hijacked for NMT arg testing and the summary was never 
updated to reflect that.

Thanks,
David

> Thanks
> Kumar
>


From david.holmes at oracle.com  Tue Feb 24 02:23:52 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Feb 2015 12:23:52 +1000
Subject: RFR(S): JDK-8073584 Native compilation warning in unpack code
In-Reply-To: <54EB330F.1090503@oracle.com>
References: <54E77CA2.3090304@oracle.com> <54EA8B75.5040406@oracle.com>
	<54EB330F.1090503@oracle.com>
Message-ID: <54EBE0B8.80804@oracle.com>

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 masayoshi.okutsu at oracle.com  Tue Feb 24 04:35:00 2015
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 24 Feb 2015 13:35:00 +0900
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EA3A41.9000309@gmail.com>
References: <54EA3A41.9000309@gmail.com>
Message-ID: <54EBFF74.4080900@oracle.com>

On 2/23/2015 5:21 AM, Peter Levart wrote:
> I think that it was never meant to change TimeZone's ID 
> (TimeZone.setID()) after such instance was put into operation (for 
> example installed as default time zone with TimeZone.setDefault()). 
> Such use is unintended and buggy. So I also changed the implementation 
> of TimeZone.setDefault() to save a defensive copy of TimeZone object 
> as default time zone instead of a reference to it.

In TimeZone.setDefault() null needs to be checked if you want to create 
a defensive copy. (The method allows for null.)

Masayoshi



From peter.levart at gmail.com  Tue Feb 24 07:18:07 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 24 Feb 2015 08:18:07 +0100
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EBFF74.4080900@oracle.com>
References: <54EA3A41.9000309@gmail.com> <54EBFF74.4080900@oracle.com>
Message-ID: <54EC25AF.8050006@gmail.com>


On 02/24/2015 05:35 AM, Masayoshi Okutsu wrote:
> On 2/23/2015 5:21 AM, Peter Levart wrote:
>> I think that it was never meant to change TimeZone's ID 
>> (TimeZone.setID()) after such instance was put into operation (for 
>> example installed as default time zone with TimeZone.setDefault()). 
>> Such use is unintended and buggy. So I also changed the 
>> implementation of TimeZone.setDefault() to save a defensive copy of 
>> TimeZone object as default time zone instead of a reference to it.
>
> In TimeZone.setDefault() null needs to be checked if you want to 
> create a defensive copy. (The method allows for null.)
>
> Masayoshi
>

Thanks for pointing that out.

Regards, Peter


From peter.levart at gmail.com  Tue Feb 24 07:43:37 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 24 Feb 2015 08:43:37 +0100
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <54EBAA3B.3080308@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com> <54E71BC3.30403@oracle.com>
	<54E74E29.2060806@gmail.com> <54EB08A5.4000905@oracle.com>
	<54EB96B8.30304@gmail.com> <54EBAA3B.3080308@oracle.com>
Message-ID: <54EC2BA9.7050606@gmail.com>


On 02/23/2015 11:31 PM, David Holmes wrote:
>> So I propose the following variant for now (including just
>> ObjectInputStream and ObjectStreamClass) that fixes 1st two issues
>> above. I suggest waiting with BigDecimal/BigInteger changes until
>> FieldAccess API is available and throw away Unsafe usage alltogether at
>> that point:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ObjectInputStream.freeze/webrev.01/ 
>>
>
> 1183             hasFinal |= d.fieldRefl.hasFinal();
>
> Didn't you suggest not using this form previously due to its 
> inefficiency.
>
> David 

Yes, in case the writes are to a field (main memory) vs. locals 
(registers typically) and when on hot-path. Here the 'hasFinal' is a 
local and not on hot-path (the result of getClassDataLayout0() is cached 
in ObjectStreamClass) so the optimization is not so important.

We would like to minimize the overhead of tracking whether 
deserialization has set any final field in object graph as much as 
possible or else it will be higher than placing the freeze fence 
unconditionally. At some point (depending on the size of deserialized 
stream) the overhead of tracking will be higher than redundant placement 
of freeze fence, but this point should be moved as high as possible. We 
should measure this. Perhaps the tracking is not needed even for the 
smallest streams.

Regards, Peter



From Alan.Bateman at oracle.com  Tue Feb 24 08:09:14 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Feb 2015 08:09:14 +0000
Subject: ConcurrentModificationException in java.util.ServiceLoader (not
	a multi-thread issue)
In-Reply-To: <54EBD493.7000001@oracle.com>
References: <54EB372B.401@geomatys.fr> <54EBD493.7000001@oracle.com>
Message-ID: <54EC31AA.6050300@oracle.com>

On 24/02/2015 01:32, David Holmes wrote:
> On 24/02/2015 12:20 AM, Martin Desruisseaux wrote:
>> Hello all
>>
>> java.util.ServiceLoader does not seem to support usage of a second
>> Iterator in the middle of a previous iteration.
>
> Nope it doesn't. At a minimum this should be documented. The distinct 
> Iterator instances returned by iterator() share the same lazy-lookup 
> iterator.
>
Right, it has never supported multiple iterators but as it's an Iterable 
then it should unless specified otherwise. So I think this is a bug 
(although one could argue that the usage is unusual, almost a mis-use). 
Not clear whether it's worth doing anything about it now, this is 
because ServiceLoader is going to change very significantly soon when it 
is re-specified to work with modules. I'll create a bug anyway to track 
it anyway.

-Alan.


From Alan.Bateman at oracle.com  Tue Feb 24 08:14:11 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Feb 2015 08:14:11 +0000
Subject: Review Request for 8073696: Remove redundant import from
	javax/rmi/CORBA/GetORBPropertiesFileAction.java
In-Reply-To: <54EBCCC0.2000406@oracle.com>
References: <54EBCAA0.5090605@oracle.com> <54EBCCC0.2000406@oracle.com>
Message-ID: <54EC32D3.1060304@oracle.com>

On 24/02/2015 00:58, Mandy Chung wrote:
> In fact, find another redundant in jdk.httpserver.   I have updated 
> the synopsis of JDK-8073696 to remove redundant imports in java.corba 
> and jdk.httpserver
>
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8073696/webrev.00/
>
> Mandy
>
Looks okay to me.

-Alan


From paul.sandoz at oracle.com  Tue Feb 24 08:47:27 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 24 Feb 2015 09:47:27 +0100
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <54EB96B8.30304@gmail.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com> <54E71BC3.30403@oracle.com>
	<54E74E29.2060806@gmail.com> <54EB08A5.4000905@oracle.com>
	<54EB96B8.30304@gmail.com>
Message-ID: <B88BC546-931E-4F85-AFB9-639B906D8D7D@oracle.com>

On Feb 23, 2015, at 10:08 PM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> - We have to be careful with "loosening" of volatile writes to final fields in custom readObject() methods (BigDecimal.intCompact for example) especialy if they are writes to fields that are not serial fields in ObjectStreamClass (either they are transient or not listed in serialPersistentFields). By doing that, you are relying on the fact that default deserialization (defaultReadObject() call in case of BigDecimal) tracks at least one other final field that is also serial field.

Yes, but i would presume that the reasons for using volatile writes is almost always to stamp in the required barrier?


> This is the case with BigDecimal and BigInteger, but in general it is not. It will be interesting how tracking will be implemented most efficiently when FieldAccess API appears, but that's another story...
> 

> So I propose the following variant for now (including just ObjectInputStream and ObjectStreamClass) that fixes 1st two issues above. I suggest waiting with BigDecimal/BigInteger changes until FieldAccess API is available and throw away Unsafe usage alltogether at that point:
> 

Why wait? These are simple and beneficial changes, and can be revisited if/when a new API is available.

--

Actually... given the performance analysis Alexey did on "All fields are final" [1], we might be able to get away with always stamping in the barrier (and we could expose another method in Unsafe if necessary just to do the storestore). We at least need to revisit if the JMM is revised to this effect.

Paul.

[1] http://shipilev.net/blog/2014/all-fields-are-final/


From scolebourne at joda.org  Tue Feb 24 09:00:06 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 24 Feb 2015 09:00:06 +0000
Subject: RFR: 8073394: Clock.systemUTC() should return a constant
In-Reply-To: <54EBA96F.9060708@gmail.com>
References: <54EB663B.70000@oracle.com> <54EBA96F.9060708@gmail.com>
Message-ID: <CACzrW9AjU+CdhnxUTWRHA5Sz9W503LmWWmE0Hy2d9qsnrDdZcw@mail.gmail.com>

On 23 February 2015 at 22:27, Peter Levart <peter.levart at gmail.com> wrote:
> What about the following idea:
>
> - create a (maybe still package-private) instance method
> ZoneId.getSystemClock() and cache the per-ZoneId Clock instance inside the
> ZoneId.
> - Clock.system(ZoneId) static method is then just delegating to
> ZoneId.getSystemClock().
> - Similarly Clock.systemDefaultZone() can just return
> ZoneId.defaultSystem().getSystemClock().
> - Similarly Clock.systemUTC() can just return
> ZoneOffset.UTC.getSystemClock().
>
> Or do we just want to cache systemUTC() Clock here?

I suspect that the above would be a good optimisation, though perhaps
a separate issue?

Stephen


From chris.hegarty at oracle.com  Tue Feb 24 09:24:25 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 24 Feb 2015 09:24:25 +0000
Subject: Review Request for 8073696: Remove redundant import from
	javax/rmi/CORBA/GetORBPropertiesFileAction.java
In-Reply-To: <54EBCCC0.2000406@oracle.com>
References: <54EBCAA0.5090605@oracle.com> <54EBCCC0.2000406@oracle.com>
Message-ID: <9F9D969C-9EF4-47D4-8999-EFF2B612E9FC@oracle.com>


On 24 Feb 2015, at 00:58, Mandy Chung <mandy.chung at oracle.com> wrote:

> In fact, find another redundant in jdk.httpserver.   I have updated the synopsis of JDK-8073696 to remove redundant imports in java.corba and jdk.httpserver
> 
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8073696/webrev.00/

Looks good to me.

-Chris.

> Mandy



From martin.desruisseaux at geomatys.fr  Tue Feb 24 09:32:36 2015
From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux)
Date: Tue, 24 Feb 2015 10:32:36 +0100
Subject: ConcurrentModificationException in java.util.ServiceLoader (not
	a multi-thread issue)
In-Reply-To: <54EC31AA.6050300@oracle.com>
References: <54EB372B.401@geomatys.fr> <54EBD493.7000001@oracle.com>
	<54EC31AA.6050300@oracle.com>
Message-ID: <54EC4534.5020909@geomatys.fr>

Le 24/02/15 09:09, Alan Bateman a ?crit :

> Right, it has never supported multiple iterators but as it's an
> Iterable then it should unless specified otherwise. So I think this is
> a bug (although one could argue that the usage is unusual, almost a
> mis-use).

One use case is that in a multi-thread environment, this bug implies
that it is not sufficient to synchronize all direct and indirect
(through Iterator) usages of ServiceLoader. We must synchronize the
entire iteration loop for preventing other threads to start a new
iteration before we finished the current one. This can be annoying if
the work to do between two calls to Iterator.hasNext() / next() is long.
Sometime it is not possible to synchronize the entire loop if we do not
control the iteration (i.e. if we advance in the iterator only when the
user invokes some method). The later case can be a problem even in
mono-thread application.


> Not clear whether it's worth doing anything about it now, this is
> because ServiceLoader is going to change very significantly soon when
> it is re-specified to work with modules. I'll create a bug anyway to
> track it anyway.

Thanks. The fact that ServiceLoader was going to be modified for Jigsaw
is precisely the reason why I was wondering if it was worth to
investigate more now.

    Martin




From Alan.Bateman at oracle.com  Tue Feb 24 09:44:33 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Feb 2015 09:44:33 +0000
Subject: ConcurrentModificationException in java.util.ServiceLoader (not
	a multi-thread issue)
In-Reply-To: <54EC4534.5020909@geomatys.fr>
References: <54EB372B.401@geomatys.fr> <54EBD493.7000001@oracle.com>
	<54EC31AA.6050300@oracle.com> <54EC4534.5020909@geomatys.fr>
Message-ID: <54EC4801.7080607@oracle.com>

On 24/02/2015 09:32, Martin Desruisseaux wrote:
> :
> One use case is that in a multi-thread environment, this bug implies
> that it is not sufficient to synchronize all direct and indirect
> (through Iterator) usages of ServiceLoader. We must synchronize the
> entire iteration loop for preventing other threads to start a new
> iteration before we finished the current one. This can be annoying if
> the work to do between two calls to Iterator.hasNext() / next() is long.
> Sometime it is not possible to synchronize the entire loop if we do not
> control the iteration (i.e. if we advance in the iterator only when the
> user invokes some method). The later case can be a problem even in
> mono-thread application.
True although I don't think it's ever come up before (at least I can't 
find any bugs/reports on this). It's good to bring it now. I do think 
that ServiceLoader will be most replaced in JDK 9 anyway.

-Alan


From daniel.fuchs at oracle.com  Tue Feb 24 10:16:45 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 24 Feb 2015 11:16:45 +0100
Subject: RFR: 8073394: Clock.systemUTC() should return a constant
In-Reply-To: <CACzrW9AjU+CdhnxUTWRHA5Sz9W503LmWWmE0Hy2d9qsnrDdZcw@mail.gmail.com>
References: <54EB663B.70000@oracle.com> <54EBA96F.9060708@gmail.com>
	<CACzrW9AjU+CdhnxUTWRHA5Sz9W503LmWWmE0Hy2d9qsnrDdZcw@mail.gmail.com>
Message-ID: <54EC4F8D.2040503@oracle.com>

Hi Peter,

On 24/02/15 10:00, Stephen Colebourne wrote:
> On 23 February 2015 at 22:27, Peter Levart <peter.levart at gmail.com> wrote:
>> What about the following idea:
>>
>> - create a (maybe still package-private) instance method
>> ZoneId.getSystemClock() and cache the per-ZoneId Clock instance inside the
>> ZoneId.
>> - Clock.system(ZoneId) static method is then just delegating to
>> ZoneId.getSystemClock().
>> - Similarly Clock.systemDefaultZone() can just return
>> ZoneId.defaultSystem().getSystemClock().
>> - Similarly Clock.systemUTC() can just return
>> ZoneOffset.UTC.getSystemClock().
>>
>> Or do we just want to cache systemUTC() Clock here?
>
> I suspect that the above would be a good optimisation, though perhaps
> a separate issue?

I agree with Stephen here.

There is an immediate value in having Clock.systemUTC() always
return the same clock.

I believe it could also be good for Clock.systemDefaultZone() to
always return the same clock as long as the default zone doesn't
change - and what you are proposing would solve this issue.
It was bothering me that Clock.systemUTC() could be optimized
but Clock.systemDefaultZone() could not.

But I'd rather handle that in a separate issue.
I'd like to understand all the implications of having
ZoneId depend on Clock, and whether it's worth it to
have an additional Clock field in all instances of ZoneId.

best regards,

-- daniel

>
> Stephen
>



From dmitry.samersoff at oracle.com  Tue Feb 24 10:37:31 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 24 Feb 2015 13:37:31 +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: <54EC546B.4020308@oracle.com>

David,

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?

It's a recommended (from warning-safe point of view) way to deal with
internally defined types because it allows to typedef jobject to
non-pointer type if necessary.

Yes, a bit of paranoia in this case.

>> 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) ?

I tend to agree with you, but it's out of scope of warning cleanup.

It's important for warning cleanup to don't alter code behavior and with
this fix code behaves exactly the same way as it is today - if read
fails, unpack aborts with "CRC error, invalid compressed data" message.

-Dmitry


> 
> 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 lev.priima at oracle.com  Tue Feb 24 10:39:54 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Tue, 24 Feb 2015 13:39:54 +0300
Subject: RFR 8073354: TimSortStackSize2.java: requires
	64*2^20*sizeof(reference) continues heap space
In-Reply-To: <54EA88A9.2080204@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>
Message-ID: <54EC54FA.9020503@oracle.com>

I've updated summary and description.

Lev

On 02/23/2015 04:55 AM, David Holmes wrote:
> On 20/02/2015 7:57 PM, Lev Priima wrote:
>> Functional is pretty same, but:
>>   - make it run with a single argument '67108864' by moving @summary tag
>> strait down to line after the @run tag
>>   - '-Xmx385' ->'-Xms385' in run command. MaxHeapSize will adjust a
>> accordingly.
>>   - spaces and code style.
>>
>> Of course this issue may be closed as dup of JDK-8073354 and test will
>> pass after applying JDK-8073354. But I just want to use this RFE ID to
>> make test run with a single argument ( as you noticed previously ).
>
> So this is all just cleanup - which is fine in itself but seems to 
> have no bearing on the issue reported/described in the bug report. If 
> you want to use this bug ID then I think you need to change the bug 
> report substantially else it will just be confusing.
>
> Thanks,
> David
>
>
>> Lev
>>
>> On 02/20/2015 05:26 AM, David Holmes wrote:
>>> On 19/02/2015 11:23 PM, Lev Priima wrote:
>>>> After Jespers comments I removed catch of OOME and added minimum heap
>>>> size required for test(-Xms385) to overcome default ergonomics for
>>>> client.
>>>> Please review: http://cr.openjdk.java.net/~lpriima/8073354/webrev.01/
>>>
>>> Didn't see this before sending my previous reply.
>>>
>>> I'm confused now. What functional change is now being made here ??
>>>
>>> Thanks,
>>> David
>>>
>>>> Lev
>>>>
>>>> On 02/19/2015 03:00 PM, Lev Priima wrote:
>>>>> There is also a problem, if the memory on host is highly fragmented,
>>>>> then we can't allocate continuous amount of heap for creating such 
>>>>> big
>>>>> array. I've added catch for OOME and treat this case as skip-pass to
>>>>> make test more robust. Also I've removed explicit -Xmx385 from @run
>>>>> tag and made it start with a single argument.
>>>>>
>>>>> Please review and push:
>>>>> http://cr.openjdk.java.net/~lpriima/8073354/webrev.00/
>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8073354
>>>>>
>>>>> Lev
>>>>>
>>>>> On 02/17/2015 09:55 AM, David Holmes wrote:
>>>>>> On 17/02/2015 3:43 PM, Lev Priima wrote:
>>>>>>> Thanks David!
>>>>>>> Is this expected behavior of this annotation ?
>>>>>>
>>>>>> Yes that is the way jtreg defines tags:
>>>>>>
>>>>>> http://openjdk.java.net/jtreg/tag-spec.html
>>>>>>
>>>>>> "The argument tokens of a tag extend from the first token after the
>>>>>> tag token to the end of the comment, the end of the file, or the 
>>>>>> next
>>>>>> tag token, whichever comes first."
>>>>>>
>>>>>> So everything between @run and @summary are taken to be the @run
>>>>>> commands. And there's no @comment tag unfortunately.
>>>>>>
>>>>>> David
>>>>>>
>>>>>>> Lev
>>>>>>>
>>>>>>> On 02/17/2015 03:20 AM, David Holmes wrote:
>>>>>>>> On 16/02/2015 9:20 PM, David Holmes wrote:
>>>>>>>>> On 16/02/2015 6:59 PM, Lev Priima wrote:
>>>>>>>>>> Thanks, David,
>>>>>>>>>> Could you please push it ?
>>>>>>>>>
>>>>>>>>> I will if Roger doesn't get to it first. It'll be 11 hours before
>>>>>>>>> I can
>>>>>>>>> push it.
>>>>>>>>
>>>>>>>> This has been pushed but note there is a minor issue with the 
>>>>>>>> test.
>>>>>>>> The jtreg tag specification doesn't terminate tags on newlines, 
>>>>>>>> they
>>>>>>>> continue until the next tag is encountered or the end of the
>>>>>>>> comment.
>>>>>>>> Consequently this:
>>>>>>>>
>>>>>>>>  * @run main/othervm -Xmx385m TimSortStackSize2 67108864
>>>>>>>>  * not for regular execution on all platforms:
>>>>>>>>  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>>>>  * run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>>>>>>
>>>>>>>> is processed as:
>>>>>>>>
>>>>>>>> @run main/othervm -Xmx385m TimSortStackSize2 67108864 not for
>>>>>>>> regular
>>>>>>>> execution on all platforms: run main/othervm -Xmx8g
>>>>>>>> TimSortStackSize2
>>>>>>>> 1073741824 run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>>>>>>
>>>>>>>> and so TimSortStackSize2 is invoked with 18 arguments.
>>>>>>>>
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> Lev
>>>>>>>>>>
>>>>>>>>>> On 02/16/2015 08:55 AM, David Holmes wrote:
>>>>>>>>>>> On 14/02/2015 12:03 AM, Lev Priima wrote:
>>>>>>>>>>>> Please review and push:
>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073124
>>>>>>>>>>>
>>>>>>>>>>> I hadn't realized 8072909 had been pushed without final 
>>>>>>>>>>> reviewer
>>>>>>>>>>> comments being addressed. :(
>>>>>>>>>>>
>>>>>>>>>>> These changes seem okay. I hope they get promoted at the same
>>>>>>>>>>> time as
>>>>>>>>>>> the original changeset so we don't get test failures.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>> Lev
>>>>>>>>>>>>
>>>>>>>>>>>> On 02/13/2015 05:20 AM, David Holmes wrote:
>>>>>>>>>>>>> Hi Lev,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 13/02/2015 2:56 AM, Lev Priima wrote:
>>>>>>>>>>>>>> Christos,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Test may fail on shorter arrays(page 8 of paper). For
>>>>>>>>>>>>>> instance, on
>>>>>>>>>>>>>> worst
>>>>>>>>>>>>>> case, generated by test, it starts to fail on length 
>>>>>>>>>>>>>> 67108864.
>>>>>>>>>>>>>> After increasing stack size of runs to merge, 
>>>>>>>>>>>>>> Arrays.sort(T[])
>>>>>>>>>>>>>> works
>>>>>>>>>>>>>> also on maximum possible array for HotSpot JVM.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd also like to see this documented somewhere in the code.
>>>>>>>>>>>>> Presently
>>>>>>>>>>>>> there is a reference to listsort.txt but then you have to go
>>>>>>>>>>>>> and
>>>>>>>>>>>>> find
>>>>>>>>>>>>> it on the web. :( At a minimum could we please add:
>>>>>>>>>>>>>
>>>>>>>>>>>>>  175          * computation below must be changed if
>>>>>>>>>>>>> MIN_MERGE is
>>>>>>>>>>>>> decreased.  See
>>>>>>>>>>>>>  176          * the MIN_MERGE declaration above for more
>>>>>>>>>>>>> information.
>>>>>>>>>>>>> +             * The maximum value of 49 allows for an array
>>>>>>>>>>>>> up to
>>>>>>>>>>>>> length
>>>>>>>>>>>>> +             * Integer.MAX_VALUE-4.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Roger, David,
>>>>>>>>>>>>>> I've updated the test (
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html 
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ) to make it more suitable for regular execution:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    27  * @run main/othervm TimSortStackSize2 67108864
>>>>>>>>>>>>>
>>>>>>>>>>>>> This will still fail on small memory devices:
>>>>>>>>>>>>>
>>>>>>>>>>>>> :~> java TimSortStackSize2 67108864
>>>>>>>>>>>>> Exception in thread "main" java.lang.OutOfMemoryError: Java
>>>>>>>>>>>>> heap
>>>>>>>>>>>>> space
>>>>>>>>>>>>>
>>>>>>>>>>>>> as the default heap ergonomics may not be large enough. I
>>>>>>>>>>>>> had to
>>>>>>>>>>>>> add a
>>>>>>>>>>>>> minimum heap of -Xmx385M to get it to run.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> David
>>>>>>>>>>>>>
>>>>>>>>>>>>>>    28  * not for regular execution on all platforms:
>>>>>>>>>>>>>>    29  * run main/othervm -Xmx8g TimSortStackSize2 
>>>>>>>>>>>>>> 1073741824
>>>>>>>>>>>>>>    30  * run main/othervm -Xmx32g TimSortStackSize2 
>>>>>>>>>>>>>> 2147483644
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Could you please push this:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Lev
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>>>>>>>>>>>>>> On Feb 12, 9:57pm,david.holmes at oracle.com  (David Holmes)
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> -- Subject: Re: 8072909: TimSort fails with
>>>>>>>>>>>>>>> ArrayIndexOutOfBoundsException on
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> | Ok - thanks Lev!
>>>>>>>>>>>>>>> |
>>>>>>>>>>>>>>> | David
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For posterity can someone document this, and also the
>>>>>>>>>>>>>>> value for
>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>> Integer.MAX_VALUE-4 fails?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> christos
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>



From joel.franck at oracle.com  Tue Feb 24 10:49:09 2015
From: joel.franck at oracle.com (=?utf-8?Q?Joel_Borggr=C3=A9n-Franck?=)
Date: Tue, 24 Feb 2015 11:49:09 +0100
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
Message-ID: <9D775E0E-16CA-43C9-AC30-A691AE7CCC0F@oracle.com>

Hi,

Here is a fix for an issue with repeating annotations when a security manager is set.

Fix is to use the Proxy invocation handler to unwrap the array containing the repeating annotations. In theory it might be possible to have instances of Annotations that are not implemented using Proxies, so the old code which  is independent of implementation is kept as a fall-back, but the user or these theoretical annotations will have to configure the security policy accordingly.

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

cheers
/Joel

From chris.hegarty at oracle.com  Tue Feb 24 10:53:12 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 24 Feb 2015 10:53:12 +0000
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <54EB96B8.30304@gmail.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com> <54E71BC3.30403@oracle.com>
	<54E74E29.2060806@gmail.com> <54EB08A5.4000905@oracle.com>
	<54EB96B8.30304@gmail.com>
Message-ID: <DAFD881E-4105-4140-AEEC-7724A5C84C6D@oracle.com>

Peter,

On 23 Feb 2015, at 21:08, Peter Levart <peter.levart at gmail.com> wrote:

> Hi Chris,
> 
> On 02/23/2015 12:01 PM, Chris Hegarty wrote:
>> Peter, David, Vitaly, 
>> 
>> Can you please take a look at the latest version of this change: 
>> 
>>   http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/ 
> 
> There are still a couple of issues with this version:
> 
> - You are issuing freeze action as soon as any readObject() invocation is complete (including nested invocations) when the invocation itself has set the requiresFreeze flag, which is cleared when freeze() is called, but can be set again for any other nested (sibling, ...) call to readObject(). So many freeze(s) can potentialy be issued. This can be fixed by checking for (level == 0) condition before calling freeze.

Agreed. That is better.

I noticed that you put the freeze after vlist.doCallbacks(). I originally wanted to freeze before the callbacks ( less chance of unsafe publication ), but now I think I agree with where you put it. The callbacks are to validate the graph, throwing an Exception if there is a problem, so we can avoid the freeze in this case.

> - You are tracking the requiresFreeze flag in readSerialData() method for each class slot the deserialized object is composed of. This can be optimized and the 'hasFinalField' flag pre-computed for the whole object (all slots) and stored in ObjestStreamClass as such.

I don?t see how your proposed changes are any more performant ( all that has happened is that the call to hasFinal has been moved inside the loop in getClassDataLayout0 ), and it is more difficult, at least for me, to grok ( and has an additional context dependency ). Is your concern the reading of the requiresFreeze field in readSerialData? Would making this a local field in the loop address your concern? 

> - We have to be careful with "loosening" of volatile writes to final fields in custom readObject() methods (BigDecimal.intCompact for example) especialy if they are writes to fields that are not serial fields in ObjectStreamClass (either they are transient or not listed in serialPersistentFields). By doing that, you are relying on the fact that default deserialization (defaultReadObject() call in case of BigDecimal) tracks at least one other final field that is also serial field. This is the case with BigDecimal and BigInteger, but in general it is not.

I agree, we need to be careful here, but as you say these two specific cases should be fine.

> It will be interesting how tracking will be implemented most efficiently when FieldAccess API appears, but that's another story?

I think the work-in-progress FieldAccess API will really help here, but for now I?d like to proceed with changing these two cases, and they can be retrofitted when the new API is available.

> So I propose the following variant for now (including just ObjectInputStream and ObjectStreamClass) that fixes 1st two issues above. I suggest waiting with BigDecimal/BigInteger changes until FieldAccess API is available and throw away Unsafe usage alltogether at that point:
> 
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ObjectInputStream.freeze/webrev.01/

It was really helpful to have a webrev to put your comments in context. Thanks.

Updated webrev, including all comments/changes so far:
  http://cr.openjdk.java.net/~chegar/deserialFence/webrev.03/webrev/

-Chris.


> 
> Regards, Peter
> 
> 
>> 
>> On 20/02/15 15:09, Peter Levart wrote: 
>>> ... 
>>> This looks good now. But I wonder if issuing fences after nested calls 
>>> to readObject() makes much sense. If cycles are present in a subgraph 
>>> deserialized by nested call to readObject(), a field pointing back to an 
>>> object not part of the subgraph stream will point to the object that 
>>> will not be fully initialized yet, so nested calls to readObject() 
>>> should not be expected to return a reference to a fully constructed 
>>> subgraph anyway. Only top-level call is guaranteed to return a fully 
>>> constructed graph. 
>> 
>> Right. I was never convinced of this myself either. Removed. Unnecessary complication. 
>> 
>>> If you optimize this and only issue one fence for top-level call to 
>>> readObject(), tracking of 'requiresFence' (I would call it 
>>> requiresFreeze to be in line with JMM terminology - the fence is just a 
>> 
>> 'requiresFreeze' is better. Updated 
>> 
>>> way to achieve freeze) can also be micro-optimized. You currently do it 
>>> like this: 
>>> 
>>> 1900             requiresFence |= slotDesc.hasFinalField(); 
>>> 
>>> which is a shortcut for: 
>>> 
>>> requiresFence = requiresFence | slotDesc.hasFinalField(); 
>>> 
>>> ...which means that the field is overwritten multiple times 
>>> unnecessarily and slotDesc.hasFinalField() is called every time. You can 
>>> write the same logic as: 
>>> 
>>> if (!requiresFence && slotDesc.hasFinalField()) { 
>>>      requiresFence = true; 
>>> } 
>> 
>> ... and it is more readable. Updated. 
>> 
>>> There will be at most one write to the field and potentially less calls 
>>> to slotDesc.hasFinalField(). 
>> 
>> -Chris. 
> 



From daniel.fuchs at oracle.com  Tue Feb 24 10:59:28 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 24 Feb 2015 11:59:28 +0100
Subject: RFR: 8073394: Clock.systemUTC() should return a constant
In-Reply-To: <CACzrW9Cz3JcCrgrzX7zwddOrCJ1wpLO2_M=RQOK59p0c396dXA@mail.gmail.com>
References: <54EB663B.70000@oracle.com>
	<54EB7666.2010401@Oracle.com>	<54EB8743.9000507@oracle.com>
	<CACzrW9Cz3JcCrgrzX7zwddOrCJ1wpLO2_M=RQOK59p0c396dXA@mail.gmail.com>
Message-ID: <54EC5990.8050804@oracle.com>

On 23/02/15 21:40, Stephen Colebourne wrote:
> The rest of the java.time code tends to put the data provider method
> before the test, and mostly uses a naming convention of
> "data_systemClocks". Neither of which are particularly important
> things.

Thanks Stephen.

I had a look at TestLocalDate.java
<http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/test/java/time/test/java/time/TestLocalDate.java#l177>
and tried to emulate what I saw there. All files in that
directory seem to share the same convention.

Here is the new webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.02/

best regards,

-- daniel

>
> Stephen
>
>
> On 23 February 2015 at 20:02, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>> On 23/02/15 19:50, Roger Riggs wrote:
>>>
>>> Hi Daniel,
>>>
>>> Typically, a TestNG DataProvider would have been used to supply the case
>>> data
>>> instead of an internal Map.
>>
>>
>> Thanks Roger. I should take some time to learn more about TestNG.
>>
>> Here is the new webrev:
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.01/
>>
>> -- daniel
>>
>>
>>>
>>> The rest looks fine.
>>>
>>> Thanks, Roger
>>>
>>> On 2/23/2015 12:41 PM, Daniel Fuchs wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please find below a small patch for
>>>> 8073394: Clock.systemUTC() should return a constant
>>>>
>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.00/
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>
>>>
>>



From paul.sandoz at oracle.com  Tue Feb 24 11:16:55 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 24 Feb 2015 12:16:55 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54EB6DD1.4090803@redhat.com>
References: <54EB6DD1.4090803@redhat.com>
Message-ID: <9C5507AD-AACE-45EF-9845-0C1DF6C10893@oracle.com>

Hi Andrew,

This looks like a good start.

On Feb 23, 2015, at 7:13 PM, Andrew Haley <aph at redhat.com> wrote:

> I've been kicking around a few ideas for Unsafe access methods for
> unaligned access to byte arrays and buffers in order to provide
> "whatever second-best mechanism the platform offers".  These would
> provide the base for fast lexicographic array comparisons, etc.
> 
> https://bugs.openjdk.java.net/browse/JDK-8044082
> 
> If the platform supports unaligned memory accesses, the implementation
> of {get,put}-X-Unaligned is obvious and trivial for both C1 and C2.
> It gets interesting when we want to provide efficient unaligned
> methods on machines with no hardware support.
> 
> We could provide compiler intrinsics which do when we need on such
> machines.  However, I think this wouldn't deliver the best results.
> From the experiments I've done, the best implementation is to write
> the access methods in Java and allow HotSpot to optimize them.  While
> this seemed a bit counter-intuitive to me, it's best because C2 has
> profile data that it can work on.  In many cases I suspect that data
> read and written from a byte array will be aligned for their type and
> C2 will take advantage of this, relegating the misaligned access to an
> out-of-line code path as appropriate.  

I am all for keeping more code in Java if we can. I don't know enough about assembler-based optimizations to determine if it might be possible to do better on certain CPU architectures.

One advantage, AFAIU, to intrinsics is they are not subject to the vagaries of inlining thresholds. It's important that the loops operating over the arrays to be compiled efficiently otherwise performance can drop off the cliff if thresholds are reached within the loop. Perhaps these methods are small enough it is not an issue? and also perhaps that is not a sufficient argument to justify the cost of an intrinsic (and we should be really tweaking the inlining mechanism)?

With that in mind is there any need to intrinsify the new methods at all given those new Java methods can defer to the older ones based on a constant check? Also should that anyway be done for the interpreter?

     private static final boolean IS_UNALIGNED = theUnsafe.unalignedAccess();

     public void putIntUnaligned(Object o, long offset, int x) {
         if (IS_UNALIGNED || (offset & 3) == 0) {
             putInt(o, offset, x);             
         } else if (byteOrder == BIG_ENDIAN) {
             putIntB(o, offset, x);
         } else {
             putIntL(o, offset, x);
         }
     }

I see you optimized the unaligned getLong by reading two aligned longs and then bit twiddled. It seems harder to optimize the putLong by straddling an aligned putInt with one to three required putByte.


> Also, these methods have the
> additional benefit that they are always atomic as long as the data are
> naturally aligned.
> 

We should probably document that in general access is not guaranteed to be atomic and an implementation detail that it currently is when naturally so.


> This does result in rather a lot of code for the methods for all sizes
> and endiannesses, but none of it will be used on machines with
> unaligned hardware support except in the interpreter.  (Perhaps the
> interpreter too could have intrinsics?)
> 
> I have changed HeapByteBuffer to use these methods, with a major
> performance improvement.  I've also provided Unsafe methods to query
> endianness and alignment support.
> 

If we expose the endianness query via a new method in unsafe we should reuse that in java.nio.Bits and get rid of the associated static code block.
 
Paul.

> Webrevs at http://cr.openjdk.java.net/~aph/unaligned.hotspot.1/
> http://cr.openjdk.java.net/~aph/unaligned.jdk.1/
> 
> Andrew.



From scolebourne at joda.org  Tue Feb 24 11:17:31 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 24 Feb 2015 11:17:31 +0000
Subject: RFR: 8073394: Clock.systemUTC() should return a constant
In-Reply-To: <54EC5990.8050804@oracle.com>
References: <54EB663B.70000@oracle.com> <54EB7666.2010401@Oracle.com>
	<54EB8743.9000507@oracle.com>
	<CACzrW9Cz3JcCrgrzX7zwddOrCJ1wpLO2_M=RQOK59p0c396dXA@mail.gmail.com>
	<54EC5990.8050804@oracle.com>
Message-ID: <CACzrW9A2B4hpRSx0-kdwca9Exchg6_2mPHX71=mofMdkorTH=A@mail.gmail.com>

Thanks for the change. This reviewer is happy.
Stephen

On 24 February 2015 at 10:59, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> On 23/02/15 21:40, Stephen Colebourne wrote:
>>
>> The rest of the java.time code tends to put the data provider method
>> before the test, and mostly uses a naming convention of
>> "data_systemClocks". Neither of which are particularly important
>> things.
>
>
> Thanks Stephen.
>
> I had a look at TestLocalDate.java
> <http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/test/java/time/test/java/time/TestLocalDate.java#l177>
> and tried to emulate what I saw there. All files in that
> directory seem to share the same convention.
>
> Here is the new webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.02/
>
> best regards,
>
> -- daniel
>
>
>>
>> Stephen
>>
>>
>> On 23 February 2015 at 20:02, Daniel Fuchs <daniel.fuchs at oracle.com>
>> wrote:
>>>
>>> On 23/02/15 19:50, Roger Riggs wrote:
>>>>
>>>>
>>>> Hi Daniel,
>>>>
>>>> Typically, a TestNG DataProvider would have been used to supply the case
>>>> data
>>>> instead of an internal Map.
>>>
>>>
>>>
>>> Thanks Roger. I should take some time to learn more about TestNG.
>>>
>>> Here is the new webrev:
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.01/
>>>
>>> -- daniel
>>>
>>>
>>>>
>>>> The rest looks fine.
>>>>
>>>> Thanks, Roger
>>>>
>>>> On 2/23/2015 12:41 PM, Daniel Fuchs wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Please find below a small patch for
>>>>> 8073394: Clock.systemUTC() should return a constant
>>>>>
>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.00/
>>>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>>
>>>>
>>>>
>>>
>


From lance.andersen at oracle.com  Tue Feb 24 11:25:29 2015
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Tue, 24 Feb 2015 06:25:29 -0500
Subject: RFR: 8073394: Clock.systemUTC() should return a constant
In-Reply-To: <54EC5990.8050804@oracle.com>
References: <54EB663B.70000@oracle.com> <54EB7666.2010401@Oracle.com>
	<54EB8743.9000507@oracle.com>
	<CACzrW9Cz3JcCrgrzX7zwddOrCJ1wpLO2_M=RQOK59p0c396dXA@mail.gmail.com>
	<54EC5990.8050804@oracle.com>
Message-ID: <DD29B690-D548-4F45-96C8-B9EA88B7FDCE@oracle.com>

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

> On Feb 24, 2015, at 5:59 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
>> On 23/02/15 21:40, Stephen Colebourne wrote:
>> The rest of the java.time code tends to put the data provider method
>> before the test, and mostly uses a naming convention of
>> "data_systemClocks". Neither of which are particularly important
>> things.
> 
> Thanks Stephen.
> 
> I had a look at TestLocalDate.java
> <http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/test/java/time/test/java/time/TestLocalDate.java#l177>
> and tried to emulate what I saw there. All files in that
> directory seem to share the same convention.
> 
> Here is the new webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.02/
> 
> best regards,
> 
> -- daniel
> 
>> 
>> Stephen
>> 
>> 
>>> On 23 February 2015 at 20:02, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>>> On 23/02/15 19:50, Roger Riggs wrote:
>>>> 
>>>> Hi Daniel,
>>>> 
>>>> Typically, a TestNG DataProvider would have been used to supply the case
>>>> data
>>>> instead of an internal Map.
>>> 
>>> 
>>> Thanks Roger. I should take some time to learn more about TestNG.
>>> 
>>> Here is the new webrev:
>>> 
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.01/
>>> 
>>> -- daniel
>>> 
>>> 
>>>> 
>>>> The rest looks fine.
>>>> 
>>>> Thanks, Roger
>>>> 
>>>>> On 2/23/2015 12:41 PM, Daniel Fuchs wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> Please find below a small patch for
>>>>> 8073394: Clock.systemUTC() should return a constant
>>>>> 
>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.00/
>>>>> 
>>>>> best regards,
>>>>> 
>>>>> -- daniel
> 


From joel.franck at oracle.com  Tue Feb 24 11:26:11 2015
From: joel.franck at oracle.com (=?utf-8?Q?Joel_Borggr=C3=A9n-Franck?=)
Date: Tue, 24 Feb 2015 12:26:11 +0100
Subject: RFR 8014678: Spurious AccessControlException thrown in
	java.lang.Class.getEnclosingMethod()
Message-ID: <0C9A8736-306C-4631-8190-BD84B9DF6F27@oracle.com>

Hi,

Here is a fix for an old issue with Class.getEnclosingMethod() and Class.getEnclosingConstructor(). The problem is that we throw a spurious AccessControlException in some cases when looking up enclosingMethod/Ctor in the presence of a SecurityManager.

 Consider the following classes: 

class C {}

class A {
   public void someMetod() {
        class B {}
    }
}

If client C has a Class<?> token for B it can call classForB.getEnclosingMethod(). While the client C must have permissions to look at declared members of A, in the nested call java.lang.Class will be looking at declared members of A while constructing the answer, and java.lang.Class might not have permissions to do this, even though the ?real? caller C has the correct permissions. So we and up with a call stack that looks like 

Caller:                               Call:

j.l.Class(for A.class)          A.class::checkMemberAccess(classloader for j.l.Class); // this can throw ACE if A is loaded in a separate loader from java.lang.Class
j.l.Class(for B.class)          A.class::getDeclaredMethods(); // j.l.Class is the caller here
C                                       B.class::getEnclosingMethod();
.... application code ?.

The solution here is to insert a doPrivileged block around the call where j.l.Class gets the members to construct the answer.

Webrev: http://cr.openjdk.java.net/~jfranck/8014678/

Bug is not open but the tests show how this is reproduced.

cheers
/Joel

From peter.levart at gmail.com  Tue Feb 24 11:45:40 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 24 Feb 2015 12:45:40 +0100
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <DAFD881E-4105-4140-AEEC-7724A5C84C6D@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com> <54E71BC3.30403@oracle.com>
	<54E74E29.2060806@gmail.com> <54EB08A5.4000905@oracle.com>
	<54EB96B8.30304@gmail.com>
	<DAFD881E-4105-4140-AEEC-7724A5C84C6D@oracle.com>
Message-ID: <54EC6464.8090608@gmail.com>

Hi Chris,

On 02/24/2015 11:53 AM, Chris Hegarty wrote:
> Peter,
>
> On 23 Feb 2015, at 21:08, Peter Levart <peter.levart at gmail.com> wrote:
>
>> Hi Chris,
>>
>> On 02/23/2015 12:01 PM, Chris Hegarty wrote:
>>> Peter, David, Vitaly,
>>>
>>> Can you please take a look at the latest version of this change:
>>>
>>>    http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/
>> There are still a couple of issues with this version:
>>
>> - You are issuing freeze action as soon as any readObject() invocation is complete (including nested invocations) when the invocation itself has set the requiresFreeze flag, which is cleared when freeze() is called, but can be set again for any other nested (sibling, ...) call to readObject(). So many freeze(s) can potentialy be issued. This can be fixed by checking for (level == 0) condition before calling freeze.
> Agreed. That is better.
>
> I noticed that you put the freeze after vlist.doCallbacks(). I originally wanted to freeze before the callbacks ( less chance of unsafe publication ), but now I think I agree with where you put it. The callbacks are to validate the graph, throwing an Exception if there is a problem, so we can avoid the freeze in this case.

Well, either way is ok considering current constraints. Exceptional path 
should not be concerned with overhead anyway.

>
>> - You are tracking the requiresFreeze flag in readSerialData() method for each class slot the deserialized object is composed of. This can be optimized and the 'hasFinalField' flag pre-computed for the whole object (all slots) and stored in ObjestStreamClass as such.
> I don?t see how your proposed changes are any more performant ( all that has happened is that the call to hasFinal has been moved inside the loop in getClassDataLayout0 ), and it is more difficult, at least for me, to grok ( and has an additional context dependency ). Is your concern the reading of the requiresFreeze field in readSerialData? Would making this a local field in the loop address your concern?

The loop in getClassDataLayout0 is only executed once per 
ObjectStreamClass (the layout is then cached). The loop in 
readSerialData() is executed for each object instance deserialized.

Considering the results of Alexey's research:

http://shipilev.net/blog/2014/all-fields-are-final/

He came to conclusion that even in constructors that just set fields and 
do no complex logic like deserialization, the relative overhead of 
freeze is minimal. So we might be better off just issuing the freeze 
unconditionally and not bother with tracking which might have more 
overhead even for very small streams (for example one object with few ints).

>
>> - We have to be careful with "loosening" of volatile writes to final fields in custom readObject() methods (BigDecimal.intCompact for example) especialy if they are writes to fields that are not serial fields in ObjectStreamClass (either they are transient or not listed in serialPersistentFields). By doing that, you are relying on the fact that default deserialization (defaultReadObject() call in case of BigDecimal) tracks at least one other final field that is also serial field. This is the case with BigDecimal and BigInteger, but in general it is not.
> I agree, we need to be careful here, but as you say these two specific cases should be fine.

And if the freeze is unconditional, we don't have to worry at all.

>
>> It will be interesting how tracking will be implemented most efficiently when FieldAccess API appears, but that's another story?
> I think the work-in-progress FieldAccess API will really help here, but for now I?d like to proceed with changing these two cases, and they can be retrofitted when the new API is available.

Agreed.

>
>> So I propose the following variant for now (including just ObjectInputStream and ObjectStreamClass) that fixes 1st two issues above. I suggest waiting with BigDecimal/BigInteger changes until FieldAccess API is available and throw away Unsafe usage alltogether at that point:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ObjectInputStream.freeze/webrev.01/
> It was really helpful to have a webrev to put your comments in context. Thanks.
>
> Updated webrev, including all comments/changes so far:
>    http://cr.openjdk.java.net/~chegar/deserialFence/webrev.03/webrev/

That's better now. Let me just try to measure the overhead of tracking 
on simple objects to see if it actually pays off or is contra-productive 
in any case.

Regards, Peter

>
> -Chris.
>
>
>> Regards, Peter
>>
>>
>>> On 20/02/15 15:09, Peter Levart wrote:
>>>> ...
>>>> This looks good now. But I wonder if issuing fences after nested calls
>>>> to readObject() makes much sense. If cycles are present in a subgraph
>>>> deserialized by nested call to readObject(), a field pointing back to an
>>>> object not part of the subgraph stream will point to the object that
>>>> will not be fully initialized yet, so nested calls to readObject()
>>>> should not be expected to return a reference to a fully constructed
>>>> subgraph anyway. Only top-level call is guaranteed to return a fully
>>>> constructed graph.
>>> Right. I was never convinced of this myself either. Removed. Unnecessary complication.
>>>
>>>> If you optimize this and only issue one fence for top-level call to
>>>> readObject(), tracking of 'requiresFence' (I would call it
>>>> requiresFreeze to be in line with JMM terminology - the fence is just a
>>> 'requiresFreeze' is better. Updated
>>>
>>>> way to achieve freeze) can also be micro-optimized. You currently do it
>>>> like this:
>>>>
>>>> 1900             requiresFence |= slotDesc.hasFinalField();
>>>>
>>>> which is a shortcut for:
>>>>
>>>> requiresFence = requiresFence | slotDesc.hasFinalField();
>>>>
>>>> ...which means that the field is overwritten multiple times
>>>> unnecessarily and slotDesc.hasFinalField() is called every time. You can
>>>> write the same logic as:
>>>>
>>>> if (!requiresFence && slotDesc.hasFinalField()) {
>>>>       requiresFence = true;
>>>> }
>>> ... and it is more readable. Updated.
>>>
>>>> There will be at most one write to the field and potentially less calls
>>>> to slotDesc.hasFinalField().
>>> -Chris.



From peter.levart at gmail.com  Tue Feb 24 11:50:14 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 24 Feb 2015 12:50:14 +0100
Subject: RFR: 8073394: Clock.systemUTC() should return a constant
In-Reply-To: <54EC4F8D.2040503@oracle.com>
References: <54EB663B.70000@oracle.com> <54EBA96F.9060708@gmail.com>
	<CACzrW9AjU+CdhnxUTWRHA5Sz9W503LmWWmE0Hy2d9qsnrDdZcw@mail.gmail.com>
	<54EC4F8D.2040503@oracle.com>
Message-ID: <54EC6576.1000804@gmail.com>

On 02/24/2015 11:16 AM, Daniel Fuchs wrote:
> Hi Peter,
>
> On 24/02/15 10:00, Stephen Colebourne wrote:
>> On 23 February 2015 at 22:27, Peter Levart <peter.levart at gmail.com> 
>> wrote:
>>> What about the following idea:
>>>
>>> - create a (maybe still package-private) instance method
>>> ZoneId.getSystemClock() and cache the per-ZoneId Clock instance 
>>> inside the
>>> ZoneId.
>>> - Clock.system(ZoneId) static method is then just delegating to
>>> ZoneId.getSystemClock().
>>> - Similarly Clock.systemDefaultZone() can just return
>>> ZoneId.defaultSystem().getSystemClock().
>>> - Similarly Clock.systemUTC() can just return
>>> ZoneOffset.UTC.getSystemClock().
>>>
>>> Or do we just want to cache systemUTC() Clock here?
>>
>> I suspect that the above would be a good optimisation, though perhaps
>> a separate issue?
>
> I agree with Stephen here.
>
> There is an immediate value in having Clock.systemUTC() always
> return the same clock.
>
> I believe it could also be good for Clock.systemDefaultZone() to
> always return the same clock as long as the default zone doesn't
> change - and what you are proposing would solve this issue.
> It was bothering me that Clock.systemUTC() could be optimized
> but Clock.systemDefaultZone() could not.
>
> But I'd rather handle that in a separate issue.
> I'd like to understand all the implications of having
> ZoneId depend on Clock, and whether it's worth it to
> have an additional Clock field in all instances of ZoneId.
>
> best regards,
>
> -- daniel

Yes, I had that concern too. Too much caching where you don't need it 
can be contra-productive.

Regards, Peter

>
>>
>> Stephen
>>
>



From peter.levart at gmail.com  Tue Feb 24 12:49:51 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 24 Feb 2015 13:49:51 +0100
Subject: ConcurrentModificationException in java.util.ServiceLoader (not
	a multi-thread issue)
In-Reply-To: <54EC4534.5020909@geomatys.fr>
References: <54EB372B.401@geomatys.fr>
	<54EBD493.7000001@oracle.com>	<54EC31AA.6050300@oracle.com>
	<54EC4534.5020909@geomatys.fr>
Message-ID: <54EC736F.30907@gmail.com>

On 02/24/2015 10:32 AM, Martin Desruisseaux wrote:
> Le 24/02/15 09:09, Alan Bateman a ?crit :
>
>> Right, it has never supported multiple iterators but as it's an
>> Iterable then it should unless specified otherwise. So I think this is
>> a bug (although one could argue that the usage is unusual, almost a
>> mis-use).
> One use case is that in a multi-thread environment, this bug implies
> that it is not sufficient to synchronize all direct and indirect
> (through Iterator) usages of ServiceLoader. We must synchronize the
> entire iteration loop for preventing other threads to start a new
> iteration before we finished the current one. This can be annoying if
> the work to do between two calls to Iterator.hasNext() / next() is long.
> Sometime it is not possible to synchronize the entire loop if we do not
> control the iteration (i.e. if we advance in the iterator only when the
> user invokes some method). The later case can be a problem even in
> mono-thread application.
>
>
>> Not clear whether it's worth doing anything about it now, this is
>> because ServiceLoader is going to change very significantly soon when
>> it is re-specified to work with modules. I'll create a bug anyway to
>> track it anyway.
> Thanks. The fact that ServiceLoader was going to be modified for Jigsaw
> is precisely the reason why I was wondering if it was worth to
> investigate more now.
>
>      Martin
>
>

You could synchronize on the entire loop and just copy over the service 
objects to another collection (say ArrayList). Then use the ArrayList 
freely from multiple threads just to iterate it without any 
synchronization. This will work if constructing service objects is 
relatively cheap and you can do them all at once. When using 
ServiceLoader for multiple (sequential) iterations, it does the same: 
the 2nd and subsequent iterations will just return the same objects from 
1st iteration. If you really must combine laziness of constructing 
service objects with concurrent iterations, you can wrap the 
ServiceLoader.iterator() with the following:

public class BufferedConcurrentIterable<E> implements Iterable<E> {

     private final Iterator<E> source;
     private final List<E> buffer = new ArrayList<>();

     public BufferedConcurrentIterable(Iterator<E> source) {
         this.source = source;
     }

     @Override
     public Iterator<E> iterator() {
         return new Iterator<E>() {
             int i;

             @Override
             public boolean hasNext() {
                 synchronized (buffer) {
                     return i < buffer.size() || source.hasNext();
                 }
             }

             @Override
             public E next() {
                 synchronized (buffer) {
                     if (i < buffer.size()) {
                         return buffer.get(i++);
                     }
                     E next = source.next();
                     buffer.add(next);
                     i++;
                     return next;
                 }
             }
         };
     }
}


Regards, Peter



From martin.desruisseaux at geomatys.fr  Tue Feb 24 13:47:28 2015
From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux)
Date: Tue, 24 Feb 2015 14:47:28 +0100
Subject: ConcurrentModificationException in java.util.ServiceLoader (not
	a multi-thread issue)
In-Reply-To: <54EC736F.30907@gmail.com>
References: <54EB372B.401@geomatys.fr>
	<54EBD493.7000001@oracle.com>	<54EC31AA.6050300@oracle.com>
	<54EC4534.5020909@geomatys.fr> <54EC736F.30907@gmail.com>
Message-ID: <54EC80F0.6030709@geomatys.fr>

Hello Peter

Le 24/02/15 13:49, Peter Levart a ?crit :
> You could synchronize on the entire loop and just copy over the
> service objects to another collection (say ArrayList).

Right, but I would like to keep the laziness instantiation behaviour.


> If you really must combine laziness of constructing service objects
> with concurrent iterations, you can wrap the ServiceLoader.iterator()
> with the following:
>
> public class BufferedConcurrentIterable<E> implements Iterable<E> {
> (...snip...)

Many thanks for your help. This is indeed what I did yesterday :-). But
given that the current ServiceLoader behaviour results in random
ConcurrentModificationException in some multi-threads environments, this
can mislead the users who believe that they have a synchronization error
in their own code before they realize that the issue is in ServiceLoader
itself.

    Martin




From aph at redhat.com  Tue Feb 24 13:48:06 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 24 Feb 2015 13:48:06 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <9C5507AD-AACE-45EF-9845-0C1DF6C10893@oracle.com>
References: <54EB6DD1.4090803@redhat.com>
	<9C5507AD-AACE-45EF-9845-0C1DF6C10893@oracle.com>
Message-ID: <54EC8116.3080006@redhat.com>

Hi,

On 02/24/2015 11:16 AM, Paul Sandoz wrote:

> This looks like a good start.

Good, thanks.

> On Feb 23, 2015, at 7:13 PM, Andrew Haley <aph at redhat.com> wrote:
> 
>> I've been kicking around a few ideas for Unsafe access methods for unaligned access to byte arrays and buffers in order to provide "whatever second-best mechanism the platform offers".  These would provide the base for fast lexicographic array comparisons, etc.
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8044082
>> 
>> If the platform supports unaligned memory accesses, the implementation of {get,put}-X-Unaligned is obvious and trivial for both C1 and C2. It gets interesting when we want to provide efficient unaligned methods on machines with no hardware support.
>> 
>> We could provide compiler intrinsics which do when we need on such machines.  However, I think this wouldn't deliver the best results. From the experiments I've done, the best implementation is to write the access methods in Java and allow HotSpot to optimize them.  While this seemed a bit counter-intuitive to me, it's best because C2 has profile data that it can work on.  In many cases I suspect that data read and written from a byte array will be aligned for their type and C2 will take advantage of this, relegating the misaligned access to an out-of-line code path as appropriate.
> 
> I am all for keeping more code in Java if we can. I don't know enough about assembler-based optimizations to determine if it might be possible to do better on certain CPU architectures.

Me either, but I have tested this on the architectures I have, and I
suspect that C2 optimization is good enough.  And we'd have to write
assembly code for machines we haven't got; something for the future, I
think.

> One advantage, AFAIU, to intrinsics is they are not subject to the vagaries of inlining thresholds. It's important that the loops operating over the arrays to be compiled efficiently otherwise performance can drop off the cliff if thresholds are reached within the loop. Perhaps these methods are small enough it is not an issue? and also perhaps that is not a sufficient argument to justify the cost of an intrinsic (and we should be really tweaking the inlining mechanism)?

Maybe so.  There are essentially two ways to do this: new compiler
node types which punt everything to the back end (and therefore
require back-end authors to write them) or generic expanders, which is
how many of the existing intrinsics are done.  Generic C2 code would,
I suspect, be worse than writing this in Java bacause it would be
lacking profile data.

> With that in mind is there any need to intrinsify the new methods at all given those new Java methods can defer to the older ones based on a constant check? Also should that anyway be done for the interpreter?
> 
> 
> private static final boolean IS_UNALIGNED = theUnsafe.unalignedAccess();
> 
> public void putIntUnaligned(Object o, long offset, int x) { if (IS_UNALIGNED || (offset & 3) == 0) { putInt(o, offset, x); } else if (byteOrder == BIG_ENDIAN) { putIntB(o, offset, x); } else { putIntL(o, offset, x); } }

Yes.  It certainly could be done like this but I think C1 doesn't do
the optimization to remove the IS_UNALIGNED test, so we'd still want
the C1 builtins.  Perhaps we could do without the C2 builtins but they
cost very little, they save C2 a fair amount of work, and they remove
the vagaries of inlining.  I take your point about the interpreter,
though.

> I see you optimized the unaligned getLong by reading two aligned longs and then bit twiddled. It seems harder to optimize the putLong by straddling an aligned putInt with one to three required putByte.

Sure, that's always a possibility.  I have code to do it but it was
all getting rather complicated for my taste.

>> Also, these methods have the additional benefit that they are always atomic as long as the data are naturally aligned.
> 
> We should probably document that in general access is not guaranteed to be atomic and an implementation detail that it currently is when naturally so.

I think that's a good idea.  The jcstress tests already come up with a
warning that the implementation is not atomic; this is not required,
but a high-quality implementation will be.

>> This does result in rather a lot of code for the methods for all sizes and endiannesses, but none of it will be used on machines with unaligned hardware support except in the interpreter.  (Perhaps the interpreter too could have intrinsics?)
>> 
>> I have changed HeapByteBuffer to use these methods, with a major performance improvement.  I've also provided Unsafe methods to query endianness and alignment support.
> 
> If we expose the endianness query via a new method in unsafe we should reuse that in java.nio.Bits and get rid of the associated static code block.

Sure, I already did that.

Thanks,
Andrew.


From paul.sandoz at oracle.com  Tue Feb 24 14:47:22 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 24 Feb 2015 15:47:22 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54EC8116.3080006@redhat.com>
References: <54EB6DD1.4090803@redhat.com>
	<9C5507AD-AACE-45EF-9845-0C1DF6C10893@oracle.com>
	<54EC8116.3080006@redhat.com>
Message-ID: <56383544-CB43-4521-A2E4-E22B48E24B73@oracle.com>

On Feb 24, 2015, at 2:48 PM, Andrew Haley <aph at redhat.com> wrote:
>> 
>> I am all for keeping more code in Java if we can. I don't know enough about assembler-based optimizations to determine if it might be possible to do better on certain CPU architectures.
> 
> Me either, but I have tested this on the architectures I have, and I
> suspect that C2 optimization is good enough.  And we'd have to write
> assembly code for machines we haven't got; something for the future, I
> think.
> 

Agreed.


>> One advantage, AFAIU, to intrinsics is they are not subject to the vagaries of inlining thresholds. It's important that the loops operating over the arrays to be compiled efficiently otherwise performance can drop off the cliff if thresholds are reached within the loop. Perhaps these methods are small enough it is not an issue? and also perhaps that is not a sufficient argument to justify the cost of an intrinsic (and we should be really tweaking the inlining mechanism)?
> 
> Maybe so.  There are essentially two ways to do this: new compiler
> node types which punt everything to the back end (and therefore
> require back-end authors to write them) or generic expanders, which is
> how many of the existing intrinsics are done.  Generic C2 code would,
> I suspect, be worse than writing this in Java bacause it would be
> lacking profile data.
> 
>> With that in mind is there any need to intrinsify the new methods at all given those new Java methods can defer to the older ones based on a constant check? Also should that anyway be done for the interpreter?
>> 
>> 
>> private static final boolean IS_UNALIGNED = theUnsafe.unalignedAccess();
>> 
>> public void putIntUnaligned(Object o, long offset, int x) { if (IS_UNALIGNED || (offset & 3) == 0) { putInt(o, offset, x); } else if (byteOrder == BIG_ENDIAN) { putIntB(o, offset, x); } else { putIntL(o, offset, x); } }
> 
> Yes.  It certainly could be done like this but I think C1 doesn't do
> the optimization to remove the IS_UNALIGNED test, so we'd still want
> the C1 builtins.

Hmm.... if i run the following code on my Mac:

import java.nio.ByteOrder;

public class Y {

    static final boolean X = ByteOrder.nativeOrder() == ByteOrder.LITTLE_ENDIAN;     // Just get a constant from somewhere...

    public static void main(String[] args) {
        Y y = new Y();

        int s = 0;
        for (int i = 0; i < 1000000; i++) {
            s += y.x(i);
        }
        System.out.println(s);
    }

    public int x(int i) {
        if (X || (i & 3) == 0) {
            return i + i;
        }
        else {
            return Integer.sum(i, i);
        }
    }
}

With the options:

  -XX:TieredStopAtLevel=1 -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly

Then Y.x is compiled to:

  0x000000011155ea80: mov    %eax,-0x14000(%rsp)
  0x000000011155ea87: push   %rbp
  0x000000011155ea88: sub    $0x30,%rsp         ;*getstatic X
                                                ; - Y::x at 0 (line 43)

  0x000000011155ea8c: mov    %rdx,%rax
  0x000000011155ea8f: add    %edx,%eax
  0x000000011155ea91: add    $0x30,%rsp
  0x000000011155ea95: pop    %rbp
  0x000000011155ea96: test   %eax,-0x62ca9c(%rip)        # 0x0000000110f32000
                                                ;   {poll_return}
  0x000000011155ea9c: retq   

For tiered compilation i do see code generated with a test, jump and de-opt:

  0x00000001112fe020: mov    %eax,-0x14000(%rsp)
  0x00000001112fe027: push   %rbp
  0x00000001112fe028: sub    $0x30,%rsp
  0x00000001112fe02c: mov    $0x125633860,%rax  ;   {metadata(method data for {method} {0x0000000125633508} 'x' '(I)I' in 'Y')}
  0x00000001112fe036: mov    0xdc(%rax),%edi
  0x00000001112fe03c: add    $0x8,%edi
  0x00000001112fe03f: mov    %edi,0xdc(%rax)
  0x00000001112fe045: mov    $0x125633508,%rax  ;   {metadata({method} {0x0000000125633508} 'x' '(I)I' in 'Y')}
  0x00000001112fe04f: and    $0x1ff8,%edi
  0x00000001112fe055: cmp    $0x0,%edi
  0x00000001112fe058: je     0x00000001112fe07f  ;*getstatic X
                                                ; - Y::x at 0 (line 43)

  0x00000001112fe05e: mov    $0x125633860,%rax  ;   {metadata(method data for {method} {0x0000000125633508} 'x' '(I)I' in 'Y')}
  0x00000001112fe068: incl   0x118(%rax)        ;*ifne
                                                ; - Y::x at 3 (line 43)

  0x00000001112fe06e: mov    %rdx,%rax
  0x00000001112fe071: add    %edx,%eax
  0x00000001112fe073: add    $0x30,%rsp
  0x00000001112fe077: pop    %rbp
  0x00000001112fe078: test   %eax,-0x62f07e(%rip)        # 0x0000000110ccf000
                                                ;   {poll_return}
  0x00000001112fe07e: retq   
  0x00000001112fe07f: mov    %rax,0x8(%rsp)
  0x00000001112fe084: movq   $0xffffffffffffffff,(%rsp)
  0x00000001112fe08c: callq  0x0000000110e63c60  ; OopMap{rsi=Oop off=145}
                                                ;*synchronization entry
                                                ; - Y::x at -1 (line 43)
                                                ;   {runtime_call}

But the method gets compiled later on to the shape of the former code e.g.:

    471   16       3       Y::x (22 bytes)
    472   17       4       Y::x (22 bytes)
    472   16       3       Y::x (22 bytes)   made not entrant



>  Perhaps we could do without the C2 builtins but they
> cost very little, they save C2 a fair amount of work, and they remove
> the vagaries of inlining.

Tis true, the changes are small.


>  I take your point about the interpreter,
> though.
> 
>> I see you optimized the unaligned getLong by reading two aligned longs and then bit twiddled. It seems harder to optimize the putLong by straddling an aligned putInt with one to three required putByte.
> 
> Sure, that's always a possibility.  I have code to do it but it was
> all getting rather complicated for my taste.

I thought it might.


> 
>>> Also, these methods have the additional benefit that they are always atomic as long as the data are naturally aligned.
>> 
>> We should probably document that in general access is not guaranteed to be atomic and an implementation detail that it currently is when naturally so.
> 
> I think that's a good idea.  The jcstress tests already come up with a
> warning that the implementation is not atomic; this is not required,
> but a high-quality implementation will be.
> 
>>> This does result in rather a lot of code for the methods for all sizes and endiannesses, but none of it will be used on machines with unaligned hardware support except in the interpreter.  (Perhaps the interpreter too could have intrinsics?)
>>> 
>>> I have changed HeapByteBuffer to use these methods, with a major performance improvement.  I've also provided Unsafe methods to query endianness and alignment support.
>> 
>> If we expose the endianness query via a new method in unsafe we should reuse that in java.nio.Bits and get rid of the associated static code block.
> 
> Sure, I already did that.
> 

Locally i guess? (just in case i missed something in the current webrev).

Paul.


From aph at redhat.com  Tue Feb 24 14:59:02 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 24 Feb 2015 14:59:02 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <56383544-CB43-4521-A2E4-E22B48E24B73@oracle.com>
References: <54EB6DD1.4090803@redhat.com>	<9C5507AD-AACE-45EF-9845-0C1DF6C10893@oracle.com>	<54EC8116.3080006@redhat.com>
	<56383544-CB43-4521-A2E4-E22B48E24B73@oracle.com>
Message-ID: <54EC91B6.60803@redhat.com>

On 02/24/2015 02:47 PM, Paul Sandoz wrote:
> On Feb 24, 2015, at 2:48 PM, Andrew Haley <aph at redhat.com> wrote:

>>> With that in mind is there any need to intrinsify the new methods
>>> at all given those new Java methods can defer to the older ones
>>> based on a constant check? Also should that anyway be done for the
>>> interpreter?
>>>
>>> public void putIntUnaligned(Object o, long offset, int x) { if (IS_UNALIGNED || (offset & 3) == 0) { putInt(o, offset, x); } else if (byteOrder == BIG_ENDIAN) { putIntB(o, offset, x); } else { putIntL(o, offset, x); } }
>>
>> Yes.  It certainly could be done like this but I think C1 doesn't do
>> the optimization to remove the IS_UNALIGNED test, so we'd still want
>> the C1 builtins.
> 
> Hmm.... if i run the following code on my Mac:
> 
> 
>     public int x(int i) {
>         if (X || (i & 3) == 0) {
>             return i + i;
>         }
>         else {
>             return Integer.sum(i, i);
>         }
>     }

> With the options:
> 
>   -XX:TieredStopAtLevel=1 -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly
> 
> Then Y.x is compiled to:
> 
>   0x000000011155ea80: mov    %eax,-0x14000(%rsp)
>   0x000000011155ea87: push   %rbp
>   0x000000011155ea88: sub    $0x30,%rsp         ;*getstatic X
>                                                 ; - Y::x at 0 (line 43)
> 
>   0x000000011155ea8c: mov    %rdx,%rax
>   0x000000011155ea8f: add    %edx,%eax
>   0x000000011155ea91: add    $0x30,%rsp
>   0x000000011155ea95: pop    %rbp
>   0x000000011155ea96: test   %eax,-0x62ca9c(%rip)        # 0x0000000110f32000
>                                                 ;   {poll_return}
>   0x000000011155ea9c: retq   

Oh, right, better than I thought.  I should know by now to check
before posting.  But even so, we don't know that the method will
be inlined.

>>> If we expose the endianness query via a new method in unsafe we
>>> should reuse that in java.nio.Bits and get rid of the associated
>>> static code block.
>>
>> Sure, I already did that.
>>
> 
> Locally i guess? (just in case i missed something in the current webrev).

Ah.  I used the query but I forgot to get rid of the static code
block:

http://cr.openjdk.java.net/~aph/unaligned.jdk.1/src/java.base/share/classes/java/nio/Bits.java.cdiff.html

Andrew.


From chris.hegarty at oracle.com  Tue Feb 24 15:07:20 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 24 Feb 2015 15:07:20 +0000
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <54EC6464.8090608@gmail.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com> <54E71BC3.30403@oracle.com>
	<54E74E29.2060806@gmail.com> <54EB08A5.4000905@oracle.com>
	<54EB96B8.30304@gmail.com>
	<DAFD881E-4105-4140-AEEC-7724A5C84C6D@oracle.com>
	<54EC6464.8090608@gmail.com>
Message-ID: <2A98B462-287D-43C1-99FA-8CF58BCA93BB@oracle.com>

On 24 Feb 2015, at 11:45, Peter Levart <peter.levart at gmail.com> wrote:

>> ...
>>> - You are tracking the requiresFreeze flag in readSerialData() method for each class slot the deserialized object is composed of. This can be optimized and the 'hasFinalField' flag pre-computed for the whole object (all slots) and stored in ObjestStreamClass as such.
>> I don?t see how your proposed changes are any more performant ( all that has happened is that the call to hasFinal has been moved inside the loop in getClassDataLayout0 ), and it is more difficult, at least for me, to grok ( and has an additional context dependency ). Is your concern the reading of the requiresFreeze field in readSerialData? Would making this a local field in the loop address your concern?
> 
> The loop in getClassDataLayout0 is only executed once per ObjectStreamClass (the layout is then cached). The loop in readSerialData() is executed for each object instance deserialized.

Ok, got it now.

> Considering the results of Alexey's research:
> 
> http://shipilev.net/blog/2014/all-fields-are-final/
> 
> He came to conclusion that even in constructors that just set fields and do no complex logic like deserialization, the relative overhead of freeze is minimal. So we might be better off just issuing the freeze unconditionally and not bother with tracking which might have more overhead even for very small streams (for example one object with few ints).

Yes, I read this before. Very interesting.

>>> - We have to be careful with "loosening" of volatile writes to final fields in custom readObject() methods (BigDecimal.intCompact for example) especialy if they are writes to fields that are not serial fields in ObjectStreamClass (either they are transient or not listed in serialPersistentFields). By doing that, you are relying on the fact that default deserialization (defaultReadObject() call in case of BigDecimal) tracks at least one other final field that is also serial field. This is the case with BigDecimal and BigInteger, but in general it is not.
>> I agree, we need to be careful here, but as you say these two specific cases should be fine.
> 
> And if the freeze is unconditional, we don't have to worry at all.

If we can accept the cost of an unconditional freeze ( yet to be compared against the cost of tracking ), then this is a very nice property, arguably worth accepting a small cost for ( if only to prevent trying to reason about transient final fields ).

>>> It will be interesting how tracking will be implemented most efficiently when FieldAccess API appears, but that's another story?
>> I think the work-in-progress FieldAccess API will really help here, but for now I?d like to proceed with changing these two cases, and they can be retrofitted when the new API is available.
> 
> Agreed.
> 
>> 
>>> So I propose the following variant for now (including just ObjectInputStream and ObjectStreamClass) that fixes 1st two issues above. I suggest waiting with BigDecimal/BigInteger changes until FieldAccess API is available and throw away Unsafe usage alltogether at that point:
>>> 
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ObjectInputStream.freeze/webrev.01/
>> It was really helpful to have a webrev to put your comments in context. Thanks.
>> 
>> Updated webrev, including all comments/changes so far:
>>   http://cr.openjdk.java.net/~chegar/deserialFence/webrev.03/webrev/
> 
> That's better now. Let me just try to measure the overhead of tracking on simple objects to see if it actually pays off or is contra-productive in any case.

Thanks. I?ll see if I can get some measurements also.

-Chris.


> Regards, Peter
> 
>> 
>> -Chris.
>> 
>> 
>>> Regards, Peter
>>> 
>>> 
>>>> On 20/02/15 15:09, Peter Levart wrote:
>>>>> ...
>>>>> This looks good now. But I wonder if issuing fences after nested calls
>>>>> to readObject() makes much sense. If cycles are present in a subgraph
>>>>> deserialized by nested call to readObject(), a field pointing back to an
>>>>> object not part of the subgraph stream will point to the object that
>>>>> will not be fully initialized yet, so nested calls to readObject()
>>>>> should not be expected to return a reference to a fully constructed
>>>>> subgraph anyway. Only top-level call is guaranteed to return a fully
>>>>> constructed graph.
>>>> Right. I was never convinced of this myself either. Removed. Unnecessary complication.
>>>> 
>>>>> If you optimize this and only issue one fence for top-level call to
>>>>> readObject(), tracking of 'requiresFence' (I would call it
>>>>> requiresFreeze to be in line with JMM terminology - the fence is just a
>>>> 'requiresFreeze' is better. Updated
>>>> 
>>>>> way to achieve freeze) can also be micro-optimized. You currently do it
>>>>> like this:
>>>>> 
>>>>> 1900             requiresFence |= slotDesc.hasFinalField();
>>>>> 
>>>>> which is a shortcut for:
>>>>> 
>>>>> requiresFence = requiresFence | slotDesc.hasFinalField();
>>>>> 
>>>>> ...which means that the field is overwritten multiple times
>>>>> unnecessarily and slotDesc.hasFinalField() is called every time. You can
>>>>> write the same logic as:
>>>>> 
>>>>> if (!requiresFence && slotDesc.hasFinalField()) {
>>>>>      requiresFence = true;
>>>>> }
>>>> ... and it is more readable. Updated.
>>>> 
>>>>> There will be at most one write to the field and potentially less calls
>>>>> to slotDesc.hasFinalField().
>>>> -Chris.



From paul.sandoz at oracle.com  Tue Feb 24 15:08:18 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 24 Feb 2015 16:08:18 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54EC91B6.60803@redhat.com>
References: <54EB6DD1.4090803@redhat.com>	<9C5507AD-AACE-45EF-9845-0C1DF6C10893@oracle.com>	<54EC8116.3080006@redhat.com>
	<56383544-CB43-4521-A2E4-E22B48E24B73@oracle.com>
	<54EC91B6.60803@redhat.com>
Message-ID: <AA2BE853-01CD-4D7B-AD53-346E893F3D4B@oracle.com>

On Feb 24, 2015, at 3:59 PM, Andrew Haley <aph at redhat.com> wrote:
> 
>>>> If we expose the endianness query via a new method in unsafe we
>>>> should reuse that in java.nio.Bits and get rid of the associated
>>>> static code block.
>>> 
>>> Sure, I already did that.
>>> 
>> 
>> Locally i guess? (just in case i missed something in the current webrev).
> 
> Ah.  I used the query but I forgot to get rid of the static code
> block:
> 
> http://cr.openjdk.java.net/~aph/unaligned.jdk.1/src/java.base/share/classes/java/nio/Bits.java.cdiff.html
> 

We are talking about different queries :-) (although the doPrivileged can now go).

I was referring to:

 570     private static final ByteOrder byteOrder;
 571 
...

 577 
 578     static {
 579         long a = unsafe.allocateMemory(8);
 580         try {
 581             unsafe.putLong(a, 0x0102030405060708L);
 582             byte b = unsafe.getByte(a);
 583             switch (b) {
 584             case 0x01: byteOrder = ByteOrder.BIG_ENDIAN;     break;
 585             case 0x08: byteOrder = ByteOrder.LITTLE_ENDIAN;  break;
 586             default:
 587                 assert false;
 588                 byteOrder = null;
 589             }
 590         } finally {
 591             unsafe.freeMemory(a);
 592         }
 593     }

Which i think could be replaced with:

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

Paul.


From peter.levart at gmail.com  Tue Feb 24 15:40:59 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 24 Feb 2015 16:40:59 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54EC8116.3080006@redhat.com>
References: <54EB6DD1.4090803@redhat.com>	<9C5507AD-AACE-45EF-9845-0C1DF6C10893@oracle.com>
	<54EC8116.3080006@redhat.com>
Message-ID: <54EC9B8B.9010505@gmail.com>

On 02/24/2015 02:48 PM, Andrew Haley wrote:
>> >private static final boolean IS_UNALIGNED = theUnsafe.unalignedAccess();
>> >
>> >public void putIntUnaligned(Object o, long offset, int x) { if (IS_UNALIGNED || (offset & 3) == 0) { putInt(o, offset, x); } else if (byteOrder == BIG_ENDIAN) { putIntB(o, offset, x); } else { putIntL(o, offset, x); } }
> Yes.  It certainly could be done like this but I think C1 doesn't do
> the optimization to remove the IS_UNALIGNED test, so we'd still want
> the C1 builtins.  Perhaps we could do without the C2 builtins but they
> cost very little, they save C2 a fair amount of work, and they remove
> the vagaries of inlining.  I take your point about the interpreter,
> though.
>

What about if you make unalignedAccess() and getByteOrder() static 
methods in Unsafe (they are safe aren't they?) and then do the following:

public abstract class Unsafe {
...
private static final Unsafe theUnsafe =
   unalignedAccess()
     ? (getByteOrder() ? new UnsafeUB() : new UnsafeUL())
     : (getByteOrder() ? new UnsafeAB() : new UnsafeAL());
...
     public abstract int getIntUnaligned(Object o, long offset);
...
   private static final class UnsafeUB extends Unsafe { ... }
   private static final class UnsafeUL extends Unsafe { ... }
   private static final class UnsafeAB extends Unsafe { ... }
   private static final class UnsafeAL extends Unsafe { ... }


There will be only one runtime Unsafe sub-type ever observed in a 
particular VM.

Peter



From aph at redhat.com  Tue Feb 24 15:49:15 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 24 Feb 2015 15:49:15 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54EC9B8B.9010505@gmail.com>
References: <54EB6DD1.4090803@redhat.com>	<9C5507AD-AACE-45EF-9845-0C1DF6C10893@oracle.com>
	<54EC8116.3080006@redhat.com> <54EC9B8B.9010505@gmail.com>
Message-ID: <54EC9D7B.1000702@redhat.com>

On 02/24/2015 03:40 PM, Peter Levart wrote:
> On 02/24/2015 02:48 PM, Andrew Haley wrote:
>>>> private static final boolean IS_UNALIGNED = theUnsafe.unalignedAccess();
>>>>
>>>> public void putIntUnaligned(Object o, long offset, int x) { if (IS_UNALIGNED || (offset & 3) == 0) { putInt(o, offset, x); } else if (byteOrder == BIG_ENDIAN) { putIntB(o, offset, x); } else { putIntL(o, offset, x); } }
>> Yes.  It certainly could be done like this but I think C1 doesn't do
>> the optimization to remove the IS_UNALIGNED test, so we'd still want
>> the C1 builtins.  Perhaps we could do without the C2 builtins but they
>> cost very little, they save C2 a fair amount of work, and they remove
>> the vagaries of inlining.  I take your point about the interpreter,
>> though.
>>
> 
> What about if you make unalignedAccess() and getByteOrder() static 
> methods in Unsafe (they are safe aren't they?) and then do the following:
> 
> public abstract class Unsafe {
> ...
> private static final Unsafe theUnsafe =
>    unalignedAccess()
>      ? (getByteOrder() ? new UnsafeUB() : new UnsafeUL())
>      : (getByteOrder() ? new UnsafeAB() : new UnsafeAL());
> ...
>      public abstract int getIntUnaligned(Object o, long offset);
> ...
>    private static final class UnsafeUB extends Unsafe { ... }
>    private static final class UnsafeUL extends Unsafe { ... }
>    private static final class UnsafeAB extends Unsafe { ... }
>    private static final class UnsafeAL extends Unsafe { ... }
> 
> 
> There will be only one runtime Unsafe sub-type ever observed in a 
> particular VM.

Oh, that's very nice.

Thanks,
Andrew.




From kumar.x.srinivasan at oracle.com  Tue Feb 24 16:17:29 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 24 Feb 2015 08:17:29 -0800
Subject: Please review: 8066185: VM crashed with SIGSEGV
	VirtualMemoryTracker::add_reserved_region
In-Reply-To: <54EBDD6B.5070404@oracle.com>
References: <54EBA658.6020001@oracle.com> <54EBDD6B.5070404@oracle.com>
Message-ID: <54ECA419.5090507@oracle.com>

Hi David,

comments inlined.

> Hi Kumar,
>
> On 24/02/2015 8:14 AM, Kumar Srinivasan wrote:
>> Hello,
>>
>> Please review the fix for the above issue.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ksrini/8066185/webrev.00/
>>
>> The fix is self explanatory, as for the test I have done the following:
>
> I found the comment:
>
>           /*
> +          * Since this is a VM flag, we need to ensure it is not an
> +          * application argument, meaning the argument must precede
> +          * the main class or those flags that invoke the VM directly.
> +          */
>
> a bit confusing - specifically the "or those flags that invoke the VM 
> directly". Took me while to realize that all the args you treat 
> specially (-version, -h, -jar etc) are all "terminal" arguments - 
> either the launcher stops looking at args after the given arg, or all 
> following args must be for the application, not the launcher or VM. I 
> would have expressed this as:
>
>   /*
>    * Since this must be a VM flag we stop processing once we see
>    * an argument the launcher would not have processed beyond (such
>    * as -version or -h), or an argument that indicates the following
>    * arguments are for the application (i.e. the main class name, or
>    * the -jar argument).
>    */
>
>
+1,  I have updated the webrev with your comments, also had an AHA moment,
I realized, had missed -X, which prints the XUsage, added this to the logic
and test.

>> a. refactored it from a single longish test to sub-tests for 
>> readability.
>> b. added new sub-test for NMT Argument Processing checks.
>
> Can you please update the @summary for that test. It seems the OSX 
> specific test was hijacked for NMT arg testing and the summary was 
> never updated to reflect that.

This test was "commandeered" :-) for other purposes, updated the summary to
describe what is being performed.

Webrev to last reviewed:
http://cr.openjdk.java.net/~ksrini/8066185/webrev.01/webrev.delta/index.html

Full webrev:
http://cr.openjdk.java.net/~ksrini/8066185/webrev.01/index.html

Thanks.
Kumar

>
> Thanks,
> David
>
>> Thanks
>> Kumar
>>



From ivan.gerasimov at oracle.com  Tue Feb 24 16:44:33 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 24 Feb 2015 19:44:33 +0300
Subject: RFR | 8073779: StackOverflowError called StackOverflowException in
	javadoc
Message-ID: <54ECAA71.6070603@oracle.com>

Hi!

A typo populated over a few places.

Fix: s/StackOverflowException/StackOverflowError/g

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

Sincerely yours,
Ivan


From martinrb at google.com  Tue Feb 24 16:46:14 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 24 Feb 2015 08:46:14 -0800
Subject: RFR | 8073779: StackOverflowError called StackOverflowException
	in javadoc
In-Reply-To: <54ECAA71.6070603@oracle.com>
References: <54ECAA71.6070603@oracle.com>
Message-ID: <CA+kOe08GEug=r-tNwXL4B2Ykxy0M28N-keDFuYu_JgoXpnFp3w@mail.gmail.com>

Approved!

On Tue, Feb 24, 2015 at 8:44 AM, Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

> Hi!
>
> A typo populated over a few places.
>
> Fix: s/StackOverflowException/StackOverflowError/g
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8073779
> WEBREV: http://cr.openjdk.java.net/~igerasim/8073779/0/webrev/
>
> Sincerely yours,
> Ivan
>


From ivan.gerasimov at oracle.com  Tue Feb 24 16:51:47 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 24 Feb 2015 19:51:47 +0300
Subject: RFR | 8073779: StackOverflowError called StackOverflowException
	in javadoc
In-Reply-To: <CA+kOe08GEug=r-tNwXL4B2Ykxy0M28N-keDFuYu_JgoXpnFp3w@mail.gmail.com>
References: <54ECAA71.6070603@oracle.com>
	<CA+kOe08GEug=r-tNwXL4B2Ykxy0M28N-keDFuYu_JgoXpnFp3w@mail.gmail.com>
Message-ID: <54ECAC23.6070900@oracle.com>

Thanks!

pushed.

On 24.02.2015 19:46, Martin Buchholz wrote:
> Approved!
>
> On Tue, Feb 24, 2015 at 8:44 AM, Ivan Gerasimov 
> <ivan.gerasimov at oracle.com <mailto:ivan.gerasimov at oracle.com>> wrote:
>
>     Hi!
>
>     A typo populated over a few places.
>
>     Fix: s/StackOverflowException/StackOverflowError/g
>
>     BUGURL: https://bugs.openjdk.java.net/browse/JDK-8073779
>     WEBREV: http://cr.openjdk.java.net/~igerasim/8073779/0/webrev/
>     <http://cr.openjdk.java.net/%7Eigerasim/8073779/0/webrev/>
>
>     Sincerely yours,
>     Ivan
>
>



From sean.coffey at oracle.com  Tue Feb 24 16:53:29 2015
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Tue, 24 Feb 2015 16:53:29 +0000
Subject: RFR | 8073779: StackOverflowError called StackOverflowException
	in javadoc
In-Reply-To: <54ECAA71.6070603@oracle.com>
References: <54ECAA71.6070603@oracle.com>
Message-ID: <54ECAC89.7050502@oracle.com>

Nice catch Ivan. You could also clean up the typo in various test cases 
relating to it also perhaps :

langtools/test/tools/javac/generics/inference/8043725/T8043725.java
jdk/test/java/util/Hashtable/SelfRef.java
jdk/test/javax/swing/border/Test6461042.java
langtools/test/tools/javac/defaultMethods/Pos13.java
jdk/test/java/util/Spliterator/SpliteratorCollisions.java
jdk/test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
jdk/test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java

regards,
Sean.

On 24/02/2015 16:44, Ivan Gerasimov wrote:
> Hi!
>
> A typo populated over a few places.
>
> Fix: s/StackOverflowException/StackOverflowError/g
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8073779
> WEBREV: http://cr.openjdk.java.net/~igerasim/8073779/0/webrev/
>
> Sincerely yours,
> Ivan



From ivan.gerasimov at oracle.com  Tue Feb 24 17:08:08 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 24 Feb 2015 20:08:08 +0300
Subject: RFR | 8073779: StackOverflowError called StackOverflowException
	in javadoc
In-Reply-To: <54ECAC89.7050502@oracle.com>
References: <54ECAA71.6070603@oracle.com> <54ECAC89.7050502@oracle.com>
Message-ID: <54ECAFF8.60603@oracle.com>

Right. I shouldn't have pushed it that quick. Sigh

On 24.02.2015 19:53, Se?n Coffey wrote:
> Nice catch Ivan. You could also clean up the typo in various test 
> cases relating to it also perhaps :
>
> langtools/test/tools/javac/generics/inference/8043725/T8043725.java
> jdk/test/java/util/Hashtable/SelfRef.java
> jdk/test/javax/swing/border/Test6461042.java
> langtools/test/tools/javac/defaultMethods/Pos13.java
> jdk/test/java/util/Spliterator/SpliteratorCollisions.java
> jdk/test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
> jdk/test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java 
>
>
> regards,
> Sean.
>
> On 24/02/2015 16:44, Ivan Gerasimov wrote:
>> Hi!
>>
>> A typo populated over a few places.
>>
>> Fix: s/StackOverflowException/StackOverflowError/g
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8073779
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8073779/0/webrev/
>>
>> Sincerely yours,
>> Ivan
>
>
>



From sean.coffey at oracle.com  Tue Feb 24 17:13:52 2015
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Tue, 24 Feb 2015 17:13:52 +0000
Subject: RFR | 8073779: StackOverflowError called StackOverflowException
	in javadoc
In-Reply-To: <54ECAFF8.60603@oracle.com>
References: <54ECAA71.6070603@oracle.com> <54ECAC89.7050502@oracle.com>
	<54ECAFF8.60603@oracle.com>
Message-ID: <54ECB150.4010105@oracle.com>


On 24/02/2015 17:08, Ivan Gerasimov wrote:
> Right. I shouldn't have pushed it that quick. Sigh
Nothing important. Just thought it might be a useful step while you were 
there! It's something we can keep in mind for a later fix.

regards,
Sean.

>
> On 24.02.2015 19:53, Se?n Coffey wrote:
>> Nice catch Ivan. You could also clean up the typo in various test 
>> cases relating to it also perhaps :
>>
>> langtools/test/tools/javac/generics/inference/8043725/T8043725.java
>> jdk/test/java/util/Hashtable/SelfRef.java
>> jdk/test/javax/swing/border/Test6461042.java
>> langtools/test/tools/javac/defaultMethods/Pos13.java
>> jdk/test/java/util/Spliterator/SpliteratorCollisions.java
>> jdk/test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java 
>>
>> jdk/test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java 
>>
>>
>> regards,
>> Sean.
>>
>> On 24/02/2015 16:44, Ivan Gerasimov wrote:
>>> Hi!
>>>
>>> A typo populated over a few places.
>>>
>>> Fix: s/StackOverflowException/StackOverflowError/g
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8073779
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8073779/0/webrev/
>>>
>>> Sincerely yours,
>>> Ivan
>>
>>
>>
>



From coleen.phillimore at oracle.com  Tue Feb 24 18:21:06 2015
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 24 Feb 2015 13:21:06 -0500
Subject: Please review: 8066185: VM crashed with SIGSEGV
	VirtualMemoryTracker::add_reserved_region
In-Reply-To: <54EBDD6B.5070404@oracle.com>
References: <54EBA658.6020001@oracle.com> <54EBDD6B.5070404@oracle.com>
Message-ID: <54ECC112.5090202@oracle.com>


Kumar,

This looks good to me.  I didn't review all the changes in the test very 
carefully, so someone else should vouch for that.

Thank you for fixing this!

Coleen

On 2/23/15, 9:09 PM, David Holmes wrote:
> Hi Kumar,
>
> On 24/02/2015 8:14 AM, Kumar Srinivasan wrote:
>> Hello,
>>
>> Please review the fix for the above issue.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ksrini/8066185/webrev.00/
>>
>> The fix is self explanatory, as for the test I have done the following:
>
> I found the comment:
>
>           /*
> +          * Since this is a VM flag, we need to ensure it is not an
> +          * application argument, meaning the argument must precede
> +          * the main class or those flags that invoke the VM directly.
> +          */
>
> a bit confusing - specifically the "or those flags that invoke the VM 
> directly". Took me while to realize that all the args you treat 
> specially (-version, -h, -jar etc) are all "terminal" arguments - 
> either the launcher stops looking at args after the given arg, or all 
> following args must be for the application, not the launcher or VM. I 
> would have expressed this as:
>
>   /*
>    * Since this must be a VM flag we stop processing once we see
>    * an argument the launcher would not have processed beyond (such
>    * as -version or -h), or an argument that indicates the following
>    * arguments are for the application (i.e. the main class name, or
>    * the -jar argument).
>    */
>
>
>> a. refactored it from a single longish test to sub-tests for 
>> readability.
>> b. added new sub-test for NMT Argument Processing checks.
>
> Can you please update the @summary for that test. It seems the OSX 
> specific test was hijacked for NMT arg testing and the summary was 
> never updated to reflect that.
>
> Thanks,
> David
>
>> Thanks
>> Kumar
>>



From forax at univ-mlv.fr  Tue Feb 24 18:28:55 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 24 Feb 2015 19:28:55 +0100
Subject: RFR (S) 8073479: Replace obj.getClass hacks
	with	Objects.requireNonNull
In-Reply-To: <D08DF39A-BB1F-4534-B2E7-0517934F8690@oracle.com>
References: <54E5F88F.6030502@oracle.com> <54E5FA36.7030206@gmail.com>
	<54E5FB07.6030400@oracle.com> <54E5FE88.4000705@gmail.com>
	<54E62ADC.1070501@oracle.com> <54E72D07.2020707@gmail.com>
	<54E733F1.7080705@oracle.com>
	<CAHjP37GdqvSNT8u-oevHda7d76WEU1gOVwr6Rg+hOw0G9Am6zA@mail.gmail.com>
	<D08DF39A-BB1F-4534-B2E7-0517934F8690@oracle.com>
Message-ID: <A9519323-315F-40FB-8608-1599A4BB7EA8@univ-mlv.fr>

Can you add 5.1 to your list ? :)
If we had AOT, small methods will be inlined and sharing their profile in that case seems just wrong.

As you said it will also make tiered compilation smarter.

R?mi 

Le 22 f?vrier 2015 01:58:02 CET, John Rose <john.r.rose at oracle.com> a ?crit :
>All of the proposed tweaks to null checks fall down for somebody, some
>time.
>
>The reason Object.getClass was being used in that twisty way is to get
>early placement of the null check.  Receiver null checks are performed
>at the call site, instead of inside the shared callee method.  So the
>trick of getClass is that you get to use the per-call-site profiling
>(of the receiver null check).
>
>There are several possible ways to "fix" Objects.requireNonNull so that
>it resists profile pollution.
>
>1. Special pleading:  Assume if the internal profile for O.rNN says
>"nulls have appeared here", that's uniquely ignorable.  A dirty hack,
>perhaps justifiable.  This could be done a couple of ways:
>
>1.1 Compiler intrinsic:  Make O.rNN into a compiler intrinsic.  Then we
>have our way with it.
>
>1.2 Profile injection:  Modify the JDK code of O.rNN to declare that
>the profile should be special-cased.  It would be something like a
>"NOTREACHED" pragma.  We used this technique in JDK-8063137.  A simpler
>form could apply here also.  This technique is better, since it leaves
>a clear "footprint" in the Java code that something is happening.
>
>2. Adopt ignorance:  Keep the implicit null check optimization (using
>OS traps, as Remi described).  But, stop using nullness profiles to
>disable this optimization, for some general class of methods which
>includes O.rNN.  The problem with this there are 0.001% places where
>null check exceptions are on warm paths, and those customers will get
>trap storms.
>
>3. Stop optimizing:  Ditch the implicit null check optimization; use
>explicitly coded null checks.  This is a straw man, since the code
>density and path length would degrade for no particular benefit.  (Some
>null checks are elidable based on local type inference, but a stubborn
>percentage are not.  PrintOptoStatistics tracks these numbers.)
>
>4. Stop optimizing when the profile is polluted, which is the status
>quo.  Aleksey has some evidence we lose a mere 1/3 of a machine cycle
>on some machines, with a polluted O.rNN.  I assume this requires good
>branch prediction and prefetch.  The HotSpot project includes
>optimizations to assist machines with poor branch prediction or
>prefetch, for various reasons I won't go into.  The implicit null
>checks are such optimizations.  If O.rNN is going to be a full
>replacement for explicit null checks, we need to make sure it can't
>suddenly change its performance characteristics, because one client has
>fed it nulls.
>
>5. Refine profiling:  Somehow gather profile information (at least
>nullness) on the operand to O.rNN, before it leaves user code and
>arrives in the shared (profile-pollutable) code of O.rNN.  There are
>several ways to do this, including:
>
>5.1 Perform profiling in Tier One code, including inlined copies of
>O.rNN and any other trivial-enough function.  Use the context-specific
>profiles in Tier Two.  We have not developed this very far.
>
>5.2 Perform argument profiling.  Set TypeProfileLevel=2 by default, or
>use some other logic that enhances argument profiling of calls to
>O.rNN.  This probably also needs more work.
>
>I think 1.2 and 5.2 are worth working on.
>
>? John
>
>On Feb 20, 2015, at 6:20 AM, Vitaly Davidovich <vitalyd at gmail.com>
>wrote:
>> 
>> I really hope this doesn't require intrinsifying requireNonNull
>since, as
>> mentioned before, this is a general issue.  I'm almost tempted to say
>that
>> JIT should always treat a null check followed by an explicit NPE as
>being
>> an uncommon path, despite what profile may say.
>> 
>> sent from my phone
>> On Feb 20, 2015 8:18 AM, "Aleksey Shipilev"
><aleksey.shipilev at oracle.com>
>> wrote:
>> 
>>> Hi Peter,
>>> 
>>> Thanks for additional testing!
>>> 
>>> On 02/20/2015 03:48 PM, Peter Levart wrote:
>>>> So we hope for Objects.requireNonNull to be inlined most of the
>times.
>>> 
>>> Yes, I think so, otherwise it is a platform bug :) And, as I said in
>>> reply to Vitaly, the ultimate answer would be to intrinsify
>>> Objects.requireNonNull to unconditionally bias it towards the
>non-null
>>> case and implicit NP checks.
>>> 
>>> The test is actually specifically crafted to amplify the costs of
>the
>>> pollution. The side effect of that method is excessive method calls.
>>> It's not a surprise CPUs can execute the dense code oblivious of
>minor
>>> code differences. (Speculation: CPUs need to re-adjust their
>pipelines
>>> after the real call, so non-inlined version would pay some extra)
>>> 
>>> Thanks,
>>> -Aleksey
>>> 
>>> 
>>> 

-- 
Envoy? de mon t?l?phone Android avec K-9 Mail. Excusez la bri?vet?.


From sean.mullan at oracle.com  Tue Feb 24 20:40:30 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 24 Feb 2015 15:40:30 -0500
Subject: Review Request: 8073361: Missing doPrivileged in
	com.sun.xml.internal.bind.v2.ClassFactory
In-Reply-To: <54E782FF.9010801@oracle.com>
References: <54E782FF.9010801@oracle.com>
Message-ID: <54ECE1BE.70406@oracle.com>

This fix looks fine.

--Sean

On 02/20/2015 01:54 PM, Mandy Chung wrote:
> This fixes a regression due to JDK-8057645 moving JAXB to ext loader
> that was tested before the fix for JDK-8054367 went in jdk9.  This
> was uncovered after JDK-8057645and JDK-8054367 met.
>
> The fix is simple.  Class.getDeclaredConstructor on a class defined
> by the null loader will require RuntimePermission("accessDeclaredMembers")
> check that needs to be wrapped with doPrivileged block.
>
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8073361/webrev.00/
>
> It doesn't change the behavior as previously when JAXB was loaded
> by the null class loader that it always has access to any declared
> member of any class (it's the ancestor of all class loaders).
>
> Mandy
> [1] http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/ef93f7aa0d2f


From martinrb at google.com  Tue Feb 24 21:14:07 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 24 Feb 2015 13:14:07 -0800
Subject: RFR 9 8055330: (process spec) ProcessBuilder.start and
	Runtime.exec should throw UnsupportedOperationException ...
In-Reply-To: <BLU175-W52F51DB26CB33B714F056E832B0@phx.gbl>
References: <54CBAA39.3050004@Oracle.com>
	<CA+kOe0_iz0HFeYu1X2qFsaYnZCh7X+EMUi0Mt9-Eh5s9zfb7hA@mail.gmail.com>
	<CA+kOe0_GNvaFbKf25_1Jm1PSBjvod8fVi9DBcYk7S44nzRkBaA@mail.gmail.com>
	<54CD4305.4080607@oracle.com>
	<CA+kOe09J2jd=qVBuwm9M6nsqsbF4a+Pe_XaF_WzfJ9sk=7cTyQ@mail.gmail.com>
	<CA+kOe0--_D-vcfh8nooBy32bxQc4pM0R92qAnt_FymGrBVQtVw@mail.gmail.com>
	<54CF7D1F.6050101@Oracle.com>
	<CA+kOe09J=B70+Nk8hkxfdT-WjHX065Cvj9sxNLb00nY_Qj7LUQ@mail.gmail.com>
	<54CFE064.70400@Oracle.com>
	<CA+kOe0-zPJRpGEa0zXy6_bHgwNcnFWuSc1fbbxsc7-nc6SUjAg@mail.gmail.com>
	<54D08997.9020300@oracle.com>
	<CA+kOe091FHtd1Mnz_eVLcP0a_fC-+nXPGjnEdYr706XguBTy=g@mail.gmail.com>
	<54DBBA84.7090108@Oracle.com>
	<CA+kOe08VHA6h=6xVipyZ-xEx-XFBJ_mfd48GcnGJMaU0hQMQVA@mail.gmail.com>
	<54DC6D4B.3070902@oracle.com>
	<CA+kOe09QDOBmNRjkJKoSxstb=+EUqWCE3PNXT7Mi_=k2hH=k0Q@mail.gmail.com>
	<BLU175-W160A859502935C3D2894B2832D0@phx.gbl>
	<54E71F5B.8060909@oracle.com>
	<CA+kOe0--qCdqK=x8fKa5afY=GCOOtejMJ7O9YLnDRpDerj4z5A@mail.gmail.com>
	<CA+kOe084OgYxKw3URx04uriKZZ=ioaAsWh7775Emo1PbTODQYw@mail.gmail.com>
	<BLU175-W52F51DB26CB33B714F056E832B0@phx.gbl>
Message-ID: <CA+kOe09cMXBYC7GSuuULdmibZXCs4WRZ8w9vgo7b2DmYnGiDvQ@mail.gmail.com>

I'm not sure I'm convincing anyone other than myself, but here's another
try:

"recover" means taking any action at all, the most common of which is ...
nothing!
Perhaps a product feature simply becomes "grayed out" when running a
process fails.
>From a WORA developer's point of view, it is irrelevant whether failure is
due to complete lack of subprocess support or a "real" IOException.  So I
don't think UOE is ever suitable for these sorts of failures (not just
Process).  But for Process we're making the API worse _AND_ breaking
existing programs.

Here's a more elaborate explanation around Josh's Item 58:
http://stackoverflow.com/questions/3540613/please-explain-runtimeexception-in-java-and-where-it-should-be-used/3540705#3540705


On Sat, Feb 21, 2015 at 2:03 PM, Jason Mehrens <jason_mehrens at hotmail.com>
wrote:

> Hi Roger,
>
> For what it is worth, the most common production use case for me is:
>
> 1. Generate output from some source to a temp file.
> 2. Use ProcessBuilder to launch process (native or JVM) for using temp
> file.
> 3. If that fails with IOException fallback to opening a save dialog.
> 4. The end user will use #2 or #3 to save the file to a known location.
> 5. The end user will finish final product or get it to a machine that
> works then finish the final product.
> 6. (non)Profit.
>
>
> So in this case you wait around for #1 to get done and as long as #2 or #3
> work then #1 wasn't a wasted effort. In the UOE case 3 through 6 are
> skipped which is a bad deal for the end user.  This is 15+ years still in
> production code where the steps were crafted by a natural evolution of the
> Murphy's Law based environment that it exists in.  End of life for this
> code is not in sight.
>
>
> Save your health and don't think too hard about the example, try to apply
> logic to it, or tear it down.  It is not my intent to hold this example up
> as 'the best counter argument', 'sky is falling' or to drag this thread
> out.  The point is, no where in the example does the calling code or user
> care about the distinction between never being able to create a process or
> creating a process failed this time.  For this code, throwing UOE is a
> breaking feature not a bug fix.  The only known thing was the API
> contract.  Everything else was assumed to be broken.
>
>
> I do appreciate your time, Alan's time, the time you have spent on this
> issue, and your arguments as they are logical.  We just differ on applying
> the logic to this case.  I also understand the decision has been made and
> that will be the future.  I'll just have to be prepared for it and Murphy.
>
>
> Respectfully,
>
>
> Jason
>
>
> ----------------------------------------
> > Date: Fri, 20 Feb 2015 13:06:05 -0800
> > Subject: Re: RFR 9 8055330: (process spec) ProcessBuilder.start and
> Runtime.exec should throw UnsupportedOperationException ...
> > From: martinrb at google.com
> > To: Roger.Riggs at oracle.com
> > CC: core-libs-dev at openjdk.java.net
> >
> > I totally disagree about "recoverable condition". Instead of thinking
> > about "recovering", think instead about whether it ever makes sense to
> > catch the resulting exception. See my sample code broken by the switch to
> > UOE.
> >
> > On Fri, Feb 20, 2015 at 11:58 AM, Roger Riggs <Roger.Riggs at oracle.com>
> > wrote:
> >
> >> Hi Martin,
> >>
> >> As I said earlier, launching a Process when process is not implemented
> >> is not a recoverable condition; there are no conditions under which it
> will
> >> succeed. If the application is probing to determine what
> >> is supported on a platform then it should be prepared to handle UOE
> >> or using a test for the specific capability it requires.
> >>
> >> Roger
> >>
> >>
> >>
> >> On 2/20/2015 1:34 PM, Martin Buchholz wrote:
> >>
> >>> One reason I keep pouring salt on this tiny wound is that throwing
> >>> (unchecked) UOE for system-dependent failures when normally IOE is
> thrown
> >>> is a fundamental design mistake for java and its checked exception
> design.
> >>> I think it violates Josh's Effective Java Item 58: Use checked
> exceptions
> >>> for recoverable conditions and runtime exceptions for programming
> errors.
> >>> I don't think it's worth fixing places in jdk8 where this small mistake
> >>> was
> >>> made, but we can at least stop the incompatible worsening of existing
> >>> APIs.
> >>>
> >>> On Fri, Feb 20, 2015 at 3:49 AM, Alan Bateman <Alan.Bateman at oracle.com
> >
> >>> wrote:
> >>>
> >>> On 19/02/2015 21:54, Jason Mehrens wrote:
> >>>>
> >>>> I'm assuming that compatibility is given more weight vs. correcting
> >>>>> choices made in the original design.
> >>>>>
> >>>>> Yes, I think we've spent more than enough time on it. In this case
> >>>>> it's
> >>>>>
> >>>> for a major release only and the compatibility impact seems to be only
> >>>> platforms or implementations that don't support launching of processes
> >>>> today but are running applications that attempt to start processes
> >>>> anyway.
> >>>> So overall it doesn't seem to be something to be overly concerned
> with.
> >>>>
> >>>> -Alan
> >>>>
> >>>>
> >>
>


From john.r.rose at oracle.com  Tue Feb 24 23:18:23 2015
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 24 Feb 2015 15:18:23 -0800
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54EB6DD1.4090803@redhat.com>
References: <54EB6DD1.4090803@redhat.com>
Message-ID: <D2144F00-8A75-44AA-873E-C418A3BF3B43@oracle.com>

On Feb 23, 2015, at 10:13 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> I've been kicking around a few ideas for Unsafe access methods for
> unaligned access to byte arrays and buffers in order to provide
> "whatever second-best mechanism the platform offers".  These would
> provide the base for fast lexicographic array comparisons, etc.
> 
> https://bugs.openjdk.java.net/browse/JDK-8044082

Bravo.  This will help Panama's native data access also.

> If the platform supports unaligned memory accesses, the implementation
> of {get,put}-X-Unaligned is obvious and trivial for both C1 and C2.
> It gets interesting when we want to provide efficient unaligned
> methods on machines with no hardware support.

The HotSpot JVM has repertoire of internal C++ methods for
performing unaligned access.  They will sometimes be better
tuned then the byte-marshalling idiom you propose in Unsafe.
An optimizing JIT will not reliably recognize and compress the
byte-marshalling idiom back down to a hardware intrinsic.

And it is not just a question of deferring to the C++ version
of the same byte-marshalling code.  Some platforms choose
to test p&7 for several cases, not just zero and non-zero.
Also, although it is not common, some chips support misaligned
memory operations as distinct instructions. MIPS and Alpha
come to mind, and SPARC has VIS instructions to manage
vector loops on misaligned data.  A rare example in x86 is
MOVDQA vs. MOVDQU, although alignment should be
ignored for nearly all x86 ops.

My bottom line:  I think we should use the internal HotSpot
API bytes.hpp by surfacing relevant parts of it up into Unsafe.
(One thing feels wrong about bytes.hpp:  It insists that big-endian
is the norm for unaligned access.  This is simply a legacy of its
origin, for classfile and bytecode parsing.)

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).  Those could be represented in Java
code as you suggest, at the cost of some duplication.
For special platforms which use a third idiom, the intrinsics
could be adjusted.

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.

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.

> We could provide compiler intrinsics which do when we need on such
> machines.  However, I think this wouldn't deliver the best results.
> From the experiments I've done, the best implementation is to write
> the access methods in Java and allow HotSpot to optimize them.  While
> this seemed a bit counter-intuitive to me, it's best because C2 has
> profile data that it can work on.  In many cases I suspect that data
> read and written from a byte array will be aligned for their type and
> C2 will take advantage of this, relegating the misaligned access to an
> out-of-line code path as appropriate.  Also, these methods have the
> additional benefit that they are always atomic as long as the data are
> naturally aligned.

As coded in your proposal, they do not preserve partial atomicity.
That's (probably) why platforms distinguish more cases among
p&7 values.

Partial atomicity is important when you are vectorizing a loop
over an array of multi-byte elements (such as Java chars).
You don't want racy reads to pick up torn array elements.

(BTW, a TO-DO item for the optimizing JIT is to track low-bits of
pointers and other values; see JDK-8001436 for nice details.
This would allow the JIT to eliminate some tests of p&7.)

> This does result in rather a lot of code for the methods for all sizes
> and endiannesses, but none of it will be used on machines with
> unaligned hardware support except in the interpreter.  (Perhaps the
> interpreter too could have intrinsics?)

Well, it does for the aligned guys.  Adding unaligned versions doubles
the set (once again), but I don't see any other effective way of getting
to the platform-specific logic (bytes.hpp) mentioned above.

> I have changed HeapByteBuffer to use these methods, with a major
> performance improvement.  I've also provided Unsafe methods to query
> endianness and alignment support.
> 
> Webrevs at http://cr.openjdk.java.net/~aph/unaligned.hotspot.1/
> http://cr.openjdk.java.net/~aph/unaligned.jdk.1/






From john.r.rose at oracle.com  Tue Feb 24 23:20:52 2015
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 24 Feb 2015 15:20:52 -0800
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54EC9D7B.1000702@redhat.com>
References: <54EB6DD1.4090803@redhat.com>
	<9C5507AD-AACE-45EF-9845-0C1DF6C10893@oracle.com>
	<54EC8116.3080006@redhat.com> <54EC9B8B.9010505@gmail.com>
	<54EC9D7B.1000702@redhat.com>
Message-ID: <7B679A37-097B-4EDF-91D4-1DE9960BBD11@oracle.com>

On Feb 24, 2015, at 7:49 AM, Andrew Haley <aph at redhat.com> wrote:
> 
>> 
>> There will be only one runtime Unsafe sub-type ever observed in a 
>> particular VM.
> 
> Oh, that's very nice.

That doesn't help with B accesses on L platforms and vice versa.
Having an optional boolean parameter (gating reverseBytes) will help.

Also, it makes Unsafe non-final, which frankly gives me the willies.
(Technical term, used by folks that have been through too many security escalations.)
Let's not create any new ways for industrious hackers to attack Unsafe.

? John

From david.holmes at oracle.com  Wed Feb 25 02:26:05 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Feb 2015 12:26:05 +1000
Subject: Please review: 8066185: VM crashed with SIGSEGV
	VirtualMemoryTracker::add_reserved_region
In-Reply-To: <54ECA419.5090507@oracle.com>
References: <54EBA658.6020001@oracle.com> <54EBDD6B.5070404@oracle.com>
	<54ECA419.5090507@oracle.com>
Message-ID: <54ED32BD.1010800@oracle.com>

Thumbs up!

Thanks,
David

On 25/02/2015 2:17 AM, Kumar Srinivasan wrote:
> Hi David,
>
> comments inlined.
>
>> Hi Kumar,
>>
>> On 24/02/2015 8:14 AM, Kumar Srinivasan wrote:
>>> Hello,
>>>
>>> Please review the fix for the above issue.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~ksrini/8066185/webrev.00/
>>>
>>> The fix is self explanatory, as for the test I have done the following:
>>
>> I found the comment:
>>
>>           /*
>> +          * Since this is a VM flag, we need to ensure it is not an
>> +          * application argument, meaning the argument must precede
>> +          * the main class or those flags that invoke the VM directly.
>> +          */
>>
>> a bit confusing - specifically the "or those flags that invoke the VM
>> directly". Took me while to realize that all the args you treat
>> specially (-version, -h, -jar etc) are all "terminal" arguments -
>> either the launcher stops looking at args after the given arg, or all
>> following args must be for the application, not the launcher or VM. I
>> would have expressed this as:
>>
>>   /*
>>    * Since this must be a VM flag we stop processing once we see
>>    * an argument the launcher would not have processed beyond (such
>>    * as -version or -h), or an argument that indicates the following
>>    * arguments are for the application (i.e. the main class name, or
>>    * the -jar argument).
>>    */
>>
>>
> +1,  I have updated the webrev with your comments, also had an AHA moment,
> I realized, had missed -X, which prints the XUsage, added this to the logic
> and test.
>
>>> a. refactored it from a single longish test to sub-tests for
>>> readability.
>>> b. added new sub-test for NMT Argument Processing checks.
>>
>> Can you please update the @summary for that test. It seems the OSX
>> specific test was hijacked for NMT arg testing and the summary was
>> never updated to reflect that.
>
> This test was "commandeered" :-) for other purposes, updated the summary to
> describe what is being performed.
>
> Webrev to last reviewed:
> http://cr.openjdk.java.net/~ksrini/8066185/webrev.01/webrev.delta/index.html
>
>
> Full webrev:
> http://cr.openjdk.java.net/~ksrini/8066185/webrev.01/index.html
>
> Thanks.
> Kumar
>
>>
>> Thanks,
>> David
>>
>>> Thanks
>>> Kumar
>>>
>


From paul.sandoz at oracle.com  Wed Feb 25 08:27:51 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 25 Feb 2015 09:27:51 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <7B679A37-097B-4EDF-91D4-1DE9960BBD11@oracle.com>
References: <54EB6DD1.4090803@redhat.com>
	<9C5507AD-AACE-45EF-9845-0C1DF6C10893@oracle.com>
	<54EC8116.3080006@redhat.com> <54EC9B8B.9010505@gmail.com>
	<54EC9D7B.1000702@redhat.com>
	<7B679A37-097B-4EDF-91D4-1DE9960BBD11@oracle.com>
Message-ID: <8169C677-C69F-479B-ABC6-2276F99168FD@oracle.com>


On Feb 25, 2015, at 12:20 AM, John Rose <john.r.rose at oracle.com> wrote:

> On Feb 24, 2015, at 7:49 AM, Andrew Haley <aph at redhat.com> wrote:
>> 
>>> 
>>> There will be only one runtime Unsafe sub-type ever observed in a 
>>> particular VM.
>> 
>> Oh, that's very nice.
> 
> That doesn't help with B accesses on L platforms and vice versa.
> Having an optional boolean parameter (gating reverseBytes) will help.
> 

Yes, that's a good point.


> Also, it makes Unsafe non-final, which frankly gives me the willies.
> (Technical term, used by folks that have been through too many security escalations.)
> Let's not create any new ways for industrious hackers to attack Unsafe.
> 

I was getting nervous about this too :-)

Paul.


From aph at redhat.com  Wed Feb 25 09:07:27 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 25 Feb 2015 09:07:27 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <7B679A37-097B-4EDF-91D4-1DE9960BBD11@oracle.com>
References: <54EB6DD1.4090803@redhat.com>
	<9C5507AD-AACE-45EF-9845-0C1DF6C10893@oracle.com>
	<54EC8116.3080006@redhat.com> <54EC9B8B.9010505@gmail.com>
	<54EC9D7B.1000702@redhat.com>
	<7B679A37-097B-4EDF-91D4-1DE9960BBD11@oracle.com>
Message-ID: <54ED90CF.40209@redhat.com>

On 24/02/15 23:20, John Rose wrote:
> On Feb 24, 2015, at 7:49 AM, Andrew Haley <aph at redhat.com <mailto:aph at redhat.com>> wrote:
>>
>>> There will be only one runtime Unsafe sub-type ever observed in a 
>>> particular VM.
>>
>> Oh, that's very nice.
> 
> That doesn't help with B accesses on L platforms and vice versa.

It wasn't supposed to, but OK, I guess we can extend it to do that.
Byte reversal was never handled at this level before and I'm not at
all sure it should be.  I'll have a look.

> Having an optional boolean parameter (gating reverseBytes) will help.
> 
> Also, it makes Unsafe non-final, which frankly gives me the willies.
> (Technical term, used by folks that have been through too many security escalations.)
> Let's not create any new ways for industrious hackers to attack Unsafe.

Oh, alright.  It was such a tidy solution, though.  :-)

Andrew.


From me at noctarius.com  Wed Feb 25 09:33:52 2015
From: me at noctarius.com (Noctarius)
Date: Wed, 25 Feb 2015 10:33:52 +0100
Subject: Defined behavior on switch-case fall-through
Message-ID: <54ED9700.2030403@noctarius.com>

Hey guys,

Sorry for crashing into the mailinglist but by looking at the Java
specification we're not really sure about it. I guess it might be
well defined but we want to make sure.

Looking at the following example we see a non natural ordered case
for fall-through. Looking at the spec there is an example which
defines the fall-through behavior, unfortunately the example uses a
natural ordered list of numbers.

switch(age){
case 0:
case 2:
case 4:
case 6: println("even");break;
case 1:
case 3:
case 5: println("uneven");break;
default: ....
}

In our example we do not have this behavior. We are sure the Java
compiler will compile it as it is above but Hotspot applies, as far
as I know, reordering on cases depending on the frequency of usage.
I expect it to only reorder fall-through blocks or let's call it
blocks without any order-dependency but is this how it works? Is
this case covered by the spec? Maybe it needs another example to
make it clear.

Thanks

Chris



From peter.levart at gmail.com  Wed Feb 25 10:03:01 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 25 Feb 2015 11:03:01 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <8169C677-C69F-479B-ABC6-2276F99168FD@oracle.com>
References: <54EB6DD1.4090803@redhat.com>	<9C5507AD-AACE-45EF-9845-0C1DF6C10893@oracle.com>	<54EC8116.3080006@redhat.com>
	<54EC9B8B.9010505@gmail.com>	<54EC9D7B.1000702@redhat.com>	<7B679A37-097B-4EDF-91D4-1DE9960BBD11@oracle.com>
	<8169C677-C69F-479B-ABC6-2276F99168FD@oracle.com>
Message-ID: <54ED9DD5.7030305@gmail.com>


On 02/25/2015 09:27 AM, Paul Sandoz wrote:
> On Feb 25, 2015, at 12:20 AM, John Rose <john.r.rose at oracle.com> wrote:
>
>> On Feb 24, 2015, at 7:49 AM, Andrew Haley <aph at redhat.com> wrote:
>>>> There will be only one runtime Unsafe sub-type ever observed in a
>>>> particular VM.
>>> Oh, that's very nice.
>> That doesn't help with B accesses on L platforms and vice versa.
>> Having an optional boolean parameter (gating reverseBytes) will help.
>>

Or having another set of methods (with B/L suffix). I think the desired 
modes are:
-  native order (platform dependent but always fastest)
- BigEndian (platform independent, fast if equal to native order)
- LittleEndian (platform independent, fast if equal to native order)

Having an order that is the opposite of native order is rarely needed, I 
think, since it is platform dependent and slower at the same time.

> Yes, that's a good point.
>
>
>> Also, it makes Unsafe non-final, which frankly gives me the willies.
>> (Technical term, used by folks that have been through too many security escalations.)
>> Let's not create any new ways for industrious hackers to attack Unsafe.
>>
> I was getting nervous about this too :-)

I also felt uncomfortable, but for other reasons (like if intrinsics 
still behave the same in abstract class too). At least in JDK9, Unsafe 
should be hidden from any attackers, right?

Is making class final any safer than making constructor private? Are 
there any known attacks on extending non-final classes with private 
constructors?

Since these methods are unsafe, they naturally belong to Unsafe, but an 
alternative would be an all-Java implementation in a parallel class 
(Unsafe2). It wouldn't be any safer though. I just have a feeling that 
if implementation is in Java, it would be best if methods were as short 
as possible (for inlineability) and with as little conditional branches 
that only depend on platform setup and can't be optimized away in all 
modes of execution (interpreter, C1, C2).

Regards, Peter

> Paul.



From magnus.ihse.bursie at oracle.com  Wed Feb 25 11:21:28 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 25 Feb 2015 12:21:28 +0100
Subject: RFR: JDK-8072842 Add support for building native JTReg tests
In-Reply-To: <31B825DC-DFD2-4EC2-81AD-9BF0FC3364CC@oracle.com>
References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com>
	<54DB0E31.3010201@oracle.com> <54DB1175.6030700@oracle.com>
	<54DB125D.2070706@oracle.com>
	<F27CF091-29B1-4C22-BDF7-DD1D3469F2BE@oracle.com>
	<54DB1528.4030708@oracle.com>
	<324EF37C-3FD2-4B8A-A509-D7315889D8DE@oracle.com>
	<54DB39C2.5010607@oracle.com>
	<31B825DC-DFD2-4EC2-81AD-9BF0FC3364CC@oracle.com>
Message-ID: <54EDB038.4000502@oracle.com>

On 2015-02-11 13:08, Staffan Larsen wrote:
>
>>>>>>> Okay so if I just cd into hotspot/test and use the Makefile to try
>>>>>>> and run some jtreg tests it looks to me that it will define an
>>>>>>> invalid -nativepath
>>>>>>
>>>>>> I'm not sure if that is a supported use case. David or Staffan will
>>>>>> have to answer to that. I have not tested that, only the "whole
>>>>>> forest" approach.
>>>>>
>>>>> I?ve never done that. I?m always running all make commands from 
>>>>> the top
>>>>> level. Is there a problem with that?
>>>>
>>>> I must confess I also haven't done that - though I often run jtreg 
>>>> directly from there. Other hotspot engineers may use it. If nothing 
>>>> else it would be a way to test out what you expect JPRT to be running.
>>>>
>>>> But perhaps we just don't add the -nativepath component if 
>>>> TESTNATIVE_DIR remains unset?
>>>
>>> Not adding -nativepath or adding it with an empty path will lead to 
>>> the same errors I think: tests that need native code will fail. So 
>>> it does not really matter.
>>
>> If you add it with an invalid path (won't be empty as the variable is 
>> only a prefix) then tests that don't need native code may also fail. 
>> Though I don't know how jtreg responds to a non-existent nativepath.
>
> You are right. Jtreg validates the that the path is a directory. So 
> better not to specify it.

Ok. I have updated the webrev, so the -nativepath: argument is only 
specified if we indeed have been given a valid path to the native libraries.

The only changes between this and the previous webrev is in 
hotspot/test/Makefile and jdk/test/Makefile.

http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.02

/Magnus


From paul.sandoz at oracle.com  Wed Feb 25 11:26:57 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 25 Feb 2015 12:26:57 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54ED9DD5.7030305@gmail.com>
References: <54EB6DD1.4090803@redhat.com>	<9C5507AD-AACE-45EF-9845-0C1DF6C10893@oracle.com>	<54EC8116.3080006@redhat.com>
	<54EC9B8B.9010505@gmail.com>	<54EC9D7B.1000702@redhat.com>	<7B679A37-097B-4EDF-91D4-1DE9960BBD11@oracle.com>
	<8169C677-C69F-479B-ABC6-2276F99168FD@oracle.com>
	<54ED9DD5.7030305@gmail.com>
Message-ID: <5290DE11-CF29-4967-A72A-24801E19DC0A@oracle.com>


On Feb 25, 2015, at 11:03 AM, Peter Levart <peter.levart at gmail.com> wrote:

> 
> On 02/25/2015 09:27 AM, Paul Sandoz wrote:
>> On Feb 25, 2015, at 12:20 AM, John Rose <john.r.rose at oracle.com>
>>  wrote:
>> 
>> 
>>> On Feb 24, 2015, at 7:49 AM, Andrew Haley <aph at redhat.com>
>>>  wrote:
>>> 
>>>>> There will be only one runtime Unsafe sub-type ever observed in a 
>>>>> particular VM.
>>>>> 
>>>> Oh, that's very nice.
>>>> 
>>> That doesn't help with B accesses on L platforms and vice versa.
>>> Having an optional boolean parameter (gating reverseBytes) will help.
>>> 
>>> 
> 
> Or having another set of methods (with B/L suffix). I think the desired modes are:
> -  native order (platform dependent but always fastest)
> - BigEndian (platform independent, fast if equal to native order)
> - LittleEndian (platform independent, fast if equal to native order)
> 

I think it simpler just to have one method with a boolean parameter whose default false value means native and true means BigEndian. Otherwise, even simpler, just support native only (like the existing access impls) and let the caller reverse as/when required.


> Having an order that is the opposite of native order is rarely needed, I think, since it is platform dependent and slower at the same time.
> 

To your point with the current unsigned byte Lexicographic comparator prototype if i were to modify to use the unaligned access methods i would want native order and only take the hit of reversing, if required, if two elements are not equal. Note that code will anyway be modified to use a more general array mismatch method leveraging the unaligned access methods using native order (i cannot think of a reason why it not do otherwise).


>> Yes, that's a good point.
>> 
>> 
>> 
>>> Also, it makes Unsafe non-final, which frankly gives me the willies.
>>> (Technical term, used by folks that have been through too many security escalations.)
>>> Let's not create any new ways for industrious hackers to attack Unsafe.
>>> 
>>> 
>> I was getting nervous about this too :-)
> 
> I also felt uncomfortable, but for other reasons (like if intrinsics still behave the same in abstract class too). At least in JDK9, Unsafe should be hidden from any attackers, right?

The non-accessibility will, by default, be more strongly enforced by the VM.


> 
> Is making class final any safer than making constructor private? Are there any known attacks on extending non-final classes with private constructors?
> 

I do not know.

Paul.

> Since these methods are unsafe, they naturally belong to Unsafe, but an alternative would be an all-Java implementation in a parallel class (Unsafe2). It wouldn't be any safer though. I just have a feeling that if implementation is in Java, it would be best if methods were as short as possible (for inlineability) and with as little conditional branches that only depend on platform setup and can't be optimized away in all modes of execution (interpreter, C1, C2).
> 
> Regards, Peter
> 
>> Paul.
>> 
> 



From aph at redhat.com  Wed Feb 25 11:47:53 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 25 Feb 2015 11:47:53 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <5290DE11-CF29-4967-A72A-24801E19DC0A@oracle.com>
References: <54EB6DD1.4090803@redhat.com>	<9C5507AD-AACE-45EF-9845-0C1DF6C10893@oracle.com>	<54EC8116.3080006@redhat.com>	<54EC9B8B.9010505@gmail.com>	<54EC9D7B.1000702@redhat.com>	<7B679A37-097B-4EDF-91D4-1DE9960BBD11@oracle.com>	<8169C677-C69F-479B-ABC6-2276F99168FD@oracle.com>	<54ED9DD5.7030305@gmail.com>
	<5290DE11-CF29-4967-A72A-24801E19DC0A@oracle.com>
Message-ID: <54EDB669.8080003@redhat.com>

On 02/25/2015 11:26 AM, Paul Sandoz wrote:

> I think it simpler just to have one method with a boolean parameter
> whose default false value means native and true means
> BigEndian. Otherwise, even simpler, just support native only (like
> the existing access impls) and let the caller reverse as/when
> required.

There have to be different big- and little-endian versions of the
get/put methods because of the different way that subwords are merged.
See hotspot/src/cpu/ppc/vm/bytes_ppc.hpp, with its two versions of
these methods.  So we're going to need big and little versions for
hardware with no unaligned access.  Any given machine will only use
one set of these methods.

Andrew.


From paul.sandoz at oracle.com  Wed Feb 25 11:55:20 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 25 Feb 2015 12:55:20 +0100
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <9D775E0E-16CA-43C9-AC30-A691AE7CCC0F@oracle.com>
References: <9D775E0E-16CA-43C9-AC30-A691AE7CCC0F@oracle.com>
Message-ID: <E874F969-AAF8-4E6B-BF85-901088F519CC@oracle.com>

Hi Joel,

I could be missing something here but would it be possible to wrap the call to m.setAccessible in a doPriv block instead?

Paul.

On Feb 24, 2015, at 11:49 AM, Joel Borggr?n-Franck <joel.franck at oracle.com> wrote:

> Hi,
> 
> Here is a fix for an issue with repeating annotations when a security manager is set.
> 
> Fix is to use the Proxy invocation handler to unwrap the array containing the repeating annotations. In theory it might be possible to have instances of Annotations that are not implemented using Proxies, so the old code which  is independent of implementation is kept as a fall-back, but the user or these theoretical annotations will have to configure the security policy accordingly.
> 
> http://cr.openjdk.java.net/~jfranck/8073056/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8073056
> 
> cheers
> /Joel



From joel.franck at oracle.com  Wed Feb 25 11:59:23 2015
From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Wed, 25 Feb 2015 12:59:23 +0100
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <E874F969-AAF8-4E6B-BF85-901088F519CC@oracle.com>
References: <9D775E0E-16CA-43C9-AC30-A691AE7CCC0F@oracle.com>
	<E874F969-AAF8-4E6B-BF85-901088F519CC@oracle.com>
Message-ID: <D74680E6-22E5-4928-B8E5-CE620DAD2870@oracle.com>

Hi Paul,

Yes that would indeed be possible, but after some internal discussions we though it safer to reuse the Proxy invocation path.

cheers
/Joel

> On 25 feb 2015, at 12:55, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi Joel,
> 
> I could be missing something here but would it be possible to wrap the call to m.setAccessible in a doPriv block instead?
> 
> Paul.
> 
> On Feb 24, 2015, at 11:49 AM, Joel Borggr?n-Franck <joel.franck at oracle.com> wrote:
> 
>> Hi,
>> 
>> Here is a fix for an issue with repeating annotations when a security manager is set.
>> 
>> Fix is to use the Proxy invocation handler to unwrap the array containing the repeating annotations. In theory it might be possible to have instances of Annotations that are not implemented using Proxies, so the old code which  is independent of implementation is kept as a fall-back, but the user or these theoretical annotations will have to configure the security policy accordingly.
>> 
>> http://cr.openjdk.java.net/~jfranck/8073056/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8073056
>> 
>> cheers
>> /Joel
> 



From paul.sandoz at oracle.com  Wed Feb 25 12:16:02 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 25 Feb 2015 13:16:02 +0100
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <D74680E6-22E5-4928-B8E5-CE620DAD2870@oracle.com>
References: <9D775E0E-16CA-43C9-AC30-A691AE7CCC0F@oracle.com>
	<E874F969-AAF8-4E6B-BF85-901088F519CC@oracle.com>
	<D74680E6-22E5-4928-B8E5-CE620DAD2870@oracle.com>
Message-ID: <E47D5487-9CFD-4F39-AC85-1B8F4ED81533@oracle.com>


On Feb 25, 2015, at 12:59 PM, Joel Borggr?n-Franck <joel.franck at oracle.com> wrote:

> Hi Paul,
> 
> Yes that would indeed be possible, but after some internal discussions we though it safer to reuse the Proxy invocation path.
> 

Ok, i claim ignorance as to why that is so :-)

Is there any performance impact since all code will go through the proxy? It might be possible to check if the security manager is enabled before going through that path? If not I think you should add a comment on the effectively dead code path of direct method invocation.


213         } catch (IllegalAccessException    | // couldn't loosen security
 214                  IllegalArgumentException  | // parameters doesn't match
 215                  InvocationTargetException | // the value method threw an exception
 216                  ClassCastException e) {

 217             throw invalidContainerException(container, e);
 218         } catch (Throwable t) { // from InvocationHandler::invoke
 219             throw invalidContainerException(container, t);
 220         }
 221     }
 222 

You could compress all this down to just catching Throwable. It seems quite a large net that may inadvertently catch other runtime exceptions.

Paul.





From paul.sandoz at oracle.com  Wed Feb 25 12:34:04 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 25 Feb 2015 13:34:04 +0100
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <54EDB669.8080003@redhat.com>
References: <54EB6DD1.4090803@redhat.com>	<9C5507AD-AACE-45EF-9845-0C1DF6C10893@oracle.com>	<54EC8116.3080006@redhat.com>	<54EC9B8B.9010505@gmail.com>	<54EC9D7B.1000702@redhat.com>	<7B679A37-097B-4EDF-91D4-1DE9960BBD11@oracle.com>	<8169C677-C69F-479B-ABC6-2276F99168FD@oracle.com>	<54ED9DD5.7030305@gmail.com>
	<5290DE11-CF29-4967-A72A-24801E19DC0A@oracle.com>
	<54EDB669.8080003@redhat.com>
Message-ID: <8D1636FA-119C-4E3D-BFD2-43C392E74A7B@oracle.com>


On Feb 25, 2015, at 12:47 PM, Andrew Haley <aph at redhat.com> wrote:

> On 02/25/2015 11:26 AM, Paul Sandoz wrote:
> 
>> I think it simpler just to have one method with a boolean parameter
>> whose default false value means native and true means
>> BigEndian. Otherwise, even simpler, just support native only (like
>> the existing access impls) and let the caller reverse as/when
>> required.
> 
> There have to be different big- and little-endian versions of the
> get/put methods because of the different way that subwords are merged.
> See hotspot/src/cpu/ppc/vm/bytes_ppc.hpp, with its two versions of
> these methods.  

Ah, i just looked at the x86 and sparc versions.


> So we're going to need big and little versions for
> hardware with no unaligned access.  Any given machine will only use
> one set of these methods.
> 

I am a little confused about the bi-endianess of PPC. The supported endianess in bytes_ppc.hpp is defined at compile time via the flag VM_LITTLE_ENDIAN. So is "native" whatever hotspot is compiled to in this case?
  
Paul.


From aph at redhat.com  Wed Feb 25 12:40:05 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 25 Feb 2015 12:40:05 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <8D1636FA-119C-4E3D-BFD2-43C392E74A7B@oracle.com>
References: <54EB6DD1.4090803@redhat.com>	<9C5507AD-AACE-45EF-9845-0C1DF6C10893@oracle.com>	<54EC8116.3080006@redhat.com>	<54EC9B8B.9010505@gmail.com>	<54EC9D7B.1000702@redhat.com>	<7B679A37-097B-4EDF-91D4-1DE9960BBD11@oracle.com>	<8169C677-C69F-479B-ABC6-2276F99168FD@oracle.com>	<54ED9DD5.7030305@gmail.com>	<5290DE11-CF29-4967-A72A-24801E19DC0A@oracle.com>	<54EDB669.8080003@redhat.com>
	<8D1636FA-119C-4E3D-BFD2-43C392E74A7B@oracle.com>
Message-ID: <54EDC2A5.2080006@redhat.com>

On 02/25/2015 12:34 PM, Paul Sandoz wrote:
> 
> On Feb 25, 2015, at 12:47 PM, Andrew Haley <aph at redhat.com> wrote:
> 
>> So we're going to need big and little versions for hardware with no
>> unaligned access.  Any given machine will only use one set of these
>> methods.
> 
> I am a little confused about the bi-endianess of PPC. The supported
> endianess in bytes_ppc.hpp is defined at compile time via the flag
> VM_LITTLE_ENDIAN. So is "native" whatever hotspot is compiled to in
> this case?

Yes, that's right.Enigmail

Andrew.


From aph at redhat.com  Wed Feb 25 12:49:51 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 25 Feb 2015 12:49:51 +0000
Subject: Unsafe.{get,put}-X-Unaligned;
	Efficient array comparison intrinsics
In-Reply-To: <5290DE11-CF29-4967-A72A-24801E19DC0A@oracle.com>
References: <54EB6DD1.4090803@redhat.com>	<9C5507AD-AACE-45EF-9845-0C1DF6C10893@oracle.com>	<54EC8116.3080006@redhat.com>	<54EC9B8B.9010505@gmail.com>	<54EC9D7B.1000702@redhat.com>	<7B679A37-097B-4EDF-91D4-1DE9960BBD11@oracle.com>	<8169C677-C69F-479B-ABC6-2276F99168FD@oracle.com>	<54ED9DD5.7030305@gmail.com>
	<5290DE11-CF29-4967-A72A-24801E19DC0A@oracle.com>
Message-ID: <54EDC4EF.7000800@redhat.com>

On 02/25/2015 11:26 AM, Paul Sandoz wrote:

> To your point with the current unsigned byte Lexicographic
> comparator prototype if i were to modify to use the unaligned access
> methods i would want native order and only take the hit of
> reversing, if required, if two elements are not equal.

I agree.

> Note that code will anyway be modified to use a more general array
> mismatch method leveraging the unaligned access methods using native
> order (i cannot think of a reason why it not do otherwise).

It has to: array elements are stored in the same order regardless of
what the hardware does.  So byte-swapping does not help here: it'd
have to be subword-swapping, which some targets support (AArch64 does)
but AFAIK Java doesn't.

I would enormously prefer to solve the simpler problem rather than all
possible versions of related problems.  The model used in bytes.hpp
makes sense IMO.  The issue of non-native endianness is better handled
at a different level from Unsafe in my opinion: that way we can use
native-only intrinsics for the most common machines and reverse bytes
in the caller.  But if the desire is for a full set of native-, big-,
and little-endian methods I can do that.

Andrew.


From paul.sandoz at oracle.com  Wed Feb 25 13:12:06 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 25 Feb 2015 14:12:06 +0100
Subject: RFR 8014678: Spurious AccessControlException thrown in
	java.lang.Class.getEnclosingMethod()
In-Reply-To: <0C9A8736-306C-4631-8190-BD84B9DF6F27@oracle.com>
References: <0C9A8736-306C-4631-8190-BD84B9DF6F27@oracle.com>
Message-ID: <C7226743-D62B-4CE7-ACBD-3BE09248B65E@oracle.com>

Hi,

Looks ok to me.

Paul.

On Feb 24, 2015, at 12:26 PM, Joel Borggr?n-Franck <joel.franck at oracle.com> wrote:

> Hi,
> 
> Here is a fix for an old issue with Class.getEnclosingMethod() and Class.getEnclosingConstructor(). The problem is that we throw a spurious AccessControlException in some cases when looking up enclosingMethod/Ctor in the presence of a SecurityManager.
> 
> Consider the following classes: 
> 
> class C {}
> 
> class A {
>   public void someMetod() {
>        class B {}
>    }
> }
> 
> If client C has a Class<?> token for B it can call classForB.getEnclosingMethod(). While the client C must have permissions to look at declared members of A, in the nested call java.lang.Class will be looking at declared members of A while constructing the answer, and java.lang.Class might not have permissions to do this, even though the ?real? caller C has the correct permissions. So we and up with a call stack that looks like 
> 
> Caller:                               Call:
> 
> j.l.Class(for A.class)          A.class::checkMemberAccess(classloader for j.l.Class); // this can throw ACE if A is loaded in a separate loader from java.lang.Class
> j.l.Class(for B.class)          A.class::getDeclaredMethods(); // j.l.Class is the caller here
> C                                       B.class::getEnclosingMethod();
> .... application code ?.
> 
> The solution here is to insert a doPrivileged block around the call where j.l.Class gets the members to construct the answer.
> 
> Webrev: http://cr.openjdk.java.net/~jfranck/8014678/
> 
> Bug is not open but the tests show how this is reproduced.
> 
> cheers
> /Joel



From joel.franck at oracle.com  Wed Feb 25 13:19:10 2015
From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=)
Date: Wed, 25 Feb 2015 14:19:10 +0100
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <E47D5487-9CFD-4F39-AC85-1B8F4ED81533@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>
Message-ID: <FBB79C47-AC33-463D-BFA4-6D8B1CF80C00@oracle.com>

Hi,

> On 25 feb 2015, at 13:16, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> On Feb 25, 2015, at 12:59 PM, Joel Borggr?n-Franck <joel.franck at oracle.com> wrote:
> 
>> Hi Paul,
>> 
>> Yes that would indeed be possible, but after some internal discussions we though it safer to reuse the Proxy invocation path.
>> 
> 
> Ok, i claim ignorance as to why that is so :-)
> 
> Is there any performance impact since all code will go through the proxy? It might be possible to check if the security manager is enabled before going through that path?

Arguably this should actually be faster. For all ?our? annotations the Proxy invocation handler will be the final invoker anyway, so this is just cutting out the middle.

> If not I think you should add a comment on the effectively dead code path of direct method invocation.
> 

Agreed.

> 
> 213         } catch (IllegalAccessException    | // couldn't loosen security
> 214                  IllegalArgumentException  | // parameters doesn't match
> 215                  InvocationTargetException | // the value method threw an exception
> 216                  ClassCastException e) {
> 
> 217             throw invalidContainerException(container, e);
> 218         } catch (Throwable t) { // from InvocationHandler::invoke
> 219             throw invalidContainerException(container, t);
> 220         }
> 221     }
> 222 
> 
> You could compress all this down to just catching Throwable. It seems quite a large net that may inadvertently catch other runtime exceptions.

InvocationHandler::invoke unfortunately throws Throwable, but I restructured it a bit so it is easier to follow.

http://cr.openjdk.java.net/~jfranck/8073056/webrev.01/

cheers
/Joel

From paul.sandoz at oracle.com  Wed Feb 25 13:20:19 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 25 Feb 2015 14:20:19 +0100
Subject: RFR 8071600: Add a flat-mapping collector
In-Reply-To: <FEF5C5C7-5EA7-461C-BDA2-00C207DC8003@oracle.com>
References: <517DF5B9-E3C5-4CD9-A04A-AC06EBD61517@oracle.com>
	<54DCCBFF.4090501@gmail.com>
	<FEF5C5C7-5EA7-461C-BDA2-00C207DC8003@oracle.com>
Message-ID: <9D69E031-D7D7-472A-8C55-F5ED5A0397F4@oracle.com>


On Feb 12, 2015, at 5:07 PM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:

> On Feb 12, 2015, at 4:51 PM, Peter Levart <peter.levart at gmail.com> wrote:
>> Hi Paul,
>> 
>> Would the following "optimization" make any sense?
>> 
>>    public static <T, U, A, R>
>>    Collector<T, ?, R> flatMapping(Function<? super T, ? extends Stream<? extends U>> mapper,
>>                                   Collector<? super U, A, R> downstream) {
>>        BiConsumer<A, ? super U> downstreamAccumulator = downstream.accumulator();
>>        return new CollectorImpl<>(downstream.supplier(),
>>            (r, t) -> {
>>                try (Stream<? extends U> result = mapper.apply(t)) {
>>                    if (result != null) {
>>                        ((result.isParallel() &&
>>                            !downstream.characteristics().contains(Collector.Characteristics.CONCURRENT))
>>                            ? result.sequential() : result).forEach(u -> downstreamAccumulator.accept(r, u));
>>                    }
>>                }
>>            },
>>            downstream.combiner(), downstream.finisher(),
>>            downstream.characteristics());
>>    }
>> 
> 
> Ah, interesting.
> 
> Possibly... i need to think thought the implications on stream and collectors (groupingByConcurrent does the right thing for a non-concurrent downstream collector and synchronizes on the accumulation).
> 

Unfortunately there is not currently enough information propagated down from the top-level collect to make an informed decision about whether one could go parallel and collect concurrently within flatMapping.

Paul.


From paul.sandoz at oracle.com  Wed Feb 25 13:30:30 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 25 Feb 2015 14:30:30 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <CACzrW9ACv0X==y0Yz_ThjFTy2Erirhr_BZ_GiNAB8X5FoEgf=g@mail.gmail.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>
	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
	<CACzrW9ACv0X==y0Yz_ThjFTy2Erirhr_BZ_GiNAB8X5FoEgf=g@mail.gmail.com>
Message-ID: <7E638FFB-627A-4286-A7F3-E2EEF69A952E@oracle.com>

On Feb 12, 2015, at 11:59 PM, Stephen Colebourne <scolebourne at joda.org> wrote:
> Interesting direction.
> 

Catching up on email after being away last week...


> Reading carefully, the goal is actually very limited in scope, by
> preventing any public API changes. It doesn't help adoption of JSR-310
> for example, but will be useful for Unsafe, which is clearly a
> motivating factor.

Yes, in addition to other stuff internal stuff.


> 
> I would expect IDEs to have some considerable work to do.

Yes, if the concept of a multi-version project has legs. It "feels" appropriate to have everything under one project rather than spread out between separate projects/repos with some form of merging.


> 
> My biggest concern will be ensuring tools like Reflections (or other
> classpath scanning tools) carry on working. Really, classpath scanning
> should no longer be necessary with a module system, but since we've
> heard nothing to indicate that issue is being tackled, those tools
> will continue to be vital (such as to find all classes implementing an
> annotation, or all implementations of an interface)
> 

Even in the modular world i will expect class scanning will be used. While we can now iterate reliably over classes in the image i don't believe that functionality is made available for classes in modules on the module path.

I am guilty if writing such class scanners :-) The context was JAX-RS/Jersey. In this case i would expect that the annotations should be the same across multiple class files targeted to different platforms, since that is part of the API. 

But in general i agree there could be issues. I am very interested in hearing feedback on such cases. 

Please share widely, if not already done so.

Paul.





From paul.sandoz at oracle.com  Wed Feb 25 13:49:11 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 25 Feb 2015 14:49:11 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <54DF6233.9070408@gmail.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>
	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
	<54DF6233.9070408@gmail.com>
Message-ID: <7146B859-428A-46C0-A723-A6C50FF293AE@oracle.com>

HI Peter,

On Feb 14, 2015, at 3:56 PM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi Paul,
> 
> I read through the proposal and couldn't find an explanation of how resources placed in versioned paths are going to be visible. For example, if the multi-versioned jar contains the following structure:
> 
> my.properties
> META-INF/versions/8/my.properties
> META-INF/versions/9/my.properties
> 
> 
> What will the following code return, when run on JDK9:
> 
> URL[] urls = ClassLoader.getSystemClassLoader().getResources("my.properties");
> 
> Will we only get 1 URL: META-INF/versions/9/my.properties
> or 3 URLs in order: META-INF/versions/9/my.properties, META-INF/versions/8/my.properties, my.properties
> 
> Class name -> .class file resolving is easy, since only the 1st one is used, but there can be multiple general resources for same path.
> 

The intension is only one such "my.properties" resource file will be found within the MVJAR. There may be some subtleties when using absolute names.  The analogy of placing things on the classpath in the appropriate order does break down in this respect.

Paul.


From peter.levart at gmail.com  Wed Feb 25 14:22:46 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 25 Feb 2015 15:22:46 +0100
Subject: RFR 8014678: Spurious AccessControlException thrown in
	java.lang.Class.getEnclosingMethod()
In-Reply-To: <0C9A8736-306C-4631-8190-BD84B9DF6F27@oracle.com>
References: <0C9A8736-306C-4631-8190-BD84B9DF6F27@oracle.com>
Message-ID: <54EDDAB6.5070104@gmail.com>

Hi Joel,

On 02/24/2015 12:26 PM, Joel Borggr?n-Franck wrote:
> Hi,
>
> Here is a fix for an old issue with Class.getEnclosingMethod() and Class.getEnclosingConstructor(). The problem is that we throw a spurious AccessControlException in some cases when looking up enclosingMethod/Ctor in the presence of a SecurityManager.
>
>   Consider the following classes:
>
> class C {}
>
> class A {
>     public void someMetod() {
>          class B {}
>      }
> }
>
> If client C has a Class<?> token for B it can call classForB.getEnclosingMethod(). While the client C must have permissions to look at declared members of A, in the nested call java.lang.Class will be looking at declared members of A while constructing the answer, and java.lang.Class might not have permissions to do this, even though the ?real? caller C has the correct permissions. So we and up with a call stack that looks like
>
> Caller:                               Call:
>
> j.l.Class(for A.class)          A.class::checkMemberAccess(classloader for j.l.Class); // this can throw ACE if A is loaded in a separate loader from java.lang.Class
> j.l.Class(for B.class)          A.class::getDeclaredMethods(); // j.l.Class is the caller here
> C                                       B.class::getEnclosingMethod();
> .... application code ?.
>
> The solution here is to insert a doPrivileged block around the call where j.l.Class gets the members to construct the answer.
>
> Webrev: http://cr.openjdk.java.net/~jfranck/8014678/
>
> Bug is not open but the tests show how this is reproduced.
>
> cheers
> /Joel

Is the AccessControlException result of the fact that client code C is 
loaded by same class loader as A and therefore can access declared 
memebers of A without special permissions, but if the caller of 
getDeclaredMethods() is j.l.Class (system code), then it is not loaded 
by same class loader as A and the permission *is* checked, but C does 
not have it?

You are elevating the permission of the call to getDeclaredMethods() and 
therefore give client C access memeber of A even in situations where 
classloaders of C and A differ and C does not have special permission.

I think the right solution should be to pass the caller of 
getEnclosingMethod() to the logic of getDecalredMethods() without 
elevating the privilege. You'd have to create a private 
getDeclaredMethods() method taking additional 'caller' parameter to 
which both public methods getEnclosingMethod() and getDecalredMethods() 
would delegate.

Regards, Peter



From peter.levart at gmail.com  Wed Feb 25 14:26:28 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 25 Feb 2015 15:26:28 +0100
Subject: RFR 8014678: Spurious AccessControlException thrown in
	java.lang.Class.getEnclosingMethod()
In-Reply-To: <54EDDAB6.5070104@gmail.com>
References: <0C9A8736-306C-4631-8190-BD84B9DF6F27@oracle.com>
	<54EDDAB6.5070104@gmail.com>
Message-ID: <54EDDB94.1090902@gmail.com>


On 02/25/2015 03:22 PM, Peter Levart wrote:
> Hi Joel,
>
> On 02/24/2015 12:26 PM, Joel Borggr?n-Franck wrote:
>> Hi,
>>
>> Here is a fix for an old issue with Class.getEnclosingMethod() and Class.getEnclosingConstructor(). The problem is that we throw a spurious AccessControlException in some cases when looking up enclosingMethod/Ctor in the presence of a SecurityManager.
>>
>>   Consider the following classes:
>>
>> class C {}
>>
>> class A {
>>     public void someMetod() {
>>          class B {}
>>      }
>> }
>>
>> If client C has a Class<?> token for B it can call classForB.getEnclosingMethod(). While the client C must have permissions to look at declared members of A, in the nested call java.lang.Class will be looking at declared members of A while constructing the answer, and java.lang.Class might not have permissions to do this, even though the ?real? caller C has the correct permissions. So we and up with a call stack that looks like
>>
>> Caller:                               Call:
>>
>> j.l.Class(for A.class)          A.class::checkMemberAccess(classloader for j.l.Class); // this can throw ACE if A is loaded in a separate loader from java.lang.Class
>> j.l.Class(for B.class)          A.class::getDeclaredMethods(); // j.l.Class is the caller here
>> C                                       B.class::getEnclosingMethod();
>> .... application code ?.
>>
>> The solution here is to insert a doPrivileged block around the call where j.l.Class gets the members to construct the answer.
>>
>> Webrev:http://cr.openjdk.java.net/~jfranck/8014678/
>>
>> Bug is not open but the tests show how this is reproduced.
>>
>> cheers
>> /Joel
>
> Is the AccessControlException result of the fact that client code C is 
> loaded by same class loader as A and therefore can access declared 
> memebers of A without special permissions, but if the caller of 
> getDeclaredMethods() is j.l.Class (system code), then it is not loaded 
> by same class loader as A and the permission *is* checked, but C does 
> not have it?
>
> You are elevating the permission of the call to getDeclaredMethods() 
> and therefore give client C access memeber of A even in situations 
> where classloaders of C and A differ and C does not have special 
> permission.
>
> I think the right solution should be to pass the caller of 
> getEnclosingMethod() to the logic of getDecalredMethods() without 
> elevating the privilege. You'd have to create a private 
> getDeclaredMethods() method taking additional 'caller' parameter to 
> which both public methods getEnclosingMethod() and 
> getDecalredMethods() would delegate.
>
> Regards, Peter
>

Ah, never mind. I missed the explicit access check that 
getEnclosingMethod() already performs on it's own before calling 
getDeclaredMethods(). But the check is for the same permission and could 
be performed implicitly by getDeclaredMethods() if the caller of 
getEnclosingMethod() was passed to it. Just an optimization opportunity 
therefore.

Peter



From peter.levart at gmail.com  Wed Feb 25 14:48:57 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 25 Feb 2015 15:48:57 +0100
Subject: RFR 8014678: Spurious AccessControlException thrown in
	java.lang.Class.getEnclosingMethod()
In-Reply-To: <54EDDB94.1090902@gmail.com>
References: <0C9A8736-306C-4631-8190-BD84B9DF6F27@oracle.com>
	<54EDDAB6.5070104@gmail.com> <54EDDB94.1090902@gmail.com>
Message-ID: <54EDE0D9.6070205@gmail.com>


On 02/25/2015 03:26 PM, Peter Levart wrote:
> Ah, never mind. I missed the explicit access check that 
> getEnclosingMethod() already performs on it's own before calling 
> getDeclaredMethods(). But the check is for the same permission and 
> could be performed implicitly by getDeclaredMethods() if the caller of 
> getEnclosingMethod() was passed to it. Just an optimization 
> opportunity therefore.
>
> Peter

Or, even a better optimization:

- leave explicit check in getEnclosingMethod() as is
- call privateGetDeclaredMethods(false) instead to iterate through methods
- return a defensive copy of just the matching Method if found


Peter



From joel.franck at oracle.com  Wed Feb 25 15:10:29 2015
From: joel.franck at oracle.com (=?utf-8?Q?Joel_Borggr=C3=A9n-Franck?=)
Date: Wed, 25 Feb 2015 16:10:29 +0100
Subject: RFR 8014678: Spurious AccessControlException thrown in
	java.lang.Class.getEnclosingMethod()
In-Reply-To: <54EDE0D9.6070205@gmail.com>
References: <0C9A8736-306C-4631-8190-BD84B9DF6F27@oracle.com>
	<54EDDAB6.5070104@gmail.com> <54EDDB94.1090902@gmail.com>
	<54EDE0D9.6070205@gmail.com>
Message-ID: <C964B1D4-6121-4498-87AA-CD67A682EC80@oracle.com>

Hi Peter,

> On 25 feb 2015, at 15:48, Peter Levart <peter.levart at gmail.com> wrote:
> 
> 
> On 02/25/2015 03:26 PM, Peter Levart wrote:
>> Ah, never mind. I missed the explicit access check that getEnclosingMethod() already performs on it's own before calling getDeclaredMethods(). But the check is for the same permission and could be performed implicitly by getDeclaredMethods() if the caller of getEnclosingMethod() was passed to it. Just an optimization opportunity therefore.
>> 
>> Peter
> 
> Or, even a better optimization:
> 
> - leave explicit check in getEnclosingMethod() as is
> - call privateGetDeclaredMethods(false) instead to iterate through methods
> - return a defensive copy of just the matching Method if found

I did consider variations of this, but there is always a risk that someone someday forgets to copy methods, or uses a potential innerGetDeclaredMethods without making the proper checking beforehand. So I went for the IMO more maintainable solution. I suppose if this turns out to be a drag on performance we might be able to skip the doPrivileged if there is no SecurityManager set.

cheers
/Joel

From peter.levart at gmail.com  Wed Feb 25 15:32:47 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 25 Feb 2015 16:32:47 +0100
Subject: RFR 8014678: Spurious AccessControlException thrown in
	java.lang.Class.getEnclosingMethod()
In-Reply-To: <C964B1D4-6121-4498-87AA-CD67A682EC80@oracle.com>
References: <0C9A8736-306C-4631-8190-BD84B9DF6F27@oracle.com>
	<54EDDAB6.5070104@gmail.com> <54EDDB94.1090902@gmail.com>
	<54EDE0D9.6070205@gmail.com>
	<C964B1D4-6121-4498-87AA-CD67A682EC80@oracle.com>
Message-ID: <54EDEB1F.1000102@gmail.com>


On 02/25/2015 04:10 PM, Joel Borggr?n-Franck wrote:
> Hi Peter,
>
>> On 25 feb 2015, at 15:48, Peter Levart <peter.levart at gmail.com> wrote:
>>
>>
>> On 02/25/2015 03:26 PM, Peter Levart wrote:
>>> Ah, never mind. I missed the explicit access check that getEnclosingMethod() already performs on it's own before calling getDeclaredMethods(). But the check is for the same permission and could be performed implicitly by getDeclaredMethods() if the caller of getEnclosingMethod() was passed to it. Just an optimization opportunity therefore.
>>>
>>> Peter
>> Or, even a better optimization:
>>
>> - leave explicit check in getEnclosingMethod() as is
>> - call privateGetDeclaredMethods(false) instead to iterate through methods
>> - return a defensive copy of just the matching Method if found
> I did consider variations of this, but there is always a risk that someone someday forgets to copy methods, or uses a potential innerGetDeclaredMethods without making the proper checking beforehand. So I went for the IMO more maintainable solution. I suppose if this turns out to be a drag on performance we might be able to skip the doPrivileged if there is no SecurityManager set.

getDeclaredMethod(name, types) is simmilar. It does explicit permissions 
check (as does getEnclosingMethod), it calls 
privateGetDeclaredMethods(false), searches for matching method and 
copies it before returning. That's very similar to getEnclosingMethod(), 
just the Class target and search criteria are different.

IMO, a comment at permission check and at defensive copying of the 
Method object is enough for a maintainer to watch out what (s)he's 
doing, but I guess this method is not so frequently used as 
getDeclaredMethod() to be important that it is optimal.

Regards, Peter

> cheers
> /Joel



From paul.sandoz at oracle.com  Wed Feb 25 15:41:13 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 25 Feb 2015 16:41:13 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <54DFA80E.1000108@gmail.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>
	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
	<54DFA80E.1000108@gmail.com>
Message-ID: <FA85883F-F32A-4221-B322-DB83E5DA2168@oracle.com>

Hi Peter,

On Feb 14, 2015, at 8:54 PM, Peter Levart <peter.levart at gmail.com> wrote:

> 
> On 02/12/2015 09:52 PM, Paul Sandoz wrote:
>> Hi
>> 
>> In connection with the JEP there is also a design document to help the discussion:
>> 
>>   http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
>> 
> 
> Hi Paul,
> 
> Thinking about this proposal, I can't escape the feeling that the design favors JDK as the only target for which multi-version jars exist.

There is a reason you cannot escape that feeling :-) because as currently designed it is intended only to version a JAR over major Java platform versions.

Your maven-inspried profile solution is an interesting, but  do think it increases the complexity by expanding versioning to any dependency.

A MVJAR (a unit of release) now has two or more sets of dependencies. The developer has to layout the classpath carefully with an understanding of what jar files are associated to what profile in another jar. Managing dependencies in large systems can be rather complex and i fear this will add further to that complexity.

I could see how one could more formally manage this with a module system where modules have names and declare the names of modules they depend on. Thus modules can be formally analysed and the module paths verified. But still the multiple sets of dependencies and selection of concerns me (furthermore Project Jigsaw already has a stacked schedule of stuff to do). 

So at the moment i would prefer to keep this more constrained and focused on the JDK itself. 

Paul.


From brian.goetz at oracle.com  Wed Feb 25 16:27:14 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 25 Feb 2015 11:27:14 -0500
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <CACzrW9ACv0X==y0Yz_ThjFTy2Erirhr_BZ_GiNAB8X5FoEgf=g@mail.gmail.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
	<CACzrW9ACv0X==y0Yz_ThjFTy2Erirhr_BZ_GiNAB8X5FoEgf=g@mail.gmail.com>
Message-ID: <54EDF7E2.2030401@oracle.com>



On 2/12/2015 5:59 PM, Stephen Colebourne wrote:
> Interesting direction.
>
> Reading carefully, the goal is actually very limited in scope, by
> preventing any public API changes. It doesn't help adoption of JSR-310
> for example, but will be useful for Unsafe, which is clearly a
> motivating factor.
>
> 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.)



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

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.
> (One thing feels wrong about bytes.hpp:  It insists that big-endian
> is the norm for unaligned access.  This is simply a legacy of its
> origin, for classfile and bytecode parsing.)
> 
> 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).  Those could be represented in Java
> code as you suggest, at the cost of some duplication.
> For special platforms which use a third idiom, the intrinsics
> could be adjusted.

OK.

> 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.

OK.

> 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.

OK, I'll look at that.

Andrew.


From paul.sandoz at oracle.com  Wed Feb 25 17:41:48 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 25 Feb 2015 18:41:48 +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: <B22734C2-E60F-48FC-BE05-6FDAF9512B03@oracle.com>


On Feb 25, 2015, at 5:27 PM, Brian Goetz <brian.goetz at Oracle.COM> wrote:

> 
> 
> On 2/12/2015 5:59 PM, Stephen Colebourne wrote:
>> Interesting direction.
>> 
>> Reading carefully, the goal is actually very limited in scope, by
>> preventing any public API changes. It doesn't help adoption of JSR-310
>> for example, but will be useful for Unsafe, which is clearly a
>> motivating factor.
>> 
>> 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.)
> 

In the design doc i outlined how to explicitly compile an mv-style project.

How hard would it be to hack up a new kind of maven project layout and javac compilation task that did something similar? 

Does anybody with maven expertise know more?

Paul. 


From scolebourne at joda.org  Wed Feb 25 17:45:12 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 25 Feb 2015 17:45:12 +0000
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <7E638FFB-627A-4286-A7F3-E2EEF69A952E@oracle.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>
	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
	<CACzrW9ACv0X==y0Yz_ThjFTy2Erirhr_BZ_GiNAB8X5FoEgf=g@mail.gmail.com>
	<7E638FFB-627A-4286-A7F3-E2EEF69A952E@oracle.com>
Message-ID: <CACzrW9BE9Sj7Vf5i3+oxUcUxNSjfTd8_0JregekM0CV-QdeqHw@mail.gmail.com>

On 25 February 2015 at 13:30, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> Even in the modular world i will expect class scanning will be used. While we can now iterate reliably over classes in the image i don't believe that functionality is made available for classes in modules on the module path.

To be honest, being able to reliably iterate over classes in a module
is the most interesting potential feature about modules in general.
Its such an unreliable pain at the moment that it really needs
tackling, and it is a very effective tool in application design in
languages that have it (like Fantom).

On 25 February 2015 at 16:27, Brian Goetz <brian.goetz at oracle.com> 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".

In Eclipse, there is a 1:1 mapping between a project and a JDK
compiler/version. Same in Maven. And no doubt elsewhere. I don't think
making that one to many instead is likely to be a particularly small
change.

Stephen


From paul.sandoz at oracle.com  Wed Feb 25 18:03:48 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 25 Feb 2015 19:03:48 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <CACzrW9BE9Sj7Vf5i3+oxUcUxNSjfTd8_0JregekM0CV-QdeqHw@mail.gmail.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>
	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
	<CACzrW9ACv0X==y0Yz_ThjFTy2Erirhr_BZ_GiNAB8X5FoEgf=g@mail.gmail.com>
	<7E638FFB-627A-4286-A7F3-E2EEF69A952E@oracle.com>
	<CACzrW9BE9Sj7Vf5i3+oxUcUxNSjfTd8_0JregekM0CV-QdeqHw@mail.gmail.com>
Message-ID: <72ED8D7C-4E39-4AEA-88EA-915D1F9EFE4D@oracle.com>


On Feb 25, 2015, at 6:45 PM, Stephen Colebourne <scolebourne at joda.org> wrote:

> On 25 February 2015 at 13:30, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> Even in the modular world i will expect class scanning will be used. While we can now iterate reliably over classes in the image i don't believe that functionality is made available for classes in modules on the module path.
> 
> To be honest, being able to reliably iterate over classes in a module
> is the most interesting potential feature about modules in general.

Really? I would have thought that the most interesting aspects would be formalizing names and dependencies so they can be computed on.


> Its such an unreliable pain at the moment that it really needs
> tackling, and it is a very effective tool in application design in
> languages that have it (like Fantom).
> 

How did they solve it? bundled their own class scanning tool?

I recall the biggest pain with class scanning was supporting Web/App servers that had their own class loader URL scheme that needed to be reverse engineered.

It seems to be a fundamental issue with class loaders. It might be possible if one know the module path in a certain context to start accessing the contents of those modules (the module system API is in flux and i would need to remind myself of it).

Paul.



From david.lloyd at redhat.com  Wed Feb 25 18:42:08 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 25 Feb 2015 12:42:08 -0600
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <B22734C2-E60F-48FC-BE05-6FDAF9512B03@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>
	<B22734C2-E60F-48FC-BE05-6FDAF9512B03@oracle.com>
Message-ID: <54EE1780.40705@redhat.com>

On 02/25/2015 11:41 AM, Paul Sandoz wrote:
>
> On Feb 25, 2015, at 5:27 PM, Brian Goetz <brian.goetz at Oracle.COM> wrote:
>
>>
>>
>> On 2/12/2015 5:59 PM, Stephen Colebourne wrote:
>>> Interesting direction.
>>>
>>> Reading carefully, the goal is actually very limited in scope, by
>>> preventing any public API changes. It doesn't help adoption of JSR-310
>>> for example, but will be useful for Unsafe, which is clearly a
>>> motivating factor.
>>>
>>> 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.)
>>
>
> In the design doc i outlined how to explicitly compile an mv-style project.
>
> How hard would it be to hack up a new kind of maven project layout and javac compilation task that did something similar?
>
> Does anybody with maven expertise know more?

I've done a little bit of work on the maven-compiler-plugin internals 
and its plexus buddies, and overall I don't think this would necessarily 
be a massive undertaking, though it might have to be, depending on some 
factors:

1) If the JDK-agnostic sources are required to be fully self-contained 
(i.e. no "outward" dependencies on JDK-specific code), it would be 
trivial to compile the JDK-agnostic code first, then the JDK-specific 
code which references the other code as dependencies.  However this 
arrangement is practically quite useless for the average developer who 
is doing this just so they could have just one JDK-specific version of 
some class used by their main code.

2) In the more likely case that the -specific and -agnostic code is 
interdependent, it gets trickier because the compiler task would have to 
(I guess) compile the code N times, once for each JDK, while also 
correlating the -specific files and discarding the redundant -agnostic 
files (leaving aside weirdness that may occur if the files actually 
*differ* due to constant expansion weirdness and so on).  This thought 
leaves me feeling not so great - it seems like there are many subtle 
ways it could fail.

3) The best scenario however is that JavaCompiler will magically do all 
this work for us, figuring out (for example) the constant stuff and 
other potential weirdness, and then organizing the resultant .class 
files in their appropriate places based on some input 
configuration/cooperation with the JavaFileManager for the task.  In 
this case I'd imagine that the maven-compiler-plugin would work as 
today, with just a few extra switches to point out the JDK-specific 
source directories, and Maven would be blissfully ignorant of any other 
considerations.

-- 
- DML


From xueming.shen at oracle.com  Wed Feb 25 19:51:46 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 25 Feb 2015 11:51:46 -0800
Subject: RFR  JDK-8073893: Enable charsets build system to configure euc_tw
	into java.base module/sun.nio.cs
Message-ID: <54EE27D2.8030500@oracle.com>

Hi, please help review the changes for

issue: 8073893: Enable charsets build system to configure euc_tw into java.base module/sun.nio.cs
webrev: http://cr.openjdk.java.net/~sherman/8073893/webrev

This is the continuation of JDK-8073152, in which we updated the build mechanism to be move
some sun.nio.cs.ext charsets from the jdk.charsets module into the java.base module. The
proposed change in this RFE is to do the same thing to enable the EUC_TW (huge, about
200k) to be built into the java.base/sun.nio.cs as well, for Solaris platform.

The change also includes a small update to move the x-COMPOUND_TEXT into the configure
file for the extended charsets provider, in stead of being hard-coded in the source file.

Thanks!
-Sherman


From Alan.Bateman at oracle.com  Wed Feb 25 20:05:18 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 25 Feb 2015 20:05:18 +0000
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <72ED8D7C-4E39-4AEA-88EA-915D1F9EFE4D@oracle.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>	<CACzrW9ACv0X==y0Yz_ThjFTy2Erirhr_BZ_GiNAB8X5FoEgf=g@mail.gmail.com>	<7E638FFB-627A-4286-A7F3-E2EEF69A952E@oracle.com>	<CACzrW9BE9Sj7Vf5i3+oxUcUxNSjfTd8_0JregekM0CV-QdeqHw@mail.gmail.com>
	<72ED8D7C-4E39-4AEA-88EA-915D1F9EFE4D@oracle.com>
Message-ID: <54EE2AFE.4000707@oracle.com>

On 25/02/2015 18:03, Paul Sandoz wrote:
> On Feb 25, 2015, at 6:45 PM, Stephen Colebourne <scolebourne at joda.org> wrote:
>
>> On 25 February 2015 at 13:30, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>> Even in the modular world i will expect class scanning will be used. While we can now iterate reliably over classes in the image i don't believe that functionality is made available for classes in modules on the module path.
>> To be honest, being able to reliably iterate over classes in a module
>> is the most interesting potential feature about modules in general.
> Really? I would have thought that the most interesting aspects would be formalizing names and dependencies so they can be computed on.
>
Right, plus encapsulation too. I've no doubt that there will be APIs 
(both new and updates to existing) to introspect the contents of modules 
but I wouldn't consider this one of the primary goals or benefits of 
modules, rather it's just something that has to happen anyway as part of 
bringing modules to the platform.

-Alan


From Alan.Bateman at oracle.com  Wed Feb 25 20:14:53 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 25 Feb 2015 20:14:53 +0000
Subject: RFR JDK-8073893: Enable charsets build system to configure euc_tw
	into java.base module/sun.nio.cs
In-Reply-To: <54EE27D2.8030500@oracle.com>
References: <54EE27D2.8030500@oracle.com>
Message-ID: <54EE2D3D.7090607@oracle.com>

On 25/02/2015 19:51, Xueming Shen wrote:
> Hi, please help review the changes for
>
> issue: 8073893: Enable charsets build system to configure euc_tw into 
> java.base module/sun.nio.cs
> webrev: http://cr.openjdk.java.net/~sherman/8073893/webrev
>
> This is the continuation of JDK-8073152, in which we updated the build 
> mechanism to be move
> some sun.nio.cs.ext charsets from the jdk.charsets module into the 
> java.base module. The
> proposed change in this RFE is to do the same thing to enable the 
> EUC_TW (huge, about
> 200k) to be built into the java.base/sun.nio.cs as well, for Solaris 
> platform.
>
> The change also includes a small update to move the x-COMPOUND_TEXT 
> into the configure
> file for the extended charsets provider, in stead of being hard-coded 
> in the source file.
This looks good to me and I don't think the static footprint size on 
Solaris is a big issue.

Were there copyright headers missing from the gensrc, just wondering 
about the change to Gensrc-jdk.charsets.gmk.

-Alan


From xueming.shen at oracle.com  Wed Feb 25 20:21:03 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 25 Feb 2015 12:21:03 -0800
Subject: RFR JDK-8073893: Enable charsets build system to configure euc_tw
	into java.base module/sun.nio.cs
In-Reply-To: <54EE2D3D.7090607@oracle.com>
References: <54EE27D2.8030500@oracle.com> <54EE2D3D.7090607@oracle.com>
Message-ID: <54EE2EAF.6000307@oracle.com>

On 02/25/2015 12:14 PM, Alan Bateman wrote:
> On 25/02/2015 19:51, Xueming Shen wrote:
>> Hi, please help review the changes for
>>
>> issue: 8073893: Enable charsets build system to configure euc_tw into java.base module/sun.nio.cs
>> webrev: http://cr.openjdk.java.net/~sherman/8073893/webrev
>>
>> This is the continuation of JDK-8073152, in which we updated the build mechanism to be move
>> some sun.nio.cs.ext charsets from the jdk.charsets module into the java.base module. The
>> proposed change in this RFE is to do the same thing to enable the EUC_TW (huge, about
>> 200k) to be built into the java.base/sun.nio.cs as well, for Solaris platform.
>>
>> The change also includes a small update to move the x-COMPOUND_TEXT into the configure
>> file for the extended charsets provider, in stead of being hard-coded in the source file.
> This looks good to me and I don't think the static footprint size on Solaris is a big issue.
>
> Were there copyright headers missing from the gensrc, just wondering about the change to Gensrc-jdk.charsets.gmk.

Thanks!

Yes, those copyright headers were missing in my last change for those hkscs.

-Sherman


From mandy.chung at oracle.com  Wed Feb 25 20:28:30 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 25 Feb 2015 12:28:30 -0800
Subject: RFR JDK-8073893: Enable charsets build system to configure euc_tw
	into java.base module/sun.nio.cs
In-Reply-To: <54EE27D2.8030500@oracle.com>
References: <54EE27D2.8030500@oracle.com>
Message-ID: <54EE306E.6080707@oracle.com>


On 2/25/2015 11:51 AM, Xueming Shen wrote:
> Hi, please help review the changes for
>
> issue: 8073893: Enable charsets build system to configure euc_tw into 
> java.base module/sun.nio.cs
> webrev: http://cr.openjdk.java.net/~sherman/8073893/webrev
>
> This is the continuation of JDK-8073152, in which we updated the build 
> mechanism to be move
> some sun.nio.cs.ext charsets from the jdk.charsets module into the 
> java.base module. The
> proposed change in this RFE is to do the same thing to enable the 
> EUC_TW (huge, about
> 200k) to be built into the java.base/sun.nio.cs as well, for Solaris 
> platform.
>
> The change also includes a small update to move the x-COMPOUND_TEXT 
> into the configure
> file for the extended charsets provider, in stead of being hard-coded 
> in the source file.

This looks fine to me (I'm learning more about the build change for 
charsets :)

Mandy


From brian.burkhalter at oracle.com  Wed Feb 25 22:12:14 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 25 Feb 2015 14:12:14 -0800
Subject: {PING! PING!} Fwd: {PING!} [9] RFR JDK-8068373: (prefs)
	FileSystemPreferences writes \0 to XML storage,
	causing loss of all preferences 
References: <729FD4ED-8D78-4680-BFD2-71527E118DD3@oracle.com>
Message-ID: <54D4C1D0-AFA5-4D54-BAB7-B1F6BDD49A02@oracle.com>

Would like to come to a conclusion on this one. There are three choices as I see it.

A) The already approved version (which has also passed CCC review): http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031591.html

B) The modified version of (A) listed as approach (1) below.

C) The other version listed as approach (2) below.

Thanks,

Brian

Begin forwarded message:

> On Feb 18, 2015, at 7:27 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
>> On Feb 18, 2015, at 12:47 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>>> On 17/02/2015 21:56, Brian Burkhalter wrote:
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031502.html
>>>> 
>>>> 
>>> It's good to see this changed to throw IAE. What about other methods that take a key (like get), do they need their javadoc updated too?
>> 
>> That?s a good point. I?ll take a look while the push of this change is pending the outcome of the CCC request I submitted.
> 
> Well the CCC request for this change to the put() method has been approved so now I return to the topic addressing the point above and noting an alternate possible approach.
> 
> 1) Current Approach
> 
> If the present approach is maintained, the get(String,String) and remove(String) methods should also throw IAEs if any of their parameters are code point U+0000. This would require an updated patch and a re-spin of the review and CCC processes.
> 
> 2) Alternate Approach
> 
> Reviewing the documentation in j.u.prefs.AbstractPreferences suggested to me an alternate approach perhaps more consistent with the extant specification. To be specific, consider these excerpts from the class documentation of AbstractPreferences:
> 
> <classDoc>
> A. The SPI methods fall into three groups concerning exception behavior. The getSpi method should never throw exceptions, [?]
> 
> B. The remaining SPI methods putSpi(String,String), removeSpi(String) and childSpi(String) have more complicated exception behavior. They are not specified to throw BackingStoreException, as they can generally obey their contracts even if the backing store is unavailable. This is true because they return no information and their effects are not required to become permanent until a subsequent call to Preferences.flush() or Preferences.sync(). Generally speaking, these SPI methods should not throw exceptions. In some implementations, there may be circumstances under which these calls cannot even enqueue the requested operation for later processing. Even under these circumstances it is generally better to simply ignore the invocation and return, rather than throwing an exception. Under these circumstances, however, all subsequent invocations of flush() and sync should return false, as returning true would imply that all previous operations had successfully been made permanent.
> </classDoc>
> 
> Note that the last sentence of the second paragraph above is in fact incorrect as both flush() and sync() are declared to ?return? void. Another bug ...
>  
> Considering the foregoing it seems to make some sense to make the following changes instead of those suggested in the currently approved approach:
> 
> i. getSpi(?\u0000?), putSpi(?\u0000?, ?\u0000?) and removeSpi(?\u0000?) are no-ops and throw no exception
> ii. childSpi(U+0000) does something TBD
> 
> At your convenience any comments  you might be able to provide on these alternatives would be appreciated.
> 
> Thanks,
> 
> Brian



From mandy.chung at oracle.com  Wed Feb 25 22:19:51 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 25 Feb 2015 14:19:51 -0800
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <FBB79C47-AC33-463D-BFA4-6D8B1CF80C00@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>
Message-ID: <54EE4A87.8050807@oracle.com>


On 2/25/2015 5:19 AM, Joel Borggr?n-Franck wrote:
> InvocationHandler::invoke unfortunately throws Throwable, but I restructured it a bit so it is easier to follow.
>
> http://cr.openjdk.java.net/~jfranck/8073056/webrev.01/

196      InvocationHandler handler = Proxy.getInvocationHandler(container);

Do you want to ensure it's from our implementation?
i.e.  sun.reflect.annotation.AnnotationInvocationHandler

204      }catch (Throwable t) { // from InvocationHandler::invoke

Missing space between } and catch

  182     // According to JLS the container must have an array-valued value
  183     // method. Get the AnnotationType, get the "value" method and invoke
  184     // it to get the content.
  190     Method m = annoType.members().get("value");
  212     m.setAccessible(true);

I am missing something here. I read the code and I think
annoType is of sun.reflect.annotation.AnnotationType type.
Does the old implementation still exist that is supported?
Which method is it in the old implementation?  If it's still
supported, as Class.getAnnotationsByType is not specified to
require any permission check nor throw any SecurityException,
and it seems that setAccessible(true) should be wrapped with
doPrivileged.

If it's not used in our implementation after your patch,
perhaps better to take m.setAccessible(true) out.

Mandy




From mandy.chung at oracle.com  Wed Feb 25 23:17:21 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 25 Feb 2015 15:17:21 -0800
Subject: RFR 8014678: Spurious AccessControlException thrown in
	java.lang.Class.getEnclosingMethod()
In-Reply-To: <0C9A8736-306C-4631-8190-BD84B9DF6F27@oracle.com>
References: <0C9A8736-306C-4631-8190-BD84B9DF6F27@oracle.com>
Message-ID: <54EE5801.3000509@oracle.com>


On 2/24/2015 3:26 AM, Joel Borggr?n-Franck wrote:
> The solution here is to insert a doPrivileged block around the call where j.l.Class gets the members to construct the answer.
>
> Webrev: http://cr.openjdk.java.net/~jfranck/8014678/

This looks fine to me.

Mandy


From mark.sheppard at oracle.com  Wed Feb 25 23:27:11 2015
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 25 Feb 2015 23:27:11 +0000
Subject: RFR: JDK-8040826 - Check jdk/src/share/native/common for uninitialized
	memory warnings
Message-ID: <54EE5A4F.6020706@oracle.com>

Hi
   please oblige and review the following small changes
http://cr.openjdk.java.net/~msheppar/8040826/webrev/

which address the issues in
https://bugs.openjdk.java.net/browse/JDK-8040826

flagged local variables are explicitly initialized

regards
Mark


From claes.redestad at oracle.com  Thu Feb 26 00:17:39 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 26 Feb 2015 01:17:39 +0100
Subject: RFR(S): 8073497: Lazy conversion of ZipEntry time
In-Reply-To: <54EB4A3C.7030308@oracle.com>
References: <54E8976B.8050104@oracle.com>
	<54E8D34C.7000805@oracle.com>	<54E93AE4.1030301@oracle.com>
	<54EA4744.1090703@oracle.com> <54EB4A3C.7030308@oracle.com>
Message-ID: <54EE6623.5020405@oracle.com>


On 2015-02-23 16:41, Claes Redestad wrote:
> On 02/22/2015 10:16 PM, Xueming Shen wrote:
>> On 2/21/15 6:11 PM, Claes Redestad wrote:
>>> Hi Sherman,
>>>
>>> On 2015-02-21 19:49, Xueming Shen wrote:
>>>> Hi Claes,
>>>>
>>>> This change basically undo the "fix" for 4759491 [1], for better 
>>>> performance ...
>>>>
>>>
>>> my intent was never to break current behavior, but that mistake can 
>>> be rectified
>>> without missing out on the startup benefit of laziness:
>>>
>>> http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.1/
>>>
>>> The time/mtime getters now use the mtime field if it exists, while 
>>> the setters will
>>> update both fields. Since getLastModified already fell back to 
>>> converting the
>>> time field rather than null if mtime wasn't set, setting mtime to a 
>>> FileTime when
>>> calling setTime seems consistent and a cheap way to preserve the 
>>> time precision.
>>>
>>> I guess a range check to skip the FileTime creation in setTime if 
>>> the time is within
>>> the DOS time bounds would be a valid optimization, since that will 
>>> typically
>>> always be the case.
>>
>>
>> It's a reasonable solution. I would assume we probably need that 
>> "range check" optimization
>> to avoid setting the "mtime" field in normal use scenario. ZOS now 
>> outputs the more accurate
>> "mtime" to the zip file using "extend timestamp" if it's not null 
>> (the entry gets bigger). The
>> assumption now is that we only output the extended timestamp if the 
>> time stamps set
>> via the setXYZTime() explicitly.
>>
>> ZOS.java
>>
>> ...
>>   432         int elenEXTT = 0;               // info-zip extended 
>> timestamp
>>   433         int flagEXTT = 0;
>>   434         if (e.mtime != null) {
>>   435             elenEXTT += 4;
>>   436             flagEXTT |= EXTT_FLAG_LMT;
>>   437         }
>>   438         if (e.atime != null) {
>>   439             elenEXTT += 4;
>>   440             flagEXTT |= EXTT_FLAG_LAT;
>>   441         }
>>   442         if (e.ctime != null) {
>>   443             elenEXTT += 4;
>>   444             flagEXTT |= EXTT_FLAT_CT;
>>   445         }
>>   446         if (flagEXTT != 0)
>>   447             elen += (elenEXTT + 5);    // headid(2) + size(2) + 
>> flag(1) + data
>>   448         writeShort(elen);
>> ...
>
> Here's my attempt to resolve this: 

We could preserve precision by shifting the remaining milliseconds into 
the dostime field,
since the DOS time will only use the 4 lower bytes:

http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.4/

After I went through more extensive testing and verification I realized 
that narrowing
dostime to an int and breaking this remainder hack out into a separate 
field would be
possible without affecting ZipEntry footprint; arguably cleaner, but if 
this version is
acceptable I would prefer not to.

Going this way preserves precision across the entire input range of 
setTime, thus all tests
I could find pass with this version; I've also expanded the 
TestExtraTime test to test both
far ancient, far future and near future times to verify precision is 
preserved.

I backpedaled on the getLastModifiedTime optimization to set the mtime 
field that Peter
suggested since it would have the side-effect that the extra time field 
would be written
after a call to this getter, which would be a bit too unexpected.

Thanks!

/Claes


From david.holmes at oracle.com  Thu Feb 26 00:40:24 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Feb 2015 10:40:24 +1000
Subject: Defined behavior on switch-case fall-through
In-Reply-To: <54ED9700.2030403@noctarius.com>
References: <54ED9700.2030403@noctarius.com>
Message-ID: <54EE6B78.9020005@oracle.com>

On 25/02/2015 7:33 PM, Noctarius wrote:
> Hey guys,
>
> Sorry for crashing into the mailinglist but by looking at the Java
> specification we're not really sure about it. I guess it might be
> well defined but we want to make sure.

You are asking a question about the language rather than the libraries, 
but we don't have a specific mailing list for language discussions.

> Looking at the following example we see a non natural ordered case
> for fall-through. Looking at the spec there is an example which
> defines the fall-through behavior, unfortunately the example uses a
> natural ordered list of numbers.
>
> switch(age){
> case 0:
> case 2:
> case 4:
> case 6: println("even");break;
> case 1:
> case 3:
> case 5: println("uneven");break;
> default: ....
> }
>
> In our example we do not have this behavior. We are sure the Java
> compiler will compile it as it is above but Hotspot applies, as far
> as I know, reordering on cases depending on the frequency of usage.
> I expect it to only reorder fall-through blocks or let's call it
> blocks without any order-dependency but is this how it works? Is
> this case covered by the spec? Maybe it needs another example to
> make it clear.

Ordering is irrelevant. The code generated will execute the logic as 
specified:

if (age==0 || age==2 || age==4 || age==6)
   println("even");
else if (age==1 || age==3 || age==5)
   println("uneven");
else
   // default ...

David
-----

> Thanks
>
> Chris
>


From david.holmes at oracle.com  Thu Feb 26 01:14:29 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Feb 2015 11:14:29 +1000
Subject: Annotated Type bugs in OpenJDK 8
In-Reply-To: <CAFGBEr0MNoQViKGhR_fbpL=110PNVA7f8tsjtw0VEgNCSCAsCw@mail.gmail.com>
References: <CAFGBEr0MNoQViKGhR_fbpL=110PNVA7f8tsjtw0VEgNCSCAsCw@mail.gmail.com>
Message-ID: <54EE7375.9080606@oracle.com>

Probably better discussed on core-libs-dev - cc'd.

David

On 26/02/2015 4:02 AM, Joshua Humphries wrote:
> Hey, all,
> I'm want to contribute some fixes to JDK 8 Updates related to annotated
> types in core reflection.
>
> After much pain, I finally got it to build on my Macbook. So now I'm ready
> to tackle a patch. The issues I plan to address in this patch follow:
>
>     - JDK-8057804 <https://bugs.openjdk.java.net/browse/JDK-8057804>
>     - JDK-8057898 <https://bugs.openjdk.java.net/browse/JDK-8057898>
>     - JDK-8058202 <https://bugs.openjdk.java.net/browse/JDK-8058202>
>     - JDK-8066967 <https://bugs.openjdk.java.net/browse/JDK-8066967> (marked
>     resolved as a dup of the one above, JDK-8058202, but really is *not* a
>     dup)
>
> I actually filed all of these back in September. Unfortunately, since I'm
> not an OpenJDK author, I can't login and add more comments to any of thee
> bugs or interact with the assignee through the bug dashboard :(
>
> They are all assigned to Joel Borggr?n-Franck -- so I hope you're on this
> list and see this, Joel :)
>
> The biggest change is JDK-8057804
> <https://bugs.openjdk.java.net/browse/JDK-8057804>, so I wanted to discuss
> options of how to address it.
>
> To summarize: there is a glaring omission in the
> java.lang.reflect.AnnotatedType interfaces: there is *no way* to get to the
> annotations on a (non-static, inner) parameterized type's owner.
>
> The AnnotatedParameterizedType interface really *should *have a method such
> as:
>     AnnotatedType getAnnotatedOwnerType();
>
> Without it, there is *no way* to use core reflection to examine annotations
> on the owner type. Such annotations are allowed, included in the class file
> by the compiler, and available via the model and annotation mirror APIs
> used by annotation processors. But they aren't available via core
> reflection.
>
> I've experimented with adding this method, and I have things working in a
> local development environment. But there are some nasty implications to
> adding a method to an interface. I think there are three approaches that
> can be taken:
>
>     1. Add the method to the interface. Do not supply a default
>     implementation (e.g. break compatibility). This would be very similar to
>     the action taken in Java 8 to add the #getAnnotatedBounds() method to the
>     TypeVariable interface. (Related: JDK-8062794
>     <https://bugs.openjdk.java.net/browse/JDK-8062794>)
>        - If such an incompatible change were deemed acceptable, it is
>        unlikely that it would be done in a point release. So, if this
> is the right
>        solution, it would probably need to be implemented in the JDK 9 project
>        instead of the JDK 8 Updates project
>     2. Add the method to the interface. Supply a default implementation for
>     backwards compatibility.
>        - A "best effort" implementation could grab the corresponding
>        ParameterizedType's owner and wrap it an AnnotatedType that has no
>        annotations. But then we're quietly suppressing the fact that we've lost
>        any annotations actually present.
>        - Instead of supplying an incorrect implementation, perhaps a better
>        default would be to simply throw UnsupportedOperationException, kind of
>        like the default implementation added for Iterator#remove().
>     3. Add a new interface that extends AnnotatedParameterizedType and adds
>     the method. This has the downside of polluting the namespace with redundant
>     interfaces, solely for trying to maintain compatibility. (No future code
>     should ever really use AnnotatedParameterizedType, so this feels icky.)
>
> At the moment, I'm tempted to think that option #2 is the best, with the
> default implementation being to throw.
>
> I was hoping for some feedback from folks on this list with goal of
> arriving at a solution that would be accepted into the JDK 8 Update project.
>
> ----
> *Joshua Humphries*
> joshua at bluegosling.com
>


From xueming.shen at oracle.com  Thu Feb 26 02:47:04 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 25 Feb 2015 18:47:04 -0800
Subject: RFR JDK-8073924: Update
	test/java/nio/charset/Charset/NIOCharsetAvailability.java
	to work with module system
Message-ID: <54EE8928.7050702@oracle.com>

Please help review the change for JDK-8073924.

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

Thanks,
-Sherman


From david.holmes at oracle.com  Thu Feb 26 07:20:41 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Feb 2015 17:20:41 +1000
Subject: RFR 8073354: TimSortStackSize2.java: requires
	64*2^20*sizeof(reference) continues heap space
In-Reply-To: <54EC54FA.9020503@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>
Message-ID: <54EEC949.20704@oracle.com>

On 24/02/2015 8:39 PM, Lev Priima wrote:
> I've updated summary and description.

Okay - thanks.

David

> Lev
>
> On 02/23/2015 04:55 AM, David Holmes wrote:
>> On 20/02/2015 7:57 PM, Lev Priima wrote:
>>> Functional is pretty same, but:
>>>   - make it run with a single argument '67108864' by moving @summary tag
>>> strait down to line after the @run tag
>>>   - '-Xmx385' ->'-Xms385' in run command. MaxHeapSize will adjust a
>>> accordingly.
>>>   - spaces and code style.
>>>
>>> Of course this issue may be closed as dup of JDK-8073354 and test will
>>> pass after applying JDK-8073354. But I just want to use this RFE ID to
>>> make test run with a single argument ( as you noticed previously ).
>>
>> So this is all just cleanup - which is fine in itself but seems to
>> have no bearing on the issue reported/described in the bug report. If
>> you want to use this bug ID then I think you need to change the bug
>> report substantially else it will just be confusing.
>>
>> Thanks,
>> David
>>
>>
>>> Lev
>>>
>>> On 02/20/2015 05:26 AM, David Holmes wrote:
>>>> On 19/02/2015 11:23 PM, Lev Priima wrote:
>>>>> After Jespers comments I removed catch of OOME and added minimum heap
>>>>> size required for test(-Xms385) to overcome default ergonomics for
>>>>> client.
>>>>> Please review: http://cr.openjdk.java.net/~lpriima/8073354/webrev.01/
>>>>
>>>> Didn't see this before sending my previous reply.
>>>>
>>>> I'm confused now. What functional change is now being made here ??
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Lev
>>>>>
>>>>> On 02/19/2015 03:00 PM, Lev Priima wrote:
>>>>>> There is also a problem, if the memory on host is highly fragmented,
>>>>>> then we can't allocate continuous amount of heap for creating such
>>>>>> big
>>>>>> array. I've added catch for OOME and treat this case as skip-pass to
>>>>>> make test more robust. Also I've removed explicit -Xmx385 from @run
>>>>>> tag and made it start with a single argument.
>>>>>>
>>>>>> Please review and push:
>>>>>> http://cr.openjdk.java.net/~lpriima/8073354/webrev.00/
>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8073354
>>>>>>
>>>>>> Lev
>>>>>>
>>>>>> On 02/17/2015 09:55 AM, David Holmes wrote:
>>>>>>> On 17/02/2015 3:43 PM, Lev Priima wrote:
>>>>>>>> Thanks David!
>>>>>>>> Is this expected behavior of this annotation ?
>>>>>>>
>>>>>>> Yes that is the way jtreg defines tags:
>>>>>>>
>>>>>>> http://openjdk.java.net/jtreg/tag-spec.html
>>>>>>>
>>>>>>> "The argument tokens of a tag extend from the first token after the
>>>>>>> tag token to the end of the comment, the end of the file, or the
>>>>>>> next
>>>>>>> tag token, whichever comes first."
>>>>>>>
>>>>>>> So everything between @run and @summary are taken to be the @run
>>>>>>> commands. And there's no @comment tag unfortunately.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>> Lev
>>>>>>>>
>>>>>>>> On 02/17/2015 03:20 AM, David Holmes wrote:
>>>>>>>>> On 16/02/2015 9:20 PM, David Holmes wrote:
>>>>>>>>>> On 16/02/2015 6:59 PM, Lev Priima wrote:
>>>>>>>>>>> Thanks, David,
>>>>>>>>>>> Could you please push it ?
>>>>>>>>>>
>>>>>>>>>> I will if Roger doesn't get to it first. It'll be 11 hours before
>>>>>>>>>> I can
>>>>>>>>>> push it.
>>>>>>>>>
>>>>>>>>> This has been pushed but note there is a minor issue with the
>>>>>>>>> test.
>>>>>>>>> The jtreg tag specification doesn't terminate tags on newlines,
>>>>>>>>> they
>>>>>>>>> continue until the next tag is encountered or the end of the
>>>>>>>>> comment.
>>>>>>>>> Consequently this:
>>>>>>>>>
>>>>>>>>>  * @run main/othervm -Xmx385m TimSortStackSize2 67108864
>>>>>>>>>  * not for regular execution on all platforms:
>>>>>>>>>  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>>>>>  * run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>>>>>>>
>>>>>>>>> is processed as:
>>>>>>>>>
>>>>>>>>> @run main/othervm -Xmx385m TimSortStackSize2 67108864 not for
>>>>>>>>> regular
>>>>>>>>> execution on all platforms: run main/othervm -Xmx8g
>>>>>>>>> TimSortStackSize2
>>>>>>>>> 1073741824 run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>>>>>>>
>>>>>>>>> and so TimSortStackSize2 is invoked with 18 arguments.
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>> Lev
>>>>>>>>>>>
>>>>>>>>>>> On 02/16/2015 08:55 AM, David Holmes wrote:
>>>>>>>>>>>> On 14/02/2015 12:03 AM, Lev Priima wrote:
>>>>>>>>>>>>> Please review and push:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073124
>>>>>>>>>>>>
>>>>>>>>>>>> I hadn't realized 8072909 had been pushed without final
>>>>>>>>>>>> reviewer
>>>>>>>>>>>> comments being addressed. :(
>>>>>>>>>>>>
>>>>>>>>>>>> These changes seem okay. I hope they get promoted at the same
>>>>>>>>>>>> time as
>>>>>>>>>>>> the original changeset so we don't get test failures.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>>> Lev
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 02/13/2015 05:20 AM, David Holmes wrote:
>>>>>>>>>>>>>> Hi Lev,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 13/02/2015 2:56 AM, Lev Priima wrote:
>>>>>>>>>>>>>>> Christos,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Test may fail on shorter arrays(page 8 of paper). For
>>>>>>>>>>>>>>> instance, on
>>>>>>>>>>>>>>> worst
>>>>>>>>>>>>>>> case, generated by test, it starts to fail on length
>>>>>>>>>>>>>>> 67108864.
>>>>>>>>>>>>>>> After increasing stack size of runs to merge,
>>>>>>>>>>>>>>> Arrays.sort(T[])
>>>>>>>>>>>>>>> works
>>>>>>>>>>>>>>> also on maximum possible array for HotSpot JVM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'd also like to see this documented somewhere in the code.
>>>>>>>>>>>>>> Presently
>>>>>>>>>>>>>> there is a reference to listsort.txt but then you have to go
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> find
>>>>>>>>>>>>>> it on the web. :( At a minimum could we please add:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  175          * computation below must be changed if
>>>>>>>>>>>>>> MIN_MERGE is
>>>>>>>>>>>>>> decreased.  See
>>>>>>>>>>>>>>  176          * the MIN_MERGE declaration above for more
>>>>>>>>>>>>>> information.
>>>>>>>>>>>>>> +             * The maximum value of 49 allows for an array
>>>>>>>>>>>>>> up to
>>>>>>>>>>>>>> length
>>>>>>>>>>>>>> +             * Integer.MAX_VALUE-4.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Roger, David,
>>>>>>>>>>>>>>> I've updated the test (
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ) to make it more suitable for regular execution:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    27  * @run main/othervm TimSortStackSize2 67108864
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This will still fail on small memory devices:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> :~> java TimSortStackSize2 67108864
>>>>>>>>>>>>>> Exception in thread "main" java.lang.OutOfMemoryError: Java
>>>>>>>>>>>>>> heap
>>>>>>>>>>>>>> space
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> as the default heap ergonomics may not be large enough. I
>>>>>>>>>>>>>> had to
>>>>>>>>>>>>>> add a
>>>>>>>>>>>>>> minimum heap of -Xmx385M to get it to run.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    28  * not for regular execution on all platforms:
>>>>>>>>>>>>>>>    29  * run main/othervm -Xmx8g TimSortStackSize2
>>>>>>>>>>>>>>> 1073741824
>>>>>>>>>>>>>>>    30  * run main/othervm -Xmx32g TimSortStackSize2
>>>>>>>>>>>>>>> 2147483644
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Could you please push this:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Lev
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>>>>>>>>>>>>>>> On Feb 12, 9:57pm,david.holmes at oracle.com  (David Holmes)
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> -- Subject: Re: 8072909: TimSort fails with
>>>>>>>>>>>>>>>> ArrayIndexOutOfBoundsException on
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> | Ok - thanks Lev!
>>>>>>>>>>>>>>>> |
>>>>>>>>>>>>>>>> | David
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For posterity can someone document this, and also the
>>>>>>>>>>>>>>>> value for
>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>> Integer.MAX_VALUE-4 fails?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> christos
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>


From joel.franck at oracle.com  Thu Feb 26 08:30:38 2015
From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=)
Date: Thu, 26 Feb 2015 09:30:38 +0100
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <54EE4A87.8050807@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>
Message-ID: <19E11AB6-1504-4278-8256-154A61D7CBD9@oracle.com>

Hi Mandy,

> On 25 feb 2015, at 23:19, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
> On 2/25/2015 5:19 AM, Joel Borggr?n-Franck wrote:
>> InvocationHandler::invoke unfortunately throws Throwable, but I restructured it a bit so it is easier to follow.
>> 
>> http://cr.openjdk.java.net/~jfranck/8073056/webrev.01/
> 
> 196      InvocationHandler handler = Proxy.getInvocationHandler(container);
> 
> Do you want to ensure it's from our implementation?
> i.e.  sun.reflect.annotation.AnnotationInvocationHandler
> 

I think I have a mail somewhere where Joe states that annotations were designed so that there could be other implementations of the invocation handler.  

> 204      }catch (Throwable t) { // from InvocationHandler::invoke
> 
> Missing space between } and catch

Will fix.

> 182     // According to JLS the container must have an array-valued value
> 183     // method. Get the AnnotationType, get the "value" method and invoke
> 184     // it to get the content.
> 190     Method m = annoType.members().get("value");
> 212     m.setAccessible(true);
> 
> I am missing something here. I read the code and I think
> annoType is of sun.reflect.annotation.AnnotationType type.
> Does the old implementation still exist that is supported?
> Which method is it in the old implementation?  If it's still
> supported, as Class.getAnnotationsByType is not specified to
> require any permission check nor throw any SecurityException,
> and it seems that setAccessible(true) should be wrapped with
> doPrivileged.
> 
> If it's not used in our implementation after your patch,
> perhaps better to take m.setAccessible(true) out.

I realize now that this code will probably never have worked on other hypothetical implementations of Annotations. The problem is with the default method AnnotatedElement::getDeclaredAnnotationsByType. If someone has an external implementation of AnnotatedElement (and one of the lessons from adding these methods in 8 was that there are other implementations) then if that external implementation haven?t added getDeclaredAnnotationsByType they will call into our AnnotationSupport. This is all fine if that external representation of AnnotatedElement uses our representation of Annotations, with Proxies and all. But I suspect that the conditions that would end up taking the non-proxy code path in the patch, will already fail in the check:

             AnnotationType annoType = AnnotationType.getInstance(containerClass);
             if (annoType == null)
                 throw invalidContainerException(container, null);

So what is the best thing to do here if the annotation is not Proxy based and is coming from an implementation of the AnnotatedElement interface that we don?t control and that is missing the methods added in 8? I think throwing here might be the best option, especially since we will probably already have failed in the AnnotationType.getInstance check.

cheers
/Joel

From joel.franck at oracle.com  Thu Feb 26 08:50:47 2015
From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=)
Date: Thu, 26 Feb 2015 09:50:47 +0100
Subject: RFR 8014678: Spurious AccessControlException thrown in
	java.lang.Class.getEnclosingMethod()
In-Reply-To: <54EDEB1F.1000102@gmail.com>
References: <0C9A8736-306C-4631-8190-BD84B9DF6F27@oracle.com>
	<54EDDAB6.5070104@gmail.com> <54EDDB94.1090902@gmail.com>
	<54EDE0D9.6070205@gmail.com>
	<C964B1D4-6121-4498-87AA-CD67A682EC80@oracle.com>
	<54EDEB1F.1000102@gmail.com>
Message-ID: <68FBA1FA-053C-4B9E-8492-6D693E8609E1@oracle.com>

Hi,

> On 25 feb 2015, at 16:32, Peter Levart <peter.levart at gmail.com> wrote:
> On 02/25/2015 04:10 PM, Joel Borggr?n-Franck wrote:
>> Hi Peter,
>> 
>> 
>>> On 25 feb 2015, at 15:48, Peter Levart <peter.levart at gmail.com>
>>>  wrote:
>>> 
>>> 
>>> On 02/25/2015 03:26 PM, Peter Levart wrote:
>>> 
>>>> Ah, never mind. I missed the explicit access check that getEnclosingMethod() already performs on it's own before calling getDeclaredMethods(). But the check is for the same permission and could be performed implicitly by getDeclaredMethods() if the caller of getEnclosingMethod() was passed to it. Just an optimization opportunity therefore.
>>>> 
>>>> Peter
>>>> 
>>> Or, even a better optimization:
>>> 
>>> - leave explicit check in getEnclosingMethod() as is
>>> - call privateGetDeclaredMethods(false) instead to iterate through methods
>>> - return a defensive copy of just the matching Method if found
>>> 
>> I did consider variations of this, but there is always a risk that someone someday forgets to copy methods, or uses a potential innerGetDeclaredMethods without making the proper checking beforehand. So I went for the IMO more maintainable solution. I suppose if this turns out to be a drag on performance we might be able to skip the doPrivileged if there is no SecurityManager set.
> 
> getDeclaredMethod(name, types) is simmilar. It does explicit permissions check (as does getEnclosingMethod), it calls privateGetDeclaredMethods(false), searches for matching method and copies it before returning. That's very similar to getEnclosingMethod(), just the Class target and search criteria are different.
> 
> IMO, a comment at permission check and at defensive copying of the Method object is enough for a maintainer to watch out what (s)he's doing, but I guess this method is not so frequently used as getDeclaredMethod() to be important that it is optimal.

My argument here is that every time we add uses of code that requires explicit permission checks, there is a risk that check will be forgotten someday.

As you write, my assumption is that this code isn?t in the hot path of performance critical code. If real world use cases show up where this is to slow, we can revisit.

cheers
/Joel

From joel.franck at oracle.com  Thu Feb 26 08:52:05 2015
From: joel.franck at oracle.com (=?utf-8?Q?Joel_Borggr=C3=A9n-Franck?=)
Date: Thu, 26 Feb 2015 09:52:05 +0100
Subject: RFR 8014678: Spurious AccessControlException thrown in
	java.lang.Class.getEnclosingMethod()
In-Reply-To: <0C9A8736-306C-4631-8190-BD84B9DF6F27@oracle.com>
References: <0C9A8736-306C-4631-8190-BD84B9DF6F27@oracle.com>
Message-ID: <9016F5ED-BE8B-4541-A574-1F6866EFA1C8@oracle.com>

Hi Mandy, Paul,

Thanks for the reviews!

cheers
/Joel

> On 24 feb 2015, at 12:26, Joel Borggr?n-Franck <joel.franck at oracle.com> wrote:
> 
> Hi,
> 
> Here is a fix for an old issue with Class.getEnclosingMethod() and Class.getEnclosingConstructor(). The problem is that we throw a spurious AccessControlException in some cases when looking up enclosingMethod/Ctor in the presence of a SecurityManager.
> 
> Consider the following classes: 
> 
> class C {}
> 
> class A {
>   public void someMetod() {
>        class B {}
>    }
> }
> 
> If client C has a Class<?> token for B it can call classForB.getEnclosingMethod(). While the client C must have permissions to look at declared members of A, in the nested call java.lang.Class will be looking at declared members of A while constructing the answer, and java.lang.Class might not have permissions to do this, even though the ?real? caller C has the correct permissions. So we and up with a call stack that looks like 
> 
> Caller:                               Call:
> 
> j.l.Class(for A.class)          A.class::checkMemberAccess(classloader for j.l.Class); // this can throw ACE if A is loaded in a separate loader from java.lang.Class
> j.l.Class(for B.class)          A.class::getDeclaredMethods(); // j.l.Class is the caller here
> C                                       B.class::getEnclosingMethod();
> .... application code ?.
> 
> The solution here is to insert a doPrivileged block around the call where j.l.Class gets the members to construct the answer.
> 
> Webrev: http://cr.openjdk.java.net/~jfranck/8014678/
> 
> Bug is not open but the tests show how this is reproduced.
> 
> cheers
> /Joel



From staffan.larsen at oracle.com  Thu Feb 26 09:08:01 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 26 Feb 2015 10:08:01 +0100
Subject: RFR: JDK-8072842 Add support for building native JTReg tests
In-Reply-To: <54EDB038.4000502@oracle.com>
References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com>
	<54DB0E31.3010201@oracle.com> <54DB1175.6030700@oracle.com>
	<54DB125D.2070706@oracle.com>
	<F27CF091-29B1-4C22-BDF7-DD1D3469F2BE@oracle.com>
	<54DB1528.4030708@oracle.com>
	<324EF37C-3FD2-4B8A-A509-D7315889D8DE@oracle.com>
	<54DB39C2.5010607@oracle.com>
	<31B825DC-DFD2-4EC2-81AD-9BF0FC3364CC@oracle.com>
	<54EDB038.4000502@oracle.com>
Message-ID: <E10601CD-5F54-4BF9-8C99-6B82AAE2B166@oracle.com>

As far as I can tell (I?m not a makefile expert) this looks good.

Thanks,
/Staffan

> On 25 feb 2015, at 12:21, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> On 2015-02-11 13:08, Staffan Larsen wrote:
>> 
>>>>>>>> Okay so if I just cd into hotspot/test and use the Makefile to try
>>>>>>>> and run some jtreg tests it looks to me that it will define an
>>>>>>>> invalid -nativepath
>>>>>>> 
>>>>>>> I'm not sure if that is a supported use case. David or Staffan will
>>>>>>> have to answer to that. I have not tested that, only the "whole
>>>>>>> forest" approach.
>>>>>> 
>>>>>> I?ve never done that. I?m always running all make commands from the top
>>>>>> level. Is there a problem with that?
>>>>> 
>>>>> I must confess I also haven't done that - though I often run jtreg directly from there. Other hotspot engineers may use it. If nothing else it would be a way to test out what you expect JPRT to be running.
>>>>> 
>>>>> But perhaps we just don't add the -nativepath component if TESTNATIVE_DIR remains unset?
>>>> 
>>>> Not adding -nativepath or adding it with an empty path will lead to the same errors I think: tests that need native code will fail. So it does not really matter.
>>> 
>>> If you add it with an invalid path (won't be empty as the variable is only a prefix) then tests that don't need native code may also fail. Though I don't know how jtreg responds to a non-existent nativepath.
>> 
>> You are right. Jtreg validates the that the path is a directory. So better not to specify it.
> 
> Ok. I have updated the webrev, so the -nativepath: argument is only specified if we indeed have been given a valid path to the native libraries.
> 
> The only changes between this and the previous webrev is in hotspot/test/Makefile and jdk/test/Makefile.
> 
> http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.02 <http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.02>
> 
> /Magnus



From erik.joelsson at oracle.com  Thu Feb 26 09:25:58 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 26 Feb 2015 10:25:58 +0100
Subject: RFR: JDK-8072842 Add support for building native JTReg tests
In-Reply-To: <54EDB038.4000502@oracle.com>
References: <54DA146D.3060904@oracle.com>
	<54DAB1CE.70506@oracle.com>	<54DB0E31.3010201@oracle.com>
	<54DB1175.6030700@oracle.com>	<54DB125D.2070706@oracle.com>	<F27CF091-29B1-4C22-BDF7-DD1D3469F2BE@oracle.com>	<54DB1528.4030708@oracle.com>	<324EF37C-3FD2-4B8A-A509-D7315889D8DE@oracle.com>	<54DB39C2.5010607@oracle.com>	<31B825DC-DFD2-4EC2-81AD-9BF0FC3364CC@oracle.com>
	<54EDB038.4000502@oracle.com>
Message-ID: <54EEE6A6.8050103@oracle.com>

Hello Magnus,

Overall looks good. I would prefer if some of the longer lines in 
Main.gmk were split as it's a file I often need to read. In MakeBase, 
the definition of dups, I thought we (informally) agreed to start such 
macro definitions with a newline to make them stand out more from normal 
variable declarations?

/Erik

On 2015-02-25 12:21, Magnus Ihse Bursie wrote:
> On 2015-02-11 13:08, Staffan Larsen wrote:
>>
>>>>>>>> Okay so if I just cd into hotspot/test and use the Makefile to try
>>>>>>>> and run some jtreg tests it looks to me that it will define an
>>>>>>>> invalid -nativepath
>>>>>>>
>>>>>>> I'm not sure if that is a supported use case. David or Staffan will
>>>>>>> have to answer to that. I have not tested that, only the "whole
>>>>>>> forest" approach.
>>>>>>
>>>>>> I?ve never done that. I?m always running all make commands from 
>>>>>> the top
>>>>>> level. Is there a problem with that?
>>>>>
>>>>> I must confess I also haven't done that - though I often run jtreg 
>>>>> directly from there. Other hotspot engineers may use it. If 
>>>>> nothing else it would be a way to test out what you expect JPRT to 
>>>>> be running.
>>>>>
>>>>> But perhaps we just don't add the -nativepath component if 
>>>>> TESTNATIVE_DIR remains unset?
>>>>
>>>> Not adding -nativepath or adding it with an empty path will lead to 
>>>> the same errors I think: tests that need native code will fail. So 
>>>> it does not really matter.
>>>
>>> If you add it with an invalid path (won't be empty as the variable 
>>> is only a prefix) then tests that don't need native code may also 
>>> fail. Though I don't know how jtreg responds to a non-existent 
>>> nativepath.
>>
>> You are right. Jtreg validates the that the path is a directory. So 
>> better not to specify it.
>
> Ok. I have updated the webrev, so the -nativepath: argument is only 
> specified if we indeed have been given a valid path to the native 
> libraries.
>
> The only changes between this and the previous webrev is in 
> hotspot/test/Makefile and jdk/test/Makefile.
>
> http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.02 
>
>
> /Magnus



From paul.sandoz at oracle.com  Thu Feb 26 09:31:51 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 26 Feb 2015 10:31:51 +0100
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <19E11AB6-1504-4278-8256-154A61D7CBD9@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>
Message-ID: <57CFEDF0-7BD3-4B02-9DF7-27D05D5FA96F@oracle.com>

On Feb 26, 2015, at 9:30 AM, Joel Borggr?n-Franck <joel.franck at oracle.com> wrote:
>> 182     // According to JLS the container must have an array-valued value
>> 183     // method. Get the AnnotationType, get the "value" method and invoke
>> 184     // it to get the content.
>> 190     Method m = annoType.members().get("value");
>> 212     m.setAccessible(true);
>> 
>> I am missing something here. I read the code and I think
>> annoType is of sun.reflect.annotation.AnnotationType type.
>> Does the old implementation still exist that is supported?
>> Which method is it in the old implementation?  If it's still
>> supported, as Class.getAnnotationsByType is not specified to
>> require any permission check nor throw any SecurityException,
>> and it seems that setAccessible(true) should be wrapped with
>> doPrivileged.
>> 
>> If it's not used in our implementation after your patch,
>> perhaps better to take m.setAccessible(true) out.
> 
> I realize now that this code will probably never have worked on other hypothetical implementations of Annotations. The problem is with the default method AnnotatedElement::getDeclaredAnnotationsByType. If someone has an external implementation of AnnotatedElement (and one of the lessons from adding these methods in 8 was that there are other implementations) then if that external implementation haven?t added getDeclaredAnnotationsByType they will call into our AnnotationSupport. This is all fine if that external representation of AnnotatedElement uses our representation of Annotations, with Proxies and all. But I suspect that the conditions that would end up taking the non-proxy code path in the patch, will already fail in the check:
> 
>             AnnotationType annoType = AnnotationType.getInstance(containerClass);
>             if (annoType == null)
>                 throw invalidContainerException(container, null);
> 
> So what is the best thing to do here if the annotation is not Proxy based and is coming from an implementation of the AnnotatedElement interface that we don?t control and that is missing the methods added in 8? I think throwing here might be the best option, especially since we will probably already have failed in the AnnotationType.getInstance check.
> 

From what you say it seems like throwing a USO might be the best option with an "unsupported annotation container" message. Although i presume being a Proxy is not entirely sufficient to identify that the container comes from an external implementation?

Paul.


From lev.priima at oracle.com  Thu Feb 26 11:01:42 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Thu, 26 Feb 2015 14:01:42 +0300
Subject: RFR 8073354: TimSortStackSize2.java: test cleanup: make test
	run with single argument
In-Reply-To: <54EEC949.20704@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>
Message-ID: <54EEFD16.5090009@oracle.com>

Thanks David,
Are OK with pushing this 
http://cr.openjdk.java.net/~lpriima/8073354/webrev.01/ cleanup ?

Lev

On 02/26/2015 10:20 AM, David Holmes wrote:
> On 24/02/2015 8:39 PM, Lev Priima wrote:
>> I've updated summary and description.
>
> Okay - thanks.
>
> David
>
>> Lev
>>
>> On 02/23/2015 04:55 AM, David Holmes wrote:
>>> On 20/02/2015 7:57 PM, Lev Priima wrote:
>>>> Functional is pretty same, but:
>>>>   - make it run with a single argument '67108864' by moving 
>>>> @summary tag
>>>> strait down to line after the @run tag
>>>>   - '-Xmx385' ->'-Xms385' in run command. MaxHeapSize will adjust a
>>>> accordingly.
>>>>   - spaces and code style.
>>>>
>>>> Of course this issue may be closed as dup of JDK-8073354 and test will
>>>> pass after applying JDK-8073354. But I just want to use this RFE ID to
>>>> make test run with a single argument ( as you noticed previously ).
>>>
>>> So this is all just cleanup - which is fine in itself but seems to
>>> have no bearing on the issue reported/described in the bug report. If
>>> you want to use this bug ID then I think you need to change the bug
>>> report substantially else it will just be confusing.
>>>
>>> Thanks,
>>> David
>>>
>>>
>>>> Lev
>>>>
>>>> On 02/20/2015 05:26 AM, David Holmes wrote:
>>>>> On 19/02/2015 11:23 PM, Lev Priima wrote:
>>>>>> After Jespers comments I removed catch of OOME and added minimum 
>>>>>> heap
>>>>>> size required for test(-Xms385) to overcome default ergonomics for
>>>>>> client.
>>>>>> Please review: 
>>>>>> http://cr.openjdk.java.net/~lpriima/8073354/webrev.01/
>>>>>
>>>>> Didn't see this before sending my previous reply.
>>>>>
>>>>> I'm confused now. What functional change is now being made here ??
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Lev
>>>>>>
>>>>>> On 02/19/2015 03:00 PM, Lev Priima wrote:
>>>>>>> There is also a problem, if the memory on host is highly 
>>>>>>> fragmented,
>>>>>>> then we can't allocate continuous amount of heap for creating such
>>>>>>> big
>>>>>>> array. I've added catch for OOME and treat this case as 
>>>>>>> skip-pass to
>>>>>>> make test more robust. Also I've removed explicit -Xmx385 from @run
>>>>>>> tag and made it start with a single argument.
>>>>>>>
>>>>>>> Please review and push:
>>>>>>> http://cr.openjdk.java.net/~lpriima/8073354/webrev.00/
>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8073354
>>>>>>>
>>>>>>> Lev
>>>>>>>
>>>>>>> On 02/17/2015 09:55 AM, David Holmes wrote:
>>>>>>>> On 17/02/2015 3:43 PM, Lev Priima wrote:
>>>>>>>>> Thanks David!
>>>>>>>>> Is this expected behavior of this annotation ?
>>>>>>>>
>>>>>>>> Yes that is the way jtreg defines tags:
>>>>>>>>
>>>>>>>> http://openjdk.java.net/jtreg/tag-spec.html
>>>>>>>>
>>>>>>>> "The argument tokens of a tag extend from the first token after 
>>>>>>>> the
>>>>>>>> tag token to the end of the comment, the end of the file, or the
>>>>>>>> next
>>>>>>>> tag token, whichever comes first."
>>>>>>>>
>>>>>>>> So everything between @run and @summary are taken to be the @run
>>>>>>>> commands. And there's no @comment tag unfortunately.
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Lev
>>>>>>>>>
>>>>>>>>> On 02/17/2015 03:20 AM, David Holmes wrote:
>>>>>>>>>> On 16/02/2015 9:20 PM, David Holmes wrote:
>>>>>>>>>>> On 16/02/2015 6:59 PM, Lev Priima wrote:
>>>>>>>>>>>> Thanks, David,
>>>>>>>>>>>> Could you please push it ?
>>>>>>>>>>>
>>>>>>>>>>> I will if Roger doesn't get to it first. It'll be 11 hours 
>>>>>>>>>>> before
>>>>>>>>>>> I can
>>>>>>>>>>> push it.
>>>>>>>>>>
>>>>>>>>>> This has been pushed but note there is a minor issue with the
>>>>>>>>>> test.
>>>>>>>>>> The jtreg tag specification doesn't terminate tags on newlines,
>>>>>>>>>> they
>>>>>>>>>> continue until the next tag is encountered or the end of the
>>>>>>>>>> comment.
>>>>>>>>>> Consequently this:
>>>>>>>>>>
>>>>>>>>>>  * @run main/othervm -Xmx385m TimSortStackSize2 67108864
>>>>>>>>>>  * not for regular execution on all platforms:
>>>>>>>>>>  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>>>>>>  * run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>>>>>>>>
>>>>>>>>>> is processed as:
>>>>>>>>>>
>>>>>>>>>> @run main/othervm -Xmx385m TimSortStackSize2 67108864 not for
>>>>>>>>>> regular
>>>>>>>>>> execution on all platforms: run main/othervm -Xmx8g
>>>>>>>>>> TimSortStackSize2
>>>>>>>>>> 1073741824 run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>>>>>>>>
>>>>>>>>>> and so TimSortStackSize2 is invoked with 18 arguments.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>> Lev
>>>>>>>>>>>>
>>>>>>>>>>>> On 02/16/2015 08:55 AM, David Holmes wrote:
>>>>>>>>>>>>> On 14/02/2015 12:03 AM, Lev Priima wrote:
>>>>>>>>>>>>>> Please review and push:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073124
>>>>>>>>>>>>>
>>>>>>>>>>>>> I hadn't realized 8072909 had been pushed without final
>>>>>>>>>>>>> reviewer
>>>>>>>>>>>>> comments being addressed. :(
>>>>>>>>>>>>>
>>>>>>>>>>>>> These changes seem okay. I hope they get promoted at the same
>>>>>>>>>>>>> time as
>>>>>>>>>>>>> the original changeset so we don't get test failures.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> David
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Lev
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 02/13/2015 05:20 AM, David Holmes wrote:
>>>>>>>>>>>>>>> Hi Lev,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 13/02/2015 2:56 AM, Lev Priima wrote:
>>>>>>>>>>>>>>>> Christos,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Test may fail on shorter arrays(page 8 of paper). For
>>>>>>>>>>>>>>>> instance, on
>>>>>>>>>>>>>>>> worst
>>>>>>>>>>>>>>>> case, generated by test, it starts to fail on length
>>>>>>>>>>>>>>>> 67108864.
>>>>>>>>>>>>>>>> After increasing stack size of runs to merge,
>>>>>>>>>>>>>>>> Arrays.sort(T[])
>>>>>>>>>>>>>>>> works
>>>>>>>>>>>>>>>> also on maximum possible array for HotSpot JVM.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'd also like to see this documented somewhere in the code.
>>>>>>>>>>>>>>> Presently
>>>>>>>>>>>>>>> there is a reference to listsort.txt but then you have 
>>>>>>>>>>>>>>> to go
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> find
>>>>>>>>>>>>>>> it on the web. :( At a minimum could we please add:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  175          * computation below must be changed if
>>>>>>>>>>>>>>> MIN_MERGE is
>>>>>>>>>>>>>>> decreased.  See
>>>>>>>>>>>>>>>  176          * the MIN_MERGE declaration above for more
>>>>>>>>>>>>>>> information.
>>>>>>>>>>>>>>> +             * The maximum value of 49 allows for an array
>>>>>>>>>>>>>>> up to
>>>>>>>>>>>>>>> length
>>>>>>>>>>>>>>> +             * Integer.MAX_VALUE-4.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Roger, David,
>>>>>>>>>>>>>>>> I've updated the test (
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html 
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ) to make it more suitable for regular execution:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    27  * @run main/othervm TimSortStackSize2 67108864
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This will still fail on small memory devices:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> :~> java TimSortStackSize2 67108864
>>>>>>>>>>>>>>> Exception in thread "main" java.lang.OutOfMemoryError: Java
>>>>>>>>>>>>>>> heap
>>>>>>>>>>>>>>> space
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> as the default heap ergonomics may not be large enough. I
>>>>>>>>>>>>>>> had to
>>>>>>>>>>>>>>> add a
>>>>>>>>>>>>>>> minimum heap of -Xmx385M to get it to run.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    28  * not for regular execution on all platforms:
>>>>>>>>>>>>>>>>    29  * run main/othervm -Xmx8g TimSortStackSize2
>>>>>>>>>>>>>>>> 1073741824
>>>>>>>>>>>>>>>>    30  * run main/othervm -Xmx32g TimSortStackSize2
>>>>>>>>>>>>>>>> 2147483644
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Could you please push this:
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>>>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Lev
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>>>>>>>>>>>>>>>> On Feb 12, 9:57pm,david.holmes at oracle.com (David Holmes)
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> -- Subject: Re: 8072909: TimSort fails with
>>>>>>>>>>>>>>>>> ArrayIndexOutOfBoundsException on
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> | Ok - thanks Lev!
>>>>>>>>>>>>>>>>> |
>>>>>>>>>>>>>>>>> | David
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> For posterity can someone document this, and also the
>>>>>>>>>>>>>>>>> value for
>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>> Integer.MAX_VALUE-4 fails?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> christos
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>



From chris.hegarty at oracle.com  Thu Feb 26 11:38:22 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 26 Feb 2015 11:38:22 +0000
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <2A98B462-287D-43C1-99FA-8CF58BCA93BB@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com> <54E71BC3.30403@oracle.com>
	<54E74E29.2060806@gmail.com> <54EB08A5.4000905@oracle.com>
	<54EB96B8.30304@gmail.com>
	<DAFD881E-4105-4140-AEEC-7724A5C84C6D@oracle.com>
	<54EC6464.8090608@gmail.com>
	<2A98B462-287D-43C1-99FA-8CF58BCA93BB@oracle.com>
Message-ID: <EAA6E2DA-AB45-4C35-A1AD-2493E82275B9@oracle.com>

On 24 Feb 2015, at 15:07, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> On 24 Feb 2015, at 11:45, Peter Levart <peter.levart at gmail.com> wrote:
> ...
>> That's better now. Let me just try to measure the overhead of tracking on simple objects to see if it actually pays off or is contra-productive in any case.
> 
> Thanks. I?ll see if I can get some measurements also.

I created a very simple benchmark [1] that deserializes a single object with no fields. Run with JDK 9 b52, on a reasonably fast machine ( results [2] ), we can see the time taken to reconstitute the simple object is relatively large compared to the measured 5ns [3] for the fence on a, slower, ARM processor. The fence should be a noop on x86 and SPARC.  When you start adding fields to object being deserialized [4] the time increases significantly. 

Result: 2176.895 ??(99.9%) 72.194 ns/op [Average]
  Statistics: (min, avg, max) = (2131.529, 2176.895, 2287.482), stdev = 47.752
  Confidence interval (99.9%): [2104.701, 2249.089]

Given this, I think we should issue the fence unconditionally. A nice property of this is that custom readObjects, using Unsafe, no longer need to reason about transient final fields, they can simply use putXXX for any field.

Updated, and greatly simplified, webrev:
  http://cr.openjdk.java.net/~chegar/deserialFence/webrev.04/webrev/

-Chris.

[1] http://cr.openjdk.java.net/~chegar/deserialFence/benchmark/DeserialBenchmark.java
[2] http://cr.openjdk.java.net/~chegar/deserialFence/benchmark/results.txt
[3] http://shipilev.net/blog/2014/all-fields-are-final/
[4] http://cr.openjdk.java.net/~chegar/deserialFence/benchmark/moreFields/

From chris.hegarty at oracle.com  Thu Feb 26 11:57:37 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 26 Feb 2015 11:57:37 +0000
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <EAA6E2DA-AB45-4C35-A1AD-2493E82275B9@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com> <54E71BC3.30403@oracle.com>
	<54E74E29.2060806@gmail.com> <54EB08A5.4000905@oracle.com>
	<54EB96B8.30304@gmail.com>
	<DAFD881E-4105-4140-AEEC-7724A5C84C6D@oracle.com>
	<54EC6464.8090608@gmail.com>
	<2A98B462-287D-43C1-99FA-8CF58BCA93BB@oracle.com>
	<EAA6E2DA-AB45-4C35-A1AD-2493E82275B9@oracle.com>
Message-ID: <82BBA5EF-1A9B-48FD-883E-A9F9643AB4EA@oracle.com>


On 26 Feb 2015, at 11:38, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> On 24 Feb 2015, at 15:07, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
>> On 24 Feb 2015, at 11:45, Peter Levart <peter.levart at gmail.com> wrote:
>> ...
>>> That's better now. Let me just try to measure the overhead of tracking on simple objects to see if it actually pays off or is contra-productive in any case.
>> 
>> Thanks. I?ll see if I can get some measurements also.
> 
> I created a very simple benchmark [1] that deserializes a single object with no fields. Run with JDK 9 b52, on a reasonably fast machine ( results [2] ), we can see the time taken to reconstitute the simple object is relatively large compared to the measured 5ns [3] for the fence on a, slower, ARM processor.

Of course, this measurement was for a hotspots post construction StoreStore, we are issuing a StoreStore|StoreLoad, but the general idea is still the same, the fence is relatively insignificant, when performed per graph, compared to the cost or re-consisituing the graph.

-Chris.

> The fence should be a noop on x86 and SPARC.  When you start adding fields to object being deserialized [4] the time increases significantly. 
> 
> Result: 2176.895 ??(99.9%) 72.194 ns/op [Average]
>  Statistics: (min, avg, max) = (2131.529, 2176.895, 2287.482), stdev = 47.752
>  Confidence interval (99.9%): [2104.701, 2249.089]
> 
> Given this, I think we should issue the fence unconditionally. A nice property of this is that custom readObjects, using Unsafe, no longer need to reason about transient final fields, they can simply use putXXX for any field.
> 
> Updated, and greatly simplified, webrev:
>  http://cr.openjdk.java.net/~chegar/deserialFence/webrev.04/webrev/
> 
> -Chris.
> 
> [1] http://cr.openjdk.java.net/~chegar/deserialFence/benchmark/DeserialBenchmark.java
> [2] http://cr.openjdk.java.net/~chegar/deserialFence/benchmark/results.txt
> [3] http://shipilev.net/blog/2014/all-fields-are-final/
> [4] http://cr.openjdk.java.net/~chegar/deserialFence/benchmark/moreFields/



From Roger.Riggs at Oracle.com  Thu Feb 26 14:23:20 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 26 Feb 2015 09:23:20 -0500
Subject: RFR: JDK-8040826 - Check jdk/src/share/native/common for
	uninitialized memory warnings
In-Reply-To: <54EE5A4F.6020706@oracle.com>
References: <54EE5A4F.6020706@oracle.com>
Message-ID: <54EF2C58.1030104@Oracle.com>

Hi Mark,

Looks fine.

Thanks, Roger

On 2/25/2015 6:27 PM, Mark Sheppard wrote:
> Hi
>   please oblige and review the following small changes
> http://cr.openjdk.java.net/~msheppar/8040826/webrev/
>
> which address the issues in
> https://bugs.openjdk.java.net/browse/JDK-8040826
>
> flagged local variables are explicitly initialized
>
> regards
> Mark



From paul.sandoz at oracle.com  Thu Feb 26 16:02:05 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 26 Feb 2015 17:02:05 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>
	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
Message-ID: <C976000D-D17B-4309-BA91-B26CDD0647A3@oracle.com>

Hi,

If anyone wants to give this a test drive see stuff in here:

  http://cr.openjdk.java.net/~psandoz/multiversion-jar/

produced by Steve (CC'ed) who has done all the development.

For example:

  multiversion-jar $ java -version
  java version "1.7.0_72"
  Java(TM) SE Runtime Environment (build 1.7.0_72-b14)
  Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)
  multiversion-jar $ 
  multiversion-jar $ java -jar version.jar 
  I am running on version 7


  multiversion-jar $ java -jar version.jar 
  I am running on version 7
  multiversion-jar $ 
  multiversion-jar $ java -jar version.jar 
  I am running on version 7
  multiversion-jar $ 
  multiversion-jar $ java -Xbootclasspath/p:URLClassPath.jar -jar version.jar 
  I am running on version 8


  multiversion-jar $ java -version
  java version "1.9.0-internal"
  Java(TM) SE Runtime Environment (build 1.9.0-internal-sandoz_2015_01_26_16_48-b00)
  Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-sandoz_2015_01_26_16_48-b00, mixed mode)
  multiversion-jar $ 
  multiversion-jar $ java -jar version.jar 
  I am running on version 7
  multiversion-jar $ 
  multiversion-jar $ java -Xbootclasspath/p:URLClassPath.jar -jar version.jar 
  I am running on version 9

Paul.

On Feb 12, 2015, at 9:52 PM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:

> Hi
> 
> In connection with the JEP there is also a design document to help the discussion:
> 
>  http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
> 
> We are especially interesting in hearing feedback from library developers, tool/IDE developers, and anyone doing funky stuff with class loading and JAR files.
> 
> Paul.
> 
> On Feb 12, 2015, at 9:41 PM, mark.reinhold at oracle.com wrote:
> 
>> New JEP Candidate: http://openjdk.java.net/jeps/238
>> 
>> - Mark
> 



From paul.sandoz at oracle.com  Thu Feb 26 16:10:00 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 26 Feb 2015 17:10:00 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <C976000D-D17B-4309-BA91-B26CDD0647A3@oracle.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>
	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
	<C976000D-D17B-4309-BA91-B26CDD0647A3@oracle.com>
Message-ID: <6C9132FB-1498-4F85-842E-2A45635DE479@oracle.com>


On Feb 26, 2015, at 5:02 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
> 
> If anyone wants to give this a test drive see stuff in here:
> 
>  http://cr.openjdk.java.net/~psandoz/multiversion-jar/
> 
> produced by Steve (CC'ed) who has done all the development.
> 
> For example:
> 
>  multiversion-jar $ java -version
>  java version "1.7.0_72"
>  Java(TM) SE Runtime Environment (build 1.7.0_72-b14)
>  Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)
>  multiversion-jar $ 
>  multiversion-jar $ java -jar version.jar 
>  I am running on version 7
> 
> 
>  multiversion-jar $ java -jar version.jar 
>  I am running on version 7

The above two lines should be:

  multiversion-jar $ java -version
  java version "1.8.0"
  Java(TM) SE Runtime Environment (build 1.8.0-b132)
  Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)


>  multiversion-jar $ 
>  multiversion-jar $ java -jar version.jar 
>  I am running on version 7
>  multiversion-jar $ 
>  multiversion-jar $ java -Xbootclasspath/p:URLClassPath.jar -jar version.jar 
>  I am running on version 8
> 
> 
>  multiversion-jar $ java -version
>  java version "1.9.0-internal"
>  Java(TM) SE Runtime Environment (build 1.9.0-internal-sandoz_2015_01_26_16_48-b00)
>  Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-internal-sandoz_2015_01_26_16_48-b00, mixed mode)
>  multiversion-jar $ 
>  multiversion-jar $ java -jar version.jar 
>  I am running on version 7
>  multiversion-jar $ 
>  multiversion-jar $ java -Xbootclasspath/p:URLClassPath.jar -jar version.jar 
>  I am running on version 9
> 
> Paul.
> 
> On Feb 12, 2015, at 9:52 PM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
> 
>> Hi
>> 
>> In connection with the JEP there is also a design document to help the discussion:
>> 
>> http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
>> 
>> We are especially interesting in hearing feedback from library developers, tool/IDE developers, and anyone doing funky stuff with class loading and JAR files.
>> 
>> Paul.
>> 
>> On Feb 12, 2015, at 9:41 PM, mark.reinhold at oracle.com wrote:
>> 
>>> New JEP Candidate: http://openjdk.java.net/jeps/238
>>> 
>>> - Mark
>> 
> 



From mandy.chung at oracle.com  Thu Feb 26 16:34:52 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 26 Feb 2015 08:34:52 -0800
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <19E11AB6-1504-4278-8256-154A61D7CBD9@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>
Message-ID: <54EF4B2C.3000002@oracle.com>


On 2/26/2015 12:30 AM, Joel Borggr?n-Franck wrote:
> I realize now that this code will probably never have worked on other hypothetical implementations of Annotations.

This is what I was wondering when I see it expect
sun.reflect.annotation.AnnotationType.

> The problem is with the default method AnnotatedElement::getDeclaredAnnotationsByType. If someone has an external implementation of AnnotatedElement (and one of the lessons from adding these methods in 8 was that there are other implementations) then if that external implementation haven?t added getDeclaredAnnotationsByType they will call into our AnnotationSupport. This is all fine if that external representation of AnnotatedElement uses our representation of Annotations, with Proxies and all. But I suspect that the conditions that would end up taking the non-proxy code path in the patch, will already fail in the check:
>
>               AnnotationType annoType = AnnotationType.getInstance(containerClass);
>               if (annoType == null)
>                   throw invalidContainerException(container, null);
>
> So what is the best thing to do here if the annotation is not Proxy based and is coming from an implementation of the AnnotatedElement interface that we don?t control and that is missing the methods added in 8?

I did a quick search on my corpus and find only one reference to
sun.reflect.annotation.AnnotationType.  Looks like external implementation
doesn't get pass this.

> I think throwing here might be the best option, especially since we will probably already have failed in the AnnotationType.getInstance check.

I haven't studied closely the specification about support for alternate 
implementation.   One thing I would say is that if the implementation 
never works for alternate implementation, to fix JDK-8073056, I would 
simply remove line 207-218.   Perhaps file a new issue to follow up the 
support for alternate implementation if appropriate.

Mandy


From xueming.shen at oracle.com  Thu Feb 26 16:45:35 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 26 Feb 2015 08:45:35 -0800
Subject: RFR(S): 8073497: Lazy conversion of ZipEntry time
In-Reply-To: <54EE6623.5020405@oracle.com>
References: <54E8976B.8050104@oracle.com>
	<54E8D34C.7000805@oracle.com>	<54E93AE4.1030301@oracle.com>
	<54EA4744.1090703@oracle.com> <54EB4A3C.7030308@oracle.com>
	<54EE6623.5020405@oracle.com>
Message-ID: <54EF4DAF.6070907@oracle.com>

On 2/25/15 4:17 PM, Claes Redestad wrote:
>
>
> We could preserve precision by shifting the remaining milliseconds 
> into the dostime field,
> since the DOS time will only use the 4 lower bytes:
>
> http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.4/
>
> After I went through more extensive testing and verification I 
> realized that narrowing
> dostime to an int and breaking this remainder hack out into a separate 
> field would be
> possible without affecting ZipEntry footprint; arguably cleaner, but 
> if this version is
> acceptable I would prefer not to.
>
> Going this way preserves precision across the entire input range of 
> setTime, thus all tests
> I could find pass with this version; I've also expanded the 
> TestExtraTime test to test both
> far ancient, far future and near future times to verify precision is 
> preserved.
>
> I backpedaled on the getLastModifiedTime optimization to set the mtime 
> field that Peter
> suggested since it would have the side-effect that the extra time 
> field would be written
> after a call to this getter, which would be a bit too unexpected.
>
> Thanks!
>
> /Claes

Hi Claes,

It's a good idea! Given the upper half now covers that 2000 million 
seconds, the "dostime" field
is no longer a real "dos time", just wonder if we can go a little 
further.  For example simply move
the bits for years/months/days/hours/minutes/seconds out (left) a little 
more, 11(?) bits, to leave
the lower bits for the 2000 million seconds. The benefit is that the 
upper bound is no longer needed.
We need a pair of package private set/getDostime()  for ZIS, ZOS and ZF 
to access though. Yes,
it costs a little left/right bit-shift when to set/get the dostime, but 
it does not requires the
expensive  j.u.Date/timezone.

-Sherman


From vladimir.x.ivanov at oracle.com  Thu Feb 26 18:14:25 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 26 Feb 2015 21:14:25 +0300
Subject: [9] RFR (XS): 8073644: Assertion in LambdaFormEditor.bindArgumentType
	is too strict
Message-ID: <54EF6281.3040501@oracle.com>

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

After JDK-8069591 [1] which introduced LambdaForm customization, the 
assert in LambdaFormEditor.bindArgumentType became too strict.

The fix is to relax it - compare uncustomized versions. And 
LambdaFormEditor.lambdaForm is always uncustomized.

Testing: java/lang/invoke, nashorn tests

Thanks!

Best regards,
Vladimir Ivanov

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


From brian.goetz at oracle.com  Thu Feb 26 18:44:57 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 26 Feb 2015 13:44:57 -0500
Subject: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces
In-Reply-To: <313ABEF2-036C-4E7F-A15D-F3240E417629@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>
Message-ID: <54EF69A9.1000200@oracle.com>

> 1. Are there other places where we generate ACC_SYNTHETIC that should
> also get @Hidden annotations?

Compiler-generated bridge methods?



From peter.levart at gmail.com  Thu Feb 26 20:14:49 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 26 Feb 2015 21:14:49 +0100
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <CACzrW9AAzCce5D9k20GZz8XHnZ3QpRD5z_+Pv3HcquaNzK2u4Q@mail.gmail.com>
References: <54EA3A41.9000309@gmail.com>
	<CACzrW9AAzCce5D9k20GZz8XHnZ3QpRD5z_+Pv3HcquaNzK2u4Q@mail.gmail.com>
Message-ID: <54EF7EB9.1040305@gmail.com>

Hi,

Using routines for converting DOS time to Java time and back 
(java.util.zip.ZipUtils.[dosToJavaTime,javaToDosTime]) as a base for 
comparing deprecated java.util.Date API with new java.time API, here's a 
JMH test with 3 distinct implementations of those routines using 
java.util.Date, java.time.LocalDateTime and java.util.ZonedDateTime 
respectively:

http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/ZipUtilsTest.java

Running the test in unpatched JDK9 reveals these results:

Benchmark                               Mode   Samples Score  Score 
error    Units
j.t.ZipUtilsTest.dosToJavaTime_Date     avgt 15       95.644        
4.241    ns/op
j.t.ZipUtilsTest.dosToJavaTime_LDT      avgt        15 118.155        
2.980    ns/op
j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt        15 131.456        
3.586    ns/op
j.t.ZipUtilsTest.javaToDosTime_Date     avgt 15       74.692        
1.709    ns/op
j.t.ZipUtilsTest.javaToDosTime_LDT      avgt        15 134.116        
4.396    ns/op
j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt        15 141.987        
8.697    ns/op

Using LocalDateTime instead of ZonedDateTime is a little faster, but 
does not make it as fast as using java.util.Date.

With a patch for caching of ZoneId on default TimeZone, which speeds up 
repeated calls to ZoneId.systemDefault(), the results are as follows:

Benchmark                               Mode   Samples Score  Score 
error    Units
j.t.ZipUtilsTest.dosToJavaTime_Date     avgt 15       95.590        
2.354    ns/op
j.t.ZipUtilsTest.dosToJavaTime_LDT      avgt 15       79.682        
3.572    ns/op
j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt 15       86.801        
2.081    ns/op
j.t.ZipUtilsTest.javaToDosTime_Date     avgt 15       75.096        
1.178    ns/op
j.t.ZipUtilsTest.javaToDosTime_LDT      avgt 15       91.919        
2.191    ns/op
j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt 15       92.037        
2.054    ns/op

dosToJavaTime routine using LocalDateTime outperforms java.util.Date 
based. But javaToDosTime still lags behind. Profiling shows another 
point that can be optimized. In ZoneRules.getOffset(Instant) there is a 
loop over ZoneOffsetTransition[] array that searches for 1st transition 
that has its toEpochSecond value less than the Instant's epochSecond. 
This calls ZoneOffsetTransition.toEpochSecond repeatedly, converting 
ZoneOffsetTransition.transition which is a LocalDateTime to epochSecond. 
This repeated conversion is unnecessary, as ZoneOffsetTransition[] array 
is part of ZoneRules which is cached. Optimizing the 
ZoneOffsetTransition implementation (keeping both LocalDateTime variant 
and eposhSecond variant of transition time as the object's state) speeds 
up this conversion which makes the above test produce these results when 
combined with ZoneId.systemDefault() optimization:

Benchmark                               Mode   Samples Score  Score 
error    Units
j.t.ZipUtilsTest.dosToJavaTime_Date     avgt 15       92.291        
2.903    ns/op
j.t.ZipUtilsTest.dosToJavaTime_LDT      avgt 15       79.765        
3.106    ns/op
j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt 15       87.282        
2.967    ns/op
j.t.ZipUtilsTest.javaToDosTime_Date     avgt 15       76.235        
2.651    ns/op
j.t.ZipUtilsTest.javaToDosTime_LDT      avgt 15       73.115        
2.567    ns/op
j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt 15       75.701        
2.226    ns/op

For these tests I used another approach for speeding up 
ZoneId.systemDefault() which doesn't use ShareSecrets. It changes only 
TimeZone class so that base TimeZone instance is referenced from the 
clone returned by TimeZone.getDefault(). Although TimeZone object is 
unnecessarily cloned, it does not represent much overhead (probably the 
allocation is optimized away by JIT as the clone never escapes from 
ZoneId.systemDefault()):

http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.02/

The patch to ZoneOffsetTransition class is straightforward:

http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.01/


So is this a worthy improvement? What do you think about the new 
approach for optimizing ZoneId.systemDefault() compared to SharedSecrets 
based:

http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.01/

(this one still has a NPE bug in timeZone.setDefault())



Regards, Peter


On 02/23/2015 12:50 PM, Stephen Colebourne wrote:
> Having recently spent time on performance myself, I know that there
> are a number of things in the java.time package that need some work.
>
> Improving ZoneId.systemDefault() is definitely an improvement I
> welcome. The change is along the lines of that I would have made,
> involving a "secret" location to allow data to be exchanged (this code
> needs to avoid the clone). The idea of adding a public method
> TimeZone.getDefaultZoneId() is also one I'd be interested in if it
> works.
>
> On the patch, in TimeZone::toZoneId() I would use two methods:
>
> public ZoneId toZoneId() {
>   ZoneId zId = zoneId;
>   if (zId == null) {
>    zoneId = zId = toZoneId0();
>   }
> return zId;
> }
>
> private ZoneId toZoneId0() {
>   String id = getID();
>   if (ZoneInfoFile.useOldMapping() && id.length() == 3) {
>    if ("EST".equals(id)) {
>     zId = ZoneId.of("America/New_York");
>    } else if ("MST".equals(id)) {
>     zId = ZoneId.of("America/Denver");
>    } else if ("HST".equals(id)) {
>     zId = ZoneId.of("America/Honolulu");
>    } else {
>     zId = ZoneId.of(id, ZoneId.SHORT_IDS);
>    }
>   }
> }
>
> This should aid hotspot inlining (removing uncommon paths from main flow).
>
> Does the code properly handle the static setDefault() method? I
> suspect so, but will be worth a test.
>
>>> If there's no undesirable side effect then caching zoneId
>>> inside TimeZone looks reasonable to me - however I'm not an expert
>>> of the field, and I got to learn that time/date can be more complex
>>> than what I first thought ;-)
>> One thing I noticed is that there are two kinds of ZoneRulesProvider(s):
>> those that are static and allow their rules to be cached and the dynamic
>> ones, that can provide dynamic view on rules and therefore don't allow
>> caching of rules. But this aspect is encapsulated in ZoneRegion class (an
>> implementation of ZoneId). So I think an instance to ZoneRegion (or any
>> ZoneId) can be cached for indefinite time as long as it's id is the one that
>> we are looking for.
> Yes, ZoneId can be safely cached as an immutable object (probably
> never going to be a value type BTW). All current ZoneRegion instances
> have static, not dynamic, rules.
>
>
> As a final possibility, it might be possible to add a new subclass of
> TimeZone that works directly off ZoneId. (sourcing the offset rules
> from ZoneId instead of direct from the underlying data). However, the
> mutable API of TimeZone probably makes it quite hard to get right.
>
> On the specific ZIP code, using LocalDateTime rather than
> ZonedDateTime may be faster as there are less objects to create.Claes'
> code looks OK at first glance.
>
> To get more performance, effort needs to be spent on LocalDate.of()
> and LocalTime.of(). Both use very clean code, but it calls out to a
> general routine that has to lookup boundary numbers. Because they are
> general, they have quite deep call stacks, and inlining sometimes
> fails to reach them due to inlining depth limits. For those two
> critical pieces of code, the limits need to be inlined, something like
> this:
>
> public static LocalDate of(int year, int month, int dayOfMonth) {
>   if (year < Year.MIN_VALUE || year > Year.MAX_VALUE) {
>    throw new DateTimeException(genInvalidFieldMessage(YEAR, year))
>   }
>   if (month < 1 || month > 12) {
>    throw new DateTimeException(genInvalidFieldMessage(MONTH_OF_YEAR, month))
>   }
>   if (dayOfMonth < 1 || dayOfMonth > 31) {
>    throw new DateTimeException(genInvalidFieldMessage(DAY_OF_MONTH, dayOfMonth))
>   }
>   return create(year, month, dayOfMonth);
> }
> private String genInvalidFieldMessage(TemporalField field, long value) {
>   return "Invalid value for " + field + " (valid values " + this + "): " + value;
> }
>
> I've not tested if this is faster, but I'd be surprised if it wasn't.
>
> Stephen
>
>
>
> On 22 February 2015 at 20:21, Peter Levart <peter.levart at gmail.com> wrote:
>> Hi,
>>
>> I noticed internal JDK class java.util.zip.ZipUtils uses deprecated
>> java.util.Date API for implementing two methods for converting DOS to Java
>> time and back. I thought I'd try translating them to use new java.time API.
>> Translation was straightforward, but I noticed that new implementations are
>> not on par with speed to old java.util.Date versions. Here's a JMH benchmark
>> implementing those two conversion methods with java.util.Date and
>> java.time.ZonedDateTime APIs:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/ZipUtilsTest.java
>>
>> The results show the following:
>>
>> Benchmark                               Mode   Samples Score  Score error
>> Units
>> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt         5 101.890       17.570
>> ns/op
>> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt         5 137.587       13.533
>> ns/op
>> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       67.114       10.382
>> ns/op
>> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt         5 143.739       15.243
>> ns/op
>>
>>
>> Quick sampling with jvisualvm shows that a substantial time is spent
>> repeatedly obtaining ZoneId.systemDefault() instance. I checked the
>> implementation and came up with the following optimization:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.01/
>>
>> TimeZone is a mutable object and has to be defensively cloned when
>> TimeZone.getDefault() is invoked. So there's no point in caching a ZoneId
>> instance inside TimeZone instance if we cache it on a clone that is thrown
>> away each time ZoneId.systemDefault() is invoked. I use SharedSecrets to
>> access the uncloned TimeZone.defaultTimeZone instance where caching of
>> ZoneId pays of.
>>
>> I think that it was never meant to change TimeZone's ID (TimeZone.setID())
>> after such instance was put into operation (for example installed as default
>> time zone with TimeZone.setDefault()). Such use is unintended and buggy. So
>> I also changed the implementation of TimeZone.setDefault() to save a
>> defensive copy of TimeZone object as default time zone instead of a
>> reference to it.
>>
>> With this patch, the DOS/Java time conversion benchmark shows an
>> improvement:
>>
>> Benchmark                               Mode   Samples Score  Score error
>> Units
>> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt 5       97.986       18.379
>> ns/op
>> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt 5       85.010       10.863
>> ns/op
>> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       71.073       25.408
>> ns/op
>> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt 5       95.298       17.620
>> ns/op
>>
>>
>> Is this patch correct or did I miss something from the internals of
>> java.time API that does not permit such caching?
>>
>>
>> Regards, Peter
>>



From claes.redestad at oracle.com  Thu Feb 26 20:13:14 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 26 Feb 2015 21:13:14 +0100
Subject: RFR(S): 8073497: Lazy conversion of ZipEntry time
In-Reply-To: <54EF4DAF.6070907@oracle.com>
References: <54E8976B.8050104@oracle.com>
	<54E8D34C.7000805@oracle.com>	<54E93AE4.1030301@oracle.com>
	<54EA4744.1090703@oracle.com> <54EB4A3C.7030308@oracle.com>
	<54EE6623.5020405@oracle.com> <54EF4DAF.6070907@oracle.com>
Message-ID: <54EF7E5A.3020801@oracle.com>

On 02/26/2015 05:45 PM, Xueming Shen wrote:
> On 2/25/15 4:17 PM, Claes Redestad wrote:
>>
>>
>> We could preserve precision by shifting the remaining milliseconds 
>> into the dostime field,
>> since the DOS time will only use the 4 lower bytes:
>>
>> http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.4/
>>
>> After I went through more extensive testing and verification I 
>> realized that narrowing
>> dostime to an int and breaking this remainder hack out into a 
>> separate field would be
>> possible without affecting ZipEntry footprint; arguably cleaner, but 
>> if this version is
>> acceptable I would prefer not to.
>>
>> Going this way preserves precision across the entire input range of 
>> setTime, thus all tests
>> I could find pass with this version; I've also expanded the 
>> TestExtraTime test to test both
>> far ancient, far future and near future times to verify precision is 
>> preserved.
>>
>> I backpedaled on the getLastModifiedTime optimization to set the 
>> mtime field that Peter
>> suggested since it would have the side-effect that the extra time 
>> field would be written
>> after a call to this getter, which would be a bit too unexpected.
>>
>> Thanks!
>>
>> /Claes
>
> Hi Claes,
>
> It's a good idea! Given the upper half now covers that 2000 million 
> seconds, the "dostime" field
> is no longer a real "dos time", just wonder if we can go a little 
> further.  For example simply move
> the bits for years/months/days/hours/minutes/seconds out (left) a 
> little more, 11(?) bits, to leave
> the lower bits for the 2000 million seconds. The benefit is that the 
> upper bound is no longer needed.
> We need a pair of package private set/getDostime()  for ZIS, ZOS and 
> ZF to access though. Yes,
> it costs a little left/right bit-shift when to set/get the dostime, 
> but it does not requires the
> expensive  j.u.Date/timezone.

Not sure what the practical benefit would be, though: the entry we read 
from and write to is
just 32 bits, so precision will be still be lost when writing and we 
won't read more exact values.

So.. we'd still need to populate and write the extended time field 
sooner or later (although no later
than 2107) or accept the overflow to 1980. We can chose to do that 
implicitly (like in this patch:
let the dostime overflow, but output the extended timestamp for full 
precision) or leave it to the
end user to handle this by explicit use of setLastModifiedTime.

The current proposal has the benefit that the 4 bytes we write/read in 
ZIS/ZOS/ZF is the actual
dostime, the "soft" upper bound enables us to cheaply detect risk of 
overflow and act accordingly
(we could add 10 years to the bound, though), while requiring no extra 
manipulation when just
reading a zip (which I believe needs to be our optimization priority here).

We'd also have to update the javaToDosTime to do long arithmetic since 
it currently only keeps 7
bits for the year field. Minor detail, though.

/Claes

>
> -Sherman 



From xueming.shen at oracle.com  Thu Feb 26 20:42:16 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 26 Feb 2015 12:42:16 -0800
Subject: RFR(S): 8073497: Lazy conversion of ZipEntry time
In-Reply-To: <54EF7E5A.3020801@oracle.com>
References: <54E8976B.8050104@oracle.com>
	<54E8D34C.7000805@oracle.com>	<54E93AE4.1030301@oracle.com>
	<54EA4744.1090703@oracle.com> <54EB4A3C.7030308@oracle.com>
	<54EE6623.5020405@oracle.com> <54EF4DAF.6070907@oracle.com>
	<54EF7E5A.3020801@oracle.com>
Message-ID: <54EF8528.4070608@oracle.com>

On 02/26/2015 12:13 PM, Claes Redestad wrote:
> On 02/26/2015 05:45 PM, Xueming Shen wrote:
>> On 2/25/15 4:17 PM, Claes Redestad wrote:
>>>
>>>
>>> We could preserve precision by shifting the remaining milliseconds into the dostime field,
>>> since the DOS time will only use the 4 lower bytes:
>>>
>>> http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.4/
>>>
>>> After I went through more extensive testing and verification I realized that narrowing
>>> dostime to an int and breaking this remainder hack out into a separate field would be
>>> possible without affecting ZipEntry footprint; arguably cleaner, but if this version is
>>> acceptable I would prefer not to.
>>>
>>> Going this way preserves precision across the entire input range of setTime, thus all tests
>>> I could find pass with this version; I've also expanded the TestExtraTime test to test both
>>> far ancient, far future and near future times to verify precision is preserved.
>>>
>>> I backpedaled on the getLastModifiedTime optimization to set the mtime field that Peter
>>> suggested since it would have the side-effect that the extra time field would be written
>>> after a call to this getter, which would be a bit too unexpected.
>>>
>>> Thanks!
>>>
>>> /Claes
>>
>> Hi Claes,
>>
>> It's a good idea! Given the upper half now covers that 2000 million seconds, the "dostime" field
>> is no longer a real "dos time", just wonder if we can go a little further.  For example simply move
>> the bits for years/months/days/hours/minutes/seconds out (left) a little more, 11(?) bits, to leave
>> the lower bits for the 2000 million seconds. The benefit is that the upper bound is no longer needed.
>> We need a pair of package private set/getDostime()  for ZIS, ZOS and ZF to access though. Yes,
>> it costs a little left/right bit-shift when to set/get the dostime, but it does not requires the
>> expensive  j.u.Date/timezone.
>
> Not sure what the practical benefit would be, though: the entry we read from and write to is
> just 32 bits, so precision will be still be lost when writing and we won't read more exact values.
>
> So.. we'd still need to populate and write the extended time field sooner or later (although no later
> than 2107) or accept the overflow to 1980. We can chose to do that implicitly (like in this patch:
> let the dostime overflow, but output the extended timestamp for full precision) or leave it to the
> end user to handle this by explicit use of setLastModifiedTime.
>
> The current proposal has the benefit that the 4 bytes we write/read in ZIS/ZOS/ZF is the actual
> dostime, the "soft" upper bound enables us to cheaply detect risk of overflow and act accordingly
> (we could add 10 years to the bound, though), while requiring no extra manipulation when just
> reading a zip (which I believe needs to be our optimization priority here).
>
> We'd also have to update the javaToDosTime to do long arithmetic since it currently only keeps 7
> bits for the year field. Minor detail, though.
>
> /Claes

Yes, practically it does not benefit any real world zip/jar file. Just thought the upper-bound check
might not be necessary. No, I don't have a strong opinion on this one.

-Sherman


From lev.priima at oracle.com  Thu Feb 26 20:53:24 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Thu, 26 Feb 2015 23:53:24 +0300
Subject: RFR 8073354: TimSortStackSize2.java: test cleanup: make test
	run with single argument
In-Reply-To: <54EEFD16.5090009@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>
Message-ID: <54EF87C4.5000407@oracle.com>

this cleanup is also required to fix this: 
https://bugs.openjdk.java.net/browse/JDK-8073959

Lev

On 02/26/2015 02:01 PM, Lev Priima wrote:
> Thanks David,
> Are OK with pushing this 
> http://cr.openjdk.java.net/~lpriima/8073354/webrev.01/ cleanup ?
>
> Lev
>
> On 02/26/2015 10:20 AM, David Holmes wrote:
>> On 24/02/2015 8:39 PM, Lev Priima wrote:
>>> I've updated summary and description.
>>
>> Okay - thanks.
>>
>> David
>>
>>> Lev
>>>
>>> On 02/23/2015 04:55 AM, David Holmes wrote:
>>>> On 20/02/2015 7:57 PM, Lev Priima wrote:
>>>>> Functional is pretty same, but:
>>>>>   - make it run with a single argument '67108864' by moving 
>>>>> @summary tag
>>>>> strait down to line after the @run tag
>>>>>   - '-Xmx385' ->'-Xms385' in run command. MaxHeapSize will adjust a
>>>>> accordingly.
>>>>>   - spaces and code style.
>>>>>
>>>>> Of course this issue may be closed as dup of JDK-8073354 and test 
>>>>> will
>>>>> pass after applying JDK-8073354. But I just want to use this RFE 
>>>>> ID to
>>>>> make test run with a single argument ( as you noticed previously ).
>>>>
>>>> So this is all just cleanup - which is fine in itself but seems to
>>>> have no bearing on the issue reported/described in the bug report. If
>>>> you want to use this bug ID then I think you need to change the bug
>>>> report substantially else it will just be confusing.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>
>>>>> Lev
>>>>>
>>>>> On 02/20/2015 05:26 AM, David Holmes wrote:
>>>>>> On 19/02/2015 11:23 PM, Lev Priima wrote:
>>>>>>> After Jespers comments I removed catch of OOME and added minimum 
>>>>>>> heap
>>>>>>> size required for test(-Xms385) to overcome default ergonomics for
>>>>>>> client.
>>>>>>> Please review: 
>>>>>>> http://cr.openjdk.java.net/~lpriima/8073354/webrev.01/
>>>>>>
>>>>>> Didn't see this before sending my previous reply.
>>>>>>
>>>>>> I'm confused now. What functional change is now being made here ??
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Lev
>>>>>>>
>>>>>>> On 02/19/2015 03:00 PM, Lev Priima wrote:
>>>>>>>> There is also a problem, if the memory on host is highly 
>>>>>>>> fragmented,
>>>>>>>> then we can't allocate continuous amount of heap for creating such
>>>>>>>> big
>>>>>>>> array. I've added catch for OOME and treat this case as 
>>>>>>>> skip-pass to
>>>>>>>> make test more robust. Also I've removed explicit -Xmx385 from 
>>>>>>>> @run
>>>>>>>> tag and made it start with a single argument.
>>>>>>>>
>>>>>>>> Please review and push:
>>>>>>>> http://cr.openjdk.java.net/~lpriima/8073354/webrev.00/
>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8073354
>>>>>>>>
>>>>>>>> Lev
>>>>>>>>
>>>>>>>> On 02/17/2015 09:55 AM, David Holmes wrote:
>>>>>>>>> On 17/02/2015 3:43 PM, Lev Priima wrote:
>>>>>>>>>> Thanks David!
>>>>>>>>>> Is this expected behavior of this annotation ?
>>>>>>>>>
>>>>>>>>> Yes that is the way jtreg defines tags:
>>>>>>>>>
>>>>>>>>> http://openjdk.java.net/jtreg/tag-spec.html
>>>>>>>>>
>>>>>>>>> "The argument tokens of a tag extend from the first token 
>>>>>>>>> after the
>>>>>>>>> tag token to the end of the comment, the end of the file, or the
>>>>>>>>> next
>>>>>>>>> tag token, whichever comes first."
>>>>>>>>>
>>>>>>>>> So everything between @run and @summary are taken to be the @run
>>>>>>>>> commands. And there's no @comment tag unfortunately.
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> Lev
>>>>>>>>>>
>>>>>>>>>> On 02/17/2015 03:20 AM, David Holmes wrote:
>>>>>>>>>>> On 16/02/2015 9:20 PM, David Holmes wrote:
>>>>>>>>>>>> On 16/02/2015 6:59 PM, Lev Priima wrote:
>>>>>>>>>>>>> Thanks, David,
>>>>>>>>>>>>> Could you please push it ?
>>>>>>>>>>>>
>>>>>>>>>>>> I will if Roger doesn't get to it first. It'll be 11 hours 
>>>>>>>>>>>> before
>>>>>>>>>>>> I can
>>>>>>>>>>>> push it.
>>>>>>>>>>>
>>>>>>>>>>> This has been pushed but note there is a minor issue with the
>>>>>>>>>>> test.
>>>>>>>>>>> The jtreg tag specification doesn't terminate tags on newlines,
>>>>>>>>>>> they
>>>>>>>>>>> continue until the next tag is encountered or the end of the
>>>>>>>>>>> comment.
>>>>>>>>>>> Consequently this:
>>>>>>>>>>>
>>>>>>>>>>>  * @run main/othervm -Xmx385m TimSortStackSize2 67108864
>>>>>>>>>>>  * not for regular execution on all platforms:
>>>>>>>>>>>  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>>>>>>>  * run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>>>>>>>>>
>>>>>>>>>>> is processed as:
>>>>>>>>>>>
>>>>>>>>>>> @run main/othervm -Xmx385m TimSortStackSize2 67108864 not for
>>>>>>>>>>> regular
>>>>>>>>>>> execution on all platforms: run main/othervm -Xmx8g
>>>>>>>>>>> TimSortStackSize2
>>>>>>>>>>> 1073741824 run main/othervm -Xmx16g TimSortStackSize2 
>>>>>>>>>>> 2147483644
>>>>>>>>>>>
>>>>>>>>>>> and so TimSortStackSize2 is invoked with 18 arguments.
>>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>> -----
>>>>>>>>>>>
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>>> Lev
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 02/16/2015 08:55 AM, David Holmes wrote:
>>>>>>>>>>>>>> On 14/02/2015 12:03 AM, Lev Priima wrote:
>>>>>>>>>>>>>>> Please review and push:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073124
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I hadn't realized 8072909 had been pushed without final
>>>>>>>>>>>>>> reviewer
>>>>>>>>>>>>>> comments being addressed. :(
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> These changes seem okay. I hope they get promoted at the 
>>>>>>>>>>>>>> same
>>>>>>>>>>>>>> time as
>>>>>>>>>>>>>> the original changeset so we don't get test failures.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Lev
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 02/13/2015 05:20 AM, David Holmes wrote:
>>>>>>>>>>>>>>>> Hi Lev,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 13/02/2015 2:56 AM, Lev Priima wrote:
>>>>>>>>>>>>>>>>> Christos,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Test may fail on shorter arrays(page 8 of paper). For
>>>>>>>>>>>>>>>>> instance, on
>>>>>>>>>>>>>>>>> worst
>>>>>>>>>>>>>>>>> case, generated by test, it starts to fail on length
>>>>>>>>>>>>>>>>> 67108864.
>>>>>>>>>>>>>>>>> After increasing stack size of runs to merge,
>>>>>>>>>>>>>>>>> Arrays.sort(T[])
>>>>>>>>>>>>>>>>> works
>>>>>>>>>>>>>>>>> also on maximum possible array for HotSpot JVM.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'd also like to see this documented somewhere in the 
>>>>>>>>>>>>>>>> code.
>>>>>>>>>>>>>>>> Presently
>>>>>>>>>>>>>>>> there is a reference to listsort.txt but then you have 
>>>>>>>>>>>>>>>> to go
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> find
>>>>>>>>>>>>>>>> it on the web. :( At a minimum could we please add:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  175          * computation below must be changed if
>>>>>>>>>>>>>>>> MIN_MERGE is
>>>>>>>>>>>>>>>> decreased.  See
>>>>>>>>>>>>>>>>  176          * the MIN_MERGE declaration above for more
>>>>>>>>>>>>>>>> information.
>>>>>>>>>>>>>>>> +             * The maximum value of 49 allows for an 
>>>>>>>>>>>>>>>> array
>>>>>>>>>>>>>>>> up to
>>>>>>>>>>>>>>>> length
>>>>>>>>>>>>>>>> +             * Integer.MAX_VALUE-4.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Roger, David,
>>>>>>>>>>>>>>>>> I've updated the test (
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html 
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ) to make it more suitable for regular execution:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>    27  * @run main/othervm TimSortStackSize2 67108864
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This will still fail on small memory devices:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> :~> java TimSortStackSize2 67108864
>>>>>>>>>>>>>>>> Exception in thread "main" java.lang.OutOfMemoryError: 
>>>>>>>>>>>>>>>> Java
>>>>>>>>>>>>>>>> heap
>>>>>>>>>>>>>>>> space
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> as the default heap ergonomics may not be large enough. I
>>>>>>>>>>>>>>>> had to
>>>>>>>>>>>>>>>> add a
>>>>>>>>>>>>>>>> minimum heap of -Xmx385M to get it to run.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>    28  * not for regular execution on all platforms:
>>>>>>>>>>>>>>>>>    29  * run main/othervm -Xmx8g TimSortStackSize2
>>>>>>>>>>>>>>>>> 1073741824
>>>>>>>>>>>>>>>>>    30  * run main/othervm -Xmx32g TimSortStackSize2
>>>>>>>>>>>>>>>>> 2147483644
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Could you please push this:
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>>>>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Lev
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>>>>>>>>>>>>>>>>> On Feb 12, 9:57pm,david.holmes at oracle.com (David Holmes)
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> -- Subject: Re: 8072909: TimSort fails with
>>>>>>>>>>>>>>>>>> ArrayIndexOutOfBoundsException on
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> | Ok - thanks Lev!
>>>>>>>>>>>>>>>>>> |
>>>>>>>>>>>>>>>>>> | David
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> For posterity can someone document this, and also the
>>>>>>>>>>>>>>>>>> value for
>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>> Integer.MAX_VALUE-4 fails?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> christos
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>



From Alan.Bateman at oracle.com  Thu Feb 26 21:05:15 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 26 Feb 2015 21:05:15 +0000
Subject: RFR JDK-8073924: Update
	test/java/nio/charset/Charset/NIOCharsetAvailability.java
	to work with module system
In-Reply-To: <54EE8928.7050702@oracle.com>
References: <54EE8928.7050702@oracle.com>
Message-ID: <54EF8A8B.3070005@oracle.com>

On 26/02/2015 02:47, Xueming Shen wrote:
> Please help review the change for JDK-8073924.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8073924
> webrev: http://cr.openjdk.java.net/~sherman/8073924/webrev
This looks okay although you should avoid walking the entire file system 
with:

   Path root1 = fs.getPath("/java.base/sun/nio.cs");
   Path root1 = fs.getPath("/jdk.charsets/sun/nio/cs/ext");
   Stream.concat(Files.walk(root1), Files.walk(root2))...

An alternative is of course Files.walkFileTree and FileVisitor that 
returns SKIP_SUBTREE.

One other thing to be aware if that jrt file system needs to change soon 
to have /modules and /packages top level directories. Sundar is working 
on that so I guess this test will need to be updated as part of that work.

-Alan



From peter.levart at gmail.com  Thu Feb 26 21:09:16 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 26 Feb 2015 22:09:16 +0100
Subject: RFR(S): 8073497: Lazy conversion of ZipEntry time
In-Reply-To: <54EE6623.5020405@oracle.com>
References: <54E8976B.8050104@oracle.com>	<54E8D34C.7000805@oracle.com>	<54E93AE4.1030301@oracle.com>	<54EA4744.1090703@oracle.com>
	<54EB4A3C.7030308@oracle.com> <54EE6623.5020405@oracle.com>
Message-ID: <54EF8B7C.3020408@gmail.com>


On 02/26/2015 01:17 AM, Claes Redestad wrote:
>
> We could preserve precision by shifting the remaining milliseconds 
> into the dostime field,
> since the DOS time will only use the 4 lower bytes:
>
> http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.4/
>
> After I went through more extensive testing and verification I 
> realized that narrowing
> dostime to an int and breaking this remainder hack out into a separate 
> field would be
> possible without affecting ZipEntry footprint; arguably cleaner, but 
> if this version is
> acceptable I would prefer not to.
>
> Going this way preserves precision across the entire input range of 
> setTime, thus all tests
> I could find pass with this version; I've also expanded the 
> TestExtraTime test to test both
> far ancient, far future and near future times to verify precision is 
> preserved.
>
> I backpedaled on the getLastModifiedTime optimization to set the mtime 
> field that Peter
> suggested since it would have the side-effect that the extra time 
> field would be written
> after a call to this getter, which would be a bit too unexpected.
>
> Thanks!
>
> /Claes

Hi Claes,

I like the backwards-compatible extended DOS time format idea. If you 
keep it as one field, you could move the code for conversion from 
millisecond Java time to/from extended DOS time format to the ZipUtils 
methods entirely (javaToXdosTime, xdosToJavaTime) to make logic in 
ZipEntry simpler. I would call the field 'xdostime' then to hint the 
reader about the format which would be nice if it was described in a 
javadoc on the field.

Regards, Peter



From Roger.Riggs at Oracle.com  Thu Feb 26 21:14:40 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 26 Feb 2015 16:14:40 -0500
Subject: RFR 9: 8044051 Test jdk/lambda/vm/InterfaceAccessFlagsTest.java gets
	IOException during compilation
Message-ID: <54EF8CC0.4010201@Oracle.com>

Please review this test fix to make the test more robust to 
configuration and
pollution of the temp directory.

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-ioex-8044051/

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

Thanks, Roger


From xueming.shen at oracle.com  Thu Feb 26 21:23:18 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 26 Feb 2015 13:23:18 -0800
Subject: RFR JDK-8073924: Update
	test/java/nio/charset/Charset/NIOCharsetAvailability.java
	to work with module system
In-Reply-To: <54EF8A8B.3070005@oracle.com>
References: <54EE8928.7050702@oracle.com> <54EF8A8B.3070005@oracle.com>
Message-ID: <54EF8EC6.5070306@oracle.com>

On 02/26/2015 01:05 PM, Alan Bateman wrote:
> On 26/02/2015 02:47, Xueming Shen wrote:
>> Please help review the change for JDK-8073924.
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8073924
>> webrev: http://cr.openjdk.java.net/~sherman/8073924/webrev
> This looks okay although you should avoid walking the entire file system with:
>
>   Path root1 = fs.getPath("/java.base/sun/nio.cs");
>   Path root1 = fs.getPath("/jdk.charsets/sun/nio/cs/ext");
>   Stream.concat(Files.walk(root1), Files.walk(root2))...

This looks nice :-) webrev has been updated accordingly.

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

Thanks,
-sherman

>
> An alternative is of course Files.walkFileTree and FileVisitor that returns SKIP_SUBTREE.
>
> One other thing to be aware if that jrt file system needs to change soon to have /modules and /packages top level directories. Sundar is working on that so I guess this test will need to be updated as part of that work.
>
> -Alan
>



From lev.priima at oracle.com  Thu Feb 26 21:23:00 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Fri, 27 Feb 2015 00:23:00 +0300
Subject: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on
	arrays longer than 1073741824
In-Reply-To: <1BCEC143FAB53F499E89DA5EB571FA0E01048063DF@USSLMMBX003.net.plm.eds.com>
References: <1BCEC143FAB53F499E89DA5EB571FA0E01048063DF@USSLMMBX003.net.plm.eds.com>
Message-ID: <54EF8EB4.4090607@oracle.com>

Hi Seth,

No. But, General direction of openjdk is mostly care about "do not 
introduce regression" in next release. All performance improvements are 
introduced with a very conservative way with checking that we do not 
slow down any previous behavior/benchmarks. I'm almost sure that simple 
increasing stack size do not introduce performance regression, but 
changing mergeCollapse() may do.

Please provide performance comparision of different fixes if you have it.

Lev

On 02/24/2015 11:51 PM, Cantrell, Seth wrote:
>
> Hi Lev,
>
> I have a quick question about your patch; did you have any time to do 
> a performance comparison on this vs. the change proposed with the bug 
> report?
>
> Thanks,
>
> Seth Cantrell
>
> Software Engineer
>
> Siemens Industry Sector
>
> Industry Automation Division
>
> Siemens Industry Sector
>
> Siemens Product Lifecycle Management Software Inc.
>
> 2000 Eastman Dr.
>
> Milford, OH 45150
>
> Tel. +1 (513) 576-3799
>
> seth.cantrell at siemens.com
>
> www.siemens.com/plm
>



From peter.levart at gmail.com  Thu Feb 26 21:27:28 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 26 Feb 2015 22:27:28 +0100
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <54EF4B2C.3000002@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>
Message-ID: <54EF8FC0.9060501@gmail.com>


On 02/26/2015 05:34 PM, Mandy Chung wrote:
>> The problem is with the default method 
>> AnnotatedElement::getDeclaredAnnotationsByType. If someone has an 
>> external implementation of AnnotatedElement (and one of the lessons 
>> from adding these methods in 8 was that there are other 
>> implementations) then if that external implementation haven?t added 
>> getDeclaredAnnotationsByType they will call into our 
>> AnnotationSupport. This is all fine if that external representation 
>> of AnnotatedElement uses our representation of Annotations, with 
>> Proxies and all. But I suspect that the conditions that would end up 
>> taking the non-proxy code path in the patch, will already fail in the 
>> check:
>>
>>               AnnotationType annoType = 
>> AnnotationType.getInstance(containerClass);
>>               if (annoType == null)
>>                   throw invalidContainerException(container, null);
>>
>> So what is the best thing to do here if the annotation is not Proxy 
>> based and is coming from an implementation of the AnnotatedElement 
>> interface that we don?t control and that is missing the methods added 
>> in 8?
>
> I did a quick search on my corpus and find only one reference to
> sun.reflect.annotation.AnnotationType.  Looks like external 
> implementation
> doesn't get pass this. 

Now I'm missing something. Why would a custom non-Proxy based annotation 
not pass the above code? I don't see anything in AnnotationType 
implementation that would be dependent on annotation implementation to 
be a Proxy. AnnotationType only deals with the annotation type, which is 
an interface, not with implementation.

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.

Regards, Peter



From peter.levart at gmail.com  Thu Feb 26 21:35:36 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 26 Feb 2015 22:35:36 +0100
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <54EF8FC0.9060501@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>
Message-ID: <54EF91A8.4050303@gmail.com>


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...

Peter

>
> Regards, Peter



From Alan.Bateman at oracle.com  Thu Feb 26 21:49:41 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 26 Feb 2015 21:49:41 +0000
Subject: RFR JDK-8073924: Update
	test/java/nio/charset/Charset/NIOCharsetAvailability.java
	to work with module system
In-Reply-To: <54EF8EC6.5070306@oracle.com>
References: <54EE8928.7050702@oracle.com> <54EF8A8B.3070005@oracle.com>
	<54EF8EC6.5070306@oracle.com>
Message-ID: <54EF94F5.2030204@oracle.com>

On 26/02/2015 21:23, Xueming Shen wrote:
>
> This looks nice :-) webrev has been updated accordingly.
>
> http://cr.openjdk.java.net/~sherman/8073924/webrev
This looks okay but if you want to reduce the code a bit then you could 
use subpath to drop the module name before mapping it to the string 
representation ,like this:

.map(p -> p.subpath(1, p.getNameCount()))
.map(Object::toString)
.filter(s -> s.endsWith(".class"))

-Alan.


From peter.levart at gmail.com  Thu Feb 26 22:04:15 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 26 Feb 2015 23:04:15 +0100
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <54EF8FC0.9060501@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>
Message-ID: <54EF985F.8050707@gmail.com>


On 02/26/2015 10:27 PM, Peter Levart wrote:
>
> On 02/26/2015 05:34 PM, Mandy Chung wrote:
>>> The problem is with the default method 
>>> AnnotatedElement::getDeclaredAnnotationsByType. If someone has an 
>>> external implementation of AnnotatedElement (and one of the lessons 
>>> from adding these methods in 8 was that there are other 
>>> implementations) then if that external implementation haven?t added 
>>> getDeclaredAnnotationsByType they will call into our 
>>> AnnotationSupport. This is all fine if that external representation 
>>> of AnnotatedElement uses our representation of Annotations, with 
>>> Proxies and all. But I suspect that the conditions that would end up 
>>> taking the non-proxy code path in the patch, will already fail in 
>>> the check:
>>>
>>>               AnnotationType annoType = 
>>> AnnotationType.getInstance(containerClass);
>>>               if (annoType == null)
>>>                   throw invalidContainerException(container, null);
>>>
>>> So what is the best thing to do here if the annotation is not Proxy 
>>> based and is coming from an implementation of the AnnotatedElement 
>>> interface that we don?t control and that is missing the methods 
>>> added in 8?
>>
>> I did a quick search on my corpus and find only one reference to
>> sun.reflect.annotation.AnnotationType.  Looks like external 
>> implementation
>> doesn't get pass this. 
>
> Now I'm missing something. Why would a custom non-Proxy based 
> annotation not pass the above code? I don't see anything in 
> AnnotationType implementation that would be dependent on annotation 
> implementation to be a Proxy. AnnotationType only deals with the 
> annotation type, which is an interface, not with implementation.

I verified this with the following code:


import java.lang.annotation.Annotation;
import java.lang.annotation.Repeatable;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.reflect.AnnotatedElement;
import java.util.Arrays;

@CustomAnnTest.Containee("a")
@CustomAnnTest.Containee("b")
@CustomAnnTest.Containee("c")
public class CustomAnnTest {

     @Retention(RetentionPolicy.RUNTIME)
     @Repeatable(Container.class)
     public @interface Containee {
         String value();
     }

     @Retention(RetentionPolicy.RUNTIME)
     public @interface Container {
         Containee[] value();
     }

     public static class MyElement implements AnnotatedElement {
         @Override
         public <T extends Annotation> T getAnnotation(Class<T> 
annotationClass) {
             for (Annotation ann : getDeclaredAnnotations()) {
                 if (ann.annotationType() == annotationClass) {
                     return annotationClass.cast(ann);
                 }
             }
             return null;
         }

         @Override
         public Annotation[] getAnnotations() {
             return getDeclaredAnnotations();
         }

         @Override
         public Annotation[] getDeclaredAnnotations() {
             return new Annotation[] {
                 new MyContainer(
                     new MyContainee("A"),
                     new MyContainee("B"),
                     new MyContainee("C")
                 )
             };
         }

         static class MyContainee implements Containee {
             final String value;

             MyContainee(String value) {
                 this.value = value;
             }

             @Override
             public String value() {
                 return value;
             }

             @Override
             public Class<? extends Annotation> annotationType() {
                 return Containee.class;
             }

             @Override
             public String toString() {
                 return "@" + annotationType().getName() + "(value=" + 
value + ")";
             }
         }

         static class MyContainer implements Container {
             final Containee[] value;

             MyContainer(Containee ... value) {
                 this.value = value;
             }

             @Override
             public Containee[] value() {
                 return value;
             }

             @Override
             public Class<? extends Annotation> annotationType() {
                 return Container.class;
             }

             @Override
             public String toString() {
                 return "@" + annotationType().getName() + "(value=" + 
Arrays.toString(value) + ")";
             }
         }
     }

     static void test(AnnotatedElement ae) {
         System.out.println(ae + ":");
System.out.println(Arrays.toString(ae.getDeclaredAnnotations()));
         System.out.println(ae.getAnnotation(Container.class));
         System.out.println(ae.getAnnotation(Containee.class));
System.out.println(Arrays.toString(ae.getDeclaredAnnotationsByType(Containee.class)));
         System.out.println();
     }

     public static void main(String[] args) {
         test(CustomAnnTest.class);
         test(new MyElement());
     }
}



... it works without problems and prints the expected:


class jdk.test.CustomAnnTest:
[@jdk.test.CustomAnnTest$Container(value=[@jdk.test.CustomAnnTest$Containee(value=a), 
@jdk.test.CustomAnnTest$Containee(value=b), 
@jdk.test.CustomAnnTest$Containee(value=c)])]
@jdk.test.CustomAnnTest$Container(value=[@jdk.test.CustomAnnTest$Containee(value=a), 
@jdk.test.CustomAnnTest$Containee(value=b), 
@jdk.test.CustomAnnTest$Containee(value=c)])
null
[@jdk.test.CustomAnnTest$Containee(value=a), 
@jdk.test.CustomAnnTest$Containee(value=b), 
@jdk.test.CustomAnnTest$Containee(value=c)]

jdk.test.CustomAnnTest$MyElement at 3764951d:
[@jdk.test.CustomAnnTest$Container(value=[@jdk.test.CustomAnnTest$Containee(value=A), 
@jdk.test.CustomAnnTest$Containee(value=B), 
@jdk.test.CustomAnnTest$Containee(value=C)])]
@jdk.test.CustomAnnTest$Container(value=[@jdk.test.CustomAnnTest$Containee(value=A), 
@jdk.test.CustomAnnTest$Containee(value=B), 
@jdk.test.CustomAnnTest$Containee(value=C)])
null
[@jdk.test.CustomAnnTest$Containee(value=A), 
@jdk.test.CustomAnnTest$Containee(value=B), 
@jdk.test.CustomAnnTest$Containee(value=C)]



From xueming.shen at oracle.com  Thu Feb 26 22:09:50 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 26 Feb 2015 14:09:50 -0800
Subject: RFR JDK-8073924: Update
	test/java/nio/charset/Charset/NIOCharsetAvailability.java
	to work with module system
In-Reply-To: <54EF94F5.2030204@oracle.com>
References: <54EE8928.7050702@oracle.com> <54EF8A8B.3070005@oracle.com>
	<54EF8EC6.5070306@oracle.com> <54EF94F5.2030204@oracle.com>
Message-ID: <54EF99AE.6020400@oracle.com>

On 02/26/2015 01:49 PM, Alan Bateman wrote:
> On 26/02/2015 21:23, Xueming Shen wrote:
>>
>> This looks nice :-) webrev has been updated accordingly.
>>
>> http://cr.openjdk.java.net/~sherman/8073924/webrev
> This looks okay but if you want to reduce the code a bit then you could use subpath to drop the module name before mapping it to the string representation ,like this:
>
> .map(p -> p.subpath(1, p.getNameCount()))
> .map(Object::toString)
> .filter(s -> s.endsWith(".class"))
>

thanks! webrev has been updated accordingly.

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

-sherman


From david.holmes at oracle.com  Thu Feb 26 22:10:46 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 27 Feb 2015 08:10:46 +1000
Subject: RFR 8073354: TimSortStackSize2.java: test cleanup: make test
	run with single argument
In-Reply-To: <54EF87C4.5000407@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>
Message-ID: <54EF99E6.4030003@oracle.com>

Okay I will push this for you Lev.

Thanks,
David

On 27/02/2015 6:53 AM, Lev Priima wrote:
> this cleanup is also required to fix this:
> https://bugs.openjdk.java.net/browse/JDK-8073959
>
> Lev
>
> On 02/26/2015 02:01 PM, Lev Priima wrote:
>> Thanks David,
>> Are OK with pushing this
>> http://cr.openjdk.java.net/~lpriima/8073354/webrev.01/ cleanup ?
>>
>> Lev
>>
>> On 02/26/2015 10:20 AM, David Holmes wrote:
>>> On 24/02/2015 8:39 PM, Lev Priima wrote:
>>>> I've updated summary and description.
>>>
>>> Okay - thanks.
>>>
>>> David
>>>
>>>> Lev
>>>>
>>>> On 02/23/2015 04:55 AM, David Holmes wrote:
>>>>> On 20/02/2015 7:57 PM, Lev Priima wrote:
>>>>>> Functional is pretty same, but:
>>>>>>   - make it run with a single argument '67108864' by moving
>>>>>> @summary tag
>>>>>> strait down to line after the @run tag
>>>>>>   - '-Xmx385' ->'-Xms385' in run command. MaxHeapSize will adjust a
>>>>>> accordingly.
>>>>>>   - spaces and code style.
>>>>>>
>>>>>> Of course this issue may be closed as dup of JDK-8073354 and test
>>>>>> will
>>>>>> pass after applying JDK-8073354. But I just want to use this RFE
>>>>>> ID to
>>>>>> make test run with a single argument ( as you noticed previously ).
>>>>>
>>>>> So this is all just cleanup - which is fine in itself but seems to
>>>>> have no bearing on the issue reported/described in the bug report. If
>>>>> you want to use this bug ID then I think you need to change the bug
>>>>> report substantially else it will just be confusing.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>
>>>>>> Lev
>>>>>>
>>>>>> On 02/20/2015 05:26 AM, David Holmes wrote:
>>>>>>> On 19/02/2015 11:23 PM, Lev Priima wrote:
>>>>>>>> After Jespers comments I removed catch of OOME and added minimum
>>>>>>>> heap
>>>>>>>> size required for test(-Xms385) to overcome default ergonomics for
>>>>>>>> client.
>>>>>>>> Please review:
>>>>>>>> http://cr.openjdk.java.net/~lpriima/8073354/webrev.01/
>>>>>>>
>>>>>>> Didn't see this before sending my previous reply.
>>>>>>>
>>>>>>> I'm confused now. What functional change is now being made here ??
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>> Lev
>>>>>>>>
>>>>>>>> On 02/19/2015 03:00 PM, Lev Priima wrote:
>>>>>>>>> There is also a problem, if the memory on host is highly
>>>>>>>>> fragmented,
>>>>>>>>> then we can't allocate continuous amount of heap for creating such
>>>>>>>>> big
>>>>>>>>> array. I've added catch for OOME and treat this case as
>>>>>>>>> skip-pass to
>>>>>>>>> make test more robust. Also I've removed explicit -Xmx385 from
>>>>>>>>> @run
>>>>>>>>> tag and made it start with a single argument.
>>>>>>>>>
>>>>>>>>> Please review and push:
>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8073354/webrev.00/
>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8073354
>>>>>>>>>
>>>>>>>>> Lev
>>>>>>>>>
>>>>>>>>> On 02/17/2015 09:55 AM, David Holmes wrote:
>>>>>>>>>> On 17/02/2015 3:43 PM, Lev Priima wrote:
>>>>>>>>>>> Thanks David!
>>>>>>>>>>> Is this expected behavior of this annotation ?
>>>>>>>>>>
>>>>>>>>>> Yes that is the way jtreg defines tags:
>>>>>>>>>>
>>>>>>>>>> http://openjdk.java.net/jtreg/tag-spec.html
>>>>>>>>>>
>>>>>>>>>> "The argument tokens of a tag extend from the first token
>>>>>>>>>> after the
>>>>>>>>>> tag token to the end of the comment, the end of the file, or the
>>>>>>>>>> next
>>>>>>>>>> tag token, whichever comes first."
>>>>>>>>>>
>>>>>>>>>> So everything between @run and @summary are taken to be the @run
>>>>>>>>>> commands. And there's no @comment tag unfortunately.
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>> Lev
>>>>>>>>>>>
>>>>>>>>>>> On 02/17/2015 03:20 AM, David Holmes wrote:
>>>>>>>>>>>> On 16/02/2015 9:20 PM, David Holmes wrote:
>>>>>>>>>>>>> On 16/02/2015 6:59 PM, Lev Priima wrote:
>>>>>>>>>>>>>> Thanks, David,
>>>>>>>>>>>>>> Could you please push it ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I will if Roger doesn't get to it first. It'll be 11 hours
>>>>>>>>>>>>> before
>>>>>>>>>>>>> I can
>>>>>>>>>>>>> push it.
>>>>>>>>>>>>
>>>>>>>>>>>> This has been pushed but note there is a minor issue with the
>>>>>>>>>>>> test.
>>>>>>>>>>>> The jtreg tag specification doesn't terminate tags on newlines,
>>>>>>>>>>>> they
>>>>>>>>>>>> continue until the next tag is encountered or the end of the
>>>>>>>>>>>> comment.
>>>>>>>>>>>> Consequently this:
>>>>>>>>>>>>
>>>>>>>>>>>>  * @run main/othervm -Xmx385m TimSortStackSize2 67108864
>>>>>>>>>>>>  * not for regular execution on all platforms:
>>>>>>>>>>>>  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>>>>>>>>  * run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>>>>>>>>>>
>>>>>>>>>>>> is processed as:
>>>>>>>>>>>>
>>>>>>>>>>>> @run main/othervm -Xmx385m TimSortStackSize2 67108864 not for
>>>>>>>>>>>> regular
>>>>>>>>>>>> execution on all platforms: run main/othervm -Xmx8g
>>>>>>>>>>>> TimSortStackSize2
>>>>>>>>>>>> 1073741824 run main/othervm -Xmx16g TimSortStackSize2
>>>>>>>>>>>> 2147483644
>>>>>>>>>>>>
>>>>>>>>>>>> and so TimSortStackSize2 is invoked with 18 arguments.
>>>>>>>>>>>>
>>>>>>>>>>>> David
>>>>>>>>>>>> -----
>>>>>>>>>>>>
>>>>>>>>>>>>> David
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Lev
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 02/16/2015 08:55 AM, David Holmes wrote:
>>>>>>>>>>>>>>> On 14/02/2015 12:03 AM, Lev Priima wrote:
>>>>>>>>>>>>>>>> Please review and push:
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073124
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I hadn't realized 8072909 had been pushed without final
>>>>>>>>>>>>>>> reviewer
>>>>>>>>>>>>>>> comments being addressed. :(
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> These changes seem okay. I hope they get promoted at the
>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>> time as
>>>>>>>>>>>>>>> the original changeset so we don't get test failures.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Lev
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 02/13/2015 05:20 AM, David Holmes wrote:
>>>>>>>>>>>>>>>>> Hi Lev,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 13/02/2015 2:56 AM, Lev Priima wrote:
>>>>>>>>>>>>>>>>>> Christos,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Test may fail on shorter arrays(page 8 of paper). For
>>>>>>>>>>>>>>>>>> instance, on
>>>>>>>>>>>>>>>>>> worst
>>>>>>>>>>>>>>>>>> case, generated by test, it starts to fail on length
>>>>>>>>>>>>>>>>>> 67108864.
>>>>>>>>>>>>>>>>>> After increasing stack size of runs to merge,
>>>>>>>>>>>>>>>>>> Arrays.sort(T[])
>>>>>>>>>>>>>>>>>> works
>>>>>>>>>>>>>>>>>> also on maximum possible array for HotSpot JVM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'd also like to see this documented somewhere in the
>>>>>>>>>>>>>>>>> code.
>>>>>>>>>>>>>>>>> Presently
>>>>>>>>>>>>>>>>> there is a reference to listsort.txt but then you have
>>>>>>>>>>>>>>>>> to go
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> find
>>>>>>>>>>>>>>>>> it on the web. :( At a minimum could we please add:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  175          * computation below must be changed if
>>>>>>>>>>>>>>>>> MIN_MERGE is
>>>>>>>>>>>>>>>>> decreased.  See
>>>>>>>>>>>>>>>>>  176          * the MIN_MERGE declaration above for more
>>>>>>>>>>>>>>>>> information.
>>>>>>>>>>>>>>>>> +             * The maximum value of 49 allows for an
>>>>>>>>>>>>>>>>> array
>>>>>>>>>>>>>>>>> up to
>>>>>>>>>>>>>>>>> length
>>>>>>>>>>>>>>>>> +             * Integer.MAX_VALUE-4.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Roger, David,
>>>>>>>>>>>>>>>>>> I've updated the test (
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ) to make it more suitable for regular execution:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    27  * @run main/othervm TimSortStackSize2 67108864
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This will still fail on small memory devices:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> :~> java TimSortStackSize2 67108864
>>>>>>>>>>>>>>>>> Exception in thread "main" java.lang.OutOfMemoryError:
>>>>>>>>>>>>>>>>> Java
>>>>>>>>>>>>>>>>> heap
>>>>>>>>>>>>>>>>> space
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> as the default heap ergonomics may not be large enough. I
>>>>>>>>>>>>>>>>> had to
>>>>>>>>>>>>>>>>> add a
>>>>>>>>>>>>>>>>> minimum heap of -Xmx385M to get it to run.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    28  * not for regular execution on all platforms:
>>>>>>>>>>>>>>>>>>    29  * run main/othervm -Xmx8g TimSortStackSize2
>>>>>>>>>>>>>>>>>> 1073741824
>>>>>>>>>>>>>>>>>>    30  * run main/othervm -Xmx32g TimSortStackSize2
>>>>>>>>>>>>>>>>>> 2147483644
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Could you please push this:
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>>>>>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Lev
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>>>>>>>>>>>>>>>>>> On Feb 12, 9:57pm,david.holmes at oracle.com (David Holmes)
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> -- Subject: Re: 8072909: TimSort fails with
>>>>>>>>>>>>>>>>>>> ArrayIndexOutOfBoundsException on
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> | Ok - thanks Lev!
>>>>>>>>>>>>>>>>>>> |
>>>>>>>>>>>>>>>>>>> | David
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> For posterity can someone document this, and also the
>>>>>>>>>>>>>>>>>>> value for
>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>> Integer.MAX_VALUE-4 fails?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> christos
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
>


From christos at zoulas.com  Thu Feb 26 22:17:59 2015
From: christos at zoulas.com (Christos Zoulas)
Date: Thu, 26 Feb 2015 17:17:59 -0500
Subject: stop using mmap for zip I/O
Message-ID: <20150226221759.4560B17FDAA@rebar.astron.com>


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


From Alan.Bateman at oracle.com  Thu Feb 26 22:24:45 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 26 Feb 2015 22:24:45 +0000
Subject: stop using mmap for zip I/O
In-Reply-To: <20150226221759.4560B17FDAA@rebar.astron.com>
References: <20150226221759.4560B17FDAA@rebar.astron.com>
Message-ID: <54EF9D2D.1080400@oracle.com>

On 26/02/2015 22: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)?
>
Sherman has a number of proposals here for some time.

In the mean-time then you run run with -Dsun.zip.disableMemoryMapping to 
disable mmapping of the CEN in environments where there is potential to 
overwrite zip files that are in use.

-Alan.


From xueming.shen at oracle.com  Thu Feb 26 22:32:26 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 26 Feb 2015 14:32:26 -0800
Subject: stop using mmap for zip I/O
In-Reply-To: <20150226221759.4560B17FDAA@rebar.astron.com>
References: <20150226221759.4560B17FDAA@rebar.astron.com>
Message-ID: <54EF9EFA.7030201@oracle.com>

On 02/26/2015 02:17 PM, 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:
>
That's true, unfortunately, the mmap does trigger crash here and there....

There is a property you can define to disable it in later releases
-Dsun.zip.disableMemoryMapping=true

There is discussion that maybe we should simply disable the mmap by default ...

And, there is further plan to simply move the general zip file handling up to
pure java, without any native code, as the webrev showed below. I'm still
hoping we can do it in jdk9 later, when everyone is not that busy and can
help codereview the change. (the webrev might be a little aged)

-Sherman

--------------------------------------------------------------------
Hi,

This one didn't make into jdk8. Here is an updated webrev for the jdk9 repo

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

And a pure java version of j.u.ZipFile is also available at

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

We do have incident reports and requests that suggest a pure Java version
of j.u.ZipFile might be preferred, especially to eliminate the possibility of
jvm crash at native level, mostly triggered by the mmap usage and/or use
scenario that the target zip/jar file is being overwritten while reading.

And java implementation also brings in the benefits of better memory usage
(all memory allocated in java heap), no more expensive jni invocations...

Opinion/comments are appreciated.

Thanks!
-Sherman
---------------------------------------------------------------------


From Alan.Bateman at oracle.com  Thu Feb 26 22:33:48 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 26 Feb 2015 22:33:48 +0000
Subject: RFR JDK-8073924: Update
	test/java/nio/charset/Charset/NIOCharsetAvailability.java
	to work with module system
In-Reply-To: <54EF99AE.6020400@oracle.com>
References: <54EE8928.7050702@oracle.com> <54EF8A8B.3070005@oracle.com>
	<54EF8EC6.5070306@oracle.com> <54EF94F5.2030204@oracle.com>
	<54EF99AE.6020400@oracle.com>
Message-ID: <54EF9F4C.8090900@oracle.com>

On 26/02/2015 22:09, Xueming Shen wrote:
>
> thanks! webrev has been updated accordingly.
>
> http://cr.openjdk.java.net/~sherman/8073924/webrev
We could probably improve it further but what you have is good and not 
worth spending more time on it.

-Alan


From lev.priima at oracle.com  Thu Feb 26 22:35:35 2015
From: lev.priima at oracle.com (Lev Priima)
Date: Fri, 27 Feb 2015 01:35:35 +0300
Subject: RFR 8073354: TimSortStackSize2.java: test cleanup: make test
	run with single argument
In-Reply-To: <54EF99E6.4030003@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>
Message-ID: <54EF9FB7.7030400@oracle.com>

Thanks a lot, David!

Lev

On 02/27/2015 01:10 AM, David Holmes wrote:
> Okay I will push this for you Lev.
>
> Thanks,
> David
>
> On 27/02/2015 6:53 AM, Lev Priima wrote:
>> this cleanup is also required to fix this:
>> https://bugs.openjdk.java.net/browse/JDK-8073959
>>
>> Lev
>>
>> On 02/26/2015 02:01 PM, Lev Priima wrote:
>>> Thanks David,
>>> Are OK with pushing this
>>> http://cr.openjdk.java.net/~lpriima/8073354/webrev.01/ cleanup ?
>>>
>>> Lev
>>>
>>> On 02/26/2015 10:20 AM, David Holmes wrote:
>>>> On 24/02/2015 8:39 PM, Lev Priima wrote:
>>>>> I've updated summary and description.
>>>>
>>>> Okay - thanks.
>>>>
>>>> David
>>>>
>>>>> Lev
>>>>>
>>>>> On 02/23/2015 04:55 AM, David Holmes wrote:
>>>>>> On 20/02/2015 7:57 PM, Lev Priima wrote:
>>>>>>> Functional is pretty same, but:
>>>>>>>   - make it run with a single argument '67108864' by moving
>>>>>>> @summary tag
>>>>>>> strait down to line after the @run tag
>>>>>>>   - '-Xmx385' ->'-Xms385' in run command. MaxHeapSize will adjust a
>>>>>>> accordingly.
>>>>>>>   - spaces and code style.
>>>>>>>
>>>>>>> Of course this issue may be closed as dup of JDK-8073354 and test
>>>>>>> will
>>>>>>> pass after applying JDK-8073354. But I just want to use this RFE
>>>>>>> ID to
>>>>>>> make test run with a single argument ( as you noticed previously ).
>>>>>>
>>>>>> So this is all just cleanup - which is fine in itself but seems to
>>>>>> have no bearing on the issue reported/described in the bug 
>>>>>> report. If
>>>>>> you want to use this bug ID then I think you need to change the bug
>>>>>> report substantially else it will just be confusing.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>
>>>>>>> Lev
>>>>>>>
>>>>>>> On 02/20/2015 05:26 AM, David Holmes wrote:
>>>>>>>> On 19/02/2015 11:23 PM, Lev Priima wrote:
>>>>>>>>> After Jespers comments I removed catch of OOME and added minimum
>>>>>>>>> heap
>>>>>>>>> size required for test(-Xms385) to overcome default ergonomics 
>>>>>>>>> for
>>>>>>>>> client.
>>>>>>>>> Please review:
>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8073354/webrev.01/
>>>>>>>>
>>>>>>>> Didn't see this before sending my previous reply.
>>>>>>>>
>>>>>>>> I'm confused now. What functional change is now being made here ??
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Lev
>>>>>>>>>
>>>>>>>>> On 02/19/2015 03:00 PM, Lev Priima wrote:
>>>>>>>>>> There is also a problem, if the memory on host is highly
>>>>>>>>>> fragmented,
>>>>>>>>>> then we can't allocate continuous amount of heap for creating 
>>>>>>>>>> such
>>>>>>>>>> big
>>>>>>>>>> array. I've added catch for OOME and treat this case as
>>>>>>>>>> skip-pass to
>>>>>>>>>> make test more robust. Also I've removed explicit -Xmx385 from
>>>>>>>>>> @run
>>>>>>>>>> tag and made it start with a single argument.
>>>>>>>>>>
>>>>>>>>>> Please review and push:
>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8073354/webrev.00/
>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8073354
>>>>>>>>>>
>>>>>>>>>> Lev
>>>>>>>>>>
>>>>>>>>>> On 02/17/2015 09:55 AM, David Holmes wrote:
>>>>>>>>>>> On 17/02/2015 3:43 PM, Lev Priima wrote:
>>>>>>>>>>>> Thanks David!
>>>>>>>>>>>> Is this expected behavior of this annotation ?
>>>>>>>>>>>
>>>>>>>>>>> Yes that is the way jtreg defines tags:
>>>>>>>>>>>
>>>>>>>>>>> http://openjdk.java.net/jtreg/tag-spec.html
>>>>>>>>>>>
>>>>>>>>>>> "The argument tokens of a tag extend from the first token
>>>>>>>>>>> after the
>>>>>>>>>>> tag token to the end of the comment, the end of the file, or 
>>>>>>>>>>> the
>>>>>>>>>>> next
>>>>>>>>>>> tag token, whichever comes first."
>>>>>>>>>>>
>>>>>>>>>>> So everything between @run and @summary are taken to be the 
>>>>>>>>>>> @run
>>>>>>>>>>> commands. And there's no @comment tag unfortunately.
>>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>>> Lev
>>>>>>>>>>>>
>>>>>>>>>>>> On 02/17/2015 03:20 AM, David Holmes wrote:
>>>>>>>>>>>>> On 16/02/2015 9:20 PM, David Holmes wrote:
>>>>>>>>>>>>>> On 16/02/2015 6:59 PM, Lev Priima wrote:
>>>>>>>>>>>>>>> Thanks, David,
>>>>>>>>>>>>>>> Could you please push it ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I will if Roger doesn't get to it first. It'll be 11 hours
>>>>>>>>>>>>>> before
>>>>>>>>>>>>>> I can
>>>>>>>>>>>>>> push it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This has been pushed but note there is a minor issue with the
>>>>>>>>>>>>> test.
>>>>>>>>>>>>> The jtreg tag specification doesn't terminate tags on 
>>>>>>>>>>>>> newlines,
>>>>>>>>>>>>> they
>>>>>>>>>>>>> continue until the next tag is encountered or the end of the
>>>>>>>>>>>>> comment.
>>>>>>>>>>>>> Consequently this:
>>>>>>>>>>>>>
>>>>>>>>>>>>>  * @run main/othervm -Xmx385m TimSortStackSize2 67108864
>>>>>>>>>>>>>  * not for regular execution on all platforms:
>>>>>>>>>>>>>  * run main/othervm -Xmx8g TimSortStackSize2 1073741824
>>>>>>>>>>>>>  * run main/othervm -Xmx16g TimSortStackSize2 2147483644
>>>>>>>>>>>>>
>>>>>>>>>>>>> is processed as:
>>>>>>>>>>>>>
>>>>>>>>>>>>> @run main/othervm -Xmx385m TimSortStackSize2 67108864 not for
>>>>>>>>>>>>> regular
>>>>>>>>>>>>> execution on all platforms: run main/othervm -Xmx8g
>>>>>>>>>>>>> TimSortStackSize2
>>>>>>>>>>>>> 1073741824 run main/othervm -Xmx16g TimSortStackSize2
>>>>>>>>>>>>> 2147483644
>>>>>>>>>>>>>
>>>>>>>>>>>>> and so TimSortStackSize2 is invoked with 18 arguments.
>>>>>>>>>>>>>
>>>>>>>>>>>>> David
>>>>>>>>>>>>> -----
>>>>>>>>>>>>>
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Lev
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 02/16/2015 08:55 AM, David Holmes wrote:
>>>>>>>>>>>>>>>> On 14/02/2015 12:03 AM, Lev Priima wrote:
>>>>>>>>>>>>>>>>> Please review and push:
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/
>>>>>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073124
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I hadn't realized 8072909 had been pushed without final
>>>>>>>>>>>>>>>> reviewer
>>>>>>>>>>>>>>>> comments being addressed. :(
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> These changes seem okay. I hope they get promoted at the
>>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>> time as
>>>>>>>>>>>>>>>> the original changeset so we don't get test failures.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Lev
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 02/13/2015 05:20 AM, David Holmes wrote:
>>>>>>>>>>>>>>>>>> Hi Lev,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 13/02/2015 2:56 AM, Lev Priima wrote:
>>>>>>>>>>>>>>>>>>> Christos,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Test may fail on shorter arrays(page 8 of paper). For
>>>>>>>>>>>>>>>>>>> instance, on
>>>>>>>>>>>>>>>>>>> worst
>>>>>>>>>>>>>>>>>>> case, generated by test, it starts to fail on length
>>>>>>>>>>>>>>>>>>> 67108864.
>>>>>>>>>>>>>>>>>>> After increasing stack size of runs to merge,
>>>>>>>>>>>>>>>>>>> Arrays.sort(T[])
>>>>>>>>>>>>>>>>>>> works
>>>>>>>>>>>>>>>>>>> also on maximum possible array for HotSpot JVM.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'd also like to see this documented somewhere in the
>>>>>>>>>>>>>>>>>> code.
>>>>>>>>>>>>>>>>>> Presently
>>>>>>>>>>>>>>>>>> there is a reference to listsort.txt but then you have
>>>>>>>>>>>>>>>>>> to go
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> find
>>>>>>>>>>>>>>>>>> it on the web. :( At a minimum could we please add:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>  175          * computation below must be changed if
>>>>>>>>>>>>>>>>>> MIN_MERGE is
>>>>>>>>>>>>>>>>>> decreased.  See
>>>>>>>>>>>>>>>>>>  176          * the MIN_MERGE declaration above for more
>>>>>>>>>>>>>>>>>> information.
>>>>>>>>>>>>>>>>>> +             * The maximum value of 49 allows for an
>>>>>>>>>>>>>>>>>> array
>>>>>>>>>>>>>>>>>> up to
>>>>>>>>>>>>>>>>>> length
>>>>>>>>>>>>>>>>>> +             * Integer.MAX_VALUE-4.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Roger, David,
>>>>>>>>>>>>>>>>>>> I've updated the test (
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/test/java/util/Arrays/TimSortStackSize2.java.html 
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ) to make it more suitable for regular execution:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>    27  * @run main/othervm TimSortStackSize2 67108864
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This will still fail on small memory devices:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> :~> java TimSortStackSize2 67108864
>>>>>>>>>>>>>>>>>> Exception in thread "main" java.lang.OutOfMemoryError:
>>>>>>>>>>>>>>>>>> Java
>>>>>>>>>>>>>>>>>> heap
>>>>>>>>>>>>>>>>>> space
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> as the default heap ergonomics may not be large 
>>>>>>>>>>>>>>>>>> enough. I
>>>>>>>>>>>>>>>>>> had to
>>>>>>>>>>>>>>>>>> add a
>>>>>>>>>>>>>>>>>> minimum heap of -Xmx385M to get it to run.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>    28  * not for regular execution on all platforms:
>>>>>>>>>>>>>>>>>>>    29  * run main/othervm -Xmx8g TimSortStackSize2
>>>>>>>>>>>>>>>>>>> 1073741824
>>>>>>>>>>>>>>>>>>>    30  * run main/othervm -Xmx32g TimSortStackSize2
>>>>>>>>>>>>>>>>>>> 2147483644
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Could you please push this:
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~lpriima/8072909/webrev.01/
>>>>>>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Lev
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 02/12/2015 12:54 PM, christos at zoulas.com wrote:
>>>>>>>>>>>>>>>>>>>> On Feb 12, 9:57pm,david.holmes at oracle.com (David 
>>>>>>>>>>>>>>>>>>>> Holmes)
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> -- Subject: Re: 8072909: TimSort fails with
>>>>>>>>>>>>>>>>>>>> ArrayIndexOutOfBoundsException on
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> | Ok - thanks Lev!
>>>>>>>>>>>>>>>>>>>> |
>>>>>>>>>>>>>>>>>>>> | David
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> For posterity can someone document this, and also the
>>>>>>>>>>>>>>>>>>>> value for
>>>>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>>>> Integer.MAX_VALUE-4 fails?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> christos
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>



From scolebourne at joda.org  Thu Feb 26 22:47:53 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 26 Feb 2015 22:47:53 +0000
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EF7EB9.1040305@gmail.com>
References: <54EA3A41.9000309@gmail.com>
	<CACzrW9AAzCce5D9k20GZz8XHnZ3QpRD5z_+Pv3HcquaNzK2u4Q@mail.gmail.com>
	<54EF7EB9.1040305@gmail.com>
Message-ID: <CACzrW9Dx+UnkvC2_pc-k9jbkmuynRnnSc=_2fV-asioyYjHheA@mail.gmail.com>

Personally, I found the SharedSecrets version easier to follow. I also
suspect that the toZoneId0() method would be invoked most of the time
with this variant, resulting in no beneficial inlining effect.

The ZoneOffsetTransition patch looks like a no-brainer to me.

Stephen




On 26 February 2015 at 20:14, Peter Levart <peter.levart at gmail.com> wrote:
> Hi,
>
> Using routines for converting DOS time to Java time and back
> (java.util.zip.ZipUtils.[dosToJavaTime,javaToDosTime]) as a base for
> comparing deprecated java.util.Date API with new java.time API, here's a JMH
> test with 3 distinct implementations of those routines using java.util.Date,
> java.time.LocalDateTime and java.util.ZonedDateTime respectively:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/ZipUtilsTest.java
>
> Running the test in unpatched JDK9 reveals these results:
>
> Benchmark                               Mode   Samples        Score  Score
> error    Units
> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt        15       95.644
> 4.241    ns/op
> j.t.ZipUtilsTest.dosToJavaTime_LDT      avgt        15      118.155
> 2.980    ns/op
> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt        15      131.456
> 3.586    ns/op
> j.t.ZipUtilsTest.javaToDosTime_Date     avgt        15       74.692
> 1.709    ns/op
> j.t.ZipUtilsTest.javaToDosTime_LDT      avgt        15      134.116
> 4.396    ns/op
> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt        15      141.987
> 8.697    ns/op
>
> Using LocalDateTime instead of ZonedDateTime is a little faster, but does
> not make it as fast as using java.util.Date.
>
> With a patch for caching of ZoneId on default TimeZone, which speeds up
> repeated calls to ZoneId.systemDefault(), the results are as follows:
>
> Benchmark                               Mode   Samples        Score  Score
> error    Units
> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt        15       95.590
> 2.354    ns/op
> j.t.ZipUtilsTest.dosToJavaTime_LDT      avgt        15       79.682
> 3.572    ns/op
> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt        15       86.801
> 2.081    ns/op
> j.t.ZipUtilsTest.javaToDosTime_Date     avgt        15       75.096
> 1.178    ns/op
> j.t.ZipUtilsTest.javaToDosTime_LDT      avgt        15       91.919
> 2.191    ns/op
> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt        15       92.037
> 2.054    ns/op
>
> dosToJavaTime routine using LocalDateTime outperforms java.util.Date based.
> But javaToDosTime still lags behind. Profiling shows another point that can
> be optimized. In ZoneRules.getOffset(Instant) there is a loop over
> ZoneOffsetTransition[] array that searches for 1st transition that has its
> toEpochSecond value less than the Instant's epochSecond. This calls
> ZoneOffsetTransition.toEpochSecond repeatedly, converting
> ZoneOffsetTransition.transition which is a LocalDateTime to epochSecond.
> This repeated conversion is unnecessary, as ZoneOffsetTransition[] array is
> part of ZoneRules which is cached. Optimizing the ZoneOffsetTransition
> implementation (keeping both LocalDateTime variant and eposhSecond variant
> of transition time as the object's state) speeds up this conversion which
> makes the above test produce these results when combined with
> ZoneId.systemDefault() optimization:
>
> Benchmark                               Mode   Samples        Score  Score
> error    Units
> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt        15       92.291
> 2.903    ns/op
> j.t.ZipUtilsTest.dosToJavaTime_LDT      avgt        15       79.765
> 3.106    ns/op
> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt        15       87.282
> 2.967    ns/op
> j.t.ZipUtilsTest.javaToDosTime_Date     avgt        15       76.235
> 2.651    ns/op
> j.t.ZipUtilsTest.javaToDosTime_LDT      avgt        15       73.115
> 2.567    ns/op
> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt        15       75.701
> 2.226    ns/op
>
> For these tests I used another approach for speeding up
> ZoneId.systemDefault() which doesn't use ShareSecrets. It changes only
> TimeZone class so that base TimeZone instance is referenced from the clone
> returned by TimeZone.getDefault(). Although TimeZone object is unnecessarily
> cloned, it does not represent much overhead (probably the allocation is
> optimized away by JIT as the clone never escapes from
> ZoneId.systemDefault()):
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.02/
>
> The patch to ZoneOffsetTransition class is straightforward:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.01/
>
>
> So is this a worthy improvement? What do you think about the new approach
> for optimizing ZoneId.systemDefault() compared to SharedSecrets based:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.01/
>
> (this one still has a NPE bug in timeZone.setDefault())
>
>
>
> Regards, Peter
>
>
>
> On 02/23/2015 12:50 PM, Stephen Colebourne wrote:
>
> Having recently spent time on performance myself, I know that there
> are a number of things in the java.time package that need some work.
>
> Improving ZoneId.systemDefault() is definitely an improvement I
> welcome. The change is along the lines of that I would have made,
> involving a "secret" location to allow data to be exchanged (this code
> needs to avoid the clone). The idea of adding a public method
> TimeZone.getDefaultZoneId() is also one I'd be interested in if it
> works.
>
> On the patch, in TimeZone::toZoneId() I would use two methods:
>
> public ZoneId toZoneId() {
>  ZoneId zId = zoneId;
>  if (zId == null) {
>   zoneId = zId = toZoneId0();
>  }
> return zId;
> }
>
> private ZoneId toZoneId0() {
>  String id = getID();
>  if (ZoneInfoFile.useOldMapping() && id.length() == 3) {
>   if ("EST".equals(id)) {
>    zId = ZoneId.of("America/New_York");
>   } else if ("MST".equals(id)) {
>    zId = ZoneId.of("America/Denver");
>   } else if ("HST".equals(id)) {
>    zId = ZoneId.of("America/Honolulu");
>   } else {
>    zId = ZoneId.of(id, ZoneId.SHORT_IDS);
>   }
>  }
> }
>
> This should aid hotspot inlining (removing uncommon paths from main flow).
>
> Does the code properly handle the static setDefault() method? I
> suspect so, but will be worth a test.
>
> If there's no undesirable side effect then caching zoneId
> inside TimeZone looks reasonable to me - however I'm not an expert
> of the field, and I got to learn that time/date can be more complex
> than what I first thought ;-)
>
> One thing I noticed is that there are two kinds of ZoneRulesProvider(s):
> those that are static and allow their rules to be cached and the dynamic
> ones, that can provide dynamic view on rules and therefore don't allow
> caching of rules. But this aspect is encapsulated in ZoneRegion class (an
> implementation of ZoneId). So I think an instance to ZoneRegion (or any
> ZoneId) can be cached for indefinite time as long as it's id is the one that
> we are looking for.
>
> Yes, ZoneId can be safely cached as an immutable object (probably
> never going to be a value type BTW). All current ZoneRegion instances
> have static, not dynamic, rules.
>
>
> As a final possibility, it might be possible to add a new subclass of
> TimeZone that works directly off ZoneId. (sourcing the offset rules
> from ZoneId instead of direct from the underlying data). However, the
> mutable API of TimeZone probably makes it quite hard to get right.
>
> On the specific ZIP code, using LocalDateTime rather than
> ZonedDateTime may be faster as there are less objects to create.Claes'
> code looks OK at first glance.
>
> To get more performance, effort needs to be spent on LocalDate.of()
> and LocalTime.of(). Both use very clean code, but it calls out to a
> general routine that has to lookup boundary numbers. Because they are
> general, they have quite deep call stacks, and inlining sometimes
> fails to reach them due to inlining depth limits. For those two
> critical pieces of code, the limits need to be inlined, something like
> this:
>
> public static LocalDate of(int year, int month, int dayOfMonth) {
>  if (year < Year.MIN_VALUE || year > Year.MAX_VALUE) {
>   throw new DateTimeException(genInvalidFieldMessage(YEAR, year))
>  }
>  if (month < 1 || month > 12) {
>   throw new DateTimeException(genInvalidFieldMessage(MONTH_OF_YEAR, month))
>  }
>  if (dayOfMonth < 1 || dayOfMonth > 31) {
>   throw new DateTimeException(genInvalidFieldMessage(DAY_OF_MONTH,
> dayOfMonth))
>  }
>  return create(year, month, dayOfMonth);
> }
> private String genInvalidFieldMessage(TemporalField field, long value) {
>  return "Invalid value for " + field + " (valid values " + this + "): " +
> value;
> }
>
> I've not tested if this is faster, but I'd be surprised if it wasn't.
>
> Stephen
>
>
>
> On 22 February 2015 at 20:21, Peter Levart <peter.levart at gmail.com> wrote:
>
> Hi,
>
> I noticed internal JDK class java.util.zip.ZipUtils uses deprecated
> java.util.Date API for implementing two methods for converting DOS to Java
> time and back. I thought I'd try translating them to use new java.time API.
> Translation was straightforward, but I noticed that new implementations are
> not on par with speed to old java.util.Date versions. Here's a JMH benchmark
> implementing those two conversion methods with java.util.Date and
> java.time.ZonedDateTime APIs:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/ZipUtilsTest.java
>
> The results show the following:
>
> Benchmark                               Mode   Samples Score  Score error
> Units
> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt         5 101.890       17.570
> ns/op
> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt         5 137.587       13.533
> ns/op
> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       67.114       10.382
> ns/op
> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt         5 143.739       15.243
> ns/op
>
>
> Quick sampling with jvisualvm shows that a substantial time is spent
> repeatedly obtaining ZoneId.systemDefault() instance. I checked the
> implementation and came up with the following optimization:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.01/
>
> TimeZone is a mutable object and has to be defensively cloned when
> TimeZone.getDefault() is invoked. So there's no point in caching a ZoneId
> instance inside TimeZone instance if we cache it on a clone that is thrown
> away each time ZoneId.systemDefault() is invoked. I use SharedSecrets to
> access the uncloned TimeZone.defaultTimeZone instance where caching of
> ZoneId pays of.
>
> I think that it was never meant to change TimeZone's ID (TimeZone.setID())
> after such instance was put into operation (for example installed as default
> time zone with TimeZone.setDefault()). Such use is unintended and buggy. So
> I also changed the implementation of TimeZone.setDefault() to save a
> defensive copy of TimeZone object as default time zone instead of a
> reference to it.
>
> With this patch, the DOS/Java time conversion benchmark shows an
> improvement:
>
> Benchmark                               Mode   Samples Score  Score error
> Units
> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt 5       97.986       18.379
> ns/op
> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt 5       85.010       10.863
> ns/op
> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       71.073       25.408
> ns/op
> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt 5       95.298       17.620
> ns/op
>
>
> Is this patch correct or did I miss something from the internals of
> java.time API that does not permit such caching?
>
>
> Regards, Peter
>
>


From christos at zoulas.com  Thu Feb 26 22:59:48 2015
From: christos at zoulas.com (Christos Zoulas)
Date: Thu, 26 Feb 2015 17:59:48 -0500
Subject: stop using mmap for zip I/O
In-Reply-To: <54EF9EFA.7030201@oracle.com> from Xueming Shen (Feb 26,  2:32pm)
Message-ID: <20150226225948.3E88D17FDAA@rebar.astron.com>

On Feb 26,  2:32pm, xueming.shen at oracle.com (Xueming Shen) wrote:
-- Subject: Re: stop using mmap for zip I/O

| That's true, unfortunately, the mmap does trigger crash here and there....
| 
| There is a property you can define to disable it in later releases
| -Dsun.zip.disableMemoryMapping=true
| 
| There is discussion that maybe we should simply disable the mmap by default ...
| 
| And, there is further plan to simply move the general zip file handling up to
| pure java, without any native code, as the webrev showed below. I'm still
| hoping we can do it in jdk9 later, when everyone is not that busy and can
| help codereview the change. (the webrev might be a little aged)

Thanks a lot! The plan sounds great, as the pure java implementation will
prevent other core-dumps from corrupt zip files...

Best,

christos


From peter.levart at gmail.com  Thu Feb 26 23:10:09 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 27 Feb 2015 00:10:09 +0100
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <CACzrW9Dx+UnkvC2_pc-k9jbkmuynRnnSc=_2fV-asioyYjHheA@mail.gmail.com>
References: <54EA3A41.9000309@gmail.com>	<CACzrW9AAzCce5D9k20GZz8XHnZ3QpRD5z_+Pv3HcquaNzK2u4Q@mail.gmail.com>	<54EF7EB9.1040305@gmail.com>
	<CACzrW9Dx+UnkvC2_pc-k9jbkmuynRnnSc=_2fV-asioyYjHheA@mail.gmail.com>
Message-ID: <54EFA7D1.6000907@gmail.com>


On 02/26/2015 11:47 PM, Stephen Colebourne wrote:
> Personally, I found the SharedSecrets version easier to follow. I also
> suspect that the toZoneId0() method would be invoked most of the time
> with this variant, resulting in no beneficial inlining effect.

Not true. Once the toZoneId0() invokes baseZone.toZoneId() (on the base 
instance which is attached to defaultTimeZone static field) the ZoneId 
object will be set on both instances (base and clone). Next call to 
TimeZone.getDefault() will create another clone of default TimeZone, but 
this time, the cloned zoneId field will already point to cached ZoneId. 
That and EA-based elimination of clone's allocation makes this variant 
as performant as SharedSecrets based.

But I agree that it is not simple to follow all the possible code paths. 
The benefit is that java.time is not dependent on ShareSecrets.

> The ZoneOffsetTransition patch looks like a no-brainer to me.

Good. I'll create two RFE issues in JIRA to track this.

Regards, Peter

> Stephen
>
>
>
>
> On 26 February 2015 at 20:14, Peter Levart <peter.levart at gmail.com> wrote:
>> Hi,
>>
>> Using routines for converting DOS time to Java time and back
>> (java.util.zip.ZipUtils.[dosToJavaTime,javaToDosTime]) as a base for
>> comparing deprecated java.util.Date API with new java.time API, here's a JMH
>> test with 3 distinct implementations of those routines using java.util.Date,
>> java.time.LocalDateTime and java.util.ZonedDateTime respectively:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/ZipUtilsTest.java
>>
>> Running the test in unpatched JDK9 reveals these results:
>>
>> Benchmark                               Mode   Samples        Score  Score
>> error    Units
>> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt        15       95.644
>> 4.241    ns/op
>> j.t.ZipUtilsTest.dosToJavaTime_LDT      avgt        15      118.155
>> 2.980    ns/op
>> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt        15      131.456
>> 3.586    ns/op
>> j.t.ZipUtilsTest.javaToDosTime_Date     avgt        15       74.692
>> 1.709    ns/op
>> j.t.ZipUtilsTest.javaToDosTime_LDT      avgt        15      134.116
>> 4.396    ns/op
>> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt        15      141.987
>> 8.697    ns/op
>>
>> Using LocalDateTime instead of ZonedDateTime is a little faster, but does
>> not make it as fast as using java.util.Date.
>>
>> With a patch for caching of ZoneId on default TimeZone, which speeds up
>> repeated calls to ZoneId.systemDefault(), the results are as follows:
>>
>> Benchmark                               Mode   Samples        Score  Score
>> error    Units
>> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt        15       95.590
>> 2.354    ns/op
>> j.t.ZipUtilsTest.dosToJavaTime_LDT      avgt        15       79.682
>> 3.572    ns/op
>> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt        15       86.801
>> 2.081    ns/op
>> j.t.ZipUtilsTest.javaToDosTime_Date     avgt        15       75.096
>> 1.178    ns/op
>> j.t.ZipUtilsTest.javaToDosTime_LDT      avgt        15       91.919
>> 2.191    ns/op
>> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt        15       92.037
>> 2.054    ns/op
>>
>> dosToJavaTime routine using LocalDateTime outperforms java.util.Date based.
>> But javaToDosTime still lags behind. Profiling shows another point that can
>> be optimized. In ZoneRules.getOffset(Instant) there is a loop over
>> ZoneOffsetTransition[] array that searches for 1st transition that has its
>> toEpochSecond value less than the Instant's epochSecond. This calls
>> ZoneOffsetTransition.toEpochSecond repeatedly, converting
>> ZoneOffsetTransition.transition which is a LocalDateTime to epochSecond.
>> This repeated conversion is unnecessary, as ZoneOffsetTransition[] array is
>> part of ZoneRules which is cached. Optimizing the ZoneOffsetTransition
>> implementation (keeping both LocalDateTime variant and eposhSecond variant
>> of transition time as the object's state) speeds up this conversion which
>> makes the above test produce these results when combined with
>> ZoneId.systemDefault() optimization:
>>
>> Benchmark                               Mode   Samples        Score  Score
>> error    Units
>> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt        15       92.291
>> 2.903    ns/op
>> j.t.ZipUtilsTest.dosToJavaTime_LDT      avgt        15       79.765
>> 3.106    ns/op
>> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt        15       87.282
>> 2.967    ns/op
>> j.t.ZipUtilsTest.javaToDosTime_Date     avgt        15       76.235
>> 2.651    ns/op
>> j.t.ZipUtilsTest.javaToDosTime_LDT      avgt        15       73.115
>> 2.567    ns/op
>> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt        15       75.701
>> 2.226    ns/op
>>
>> For these tests I used another approach for speeding up
>> ZoneId.systemDefault() which doesn't use ShareSecrets. It changes only
>> TimeZone class so that base TimeZone instance is referenced from the clone
>> returned by TimeZone.getDefault(). Although TimeZone object is unnecessarily
>> cloned, it does not represent much overhead (probably the allocation is
>> optimized away by JIT as the clone never escapes from
>> ZoneId.systemDefault()):
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.02/
>>
>> The patch to ZoneOffsetTransition class is straightforward:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.01/
>>
>>
>> So is this a worthy improvement? What do you think about the new approach
>> for optimizing ZoneId.systemDefault() compared to SharedSecrets based:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.01/
>>
>> (this one still has a NPE bug in timeZone.setDefault())
>>
>>
>>
>> Regards, Peter
>>
>>
>>
>> On 02/23/2015 12:50 PM, Stephen Colebourne wrote:
>>
>> Having recently spent time on performance myself, I know that there
>> are a number of things in the java.time package that need some work.
>>
>> Improving ZoneId.systemDefault() is definitely an improvement I
>> welcome. The change is along the lines of that I would have made,
>> involving a "secret" location to allow data to be exchanged (this code
>> needs to avoid the clone). The idea of adding a public method
>> TimeZone.getDefaultZoneId() is also one I'd be interested in if it
>> works.
>>
>> On the patch, in TimeZone::toZoneId() I would use two methods:
>>
>> public ZoneId toZoneId() {
>>   ZoneId zId = zoneId;
>>   if (zId == null) {
>>    zoneId = zId = toZoneId0();
>>   }
>> return zId;
>> }
>>
>> private ZoneId toZoneId0() {
>>   String id = getID();
>>   if (ZoneInfoFile.useOldMapping() && id.length() == 3) {
>>    if ("EST".equals(id)) {
>>     zId = ZoneId.of("America/New_York");
>>    } else if ("MST".equals(id)) {
>>     zId = ZoneId.of("America/Denver");
>>    } else if ("HST".equals(id)) {
>>     zId = ZoneId.of("America/Honolulu");
>>    } else {
>>     zId = ZoneId.of(id, ZoneId.SHORT_IDS);
>>    }
>>   }
>> }
>>
>> This should aid hotspot inlining (removing uncommon paths from main flow).
>>
>> Does the code properly handle the static setDefault() method? I
>> suspect so, but will be worth a test.
>>
>> If there's no undesirable side effect then caching zoneId
>> inside TimeZone looks reasonable to me - however I'm not an expert
>> of the field, and I got to learn that time/date can be more complex
>> than what I first thought ;-)
>>
>> One thing I noticed is that there are two kinds of ZoneRulesProvider(s):
>> those that are static and allow their rules to be cached and the dynamic
>> ones, that can provide dynamic view on rules and therefore don't allow
>> caching of rules. But this aspect is encapsulated in ZoneRegion class (an
>> implementation of ZoneId). So I think an instance to ZoneRegion (or any
>> ZoneId) can be cached for indefinite time as long as it's id is the one that
>> we are looking for.
>>
>> Yes, ZoneId can be safely cached as an immutable object (probably
>> never going to be a value type BTW). All current ZoneRegion instances
>> have static, not dynamic, rules.
>>
>>
>> As a final possibility, it might be possible to add a new subclass of
>> TimeZone that works directly off ZoneId. (sourcing the offset rules
>> from ZoneId instead of direct from the underlying data). However, the
>> mutable API of TimeZone probably makes it quite hard to get right.
>>
>> On the specific ZIP code, using LocalDateTime rather than
>> ZonedDateTime may be faster as there are less objects to create.Claes'
>> code looks OK at first glance.
>>
>> To get more performance, effort needs to be spent on LocalDate.of()
>> and LocalTime.of(). Both use very clean code, but it calls out to a
>> general routine that has to lookup boundary numbers. Because they are
>> general, they have quite deep call stacks, and inlining sometimes
>> fails to reach them due to inlining depth limits. For those two
>> critical pieces of code, the limits need to be inlined, something like
>> this:
>>
>> public static LocalDate of(int year, int month, int dayOfMonth) {
>>   if (year < Year.MIN_VALUE || year > Year.MAX_VALUE) {
>>    throw new DateTimeException(genInvalidFieldMessage(YEAR, year))
>>   }
>>   if (month < 1 || month > 12) {
>>    throw new DateTimeException(genInvalidFieldMessage(MONTH_OF_YEAR, month))
>>   }
>>   if (dayOfMonth < 1 || dayOfMonth > 31) {
>>    throw new DateTimeException(genInvalidFieldMessage(DAY_OF_MONTH,
>> dayOfMonth))
>>   }
>>   return create(year, month, dayOfMonth);
>> }
>> private String genInvalidFieldMessage(TemporalField field, long value) {
>>   return "Invalid value for " + field + " (valid values " + this + "): " +
>> value;
>> }
>>
>> I've not tested if this is faster, but I'd be surprised if it wasn't.
>>
>> Stephen
>>
>>
>>
>> On 22 February 2015 at 20:21, Peter Levart <peter.levart at gmail.com> wrote:
>>
>> Hi,
>>
>> I noticed internal JDK class java.util.zip.ZipUtils uses deprecated
>> java.util.Date API for implementing two methods for converting DOS to Java
>> time and back. I thought I'd try translating them to use new java.time API.
>> Translation was straightforward, but I noticed that new implementations are
>> not on par with speed to old java.util.Date versions. Here's a JMH benchmark
>> implementing those two conversion methods with java.util.Date and
>> java.time.ZonedDateTime APIs:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/ZipUtilsTest.java
>>
>> The results show the following:
>>
>> Benchmark                               Mode   Samples Score  Score error
>> Units
>> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt         5 101.890       17.570
>> ns/op
>> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt         5 137.587       13.533
>> ns/op
>> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       67.114       10.382
>> ns/op
>> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt         5 143.739       15.243
>> ns/op
>>
>>
>> Quick sampling with jvisualvm shows that a substantial time is spent
>> repeatedly obtaining ZoneId.systemDefault() instance. I checked the
>> implementation and came up with the following optimization:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.01/
>>
>> TimeZone is a mutable object and has to be defensively cloned when
>> TimeZone.getDefault() is invoked. So there's no point in caching a ZoneId
>> instance inside TimeZone instance if we cache it on a clone that is thrown
>> away each time ZoneId.systemDefault() is invoked. I use SharedSecrets to
>> access the uncloned TimeZone.defaultTimeZone instance where caching of
>> ZoneId pays of.
>>
>> I think that it was never meant to change TimeZone's ID (TimeZone.setID())
>> after such instance was put into operation (for example installed as default
>> time zone with TimeZone.setDefault()). Such use is unintended and buggy. So
>> I also changed the implementation of TimeZone.setDefault() to save a
>> defensive copy of TimeZone object as default time zone instead of a
>> reference to it.
>>
>> With this patch, the DOS/Java time conversion benchmark shows an
>> improvement:
>>
>> Benchmark                               Mode   Samples Score  Score error
>> Units
>> j.t.ZipUtilsTest.dosToJavaTime_Date     avgt 5       97.986       18.379
>> ns/op
>> j.t.ZipUtilsTest.dosToJavaTime_ZDT      avgt 5       85.010       10.863
>> ns/op
>> j.t.ZipUtilsTest.javaToDosTime_Date     avgt 5       71.073       25.408
>> ns/op
>> j.t.ZipUtilsTest.javaToDosTime_ZDT      avgt 5       95.298       17.620
>> ns/op
>>
>>
>> Is this patch correct or did I miss something from the internals of
>> java.time API that does not permit such caching?
>>
>>
>> Regards, Peter
>>
>>



From peter.levart at gmail.com  Thu Feb 26 23:29:17 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 27 Feb 2015 00:29:17 +0100
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EFA7D1.6000907@gmail.com>
References: <54EA3A41.9000309@gmail.com>	<CACzrW9AAzCce5D9k20GZz8XHnZ3QpRD5z_+Pv3HcquaNzK2u4Q@mail.gmail.com>	<54EF7EB9.1040305@gmail.com>
	<CACzrW9Dx+UnkvC2_pc-k9jbkmuynRnnSc=_2fV-asioyYjHheA@mail.gmail.com>
	<54EFA7D1.6000907@gmail.com>
Message-ID: <54EFAC4D.4060800@gmail.com>


On 02/27/2015 12:10 AM, Peter Levart wrote:
> On 02/26/2015 11:47 PM, Stephen Colebourne wrote:
>> Personally, I found the SharedSecrets version easier to follow. I also
>> suspect that the toZoneId0() method would be invoked most of the time
>> with this variant, resulting in no beneficial inlining effect.
>
> Not true. Once the toZoneId0() invokes baseZone.toZoneId() (on the 
> base instance which is attached to defaultTimeZone static field) the 
> ZoneId object will be set on both instances (base and clone). Next 
> call to TimeZone.getDefault() will create another clone of default 
> TimeZone, but this time, the cloned zoneId field will already point to 
> cached ZoneId. That and EA-based elimination of clone's allocation 
> makes this variant as performant as SharedSecrets based.
>
> But I agree that it is not simple to follow all the possible code 
> paths. The benefit is that java.time is not dependent on ShareSecrets.

Here's another variant that doesn't use a back link to base TimeZone:

http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.03/

I think it's easier to follow than previous one.


Regards, Peter



From joe.darcy at oracle.com  Thu Feb 26 23:34:18 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 26 Feb 2015 15:34:18 -0800
Subject: RFR 9: 8044051 Test jdk/lambda/vm/InterfaceAccessFlagsTest.java
	gets IOException during compilation
In-Reply-To: <54EF8CC0.4010201@Oracle.com>
References: <54EF8CC0.4010201@Oracle.com>
Message-ID: <54EFAD7A.9070402@oracle.com>

Hi Roger,

Doesn't jtreg define a test-specific scratch directory? Is that not 
available to TestNG tests?

Cheers,

-Joe

On 2/26/2015 1:14 PM, Roger Riggs wrote:
> Please review this test fix to make the test more robust to 
> configuration and
> pollution of the temp directory.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-ioex-8044051/
>
> Issue:
>   https://bugs.openjdk.java.net/browse/JDK-8044051
>
> Thanks, Roger



From mandy.chung at oracle.com  Fri Feb 27 00:04:14 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 26 Feb 2015 16:04:14 -0800
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <54EF8FC0.9060501@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>
Message-ID: <54EFB47E.4050901@oracle.com>

On 2/26/15 1:27 PM, Peter Levart wrote:
>
> On 02/26/2015 05:34 PM, Mandy Chung wrote:
>>> The problem is with the default method 
>>> AnnotatedElement::getDeclaredAnnotationsByType. If someone has an 
>>> external implementation of AnnotatedElement (and one of the lessons 
>>> from adding these methods in 8 was that there are other 
>>> implementations) then if that external implementation haven?t added 
>>> getDeclaredAnnotationsByType they will call into our 
>>> AnnotationSupport. This is all fine if that external representation 
>>> of AnnotatedElement uses our representation of Annotations, with 
>>> Proxies and all. But I suspect that the conditions that would end up 
>>> taking the non-proxy code path in the patch, will already fail in 
>>> the check:
>>>
>>>               AnnotationType annoType = 
>>> AnnotationType.getInstance(containerClass);
>>>               if (annoType == null)
>>>                   throw invalidContainerException(container, null);
>>>
>>> So what is the best thing to do here if the annotation is not Proxy 
>>> based and is coming from an implementation of the AnnotatedElement 
>>> interface that we don?t control and that is missing the methods 
>>> added in 8?
>>
>> I did a quick search on my corpus and find only one reference to
>> sun.reflect.annotation.AnnotationType.  Looks like external 
>> implementation
>> doesn't get pass this. 
>
> Now I'm missing something. Why would a custom non-Proxy based 
> annotation not pass the above code?

I had assumed that AnnotationType.getInstance also expects the 
implementation of the annotation type is 
sun.reflect.annotation.AnnotationType.  I don't know enough about this 
area and that's just my observation. Hope Joel will say more details.
> I don't see anything in AnnotationType implementation that would be 
> dependent on annotation implementation to be a Proxy. AnnotationType 
> only deals with the annotation type, which is an interface, not with 
> implementation.
>
> The m.setAccessible(true) for the methods is needed to access methods 
> of non-public annotations, right? 

I think so.
> This call could be moved to AnnotationType constructor as there it 
> will be performed only once per Method object.
>
If the specification supports other implementation, it seems to me that 
calling setAccessible(true) should be wrapped with doPrivileged unless 
the specification states the "suppressAccessCheck" permission is 
required; otherwise, SecurityException will be thrown.  It'd be good to 
clarify what that code is intended for.

Mandy



From mandy.chung at oracle.com  Fri Feb 27 00:07:28 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 26 Feb 2015 16:07:28 -0800
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <54EF985F.8050707@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>
	<54EF985F.8050707@gmail.com>
Message-ID: <54EFB540.2050307@oracle.com>

On 2/26/15 2:04 PM, Peter Levart wrote:
> I verified this with the following code:
> :
>
> ... it works without problems and prints the expected:

Thanks for the test.  The question is what the spec says about 
SecurityException, or it should require the value() method be public or 
there is a reason to support a non-public value() method?

Mandy


From peter.levart at gmail.com  Fri Feb 27 00:59:19 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 27 Feb 2015 01:59:19 +0100
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <54EFB540.2050307@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>
	<54EF985F.8050707@gmail.com> <54EFB540.2050307@oracle.com>
Message-ID: <54EFC167.9080505@gmail.com>


On 02/27/2015 01:07 AM, Mandy Chung wrote:
> On 2/26/15 2:04 PM, Peter Levart wrote:
>> I verified this with the following code:
>> :
>>
>> ... it works without problems and prints the expected:
>
> Thanks for the test.  The question is what the spec says about 
> SecurityException, or it should require the value() method be public 
> or there is a reason to support a non-public value() method?
>
> Mandy

Well, currently, with pre-JDK8 APIs, one has access to annotation 
instances of types that are otherwise inaccessible. For example:

public class Test {
     public static void main(String[] args) throws Exception {
         // 
TestSibling.class.getDeclaredAnnotation(TestSibling.PrivateAnn.class);
         // >>> javac Error: The type TestSibling.PrivateAnn is not visible

         // but:

         Annotation privateAnn = 
TestSibling.class.getDeclaredAnnotations()[0];
         System.out.println(privateAnn);
         // >>> @TestSibling$PrivateAnn()
     }
}

@TestSibling.PrivateAnn()
class TestSibling {
     @Retention(RetentionPolicy.RUNTIME)
     private @interface PrivateAnn {
     }
}

So I don't think we should prevent access to repeatable annotation 
instances just because the container annotation type of the repeatable 
annotation is not public.

The call to setAccessible(true) should be wrapped by doPrivileged and 
should be performed in AnnotationType constructor and not sprinkled in 
other places that need to invoke the Method(s). This is by no means less 
secure as it doesn't matter what part of code makes the Method object 
setAccessible(true) if it is a shared Method object.

Regards, Peter



From peter.levart at gmail.com  Fri Feb 27 01:01:04 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 27 Feb 2015 02:01:04 +0100
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <54EFB540.2050307@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>
	<54EF985F.8050707@gmail.com> <54EFB540.2050307@oracle.com>
Message-ID: <54EFC1D0.1040902@gmail.com>


On 02/27/2015 01:07 AM, Mandy Chung wrote:
> Thanks for the test.  The question is what the spec says about 
> SecurityException, or it should require the value() method be public 
> or there is a reason to support a non-public value() method?

The value() method is always public (since it's an interface method), 
but the interface need not be public.

>
> Mandy



From joe.darcy at oracle.com  Fri Feb 27 01:28:25 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 26 Feb 2015 17:28:25 -0800
Subject: JDK 9 RFR of JDK-8073952: Spec of
	j.l.r.Method.toString/toGenericString need to be clarified
Message-ID: <54EFC839.6050609@oracle.com>

Hello,

Please review the small changes to address

     JDK-8073952: Spec of j.l.r.Method.toString/toGenericString need to 
be clarified
     http://cr.openjdk.java.net/~darcy/8073952.0/

Full patch below.

In essence, the patch adds references to the JLS sections which talk 
about interfaces and default methods.

Thanks,

-Joe

--- old/src/java.base/share/classes/java/lang/reflect/Constructor.java 
2015-02-26 17:14:49.955169685 -0800
+++ new/src/java.base/share/classes/java/lang/reflect/Constructor.java 
2015-02-26 17:14:49.799091677 -0800
@@ -296,7 +296,8 @@
       * constructor has default (package) access.
       *
       * @return a string describing this {@code Constructor}
-     * @jls 8.8.3. Constructor Modifiers
+     * @jls 8.8.3 Constructor Modifiers
+     * @jls 8.9.2 Enum Body Declarations
       */
      public String toString() {
          return sharedToString(Modifier.constructorModifiers(),
@@ -342,7 +343,8 @@
       * include type parameters
       *
       * @since 1.5
-     * @jls 8.8.3. Constructor Modifiers
+     * @jls 8.8.3 Constructor Modifiers
+     * @jls 8.9.2 Enum Body Declarations
       */
      @Override
      public String toGenericString() {
--- old/src/java.base/share/classes/java/lang/reflect/Method.java 
2015-02-26 17:14:50.403393705 -0800
+++ new/src/java.base/share/classes/java/lang/reflect/Method.java 
2015-02-26 17:14:50.227305697 -0800
@@ -356,6 +356,8 @@
       * @return a string describing this {@code Method}
       *
       * @jls 8.4.3 Method Modifiers
+     * @jls 9.4   Method Declarations
+     * @jls 9.6.1 Annotation Type Elements
       */
      public String toString() {
          return sharedToString(Modifier.methodModifiers(),
@@ -409,6 +411,8 @@
       * @since 1.5
       *
       * @jls 8.4.3 Method Modifiers
+     * @jls 9.4   Method Declarations
+     * @jls 9.6.1 Annotation Type Elements
       */
      @Override
      public String toGenericString() {



From lance.andersen at oracle.com  Fri Feb 27 01:40:09 2015
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Thu, 26 Feb 2015 20:40:09 -0500
Subject: JDK 9 RFR of JDK-8073952: Spec of
	j.l.r.Method.toString/toGenericString need to be clarified
In-Reply-To: <54EFC839.6050609@oracle.com>
References: <54EFC839.6050609@oracle.com>
Message-ID: <510B9AC7-D3AC-4BB6-99A0-FF5C12E156E4@oracle.com>

+1


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 Feb 26, 2015, at 8:28 PM, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> Please review the small changes to address
> 
>    JDK-8073952: Spec of j.l.r.Method.toString/toGenericString need to be clarified
>    http://cr.openjdk.java.net/~darcy/8073952.0/
> 
> Full patch below.
> 
> In essence, the patch adds references to the JLS sections which talk about interfaces and default methods.
> 
> Thanks,
> 
> -Joe
> 
> --- old/src/java.base/share/classes/java/lang/reflect/Constructor.java 2015-02-26 17:14:49.955169685 -0800
> +++ new/src/java.base/share/classes/java/lang/reflect/Constructor.java 2015-02-26 17:14:49.799091677 -0800
> @@ -296,7 +296,8 @@
>      * constructor has default (package) access.
>      *
>      * @return a string describing this {@code Constructor}
> -     * @jls 8.8.3. Constructor Modifiers
> +     * @jls 8.8.3 Constructor Modifiers
> +     * @jls 8.9.2 Enum Body Declarations
>      */
>     public String toString() {
>         return sharedToString(Modifier.constructorModifiers(),
> @@ -342,7 +343,8 @@
>      * include type parameters
>      *
>      * @since 1.5
> -     * @jls 8.8.3. Constructor Modifiers
> +     * @jls 8.8.3 Constructor Modifiers
> +     * @jls 8.9.2 Enum Body Declarations
>      */
>     @Override
>     public String toGenericString() {
> --- old/src/java.base/share/classes/java/lang/reflect/Method.java 2015-02-26 17:14:50.403393705 -0800
> +++ new/src/java.base/share/classes/java/lang/reflect/Method.java 2015-02-26 17:14:50.227305697 -0800
> @@ -356,6 +356,8 @@
>      * @return a string describing this {@code Method}
>      *
>      * @jls 8.4.3 Method Modifiers
> +     * @jls 9.4   Method Declarations
> +     * @jls 9.6.1 Annotation Type Elements
>      */
>     public String toString() {
>         return sharedToString(Modifier.methodModifiers(),
> @@ -409,6 +411,8 @@
>      * @since 1.5
>      *
>      * @jls 8.4.3 Method Modifiers
> +     * @jls 9.4   Method Declarations
> +     * @jls 9.6.1 Annotation Type Elements
>      */
>     @Override
>     public String toGenericString() {
> 


From mandy.chung at oracle.com  Fri Feb 27 01:57:49 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 26 Feb 2015 17:57:49 -0800
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <54EFC1D0.1040902@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>
	<54EF985F.8050707@gmail.com> <54EFB540.2050307@oracle.com>
	<54EFC1D0.1040902@gmail.com>
Message-ID: <54EFCF1D.5010605@oracle.com>


On 2/26/2015 5:01 PM, Peter Levart wrote:
>
> On 02/27/2015 01:07 AM, Mandy Chung wrote:
>> Thanks for the test.  The question is what the spec says about 
>> SecurityException, or it should require the value() method be public 
>> or there is a reason to support a non-public value() method?
>
> The value() method is always public (since it's an interface method), 
> but the interface need not be public.

Thanks for the clarification.

> So I don't think we should prevent access to repeatable annotation 
> instances just because the container annotation type of the repeatable 
> annotation is not public.
>
> The call to setAccessible(true) should be wrapped by doPrivileged and 
> should be performed in AnnotationType constructor and not sprinkled in 
> other places that need to invoke the Method(s). This is by no means 
> less secure as it doesn't matter what part of code makes the Method 
> object setAccessible(true) if it is a shared Method object.

Will wait for Joel to say more about this.   I agree with your observation.

Mandy


From stuart.marks at oracle.com  Fri Feb 27 02:04:17 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 26 Feb 2015 18:04:17 -0800
Subject: j.u.Arrays setAll and parallelSetAll subrange note
In-Reply-To: <ACD70EB0-6A49-4DA9-80CA-C8B68BCB2736@oracle.com>
References: <ACD70EB0-6A49-4DA9-80CA-C8B68BCB2736@oracle.com>
Message-ID: <54EFD0A1.8070409@oracle.com>

On 2/19/15 9:33 AM, Chris Hegarty wrote:
> It came up recently that java.util.Arrays was missing subrange overloads for setAll and parallelSetAll. These methods can be easily written with IntStream.range. Rather than adding eight new methods for this, it makes sense to point developers to IntStream.range. It seems reasonable to add a small note to these methods, promoting the use of IntStream. If someone is hunting around for a subrange setAll, then they will inevitable end up seeing this note.
>
> http://cr.openjdk.java.net/~chegar/setAllNotes/webrev.00/webrev/

Hi Chris,

Sorry I missed this -- it got buried in the usual avalanche of core-libs-dev 
email. :-)

Overall it seems reasonable, if a bit repetitive, but you've already done the 
work to customize the example for each different case. In any case, looks fine 
to me.

Are you going to file a bug for this and push it in? If so, consider this to be 
the review.

s'marks



From Roger.Riggs at Oracle.com  Fri Feb 27 02:08:45 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 26 Feb 2015 21:08:45 -0500
Subject: RFR 9: 8044051 Test jdk/lambda/vm/InterfaceAccessFlagsTest.java
	gets IOException during compilation
In-Reply-To: <54EFAD7A.9070402@oracle.com>
References: <54EF8CC0.4010201@Oracle.com> <54EFAD7A.9070402@oracle.com>
Message-ID: <54EFD1AD.6090003@Oracle.com>

Hi Joe,

Yes, jtreg sets the current directory to the scratch directory before 
starting the test.
The fix here is to use that directory (".") instead of using the jre's 
temp directory.

Roger

On 2/26/2015 6:34 PM, Joseph D. Darcy wrote:
> Hi Roger,
>
> Doesn't jtreg define a test-specific scratch directory? Is that not 
> available to TestNG tests?
>
> Cheers,
>
> -Joe
>
> On 2/26/2015 1:14 PM, Roger Riggs wrote:
>> Please review this test fix to make the test more robust to 
>> configuration and
>> pollution of the temp directory.
>>
>> Webrev:
>>    http://cr.openjdk.java.net/~rriggs/webrev-ioex-8044051/
>>
>> Issue:
>>   https://bugs.openjdk.java.net/browse/JDK-8044051
>>
>> Thanks, Roger
>



From stuart.marks at oracle.com  Fri Feb 27 02:21:50 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 26 Feb 2015 18:21:50 -0800
Subject: Time to remove deprecated Runtime.getLocalizedInput/OutputStream
	methods?
In-Reply-To: <54EB5C11.8060302@Oracle.com>
References: <54D4D5DC.3040303@Oracle.com> <54EB5C11.8060302@Oracle.com>
Message-ID: <54EFD4BE.5070501@oracle.com>

On 2/23/15 8:57 AM, Roger Riggs wrote:
> I propose to remove two methods; they have been deprecated for more than a decade,
> do not seem to be in use anywhere, and have degenerate implementations.
>
> java.lang.Runtime.getLocalizedInputStream(InputStream in)
> java.lang.Runtime.getLocalizedOutputStream(OutputStream out)
>
> I have not been able to find any use of them but would be happy to check further.
>
> Comments and suggestions welcome, Roger

Sounds like a fine idea to remove them!

s'marks
(aka DrDeprecator)


From joe.darcy at oracle.com  Fri Feb 27 02:21:24 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 26 Feb 2015 18:21:24 -0800
Subject: RFR 9: 8044051 Test jdk/lambda/vm/InterfaceAccessFlagsTest.java
	gets IOException during compilation
In-Reply-To: <54EFD1AD.6090003@Oracle.com>
References: <54EF8CC0.4010201@Oracle.com> <54EFAD7A.9070402@oracle.com>
	<54EFD1AD.6090003@Oracle.com>
Message-ID: <54EFD4A4.6080803@oracle.com>

Hi Roger,

Ah -- okay -- then approved to go back. (I was expecting to see use of 
the JT_SCRATCH variable, or similar, but I suppose "." would work too 
and is simpler.)

Thanks,

-Joe

On 2/26/2015 6:08 PM, Roger Riggs wrote:
> Hi Joe,
>
> Yes, jtreg sets the current directory to the scratch directory before 
> starting the test.
> The fix here is to use that directory (".") instead of using the jre's 
> temp directory.
>
> Roger
>
> On 2/26/2015 6:34 PM, Joseph D. Darcy wrote:
>> Hi Roger,
>>
>> Doesn't jtreg define a test-specific scratch directory? Is that not 
>> available to TestNG tests?
>>
>> Cheers,
>>
>> -Joe
>>
>> On 2/26/2015 1:14 PM, Roger Riggs wrote:
>>> Please review this test fix to make the test more robust to 
>>> configuration and
>>> pollution of the temp directory.
>>>
>>> Webrev:
>>>    http://cr.openjdk.java.net/~rriggs/webrev-ioex-8044051/
>>>
>>> Issue:
>>>   https://bugs.openjdk.java.net/browse/JDK-8044051
>>>
>>> Thanks, Roger
>>
>



From Roger.Riggs at Oracle.com  Fri Feb 27 03:13:04 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 26 Feb 2015 22:13:04 -0500
Subject: RFR 9: 8044051 Test jdk/lambda/vm/InterfaceAccessFlagsTest.java
	gets IOException during compilation
In-Reply-To: <54EFD4A4.6080803@oracle.com>
References: <54EF8CC0.4010201@Oracle.com> <54EFAD7A.9070402@oracle.com>
	<54EFD1AD.6090003@Oracle.com> <54EFD4A4.6080803@oracle.com>
Message-ID: <54EFE0C0.6010803@Oracle.com>

Thanks Joe,

This has been on the intermittent fail list for a long time.

Roger

On 2/26/2015 9:21 PM, joe darcy wrote:
> Hi Roger,
>
> Ah -- okay -- then approved to go back. (I was expecting to see use of 
> the JT_SCRATCH variable, or similar, but I suppose "." would work too 
> and is simpler.)
>
> Thanks,
>
> -Joe
>
> On 2/26/2015 6:08 PM, Roger Riggs wrote:
>> Hi Joe,
>>
>> Yes, jtreg sets the current directory to the scratch directory before 
>> starting the test.
>> The fix here is to use that directory (".") instead of using the 
>> jre's temp directory.
>>
>> Roger
>>
>> On 2/26/2015 6:34 PM, Joseph D. Darcy wrote:
>>> Hi Roger,
>>>
>>> Doesn't jtreg define a test-specific scratch directory? Is that not 
>>> available to TestNG tests?
>>>
>>> Cheers,
>>>
>>> -Joe
>>>
>>> On 2/26/2015 1:14 PM, Roger Riggs wrote:
>>>> Please review this test fix to make the test more robust to 
>>>> configuration and
>>>> pollution of the temp directory.
>>>>
>>>> Webrev:
>>>>    http://cr.openjdk.java.net/~rriggs/webrev-ioex-8044051/
>>>>
>>>> Issue:
>>>>   https://bugs.openjdk.java.net/browse/JDK-8044051
>>>>
>>>> Thanks, Roger
>>>
>>
>



From paul.sandoz at oracle.com  Fri Feb 27 08:00:32 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 27 Feb 2015 09:00:32 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <C976000D-D17B-4309-BA91-B26CDD0647A3@oracle.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>
	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
	<C976000D-D17B-4309-BA91-B26CDD0647A3@oracle.com>
Message-ID: <2EF3FF5D-2CC8-49D1-A0F5-B45BA25D9255@oracle.com>


On Feb 26, 2015, at 5:02 PM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:

> Hi,
> 
> If anyone wants to give this a test drive see stuff in here:
> 
>  http://cr.openjdk.java.net/~psandoz/multiversion-jar/
> 
> produced by Steve (CC'ed) who has done all the development.
> 

Another correction, CC'ing Steve this time...

Paul.


From paul.sandoz at oracle.com  Fri Feb 27 08:20:19 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 27 Feb 2015 09:20:19 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <2EF3FF5D-2CC8-49D1-A0F5-B45BA25D9255@oracle.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>
	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
	<C976000D-D17B-4309-BA91-B26CDD0647A3@oracle.com>
	<2EF3FF5D-2CC8-49D1-A0F5-B45BA25D9255@oracle.com>
Message-ID: <96710E08-A7FA-4645-B4D7-9D7CD576CE7E@oracle.com>

On Feb 27, 2015, at 9:00 AM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
> 
> On Feb 26, 2015, at 5:02 PM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
> 
>> Hi,
>> 
>> If anyone wants to give this a test drive see stuff in here:
>> 
>> http://cr.openjdk.java.net/~psandoz/multiversion-jar/
>> 
>> produced by Steve (CC'ed) who has done all the development.
>> 
> 
> Another correction, CC'ing Steve this time...
> 

Hmm.... it seems the CC field is being removed by the server. Anyone else noticing this?

FTR here is Steve's email:

  Steve Drach <steve.drach at oracle.com>

Paul.


From scolebourne at joda.org  Fri Feb 27 08:36:38 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 27 Feb 2015 08:36:38 +0000
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54EFAC4D.4060800@gmail.com>
References: <54EA3A41.9000309@gmail.com>
	<CACzrW9AAzCce5D9k20GZz8XHnZ3QpRD5z_+Pv3HcquaNzK2u4Q@mail.gmail.com>
	<54EF7EB9.1040305@gmail.com>
	<CACzrW9Dx+UnkvC2_pc-k9jbkmuynRnnSc=_2fV-asioyYjHheA@mail.gmail.com>
	<54EFA7D1.6000907@gmail.com> <54EFAC4D.4060800@gmail.com>
Message-ID: <CACzrW9DGF8=E68fHhqQWHdL=g-KZ4abowt4BU3pa2juvz=p-Qw@mail.gmail.com>

On 26 February 2015 at 23:29, Peter Levart <peter.levart at gmail.com> wrote:
> Here's another variant that doesn't use a back link to base TimeZone:
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.03/

Yes, thats easier to follow. I think I'd be happy with that approach.

I don't think I saw an issue raised for caching the clock in ZoneId.
That seems like a good plan to me (ZoneId instances are controlled
singletons, so there is no big memory issue there)

Stephen


From paul.sandoz at oracle.com  Fri Feb 27 08:43:02 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 27 Feb 2015 09:43:02 +0100
Subject: RFR JDK-8073924: Update
	test/java/nio/charset/Charset/NIOCharsetAvailability.java to
	work with module system
In-Reply-To: <54EF9F4C.8090900@oracle.com>
References: <54EE8928.7050702@oracle.com> <54EF8A8B.3070005@oracle.com>
	<54EF8EC6.5070306@oracle.com> <54EF94F5.2030204@oracle.com>
	<54EF99AE.6020400@oracle.com> <54EF9F4C.8090900@oracle.com>
Message-ID: <FF15F05B-482D-4319-ADE7-2A48A1C8E29B@oracle.com>


On Feb 26, 2015, at 11:33 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 26/02/2015 22:09, Xueming Shen wrote:
>> 
>> thanks! webrev has been updated accordingly.
>> 
>> http://cr.openjdk.java.net/~sherman/8073924/webrev
> We could probably improve it further but what you have is good and not worth spending more time on it.
> 

Looks ok to me.

Paul.


From Alan.Bateman at oracle.com  Fri Feb 27 08:45:17 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 27 Feb 2015 08:45:17 +0000
Subject: RFR JDK-8073924: Update
	test/java/nio/charset/Charset/NIOCharsetAvailability.java
	to work with module system
In-Reply-To: <54EF99AE.6020400@oracle.com>
References: <54EE8928.7050702@oracle.com> <54EF8A8B.3070005@oracle.com>
	<54EF8EC6.5070306@oracle.com> <54EF94F5.2030204@oracle.com>
	<54EF99AE.6020400@oracle.com>
Message-ID: <54F02E9D.30802@oracle.com>

On 26/02/2015 22:09, Xueming Shen wrote:
>
> thanks! webrev has been updated accordingly.
One other tests that needs to be re-examined is 
test/sun/nio/cs/Test4200310.sh as it assumes rt.jar and charsets.jar 
too. In this case then it might be better to just remove it.

-Alan


From paul.sandoz at oracle.com  Fri Feb 27 08:52:55 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 27 Feb 2015 09:52:55 +0100
Subject: Time to remove deprecated Runtime.getLocalizedInput/OutputStream
	methods?
In-Reply-To: <54EB5C11.8060302@Oracle.com>
References: <54D4D5DC.3040303@Oracle.com> <54EB5C11.8060302@Oracle.com>
Message-ID: <CA86AB42-56DA-418F-BD5F-A348795CD6C7@oracle.com>


On Feb 23, 2015, at 5:57 PM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:

> Hi,
> 
> I propose to remove two methods; they have been deprecated for more than a decade,
> do not seem to be in use anywhere, and have degenerate implementations.
> 
> java.lang.Runtime.getLocalizedInputStream(InputStream in) java.lang.Runtime.getLocalizedOutputStream(OutputStream out)
> 
> I have not been able to find any use of them but would be happy to check further.
> 

grepcode.com reports no usages or derivations, that's usually a good sign they can be removed.

Paul.



From paul.sandoz at oracle.com  Fri Feb 27 09:06:59 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 27 Feb 2015 10:06:59 +0100
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <EAA6E2DA-AB45-4C35-A1AD-2493E82275B9@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com> <54E71BC3.30403@oracle.com>
	<54E74E29.2060806@gmail.com> <54EB08A5.4000905@oracle.com>
	<54EB96B8.30304@gmail.com>
	<DAFD881E-4105-4140-AEEC-7724A5C84C6D@oracle.com>
	<54EC6464.8090608@gmail.com>
	<2A98B462-287D-43C1-99FA-8CF58BCA93BB@oracle.com>
	<EAA6E2DA-AB45-4C35-A1AD-2493E82275B9@oracle.com>
Message-ID: <5131E491-0E0B-49AF-9F78-4E914B2A5580@oracle.com>


On Feb 26, 2015, at 12:38 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> On 24 Feb 2015, at 15:07, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
>> On 24 Feb 2015, at 11:45, Peter Levart <peter.levart at gmail.com> wrote:
>> ...
>>> That's better now. Let me just try to measure the overhead of tracking on simple objects to see if it actually pays off or is contra-productive in any case.
>> 
>> Thanks. I?ll see if I can get some measurements also.
> 
> I created a very simple benchmark [1] that deserializes a single object with no fields. Run with JDK 9 b52, on a reasonably fast machine ( results [2] ), we can see the time taken to reconstitute the simple object is relatively large compared to the measured 5ns [3] for the fence on a, slower, ARM processor. The fence should be a noop on x86 and SPARC.  When you start adding fields to object being deserialized [4] the time increases significantly. 
> 
> Result: 2176.895 ??(99.9%) 72.194 ns/op [Average]
>  Statistics: (min, avg, max) = (2131.529, 2176.895, 2287.482), stdev = 47.752
>  Confidence interval (99.9%): [2104.701, 2249.089]
> 
> Given this, I think we should issue the fence unconditionally. A nice property of this is that custom readObjects, using Unsafe, no longer need to reason about transient final fields, they can simply use putXXX for any field.
> 
> Updated, and greatly simplified, webrev:
>  http://cr.openjdk.java.net/~chegar/deserialFence/webrev.04/webrev/
> 

A nice simplification.


On Feb 26, 2015, at 12:57 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> I created a very simple benchmark [1] that deserializes a single object with no fields. Run with JDK 9 b52, on a reasonably fast machine ( results [2] ), we can see the time taken to reconstitute the simple object is relatively large compared to the measured 5ns [3] for the fence on a, slower, ARM processor.
> 
> Of course, this measurement was for a hotspots post construction StoreStore, we are issuing a StoreStore|StoreLoad, but the general idea is still the same, the fence is relatively insignificant, when performed per graph, compared to the cost or re-consisituing the graph.

Yes.

Paul.


From joel.franck at oracle.com  Fri Feb 27 09:27:23 2015
From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=)
Date: Fri, 27 Feb 2015 10:27:23 +0100
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <54EF91A8.4050303@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>
Message-ID: <915E482B-4BE9-4BB1-AF9B-712C5FF12A3F@oracle.com>


> 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.

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().

cheers
/Joel


From aph at redhat.com  Fri Feb 27 09:34:01 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 27 Feb 2015 09:34:01 +0000
Subject: stop using mmap for zip I/O
In-Reply-To: <20150226221759.4560B17FDAA@rebar.astron.com>
References: <20150226221759.4560B17FDAA@rebar.astron.com>
Message-ID: <54F03A09.9060507@redhat.com>

On 26/02/15 22:17, Christos Zoulas wrote:
> 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.

So we catch the signal, right?  Maybe there's something I'm missing...

Andrew.



From magnus.ihse.bursie at oracle.com  Fri Feb 27 09:43:44 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 27 Feb 2015 10:43:44 +0100
Subject: RFR: JDK-8072842 Add support for building native JTReg tests
In-Reply-To: <54EEE6A6.8050103@oracle.com>
References: <54DA146D.3060904@oracle.com>
	<54DAB1CE.70506@oracle.com>	<54DB0E31.3010201@oracle.com>
	<54DB1175.6030700@oracle.com>	<54DB125D.2070706@oracle.com>	<F27CF091-29B1-4C22-BDF7-DD1D3469F2BE@oracle.com>	<54DB1528.4030708@oracle.com>	<324EF37C-3FD2-4B8A-A509-D7315889D8DE@oracle.com>	<54DB39C2.5010607@oracle.com>	<31B825DC-DFD2-4EC2-81AD-9BF0FC3364CC@oracle.com>
	<54EDB038.4000502@oracle.com> <54EEE6A6.8050103@oracle.com>
Message-ID: <54F03C50.7040001@oracle.com>

On 2015-02-26 10:25, Erik Joelsson wrote:
> Hello Magnus,
>
> Overall looks good. I would prefer if some of the longer lines in 
> Main.gmk were split as it's a file I often need to read. In MakeBase, 
> the definition of dups, I thought we (informally) agreed to start such 
> macro definitions with a newline to make them stand out more from 
> normal variable declarations?

I had forgot about that; I just copied the pattern of the macros that 
was already in place.

I have now updated dups to use the newline format. I also updated the 
old macros to follow this rule.

All the new lines in MakeBase should now be shorter than 80 chars.

New webrev: 
http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.03

/Magnus



From sean.coffey at oracle.com  Fri Feb 27 09:51:44 2015
From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=)
Date: Fri, 27 Feb 2015 09:51:44 +0000
Subject: stop using mmap for zip I/O
In-Reply-To: <54F03A09.9060507@redhat.com>
References: <20150226221759.4560B17FDAA@rebar.astron.com>
	<54F03A09.9060507@redhat.com>
Message-ID: <54F03E30.6040709@oracle.com>

The sun.zip.disableMemoryMapping=true property helps with ZipFile class 
only. There are other related issues in the ZipInput/Output streams. 
Some code areas don't have synchronization and there are opportunities 
for the underlying native zip resources to be freed which Java code then 
tries to reference causing various SEGV. I've one or two areas of code 
identified for tightening up and hope to get to it in coming weeks. 
(long standing action item)
> 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 ?

regards,
Sean.

On 27/02/2015 09:34, Andrew Haley wrote:
> On 26/02/15 22:17, Christos Zoulas wrote:
>> 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.
> So we catch the signal, right?  Maybe there's something I'm missing...
>
> Andrew.
>



From joel.franck at oracle.com  Fri Feb 27 09:52:20 2015
From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=)
Date: Fri, 27 Feb 2015 10:52:20 +0100
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <54EFB47E.4050901@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>
	<54EFB47E.4050901@oracle.com>
Message-ID: <B4B792DB-F5E5-4D8C-B732-23C44F56AB96@oracle.com>

Hi,

> On 27 feb 2015, at 01:04, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> On 2/26/15 1:27 PM, Peter Levart wrote:
>> 
>> On 02/26/2015 05:34 PM, Mandy Chung wrote:
>>>> The problem is with the default method AnnotatedElement::getDeclaredAnnotationsByType. If someone has an external implementation of AnnotatedElement (and one of the lessons from adding these methods in 8 was that there are other implementations) then if that external implementation haven?t added getDeclaredAnnotationsByType they will call into our AnnotationSupport. This is all fine if that external representation of AnnotatedElement uses our representation of Annotations, with Proxies and all. But I suspect that the conditions that would end up taking the non-proxy code path in the patch, will already fail in the check: 
>>>> 
>>>>               AnnotationType annoType = AnnotationType.getInstance(containerClass); 
>>>>               if (annoType == null) 
>>>>                   throw invalidContainerException(container, null); 
>>>> 
>>>> So what is the best thing to do here if the annotation is not Proxy based and is coming from an implementation of the AnnotatedElement interface that we don?t control and that is missing the methods added in 8? 
>>> 
>>> I did a quick search on my corpus and find only one reference to 
>>> sun.reflect.annotation.AnnotationType.  Looks like external implementation 
>>> doesn't get pass this.
>> 
>> Now I'm missing something. Why would a custom non-Proxy based annotation not pass the above code?
> 
> I had assumed that AnnotationType.getInstance also expects the implementation of the annotation type is sun.reflect.annotation.AnnotationType.  I don't know enough about this area and that's just my observation. Hope Joel will say more details.
>> I don't see anything in AnnotationType implementation that would be dependent on annotation implementation to be a Proxy. AnnotationType only deals with the annotation type, which is an interface, not with implementation.

I realized this on my way home, and Peter is right here. There is nothing special for ?our? annotations in AnnotationType::getInstance.

>> 
>> The m.setAccessible(true) for the methods is needed to access methods of non-public annotations, right?
> 
> I think so.

Yes, the method on the interface will always (pre 9  at least) be public, the interface might not be accessible. I have toyed with the idea of fetching the method form the impl instead, but that has the same issues, and is arguably worse from a security perspective.

>> This call could be moved to AnnotationType constructor as there it will be performed only once per Method object.
>> 
> If the specification supports other implementation, it seems to me that calling setAccessible(true) should be wrapped with doPrivileged unless the specification states the "suppressAccessCheck" permission is required; otherwise, SecurityException will be thrown.  It'd be good to clarify what that code is intended for.
> 

There is nothing in the spec about any security exceptions here. But on the other hand, there is nothing in the spec for AnnotatedElement::getAnnotationsByType specifying throwing anything that a custom implementation of AnnotatedElement using the default methods may throw.

But I?ll take this back to the drawing board, there is some things I want to explore. However performance is at best a very distant third priority here, after security and compatibility.

cheers
/Joel

From paul.sandoz at oracle.com  Fri Feb 27 10:03:10 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 27 Feb 2015 11:03:10 +0100
Subject: [9] RFR (XS): 8073644: Assertion in
	LambdaFormEditor.bindArgumentType is too strict
In-Reply-To: <54EF6281.3040501@oracle.com>
References: <54EF6281.3040501@oracle.com>
Message-ID: <BE60F08B-8C22-4AED-9AEB-195AA4F0E5EC@oracle.com>


On Feb 26, 2015, at 7:14 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> http://cr.openjdk.java.net/~vlivanov/8073644/webrev.00
> https://bugs.openjdk.java.net/browse/JDK-8073644
> 
> After JDK-8069591 [1] which introduced LambdaForm customization, the assert in LambdaFormEditor.bindArgumentType became too strict.
> 
> The fix is to relax it - compare uncustomized versions. And LambdaFormEditor.lambdaForm is always uncustomized.
> 
> Testing: java/lang/invoke, nashorn tests
> 

+1

I needed to remind myself of the dual nature of LambdaForm.transformCache :-)
 
Paul.


From peter.levart at gmail.com  Fri Feb 27 10:06:58 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 27 Feb 2015 11:06:58 +0100
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <915E482B-4BE9-4BB1-AF9B-712C5FF12A3F@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>
Message-ID: <54F041C2.7040701@gmail.com>


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.

Regards, Peter

> cheers
> /Joel



From peter.levart at gmail.com  Fri Feb 27 10:22:47 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 27 Feb 2015 11:22:47 +0100
Subject: RFR [9]: default Serialization should issue a fence after
	reconstructing an Object with final fields
In-Reply-To: <54F04437.2070605@oracle.com>
References: <7B4C2165-143B-4116-96D4-F69E3DC7C4D8@oracle.com>
	<7DC94668-84A3-463B-85B0-C6FE3C546E90@oracle.com>
	<CAHjP37HexLdHGwVLFgD1VuE--i2ODjji5SPVchFZJGzZsiBB0Q@mail.gmail.com>
	<54E67F76.8030104@oracle.com> <54E71BC3.30403@oracle.com>
	<54E74E29.2060806@gmail.com> <54EB08A5.4000905@oracle.com>
	<54EB96B8.30304@gmail.com>
	<DAFD881E-4105-4140-AEEC-7724A5C84C6D@oracle.com>
	<54EC6464.8090608@gmail.com>
	<2A98B462-287D-43C1-99FA-8CF58BCA93BB@oracle.com>
	<EAA6E2DA-AB45-4C35-A1AD-2493E82275B9@oracle.com>
	<5131E491-0E0B-49AF-9F78-4E914B2A5580@oracle.com>
	<54F04437.2070605@oracle.com>
Message-ID: <CAJUsCJCD9gpoJETYyJyu=t+Lrk6Q4Ms=rgBRRoNMseptQK4SdA@mail.gmail.com>

Hi Chris,

webrev.04 is nice an simple now. I'm ok with it.

Regards, Peter
On Feb 27, 2015 11:11 AM, "Chris Hegarty" <chris.hegarty at oracle.com> wrote:

> Hi Peter,
>
> I think you are ok with this now. If so, would you mind to just taking a
> quick look at the webrev, the changes are trivial, and replying to the list.
>
> ( I want to list you as a reviewer, but don't want to do so until I know
> you are happy with the changes) .
>
> Thanks,
> -Chris.
>
> On 27/02/15 09:06, Paul Sandoz wrote:
>
>>
>> On Feb 26, 2015, at 12:38 PM, Chris Hegarty <chris.hegarty at oracle.com>
>> wrote:
>>
>>  On 24 Feb 2015, at 15:07, Chris Hegarty <chris.hegarty at oracle.com>
>>> wrote:
>>>
>>>  On 24 Feb 2015, at 11:45, Peter Levart <peter.levart at gmail.com> wrote:
>>>> ...
>>>>
>>>>> That's better now. Let me just try to measure the overhead of tracking
>>>>> on simple objects to see if it actually pays off or is contra-productive in
>>>>> any case.
>>>>>
>>>>
>>>> Thanks. I?ll see if I can get some measurements also.
>>>>
>>>
>>> I created a very simple benchmark [1] that deserializes a single object
>>> with no fields. Run with JDK 9 b52, on a reasonably fast machine ( results
>>> [2] ), we can see the time taken to reconstitute the simple object is
>>> relatively large compared to the measured 5ns [3] for the fence on a,
>>> slower, ARM processor. The fence should be a noop on x86 and SPARC.  When
>>> you start adding fields to object being deserialized [4] the time increases
>>> significantly.
>>>
>>> Result: 2176.895 ??(99.9%) 72.194 ns/op [Average]
>>>   Statistics: (min, avg, max) = (2131.529, 2176.895, 2287.482), stdev =
>>> 47.752
>>>   Confidence interval (99.9%): [2104.701, 2249.089]
>>>
>>> Given this, I think we should issue the fence unconditionally. A nice
>>> property of this is that custom readObjects, using Unsafe, no longer need
>>> to reason about transient final fields, they can simply use putXXX for any
>>> field.
>>>
>>> Updated, and greatly simplified, webrev:
>>>   http://cr.openjdk.java.net/~chegar/deserialFence/webrev.04/webrev/
>>>
>>>
>> A nice simplification.
>>
>>
>> On Feb 26, 2015, at 12:57 PM, Chris Hegarty <chris.hegarty at oracle.com>
>> wrote:
>>
>>> I created a very simple benchmark [1] that deserializes a single object
>>>> with no fields. Run with JDK 9 b52, on a reasonably fast machine ( results
>>>> [2] ), we can see the time taken to reconstitute the simple object is
>>>> relatively large compared to the measured 5ns [3] for the fence on a,
>>>> slower, ARM processor.
>>>>
>>>
>>> Of course, this measurement was for a hotspots post construction
>>> StoreStore, we are issuing a StoreStore|StoreLoad, but the general idea is
>>> still the same, the fence is relatively insignificant, when performed per
>>> graph, compared to the cost or re-consisituing the graph.
>>>
>>
>> Yes.
>>
>> Paul.
>>
>>


From daniel.fuchs at oracle.com  Fri Feb 27 10:55:01 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 27 Feb 2015 11:55:01 +0100
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <CACzrW9DGF8=E68fHhqQWHdL=g-KZ4abowt4BU3pa2juvz=p-Qw@mail.gmail.com>
References: <54EA3A41.9000309@gmail.com>	<CACzrW9AAzCce5D9k20GZz8XHnZ3QpRD5z_+Pv3HcquaNzK2u4Q@mail.gmail.com>	<54EF7EB9.1040305@gmail.com>	<CACzrW9Dx+UnkvC2_pc-k9jbkmuynRnnSc=_2fV-asioyYjHheA@mail.gmail.com>	<54EFA7D1.6000907@gmail.com>
	<54EFAC4D.4060800@gmail.com>
	<CACzrW9DGF8=E68fHhqQWHdL=g-KZ4abowt4BU3pa2juvz=p-Qw@mail.gmail.com>
Message-ID: <54F04D05.2040907@oracle.com>

On 27/02/15 09:36, Stephen Colebourne wrote:
> On 26 February 2015 at 23:29, Peter Levart <peter.levart at gmail.com> wrote:
>> Here's another variant that doesn't use a back link to base TimeZone:
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.03/
>
> Yes, thats easier to follow. I think I'd be happy with that approach.
>
> I don't think I saw an issue raised for caching the clock in ZoneId.
> That seems like a good plan to me (ZoneId instances are controlled
> singletons, so there is no big memory issue there)

I'd been intending to log that. Thanks for reminding me!
Here is the issue:
https://bugs.openjdk.java.net/browse/JDK-8074023

best regards,

-- daniel

>
> Stephen
>



From aph at redhat.com  Fri Feb 27 11:30:39 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 27 Feb 2015 11:30:39 +0000
Subject: stop using mmap for zip I/O
In-Reply-To: <54F03E30.6040709@oracle.com>
References: <20150226221759.4560B17FDAA@rebar.astron.com>
	<54F03A09.9060507@redhat.com> <54F03E30.6040709@oracle.com>
Message-ID: <54F0555F.3090200@redhat.com>

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.

Andrew.


From scolebourne at joda.org  Fri Feb 27 12:16:42 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 27 Feb 2015 12:16:42 +0000
Subject: java.time.ZoneId.systemDefalut() overhead
In-Reply-To: <54F04D05.2040907@oracle.com>
References: <54EA3A41.9000309@gmail.com>
	<CACzrW9AAzCce5D9k20GZz8XHnZ3QpRD5z_+Pv3HcquaNzK2u4Q@mail.gmail.com>
	<54EF7EB9.1040305@gmail.com>
	<CACzrW9Dx+UnkvC2_pc-k9jbkmuynRnnSc=_2fV-asioyYjHheA@mail.gmail.com>
	<54EFA7D1.6000907@gmail.com> <54EFAC4D.4060800@gmail.com>
	<CACzrW9DGF8=E68fHhqQWHdL=g-KZ4abowt4BU3pa2juvz=p-Qw@mail.gmail.com>
	<54F04D05.2040907@oracle.com>
Message-ID: <CACzrW9DKtvc9GVAp92Ox4CX-qcHOTAXABHQjjAc9K9F4keDGEQ@mail.gmail.com>

On 27 February 2015 at 10:55, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>> I don't think I saw an issue raised for caching the clock in ZoneId.
>> That seems like a good plan to me (ZoneId instances are controlled
>> singletons, so there is no big memory issue there)
>
> I'd been intending to log that. Thanks for reminding me!
> Here is the issue:
> https://bugs.openjdk.java.net/browse/JDK-8074023

I've commented on the issue. Its a little more complex than I thought,
but perfectly do-able. Just needs some ZoneId instances to be cached
as well.

Stephen


From christos at zoulas.com  Fri Feb 27 12:21:12 2015
From: christos at zoulas.com (Christos Zoulas)
Date: Fri, 27 Feb 2015 07:21:12 -0500
Subject: stop using mmap for zip I/O
In-Reply-To: <54F03A09.9060507@redhat.com> from Andrew Haley (Feb 27,  9:34am)
Message-ID: <20150227122112.85EEB17FDAA@rebar.astron.com>

On Feb 27,  9:34am, aph at redhat.com (Andrew Haley) wrote:
-- Subject: Re: stop using mmap for zip I/O

| On 26/02/15 22:17, Christos Zoulas wrote:
| > 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.
| 
| So we catch the signal, right?  Maybe there's something I'm missing...

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

Uncomment the crashReadWrite() test, add a few imports and run it...
[it crashes the jdk with SIGBUS on linux]

christos


From christos at zoulas.com  Fri Feb 27 12:23:55 2015
From: christos at zoulas.com (Christos Zoulas)
Date: Fri, 27 Feb 2015 07:23:55 -0500
Subject: stop using mmap for zip I/O
In-Reply-To: <54F03E30.6040709@oracle.com>
	from =?windows-1252?Q?Se=E1n_Coffey?= (Feb 27,  9:51am)
Message-ID: <20150227122355.E13DC17FDAA@rebar.astron.com>

On Feb 27,  9:51am, sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) wrote:
-- Subject: Re: stop using mmap for zip I/O

| The sun.zip.disableMemoryMapping=true property helps with ZipFile class 
| only. There are other related issues in the ZipInput/Output streams. 
| Some code areas don't have synchronization and there are opportunities 
| for the underlying native zip resources to be freed which Java code then 
| tries to reference causing various SEGV. I've one or two areas of code 
| identified for tightening up and hope to get to it in coming weeks. 
| (long standing action item)

Absolutely, there are unchecked lengths that are used to copy buffers...

| > 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 ?

It is SIGBUS...

christos


From elena.votchennikova at oracle.com  Fri Feb 27 11:38:13 2015
From: elena.votchennikova at oracle.com (elena votchennikova)
Date: Fri, 27 Feb 2015 15:38:13 +0400
Subject: JDK 9 RFR of JDK-8073952: Spec of
	j.l.r.Method.toString/toGenericString need to be clarified
In-Reply-To: <54EFC839.6050609@oracle.com>
References: <54EFC839.6050609@oracle.com>
Message-ID: <54F05725.1090208@oracle.com>

Hello,

Looks good to me.

Thank you,
Elena

On 27.02.2015 5:28, joe darcy wrote:
> Hello,
>
> Please review the small changes to address
>
>     JDK-8073952: Spec of j.l.r.Method.toString/toGenericString need to 
> be clarified
>     http://cr.openjdk.java.net/~darcy/8073952.0/
>
> Full patch below.
>
> In essence, the patch adds references to the JLS sections which talk 
> about interfaces and default methods.
>
> Thanks,
>
> -Joe
>
> --- old/src/java.base/share/classes/java/lang/reflect/Constructor.java 
> 2015-02-26 17:14:49.955169685 -0800
> +++ new/src/java.base/share/classes/java/lang/reflect/Constructor.java 
> 2015-02-26 17:14:49.799091677 -0800
> @@ -296,7 +296,8 @@
>       * constructor has default (package) access.
>       *
>       * @return a string describing this {@code Constructor}
> -     * @jls 8.8.3. Constructor Modifiers
> +     * @jls 8.8.3 Constructor Modifiers
> +     * @jls 8.9.2 Enum Body Declarations
>       */
>      public String toString() {
>          return sharedToString(Modifier.constructorModifiers(),
> @@ -342,7 +343,8 @@
>       * include type parameters
>       *
>       * @since 1.5
> -     * @jls 8.8.3. Constructor Modifiers
> +     * @jls 8.8.3 Constructor Modifiers
> +     * @jls 8.9.2 Enum Body Declarations
>       */
>      @Override
>      public String toGenericString() {
> --- old/src/java.base/share/classes/java/lang/reflect/Method.java 
> 2015-02-26 17:14:50.403393705 -0800
> +++ new/src/java.base/share/classes/java/lang/reflect/Method.java 
> 2015-02-26 17:14:50.227305697 -0800
> @@ -356,6 +356,8 @@
>       * @return a string describing this {@code Method}
>       *
>       * @jls 8.4.3 Method Modifiers
> +     * @jls 9.4   Method Declarations
> +     * @jls 9.6.1 Annotation Type Elements
>       */
>      public String toString() {
>          return sharedToString(Modifier.methodModifiers(),
> @@ -409,6 +411,8 @@
>       * @since 1.5
>       *
>       * @jls 8.4.3 Method Modifiers
> +     * @jls 9.4   Method Declarations
> +     * @jls 9.6.1 Annotation Type Elements
>       */
>      @Override
>      public String toGenericString() {
>



From fweimer at redhat.com  Fri Feb 27 13:27:18 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Fri, 27 Feb 2015 14:27:18 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>
	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
Message-ID: <54F070B6.4070204@redhat.com>

On 02/12/2015 09:52 PM, Paul Sandoz wrote:
> Hi
> 
> In connection with the JEP there is also a design document to help the discussion:
> 
>   http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
> 
> We are especially interesting in hearing feedback from library developers, tool/IDE developers, and anyone doing funky stuff with class loading and JAR files.

I'm wondering how you propose to build such JAR files.  Do you think
library developers will maintain two separate branches, compile one with
JDK 8, the other one with JDK 9, and then use some (not yet existing?)
tool to merge the output into a single JAR?  Is such automated merging
even possible if the bytecode was compiled with different javac versions?

What about presenting Javadoc in a useful fashion?

-- 
Florian Weimer / Red Hat Product Security


From sean.coffey at oracle.com  Fri Feb 27 13:47:01 2015
From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=)
Date: Fri, 27 Feb 2015 13:47:01 +0000
Subject: stop using mmap for zip I/O
In-Reply-To: <20150227122355.E13DC17FDAA@rebar.astron.com>
References: <20150227122355.E13DC17FDAA@rebar.astron.com>
Message-ID: <54F07555.50902@oracle.com>


On 27/02/15 12:23, christos at zoulas.com wrote:
> On Feb 27,  9:51am, sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) wrote:
> -- Subject: Re: stop using mmap for zip I/O
>
> | The sun.zip.disableMemoryMapping=true property helps with ZipFile class
> | only. There are other related issues in the ZipInput/Output streams.
> | Some code areas don't have synchronization and there are opportunities
> | for the underlying native zip resources to be freed which Java code then
> | tries to reference causing various SEGV. I've one or two areas of code
> | identified for tightening up and hope to get to it in coming weeks.
> | (long standing action item)
>
> Absolutely, there are unchecked lengths that are used to copy buffers...
Are those issues documented in a bug report somewhere ? Please share if not.

>
> | > 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 ?
>
> It is SIGBUS...
The issues I've been looking at are SEGV issues concerning multiple threads
operating on the same zip structure. (one freeing, while another is 
attempting access)

Variants of that issue exist also. E.g. :
https://bugs.openjdk.java.net/browse/JDK-8031691
https://bugs.openjdk.java.net/browse/JDK-8028216
https://bugs.openjdk.java.net/browse/JDK-7092196

regards,
Sean.

>
> christos



From aph at redhat.com  Fri Feb 27 13:49:33 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 27 Feb 2015 13:49:33 +0000
Subject: stop using mmap for zip I/O
In-Reply-To: <54F07555.50902@oracle.com>
References: <20150227122355.E13DC17FDAA@rebar.astron.com>
	<54F07555.50902@oracle.com>
Message-ID: <54F075ED.4020300@redhat.com>

On 02/27/2015 01:47 PM, Se?n Coffey wrote:
> 
> On 27/02/15 12:23, christos at zoulas.com wrote:
>> On Feb 27,  9:51am, sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) wrote:
>> -- Subject: Re: stop using mmap for zip I/O
>>
>> | The sun.zip.disableMemoryMapping=true property helps with ZipFile class
>> | only. There are other related issues in the ZipInput/Output streams.
>> | Some code areas don't have synchronization and there are opportunities
>> | for the underlying native zip resources to be freed which Java code then
>> | tries to reference causing various SEGV. I've one or two areas of code
>> | identified for tightening up and hope to get to it in coming weeks.
>> | (long standing action item)
>>
>> Absolutely, there are unchecked lengths that are used to copy buffers...
> Are those issues documented in a bug report somewhere ? Please share if not.
> 
>> | > 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 ?
>>
>> It is SIGBUS...
> The issues I've been looking at are SEGV issues concerning multiple threads
> operating on the same zip structure. (one freeing, while another is 
> attempting access)

The issue Christos is referring to is probably the bus error you get
when a buffer is unmapped.  This is what I was referring to as well.

Recovering from a crash caused by one thread modifying a structure
while another reads it is much harder; my apologies, I misunderstood
you.

Andrew.


From david.lloyd at redhat.com  Fri Feb 27 13:58:06 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 27 Feb 2015 07:58:06 -0600
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <54F070B6.4070204@redhat.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
	<54F070B6.4070204@redhat.com>
Message-ID: <54F077EE.8070504@redhat.com>

On 02/27/2015 07:27 AM, Florian Weimer wrote:
> On 02/12/2015 09:52 PM, Paul Sandoz wrote:
>> Hi
>>
>> In connection with the JEP there is also a design document to help the discussion:
>>
>>    http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
>>
>> We are especially interesting in hearing feedback from library developers, tool/IDE developers, and anyone doing funky stuff with class loading and JAR files.
>
> I'm wondering how you propose to build such JAR files.  Do you think
> library developers will maintain two separate branches, compile one with
> JDK 8, the other one with JDK 9, and then use some (not yet existing?)
> tool to merge the output into a single JAR?  Is such automated merging
> even possible if the bytecode was compiled with different javac versions?

This is basically what I was getting at in my post.  It's interesting 
that JDK-8058150 (Compile for Specific Platform Version) is surfacing at 
the same time, because it seems to me that this would make it possible 
for javac to compile for multiple targets in one pass.  Maybe not easy, 
but possible. :-)

> What about presenting Javadoc in a useful fashion?

Good question...

-- 
- DML


From christos at zoulas.com  Fri Feb 27 14:14:42 2015
From: christos at zoulas.com (Christos Zoulas)
Date: Fri, 27 Feb 2015 09:14:42 -0500
Subject: stop using mmap for zip I/O
In-Reply-To: <54F075ED.4020300@redhat.com> from Andrew Haley (Feb 27,  1:49pm)
Message-ID: <20150227141442.1472D17FDAA@rebar.astron.com>

On Feb 27,  1:49pm, aph at redhat.com (Andrew Haley) wrote:
-- Subject: Re: stop using mmap for zip I/O

| > The issues I've been looking at are SEGV issues concerning multiple threads
| > operating on the same zip structure. (one freeing, while another is 
| > attempting access)

Yes, I am not referring to the SEGV's from concurrent access or unchecked
buffer limits from corrupt entries in the central directory. These are much
more complicated to fix.

| The issue Christos is referring to is probably the bus error you get
| when a buffer is unmapped.  This is what I was referring to as well.

Yes, but the cause is not the buffer being unmapped. It is because the
buffer gets truncated:

    http://pubs.opengroup.org/onlinepubs/009695399/functions/mmap.html

    "References within the address range starting at pa and continuing
     for len bytes to whole pages following the end of an object shall
     result in delivery of a SIGBUS signal."

Which is what my example program and the bug report I referenced demonstrate.

| Recovering from a crash caused by one thread modifying a structure
| while another reads it is much harder; my apologies, I misunderstood
| you.

Absolutely, I was just advocating turning mmap off since it fixes the
simple case of someone overwriting the zip file loaded which is quite
common.

christos


From Alan.Bateman at oracle.com  Fri Feb 27 14:17:03 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 27 Feb 2015 14:17:03 +0000
Subject: stop using mmap for zip I/O
In-Reply-To: <54F0555F.3090200@redhat.com>
References: <20150226221759.4560B17FDAA@rebar.astron.com>	<54F03A09.9060507@redhat.com>
	<54F03E30.6040709@oracle.com> <54F0555F.3090200@redhat.com>
Message-ID: <54F07C5F.7060204@oracle.com>

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 Alan.Bateman at oracle.com  Fri Feb 27 14:20:41 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 27 Feb 2015 14:20:41 +0000
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <54F070B6.4070204@redhat.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
	<54F070B6.4070204@redhat.com>
Message-ID: <54F07D39.8000406@oracle.com>

On 27/02/2015 13:27, Florian Weimer wrote:
> :
> I'm wondering how you propose to build such JAR files.  Do you think
> library developers will maintain two separate branches, compile one with
> JDK 8, the other one with JDK 9, and then use some (not yet existing?)
> tool to merge the output into a single JAR?

This submitted JEP is good reading and gives an idea how how to compile 
to older JDKs:
   http://openjdk.java.net/jeps/8058150

-Alan.


From paul.sandoz at oracle.com  Fri Feb 27 14:37:37 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 27 Feb 2015 15:37:37 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <54F070B6.4070204@redhat.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>
	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
	<54F070B6.4070204@redhat.com>
Message-ID: <834DA619-4781-469D-ACDF-D1C0A83BEA5F@oracle.com>

On Feb 27, 2015, at 2:27 PM, Florian Weimer <fweimer at redhat.com> wrote:
> On 02/12/2015 09:52 PM, Paul Sandoz wrote:
>> Hi
>> 
>> In connection with the JEP there is also a design document to help the discussion:
>> 
>>  http://cr.openjdk.java.net/~psandoz/jdk9/MultiVersionJar-8u60-9-design.md
>> 
>> We are especially interesting in hearing feedback from library developers, tool/IDE developers, and anyone doing funky stuff with class loading and JAR files.
> 
> I'm wondering how you propose to build such JAR files.  Do you think
> library developers will maintain two separate branches, compile one with
> JDK 8, the other one with JDK 9, and then use some (not yet existing?)
> tool to merge the output into a single JAR?  Is such automated merging
> even possible if the bytecode was compiled with different javac versions?
> 

In the last section of the design document i was trying to anticipate a particular approach, a multiversion project, with examples for compiling and packaging.

That is out of scope of the MVJAR effort itself but still very important and is dependent on getting buy in from tooling such as maven and gradle.


> What about presenting Javadoc in a useful fashion?

A MVJAR should only have one API.

Paul.


From vladimir.x.ivanov at oracle.com  Fri Feb 27 15:01:17 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 27 Feb 2015 18:01:17 +0300
Subject: [9] RFR (XS): 8073644: Assertion in
	LambdaFormEditor.bindArgumentType is too strict
In-Reply-To: <BE60F08B-8C22-4AED-9AEB-195AA4F0E5EC@oracle.com>
References: <54EF6281.3040501@oracle.com>
	<BE60F08B-8C22-4AED-9AEB-195AA4F0E5EC@oracle.com>
Message-ID: <54F086BD.9000601@oracle.com>

Thanks, Paul!

Best regards,
Vladimir Ivanov

On 2/27/15 1:03 PM, Paul Sandoz wrote:
>
> On Feb 26, 2015, at 7:14 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>
>> http://cr.openjdk.java.net/~vlivanov/8073644/webrev.00
>> https://bugs.openjdk.java.net/browse/JDK-8073644
>>
>> After JDK-8069591 [1] which introduced LambdaForm customization, the assert in LambdaFormEditor.bindArgumentType became too strict.
>>
>> The fix is to relax it - compare uncustomized versions. And LambdaFormEditor.lambdaForm is always uncustomized.
>>
>> Testing: java/lang/invoke, nashorn tests
>>
>
> +1
>
> I needed to remind myself of the dual nature of LambdaForm.transformCache :-)
>
> Paul.
>


From fweimer at redhat.com  Fri Feb 27 15:47:30 2015
From: fweimer at redhat.com (Florian Weimer)
Date: Fri, 27 Feb 2015 16:47:30 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <54F07D39.8000406@oracle.com>
References: <20150212204102.BC2B84DB25@eggemoggin.niobe.net>	<553E75B2-C52C-4381-B769-7D3F84089643@oracle.com>
	<54F070B6.4070204@redhat.com> <54F07D39.8000406@oracle.com>
Message-ID: <54F09192.5070104@redhat.com>

On 02/27/2015 03:20 PM, Alan Bateman wrote:
> On 27/02/2015 13:27, Florian Weimer wrote:
>> :
>> I'm wondering how you propose to build such JAR files.  Do you think
>> library developers will maintain two separate branches, compile one with
>> JDK 8, the other one with JDK 9, and then use some (not yet existing?)
>> tool to merge the output into a single JAR?
> 
> This submitted JEP is good reading and gives an idea how how to compile
> to older JDKs:
>   http://openjdk.java.net/jeps/8058150

Maybe I misunderstood the multi-version JAR files proposal, but I
thought that the assumption there is that there are actual *source*
files which use newer features of the platform.

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?

-- 
Florian Weimer / Red Hat Product Security


From daniel.fuchs at oracle.com  Fri Feb 27 16:25:03 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 27 Feb 2015 17:25:03 +0100
Subject: RFR: 8074032: Instant.ofEpochMilli(millis).toEpochMilli() can throw
	arithmetic overflow in toEpochMilli()
Message-ID: <54F09A5F.7070407@oracle.com>

Hi,

Please find below a patch for:

8074032: Instant.ofEpochMilli(millis).toEpochMilli() can
          throw arithmetic overflow in toEpochMilli()

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

The issue is that when converting milliseconds to seconds + nanos
Instant.ofEpochMilli() uses floorDiv and floorMod, as it should.
This means that for negative values of 'millis' then seconds will
be millis/1000 - 1,  and nanos will be positive.

When converting back to epoch millis, if multiplyExact is used
without precaution, then (millis/1000 -1) * 1000 may not fit in
a long. The solution is thus to compute ((millis/1000 -1) +1) * 1000
instead and then add (nanos - 1000) to the result.


Note: this issue is causing some JCK tests that call
LogRecord.setMillis(Long.MIN_VALUE) to fail.

best regards,

-- daniel


From paul.sandoz at oracle.com  Fri Feb 27 16:32:19 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 27 Feb 2015 17:32:19 +0100
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <54DE4FF9.6050609@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>
Message-ID: <67B7F7EA-3B80-458E-9ED3-2C7EAD901C81@oracle.com>

Hi,

On Feb 13, 2015, at 8:26 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> OK, this looks great. Thanks for the updates.
> 
> There is also
> 
>    "in same order" -> "in the same order"
> 
> in the doc for the results() method, as Brian pointed out internally.
> 
> No need for another webrev.
> 

Alas there is :-) I made some updates:

1) Improving the documentation based on feedback from Brian; and

2) added co-mod checking to the replace* methods.

http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev

Paul.



From claes.redestad at oracle.com  Fri Feb 27 16:32:50 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 27 Feb 2015 17:32:50 +0100
Subject: RFR(S): 8073497: Lazy conversion of ZipEntry time
In-Reply-To: <54EF8B7C.3020408@gmail.com>
References: <54E8976B.8050104@oracle.com>	<54E8D34C.7000805@oracle.com>	<54E93AE4.1030301@oracle.com>	<54EA4744.1090703@oracle.com>
	<54EB4A3C.7030308@oracle.com> <54EE6623.5020405@oracle.com>
	<54EF8B7C.3020408@gmail.com>
Message-ID: <54F09C32.2090902@oracle.com>

On 02/26/2015 10:09 PM, Peter Levart wrote:
>
> Hi Claes,
>
> I like the backwards-compatible extended DOS time format idea. If you 
> keep it as one field, you could move the code for conversion from 
> millisecond Java time to/from extended DOS time format to the ZipUtils 
> methods entirely (javaToXdosTime, xdosToJavaTime) to make logic in 
> ZipEntry simpler. I would call the field 'xdostime' then to hint the 
> reader about the format which would be nice if it was described in a 
> javadoc on the field.
>
> Regards, Peter

Something like this, then:

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

Thanks!

/Claes


From scolebourne at joda.org  Fri Feb 27 16:41:31 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 27 Feb 2015 16:41:31 +0000
Subject: RFR: 8074032: Instant.ofEpochMilli(millis).toEpochMilli() can
	throw arithmetic overflow in toEpochMilli()
In-Reply-To: <54F09A5F.7070407@oracle.com>
References: <54F09A5F.7070407@oracle.com>
Message-ID: <CACzrW9BiLwTepFfMDO1nrzok8YkYPo0vgxGcu3MgzD6cZoW=nw@mail.gmail.com>

Looks good to me.
thanks
Stephen

On 27 February 2015 at 16:25, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> Hi,
>
> Please find below a patch for:
>
> 8074032: Instant.ofEpochMilli(millis).toEpochMilli() can
>          throw arithmetic overflow in toEpochMilli()
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8074032/webrev.00/
>
> The issue is that when converting milliseconds to seconds + nanos
> Instant.ofEpochMilli() uses floorDiv and floorMod, as it should.
> This means that for negative values of 'millis' then seconds will
> be millis/1000 - 1,  and nanos will be positive.
>
> When converting back to epoch millis, if multiplyExact is used
> without precaution, then (millis/1000 -1) * 1000 may not fit in
> a long. The solution is thus to compute ((millis/1000 -1) +1) * 1000
> instead and then add (nanos - 1000) to the result.
>
>
> Note: this issue is causing some JCK tests that call
> LogRecord.setMillis(Long.MIN_VALUE) to fail.
>
> best regards,
>
> -- daniel


From Roger.Riggs at Oracle.com  Fri Feb 27 16:42:18 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 27 Feb 2015 11:42:18 -0500
Subject: RFR: 8074032: Instant.ofEpochMilli(millis).toEpochMilli() can
	throw arithmetic overflow in toEpochMilli()
In-Reply-To: <54F09A5F.7070407@oracle.com>
References: <54F09A5F.7070407@oracle.com>
Message-ID: <54F09E6A.7060409@Oracle.com>

Hi Daniel,

Looks ok.

Roger

On 2/27/2015 11:25 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a patch for:
>
> 8074032: Instant.ofEpochMilli(millis).toEpochMilli() can
>          throw arithmetic overflow in toEpochMilli()
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8074032/webrev.00/
>
> The issue is that when converting milliseconds to seconds + nanos
> Instant.ofEpochMilli() uses floorDiv and floorMod, as it should.
> This means that for negative values of 'millis' then seconds will
> be millis/1000 - 1,  and nanos will be positive.
>
> When converting back to epoch millis, if multiplyExact is used
> without precaution, then (millis/1000 -1) * 1000 may not fit in
> a long. The solution is thus to compute ((millis/1000 -1) +1) * 1000
> instead and then add (nanos - 1000) to the result.
>
>
> Note: this issue is causing some JCK tests that call
> LogRecord.setMillis(Long.MIN_VALUE) to fail.
>
> best regards,
>
> -- daniel



From Roger.Riggs at Oracle.com  Fri Feb 27 16:57:13 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 27 Feb 2015 11:57:13 -0500
Subject: RFR 9:  8074045 Remove deprecated Runtime.getLocalizedInputStream
	and getLocalizedOutputStream methods
Message-ID: <54F0A1E9.9070605@Oracle.com>

Please review this change to remove deprecated methods:
   java.lang.Runtime.getLocalizedInputStream(InputStream in)
   java.lang.Runtime.getLocalizedOutputStream(OutputStream out)

If you are aware of any uses of these methods please comment; I could 
not find any.

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-remove-localized-stream-8074045/
Issue:
    https://bugs.openjdk.java.net/browse/JDK-8074045

Thanks, Roger



From xueming.shen at oracle.com  Fri Feb 27 17:00:47 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 27 Feb 2015 09:00:47 -0800
Subject: RFR(S): 8073497: Lazy conversion of ZipEntry time
In-Reply-To: <54F09C32.2090902@oracle.com>
References: <54E8976B.8050104@oracle.com>	<54E8D34C.7000805@oracle.com>	<54E93AE4.1030301@oracle.com>	<54EA4744.1090703@oracle.com>
	<54EB4A3C.7030308@oracle.com> <54EE6623.5020405@oracle.com>
	<54EF8B7C.3020408@gmail.com> <54F09C32.2090902@oracle.com>
Message-ID: <54F0A2BF.1010001@oracle.com>

Any reason setlastModifiedTime() uses javaToDosTime()? maybe the original
pair should be private?

On 02/27/2015 08:32 AM, Claes Redestad wrote:
> On 02/26/2015 10:09 PM, Peter Levart wrote:
>>
>> Hi Claes,
>>
>> I like the backwards-compatible extended DOS time format idea. If you keep it as one field, you could move the code for conversion from millisecond Java time to/from extended DOS time format to the ZipUtils methods entirely (javaToXdosTime, xdosToJavaTime) to make logic in ZipEntry simpler. I would call the field 'xdostime' then to hint the reader about the format which would be nice if it was described in a javadoc on the field.
>>
>> Regards, Peter
>
> Something like this, then:
>
> http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.5
>
> Thanks!
>
> /Claes



From lance.andersen at oracle.com  Fri Feb 27 17:05:09 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 27 Feb 2015 12:05:09 -0500
Subject: RFR 9: 8074045 Remove deprecated Runtime.getLocalizedInputStream
	and getLocalizedOutputStream methods
In-Reply-To: <54F0A1E9.9070605@Oracle.com>
References: <54F0A1E9.9070605@Oracle.com>
Message-ID: <F2941890-EFFA-4E33-835F-F4DE867776E3@oracle.com>

Hi Roger,

Looks fine based on the various discussions about these methods


On Feb 27, 2015, at 11:57 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Please review this change to remove deprecated methods:
>  java.lang.Runtime.getLocalizedInputStream(InputStream in)
>  java.lang.Runtime.getLocalizedOutputStream(OutputStream out)
> 
> If you are aware of any uses of these methods please comment; I could not find any.
> 
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-remove-localized-stream-8074045/
> Issue:
>   https://bugs.openjdk.java.net/browse/JDK-8074045
> 
> Thanks, Roger
> 



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  Fri Feb 27 17:16:20 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 27 Feb 2015 18:16:20 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <54F09192.5070104@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>
Message-ID: <493F2892-E8A4-4547-A68C-EF7E1E61BAB9@oracle.com>

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?

Hypothetical project layout:

  src/main/java
  src/main/resources
  src/test/java
  src/test/resources
  src/main-8/java
  src/main-8/resources
  src/test-8/java
  src/test-8/resources
  src/main-9/java
  src/main-9/resources
  src/test-9/java
  src/test-9/resources

(If this were a maven-kind of project there would be one pom.xml, one version and one set of dependencies, and one (MV) JAR produced when packaging.)
 
I would anticipate most of the source would reside under src/main/java then there would be "overriding" source in the versioned areas for classes that use replace usage of say internal JDK features with public JDK features. 

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	
  }

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).

Paul.


From chris.hegarty at oracle.com  Fri Feb 27 18:08:51 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 27 Feb 2015 18:08:51 +0000
Subject: j.u.Arrays setAll and parallelSetAll subrange note
In-Reply-To: <54EFD0A1.8070409@oracle.com>
References: <ACD70EB0-6A49-4DA9-80CA-C8B68BCB2736@oracle.com>
	<54EFD0A1.8070409@oracle.com>
Message-ID: <4BA4A85D-1879-44E3-B515-52A45EBD4E23@oracle.com>

On 27/02/15 02:04, Stuart Marks wrote:
> On 2/19/15 9:33 AM, Chris Hegarty wrote:
>> It came up recently that java.util.Arrays was missing subrange
>> overloads for setAll and parallelSetAll. These methods can be easily
>> written with IntStream.range. Rather than adding eight new methods for
>> this, it makes sense to point developers to IntStream.range. It seems
>> reasonable to add a small note to these methods, promoting the use of
>> IntStream. If someone is hunting around for a subrange setAll, then
>> they will inevitable end up seeing this note.
>> 
>> http://cr.openjdk.java.net/~chegar/setAllNotes/webrev.00/webrev/
> 
> Hi Chris,
> 
> Sorry I missed this -- it got buried in the usual avalanche of
> core-libs-dev email. :-)
> 
> Overall it seems reasonable, if a bit repetitive, but you've already
> done the work to customize the example for each different case. In any
> case, looks fine to me.
> 
> Are you going to file a bug for this and push it in? If so, consider
> this to be the review.

Thanks for the review Stuart. Pushed
  http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d2a4b295498e

-Chris.

> s'marks
> 


From xueming.shen at oracle.com  Fri Feb 27 18:18:10 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 27 Feb 2015 10:18:10 -0800
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <67B7F7EA-3B80-458E-9ED3-2C7EAD901C81@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>
Message-ID: <54F0B4E2.5060003@oracle.com>

Hi Paul,

1133      * @param  replacer
1134      *         The function to be applied to the match result of this matcher
1135      *         that returns a replacement string.
1136      *
1137      *<p>  The function should not modify this matcher's state during
1138      *         replacement.  This method will, on a best-effort basis, throw a
1139      *         {@link java.util.ConcurrentModificationException} if such
1140      *         modification is detected.
1141      *
1142      *<p>  The state of the match result is guaranteed to be constant
1143      *         only for the duration of the function call and only if the
1144      *         function does not modify this matcher's state.


1151      * @throws ConcurrentModificationException if it is detected, on a
1152      *         best-effort basis, that the replacer function modified this
1153      *         matcher's state


Just wonder from API point of view, in theory the replacer should not be able to modify
this matcher's state via a MatchResult, it is the side-effect of our implementation detail
that happens to return "this matcher" as a MatchResult. For example, it should be possible
to simply return a wrapper MatchResult on top of this matcher to only expose the read-only
MatchResult methods, so the "replacer" will never be possible to modify the "matcher".

The modCount might still be good to have to catch the possible concurrent modification
of the "matcher" while iterating, though the existing implementation does not do that for
the original methods

The "results" currently returns "heavy" clone of this matcher, it might be ideal
to have a light weight MatchResult implementation with less fields and especially
to a single "text.toString()", this might be helpful when the "text" is huge and it
is not a "String" object.

-Sherman

On 02/27/2015 08:32 AM, Paul Sandoz wrote:
> Hi,
>
> On Feb 13, 2015, at 8:26 PM, Stuart Marks<stuart.marks at oracle.com>  wrote:
>> OK, this looks great. Thanks for the updates.
>>
>> There is also
>>
>>     "in same order" ->  "in the same order"
>>
>> in the doc for the results() method, as Brian pointed out internally.
>>
>> No need for another webrev.
>>
> Alas there is :-) I made some updates:
>
> 1) Improving the documentation based on feedback from Brian; and
>
> 2) added co-mod checking to the replace* methods.
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev
>
> Paul.
>



From Mohammad.Rezaei at gs.com  Fri Feb 27 18:23:13 2015
From: Mohammad.Rezaei at gs.com (Rezaei, Mohammad A.)
Date: Fri, 27 Feb 2015 13:23:13 -0500
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: <6882C9A35DFB9B4FA2779F7BF5B9757D2070034A6A@GSCMAMP06EX.firmwide.corp.gs.com>

Why do you expect the new classes in the JDK not to be part of the API? 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

>-----Original Message-----
>From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf
>Of Paul Sandoz
>Sent: Friday, February 27, 2015 12:16 PM
>Cc: core-libs-dev at openjdk.java.net
>Subject: Re: JEP 238: Multi-Version JAR Files
>
>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?
>
>Hypothetical project layout:
>
>  src/main/java
>  src/main/resources
>  src/test/java
>  src/test/resources
>  src/main-8/java
>  src/main-8/resources
>  src/test-8/java
>  src/test-8/resources
>  src/main-9/java
>  src/main-9/resources
>  src/test-9/java
>  src/test-9/resources
>
>(If this were a maven-kind of project there would be one pom.xml, one version
>and one set of dependencies, and one (MV) JAR produced when packaging.)
>
>I would anticipate most of the source would reside under src/main/java then
>there would be "overriding" source in the versioned areas for classes that use
>replace usage of say internal JDK features with public JDK features.
>
>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
>  }
>
>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).
>
>Paul.


From paul.sandoz at oracle.com  Fri Feb 27 18:34:52 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 27 Feb 2015 19:34:52 +0100
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <54F0B4E2.5060003@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>
Message-ID: <959E1D9F-4445-42B2-94E8-2E8F2106932F@oracle.com>


On Feb 27, 2015, at 7:18 PM, Xueming Shen <xueming.shen at oracle.com> wrote:

> Hi Paul,
> 
> 1133      * @param  replacer
> 1134      *         The function to be applied to the match result of this matcher
> 1135      *         that returns a replacement string.
> 1136      *
> 1137      *<p>  The function should not modify this matcher's state during
> 1138      *         replacement.  This method will, on a best-effort basis, throw a
> 1139      *         {@link java.util.ConcurrentModificationException} if such
> 1140      *         modification is detected.
> 1141      *
> 1142      *<p>  The state of the match result is guaranteed to be constant
> 1143      *         only for the duration of the function call and only if the
> 1144      *         function does not modify this matcher's state.
> 
> 
> 1151      * @throws ConcurrentModificationException if it is detected, on a
> 1152      *         best-effort basis, that the replacer function modified this
> 1153      *         matcher's state
> 
> 
> Just wonder from API point of view, in theory the replacer should not be able to modify
> this matcher's state via a MatchResult, it is the side-effect of our implementation detail
> that happens to return "this matcher" as a MatchResult. For example, it should be possible
> to simply return a wrapper MatchResult on top of this matcher to only expose the read-only
> MatchResult methods, so the "replacer" will never be possible to modify the "matcher".
> 

It's not really about casting a MatchResult to Matcher it's about the function capturing the Matcher instance and operating on it.


> The modCount might still be good to have to catch the possible concurrent modification
> of the "matcher" while iterating, though the existing implementation does not do that for
> the original methods
> 
> The "results" currently returns "heavy" clone of this matcher, it might be ideal
> to have a light weight MatchResult implementation with less fields and especially
> to a single "text.toString()", this might be helpful when the "text" is huge and it
> is not a "String" object.

Can you suggest, via code, such a lighter weight immutable implementation?

If there was a lighter weight alternative we could apply that to replace* functions as well.

Paul.


From martin.desruisseaux at geomatys.fr  Fri Feb 27 18:37:06 2015
From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux)
Date: Fri, 27 Feb 2015 19:37:06 +0100
Subject: JEP 238: Multi-Version JAR Files
In-Reply-To: <54F09192.5070104@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>
Message-ID: <54F0B952.4040406@geomatys.fr>

Le 27/02/15 16:47, Florian Weimer a ?crit :
> Maybe I misunderstood the multi-version JAR files proposal, but I
> thought that the assumption there is that there are actual *source*
> files which use newer features of the platform.
>
> 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.

Some projects do, while admittedly maybe only a minority. For example
Apache Spatial Information System (SIS) has JDK6, JDK7 and JDK8
branches. Development is done on JDK8, then ported down to JDK6, which
is the target JDK platform for current releases [1].

    Martin

[1] http://sis.apache.org/branches.html



From xueming.shen at oracle.com  Fri Feb 27 18:48:17 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 27 Feb 2015 10:48:17 -0800
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <959E1D9F-4445-42B2-94E8-2E8F2106932F@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>
Message-ID: <54F0BBF1.2000901@oracle.com>

On 02/27/2015 10:34 AM, Paul Sandoz wrote:
> On Feb 27, 2015, at 7:18 PM, Xueming Shen<xueming.shen at oracle.com>  wrote:
>
>> Hi Paul,
>>
>> 1133      * @param  replacer
>> 1134      *         The function to be applied to the match result of this matcher
>> 1135      *         that returns a replacement string.
>> 1136      *
>> 1137      *<p>   The function should not modify this matcher's state during
>> 1138      *         replacement.  This method will, on a best-effort basis, throw a
>> 1139      *         {@link java.util.ConcurrentModificationException} if such
>> 1140      *         modification is detected.
>> 1141      *
>> 1142      *<p>   The state of the match result is guaranteed to be constant
>> 1143      *         only for the duration of the function call and only if the
>> 1144      *         function does not modify this matcher's state.
>>
>>
>> 1151      * @throws ConcurrentModificationException if it is detected, on a
>> 1152      *         best-effort basis, that the replacer function modified this
>> 1153      *         matcher's state
>>
>>
>> Just wonder from API point of view, in theory the replacer should not be able to modify
>> this matcher's state via a MatchResult, it is the side-effect of our implementation detail
>> that happens to return "this matcher" as a MatchResult. For example, it should be possible
>> to simply return a wrapper MatchResult on top of this matcher to only expose the read-only
>> MatchResult methods, so the "replacer" will never be possible to modify the "matcher".
>>
> It's not really about casting a MatchResult to Matcher it's about the function capturing the Matcher instance and operating on it.
>

The "replacer" does not have an explicit reference to the matcher... and
from the implementation it is not really about the "replacer" to change the
state of the matcher, but the matcher's state gets changed during "replacing"?
it might be more clear/obvious to move those warning notes up to the method
doc as "the matcher state should not be updated/changed during the replaceAll
is invoked..."?

-sherman


From paul.sandoz at oracle.com  Fri Feb 27 18:55:35 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 27 Feb 2015 19:55:35 +0100
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <54F0BBF1.2000901@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>
Message-ID: <9BBCF56A-13DF-46E7-A645-36F04FD3881C@oracle.com>


On Feb 27, 2015, at 7:48 PM, Xueming Shen <xueming.shen at oracle.com> wrote:

> On 02/27/2015 10:34 AM, Paul Sandoz wrote:
>> On Feb 27, 2015, at 7:18 PM, Xueming Shen<xueming.shen at oracle.com>  wrote:
>> 
>>> Hi Paul,
>>> 
>>> 1133      * @param  replacer
>>> 1134      *         The function to be applied to the match result of this matcher
>>> 1135      *         that returns a replacement string.
>>> 1136      *
>>> 1137      *<p>   The function should not modify this matcher's state during
>>> 1138      *         replacement.  This method will, on a best-effort basis, throw a
>>> 1139      *         {@link java.util.ConcurrentModificationException} if such
>>> 1140      *         modification is detected.
>>> 1141      *
>>> 1142      *<p>   The state of the match result is guaranteed to be constant
>>> 1143      *         only for the duration of the function call and only if the
>>> 1144      *         function does not modify this matcher's state.
>>> 
>>> 
>>> 1151      * @throws ConcurrentModificationException if it is detected, on a
>>> 1152      *         best-effort basis, that the replacer function modified this
>>> 1153      *         matcher's state
>>> 
>>> 
>>> Just wonder from API point of view, in theory the replacer should not be able to modify
>>> this matcher's state via a MatchResult, it is the side-effect of our implementation detail
>>> that happens to return "this matcher" as a MatchResult. For example, it should be possible
>>> to simply return a wrapper MatchResult on top of this matcher to only expose the read-only
>>> MatchResult methods, so the "replacer" will never be possible to modify the "matcher".
>>> 
>> It's not really about casting a MatchResult to Matcher it's about the function capturing the Matcher instance and operating on it.
>> 
> 
> The "replacer" does not have an explicit reference to the matcher...

Correct, just like a Consumer does not have an Iterable with Iterable.forEach.


> and
> from the implementation it is not really about the "replacer" to change the
> state of the matcher, but the matcher's state gets changed during "replacing"?

It's both, A function could do something silly, such as:

 Matcher m = ...
 m.replaceAll(mr -> { 
    m.find(); // bad
    // mr state is now messed up
    return mr.group();
 });


 List l = ...
 m.replaceAll(mr -> { 
  l.add(mr); // bad, mr escapes
  return mr.group();
 });


> it might be more clear/obvious to move those warning notes up to the method
> doc as "the matcher state should not be updated/changed during the replaceAll
> is invoked..."?
> 

Moving them up would be clearer, i will do that.

What about a light wright immutable MatchResult? is that possible?

Paul.



From xueming.shen at oracle.com  Fri Feb 27 19:21:15 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 27 Feb 2015 11:21:15 -0800
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <9BBCF56A-13DF-46E7-A645-36F04FD3881C@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>
Message-ID: <54F0C3AB.4020203@oracle.com>

On 02/27/2015 10:55 AM, Paul Sandoz wrote:
>
> What about a light wright immutable MatchResult? is that possible?
>

Should be possible. I can give it try.



From xueming.shen at oracle.com  Fri Feb 27 20:40:35 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 27 Feb 2015 12:40:35 -0800
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <54F0C3AB.4020203@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>
Message-ID: <54F0D643.5060005@oracle.com>

On 02/27/2015 11:21 AM, Xueming Shen wrote:
> On 02/27/2015 10:55 AM, Paul Sandoz wrote:
>>
>> What about a light wright immutable MatchResult? is that possible?
>>
>
> Should be possible. I can give it try.
>

too repetitive?

http://cr.openjdk.java.net/~sherman/regex.stream/src/java.base/share/classes/java/util/regex/Matcher.java.sdiff.html


From Roger.Riggs at Oracle.com  Fri Feb 27 23:06:04 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 27 Feb 2015 18:06:04 -0500
Subject: RFR 10: 8074045 Remove deprecated Runtime.getLocalizedInputStream
	and getLocalizedOutputStream methods
In-Reply-To: <54F0A1E9.9070605@Oracle.com>
References: <54F0A1E9.9070605@Oracle.com>
Message-ID: <54F0F85C.9000404@Oracle.com>

Hi,

It seems in my eagerness to expedite this, I neglected to follow the 
established
protocol for removing methods.

The decision and announcement to remove methods will be made as part of 
the JDK 9
updates but the actual removal will be in a later release (JDK 10).

My apologies for the confusion, Roger

On 2/27/2015 11:57 AM, Roger Riggs wrote:
> Please review this change to remove deprecated methods:
>   java.lang.Runtime.getLocalizedInputStream(InputStream in)
>   java.lang.Runtime.getLocalizedOutputStream(OutputStream out)
>
> If you are aware of any uses of these methods please comment; I could 
> not find any.
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-remove-localized-stream-8074045/ 
>
> Issue:
>    https://bugs.openjdk.java.net/browse/JDK-8074045
>
> Thanks, Roger
>



From stuart.marks at oracle.com  Fri Feb 27 23:19:57 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 27 Feb 2015 15:19:57 -0800
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <54F0D643.5060005@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>
Message-ID: <54F0FB9D.4000508@oracle.com>

On 2/27/15 12:40 PM, Xueming Shen wrote:
> On 02/27/2015 11:21 AM, Xueming Shen wrote:
>> On 02/27/2015 10:55 AM, Paul Sandoz wrote:
>>>
>>> What about a light wright immutable MatchResult? is that possible?
>>
>> Should be possible. I can give it try.
>
> too repetitive?
>
> http://cr.openjdk.java.net/~sherman/regex.stream/src/java.base/share/classes/java/util/regex/Matcher.java.sdiff.html

Not too bad. I know I was surprised to see that Matcher itself is the only 
MatchResult implementation, and that there wasn't a lightweight immutable 
MatchResult separate from Matcher. So I'm glad to see this added.

(One thing to think about, not part of this particular change, is whether named 
matching groups could be added to or extend MatchResult. Doing that would change 
the implementation of the lightweight MatchResult. See JDK-8065554.)

A few comments on the implementation.

At line 302, end(group) calls the groupCount() method instead of returning the 
captured groupCount local.

The MatchResult anonymous class unavoidably captures a reference to 'this', 
which is the enclosing Matcher instance. I don't think it needs that, but it 
does enable methods like groupCount() on the enclosing class to be called 
inadvertently.

For these reasons the lightweight MatchResult might better be refactored to be a 
(named) static nested class (or even a top-level class). You'll have to write a 
constructor and declare fields instead of capturing locals though, but I think 
this makes it a bit more clear as to what's actually going on. For example, you 
could make all the fields final to make it clear that the object really is 
immutable.

s'marks


From claes.redestad at oracle.com  Sat Feb 28 01:10:17 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 28 Feb 2015 02:10:17 +0100
Subject: RFR(S): 8073497: Lazy conversion of ZipEntry time
In-Reply-To: <54F0A2BF.1010001@oracle.com>
References: <54E8976B.8050104@oracle.com>	<54E8D34C.7000805@oracle.com>	<54E93AE4.1030301@oracle.com>	<54EA4744.1090703@oracle.com>
	<54EB4A3C.7030308@oracle.com> <54EE6623.5020405@oracle.com>
	<54EF8B7C.3020408@gmail.com> <54F09C32.2090902@oracle.com>
	<54F0A2BF.1010001@oracle.com>
Message-ID: <54F11579.8040402@oracle.com>


On 2015-02-27 18:00, Xueming Shen wrote:
> Any reason setlastModifiedTime() uses javaToDosTime()? maybe the original
> pair should be private?

Right, hiding the now internal methods and making the calls consistent is a
better practice here.

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

/Claes




From jonathan.gibbons at oracle.com  Sat Feb 28 03:32:14 2015
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 27 Feb 2015 19:32:14 -0800
Subject: RFR: JDK-8072842 Add support for building native JTReg tests
In-Reply-To: <D93A391C-0FC1-4328-BD34-5D2D804E4FEC@oracle.com>
References: <54DA146D.3060904@oracle.com>
	<D93A391C-0FC1-4328-BD34-5D2D804E4FEC@oracle.com>
Message-ID: <54F136BE.9070304@oracle.com>


On 02/10/2015 07:10 AM, Staffan Larsen wrote:
> To clarify: The restriction in jtreg is that all tests are loaded in separate class loaders (when running in samevm mode). A native library can only be loaded in one class loader at a time. So if two tests tries to load the same library we get errors. It would be possible to change this if samevm mode is removed from jtreg.
>
> /Staffan

Staffan,

The restriction to use separate class loaders exists in agentvm mode as 
well. I don't think it would be advisable to change this, partly because 
different tests may define the same class, and partly because you want 
to be able to get rid of classes that are no longer required.

-- Jon


From xueming.shen at oracle.com  Sat Feb 28 03:40:46 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 27 Feb 2015 19:40:46 -0800
Subject: RFR 8071479: Stream and lamdification improvements to
	j.u.regex.Matcher
In-Reply-To: <54F0FB9D.4000508@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>
Message-ID: <54F138BE.10503@oracle.com>

On 2/27/15 3:19 PM, Stuart Marks wrote:
> On 2/27/15 12:40 PM, Xueming Shen wrote:
>> On 02/27/2015 11:21 AM, Xueming Shen wrote:
>>> On 02/27/2015 10:55 AM, Paul Sandoz wrote:
>>>>
>>>> What about a light wright immutable MatchResult? is that possible?
>>>
>>> Should be possible. I can give it try.
>>
>> too repetitive?
>>
>> http://cr.openjdk.java.net/~sherman/regex.stream/src/java.base/share/classes/java/util/regex/Matcher.java.sdiff.html 
>>
>
> Not too bad. I know I was surprised to see that Matcher itself is the 
> only MatchResult implementation, and that there wasn't a lightweight 
> immutable MatchResult separate from Matcher. So I'm glad to see this 
> added.
>
> (One thing to think about, not part of this particular change, is 
> whether named matching groups could be added to or extend MatchResult. 
> Doing that would change the implementation of the lightweight 
> MatchResult. See JDK-8065554.)
>
> A few comments on the implementation.
>
> At line 302, end(group) calls the groupCount() method instead of 
> returning the captured groupCount local.
>
> The MatchResult anonymous class unavoidably captures a reference to 
> 'this', which is the enclosing Matcher instance. I don't think it 
> needs that, but it does enable methods like groupCount() on the 
> enclosing class to be called inadvertently.
>
> For these reasons the lightweight MatchResult might better be 
> refactored to be a (named) static nested class (or even a top-level 
> class). You'll have to write a constructor and declare fields instead 
> of capturing locals though, but I think this makes it a bit more clear 
> as to what's actually going on. For example, you could make all the 
> fields final to make it clear that the object really is immutable.
>
> s'marks

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

-Sherman


From xueming.shen at oracle.com  Sat Feb 28 07:28:44 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 27 Feb 2015 23:28:44 -0800
Subject: RFR(S): 8073497: Lazy conversion of ZipEntry time
In-Reply-To: <54F11579.8040402@oracle.com>
References: <54E8976B.8050104@oracle.com>	<54E8D34C.7000805@oracle.com>	<54E93AE4.1030301@oracle.com>	<54EA4744.1090703@oracle.com>
	<54EB4A3C.7030308@oracle.com> <54EE6623.5020405@oracle.com>
	<54EF8B7C.3020408@gmail.com> <54F09C32.2090902@oracle.com>
	<54F0A2BF.1010001@oracle.com> <54F11579.8040402@oracle.com>
Message-ID: <54F16E2C.1000306@oracle.com>

looks good.

-Sherman

On 2/27/2015 5:10 PM, Claes Redestad wrote:
>
> On 2015-02-27 18:00, Xueming Shen wrote:
>> Any reason setlastModifiedTime() uses javaToDosTime()? maybe the 
>> original
>> pair should be private?
>
> Right, hiding the now internal methods and making the calls consistent 
> is a
> better practice here.
>
> http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6/
>
> /Claes
>
>



From peter.levart at gmail.com  Sat Feb 28 09:53:25 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 28 Feb 2015 10:53:25 +0100
Subject: RFR(S): 8073497: Lazy conversion of ZipEntry time
In-Reply-To: <54F11579.8040402@oracle.com>
References: <54E8976B.8050104@oracle.com>	<54E8D34C.7000805@oracle.com>	<54E93AE4.1030301@oracle.com>	<54EA4744.1090703@oracle.com>
	<54EB4A3C.7030308@oracle.com> <54EE6623.5020405@oracle.com>
	<54EF8B7C.3020408@gmail.com> <54F09C32.2090902@oracle.com>
	<54F0A2BF.1010001@oracle.com> <54F11579.8040402@oracle.com>
Message-ID: <54F19015.2080407@gmail.com>


On 02/28/2015 02:10 AM, Claes Redestad wrote:
>
> On 2015-02-27 18:00, Xueming Shen wrote:
>> Any reason setlastModifiedTime() uses javaToDosTime()? maybe the 
>> original
>> pair should be private?
>
> Right, hiding the now internal methods and making the calls consistent 
> is a
> better practice here.
>
> http://cr.openjdk.java.net/~redestad/jdk9/8073497/webrev.6/
>
> /Claes
>
>

Hi Claes,

I think this is OK.

Regards, Peter