Looks good.
/Erik
On 2015-06-10 15:44, Magnus Ihse Bursie wrote:
On 2015-06-09 01:31, Daniel D. Daugherty wrote:
>
http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01
General comment: Not all copyright years were updated.
I realize I missed that part of the revi
On 10/06/2015 11:29 PM, Peter Levart wrote:
Hi Roger,
I don't know how the tests are executed in your environment, but is it
possible that, while you're running the test in a shared VM, some other
concurrent activity allocates from heap and that the test fails because
of that and not because of
Hi Magnus,
On 10/06/2015 10:13 PM, Magnus Ihse Bursie wrote:
On 2015-06-10 11:58, David Holmes wrote:
Hi Magnus,
Generally looks good - a few comments/queries below.
In general, I believe most issues you found are valid. :-) However, as I
said before in this thread, I'd like to see them reso
Redirecting this thread here
http://mail.openjdk.java.net/pipermail/nio-dev/2015-June/003187.html
to where it should have gone.
On Jun 10, 2015, at 3:57 PM, Brian Burkhalter
wrote:
> Please review at your convenience.
>
> Issue:https://bugs.openjdk.java.net/browse/JDK-8081843
> Patch
On Wednesday, June 10, 2015, Mandy Chung wrote:
>
> > On Jun 10, 2015, at 9:23 AM, Volker Simonis > wrote:
> >
> > Hy Mandy,
> >
> > that's a real good proposal and it only requires changes in the jdk
> > repository which makes it even more attractive.
> >
> > I've just checked and it does indee
Please review at your convenience.
Issue: https://bugs.openjdk.java.net/browse/JDK-8081843
Patch: http://cr.openjdk.java.net/~bpb/8081843/webrev.00/
Summary: On Mac OS X use BSD system call statfs() instead of Standard C Library
call statvfs() to obtain file system size statistics.
Standard r
Thumbs up. I like code deletion.
Mandy
> On Jun 10, 2015, at 3:16 PM, Brent Christian
> wrote:
>
> Hi,
>
> Please review my change for:
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8064956
> Webrev:
> http://cr.openjdk.java.net/~bchristi/8064956/
>
> After clearing some internal dep
Hi,
Please review my change for:
Bug:
https://bugs.openjdk.java.net/browse/JDK-8064956
Webrev:
http://cr.openjdk.java.net/~bchristi/8064956/
After clearing some internal dependencies following the removal of the
extension mechanism from JDK 9[1], we can now remove 4 extension-related
classes
Hi Tomasz,
The change was made to fix a performance regression in JDK8:
https://bugs.openjdk.java.net/browse/JDK-8076287
Those time zone names weren't cached in JDK8, so the fix was to cache
those arrays, which are also shared with ZoneId.getDisplayName() which
can also return generic names.
> On Jun 10, 2015, at 9:23 AM, Volker Simonis wrote:
>
> Hy Mandy,
>
> that's a real good proposal and it only requires changes in the jdk
> repository which makes it even more attractive.
>
> I've just checked and it does indeed solve the initial
> EmptyStackException problem in both jdk8 and
On 6/10/2015 6:13 AM, Magnus Ihse Bursie wrote:
On 2015-06-10 11:58, David Holmes wrote:
Hi Magnus,
Generally looks good - a few comments/queries below.
In general, I believe most issues you found are valid. :-) However, as
I said before in this thread, I'd like to see them resolved in the
Hy Mandy,
that's a real good proposal and it only requires changes in the jdk
repository which makes it even more attractive.
I've just checked and it does indeed solve the initial
EmptyStackException problem in both jdk8 and jdk9. Here are the
corresponding webrevs:
http://cr.openjdk.java.net/~
Have you checked out this patch moving out findBuiltinLib from NativeLibrary
class?
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8081674/webrev.00/
Mandy
> On Jun 10, 2015, at 12:34 AM, Volker Simonis wrote:
>
> Mandy, the example/stacktrace I sent was with 8u.
>
> The problem isn't rel
On 2015-06-09 01:31, Daniel D. Daugherty wrote:
>
http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01
General comment: Not all copyright years were updated.
I realize I missed that part of the review. :-(
I have now updated the copyright years. Here's a delta revi
Hi Roger,
I don't know how the tests are executed in your environment, but is it
possible that, while you're running the test in a shared VM, some other
concurrent activity allocates from heap and that the test fails because
of that and not because of Process.exec() at all?
Regards, Peter
O
On 2015-06-10 11:58, David Holmes wrote:
Hi Magnus,
Generally looks good - a few comments/queries below.
In general, I believe most issues you found are valid. :-) However, as I
said before in this thread, I'd like to see them resolved in the needed
follow-up patches. The source code changes
Hi Chris,
Thanks for the review.
In the previous iteration of this fix, it was recommended to retain the
intermittent keyword
until there is a track record of the test not failing.
Roger
On 6/10/15 11:12 AM, Chris Hegarty wrote:
Roger,
It seems reasonable to be more lenient in testing for
Hi,
I am not sure where to write about this, I hope somebody will point me to
right list if this one is not correct.
I have been playing with newest Java 1.8u60 to try PreserveFramePointer
functionality. Unfortunately none of our servers start on this version of
java. It is because of REST call t
Roger,
It seems reasonable to be more lenient in testing for memory consumption
in this test, given that the test would OOM quickly if the original bug
was present.
Are you confident enough to remove the '@key intermittent' tag at the
same time?
-Chris.
On 10/06/15 10:55, Roger Riggs wrot
Hi Magnus,
Generally looks good - a few comments/queries below.
On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote:
Here's an updated webrev, which fixes the typos that were pointed out by
reviewers:
http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/
common/autoconf/ve
Please review a test change in the algorithm for detecting memory growth to
resolve an intermittent reporting problem.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-lots-8086117/
Issue:
https://bugs.openjdk.java.net/browse/JDK-8086117
Thanks, Roger
Mandy, the example/stacktrace I sent was with 8u.
The problem isn't related to libzip, it is only the first library
which gets loaded with System.loadLibrary().
The problem will occur with every library which gets loaded by
System.loadLibrary() because
java.lang.ClassLoader$NativeLibrary.findBuil
Looks good.
/Erik
On 2015-06-09 15:52, Magnus Ihse Bursie wrote:
Here's an updated webrev, which fixes the typos that were pointed out
by reviewers:
http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/
And here's a (much simpler) delta webrev which shows just these
23 matches
Mail list logo
