On 5/4/2015 11:52 AM, Daniel Fuchs wrote:
On 04/05/15 16:46, Peter Levart wrote:
Hi Daniel,
Here it is:
http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.04/
Looks good for me Peter :-)
Hopefully Mandy will like it too!
Yes it looks good to me. Thanks to both
>
>
> One query in ConcurrentSkipListMap, we have:
>
> 2500 // else use iterator
> 2501 @SuppressWarnings("unchecked")
> Iterator> it =
> 2502 ((SubMap)m).entryIterator();
>
> and then
>
> 2578 // else use iterator
> 2579 Iterator>
Hi Paul,
On 5/05/2015 1:59 AM, Paul Sandoz wrote:
Hi
Please review:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8078645-ConcurrentMap-views-removeIf/webrev/
These updates are already in the 166 repo.
The documentation update to the class of ConcurrentMap is going through CCC. I
took th
Hi Brent,
On 5/05/2015 2:11 AM, Brent Christian wrote:
Hi,
Please review this fix, courtesy of Peter Levart (thanks!), that I would
like to get in.
https://bugs.openjdk.java.net/browse/JDK-8029891
http://cr.openjdk.java.net/~bchristi/8029891/webrev.0/
There is some discussion of it in the bug
Paul, thanks.
Looks good.
Test uses some impressive machinery, but I like what we did in jsr166 tck
tests for similar sorts of tests:
- rename latch to "done"
- rename barrier to "threadsStarted"
- rename "map" to "entry" or "e"
- if a worker thread throws, make sure the test fails, e.g. by defin
On May 4, 2015, at 7:29 PM, Paul Sandoz wrote:
>> There are still a number of differences, mostly cosmetic, between your
>> version of ConcurrentMap.java and jsr166 CVS (let's try hard to keep that
>> the "master" copy).
>
> Yeah, there are a bunch of cosmetic differences, i just tried to fix s
Hi Brent,
I think all you need for test is this:
import java.lang.reflect.Method;
import java.lang.reflect.Modifier;
import java.util.*;
import java.util.stream.Collectors;
import java.util.stream.Stream;
public class CheckOverrides {
public static void main(String[] args) {
Set p
On 04/05/15 16:46, Peter Levart wrote:
Hi Daniel,
Here it is:
http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.04/
Looks good for me Peter :-)
Hopefully Mandy will like it too!
All java/util/logging tests pass for me except
java/util/logging/TestLoggerWeakRefLeak
On 05/04/2015 06:11 PM, Brent Christian wrote:
Hi,
Please review this fix, courtesy of Peter Levart (thanks!), that I
would like to get in.
https://bugs.openjdk.java.net/browse/JDK-8029891
http://cr.openjdk.java.net/~bchristi/8029891/webrev.0/
There is some discussion of it in the bug repo
On May 4, 2015, at 7:12 PM, Martin Buchholz wrote:
> Thanks, Paul.
>
> Are there are too many cooks spoiling this broth?
Probably :-)
> There are still a number of differences, mostly cosmetic, between your
> version of ConcurrentMap.java and jsr166 CVS (let's try hard to keep that the
> "
Thanks, Paul.
Are there are too many cooks spoiling this broth?
There are still a number of differences, mostly cosmetic, between your
version of ConcurrentMap.java and jsr166 CVS (let's try hard to keep that
the "master" copy). E.g. This code sample won't compile:
* do {
*
Hi,
Please review this fix, courtesy of Peter Levart (thanks!), that I would
like to get in.
https://bugs.openjdk.java.net/browse/JDK-8029891
http://cr.openjdk.java.net/~bchristi/8029891/webrev.0/
There is some discussion of it in the bug report, starting at 2014-12-31.
The problem, as state
Hi
Please review:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8078645-ConcurrentMap-views-removeIf/webrev/
These updates are already in the 166 repo.
The documentation update to the class of ConcurrentMap is going through CCC. I
took the liberty of also cleaning up some smaller doc errors
Hi Daniel,
Here it is:
http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.04/
All java/util/logging tests pass for me except
java/util/logging/TestLoggerWeakRefLeak
#section:build
--messages:(2/93)--
command: build jdk.testlibrary.*
reason: User specif
On 05/04/2015 03:46 PM, Daniel Fuchs wrote:
On 04/05/15 15:26, Peter Levart wrote:
Hi Daniel, Mandy,
What about the following:
http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.03/
You see, no boolean flags needed. The globalHandlersState is always
changed atomic
On 04/05/15 15:26, Peter Levart wrote:
Hi Daniel, Mandy,
What about the following:
http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.03/
You see, no boolean flags needed. The globalHandlersState is always
changed atomically within a locked region, so a graph of transit
Hi Daniel, Mandy,
What about the following:
http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.03/
You see, no boolean flags needed. The globalHandlersState is always
changed atomically within a locked region, so a graph of transitions can
be drawn:
http://cr.openjdk
On 05/01/2015 10:14 PM, Bernd Eckenfels wrote:
> btw just a small - maybe unrelated - observation on stock Java8u40. When
> benchmarking String.valueOf/Integer.toString/""+n with JMH I noticed
> that the compiler aided concatenation is the fastest,
String concat desugaring and optimizations is a
Hi,
Now that JDK-8074003 is in, I'd like to discuss how to tackle JDK-8079063.
Package-private ZoneOffsetTransition constructor that takes
LocalDateTime transition is invoked from the following 4 places:
1 - the public static factory method:
/**
* Obtains an instance defining a tran
Stephen, Roger,
Thanks for reviews. This has been pushed to jdk9-dev.
Regards, Peter
On 04/30/2015 02:47 PM, Roger Riggs wrote:
Hi Peter,
Yes, go ahead with the patch as is.
Thanks, Roger
On 4/30/2015 6:24 AM, Peter Levart wrote:
On 04/29/2015 05:35 PM, Roger Riggs wrote:
Hi Peter,
The
Hi Alan,
Can you point us to the benchmarks that were created? I look back at the
archive which mentions some benchmark but the sources doesn't look like they
have been made available on OpenJDK - are they available somewhere else?
(original discussion on DP quicksort implementation:
http://pe
21 matches
Mail list logo
