On 2/28/14 1:19 PM, frederic parain wrote:
Greetings,
Please review this small changeset for CR JDK-8035952
"Remove use of JVM_Open, JVM_Read and JVM_Close functions from
serviceability code"
Bug:
https://bugs.openjdk.java.net/browse/JDK-8035952
Webrev:
http://cr.openjdk.java.net/~fparain/80
Looks good to me Frederic.
JVM_Read is restartable, but that may not be an issue here.
-Chris.
> On 28 Feb 2014, at 21:19, frederic parain wrote:
>
> Greetings,
>
> Please review this small changeset for CR JDK-8035952
> "Remove use of JVM_Open, JVM_Read and JVM_Close functions from serviceab
> Looks good.
Thanks! Last backport (by me) for this one...
Dan
On 2/28/14 3:09 PM, serguei.spit...@oracle.com wrote:
On 2/28/14 1:55 PM, Daniel D. Daugherty wrote:
Resend with the corrected subject line... sigh...
Greetings,
This is a code review request for the JDK7u-hs-dev backport of t
On 2/28/14 1:55 PM, Daniel D. Daugherty wrote:
Resend with the corrected subject line... sigh...
Greetings,
This is a code review request for the JDK7u-hs-dev backport of the
following ObjectMonitor-JVM/TI hang fix:
8028073 race condition in ObjectMonitor implementation causing
deadlocks
Resend with the corrected subject line... sigh...
Greetings,
This is a code review request for the JDK7u-hs-dev backport of the
following ObjectMonitor-JVM/TI hang fix:
8028073 race condition in ObjectMonitor implementation causing
deadlocks
https://bugs.openjdk.java.net/browse/JDK-80
Greetings,
This is a code review request for the JDK7u-hs-dev backport of the
following ObjectMonitor-JVM/TI hang fix:
8028073 race condition in ObjectMonitor implementation causing
deadlocks
https://bugs.openjdk.java.net/browse/JDK-8028073
Here is the JDK7u-hs-dev webrev URL:
ht
On 2/28/14 1:26 PM, Daniel D. Daugherty wrote:
On 2/28/14 2:24 PM, serguei.spit...@oracle.com wrote:
On 2/28/14 1:12 PM, Daniel D. Daugherty wrote:
On 2/28/14 12:55 PM, serguei.spit...@oracle.com wrote:
On 2/27/14 10:04 PM, David Holmes wrote:
Hi Serguei,
On 28/02/2014 1:50 PM, serguei.spit.
On 2/28/14 2:24 PM, serguei.spit...@oracle.com wrote:
On 2/28/14 1:12 PM, Daniel D. Daugherty wrote:
On 2/28/14 12:55 PM, serguei.spit...@oracle.com wrote:
On 2/27/14 10:04 PM, David Holmes wrote:
Hi Serguei,
On 28/02/2014 1:50 PM, serguei.spit...@oracle.com wrote:
Please, review the fix for
On 2/28/14 1:12 PM, Daniel D. Daugherty wrote:
On 2/28/14 12:55 PM, serguei.spit...@oracle.com wrote:
On 2/27/14 10:04 PM, David Holmes wrote:
Hi Serguei,
On 28/02/2014 1:50 PM, serguei.spit...@oracle.com wrote:
Please, review the fix for:
https://bugs.openjdk.java.net/browse/JDK-6471769
Greetings,
Please review this small changeset for CR JDK-8035952
"Remove use of JVM_Open, JVM_Read and JVM_Close functions from
serviceability code"
Bug:
https://bugs.openjdk.java.net/browse/JDK-8035952
Webrev:
http://cr.openjdk.java.net/~fparain/8035952/webrev.00/
Tested with jdk_management
On 2/28/14 12:55 PM, serguei.spit...@oracle.com wrote:
On 2/27/14 10:04 PM, David Holmes wrote:
Hi Serguei,
On 28/02/2014 1:50 PM, serguei.spit...@oracle.com wrote:
Please, review the fix for:
https://bugs.openjdk.java.net/browse/JDK-6471769
Open webrev:
http://cr.openjdk.java.net/~sspits
On 2/27/14 10:04 PM, David Holmes wrote:
Hi Serguei,
On 28/02/2014 1:50 PM, serguei.spit...@oracle.com wrote:
Please, review the fix for:
https://bugs.openjdk.java.net/browse/JDK-6471769
Open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.3
Summa
On 2/28/14 7:36 AM, Pavel Punegov wrote:
New wevrev, thanks to Igor I.:
http://cr.openjdk.java.net/~iignatyev/ppunegov/6946101/webrev.01/
Thumbs up.
Dan
Fixed typos/grammar
Added next string to catch the situation when jdb exited with
input stream closed prematurely (break in a while lo
On 2/28/14 9:27 AM, Stuart Marks wrote:
I guess there is some risk of adding new intermittent failures, but
tackling @ignore'd tests is important too.
Right - the main risk is that we will see this test fail again at some
point in the future. I'll be keeping an eye out for that.
Thanks for
Changeset: 183a8c520b4a
Author:rfield
Date: 2014-02-28 10:43 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/183a8c520b4a
8035777: Consistent Lambda construction
Reviewed-by: ahgross, briangoetz, dlsmith
! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory
On 2/26/14 11:34 AM, Brent Christian wrote:
File under "chipping away at test stabilization issues."
https://bugs.openjdk.java.net/browse/JDK-6835233
I would like to resolve this bug by removing the "@ignore" tag for JDK 9, and
bring the test back into rotation. If the failure comes back, I'll
Still good.
Thanks,
/Staffan
On 28 feb 2014, at 15:36, Pavel Punegov wrote:
> New wevrev, thanks to Igor I.:
> http://cr.openjdk.java.net/~iignatyev/ppunegov/6946101/webrev.01/
>
> Fixed typos/grammar
> Added next string to catch the situation when jdb exited with
> input stream closed prema
New wevrev, thanks to Igor I.:
http://cr.openjdk.java.net/~iignatyev/ppunegov/6946101/webrev.01/
Fixed typos/grammar
Added next string to catch the situation when jdb exited with
input stream closed prematurely (break in a while loop before the check) :
996 # jdb exited because its input
Looks good!
Thanks,
/Staffan
On 28 feb 2014, at 13:56, Mattias Tobiasson
wrote:
> Hi,
> Could you please review this fix?
>
> The test often fails when run with command line "-Xcomp"
>
> The test creates some objects and stores them in a local variable in the
> function. The test expects th
Hi,
Could you please review this fix?
The test often fails when run with command line "-Xcomp"
The test creates some objects and stores them in a local variable in the
function. The test expects those objects to survive until they are set to null.
The problem seems to be that the optimizer real
Thanks for the review.
Unfortunately I can not remove the thresholdExceeded, because the "break" only
leaves the loop of memory pools.
I know nested loops are not perfect, but I did not want to change too much from
the original test.
Mattias
- Original Message -
From: shanliang.ji...@or
Hi Mattias,
The new version looks good!
best regards,
-- daniel
On 2/28/14 11:33 AM, Mattias Tobiasson wrote:
Hi,
I have updated the test and now stop allocating when we have reached the
threshold.
Since we now do all allocations first and then just wait for the notification,
I have split t
Looks good!
It could be improved to not use the variable thresholdExceeded:
change Line 146 to
while(true) {
and remove Line 143 and 158
Thanks,
Shanliang
Mattias Tobiasson wrote:
Hi,
I have updated the test and now stop allocating when we have reached the
threshold.
Since we now do all
Hi,
I have updated the test and now stop allocating when we have reached the
threshold.
Since we now do all allocations first and then just wait for the notification,
I have split the loop into two separate loops to make it clearer.
To detect if we have reached the threshold I now check
MemoryP
You are missing the copyright-header.
Otherwise looks good.
Thanks,
/Staffan
On 27 feb 2014, at 13:58, Jaroslav Bachorik
wrote:
> Please, review the addition of the jstat related test.
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8035668
> Webrev: http://cr.openjdk.java.net/~jbachori
Looks good to me!
Thanks,
/Staffan
On 27 feb 2014, at 16:34, roger riggs wrote:
> Hi Mandy,
>
> I updated the webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-testlibrary-asserts-8035889/
>
> Alan suggested copying serviceability-dev so they have a chance to review if
> desired.
>
>
Very nice change - looks good!
test/com/sun/jdi/ShellScaffold.sh
line 1000: # mydojdbCmds() didn't finished because it waits for JDB
message
nit: finished -> finish
Just a note that this should be pushed through jdk9/dev and not jdk9/hs-comp
(where the webrev was made).
Thanks,
/Sta
27 matches
Mail list logo
