This is better (fixed a data race in Cleaner.clean()):
http://cr.openjdk.java.net/~plevart/jdk9-dev/OOMEInReferenceHandler/Investigation/webrev.05/
Regards, Peter
On 05/06/2015 07:13 PM, Peter Levart wrote:
Hi,
I might have a closure for this long beard issue [1] and I'd like to
propose a c
Hi Ivan,
I'm afraid of these changes - they are hard to review.
Can't we fix the SOE with a relatively small change to ArrayList.SubList
methods that recursively invoke parent methods to use iteration instead,
i.e. can't you implement updateSizeAndModCount in the existing SubList
class?
---
I w
Looks fine.
On 05/06/2015 03:19 PM, Joseph D. Darcy wrote:
PS Shortly after I pushed this fix I thought, "it would have been better to add the
intermittent keyword to the test too." Please review this change to add the keyword:
diff -r a199b72a5b37 test/java/util/regex/RegExTest.java
--- a/tes
PS Shortly after I pushed this fix I thought, "it would have been better
to add the intermittent keyword to the test too." Please review this
change to add the keyword:
diff -r a199b72a5b37 test/java/util/regex/RegExTest.java
--- a/test/java/util/regex/RegExTest.javaWed May 06 21:15:07 2015
And here's another update:
WEBREV: http://cr.openjdk.java.net/~igerasim/8079136/2/webrev/
This is cleaner.
For extra bonus test points you could add singleton-list, checked wrappers, and
synchronized list wrappers to the test set.
Done.
I also added a simple implementation of AbstractList,
Hi,
I might have a closure for this long beard issue [1] and I'd like to
propose a change [2].
It all started with [3] discussed here [4] which resulted in the fix for
one source of OutOfMemoryError(s) terminating ReferenceHandler thread.
With this fix, new test was added which started faili
On 05/06/2015 04:21 AM, Yekaterina Kantserova wrote:
The new webrev can be found here:
http://cr.openjdk.java.net/~ykantser/8078896/webrev.02/
Looks good.
About the test selection, one typical aspect of svc tests is to run a
j* tool in a child process (e.g. jinfo, jstack, jstat, jstatd,
OK, we will merge slightly tidier ConcurrentSkip* sources during the Great
jsr166 jdk9 Merge.
On Wed, May 6, 2015 at 1:14 AM, Paul Sandoz wrote:
> On May 5, 2015, at 7:39 PM, Martin Buchholz wrote:
> > I'd prefer to go the other way, deleting those trivial methods entirely,
> utilizing the rare
Hi Peter,
I'll run the CCC side, mostly it follows the similar rationale and
structure as the jira entry.
And the details are in your webrev.
Thanks, Roger
On 5/6/2015 11:43 AM, Peter Levart wrote:
Cool!
Do we need any CCC approval as this *is* a spec change isn't it?
I haven't done such
Cool!
Do we need any CCC approval as this *is* a spec change isn't it?
I haven't done such a thing yet, so please give me some pointers. I also
intend to add a jtreg test that verifies this new behavior.
Regards, Peter
On 05/06/2015 05:06 PM, Stephen Colebourne wrote:
I am also happy with t
On 05/06/2015 04:11 PM, Roger Riggs wrote:
Hi Peter,
Yes, looks good.
Roger
On 05/06/2015 02:44 PM, Daniel Fuchs wrote:
Hi Peter,
The logic looks good to me.
But I'm not an expert of the field, despite my small incursions :-)
I wish we didn't have to do defensive cloning - but I don't se
I am also happy with this change.
Stephen
On 6 May 2015 at 15:43, Roger Riggs wrote:
> Hi Peter,
>
> Thanks for the analysis and followup.
>
> Yes, I think thesimple check as you propose is the desired clarification.
> I agree that the change should not affect any existing code outside the JDK
On 06/05/15 16:47, Paul Sandoz wrote:
n May 6, 2015, at 4:08 PM, Ivan Gerasimov wrote:
>Hello everyone!
>
>Here's the second iteration of the fix.
>
>BUGURL:https://bugs.openjdk.java.net/browse/JDK-8079136
>WEBREV:http://cr.openjdk.java.net/~igerasim/8079136/1/webrev/
>
This is cleaner.
For
On May 6, 2015, at 4:08 PM, Ivan Gerasimov wrote:
> Hello everyone!
>
> Here's the second iteration of the fix.
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8079136
> WEBREV: http://cr.openjdk.java.net/~igerasim/8079136/1/webrev/
>
This is cleaner.
For extra bonus test points you co
Hi Peter,
Thanks for the analysis and followup.
Yes, I think thesimple check as you propose is the desired clarification.
I agree that the change should not affect any existing code outside the JDK
and does not raise a compatibility issue.
Roger
On 5/4/2015 6:22 AM, Peter Levart wrote:
Hi,
Hi Pavel!
It was intentional to avoid checking for co-modification for every pair
of list-sublist in the chain.
It's surely enough to only compare modCount of the root and the sublist
we're dealing with.
However, I didn't notice that SubList.size() had not checked for
comodifications recursi
Hi Peter,
Yes, looks good.
Roger
On 5/6/2015 8:21 AM, Peter Levart wrote:
Any official Reviewers with a couple of cycles to spare?
Thanks,
Peter Levart
On 04/27/2015 08:24 PM, Stephen Colebourne wrote:
This seems like a good enhancement.
Stephen
On 27 April 2015 at 16:26, Peter Levart
Hello everyone!
Here's the second iteration of the fix.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8079136
WEBREV: http://cr.openjdk.java.net/~igerasim/8079136/1/webrev/
I changed all the sub-list classes to be non internal, but standalone.
I think the logic become more obvious now.
Arra
On 6 May 2015 at 14:53, Paul Sandoz wrote:
>>> In some respects i wonder if the default methods on the functional
>>> interfaces are an attractive nuisance.
>>
>> Meaning, if .negate(Predicate) were a static method on the Predicate class
>> instead of a default method, then
>> stream.filter(Pre
On May 6, 2015, at 1:58 PM, Attila Szegedi wrote:
> On May 6, 2015, at 12:37 PM, Paul Sandoz wrote:
>>
>>
>> On May 2, 2015, at 11:31 PM, Remi Forax wrote:
>>
>>> Hi all,
>>> today, I stubble on a variant of JDK-8050818 [1],
>>> trying to call negate() on a lambda which is not yet a Predica
Hi Peter,
The logic looks good to me.
But I'm not an expert of the field, despite my small incursions :-)
I wish we didn't have to do defensive cloning - but I don't see
any way around.
best regards,
-- daniel
On 27/04/15 17:26, Peter Levart wrote:
Hi,
Please review the following improveme
Any official Reviewers with a couple of cycles to spare?
Thanks,
Peter Levart
On 04/27/2015 08:24 PM, Stephen Colebourne wrote:
This seems like a good enhancement.
Stephen
On 27 April 2015 at 16:26, Peter Levart wrote:
Hi,
Please review the following improvement that caches default ZoneId
Scala provides a filterNot method as a work around. This is a less generic fix,
but arguably more pragmatic for the common case of the streams API.
Sent from Yahoo Mail on Android
From:"Attila Szegedi"
Date:Wed, May 6, 2015 at 4:59 am
Subject:Re: Add Predicate.of(), Consumer.of(), etc.
On May
On May 6, 2015, at 12:37 PM, Paul Sandoz wrote:
>
>
> On May 2, 2015, at 11:31 PM, Remi Forax wrote:
>
>> Hi all,
>> today, I stubble on a variant of JDK-8050818 [1],
>> trying to call negate() on a lambda which is not yet a Predicate (due to
>> target typing) which requires either to cast th
Mandy,
Thanks fro your review! Please see my comment inlined.
On 05/05/2015 11:00 PM, Mandy Chung wrote:
com.sun.management has been moved to jdk.management module. The
patch for JDK-8042901 is just integrated in jdk9/dev today. Most, if
not all, test/com/sun/management tests need updates t
On May 2, 2015, at 11:31 PM, Remi Forax wrote:
> Hi all,
> today, I stubble on a variant of JDK-8050818 [1],
> trying to call negate() on a lambda which is not yet a Predicate (due to
> target typing) which requires either to cast the lambda to a Predicate and
> everybody knows that cast are e
Thanks!
> the comments in ValueBoxGen24 are somewhat cryptic to me at least
Yes, indeed... Roger mentioned that these may be some (outdated?) bug
tracker references, so I prefer not to touch them; just remove the angle
brackets to avoid warnings.
Regards,
Alexander
On 05.05.2015 21:25, Lance
On 06/05/15 11:41, David Holmes wrote:
I don't think you want to de-synchronize the load* methods - you don't
want two threads calling load concurrently. But that then raises the
problem of concurrent modification while a load is in progress.
Synchronization ensures serialization and by removing
On 6/05/2015 5:57 PM, Peter Levart wrote:
On 05/05/2015 03:25 AM, David Holmes wrote:
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://
Ivan,
It looks like your change (I don't know whether it was intentional or not)
brings some more "fail-fast"-ness which is good! For instance, before the
change, this snippet:
List integers = new LinkedList<>();
integers.addAll(Arrays.asList(0, 1));
List sublist = integers.subList(0
Hi,
Is there any interest to propose JEP 132 for JDK9 ?
I have some ideas how to achieve it's goals.
Regards, Peter
On May 5, 2015, at 7:39 PM, Martin Buchholz wrote:
> I'd prefer to go the other way, deleting those trivial methods entirely,
> utilizing the rarely used .new syntax.
>
Very good, even better!
Paul.
On 05/05/2015 03:25 AM, David Holmes wrote:
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/webre
On 05/05/2015 22:00, Mandy Chung wrote:
:
About the test selection, one typical aspect of svc tests is to run a
j* tool in a child process (e.g. jinfo, jstack, jstat, jstatd,jcmd,
jps etc that are in jdk.jcmd module). I would expect all
test/sun/tools/jcmd tests should have @modules jdk.jc
34 matches
Mail list logo
