hg: jdk8/tl/jdk: 8006265: Add test SSLEngineDeadlock.java to ProblemList

Changeset: edb7e34a0531 Author:xuelei Date: 2013-01-14 18:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/edb7e34a0531 8006265: Add test SSLEngineDeadlock.java to ProblemList Reviewed-by: weijun ! test/ProblemList.txt

Re: Request for review: 8005618 - TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently

On Mon, Jan 14, 2013 at 5:31 PM, David Holmes wrote: > On 15/01/2013 7:12 AM, Rob McKenna wrote: >> >> Simple enough fix but to be honest I'm not sure any value will *always* >> work for the dead process waitFor(). Our testing infrastructure seems to >> glide past whatever we consider to be accept

Re: Request for review: 8005618 - TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently

On 15/01/2013 7:12 AM, Rob McKenna wrote: Simple enough fix but to be honest I'm not sure any value will *always* work for the dead process waitFor(). Our testing infrastructure seems to glide past whatever we consider to be acceptable tolerances. http://cr.openjdk.java.net/~robm/8005618/webrev.

Re: Request for review: 8005618 - TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently

Looks good! Mea culpa for some of those slow and flaky sleeps in this code, although they are tricky to avoid - there is no cross-process latches, for example. On Mon, Jan 14, 2013 at 1:12 PM, Rob McKenna wrote: > Simple enough fix but to be honest I'm not sure any value will *always* work > for

hg: jdk8/tl/jdk: 8005252: pack200 should support MethodParameters

Changeset: dcb64d498d5b Author:ksrini Date: 2013-01-14 15:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dcb64d498d5b 8005252: pack200 should support MethodParameters Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

On 01/14/13 17:58, Chris Hegarty wrote: I'm not sure what we are saving here. Since new TLR is a singleton, we save ~64 bytes per classloader. Worth messing with advanced serialization mechanics? Probably not. I'll publish a revised webrev soon. serialPersistentFields is really quite simple, a

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

Yeah, that's what I meant in my earlier post. It keeps the serial format compatible with little impact on performance in this case. On 15/01/2013, Aleksey Shipilev wrote: > On 01/15/2013 02:58 AM, Chris Hegarty wrote: >> serialPersistentFields is really quite simple, and will help avoid >> any p

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

On 01/15/2013 02:58 AM, Chris Hegarty wrote: > serialPersistentFields is really quite simple, and will help avoid > any potential issues like this in the future. I can help implement > this on top of your patch if you like. Oh, please go ahead. That's the learning opportunity for me (never used sP

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

On 14 Jan 2013, at 22:53, Aleksey Shipilev wrote: > On 01/15/2013 02:47 AM, Chris Hegarty wrote: >> >> On 14 Jan 2013, at 22:33, Aleksey Shipilev >> wrote: >> >>> On 01/15/2013 02:17 AM, Alan Bateman wrote: The other thing I notice is that the serialized form of the original Thread

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

On 01/15/2013 02:47 AM, Chris Hegarty wrote: > > On 14 Jan 2013, at 22:33, Aleksey Shipilev > wrote: > >> On 01/15/2013 02:17 AM, Alan Bateman wrote: >>> The other thing I notice is that the serialized form of the original >>> ThreadLocalRandom included the padding fields, I guess they should h

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

On 01/15/2013 02:36 AM, Dr Heinz M. Kabutz wrote: > The padded fields are interesting, as in Java 7 they would quite > possibly be optimized away or at least rearranged, no? At my level of HotSpot knowledge I find this very unlikely. Once the class is loaded, it's layout is finalized. That pretty

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

On 14 Jan 2013, at 22:33, Aleksey Shipilev wrote: > On 01/15/2013 02:17 AM, Alan Bateman wrote: >> The other thing I notice is that the serialized form of the original >> ThreadLocalRandom included the padding fields, I guess they should have >> been transient in the original implementation. >

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

Agreed. But I think just faking it with the plain fields is less error-prone. The memory overhead is somewhat 8x8 = 64 bytes per JVM instance. -Aleksey. On 01/15/2013 02:40 AM, Dr Heinz M. Kabutz wrote: > We can probably fake the serialized form with some field descriptors > and a writeObject and

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

We can probably fake the serialized form with some field descriptors and a writeObject and readObject method. Then we can keep the format exactly the same as previously. The serialized form should not stop us from optimizing this very important class. Just my 2c On 15/01/2013, Aleksey Shipilev

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

The padded fields are interesting, as in Java 7 they would quite possibly be optimized away or at least rearranged, no? My own tests certainly suggested this. Probably a case for @Contended? Also, do you intend on moving the padding fields over to Thread too? Other than my questions about paddi

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

On 01/15/2013 02:17 AM, Alan Bateman wrote: > The other thing I notice is that the serialized form of the original > ThreadLocalRandom included the padding fields, I guess they should have > been transient in the original implementation. Damn. These *are* the part of TLR serialized form :( http://

hg: jdk8/tl/langtools: 8006241: Test DocRootSlash.java fails

Changeset: d54b4a091450 Author:jjg Date: 2013-01-14 14:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d54b4a091450 8006241: Test DocRootSlash.java fails Reviewed-by: darcy ! test/com/sun/javadoc/DocRootSlash/DocRootSlash.java

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

On 14/01/2013 18:20, Chris Hegarty wrote: Ooh this change goes beyond my review capability!!! I thought we were just eliminating the indirection of ThreadLocal, anyway... As a basic review I don't see anything obviously wrong, and I don't have a problem with adding the fields to j.l.Th

hg: jdk8/tl/langtools: 8006119: update javac to follow latest spec for repeatable annotations

Changeset: df694c775e8a Author:jjg Date: 2013-01-14 13:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/df694c775e8a 8006119: update javac to follow latest spec for repeatable annotations Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Annotations.java

Request for review: 8005618 - TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently

Simple enough fix but to be honest I'm not sure any value will *always* work for the dead process waitFor(). Our testing infrastructure seems to glide past whatever we consider to be acceptable tolerances. http://cr.openjdk.java.net/~robm/8005618/webrev.01/

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

On Mon, Jan 14, 2013 at 12:15 PM, Aleksey Shipilev wrote: > I'm not sure I'm listed as reviewer by OpenJDK census. If that does not > matter, then yes, count me as the reviewer :) OpenJDK should give Aleksey some reviewer bits, but I don't know how that happens.

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

On 01/15/2013 12:09 AM, Chris Hegarty wrote: > > On 14 Jan 2013, at 20:01, Martin Buchholz > wrote: > >> On Mon, Jan 14, 2013 at 10:20 AM, Chris Hegarty >> wrote: >>> Ooh this change goes beyond my review capability!!! >> >> We don't really need another one, since we already have Alek

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

On 14 Jan 2013, at 20:01, Martin Buchholz wrote: > On Mon, Jan 14, 2013 at 10:20 AM, Chris Hegarty > wrote: >> Ooh this change goes beyond my review capability!!! > > We don't really need another one, since we already have Aleksey and Doug, > right? I wasn't sure if Aleksey was volun

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

On Mon, Jan 14, 2013 at 10:20 AM, Chris Hegarty wrote: > Ooh this change goes beyond my review capability!!! We don't really need another one, since we already have Aleksey and Doug, right? We should cc: Doug on threads like this (even though he is on the list).

hg: jdk8/tl/jdk: 7162007: Clean up i18n related caches

Changeset: 1d7a6adf499f Author:naoto Date: 2013-01-14 11:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d7a6adf499f 7162007: Clean up i18n related caches Reviewed-by: okutsu, ohair ! make/java/java/FILES_java.gmk ! src/share/classes/java/text/DateFormatSymbols.java ! src

hg: jdk8/tl/langtools: 7193719: Support repeating annotations in javax.lang.model

Changeset: 9f42a06a49c0 Author:jfranck Date: 2013-01-14 19:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9f42a06a49c0 7193719: Support repeating annotations in javax.lang.model Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/cl

Re: RFR: javax.xml.validation: Using ServiceLoader to load JAXP schema factories (7169894: JAXP Plugability Layer: using service loader)

On 11/01/2013 19:14, Daniel Fuchs wrote: Although it seems cleaner to use a SchemaFactoryConfigurationError, we could wrap the ServiceConfigurationError in an IllegalArgumentException - which is what would have eventually been thrown in the old code. If that seems like a safer strategy I could

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

Ooh this change goes beyond my review capability!!! I thought we were just eliminating the indirection of ThreadLocal, anyway... As a basic review I don't see anything obviously wrong, and I don't have a problem with adding the fields to j.l.Thread, but I'm not in a position to review

Re: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder

On Jan 14, 2013, at 4:47 PM, Peter Levart wrote: > On 01/14/2013 04:06 PM, Paul Sandoz wrote: >> On Jan 14, 2013, at 3:38 PM, Peter Levart wrote: >> >>> I think these classes are targeted at use cases such as gathering real-time >>> statistics of profiling or business data, where data comes i

Re: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder

On 01/14/2013 04:06 PM, Paul Sandoz wrote: On Jan 14, 2013, at 3:38 PM, Peter Levart wrote: I think these classes are targeted at use cases such as gathering real-time statistics of profiling or business data, where data comes in from various sources in real-time and statistics are sampled i

Re: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder

On 01/14/2013 06:38 PM, Peter Levart wrote: > I think these classes are targeted at use cases such as gathering > real-time statistics of profiling or business data, where data comes in > from various sources in real-time and statistics are sampled in > real-time too... > > For bulk processing,

Re: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder

On Jan 14, 2013, at 3:38 PM, Peter Levart wrote: > I think these classes are targeted at use cases such as gathering real-time > statistics of profiling or business data, where data comes in from various > sources in real-time and statistics are sampled in real-time too... > > For bulk proces

Re: RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder

I think these classes are targeted at use cases such as gathering real-time statistics of profiling or business data, where data comes in from various sources in real-time and statistics are sampled in real-time too... For bulk processing, the new streams API seems more appropriate. I think t

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

For what it is worth, it is on my list for today. -Chris. On 14/01/2013 13:31, Aleksey Shipilev wrote: I understand everyone is busy with JDK8 milestone, but maybe some critical people have missed this note? It would be terrific if someone could review this (or even sponsor it!). Thanks, Aleks

Re: RFR (S): CR 8005926: (thread) Merge ThreadLocalRandom state into java.lang.Thread

I understand everyone is busy with JDK8 milestone, but maybe some critical people have missed this note? It would be terrific if someone could review this (or even sponsor it!). Thanks, Aleksey. On 01/11/2013 02:31 AM, Aleksey Shipilev wrote: > Hi, > > Submitting this on behalf of Doug Lea. The

Re: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl

Yes sorry if that was not clear but that is my plan with the ccc and javadoc update I will get the JBS entry and ccc submitted later today and make a few of the minor suggestions from ulf and push out the revised webrev later today or Tuesday Best Lance Lance Andersen| Principal Member of Te

Re: review request 8006139, add missing methods to javax.sql.rowset.serial.SQLInput/OutputImpl

On 13/01/2013 23:51, Lance Andersen - Oracle wrote: : One other thing is that the CCE has a side-effect in that it "consumes" the next attribute. The methods could be changed to peek at the next attribute but that wouldn't work without synchronization or making it clear in the spec that the i

Re: RFR (XS): CR 8003985: Support @Contended annotation

On 13/01/2013 23:23, David Holmes wrote: On 14/01/2013 4:30 AM, Vladimir Kozlov wrote: Thank you, Alan I already pushed it into hotspot/jdk: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9d5c43050210 We will promote it as we did before with similar changes together with Hotspot changes.