On 4/6/16 16:51, Daniel D. Daugherty wrote:
On 4/6/16 5:45 PM, serguei.spit...@oracle.com wrote:
Hi Dan,
The fix looks right.
Thanks!
Thank you for taking care about the hs-rt stability!
You are very welcome.
It makes sense to back the fix of the 4858370 out at least because
it introd
On 4/6/16 5:45 PM, serguei.spit...@oracle.com wrote:
Hi Dan,
The fix looks right.
Thanks!
Thank you for taking care about the hs-rt stability!
You are very welcome.
It makes sense to back the fix of the 4858370 out at least because
it introduced new test that started failing intermitte
Hi Dan,
The fix looks right.
Thank you for taking care about the hs-rt stability!
It makes sense to back the fix of the 4858370 out at least because
it introduced new test that started failing intermittently.
The following 3 bugs have similar manifestation and related to the
remote invocation
Thanks!
Dan
On 4/6/16 5:43 PM, Jesper Wilhelmsson wrote:
Looks good!
/Jesper
Den 7/4/16 kl. 01:34, skrev Daniel D. Daugherty:
Resending with Jesper and Serguei on directly...
Greetings,
It appears that the fix for this bug:
JDK-4858370 JDWP: Memory Leak: GlobalRefs never deleted when
Looks good!
/Jesper
Den 7/4/16 kl. 01:34, skrev Daniel D. Daugherty:
Resending with Jesper and Serguei on directly...
Greetings,
It appears that the fix for this bug:
JDK-4858370 JDWP: Memory Leak: GlobalRefs never deleted when processing
invokeMethod command
https:
Resending with Jesper and Serguei on directly...
Greetings,
It appears that the fix for this bug:
JDK-4858370 JDWP: Memory Leak: GlobalRefs never deleted when processing
invokeMethod command
https://bugs.openjdk.java.net/browse/JDK-4858370
has been causing intermittent
Greetings,
It appears that the fix for this bug:
JDK-4858370 JDWP: Memory Leak: GlobalRefs never deleted when processing
invokeMethod command
https://bugs.openjdk.java.net/browse/JDK-4858370
has been causing intermittent test failures in the JDK9-hs-rt nightly.
***
Cheleswer,
Some times ago I invented LingeredAppWithDeadlock for tests like this one.
Please take a look at:
.../jdk/test/sun/tools/jstack/DeadlockDetectionTest.java
.../hotspot/test/serviceability/sa/DeadlockDetectionTest.java
-Dmitry
On 2016-04-05 13:23, Cheleswer Sahu wrote:
> Hi,
>
>
Thanks Stefan.
Per
On 2016-04-06 13:02, Stefan Johansson wrote:
Looks good,
StefanJ
On 2016-04-06 11:32, Per Liden wrote:
Summary: This patch updates the tests in serviceability/tmtools/jstat/
to use a fixed (and relatively small) heap size. Without this these
tests tend to run out of memory
Hi,
this is GC code and the rewview should go to hotspot-gc-dev.
I'm redirecting this mail there.
/Mikael
On 2016-04-06 08:15, Cheleswer Sahu wrote:
Hi,
This fix is waiting for review, can somebody please review this change.
Regards,
Cheleswer
From: Cheleswer Sahu
Sent: Friday, Apri
On 2016-04-06 11:46, Dmitry Samersoff wrote:
Per,
The fix looks good for me.
Thanks Dima.
Copyright year of these tests is not updated.
GcCapacityTest.java
GcCauseTest01.java
GcTest02.java
These already have 2016 in their copyright.
cheers,
Per
-Dmitry
On 2016-04-06 12:32, Per Liden
Looks good,
StefanJ
On 2016-04-06 11:32, Per Liden wrote:
Summary: This patch updates the tests in serviceability/tmtools/jstat/
to use a fixed (and relatively small) heap size. Without this these
tests tend to run out of memory on machines with VM overcommit
disabled. This has happened in nig
I've moved the test to the jdk repo.
Webrev: http://cr.openjdk.java.net/~akulyakh/8153584_02/
Thank you very much for your help.
Best regards,
Alexander
- Original Message -
From: serguei.spit...@oracle.com
To: alexander.kulyakh...@oracle.com, alan.bate...@oracle.com
Cc: serviceabilit
As Dmitry noted:
jdk/test/com/sun/jdi
Sorry, we did not point to it in the internal review.
Thanks,
Serguei
On 4/6/16 02:56, Alexander Kulyakhtin wrote:
Alan,
What would be, the most suitable location for the test? I'm going to make sure
this new test does not duplicate any existing one a
Alan,
What would be, the most suitable location for the test? I'm going to make sure
this new test does not duplicate any existing one and, if not, will change the
patch accordingly then.
Best regards,
Alexander
- Original Message -
From: alan.bate...@oracle.com
To: alexander.kulyakh.
Alexander,
The test looks good for me.
But, as Alan says if the test is for JDI (but not SAJDI), please place
it to
.../jdk/test/com/sun/jdi
-Dmitry
On 2016-04-06 12:46, Alexander Kulyakhtin wrote:
> Hi,
>
> Could you, please, review, the following test-only changes (adding a new
> test).
>
On 06/04/2016 10:46, Alexander Kulyakhtin wrote:
Hi,
Could you, please, review, the following test-only changes (adding a new test).
CR: https://bugs.openjdk.java.net/browse/JDK-8153584 "New jtreg test to verify
PathSearchingVirutalMachine.bootClassPath() behaviour"
Webrev: http://cr.openjdk.j
Hi,
Could you, please, review, the following test-only changes (adding a new test).
CR: https://bugs.openjdk.java.net/browse/JDK-8153584 "New jtreg test to verify
PathSearchingVirutalMachine.bootClassPath() behaviour"
Webrev: http://cr.openjdk.java.net/~akulyakh/8153584/
The new test verifies
Per,
The fix looks good for me.
Copyright year of these tests is not updated.
GcCapacityTest.java
GcCauseTest01.java
GcTest02.java
-Dmitry
On 2016-04-06 12:32, Per Liden wrote:
> Summary: This patch updates the tests in serviceability/tmtools/jstat/
> to use a fixed (and relatively small) heap
Summary: This patch updates the tests in serviceability/tmtools/jstat/
to use a fixed (and relatively small) heap size. Without this these
tests tend to run out of memory on machines with VM overcommit disabled.
This has happened in nightly testing.
The patch also moves a misplaced @ignore tag
Yasumasa,
> Is it allowed?
Hmm. Lets go ahead with SAGetoptException.
-Dmitry
On 2016-04-06 02:15, Yasumasa Suenaga wrote:
> Hi Dmitry,
>
> Thanks for your comment.
>
>> So please use DebuggerException in SALauncher.
>
> DebuggerException will be thrown from many point in
> hotspot/src/jdk.h
21 matches
Mail list logo
