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 it
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
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
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,
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
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, the
On 01/14/2013 04:06 PM, Paul Sandoz wrote:
On Jan 14, 2013, at 3:38 PM, Peter Levart peter.lev...@gmail.com 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
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
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
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
!
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
!
On Mon, Jan 14, 2013 at 10:20 AM, Chris Hegarty
chris.hega...@oracle.com 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).
On Mon, Jan 14, 2013 at 12:15 PM, Aleksey Shipilev
aleksey.shipi...@oracle.com 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.
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/
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
!
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
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
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 :(
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
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
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
On 14 Jan 2013, at 22:33, Aleksey Shipilev aleksey.shipi...@oracle.com 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
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
On 01/15/2013 02:47 AM, Chris Hegarty wrote:
On 14 Jan 2013, at 22:33, Aleksey Shipilev aleksey.shipi...@oracle.com
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
On 14 Jan 2013, at 22:53, Aleksey Shipilev aleksey.shipi...@oracle.com wrote:
On 01/15/2013 02:47 AM, Chris Hegarty wrote:
On 14 Jan 2013, at 22:33, Aleksey Shipilev aleksey.shipi...@oracle.com
wrote:
On 01/15/2013 02:17 AM, Alan Bateman wrote:
The other thing I notice is that the
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
sPF
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 aleksey.shipi...@oracle.com wrote:
On 01/15/2013 02:58 AM, Chris Hegarty wrote:
serialPersistentFields is really quite simple, and
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,
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
!
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 rob.mcke...@oracle.com wrote:
Simple enough fix but to be honest I'm not sure any value
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.
On Mon, Jan 14, 2013 at 5:31 PM, David Holmes david.hol...@oracle.com 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
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
33 matches
Mail list logo
