Hello Olivier,
By inspection I think that the fix and the test update look good. I verified
that the test hits all five branches contained in the else-if block of
DigitList beginning at line 527. I also verified that the current code base
fails four test cases when run against the updated test.
Hello Sandipan,
Finally got this off the back burner …
This review request follows this thread:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027086.html
in which you provided a patch (thank you!) for:
https://bugs.openjdk.java.net/browse/JDK-8043740
I’ve created an updated w
Hi Robert,
What happened was that for whatever reason my version of the ‘patch’ command
did not like your patch. I tried various things to get ‘patch’ to accept it but
without success. Note that this had nothing to do with the modular
restructuring of the source tree as the path is easily unshu
> Hi Oliver,
First, sorry about mistyping your name, Olivier!
> I copied your patch into my shim locally and ran my test cases and
> still get a couple failures (see output below). Your patch and my version
> differ in the way and order in which we interpret allDecimalDigits and
> alreadyRounded
> For the 2D disposer issue then 2d-dev is the place to start
The 2d disposer has a call to Thread.setContextClassLoader(null)
It's been there since JDK6u21 ... and is in all later releases.
https://bugs.openjdk.java.net/browse/JDK-6936389
So there is no need I see for accessing this in JDK 9
Hi Oliver,
I wrote a javaagent-based patch for this bug. I haven't contributed it
formally since my employer's legal department is still hung up on the Oracle
Contributor Agreement (though we have released it on GitHub under GPLv2 w/CPE).
I'm not linking to it here under the assumption that y
Reviewed.
On Sep 17, 2014, at 4:09 AM, Vladimir Ivanov
wrote:
> http://cr.openjdk.java.net/~vlivanov/8058626/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8058626
>
> I've noticed a difference between 8057656 fixes in 8u-dev [1] and 9 [2].
> It seems I integrated [3] into 8u and [4] in
On 19/09/2014 14:12, Mark Thomas wrote:
:
The memory leaks stem from the generally more complex class loader
structure present in a JavaEE container than is typically present in a
standalone Java app.
At this point, I have two questions.
1. Is this community interested in examining these memor
Miran,
thanks for the update. Seems like you're working from an old JDK 9
forest. The webrev is
using the pre-modular path layout. I've converted them. I'm am seeing
the new test fail
on windows though. Will share the details with you offline.
regards,
Sean.
On 18/09/14 16:22, Miroslav Kos w
All,
As you may know I am one of the Apache Tomcat committers. The Tomcat
project was approached recently[1] to see what, if any, internal APIs
Tomcat was using as part of the JDK 9 preparations.
My response was that the only place Tomcat does this is in the memory
leak prevention class [2]. I al
thx. Reviewed.
-- II
- Reply message -
From: "Konstantin Shefov"
To: "Igor Ignatyev"
Cc: "VLADIMIR.X.IVANOV" ,
,
Subject: [9] Review request : JDK-8058728: TEST_BUG: Make
java/lang/invoke/LFCaching/LFGarbageCollectedTest.java skip arrayElementSetter
and arrayElementGetter methods
Da
Yes, the test compiles and runs ok, but fails because of 8057020.
If we remove -Djava.lang.invoke.MethodHandle.USE_LF_EDITOR=true, the
test passes.
-Konstantin
On 19.09.2014 16:01, Igor Ignatyev wrote:
Hi,
looks good to me.
how have you tested your changes?
Thanks,
Igor
On 09/19/2014 01:5
Hi,
looks good to me.
how have you tested your changes?
Thanks,
Igor
On 09/19/2014 01:50 PM, Konstantin Shefov wrote:
Hello,
Please review the test bug fix
https://bugs.openjdk.java.net/browse/JDK-8058728
Webrev is http://cr.openjdk.java.net/~kshefov/8058728/webrev.00
Thanks
-Konstantin
Hi,
This is a code change we would like to integrate in next release of
JDK8, since impacting some customer apps/deployments.
So it would be good to have it reviewed and backported to 8 soon.
Is there anyone having a bit of free time to review it ?
Best Regards,
Olivier Lagneau
On 11/09/201
On Sep 19, 2014, at 11:54 AM, Vladimir Ivanov
wrote:
> Looks good.
>
Small typo in the comment:
s/filed/field
Otherwise +1,
Paul.
> Best regards,
> Vladimir Ivanov
>
> On 9/19/14, 1:50 PM, Konstantin Shefov wrote:
>> Hello,
>>
>> Please review the test bug fix
>> https://bugs.openjdk.jav
Looks good.
Best regards,
Vladimir Ivanov
On 9/19/14, 1:50 PM, Konstantin Shefov wrote:
Hello,
Please review the test bug fix
https://bugs.openjdk.java.net/browse/JDK-8058728
Webrev is http://cr.openjdk.java.net/~kshefov/8058728/webrev.00
Thanks
-Konstantin
Hello,
Please review the test bug fix
https://bugs.openjdk.java.net/browse/JDK-8058728
Webrev is http://cr.openjdk.java.net/~kshefov/8058728/webrev.00
Thanks
-Konstantin
On 19/09/14 10:21, Alan Bateman wrote:
On 19/09/2014 10:14, Chris Hegarty wrote:
Thank you Martin and Alan. This does indeed look better.
Since this is a small specification clarification, of existing
behavior, then a CCC should be filed so it is included in the next
Java SE maintenance review,
On 19/09/2014 10:14, Chris Hegarty wrote:
Thank you Martin and Alan. This does indeed look better.
Since this is a small specification clarification, of existing
behavior, then a CCC should be filed so it is included in the next
Java SE maintenance review, gets JCK attention, etc. I will do th
Thank you Martin and Alan. This does indeed look better.
Since this is a small specification clarification, of existing behavior,
then a CCC should be filed so it is included in the next Java SE
maintenance review, gets JCK attention, etc. I will do this.
-Chris.
On 19/09/14 00:22, Martin Bu
On 09/19/2014 09:45 AM, David Holmes wrote:
On 19/09/2014 5:35 PM, Peter Levart wrote:
On 09/19/2014 09:06 AM, David Holmes wrote:
Hi Peter,
Two comments:
1. Doing the Object.wait() violates the thou-shalt-not-allocate rule,
due to the potential for creating the InterruptedException. But ther
On 19/09/2014 5:35 PM, Peter Levart wrote:
On 09/19/2014 09:06 AM, David Holmes wrote:
Hi Peter,
Two comments:
1. Doing the Object.wait() violates the thou-shalt-not-allocate rule,
due to the potential for creating the InterruptedException. But there
is no way to avoid that.
It depends on wh
On 09/19/2014 09:06 AM, David Holmes wrote:
Hi Peter,
Two comments:
1. Doing the Object.wait() violates the thou-shalt-not-allocate rule,
due to the potential for creating the InterruptedException. But there
is no way to avoid that.
It depends on when the InterruptedException is allocated.
Hi Peter,
Two comments:
1. Doing the Object.wait() violates the thou-shalt-not-allocate rule,
due to the potential for creating the InterruptedException. But there is
no way to avoid that.
2. I don't see how the instanceof can still result in OOME if we have
pre-loaded and initialized the r
24 matches
Mail list logo
