On 5/06/2015 9:32 AM, Chris Plummer wrote:
Hi David,
Here's an updated webrev:
http://cr.openjdk.java.net/~cjplummer/8054386/webrev.04/
Thanks - should have said updated webrev not necessary :)
Looks good.
David
thanks,
Chris
On 6/3/15 11:29 PM, David Holmes wrote:
Hi Chris,
Hotspot
java/util/Arrays/ParallelPrefix.java
This test has been observed to fail intermittently. This fix is to mark
it accordingly with keyword 'intermittent'.
bug: https://bugs.openjdk.java.net/browse/JDK-8085879
webrev: http://cr.openjdk.java.net/~amlu/8085879/webrev.00/
Thanks,
Amy
---
Hi Chris,
On 5/06/2015 9:34 AM, Chris Plummer wrote:
On 6/3/15 11:31 PM, David Holmes wrote:
Typo ...
On 4/06/2015 4:04 PM, David Holmes wrote:
Hi Chris,
On 3/06/2015 1:20 PM, Chris Plummer wrote:
Please review the following:
Webrev:
I guess, there is no need to re-review.
It looks good anyway.
Thanks,
Serguei
On 6/4/15 4:32 PM, Chris Plummer wrote:
Hi David,
Here's an updated webrev:
http://cr.openjdk.java.net/~cjplummer/8054386/webrev.04/
thanks,
Chris
On 6/3/15 11:29 PM, David Holmes wrote:
Hi Chris,
Hotspot
Hi David,
Here's an updated webrev:
http://cr.openjdk.java.net/~cjplummer/8054386/webrev.04/
thanks,
Chris
On 6/3/15 11:29 PM, David Holmes wrote:
Hi Chris,
Hotspot change is good.
Only a couple of style nits with the tests (where are our Java style
guidelines ???). Taking
On Jun 4, 2015, at 8:49 AM, Dmitry Samersoff dmitry.samers...@oracle.com
wrote:
Mandy,
Webrev updated in-place (press shift-reload).
http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.14
getFinalizerHistogram() now returns Entry[]
@library and @build removed from the
With respect to the 'stream test library not closing streams' bug:
would you mind to create a separate bugtracker issue for that, or do you
think it's too special to carry that weight?
Thanks,
Stefan
2015-06-04 22:06 GMT+02:00 Paul Sandoz paul.san...@oracle.com:
On Jun 3, 2015, at 6:18 PM,
On Jun 3, 2015, at 6:18 PM, Alan Bateman alan.bate...@oracle.com wrote:
As this code path is only for the default provider case then there's a good
chance that it will be a FileChannelImpl, in which case you can call its
unmap method (directly or via a shared secret). It is possible to
Mandy,
Webrev updated in-place (press shift-reload).
http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.14
getFinalizerHistogram() now returns Entry[]
@library and @build removed from the test.
-Dmitry
On 2015-06-04 16:56, Mandy Chung wrote:
On Jun 4, 2015, at 6:38 AM, Dmitry
On Jun 4, 2015, at 6:38 AM, Dmitry Samersoff dmitry.samers...@oracle.com
wrote:
Mandy,
Thank you for the review.
Updated webrev is:
http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.14
Thanks for the update and the test.
addressed comments, added a unit test to JDK
Thanks for the reviews.
On 4 Jun 2015, at 13:59, Ivan Gerasimov ivan.gerasi...@oracle.com wrote:
Wouldn't it cause the additional error message be printed _before_ the line
'test:.. : failure' ?
I guess, It may look confusing.
Would it make sense to re-throw the exception with this
On Jun 4, 2015, at 4:09 PM, Chris Hegarty chris.hega...@oracle.com wrote:
On 4 Jun 2015, at 13:37, Paul Sandoz paul.san...@oracle.com wrote:
...
If you wanna go the extra mile it's useful for the data provider to supply a
string description argument summarizing the test data.
Added.
I
On 4 Jun 2015, at 15:28, Paul Sandoz paul.san...@oracle.com wrote:
On Jun 4, 2015, at 4:09 PM, Chris Hegarty chris.hega...@oracle.com wrote:
On 4 Jun 2015, at 13:37, Paul Sandoz paul.san...@oracle.com wrote:
...
If you wanna go the extra mile it's useful for the data provider to supply
a
On Jun 4, 2015, at 9:04 AM, Remi Forax fo...@univ-mlv.fr wrote:
Thinking a little more about dropWhile(),
it can be written using filter() more or less like this:
default StreamT dropWhile(Predicate? super T predicate) {
return filter(new Predicate() {
private boolean
On Jun 3, 2015, at 11:00 PM, Chris Hegarty chris.hega...@oracle.com wrote:
Looks good Paul, just a few minor comments. ( looked at all, but *security*
and *sql* )
NetworkInterface
s/Enumertion/Stream
L127 * will be returned in the Enumeration. However, if the caller has the
Typo ...
On 4/06/2015 4:04 PM, David Holmes wrote:
Hi Chris,
On 3/06/2015 1:20 PM, Chris Plummer wrote:
Please review the following:
Webrev: http://cr.openjdk.java.net/~cjplummer/8054386/webrev.02/
Bug: https://bugs.openjdk.java.net/browse/JDK-8081771
This review only concerns the changes
Hi Chris,
Hotspot change is good.
Only a couple of style nits with the tests (where are our Java style
guidelines ???). Taking CDSJDITest.java as an example:
If you are okay with this line length:
115 public static OutputAnalyzer executeAndLog(ProcessBuilder pb,
String logName) throws
Thinking a little more about dropWhile(),
it can be written using filter() more or less like this:
default StreamT dropWhile(Predicate? super T predicate) {
return filter(new Predicate() {
private boolean noDropAnymore;
public boolean test(T t) {
return noDropAnymore
Vladimir
In all cases when OOME happens the test operates with
BoundMethodHandle$SpeciesData class, so it indeed may be caused by
JDK-8078602.
But is it a good idea of excluding the test? LFGarbageCollectedTest.java
fails not every time and may catch other product issues if they happen.
We
This is a review request to add better test failure output to
jdk/test/java/util/Arrays/ParallelPrefix.java
This test has been seen to fail occasionally on recent JDK 9 builds. It fails
with a message similar to:
...
test ParallelPrefix.testParallelPrefixForInt([I@47a7a8ef, 1365, 2730,
On 03/06/2015 21:17, Paul Sandoz wrote:
:
For the tests then @library ../../util/streambootlib doesn't seem right. Is it
time to move some infrastructure to make it easier to get at in other parts of
the suite?
Quite probably, but not with this fix.
Sure, but we should create a bug to
On 06/03/2015 08:53 PM, Peter Levart wrote:
Hi Paul,
This is a usefull addition to Stream API for sequential ordered
streams. But does it have any utility in unordered streams at all?
Wouldn't it be better to just throw an IllegalStateException or
something if the stream is not ordered? I
On Jun 4, 2015, at 10:09 AM, Remi Forax fo...@univ-mlv.fr wrote:
On 06/04/2015 09:37 AM, Paul Sandoz wrote:
On Jun 4, 2015, at 9:04 AM, Remi Forax fo...@univ-mlv.fr wrote:
Thinking a little more about dropWhile(),
it can be written using filter() more or less like this:
default StreamT
On Jun 4, 2015, at 10:27 AM, Peter Levart peter.lev...@gmail.com wrote:
On 06/03/2015 08:53 PM, Peter Levart wrote:
Hi Paul,
This is a usefull addition to Stream API for sequential ordered streams. But
does it have any utility in unordered streams at all? Wouldn't it be better
to just
Igor,
It seems I have given you wrong information. This test fails with OOME
against JDK 9 also, I managed to reproduce the failure now.
It was hard to reproduce it because of randomness, I need to rerun the
test 50 times. Although the test seems to fail with OOME more often
against JDK 8u,
Hi Sean, there should be exactly 440, because 11 cycles is one iteration.
-Konstantin
On 06/03/2015 10:14 PM, Seán Coffey wrote:
I bumped into this failure myself today. I think you've got a typo.
440 should be 40. Looks like a good approach otherwise.
Regards,
Sean.
On 03/06/2015 17:33,
On 06/04/2015 09:37 AM, Paul Sandoz wrote:
On Jun 4, 2015, at 9:04 AM, Remi Forax fo...@univ-mlv.fr wrote:
Thinking a little more about dropWhile(),
it can be written using filter() more or less like this:
default StreamT dropWhile(Predicate? super T predicate) {
return filter(new
Konstantin,
could you please run the test on JDK 9 w/ the seed values which lead to
failures on JDK 8u?
and please update the bug w/ gotten information.
Thanks,
Igor
On 06/04/2015 12:10 PM, Konstantin Shefov wrote:
Igor,
It seems I have given you wrong information. This test fails with
Hi Chris,
On 3/06/2015 1:20 PM, Chris Plummer wrote:
Please review the following:
Webrev: http://cr.openjdk.java.net/~cjplummer/8054386/webrev.02/
Bug: https://bugs.openjdk.java.net/browse/JDK-8081771
This review only concerns the changes to ProcessTool.java. The
Your new method needs
Igor,
I have added comment to https://bugs.openjdk.java.net/browse/JDK-8068416
Tried 10 seeds, for all of them test fails with OOME for both 8u60 and 9.
-Konstantin
On 06/04/2015 12:15 PM, Igor Ignatyev wrote:
Konstantin,
could you please run the test on JDK 9 w/ the seed values which lead
Konstantin,
Have you looked into the heap dump to understand why the test provokes
an OOM? Limiting test iterations is counter-productive, because it
defeats the purpose of the test.
Probably, the failure is caused by BMHs which aren't collected (see
JDK-8078602 [1]). In that case I'd
Hello,
Please review this fix for https://bugs.openjdk.java.net/browse/JDK-8054304
(twin for conformance test failures:
https://bugs.openjdk.java.net/browse/JDK-8058595)
JBS:
https://bugs.openjdk.java.net/browse/JDK-8054304
Webrev:
Konstantin,
In all cases when OOME happens the test operates with
BoundMethodHandle$SpeciesData class, so it indeed may be caused by
JDK-8078602.
It's not necessarily an evidence. Most of method handles are BMHs. So,
I'd suggest to inspect the heap dump.
But is it a good idea of excluding
Vladimir,
I have verified the failure again.
Even if I use random seed that causes failure against JDK 8u60, the test
passes against JDK 9 with this seed.
So JDK-8062904 ([1]) is really reproduced only against JDK 8u, not JDK 9.
And failure happens only with -Xcomp option.
I think it is a
Hi Xue-Lei
Thanks for reviewing! I will reduce the line size, make JPRT testing and
push then.
-Konstantin
On 06/04/2015 04:57 AM, Xuelei Fan wrote:
Looks fine to me.
It's nice to keep each line not exceed 80 characters. For example
- * @run main/othervm -Dtest.security.protocol=DTLS
Vladimir
On 06/04/2015 02:19 PM, Vladimir Ivanov wrote:
Konstantin,
In all cases when OOME happens the test operates with
BoundMethodHandle$SpeciesData class, so it indeed may be caused by
JDK-8078602.
It's not necessarily an evidence. Most of method handles are BMHs. So,
I'd suggest to
Hi,
I'm still planning to be the sponsor for this RFE and get this one
into the jdk9. We are current working on JEP 254 [1][2][3]in which
the internal storage mechanism is changed from char[] to byte[]. If
this JEP get approved and is scheduled to target JDK9, the
decoding/encoding
On Jun 4, 2015, at 12:54 PM, Chris Hegarty chris.hega...@oracle.com wrote:
This is a review request to add better test failure output to
jdk/test/java/util/Arrays/ParallelPrefix.java
Looks ok.
Printing the content should give some clues, but i expect it's only with some
focused repeated
Hi Chris!
Wouldn't it cause the additional error message be printed _before_ the
line 'test:.. : failure' ?
I guess, It may look confusing.
Would it make sense to re-throw the exception with this additional
message instead?
+try {
+assertEquals(actual, expected, );
Vladimir
I looked at heap dump using jhat tool.
Heap contained 2452 occurences of
java.lang.invoke.BoundMethodHandle$Species_* classes by the moment OOME
happened.
So looks like java.lang.invoke.BoundMethodHandle$Species_* classesare
not unloading as it is said in JDK-8078602 [1].
So I will
On Jun 4, 2015, at 10:06 AM, Alan Bateman alan.bate...@oracle.com wrote:
On 03/06/2015 21:17, Paul Sandoz wrote:
:
For the tests then @library ../../util/streambootlib doesn't seem right. Is
it time to move some infrastructure to make it easier to get at in other
parts of the suite?
Mandy,
Thank you for the review.
Updated webrev is:
http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.14
addressed comments, added a unit test to JDK workspace.
On 2015-06-03 21:36, Mandy Chung wrote:
Should getFinalizerHistogram() return FinalizerHistogramEntry[]?
The VM knows
42 matches
Mail list logo
