<0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com>
Message-ID: <50BEE556.6090602@oracle.com>
Hi Mike,
In multiple places:
+ * xxx ...
Should that be tag? Is it actually needed? (my javadoc is a bit rusty).
Aside: I don't realise you could {@inheritDoc) as a simple text
insertion mechanism.
Just to be clear, the null-handling statements are intended to be
normative and apply to anyone who might provide an implementation of
theses classes - right?
Thanks,
David
On 5/12/2012 3:47 PM, Mike Duigou wrote:
> Hello all;
>
> I have updated the proposed patch. The changes primarily add class and method documentation regarding handling of null for the primitive specializations.
>
> http://cr.openjdk.java.net/~mduigou/8004015/1/webrev/
> http://cr.openjdk.java.net/~mduigou/8004015/1/specdiff/java/util/function/package-summary.html
>
> I've also reformatted the source for the default methods.
>
> Mike
>
>
> On Nov 26 2012, at 18:12 , Mike Duigou wrote:
>
>> Hello all;
>>
>> In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy.
>>
>> Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined.
>>
>> The patch to add parent interfaces and default methods can be found here:
>>
>> http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/
>> http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html
>>
>> Mike
>>
>> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e80176a697
>
From Lance.Andersen at oracle.com Wed Dec 5 11:49:42 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Wed, 5 Dec 2012 06:49:42 -0500
Subject: Request for Review : CR#8004015 : [2nd pass] Add interface
extends and defaults for basic functional interfaces
In-Reply-To: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com>
References:
<0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com>
Message-ID: <965DB95B-8F79-4025-B4D9-94C5CCF12403@oracle.com>
I am still wondering if we need some sort of javadoc tag for default implementations so that it will stand out better and allow us to be consistent with how we specify this across Java SE and other APIs that leverage default methods.
Has any thought been given to this?
Best
Lance
On Dec 5, 2012, at 12:47 AM, Mike Duigou wrote:
> Hello all;
>
> I have updated the proposed patch. The changes primarily add class and method documentation regarding handling of null for the primitive specializations.
>
> http://cr.openjdk.java.net/~mduigou/8004015/1/webrev/
> http://cr.openjdk.java.net/~mduigou/8004015/1/specdiff/java/util/function/package-summary.html
>
> I've also reformatted the source for the default methods.
>
> Mike
>
>
> On Nov 26 2012, at 18:12 , Mike Duigou wrote:
>
>> Hello all;
>>
>> In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy.
>>
>> Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined.
>>
>> The patch to add parent interfaces and default methods can be found here:
>>
>> http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/
>> http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html
>>
>> Mike
>>
>> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e80176a697
>
-------------- next part --------------
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com
From david.holmes at oracle.com Wed Dec 5 11:59:22 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 05 Dec 2012 21:59:22 +1000
Subject: Proposal: Fully Concurrent ClassLoading
Message-ID: <50BF371A.1060604@oracle.com>
Java 7 introduced support for parallel classloading by adding to each
class loader a ConcurrentHashMap, referenced through a new field,
parallelLockMap. This contains a mapping from class names to Objects to
use as a classloading lock for that class name. This scheme has a number
of inefficiencies. To address this we propose for Java 8 the notion of a
fully concurrent classloader ...
This is a fairly simple proposal that I've written up as a blog entry:
https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent
Please discuss this proposal here.
Thanks,
David Holmes
From alan.bateman at oracle.com Wed Dec 5 12:55:51 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 05 Dec 2012 12:55:51 +0000
Subject: hg: jdk8/tl/jdk: 8004491: Build breakage on Linux due to 8004188
Message-ID: <20121205125631.21EC047E25@hg.openjdk.java.net>
Changeset: b54a5b7d2e65
Author: alanb
Date: 2012-12-05 12:20 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b54a5b7d2e65
8004491: Build breakage on Linux due to 8004188
Reviewed-by: chegar, erikj
! makefiles/CopyFiles.gmk
From Alan.Bateman at oracle.com Wed Dec 5 14:45:16 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 05 Dec 2012 14:45:16 +0000
Subject: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser
factories (7169894: JAXP Plugability Layer: using service loader)
In-Reply-To: <50BE1CD7.3040104@oracle.com>
References: <50BCF7CD.1020308@oracle.com> <50BE007A.4090102@oracle.com>
<50BE0BD3.9060709@oracle.com> <50BE1CD7.3040104@oracle.com>
Message-ID: <50BF5DFC.4060009@oracle.com>
On 04/12/2012 15:55, Daniel Fuchs wrote:
>
> So that would be the wording:
>
> * Uses the service-provider loading facilities, defined by the
> * {@link java.util.ServiceLoader} class, to attempt to locate
> * and load an implementation of the service. If there are
> * providers other than the implementation specific default
> * located, then the first provider that is
> * not the default is instantiated and returned; Otherwise
> * the default implementation is returned if it is on the
> * classpath or installed as an extension.
>
> This however suggests that in JDK 8 the default implementation
> *needs* to be put on the classpath or installed as an extension.
> But is that right?
> Wouldn't that be required only when running with a profile in
> which the default implementation is not present by default?
>
> Maybe we need to find yet a better wording.
>
> -- daniel
It might be better to just leave it as "Otherwise the default
implementation is returned".
-Alan
From daniel.fuchs at oracle.com Wed Dec 5 14:56:00 2012
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 05 Dec 2012 15:56:00 +0100
Subject: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser
factories (7169894: JAXP Plugability Layer: using service loader)
In-Reply-To: <50BF5DFC.4060009@oracle.com>
References: <50BCF7CD.1020308@oracle.com> <50BE007A.4090102@oracle.com>
<50BE0BD3.9060709@oracle.com> <50BE1CD7.3040104@oracle.com>
<50BF5DFC.4060009@oracle.com>
Message-ID: <50BF6080.7020500@oracle.com>
On 12/5/12 3:45 PM, Alan Bateman wrote:
> On 04/12/2012 15:55, Daniel Fuchs wrote:
>>
>> So that would be the wording:
>>
>> * Uses the service-provider loading facilities, defined by the
>> * {@link java.util.ServiceLoader} class, to attempt to locate
>> * and load an implementation of the service. If there are
>> * providers other than the implementation specific default
>> * located, then the first provider that is
>> * not the default is instantiated and returned; Otherwise
>> * the default implementation is returned if it is on the
>> * classpath or installed as an extension.
>>
>> This however suggests that in JDK 8 the default implementation
>> *needs* to be put on the classpath or installed as an extension.
>> But is that right?
>> Wouldn't that be required only when running with a profile in
>> which the default implementation is not present by default?
>>
>> Maybe we need to find yet a better wording.
>>
>> -- daniel
> It might be better to just leave it as "Otherwise the default
> implementation is returned".
Or maybe:
"Otherwise, the default implementation, if present, is returned" ?
I think the original intent was to make provision for the case where
the implementation module would not be installed....
-- daniel
>
> -Alan
From Alan.Bateman at oracle.com Wed Dec 5 15:44:08 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 05 Dec 2012 15:44:08 +0000
Subject: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser
factories (7169894: JAXP Plugability Layer: using service loader)
In-Reply-To: <50BF6080.7020500@oracle.com>
References: <50BCF7CD.1020308@oracle.com> <50BE007A.4090102@oracle.com>
<50BE0BD3.9060709@oracle.com> <50BE1CD7.3040104@oracle.com>
<50BF5DFC.4060009@oracle.com> <50BF6080.7020500@oracle.com>
Message-ID: <50BF6BC8.5000205@oracle.com>
On 05/12/2012 14:56, Daniel Fuchs wrote:
>
> Or maybe:
>
> "Otherwise, the default implementation, if present, is returned" ?
>
> I think the original intent was to make provision for the case where
> the implementation module would not be installed....
That is longer term intent, meaning when we go do modules. So your
proposal seems good to me.
-Alan
From Alan.Bateman at oracle.com Wed Dec 5 15:57:15 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 05 Dec 2012 15:57:15 +0000
Subject: 8003562: Provide a command-line tool to find static dependencies
In-Reply-To: <50BE59E1.6010008@oracle.com>
References: <50B54A2C.1040907@oracle.com> <50BE59E1.6010008@oracle.com>
Message-ID: <50BF6EDB.6090603@oracle.com>
On 04/12/2012 20:15, Mandy Chung wrote:
> Alan - thanks for the feedback. I have made several changes to the
> jdeps tool. Here is the new webrev at:
>
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8003562/langtools-webrev.01/
>
> I'll send out a formal code review request once I add the new unit tests.
I like the name of the tool, and I think the new proposed options looks
much better.
The only option that I suspect might confuse people is -d, I'm not sure
that this is really needed.
A minor observation but I wonder if -v/--verbose should be something
else. The sub-options are good, it's just that -v is really is
selecting the level that the dependencies are printed (and -v:summary is
less verbose than the default).
Otherwise I think this will be really useful to have.
-Alan,
From daniel.fuchs at oracle.com Wed Dec 5 16:17:54 2012
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 05 Dec 2012 17:17:54 +0100
Subject: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser
factories (7169894: JAXP Plugability Layer: using service loader)
In-Reply-To: <50BE007A.4090102@oracle.com>
References: <50BCF7CD.1020308@oracle.com> <50BE007A.4090102@oracle.com>
Message-ID: <50BF73B2.5000102@oracle.com>
Hi,
Please find below a revised version of the changes for
the javax.xml.parsers package.
It hopefully incorporates all comments I have received so far.
* better wording/formating for Javadoc changes
* using for( : ) syntax in findServiceProvider
* improved // comments explaining why the additional layer of
RuntimeException is needed when wrapping ServiceConfigurationError.
best regards,
-- daniel
On 12/4/12 2:54 PM, Alan Bateman wrote:
> On 03/12/2012 19:04, Daniel Fuchs wrote:
>> Hi,
>>
>> This is a first webrev in a series that addresses a change intended
>> for JDK 8:
>>
>> 7169894: JAXP Plugability Layer: using service loader
>>
>> I've been building up on Joe's work and Paul & Alan comments
>> from an earlier discussion thread [1]
>>
>> This here addresses changes in the javax.xml.parsers
>> package for the SAXParserFactory and DocumentBuilderFactory - and
>> more specifically their no-argument newInstance() method.
>>
>> This change replaces the custom code that was reading the
>> META-INF/services/ resources by a simple call to ServiceLoader.
>>
>>
>>
> Thank you very much for taking this one on. I think your approach to
> take javax.xml.parsers on its own is good as the previous review rounds
> got really stuck in the mire due to the number of factories, code
> duplication, and subtle specification and implementation differences.
>
> In the class descriptions it suggests that the default implementation
> may be "installed as a module" but we aren't there yet so I'm not sure
> about using the term "module". I think it should be okay to say
> "installed as an extension" as ServiceLoader uses this term.
>
> The class description also suggests that a SCE will be wrapped as a
> FactoryConfigurationException but in FactoryFinder I see that it actual
> wraps a RuntimeException. I think you can just use the no-arg
> constructor then then use initCause to set the cause to the SCE.
>
> Also the statement "If a misconfigured provider is encountered and SCE
> is thrown" can probably be changed to "If SCE is thrown" as it can be
> thrown for other reasons too.
>
> Minor nit is that the updates to DocumentBuilderFactory's class
> description requires a really wide screen compared to the rest of the
> javadoc.
>
> Minor implementation suggestion for findServiceProvider is that you can
> use for-each to iterate through the providers.
>
> Otherwise I think you've captured all the points of feedback from the
> original review.
>
> Finally one suggestion is to make keep notes on the "before & after"
> behavior, this is something that will be important for release and
> compatibility notes.
>
> -Alan.
>
>
>
>
>
From jim.gish at oracle.com Wed Dec 5 16:41:17 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Wed, 05 Dec 2012 11:41:17 -0500
Subject: RFR: 8004317 TestLibrary.getUnusedRandomPort() fails
intermittently, but exception not reported
In-Reply-To: <50BE9014.9000508@oracle.com>
References: <50BE56FA.8070508@oracle.com> <50BE65F7.6030306@oracle.com>
<50BE66C6.90409@oracle.com> <50BE697B.7040903@oracle.com>
<50BE6E56.5060905@oracle.com> <50BE9014.9000508@oracle.com>
Message-ID: <50BF792D.9010605@oracle.com>
Thanks for the suggestions, Stuart. BTW printStackTrace() prints to
standard error by default -- that's why I don't explicitly have it in there.
Cheers,
Jim
On 12/04/2012 07:06 PM, Stuart Marks wrote:
> Hi Jim,
>
> (Looks like you're cleaning up warnings along the way. I guess that's
> OK.)
>
> Before printing the stack trace, there should be a message to stderr
> indicating where this stack trace is coming from. For example,
> "getUnusedRandomPort: caught exception". The stack trace should be
> printed to stderr as well, using something like
> ex.printStackTrace(System.err).
>
> I think narrowing the catch to IOException is good, since that's the
> only exception case we really want to retry. I don't think it makes
> sense to mention IllegalArgumentException or SecurityException
> specifically in the comments though. Any exception other than
> IOException should fail-fast.
>
> A message should also be printed if we decide to retry because the
> port is one of the "reserved" ports. This might provide an important
> clue to solving the puzzle.
>
> (My hypothesis is that this routine fails relatively silently when, on
> its last retry, it successfully opens a reserved port. In this case ex
> will be null and we get the RuntimeException with no further
> explanation.)
>
> It would also be helpful to print numTries each time around the loop
> so that we can see if it really is retrying that many times.
>
> Regarding netstat, I think it's a good idea, but I'd suggest we work
> on it separately from this change. Instead, suppose we add a shell
> script test that's named so that it runs at the end of the jdk_rmi
> test target. This could just run netstat -a (or whatever)
> unconditionally. In fact, I could do that without even pushing any
> changes to the source code....
>
> s'marks
>
> On 12/4/12 1:42 PM, Jim Gish wrote:
>> OK -- how about a push then for now and with luck we might get some
>> useful
>> output in a day or two.
>>
>> Jim
>>
>> On 12/04/2012 04:22 PM, Alan Bateman wrote:
>>> On 04/12/2012 21:10, Jim Gish wrote:
>>>> :
>>>>
>>>> P.S. working on adding nestat -a output per Alan's suggestion.
>>> BTW: I didn't mean you have to run with my comment, it's just that I
>>> assume
>>> the issue that the Windows is out of dynamic ports. There is a registry
>>> setting to change the range, and I think there is a netsh command to
>>> adjust
>>> it too. If we can somehow capture the netstat output then it may
>>> confirm this.
>>>
>>> -Alan.
>>
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com
From mike.duigou at oracle.com Wed Dec 5 18:07:54 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 5 Dec 2012 10:07:54 -0800
Subject: Request for Review : CR#8004015 : [2nd pass] Add interface
extends and defaults for basic functional interfaces
In-Reply-To: <50BEE556.6090602@oracle.com>
References:
<0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com>
<50BEE556.6090602@oracle.com>
Message-ID: <56B46C81-9364-4329-B373-80D1D80B295A@oracle.com>
On Dec 4 2012, at 22:10 , David Holmes wrote:
> Hi Mike,
>
> In multiple places:
>
> + * xxx ...
>
> Should that be tag? Is it actually needed? (my javadoc is a bit rusty).
Many of these were added/changed by NetBeans styler. I then added additional instances. I have converted all of the
-> .
I have also filed a bug against NetBans styler: http://netbeans.org/bugzilla/show_bug.cgi?id=223342
> Aside: I don't realise you could {@inheritDoc) as a simple text insertion mechanism.
I only learned of this in the last six months myself. :-)
> Just to be clear, the null-handling statements are intended to be normative and apply to anyone who might provide an implementation of theses classes - right?
Correct. I would prefer that they were not but it seems unavoidable.
Mike
>
> Thanks,
> David
>
> On 5/12/2012 3:47 PM, Mike Duigou wrote:
>> Hello all;
>>
>> I have updated the proposed patch. The changes primarily add class and method documentation regarding handling of null for the primitive specializations.
>>
>> http://cr.openjdk.java.net/~mduigou/8004015/1/webrev/
>> http://cr.openjdk.java.net/~mduigou/8004015/1/specdiff/java/util/function/package-summary.html
>>
>> I've also reformatted the source for the default methods.
>>
>> Mike
>>
>>
>> On Nov 26 2012, at 18:12 , Mike Duigou wrote:
>>
>>> Hello all;
>>>
>>> In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy.
>>>
>>> Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined.
>>>
>>> The patch to add parent interfaces and default methods can be found here:
>>>
>>> http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/
>>> http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html
>>>
>>> Mike
>>>
>>> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e80176a697
>>
From mike.duigou at oracle.com Wed Dec 5 18:20:26 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 5 Dec 2012 10:20:26 -0800
Subject: Request for Review : CR#8004015 : [final (?) pass] Add interface
extends and defaults for basic functional interfaces
In-Reply-To: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com>
References:
<0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com>
Message-ID:
I have updated webrev again to fix some reported javadoc technical issues and added null handling specification to the {Int|Double|Long}Supplier.
http://cr.openjdk.java.net/~mduigou/8004015/2/webrev/
http://cr.openjdk.java.net/~mduigou/8004015/2/specdiff/java/util/function/package-summary.html
I believe that this iteration is complete (or very nearly so).
Mike
On Dec 4 2012, at 21:47 , Mike Duigou wrote:
> Hello all;
>
> I have updated the proposed patch. The changes primarily add class and method documentation regarding handling of null for the primitive specializations.
>
> http://cr.openjdk.java.net/~mduigou/8004015/1/webrev/
> http://cr.openjdk.java.net/~mduigou/8004015/1/specdiff/java/util/function/package-summary.html
>
> I've also reformatted the source for the default methods.
>
> Mike
>
>
> On Nov 26 2012, at 18:12 , Mike Duigou wrote:
>
>> Hello all;
>>
>> In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy.
>>
>> Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined.
>>
>> The patch to add parent interfaces and default methods can be found here:
>>
>> http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/
>> http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html
>>
>> Mike
>>
>> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e80176a697
>
From huizhe.wang at oracle.com Wed Dec 5 18:53:16 2012
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 05 Dec 2012 10:53:16 -0800
Subject: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser
factories (7169894: JAXP Plugability Layer: using service loader)
In-Reply-To: <50BF73B2.5000102@oracle.com>
References: <50BCF7CD.1020308@oracle.com> <50BE007A.4090102@oracle.com>
<50BF73B2.5000102@oracle.com>
Message-ID: <50BF981C.1010702@oracle.com>
Hi Daniel,
Looks good to me!
-Joe
On 12/5/2012 8:17 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a revised version of the changes for
> the javax.xml.parsers package.
>
> It hopefully incorporates all comments I have received so far.
>
>
>
>
> * better wording/formating for Javadoc changes
> * using for( : ) syntax in findServiceProvider
> * improved // comments explaining why the additional layer of
> RuntimeException is needed when wrapping ServiceConfigurationError.
>
> best regards,
>
> -- daniel
>
> On 12/4/12 2:54 PM, Alan Bateman wrote:
>> On 03/12/2012 19:04, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> This is a first webrev in a series that addresses a change intended
>>> for JDK 8:
>>>
>>> 7169894: JAXP Plugability Layer: using service loader
>>>
>>> I've been building up on Joe's work and Paul & Alan comments
>>> from an earlier discussion thread [1]
>>>
>>> This here addresses changes in the javax.xml.parsers
>>> package for the SAXParserFactory and DocumentBuilderFactory - and
>>> more specifically their no-argument newInstance() method.
>>>
>>> This change replaces the custom code that was reading the
>>> META-INF/services/ resources by a simple call to ServiceLoader.
>>>
>>>
>>>
>>>
>> Thank you very much for taking this one on. I think your approach to
>> take javax.xml.parsers on its own is good as the previous review rounds
>> got really stuck in the mire due to the number of factories, code
>> duplication, and subtle specification and implementation differences.
>>
>> In the class descriptions it suggests that the default implementation
>> may be "installed as a module" but we aren't there yet so I'm not sure
>> about using the term "module". I think it should be okay to say
>> "installed as an extension" as ServiceLoader uses this term.
>>
>> The class description also suggests that a SCE will be wrapped as a
>> FactoryConfigurationException but in FactoryFinder I see that it actual
>> wraps a RuntimeException. I think you can just use the no-arg
>> constructor then then use initCause to set the cause to the SCE.
>>
>> Also the statement "If a misconfigured provider is encountered and SCE
>> is thrown" can probably be changed to "If SCE is thrown" as it can be
>> thrown for other reasons too.
>>
>> Minor nit is that the updates to DocumentBuilderFactory's class
>> description requires a really wide screen compared to the rest of the
>> javadoc.
>>
>> Minor implementation suggestion for findServiceProvider is that you can
>> use for-each to iterate through the providers.
>>
>> Otherwise I think you've captured all the points of feedback from the
>> original review.
>>
>> Finally one suggestion is to make keep notes on the "before & after"
>> behavior, this is something that will be important for release and
>> compatibility notes.
>>
>> -Alan.
>>
>>
>>
>>
>>
>
From Alan.Bateman at oracle.com Wed Dec 5 18:58:19 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 05 Dec 2012 18:58:19 +0000
Subject: 8004371: (props) Properties.loadFromXML needs small footprint XML
parser as fallback when JAXP is not present
Message-ID: <50BF994B.5020308@oracle.com>
A while back [1], I brought up the issue of the Properties
storeToXML/loadFromXML methods being problematic for our efforts to
modularize the JDK and also the Compact Profiles effort. At the time I
mentioned that we were thinking of including a small footprint XML
parser that we could use in the base module (when JAXP is not present)
and also use in the compact1 profile. The preparatory work to create a
JDK-internal provider mechanism and the spec work to only require an
implementation support UTF-8 and UTF-16 is already in jdk8, now it's
time for the next step.
Joe Wang has taken the JSR-280 RI, which includes some code from SAX,
and stripped it down so that it's reasonably small (less than 50k in a
compressed rt.jar). We've hooked it up to Properties so that it works as
a fallback when there isn't an XmlPropertiesProvider present. There's
still a good bit of clean-up required and there's probably more that can
be pulled out but it's at the point where we can start early review. To
that end, the webrev with everything is here:
http://cr.openjdk.java.net/~alanb/8004371/webrev/
For tests then I've changed the LoadAndStoreXML test that I added
recently to exercise the implementation. Otherwise, the implementation
will only be used when testing the smallest profile (compact1, brewing
in the jdk8/profiles forest) or when it gets pulled into the downstream
jigsaw forest. Joe has some additional tests and we need to compare
these with existing tests to see if it's worth converting them.
One issue that I'm still mulling over, as least for the profiles effort,
is whether to only include the fallback provider in the smallest profile
as it won't be used otherwise. If the eventual size isn't too
significant then it might not be worth it of course.
-Alan.
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-October/011648.html
From akhil.arora at oracle.com Wed Dec 5 19:39:40 2012
From: akhil.arora at oracle.com (Akhil Arora)
Date: Wed, 05 Dec 2012 11:39:40 -0800
Subject: RFR: 8003246: Add Supplier to ThreadLocal
Message-ID: <50BFA2FC.4010201@oracle.com>
This patch adds a constructor to ThreadLocal to supply initial values
using the new Supplier functional interface. Please review. This work
was done by Jim Gish.
http://cr.openjdk.java.net/~akhil/8003246.0/webrev/
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003246
Thanks
From stuart.marks at oracle.com Wed Dec 5 19:45:20 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 05 Dec 2012 11:45:20 -0800
Subject: RFR: 8004317 TestLibrary.getUnusedRandomPort() fails
intermittently, but exception not reported
In-Reply-To: <50BF792D.9010605@oracle.com>
References: <50BE56FA.8070508@oracle.com> <50BE65F7.6030306@oracle.com>
<50BE66C6.90409@oracle.com> <50BE697B.7040903@oracle.com>
<50BE6E56.5060905@oracle.com> <50BE9014.9000508@oracle.com>
<50BF792D.9010605@oracle.com>
Message-ID: <50BFA450.3030001@oracle.com>
On 12/5/12 8:41 AM, Jim Gish wrote:
> BTW printStackTrace() prints to standard error by default -- that's why I don't
> explicitly have it in there.
Oh yes, so it does. Sorry, I was confused.
s'marks
From mike.duigou at oracle.com Wed Dec 5 19:50:19 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 5 Dec 2012 11:50:19 -0800
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50BFA2FC.4010201@oracle.com>
References: <50BFA2FC.4010201@oracle.com>
Message-ID:
Looks good to me.
Mike
On Dec 5 2012, at 11:39 , Akhil Arora wrote:
> This patch adds a constructor to ThreadLocal to supply initial values using the new Supplier functional interface. Please review. This work was done by Jim Gish.
>
> http://cr.openjdk.java.net/~akhil/8003246.0/webrev/
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003246
>
> Thanks
From dl at cs.oswego.edu Wed Dec 5 19:51:13 2012
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 05 Dec 2012 14:51:13 -0500
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50BFA2FC.4010201@oracle.com>
References: <50BFA2FC.4010201@oracle.com>
Message-ID: <50BFA5B1.3010301@cs.oswego.edu>
On 12/05/12 14:39, Akhil Arora wrote:
> This patch adds a constructor to ThreadLocal to supply initial values using the
> new Supplier functional interface. Please review. This work was done by Jim Gish.
>
> http://cr.openjdk.java.net/~akhil/8003246.0/webrev/
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003246
>
> Thanks
>
I see that EVERY ThreadLocal now has an extra field in case it is
used with a Supplier. I expect that those web frameworks that create
thousands of ThreadLocals (not just instances of Threadlocals)
will see a measurable space increase. has anyone measure the impact?
Did anyone consider instead defining a SuppliedThreadLocal
subclass (or some better name) to isolate the impact?
-Doug
From forax at univ-mlv.fr Wed Dec 5 19:56:04 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 05 Dec 2012 20:56:04 +0100
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50BFA5B1.3010301@cs.oswego.edu>
References: <50BFA2FC.4010201@oracle.com> <50BFA5B1.3010301@cs.oswego.edu>
Message-ID: <50BFA6D4.7030108@univ-mlv.fr>
On 12/05/2012 08:51 PM, Doug Lea wrote:
> On 12/05/12 14:39, Akhil Arora wrote:
>> This patch adds a constructor to ThreadLocal to supply initial values
>> using the
>> new Supplier functional interface. Please review. This work was done
>> by Jim Gish.
>>
>> http://cr.openjdk.java.net/~akhil/8003246.0/webrev/
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003246
>>
>> Thanks
>>
>
> I see that EVERY ThreadLocal now has an extra field in case it is
> used with a Supplier. I expect that those web frameworks that create
> thousands of ThreadLocals (not just instances of Threadlocals)
> will see a measurable space increase. has anyone measure the impact?
>
> Did anyone consider instead defining a SuppliedThreadLocal
> subclass (or some better name) to isolate the impact?
The class doesn't even to have a name, one can add a static factory
method in ThreadLocal and use an anonymous class to implement it.
The other problem is that Supplier should be replaced by Supplier everywhere in the code.
>
>
> -Doug
>
R?mi
From jim.gish at oracle.com Wed Dec 5 20:51:48 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Wed, 05 Dec 2012 15:51:48 -0500
Subject: RFR: 8004317 TestLibrary.getUnusedRandomPort() fails
intermittently, but exception not reported
In-Reply-To: <50BFA450.3030001@oracle.com>
References: <50BE56FA.8070508@oracle.com> <50BE65F7.6030306@oracle.com>
<50BE66C6.90409@oracle.com> <50BE697B.7040903@oracle.com>
<50BE6E56.5060905@oracle.com> <50BE9014.9000508@oracle.com>
<50BF792D.9010605@oracle.com> <50BFA450.3030001@oracle.com>
Message-ID: <50BFB3E4.80807@oracle.com>
Here's a new version for your consideration :-)
http://cr.openjdk.java.net/~jgish/Bug8004317-TestLibrary-getUnusedRandomPort-Failure/
Thanks,
Jim
On 12/05/2012 02:45 PM, Stuart Marks wrote:
> On 12/5/12 8:41 AM, Jim Gish wrote:
>> BTW printStackTrace() prints to standard error by default -- that's
>> why I don't
>> explicitly have it in there.
>
> Oh yes, so it does. Sorry, I was confused.
>
> s'marks
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com
From akhil.arora at oracle.com Wed Dec 5 21:27:37 2012
From: akhil.arora at oracle.com (Akhil Arora)
Date: Wed, 05 Dec 2012 13:27:37 -0800
Subject: Review Request: 8004201: add reducers to primitive type wrappers
In-Reply-To: <50BC0576.4070202@oracle.com>
References: <50B8FE8A.2030403@oracle.com> <50BC0576.4070202@oracle.com>
Message-ID: <50BFBC49.9020200@oracle.com>
Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/
- delegate to Math.min/max for int/long/float/double
- rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor
- removed Character variants of min/max/sum
On 12/02/2012 05:50 PM, David Holmes wrote:
> Hi Akhil,
>
> Is it really necessary/desirable to flag all of these as " Suitable for
> conversion as a method reference to functional interfaces such as ..." ?
Not necessary, but it does provide a hint as to their intended use to a
casual browser of these docs.
> This style:
>
> + * @param a a boolean argument.
> + * @param b another boolean argument.
>
> is at odds with the style used elsewhere for new Functional APIs, and
> with the style of other methods in these classes. Can we just use "first
> operand" and "second operand" for all of these?
It is consistent with Math.min/max, which use the a/b style. Since these
methods are not in one of the functional package, is'nt it better to
stick to the local style?
> Character.sum does not make sense to me. Who adds together characters?
> I'm not even sure min and max are worth supporting for Character.
Good point - removed these methods for Character.
> I disagree with other suggestions to use the Math functions for
> float/double. I think all these methods should use the underlying
> primitive operator regardless of type.
Are you disagreeing only for float/double or for int/long also? Can you
provide more information as to why you disagree?
Thanks
> Thanks,
> David
> -----
>
> On 1/12/2012 4:44 AM, Akhil Arora wrote:
>> Hi
>>
>> Requesting review for some basic functionality related to lambdas -
>>
>> Add min, max, sum methods to the primitive wrapper classes - Byte,
>> Short, Integer, Long, Float, Double and Character so as to be able to
>> use them as reducers in lambda expressions. Add and, or, xor methods to
>> Boolean.
>>
>> http://cr.openjdk.java.net/~akhil/8004201.0/webrev/
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201
>>
>> Thanks
From vitalyd at gmail.com Wed Dec 5 21:42:01 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 5 Dec 2012 16:42:01 -0500
Subject: Review Request: 8004201: add reducers to primitive type wrappers
In-Reply-To: <50BFBC49.9020200@oracle.com>
References: <50B8FE8A.2030403@oracle.com> <50BC0576.4070202@oracle.com>
<50BFBC49.9020200@oracle.com>
Message-ID:
Regarding Character methods; it's unorthodox but some people use them as
"fake" unsigned shorts. Whether that's enough to justify adding
sum/max/min, I don't know.
Sent from my phone
On Dec 5, 2012 4:28 PM, "Akhil Arora" wrote:
> Updated - http://cr.openjdk.java.net/~**akhil/8004201.1/webrev/
>
> - delegate to Math.min/max for int/long/float/double
> - rename Boolean.and/or/xor to logicalAnd/logicalOr/**logicalXor
> - removed Character variants of min/max/sum
>
> On 12/02/2012 05:50 PM, David Holmes wrote:
>
>> Hi Akhil,
>>
>> Is it really necessary/desirable to flag all of these as " Suitable for
>> conversion as a method reference to functional interfaces such as ..." ?
>>
>
> Not necessary, but it does provide a hint as to their intended use to a
> casual browser of these docs.
>
> This style:
>>
>> + * @param a a boolean argument.
>> + * @param b another boolean argument.
>>
>> is at odds with the style used elsewhere for new Functional APIs, and
>> with the style of other methods in these classes. Can we just use "first
>> operand" and "second operand" for all of these?
>>
>
> It is consistent with Math.min/max, which use the a/b style. Since these
> methods are not in one of the functional package, is'nt it better to stick
> to the local style?
>
> Character.sum does not make sense to me. Who adds together characters?
>> I'm not even sure min and max are worth supporting for Character.
>>
>
> Good point - removed these methods for Character.
>
> I disagree with other suggestions to use the Math functions for
>> float/double. I think all these methods should use the underlying
>> primitive operator regardless of type.
>>
>
> Are you disagreeing only for float/double or for int/long also? Can you
> provide more information as to why you disagree?
>
> Thanks
>
> Thanks,
>> David
>> -----
>>
>> On 1/12/2012 4:44 AM, Akhil Arora wrote:
>>
>>> Hi
>>>
>>> Requesting review for some basic functionality related to lambdas -
>>>
>>> Add min, max, sum methods to the primitive wrapper classes - Byte,
>>> Short, Integer, Long, Float, Double and Character so as to be able to
>>> use them as reducers in lambda expressions. Add and, or, xor methods to
>>> Boolean.
>>>
>>> http://cr.openjdk.java.net/~**akhil/8004201.0/webrev/
>>> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8004201
>>>
>>> Thanks
>>>
>>
>
From mandy.chung at oracle.com Wed Dec 5 21:55:40 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 05 Dec 2012 13:55:40 -0800
Subject: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser
factories (7169894: JAXP Plugability Layer: using service loader)
In-Reply-To: <50BF73B2.5000102@oracle.com>
References: <50BCF7CD.1020308@oracle.com> <50BE007A.4090102@oracle.com>
<50BF73B2.5000102@oracle.com>
Message-ID: <50BFC2DC.1090608@oracle.com>
Hi Daniel,
Looks good to me. One question - the last bullet in the search order
covers the default implementation case:
"Platform default DocumentBuilderFactory instance."
Would it make sense to merge the statement "Otherwise, the default
implementation, if present, is returned" with the above statement? e.g.
"Default implementation of DocumentBuilderFactory if
present".
Mandy
On 12/5/2012 8:17 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a revised version of the changes for
> the javax.xml.parsers package.
>
> It hopefully incorporates all comments I have received so far.
>
>
>
>
> * better wording/formating for Javadoc changes
> * using for( : ) syntax in findServiceProvider
> * improved // comments explaining why the additional layer of
> RuntimeException is needed when wrapping ServiceConfigurationError.
>
> best regards,
>
> -- daniel
>
> On 12/4/12 2:54 PM, Alan Bateman wrote:
>> On 03/12/2012 19:04, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> This is a first webrev in a series that addresses a change intended
>>> for JDK 8:
>>>
>>> 7169894: JAXP Plugability Layer: using service loader
>>>
>>> I've been building up on Joe's work and Paul & Alan comments
>>> from an earlier discussion thread [1]
>>>
>>> This here addresses changes in the javax.xml.parsers
>>> package for the SAXParserFactory and DocumentBuilderFactory - and
>>> more specifically their no-argument newInstance() method.
>>>
>>> This change replaces the custom code that was reading the
>>> META-INF/services/ resources by a simple call to ServiceLoader.
>>>
>>>
>>>
>>>
>> Thank you very much for taking this one on. I think your approach to
>> take javax.xml.parsers on its own is good as the previous review rounds
>> got really stuck in the mire due to the number of factories, code
>> duplication, and subtle specification and implementation differences.
>>
>> In the class descriptions it suggests that the default implementation
>> may be "installed as a module" but we aren't there yet so I'm not sure
>> about using the term "module". I think it should be okay to say
>> "installed as an extension" as ServiceLoader uses this term.
>>
>> The class description also suggests that a SCE will be wrapped as a
>> FactoryConfigurationException but in FactoryFinder I see that it actual
>> wraps a RuntimeException. I think you can just use the no-arg
>> constructor then then use initCause to set the cause to the SCE.
>>
>> Also the statement "If a misconfigured provider is encountered and SCE
>> is thrown" can probably be changed to "If SCE is thrown" as it can be
>> thrown for other reasons too.
>>
>> Minor nit is that the updates to DocumentBuilderFactory's class
>> description requires a really wide screen compared to the rest of the
>> javadoc.
>>
>> Minor implementation suggestion for findServiceProvider is that you can
>> use for-each to iterate through the providers.
>>
>> Otherwise I think you've captured all the points of feedback from the
>> original review.
>>
>> Finally one suggestion is to make keep notes on the "before & after"
>> behavior, this is something that will be important for release and
>> compatibility notes.
>>
>> -Alan.
>>
>>
>>
>>
>>
>
From Ulf.Zibis at CoSoCo.de Wed Dec 5 21:58:37 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Wed, 05 Dec 2012 22:58:37 +0100
Subject: 8003562: Provide a command-line tool to find static dependencies
In-Reply-To: <50B54A2C.1040907@oracle.com>
References: <50B54A2C.1040907@oracle.com>
Message-ID: <50BFC38D.8020406@CoSoCo.de>
Yeah, this is a great tool.
Does it also help to find the need to recompile a class if the source of a inlined referred static
final constant has changed?
-Ulf
Am 28.11.2012 00:18, schrieb Mandy Chung:
> As part of prepare for modules [1], this RFE is to provide a command-line tool in JDK8 so that
> developers can understand the static dependencies of their applications and libraries.As part of
> Project Jigsaw, a useful class analyzer [2] was developed that makes it very easy to identify the
> dependencies based on the classfile library thathas also been enhanced to support dependency
> analysis [3].
>
> Inspired by the sample tool that Jon Gibbons developed, we propose this new command-line name as
> "jdeps".
>
> $ ./bin/jdeps -h
> Usage: jdeps
> where possible options include:
> -version Version information
> -classpath Specify where to find class files
> -v --verbose Print class-level dependencies
> -r --reverse Invert the dependencies in the output
> -p Restrict analysis to classes in this package
> (may be given multiple times)
> -e --regex Restrict analysis to packages matching pattern
> (-p and -e are exclusive)
> -P --profile Show profile or the file containing a package
> -d --depth Specify the depth of the transitive dependency analysis
> Default depth is 1. Set depth to 0 to traverse all dependencies.
> -all Show all classes and members with no breakdown
>
> The jdeps tool shows package-level dependencies of the input files that can be .class files, a
> directory, or a JAR file. Specify the depth for the transitive dependency analysis; otherwise, it
> only analyzes the input files. jdeps -P option will show where the class/package comes from. For
> Java SE API, it will show the Profile name (I implement a workaround for now until the profile
> work is in jdk8). For JDK internal APIs, they will not be exported in modular world. jdeps will
> indicate any usage of the JDK internal APIs in the output to help developers prepare for
> transitioning to modules.
>
> See below for a few sample output.
>
> Webrev at:
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8003562/
>
> The implementation classes for jdeps are in the langtools repo along with the
> com.sun.tools.classfile library. I'm working on adding more unit tests. I'd like to get this
> webrev out to begin the discussion and get review feedback.
>
> Thanks
> Mandy
> [1] http://openjdk.java.net/jeps/162
> [2]
> http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/raw-file/543b0d24a920/make/tools/classanalyzer/classanalyzer.html
> [3] http://bugs.sun.com/view_bug.do?bug_id=6907575
>
> Sample Output
>
> $./bin/jdeps demo/jfc/Notepad/Notepad.jar
> (demo/jfc/Notepad/Notepad.jar)
> -> java.awt
> -> java.awt.event
> -> java.beans
> -> java.io
> -> java.lang
> -> java.net
> -> java.util
> -> java.util.logging
> -> javax.swing
> -> javax.swing.border
> -> javax.swing.event
> -> javax.swing.text
> -> javax.swing.tree
> -> javax.swing.undo
>
> $ ./bin/jdeps -P demo/jfc/Notepad/Notepad.jar
> (demo/jfc/Notepad/Notepad.jar)
> -> java.awt compact4
> -> java.awt.event compact4
> -> java.beans compact4
> -> java.io compact1
> -> java.lang compact1
> -> java.net compact1
> -> java.util compact1
> -> java.util.logging compact1
> -> javax.swing compact4
> -> javax.swing.border compact4
> -> javax.swing.event compact4
> -> javax.swing.text compact4
> -> javax.swing.tree compact4
> -> javax.swing.undo compact4
>
> $ ./bin/jdeps -d 10 demo/jfc/Notepad/Notepad.jar
> (demo/jfc/Notepad/Notepad.jar)
> -> java.awt
> -> java.awt.event
> -> java.beans
> -> java.io
> -> java.lang
> -> java.net
> -> java.util
> -> java.util.logging
> -> javax.swing
> -> javax.swing.border
> -> javax.swing.event
> -> javax.swing.text
> -> javax.swing.tree
> -> javax.swing.undo
> java.security (/export/mchung/ws/jdeps-repo/build/macosx-x86_64/j2sdk-image/jre/lib/rt.jar)
> -> javax.crypto
> javax.crypto (/export/mchung/ws/jdeps-repo/build/macosx-x86_64/j2sdk-image/jre/lib/jce.jar)
> -> java.io
> -> java.lang
> -> java.lang.reflect
> -> java.net
> -> java.nio
> -> java.security
> -> java.security.cert
> -> java.security.spec
> -> java.util
> -> java.util.concurrent
> -> java.util.jar
> -> java.util.regex
> -> java.util.zip
> -> sun.security.jca JDK internal API
> -> sun.security.util JDK internal API
> javax.crypto.spec (/export/mchung/ws/jdeps-repo/build/macosx-x86_64/j2sdk-image/jre/lib/jce.jar)
> -> java.lang
> -> java.security.spec
> -> java.util
>
From david.dehaven at oracle.com Wed Dec 5 22:44:12 2012
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 5 Dec 2012 14:44:12 -0800
Subject: Review request: 8004042 : Arrrghs.java test failed on windows with
access error.
Message-ID: <99E014EB-0210-4C77-BE43-88CED80B1825@oracle.com>
A fix for intermittent test failures causing grief on Windows, particularly Windows 7 and 2008 systems:
http://cr.openjdk.java.net/~ddehaven/8004042/webrev.1/
The underlying cause is as of yet unknown, but I was able to create an environment that caused similar failures by running "watch -n 0.2 cat JTwork/scratch/atest.bat" in another shell then running jtreg. Without the patch it would fail very regularly (especially when isolated and looped 1,000 times), with the patch it always passes.
-DrD-
From joe.darcy at oracle.com Wed Dec 5 23:44:53 2012
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Wed, 05 Dec 2012 15:44:53 -0800
Subject: Review Request: 8004201: add reducers to primitive type wrappers
In-Reply-To: <50BFBC49.9020200@oracle.com>
References: <50B8FE8A.2030403@oracle.com> <50BC0576.4070202@oracle.com>
<50BFBC49.9020200@oracle.com>
Message-ID: <50BFDC75.6000306@oracle.com>
Akhil,
In javadoc like this
298 * as {@code BinaryOperator<Boolean>}.
you don't have to use "<" and the like inside {@code}; please change to
298 * as {@code BinaryOperator}.
As a general comment, if the operations for primitive type Foo are put
into java.lang.Foo, then the type of the operation needs to be
explicitly represented in the expression calling the method (unless
static imports are used, etc.). Therefore, I suggest putting these sort
of static methods all into one class to allow overloading to do its
thing (java.lang.Operators?). Also, for methods like sum, I think it is
worth considering returning a larger type than the operands to avoid
problems from integer or floating-point overflow. For example, sum on
byte and short would return int, sun on int would return long, etc.
As an aside, to get a numerically robust result, the summation logic
over a set of doubles needs to be more than just a set of raw double
additions, but that can be tackled later.
Cheers,
-Joe
On 12/5/2012 1:27 PM, Akhil Arora wrote:
> Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/
>
> - delegate to Math.min/max for int/long/float/double
> - rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor
> - removed Character variants of min/max/sum
>
> On 12/02/2012 05:50 PM, David Holmes wrote:
>> Hi Akhil,
>>
>> Is it really necessary/desirable to flag all of these as " Suitable for
>> conversion as a method reference to functional interfaces such as ..." ?
> Not necessary, but it does provide a hint as to their intended use to a
> casual browser of these docs.
>
>> This style:
>>
>> + * @param a a boolean argument.
>> + * @param b another boolean argument.
>>
>> is at odds with the style used elsewhere for new Functional APIs, and
>> with the style of other methods in these classes. Can we just use "first
>> operand" and "second operand" for all of these?
> It is consistent with Math.min/max, which use the a/b style. Since these
> methods are not in one of the functional package, is'nt it better to
> stick to the local style?
>
>> Character.sum does not make sense to me. Who adds together characters?
>> I'm not even sure min and max are worth supporting for Character.
> Good point - removed these methods for Character.
>
>> I disagree with other suggestions to use the Math functions for
>> float/double. I think all these methods should use the underlying
>> primitive operator regardless of type.
> Are you disagreeing only for float/double or for int/long also? Can you
> provide more information as to why you disagree?
>
> Thanks
>
>> Thanks,
>> David
>> -----
>>
>> On 1/12/2012 4:44 AM, Akhil Arora wrote:
>>> Hi
>>>
>>> Requesting review for some basic functionality related to lambdas -
>>>
>>> Add min, max, sum methods to the primitive wrapper classes - Byte,
>>> Short, Integer, Long, Float, Double and Character so as to be able to
>>> use them as reducers in lambda expressions. Add and, or, xor methods to
>>> Boolean.
>>>
>>> http://cr.openjdk.java.net/~akhil/8004201.0/webrev/
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201
>>>
>>> Thanks
>
From stuart.marks at oracle.com Wed Dec 5 23:54:30 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 05 Dec 2012 15:54:30 -0800
Subject: RFR: 8004317 TestLibrary.getUnusedRandomPort() fails
intermittently, but exception not reported
In-Reply-To: <50BFB3E4.80807@oracle.com>
References: <50BE56FA.8070508@oracle.com> <50BE65F7.6030306@oracle.com>
<50BE66C6.90409@oracle.com> <50BE697B.7040903@oracle.com>
<50BE6E56.5060905@oracle.com> <50BE9014.9000508@oracle.com>
<50BF792D.9010605@oracle.com> <50BFA450.3030001@oracle.com>
<50BFB3E4.80807@oracle.com>
Message-ID: <50BFDEB6.3070401@oracle.com>
OK, looks better, more explicit so that we can find out why this is failing.
There's still a subtle issue in the reporting though. Consider if on attempt N
the ServerSocket call gets a valid port but it's one of the reserved ports.
Then, unusedRandomPort will be >= 0 and isReservedPort() will be true, so we'll
get the "INFO" message.
Now on attempt N+1 suppose ServerSocket throws an exception. We'll get the
exception stack trace, but then unusedRandomPort will still have its previous
value, and we'll get the INFO message again, but spuriously this time. I hate
to ask you to update this again, but as it stands I think the output will be
quite confusing.
I think setting unusedRandomPort back to -1 at the top of the loop should fix it.
You need me to push this for you? I can drop in this change before I push, if
you're OK with me doing this.
s'marks
On 12/5/12 12:51 PM, Jim Gish wrote:
> Here's a new version for your consideration :-)
>
> http://cr.openjdk.java.net/~jgish/Bug8004317-TestLibrary-getUnusedRandomPort-Failure/
>
>
> Thanks,
> Jim
>
> On 12/05/2012 02:45 PM, Stuart Marks wrote:
>> On 12/5/12 8:41 AM, Jim Gish wrote:
>>> BTW printStackTrace() prints to standard error by default -- that's why I don't
>>> explicitly have it in there.
>>
>> Oh yes, so it does. Sorry, I was confused.
>>
>> s'marks
>
> --
> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
> Oracle Java Platform Group | Core Libraries Team
> 35 Network Drive
> Burlington, MA 01803
> jim.gish at oracle.com
>
From jim.gish at oracle.com Thu Dec 6 00:02:56 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Wed, 05 Dec 2012 19:02:56 -0500
Subject: RFR: 8004317 TestLibrary.getUnusedRandomPort() fails
intermittently, but exception not reported
In-Reply-To: <50BFDEB6.3070401@oracle.com>
References: <50BE56FA.8070508@oracle.com> <50BE65F7.6030306@oracle.com>
<50BE66C6.90409@oracle.com> <50BE697B.7040903@oracle.com>
<50BE6E56.5060905@oracle.com> <50BE9014.9000508@oracle.com>
<50BF792D.9010605@oracle.com> <50BFA450.3030001@oracle.com>
<50BFB3E4.80807@oracle.com> <50BFDEB6.3070401@oracle.com>
Message-ID: <50BFE0B0.9030102@oracle.com>
Thanks Stuart. Sure - go ahead and make the change and do the push.
Maybe we'll get lucky with the nightlies!
Thanks again,
Jim
On 12/05/2012 06:54 PM, Stuart Marks wrote:
> OK, looks better, more explicit so that we can find out why this is
> failing.
>
> There's still a subtle issue in the reporting though. Consider if on
> attempt N the ServerSocket call gets a valid port but it's one of the
> reserved ports. Then, unusedRandomPort will be >= 0 and
> isReservedPort() will be true, so we'll get the "INFO" message.
>
> Now on attempt N+1 suppose ServerSocket throws an exception. We'll get
> the exception stack trace, but then unusedRandomPort will still have
> its previous value, and we'll get the INFO message again, but
> spuriously this time. I hate to ask you to update this again, but as
> it stands I think the output will be quite confusing.
>
> I think setting unusedRandomPort back to -1 at the top of the loop
> should fix it.
>
> You need me to push this for you? I can drop in this change before I
> push, if you're OK with me doing this.
>
> s'marks
>
> On 12/5/12 12:51 PM, Jim Gish wrote:
>> Here's a new version for your consideration :-)
>>
>> http://cr.openjdk.java.net/~jgish/Bug8004317-TestLibrary-getUnusedRandomPort-Failure/
>>
>>
>>
>>
>> Thanks,
>> Jim
>>
>> On 12/05/2012 02:45 PM, Stuart Marks wrote:
>>> On 12/5/12 8:41 AM, Jim Gish wrote:
>>>> BTW printStackTrace() prints to standard error by default -- that's
>>>> why I don't
>>>> explicitly have it in there.
>>>
>>> Oh yes, so it does. Sorry, I was confused.
>>>
>>> s'marks
>>
>> --
>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
>> Oracle Java Platform Group | Core Libraries Team
>> 35 Network Drive
>> Burlington, MA 01803
>> jim.gish at oracle.com
>>
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com
From mandy.chung at oracle.com Thu Dec 6 01:36:30 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 05 Dec 2012 17:36:30 -0800
Subject: Review request: 8003562: Provide a command-line tool to find static
dependencies
In-Reply-To: <50B54A2C.1040907@oracle.com>
References: <50B54A2C.1040907@oracle.com>
Message-ID: <50BFF69E.1040805@oracle.com>
This review request (add a new jdeps tool in the JDK) include changes in
langtools and the jdk build. I would need reviewers from the langtools
and the build-infra team.
Webrev for review:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/jdeps/langtools-webrev.02/
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/jdeps/jdk-webrev.02/
The jdeps source is in the langtools repo. The change in the jdk repo is
to add the new jdeps executable. I made change in the old and new build
for the addition of this new jdeps tool. I discussed with Jon whether I
should modify langtools/make/build.xml to add a new jdeps target. Since
the old build will be replaced by the new build soon, I simply add
com/sun/tools/jdeps as part of javap.includes.
Alan,
The -d option is kept as a hidden option and use as implementation. We
can remove it when it's determined not useful in the future. I also
rename -v:summary to -summary.
Thanks
Mandy
----------------------------
$ jdep -h
Usage: jdeps
where possible options include:
-version Version information
-classpath Specify where to find class files
-summary Print dependency summary only
-v:class Print class-level dependencies
-v:package Print package-level dependencies
-p Restrict analysis to classes in this package
(may be given multiple times)
-e Restrict analysis to packages matching pattern
(-p and -e are exclusive)
-P --profile Show profile or the file containing a package
-R --recursive Traverse all dependencies recursively
-all Process all classes specified in -classpath
$ jdep Notepad.jar Ensemble.jar
Notepad.jar -> D:\tools\devtools\jdk8\windows-i586\jre\lib\rt.jar
(Notepad.jar)
-> java.awt
-> java.awt.event
-> java.beans
-> java.io
-> java.lang
-> java.net
-> java.util
-> java.util.logging
-> javax.swing
-> javax.swing.border
-> javax.swing.event
-> javax.swing.text
-> javax.swing.tree
-> javax.swing.undo
Ensemble.jar -> D:\tools\devtools\jdk8\windows-i586\jre\lib\jfxrt.jar
Ensemble.jar -> D:\tools\devtools\jdk8\windows-i586\jre\lib\rt.jar
com.javafx.main (Ensemble.jar)
-> java.applet
-> java.awt
-> java.awt.event
-> java.io
-> java.lang
-> java.lang.reflect
-> java.net
-> java.security
-> java.util
-> java.util.jar
-> javax.swing
-> sun.misc JDK internal API (rt.jar)
From david.holmes at oracle.com Thu Dec 6 05:10:55 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 06 Dec 2012 15:10:55 +1000
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50BFA2FC.4010201@oracle.com>
References: <50BFA2FC.4010201@oracle.com>
Message-ID: <50C028DF.2030303@oracle.com>
On 6/12/2012 5:39 AM, Akhil Arora wrote:
> This patch adds a constructor to ThreadLocal to supply initial values
> using the new Supplier functional interface. Please review. This work
> was done by Jim Gish.
>
> http://cr.openjdk.java.net/~akhil/8003246.0/webrev/
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003246
Has anyone actually established that this is a useful addition to make?
What is the acceptance criteria for adding these new mechanisms to
existing classes? Was there a CCC request for this?
We need to be very wary of unnecessary bloat.
David
> Thanks
From stuart.marks at oracle.com Thu Dec 6 05:12:03 2012
From: stuart.marks at oracle.com (stuart.marks at oracle.com)
Date: Thu, 06 Dec 2012 05:12:03 +0000
Subject: hg: jdk8/tl/jdk: 8004317: TestLibrary.getUnusedRandomPort() fails
intermittently, but exception not reported
Message-ID: <20121206051214.7A1D447EF1@hg.openjdk.java.net>
Changeset: a971516029ab
Author: jgish
Date: 2012-12-05 21:08 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a971516029ab
8004317: TestLibrary.getUnusedRandomPort() fails intermittently, but exception not reported
Reviewed-by: alanb, dmocek, smarks
! test/java/rmi/testlibrary/TestLibrary.java
From stuart.marks at oracle.com Thu Dec 6 05:24:47 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 05 Dec 2012 21:24:47 -0800
Subject: RFR: 8004317 TestLibrary.getUnusedRandomPort() fails
intermittently, but exception not reported
In-Reply-To: <50BFE0B0.9030102@oracle.com>
References: <50BE56FA.8070508@oracle.com> <50BE65F7.6030306@oracle.com>
<50BE66C6.90409@oracle.com> <50BE697B.7040903@oracle.com>
<50BE6E56.5060905@oracle.com> <50BE9014.9000508@oracle.com>
<50BF792D.9010605@oracle.com> <50BFA450.3030001@oracle.com>
<50BFB3E4.80807@oracle.com> <50BFDEB6.3070401@oracle.com>
<50BFE0B0.9030102@oracle.com>
Message-ID: <50C02C1F.8090006@oracle.com>
Pushed:
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a971516029ab
I couldn't resist doing a couple more fixups. (Man, there is a lot more
cleaning up that could be done in here.)
I don't know if I got this in time for tonight's nightly. Well, get it in there
and see if it falls over sooner or later.
s'marks
On 12/5/12 4:02 PM, Jim Gish wrote:
> Thanks Stuart. Sure - go ahead and make the change and do the push. Maybe
> we'll get lucky with the nightlies!
>
> Thanks again,
> Jim
> On 12/05/2012 06:54 PM, Stuart Marks wrote:
>> OK, looks better, more explicit so that we can find out why this is failing.
>>
>> There's still a subtle issue in the reporting though. Consider if on attempt
>> N the ServerSocket call gets a valid port but it's one of the reserved ports.
>> Then, unusedRandomPort will be >= 0 and isReservedPort() will be true, so
>> we'll get the "INFO" message.
>>
>> Now on attempt N+1 suppose ServerSocket throws an exception. We'll get the
>> exception stack trace, but then unusedRandomPort will still have its previous
>> value, and we'll get the INFO message again, but spuriously this time. I hate
>> to ask you to update this again, but as it stands I think the output will be
>> quite confusing.
>>
>> I think setting unusedRandomPort back to -1 at the top of the loop should fix
>> it.
>>
>> You need me to push this for you? I can drop in this change before I push, if
>> you're OK with me doing this.
>>
>> s'marks
>>
>> On 12/5/12 12:51 PM, Jim Gish wrote:
>>> Here's a new version for your consideration :-)
>>>
>>> http://cr.openjdk.java.net/~jgish/Bug8004317-TestLibrary-getUnusedRandomPort-Failure/
>>>
>>>
>>>
>>>
>>> Thanks,
>>> Jim
>>>
>>> On 12/05/2012 02:45 PM, Stuart Marks wrote:
>>>> On 12/5/12 8:41 AM, Jim Gish wrote:
>>>>> BTW printStackTrace() prints to standard error by default -- that's why I
>>>>> don't
>>>>> explicitly have it in there.
>>>>
>>>> Oh yes, so it does. Sorry, I was confused.
>>>>
>>>> s'marks
>>>
>>> --
>>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
>>> Oracle Java Platform Group | Core Libraries Team
>>> 35 Network Drive
>>> Burlington, MA 01803
>>> jim.gish at oracle.com
>>>
>
From stuart.marks at oracle.com Thu Dec 6 05:43:31 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 05 Dec 2012 21:43:31 -0800
Subject: Review request: 8004042 : Arrrghs.java test failed on windows
with access error.
In-Reply-To: <99E014EB-0210-4C77-BE43-88CED80B1825@oracle.com>
References: <99E014EB-0210-4C77-BE43-88CED80B1825@oracle.com>
Message-ID: <50C03083.4030102@oracle.com>
On 12/5/12 2:44 PM, David DeHaven wrote:
>
> A fix for intermittent test failures causing grief on Windows, particularly Windows 7 and 2008 systems:
> http://cr.openjdk.java.net/~ddehaven/8004042/webrev.1/
>
> The underlying cause is as of yet unknown, but I was able to create an environment that caused similar failures by running "watch -n 0.2 cat JTwork/scratch/atest.bat" in another shell then running jtreg. Without the patch it would fail very regularly (especially when isolated and looped 1,000 times), with the patch it always passes.
We had been discussing/speculating that the problem is the virus scanner
checking the old incarnation of the file at the same time we want to create a
new one. If so, and if it were to hold the file open with exclusive access,
that would explain the AccessDeniedException instead of
FileAlreadyExistsException (in the CREATE_NEW case).
(I still don't have an explanation for why the file deletion doesn't throw an
exception. That's what seems to cause jtreg some grief in its cleanup phase,
and for that reason we've added retry logic to jtreg.)
In any case I think backing off and retrying is probably what's getting us the
benefit, not the adjustment of the file creation flags.
In any case I'd increase the number of retry attempts. The test environment is
surprisingly hostile. In the RMI tests we try to open an unused network port
and retry 10 times if that fails, and sometimes that's not enough. (See Jim
Gish's recent changeset.)
InterruptedException shouldn't be ignored. Jtreg will interrupt the test if it
times out, so this interruption should be handled gracefully. Perhaps, wrap the
InterruptedException in an IOException and rethrow it? (Since the caller is
clearly prepared to handle IOException.) Terminating the loop and returning
normally doesn't seem right, since the file wasn't created successfully.
This is only style, but perhaps it would be good to get rid of the 'done'
boolean and replace the 'done = true' statement with a 'return'. This
simplifies things a bit, I think.
s'marks
From david.holmes at oracle.com Thu Dec 6 06:06:45 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 06 Dec 2012 16:06:45 +1000
Subject: Request for Review : CR#8004015 : [final (?) pass] Add interface
extends and defaults for basic functional interfaces
In-Reply-To:
References:
<0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com>
Message-ID: <50C035F5.4050007@oracle.com>
On 6/12/2012 4:20 AM, Mike Duigou wrote:
> I have updated webrev again to fix some reported javadoc technical issues and added null handling specification to the {Int|Double|Long}Supplier.
>
> http://cr.openjdk.java.net/~mduigou/8004015/2/webrev/
> http://cr.openjdk.java.net/~mduigou/8004015/2/specdiff/java/util/function/package-summary.html
>
> I believe that this iteration is complete (or very nearly so).
Sorry to be a pain but this:
left - the left operand, must be non-null
doesn't tell you what happens if it is null. Is it not better to simply
have:
@param left the left operand
@param right the right operand
@throws NullPointerException if either left or right are null
?
David
-----
> Mike
>
> On Dec 4 2012, at 21:47 , Mike Duigou wrote:
>
>> Hello all;
>>
>> I have updated the proposed patch. The changes primarily add class and method documentation regarding handling of null for the primitive specializations.
>>
>> http://cr.openjdk.java.net/~mduigou/8004015/1/webrev/
>> http://cr.openjdk.java.net/~mduigou/8004015/1/specdiff/java/util/function/package-summary.html
>>
>> I've also reformatted the source for the default methods.
>>
>> Mike
>>
>>
>> On Nov 26 2012, at 18:12 , Mike Duigou wrote:
>>
>>> Hello all;
>>>
>>> In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy.
>>>
>>> Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined.
>>>
>>> The patch to add parent interfaces and default methods can be found here:
>>>
>>> http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/
>>> http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html
>>>
>>> Mike
>>>
>>> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e80176a697
>>
>
>
From henry.jen at oracle.com Thu Dec 6 06:57:23 2012
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 05 Dec 2012 22:57:23 -0800
Subject: Request for Review: CR#8001667, second attempt
Message-ID: <50C041D3.9060703@oracle.com>
Hi,
This update reflect changes based on feedbacks for last version, the
changes are
- rename reverse() to reverseOrder()
- rename Comparator.compose to Comparator.thenComparing
- add 4 Comparator.thenComparing methods take [Int|Long|Double]Function
to enable fluent syntax like this example,
people.sort(Comparators.comparing(People::getFirstName).thenComparing(People.getLastName))
vs previously,
people.sort(Comparators.comparing(Person::getName))
Comparator byLastFirst
= Comparators.comparing(Person::getLastName)
.compose(Comparators.comparing(Person::getFirstName))
Please review and comment on the webrev[1] and specdiff[2].
[1] http://cr.openjdk.java.net/~henryjen/ccc/8001667.1/webrev
[2]
http://cr.openjdk.java.net/~henryjen/ccc/8001667.1/specdiff/overview-summary.html
Cheers,
Henry
From forax at univ-mlv.fr Thu Dec 6 08:23:09 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 06 Dec 2012 09:23:09 +0100
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C028DF.2030303@oracle.com>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
Message-ID: <50C055ED.1040602@univ-mlv.fr>
On 12/06/2012 06:10 AM, David Holmes wrote:
> On 6/12/2012 5:39 AM, Akhil Arora wrote:
>> This patch adds a constructor to ThreadLocal to supply initial values
>> using the new Supplier functional interface. Please review. This work
>> was done by Jim Gish.
>>
>> http://cr.openjdk.java.net/~akhil/8003246.0/webrev/
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003246
>
> Has anyone actually established that this is a useful addition to
> make? What is the acceptance criteria for adding these new mechanisms
> to existing classes? Was there a CCC request for this?
>
> We need to be very wary of unnecessary bloat.
It's a necessary bloat :)
There are two good reasons to provide a new ThreadLocal<>(() ->
initialValue),
if all goes as planned, every Supplier will share the same class so
instead of having one class by thread local that want to specify an
initialValue, we will have only 2 classes (or 3 if the ThreadLocal that
takes a Supplier is a subclass) in memory. Also, letting people to
subclass ThreadLocal is not a good idea because if in one location
someone decide to override get() to by example add a logging code (I've
seen a similar problem) then suddenly all the codes that use
ThreadLocal.get() will not be able to inline it. Given that too many
things are done using ThreadLocal in JEE container, having a way to
provide an initial value without subclassing ThreadLocal is a good idea.
>
> David
R?mi
From Alan.Bateman at oracle.com Thu Dec 6 10:04:28 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 06 Dec 2012 10:04:28 +0000
Subject: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser
factories (7169894: JAXP Plugability Layer: using service loader)
In-Reply-To: <50BF73B2.5000102@oracle.com>
References: <50BCF7CD.1020308@oracle.com> <50BE007A.4090102@oracle.com>
<50BF73B2.5000102@oracle.com>
Message-ID: <50C06DAC.5050500@oracle.com>
On 05/12/2012 16:17, Daniel Fuchs wrote:
> Hi,
>
> Please find below a revised version of the changes for
> the javax.xml.parsers package.
>
> It hopefully incorporates all comments I have received so far.
>
>
>
>
> * better wording/formating for Javadoc changes
> * using for( : ) syntax in findServiceProvider
> * improved // comments explaining why the additional layer of
> RuntimeException is needed when wrapping ServiceConfigurationError.
>
> best regards,
>
> -- daniel
You've addressed all my comments and I think this looks very good.
One other comment. Now that the wording is "Otherwise the default
implementation, if present, is returned" it raises the question as to
how what happens if the default implementation is not present. A
suggestion is to just handle it in the next statement, something like
"In the case of a SCE or the default provider is not present, then FCE
will be thrown".
I see Mandy's comment about the bullet item "Platform default
DocumentBuilderFactory instance". I hadn't noticed this but
I assume this should just be removed now.
-Alan.
From daniel.fuchs at oracle.com Thu Dec 6 11:22:23 2012
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 06 Dec 2012 12:22:23 +0100
Subject: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser
factories (7169894: JAXP Plugability Layer: using service loader)
In-Reply-To: <50BFC2DC.1090608@oracle.com>
References: <50BCF7CD.1020308@oracle.com> <50BE007A.4090102@oracle.com>
<50BF73B2.5000102@oracle.com> <50BFC2DC.1090608@oracle.com>
Message-ID: <50C07FEF.7050102@oracle.com>
Hi Mandy,
On 12/5/12 10:55 PM, Mandy Chung wrote:
> Hi Daniel,
>
> Looks good to me. One question - the last bullet in the search order
> covers the default implementation case:
> "Platform default DocumentBuilderFactory instance."
>
> Would it make sense to merge the statement "Otherwise, the default
> implementation, if present, is returned" with the above statement? e.g.
> "Default implementation of DocumentBuilderFactory if
> present".
Good point - the description matches the internal implementation, but
maybe too literally:
ServiceLoader.load() may return the default implementation - or
may return null - hence the text 'the default implementation, if
present, is returned.'
If ServiceLoader.load() returns null, then the algorithm will again
try to instantiate the default implementation - usually using
Class.forName with the TCCL - hence the last bullet:
'Platform default DocumentBuilderFactory instance.'
This last step is necessary because the default implementation
may be present without being accessible through a service
provider (that's the default configuration: in JDK 8 - with no
user configuration, ServiceLoader.load() will never instantiate
the default implementation)
However - from a user point of view - I don't think it makes sense
to differentiate these two cases: As a user of the JAXP parser factories
I won't really care how the default implementation is instantiated,
will I? So indeed - I think we should merge the two!
Thanks,
-- daniel
>
> Mandy
>
> On 12/5/2012 8:17 AM, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a revised version of the changes for
>> the javax.xml.parsers package.
>>
>> It hopefully incorporates all comments I have received so far.
>>
>>
>>
>>
>> * better wording/formating for Javadoc changes
>> * using for( : ) syntax in findServiceProvider
>> * improved // comments explaining why the additional layer of
>> RuntimeException is needed when wrapping ServiceConfigurationError.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 12/4/12 2:54 PM, Alan Bateman wrote:
>>> On 03/12/2012 19:04, Daniel Fuchs wrote:
>>>> Hi,
>>>>
>>>> This is a first webrev in a series that addresses a change intended
>>>> for JDK 8:
>>>>
>>>> 7169894: JAXP Plugability Layer: using service loader
>>>>
>>>> I've been building up on Joe's work and Paul & Alan comments
>>>> from an earlier discussion thread [1]
>>>>
>>>> This here addresses changes in the javax.xml.parsers
>>>> package for the SAXParserFactory and DocumentBuilderFactory - and
>>>> more specifically their no-argument newInstance() method.
>>>>
>>>> This change replaces the custom code that was reading the
>>>> META-INF/services/ resources by a simple call to ServiceLoader.
>>>>
>>>>
>>>>
>>>>
>>> Thank you very much for taking this one on. I think your approach to
>>> take javax.xml.parsers on its own is good as the previous review rounds
>>> got really stuck in the mire due to the number of factories, code
>>> duplication, and subtle specification and implementation differences.
>>>
>>> In the class descriptions it suggests that the default implementation
>>> may be "installed as a module" but we aren't there yet so I'm not sure
>>> about using the term "module". I think it should be okay to say
>>> "installed as an extension" as ServiceLoader uses this term.
>>>
>>> The class description also suggests that a SCE will be wrapped as a
>>> FactoryConfigurationException but in FactoryFinder I see that it actual
>>> wraps a RuntimeException. I think you can just use the no-arg
>>> constructor then then use initCause to set the cause to the SCE.
>>>
>>> Also the statement "If a misconfigured provider is encountered and SCE
>>> is thrown" can probably be changed to "If SCE is thrown" as it can be
>>> thrown for other reasons too.
>>>
>>> Minor nit is that the updates to DocumentBuilderFactory's class
>>> description requires a really wide screen compared to the rest of the
>>> javadoc.
>>>
>>> Minor implementation suggestion for findServiceProvider is that you can
>>> use for-each to iterate through the providers.
>>>
>>> Otherwise I think you've captured all the points of feedback from the
>>> original review.
>>>
>>> Finally one suggestion is to make keep notes on the "before & after"
>>> behavior, this is something that will be important for release and
>>> compatibility notes.
>>>
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>
From dl at cs.oswego.edu Thu Dec 6 11:32:35 2012
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 06 Dec 2012 06:32:35 -0500
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C055ED.1040602@univ-mlv.fr>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr>
Message-ID: <50C08253.9030904@cs.oswego.edu>
On 12/06/12 03:23, Remi Forax wrote:
> On 12/06/2012 06:10 AM, David Holmes wrote:
>> On 6/12/2012 5:39 AM, Akhil Arora wrote:
>>> This patch adds a constructor to ThreadLocal to supply initial values
>>> using the new Supplier functional interface. Please review. This work was
>>> done by Jim Gish.
>>>
>>> http://cr.openjdk.java.net/~akhil/8003246.0/webrev/
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003246
>> ...
>
> There are two good reasons to provide a new ThreadLocal<>(() ->
> initialValue), if all goes as planned, every Supplier will share the same
> class so instead of having one class by thread local that want to specify an
> initialValue, we will have only 2 classes (or 3 if the ThreadLocal that takes
> a Supplier is a subclass) in memory.
These seem like really good reasons to implement as you
suggested in last post, with a static factory that uses a non-public
*final* subclass that wires initialValue to supplier call,
and not otherwise modifying the ThreadLocal class.
It has the added benefit of, by not touching ThreadLocal,
guaranteeing that it is time/space-neutral for other existing
uses. Which also means that any future time/space improvements
in ThreadLocal will not need to be constrained by this change.
Jim/Akhil, could you please redo it this way?
> Also, letting people to subclass ThreadLocal is not a good idea because if in
> one location someone decide to override get() to by example add a logging
> code (I've seen a similar problem) then suddenly all the codes that use
> ThreadLocal.get() will not be able to inline it.
(Yes. We see this when our (very heavy) uses of ThreadLocal
inside j.u.c. go from fast to slow mode due to overrides in other
unrelated ThreadLocal classes in application code. I've many
times considered introducing a "JDK-internal" variant of
ThreadLocal to protect against such things. Possibly even
one with only a finite fixed capacity, that would allow
further speed ups. Or maybe just introducing say a dozen
extra dedicated fields in class Thread, making it optimally fast
at the expense of non-extensibility.)
-Doug
From peter.levart at gmail.com Thu Dec 6 11:32:52 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 06 Dec 2012 12:32:52 +0100
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To: <50BF371A.1060604@oracle.com>
References: <50BF371A.1060604@oracle.com>
Message-ID: <50C08264.80804@gmail.com>
Hi David,
What about a middle-ground mode where findLoadedClass() and delegation
to parent would be called without locks and only findClass() would be
guarded by a per-class-name-per-classloader lock? In this mode
concurrent attempts to define the same class would still be possible,
but the possibility would be much lower. Usually findClass() involves
non-ignorable level of resource-intensive work (ZIP, IO, NET) before it
calls defineClass()...
Also, in this mode, the Map of locks could be implemented so that lock
objects would be Weak(ly)Reference(d), since requests for already loaded
classes would be satisfied by findLoadedClass() already. We'd just need
a ConcurrentWeakValuesHashMap.
There must be something I'm missing here, isn't it?
Regards, Peter
On 12/05/2012 12:59 PM, David Holmes wrote:
> Java 7 introduced support for parallel classloading by adding to each
> class loader a ConcurrentHashMap, referenced through a new field,
> parallelLockMap. This contains a mapping from class names to Objects
> to use as a classloading lock for that class name. This scheme has a
> number of inefficiencies. To address this we propose for Java 8 the
> notion of a fully concurrent classloader ...
>
> This is a fairly simple proposal that I've written up as a blog entry:
>
> https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent
>
>
> Please discuss this proposal here.
>
> Thanks,
> David Holmes
>
From Alan.Bateman at oracle.com Thu Dec 6 11:35:33 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 06 Dec 2012 11:35:33 +0000
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To: <50BF371A.1060604@oracle.com>
References: <50BF371A.1060604@oracle.com>
Message-ID: <50C08305.90907@oracle.com>
On 05/12/2012 11:59, David Holmes wrote:
> Java 7 introduced support for parallel classloading by adding to each
> class loader a ConcurrentHashMap, referenced through a new field,
> parallelLockMap. This contains a mapping from class names to Objects
> to use as a classloading lock for that class name. This scheme has a
> number of inefficiencies. To address this we propose for Java 8 the
> notion of a fully concurrent classloader ...
>
> This is a fairly simple proposal that I've written up as a blog entry:
>
> https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent
>
The jdk7 implementation is very unfortunate, it's a pity this wasn't
caught before 7 shipped.
I think the proposal is good, it preserves compatibility, and if there
are loaders calling registerAsParallelCapable now (probably very few)
then it they may be able to change to using registerAsFullyConcurrent
without too much work.
I am tempted to suggest that registerAsParallelCapable should be
deprecated too.
-Alan.
From vitalyd at gmail.com Thu Dec 6 11:56:02 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 6 Dec 2012 06:56:02 -0500
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C08253.9030904@cs.oswego.edu>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
Message-ID:
Doug,
When you see the fast to slow ThreadLocal transition due to class loading
invalidating inlined get(), do you not then see it get restored back to
fast mode since the receiver type in your call sites is still the
monomorphic ThreadLocal (and not the unrelated subclasses)? Just trying to
understand what R?mi and you are saying.
Thanks
Sent from my phone
On Dec 6, 2012 6:33 AM, "Doug Lea" wrote:
> On 12/06/12 03:23, Remi Forax wrote:
>
>> On 12/06/2012 06:10 AM, David Holmes wrote:
>>
>>> On 6/12/2012 5:39 AM, Akhil Arora wrote:
>>>
>>>> This patch adds a constructor to ThreadLocal to supply initial values
>>>> using the new Supplier functional interface. Please review. This work
>>>> was
>>>> done by Jim Gish.
>>>>
>>>> http://cr.openjdk.java.net/~**akhil/8003246.0/webrev/
>>>> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8003246
>>>>
>>> ...
>>>
>>
>> There are two good reasons to provide a new ThreadLocal<>(() ->
>> initialValue), if all goes as planned, every Supplier will share the same
>> class so instead of having one class by thread local that want to specify
>> an
>> initialValue, we will have only 2 classes (or 3 if the ThreadLocal that
>> takes
>> a Supplier is a subclass) in memory.
>>
>
>
> These seem like really good reasons to implement as you
> suggested in last post, with a static factory that uses a non-public
> *final* subclass that wires initialValue to supplier call,
> and not otherwise modifying the ThreadLocal class.
> It has the added benefit of, by not touching ThreadLocal,
> guaranteeing that it is time/space-neutral for other existing
> uses. Which also means that any future time/space improvements
> in ThreadLocal will not need to be constrained by this change.
>
> Jim/Akhil, could you please redo it this way?
>
>
> Also, letting people to subclass ThreadLocal is not a good idea because
>> if in
>> one location someone decide to override get() to by example add a logging
>> code (I've seen a similar problem) then suddenly all the codes that use
>> ThreadLocal.get() will not be able to inline it.
>>
>
> (Yes. We see this when our (very heavy) uses of ThreadLocal
> inside j.u.c. go from fast to slow mode due to overrides in other
> unrelated ThreadLocal classes in application code. I've many
> times considered introducing a "JDK-internal" variant of
> ThreadLocal to protect against such things. Possibly even
> one with only a finite fixed capacity, that would allow
> further speed ups. Or maybe just introducing say a dozen
> extra dedicated fields in class Thread, making it optimally fast
> at the expense of non-extensibility.)
>
> -Doug
>
>
>
From chris.hegarty at oracle.com Thu Dec 6 11:59:58 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 06 Dec 2012 11:59:58 +0000
Subject: Request for Review : CR#8004015 : [final (?) pass] Add interface
extends and defaults for basic functional interfaces
In-Reply-To: <50C035F5.4050007@oracle.com>
References:
<0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com>
<50C035F5.4050007@oracle.com>
Message-ID: <50C088BE.1040403@oracle.com>
Mike,
Some small comments.
1) IntUnaryOperator.java
Typo in:
+ 30 * This is the primitive type specialization of {@link
IntUnaryOperator} for
+ 31 * {@code int} and also may be used as a {@code
IntUnaryOperator}. When
+ 32 * used as a {@code IntUnaryOperator} the default {@code
operate} implementation
+ 33 * provided by this interface neither accepts null parameters
nor does it return
+ 34 * null results.
IntUnaryOperator -> UnaryOperator
2) Double/Int/Long Function
"When used as a Function the default apply implementation provided
by this interface neither accepts null parameters nor does it
return null results."
"When used as a Function", is this really necessary, or should the
behavior of the default apply method just be described?
Why the restriction on null parameters, it seems overly restrictive
since applyAsXXXX accepts nulls, right?
3) package description
"null values are accepted and returned by these functional
interfaces according to the constraints of the specification in
which the functional interfaces are used. The functional interfaces
themselves do not constrain or mandate use of null values. Most
usages of the functional interfaces will define the role, if any,
of null for that context."
Given these changes, doesn't this need to be reworked ( to indicate
that some methods specify null value behavior)?
4) Trivially, IntSupplier is missing a '', before "This is the
primitive type..."
5) I agree with David, NPE should be defined where applicable.
-Chris.
On 12/06/2012 06:06 AM, David Holmes wrote:
> On 6/12/2012 4:20 AM, Mike Duigou wrote:
>> I have updated webrev again to fix some reported javadoc technical
>> issues and added null handling specification to the
>> {Int|Double|Long}Supplier.
>>
>> http://cr.openjdk.java.net/~mduigou/8004015/2/webrev/
>> http://cr.openjdk.java.net/~mduigou/8004015/2/specdiff/java/util/function/package-summary.html
>>
>>
>> I believe that this iteration is complete (or very nearly so).
>
> Sorry to be a pain but this:
>
> left - the left operand, must be non-null
>
> doesn't tell you what happens if it is null. Is it not better to simply
> have:
>
> @param left the left operand
> @param right the right operand
> @throws NullPointerException if either left or right are null
>
> ?
>
> David
> -----
>
>
>> Mike
>>
>> On Dec 4 2012, at 21:47 , Mike Duigou wrote:
>>
>>> Hello all;
>>>
>>> I have updated the proposed patch. The changes primarily add class
>>> and method documentation regarding handling of null for the primitive
>>> specializations.
>>>
>>> http://cr.openjdk.java.net/~mduigou/8004015/1/webrev/
>>> http://cr.openjdk.java.net/~mduigou/8004015/1/specdiff/java/util/function/package-summary.html
>>>
>>>
>>> I've also reformatted the source for the default methods.
>>>
>>> Mike
>>>
>>>
>>> On Nov 26 2012, at 18:12 , Mike Duigou wrote:
>>>
>>>> Hello all;
>>>>
>>>> In the original patch which added the basic lambda functional
>>>> interfaces, CR#8001634 [1], none of the interfaces extended other
>>>> interfaces. The reason was primarily that the javac compiler did
>>>> not, at the time that 8001634 was proposed, support extension
>>>> methods. The compiler now supports adding of method defaults so this
>>>> patch improves the functional interfaces by filing in the
>>>> inheritance hierarchy.
>>>>
>>>> Adding the parent interfaces and default methods allows each
>>>> functional interface to be used in more places. It is especially
>>>> important for the functional interfaces which support primitive
>>>> types, IntSupplier, IntFunction, IntUnaryOperator,
>>>> IntBinaryOperator, etc. We expect that eventually standard
>>>> implementations of these interfaces will be provided for functions
>>>> like max, min, sum, etc. By extending the reference oriented
>>>> functional interfaces such as Function, the primitive
>>>> implementations can be used with the boxed primitive types along
>>>> with the primitive types for which they are defined.
>>>>
>>>> The patch to add parent interfaces and default methods can be found
>>>> here:
>>>>
>>>> http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/
>>>> http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html
>>>>
>>>>
>>>> Mike
>>>>
>>>> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e80176a697
>>>
>>
>>
From dl at cs.oswego.edu Thu Dec 6 12:03:45 2012
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 06 Dec 2012 07:03:45 -0500
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To:
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
Message-ID: <50C089A1.3090500@cs.oswego.edu>
On 12/06/12 06:56, Vitaly Davidovich wrote:
> Doug,
>
> When you see the fast to slow ThreadLocal transition due to class loading
> invalidating inlined get(), do you not then see it get restored back to fast
> mode since the receiver type in your call sites is still the monomorphic
> ThreadLocal (and not the unrelated subclasses)? Just trying to understand what
> R?mi and you are saying.
>
The possible outcomes are fairly non-deterministic, depending
on hotspot's mood about recompiles, tiered-compile interactions,
method size, Amddahl's law interactions, phase of moon, etc.
(In j.u.c, we have learned that our users appreciate things
being predictably fast enough rather than being
unpredictably sometimes even faster but often slower.
So when we see such cases, as with ThreadLocal, they get added
to todo list.)
-Doug
From vitalyd at gmail.com Thu Dec 6 12:12:11 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 6 Dec 2012 07:12:11 -0500
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C089A1.3090500@cs.oswego.edu>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C089A1.3090500@cs.oswego.edu>
Message-ID:
Understood - I'm just trying to make sure I don't have the wrong mental
model of this in my mind. Taking pathology aside (e.g. code cache is full
when time to recompile, poor tiering interaction, etc), I'd expect the fast
inlined path to be restored assuming call site type profile (of the ones we
care about) doesn't change after other subclasses are loaded. Would be
good if someone can correct that if it's inaccurate. Apologies if this is
slightly hijacking the thread, but it's Remi's fault :).
Sent from my phone
On Dec 6, 2012 7:03 AM, "Doug Lea" wrote:
> On 12/06/12 06:56, Vitaly Davidovich wrote:
>
>> Doug,
>>
>> When you see the fast to slow ThreadLocal transition due to class loading
>> invalidating inlined get(), do you not then see it get restored back to
>> fast
>> mode since the receiver type in your call sites is still the monomorphic
>> ThreadLocal (and not the unrelated subclasses)? Just trying to understand
>> what
>> R?mi and you are saying.
>>
>>
> The possible outcomes are fairly non-deterministic, depending
> on hotspot's mood about recompiles, tiered-compile interactions,
> method size, Amddahl's law interactions, phase of moon, etc.
>
> (In j.u.c, we have learned that our users appreciate things
> being predictably fast enough rather than being
> unpredictably sometimes even faster but often slower.
> So when we see such cases, as with ThreadLocal, they get added
> to todo list.)
>
> -Doug
>
>
>
>
>
From david.holmes at oracle.com Thu Dec 6 12:42:59 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 06 Dec 2012 22:42:59 +1000
Subject: Review Request: 8004201: add reducers to primitive type wrappers
In-Reply-To: <50BFBC49.9020200@oracle.com>
References: <50B8FE8A.2030403@oracle.com> <50BC0576.4070202@oracle.com>
<50BFBC49.9020200@oracle.com>
Message-ID: <50C092D3.4020201@oracle.com>
On 6/12/2012 7:27 AM, Akhil Arora wrote:
> Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/
>
> - delegate to Math.min/max for int/long/float/double
> - rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor
> - removed Character variants of min/max/sum
>
> On 12/02/2012 05:50 PM, David Holmes wrote:
>> Is it really necessary/desirable to flag all of these as " Suitable for
>> conversion as a method reference to functional interfaces such as ..." ?
>
> Not necessary, but it does provide a hint as to their intended use to a
> casual browser of these docs.
I don't find it desirable either.
>> This style:
>>
>> + * @param a a boolean argument.
>> + * @param b another boolean argument.
>>
>> is at odds with the style used elsewhere for new Functional APIs, and
>> with the style of other methods in these classes. Can we just use "first
>> operand" and "second operand" for all of these?
>
> It is consistent with Math.min/max, which use the a/b style. Since these
> methods are not in one of the functional package, is'nt it better to
> stick to the local style?
Why do you consider Math to be representative of "local style"? Math
isn't even internally consistent with its style - see Math.max versus
Math.addExact etc. And Math doesn't include the arguments type in its
description. (Consistency is not a strong point in the Java APIs :( )
Given these are being added to support the new functional type I suggest
using the same style as for the functional types.
>> Character.sum does not make sense to me. Who adds together characters?
>> I'm not even sure min and max are worth supporting for Character.
>
> Good point - removed these methods for Character.
>
>> I disagree with other suggestions to use the Math functions for
>> float/double. I think all these methods should use the underlying
>> primitive operator regardless of type.
>
> Are you disagreeing only for float/double or for int/long also? Can you
> provide more information as to why you disagree?
I withdraw my objection.
David
-----
> Thanks
>
>> Thanks,
>> David
>> -----
>>
>> On 1/12/2012 4:44 AM, Akhil Arora wrote:
>>> Hi
>>>
>>> Requesting review for some basic functionality related to lambdas -
>>>
>>> Add min, max, sum methods to the primitive wrapper classes - Byte,
>>> Short, Integer, Long, Float, Double and Character so as to be able to
>>> use them as reducers in lambda expressions. Add and, or, xor methods to
>>> Boolean.
>>>
>>> http://cr.openjdk.java.net/~akhil/8004201.0/webrev/
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201
>>>
>>> Thanks
>
From david.lloyd at redhat.com Thu Dec 6 15:06:56 2012
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 06 Dec 2012 09:06:56 -0600
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To: <50C08305.90907@oracle.com>
References: <50BF371A.1060604@oracle.com> <50C08305.90907@oracle.com>
Message-ID: <50C0B490.7050005@redhat.com>
On 12/06/2012 05:35 AM, Alan Bateman wrote:
> On 05/12/2012 11:59, David Holmes wrote:
>> Java 7 introduced support for parallel classloading by adding to each
>> class loader a ConcurrentHashMap, referenced through a new field,
>> parallelLockMap. This contains a mapping from class names to Objects
>> to use as a classloading lock for that class name. This scheme has a
>> number of inefficiencies. To address this we propose for Java 8 the
>> notion of a fully concurrent classloader ...
>>
>> This is a fairly simple proposal that I've written up as a blog entry:
>>
>> https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent
>>
> The jdk7 implementation is very unfortunate, it's a pity this wasn't
> caught before 7 shipped.
>
> I think the proposal is good, it preserves compatibility, and if there
> are loaders calling registerAsParallelCapable now (probably very few)
> then it they may be able to change to using registerAsFullyConcurrent
> without too much work.
>
> I am tempted to suggest that registerAsParallelCapable should be
> deprecated too.
I'm sorry I missed the original post, and I just want to add my
wholehearted support for this idea. Our application server's class
loader implementation can be configured (on certain JVMs) to run in a
lock-free mode and we have seen good performance and memory footprint as
a result on these particular JVMs.
As far as the defineClass concurrent redefine issue goes - our current
implementation simply does a try/catch for redefinition exceptions. If
such an exception occurs, we load the concurrently defined class and
return that. In practice, even with many threads, we would see
relatively few such collisions. But, a tryDefineClass or
defineClassIfNotPresent would be a welcome addition for certain.
I'm very glad to see that Mr. Holmes has taken this initiative and found
solutions to the various stumbling blocks.
--
- DML
From mandy.chung at oracle.com Thu Dec 6 15:35:33 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 06 Dec 2012 07:35:33 -0800
Subject: Review request: 8003562: Provide a command-line tool to find
static dependencies
In-Reply-To: <50C0AD96.30407@oracle.com>
References: <50B54A2C.1040907@oracle.com> <50BFF69E.1040805@oracle.com>
<50C0AD96.30407@oracle.com>
Message-ID: <50C0BB45.9030501@oracle.com>
Thanks Erik for the help. I missed the files for images build. I'll
incorporate your patch.
Mandy
On 12/6/2012 6:37 AM, Erik Joelsson wrote:
> Hello,
>
> I've looked at the build changes and noted that the old and new build
> did not produce the same results. Here is a webrev with adjustments (I
> chose to do a full forest webrev because I needed to change a file in
> the root too):
>
> http://cr.openjdk.java.net/~erikj/8003562/webrev.03/
>
> The changes are:
>
> * Add the jdeps package to tools.jar in new build
> * Exclude jdeps from jre in new build
> * Add "-DEXPAND_CLASSPATH_WILDCARDS
> -DNEVER_ACT_AS_SERVER_CLASS_MACHINE" to compile in old build. I wasn't
> sure if these were intended for this launcher, but I'm guessing that
> it makes sense to match the settings of javap and javah. The other
> alternative is to remove these from both old and new build.
> * Add ./bin/jdeps to some exception lists in compare script. (jdeps,
> like most executables, contains the version string.)
>
> With these changes, I don't see any new regressions in the compare
> script on my machine.
>
> /Erik
>
> On 2012-12-06 02:36, Mandy Chung wrote:
>> This review request (add a new jdeps tool in the JDK) include changes in
>> langtools and the jdk build. I would need reviewers from the langtools
>> and the build-infra team.
>>
>> Webrev for review:
>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/jdeps/langtools-webrev.02/
>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/jdeps/jdk-webrev.02/
>>
>> The jdeps source is in the langtools repo. The change in the jdk
>> repo is
>> to add the new jdeps executable. I made change in the old and new build
>> for the addition of this new jdeps tool. I discussed with Jon whether I
>> should modify langtools/make/build.xml to add a new jdeps target. Since
>> the old build will be replaced by the new build soon, I simply add
>> com/sun/tools/jdeps as part of javap.includes.
>>
>> Alan,
>>
>> The -d option is kept as a hidden option and use as implementation. We
>> can remove it when it's determined not useful in the future. I also
>> rename -v:summary to -summary.
>>
>> Thanks
>> Mandy
>>
>> ----------------------------
>>
>> $ jdep -h
>> Usage: jdeps
>> where possible options include:
>> -version Version information
>> -classpath Specify where to find class files
>> -summary Print dependency summary only
>> -v:class Print class-level dependencies
>> -v:package Print package-level dependencies
>> -p Restrict analysis to classes in this package
>> (may be given multiple times)
>> -e Restrict analysis to packages matching
>> pattern
>> (-p and -e are exclusive)
>> -P --profile Show profile or the file containing a package
>> -R --recursive Traverse all dependencies recursively
>> -all Process all classes specified in -classpath
>>
>> $ jdep Notepad.jar Ensemble.jar
>> Notepad.jar -> D:\tools\devtools\jdk8\windows-i586\jre\lib\rt.jar
>> (Notepad.jar)
>> -> java.awt
>> -> java.awt.event
>> -> java.beans
>> -> java.io
>> -> java.lang
>> -> java.net
>> -> java.util
>> -> java.util.logging
>> -> javax.swing
>> -> javax.swing.border
>> -> javax.swing.event
>> -> javax.swing.text
>> -> javax.swing.tree
>> -> javax.swing.undo
>>
>> Ensemble.jar -> D:\tools\devtools\jdk8\windows-i586\jre\lib\jfxrt.jar
>> Ensemble.jar -> D:\tools\devtools\jdk8\windows-i586\jre\lib\rt.jar
>> com.javafx.main (Ensemble.jar)
>> -> java.applet
>> -> java.awt
>> -> java.awt.event
>> -> java.io
>> -> java.lang
>> -> java.lang.reflect
>> -> java.net
>> -> java.security
>> -> java.util
>> -> java.util.jar
>> -> javax.swing
>> -> sun.misc JDK internal API
>> (rt.jar)
From david.dehaven at oracle.com Thu Dec 6 16:45:23 2012
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 6 Dec 2012 08:45:23 -0800
Subject: Review request: 8004042 : Arrrghs.java test failed on windows
with access error.
In-Reply-To: <50C03083.4030102@oracle.com>
References: <99E014EB-0210-4C77-BE43-88CED80B1825@oracle.com>
<50C03083.4030102@oracle.com>
Message-ID:
>> A fix for intermittent test failures causing grief on Windows, particularly Windows 7 and 2008 systems:
>> http://cr.openjdk.java.net/~ddehaven/8004042/webrev.1/
>>
>> The underlying cause is as of yet unknown, but I was able to create an environment that caused similar failures by running "watch -n 0.2 cat JTwork/scratch/atest.bat" in another shell then running jtreg. Without the patch it would fail very regularly (especially when isolated and looped 1,000 times), with the patch it always passes.
>
> We had been discussing/speculating that the problem is the virus scanner checking the old incarnation of the file at the same time we want to create a new one. If so, and if it were to hold the file open with exclusive access, that would explain the AccessDeniedException instead of FileAlreadyExistsException (in the CREATE_NEW case).
>
> (I still don't have an explanation for why the file deletion doesn't throw an exception. That's what seems to cause jtreg some grief in its cleanup phase, and for that reason we've added retry logic to jtreg.)
I see a lot of quirky filesystem behavior just using Windows 7, especially compared to Unixish systems ? but maybe that's just me and my environment :)
> In any case I think backing off and retrying is probably what's getting us the benefit, not the adjustment of the file creation flags.
I agree? I also think this is deeper than just the virus scanner, but I've not the expertise to validate that claim.
> In any case I'd increase the number of retry attempts. The test environment is surprisingly hostile. In the RMI tests we try to open an unused network port and retry 10 times if that fails, and sometimes that's not enough. (See Jim Gish's recent changeset.)
For 8004317 (I think you pushed it yesterday)? I'll take a look at it.
That was my initial value. I backed it off thinking it was overly aggressive, but if the environment is that hostile perhaps it's not.
> InterruptedException shouldn't be ignored. Jtreg will interrupt the test if it times out, so this interruption should be handled gracefully. Perhaps, wrap the InterruptedException in an IOException and rethrow it? (Since the caller is clearly prepared to handle IOException.) Terminating the loop and returning normally doesn't seem right, since the file wasn't created successfully.
Good point! I'll add that. I think I should through RuntimeException in both cases, to be consistent.
> This is only style, but perhaps it would be good to get rid of the 'done' boolean and replace the 'done = true' statement with a 'return'. This simplifies things a bit, I think.
I rewrote it to use a for loop instead and it's much cleaner. I'll post a new webrev later today.
-DrD-
From Lance.Andersen at oracle.com Thu Dec 6 17:01:09 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 6 Dec 2012 12:01:09 -0500
Subject: signatures that are recorded for default methods
Message-ID: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com>
Folks,
Will the signatures for interfaces that are recorded by the TCKs for interfaces record the fact that a method includes a default method? or will it just record the method definition?
I am assuming it will, but I know there has been discussion that a implementor could choose a different default implementation on one of the recent threads that was up for review.
I am still trying to understand what our guidelines are, if any for documenting the behavior of the supplied default methods given the javadocs are part of the specification for many APIs (and in some case the only spec).
Best
Lance
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com
From akhil.arora at oracle.com Thu Dec 6 17:01:55 2012
From: akhil.arora at oracle.com (Akhil Arora)
Date: Thu, 06 Dec 2012 09:01:55 -0800
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C08253.9030904@cs.oswego.edu>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
Message-ID: <50C0CF83.1080208@oracle.com>
On 12/06/2012 03:32 AM, Doug Lea wrote:
>
> These seem like really good reasons to implement as you
> suggested in last post, with a static factory that uses a non-public
> *final* subclass that wires initialValue to supplier call,
> and not otherwise modifying the ThreadLocal class.
> It has the added benefit of, by not touching ThreadLocal,
> guaranteeing that it is time/space-neutral for other existing
> uses. Which also means that any future time/space improvements
> in ThreadLocal will not need to be constrained by this change.
>
> Jim/Akhil, could you please redo it this way?
redone - http://cr.openjdk.java.net/~akhil/8003246.1/webrev/
Thanks
From cs at schulte.it Thu Dec 6 17:26:10 2012
From: cs at schulte.it (Christian Schulte)
Date: Thu, 06 Dec 2012 18:26:10 +0100
Subject: Misleading documentation for class
java.nio.charset.spi.CharsetProvider
Message-ID: <50C0D532.90001@schulte.it>
Hello,
I am not sure if this is the correct mailing list to send this mail to.
Please apologize any inconvenience caused.
The JDK 7 documentation of class java.nio.charset.spi.CharsetProvider
states the following:
[...]
Charset providers are looked up via the current thread's context class
loader.
[...]
Looking at method 'private static Iterator providers()' of class
'java.nio.charset.Charset', the above documentation seems incorrect
since that method uses the system class loader.
ClassLoader cl = ClassLoader.getSystemClassLoader();
ServiceLoader sl =
ServiceLoader.load(CharsetProvider.class, cl);
Is this intended ?
Regards,
--
Christian Schulte
From brian.goetz at oracle.com Thu Dec 6 17:35:27 2012
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 06 Dec 2012 12:35:27 -0500
Subject: Review Request: 8004201: add reducers to primitive type wrappers
In-Reply-To: <50BFDC75.6000306@oracle.com>
References: <50B8FE8A.2030403@oracle.com> <50BC0576.4070202@oracle.com>
<50BFBC49.9020200@oracle.com> <50BFDC75.6000306@oracle.com>
Message-ID: <50C0D75F.3030705@oracle.com>
This suggestion makes me nervous, because we're already asking a great
deal of type inference. If you say
reduce(Operators::plus)
and there are eight versions of Operators to choose from (and add boxing
into the mix), I think we'll see a lot more inference errors. If the
user says Integer::plus, the user has already told us what we want, and
we're done.
On 12/5/2012 6:44 PM, Joseph Darcy wrote:
> Akhil,
>
> In javadoc like this
>
> 298 * as {@code BinaryOperator<Boolean>}.
>
> you don't have to use "<" and the like inside {@code}; please change to
>
> 298 * as {@code BinaryOperator}.
>
> As a general comment, if the operations for primitive type Foo are put
> into java.lang.Foo, then the type of the operation needs to be
> explicitly represented in the expression calling the method (unless
> static imports are used, etc.). Therefore, I suggest putting these sort
> of static methods all into one class to allow overloading to do its
> thing (java.lang.Operators?). Also, for methods like sum, I think it is
> worth considering returning a larger type than the operands to avoid
> problems from integer or floating-point overflow. For example, sum on
> byte and short would return int, sun on int would return long, etc.
>
> As an aside, to get a numerically robust result, the summation logic
> over a set of doubles needs to be more than just a set of raw double
> additions, but that can be tackled later.
>
> Cheers,
>
> -Joe
>
>
> On 12/5/2012 1:27 PM, Akhil Arora wrote:
>> Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/
>>
>> - delegate to Math.min/max for int/long/float/double
>> - rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor
>> - removed Character variants of min/max/sum
>>
>> On 12/02/2012 05:50 PM, David Holmes wrote:
>>> Hi Akhil,
>>>
>>> Is it really necessary/desirable to flag all of these as " Suitable for
>>> conversion as a method reference to functional interfaces such as ..." ?
>> Not necessary, but it does provide a hint as to their intended use to a
>> casual browser of these docs.
>>
>>> This style:
>>>
>>> + * @param a a boolean argument.
>>> + * @param b another boolean argument.
>>>
>>> is at odds with the style used elsewhere for new Functional APIs, and
>>> with the style of other methods in these classes. Can we just use "first
>>> operand" and "second operand" for all of these?
>> It is consistent with Math.min/max, which use the a/b style. Since these
>> methods are not in one of the functional package, is'nt it better to
>> stick to the local style?
>>
>>> Character.sum does not make sense to me. Who adds together characters?
>>> I'm not even sure min and max are worth supporting for Character.
>> Good point - removed these methods for Character.
>>
>>> I disagree with other suggestions to use the Math functions for
>>> float/double. I think all these methods should use the underlying
>>> primitive operator regardless of type.
>> Are you disagreeing only for float/double or for int/long also? Can you
>> provide more information as to why you disagree?
>>
>> Thanks
>>
>>> Thanks,
>>> David
>>> -----
>>>
>>> On 1/12/2012 4:44 AM, Akhil Arora wrote:
>>>> Hi
>>>>
>>>> Requesting review for some basic functionality related to lambdas -
>>>>
>>>> Add min, max, sum methods to the primitive wrapper classes - Byte,
>>>> Short, Integer, Long, Float, Double and Character so as to be able to
>>>> use them as reducers in lambda expressions. Add and, or, xor methods to
>>>> Boolean.
>>>>
>>>> http://cr.openjdk.java.net/~akhil/8004201.0/webrev/
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201
>>>>
>>>> Thanks
>>
>
From chris.hegarty at oracle.com Thu Dec 6 17:36:26 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 06 Dec 2012 17:36:26 +0000
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C0CF83.1080208@oracle.com>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C0CF83.1080208@oracle.com>
Message-ID: <50C0D79A.9020006@oracle.com>
Thank you Akhil, this looks much better.
I'm not completely comfortable with, "The initial value of the variable
is provided by calling the {@code intialValue} method." Similarly, " The
initial value of the variable is determined by invoking the {@code get}
method on the {@code Supplier."
Should these statements defer to the text in initialValue? Or maybe just
leave out the additional text in the no-args constructor, and have
withInitial() just describe its implementation? My concern is with the
omission of the behavior of set(), and the term 'initial value' could be
misinterpreted.
Anyway, I'm relatively happy with this, let's see what others think.
-Chris.
On 12/06/2012 05:01 PM, Akhil Arora wrote:
> On 12/06/2012 03:32 AM, Doug Lea wrote:
>>
>> These seem like really good reasons to implement as you
>> suggested in last post, with a static factory that uses a non-public
>> *final* subclass that wires initialValue to supplier call,
>> and not otherwise modifying the ThreadLocal class.
>> It has the added benefit of, by not touching ThreadLocal,
>> guaranteeing that it is time/space-neutral for other existing
>> uses. Which also means that any future time/space improvements
>> in ThreadLocal will not need to be constrained by this change.
>>
>> Jim/Akhil, could you please redo it this way?
>
> redone - http://cr.openjdk.java.net/~akhil/8003246.1/webrev/
>
> Thanks
From daniel.fuchs at oracle.com Thu Dec 6 17:38:13 2012
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 06 Dec 2012 18:38:13 +0100
Subject: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser
factories (7169894: JAXP Plugability Layer: using service loader)
In-Reply-To: <50C06DAC.5050500@oracle.com>
References: <50BCF7CD.1020308@oracle.com> <50BE007A.4090102@oracle.com>
<50BF73B2.5000102@oracle.com> <50C06DAC.5050500@oracle.com>
Message-ID: <50C0D805.5030509@oracle.com>
Updated the javadoc for newInstance():
-- daniel
On 12/6/12 11:04 AM, Alan Bateman wrote:
> On 05/12/2012 16:17, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a revised version of the changes for
>> the javax.xml.parsers package.
>>
>> It hopefully incorporates all comments I have received so far.
>>
>>
>>
>>
>> * better wording/formating for Javadoc changes
>> * using for( : ) syntax in findServiceProvider
>> * improved // comments explaining why the additional layer of
>> RuntimeException is needed when wrapping ServiceConfigurationError.
>>
>> best regards,
>>
>> -- daniel
> You've addressed all my comments and I think this looks very good.
>
> One other comment. Now that the wording is "Otherwise the default
> implementation, if present, is returned" it raises the question as to
> how what happens if the default implementation is not present. A
> suggestion is to just handle it in the next statement, something like
> "In the case of a SCE or the default provider is not present, then FCE
> will be thrown".
>
> I see Mandy's comment about the bullet item "Platform default
> DocumentBuilderFactory instance". I hadn't noticed this but
> I assume this should just be removed now.
>
> -Alan.
From dl at cs.oswego.edu Thu Dec 6 17:38:34 2012
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 06 Dec 2012 12:38:34 -0500
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C0CF83.1080208@oracle.com>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C0CF83.1080208@oracle.com>
Message-ID: <50C0D81A.5030607@cs.oswego.edu>
On 12/06/12 12:01, Akhil Arora wrote:
>
> redone - http://cr.openjdk.java.net/~akhil/8003246.1/webrev/
>
Much better; thanks!
As a minor matter, it probably makes sense to give that class a
name. Even though it is a non-public static class, the name
will be seen here and there by debuggers, stacktraces, etc,
and the default "$" name will be confusing. As in:
static final class SuppliedThreadLocal extends ThreadLocal ..
public static ThreadLocal withInitial(Supplier supplier) {
return new SuppliedThreadLocal(supplier);
}
From david.dehaven at oracle.com Thu Dec 6 17:41:14 2012
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 6 Dec 2012 09:41:14 -0800
Subject: Review request: 8004042 : Arrrghs.java test failed on windows
with access error.
In-Reply-To:
References: <99E014EB-0210-4C77-BE43-88CED80B1825@oracle.com>
<50C03083.4030102@oracle.com>
Message-ID:
New webrev posted:
http://cr.openjdk.java.net/~ddehaven/8004042/webrev.2/
Summary:
- Cleaned it up a bit by change to a for loop (eliminating done flag)
- Throws RuntimeException instead of IOException, handles InterruptedException
- Bumped retry count to 10
- Changed @run mode to "main/othervm" as suggested by Kumar
-DrD-
From Alan.Bateman at oracle.com Thu Dec 6 17:50:27 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 06 Dec 2012 17:50:27 +0000
Subject: Misleading documentation for class
java.nio.charset.spi.CharsetProvider
In-Reply-To: <50C0D532.90001@schulte.it>
References: <50C0D532.90001@schulte.it>
Message-ID: <50C0DAE3.3070905@oracle.com>
On 06/12/2012 17:26, Christian Schulte wrote:
> Hello,
>
> I am not sure if this is the correct mailing list to send this mail to.
> Please apologize any inconvenience caused.
>
> The JDK 7 documentation of class java.nio.charset.spi.CharsetProvider
> states the following:
>
> [...]
> Charset providers are looked up via the current thread's context class
> loader.
> [...]
>
> Looking at method 'private static Iterator providers()' of class
> 'java.nio.charset.Charset', the above documentation seems incorrect
> since that method uses the system class loader.
>
> ClassLoader cl = ClassLoader.getSystemClassLoader();
> ServiceLoader sl =
> ServiceLoader.load(CharsetProvider.class, cl);
>
> Is this intended ?
>
This is a long standing issue (going back to 1.4), we should remove this
from the javadoc.
-Alan.
From akhil.arora at oracle.com Thu Dec 6 18:00:41 2012
From: akhil.arora at oracle.com (Akhil Arora)
Date: Thu, 06 Dec 2012 10:00:41 -0800
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C0D81A.5030607@cs.oswego.edu>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C0CF83.1080208@oracle.com> <50C0D81A.5030607@cs.oswego.edu>
Message-ID: <50C0DD49.4060900@oracle.com>
On 12/06/2012 09:38 AM, Doug Lea wrote:
> Much better; thanks!
> As a minor matter, it probably makes sense to give that class a
> name. Even though it is a non-public static class, the name
> will be seen here and there by debuggers, stacktraces, etc,
> and the default "$" name will be confusing. As in:
>
>
> static final class SuppliedThreadLocal extends ThreadLocal ..
>
> public static ThreadLocal withInitial(Supplier
> supplier) {
> return new SuppliedThreadLocal(supplier);
> }
http://cr.openjdk.java.net/~akhil/8003246.2/webrev/
- added SuppliedThreadLocal inner class
- reverted javadoc changes to no-args constructor
- added null check for Supplier
Thanks
From akhil.arora at oracle.com Thu Dec 6 18:15:22 2012
From: akhil.arora at oracle.com (Akhil Arora)
Date: Thu, 06 Dec 2012 10:15:22 -0800
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C028DF.2030303@oracle.com>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
Message-ID: <50C0E0BA.5010005@oracle.com>
On 12/05/2012 09:10 PM, David Holmes wrote:
> Was there a CCC request for this?
Yes, a CCC was submitted on Nov 12, but it was deferred pending a
discussion on this alias. I just updated and resubmitted the CCC based
on Doug and Remi's suggestions.
From dl at cs.oswego.edu Thu Dec 6 18:29:06 2012
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 06 Dec 2012 13:29:06 -0500
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C0DD49.4060900@oracle.com>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C0CF83.1080208@oracle.com> <50C0D81A.5030607@cs.oswego.edu>
<50C0DD49.4060900@oracle.com>
Message-ID: <50C0E3F2.9030004@cs.oswego.edu>
On 12/06/12 13:00, Akhil Arora wrote:
> http://cr.openjdk.java.net/~akhil/8003246.2/webrev/
>
> - added SuppliedThreadLocal inner class
> - reverted javadoc changes to no-args constructor
> - added null check for Supplier
>
Great! Thanks for the quick response.
-Doug
From forax at univ-mlv.fr Thu Dec 6 18:47:46 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 06 Dec 2012 19:47:46 +0100
Subject: Review Request: 8004201: add reducers to primitive type wrappers
In-Reply-To: <50C0D75F.3030705@oracle.com>
References: <50B8FE8A.2030403@oracle.com> <50BC0576.4070202@oracle.com>
<50BFBC49.9020200@oracle.com> <50BFDC75.6000306@oracle.com>
<50C0D75F.3030705@oracle.com>
Message-ID: <50C0E852.7090109@univ-mlv.fr>
On 12/06/2012 06:35 PM, Brian Goetz wrote:
> This suggestion makes me nervous, because we're already asking a great
> deal of type inference. If you say
>
> reduce(Operators::plus)
>
> and there are eight versions of Operators to choose from (and add
> boxing into the mix), I think we'll see a lot more inference errors.
> If the user says Integer::plus, the user has already told us what we
> want, and we're done.
I think that rule for method references are strong enough (unlike lambda
you don't have to guess the type of the formal parameter) to work here,
but we should not play with the devil.
R?mi
>
> On 12/5/2012 6:44 PM, Joseph Darcy wrote:
>> Akhil,
>>
>> In javadoc like this
>>
>> 298 * as {@code BinaryOperator<Boolean>}.
>>
>> you don't have to use "<" and the like inside {@code}; please
>> change to
>>
>> 298 * as {@code BinaryOperator}.
>>
>> As a general comment, if the operations for primitive type Foo are put
>> into java.lang.Foo, then the type of the operation needs to be
>> explicitly represented in the expression calling the method (unless
>> static imports are used, etc.). Therefore, I suggest putting these sort
>> of static methods all into one class to allow overloading to do its
>> thing (java.lang.Operators?). Also, for methods like sum, I think it is
>> worth considering returning a larger type than the operands to avoid
>> problems from integer or floating-point overflow. For example, sum on
>> byte and short would return int, sun on int would return long, etc.
>>
>> As an aside, to get a numerically robust result, the summation logic
>> over a set of doubles needs to be more than just a set of raw double
>> additions, but that can be tackled later.
>>
>> Cheers,
>>
>> -Joe
>>
>>
>> On 12/5/2012 1:27 PM, Akhil Arora wrote:
>>> Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/
>>>
>>> - delegate to Math.min/max for int/long/float/double
>>> - rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor
>>> - removed Character variants of min/max/sum
>>>
>>> On 12/02/2012 05:50 PM, David Holmes wrote:
>>>> Hi Akhil,
>>>>
>>>> Is it really necessary/desirable to flag all of these as " Suitable
>>>> for
>>>> conversion as a method reference to functional interfaces such as
>>>> ..." ?
>>> Not necessary, but it does provide a hint as to their intended use to a
>>> casual browser of these docs.
>>>
>>>> This style:
>>>>
>>>> + * @param a a boolean argument.
>>>> + * @param b another boolean argument.
>>>>
>>>> is at odds with the style used elsewhere for new Functional APIs, and
>>>> with the style of other methods in these classes. Can we just use
>>>> "first
>>>> operand" and "second operand" for all of these?
>>> It is consistent with Math.min/max, which use the a/b style. Since
>>> these
>>> methods are not in one of the functional package, is'nt it better to
>>> stick to the local style?
>>>
>>>> Character.sum does not make sense to me. Who adds together characters?
>>>> I'm not even sure min and max are worth supporting for Character.
>>> Good point - removed these methods for Character.
>>>
>>>> I disagree with other suggestions to use the Math functions for
>>>> float/double. I think all these methods should use the underlying
>>>> primitive operator regardless of type.
>>> Are you disagreeing only for float/double or for int/long also? Can you
>>> provide more information as to why you disagree?
>>>
>>> Thanks
>>>
>>>> Thanks,
>>>> David
>>>> -----
>>>>
>>>> On 1/12/2012 4:44 AM, Akhil Arora wrote:
>>>>> Hi
>>>>>
>>>>> Requesting review for some basic functionality related to lambdas -
>>>>>
>>>>> Add min, max, sum methods to the primitive wrapper classes - Byte,
>>>>> Short, Integer, Long, Float, Double and Character so as to be able to
>>>>> use them as reducers in lambda expressions. Add and, or, xor
>>>>> methods to
>>>>> Boolean.
>>>>>
>>>>> http://cr.openjdk.java.net/~akhil/8004201.0/webrev/
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201
>>>>>
>>>>> Thanks
>>>
>>
From peter.levart at gmail.com Thu Dec 6 19:01:41 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 06 Dec 2012 20:01:41 +0100
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C089A1.3090500@cs.oswego.edu>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C089A1.3090500@cs.oswego.edu>
Message-ID: <50C0EB95.6070800@gmail.com>
There's a quick trick that guarantees in-lining of get/set/remove:
public static class FastThreadLocal extends ThreadLocal {
@Override
public final T get() { return super.get(); }
@Override
public final void set(T value) { super.set(value); }
@Override
public final void remove() { super.remove(); }
}
....just use static type FastThreadLocal everywhere in code.
I tried it and it works.
Regards, Peter
On 12/06/2012 01:03 PM, Doug Lea wrote:
> On 12/06/12 06:56, Vitaly Davidovich wrote:
>> Doug,
>>
>> When you see the fast to slow ThreadLocal transition due to class
>> loading
>> invalidating inlined get(), do you not then see it get restored back
>> to fast
>> mode since the receiver type in your call sites is still the monomorphic
>> ThreadLocal (and not the unrelated subclasses)? Just trying to
>> understand what
>> R?mi and you are saying.
>>
>
> The possible outcomes are fairly non-deterministic, depending
> on hotspot's mood about recompiles, tiered-compile interactions,
> method size, Amddahl's law interactions, phase of moon, etc.
>
> (In j.u.c, we have learned that our users appreciate things
> being predictably fast enough rather than being
> unpredictably sometimes even faster but often slower.
> So when we see such cases, as with ThreadLocal, they get added
> to todo list.)
>
> -Doug
>
>
>
>
From forax at univ-mlv.fr Thu Dec 6 19:02:33 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 06 Dec 2012 20:02:33 +0100
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C0E3F2.9030004@cs.oswego.edu>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C0CF83.1080208@oracle.com> <50C0D81A.5030607@cs.oswego.edu>
<50C0DD49.4060900@oracle.com> <50C0E3F2.9030004@cs.oswego.edu>
Message-ID: <50C0EBC9.2070101@univ-mlv.fr>
On 12/06/2012 07:29 PM, Doug Lea wrote:
> On 12/06/12 13:00, Akhil Arora wrote:
>
>> http://cr.openjdk.java.net/~akhil/8003246.2/webrev/
>>
>> - added SuppliedThreadLocal inner class
>> - reverted javadoc changes to no-args constructor
>> - added null check for Supplier
>>
>
> Great! Thanks for the quick response.
>
> -Doug
>
>
Yes, great !
just nitpicking,
return new SuppliedThreadLocal(supplier);
should be
return new SuppliedThreadLocal<>(supplier);
Also, can you add a @see in the constructor of ThreadLocal that
references ThreadLocal.withInitialValue(Supplier).
cheers,
R?mi
From mandy.chung at oracle.com Thu Dec 6 19:05:49 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 06 Dec 2012 11:05:49 -0800
Subject: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser
factories (7169894: JAXP Plugability Layer: using service loader)
In-Reply-To: <50C0D805.5030509@oracle.com>
References: <50BCF7CD.1020308@oracle.com> <50BE007A.4090102@oracle.com>
<50BF73B2.5000102@oracle.com> <50C06DAC.5050500@oracle.com>
<50C0D805.5030509@oracle.com>
Message-ID: <50C0EC8D.3080606@oracle.com>
On 12/6/12 9:38 AM, Daniel Fuchs wrote:
> Updated the javadoc for newInstance():
>
>
>
>
Looks good to me.
Nit: you may want to use @linkplain instead of @link for this:
{@link java.util.ServiceConfigurationError service configuration error},
Thanks
Mandy
From forax at univ-mlv.fr Thu Dec 6 19:08:52 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 06 Dec 2012 20:08:52 +0100
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C0EB95.6070800@gmail.com>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C089A1.3090500@cs.oswego.edu> <50C0EB95.6070800@gmail.com>
Message-ID: <50C0ED44.8030106@univ-mlv.fr>
On 12/06/2012 08:01 PM, Peter Levart wrote:
> There's a quick trick that guarantees in-lining of get/set/remove:
>
> public static class FastThreadLocal extends ThreadLocal {
> @Override
> public final T get() { return super.get(); }
>
> @Override
> public final void set(T value) { super.set(value); }
>
> @Override
> public final void remove() { super.remove(); }
> }
>
> ....just use static type FastThreadLocal everywhere in code.
>
> I tried it and it works.
No, there is no way to have such guarantee, here, it works either
because the only class ThreadLocal you load is FastThreadLocal or
because the VM has profiled the callsite see that you only use
FastThreadLocal for a specific instruction.
>
>
> Regards, Peter
cheers,
R?mi
>
> On 12/06/2012 01:03 PM, Doug Lea wrote:
>> On 12/06/12 06:56, Vitaly Davidovich wrote:
>>> Doug,
>>>
>>> When you see the fast to slow ThreadLocal transition due to class
>>> loading
>>> invalidating inlined get(), do you not then see it get restored back
>>> to fast
>>> mode since the receiver type in your call sites is still the
>>> monomorphic
>>> ThreadLocal (and not the unrelated subclasses)? Just trying to
>>> understand what
>>> R?mi and you are saying.
>>>
>>
>> The possible outcomes are fairly non-deterministic, depending
>> on hotspot's mood about recompiles, tiered-compile interactions,
>> method size, Amddahl's law interactions, phase of moon, etc.
>>
>> (In j.u.c, we have learned that our users appreciate things
>> being predictably fast enough rather than being
>> unpredictably sometimes even faster but often slower.
>> So when we see such cases, as with ThreadLocal, they get added
>> to todo list.)
>>
>> -Doug
>>
>>
>>
>>
>
From Alan.Bateman at oracle.com Thu Dec 6 19:27:22 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 06 Dec 2012 19:27:22 +0000
Subject: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser
factories (7169894: JAXP Plugability Layer: using service loader)
In-Reply-To: <50C0D805.5030509@oracle.com>
References: <50BCF7CD.1020308@oracle.com> <50BE007A.4090102@oracle.com>
<50BF73B2.5000102@oracle.com> <50C06DAC.5050500@oracle.com>
<50C0D805.5030509@oracle.com>
Message-ID: <50C0F19A.7080302@oracle.com>
On 06/12/2012 17:38, Daniel Fuchs wrote:
> Updated the javadoc for newInstance():
>
>
>
>
> -- daniel
Thumbs up from me!
-Alan
From forax at univ-mlv.fr Thu Dec 6 19:25:18 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 06 Dec 2012 20:25:18 +0100
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To:
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C089A1.3090500@cs.oswego.edu>
Message-ID: <50C0F11E.4060003@univ-mlv.fr>
On 12/06/2012 01:12 PM, Vitaly Davidovich wrote:
> Understood - I'm just trying to make sure I don't have the wrong mental
> model of this in my mind. Taking pathology aside (e.g. code cache is full
> when time to recompile, poor tiering interaction, etc), I'd expect the fast
> inlined path to be restored assuming call site type profile (of the ones we
> care about) doesn't change after other subclasses are loaded. Would be
> good if someone can correct that if it's inaccurate. Apologies if this is
> slightly hijacking the thread, but it's Remi's fault :).
:)
Usually, it's inline just fine because the code just stores the
ThreadLocal in a static field, the VM profiles the code and you get the
fast path.
But some codes use a ThreadLocal in a non static field or use a map of
ThreadLocal so the profile becomes bloated, and there is no inlining
anymore.
If all loaded codes always use the same ThreadLocal (using
ThreadLocal.withSupplier()) then, the call to the supplier is not
inlined but you don't care because it's not part of the fast path of get.
cheers,
R?mi
>
> Sent from my phone
> On Dec 6, 2012 7:03 AM, "Doug Lea" wrote:
>
>> On 12/06/12 06:56, Vitaly Davidovich wrote:
>>
>>> Doug,
>>>
>>> When you see the fast to slow ThreadLocal transition due to class loading
>>> invalidating inlined get(), do you not then see it get restored back to
>>> fast
>>> mode since the receiver type in your call sites is still the monomorphic
>>> ThreadLocal (and not the unrelated subclasses)? Just trying to understand
>>> what
>>> R?mi and you are saying.
>>>
>>>
>> The possible outcomes are fairly non-deterministic, depending
>> on hotspot's mood about recompiles, tiered-compile interactions,
>> method size, Amddahl's law interactions, phase of moon, etc.
>>
>> (In j.u.c, we have learned that our users appreciate things
>> being predictably fast enough rather than being
>> unpredictably sometimes even faster but often slower.
>> So when we see such cases, as with ThreadLocal, they get added
>> to todo list.)
>>
>> -Doug
>>
>>
>>
>>
>>
From akhil.arora at oracle.com Thu Dec 6 19:43:21 2012
From: akhil.arora at oracle.com (Akhil Arora)
Date: Thu, 06 Dec 2012 11:43:21 -0800
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C0EBC9.2070101@univ-mlv.fr>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C0CF83.1080208@oracle.com> <50C0D81A.5030607@cs.oswego.edu>
<50C0DD49.4060900@oracle.com> <50C0E3F2.9030004@cs.oswego.edu>
<50C0EBC9.2070101@univ-mlv.fr>
Message-ID: <50C0F559.5090600@oracle.com>
On 12/06/2012 11:02 AM, Remi Forax wrote:
>
> just nitpicking,
> return new SuppliedThreadLocal(supplier);
> should be
> return new SuppliedThreadLocal<>(supplier);
>
> Also, can you add a @see in the constructor of ThreadLocal that
> references ThreadLocal.withInitialValue(Supplier).
http://cr.openjdk.java.net/~akhil/8003246.3/webrev/
also incorporates a nitpick from Mike -
Objects.requireNonNull returns its arg
Thanks - nitpicking welcome :)
From Alan.Bateman at oracle.com Thu Dec 6 19:59:10 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 06 Dec 2012 19:59:10 +0000
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C0F559.5090600@oracle.com>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C0CF83.1080208@oracle.com> <50C0D81A.5030607@cs.oswego.edu>
<50C0DD49.4060900@oracle.com> <50C0E3F2.9030004@cs.oswego.edu>
<50C0EBC9.2070101@univ-mlv.fr> <50C0F559.5090600@oracle.com>
Message-ID: <50C0F90E.6010404@oracle.com>
On 06/12/2012 19:43, Akhil Arora wrote:
>
> http://cr.openjdk.java.net/~akhil/8003246.3/webrev/
>
> also incorporates a nitpick from Mike -
> Objects.requireNonNull returns its arg
>
> Thanks - nitpicking welcome :)
Would it be worth including a note in the withInitial's javadoc to make
it clear that the given Supplier needs to be thread-safe?
-Alan.
From peter.levart at gmail.com Thu Dec 6 20:38:02 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 06 Dec 2012 21:38:02 +0100
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C0ED44.8030106@univ-mlv.fr>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C089A1.3090500@cs.oswego.edu> <50C0EB95.6070800@gmail.com>
<50C0ED44.8030106@univ-mlv.fr>
Message-ID: <50C1022A.8060202@gmail.com>
On 12/06/2012 08:08 PM, Remi Forax wrote:
> On 12/06/2012 08:01 PM, Peter Levart wrote:
>> There's a quick trick that guarantees in-lining of get/set/remove:
>>
>> public static class FastThreadLocal extends ThreadLocal {
>> @Override
>> public final T get() { return super.get(); }
>>
>> @Override
>> public final void set(T value) { super.set(value); }
>>
>> @Override
>> public final void remove() { super.remove(); }
>> }
>>
>> ....just use static type FastThreadLocal everywhere in code.
>>
>> I tried it and it works.
>
> No, there is no way to have such guarantee, here, it works either
> because the only class ThreadLocal you load is FastThreadLocal or
> because the VM has profiled the callsite see that you only use
> FastThreadLocal for a specific instruction.
Nothing is certain but death and taxes, I agree.
But think deeper, Remi!
How do you explain the following test:
public class ThreadLocalTest {
static class Int { int value; }
static class TL0 extends ThreadLocal {}
static class TL1 extends ThreadLocal { public Int get() {
return super.get(); } }
static class TL2 extends ThreadLocal { public Int get() {
return super.get(); } }
static class TL3 extends ThreadLocal { public Int get() {
return super.get(); } }
static class TL4 extends ThreadLocal { public Int get() {
return super.get(); } }
static long doTest(ThreadLocal tl) {
long t0 = System.nanoTime();
for (int i = 0; i < 100000000; i++)
tl.get().value++;
return System.nanoTime() - t0;
}
static long doTest(FastThreadLocal tl) {
long t0 = System.nanoTime();
for (int i = 0; i < 100000000; i++)
tl.get().value++;
return System.nanoTime() - t0;
}
static long test0(ThreadLocal tl) {
if (tl instanceof FastThreadLocal)
return doTest((FastThreadLocal)tl);
else
return doTest(tl);
}
static void test(ThreadLocal tl) {
tl.set(new Int());
System.out.print(tl.getClass().getName() + ":");
for (int i = 0; i < 8; i++)
System.out.print(" " + test0(tl));
System.out.println();
}
public static void main(String[] args) {
TL0 tl0 = new TL0();
test(tl0);
test(new TL1());
test(new TL2());
test(new TL3());
test(new TL4());
test(tl0);
}
}
Which prints the following (demonstrating almost 2x slowdown of TL0 -
last line compared to first):
test.ThreadLocalTest$TL0: 342716421 326105315 300744544 300654890
300726346 300752009 300700781 300735651
test.ThreadLocalTest$TL1: 321424139 312128166 312173383 312125203
312142144 312150949 316760957 313393554
test.ThreadLocalTest$TL2: 525661886 524169413 524184405 524215685
524162050 524400364 524174966 454370228
test.ThreadLocalTest$TL3: 472042229 471071328 464387909 468047355
464795171 464466481 464449567 464365974
test.ThreadLocalTest$TL4: 459651686 454142365 454129481 454180718
454217277 454109611 454119988 456978405
test.ThreadLocalTest$TL0: 582252322 582773455 582612509 582753610
582626360 582852195 582805654 582598285
Now with a simple change of:
static class TL0 extends FastThreadLocal {}
...the same test prints:
test.ThreadLocalTest$TL0: 330722181 325823711 301171182 309992192
321868979 308111417 303806979 300612033
test.ThreadLocalTest$TL1: 330263857 326448062 300607081 300575641
307442821 300616794 300548457 303462898
test.ThreadLocalTest$TL2: 319627165 311309477 311465815 311279612
311294427 311315803 311470291 311293823
test.ThreadLocalTest$TL3: 526849874 524209792 524421574 524166747
524396011 524163313 524395641 524165429
test.ThreadLocalTest$TL4: 464963126 455172216 455466304 455245487
455368318 455093735 455125038 455317375
test.ThreadLocalTest$TL0: 300472239 300695398 300480230 303459397
300451419 300679904 300445717 300451166
And that's very repeatable! Try it for yourself (on JDK8 of course).
Regards, Peter
>
>>
>>
>> Regards, Peter
>
> cheers,
> R?mi
>
>>
>> On 12/06/2012 01:03 PM, Doug Lea wrote:
>>> On 12/06/12 06:56, Vitaly Davidovich wrote:
>>>> Doug,
>>>>
>>>> When you see the fast to slow ThreadLocal transition due to class
>>>> loading
>>>> invalidating inlined get(), do you not then see it get restored
>>>> back to fast
>>>> mode since the receiver type in your call sites is still the
>>>> monomorphic
>>>> ThreadLocal (and not the unrelated subclasses)? Just trying to
>>>> understand what
>>>> R?mi and you are saying.
>>>>
>>>
>>> The possible outcomes are fairly non-deterministic, depending
>>> on hotspot's mood about recompiles, tiered-compile interactions,
>>> method size, Amddahl's law interactions, phase of moon, etc.
>>>
>>> (In j.u.c, we have learned that our users appreciate things
>>> being predictably fast enough rather than being
>>> unpredictably sometimes even faster but often slower.
>>> So when we see such cases, as with ThreadLocal, they get added
>>> to todo list.)
>>>
>>> -Doug
>>>
>>>
>>>
>>>
>>
>
From lance.andersen at oracle.com Thu Dec 6 20:52:41 2012
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Thu, 06 Dec 2012 20:52:41 +0000
Subject: hg: jdk8/tl/jdk: 8004374: CachedRowSetSwriter.writeData reports wrong
number of conflicts in SyncProviderException
Message-ID: <20121206205310.E808047F56@hg.openjdk.java.net>
Changeset: 41a1b110f34d
Author: lancea
Date: 2012-12-06 15:51 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/41a1b110f34d
8004374: CachedRowSetSwriter.writeData reports wrong number of conflicts in SyncProviderException
Reviewed-by: naoto
! src/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java
From rob.mckenna at oracle.com Thu Dec 6 21:19:30 2012
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 06 Dec 2012 21:19:30 +0000
Subject: Request for review: 8000525: Java.net.httpcookie api does not support
2-digit year format
Message-ID: <50C10BE2.5070006@oracle.com>
Hi folks,
According to HttpCookie.java:
"""
There are 3 http cookie specifications:
Netscape draft
RFC 2109 -/http://www.ietf.org/rfc/rfc2109.txt/
RFC 2965 -/http://www.ietf.org/rfc/rfc2965.txt/
HttpCookie class can accept all these 3 forms of syntax.
"""
According to http://www.ietf.org/rfc/rfc2109.txt section 10.1.2:
"""
Netscape's original proposal defined an Expires header that took a date
value in a fixed-length variant format in place of Max-Age: Wdy,
DD-Mon-YY HH:MM:SS GMT
"""
Thats in the "Historical" section provided to allow for compatibility
with Netscape's implementation, which we also support: (as per
http://docs.oracle.com/javase/6/docs/api/java/net/HttpCookie.html )
While we don't support the rfc explicitly, this change follows the
format specified in section 5.1.1 of rfc 6265:
"""
3. If the year-value is greater than or equal to 70 and less than or
equal to 99, increment the year-value by 1900.
4. If the year-value is greater than or equal to 0 and less than or
equal to 69, increment the year-value by 2000.
1. NOTE: Some existing user agents interpret two-digit years
differently.
"""
The webrev is at:
http://cr.openjdk.java.net/~robm/8000525/webrev.01/
Note: The addition of setLenient(false) has required changes to two
existing testcases.
-Rob
From peter.levart at gmail.com Thu Dec 6 21:21:02 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 06 Dec 2012 22:21:02 +0100
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C1022A.8060202@gmail.com>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C089A1.3090500@cs.oswego.edu> <50C0EB95.6070800@gmail.com>
<50C0ED44.8030106@univ-mlv.fr> <50C1022A.8060202@gmail.com>
Message-ID: <50C10C3E.4080404@gmail.com>
Ok, I've got an explanation.
It's not because of using different static type of variables in code
with final methods, but because TL0 was redirected to a separate method
with separate call sites. The same happens using this variant:
static class TL0 extends ThreadLocal {}
static class TL1 extends ThreadLocal { public Int get() {
return super.get(); } }
static class TL2 extends ThreadLocal { public Int get() {
return super.get(); } }
static class TL3 extends ThreadLocal { public Int get() {
return super.get(); } }
static class TL4 extends ThreadLocal { public Int get() {
return super.get(); } }
static long doTest(ThreadLocal tl) {
long t0 = System.nanoTime();
for (int i = 0; i < 100000000; i++)
tl.get().value++;
return System.nanoTime() - t0;
}
static long doTest0(ThreadLocal tl) {
long t0 = System.nanoTime();
for (int i = 0; i < 100000000; i++)
tl.get().value++;
return System.nanoTime() - t0;
}
static long test0(ThreadLocal tl) {
if (tl instanceof TL0)
return doTest0(tl);
else
return doTest(tl);
}
But I think that deoptimizations that Dough is talking about might be
prevented by using the following variant of TL:
public class FastThreadLocal extends ThreadLocal {
public final T getFast() { return super.get(); }
public final void setFast(T value) { super.set(value); }
public final void removeFast() { super.remove(); }
}
and invoking the "fast" methods in code.
Right?
Regards, Peter
On 12/06/2012 09:38 PM, Peter Levart wrote:
> On 12/06/2012 08:08 PM, Remi Forax wrote:
>> On 12/06/2012 08:01 PM, Peter Levart wrote:
>>> There's a quick trick that guarantees in-lining of get/set/remove:
>>>
>>> public static class FastThreadLocal extends ThreadLocal {
>>> @Override
>>> public final T get() { return super.get(); }
>>>
>>> @Override
>>> public final void set(T value) { super.set(value); }
>>>
>>> @Override
>>> public final void remove() { super.remove(); }
>>> }
>>>
>>> ....just use static type FastThreadLocal everywhere in code.
>>>
>>> I tried it and it works.
>>
>> No, there is no way to have such guarantee, here, it works either
>> because the only class ThreadLocal you load is FastThreadLocal or
>> because the VM has profiled the callsite see that you only use
>> FastThreadLocal for a specific instruction.
>
> Nothing is certain but death and taxes, I agree.
>
> But think deeper, Remi!
>
> How do you explain the following test:
>
> public class ThreadLocalTest {
>
> static class Int { int value; }
>
> static class TL0 extends ThreadLocal {}
> static class TL1 extends ThreadLocal { public Int get() {
> return super.get(); } }
> static class TL2 extends ThreadLocal { public Int get() {
> return super.get(); } }
> static class TL3 extends ThreadLocal { public Int get() {
> return super.get(); } }
> static class TL4 extends ThreadLocal { public Int get() {
> return super.get(); } }
>
> static long doTest(ThreadLocal tl) {
> long t0 = System.nanoTime();
> for (int i = 0; i < 100000000; i++)
> tl.get().value++;
> return System.nanoTime() - t0;
> }
>
> static long doTest(FastThreadLocal tl) {
> long t0 = System.nanoTime();
> for (int i = 0; i < 100000000; i++)
> tl.get().value++;
> return System.nanoTime() - t0;
> }
>
> static long test0(ThreadLocal tl) {
> if (tl instanceof FastThreadLocal)
> return doTest((FastThreadLocal)tl);
> else
> return doTest(tl);
> }
>
> static void test(ThreadLocal tl) {
> tl.set(new Int());
> System.out.print(tl.getClass().getName() + ":");
> for (int i = 0; i < 8; i++)
> System.out.print(" " + test0(tl));
> System.out.println();
> }
>
> public static void main(String[] args) {
> TL0 tl0 = new TL0();
> test(tl0);
> test(new TL1());
> test(new TL2());
> test(new TL3());
> test(new TL4());
> test(tl0);
> }
> }
>
>
> Which prints the following (demonstrating almost 2x slowdown of TL0 -
> last line compared to first):
>
> test.ThreadLocalTest$TL0: 342716421 326105315 300744544 300654890
> 300726346 300752009 300700781 300735651
> test.ThreadLocalTest$TL1: 321424139 312128166 312173383 312125203
> 312142144 312150949 316760957 313393554
> test.ThreadLocalTest$TL2: 525661886 524169413 524184405 524215685
> 524162050 524400364 524174966 454370228
> test.ThreadLocalTest$TL3: 472042229 471071328 464387909 468047355
> 464795171 464466481 464449567 464365974
> test.ThreadLocalTest$TL4: 459651686 454142365 454129481 454180718
> 454217277 454109611 454119988 456978405
> test.ThreadLocalTest$TL0: 582252322 582773455 582612509 582753610
> 582626360 582852195 582805654 582598285
>
> Now with a simple change of:
>
> static class TL0 extends FastThreadLocal {}
>
> ...the same test prints:
>
> test.ThreadLocalTest$TL0: 330722181 325823711 301171182 309992192
> 321868979 308111417 303806979 300612033
> test.ThreadLocalTest$TL1: 330263857 326448062 300607081 300575641
> 307442821 300616794 300548457 303462898
> test.ThreadLocalTest$TL2: 319627165 311309477 311465815 311279612
> 311294427 311315803 311470291 311293823
> test.ThreadLocalTest$TL3: 526849874 524209792 524421574 524166747
> 524396011 524163313 524395641 524165429
> test.ThreadLocalTest$TL4: 464963126 455172216 455466304 455245487
> 455368318 455093735 455125038 455317375
> test.ThreadLocalTest$TL0: 300472239 300695398 300480230 303459397
> 300451419 300679904 300445717 300451166
>
>
> And that's very repeatable! Try it for yourself (on JDK8 of course).
>
> Regards, Peter
>
>
>>
>>>
>>>
>>> Regards, Peter
>>
>> cheers,
>> R?mi
>>
>>>
>>> On 12/06/2012 01:03 PM, Doug Lea wrote:
>>>> On 12/06/12 06:56, Vitaly Davidovich wrote:
>>>>> Doug,
>>>>>
>>>>> When you see the fast to slow ThreadLocal transition due to class
>>>>> loading
>>>>> invalidating inlined get(), do you not then see it get restored
>>>>> back to fast
>>>>> mode since the receiver type in your call sites is still the
>>>>> monomorphic
>>>>> ThreadLocal (and not the unrelated subclasses)? Just trying to
>>>>> understand what
>>>>> R?mi and you are saying.
>>>>>
>>>>
>>>> The possible outcomes are fairly non-deterministic, depending
>>>> on hotspot's mood about recompiles, tiered-compile interactions,
>>>> method size, Amddahl's law interactions, phase of moon, etc.
>>>>
>>>> (In j.u.c, we have learned that our users appreciate things
>>>> being predictably fast enough rather than being
>>>> unpredictably sometimes even faster but often slower.
>>>> So when we see such cases, as with ThreadLocal, they get added
>>>> to todo list.)
>>>>
>>>> -Doug
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
From rob.mckenna at oracle.com Thu Dec 6 21:22:26 2012
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 06 Dec 2012 21:22:26 +0000
Subject: Request for review: JDK-8004337: java/sql tests aren't run in
test/Makefile
Message-ID: <50C10C92.50605@oracle.com>
Hi folks,
There's a missing folder in the jdk_other test target:
http://cr.openjdk.java.net/~robm/8004337/webrev.01/
-Rob
From forax at univ-mlv.fr Thu Dec 6 21:20:54 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 06 Dec 2012 22:20:54 +0100
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C1022A.8060202@gmail.com>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C089A1.3090500@cs.oswego.edu> <50C0EB95.6070800@gmail.com>
<50C0ED44.8030106@univ-mlv.fr> <50C1022A.8060202@gmail.com>
Message-ID: <50C10C36.7010201@univ-mlv.fr>
On 12/06/2012 09:38 PM, Peter Levart wrote:
> On 12/06/2012 08:08 PM, Remi Forax wrote:
>> On 12/06/2012 08:01 PM, Peter Levart wrote:
>>> There's a quick trick that guarantees in-lining of get/set/remove:
>>>
>>> public static class FastThreadLocal extends ThreadLocal {
>>> @Override
>>> public final T get() { return super.get(); }
>>>
>>> @Override
>>> public final void set(T value) { super.set(value); }
>>>
>>> @Override
>>> public final void remove() { super.remove(); }
>>> }
>>>
>>> ....just use static type FastThreadLocal everywhere in code.
>>>
>>> I tried it and it works.
>>
>> No, there is no way to have such guarantee, here, it works either
>> because the only class ThreadLocal you load is FastThreadLocal or
>> because the VM has profiled the callsite see that you only use
>> FastThreadLocal for a specific instruction.
>
> Nothing is certain but death and taxes, I agree.
>
> But think deeper, Remi!
I try, i try, i've trouble to understand what you mean
>
> How do you explain the following test:
>
> public class ThreadLocalTest {
>
> static class Int { int value; }
>
> static class TL0 extends ThreadLocal {}
> static class TL1 extends ThreadLocal { public Int get() {
> return super.get(); } }
> static class TL2 extends ThreadLocal { public Int get() {
> return super.get(); } }
> static class TL3 extends ThreadLocal { public Int get() {
> return super.get(); } }
> static class TL4 extends ThreadLocal { public Int get() {
> return super.get(); } }
>
> static long doTest(ThreadLocal tl) {
> long t0 = System.nanoTime();
> for (int i = 0; i < 100000000; i++)
> tl.get().value++; //
> callsite 1
> return System.nanoTime() - t0;
> }
here, tl.get() (callsite 1) is called with TL0, TL1, TL2, TL3 and TL4,
do tl.get() is a polymorphic call
>
> static long doTest(FastThreadLocal tl) {
> long t0 = System.nanoTime();
> for (int i = 0; i < 100000000; i++)
> tl.get().value++; // callsite 2
> return System.nanoTime() - t0;
> }
if TL0 is defined like as a FastThreadLocal. doTest is called and here
tl.get() (callsite 2) is only called with a FastThreadLocal, so the call
is inlined.
>
> static long test0(ThreadLocal tl) {
> if (tl instanceof FastThreadLocal)
> return doTest((FastThreadLocal)tl);
> else
> return doTest(tl);
> }
>
> static void test(ThreadLocal tl) {
> tl.set(new Int());
> System.out.print(tl.getClass().getName() + ":");
> for (int i = 0; i < 8; i++)
> System.out.print(" " + test0(tl));
> System.out.println();
> }
>
> public static void main(String[] args) {
> TL0 tl0 = new TL0();
> test(tl0);
> test(new TL1());
> test(new TL2());
> test(new TL3());
> test(new TL4());
> test(tl0);
> }
> }
>
>
> Which prints the following (demonstrating almost 2x slowdown of TL0 -
> last line compared to first):
>
> test.ThreadLocalTest$TL0: 342716421 326105315 300744544 300654890
> 300726346 300752009 300700781 300735651
> test.ThreadLocalTest$TL1: 321424139 312128166 312173383 312125203
> 312142144 312150949 316760957 313393554
> test.ThreadLocalTest$TL2: 525661886 524169413 524184405 524215685
> 524162050 524400364 524174966 454370228
> test.ThreadLocalTest$TL3: 472042229 471071328 464387909 468047355
> 464795171 464466481 464449567 464365974
> test.ThreadLocalTest$TL4: 459651686 454142365 454129481 454180718
> 454217277 454109611 454119988 456978405
> test.ThreadLocalTest$TL0: 582252322 582773455 582612509 582753610
> 582626360 582852195 582805654 582598285
>
> Now with a simple change of:
>
> static class TL0 extends FastThreadLocal {}
>
> ...the same test prints:
>
> test.ThreadLocalTest$TL0: 330722181 325823711 301171182 309992192
> 321868979 308111417 303806979 300612033
> test.ThreadLocalTest$TL1: 330263857 326448062 300607081 300575641
> 307442821 300616794 300548457 303462898
> test.ThreadLocalTest$TL2: 319627165 311309477 311465815 311279612
> 311294427 311315803 311470291 311293823
> test.ThreadLocalTest$TL3: 526849874 524209792 524421574 524166747
> 524396011 524163313 524395641 524165429
> test.ThreadLocalTest$TL4: 464963126 455172216 455466304 455245487
> 455368318 455093735 455125038 455317375
> test.ThreadLocalTest$TL0: 300472239 300695398 300480230 303459397
> 300451419 300679904 300445717 300451166
>
>
> And that's very repeatable! Try it for yourself (on JDK8 of course).
>
> Regards, Peter
so to summarize, the tl.get() in doTest(ThreadLocal) is polymorphic and
the one in doTest(FastThreadLocal) is monomorphic thus inlinable.
It has nothing to do with the fact that FastThreadLocal override get,
set and remove.
You can comment the methods inside FastThreadLocal to see that it change
nothing.
regards,
R?mi
From Lance.Andersen at oracle.com Thu Dec 6 21:26:48 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 6 Dec 2012 16:26:48 -0500
Subject: Request for review: JDK-8004337: java/sql tests aren't run in
test/Makefile
In-Reply-To: <50C10C92.50605@oracle.com>
References: <50C10C92.50605@oracle.com>
Message-ID: <210B31C0-2311-4973-B332-802F69223A21@oracle.com>
Looks fine Rob
On Dec 6, 2012, at 4:22 PM, Rob McKenna wrote:
> Hi folks,
>
> There's a missing folder in the jdk_other test target:
>
> http://cr.openjdk.java.net/~robm/8004337/webrev.01/
>
> -Rob
-------------- next part --------------
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 cs at schulte.it Thu Dec 6 22:03:11 2012
From: cs at schulte.it (Christian Schulte)
Date: Thu, 06 Dec 2012 23:03:11 +0100
Subject: Misleading documentation for class
java.nio.charset.spi.CharsetProvider
In-Reply-To: <50C0DAE3.3070905@oracle.com>
References: <50C0D532.90001@schulte.it> <50C0DAE3.3070905@oracle.com>
Message-ID: <50C1161F.4070005@schulte.it>
Am 12/06/12 18:50, schrieb Alan Bateman:
> On 06/12/2012 17:26, Christian Schulte wrote:
>> Hello,
>>
>> I am not sure if this is the correct mailing list to send this mail to.
>> Please apologize any inconvenience caused.
>>
>> The JDK 7 documentation of class java.nio.charset.spi.CharsetProvider
>> states the following:
>>
>> [...]
>> Charset providers are looked up via the current thread's context class
>> loader.
>> [...]
>>
>> Looking at method 'private static Iterator providers()' of class
>> 'java.nio.charset.Charset', the above documentation seems incorrect
>> since that method uses the system class loader.
>>
>> ClassLoader cl = ClassLoader.getSystemClassLoader();
>> ServiceLoader sl =
>> ServiceLoader.load(CharsetProvider.class, cl);
>>
>> Is this intended ?
>>
> This is a long standing issue (going back to 1.4), we should remove this
> from the javadoc.
Or update the code to use the thread context class loader if possible.
This would allow using custom charset providers with e.g. Webstart.
Anyway. Thanks for taking a look.
--
Christian Schulte
From jeffhain at rocketmail.com Thu Dec 6 22:05:13 2012
From: jeffhain at rocketmail.com (Jeff Hain)
Date: Thu, 6 Dec 2012 22:05:13 +0000 (GMT)
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C0F559.5090600@oracle.com>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C0CF83.1080208@oracle.com> <50C0D81A.5030607@cs.oswego.edu>
<50C0DD49.4060900@oracle.com> <50C0E3F2.9030004@cs.oswego.edu>
<50C0EBC9.2070101@univ-mlv.fr> <50C0F559.5090600@oracle.com>
Message-ID: <1354831513.40215.YahooMailNeo@web132104.mail.ird.yahoo.com>
>nitpicking welcome :)
AFAIK (*), removing 'private' for supplier field could prevent
javac to generate accessors for this field, in case it would be
accessed from outside inner class (but since it's not, it would
not yield better perfs, just smaller bytecode).
(*) If I correctly undertood what R?mi once said :)
-Jeff
From mike.duigou at oracle.com Thu Dec 6 23:39:14 2012
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Thu, 06 Dec 2012 23:39:14 +0000
Subject: hg: jdk8/tl: 8004685: add java.util.function to CORE_PKGS.gmk
Message-ID: <20121206233914.9C9E847F5F@hg.openjdk.java.net>
Changeset: fb1bf5e5bc9e
Author: henryjen
Date: 2012-12-06 15:38 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/rev/fb1bf5e5bc9e
8004685: add java.util.function to CORE_PKGS.gmk
Reviewed-by: mduigou
! common/makefiles/javadoc/CORE_PKGS.gmk
From forax at univ-mlv.fr Thu Dec 6 23:44:44 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 07 Dec 2012 00:44:44 +0100
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <1354831513.40215.YahooMailNeo@web132104.mail.ird.yahoo.com>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C0CF83.1080208@oracle.com> <50C0D81A.5030607@cs.oswego.edu>
<50C0DD49.4060900@oracle.com> <50C0E3F2.9030004@cs.oswego.edu>
<50C0EBC9.2070101@univ-mlv.fr> <50C0F559.5090600@oracle.com>
<1354831513.40215.YahooMailNeo@web132104.mail.ird.yahoo.com>
Message-ID: <50C12DEC.9060006@univ-mlv.fr>
On 12/06/2012 11:05 PM, Jeff Hain wrote:
>> nitpicking welcome :)
> AFAIK (*), removing 'private' for supplier field could prevent
> javac to generate accessors for this field, in case it would be
> accessed from outside inner class (but since it's not, it would
> not yield better perfs, just smaller bytecode).
>
> (*) If I correctly undertood what R?mi once said :)
It's true only if the field is accessed ouside the inner class but
inside the enclosing class (or the enclosing class of the enclosing class).
BTW, at some point, it will be a good idea to get ride of all these
method access$000 in java.lang/java.util at least.
>
> -Jeff
R?mi
From stuart.marks at oracle.com Fri Dec 7 02:12:15 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 06 Dec 2012 18:12:15 -0800
Subject: Review request: 8004042 : Arrrghs.java test failed on windows
with access error.
In-Reply-To:
References: <99E014EB-0210-4C77-BE43-88CED80B1825@oracle.com>
<50C03083.4030102@oracle.com>
Message-ID: <50C1507F.7040202@oracle.com>
OK, looks pretty good. But....
One little thing is still bothering me. Suppose we get interrupted from the
sleep() and bail out on that basis. If we got to the point where we're
sleeping, we must have caught an AccessDeniedException previously.
Unfortunately this exception is discarded if we were interrupted. This might
lose valuable diagnostic information. So, what do we do with it? How about adding:
ie.addSuppressed(cause);
in the catch InterruptedException clause, before throwing the RuntimeException.
(There's another issue which is that if there were previous retries, the ADEs
from them are thrown away. But maybe we should save that one for another day.)
s'marks
On 12/6/12 9:41 AM, David DeHaven wrote:
>
> New webrev posted:
> http://cr.openjdk.java.net/~ddehaven/8004042/webrev.2/
>
> Summary:
> - Cleaned it up a bit by change to a for loop (eliminating done flag)
> - Throws RuntimeException instead of IOException, handles InterruptedException
> - Bumped retry count to 10
> - Changed @run mode to "main/othervm" as suggested by Kumar
>
> -DrD-
>
From robert.field at oracle.com Fri Dec 7 05:57:22 2012
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Fri, 07 Dec 2012 05:57:22 +0000
Subject: hg: jdk8/tl/jdk: 8003881: Prevent lambda implementing inner classes
from allowing the creation of new instances
Message-ID: <20121207055741.6431447FA8@hg.openjdk.java.net>
Changeset: 896d4af2ebfd
Author: rfield
Date: 2012-12-06 21:55 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/896d4af2ebfd
8003881: Prevent lambda implementing inner classes from allowing the creation of new instances
Summary: Lambda implementing inner classes now has private constructor (thanks Kumar)
Reviewed-by: ksrini
! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
+ test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java
+ test/java/lang/invoke/lambda/LambdaAccessControlTest.java
From huizhe.wang at oracle.com Fri Dec 7 08:04:45 2012
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 07 Dec 2012 00:04:45 -0800
Subject: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser
factories (7169894: JAXP Plugability Layer: using service loader)
In-Reply-To: <50C0D805.5030509@oracle.com>
References: <50BCF7CD.1020308@oracle.com> <50BE007A.4090102@oracle.com>
<50BF73B2.5000102@oracle.com> <50C06DAC.5050500@oracle.com>
<50C0D805.5030509@oracle.com>
Message-ID: <50C1A31D.1090805@oracle.com>
I would think that it's good to merge the 3rd and 4th steps for a jdk in
module mode. In regular mode or JDK8, where the existence of the default
implementation is guaranteed, the last step is still necessary. It is a
requirement for the API implementation.
I probably was wrong to use "default" to refer to the jaxp ri at the 3rd
step of the service mechanism. After reading your comments/discussions,
I felt it might not be appropriate for regular JDKs or JDKs in regular
mode. Users may well, as they should, take what's installed within the
JDK as the "default" implementation and be confused with the statement
that the "default" may not be present.
So it looks like we need to differentiate regular from modular JDK, and
more importantly the jaxp ri from the "default" implementation:
1) In regular JDK (e.g. JDK8), the service loader shall return the first
provider (whether it's a 3rd-party impl or the jaxp ri, it's users'
decision to put them on the classpath or in the endorsed directory)
The 4th step is still "Platform default
DocumentBuilderFactory instance."
2) In module mode, the default impl would be one of the modules. My
understanding is that there would not be such a thing as a JAXP RI
module. So merging 3rd and 4th steps are fine. But it may be necessary
to clarify that it's for module mode.
Thanks,
Joe
On 12/6/2012 9:38 AM, Daniel Fuchs wrote:
> Updated the javadoc for newInstance():
>
>
>
>
> -- daniel
>
> On 12/6/12 11:04 AM, Alan Bateman wrote:
>> On 05/12/2012 16:17, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Please find below a revised version of the changes for
>>> the javax.xml.parsers package.
>>>
>>> It hopefully incorporates all comments I have received so far.
>>>
>>>
>>>
>>>
>>>
>>> * better wording/formating for Javadoc changes
>>> * using for( : ) syntax in findServiceProvider
>>> * improved // comments explaining why the additional layer of
>>> RuntimeException is needed when wrapping ServiceConfigurationError.
>>>
>>> best regards,
>>>
>>> -- daniel
>> You've addressed all my comments and I think this looks very good.
>>
>> One other comment. Now that the wording is "Otherwise the default
>> implementation, if present, is returned" it raises the question as to
>> how what happens if the default implementation is not present. A
>> suggestion is to just handle it in the next statement, something like
>> "In the case of a SCE or the default provider is not present, then FCE
>> will be thrown".
>>
>> I see Mandy's comment about the bullet item "Platform default
>> DocumentBuilderFactory instance". I hadn't noticed this but
>> I assume this should just be removed now.
>>
>> -Alan.
>
From peter.levart at gmail.com Fri Dec 7 09:09:18 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 07 Dec 2012 10:09:18 +0100
Subject: Request for Review: CR#8001667, second attempt
In-Reply-To: <50C041D3.9060703@oracle.com>
References: <50C041D3.9060703@oracle.com>
Message-ID: <50C1B23E.8010003@gmail.com>
Hi Henry,
I don't know what the plans are about moving the static methods in
Comparators to the Comparator interface when static interface methods
are enabled, but if that is planned, there will be a clash between
Comparator.reverseOrder() default method and static method with same
name and signature.
Maybe rename static .reverseOrder() to .reverseNaturalOrder() (to
long?), or rename the default method .reverseOrder() to .reverse();
Also, I like the natural-language-like fluent syntax when starting with
Comparators.comparing(...).thenComparing(...).reverse[Order](), but the
.thenComparing name is also overloaded with the variant for composing:
.thenComparing(Comparator) which makes statements like:
Comparators.comparing(x -> x.size).thenComparing(x ->
x.y).thenComparing((x, y) -> some expression)
a little confusing, because what you get is not a comparator that
compares one value of "some expression" with some other value of the
same expression, but a comparator that uses the value of expression to
order two elements.
I think that using the same method name for two different purposes is a
little confusing. Maybe .compose(Comparator) or just plain
.then(Comparator) would be better here.
Regards, Peter
On 12/06/2012 07:57 AM, Henry Jen wrote:
> Hi,
>
> This update reflect changes based on feedbacks for last version, the
> changes are
>
> - rename reverse() to reverseOrder()
> - rename Comparator.compose to Comparator.thenComparing
> - add 4 Comparator.thenComparing methods take [Int|Long|Double]Function
> to enable fluent syntax like this example,
>
> people.sort(Comparators.comparing(People::getFirstName).thenComparing(People.getLastName))
>
> vs previously,
>
> people.sort(Comparators.comparing(Person::getName))
> Comparator byLastFirst
> = Comparators.comparing(Person::getLastName)
> .compose(Comparators.comparing(Person::getFirstName))
>
> Please review and comment on the webrev[1] and specdiff[2].
>
> [1] http://cr.openjdk.java.net/~henryjen/ccc/8001667.1/webrev
> [2]
> http://cr.openjdk.java.net/~henryjen/ccc/8001667.1/specdiff/overview-summary.html
>
> Cheers,
> Henry
From Alan.Bateman at oracle.com Fri Dec 7 09:41:13 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 07 Dec 2012 09:41:13 +0000
Subject: Request for review: JDK-8004337: java/sql tests aren't run in
test/Makefile
In-Reply-To: <50C10C92.50605@oracle.com>
References: <50C10C92.50605@oracle.com>
Message-ID: <50C1B9B9.9040604@oracle.com>
On 06/12/2012 21:22, Rob McKenna wrote:
> Hi folks,
>
> There's a missing folder in the jdk_other test target:
>
> http://cr.openjdk.java.net/~robm/8004337/webrev.01/
>
>
> -Rob
Thanks for catching this, looks good to me.
-Alan
From Alan.Bateman at oracle.com Fri Dec 7 09:43:02 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 07 Dec 2012 09:43:02 +0000
Subject: Misleading documentation for class
java.nio.charset.spi.CharsetProvider
In-Reply-To: <50C1161F.4070005@schulte.it>
References: <50C0D532.90001@schulte.it> <50C0DAE3.3070905@oracle.com>
<50C1161F.4070005@schulte.it>
Message-ID: <50C1BA26.5020804@oracle.com>
On 06/12/2012 22:03, Christian Schulte wrote:
> :
> Or update the code to use the thread context class loader if possible.
> This would allow using custom charset providers with e.g. Webstart.
> Anyway. Thanks for taking a look.
>
Using the TCCL for charset providers is highly problematic, this is a
case where it would be preferable to just align the specification with
the long standing behavior.
-Alan
From Alan.Bateman at oracle.com Fri Dec 7 13:12:33 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 07 Dec 2012 13:12:33 +0000
Subject: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser
factories (7169894: JAXP Plugability Layer: using service loader)
In-Reply-To: <50C1A31D.1090805@oracle.com>
References: <50BCF7CD.1020308@oracle.com> <50BE007A.4090102@oracle.com>
<50BF73B2.5000102@oracle.com> <50C06DAC.5050500@oracle.com>
<50C0D805.5030509@oracle.com> <50C1A31D.1090805@oracle.com>
Message-ID: <50C1EB41.2010502@oracle.com>
On 07/12/2012 08:04, Joe Wang wrote:
>
> I would think that it's good to merge the 3rd and 4th steps for a jdk
> in module mode. In regular mode or JDK8, where the existence of the
> default implementation is guaranteed, the last step is still
> necessary. It is a requirement for the API implementation.
>
> I probably was wrong to use "default" to refer to the jaxp ri at the
> 3rd step of the service mechanism. After reading your
> comments/discussions, I felt it might not be appropriate for regular
> JDKs or JDKs in regular mode. Users may well, as they should, take
> what's installed within the JDK as the "default" implementation and be
> confused with the statement that the "default" may not be present.
>
> So it looks like we need to differentiate regular from modular JDK,
> and more importantly the jaxp ri from the "default" implementation:
>
> 1) In regular JDK (e.g. JDK8), the service loader shall return the
> first provider (whether it's a 3rd-party impl or the jaxp ri, it's
> users' decision to put them on the classpath or in the endorsed
> directory)
>
> The 4th step is still "Platform default
> DocumentBuilderFactory instance."
>
> 2) In module mode, the default impl would be one of the modules. My
> understanding is that there would not be such a thing as a JAXP RI
> module. So merging 3rd and 4th steps are fine. But it may be necessary
> to clarify that it's for module mode.
>
I think it's a bit premature to talk about modules and "module mode" in
this specification. To use those terms would require somewhere to
reference and there won't be anything to reference in Java SE 8. Also as
this is a standalone technology then it can be used with implementation
of previous Java SE versions too.
The way I look at this is that we are getting there in phases and a
really important first phase for JAXP is to upgrade it to use
ServiceLoader consistently. This is painful work due to
under-specification and subtle compatibility issues that may arise due
to these changes. Even without modules as a driver for this, then I
think will be beneficial to JAXP anyway because it's cleaning up an area
that is a mess today (not your fault, this pre-dates your watch).
If we can bring you around to agreeing with this then I think the only
point remaining is whether the API requires at least one implementation
to be present. I see your point and this may be something that needs to
be deferred to a later time, in which case this requires changing the
javadoc to:
"Otherwise the system-default implementation is returned."
and
"In case of {@link java.util.ServiceConfigurationError},then {@link
FactoryConfigurationError} will be thrown."
Would you be okay with that? I don't think the javadoc should mention
the JAXP RI, that may or may not be the system-default implementation.
-Alan.
From dl at cs.oswego.edu Fri Dec 7 14:27:36 2012
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 07 Dec 2012 09:27:36 -0500
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C12DEC.9060006@univ-mlv.fr>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C0CF83.1080208@oracle.com> <50C0D81A.5030607@cs.oswego.edu>
<50C0DD49.4060900@oracle.com> <50C0E3F2.9030004@cs.oswego.edu>
<50C0EBC9.2070101@univ-mlv.fr> <50C0F559.5090600@oracle.com>
<1354831513.40215.YahooMailNeo@web132104.mail.ird.yahoo.com>
<50C12DEC.9060006@univ-mlv.fr>
Message-ID: <50C1FCD8.3030109@cs.oswego.edu>
On 12/06/12 18:44, Remi Forax wrote:
> BTW, at some point, it will be a good idea to get ride of all these method
> access$000 in java.lang/java.util at least.
>
Maybe this is out of scope for this CR, but while in the
neighborhood of ThreadLocal, it could be done here.
There are a couple of annoying ones that kick in on any
compile of anything involving ThreadLocals (try running with
-XX:+PrintCompilation). To remove, replace "private" with
"final" for methods, and just kill "private" for fields.
-Doug
From daniel.fuchs at oracle.com Fri Dec 7 15:15:05 2012
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 07 Dec 2012 16:15:05 +0100
Subject: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser
factories (7169894: JAXP Plugability Layer: using service loader)
In-Reply-To: <50C1EB41.2010502@oracle.com>
References: <50BCF7CD.1020308@oracle.com> <50BE007A.4090102@oracle.com>
<50BF73B2.5000102@oracle.com> <50C06DAC.5050500@oracle.com>
<50C0D805.5030509@oracle.com> <50C1A31D.1090805@oracle.com>
<50C1EB41.2010502@oracle.com>
Message-ID: <50C207F9.5060307@oracle.com>
Hi Alan,
I have updated the webrev according to your suggestion. I think it makes
things much clearer.
The new version is there:
On 12/7/12 2:12 PM, Alan Bateman wrote:
> On 07/12/2012 08:04, Joe Wang wrote:
>>
>> I would think that it's good to merge the 3rd and 4th steps for a jdk
>> in module mode. In regular mode or JDK8, where the existence of the
>> default implementation is guaranteed, the last step is still
>> necessary. It is a requirement for the API implementation.
>>
>> I probably was wrong to use "default" to refer to the jaxp ri at the
>> 3rd step of the service mechanism. After reading your
>> comments/discussions, I felt it might not be appropriate for regular
>> JDKs or JDKs in regular mode. Users may well, as they should, take
>> what's installed within the JDK as the "default" implementation and be
>> confused with the statement that the "default" may not be present.
>>
>> So it looks like we need to differentiate regular from modular JDK,
>> and more importantly the jaxp ri from the "default" implementation:
>>
>> 1) In regular JDK (e.g. JDK8), the service loader shall return the
>> first provider (whether it's a 3rd-party impl or the jaxp ri, it's
>> users' decision to put them on the classpath or in the endorsed
>> directory)
>>
>> The 4th step is still "Platform default
>> DocumentBuilderFactory instance."
>>
>> 2) In module mode, the default impl would be one of the modules. My
>> understanding is that there would not be such a thing as a JAXP RI
>> module. So merging 3rd and 4th steps are fine. But it may be necessary
>> to clarify that it's for module mode.
>>
> I think it's a bit premature to talk about modules and "module mode" in
> this specification. To use those terms would require somewhere to
> reference and there won't be anything to reference in Java SE 8. Also as
> this is a standalone technology then it can be used with implementation
> of previous Java SE versions too.
>
> The way I look at this is that we are getting there in phases and a
> really important first phase for JAXP is to upgrade it to use
> ServiceLoader consistently. This is painful work due to
> under-specification and subtle compatibility issues that may arise due
> to these changes. Even without modules as a driver for this, then I
> think will be beneficial to JAXP anyway because it's cleaning up an area
> that is a mess today (not your fault, this pre-dates your watch).
>
> If we can bring you around to agreeing with this then I think the only
> point remaining is whether the API requires at least one implementation
> to be present. I see your point and this may be something that needs to
> be deferred to a later time, in which case this requires changing the
> javadoc to:
>
> "Otherwise the system-default implementation is returned."
>
> and
>
> "In case of {@link java.util.ServiceConfigurationError},then {@link
> FactoryConfigurationError} will be thrown."
>
> Would you be okay with that? I don't think the javadoc should mention
> the JAXP RI, that may or may not be the system-default implementation.
>
> -Alan.
>
>
From chris.hegarty at oracle.com Fri Dec 7 15:34:40 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 07 Dec 2012 15:34:40 +0000
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C1FCD8.3030109@cs.oswego.edu>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C0CF83.1080208@oracle.com> <50C0D81A.5030607@cs.oswego.edu>
<50C0DD49.4060900@oracle.com> <50C0E3F2.9030004@cs.oswego.edu>
<50C0EBC9.2070101@univ-mlv.fr> <50C0F559.5090600@oracle.com>
<1354831513.40215.YahooMailNeo@web132104.mail.ird.yahoo.com>
<50C12DEC.9060006@univ-mlv.fr> <50C1FCD8.3030109@cs.oswego.edu>
Message-ID: <50C20C90.6070200@oracle.com>
I filed 8004707: "Remove superfluous access$000 methods in java.util",
to track this issue. I can file a separate issue for java.lang.
I'm sure there are other ways, but a simple find reports them:
:>pwd
build/solaris-i586/classes/java/util
:> find . -name "*.class" -exec javap -v {} \; | grep '\.access\$00'
-Chris
On 07/12/2012 14:27, Doug Lea wrote:
> On 12/06/12 18:44, Remi Forax wrote:
>
>> BTW, at some point, it will be a good idea to get ride of all these
>> method
>> access$000 in java.lang/java.util at least.
>>
>
> Maybe this is out of scope for this CR, but while in the
> neighborhood of ThreadLocal, it could be done here.
> There are a couple of annoying ones that kick in on any
> compile of anything involving ThreadLocals (try running with
> -XX:+PrintCompilation). To remove, replace "private" with
> "final" for methods, and just kill "private" for fields.
>
> -Doug
>
>
>
From david.dehaven at oracle.com Fri Dec 7 15:38:34 2012
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 7 Dec 2012 07:38:34 -0800
Subject: Review request: 8004042 : Arrrghs.java test failed on windows
with access error.
In-Reply-To: <50C1507F.7040202@oracle.com>
References: <99E014EB-0210-4C77-BE43-88CED80B1825@oracle.com>
<50C03083.4030102@oracle.com>
<50C1507F.7040202@oracle.com>
Message-ID: <9365B2DD-5DFA-4B8D-9F37-8F4ED9D05772@oracle.com>
> OK, looks pretty good. But....
>
> One little thing is still bothering me. Suppose we get interrupted from the sleep() and bail out on that basis. If we got to the point where we're sleeping, we must have caught an AccessDeniedException previously. Unfortunately this exception is discarded if we were interrupted. This might lose valuable diagnostic information. So, what do we do with it? How about adding:
>
> ie.addSuppressed(cause);
>
> in the catch InterruptedException clause, before throwing the RuntimeException.
Another good point...
> (There's another issue which is that if there were previous retries, the ADEs from them are thrown away. But maybe we should save that one for another day.)
I had the same thought, but aside from collecting and reporting all of them somehow I'm not sure what could be done about it.
Maybe instead of:
cause = ade;
do:
if (cause != null) {
cause.addSuppressed(ade);
} else {
cause = ade;
}
Then they'll at least all be reported when RuntimeException is thrown.
-DrD-
From forax at univ-mlv.fr Fri Dec 7 15:46:34 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 07 Dec 2012 16:46:34 +0100
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C20C90.6070200@oracle.com>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C0CF83.1080208@oracle.com> <50C0D81A.5030607@cs.oswego.edu>
<50C0DD49.4060900@oracle.com> <50C0E3F2.9030004@cs.oswego.edu>
<50C0EBC9.2070101@univ-mlv.fr> <50C0F559.5090600@oracle.com>
<1354831513.40215.YahooMailNeo@web132104.mail.ird.yahoo.com>
<50C12DEC.9060006@univ-mlv.fr> <50C1FCD8.3030109@cs.oswego.edu>
<50C20C90.6070200@oracle.com>
Message-ID: <50C20F5A.8060900@univ-mlv.fr>
On 12/07/2012 04:34 PM, Chris Hegarty wrote:
> I filed 8004707: "Remove superfluous access$000 methods in java.util",
> to track this issue. I can file a separate issue for java.lang.
yes, please do that.
>
> I'm sure there are other ways, but a simple find reports them:
> :>pwd
> build/solaris-i586/classes/java/util
> :> find . -name "*.class" -exec javap -v {} \; | grep '\.access\$00'
Technically, javac also generate constructor accessors that doesn't
start by access00 but this should catch most of the generated accessors.
once changeset for 8003246 will be pushed, I will send two patches one
for java.lang and one for java.util.
>
> -Chris
R?mi
>
> On 07/12/2012 14:27, Doug Lea wrote:
>> On 12/06/12 18:44, Remi Forax wrote:
>>
>>> BTW, at some point, it will be a good idea to get ride of all these
>>> method
>>> access$000 in java.lang/java.util at least.
>>>
>>
>> Maybe this is out of scope for this CR, but while in the
>> neighborhood of ThreadLocal, it could be done here.
>> There are a couple of annoying ones that kick in on any
>> compile of anything involving ThreadLocals (try running with
>> -XX:+PrintCompilation). To remove, replace "private" with
>> "final" for methods, and just kill "private" for fields.
>>
>> -Doug
>>
>>
>>
From kumar.x.srinivasan at oracle.com Fri Dec 7 16:20:11 2012
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 07 Dec 2012 08:20:11 -0800
Subject: Review request: 8004042 : Arrrghs.java test failed on windows
with access error.
In-Reply-To: <9365B2DD-5DFA-4B8D-9F37-8F4ED9D05772@oracle.com>
References: <99E014EB-0210-4C77-BE43-88CED80B1825@oracle.com>
<50C03083.4030102@oracle.com>
<50C1507F.7040202@oracle.com>
<9365B2DD-5DFA-4B8D-9F37-8F4ED9D05772@oracle.com>
Message-ID: <50C2173B.1030500@oracle.com>
>> OK, looks pretty good. But....
>>
>> One little thing is still bothering me. Suppose we get interrupted from the sleep() and bail out on that basis. If we got to the point where we're sleeping, we must have caught an AccessDeniedException previously. Unfortunately this exception is discarded if we were interrupted. This might lose valuable diagnostic information. So, what do we do with it? How about adding:
>>
>> ie.addSuppressed(cause);
>>
>> in the catch InterruptedException clause, before throwing the RuntimeException.
> Another good point...
>
>
>> (There's another issue which is that if there were previous retries, the ADEs from them are thrown away. But maybe we should save that one for another day.)
> I had the same thought, but aside from collecting and reporting all of them somehow I'm not sure what could be done about it.
>
> Maybe instead of:
> cause = ade;
>
> do:
> if (cause != null) {
> cause.addSuppressed(ade);
> } else {
> cause = ade;
> }
>
> Then they'll at least all be reported when RuntimeException is thrown.
Very good point indeed, how about we also capture/print unconditionally
how many retries were made, this might give us some indication of the
gremlin we are dealing with.
Kumar
>
> -DrD-
>
From stuart.marks at oracle.com Fri Dec 7 16:22:16 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 07 Dec 2012 08:22:16 -0800
Subject: Review request: 8004042 : Arrrghs.java test failed on windows
with access error.
In-Reply-To: <9365B2DD-5DFA-4B8D-9F37-8F4ED9D05772@oracle.com>
References: <99E014EB-0210-4C77-BE43-88CED80B1825@oracle.com>
<50C03083.4030102@oracle.com>
<50C1507F.7040202@oracle.com>
<9365B2DD-5DFA-4B8D-9F37-8F4ED9D05772@oracle.com>
Message-ID: <50C217B8.7050001@oracle.com>
On 12/7/12 7:38 AM, David DeHaven wrote:
>> (There's another issue which is that if there were previous retries, the ADEs from them are thrown away. But maybe we should save that one for another day.)
>
> I had the same thought, but aside from collecting and reporting all of them somehow I'm not sure what could be done about it.
>
> Maybe instead of:
> cause = ade;
>
> do:
> if (cause != null) {
> cause.addSuppressed(ade);
> } else {
> cause = ade;
> }
>
> Then they'll at least all be reported when RuntimeException is thrown.
Ah, ok, this isn't bad at all! Let's go with this.
Did you need somebody to push this for you?
s'marks
From Alan.Bateman at oracle.com Fri Dec 7 16:32:44 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 07 Dec 2012 16:32:44 +0000
Subject: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser
factories (7169894: JAXP Plugability Layer: using service loader)
In-Reply-To: <50C207F9.5060307@oracle.com>
References: <50BCF7CD.1020308@oracle.com> <50BE007A.4090102@oracle.com>
<50BF73B2.5000102@oracle.com> <50C06DAC.5050500@oracle.com>
<50C0D805.5030509@oracle.com> <50C1A31D.1090805@oracle.com>
<50C1EB41.2010502@oracle.com> <50C207F9.5060307@oracle.com>
Message-ID: <50C21A2C.8070503@oracle.com>
On 07/12/2012 15:15, Daniel Fuchs wrote:
> Hi Alan,
>
> I have updated the webrev according to your suggestion. I think it makes
> things much clearer.
>
> The new version is there:
>
>
>
This looks good to me except that "implementation system default" should
be "system-default implementation".
-Alan
From david.dehaven at oracle.com Fri Dec 7 16:39:32 2012
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 7 Dec 2012 08:39:32 -0800
Subject: Review request: 8004042 : Arrrghs.java test failed on windows
with access error.
In-Reply-To: <50C217B8.7050001@oracle.com>
References: <99E014EB-0210-4C77-BE43-88CED80B1825@oracle.com>
<50C03083.4030102@oracle.com>
<50C1507F.7040202@oracle.com>
<9365B2DD-5DFA-4B8D-9F37-8F4ED9D05772@oracle.com>
<50C217B8.7050001@oracle.com>
Message-ID:
>>> (There's another issue which is that if there were previous retries, the ADEs from them are thrown away. But maybe we should save that one for another day.)
>>
>> I had the same thought, but aside from collecting and reporting all of them somehow I'm not sure what could be done about it.
>>
>> Maybe instead of:
>> cause = ade;
>>
>> do:
>> if (cause != null) {
>> cause.addSuppressed(ade);
>> } else {
>> cause = ade;
>> }
>>
>> Then they'll at least all be reported when RuntimeException is thrown.
>
> Ah, ok, this isn't bad at all! Let's go with this.
Sounds like a plan :)
> Did you need somebody to push this for you?
Kumar is going to push for me.
-DrD-
From mark.sheppard at oracle.com Fri Dec 7 16:57:59 2012
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Fri, 7 Dec 2012 08:57:59 -0800 (PST)
Subject: RFR: JDK-8003890: modify test scripts to pass VMOPTIONS
Message-ID: <780ee521-ef19-401b-9ed9-8c5cce2cb91c@default>
test scripts have been updated to invoke the JVM with an env variable TESTVMOPTS
which carries the vm options to be passed when the jvm is invoked in the test.
webrev location:
http://cr.openjdk.java.net/~chegar/8003890/webrev.00/
regards
Mark
From henry.jen at oracle.com Fri Dec 7 17:27:02 2012
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 7 Dec 2012 09:27:02 -0800
Subject: Request for Review: CR#8001667, second attempt
In-Reply-To: <50C1B23E.8010003@gmail.com>
References: <50C041D3.9060703@oracle.com> <50C1B23E.8010003@gmail.com>
Message-ID: <32DA82DE-9FFF-4ABA-BD38-480057EADE7A@oracle.com>
On Dec 7, 2012, at 1:09 AM, Peter Levart wrote:
> Hi Henry,
>
> I don't know what the plans are about moving the static methods in Comparators to the Comparator interface when static interface methods are enabled, but if that is planned, there will be a clash between Comparator.reverseOrder() default method and static method with same name and signature.
>
We will be exploring that along with other classes given static default method support ready.
Cheers,
Henry
From david.dehaven at oracle.com Fri Dec 7 18:09:04 2012
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 7 Dec 2012 10:09:04 -0800
Subject: Review request: 8004042 : Arrrghs.java test failed on windows
with access error.
In-Reply-To:
References: <99E014EB-0210-4C77-BE43-88CED80B1825@oracle.com>
<50C03083.4030102@oracle.com>
<50C1507F.7040202@oracle.com>
<9365B2DD-5DFA-4B8D-9F37-8F4ED9D05772@oracle.com>
<50C217B8.7050001@oracle.com>
Message-ID: <025D881F-A63C-4DDB-95B9-C75A939F91D4@oracle.com>
>>>> (There's another issue which is that if there were previous retries, the ADEs from them are thrown away. But maybe we should save that one for another day.)
>>>
>>> I had the same thought, but aside from collecting and reporting all of them somehow I'm not sure what could be done about it.
>>>
>>> Maybe instead of:
>>> cause = ade;
>>>
>>> do:
>>> if (cause != null) {
>>> cause.addSuppressed(ade);
>>> } else {
>>> cause = ade;
>>> }
>>>
>>> Then they'll at least all be reported when RuntimeException is thrown.
>>
>> Ah, ok, this isn't bad at all! Let's go with this.
>
> Sounds like a plan :)
>
>
>> Did you need somebody to push this for you?
>
> Kumar is going to push for me.
I updated the webrev, unfortunately I lost count and updated the same webrev so it's still at webrev.2. I'm doing a final sanity check and will submit a JPRT run when that's done.
http://cr.openjdk.java.net/~ddehaven/8004042/webrev.2/
-DrD-
From mandy.chung at oracle.com Fri Dec 7 18:37:09 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 07 Dec 2012 10:37:09 -0800
Subject: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser
factories (7169894: JAXP Plugability Layer: using service loader)
In-Reply-To: <50C21A2C.8070503@oracle.com>
References: <50BCF7CD.1020308@oracle.com> <50BE007A.4090102@oracle.com>
<50BF73B2.5000102@oracle.com> <50C06DAC.5050500@oracle.com>
<50C0D805.5030509@oracle.com> <50C1A31D.1090805@oracle.com>
<50C1EB41.2010502@oracle.com> <50C207F9.5060307@oracle.com>
<50C21A2C.8070503@oracle.com>
Message-ID: <50C23755.5030503@oracle.com>
On 12/7/12 8:32 AM, Alan Bateman wrote:
> On 07/12/2012 15:15, Daniel Fuchs wrote:
>> Hi Alan,
>>
>> I have updated the webrev according to your suggestion. I think it makes
>> things much clearer.
>>
>> The new version is there:
>>
>>
>>
> This looks good to me except that "implementation system default"
> should be "system-default implementation".
>
Looks good to me too with the change to "system-default implementation".
Mandy
From jim.gish at oracle.com Fri Dec 7 19:18:38 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Fri, 07 Dec 2012 14:18:38 -0500
Subject: RFR: 8004651 - TEST: java/util/logging/CheckLockLocationTest.java
failed to delete file (win)
Message-ID: <50C2410E.7040200@oracle.com>
Please review
http://cr.openjdk.java.net/~jgish/Bug8004651-CheckLockLocationTest-Windows-delete-file-fix/
Summary -- failure to delete a test log should be a warning instead of a
failure. Also, while fixing this problem another one popped up -- not
all platforms generate the same message in the FileSystemException ("Not
a directory"), so removing the exception content check.
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com
From Alan.Bateman at oracle.com Fri Dec 7 19:18:58 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 07 Dec 2012 19:18:58 +0000
Subject: RFR: JDK-8003890: modify test scripts to pass VMOPTIONS
In-Reply-To: <780ee521-ef19-401b-9ed9-8c5cce2cb91c@default>
References: <780ee521-ef19-401b-9ed9-8c5cce2cb91c@default>
Message-ID: <50C24122.10302@oracle.com>
On 07/12/2012 16:57, Mark Sheppard wrote:
>
>
> test scripts have been updated to invoke the JVM with an env variable TESTVMOPTS
> which carries the vm options to be passed when the jvm is invoked in the test.
>
> webrev location:
>
> http://cr.openjdk.java.net/~chegar/8003890/webrev.00/
>
> regards
> Mark
This is long overdue, thank you!
With your changes it means that these tests will actually test what we
think they are testing, eg: "jtreg -vmoption:-client" will actually use
the client VM to give a simple example. Also it means that finally we
can control the heap size of these tests, really important when running
tests concurrently. Finally it means that we can do code coverage and
use other tool agents with the shell tests, impossible until now.
Clearly we need to try to replace as many of these shell tests as
possible over time but that is a much longer term effort.
I skimmed over the patch file and nothing obvious jumped out. The main
thing that I looked for was tests that were specifying VM options that
might conflict with options passed into jtreg. A few minor comments:
- it's okay to ignore java/nio/Buffer/genBasic.sh and
java/nio/Buffer/genCopyDirectMemory.sh as they are used to generate the
tests and so aren't used in the actual test execution.
- java/nio/channels/AsynchronousChannelGroup/run_any_task.sh, I see this
is using -XX:-UseVMInterruptibleIO. This isn't needed any more so you
can remove it while you are there.
One final point is that jdk/test/Makefile will likely require changes
too but that is separate to your changes.
-Alan
From mandy.chung at oracle.com Fri Dec 7 19:38:07 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 07 Dec 2012 11:38:07 -0800
Subject: 8004371: (props) Properties.loadFromXML needs small footprint
XML parser as fallback when JAXP is not present
In-Reply-To: <50BF994B.5020308@oracle.com>
References: <50BF994B.5020308@oracle.com>
Message-ID: <50C2459F.6080102@oracle.com>
On 12/5/12 10:58 AM, Alan Bateman wrote:
> http://cr.openjdk.java.net/~alanb/8004371/webrev/
>
Yay! Properties no longer requires JAXP to be present in order to
load/store properties in XML format. This looks okay to me. Some minor
comments:
XMLStreamWriterImpl.isEncodingSupported - it returns true if any string
!= "UTF-32" that assumes the given encoding is one of the few known
values. Would it be better to check the explicit list of supported
encoding?
private boolean isEncodingSupported(String encoding) {
if (encoding.equalsIgnoreCase("UTF-32")) {
return false;
}
return true;
}
PropertiesDefaultHandler.java L115-116: can be replaced with
Properties.stringPropertyNames() and foreach.
XMLStreamWriterImpl.java L156 - since the caller needs to unwrap
XMLStreamException to determine if the encoding is supported or not,
maybe better to throw this constructor to throw
UnsupportedEncodingException.
Perhaps s/SAXParserImp/SAXParserImpl be consistent with the other
classname e.g. XMLStreamWriterImpl.
As you mentioned, there is still a good bit of clean-up required and I
skip the style and coding convention comments. One question though -
jdk.internal.org.xml.sax.** are copied from JAXP source. What should
the copyright years be? It currently retains the same value from the
original copy.
> One issue that I'm still mulling over, as least for the profiles
> effort, is whether to only include the fallback provider in the
> smallest profile as it won't be used otherwise. If the eventual size
> isn't too significant then it might not be worth it of course.
Do you plan to include jdk.internal.util.xml.BasicXmlPropertiesProvider
in META-INF/services/sun.util.spi.XmlPropertiesProvider?
I guess you are referring to what makefile change should be depending on
the decision?
Mandy
From mike.duigou at oracle.com Fri Dec 7 21:02:09 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 7 Dec 2012 13:02:09 -0800
Subject: Request for Review : CR#8004015 : [final (?) pass] Add interface
extends and defaults for basic functional interfaces
In-Reply-To: <50C088BE.1040403@oracle.com>
References:
<0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com>
<50C035F5.4050007@oracle.com> <50C088BE.1040403@oracle.com>
Message-ID: <2D5B0B63-59C9-4989-B8C7-D5A9D41FF7C0@oracle.com>
On Dec 6 2012, at 03:59 , Chris Hegarty wrote:
> Mike,
>
> Some small comments.
>
> 1) IntUnaryOperator.java
>
> Typo in:
> + 30 * This is the primitive type specialization of {@link IntUnaryOperator} for
> + 31 * {@code int} and also may be used as a {@code IntUnaryOperator}. When
> + 32 * used as a {@code IntUnaryOperator} the default {@code operate} implementation
> + 33 * provided by this interface neither accepts null parameters nor does it return
> + 34 * null results.
>
> IntUnaryOperator -> UnaryOperator
Corrected.
>
> 2) Double/Int/Long Function
>
> "When used as a Function the default apply implementation provided
> by this interface neither accepts null parameters nor does it
> return null results."
>
> "When used as a Function", is this really necessary, or should the
> behavior of the default apply method just be described?
I agree that this is somewhat awkward. I will see if I can't think of something better.
> Why the restriction on null parameters, it seems overly restrictive
> since applyAsXXXX accepts nulls, right?
Corrected. Thank you for noticing this.
> 3) package description
>
> "null values are accepted and returned by these functional
> interfaces according to the constraints of the specification in
> which the functional interfaces are used. The functional interfaces
> themselves do not constrain or mandate use of null values. Most
> usages of the functional interfaces will define the role, if any,
> of null for that context."
>
> Given these changes, doesn't this need to be reworked ( to indicate
> that some methods specify null value behavior)?
>
> 4) Trivially, IntSupplier is missing a '', before "This is the
> primitive type..."
>
> 5) I agree with David, NPE should be defined where applicable.
I am adding these though I am still somewhat resistant for reasons I will mention in next review cycle thread
Mike
From david.dehaven at oracle.com Fri Dec 7 21:39:29 2012
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 7 Dec 2012 13:39:29 -0800
Subject: Review request: 8004042 : Arrrghs.java test failed on windows
with access error.
In-Reply-To: <025D881F-A63C-4DDB-95B9-C75A939F91D4@oracle.com>
References: <99E014EB-0210-4C77-BE43-88CED80B1825@oracle.com>
<50C03083.4030102@oracle.com>
<50C1507F.7040202@oracle.com>
<9365B2DD-5DFA-4B8D-9F37-8F4ED9D05772@oracle.com>
<50C217B8.7050001@oracle.com>
<025D881F-A63C-4DDB-95B9-C75A939F91D4@oracle.com>
Message-ID:
Hopefully final webrev for this change:
http://cr.openjdk.java.net/~ddehaven/8004042/webrev.3/
I moved the createBatFile method to TestHelper as I thought it could be useful to other tests and added more diagnostic info.
It turns out the culprit on my machine was Windows' "Application Experience" service. Each time the batch file is launched svchost.exe tries to access the file, if it doesn't release it's file locks quickly enough then when java attempts to create a new file it fails with AccessDeniedException. In procmon this was showing up as a "DELETE PENDING" result, followed by svchost.exe getting the same result at least twice then giving up. Disabling that service allowed me to run my filesystem tests unpatched without failing.
I don't see any other option to fix this as this is somewhat expected of asynchronous access in a multitasking environment. Maybe there's some means to synchronously delete files...
-DrD-
From mandy.chung at oracle.com Fri Dec 7 21:55:36 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 07 Dec 2012 13:55:36 -0800
Subject: Review request: 8003562: Provide a command-line tool to find
static dependencies
In-Reply-To: <50BFF69E.1040805@oracle.com>
References: <50B54A2C.1040907@oracle.com> <50BFF69E.1040805@oracle.com>
Message-ID: <50C265D8.3050107@oracle.com>
This is the updated webrev. It includes Erik's makefile changes and
small change - be consistent with javap, jdeps can take classnames as
the input argument or wildcard "*" to analyze all class files that
replaces the "-all" option.
Webrev:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/jdeps/webrev.03/
Mandy
On 12/5/12 5:36 PM, Mandy Chung wrote:
> This review request (add a new jdeps tool in the JDK) include changes in
> langtools and the jdk build. I would need reviewers from the langtools
> and the build-infra team.
>
> Webrev for review:
>
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/jdeps/langtools-webrev.02/
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/jdeps/jdk-webrev.02/
>
> The jdeps source is in the langtools repo. The change in the jdk repo is
> to add the new jdeps executable. I made change in the old and new build
> for the addition of this new jdeps tool. I discussed with Jon whether I
> should modify langtools/make/build.xml to add a new jdeps target. Since
> the old build will be replaced by the new build soon, I simply add
> com/sun/tools/jdeps as part of javap.includes.
>
> Alan,
>
> The -d option is kept as a hidden option and use as implementation. We
> can remove it when it's determined not useful in the future. I also
> rename -v:summary to -summary.
>
> Thanks
> Mandy
>
> ----------------------------
>
> $ jdep -h
> Usage: jdeps
> where possible options include:
> -version Version information
> -classpath Specify where to find class files
> -summary Print dependency summary only
> -v:class Print class-level dependencies
> -v:package Print package-level dependencies
> -p Restrict analysis to classes in this package
> (may be given multiple times)
> -e Restrict analysis to packages matching pattern
> (-p and -e are exclusive)
> -P --profile Show profile or the file containing a package
> -R --recursive Traverse all dependencies recursively
> -all Process all classes specified in -classpath
>
> $ jdep Notepad.jar Ensemble.jar
> Notepad.jar -> D:\tools\devtools\jdk8\windows-i586\jre\lib\rt.jar
> (Notepad.jar)
> -> java.awt
> -> java.awt.event
> -> java.beans
> -> java.io
> -> java.lang
> -> java.net
> -> java.util
> -> java.util.logging
> -> javax.swing
> -> javax.swing.border
> -> javax.swing.event
> -> javax.swing.text
> -> javax.swing.tree
> -> javax.swing.undo
>
> Ensemble.jar -> D:\tools\devtools\jdk8\windows-i586\jre\lib\jfxrt.jar
> Ensemble.jar -> D:\tools\devtools\jdk8\windows-i586\jre\lib\rt.jar
> com.javafx.main (Ensemble.jar)
> -> java.applet
> -> java.awt
> -> java.awt.event
> -> java.io
> -> java.lang
> -> java.lang.reflect
> -> java.net
> -> java.security
> -> java.util
> -> java.util.jar
> -> javax.swing
> -> sun.misc JDK internal API
> (rt.jar)
From Alan.Bateman at oracle.com Fri Dec 7 22:14:09 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 07 Dec 2012 22:14:09 +0000
Subject: 8004371: (props) Properties.loadFromXML needs small footprint
XML parser as fallback when JAXP is not present
In-Reply-To: <50C2459F.6080102@oracle.com>
References: <50BF994B.5020308@oracle.com> <50C2459F.6080102@oracle.com>
Message-ID: <50C26A31.1070100@oracle.com>
On 07/12/2012 19:38, Mandy Chung wrote:
> :
> Yay! Properties no longer requires JAXP to be present in order to
> load/store properties in XML format. This looks okay to me. Some
> minor comments:
Thanks for going through it, I'll leave it Joe to respond as he did the
work.
> :
>
> As you mentioned, there is still a good bit of clean-up required and I
> skip the style and coding convention comments. One question though -
> jdk.internal.org.xml.sax.** are copied from JAXP source. What should
> the copyright years be? It currently retains the same value from the
> original copy.
As the package has changed then the end year should probably be changed
(which should happen anyway when the script to do bulk updates is run
again).
>
>> One issue that I'm still mulling over, as least for the profiles
>> effort, is whether to only include the fallback provider in the
>> smallest profile as it won't be used otherwise. If the eventual size
>> isn't too significant then it might not be worth it of course.
>
> Do you plan to include
> jdk.internal.util.xml.BasicXmlPropertiesProvider in
> META-INF/services/sun.util.spi.XmlPropertiesProvider?
>
> I guess you are referring to what makefile change should be depending
> on the decision?
For profiles then I think it should only be in compact1 but that would
complicate the build. It's something for David Holmes to comment on as
he is doing the build work in jdk8/profiles. For modules then we can
include it in the base module or else put it into its own service
provider module.
-Alan
From mandy.chung at oracle.com Fri Dec 7 22:25:49 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 07 Dec 2012 14:25:49 -0800
Subject: 8004371: (props) Properties.loadFromXML needs small footprint
XML parser as fallback when JAXP is not present
In-Reply-To: <50C26A31.1070100@oracle.com>
References: <50BF994B.5020308@oracle.com> <50C2459F.6080102@oracle.com>
<50C26A31.1070100@oracle.com>
Message-ID: <50C26CED.2070701@oracle.com>
On 12/7/12 2:14 PM, Alan Bateman wrote:
>> One question though - jdk.internal.org.xml.sax.** are copied from
>> JAXP source. What should the copyright years be? It currently
>> retains the same value from the original copy.
> As the package has changed then the end year should probably be
> changed (which should happen anyway when the script to do bulk updates
> is run again).
To be specific, what should the start year be in the new copy?
Mandy
From huizhe.wang at oracle.com Fri Dec 7 23:24:49 2012
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 07 Dec 2012 15:24:49 -0800
Subject: 8004371: (props) Properties.loadFromXML needs small footprint
XML parser as fallback when JAXP is not present
In-Reply-To: <50C2459F.6080102@oracle.com>
References: <50BF994B.5020308@oracle.com> <50C2459F.6080102@oracle.com>
Message-ID: <50C27AC1.2050600@oracle.com>
Thanks for reviewing the changes. Please see comments inline.
On 12/7/2012 11:38 AM, Mandy Chung wrote:
> On 12/5/12 10:58 AM, Alan Bateman wrote:
>> http://cr.openjdk.java.net/~alanb/8004371/webrev/
>>
>
> Yay! Properties no longer requires JAXP to be present in order to
> load/store properties in XML format. This looks okay to me. Some
> minor comments:
>
> XMLStreamWriterImpl.isEncodingSupported - it returns true if any
> string != "UTF-32" that assumes the given encoding is one of the few
> known values. Would it be better to check the explicit list of
> supported encoding?
> private boolean isEncodingSupported(String encoding) {
> if (encoding.equalsIgnoreCase("UTF-32")) {
> return false;
> }
> return true;
> }
The spec only requires UTF-8 and 16. But the writer can actually handle
most of the encodings. An explicit list would be quite long and require
comprehensive tests. Since the ukit parser explicitly rejects UTF-32, I
chose to do the same. Other than that, the XMLWriter leaves it to
java.nio.charset.Charset to determine if a specified encoding is
supported through this call:
try {
cs = Charset.forName(encoding);
} catch (IllegalCharsetNameException |
UnsupportedCharsetException ex) {
throw new XMLStreamException(new
UnsupportedEncodingException(encoding));
}
>
> PropertiesDefaultHandler.java L115-116: can be replaced with
> Properties.stringPropertyNames() and foreach.
Done. Will send update to Alan.
>
> XMLStreamWriterImpl.java L156 - since the caller needs to unwrap
> XMLStreamException to determine if the encoding is supported or not,
> maybe better to throw this constructor to throw
> UnsupportedEncodingException.
The writer implements partially the original StAX API. So I tried not
to change the writer API. But java.util.Properties expect
UnsupportedEncodingException in case of invalid encoding, thus the
compromise.
>
> Perhaps s/SAXParserImp/SAXParserImpl be consistent with the other
> classname e.g. XMLStreamWriterImpl.
SAXParserImp was from UKit, but I followed StAX's convention for
XMLStreamWriterImpl :) I'll rename SAXParserImp to SAXParserImpl.
>
> As you mentioned, there is still a good bit of clean-up required and I
> skip the style and coding convention comments. One question though -
> jdk.internal.org.xml.sax.** are copied from JAXP source. What should
> the copyright years be? It currently retains the same value from the
> original copy.
I thought the rule was that the copyright years be retained if there's
no material change. But I saw Alan's comment that it'd be done by a
script. So I'll leave it as is for now.
Thanks,
Joe
>
>> One issue that I'm still mulling over, as least for the profiles
>> effort, is whether to only include the fallback provider in the
>> smallest profile as it won't be used otherwise. If the eventual size
>> isn't too significant then it might not be worth it of course.
>
> Do you plan to include
> jdk.internal.util.xml.BasicXmlPropertiesProvider in
> META-INF/services/sun.util.spi.XmlPropertiesProvider?
>
> I guess you are referring to what makefile change should be depending
> on the decision?
>
> Mandy
From mandy.chung at oracle.com Fri Dec 7 23:37:30 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 07 Dec 2012 15:37:30 -0800
Subject: 8004371: (props) Properties.loadFromXML needs small footprint
XML parser as fallback when JAXP is not present
In-Reply-To: <50C27AC1.2050600@oracle.com>
References: <50BF994B.5020308@oracle.com> <50C2459F.6080102@oracle.com>
<50C27AC1.2050600@oracle.com>
Message-ID: <50C27DBA.3050808@oracle.com>
On 12/7/12 3:24 PM, Joe Wang wrote:
> Thanks for reviewing the changes. Please see comments inline.
>
> On 12/7/2012 11:38 AM, Mandy Chung wrote:
>> On 12/5/12 10:58 AM, Alan Bateman wrote:
>>> http://cr.openjdk.java.net/~alanb/8004371/webrev/
>>>
>>
>> Yay! Properties no longer requires JAXP to be present in order to
>> load/store properties in XML format. This looks okay to me. Some
>> minor comments:
>>
>> XMLStreamWriterImpl.isEncodingSupported - it returns true if any
>> string != "UTF-32" that assumes the given encoding is one of the few
>> known values. Would it be better to check the explicit list of
>> supported encoding?
>> private boolean isEncodingSupported(String encoding) {
>> if (encoding.equalsIgnoreCase("UTF-32")) {
>> return false;
>> }
>> return true;
>> }
>
> The spec only requires UTF-8 and 16. But the writer can actually
> handle most of the encodings. An explicit list would be quite long and
> require comprehensive tests. Since the ukit parser explicitly rejects
> UTF-32, I chose to do the same. Other than that, the XMLWriter leaves
> it to java.nio.charset.Charset to determine if a specified encoding is
> supported through this call:
> try {
> cs = Charset.forName(encoding);
> } catch (IllegalCharsetNameException |
> UnsupportedCharsetException ex) {
> throw new XMLStreamException(new
> UnsupportedEncodingException(encoding));
> }
OK - you leave it for XMLWriter to check if it's a valid encoding. It
may be better to include Charset.forName check in the
isEncodingSupporting method that would avoid confusion.
>>
>> PropertiesDefaultHandler.java L115-116: can be replaced with
>> Properties.stringPropertyNames() and foreach.
>
> Done. Will send update to Alan.
>
>>
>> XMLStreamWriterImpl.java L156 - since the caller needs to unwrap
>> XMLStreamException to determine if the encoding is supported or not,
>> maybe better to throw this constructor to throw
>> UnsupportedEncodingException.
>
> The writer implements partially the original StAX API. So I tried not
> to change the writer API. But java.util.Properties expect
> UnsupportedEncodingException in case of invalid encoding, thus the
> compromise.
>
OK - PropertiesDefaultHandler uses the XMLStreamWriter API. That's fine
with me.
Thanks
Mandy
From mandy.chung at oracle.com Fri Dec 7 23:46:46 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 07 Dec 2012 15:46:46 -0800
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To: <50BF371A.1060604@oracle.com>
References: <50BF371A.1060604@oracle.com>
Message-ID: <50C27FE6.1050107@oracle.com>
On 12/5/12 3:59 AM, David Holmes wrote:
> Java 7 introduced support for parallel classloading by adding to each
> class loader a ConcurrentHashMap, referenced through a new field,
> parallelLockMap. This contains a mapping from class names to Objects
> to use as a classloading lock for that class name. This scheme has a
> number of inefficiencies. To address this we propose for Java 8 the
> notion of a fully concurrent classloader ...
>
> This is a fairly simple proposal that I've written up as a blog entry:
>
> https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent
>
>
It's a good and simple proposal and also handles the backward
compatibility nicely.
I think having getClassLoadingLock() to return null for a fully
concurrent loader is a good idea. In case if any code synchronizes on
the returned value after migrating to fully concurrent class loader, it
will catch such usage (it might be very rare)/
I agree with Alan's suggestion - we should consider deprecating
registerAsParallelCapable.
Mandy
From stuart.marks at oracle.com Sat Dec 8 00:58:24 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 07 Dec 2012 16:58:24 -0800
Subject: Review request: 8004042 : Arrrghs.java test failed on windows
with access error.
In-Reply-To:
References: <99E014EB-0210-4C77-BE43-88CED80B1825@oracle.com>
<50C03083.4030102@oracle.com>
<50C1507F.7040202@oracle.com>
<9365B2DD-5DFA-4B8D-9F37-8F4ED9D05772@oracle.com>
<50C217B8.7050001@oracle.com>
<025D881F-A63C-4DDB-95B9-C75A939F91D4@oracle.com>
Message-ID: <50C290B0.10802@oracle.com>
On 12/7/12 1:39 PM, David DeHaven wrote:
>
> Hopefully final webrev for this change:
> http://cr.openjdk.java.net/~ddehaven/8004042/webrev.3/
>
> I moved the createBatFile method to TestHelper as I thought it could be useful to other tests and added more diagnostic info.
>
> It turns out the culprit on my machine was Windows' "Application Experience" service. Each time the batch file is launched svchost.exe tries to access the file, if it doesn't release it's file locks quickly enough then when java attempts to create a new file it fails with AccessDeniedException. In procmon this was showing up as a "DELETE PENDING" result, followed by svchost.exe getting the same result at least twice then giving up. Disabling that service allowed me to run my filesystem tests unpatched without failing.
>
> I don't see any other option to fix this as this is somewhat expected of asynchronous access in a multitasking environment. Maybe there's some means to synchronously delete files...
Ah, the mysteries of Windows. The test looks fine.
s'marks
From akhil.arora at oracle.com Sat Dec 8 01:42:28 2012
From: akhil.arora at oracle.com (Akhil Arora)
Date: Fri, 07 Dec 2012 17:42:28 -0800
Subject: RFR: 8001647: In-place methods on Collection/List
Message-ID: <50C29B04.5070508@oracle.com>
As part of the Library Lambdafication, this patch adds the following
default methods to Collections -
Iterable.forEach(Block)
Collection.removeAll(Predicate)
List.sort(Comparator)
List.replaceAll(UnaryOperator)
It also provides more efficient implementations of these methods for
ArrayList, Vector and CopyOnWriteArrayList. Please review.
http://cr.openjdk.java.net/~akhil/8001647.1/webrev/
Thanks to the many people who have already contributed to this patch.
From Alan.Bateman at oracle.com Sat Dec 8 10:37:29 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 08 Dec 2012 10:37:29 +0000
Subject: Review request: 8004042 : Arrrghs.java test failed on windows
with access error.
In-Reply-To:
References: <99E014EB-0210-4C77-BE43-88CED80B1825@oracle.com>
<50C03083.4030102@oracle.com>
<50C1507F.7040202@oracle.com>
<9365B2DD-5DFA-4B8D-9F37-8F4ED9D05772@oracle.com>
<50C217B8.7050001@oracle.com>
<025D881F-A63C-4DDB-95B9-C75A939F91D4@oracle.com>
Message-ID: <50C31869.5030109@oracle.com>
On 07/12/2012 21:39, David DeHaven wrote:
> It turns out the culprit on my machine was Windows' "Application Experience" service. Each time the batch file is launched svchost.exe tries to access the file, if it doesn't release it's file locks quickly enough then when java attempts to create a new file it fails with AccessDeniedException. In procmon this was showing up as a "DELETE PENDING" result, followed by svchost.exe getting the same result at least twice then giving up. Disabling that service allowed me to run my filesystem tests unpatched without failing.
>
Good sleuthing, I guess some of us owe at least one AV vendor a written
apology :-)
I wonder if we should submit a bug to Microsoft, it's very surprising to
have a service running by default that causes interference like this.
This investigation also makes me wonder if
java/lang/Runtime/exec/WinCommand.java might be another victim.
-Alan
From peter.levart at gmail.com Sat Dec 8 12:41:20 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 08 Dec 2012 13:41:20 +0100
Subject: Request for Review: CR#8001667, second attempt
In-Reply-To: <32DA82DE-9FFF-4ABA-BD38-480057EADE7A@oracle.com>
References: <50C041D3.9060703@oracle.com> <50C1B23E.8010003@gmail.com>
<32DA82DE-9FFF-4ABA-BD38-480057EADE7A@oracle.com>
Message-ID: <50C33570.9020202@gmail.com>
On 12/07/2012 06:27 PM, Henry Jen wrote:
> On Dec 7, 2012, at 1:09 AM, Peter Levart wrote:
>
>> Hi Henry,
>>
>> I don't know what the plans are about moving the static methods in Comparators to the Comparator interface when static interface methods are enabled, but if that is planned, there will be a clash between Comparator.reverseOrder() default method and static method with same name and signature.
>>
> We will be exploring that along with other classes given static default method support ready.
>
> Cheers,
> Henry
>
And what about the aComparator.thenComparing(Comparator) method name? Do
you think it's ok to use the same name as in
aComparator.thenComparing(Function) ?
A suitable alternative might be aComparator.thenUsing(Comparator).
Regards, Peter
From peter.levart at gmail.com Sat Dec 8 13:27:10 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 08 Dec 2012 14:27:10 +0100
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <50C29B04.5070508@oracle.com>
References: <50C29B04.5070508@oracle.com>
Message-ID: <50C3402E.9050608@gmail.com>
On 12/08/2012 02:42 AM, Akhil Arora wrote:
> As part of the Library Lambdafication, this patch adds the following
> default methods to Collections -
>
> Iterable.forEach(Block)
> Collection.removeAll(Predicate)
> List.sort(Comparator)
> List.replaceAll(UnaryOperator)
>
> It also provides more efficient implementations of these methods for
> ArrayList, Vector and CopyOnWriteArrayList. Please review.
Yes!
There's finally a way to sort ArrayList's array in-place. Until now you
either had to resort to using arrays or a sub-optimal
Collections.sort(List) method.
Regards, Peter
From kumar.x.srinivasan at oracle.com Sun Dec 9 17:17:55 2012
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Sun, 09 Dec 2012 17:17:55 +0000
Subject: hg: jdk8/tl/jdk: 8004042: Arrrghs.java test failed on windows with
access error.
Message-ID: <20121209171842.20CC747FF6@hg.openjdk.java.net>
Changeset: da387f0cecb7
Author: ksrini
Date: 2012-12-09 07:43 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da387f0cecb7
8004042: Arrrghs.java test failed on windows with access error.
Reviewed-by: smarks, jjh, ksrini
Contributed-by: david.dehaven at oracle.com
! test/tools/launcher/Arrrghs.java
! test/tools/launcher/TestHelper.java
From alan.bateman at oracle.com Sun Dec 9 19:13:03 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sun, 09 Dec 2012 19:13:03 +0000
Subject: hg: jdk8/tl/jdk: 7194370: (fs) WatchService fails if volume S/N is 0
[win]
Message-ID: <20121209191314.ADFA647FF9@hg.openjdk.java.net>
Changeset: 343615aa0539
Author: dxu
Date: 2012-12-09 19:13 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/343615aa0539
7194370: (fs) WatchService fails if volume S/N is 0 [win]
Reviewed-by: alanb, forax
! src/windows/classes/sun/nio/fs/WindowsFileAttributes.java
From masayoshi.okutsu at oracle.com Mon Dec 10 02:01:06 2012
From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com)
Date: Mon, 10 Dec 2012 02:01:06 +0000
Subject: hg: jdk8/tl/jdk: 8000983: Support narrow display names for calendar
fields; ...
Message-ID: <20121210020127.5EB7747FFC@hg.openjdk.java.net>
Changeset: fda257689786
Author: okutsu
Date: 2012-12-10 10:52 +0900
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fda257689786
8000983: Support narrow display names for calendar fields
8003267: Support generic time zone names in TimeZoneNameProvider (SPI)
Reviewed-by: naoto
! make/tools/src/build/tools/cldrconverter/Bundle.java
! make/tools/src/build/tools/cldrconverter/BundleGenerator.java
! make/tools/src/build/tools/cldrconverter/CLDRConverter.java
! make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java
! make/tools/src/build/tools/cldrconverter/MetaZonesParseHandler.java
! make/tools/src/build/tools/cldrconverter/ResourceBundleGenerator.java
! src/share/classes/java/text/DateFormatSymbols.java
! src/share/classes/java/text/SimpleDateFormat.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/JapaneseImperialCalendar.java
! src/share/classes/java/util/TimeZone.java
! src/share/classes/java/util/spi/CalendarNameProvider.java
! src/share/classes/java/util/spi/TimeZoneNameProvider.java
! src/share/classes/sun/text/resources/FormatData.java
! src/share/classes/sun/text/resources/ar/FormatData_ar.java
! src/share/classes/sun/text/resources/be/FormatData_be.java
! src/share/classes/sun/text/resources/bg/FormatData_bg.java
! src/share/classes/sun/text/resources/ca/FormatData_ca.java
! src/share/classes/sun/text/resources/cs/FormatData_cs.java
! src/share/classes/sun/text/resources/da/FormatData_da.java
! src/share/classes/sun/text/resources/de/FormatData_de.java
! src/share/classes/sun/text/resources/el/FormatData_el.java
! src/share/classes/sun/text/resources/es/FormatData_es.java
! src/share/classes/sun/text/resources/et/FormatData_et.java
! src/share/classes/sun/text/resources/fi/FormatData_fi.java
! src/share/classes/sun/text/resources/fr/FormatData_fr.java
! src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java
! src/share/classes/sun/text/resources/hr/FormatData_hr.java
! src/share/classes/sun/text/resources/hu/FormatData_hu.java
! src/share/classes/sun/text/resources/is/FormatData_is.java
! src/share/classes/sun/text/resources/it/FormatData_it.java
! src/share/classes/sun/text/resources/iw/FormatData_iw.java
! src/share/classes/sun/text/resources/ja/FormatData_ja.java
! src/share/classes/sun/text/resources/ko/FormatData_ko.java
! src/share/classes/sun/text/resources/lt/FormatData_lt.java
! src/share/classes/sun/text/resources/lv/FormatData_lv.java
! src/share/classes/sun/text/resources/mk/FormatData_mk.java
! src/share/classes/sun/text/resources/ms/FormatData_ms.java
! src/share/classes/sun/text/resources/mt/FormatData_mt.java
! src/share/classes/sun/text/resources/nl/FormatData_nl.java
! src/share/classes/sun/text/resources/pl/FormatData_pl.java
! src/share/classes/sun/text/resources/pt/FormatData_pt.java
! src/share/classes/sun/text/resources/ro/FormatData_ro.java
! src/share/classes/sun/text/resources/ru/FormatData_ru.java
! src/share/classes/sun/text/resources/sk/FormatData_sk.java
! src/share/classes/sun/text/resources/sl/FormatData_sl.java
! src/share/classes/sun/text/resources/sq/FormatData_sq.java
! src/share/classes/sun/text/resources/sr/FormatData_sr.java
! src/share/classes/sun/text/resources/sv/FormatData_sv.java
! src/share/classes/sun/text/resources/th/FormatData_th.java
! src/share/classes/sun/text/resources/tr/FormatData_tr.java
! src/share/classes/sun/text/resources/uk/FormatData_uk.java
! src/share/classes/sun/text/resources/vi/FormatData_vi.java
! src/share/classes/sun/text/resources/zh/FormatData_zh.java
! src/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java
! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/LocaleResources.java
! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java
! src/share/classes/sun/util/resources/LocaleData.java
! src/share/classes/sun/util/resources/OpenListResourceBundle.java
! src/share/classes/sun/util/resources/TimeZoneNames.java
! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java
+ test/java/util/Calendar/GenericTimeZoneNamesTest.java
+ test/java/util/Calendar/GenericTimeZoneNamesTest.sh
+ test/java/util/Calendar/NarrowNamesTest.java
+ test/java/util/Calendar/NarrowNamesTest.sh
! test/java/util/PluggableLocale/GenericTest.java
! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java
! test/java/util/PluggableLocale/TimeZoneNameProviderTest.sh
! test/java/util/PluggableLocale/barprovider.jar
+ test/java/util/PluggableLocale/providersrc/GenericTimeZoneNameProviderImpl.java
! test/java/util/PluggableLocale/providersrc/Makefile
! test/java/util/PluggableLocale/providersrc/java.util.spi.TimeZoneNameProvider
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java
From david.holmes at oracle.com Mon Dec 10 03:53:21 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 10 Dec 2012 13:53:21 +1000
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To: <50C08264.80804@gmail.com>
References: <50BF371A.1060604@oracle.com> <50C08264.80804@gmail.com>
Message-ID: <50C55CB1.3000901@oracle.com>
Hi Peter,
I think your middle-ground sounds like it may have been a better choice
for JDK 7. But for this proposal I want to try and leave parallel
loaders behind and move to the fully concurrent model.
The real crux of my proposal is how often you really do get concurrent
load attempts and so waste effort doing concurrent findClass for the
same class. Obviously you can easily construct the pathological
microbenchmark for this, but I'd like to base this on real experiences.
The question then is whether some additional flow-control can be added
to the fully concurrent model, if it proves necessary.
Thanks,
David
On 6/12/2012 9:32 PM, Peter Levart wrote:
> Hi David,
>
> What about a middle-ground mode where findLoadedClass() and delegation
> to parent would be called without locks and only findClass() would be
> guarded by a per-class-name-per-classloader lock? In this mode
> concurrent attempts to define the same class would still be possible,
> but the possibility would be much lower. Usually findClass() involves
> non-ignorable level of resource-intensive work (ZIP, IO, NET) before it
> calls defineClass()...
> Also, in this mode, the Map of locks could be implemented so that lock
> objects would be Weak(ly)Reference(d), since requests for already loaded
> classes would be satisfied by findLoadedClass() already. We'd just need
> a ConcurrentWeakValuesHashMap.
>
> There must be something I'm missing here, isn't it?
>
> Regards, Peter
>
> On 12/05/2012 12:59 PM, David Holmes wrote:
>> Java 7 introduced support for parallel classloading by adding to each
>> class loader a ConcurrentHashMap, referenced through a new field,
>> parallelLockMap. This contains a mapping from class names to Objects
>> to use as a classloading lock for that class name. This scheme has a
>> number of inefficiencies. To address this we propose for Java 8 the
>> notion of a fully concurrent classloader ...
>>
>> This is a fairly simple proposal that I've written up as a blog entry:
>>
>> https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent
>>
>>
>> Please discuss this proposal here.
>>
>> Thanks,
>> David Holmes
>>
>
From david.holmes at oracle.com Mon Dec 10 03:54:26 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 10 Dec 2012 13:54:26 +1000
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To: <50C08305.90907@oracle.com>
References: <50BF371A.1060604@oracle.com> <50C08305.90907@oracle.com>
Message-ID: <50C55CF2.3050809@oracle.com>
On 6/12/2012 9:35 PM, Alan Bateman wrote:
> On 05/12/2012 11:59, David Holmes wrote:
>> Java 7 introduced support for parallel classloading by adding to each
>> class loader a ConcurrentHashMap, referenced through a new field,
>> parallelLockMap. This contains a mapping from class names to Objects
>> to use as a classloading lock for that class name. This scheme has a
>> number of inefficiencies. To address this we propose for Java 8 the
>> notion of a fully concurrent classloader ...
>>
>> This is a fairly simple proposal that I've written up as a blog entry:
>>
>> https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent
>>
> The jdk7 implementation is very unfortunate, it's a pity this wasn't
> caught before 7 shipped.
>
> I think the proposal is good, it preserves compatibility, and if there
> are loaders calling registerAsParallelCapable now (probably very few)
> then it they may be able to change to using registerAsFullyConcurrent
> without too much work.
Thanks for your comments and support Alan.
> I am tempted to suggest that registerAsParallelCapable should be
> deprecated too.
I think that may be premature for 8, perhaps for 9?
David
> -Alan.
From david.holmes at oracle.com Mon Dec 10 04:03:29 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 10 Dec 2012 14:03:29 +1000
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To: <50C0B490.7050005@redhat.com>
References: <50BF371A.1060604@oracle.com> <50C08305.90907@oracle.com>
<50C0B490.7050005@redhat.com>
Message-ID: <50C55F11.6020801@oracle.com>
Hi David,
On 7/12/2012 1:06 AM, David M. Lloyd wrote:
> On 12/06/2012 05:35 AM, Alan Bateman wrote:
>> On 05/12/2012 11:59, David Holmes wrote:
>>> Java 7 introduced support for parallel classloading by adding to each
>>> class loader a ConcurrentHashMap, referenced through a new field,
>>> parallelLockMap. This contains a mapping from class names to Objects
>>> to use as a classloading lock for that class name. This scheme has a
>>> number of inefficiencies. To address this we propose for Java 8 the
>>> notion of a fully concurrent classloader ...
>>>
>>> This is a fairly simple proposal that I've written up as a blog entry:
>>>
>>> https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent
>>>
>>>
>> The jdk7 implementation is very unfortunate, it's a pity this wasn't
>> caught before 7 shipped.
>>
>> I think the proposal is good, it preserves compatibility, and if there
>> are loaders calling registerAsParallelCapable now (probably very few)
>> then it they may be able to change to using registerAsFullyConcurrent
>> without too much work.
>>
>> I am tempted to suggest that registerAsParallelCapable should be
>> deprecated too.
>
> I'm sorry I missed the original post, and I just want to add my
> wholehearted support for this idea. Our application server's class
> loader implementation can be configured (on certain JVMs) to run in a
> lock-free mode and we have seen good performance and memory footprint as
> a result on these particular JVMs.
That sounds promising. Are you in a position to try out this proposal on
a testbed with your app server?
> As far as the defineClass concurrent redefine issue goes - our current
> implementation simply does a try/catch for redefinition exceptions. If
> such an exception occurs, we load the concurrently defined class and
> return that. In practice, even with many threads, we would see
> relatively few such collisions. But, a tryDefineClass or
> defineClassIfNotPresent would be a welcome addition for certain.
To be clear, in this proposal defineClass, at the VM level
(SystemDictionary::find_or_define_instance_class), acts as a
defineClassIfNotPresent, and simply returns the class that has already
been defined if a race occurs.
> I'm very glad to see that Mr. Holmes has taken this initiative and found
> solutions to the various stumbling blocks.
This still requires extensive validation but I'm hopeful that this will
at least ameliorate the situation with the JDK's own classloaders, and
hopefully enable others to utilise fully concurrent loaders.
Thanks,
David
From david.holmes at oracle.com Mon Dec 10 04:08:51 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 10 Dec 2012 14:08:51 +1000
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To: <50C27FE6.1050107@oracle.com>
References: <50BF371A.1060604@oracle.com> <50C27FE6.1050107@oracle.com>
Message-ID: <50C56053.1060306@oracle.com>
Thanks for the comments Mandy.
On 8/12/2012 9:46 AM, Mandy Chung wrote:
> On 12/5/12 3:59 AM, David Holmes wrote:
>> Java 7 introduced support for parallel classloading by adding to each
>> class loader a ConcurrentHashMap, referenced through a new field,
>> parallelLockMap. This contains a mapping from class names to Objects
>> to use as a classloading lock for that class name. This scheme has a
>> number of inefficiencies. To address this we propose for Java 8 the
>> notion of a fully concurrent classloader ...
>>
>> This is a fairly simple proposal that I've written up as a blog entry:
>>
>> https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent
>>
>>
> It's a good and simple proposal and also handles the backward
> compatibility nicely.
>
> I think having getClassLoadingLock() to return null for a fully
> concurrent loader is a good idea. In case if any code synchronizes on
> the returned value after migrating to fully concurrent class loader, it
> will catch such usage (it might be very rare)/
The only glitch with this is that a concurrent loader is-a parallel
loader, so anyone trying work with an arbitrary parallel loader will
encounter a problem with a concurrent loader if they don't make their
code concurrent-loader aware. I am hopeful that the parallelLockMap is
only being used internally by the classloaders themselves, and that
there are no, or very few, external clients.
> I agree with Alan's suggestion - we should consider deprecating
> registerAsParallelCapable.
Definitely a consideration, though as I said perhaps for 9 rather than 8.
Thanks,
David
>
> Mandy
>
From david.holmes at oracle.com Mon Dec 10 06:18:24 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 10 Dec 2012 16:18:24 +1000
Subject: bottleneck by java.lang.Class.getAnnotations() - rebased patch
In-Reply-To: <50BC57A0.8000108@gmail.com>
References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com>
<23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com>
<5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com>
<5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com>
<50990CB8.2040400@gmail.com> <5099C2FA.2020202@oracle.com>
<509A3A63.5010102@gmail.com> <50AF5930.5010903@gmail.com>
<50AFADB4.9000204@gmail.com> <50B8FC99.401@gmail.com>
<50B900F2.9060902@oracle.com> <50BBFD2F.1080108@oracle.com>
<50BC57A0.8000108@gmail.com>
Message-ID: <50C57EB0.1000202@oracle.com>
Hi Peter,
Sorry for the delay on this.
Generally your VolatileData and my ReflectionHelper are doing a similar
job. But I agree with your reasoning that all of the cached
SoftReferences are likely to be cleared at once, and so a SoftReference
to a helper object with direct references, is more effective than a
direct reference to a helper object with SoftReferences. My initial
stance with this was very conservative as the more change that is
introduced the more uncertainty there is about the impact.
I say the above primarily because I think, if I am to proceed with this,
I will need to separate out the general reflection caching changes from
the annotation changes. There are a number of reasons for this:
First, I'm not at all familiar with the implementation of annotations at
the VM or Java level, and the recent changes in this area just
exacerbate my ignorance of the mechanics. So I don't feel qualified to
evaluate that aspect.
Second, the bulk of the reflection caching code is simplified by the
fact that due to current constraints on class redefinition the caching
is effectively idempotent for fields/methods/constructors. But that is
not the case for annotations.
Finally, the use of synchronization with the annotations method is
perplexing me. I sent Joe a private email on this but I may as well
raise it here - and I think you have alluded to this in your earlier
emails as well: initAnnotationsIfNecessary() is a synchronized instance
method but I can not find any other code in the VM that synchronizes on
the Class object's monitor. So if this synchronization is trying to
establish consistency in the face of class redefinition, I do not see
where class redefinition is participating in the synchronization!
So what I would like to do is take your basic VolatileData part of the
patch and run with it for JEP-149 purposes, while separating the
annotations issue so they can be dealt with by the experts in that
particular area.
I'm sorry it has taken so long to arrive at a fairly negative position,
but I need someone else to take up the annotations gauntlet and run with it.
Thanks,
David
On 3/12/2012 5:41 PM, Peter Levart wrote:
> Hi David, Alan, Alexander and others,
>
> In the meanwhile I have added another annotations space optimization to
> the patch. If a Class doesn't inherit any annotations from a superclass,
> which I think is a common case, it assigns the same Map instance to
> "annotations" as well as "declaredAnnotations" fields. Previously - and
> in the original code - this only happened for java.lang.Object and
> interfaces.
>
> Here's the updated webrev:
>
> http://dl.dropbox.com/u/101777488/jdk8-tl/JEP-149/webrev.02/index.html
>
> I have also rewritten the performance micro-benchmarks. With the
> addition of repeating annotations, one performance aspect surfaces: when
> asking for a particular annotation type on a Class and that annotation
> is not present, the new repeating annotations support method
> AnnotationSupport.getOneAnnotation asks for @ContainedBy meta-annotation
> on the annotation type. This can result in an even more apparent
> synchronization hot-spot with original code that uses synchronized
> initAnnotationsIfNecessary(). This aspect is tested with the 3rd test.
> Other 2 tests test the same thing as before but are more stable now,
> since now they measure retrieval of 5 different annotation types from
> each AnnotatedElement, previously they only measured retrieval of 1
> which was very sensitive to HashMap irregularities (it could happen that
> a particular key mapped to a bucket that was overloaded in one test-run
> and not in another)...
>
> Here're the new tests:
>
> https://raw.github.com/plevart/jdk8-tl/JEP-149/test/src/test/ReflectionTest.java
>
> And the corresponding results when run on an i7 CPU on Linux:
>
> https://raw.github.com/plevart/jdk8-tl/JEP-149/test/benchmark_results_i7-2600K.txt
>
>
> Regards, Peter
>
>
>
> On 12/03/2012 02:15 AM, David Holmes wrote:
>> On 1/12/2012 4:54 AM, Alan Bateman wrote:
>>> On 30/11/2012 18:36, Peter Levart wrote:
>>>> :
>>>>
>>>> So, what do you think? What kind of tests should I prepare in addidion
>>>> to those 3 so that the patch might get a consideration?
>>> I think this is good work and thanks for re-basing your patch. I know
>>> David plans to do a detail review. I think it will require extensive
>>> performance testing too, perhaps with some large applications.
>>
>> Indeed I do plan a detailed review and have initiated some initial
>> performance tests.
>>
>> I am also swamped but will try to get to the review this week - and
>> will also need to check the referenced annotations updates.
>>
>> David
>>
>>> -Alan
>>>
>
From david.buck at oracle.com Mon Dec 10 06:25:54 2012
From: david.buck at oracle.com (David Buck)
Date: Mon, 10 Dec 2012 15:25:54 +0900
Subject: code review request : 8003147 port fix for BCEL bug 39695
Message-ID: <50C58072.4060802@oracle.com>
Hi!
I would like to request a code review of my JDK8 fix for the following
issue:
[ 8003147 : port fix for BCEL bug 39695 to our copy bundled as part of
jaxp ]
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003147
In addition to the fix that the BCEL project had for this issue, I
needed to "port" some of their support for LocalVariableTypeTable:s to
our copy of BCEL as well. Implementing support for LVTT is very
straightforward and does not add much to the complexity or risk of this
change (especially considering the limited scope of jaxp's use of BCEL).
Here is the webrev for my fix:
[ Code Review for jaxp ]
http://cr.openjdk.java.net/~dbuck/8003147/webrev.00/
My understanding is that the test cases for our copy of the jaxp code
are handled in a separate repository / test suite. I have been in
contact with Patrick Zhang (Oracle QA) and Joe Wang and have provided a
junit test for this issue as requested. Please see bug report for a
simpler (non-junit) test-case. If for some reason anyone wants to see
the junit-based test, please let me know and I can provide a copy of
that as well.
Best Regards,
-Buck
From dingxmin at linux.vnet.ibm.com Mon Dec 10 07:44:33 2012
From: dingxmin at linux.vnet.ibm.com (Frank Ding)
Date: Mon, 10 Dec 2012 15:44:33 +0800
Subject: Review needed: 8004374 : Fwd: JDBC bug: Incorrect number of
conflicts is reported by CachedRowSetWriter.writeData
In-Reply-To:
References:
Message-ID: <50C592E1.9050400@linux.vnet.ibm.com>
Hi Lance,
The code refactory looks good. By the way, the newly added unit test
is not jtreg test case?
Best regards,
Frank
On 12/5/2012 4:38 AM, Lance Andersen - Oracle wrote:
> All,
>
> Attached is the patch for: 8004374 based off the issue that Frank
> reported.
>
> for http://cr.openjdk.java.net/~lancea/8004374/webrev.00/
>
>
> The TCK, SQE and the JDBC Unit Tests run clean. I added a new Unit
> Test to validate the issue.
>
> Frank, I did not use your fix as I was able to clean the code up a bit
> more and get rid of more crud while addressing it. It is similar though.
>
> Best
> Lance
>
>
>
>
>
> Lance
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
From Alan.Bateman at oracle.com Mon Dec 10 10:08:11 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 10 Dec 2012 10:08:11 +0000
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To: <50C55CF2.3050809@oracle.com>
References: <50BF371A.1060604@oracle.com> <50C08305.90907@oracle.com>
<50C55CF2.3050809@oracle.com>
Message-ID: <50C5B48B.60906@oracle.com>
On 10/12/2012 03:54, David Holmes wrote:
> :
>
>> I am tempted to suggest that registerAsParallelCapable should be
>> deprecated too.
>
> I think that may be premature for 8, perhaps for 9?
I think we should just it over with and deprecate it is now to
discourage usage. I don't have data but I'll bet that there are only are
handful of frameworks or app servers using it.
-Alan
From erik.joelsson at oracle.com Mon Dec 10 10:30:10 2012
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 10 Dec 2012 02:30:10 -0800 (PST)
Subject: Review request: 8003562: Provide a command-line tool to find
static dependencies
In-Reply-To: <50C265D8.3050107@oracle.com>
References: <50B54A2C.1040907@oracle.com> <50BFF69E.1040805@oracle.com>
<50C265D8.3050107@oracle.com>
Message-ID: <50C5B9B2.2050705@oracle.com>
Looks good.
/Erik
On 2012-12-07 22:55, Mandy Chung wrote:
> This is the updated webrev. It includes Erik's makefile changes and
> small change - be consistent with javap, jdeps can take classnames as
> the input argument or wildcard "*" to analyze all class files that
> replaces the "-all" option.
>
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/jdeps/webrev.03/
>
> Mandy
>
> On 12/5/12 5:36 PM, Mandy Chung wrote:
>> This review request (add a new jdeps tool in the JDK) include changes in
>> langtools and the jdk build. I would need reviewers from the langtools
>> and the build-infra team.
>>
>> Webrev for review:
>>
>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/jdeps/langtools-webrev.02/
>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/jdeps/jdk-webrev.02/
>>
>> The jdeps source is in the langtools repo. The change in the jdk
>> repo is
>> to add the new jdeps executable. I made change in the old and new build
>> for the addition of this new jdeps tool. I discussed with Jon whether I
>> should modify langtools/make/build.xml to add a new jdeps target. Since
>> the old build will be replaced by the new build soon, I simply add
>> com/sun/tools/jdeps as part of javap.includes.
>>
>> Alan,
>>
>> The -d option is kept as a hidden option and use as implementation. We
>> can remove it when it's determined not useful in the future. I also
>> rename -v:summary to -summary.
>>
>> Thanks
>> Mandy
>>
>> ----------------------------
>>
>> $ jdep -h
>> Usage: jdeps
>> where possible options include:
>> -version Version information
>> -classpath Specify where to find class files
>> -summary Print dependency summary only
>> -v:class Print class-level dependencies
>> -v:package Print package-level dependencies
>> -p Restrict analysis to classes in this package
>> (may be given multiple times)
>> -e Restrict analysis to packages matching
>> pattern
>> (-p and -e are exclusive)
>> -P --profile Show profile or the file containing a package
>> -R --recursive Traverse all dependencies recursively
>> -all Process all classes specified in -classpath
>>
>> $ jdep Notepad.jar Ensemble.jar
>> Notepad.jar -> D:\tools\devtools\jdk8\windows-i586\jre\lib\rt.jar
>> (Notepad.jar)
>> -> java.awt
>> -> java.awt.event
>> -> java.beans
>> -> java.io
>> -> java.lang
>> -> java.net
>> -> java.util
>> -> java.util.logging
>> -> javax.swing
>> -> javax.swing.border
>> -> javax.swing.event
>> -> javax.swing.text
>> -> javax.swing.tree
>> -> javax.swing.undo
>>
>> Ensemble.jar -> D:\tools\devtools\jdk8\windows-i586\jre\lib\jfxrt.jar
>> Ensemble.jar -> D:\tools\devtools\jdk8\windows-i586\jre\lib\rt.jar
>> com.javafx.main (Ensemble.jar)
>> -> java.applet
>> -> java.awt
>> -> java.awt.event
>> -> java.io
>> -> java.lang
>> -> java.lang.reflect
>> -> java.net
>> -> java.security
>> -> java.util
>> -> java.util.jar
>> -> javax.swing
>> -> sun.misc JDK internal API
>> (rt.jar)
>
From chris.hegarty at oracle.com Mon Dec 10 10:33:52 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 10 Dec 2012 02:33:52 -0800 (PST)
Subject: Request for Review : CR#8004015 : [final (?) pass] Add interface
extends and defaults for basic functional interfaces
In-Reply-To: <2D5B0B63-59C9-4989-B8C7-D5A9D41FF7C0@oracle.com>
References:
<0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com>
<50C035F5.4050007@oracle.com> <50C088BE.1040403@oracle.com>
<2D5B0B63-59C9-4989-B8C7-D5A9D41FF7C0@oracle.com>
Message-ID: <50C5BA90.9010204@oracle.com>
On 07/12/2012 21:02, Mike Duigou wrote:
> ...
>> 5) I agree with David, NPE should be defined where applicable.
>
> I am adding these though I am still somewhat resistant for reasons I will mention in next review cycle thread
I don't want to to get bogged down in a debate over this, I'm really
happy too see these changes making their way into jdk8. Maybe some text
in the package description that indicates that "an exception" will be
thrown in cases where the API specifies a non-null argument? I'll leave
it to you to decide. All in all, this is looking good.
-Chris.
>
> Mike
>
>
>
From chris.hegarty at oracle.com Mon Dec 10 10:51:13 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 10 Dec 2012 10:51:13 +0000
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C20F5A.8060900@univ-mlv.fr>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C0CF83.1080208@oracle.com> <50C0D81A.5030607@cs.oswego.edu>
<50C0DD49.4060900@oracle.com> <50C0E3F2.9030004@cs.oswego.edu>
<50C0EBC9.2070101@univ-mlv.fr> <50C0F559.5090600@oracle.com>
<1354831513.40215.YahooMailNeo@web132104.mail.ird.yahoo.com>
<50C12DEC.9060006@univ-mlv.fr> <50C1FCD8.3030109@cs.oswego.edu>
<50C20C90.6070200@oracle.com> <50C20F5A.8060900@univ-mlv.fr>
Message-ID: <50C5BEA1.3080707@oracle.com>
On 07/12/2012 15:46, Remi Forax wrote:
> On 12/07/2012 04:34 PM, Chris Hegarty wrote:
>> I filed 8004707: "Remove superfluous access$000 methods in java.util",
>> to track this issue. I can file a separate issue for java.lang.
>
> yes, please do that.
I filed 8004797: "Remove superfluous access$000 methods in java.lang"
-Chris.
>
>>
>> I'm sure there are other ways, but a simple find reports them:
>> :>pwd
>> build/solaris-i586/classes/java/util
>> :> find . -name "*.class" -exec javap -v {} \; | grep '\.access\$00'
>
> Technically, javac also generate constructor accessors that doesn't
> start by access00 but this should catch most of the generated accessors.
>
> once changeset for 8003246 will be pushed, I will send two patches one
> for java.lang and one for java.util.
>
>>
>> -Chris
>
> R?mi
>
>>
>> On 07/12/2012 14:27, Doug Lea wrote:
>>> On 12/06/12 18:44, Remi Forax wrote:
>>>
>>>> BTW, at some point, it will be a good idea to get ride of all these
>>>> method
>>>> access$000 in java.lang/java.util at least.
>>>>
>>>
>>> Maybe this is out of scope for this CR, but while in the
>>> neighborhood of ThreadLocal, it could be done here.
>>> There are a couple of annoying ones that kick in on any
>>> compile of anything involving ThreadLocals (try running with
>>> -XX:+PrintCompilation). To remove, replace "private" with
>>> "final" for methods, and just kill "private" for fields.
>>>
>>> -Doug
>>>
>>>
>>>
>
From chris.hegarty at oracle.com Mon Dec 10 11:13:46 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 10 Dec 2012 11:13:46 +0000
Subject: RFR: JDK-8003890: modify test scripts to pass VMOPTIONS
In-Reply-To: <780ee521-ef19-401b-9ed9-8c5cce2cb91c@default>
References: <780ee521-ef19-401b-9ed9-8c5cce2cb91c@default>
Message-ID: <50C5C3EA.4080802@oracle.com>
Thank you Mark, this is a really useful contribution.
I noticed that a few tests (below) specify either -client or -server. If
the vmoptions contain either of these arguments, and this seems to be
the way our test/Makefile is passing them, then it may result in the
test using the wrong vm. I think we should remove TESTVMOPTS from these
tests, but then we lose other potential opts, like heap size, etc.
java/rmi/reliability/benchmark/runRmiBench.sh
java/rmi/reliability/benchmark/runSerialBench.sh
sun/management/jmxremote/startstop/JMXStartStopTest.sh
-Chris.
On 07/12/2012 16:57, Mark Sheppard wrote:
>
>
>
> test scripts have been updated to invoke the JVM with an env variable TESTVMOPTS
> which carries the vm options to be passed when the jvm is invoked in the test.
>
> webrev location:
>
> http://cr.openjdk.java.net/~chegar/8003890/webrev.00/
>
> regards
> Mark
From Alan.Bateman at oracle.com Mon Dec 10 11:25:49 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 10 Dec 2012 11:25:49 +0000
Subject: RFR: JDK-8003890: modify test scripts to pass VMOPTIONS
In-Reply-To: <50C5C3EA.4080802@oracle.com>
References: <780ee521-ef19-401b-9ed9-8c5cce2cb91c@default>
<50C5C3EA.4080802@oracle.com>
Message-ID: <50C5C6BD.3090609@oracle.com>
On 10/12/2012 11:13, Chris Hegarty wrote:
> Thank you Mark, this is a really useful contribution.
>
> I noticed that a few tests (below) specify either -client or -server.
> If the vmoptions contain either of these arguments, and this seems to
> be the way our test/Makefile is passing them, then it may result in
> the test using the wrong vm. I think we should remove TESTVMOPTS from
> these tests, but then we lose other potential opts, like heap size, etc.
>
> java/rmi/reliability/benchmark/runRmiBench.sh
> java/rmi/reliability/benchmark/runSerialBench.sh
> sun/management/jmxremote/startstop/JMXStartStopTest.sh
You're right, this will cause conflict.
In the case of JMXStartStopTest.sh and runSerialBench.sh then it might
be better to remove the -server.
Stuart might have an opinion on runRmiBench.sh but one idea is to change
is so that when run interactively (TESTJAVA not set) then it works as it
does now and runs the benchmark twice. If TESTJAVA is not set then it
runs the benchmark once, with whatever VM options are in use.
-Alan
From chris.hegarty at oracle.com Mon Dec 10 11:33:39 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 10 Dec 2012 11:33:39 +0000
Subject: RFR: JDK-8003890: modify test scripts to pass VMOPTIONS
In-Reply-To: <50C5C6BD.3090609@oracle.com>
References: <780ee521-ef19-401b-9ed9-8c5cce2cb91c@default>
<50C5C3EA.4080802@oracle.com> <50C5C6BD.3090609@oracle.com>
Message-ID: <50C5C893.4090600@oracle.com>
On 10/12/2012 11:25, Alan Bateman wrote:
> On 10/12/2012 11:13, Chris Hegarty wrote:
>> Thank you Mark, this is a really useful contribution.
>>
>> I noticed that a few tests (below) specify either -client or -server.
>> If the vmoptions contain either of these arguments, and this seems to
>> be the way our test/Makefile is passing them, then it may result in
>> the test using the wrong vm. I think we should remove TESTVMOPTS from
>> these tests, but then we lose other potential opts, like heap size, etc.
>>
>> java/rmi/reliability/benchmark/runRmiBench.sh
>> java/rmi/reliability/benchmark/runSerialBench.sh
>> sun/management/jmxremote/startstop/JMXStartStopTest.sh
> You're right, this will cause conflict.
>
> In the case of JMXStartStopTest.sh and runSerialBench.sh then it might
> be better to remove the -server.
Agreed. I see no reason for specifying the vm. TESTVMOPTS will give us
better coverage.
> Stuart might have an opinion on runRmiBench.sh but one idea is to change
> is so that when run interactively (TESTJAVA not set) then it works as it
> does now and runs the benchmark twice. If TESTJAVA is not set then it
> runs the benchmark once, with whatever VM options are in use.
Sounds reasonable.
-Chris.
>
> -Alan
>
>
>
From Lance.Andersen at oracle.com Mon Dec 10 11:49:18 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Mon, 10 Dec 2012 06:49:18 -0500
Subject: Review needed: 8004374 : Fwd: JDBC bug: Incorrect number of
conflicts is reported by CachedRowSetWriter.writeData
In-Reply-To: <50C592E1.9050400@linux.vnet.ibm.com>
References:
<50C592E1.9050400@linux.vnet.ibm.com>
Message-ID:
Hi Frank,
As I explained in one of my earlier emails, tests that require a database will not be added to jtreg. I have a unit test suite which i use for that but that is not external
Best
Lance
On Dec 10, 2012, at 2:44 AM, Frank Ding wrote:
> Hi Lance,
> The code refactory looks good. By the way, the newly added unit test is not jtreg test case?
>
> Best regards,
> Frank
>
> On 12/5/2012 4:38 AM, Lance Andersen - Oracle wrote:
>> All,
>>
>> Attached is the patch for: 8004374 based off the issue that Frank reported.
>>
>> for http://cr.openjdk.java.net/~lancea/8004374/webrev.00/
>>
>> The TCK, SQE and the JDBC Unit Tests run clean. I added a new Unit Test to validate the issue.
>>
>> Frank, I did not use your fix as I was able to clean the code up a bit more and get rid of more crud while addressing it. It is similar though.
>>
>> Best
>> Lance
>>
>>
>>
>>
>>
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>>
>>
>
-------------- next part --------------
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 maurizio.cimadamore at oracle.com Mon Dec 10 12:31:47 2012
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Mon, 10 Dec 2012 12:31:47 +0000
Subject: hg: jdk8/tl/langtools: 8004094: Javac compiler error - synthetic
method accessor generated with duplicate name
Message-ID: <20121210123154.906744700B@hg.openjdk.java.net>
Changeset: c78acf6c2f3e
Author: mcimadamore
Date: 2012-12-10 12:10 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c78acf6c2f3e
8004094: Javac compiler error - synthetic method accessor generated with duplicate name
Summary: method clash check logic should skip methods marked with ACC_SYNTHETIC
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ test/tools/javac/generics/8004094/B.java
+ test/tools/javac/generics/8004094/T8004094.java
From Alan.Bateman at oracle.com Mon Dec 10 13:28:11 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 10 Dec 2012 13:28:11 +0000
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <50C29B04.5070508@oracle.com>
References: <50C29B04.5070508@oracle.com>
Message-ID: <50C5E36B.2040005@oracle.com>
On 08/12/2012 01:42, Akhil Arora wrote:
> As part of the Library Lambdafication, this patch adds the following
> default methods to Collections -
>
> Iterable.forEach(Block)
> Collection.removeAll(Predicate)
> List.sort(Comparator)
> List.replaceAll(UnaryOperator)
>
> It also provides more efficient implementations of these methods for
> ArrayList, Vector and CopyOnWriteArrayList. Please review.
>
> http://cr.openjdk.java.net/~akhil/8001647.1/webrev/
>
> Thanks to the many people who have already contributed to this patch.
>
This may be bikeshed territory but we usually don't use the "public"
modifier on methods defined by interfaces as they are public anyway. It
seems inconsistent to me to have it on the default methods. Perhaps this
has been discussed before, in which case ignore this. BTW: The only
reason I'm bringing this up is because there are lots of default methods
to come and it would be nice to establish a convention and consistency
from the start.
One small comment on ArrayList.removeAll is that it might be more
efficient to keep a count of the number of elements to remove rather
than using the cardinality method (to avoid the bit scan).
For the supporting classes in testlibrary then is @library needed? (I
haven't fully groked how jtreg supports TestNG so perhaps @library
without specifying a location or JAR file has some meaning).
-Alan.
From david.lloyd at redhat.com Mon Dec 10 13:53:45 2012
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 10 Dec 2012 07:53:45 -0600
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To: <50C55F11.6020801@oracle.com>
References: <50BF371A.1060604@oracle.com> <50C08305.90907@oracle.com>
<50C0B490.7050005@redhat.com> <50C55F11.6020801@oracle.com>
Message-ID: <50C5E969.5040602@redhat.com>
On 12/09/2012 10:03 PM, David Holmes wrote:
> Hi David,
>
> On 7/12/2012 1:06 AM, David M. Lloyd wrote:
>> On 12/06/2012 05:35 AM, Alan Bateman wrote:
>>> On 05/12/2012 11:59, David Holmes wrote:
>>>> Java 7 introduced support for parallel classloading by adding to each
>>>> class loader a ConcurrentHashMap, referenced through a new field,
>>>> parallelLockMap. This contains a mapping from class names to Objects
>>>> to use as a classloading lock for that class name. This scheme has a
>>>> number of inefficiencies. To address this we propose for Java 8 the
>>>> notion of a fully concurrent classloader ...
>>>>
>>>> This is a fairly simple proposal that I've written up as a blog entry:
>>>>
>>>> https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent
>>>>
>>>>
>>>>
>>> The jdk7 implementation is very unfortunate, it's a pity this wasn't
>>> caught before 7 shipped.
>>>
>>> I think the proposal is good, it preserves compatibility, and if there
>>> are loaders calling registerAsParallelCapable now (probably very few)
>>> then it they may be able to change to using registerAsFullyConcurrent
>>> without too much work.
>>>
>>> I am tempted to suggest that registerAsParallelCapable should be
>>> deprecated too.
>>
>> I'm sorry I missed the original post, and I just want to add my
>> wholehearted support for this idea. Our application server's class
>> loader implementation can be configured (on certain JVMs) to run in a
>> lock-free mode and we have seen good performance and memory footprint as
>> a result on these particular JVMs.
>
> That sounds promising. Are you in a position to try out this proposal on
> a testbed with your app server?
Sure, I'd love to. What tree should I build?
--
- DML
From peter.levart at gmail.com Mon Dec 10 14:59:26 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 10 Dec 2012 15:59:26 +0100
Subject: bottleneck by java.lang.Class.getAnnotations() - rebased patch
In-Reply-To: <50C57EB0.1000202@oracle.com>
References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com>
<23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com>
<5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com>
<5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com>
<50990CB8.2040400@gmail.com> <5099C2FA.2020202@oracle.com>
<509A3A63.5010102@gmail.com> <50AF5930.5010903@gmail.com>
<50AFADB4.9000204@gmail.com> <50B8FC99.401@gmail.com>
<50B900F2.9060902@oracle.com> <50BBFD2F.1080108@oracle.com>
<50BC57A0.8000108@gmail.com> <50C57EB0.1000202@oracle.com>
Message-ID: <50C5F8CE.3080006@gmail.com>
On 12/10/2012 07:18 AM, David Holmes wrote:
> Hi Peter,
>
> Sorry for the delay on this.
Thank you for taking it into consideration. I can only imagine how busy
you are with other things.
>
> Generally your VolatileData and my ReflectionHelper are doing a
> similar job. But I agree with your reasoning that all of the cached
> SoftReferences are likely to be cleared at once, and so a
> SoftReference to a helper object with direct references, is more
> effective than a direct reference to a helper object with
> SoftReferences. My initial stance with this was very conservative as
> the more change that is introduced the more uncertainty there is about
> the impact.
>
> I say the above primarily because I think, if I am to proceed with
> this, I will need to separate out the general reflection caching
> changes from the annotation changes.
> There are a number of reasons for this:
>
> First, I'm not at all familiar with the implementation of annotations
> at the VM or Java level, and the recent changes in this area just
> exacerbate my ignorance of the mechanics. So I don't feel qualified to
> evaluate that aspect.
>
> Second, the bulk of the reflection caching code is simplified by the
> fact that due to current constraints on class redefinition the caching
> is effectively idempotent for fields/methods/constructors. But that is
> not the case for annotations.
I think that on the Class-level these two aspects can be separated. But
not on the Field/Method/Constructor level, because annotations are
referenced by Field/Method/Constructor objects and there is no
invalidation logic - like on the Class-level - that would just
invalidate the sets of annotations on Field/Method/Constructor, leaving
Field/Method/Constructor objects still valid. So these two aspects are
connected - it may be - I haven't looked at history yet - that
invalidation of Field/Method/Constructor was introduced just because of
annotations.
Also, the following bug (currently not accessible):
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002251 has
references to docs that suggest that current class redefinition can
introduce new methods, so If this is correct, then redefinition is not
idempotent for basic reflection data.
>
> Finally, the use of synchronization with the annotations method is
> perplexing me. I sent Joe a private email on this but I may as well
> raise it here - and I think you have alluded to this in your earlier
> emails as well: initAnnotationsIfNecessary() is a synchronized
> instance method but I can not find any other code in the VM that
> synchronizes on the Class object's monitor. So if this synchronization
> is trying to establish consistency in the face of class redefinition,
> I do not see where class redefinition is participating in the
> synchronization!
I think that the intent was merely synchronized access to / lazy
initialization of cached 'annotations' and 'declaredAnnotations' Maps.
Field[], Method[], Constructor[] arrays are published to other threads
via volatile fields one field at a time, but
initAnnotationsIfNecessary() was designed to publish two references
('annotations' and 'declaredAnnotations') atomically at the same time,
so the author of the code choose to use synchronized block. I also have
a feeling that this might have simply been the author's preferred style
of synchronization, since the same approach is used also in
Field/Method/Constructor/Executable although there's just one field of
annotations that is published at a time.
It is indicative that initAnnotationsIfNecessary() synchronized method
also contains the call to clearCachesOnClassRedefinition(), so at first
it seems that the synchronization is also meant to serialize access to
invalidation logic which invalidates both Field/Method/Constructor and
annotation fields, but that all falls-apart because
clearCachesOnClassRedefinition() is also called from elsewhere, not
guarded by the synchronization.
So all in all the two aspects - annotations and basic reflection stuff -
are quite intermingled in current code, unfortunately very
inconsistently. I'm afraid that doing one thing and not touching the
other is possible, but that would not solve the problems that this
thread was starting to address (bottleneck by
java.lang.Class.getAnnotations()) and evident dead-lock bugs.
We can approach the problem so that we separate the aspects of caching
Class-level annotations and Field/Method/Constructor arrays but using
the same approach for both. And that would only make sense if there was
a reason to separately cache Class-level annotations and
Field/Method/Constructor arrays. I haven't yet been able to think of one
such reason. So anyone with more insight (the author of annotations
code?) is invited to participate in investigation.
My approach of including the Class-level annotations together with
Field/Method/Constructor arrays was guided by:
- consistency - why should Class-level annotations be cached with hard
references, while Field/Method/Constructor annotations are indirectly
SoftReference(d)? Are they more important?
- simplicity
- space efficiency
- correctness - unsynchronized calls to clearCachesOnClassRedefinition()
followed by unsynchronized lazy initialization have - as I have shown -
theoretical races that could result in caching the old versions of data
instead of new. The approach I have chosen with the logic in
getVolatileData() is a kind of MVCC rather than synchronization.
But as said, the two aspects of caching can be separated.
We can also leave the Class-level annotation aspect untouched by
re-introducing the 'annotations' and 'declaredAnnotations' fields and
also the 'lastRedefinedCount' field on the Class-level and
re-introducing the synchronized initAnnotationsIfNecessary() method and
a clearCachesOnClassRedefinition() which would just invalidate the two
annotations fields.
To recap. How to continue?
a) as proposed;
b) separate caching of annotations and Field/Method/Constructor arrays
but with the same unblocking MVCC-like approach for both - with possible
variation in that annotations be hardly referenced and
Field/Method/Constructor arrays be softly;
c) undo the annotations caching changes and only do MVCC for
Field/Method/Constructor arrays.
I can do b) but prepare two independent patches - one for VolatileData
(rename it to MemberData?) and one for AnnotationData. So by applying
only the first, we achieve c) and can later apply the second to upgrade
to b). But it is unfortunately a) that is most efficient space-saving wise.
What do you say about the trivial changes in
Field/Method/Constructor/Executable to accommodate caching on the 'root'
instance instead of on the copies?
Regards, Peter
>
> So what I would like to do is take your basic VolatileData part of the
> patch and run with it for JEP-149 purposes, while separating the
> annotations issue so they can be dealt with by the experts in that
> particular area.
>
> I'm sorry it has taken so long to arrive at a fairly negative
> position, but I need someone else to take up the annotations gauntlet
> and run with it.
>
> Thanks,
> David
>
> On 3/12/2012 5:41 PM, Peter Levart wrote:
>> Hi David, Alan, Alexander and others,
>>
>> In the meanwhile I have added another annotations space optimization to
>> the patch. If a Class doesn't inherit any annotations from a superclass,
>> which I think is a common case, it assigns the same Map instance to
>> "annotations" as well as "declaredAnnotations" fields. Previously - and
>> in the original code - this only happened for java.lang.Object and
>> interfaces.
>>
>> Here's the updated webrev:
>>
>> http://dl.dropbox.com/u/101777488/jdk8-tl/JEP-149/webrev.02/index.html
>>
>> I have also rewritten the performance micro-benchmarks. With the
>> addition of repeating annotations, one performance aspect surfaces: when
>> asking for a particular annotation type on a Class and that annotation
>> is not present, the new repeating annotations support method
>> AnnotationSupport.getOneAnnotation asks for @ContainedBy meta-annotation
>> on the annotation type. This can result in an even more apparent
>> synchronization hot-spot with original code that uses synchronized
>> initAnnotationsIfNecessary(). This aspect is tested with the 3rd test.
>> Other 2 tests test the same thing as before but are more stable now,
>> since now they measure retrieval of 5 different annotation types from
>> each AnnotatedElement, previously they only measured retrieval of 1
>> which was very sensitive to HashMap irregularities (it could happen that
>> a particular key mapped to a bucket that was overloaded in one test-run
>> and not in another)...
>>
>> Here're the new tests:
>>
>> https://raw.github.com/plevart/jdk8-tl/JEP-149/test/src/test/ReflectionTest.java
>>
>>
>> And the corresponding results when run on an i7 CPU on Linux:
>>
>> https://raw.github.com/plevart/jdk8-tl/JEP-149/test/benchmark_results_i7-2600K.txt
>>
>>
>>
>> Regards, Peter
>>
>>
>>
>> On 12/03/2012 02:15 AM, David Holmes wrote:
>>> On 1/12/2012 4:54 AM, Alan Bateman wrote:
>>>> On 30/11/2012 18:36, Peter Levart wrote:
>>>>> :
>>>>>
>>>>> So, what do you think? What kind of tests should I prepare in
>>>>> addidion
>>>>> to those 3 so that the patch might get a consideration?
>>>> I think this is good work and thanks for re-basing your patch. I know
>>>> David plans to do a detail review. I think it will require extensive
>>>> performance testing too, perhaps with some large applications.
>>>
>>> Indeed I do plan a detailed review and have initiated some initial
>>> performance tests.
>>>
>>> I am also swamped but will try to get to the review this week - and
>>> will also need to check the referenced annotations updates.
>>>
>>> David
>>>
>>>> -Alan
>>>>
>>
From michael.x.mcmahon at oracle.com Mon Dec 10 15:06:03 2012
From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com)
Date: Mon, 10 Dec 2012 15:06:03 +0000
Subject: hg: jdk8/tl/jdk: 8003948: NTLM/Negotiate authentication problem
Message-ID: <20121210150632.D753A47015@hg.openjdk.java.net>
Changeset: fda2b2b5b98b
Author: michaelm
Date: 2012-12-10 14:56 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fda2b2b5b98b
8003948: NTLM/Negotiate authentication problem
Reviewed-by: chegar, weijun
! src/share/classes/sun/net/www/MessageHeader.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
+ test/sun/net/www/MessageHeaderTest.java
From forax at univ-mlv.fr Mon Dec 10 15:10:56 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 10 Dec 2012 16:10:56 +0100
Subject: RFR: 8003246: Add Supplier to ThreadLocal
In-Reply-To: <50C5BEA1.3080707@oracle.com>
References: <50BFA2FC.4010201@oracle.com> <50C028DF.2030303@oracle.com>
<50C055ED.1040602@univ-mlv.fr> <50C08253.9030904@cs.oswego.edu>
<50C0CF83.1080208@oracle.com> <50C0D81A.5030607@cs.oswego.edu>
<50C0DD49.4060900@oracle.com> <50C0E3F2.9030004@cs.oswego.edu>
<50C0EBC9.2070101@univ-mlv.fr> <50C0F559.5090600@oracle.com>
<1354831513.40215.YahooMailNeo@web132104.mail.ird.yahoo.com>
<50C12DEC.9060006@univ-mlv.fr> <50C1FCD8.3030109@cs.oswego.edu>
<50C20C90.6070200@oracle.com> <50C20F5A.8060900@univ-mlv.fr>
<50C5BEA1.3080707@oracle.com>
Message-ID: <50C5FB80.7090004@univ-mlv.fr>
On 12/10/2012 11:51 AM, Chris Hegarty wrote:
>
>
> On 07/12/2012 15:46, Remi Forax wrote:
>> On 12/07/2012 04:34 PM, Chris Hegarty wrote:
>>> I filed 8004707: "Remove superfluous access$000 methods in java.util",
>>> to track this issue. I can file a separate issue for java.lang.
>>
>> yes, please do that.
>
> I filed 8004797: "Remove superfluous access$000 methods in java.lang"
>
> -Chris.
thanks.
R?mi
From peter.levart at gmail.com Mon Dec 10 16:13:57 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 10 Dec 2012 17:13:57 +0100
Subject: bottleneck by java.lang.Class.getAnnotations() - rebased patch
In-Reply-To: <50C5F8CE.3080006@gmail.com>
References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com>
<23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com>
<5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com>
<5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com>
<50990CB8.2040400@gmail.com> <5099C2FA.2020202@oracle.com>
<509A3A63.5010102@gmail.com> <50AF5930.5010903@gmail.com>
<50AFADB4.9000204@gmail.com> <50B8FC99.401@gmail.com>
<50B900F2.9060902@oracle.com> <50BBFD2F.1080108@oracle.com>
<50BC57A0.8000108@gmail.com> <50C57EB0.1000202@oracle.com>
<50C5F8CE.3080006@gmail.com>
Message-ID: <50C60A45.9020807@gmail.com>
Hi David,
It would be informative to look at how java.lang.Class evolved during
history. The oldest revision I can access is from 1st of Dec. 2007,
which already contains Java 1.5 code (annotations) and is more or less
unchanged until now. The most interesting changesets would be those that
introduced annotations.
Regards, Peter
On 12/10/2012 03:59 PM, Peter Levart wrote:
> On 12/10/2012 07:18 AM, David Holmes wrote:
>> Hi Peter,
>>
>> Sorry for the delay on this.
>
> Thank you for taking it into consideration. I can only imagine how
> busy you are with other things.
>
>>
>> Generally your VolatileData and my ReflectionHelper are doing a
>> similar job. But I agree with your reasoning that all of the cached
>> SoftReferences are likely to be cleared at once, and so a
>> SoftReference to a helper object with direct references, is more
>> effective than a direct reference to a helper object with
>> SoftReferences. My initial stance with this was very conservative as
>> the more change that is introduced the more uncertainty there is
>> about the impact.
>>
>> I say the above primarily because I think, if I am to proceed with
>> this, I will need to separate out the general reflection caching
>> changes from the annotation changes. There are a number of reasons
>> for this:
>>
>> First, I'm not at all familiar with the implementation of annotations
>> at the VM or Java level, and the recent changes in this area just
>> exacerbate my ignorance of the mechanics. So I don't feel qualified
>> to evaluate that aspect.
>>
>> Second, the bulk of the reflection caching code is simplified by the
>> fact that due to current constraints on class redefinition the
>> caching is effectively idempotent for fields/methods/constructors.
>> But that is not the case for annotations.
>
> I think that on the Class-level these two aspects can be separated.
> But not on the Field/Method/Constructor level, because annotations are
> referenced by Field/Method/Constructor objects and there is no
> invalidation logic - like on the Class-level - that would just
> invalidate the sets of annotations on Field/Method/Constructor,
> leaving Field/Method/Constructor objects still valid. So these two
> aspects are connected - it may be - I haven't looked at history yet -
> that invalidation of Field/Method/Constructor was introduced just
> because of annotations.
>
> Also, the following bug (currently not accessible):
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002251 has
> references to docs that suggest that current class redefinition can
> introduce new methods, so If this is correct, then redefinition is not
> idempotent for basic reflection data.
>
>>
>> Finally, the use of synchronization with the annotations method is
>> perplexing me. I sent Joe a private email on this but I may as well
>> raise it here - and I think you have alluded to this in your earlier
>> emails as well: initAnnotationsIfNecessary() is a synchronized
>> instance method but I can not find any other code in the VM that
>> synchronizes on the Class object's monitor. So if this
>> synchronization is trying to establish consistency in the face of
>> class redefinition, I do not see where class redefinition is
>> participating in the synchronization!
>
> I think that the intent was merely synchronized access to / lazy
> initialization of cached 'annotations' and 'declaredAnnotations' Maps.
> Field[], Method[], Constructor[] arrays are published to other threads
> via volatile fields one field at a time, but
> initAnnotationsIfNecessary() was designed to publish two references
> ('annotations' and 'declaredAnnotations') atomically at the same time,
> so the author of the code choose to use synchronized block. I also
> have a feeling that this might have simply been the author's preferred
> style of synchronization, since the same approach is used also in
> Field/Method/Constructor/Executable although there's just one field of
> annotations that is published at a time.
>
> It is indicative that initAnnotationsIfNecessary() synchronized method
> also contains the call to clearCachesOnClassRedefinition(), so at
> first it seems that the synchronization is also meant to serialize
> access to invalidation logic which invalidates both
> Field/Method/Constructor and annotation fields, but that all
> falls-apart because clearCachesOnClassRedefinition() is also called
> from elsewhere, not guarded by the synchronization.
>
> So all in all the two aspects - annotations and basic reflection stuff
> - are quite intermingled in current code, unfortunately very
> inconsistently. I'm afraid that doing one thing and not touching the
> other is possible, but that would not solve the problems that this
> thread was starting to address (bottleneck by
> java.lang.Class.getAnnotations()) and evident dead-lock bugs.
>
> We can approach the problem so that we separate the aspects of caching
> Class-level annotations and Field/Method/Constructor arrays but using
> the same approach for both. And that would only make sense if there
> was a reason to separately cache Class-level annotations and
> Field/Method/Constructor arrays. I haven't yet been able to think of
> one such reason. So anyone with more insight (the author of
> annotations code?) is invited to participate in investigation.
>
> My approach of including the Class-level annotations together with
> Field/Method/Constructor arrays was guided by:
> - consistency - why should Class-level annotations be cached with hard
> references, while Field/Method/Constructor annotations are indirectly
> SoftReference(d)? Are they more important?
> - simplicity
> - space efficiency
> - correctness - unsynchronized calls to
> clearCachesOnClassRedefinition() followed by unsynchronized lazy
> initialization have - as I have shown - theoretical races that could
> result in caching the old versions of data instead of new. The
> approach I have chosen with the logic in getVolatileData() is a kind
> of MVCC rather than synchronization.
>
> But as said, the two aspects of caching can be separated.
>
> We can also leave the Class-level annotation aspect untouched by
> re-introducing the 'annotations' and 'declaredAnnotations' fields and
> also the 'lastRedefinedCount' field on the Class-level and
> re-introducing the synchronized initAnnotationsIfNecessary() method
> and a clearCachesOnClassRedefinition() which would just invalidate the
> two annotations fields.
>
> To recap. How to continue?
> a) as proposed;
> b) separate caching of annotations and Field/Method/Constructor arrays
> but with the same unblocking MVCC-like approach for both - with
> possible variation in that annotations be hardly referenced and
> Field/Method/Constructor arrays be softly;
> c) undo the annotations caching changes and only do MVCC for
> Field/Method/Constructor arrays.
>
> I can do b) but prepare two independent patches - one for VolatileData
> (rename it to MemberData?) and one for AnnotationData. So by applying
> only the first, we achieve c) and can later apply the second to
> upgrade to b). But it is unfortunately a) that is most efficient
> space-saving wise.
>
> What do you say about the trivial changes in
> Field/Method/Constructor/Executable to accommodate caching on the
> 'root' instance instead of on the copies?
>
> Regards, Peter
>
>>
>> So what I would like to do is take your basic VolatileData part of
>> the patch and run with it for JEP-149 purposes, while separating the
>> annotations issue so they can be dealt with by the experts in that
>> particular area.
>>
>> I'm sorry it has taken so long to arrive at a fairly negative
>> position, but I need someone else to take up the annotations gauntlet
>> and run with it.
>>
>> Thanks,
>> David
>>
>> On 3/12/2012 5:41 PM, Peter Levart wrote:
>>> Hi David, Alan, Alexander and others,
>>>
>>> In the meanwhile I have added another annotations space optimization to
>>> the patch. If a Class doesn't inherit any annotations from a
>>> superclass,
>>> which I think is a common case, it assigns the same Map instance to
>>> "annotations" as well as "declaredAnnotations" fields. Previously - and
>>> in the original code - this only happened for java.lang.Object and
>>> interfaces.
>>>
>>> Here's the updated webrev:
>>>
>>> http://dl.dropbox.com/u/101777488/jdk8-tl/JEP-149/webrev.02/index.html
>>>
>>> I have also rewritten the performance micro-benchmarks. With the
>>> addition of repeating annotations, one performance aspect surfaces:
>>> when
>>> asking for a particular annotation type on a Class and that annotation
>>> is not present, the new repeating annotations support method
>>> AnnotationSupport.getOneAnnotation asks for @ContainedBy
>>> meta-annotation
>>> on the annotation type. This can result in an even more apparent
>>> synchronization hot-spot with original code that uses synchronized
>>> initAnnotationsIfNecessary(). This aspect is tested with the 3rd test.
>>> Other 2 tests test the same thing as before but are more stable now,
>>> since now they measure retrieval of 5 different annotation types from
>>> each AnnotatedElement, previously they only measured retrieval of 1
>>> which was very sensitive to HashMap irregularities (it could happen
>>> that
>>> a particular key mapped to a bucket that was overloaded in one test-run
>>> and not in another)...
>>>
>>> Here're the new tests:
>>>
>>> https://raw.github.com/plevart/jdk8-tl/JEP-149/test/src/test/ReflectionTest.java
>>>
>>>
>>> And the corresponding results when run on an i7 CPU on Linux:
>>>
>>> https://raw.github.com/plevart/jdk8-tl/JEP-149/test/benchmark_results_i7-2600K.txt
>>>
>>>
>>>
>>> Regards, Peter
>>>
>>>
>>>
>>> On 12/03/2012 02:15 AM, David Holmes wrote:
>>>> On 1/12/2012 4:54 AM, Alan Bateman wrote:
>>>>> On 30/11/2012 18:36, Peter Levart wrote:
>>>>>> :
>>>>>>
>>>>>> So, what do you think? What kind of tests should I prepare in
>>>>>> addidion
>>>>>> to those 3 so that the patch might get a consideration?
>>>>> I think this is good work and thanks for re-basing your patch. I know
>>>>> David plans to do a detail review. I think it will require extensive
>>>>> performance testing too, perhaps with some large applications.
>>>>
>>>> Indeed I do plan a detailed review and have initiated some initial
>>>> performance tests.
>>>>
>>>> I am also swamped but will try to get to the review this week - and
>>>> will also need to check the referenced annotations updates.
>>>>
>>>> David
>>>>
>>>>> -Alan
>>>>>
>>>
>
From peter.levart at gmail.com Mon Dec 10 16:41:07 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 10 Dec 2012 17:41:07 +0100
Subject: bottleneck by java.lang.Class.getAnnotations() - rebased patch
In-Reply-To: <50C60A45.9020807@gmail.com>
References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com>
<23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com>
<5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com>
<5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com>
<50990CB8.2040400@gmail.com> <5099C2FA.2020202@oracle.com>
<509A3A63.5010102@gmail.com> <50AF5930.5010903@gmail.com>
<50AFADB4.9000204@gmail.com> <50B8FC99.401@gmail.com>
<50B900F2.9060902@oracle.com> <50BBFD2F.1080108@oracle.com>
<50BC57A0.8000108@gmail.com> <50C57EB0.1000202@oracle.com>
<50C5F8CE.3080006@gmail.com> <50C60A45.9020807@gmail.com>
Message-ID: <50C610A3.7020704@gmail.com>
Ok, I've got it. Downloaded j2sdk1.4_19 and unpacked src.zip ...
There are SoftReferences for individual Field/Method/Constructor arrays:
// Caches for certain reflective results
private static boolean useCaches = true;
private volatile transient SoftReference declaredFields;
private volatile transient SoftReference publicFields;
private volatile transient SoftReference declaredMethods;
private volatile transient SoftReference publicMethods;
private volatile transient SoftReference declaredConstructors;
private volatile transient SoftReference publicConstructors;
// Intermediate results for getFields and getMethods
private volatile transient SoftReference declaredPublicFields;
private volatile transient SoftReference declaredPublicMethods;
...but there's no mechanism yet for invalidation. So my assumption that
invalidation was introduced just because of annotations might be
correct. Annotations were just glued on top of the existing unchanged
structures.
Regards, Peter
P.S. I've got an Idea how to approach another variant where Class-level
annotations would still be directly referenced from the Class instance
and Field/Method/Constructor arrays would hang off a single
SoftReference in a way that would have same space efficiency that my
current integrated approach. The idea is to subclass the SoftReference
and have the additional fields on it:
static class VolatileData extends SoftReference {
volatile Map annotations, declaredAnnotations;
final int redefinedCount;
}
...and MemberData only containing volatile Fileld[], Method[],
Constructor[] fields...
I also know how to correctly synchronize access to this structure so
that annotations are not invalidated when SoftReference is cleared. Let
this be variant a2).
I rest now and wait for your pointers.
Regards, Peter
On 12/10/2012 05:13 PM, Peter Levart wrote:
> Hi David,
>
> It would be informative to look at how java.lang.Class evolved during
> history. The oldest revision I can access is from 1st of Dec. 2007,
> which already contains Java 1.5 code (annotations) and is more or less
> unchanged until now. The most interesting changesets would be those
> that introduced annotations.
>
> Regards, Peter
>
>
> On 12/10/2012 03:59 PM, Peter Levart wrote:
>> On 12/10/2012 07:18 AM, David Holmes wrote:
>>> Hi Peter,
>>>
>>> Sorry for the delay on this.
>>
>> Thank you for taking it into consideration. I can only imagine how
>> busy you are with other things.
>>
>>>
>>> Generally your VolatileData and my ReflectionHelper are doing a
>>> similar job. But I agree with your reasoning that all of the cached
>>> SoftReferences are likely to be cleared at once, and so a
>>> SoftReference to a helper object with direct references, is more
>>> effective than a direct reference to a helper object with
>>> SoftReferences. My initial stance with this was very conservative as
>>> the more change that is introduced the more uncertainty there is
>>> about the impact.
>>>
>>> I say the above primarily because I think, if I am to proceed with
>>> this, I will need to separate out the general reflection caching
>>> changes from the annotation changes. There are a number of reasons
>>> for this:
>>>
>>> First, I'm not at all familiar with the implementation of
>>> annotations at the VM or Java level, and the recent changes in this
>>> area just exacerbate my ignorance of the mechanics. So I don't feel
>>> qualified to evaluate that aspect.
>>>
>>> Second, the bulk of the reflection caching code is simplified by the
>>> fact that due to current constraints on class redefinition the
>>> caching is effectively idempotent for fields/methods/constructors.
>>> But that is not the case for annotations.
>>
>> I think that on the Class-level these two aspects can be separated.
>> But not on the Field/Method/Constructor level, because annotations
>> are referenced by Field/Method/Constructor objects and there is no
>> invalidation logic - like on the Class-level - that would just
>> invalidate the sets of annotations on Field/Method/Constructor,
>> leaving Field/Method/Constructor objects still valid. So these two
>> aspects are connected - it may be - I haven't looked at history yet -
>> that invalidation of Field/Method/Constructor was introduced just
>> because of annotations.
>>
>> Also, the following bug (currently not accessible):
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002251 has
>> references to docs that suggest that current class redefinition can
>> introduce new methods, so If this is correct, then redefinition is
>> not idempotent for basic reflection data.
>>
>>>
>>> Finally, the use of synchronization with the annotations method is
>>> perplexing me. I sent Joe a private email on this but I may as well
>>> raise it here - and I think you have alluded to this in your earlier
>>> emails as well: initAnnotationsIfNecessary() is a synchronized
>>> instance method but I can not find any other code in the VM that
>>> synchronizes on the Class object's monitor. So if this
>>> synchronization is trying to establish consistency in the face of
>>> class redefinition, I do not see where class redefinition is
>>> participating in the synchronization!
>>
>> I think that the intent was merely synchronized access to / lazy
>> initialization of cached 'annotations' and 'declaredAnnotations'
>> Maps. Field[], Method[], Constructor[] arrays are published to other
>> threads via volatile fields one field at a time, but
>> initAnnotationsIfNecessary() was designed to publish two references
>> ('annotations' and 'declaredAnnotations') atomically at the same
>> time, so the author of the code choose to use synchronized block. I
>> also have a feeling that this might have simply been the author's
>> preferred style of synchronization, since the same approach is used
>> also in Field/Method/Constructor/Executable although there's just one
>> field of annotations that is published at a time.
>>
>> It is indicative that initAnnotationsIfNecessary() synchronized
>> method also contains the call to clearCachesOnClassRedefinition(), so
>> at first it seems that the synchronization is also meant to serialize
>> access to invalidation logic which invalidates both
>> Field/Method/Constructor and annotation fields, but that all
>> falls-apart because clearCachesOnClassRedefinition() is also called
>> from elsewhere, not guarded by the synchronization.
>>
>> So all in all the two aspects - annotations and basic reflection
>> stuff - are quite intermingled in current code, unfortunately very
>> inconsistently. I'm afraid that doing one thing and not touching the
>> other is possible, but that would not solve the problems that this
>> thread was starting to address (bottleneck by
>> java.lang.Class.getAnnotations()) and evident dead-lock bugs.
>>
>> We can approach the problem so that we separate the aspects of
>> caching Class-level annotations and Field/Method/Constructor arrays
>> but using the same approach for both. And that would only make sense
>> if there was a reason to separately cache Class-level annotations and
>> Field/Method/Constructor arrays. I haven't yet been able to think of
>> one such reason. So anyone with more insight (the author of
>> annotations code?) is invited to participate in investigation.
>>
>> My approach of including the Class-level annotations together with
>> Field/Method/Constructor arrays was guided by:
>> - consistency - why should Class-level annotations be cached with
>> hard references, while Field/Method/Constructor annotations are
>> indirectly SoftReference(d)? Are they more important?
>> - simplicity
>> - space efficiency
>> - correctness - unsynchronized calls to
>> clearCachesOnClassRedefinition() followed by unsynchronized lazy
>> initialization have - as I have shown - theoretical races that could
>> result in caching the old versions of data instead of new. The
>> approach I have chosen with the logic in getVolatileData() is a kind
>> of MVCC rather than synchronization.
>>
>> But as said, the two aspects of caching can be separated.
>>
>> We can also leave the Class-level annotation aspect untouched by
>> re-introducing the 'annotations' and 'declaredAnnotations' fields and
>> also the 'lastRedefinedCount' field on the Class-level and
>> re-introducing the synchronized initAnnotationsIfNecessary() method
>> and a clearCachesOnClassRedefinition() which would just invalidate
>> the two annotations fields.
>>
>> To recap. How to continue?
>> a) as proposed;
>> b) separate caching of annotations and Field/Method/Constructor
>> arrays but with the same unblocking MVCC-like approach for both -
>> with possible variation in that annotations be hardly referenced and
>> Field/Method/Constructor arrays be softly;
>> c) undo the annotations caching changes and only do MVCC for
>> Field/Method/Constructor arrays.
>>
>> I can do b) but prepare two independent patches - one for
>> VolatileData (rename it to MemberData?) and one for AnnotationData.
>> So by applying only the first, we achieve c) and can later apply the
>> second to upgrade to b). But it is unfortunately a) that is most
>> efficient space-saving wise.
>>
>> What do you say about the trivial changes in
>> Field/Method/Constructor/Executable to accommodate caching on the
>> 'root' instance instead of on the copies?
>>
>> Regards, Peter
>>
>>>
>>> So what I would like to do is take your basic VolatileData part of
>>> the patch and run with it for JEP-149 purposes, while separating the
>>> annotations issue so they can be dealt with by the experts in that
>>> particular area.
>>>
>>> I'm sorry it has taken so long to arrive at a fairly negative
>>> position, but I need someone else to take up the annotations
>>> gauntlet and run with it.
>>>
>>> Thanks,
>>> David
>>>
>>> On 3/12/2012 5:41 PM, Peter Levart wrote:
>>>> Hi David, Alan, Alexander and others,
>>>>
>>>> In the meanwhile I have added another annotations space
>>>> optimization to
>>>> the patch. If a Class doesn't inherit any annotations from a
>>>> superclass,
>>>> which I think is a common case, it assigns the same Map instance to
>>>> "annotations" as well as "declaredAnnotations" fields. Previously -
>>>> and
>>>> in the original code - this only happened for java.lang.Object and
>>>> interfaces.
>>>>
>>>> Here's the updated webrev:
>>>>
>>>> http://dl.dropbox.com/u/101777488/jdk8-tl/JEP-149/webrev.02/index.html
>>>>
>>>> I have also rewritten the performance micro-benchmarks. With the
>>>> addition of repeating annotations, one performance aspect surfaces:
>>>> when
>>>> asking for a particular annotation type on a Class and that annotation
>>>> is not present, the new repeating annotations support method
>>>> AnnotationSupport.getOneAnnotation asks for @ContainedBy
>>>> meta-annotation
>>>> on the annotation type. This can result in an even more apparent
>>>> synchronization hot-spot with original code that uses synchronized
>>>> initAnnotationsIfNecessary(). This aspect is tested with the 3rd test.
>>>> Other 2 tests test the same thing as before but are more stable now,
>>>> since now they measure retrieval of 5 different annotation types from
>>>> each AnnotatedElement, previously they only measured retrieval of 1
>>>> which was very sensitive to HashMap irregularities (it could happen
>>>> that
>>>> a particular key mapped to a bucket that was overloaded in one
>>>> test-run
>>>> and not in another)...
>>>>
>>>> Here're the new tests:
>>>>
>>>> https://raw.github.com/plevart/jdk8-tl/JEP-149/test/src/test/ReflectionTest.java
>>>>
>>>>
>>>> And the corresponding results when run on an i7 CPU on Linux:
>>>>
>>>> https://raw.github.com/plevart/jdk8-tl/JEP-149/test/benchmark_results_i7-2600K.txt
>>>>
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>>>
>>>>
>>>> On 12/03/2012 02:15 AM, David Holmes wrote:
>>>>> On 1/12/2012 4:54 AM, Alan Bateman wrote:
>>>>>> On 30/11/2012 18:36, Peter Levart wrote:
>>>>>>> :
>>>>>>>
>>>>>>> So, what do you think? What kind of tests should I prepare in
>>>>>>> addidion
>>>>>>> to those 3 so that the patch might get a consideration?
>>>>>> I think this is good work and thanks for re-basing your patch. I
>>>>>> know
>>>>>> David plans to do a detail review. I think it will require extensive
>>>>>> performance testing too, perhaps with some large applications.
>>>>>
>>>>> Indeed I do plan a detailed review and have initiated some initial
>>>>> performance tests.
>>>>>
>>>>> I am also swamped but will try to get to the review this week - and
>>>>> will also need to check the referenced annotations updates.
>>>>>
>>>>> David
>>>>>
>>>>>> -Alan
>>>>>>
>>>>
>>
>
From chris.hegarty at oracle.com Mon Dec 10 16:59:10 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 10 Dec 2012 16:59:10 +0000
Subject: Request for review: 8000525: Java.net.httpcookie api does not
support 2-digit year format
In-Reply-To: <50C10BE2.5070006@oracle.com>
References: <50C10BE2.5070006@oracle.com>
Message-ID: <50C614DE.6090208@oracle.com>
Shouldn't 'cal.set(1970, 0, 1, 0, 0, 0)' be inside the for loop?
The test can simply throw Exception, rather can catching.
Otherwise, looks fine to me.
-Crhis.
On 06/12/2012 21:19, Rob McKenna wrote:
> Hi folks,
>
> According to HttpCookie.java:
>
> """
> There are 3 http cookie specifications:
>
> Netscape draft
> RFC 2109 -/http://www.ietf.org/rfc/rfc2109.txt/
> RFC 2965 -/http://www.ietf.org/rfc/rfc2965.txt/
>
> HttpCookie class can accept all these 3 forms of syntax.
> """
>
> According to http://www.ietf.org/rfc/rfc2109.txt section 10.1.2:
>
> """
> Netscape's original proposal defined an Expires header that took a date
> value in a fixed-length variant format in place of Max-Age: Wdy,
> DD-Mon-YY HH:MM:SS GMT
> """
>
> Thats in the "Historical" section provided to allow for compatibility
> with Netscape's implementation, which we also support: (as per
> http://docs.oracle.com/javase/6/docs/api/java/net/HttpCookie.html )
>
> While we don't support the rfc explicitly, this change follows the
> format specified in section 5.1.1 of rfc 6265:
>
> """
> 3. If the year-value is greater than or equal to 70 and less than or
> equal to 99, increment the year-value by 1900.
> 4. If the year-value is greater than or equal to 0 and less than or
> equal to 69, increment the year-value by 2000.
> 1. NOTE: Some existing user agents interpret two-digit years differently.
> """
>
> The webrev is at:
>
> http://cr.openjdk.java.net/~robm/8000525/webrev.01/
>
>
> Note: The addition of setLenient(false) has required changes to two
> existing testcases.
>
> -Rob
From daniel.fuchs at oracle.com Mon Dec 10 17:12:59 2012
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 10 Dec 2012 18:12:59 +0100
Subject: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser
factories (7169894: JAXP Plugability Layer: using service loader)
In-Reply-To: <50C23755.5030503@oracle.com>
References: <50BCF7CD.1020308@oracle.com> <50BE007A.4090102@oracle.com>
<50BF73B2.5000102@oracle.com> <50C06DAC.5050500@oracle.com>
<50C0D805.5030509@oracle.com> <50C1A31D.1090805@oracle.com>
<50C1EB41.2010502@oracle.com> <50C207F9.5060307@oracle.com>
<50C21A2C.8070503@oracle.com> <50C23755.5030503@oracle.com>
Message-ID: <50C6181B.70005@oracle.com>
Hi,
After further discussion with Joe & Alan, I changed the call
to ServiceLoader to simply return the first provider it finds,
or null.
This is closer to what was present in JDK 7 - and looping is
not necessary in JDK 8 since the default implementation is
not returned as a service provider.
So here is a new - and hopefully simpler webrev:
best regards,
-- daniel
On 12/7/12 7:37 PM, Mandy Chung wrote:
> On 12/7/12 8:32 AM, Alan Bateman wrote:
>> On 07/12/2012 15:15, Daniel Fuchs wrote:
>>> Hi Alan,
>>>
>>> I have updated the webrev according to your suggestion. I think it makes
>>> things much clearer.
>>>
>>> The new version is there:
>>>
>>>
>>>
>> This looks good to me except that "implementation system default"
>> should be "system-default implementation".
>>
> Looks good to me too with the change to "system-default implementation".
>
> Mandy
>
From huizhe.wang at oracle.com Mon Dec 10 17:26:35 2012
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 10 Dec 2012 09:26:35 -0800
Subject: 8004371: (props) Properties.loadFromXML needs small footprint
XML parser as fallback when JAXP is not present
In-Reply-To: <50C27DBA.3050808@oracle.com>
References: <50BF994B.5020308@oracle.com> <50C2459F.6080102@oracle.com>
<50C27AC1.2050600@oracle.com> <50C27DBA.3050808@oracle.com>
Message-ID: <50C61B4B.1080901@oracle.com>
On 12/7/2012 3:37 PM, Mandy Chung wrote:
> On 12/7/12 3:24 PM, Joe Wang wrote:
>> Thanks for reviewing the changes. Please see comments inline.
>>
>> On 12/7/2012 11:38 AM, Mandy Chung wrote:
>>> On 12/5/12 10:58 AM, Alan Bateman wrote:
>>>> http://cr.openjdk.java.net/~alanb/8004371/webrev/
>>>>
>>>
>>> Yay! Properties no longer requires JAXP to be present in order to
>>> load/store properties in XML format. This looks okay to me. Some
>>> minor comments:
>>>
>>> XMLStreamWriterImpl.isEncodingSupported - it returns true if any
>>> string != "UTF-32" that assumes the given encoding is one of the few
>>> known values. Would it be better to check the explicit list of
>>> supported encoding?
>>> private boolean isEncodingSupported(String encoding) {
>>> if (encoding.equalsIgnoreCase("UTF-32")) {
>>> return false;
>>> }
>>> return true;
>>> }
>>
>> The spec only requires UTF-8 and 16. But the writer can actually
>> handle most of the encodings. An explicit list would be quite long
>> and require comprehensive tests. Since the ukit parser explicitly
>> rejects UTF-32, I chose to do the same. Other than that, the
>> XMLWriter leaves it to java.nio.charset.Charset to determine if a
>> specified encoding is supported through this call:
>> try {
>> cs = Charset.forName(encoding);
>> } catch (IllegalCharsetNameException |
>> UnsupportedCharsetException ex) {
>> throw new XMLStreamException(new
>> UnsupportedEncodingException(encoding));
>> }
>
> OK - you leave it for XMLWriter to check if it's a valid encoding. It
> may be better to include Charset.forName check in the
> isEncodingSupporting method that would avoid confusion.
Sure. Will move this code into isEncodingSupported and change the method
name to getCharset so that it'd return the charset if the encoding is
not UTF32 and supported by the jdk.
>
>>>
>>> PropertiesDefaultHandler.java L115-116: can be replaced with
>>> Properties.stringPropertyNames() and foreach.
>>
>> Done. Will send update to Alan.
>>
>>>
>>> XMLStreamWriterImpl.java L156 - since the caller needs to unwrap
>>> XMLStreamException to determine if the encoding is supported or not,
>>> maybe better to throw this constructor to throw
>>> UnsupportedEncodingException.
>>
>> The writer implements partially the original StAX API. So I tried
>> not to change the writer API. But java.util.Properties expect
>> UnsupportedEncodingException in case of invalid encoding, thus the
>> compromise.
>>
> OK - PropertiesDefaultHandler uses the XMLStreamWriter API. That's
> fine with me.
Thanks,
Joe
>
> Thanks
> Mandy
From huizhe.wang at oracle.com Mon Dec 10 17:47:46 2012
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 10 Dec 2012 09:47:46 -0800
Subject: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser
factories (7169894: JAXP Plugability Layer: using service loader)
In-Reply-To: <50C6181B.70005@oracle.com>
References: <50BCF7CD.1020308@oracle.com> <50BE007A.4090102@oracle.com>
<50BF73B2.5000102@oracle.com> <50C06DAC.5050500@oracle.com>
<50C0D805.5030509@oracle.com> <50C1A31D.1090805@oracle.com>
<50C1EB41.2010502@oracle.com> <50C207F9.5060307@oracle.com>
<50C21A2C.8070503@oracle.com> <50C23755.5030503@oracle.com>
<50C6181B.70005@oracle.com>
Message-ID: <50C62042.4000600@oracle.com>
Hi Daniel,
Looks good!
Joe
On 12/10/2012 9:12 AM, Daniel Fuchs wrote:
> Hi,
>
> After further discussion with Joe & Alan, I changed the call
> to ServiceLoader to simply return the first provider it finds,
> or null.
>
> This is closer to what was present in JDK 7 - and looping is
> not necessary in JDK 8 since the default implementation is
> not returned as a service provider.
>
> So here is a new - and hopefully simpler webrev:
>
>
>
>
> best regards,
>
> -- daniel
>
> On 12/7/12 7:37 PM, Mandy Chung wrote:
>> On 12/7/12 8:32 AM, Alan Bateman wrote:
>>> On 07/12/2012 15:15, Daniel Fuchs wrote:
>>>> Hi Alan,
>>>>
>>>> I have updated the webrev according to your suggestion. I think it
>>>> makes
>>>> things much clearer.
>>>>
>>>> The new version is there:
>>>>
>>>>
>>>>
>>>>
>>> This looks good to me except that "implementation system default"
>>> should be "system-default implementation".
>>>
>> Looks good to me too with the change to "system-default
>> implementation".
>>
>> Mandy
>>
>
From joe.darcy at oracle.com Mon Dec 10 20:52:57 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 10 Dec 2012 12:52:57 -0800
Subject: bottleneck by java.lang.Class.getAnnotations() - rebased patch
In-Reply-To: <50C60A45.9020807@gmail.com>
References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com>
<23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com>
<5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com>
<5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com>
<50990CB8.2040400@gmail.com> <5099C2FA.2020202@oracle.com>
<509A3A63.5010102@gmail.com> <50AF5930.5010903@gmail.com>
<50AFADB4.9000204@gmail.com> <50B8FC99.401@gmail.com>
<50B900F2.9060902@oracle.com> <50BBFD2F.1080108@oracle.com>
<50BC57A0.8000108@gmail.com> <50C57EB0.1000202@oracle.com>
<50C5F8CE.3080006@gmail.com> <50C60A45.9020807@gmail.com>
Message-ID: <50C64BA9.1090500@oracle.com>
Yes; the OpenJDK sources only go back to circa 2007, which was part-way
into the JDK 7 release. The exact changesets of how annotations were
added back in JDK 5 are not available publicly. However, the final
results of that process may be mostly visible in the src.zip from JDK 5.
HTH,
-Joe
On 12/10/2012 8:13 AM, Peter Levart wrote:
> Hi David,
>
> It would be informative to look at how java.lang.Class evolved during
> history. The oldest revision I can access is from 1st of Dec. 2007,
> which already contains Java 1.5 code (annotations) and is more or less
> unchanged until now. The most interesting changesets would be those
> that introduced annotations.
>
> Regards, Peter
>
>
> On 12/10/2012 03:59 PM, Peter Levart wrote:
>> On 12/10/2012 07:18 AM, David Holmes wrote:
>>> Hi Peter,
>>>
>>> Sorry for the delay on this.
>>
>> Thank you for taking it into consideration. I can only imagine how
>> busy you are with other things.
>>
>>>
>>> Generally your VolatileData and my ReflectionHelper are doing a
>>> similar job. But I agree with your reasoning that all of the cached
>>> SoftReferences are likely to be cleared at once, and so a
>>> SoftReference to a helper object with direct references, is more
>>> effective than a direct reference to a helper object with
>>> SoftReferences. My initial stance with this was very conservative as
>>> the more change that is introduced the more uncertainty there is
>>> about the impact.
>>>
>>> I say the above primarily because I think, if I am to proceed with
>>> this, I will need to separate out the general reflection caching
>>> changes from the annotation changes. There are a number of reasons
>>> for this:
>>>
>>> First, I'm not at all familiar with the implementation of
>>> annotations at the VM or Java level, and the recent changes in this
>>> area just exacerbate my ignorance of the mechanics. So I don't feel
>>> qualified to evaluate that aspect.
>>>
>>> Second, the bulk of the reflection caching code is simplified by the
>>> fact that due to current constraints on class redefinition the
>>> caching is effectively idempotent for fields/methods/constructors.
>>> But that is not the case for annotations.
>>
>> I think that on the Class-level these two aspects can be separated.
>> But not on the Field/Method/Constructor level, because annotations
>> are referenced by Field/Method/Constructor objects and there is no
>> invalidation logic - like on the Class-level - that would just
>> invalidate the sets of annotations on Field/Method/Constructor,
>> leaving Field/Method/Constructor objects still valid. So these two
>> aspects are connected - it may be - I haven't looked at history yet -
>> that invalidation of Field/Method/Constructor was introduced just
>> because of annotations.
>>
>> Also, the following bug (currently not accessible):
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002251 has
>> references to docs that suggest that current class redefinition can
>> introduce new methods, so If this is correct, then redefinition is
>> not idempotent for basic reflection data.
>>
>>>
>>> Finally, the use of synchronization with the annotations method is
>>> perplexing me. I sent Joe a private email on this but I may as well
>>> raise it here - and I think you have alluded to this in your earlier
>>> emails as well: initAnnotationsIfNecessary() is a synchronized
>>> instance method but I can not find any other code in the VM that
>>> synchronizes on the Class object's monitor. So if this
>>> synchronization is trying to establish consistency in the face of
>>> class redefinition, I do not see where class redefinition is
>>> participating in the synchronization!
>>
>> I think that the intent was merely synchronized access to / lazy
>> initialization of cached 'annotations' and 'declaredAnnotations'
>> Maps. Field[], Method[], Constructor[] arrays are published to other
>> threads via volatile fields one field at a time, but
>> initAnnotationsIfNecessary() was designed to publish two references
>> ('annotations' and 'declaredAnnotations') atomically at the same
>> time, so the author of the code choose to use synchronized block. I
>> also have a feeling that this might have simply been the author's
>> preferred style of synchronization, since the same approach is used
>> also in Field/Method/Constructor/Executable although there's just one
>> field of annotations that is published at a time.
>>
>> It is indicative that initAnnotationsIfNecessary() synchronized
>> method also contains the call to clearCachesOnClassRedefinition(), so
>> at first it seems that the synchronization is also meant to serialize
>> access to invalidation logic which invalidates both
>> Field/Method/Constructor and annotation fields, but that all
>> falls-apart because clearCachesOnClassRedefinition() is also called
>> from elsewhere, not guarded by the synchronization.
>>
>> So all in all the two aspects - annotations and basic reflection
>> stuff - are quite intermingled in current code, unfortunately very
>> inconsistently. I'm afraid that doing one thing and not touching the
>> other is possible, but that would not solve the problems that this
>> thread was starting to address (bottleneck by
>> java.lang.Class.getAnnotations()) and evident dead-lock bugs.
>>
>> We can approach the problem so that we separate the aspects of
>> caching Class-level annotations and Field/Method/Constructor arrays
>> but using the same approach for both. And that would only make sense
>> if there was a reason to separately cache Class-level annotations and
>> Field/Method/Constructor arrays. I haven't yet been able to think of
>> one such reason. So anyone with more insight (the author of
>> annotations code?) is invited to participate in investigation.
>>
>> My approach of including the Class-level annotations together with
>> Field/Method/Constructor arrays was guided by:
>> - consistency - why should Class-level annotations be cached with
>> hard references, while Field/Method/Constructor annotations are
>> indirectly SoftReference(d)? Are they more important?
>> - simplicity
>> - space efficiency
>> - correctness - unsynchronized calls to
>> clearCachesOnClassRedefinition() followed by unsynchronized lazy
>> initialization have - as I have shown - theoretical races that could
>> result in caching the old versions of data instead of new. The
>> approach I have chosen with the logic in getVolatileData() is a kind
>> of MVCC rather than synchronization.
>>
>> But as said, the two aspects of caching can be separated.
>>
>> We can also leave the Class-level annotation aspect untouched by
>> re-introducing the 'annotations' and 'declaredAnnotations' fields and
>> also the 'lastRedefinedCount' field on the Class-level and
>> re-introducing the synchronized initAnnotationsIfNecessary() method
>> and a clearCachesOnClassRedefinition() which would just invalidate
>> the two annotations fields.
>>
>> To recap. How to continue?
>> a) as proposed;
>> b) separate caching of annotations and Field/Method/Constructor
>> arrays but with the same unblocking MVCC-like approach for both -
>> with possible variation in that annotations be hardly referenced and
>> Field/Method/Constructor arrays be softly;
>> c) undo the annotations caching changes and only do MVCC for
>> Field/Method/Constructor arrays.
>>
>> I can do b) but prepare two independent patches - one for
>> VolatileData (rename it to MemberData?) and one for AnnotationData.
>> So by applying only the first, we achieve c) and can later apply the
>> second to upgrade to b). But it is unfortunately a) that is most
>> efficient space-saving wise.
>>
>> What do you say about the trivial changes in
>> Field/Method/Constructor/Executable to accommodate caching on the
>> 'root' instance instead of on the copies?
>>
>> Regards, Peter
>>
>>>
>>> So what I would like to do is take your basic VolatileData part of
>>> the patch and run with it for JEP-149 purposes, while separating the
>>> annotations issue so they can be dealt with by the experts in that
>>> particular area.
>>>
>>> I'm sorry it has taken so long to arrive at a fairly negative
>>> position, but I need someone else to take up the annotations
>>> gauntlet and run with it.
>>>
>>> Thanks,
>>> David
>>>
>>> On 3/12/2012 5:41 PM, Peter Levart wrote:
>>>> Hi David, Alan, Alexander and others,
>>>>
>>>> In the meanwhile I have added another annotations space
>>>> optimization to
>>>> the patch. If a Class doesn't inherit any annotations from a
>>>> superclass,
>>>> which I think is a common case, it assigns the same Map instance to
>>>> "annotations" as well as "declaredAnnotations" fields. Previously -
>>>> and
>>>> in the original code - this only happened for java.lang.Object and
>>>> interfaces.
>>>>
>>>> Here's the updated webrev:
>>>>
>>>> http://dl.dropbox.com/u/101777488/jdk8-tl/JEP-149/webrev.02/index.html
>>>>
>>>> I have also rewritten the performance micro-benchmarks. With the
>>>> addition of repeating annotations, one performance aspect surfaces:
>>>> when
>>>> asking for a particular annotation type on a Class and that annotation
>>>> is not present, the new repeating annotations support method
>>>> AnnotationSupport.getOneAnnotation asks for @ContainedBy
>>>> meta-annotation
>>>> on the annotation type. This can result in an even more apparent
>>>> synchronization hot-spot with original code that uses synchronized
>>>> initAnnotationsIfNecessary(). This aspect is tested with the 3rd test.
>>>> Other 2 tests test the same thing as before but are more stable now,
>>>> since now they measure retrieval of 5 different annotation types from
>>>> each AnnotatedElement, previously they only measured retrieval of 1
>>>> which was very sensitive to HashMap irregularities (it could happen
>>>> that
>>>> a particular key mapped to a bucket that was overloaded in one
>>>> test-run
>>>> and not in another)...
>>>>
>>>> Here're the new tests:
>>>>
>>>> https://raw.github.com/plevart/jdk8-tl/JEP-149/test/src/test/ReflectionTest.java
>>>>
>>>>
>>>> And the corresponding results when run on an i7 CPU on Linux:
>>>>
>>>> https://raw.github.com/plevart/jdk8-tl/JEP-149/test/benchmark_results_i7-2600K.txt
>>>>
>>>>
>>>>
>>>> Regards, Peter
>>>>
>>>>
>>>>
>>>> On 12/03/2012 02:15 AM, David Holmes wrote:
>>>>> On 1/12/2012 4:54 AM, Alan Bateman wrote:
>>>>>> On 30/11/2012 18:36, Peter Levart wrote:
>>>>>>> :
>>>>>>>
>>>>>>> So, what do you think? What kind of tests should I prepare in
>>>>>>> addidion
>>>>>>> to those 3 so that the patch might get a consideration?
>>>>>> I think this is good work and thanks for re-basing your patch. I
>>>>>> know
>>>>>> David plans to do a detail review. I think it will require extensive
>>>>>> performance testing too, perhaps with some large applications.
>>>>>
>>>>> Indeed I do plan a detailed review and have initiated some initial
>>>>> performance tests.
>>>>>
>>>>> I am also swamped but will try to get to the review this week - and
>>>>> will also need to check the referenced annotations updates.
>>>>>
>>>>> David
>>>>>
>>>>>> -Alan
>>>>>>
>>>>
>>
>
From akhil.arora at oracle.com Mon Dec 10 21:48:25 2012
From: akhil.arora at oracle.com (Akhil Arora)
Date: Mon, 10 Dec 2012 13:48:25 -0800
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com>
References: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com>
Message-ID: <50C658A9.30607@oracle.com>
Updated with yours and Alan's comments -
http://cr.openjdk.java.net/~akhil/8001647.2/webrev/
- removed null check for removeSet
- cache this.size in removeAll, replaceAll
(for ArrayList, Vector and CopyOnWriteArrayList)
- calculate removeCount instead of BitCount.cardinality()
- removed unnecessary @library from test support classes
Catching IndexOOB and throwing CME in forEach/removeAll/replaceAll seems
unecessary... did you have a use-case in mind where an IndexOOB can
occur with these methods?
Thanks
On 12/08/2012 05:11 AM, Arne Siegel wrote:
> ArrayList.java, line 1171:
> final boolean anyToRemove = (removeSet != null) && !removeSet.isEmpty();
> As removeSet will never be null, this line can be simplified. This is a left-over from the
> preceding implementation (see b67).
>
> ArrayList.java, method forEach optimizes the loop by reducing the number of heap accesses:
> final int size = this.size;
> for (int i=0; modCount == expectedModCount && i < size; i++) {
> ...
> This trick might also be introduced to methods removeAll and replaceAll.
>
> In the ListIterator implementation of ArrayList, there are various appearances of the idiom:
> try {
> ...
> } catch (IndexOutOfBoundsException ex) {
> throw new ConcurrentModificationException();
> }
> This technique might also be used in forEach, removeAll, and replaceAll (though not likely to
> be of any importance).
>
> Regards
> Arne Siegel
>
From mike.duigou at oracle.com Mon Dec 10 21:59:02 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 10 Dec 2012 13:59:02 -0800
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <50C5E36B.2040005@oracle.com>
References: <50C29B04.5070508@oracle.com> <50C5E36B.2040005@oracle.com>
Message-ID: <65E39782-6530-47CB-A1FC-741A5B9ED4E2@oracle.com>
On Dec 10 2012, at 05:28 , Alan Bateman wrote:
> On 08/12/2012 01:42, Akhil Arora wrote:
>> As part of the Library Lambdafication, this patch adds the following
>> default methods to Collections -
>>
> This may be bikeshed territory but we usually don't use the "public" modifier on methods defined by interfaces as they are public anyway.
Adding "public" was at my suggestion.
> It seems inconsistent to me to have it on the default methods. Perhaps this has been discussed before, in which case ignore this. BTW: The only reason I'm bringing this up is because there are lots of default methods to come and it would be nice to establish a convention and consistency from the start.
Agreed that we should be consistent. The suggestion to add "public" isn't related specifically to the default but anticipates, perhaps prematurely, future addition of "package" "module" and "protected" modifiers. When those modifiers are added it will make sense to be explicit about the access of a method. Additionally, some have complained about the difference in default access between interfaces and classes (public vs package) and prefer to explicit so that the intent is obvious and that method signature text in interfaces and classes look the same.
So, worthwhile or not?
Mike
From peter.levart at gmail.com Mon Dec 10 22:23:25 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 10 Dec 2012 23:23:25 +0100
Subject: bottleneck by java.lang.Class.getAnnotations() - rebased patch
In-Reply-To: <50C64BA9.1090500@oracle.com>
References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com>
<23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com>
<5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com>
<5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com>
<50990CB8.2040400@gmail.com> <5099C2FA.2020202@oracle.com>
<509A3A63.5010102@gmail.com> <50AF5930.5010903@gmail.com>
<50AFADB4.9000204@gmail.com> <50B8FC99.401@gmail.com>
<50B900F2.9060902@oracle.com> <50BBFD2F.1080108@oracle.com>
<50BC57A0.8000108@gmail.com> <50C57EB0.1000202@oracle.com>
<50C5F8CE.3080006@gmail.com> <50C60A45.9020807@gmail.com>
<50C64BA9.1090500@oracle.com>
Message-ID: <50C660DD.2000605@gmail.com>
Hi David, Joe,
I unpacked the src.zip of the first release of JDK 1.5.0. Here's the
relevant part:
private transient Map annotations;
private transient Map declaredAnnotations;
private synchronized void initAnnotationsIfNecessary() {
if (annotations != null)
return;
declaredAnnotations = AnnotationParser.parseAnnotations(
getRawAnnotations(), getConstantPool(), this);
Class superClass = getSuperclass();
if (superClass == null) {
annotations = declaredAnnotations;
} else {
annotations = new HashMap();
superClass.initAnnotationsIfNecessary();
for (Map.Entry e :
superClass.annotations.entrySet()) {
Class annotationClass = e.getKey();
if
(AnnotationType.getInstance(annotationClass).isInherited())
annotations.put(annotationClass, e.getValue());
}
annotations.putAll(declaredAnnotations);
}
}
...there's no sign of invalidation logic here yet. Neither for
annotations nor for fields/methods/constructors. This appears to have
been added later, presumably to accommodate class redefinition changing
annotations.
I would also like to see the source of AnnotationType to see if it used
the same logic and synchronization, but that's not part of src.zip
sources...
Regards, Peter
On 12/10/2012 09:52 PM, Joe Darcy wrote:
> Yes; the OpenJDK sources only go back to circa 2007, which was
> part-way into the JDK 7 release. The exact changesets of how
> annotations were added back in JDK 5 are not available publicly.
> However, the final results of that process may be mostly visible in
> the src.zip from JDK 5.
>
> HTH,
>
> -Joe
>
> On 12/10/2012 8:13 AM, Peter Levart wrote:
>> Hi David,
>>
>> It would be informative to look at how java.lang.Class evolved during
>> history. The oldest revision I can access is from 1st of Dec. 2007,
>> which already contains Java 1.5 code (annotations) and is more or
>> less unchanged until now. The most interesting changesets would be
>> those that introduced annotations.
>>
>> Regards, Peter
>>
>>
>> On 12/10/2012 03:59 PM, Peter Levart wrote:
>>> On 12/10/2012 07:18 AM, David Holmes wrote:
>>>> Hi Peter,
>>>>
>>>> Sorry for the delay on this.
>>>
>>> Thank you for taking it into consideration. I can only imagine how
>>> busy you are with other things.
>>>
>>>>
>>>> Generally your VolatileData and my ReflectionHelper are doing a
>>>> similar job. But I agree with your reasoning that all of the cached
>>>> SoftReferences are likely to be cleared at once, and so a
>>>> SoftReference to a helper object with direct references, is more
>>>> effective than a direct reference to a helper object with
>>>> SoftReferences. My initial stance with this was very conservative
>>>> as the more change that is introduced the more uncertainty there is
>>>> about the impact.
>>>>
>>>> I say the above primarily because I think, if I am to proceed with
>>>> this, I will need to separate out the general reflection caching
>>>> changes from the annotation changes. There are a number of reasons
>>>> for this:
>>>>
>>>> First, I'm not at all familiar with the implementation of
>>>> annotations at the VM or Java level, and the recent changes in this
>>>> area just exacerbate my ignorance of the mechanics. So I don't feel
>>>> qualified to evaluate that aspect.
>>>>
>>>> Second, the bulk of the reflection caching code is simplified by
>>>> the fact that due to current constraints on class redefinition the
>>>> caching is effectively idempotent for fields/methods/constructors.
>>>> But that is not the case for annotations.
>>>
>>> I think that on the Class-level these two aspects can be separated.
>>> But not on the Field/Method/Constructor level, because annotations
>>> are referenced by Field/Method/Constructor objects and there is no
>>> invalidation logic - like on the Class-level - that would just
>>> invalidate the sets of annotations on Field/Method/Constructor,
>>> leaving Field/Method/Constructor objects still valid. So these two
>>> aspects are connected - it may be - I haven't looked at history yet
>>> - that invalidation of Field/Method/Constructor was introduced just
>>> because of annotations.
>>>
>>> Also, the following bug (currently not accessible):
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002251 has
>>> references to docs that suggest that current class redefinition can
>>> introduce new methods, so If this is correct, then redefinition is
>>> not idempotent for basic reflection data.
>>>
>>>>
>>>> Finally, the use of synchronization with the annotations method is
>>>> perplexing me. I sent Joe a private email on this but I may as well
>>>> raise it here - and I think you have alluded to this in your
>>>> earlier emails as well: initAnnotationsIfNecessary() is a
>>>> synchronized instance method but I can not find any other code in
>>>> the VM that synchronizes on the Class object's monitor. So if this
>>>> synchronization is trying to establish consistency in the face of
>>>> class redefinition, I do not see where class redefinition is
>>>> participating in the synchronization!
>>>
>>> I think that the intent was merely synchronized access to / lazy
>>> initialization of cached 'annotations' and 'declaredAnnotations'
>>> Maps. Field[], Method[], Constructor[] arrays are published to other
>>> threads via volatile fields one field at a time, but
>>> initAnnotationsIfNecessary() was designed to publish two references
>>> ('annotations' and 'declaredAnnotations') atomically at the same
>>> time, so the author of the code choose to use synchronized block. I
>>> also have a feeling that this might have simply been the author's
>>> preferred style of synchronization, since the same approach is used
>>> also in Field/Method/Constructor/Executable although there's just
>>> one field of annotations that is published at a time.
>>>
>>> It is indicative that initAnnotationsIfNecessary() synchronized
>>> method also contains the call to clearCachesOnClassRedefinition(),
>>> so at first it seems that the synchronization is also meant to
>>> serialize access to invalidation logic which invalidates both
>>> Field/Method/Constructor and annotation fields, but that all
>>> falls-apart because clearCachesOnClassRedefinition() is also called
>>> from elsewhere, not guarded by the synchronization.
>>>
>>> So all in all the two aspects - annotations and basic reflection
>>> stuff - are quite intermingled in current code, unfortunately very
>>> inconsistently. I'm afraid that doing one thing and not touching the
>>> other is possible, but that would not solve the problems that this
>>> thread was starting to address (bottleneck by
>>> java.lang.Class.getAnnotations()) and evident dead-lock bugs.
>>>
>>> We can approach the problem so that we separate the aspects of
>>> caching Class-level annotations and Field/Method/Constructor arrays
>>> but using the same approach for both. And that would only make sense
>>> if there was a reason to separately cache Class-level annotations
>>> and Field/Method/Constructor arrays. I haven't yet been able to
>>> think of one such reason. So anyone with more insight (the author of
>>> annotations code?) is invited to participate in investigation.
>>>
>>> My approach of including the Class-level annotations together with
>>> Field/Method/Constructor arrays was guided by:
>>> - consistency - why should Class-level annotations be cached with
>>> hard references, while Field/Method/Constructor annotations are
>>> indirectly SoftReference(d)? Are they more important?
>>> - simplicity
>>> - space efficiency
>>> - correctness - unsynchronized calls to
>>> clearCachesOnClassRedefinition() followed by unsynchronized lazy
>>> initialization have - as I have shown - theoretical races that could
>>> result in caching the old versions of data instead of new. The
>>> approach I have chosen with the logic in getVolatileData() is a kind
>>> of MVCC rather than synchronization.
>>>
>>> But as said, the two aspects of caching can be separated.
>>>
>>> We can also leave the Class-level annotation aspect untouched by
>>> re-introducing the 'annotations' and 'declaredAnnotations' fields
>>> and also the 'lastRedefinedCount' field on the Class-level and
>>> re-introducing the synchronized initAnnotationsIfNecessary() method
>>> and a clearCachesOnClassRedefinition() which would just invalidate
>>> the two annotations fields.
>>>
>>> To recap. How to continue?
>>> a) as proposed;
>>> b) separate caching of annotations and Field/Method/Constructor
>>> arrays but with the same unblocking MVCC-like approach for both -
>>> with possible variation in that annotations be hardly referenced and
>>> Field/Method/Constructor arrays be softly;
>>> c) undo the annotations caching changes and only do MVCC for
>>> Field/Method/Constructor arrays.
>>>
>>> I can do b) but prepare two independent patches - one for
>>> VolatileData (rename it to MemberData?) and one for AnnotationData.
>>> So by applying only the first, we achieve c) and can later apply the
>>> second to upgrade to b). But it is unfortunately a) that is most
>>> efficient space-saving wise.
>>>
>>> What do you say about the trivial changes in
>>> Field/Method/Constructor/Executable to accommodate caching on the
>>> 'root' instance instead of on the copies?
>>>
>>> Regards, Peter
>>>
>>>>
>>>> So what I would like to do is take your basic VolatileData part of
>>>> the patch and run with it for JEP-149 purposes, while separating
>>>> the annotations issue so they can be dealt with by the experts in
>>>> that particular area.
>>>>
>>>> I'm sorry it has taken so long to arrive at a fairly negative
>>>> position, but I need someone else to take up the annotations
>>>> gauntlet and run with it.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 3/12/2012 5:41 PM, Peter Levart wrote:
>>>>> Hi David, Alan, Alexander and others,
>>>>>
>>>>> In the meanwhile I have added another annotations space
>>>>> optimization to
>>>>> the patch. If a Class doesn't inherit any annotations from a
>>>>> superclass,
>>>>> which I think is a common case, it assigns the same Map instance to
>>>>> "annotations" as well as "declaredAnnotations" fields. Previously
>>>>> - and
>>>>> in the original code - this only happened for java.lang.Object and
>>>>> interfaces.
>>>>>
>>>>> Here's the updated webrev:
>>>>>
>>>>> http://dl.dropbox.com/u/101777488/jdk8-tl/JEP-149/webrev.02/index.html
>>>>>
>>>>>
>>>>> I have also rewritten the performance micro-benchmarks. With the
>>>>> addition of repeating annotations, one performance aspect
>>>>> surfaces: when
>>>>> asking for a particular annotation type on a Class and that
>>>>> annotation
>>>>> is not present, the new repeating annotations support method
>>>>> AnnotationSupport.getOneAnnotation asks for @ContainedBy
>>>>> meta-annotation
>>>>> on the annotation type. This can result in an even more apparent
>>>>> synchronization hot-spot with original code that uses synchronized
>>>>> initAnnotationsIfNecessary(). This aspect is tested with the 3rd
>>>>> test.
>>>>> Other 2 tests test the same thing as before but are more stable now,
>>>>> since now they measure retrieval of 5 different annotation types from
>>>>> each AnnotatedElement, previously they only measured retrieval of 1
>>>>> which was very sensitive to HashMap irregularities (it could
>>>>> happen that
>>>>> a particular key mapped to a bucket that was overloaded in one
>>>>> test-run
>>>>> and not in another)...
>>>>>
>>>>> Here're the new tests:
>>>>>
>>>>> https://raw.github.com/plevart/jdk8-tl/JEP-149/test/src/test/ReflectionTest.java
>>>>>
>>>>>
>>>>> And the corresponding results when run on an i7 CPU on Linux:
>>>>>
>>>>> https://raw.github.com/plevart/jdk8-tl/JEP-149/test/benchmark_results_i7-2600K.txt
>>>>>
>>>>>
>>>>>
>>>>> Regards, Peter
>>>>>
>>>>>
>>>>>
>>>>> On 12/03/2012 02:15 AM, David Holmes wrote:
>>>>>> On 1/12/2012 4:54 AM, Alan Bateman wrote:
>>>>>>> On 30/11/2012 18:36, Peter Levart wrote:
>>>>>>>> :
>>>>>>>>
>>>>>>>> So, what do you think? What kind of tests should I prepare in
>>>>>>>> addidion
>>>>>>>> to those 3 so that the patch might get a consideration?
>>>>>>> I think this is good work and thanks for re-basing your patch. I
>>>>>>> know
>>>>>>> David plans to do a detail review. I think it will require
>>>>>>> extensive
>>>>>>> performance testing too, perhaps with some large applications.
>>>>>>
>>>>>> Indeed I do plan a detailed review and have initiated some initial
>>>>>> performance tests.
>>>>>>
>>>>>> I am also swamped but will try to get to the review this week - and
>>>>>> will also need to check the referenced annotations updates.
>>>>>>
>>>>>> David
>>>>>>
>>>>>>> -Alan
>>>>>>>
>>>>>
>>>
>>
>
From jim.gish at oracle.com Mon Dec 10 22:44:59 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Mon, 10 Dec 2012 17:44:59 -0500
Subject: RFR (ultra-trivial review): Typo in
http://java.sun.com/j2se/1.4.1/docs/api/java/util/logging/LogManager.html
Message-ID: <50C665EB.3020907@oracle.com>
Please review and push this ridiculously trivial fix:
http://cr.openjdk.java.net/~jgish/Bug4819681-Day1-typo-in-LogManager/
I'd love to know how many people have stumbled on this ridiculous
one-letter capitalization bug which has been around since day-1 of the
introduction of logging and kept pushing it under the rug for others to
stumble on instead of just fixing the thing and getting it out of the
way. Why do we continue to carry this kind of nonsense around? I can
just imagine the number of reports that have been generated over the
years for every single release since 1.4, where someone has just said
"Ah that one. It's trivial. Just forget it." Jeez! (rant over :-) )
Thanks,
Jim
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com
From joe.darcy at oracle.com Mon Dec 10 22:59:45 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 10 Dec 2012 14:59:45 -0800
Subject: RFR (ultra-trivial review): Typo in
http://java.sun.com/j2se/1.4.1/docs/api/java/util/logging/LogManager.html
In-Reply-To: <50C665EB.3020907@oracle.com>
References: <50C665EB.3020907@oracle.com>
Message-ID: <50C66961.6020300@oracle.com>
Approved!
-Joe
On 12/10/2012 02:44 PM, Jim Gish wrote:
> Please review and push this ridiculously trivial fix:
> http://cr.openjdk.java.net/~jgish/Bug4819681-Day1-typo-in-LogManager/
>
>
> I'd love to know how many people have stumbled on this ridiculous
> one-letter capitalization bug which has been around since day-1 of the
> introduction of logging and kept pushing it under the rug for others
> to stumble on instead of just fixing the thing and getting it out of
> the way. Why do we continue to carry this kind of nonsense around? I
> can just imagine the number of reports that have been generated over
> the years for every single release since 1.4, where someone has just
> said "Ah that one. It's trivial. Just forget it." Jeez! (rant over
> :-) )
>
> Thanks,
> Jim
>
From mandy.chung at oracle.com Mon Dec 10 23:15:06 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 10 Dec 2012 15:15:06 -0800
Subject: RFR (ultra-trivial review): Typo in
http://java.sun.com/j2se/1.4.1/docs/api/java/util/logging/LogManager.html
In-Reply-To: <50C66961.6020300@oracle.com>
References: <50C665EB.3020907@oracle.com> <50C66961.6020300@oracle.com>
Message-ID: <50C66CFA.2010400@oracle.com>
I am pushing the typo fix for you - Jim.
Mandy
On 12/10/2012 2:59 PM, Joe Darcy wrote:
> Approved!
>
> -Joe
>
> On 12/10/2012 02:44 PM, Jim Gish wrote:
>> Please review and push this ridiculously trivial fix:
>> http://cr.openjdk.java.net/~jgish/Bug4819681-Day1-typo-in-LogManager/
>>
>>
>>
>> I'd love to know how many people have stumbled on this ridiculous
>> one-letter capitalization bug which has been around since day-1 of
>> the introduction of logging and kept pushing it under the rug for
>> others to stumble on instead of just fixing the thing and getting it
>> out of the way. Why do we continue to carry this kind of nonsense
>> around? I can just imagine the number of reports that have been
>> generated over the years for every single release since 1.4, where
>> someone has just said "Ah that one. It's trivial. Just forget it."
>> Jeez! (rant over :-) )
>>
>> Thanks,
>> Jim
>>
>
From mandy.chung at oracle.com Mon Dec 10 23:17:53 2012
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Mon, 10 Dec 2012 23:17:53 +0000
Subject: hg: jdk8/tl/jdk: 4819681: Typo in
http://java.sun.com/j2se/1.4.1/docs/api/java/util/logging/LogManager.html
Message-ID: <20121210231812.B49ED47020@hg.openjdk.java.net>
Changeset: cac1bfaceaaa
Author: mchung
Date: 2012-12-10 15:15 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cac1bfaceaaa
4819681: Typo in http://java.sun.com/j2se/1.4.1/docs/api/java/util/logging/LogManager.html
Summary: Simple capitalization typo in LogManager() description
Reviewed-by: darcy, mchung
! src/share/classes/java/util/logging/LogManager.java
From mandy.chung at oracle.com Mon Dec 10 23:21:19 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 10 Dec 2012 15:21:19 -0800
Subject: RFR (ultra-trivial review): Typo in
http://java.sun.com/j2se/1.4.1/docs/api/java/util/logging/LogManager.html
In-Reply-To: <50C665EB.3020907@oracle.com>
References: <50C665EB.3020907@oracle.com>
Message-ID: <50C66E6F.3090708@oracle.com>
Jim,
Pushed [1]. I'm sorry that I missed to set the user when creating the
changeset and it was too late when I noticed that and attempted to kill
the hg push comment. Hope you don't mind.
Mandy
[1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cac1bfaceaaa
On 12/10/2012 2:44 PM, Jim Gish wrote:
> Please review and push this ridiculously trivial fix:
> http://cr.openjdk.java.net/~jgish/Bug4819681-Day1-typo-in-LogManager/
>
>
> I'd love to know how many people have stumbled on this ridiculous
> one-letter capitalization bug which has been around since day-1 of the
> introduction of logging and kept pushing it under the rug for others
> to stumble on instead of just fixing the thing and getting it out of
> the way. Why do we continue to carry this kind of nonsense around? I
> can just imagine the number of reports that have been generated over
> the years for every single release since 1.4, where someone has just
> said "Ah that one. It's trivial. Just forget it." Jeez! (rant over
> :-) )
>
> Thanks,
> Jim
>
From akhil.arora at oracle.com Mon Dec 10 23:45:27 2012
From: akhil.arora at oracle.com (Akhil Arora)
Date: Mon, 10 Dec 2012 15:45:27 -0800
Subject: Review Request: 8004201: add reducers to primitive type wrappers
In-Reply-To: <50BFDC75.6000306@oracle.com>
References: <50B8FE8A.2030403@oracle.com> <50BC0576.4070202@oracle.com>
<50BFBC49.9020200@oracle.com> <50BFDC75.6000306@oracle.com>
Message-ID: <50C67417.2030205@oracle.com>
http://cr.openjdk.java.net/~akhil/8004201.2/webrev/
- replaced "Suitable for conversion as a method reference to functional
interfaces such as ..." with @see java.util.function.BinaryOperator
- javadoc - replaced 'a argument'/'another argument' with
'the first operand'/'the second operand'
- did not widen return types - widening the return type makes these
methods unusable as reducers, since BinaryOperator is declared
T operate(T left, T right)
Thanks
On 12/05/2012 03:44 PM, Joseph Darcy wrote:
> Akhil,
>
> In javadoc like this
>
> 298 * as {@code BinaryOperator<Boolean>}.
>
> you don't have to use "<" and the like inside {@code}; please change to
>
> 298 * as {@code BinaryOperator}.
>
> As a general comment, if the operations for primitive type Foo are put
> into java.lang.Foo, then the type of the operation needs to be
> explicitly represented in the expression calling the method (unless
> static imports are used, etc.). Therefore, I suggest putting these sort
> of static methods all into one class to allow overloading to do its
> thing (java.lang.Operators?). Also, for methods like sum, I think it is
> worth considering returning a larger type than the operands to avoid
> problems from integer or floating-point overflow. For example, sum on
> byte and short would return int, sun on int would return long, etc.
>
> As an aside, to get a numerically robust result, the summation logic
> over a set of doubles needs to be more than just a set of raw double
> additions, but that can be tackled later.
>
> Cheers,
>
> -Joe
>
>
> On 12/5/2012 1:27 PM, Akhil Arora wrote:
>> Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/
>>
>> - delegate to Math.min/max for int/long/float/double
>> - rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor
>> - removed Character variants of min/max/sum
>>
>> On 12/02/2012 05:50 PM, David Holmes wrote:
>>> Hi Akhil,
>>>
>>> Is it really necessary/desirable to flag all of these as " Suitable for
>>> conversion as a method reference to functional interfaces such as ..." ?
>> Not necessary, but it does provide a hint as to their intended use to a
>> casual browser of these docs.
>>
>>> This style:
>>>
>>> + * @param a a boolean argument.
>>> + * @param b another boolean argument.
>>>
>>> is at odds with the style used elsewhere for new Functional APIs, and
>>> with the style of other methods in these classes. Can we just use "first
>>> operand" and "second operand" for all of these?
>> It is consistent with Math.min/max, which use the a/b style. Since these
>> methods are not in one of the functional package, is'nt it better to
>> stick to the local style?
>>
>>> Character.sum does not make sense to me. Who adds together characters?
>>> I'm not even sure min and max are worth supporting for Character.
>> Good point - removed these methods for Character.
>>
>>> I disagree with other suggestions to use the Math functions for
>>> float/double. I think all these methods should use the underlying
>>> primitive operator regardless of type.
>> Are you disagreeing only for float/double or for int/long also? Can you
>> provide more information as to why you disagree?
>>
>> Thanks
>>
>>> Thanks,
>>> David
>>> -----
>>>
>>> On 1/12/2012 4:44 AM, Akhil Arora wrote:
>>>> Hi
>>>>
>>>> Requesting review for some basic functionality related to lambdas -
>>>>
>>>> Add min, max, sum methods to the primitive wrapper classes - Byte,
>>>> Short, Integer, Long, Float, Double and Character so as to be able to
>>>> use them as reducers in lambda expressions. Add and, or, xor methods to
>>>> Boolean.
>>>>
>>>> http://cr.openjdk.java.net/~akhil/8004201.0/webrev/
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201
>>>>
>>>> Thanks
>>
>
From stuart.marks at oracle.com Mon Dec 10 23:48:28 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 10 Dec 2012 15:48:28 -0800
Subject: RFR: JDK-8003890: modify test scripts to pass VMOPTIONS
In-Reply-To: <50C5C6BD.3090609@oracle.com>
References: <780ee521-ef19-401b-9ed9-8c5cce2cb91c@default>
<50C5C3EA.4080802@oracle.com> <50C5C6BD.3090609@oracle.com>
Message-ID: <50C674CC.2090800@oracle.com>
On 12/10/12 3:25 AM, Alan Bateman wrote:
> On 10/12/2012 11:13, Chris Hegarty wrote:
>> Thank you Mark, this is a really useful contribution.
>>
>> I noticed that a few tests (below) specify either -client or -server. If the
>> vmoptions contain either of these arguments, and this seems to be the way our
>> test/Makefile is passing them, then it may result in the test using the wrong
>> vm. I think we should remove TESTVMOPTS from these tests, but then we lose
>> other potential opts, like heap size, etc.
>>
>> java/rmi/reliability/benchmark/runRmiBench.sh
>> java/rmi/reliability/benchmark/runSerialBench.sh
>> sun/management/jmxremote/startstop/JMXStartStopTest.sh
> You're right, this will cause conflict.
>
> In the case of JMXStartStopTest.sh and runSerialBench.sh then it might be
> better to remove the -server.
>
> Stuart might have an opinion on runRmiBench.sh but one idea is to change is so
> that when run interactively (TESTJAVA not set) then it works as it does now and
> runs the benchmark twice. If TESTJAVA is not set then it runs the benchmark
> once, with whatever VM options are in use.
For runRmiBench.sh the benchmark actually runs two JVMs, one as the RMI server
and the other as the RMI client. Note that -client and -server are passed as
arguments to the bench.rmi.Main start-class, which causes them to behave
differently. I'm wondering if whoever wrote the script originally confused the
arguments to Main with the arguments to the JVMs. Or, perhaps some tenuous line
of reasoning was used, such as "the RMI server is probably running on a server
and so should be running the server VM, and same for the RMI client."
So, I think that the JVM -server and -client args should be replaced by
$TESTVMOPTS. But of course please leave -server and -client args to the Main
class unchanged.
(Note, the runRmiBench.sh test is currently on the problem list so it's not run
right now anyway.)
For runSerialBench.sh, yes, I think removing -server and adding $TESTVMOPTS is
the right thing.
* * *
I've looked over the test/java/io/Serializable and the test/java/rmi changes
and they look fine. I haven't looked at the other changes though. I can look at
more files too if you need to spread out the reviewing load.
s'marks
From david.holmes at oracle.com Tue Dec 11 00:36:04 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 11 Dec 2012 10:36:04 +1000
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To: <50C5E969.5040602@redhat.com>
References: <50BF371A.1060604@oracle.com> <50C08305.90907@oracle.com>
<50C0B490.7050005@redhat.com> <50C55F11.6020801@oracle.com>
<50C5E969.5040602@redhat.com>
Message-ID: <50C67FF4.6050506@oracle.com>
On 10/12/2012 11:53 PM, David M. Lloyd wrote:
> On 12/09/2012 10:03 PM, David Holmes wrote:
>> That sounds promising. Are you in a position to try out this proposal on
>> a testbed with your app server?
>
> Sure, I'd love to. What tree should I build?
Please apply the patches from the webrevs here:
http://cr.openjdk.java.net/~dholmes/concurrent-loaders/webrev.hotspot/
http://cr.openjdk.java.net/~dholmes/concurrent-loaders/webrev.jdk/
They should apply to a jdk8 or tl forest. (And I hope I didn't mess
something up generating the webrev ;-) )
Thanks,
David
From stuart.marks at oracle.com Tue Dec 11 00:47:14 2012
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 10 Dec 2012 16:47:14 -0800
Subject: RFR: 8004651 - TEST: java/util/logging/CheckLockLocationTest.java
failed to delete file (win)
In-Reply-To: <50C2410E.7040200@oracle.com>
References: <50C2410E.7040200@oracle.com>
Message-ID: <50C68292.4030404@oracle.com>
Hi Jim,
Catching IOException from delete() is a bit odd. The only thing in the delete()
method that throws an IOE is the explicit throw of FileNotFoundException... so
in that case we'd throw FNFE and then catch the IOE at the caller and print a
warning. Would it be better to just print a warning from within the delete()
method, and remove "throws IOException" ? There's only one other caller to
delete() and it seems indifferent to this change.
Now that we're no longer checking the message of FileSystemException, it's
possible to change the instanceof check into a separate catch-clause of
FileSystemException, which simply ignores that exception. The catch clause for
IOException can be simplified to unconditionally wrap the IOE in a
RuntimeException and rethrow it. Actually it's not clear to me that's even
necessary since runTests() is declared to throw IOException, so we might not
even need to catch IOE here at all; we can just let it propagate to the caller.
Looks like similar simplifications apply to tests 2 and 4 as well.
s'marks
On 12/7/12 11:18 AM, Jim Gish wrote:
> Please review
> http://cr.openjdk.java.net/~jgish/Bug8004651-CheckLockLocationTest-Windows-delete-file-fix/
>
>
>
> Summary -- failure to delete a test log should be a warning instead of a
> failure. Also, while fixing this problem another one popped up -- not all
> platforms generate the same message in the FileSystemException ("Not a
> directory"), so removing the exception content check.
>
> Thanks,
> Jim
>
From joe.darcy at oracle.com Tue Dec 11 02:14:40 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 10 Dec 2012 18:14:40 -0800
Subject: bottleneck by java.lang.Class.getAnnotations() - rebased patch
In-Reply-To: <50C660DD.2000605@gmail.com>
References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com>
<23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com>
<5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com>
<5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com>
<50990CB8.2040400@gmail.com> <5099C2FA.2020202@oracle.com>
<509A3A63.5010102@gmail.com> <50AF5930.5010903@gmail.com>
<50AFADB4.9000204@gmail.com> <50B8FC99.401@gmail.com>
<50B900F2.9060902@oracle.com> <50BBFD2F.1080108@oracle.com>
<50BC57A0.8000108@gmail.com> <50C57EB0.1000202@oracle.com>
<50C5F8CE.3080006@gmail.com> <50C60A45.9020807@gmail.com>
<50C64BA9.1090500@oracle.com> <50C660DD.2000605@gmail.com>
Message-ID: <50C69710.4070100@oracle.com>
Hi Peter,
On 12/10/2012 02:23 PM, Peter Levart wrote:
> Hi David, Joe,
>
> I unpacked the src.zip of the first release of JDK 1.5.0. Here's the
> relevant part:
>
> private transient Map annotations;
> private transient Map declaredAnnotations;
>
> private synchronized void initAnnotationsIfNecessary() {
> if (annotations != null)
> return;
> declaredAnnotations = AnnotationParser.parseAnnotations(
> getRawAnnotations(), getConstantPool(), this);
> Class superClass = getSuperclass();
> if (superClass == null) {
> annotations = declaredAnnotations;
> } else {
> annotations = new HashMap();
> superClass.initAnnotationsIfNecessary();
> for (Map.Entry e :
> superClass.annotations.entrySet()) {
> Class annotationClass = e.getKey();
> if
> (AnnotationType.getInstance(annotationClass).isInherited())
> annotations.put(annotationClass, e.getValue());
> }
> annotations.putAll(declaredAnnotations);
> }
> }
>
>
> ...there's no sign of invalidation logic here yet. Neither for
> annotations nor for fields/methods/constructors. This appears to have
> been added later, presumably to accommodate class redefinition
> changing annotations.
>
> I would also like to see the source of AnnotationType to see if it
> used the same logic and synchronization, but that's not part of
> src.zip sources...
In JDK 5 GA, the annotations feature did not attempt to support class
file definition. From some quick bug archaeology, that omission was
addressed circa 5.0u8 (and JDK 6) via bugs including:
5002251 potential bug with annotations and class file evolution
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002251
6412391 fix for annotation cache and RedefineClasses() conflict
needs HotSpot changes
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6412391
6422541 fix for {Constructor,Field,Method} annotation cache and
RedefineClasses() conflict needs HS changes
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6422541
-Joe
>
> Regards, Peter
>
>
> On 12/10/2012 09:52 PM, Joe Darcy wrote:
>> Yes; the OpenJDK sources only go back to circa 2007, which was
>> part-way into the JDK 7 release. The exact changesets of how
>> annotations were added back in JDK 5 are not available publicly.
>> However, the final results of that process may be mostly visible in
>> the src.zip from JDK 5.
>>
>> HTH,
>>
>> -Joe
>>
>> On 12/10/2012 8:13 AM, Peter Levart wrote:
>>> Hi David,
>>>
>>> It would be informative to look at how java.lang.Class evolved
>>> during history. The oldest revision I can access is from 1st of Dec.
>>> 2007, which already contains Java 1.5 code (annotations) and is more
>>> or less unchanged until now. The most interesting changesets would
>>> be those that introduced annotations.
>>>
>>> Regards, Peter
>>>
>>>
>>> On 12/10/2012 03:59 PM, Peter Levart wrote:
>>>> On 12/10/2012 07:18 AM, David Holmes wrote:
>>>>> Hi Peter,
>>>>>
>>>>> Sorry for the delay on this.
>>>>
>>>> Thank you for taking it into consideration. I can only imagine how
>>>> busy you are with other things.
>>>>
>>>>>
>>>>> Generally your VolatileData and my ReflectionHelper are doing a
>>>>> similar job. But I agree with your reasoning that all of the
>>>>> cached SoftReferences are likely to be cleared at once, and so a
>>>>> SoftReference to a helper object with direct references, is more
>>>>> effective than a direct reference to a helper object with
>>>>> SoftReferences. My initial stance with this was very conservative
>>>>> as the more change that is introduced the more uncertainty there
>>>>> is about the impact.
>>>>>
>>>>> I say the above primarily because I think, if I am to proceed with
>>>>> this, I will need to separate out the general reflection caching
>>>>> changes from the annotation changes. There are a number of reasons
>>>>> for this:
>>>>>
>>>>> First, I'm not at all familiar with the implementation of
>>>>> annotations at the VM or Java level, and the recent changes in
>>>>> this area just exacerbate my ignorance of the mechanics. So I
>>>>> don't feel qualified to evaluate that aspect.
>>>>>
>>>>> Second, the bulk of the reflection caching code is simplified by
>>>>> the fact that due to current constraints on class redefinition the
>>>>> caching is effectively idempotent for fields/methods/constructors.
>>>>> But that is not the case for annotations.
>>>>
>>>> I think that on the Class-level these two aspects can be separated.
>>>> But not on the Field/Method/Constructor level, because annotations
>>>> are referenced by Field/Method/Constructor objects and there is no
>>>> invalidation logic - like on the Class-level - that would just
>>>> invalidate the sets of annotations on Field/Method/Constructor,
>>>> leaving Field/Method/Constructor objects still valid. So these two
>>>> aspects are connected - it may be - I haven't looked at history yet
>>>> - that invalidation of Field/Method/Constructor was introduced just
>>>> because of annotations.
>>>>
>>>> Also, the following bug (currently not accessible):
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002251 has
>>>> references to docs that suggest that current class redefinition can
>>>> introduce new methods, so If this is correct, then redefinition is
>>>> not idempotent for basic reflection data.
>>>>
>>>>>
>>>>> Finally, the use of synchronization with the annotations method is
>>>>> perplexing me. I sent Joe a private email on this but I may as
>>>>> well raise it here - and I think you have alluded to this in your
>>>>> earlier emails as well: initAnnotationsIfNecessary() is a
>>>>> synchronized instance method but I can not find any other code in
>>>>> the VM that synchronizes on the Class object's monitor. So if this
>>>>> synchronization is trying to establish consistency in the face of
>>>>> class redefinition, I do not see where class redefinition is
>>>>> participating in the synchronization!
>>>>
>>>> I think that the intent was merely synchronized access to / lazy
>>>> initialization of cached 'annotations' and 'declaredAnnotations'
>>>> Maps. Field[], Method[], Constructor[] arrays are published to
>>>> other threads via volatile fields one field at a time, but
>>>> initAnnotationsIfNecessary() was designed to publish two references
>>>> ('annotations' and 'declaredAnnotations') atomically at the same
>>>> time, so the author of the code choose to use synchronized block. I
>>>> also have a feeling that this might have simply been the author's
>>>> preferred style of synchronization, since the same approach is used
>>>> also in Field/Method/Constructor/Executable although there's just
>>>> one field of annotations that is published at a time.
>>>>
>>>> It is indicative that initAnnotationsIfNecessary() synchronized
>>>> method also contains the call to clearCachesOnClassRedefinition(),
>>>> so at first it seems that the synchronization is also meant to
>>>> serialize access to invalidation logic which invalidates both
>>>> Field/Method/Constructor and annotation fields, but that all
>>>> falls-apart because clearCachesOnClassRedefinition() is also called
>>>> from elsewhere, not guarded by the synchronization.
>>>>
>>>> So all in all the two aspects - annotations and basic reflection
>>>> stuff - are quite intermingled in current code, unfortunately very
>>>> inconsistently. I'm afraid that doing one thing and not touching
>>>> the other is possible, but that would not solve the problems that
>>>> this thread was starting to address (bottleneck by
>>>> java.lang.Class.getAnnotations()) and evident dead-lock bugs.
>>>>
>>>> We can approach the problem so that we separate the aspects of
>>>> caching Class-level annotations and Field/Method/Constructor arrays
>>>> but using the same approach for both. And that would only make
>>>> sense if there was a reason to separately cache Class-level
>>>> annotations and Field/Method/Constructor arrays. I haven't yet been
>>>> able to think of one such reason. So anyone with more insight (the
>>>> author of annotations code?) is invited to participate in
>>>> investigation.
>>>>
>>>> My approach of including the Class-level annotations together with
>>>> Field/Method/Constructor arrays was guided by:
>>>> - consistency - why should Class-level annotations be cached with
>>>> hard references, while Field/Method/Constructor annotations are
>>>> indirectly SoftReference(d)? Are they more important?
>>>> - simplicity
>>>> - space efficiency
>>>> - correctness - unsynchronized calls to
>>>> clearCachesOnClassRedefinition() followed by unsynchronized lazy
>>>> initialization have - as I have shown - theoretical races that
>>>> could result in caching the old versions of data instead of new.
>>>> The approach I have chosen with the logic in getVolatileData() is a
>>>> kind of MVCC rather than synchronization.
>>>>
>>>> But as said, the two aspects of caching can be separated.
>>>>
>>>> We can also leave the Class-level annotation aspect untouched by
>>>> re-introducing the 'annotations' and 'declaredAnnotations' fields
>>>> and also the 'lastRedefinedCount' field on the Class-level and
>>>> re-introducing the synchronized initAnnotationsIfNecessary() method
>>>> and a clearCachesOnClassRedefinition() which would just invalidate
>>>> the two annotations fields.
>>>>
>>>> To recap. How to continue?
>>>> a) as proposed;
>>>> b) separate caching of annotations and Field/Method/Constructor
>>>> arrays but with the same unblocking MVCC-like approach for both -
>>>> with possible variation in that annotations be hardly referenced
>>>> and Field/Method/Constructor arrays be softly;
>>>> c) undo the annotations caching changes and only do MVCC for
>>>> Field/Method/Constructor arrays.
>>>>
>>>> I can do b) but prepare two independent patches - one for
>>>> VolatileData (rename it to MemberData?) and one for AnnotationData.
>>>> So by applying only the first, we achieve c) and can later apply
>>>> the second to upgrade to b). But it is unfortunately a) that is
>>>> most efficient space-saving wise.
>>>>
>>>> What do you say about the trivial changes in
>>>> Field/Method/Constructor/Executable to accommodate caching on the
>>>> 'root' instance instead of on the copies?
>>>>
>>>> Regards, Peter
>>>>
>>>>>
>>>>> So what I would like to do is take your basic VolatileData part of
>>>>> the patch and run with it for JEP-149 purposes, while separating
>>>>> the annotations issue so they can be dealt with by the experts in
>>>>> that particular area.
>>>>>
>>>>> I'm sorry it has taken so long to arrive at a fairly negative
>>>>> position, but I need someone else to take up the annotations
>>>>> gauntlet and run with it.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> On 3/12/2012 5:41 PM, Peter Levart wrote:
>>>>>> Hi David, Alan, Alexander and others,
>>>>>>
>>>>>> In the meanwhile I have added another annotations space
>>>>>> optimization to
>>>>>> the patch. If a Class doesn't inherit any annotations from a
>>>>>> superclass,
>>>>>> which I think is a common case, it assigns the same Map instance to
>>>>>> "annotations" as well as "declaredAnnotations" fields. Previously
>>>>>> - and
>>>>>> in the original code - this only happened for java.lang.Object and
>>>>>> interfaces.
>>>>>>
>>>>>> Here's the updated webrev:
>>>>>>
>>>>>> http://dl.dropbox.com/u/101777488/jdk8-tl/JEP-149/webrev.02/index.html
>>>>>>
>>>>>>
>>>>>> I have also rewritten the performance micro-benchmarks. With the
>>>>>> addition of repeating annotations, one performance aspect
>>>>>> surfaces: when
>>>>>> asking for a particular annotation type on a Class and that
>>>>>> annotation
>>>>>> is not present, the new repeating annotations support method
>>>>>> AnnotationSupport.getOneAnnotation asks for @ContainedBy
>>>>>> meta-annotation
>>>>>> on the annotation type. This can result in an even more apparent
>>>>>> synchronization hot-spot with original code that uses synchronized
>>>>>> initAnnotationsIfNecessary(). This aspect is tested with the 3rd
>>>>>> test.
>>>>>> Other 2 tests test the same thing as before but are more stable now,
>>>>>> since now they measure retrieval of 5 different annotation types
>>>>>> from
>>>>>> each AnnotatedElement, previously they only measured retrieval of 1
>>>>>> which was very sensitive to HashMap irregularities (it could
>>>>>> happen that
>>>>>> a particular key mapped to a bucket that was overloaded in one
>>>>>> test-run
>>>>>> and not in another)...
>>>>>>
>>>>>> Here're the new tests:
>>>>>>
>>>>>> https://raw.github.com/plevart/jdk8-tl/JEP-149/test/src/test/ReflectionTest.java
>>>>>>
>>>>>>
>>>>>> And the corresponding results when run on an i7 CPU on Linux:
>>>>>>
>>>>>> https://raw.github.com/plevart/jdk8-tl/JEP-149/test/benchmark_results_i7-2600K.txt
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards, Peter
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12/03/2012 02:15 AM, David Holmes wrote:
>>>>>>> On 1/12/2012 4:54 AM, Alan Bateman wrote:
>>>>>>>> On 30/11/2012 18:36, Peter Levart wrote:
>>>>>>>>> :
>>>>>>>>>
>>>>>>>>> So, what do you think? What kind of tests should I prepare in
>>>>>>>>> addidion
>>>>>>>>> to those 3 so that the patch might get a consideration?
>>>>>>>> I think this is good work and thanks for re-basing your patch.
>>>>>>>> I know
>>>>>>>> David plans to do a detail review. I think it will require
>>>>>>>> extensive
>>>>>>>> performance testing too, perhaps with some large applications.
>>>>>>>
>>>>>>> Indeed I do plan a detailed review and have initiated some initial
>>>>>>> performance tests.
>>>>>>>
>>>>>>> I am also swamped but will try to get to the review this week - and
>>>>>>> will also need to check the referenced annotations updates.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>> -Alan
>>>>>>>>
>>>>>>
>>>>
>>>
>>
>
From karen.kinnear at oracle.com Tue Dec 11 02:31:39 2012
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Mon, 10 Dec 2012 21:31:39 -0500
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To: <50C56053.1060306@oracle.com>
References: <50BF371A.1060604@oracle.com> <50C27FE6.1050107@oracle.com>
<50C56053.1060306@oracle.com>
Message-ID:
David,
I fully support the concept of a fully concurrent class loader, which allows parallel defineClass.
I would agree that we deprecate registerAsParallelCapable - starting deprecation in JDK8.
My memory is that customers asked us for the getClassLoadingLock API so that they could
do their own internal concurrency controls using the same lock we created, so I think we need
the blog etc. to explicitly ask for feedback on having this API return NULL or deprecating it. It does
matter if our customers are using the results.
"Fully concurrent" means custom class loaders that need to protect any per-class data
do their own internal locking, not that no locks are needed. It means we allow
concurrent defineClass, with the defineClassIfNotPresent semantics.
Question on the source code: registerAsFullyConcurrent has confusing comment -
do the super classes all need to be parallel capable? Or do the super classes all need
to be FullyConcurrent? I assume the latter, so just fix the comments.
thanks,
Karen
On Dec 9, 2012, at 11:08 PM, David Holmes wrote:
>
> Thanks for the comments Mandy.
>
> On 8/12/2012 9:46 AM, Mandy Chung wrote:
>> On 12/5/12 3:59 AM, David Holmes wrote:
>>> Java 7 introduced support for parallel classloading by adding to each
>>> class loader a ConcurrentHashMap, referenced through a new field,
>>> parallelLockMap. This contains a mapping from class names to Objects
>>> to use as a classloading lock for that class name. This scheme has a
>>> number of inefficiencies. To address this we propose for Java 8 the
>>> notion of a fully concurrent classloader ...
>>>
>>> This is a fairly simple proposal that I've written up as a blog entry:
>>>
>>> https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent
>>>
>>>
>> It's a good and simple proposal and also handles the backward
>> compatibility nicely.
>>
>> I think having getClassLoadingLock() to return null for a fully
>> concurrent loader is a good idea. In case if any code synchronizes on
>> the returned value after migrating to fully concurrent class loader, it
>> will catch such usage (it might be very rare)/
>
> The only glitch with this is that a concurrent loader is-a parallel loader, so anyone trying work with an arbitrary parallel loader will encounter a problem with a concurrent loader if they don't make their code concurrent-loader aware. I am hopeful that the parallelLockMap is only being used internally by the classloaders themselves, and that there are no, or very few, external clients.
>
>> I agree with Alan's suggestion - we should consider deprecating
>> registerAsParallelCapable.
>
> Definitely a consideration, though as I said perhaps for 9 rather than 8.
>
> Thanks,
> David
>>
>> Mandy
>>
From luchsh at linux.vnet.ibm.com Tue Dec 11 02:42:58 2012
From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com)
Date: Tue, 11 Dec 2012 02:42:58 +0000
Subject: hg: jdk8/tl/jdk: 6512101: Incorrect encoding in
NetworkInterface.getDisplayName()
Message-ID: <20121211024324.4C83147036@hg.openjdk.java.net>
Changeset: 883feced1cdd
Author: dingxmin
Date: 2012-12-11 10:42 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/883feced1cdd
6512101: Incorrect encoding in NetworkInterface.getDisplayName()
Reviewed-by: chegar, dsamersoff
! src/windows/native/java/net/NetworkInterface.c
From david.holmes at oracle.com Tue Dec 11 02:55:24 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 11 Dec 2012 12:55:24 +1000
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To:
References: <50BF371A.1060604@oracle.com> <50C27FE6.1050107@oracle.com>
<50C56053.1060306@oracle.com>
Message-ID: <50C6A09C.6000508@oracle.com>
Hi Karen,
Thanks for your feedback.
On 11/12/2012 12:31 PM, Karen Kinnear wrote:
> David,
>
> I fully support the concept of a fully concurrent class loader, which allows parallel defineClass.
>
> I would agree that we deprecate registerAsParallelCapable - starting deprecation in JDK8.
Okay that seems to be the consensus. I'm obviously way too conservative :)
> My memory is that customers asked us for the getClassLoadingLock API so that they could
> do their own internal concurrency controls using the same lock we created, so I think we need
> the blog etc. to explicitly ask for feedback on having this API return NULL or deprecating it. It does
> matter if our customers are using the results.
Okay it would be good to understand this better. Given each parallel
classloader had a different lock per class this really only matters if
they try to get the lock used by one of the existing system
classloaders. Their own parallel loaders will continue to function as
normal.
> "Fully concurrent" means custom class loaders that need to protect any per-class data
> do their own internal locking, not that no locks are needed. It means we allow
> concurrent defineClass, with the defineClassIfNotPresent semantics.
Is that a question or a statement? :) A fully concurrent loader needs no
'framework' support for synchronizing classloading. That could be
because it uses its own locks, or that no locks are needed.
> Question on the source code: registerAsFullyConcurrent has confusing comment -
> do the super classes all need to be parallel capable? Or do the super classes all need
> to be FullyConcurrent? I assume the latter, so just fix the comments.
Actually it is the former. There's no reason to require that all
superclasses be fully-concurrent. Of course a given loaders degree of
concurrency may be constrained by what it's supertype allows, but
there's no reason to actually force all the supertypes to be
fully-concurrent: it is enough that they are at least all parallel capable.
Thanks,
David
> thanks,
> Karen
>
> On Dec 9, 2012, at 11:08 PM, David Holmes wrote:
>
>>
>> Thanks for the comments Mandy.
>>
>> On 8/12/2012 9:46 AM, Mandy Chung wrote:
>>> On 12/5/12 3:59 AM, David Holmes wrote:
>>>> Java 7 introduced support for parallel classloading by adding to each
>>>> class loader a ConcurrentHashMap, referenced through a new field,
>>>> parallelLockMap. This contains a mapping from class names to Objects
>>>> to use as a classloading lock for that class name. This scheme has a
>>>> number of inefficiencies. To address this we propose for Java 8 the
>>>> notion of a fully concurrent classloader ...
>>>>
>>>> This is a fairly simple proposal that I've written up as a blog entry:
>>>>
>>>> https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent
>>>>
>>>>
>>> It's a good and simple proposal and also handles the backward
>>> compatibility nicely.
>>>
>>> I think having getClassLoadingLock() to return null for a fully
>>> concurrent loader is a good idea. In case if any code synchronizes on
>>> the returned value after migrating to fully concurrent class loader, it
>>> will catch such usage (it might be very rare)/
>>
>> The only glitch with this is that a concurrent loader is-a parallel loader, so anyone trying work with an arbitrary parallel loader will encounter a problem with a concurrent loader if they don't make their code concurrent-loader aware. I am hopeful that the parallelLockMap is only being used internally by the classloaders themselves, and that there are no, or very few, external clients.
>>
>>> I agree with Alan's suggestion - we should consider deprecating
>>> registerAsParallelCapable.
>>
>> Definitely a consideration, though as I said perhaps for 9 rather than 8.
>>
>> Thanks,
>> David
>>>
>>> Mandy
>>>
>
From david.lloyd at redhat.com Tue Dec 11 03:41:45 2012
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Mon, 10 Dec 2012 21:41:45 -0600
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To: <50C67FF4.6050506@oracle.com>
References: <50BF371A.1060604@oracle.com> <50C08305.90907@oracle.com>
<50C0B490.7050005@redhat.com> <50C55F11.6020801@oracle.com>
<50C5E969.5040602@redhat.com> <50C67FF4.6050506@oracle.com>
Message-ID: <50C6AB79.4010606@redhat.com>
On 12/10/2012 06:36 PM, David Holmes wrote:
> On 10/12/2012 11:53 PM, David M. Lloyd wrote:
>> On 12/09/2012 10:03 PM, David Holmes wrote:
>>> That sounds promising. Are you in a position to try out this proposal on
>>> a testbed with your app server?
>>
>> Sure, I'd love to. What tree should I build?
>
> Please apply the patches from the webrevs here:
>
> http://cr.openjdk.java.net/~dholmes/concurrent-loaders/webrev.hotspot/
> http://cr.openjdk.java.net/~dholmes/concurrent-loaders/webrev.jdk/
>
> They should apply to a jdk8 or tl forest. (And I hope I didn't mess
> something up generating the webrev ;-) )
Well, I've just gotten everything working and done some cursory testing
on a startup of an "empty" JBoss AS 7 instance, and then reviewing the
metrics reported by our class loader. Our timing metrics are not really
great for general-purpose benchmarking (for various uninteresting
reasons), but I can at least get enough information to know everything
is working more or less as expected:
On JDK 6 with our "unsafe" lockless modification, we're typically
loading 4707 classes, and I'm seeing anywhere from 0 to 5 define races
that were automatically resolved.
On JDK 7 using the standard registerAsParallelCapable() mechanism, we
are loading 4711 classes and I'm seeing 35-50 define races that were
automatically resolved - the overhead of locking starts to come to the
fore I think.
On JDK 8 with your patches, we are loading around 4750 classes and there
are, as expected, 0 define races (I believe, however, that we're getting
a false count though whenever defineClass() returns an already-defined
class - it would be nice if there were *some* way to detect that this
happened).
On our class loader implementations, I'm initializing this way:
static {
try {
ClassLoader.registerAsFullyConcurrent();
} catch (Throwable ignored) {
try {
ClassLoader.registerAsParallelCapable();
} catch (Throwable ignored2) {
}
}
}
The debugging message confirms that our class loaders are successfully
registered as fully concurrent, and the fact that it doesn't hang or
crash on JDK 7 indicates that they are still properly being registered
as parallel-capable on that platform.
--
- DML
From david.holmes at oracle.com Tue Dec 11 05:10:04 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 11 Dec 2012 15:10:04 +1000
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To: <50BF371A.1060604@oracle.com>
References: <50BF371A.1060604@oracle.com>
Message-ID: <50C6C02C.1060705@oracle.com>
FYI I've made some small updates to the blog entry.
Just to quantify the inefficiencies here is the instrumented output of a
simple test that tries to load all classes in rt.jar and prints out the
size of the lock maps:
18521 classes loaded.
sun.misc.Launcher$AppClassLoader at f2f585 - lockMap size = 19050
sun.misc.Launcher$ExtClassLoader at d5163a - lockMap size = 19050
You may be wondering about the 500+ difference between the loaded
classes and the map size? These represent classes in the list to load
that were not actually present in rt.jar. So as you can see you not only
get a lock object for every class successfully loaded, you get a lock
object for every class that is attempted to be loaded!
David
-----
On 5/12/2012 9:59 PM, David Holmes wrote:
> Java 7 introduced support for parallel classloading by adding to each
> class loader a ConcurrentHashMap, referenced through a new field,
> parallelLockMap. This contains a mapping from class names to Objects to
> use as a classloading lock for that class name. This scheme has a number
> of inefficiencies. To address this we propose for Java 8 the notion of a
> fully concurrent classloader ...
>
> This is a fairly simple proposal that I've written up as a blog entry:
>
> https://blogs.oracle.com/dholmes/entry/parallel_classloading_revisited_fully_concurrent
>
>
> Please discuss this proposal here.
>
> Thanks,
> David Holmes
>
From weijun.wang at oracle.com Tue Dec 11 05:15:30 2012
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Tue, 11 Dec 2012 05:15:30 +0000
Subject: hg: jdk8/tl/jdk: 8004488: wrong permissions checked in krb5
Message-ID: <20121211051541.92D194703D@hg.openjdk.java.net>
Changeset: d206e52bf8a6
Author: weijun
Date: 2012-12-11 13:14 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d206e52bf8a6
8004488: wrong permissions checked in krb5
Reviewed-by: xuelei
! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java
! src/share/classes/sun/security/jgss/krb5/Krb5Util.java
+ test/sun/security/krb5/auto/KeyPermissions.java
! test/sun/security/krb5/auto/KeyTabCompat.java
From david.holmes at oracle.com Tue Dec 11 05:18:10 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 11 Dec 2012 15:18:10 +1000
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To: <50C6AB79.4010606@redhat.com>
References: <50BF371A.1060604@oracle.com> <50C08305.90907@oracle.com>
<50C0B490.7050005@redhat.com> <50C55F11.6020801@oracle.com>
<50C5E969.5040602@redhat.com> <50C67FF4.6050506@oracle.com>
<50C6AB79.4010606@redhat.com>
Message-ID: <50C6C212.5090203@oracle.com>
David,
Many thanks for trialling this so promptly!
Do you have any suggestions for what instrumentation you would like to
see accompany this?
David
On 11/12/2012 1:41 PM, David M. Lloyd wrote:
> On 12/10/2012 06:36 PM, David Holmes wrote:
>> On 10/12/2012 11:53 PM, David M. Lloyd wrote:
>>> On 12/09/2012 10:03 PM, David Holmes wrote:
>>>> That sounds promising. Are you in a position to try out this
>>>> proposal on
>>>> a testbed with your app server?
>>>
>>> Sure, I'd love to. What tree should I build?
>>
>> Please apply the patches from the webrevs here:
>>
>> http://cr.openjdk.java.net/~dholmes/concurrent-loaders/webrev.hotspot/
>> http://cr.openjdk.java.net/~dholmes/concurrent-loaders/webrev.jdk/
>>
>> They should apply to a jdk8 or tl forest. (And I hope I didn't mess
>> something up generating the webrev ;-) )
>
> Well, I've just gotten everything working and done some cursory testing
> on a startup of an "empty" JBoss AS 7 instance, and then reviewing the
> metrics reported by our class loader. Our timing metrics are not really
> great for general-purpose benchmarking (for various uninteresting
> reasons), but I can at least get enough information to know everything
> is working more or less as expected:
>
> On JDK 6 with our "unsafe" lockless modification, we're typically
> loading 4707 classes, and I'm seeing anywhere from 0 to 5 define races
> that were automatically resolved.
>
> On JDK 7 using the standard registerAsParallelCapable() mechanism, we
> are loading 4711 classes and I'm seeing 35-50 define races that were
> automatically resolved - the overhead of locking starts to come to the
> fore I think.
>
> On JDK 8 with your patches, we are loading around 4750 classes and there
> are, as expected, 0 define races (I believe, however, that we're getting
> a false count though whenever defineClass() returns an already-defined
> class - it would be nice if there were *some* way to detect that this
> happened).
>
> On our class loader implementations, I'm initializing this way:
>
> static {
> try {
> ClassLoader.registerAsFullyConcurrent();
> } catch (Throwable ignored) {
> try {
> ClassLoader.registerAsParallelCapable();
> } catch (Throwable ignored2) {
> }
> }
> }
>
> The debugging message confirms that our class loaders are successfully
> registered as fully concurrent, and the fact that it doesn't hang or
> crash on JDK 7 indicates that they are still properly being registered
> as parallel-capable on that platform.
>
From akhil.arora at oracle.com Tue Dec 11 05:31:08 2012
From: akhil.arora at oracle.com (Akhil Arora)
Date: Mon, 10 Dec 2012 21:31:08 -0800
Subject: RFR: 8001647: In-place methods on Collection/List
In-Reply-To: <50C658A9.30607@oracle.com>
References: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com>
<50C658A9.30607@oracle.com>
Message-ID: <50C6C51C.8080903@oracle.com>
http://cr.openjdk.java.net/~akhil/8001647.3/webrev/
- now with synchronized and unmodifiable wrappers in Collections.java
for the default methods being added
On 12/10/2012 01:48 PM, Akhil Arora wrote:
> Updated with yours and Alan's comments -
>
> http://cr.openjdk.java.net/~akhil/8001647.2/webrev/
>
> - removed null check for removeSet
> - cache this.size in removeAll, replaceAll
> (for ArrayList, Vector and CopyOnWriteArrayList)
> - calculate removeCount instead of BitCount.cardinality()
> - removed unnecessary @library from test support classes
>
> Catching IndexOOB and throwing CME in forEach/removeAll/replaceAll seems
> unecessary... did you have a use-case in mind where an IndexOOB can
> occur with these methods?
>
> Thanks
>
> On 12/08/2012 05:11 AM, Arne Siegel wrote:
>> ArrayList.java, line 1171:
>> final boolean anyToRemove = (removeSet != null) && !removeSet.isEmpty();
>> As removeSet will never be null, this line can be simplified. This is a left-over from the
>> preceding implementation (see b67).
>>
>> ArrayList.java, method forEach optimizes the loop by reducing the number of heap accesses:
>> final int size = this.size;
>> for (int i=0; modCount == expectedModCount && i < size; i++) {
>> ...
>> This trick might also be introduced to methods removeAll and replaceAll.
>>
>> In the ListIterator implementation of ArrayList, there are various appearances of the idiom:
>> try {
>> ...
>> } catch (IndexOutOfBoundsException ex) {
>> throw new ConcurrentModificationException();
>> }
>> This technique might also be used in forEach, removeAll, and replaceAll (though not likely to
>> be of any importance).
>>
>> Regards
>> Arne Siegel
>>
>
>
From peter.levart at gmail.com Tue Dec 11 08:12:24 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 11 Dec 2012 09:12:24 +0100
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To: <50C6AB79.4010606@redhat.com>
References: <50BF371A.1060604@oracle.com> <50C08305.90907@oracle.com>
<50C0B490.7050005@redhat.com> <50C55F11.6020801@oracle.com>
<50C5E969.5040602@redhat.com> <50C67FF4.6050506@oracle.com>
<50C6AB79.4010606@redhat.com>
Message-ID: <50C6EAE8.8000204@gmail.com>
On 12/11/2012 04:41 AM, David M. Lloyd wrote:
> On JDK 8 with your patches, we are loading around 4750 classes and
> there are, as expected, 0 define races (I believe, however, that we're
> getting a false count though whenever defineClass() returns an
> already-defined class - it would be nice if there were *some* way to
> detect that this happened).
Hi David,
You could, of course this would have a minor impact on the whole thing,
in your custom ClassLoader, have an instance of:
final ConcurrentMap, Boolean> foundClasses = new
ConcurrentHashMap<>();
@Override
protected Class findClass(String name) throws ClassNotFoundException {
...
...
if (foundClasses.putIfAbsent(clazz, Boolean.TRUE) != null)
races++;
return clazz;
}
Regards, Peter
From peter.levart at gmail.com Tue Dec 11 09:20:17 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 11 Dec 2012 10:20:17 +0100
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To: <50C6A09C.6000508@oracle.com>
References: <50BF371A.1060604@oracle.com> <50C27FE6.1050107@oracle.com>
<50C56053.1060306@oracle.com>
<50C6A09C.6000508@oracle.com>
Message-ID: <50C6FAD1.40506@gmail.com>
On 12/11/2012 03:55 AM, David Holmes wrote:
>> Question on the source code: registerAsFullyConcurrent has confusing
>> comment -
>> do the super classes all need to be parallel capable? Or do the super
>> classes all need
>> to be FullyConcurrent? I assume the latter, so just fix the comments.
>
> Actually it is the former. There's no reason to require that all
> superclasses be fully-concurrent. Of course a given loaders degree of
> concurrency may be constrained by what it's supertype allows, but
> there's no reason to actually force all the supertypes to be
> fully-concurrent: it is enough that they are at least all parallel
> capable.
Hi David,
There is one caveat: if ClassLoader X declares that it is
fully-concurrent and it's superclass Y is only parallel-capable, then X
will act as fully-concurrent (returning null from
getClassLoadingLock()). superclass Y might or might not be coded to use
the getClassLoadingLock(). X therefore has to know how Y is coded. To be
defensive, X could ask for Y's registration and declare itself as only
parallel-capable if Y declares the same so that when Y is upgraded to be
fully-concurrent, X would become fully-concurrent automatically. To
support situations where the same version of X would work in two
environments where in one Y is only parallel-capable and in the other Y
is fully-concurrent, there could be a static API to retrieve the
registrations of superclasses.
Or, to have less impact on future deprecation of old parallel-capable
registration API, the fully-concurrent registration API:
protected static boolean registerAsFullyConcurrent()
might take a boolean parameter:
protected static boolean registerAsFullyConcurrent(boolean downgradeToPrallelCapableIfAnySuperclassIsNotFullyConcurrent)
and provide no accessible API to find out what the registration actually
did (register as parallel-capable or fully-concurrent - return true in
any case).
Since all JDK provided ClassLoaders will be made fully concurrent, this
might only be relevant if there is vendor A that currently provides only
parallel-capable ClassLoader implementation and there is vendor B that
subclasses A's loader and wants to upgrade and be backward compatible at
the same time.
Does this complicate things to much for no real benefit?
Regards, Peter
From peter.levart at gmail.com Tue Dec 11 09:28:34 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 11 Dec 2012 10:28:34 +0100
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To: <50C6FAD1.40506@gmail.com>
References: <50BF371A.1060604@oracle.com> <50C27FE6.1050107@oracle.com>
<50C56053.1060306@oracle.com>
<50C6A09C.6000508@oracle.com> <50C6FAD1.40506@gmail.com>
Message-ID: <50C6FCC2.8080001@gmail.com>
Hi again,
There might be a middle-ground variant. No registration API changes as
described below. When ClassLoader X declares that it is fully-concurrent
make it fully-concurrent. But if any superclass registered as only
parallel-capable, provide getClassLoadingLock() locks nevertheless. Only
if all the superclasses declare that they are fully-concurrent, make no
lock map and make getClassLoadingLock() return null.
Regards, Peter
On 12/11/2012 10:20 AM, Peter Levart wrote:
> On 12/11/2012 03:55 AM, David Holmes wrote:
>>> Question on the source code: registerAsFullyConcurrent has confusing
>>> comment -
>>> do the super classes all need to be parallel capable? Or do the
>>> super classes all need
>>> to be FullyConcurrent? I assume the latter, so just fix the comments.
>>
>> Actually it is the former. There's no reason to require that all
>> superclasses be fully-concurrent. Of course a given loaders degree of
>> concurrency may be constrained by what it's supertype allows, but
>> there's no reason to actually force all the supertypes to be
>> fully-concurrent: it is enough that they are at least all parallel
>> capable.
>
> Hi David,
>
> There is one caveat: if ClassLoader X declares that it is
> fully-concurrent and it's superclass Y is only parallel-capable, then
> X will act as fully-concurrent (returning null from
> getClassLoadingLock()). superclass Y might or might not be coded to
> use the getClassLoadingLock(). X therefore has to know how Y is coded.
> To be defensive, X could ask for Y's registration and declare itself
> as only parallel-capable if Y declares the same so that when Y is
> upgraded to be fully-concurrent, X would become fully-concurrent
> automatically. To support situations where the same version of X would
> work in two environments where in one Y is only parallel-capable and
> in the other Y is fully-concurrent, there could be a static API to
> retrieve the registrations of superclasses.
>
> Or, to have less impact on future deprecation of old parallel-capable
> registration API, the fully-concurrent registration API:
>
> protected static boolean registerAsFullyConcurrent()
>
> might take a boolean parameter:
>
> protected static boolean registerAsFullyConcurrent(boolean
> downgradeToPrallelCapableIfAnySuperclassIsNotFullyConcurrent)
>
>
> and provide no accessible API to find out what the registration
> actually did (register as parallel-capable or fully-concurrent -
> return true in any case).
>
> Since all JDK provided ClassLoaders will be made fully concurrent,
> this might only be relevant if there is vendor A that currently
> provides only parallel-capable ClassLoader implementation and there is
> vendor B that subclasses A's loader and wants to upgrade and be
> backward compatible at the same time.
>
> Does this complicate things to much for no real benefit?
>
> Regards, Peter
>
From david.holmes at oracle.com Tue Dec 11 09:29:02 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 11 Dec 2012 19:29:02 +1000
Subject: Proposal: Fully Concurrent ClassLoading
In-Reply-To: <50C6FAD1.40506@gmail.com>
References: <50BF371A.1060604@oracle.com> <50C27FE6.1050107@oracle.com>
<50C56053.1060306@oracle.com>