On 07/15/2013 04:36 PM, Peter Levart wrote:
I was guided by the Collection.contains() signature:
CollectionT {
boolean contains(Object o);
Dunno. This was done for compatibility with non-generic code. In your
code, you seem always know the type of the argument, it does not bother
me to
On 07/15/2013 05:43 PM, Peter Levart wrote:
On 07/15/2013 03:02 PM, Aleksey Shipilev wrote:
The results are here [2]. Notable results follow.
Somehow the files in the directories under:
http://cr.openjdk.java.net/~shade/8020292/data/
... are not accessible (403 - Forbidden), although
(I've been distracted by other high priority stuff, and only starting to
explore SR, sorry for dumb questions below)
On 07/11/2013 04:16 PM, Doug Lea wrote:
(I've been contemplating re-exploring alternatives in TLR,
but the options are more limited because it is a subclass
of Random. Which
(juggling an Occam's razor)
Hi Doug,
On 10.07.2013, at 23:13, Doug Lea d...@cs.oswego.edu wrote:
This post serves as a request for comment, with shorter than usual
turnaround (a couple of days) before considering a request to
integrate into OpenJDK 8. So, please take a look.
I've glanced
On 06/28/2013 10:24 PM, Brian Burkhalter wrote:
http://cr.openjdk.java.net/~bpb/8017540/
Thumbs up.
-Aleksey.
N.B.: You can put me in with Reviewed-by: shade.
On 07/01/2013 02:05 PM, Thomas Schatzl wrote:
Fyi, while waiting for your approval, I tried to clean up this a little
taking into account the comments from Peter and Aleksey (sorry if I
forgot somebody) into account.
Mandy Chung?
A webrev for this is at
On 07/01/2013 03:37 PM, David Holmes wrote:
On 1/07/2013 8:14 PM, Aleksey Shipilev wrote:
The same thou shalt not do multiple volatile reads applies to
(r.queue == NULL) || (r.queue == ENQUEUED) now.
Doesn't that just reduce to r.queue != this ? (The assert suggests
so :) )
Thomas
On 07/01/2013 03:51 PM, Thomas Schatzl wrote:
Hi all,
On Mon, 2013-07-01 at 15:44 +0400, Aleksey Shipilev wrote:
On 07/01/2013 03:37 PM, David Holmes wrote:
On 1/07/2013 8:14 PM, Aleksey Shipilev wrote:
The same thou shalt not do multiple volatile reads applies to
(r.queue == NULL
On 06/27/2013 10:37 AM, Peter Levart wrote:
Hi,
This version seems correct. Maybe just replace double volatile read at
length re-check with a single one:
private static BigInteger getRadixConversionCache(int radix, int
exponent) {
BigInteger[] cacheLine = powerCache[radix];
On 26.06.2013, at 7:31, Dmitry Nadezhin dmitry.nadez...@gmail.com wrote:
We have two versions after private discussion with Aleksey.
BigInteger getRadixConversionCache(int radix, int exponent) {
BigInteger[][] pc = powerCache; // volatile read
BigInteger[] cacheLine = pc[radix];
if
].square();
if (exponent = powerCache[radix].length) { // volatile read again
BigInteger[][] pc = Arrays.copyOf(powerCache);
pc[radix] = cacheLine;
powerCache = pc; // volatile write, publish
}
return cacheLine[exponent];
}
On Wed, Jun 26, 2013 at 10:31 AM, Aleksey Shipilev
On 06/25/2013 03:53 AM, Brian Burkhalter wrote:
http://cr.openjdk.java.net/~bpb/8017540/
Thanks! Looks good to me.
Rather minor silly nit:
cacheLine = Arrays.copyOf(cacheLine, exponent + 1);
for (int i = oldSize; i = exponent; i++) {
...is probably more consistent as:
cacheLine =
On 06/17/2013 01:00 PM, Aleksey Shipilev wrote:
This is the respin of the RFE filed a month ago:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016754.html
The webrev is here:
http://cr.openjdk.java.net/~shade/8014233/webrev.02/
The changeset is here:
http
On 06/25/2013 08:29 PM, Brian Burkhalter wrote:
Hi Aleksey,
On Jun 25, 2013, at 1:40 AM, Aleksey Shipilev wrote:
Thanks! Looks good to me.
Cool!
Hold on now. Similar to what Peter suggests in the separate thread,
there is the data race between 3458 and 3466:
3455 private static
On 06/25/2013 11:36 PM, Dmitry Nadezhin wrote:
What about such code ?
BigInteger getRadixConversionCache(int radix, int exponent) {
BigInteger retVal = null;
BigInteger[][] pc = powerCache; // volatile read
BigInteger[] cacheLine = pc[radix];
int oldSize = cacheLine.length;
if
On 06/26/2013 12:34 AM, Peter Levart wrote:
On 06/25/2013 09:50 PM, Aleksey Shipilev wrote:
On 06/25/2013 11:38 PM, Peter Levart wrote:
On 06/25/2013 09:12 PM, Aleksey Shipilev wrote:
It might be a good idea to turn $powerCache final, not volatile, since
the code will recover anyway
On 06/26/2013 12:56 AM, Peter Levart wrote:
Sorry, you are storing back when resizing. And you are resizing for
every exponent that is bigger that previous requested (cached). This can
lead to many resizings.
Dmitry had suggested going back to square one with his approach. I'll
let him post
Forgot to reply: I'm ok with webrev.01.
-Aleksey
(rural r reviewer)
On 06/24/2013 11:20 PM, Eric McCorkle wrote:
Pinging this RFR. It still needs a capital R reviewer.
http://cr.openjdk.java.net/~emc/8016285/
On 06/21/13 19:21, Eric McCorkle wrote:
On 06/21/13 16:15, Aleksey Shipilev
On 06/22/2013 08:06 AM, Dmitry Nadezhin wrote:
Alexey,
Each possible radix has its cacheLine in the cache.
Cache contents looks like
BigInteger[][] powerCache = new BigInteger[37] {
/*0*/ null,
/*1*/ null,
/*2*/ new BigInteger[] { 2, 4, 16, 256, 32768, ... },
/*3*/ new BigInteger[] {
On 06/22/2013 02:50 PM, Aleksey Shipilev wrote:
On 06/22/2013 08:06 AM, Dmitry Nadezhin wrote:
Alexey,
Each possible radix has its cacheLine in the cache.
Cache contents looks like
BigInteger[][] powerCache = new BigInteger[37] {
/*0*/ null,
/*1*/ null,
/*2*/ new BigInteger[] { 2, 4, 16
On 06/21/2013 07:04 PM, Brian Burkhalter wrote:
On Jun 21, 2013, at 2:49 AM, Alan Bateman wrote:
One part that might need attention is getRadixConversionCache as I
could imagine cases where the synchronization could lead to
contention. Have you (or Alan) considered alternatives that would
On 06/21/2013 11:57 PM, Eric McCorkle wrote:
The webrev is here:
http://cr.openjdk.java.net/~emc/8016285/
Looks generally good (but not a Reviewer).
A few questions though:
a) Are we em-bracing the brace-less control flow blocks?
b) Should hasRealParameterData be transient?
c) Should
On 06/19/2013 04:05 PM, David Holmes wrote:
I think I'm going to need a lot more time to understand this issue
completely. The synchronization being used seems complex and
somewhat ill-defined, and also inadequate. I'm not convinced that
adding code inside a synchronized block really fixes a
On 06/19/2013 06:09 PM, Thomas Schatzl wrote:
With that notion in mind, I start to wonder if we just need to move the
check in enqueue() down into the synchronized(lock), and extend it to
capture NULL:
--- a/src/share/classes/java/lang/ref/ReferenceQueue.javaMon Jun 17
16:28:22 2013
On 06/16/2013 11:44 PM, Alan Bateman wrote:
On 13/06/2013 12:47, Aleksey Shipilev wrote:
Friendly reminder for the reviewers.
On 06/10/2013 07:53 PM, Aleksey Shipilev wrote:
This is the follow-up on the issue Doug identified:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June
Hi,
This is the respin of the RFE filed a month ago:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016754.html
The webrev is here:
http://cr.openjdk.java.net/~shade/8014233/webrev.02/
Testing:
- JPRT build passes
- Linux x86_64/release passes jdk/java/lang jtreg
-
On 06/17/2013 02:20 PM, Peter Levart wrote:
Sorry, Aleksey, just a nit: In getInterfaces(), the method could be
written using a single volatile read from ReflectionData.interfaces
field instead of two (by introducing local variable).
Yes, thanks! Nothing to be sorry of, I'll cover this.
On 06/17/2013 05:22 PM, Alan Bateman wrote:
For the jdk repository then only one reviewer with reviewer role is
required. I see you have Peter and Paul listed in a Reviewed-by line so
I think we are good. Do you want Doug listed too as this started out as
a patch from Doug.
Ouch! My bad. Doug
Thanks! I do need a sponsor.
-Aleksey.
On 06/17/2013 04:52 PM, Chris Hegarty wrote:
Looks fine to me Aleksey.
Let me know if you need a sponsor.
-Chris.
On 17/06/2013 10:00, Aleksey Shipilev wrote:
Hi,
This is the respin of the RFE filed a month ago:
http
On 06/17/2013 05:33 PM, Doug Lea wrote:
On 06/17/13 09:25, Aleksey Shipilev wrote:
Ouch! My bad. Doug had not reviewed the final patch, and the final patch
is significantly different from the original one. Do we still want to
put Doug to Contributed-by, or is there some other tag useful
Hi Anubhav,
On 16.06.2013, at 14:53, Anubhav Chaturvedi mailforanub...@gmail.com wrote:
I would like to bring the required changes and needed your advice on this.
Welcome to OpenJDK!
Please read through OpenJDK contributors page for the process we follow:
http://openjdk.java.net/contribute/
Friendly reminder for the reviewers.
On 06/10/2013 07:53 PM, Aleksey Shipilev wrote:
This is the follow-up on the issue Doug identified:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017798.html
I had reworked the patch, webrev is here:
http://cr.openjdk.java.net/~shade
On 06/13/2013 09:51 PM, Christian Thalinger wrote:
While preparing the push I noticed the new code gives a warning:
src/share/classes/java/lang/invoke/MethodType.java:1106: warning: [unchecked]
unchecked cast
T that = ((WeakEntryT) obj).get();
On 06/12/2013 12:32 AM, Brent Christian wrote:
The webrev is here:
http://cr.openjdk.java.net/~bchristi/8010325/webrev.00/
Looks good.
Minor nit: (0 != seed), do we really want operands flipped?
-Aleksey.
On 06/12/2013 10:27 PM, Steven Schlansker wrote:
Thank you everyone for the valuable input!
On Jun 11, 2013, at 1:52 AM, Aleksey Shipilev
aleksey.shipi...@oracle.com wrote:
On 06/11/2013 12:31 PM, Remi Forax wrote:
On 06/10/2013 08:06 PM, Steven Schlansker wrote: Hi Steven, the
main
On 06/11/2013 02:52 AM, Christian Thalinger wrote:
This looks good to me.
Thanks for the review!
Could you run RegExp with Nashorn again with and without your changes?
Being single-threaded, the benchmark will not show much of the
improvement. Also, the results are rather flaky.
Before:
On 06/11/2013 12:31 PM, Remi Forax wrote:
On 06/10/2013 08:06 PM, Steven Schlansker wrote:
Hi Steven,
the main issue is that intern() doesn't work in isolation,
I think it's better to change the JSON Parser implementation to use it's
own cache (or not) and not rely on String.intern().
+1.
On 06/11/2013 01:31 AM, Peter Levart wrote:
While you're at it adding getInterfaces() cache, why not also
getSuperclass()? Is it maybe already intrinsified?
Yes, the C2 code and benchmarking shows it is already an intrinsic.
-Aleksey.
Hi Peter,
On 06/11/2013 12:57 AM, Peter Levart wrote:
When 'sun.reflect.noCaches=true' system property is defined,
reflectionData() returns null. In that case, the code should cope
without using ReflectionData (no caching). See other uses of
reflectionData() (for example: in
On 06/11/2013 03:27 PM, Peter Levart wrote:
The new webrev is here:
http://cr.openjdk.java.net/~shade/8016236/webrev.02/
That's good now.
Thanks!
I just wonder if renaming of native getGenericSignature -
getGenericSignature0 is still needed now that there's no
getGenericSignature
On 06/11/2013 07:43 PM, Christian Thalinger wrote:
Thanks for this but I was thinking running it with -Xprof to see
whether some of the table methods show up on the profile.
I put little trust into this kind of profiling, but here's the sample
output from JMH -prof stack, while running with 4
On 06/11/2013 07:58 PM, David Chase wrote:
On 2013-06-10, at 11:53 AM, Aleksey Shipilev aleksey.shipi...@oracle.com
wrote:
o.b.ClassBench.generic_getGenericSuperclass avgt 1 51
5.3000.008 nsec/op
Am I reading this correctly? 0.008 nsec/op means 125
On 06/11/2013 08:06 PM, Christian Thalinger wrote:
Anyway, let's push this.
Do you want me any other testing done? vm.mlvm.testlist is OK, but I
haven't done the full JPRT test cycle, only the build one.
-Aleksey.
On 06/11/2013 10:24 PM, Christian Thalinger wrote:
On Jun 11, 2013, at 9:08 AM, Aleksey Shipilev aleksey.shipi...@oracle.com
wrote:
On 06/11/2013 08:06 PM, Christian Thalinger wrote:
Anyway, let's push this.
Do you want me any other testing done? vm.mlvm.testlist is OK, but I
haven't
On 08.06.2013, at 23:51, Aleksey Shipilev aleksey.shipi...@oracle.com wrote:
Hm, sounds interesting.
What's about yet another factory-like default in Comparator:
ComparatorC Comparator.make(ClassC klass)
- returns synthetic comparator using C.compareTo iff C implements
ComparableC
Hi,
This is the follow-up on the issue Doug identified:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017798.html
I had reworked the patch, webrev is here:
http://cr.openjdk.java.net/~shade/8016236/webrev.01/
Notable differences from Doug's version are:
- handle
Hm, sounds interesting.
What's about yet another factory-like default in Comparator:
ComparatorC Comparator.make(ClassC klass)
- returns synthetic comparator using C.compareTo iff C implements
ComparableC
- returns null otherwise
That will naively instantiate the Comparator, but there is
Thanks for taking a look, Paul!
Can I count your review as official?
On 06/10/2013 08:44 PM, Paul Sandoz wrote:
- reuse ReflectionData to cache the interfaces and generic signatures
Any guess on the size impact due to those new fields in ReflectionData?
Seems to be additional 16 bytes
(copying hotspot-dev@ back, the patch is theirs)
Thanks Remi!
On 06/08/2013 02:21 PM, Remi Forax wrote:
in add, the do/while does something a little weird, if putIfAbsent
returns null, interned is equals to elem, there is no need to do a
e.get() in that case,
Oh yes, that a nice
(posting this to hotspot-dev@ and cc-ing core-libs-dev@, as Christian T.
suggested offline)
Hi guys,
The fix for scalability problem is here:
http://cr.openjdk.java.net/~shade/7177472/webrev.00/
Testing:
- Linux x86_64 builds OK
- Linux x86_64 java/lang/invoke/ jtreg passes OK
Since this
On 06/06/2013 01:44 PM, Alan Bateman wrote:
On 06/06/2013 10:38, Aleksey Shipilev wrote:
Hi guys,
What is the process to back port the issue to 7u?
Specifically, I think we need to have this issue backported:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132378
-Aleksey
Looks good to me.
-Aleksey.
On 06/05/2013 02:42 PM, Chris Hegarty wrote:
Just some minor cleanup after the integration of CHMv8. Trivially, add
@since 1.8 tags to the 34 new methods and 1 new class in ConcurrentHashMap.
On 06/05/2013 07:13 PM, Brian Burkhalter wrote:
Hi Sergey,
Aleksey :)
b) the annotations you are using on each method, can flow up to
class-level annotation, and will be inherited by all the @GMB methods;
I was not aware of this.
Yes, and with the daizy-fresh JMH, it is even possible to
On 06/04/2013 04:27 AM, Brian Burkhalter wrote:
A) Is there some particular approach that should be used in testing
these algorithms for relative performance?
The number one approach is peer review. Is there the JMH project with
microbenchmarks somewhere? Sergey (cc'ed) knows a lot about
On 05/31/2013 07:44 PM, Aleksey Shipilev wrote:
[The fields in the same contention group may not be pair-wise isolated]
Added this to the relevant section. Please see the webrev:
http://cr.openjdk.java.net/~shade/8014966/webrev.05/
Martin, David, Mike, please take a final look!
-Aleksey.
On 06/03/2013 09:33 PM, Martin Buchholz wrote:
Looks Good To Me.
Thanks guys! Please sponsor. :)
The changeset is here:
http://cr.openjdk.java.net/~shade/8014966/8014966.changeset
-Aleksey.
Thanks!
On 06/03/2013 10:29 PM, Mike Duigou wrote:
OK, I've got this covered. Will push it to jdk8/tl shortly.
Mike
On Jun 3 2013, at 11:10 , Aleksey Shipilev wrote:
On 06/03/2013 09:33 PM, Martin Buchholz wrote:
Looks Good To Me.
Thanks guys! Please sponsor. :)
The changeset
Thanks Mike!
The updated webrev is here:
http://cr.openjdk.java.net/~shade/8014966/webrev.04/
I think the changes we are doing now are converging. I would like to
hear formal OKs from Martin B, Mike D, David H, so we can proceed with
pushing this. Last-minute grammar corrections welcome!
Hi Peter,
On 05/31/2013 11:33 AM, Peter Levart wrote:
Implementation issues aside, the name of the tag specified in the
@Contended annotation could be evaluated in the context of the fully
qualified class name in which the annotation is used. For example:
I thought about implying the
On 05/29/2013 11:29 PM, Martin Buchholz wrote:
Looks good enough to me for a non-public API. I expect more contentious
arguments if this is ever made public, since the problems remain very
tricky.
Yes, that's why we want to keep it internal for now.
I'd like to hear the final yes from David
On 05/30/2013 12:49 PM, Aleksey Shipilev wrote:
On 05/29/2013 10:48 PM, roger riggs wrote:
Has it been considered that highly contended field should not be allocated
in the object itself anyway but in some pool or structure better suited
to its access characteristics? A read-only indirection
Hi Roger,
On 05/29/2013 10:48 PM, roger riggs wrote:
Thanks for the references. Currently, you are correct, I don't need it.
Now I am envious!
Has it been considered that highly contended field should not be allocated
in the object itself anyway but in some pool or structure better suited
Thanks for the review!
On 05/29/2013 04:28 AM, Martin Buchholz wrote:
Yeah, we have the same problem with javadoc issuing very verbose
warnings. I've been ignoring/filtering them and hoping they get fixed
before jdk8 ships.
Ok, reverted back to p.
+ * in concurrent contexts in which
Hi Roger,
On 05/29/2013 09:12 PM, roger riggs wrote:
I'm not sure I quite understand the purpose or semantics of this
annotation.
That's the early sign you don't need it! :) I'm actually envious.
Since it is in sun.misc, it may not be so important and is just an
implementation artifact but
Hi David,
On 05/28/2013 04:11 AM, David Holmes wrote:
Okay I have some suggested rewordings below and a couple of grammatical
corrections.
Thank you! The updated webrev is here:
http://cr.openjdk.java.net/~shade/8014966/webrev.02/
Changes from the David's version:
* added the provisioning
On 05/29/2013 12:38 AM, Martin Buchholz wrote:
Tricky stuff!
You bet! Thanks for the review! I'll wait for more reviews, and update
the webrev.
We don't use closing html tags for things like p in javadoc.
Ok, JDK 8 doclint does not like self-closing entities, and leaving
unterminated p seems
Thanks!
Let's try to re-phrase this as follows (don't mind Javadoc formatting
glitches, I'll fix them in the upcoming webrev):
- 8 --
/*
An annotation expressing that objects and/or their fields are
expected to encounter memory
On 05/23/2013 07:57 PM, Peter Levart wrote:
Have I understood this correctly?
Yes. @Contended on class is currently the shorthand for the @Contended
with the same (but unknown) tag over all the fields. However, in future
this might change, because @Contended on class might also guard the
object
On 05/23/2013 06:33 PM, Mike Duigou wrote:
A class level annotation on a class containing no annotated fields
has no effect, correct?
It does have the effect, see the last paragraph in the Javadoc. Should
we refine this a bit?
-Aleksey.
.
On 05/23/2013 08:20 PM, Mike Duigou wrote:
You could add one more sentence to cover the effect of @C on class
with no @C on any field. The response to Peter is great info (but too
much detail for JavaDoc).
Mike
On May 23 2013, at 09:17 , Aleksey Shipilev wrote:
On 05/23/2013 06:33 PM, Mike
Also, let's wait for David Holmes to glance over it. He has the immense
capability to spot the weaknesses in the specifications.
-Aleksey.
On 05/23/2013 08:47 PM, Aleksey Shipilev wrote:
Ummm... I think that's exactly what the last paragraph says. What if we
rephrase it as follows
-level. What does the following do?
@Contended(x)
class C {
@Contended(x) int a;
@Contended(y) int b;
int c;
}
Regards, Peter
On 05/23/2013 06:16 PM, Aleksey Shipilev wrote:
On 05/23/2013 07:57 PM, Peter Levart wrote:
Have I understood this correctly?
Yes. @Contended
Hi,
It is time to add the proper Javadoc to @Contended:
http://cr.openjdk.java.net/~shade/8014966/webrev.01/
Testing:
- built jdk8-tl on Linux x86_64/release without a hitch.
Please review and sponsor!
Thanks,
-Aleksey.
On 10.05.2013, at 16:17, Doug Lea d...@cs.oswego.edu wrote:
On 05/09/13 10:19, Peter Levart wrote:
Hi Aleksey,
Wouldn't it be even better if just threadLocalRandom* fields were annotated
with
@Contended(ThreadLocal) ?
Some fields within the Thread object are accessed from non-local
On 05/10/2013 05:27 PM, Aleksey Shipilev wrote:
Although I just tried what Peter had suggested, and got even more
boost on my microbenchmark. This counter-intuitive for me, since no
memory layout differences could explain this in my tests. I will have
to untangle this today, hold on.
Ok, I
On 05/09/2013 01:39 PM, David Holmes wrote:
Well the code change is easy enough to review :)
Ha! Bike-shed opportunity: to use fully quailified class name in the
annotation, or not. (I'm following the suit for j.u.c.ForkJoinPool and
friends).
As to the effects ... no way to judge that: time
On 05/09/2013 02:15 PM, David Holmes wrote:
On 9/05/2013 7:53 PM, Aleksey Shipilev wrote:
On 05/09/2013 01:39 PM, David Holmes wrote:
Well the code change is easy enough to review :)
Ha! Bike-shed opportunity: to use fully quailified class name in the
annotation, or not. (I'm following
Hi,
This is from our backlog after JDK-8005926. After ThreadLocalRandom
state was merged into Thread, we now have to deal with the false sharing
induced by heavily-updated fields in Thread. TLR was padded before, and
it should make sense to make Thread bear @Contended annotation to
isolate its
On 04/27/2013 11:37 AM, Alan Bateman wrote:
On 27/04/2013 00:13, Mandy Chung wrote:
Peter,
I have pushed the changeset:
Changeset: 5e7ae178b24d
Author:plevart
Date: 2013-04-26 16:09 -0700
URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e7ae178b24d
Mandy
This is great work,
On 03/05/2013 10:08 AM, Mike Duigou wrote:
http://cr.openjdk.java.net/~mduigou/JDK-8006593/4/webrev/
Looks good. (Not a reviewer by OpenJDK Census)
Peter has a nice suggestion about useAltHashing.
-Aleksey.
On 02/26/2013 01:46 AM, Chris Hegarty wrote:
[ Subject: 8006409: ThreadLocalRandom should drop padding fields
from its serialized form (was: Re: RFR (S): CR 8005926: (thread)
Merge ThreadLocalRandom state into java.lang.Thread) ]
I think we are in agreement that the pad fields can safely
+1. Appending char is marginally faster as well.
-Aleksey.
On 02.02.2013, at 2:07, Vitaly Davidovich vita...@gmail.com wrote:
I'm with Louis on this one. Since you're changing this code anyway, I
don't see any reason to use string here.
Sent from my phone
On Feb 1, 2013 4:45 PM, Joe
On 01/28/2013 03:32 PM, Chris Hegarty wrote:
StampedLock, as usual, is coming from Doug Lea, with assistance from
members of the former JCP JSR-166 Expert Group. Aleksey Shipilev, Dave
Dice, and I, have all informally reviewed this, and our feedback is
already incorporated in this version.
I
On 01/28/2013 03:32 PM, Chris Hegarty wrote:
Webrev:
http://cr.openjdk.java.net/~chegar/8005697/ver.00/webrev/webrev/
The only nit I find unlucky is that we need to duplicate the TLR code in
LockSupport. It looks like we would be better off with the helper class
sharing this functionality. I
On 01/25/2013 08:02 PM, Peter Levart wrote:
On 01/25/2013 06:35 AM, David Holmes wrote:
On 25/01/2013 2:36 AM, Peter Levart wrote:
On 01/24/2013 04:45 PM, Peter Levart wrote:
...so it seems that in both cases, adding a boolean to j.l.Class wastes
8 bytes per Class object :-(
Seems to be the
On 01/25/2013 08:37 PM, Peter Levart wrote:
On 01/25/2013 05:34 PM, Aleksey Shipilev wrote:
80 4 ClassValueMap Class.classValueMap
8412 (alignment/padding gap)
What's this? why 12 bytes?
96 4 int Class.classRedefinedCount
Beats me
On 01/25/2013 08:40 PM, Peter Levart wrote:
On 01/25/2013 05:34 PM, Aleksey Shipilev wrote:
But, otherwise, can't we use java.lang.ClassValue to associate this flag
with each class?
That is my proposed patch. It tries to be space saving and does not
associate the flag with each class
On 01/20/2013 04:54 AM, Steven Schlansker wrote:
a) Do you need the masks before or-ing with most/leastSigBits?
So, they seem to exist to satisfy a few Apache Harmony test cases:
On 01/20/2013 04:54 AM, Steven Schlansker wrote:
On Jan 10, 2013, at 4:50 AM, Aleksey Shipilev aleksey.shipi...@oracle.com
wrote:
On 01/09/2013 09:51 PM, Steven Schlansker wrote:
I sent this email a week ago and have received no replies. Is there
any step I have missed necessary
Hi Peter,
This is an interesting experiment.
On 01/16/2013 12:59 PM, Peter Levart wrote:
I did some micro benchmarks and here are the results:
http://dl.dropbox.com/u/101777488/TLR/TLR_benchmark_results.txt
Results indicate that usage pattern: Thread.current().nextInt() is as
fast as
On 01/16/2013 01:23 PM, Peter Levart wrote:
The test I used is simple:
https://raw.github.com/plevart/lambda-hacks/master/jdk-test/src/org/openjdk/tests/java/util/concurrent/atomic/RandomTest.java
OK, you can't get serious with that test. The failures visible at the
surface are:
- dead-code
On 01/15/2013 01:40 PM, Peter Levart wrote:
If this is an API change, then it might as well be a change in the
serializability of the ThreadLocalRandom instance. Since TLR extends
Random which is already Serializable, this could be done by throwing
appropriate exception in writeObject().
I
On 01/15/2013 02:12 PM, Chris Hegarty wrote:
On 01/15/2013 09:57 AM, Aleksey Shipilev wrote:
Chris, do you need help preparing the patch?
I'm still not sure that we have agreement here.
Sorry, I should not have replied in this thread.
My preference, for what it's worth, is to forge ahead
On 01/15/2013 06:33 PM, Peter Levart wrote:
One more thing, not related to serialization:
If a TLR reference is somehow passed from the thread that obtained it
via TLR.current() to some other thread that did never call TLR.current()
and this other thread calls methods on such instance
On 01/15/2013 08:33 PM, Chris Hegarty wrote:
Updated webrev:
http://cr.openjdk.java.net/~chegar/8005926/webrev.01/webrev/
Looks good to me; thanks for picking this up!
-Aleksey.
P.S. How many (Java) (concurrency) experts it takes to make a change to
ThreadLocalRandom?
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
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/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 :(
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 aleksey.shipi...@oracle.com wrote:
On 01/15/2013 02:17 AM, Alan Bateman wrote
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
901 - 1000 of 1039 matches
Mail list logo
