date:20160802

Re: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory

2016-08-02 Thread David Holmes


Looks good. Sorry I missed this issue in reviewing 8162524.

Thanks,
David

On 2/08/2016 10:58 PM, Markus Gronlund wrote:

Greetings,



Please review this small fix to address some new issues seen in testing
where OOM is erroneously being reported:



Bug: https://bugs.openjdk.java.net/browse/JDK-8162945



Changeset:



# HG changeset patch

# User mgronlun

# Date 1470141649 -7200

#  Tue Aug 02 14:40:49 2016 +0200

# Node ID e06e6474ff5f5798f9249aeaa6b33ec6aa021563

# Parent  9672159305d72f5dd430a3edd4b97c4e5bc816e0

[mq]: 8162945



diff --git a/src/jdk.management/share/native/libmanagement_ext/Flag.c
b/src/jdk.management/share/native/libmanagement_ext/Flag.c

--- a/src/jdk.management/share/native/libmanagement_ext/Flag.c

+++ b/src/jdk.management/share/native/libmanagement_ext/Flag.c

@@ -142,7 +142,7 @@

 continue;

 }

-if (valueObj == NULL) {

+if (valueObj == NULL && !(globals[i].type ==
JMM_VMGLOBAL_TYPE_JSTRING)) {

 free(globals);

 JNU_ThrowOutOfMemoryError(env, 0);

 return 0;





Summary:



OOM’s have manifested after the following change was integrated:

8162524: src/jdk.management/share/native/libmanagement_ext/Flag.c
doesn't handle JNI exceptions

The following check was then added to
jdk\src\jdk.management\share\native\libmanagement_ext\flags.c:

if (valueObj == NULL) {
free(globals);
JNU_ThrowOutOfMemoryError(env, 0);
return 0;
}

However, valueObj is not always the direct result of a failed JNI
allocation, for example:

case JMM_VMGLOBAL_TYPE_JSTRING:
valueObj = globals[i].value.l;

The valueObj here (a JSTRING) is coming a VM allocation, more
specifically from :



services/management.cpp jmm_GetVMGlobals()
...
add_global_entry()

} else if (flag->is_ccstr()) {
Handle str = java_lang_String::create_from_str(flag->get_ccstr(),
CHECK_false); <<--
global->value.l = (jobject)JNIHandles::make_local(env, str());
global->type = JMM_VMGLOBAL_TYPE_JSTRING;

For certain ccstr flags, such as  the "HeapDumpFlag" for example, the
ccstr() is NULL (i.e. not set).

So returning a NULL is fine here, the JNI NULL check validation needs to
take this into account.



Thanks

Markus

Re: RFR 8160833: ClassesByName2Test.java and RedefineCrossEvent.java failing with jtreg tip

2016-08-02 Thread David Holmes


Hi George,

On 3/08/2016 4:49 AM, George Triantafillou wrote:

Please review this small change to fix test failures in two JDI tests:


There's only one test changed in the webrev ??


JBS: https://bugs.openjdk.java.net/browse/JDK-8160833
Open webrev: http://cr.openjdk.java.net/~gtriantafill/8160833/webrev/


Thanks to Tim Bell for his assistance.  The fix replaces the use of
javax.rmi.CORBA.Util with String.format.  See this comment

for details.


So the assumption is that String.format will load a bunch of classes not 
already loaded? I assume the problem with javax.rmi.CORBA was module 
accessibility? Or does the Util class no longer exist?


  31  *  @modules java.corba

Presuambly this can be removed?

However this:

 56   java.awt.Toolkit tk = java.awt.Toolkit.getDefaultToolkit();

suggests we need @module java.desktop (which limits this test to running 
on a full JDK).


Thanks,
David


Tested locally on Linux with latest version of jtreg.

-George

(S) RFR: 8159461: bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or JavaThread

2016-08-02 Thread David Holmes


webrev: http://cr.openjdk.java.net/~dholmes/8159461/webrev/

bug: https://bugs.openjdk.java.net/browse/JDK-8159461

The suspend/resume signal (SR_signum) is never sent to a thread once it 
has started to terminate. On one platform (SuSE 12) we have seen what 
appears to be a "stuck" signal, which is only delivered when the 
terminating thread restores its original signal mask (as if 
pthread_sigmask makes the system realize there is a pending signal - we 
already check the signal was not blocked). At this point in the thread 
termination we have freed the osthread, so the the SR_handler would 
access deallocated memory. In debug builds we first hit an assertion 
that the current thread is a JavaThread or the VMThread - that assertion 
fails, even though it is a JavaThread, because we have already executed 
the ~JavaThread destructor and inside the ~Thread destructor we are a 
plain Thread not a JavaThread.


The fix was to make a small adjustment to the thread termination process 
so that we delete the SR_lock before calling os::free_thread(). In the 
SR_handler() we can then use a NULL check of SR_lock() to indicate the 
thread has terminated and we return.


While only seen on Linux I took the opportunity to apply the fix on all 
platforms and also cleaned up the code where we were using 
Thread::current() unsafely in a signal-handling context.


Testing: regular tier 1 (JPRT)
 Kitchensink (in progress)

As we can't readily reproduce the problem I tested this by having a 
terminating thread raise SR_signum directly from within the ~Thread 
destructor.


Thanks,
David

Re: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly

2016-08-02 Thread David Holmes


Hi Amit,

On 2/08/2016 7:49 PM, Amit Sapre wrote:

Hello,
I have made changes as David suggested.

Here is the new webrev link. 
http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.01/


If the changes are required to pass a JNI code checker then you will 
also need to check for exceptions from SetObjectArrayElement. While 
ArrayStoreException should not be possible in this code, I can't tell 
for certain that the passed in arrays are ensured to have the required 
lengths.


Thanks,
David


Thanks,
Amit

-Original Message-
From: David Holmes
Sent: Monday, August 01, 2016 12:33 PM
To: Amit Sapre; serviceability-dev
Subject: Re: RFR : JDK-8162530 : 
src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't 
handle JNI exceptions properly

Hi Amit,

On 1/08/2016 4:10 PM, Amit Sapre wrote:

Hello,



Please review JNI exception handling related changes.

Bug id : https://bugs.openjdk.java.net/browse/JDK-8162530

Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.00/


Sorry but that's wrong way to fix this. We should never just blindly clear 
exceptions and continue as if they never happened. If an exception is pending 
after one of these JNI calls the method should return immediately and allow the 
exception to propagate to the java code.

Thanks,
David




Thanks,

Amit

Re: RFR 8160833: ClassesByName2Test.java and RedefineCrossEvent.java failing with jtreg tip

2016-08-02 Thread Daniel D. Daugherty


Adding serviceability-dev@... alias since these are JDI tests...

Dan


On 8/2/16 12:49 PM, George Triantafillou wrote:

Please review this small change to fix test failures in two JDI tests:

JBS: https://bugs.openjdk.java.net/browse/JDK-8160833
Open webrev: http://cr.openjdk.java.net/~gtriantafill/8160833/webrev/ 



Thanks to Tim Bell for his assistance.  The fix replaces the use of 
javax.rmi.CORBA.Util with String.format.  See this comment 
 
for details.


Tested locally on Linux with latest version of jtreg.

-George

RE: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory

2016-08-02 Thread Markus Gronlund

Thanks Erik!

 

Markus

 

From: Erik Gahlin 
Sent: den 2 augusti 2016 15:33
To: serviceability-dev@openjdk.java.net
Subject: Re: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously 
reports OutOfMemory

 

Looks ok (not a reviewer)

Erik

On 2016-08-02 14:58, Markus Gronlund wrote:

Greetings,

 

Please review this small fix to address some new issues seen in testing where 
OOM is erroneously being reported:

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8162945

 

Changeset: 

 

# HG changeset patch

# User mgronlun

# Date 1470141649 -7200

#  Tue Aug 02 14:40:49 2016 +0200

# Node ID e06e6474ff5f5798f9249aeaa6b33ec6aa021563

# Parent  9672159305d72f5dd430a3edd4b97c4e5bc816e0

[mq]: 8162945

 

diff --git a/src/jdk.management/share/native/libmanagement_ext/Flag.c 
b/src/jdk.management/share/native/libmanagement_ext/Flag.c

--- a/src/jdk.management/share/native/libmanagement_ext/Flag.c

+++ b/src/jdk.management/share/native/libmanagement_ext/Flag.c

@@ -142,7 +142,7 @@

 continue;

 }

-if (valueObj == NULL) {

+if (valueObj == NULL && !(globals[i].type == 
JMM_VMGLOBAL_TYPE_JSTRING)) {

 free(globals);

 JNU_ThrowOutOfMemoryError(env, 0);

 return 0;

 

 

Summary:

 

OOM's have manifested after the following change was integrated: 

8162524: src/jdk.management/share/native/libmanagement_ext/Flag.c doesn't 
handle JNI exceptions 

The following check was then added to 
jdk\src\jdk.management\share\native\libmanagement_ext\flags.c: 

if (valueObj == NULL) { 
free(globals); 
JNU_ThrowOutOfMemoryError(env, 0); 
return 0; 
} 

However, valueObj is not always the direct result of a failed JNI allocation, 
for example:

case JMM_VMGLOBAL_TYPE_JSTRING: 
valueObj = globals[i].value.l; 

The valueObj here (a JSTRING) is coming a VM allocation, more specifically from 
:

 

services/management.cpp jmm_GetVMGlobals() 
... 
add_global_entry() 

} else if (flag->is_ccstr()) { 
Handle str = java_lang_String::create_from_str(flag->get_ccstr(), 
CHECK_false); <<-- 
global->value.l = (jobject)JNIHandles::make_local(env, str()); 
global->type = JMM_VMGLOBAL_TYPE_JSTRING; 

For certain ccstr flags, such as  the "HeapDumpFlag" for example, the ccstr() 
is NULL (i.e. not set). 

So returning a NULL is fine here, the JNI NULL check validation needs to take 
this into account.

 

Thanks

Markus

RE: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory

2016-08-02 Thread Markus Gronlund

Thanks Dan,

 

not too late at all  - I agree with your suggestion and will update accordingly.

 

Thanks again

Markus

 

From: Daniel D. Daugherty 
Sent: den 2 augusti 2016 18:29
To: Markus Gronlund; serviceability-dev@openjdk.java.net
Subject: Re: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously 
reports OutOfMemory

 

On 8/2/16 6:58 AM, Markus Gronlund wrote:



Greetings,

 

Please review this small fix to address some new issues seen in testing where 
OOM is erroneously being reported:

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8162945

 

Changeset: 

 

# HG changeset patch

# User mgronlun

# Date 1470141649 -7200

#  Tue Aug 02 14:40:49 2016 +0200

# Node ID e06e6474ff5f5798f9249aeaa6b33ec6aa021563

# Parent  9672159305d72f5dd430a3edd4b97c4e5bc816e0

[mq]: 8162945

 

diff --git a/src/jdk.management/share/native/libmanagement_ext/Flag.c 
b/src/jdk.management/share/native/libmanagement_ext/Flag.c

--- a/src/jdk.management/share/native/libmanagement_ext/Flag.c

+++ b/src/jdk.management/share/native/libmanagement_ext/Flag.c

@@ -142,7 +142,7 @@

 continue;

 }

-if (valueObj == NULL) {

+if (valueObj == NULL && !(globals[i].type == 
JMM_VMGLOBAL_TYPE_JSTRING)) {

 
Might be too late, but I would prefer:

if (valueObj == NULL && globals[i].type != JMM_VMGLOBAL_TYPE_JSTRING) {

which I think is more clear.

Dan





 free(globals);

 JNU_ThrowOutOfMemoryError(env, 0);

 return 0;

 

 

Summary:

 

OOM's have manifested after the following change was integrated: 

8162524: src/jdk.management/share/native/libmanagement_ext/Flag.c doesn't 
handle JNI exceptions 

The following check was then added to 
jdk\src\jdk.management\share\native\libmanagement_ext\flags.c: 

if (valueObj == NULL) { 
free(globals); 
JNU_ThrowOutOfMemoryError(env, 0); 
return 0; 
} 

However, valueObj is not always the direct result of a failed JNI allocation, 
for example:

case JMM_VMGLOBAL_TYPE_JSTRING: 
valueObj = globals[i].value.l; 

The valueObj here (a JSTRING) is coming a VM allocation, more specifically from 
:

 

services/management.cpp jmm_GetVMGlobals() 
... 
add_global_entry() 

} else if (flag->is_ccstr()) { 
Handle str = java_lang_String::create_from_str(flag->get_ccstr(), 
CHECK_false); <<-- 
global->value.l = (jobject)JNIHandles::make_local(env, str()); 
global->type = JMM_VMGLOBAL_TYPE_JSTRING; 

For certain ccstr flags, such as  the "HeapDumpFlag" for example, the ccstr() 
is NULL (i.e. not set). 

So returning a NULL is fine here, the JNI NULL check validation needs to take 
this into account.

 

Thanks

Markus

Re: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory

2016-08-02 Thread Daniel D. Daugherty


On 8/2/16 6:58 AM, Markus Gronlund wrote:


Greetings,

Please review this small fix to address some new issues seen in 
testing where OOM is erroneously being reported:


Bug: https://bugs.openjdk.java.net/browse/JDK-8162945

Changeset:

# HG changeset patch

# User mgronlun

# Date 1470141649 -7200

#  Tue Aug 02 14:40:49 2016 +0200

# Node ID e06e6474ff5f5798f9249aeaa6b33ec6aa021563

# Parent 9672159305d72f5dd430a3edd4b97c4e5bc816e0

[mq]: 8162945

diff --git a/src/jdk.management/share/native/libmanagement_ext/Flag.c 
b/src/jdk.management/share/native/libmanagement_ext/Flag.c


--- a/src/jdk.management/share/native/libmanagement_ext/Flag.c

+++ b/src/jdk.management/share/native/libmanagement_ext/Flag.c

@@ -142,7 +142,7 @@

 continue;

 }

-if (valueObj == NULL) {

+if (valueObj == NULL && !(globals[i].type == 
JMM_VMGLOBAL_TYPE_JSTRING)) {




Might be too late, but I would prefer:

if (valueObj == NULL && globals[i].type != JMM_VMGLOBAL_TYPE_JSTRING) {

which I think is more clear.

Dan



free(globals);

JNU_ThrowOutOfMemoryError(env, 0);

 return 0;

Summary:

OOM’s have manifested after the following change was integrated:

8162524: src/jdk.management/share/native/libmanagement_ext/Flag.c 
doesn't handle JNI exceptions


The following check was then added to 
jdk\src\jdk.management\share\native\libmanagement_ext\flags.c:


if (valueObj == NULL) {
free(globals);
JNU_ThrowOutOfMemoryError(env, 0);
return 0;
}

However, valueObj is not always the direct result of a failed JNI 
allocation, for example:


case JMM_VMGLOBAL_TYPE_JSTRING:
valueObj = globals[i].value.l;

The valueObj here (a JSTRING) is coming a VM allocation, more 
specifically from :


services/management.cpp jmm_GetVMGlobals()
...
add_global_entry()

} else if (flag->is_ccstr()) {
Handle str = java_lang_String::create_from_str(flag->get_ccstr(), 
CHECK_false); <<--

global->value.l = (jobject)JNIHandles::make_local(env, str());
global->type = JMM_VMGLOBAL_TYPE_JSTRING;

For certain ccstr flags, such as  the "HeapDumpFlag" for example, the 
ccstr() is NULL (i.e. not set).


So returning a NULL is fine here, the JNI NULL check validation needs 
to take this into account.


Thanks

Markus

Re: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory

2016-08-02 Thread Erik Gahlin


Looks ok (not a reviewer)

Erik

On 2016-08-02 14:58, Markus Gronlund wrote:


Greetings,

Please review this small fix to address some new issues seen in 
testing where OOM is erroneously being reported:


Bug: https://bugs.openjdk.java.net/browse/JDK-8162945

Changeset:

# HG changeset patch

# User mgronlun

# Date 1470141649 -7200

#  Tue Aug 02 14:40:49 2016 +0200

# Node ID e06e6474ff5f5798f9249aeaa6b33ec6aa021563

# Parent 9672159305d72f5dd430a3edd4b97c4e5bc816e0

[mq]: 8162945

diff --git a/src/jdk.management/share/native/libmanagement_ext/Flag.c 
b/src/jdk.management/share/native/libmanagement_ext/Flag.c


--- a/src/jdk.management/share/native/libmanagement_ext/Flag.c

+++ b/src/jdk.management/share/native/libmanagement_ext/Flag.c

@@ -142,7 +142,7 @@

 continue;

 }

-if (valueObj == NULL) {

+if (valueObj == NULL && !(globals[i].type == 
JMM_VMGLOBAL_TYPE_JSTRING)) {


free(globals);

JNU_ThrowOutOfMemoryError(env, 0);

 return 0;

Summary:

OOM’s have manifested after the following change was integrated:

8162524: src/jdk.management/share/native/libmanagement_ext/Flag.c 
doesn't handle JNI exceptions


The following check was then added to 
jdk\src\jdk.management\share\native\libmanagement_ext\flags.c:


if (valueObj == NULL) {
free(globals);
JNU_ThrowOutOfMemoryError(env, 0);
return 0;
}

However, valueObj is not always the direct result of a failed JNI 
allocation, for example:


case JMM_VMGLOBAL_TYPE_JSTRING:
valueObj = globals[i].value.l;

The valueObj here (a JSTRING) is coming a VM allocation, more 
specifically from :


services/management.cpp jmm_GetVMGlobals()
...
add_global_entry()

} else if (flag->is_ccstr()) {
Handle str = java_lang_String::create_from_str(flag->get_ccstr(), 
CHECK_false); <<--

global->value.l = (jobject)JNIHandles::make_local(env, str());
global->type = JMM_VMGLOBAL_TYPE_JSTRING;

For certain ccstr flags, such as  the "HeapDumpFlag" for example, the 
ccstr() is NULL (i.e. not set).


So returning a NULL is fine here, the JNI NULL check validation needs 
to take this into account.


Thanks

Markus

RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory

2016-08-02 Thread Markus Gronlund

Greetings,

 

Please review this small fix to address some new issues seen in testing where 
OOM is erroneously being reported:

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8162945

 

Changeset: 

 

# HG changeset patch

# User mgronlun

# Date 1470141649 -7200

#  Tue Aug 02 14:40:49 2016 +0200

# Node ID e06e6474ff5f5798f9249aeaa6b33ec6aa021563

# Parent  9672159305d72f5dd430a3edd4b97c4e5bc816e0

[mq]: 8162945

 

diff --git a/src/jdk.management/share/native/libmanagement_ext/Flag.c 
b/src/jdk.management/share/native/libmanagement_ext/Flag.c

--- a/src/jdk.management/share/native/libmanagement_ext/Flag.c

+++ b/src/jdk.management/share/native/libmanagement_ext/Flag.c

@@ -142,7 +142,7 @@

 continue;

 }

-if (valueObj == NULL) {

+if (valueObj == NULL && !(globals[i].type == 
JMM_VMGLOBAL_TYPE_JSTRING)) {

 free(globals);

 JNU_ThrowOutOfMemoryError(env, 0);

 return 0;

 

 

Summary:

 

OOM's have manifested after the following change was integrated: 

8162524: src/jdk.management/share/native/libmanagement_ext/Flag.c doesn't 
handle JNI exceptions 

The following check was then added to 
jdk\src\jdk.management\share\native\libmanagement_ext\flags.c: 

if (valueObj == NULL) { 
free(globals); 
JNU_ThrowOutOfMemoryError(env, 0); 
return 0; 
} 

However, valueObj is not always the direct result of a failed JNI allocation, 
for example:

case JMM_VMGLOBAL_TYPE_JSTRING: 
valueObj = globals[i].value.l; 

The valueObj here (a JSTRING) is coming a VM allocation, more specifically from 
:

 

services/management.cpp jmm_GetVMGlobals() 
... 
add_global_entry() 

} else if (flag->is_ccstr()) { 
Handle str = java_lang_String::create_from_str(flag->get_ccstr(), 
CHECK_false); <<-- 
global->value.l = (jobject)JNIHandles::make_local(env, str()); 
global->type = JMM_VMGLOBAL_TYPE_JSTRING; 

For certain ccstr flags, such as  the "HeapDumpFlag" for example, the ccstr() 
is NULL (i.e. not set). 

So returning a NULL is fine here, the JNI NULL check validation needs to take 
this into account.

 

Thanks

Markus

Re: JDK 9 RFR of 8161970, 8157664: Remove 4 tools tests from ProblemList.txt

2016-08-02 Thread Dmitry Samersoff

Amy,

Looks good for me!

-Dmitry


On 2016-08-02 08:57, Amy Lu wrote:
> tools/jlink/JLinkOptimTest.java
> This test has been removed in JDK-8160829
> 
> sun/tools/jinfo/JInfoSanityTest.java
> sun/tools/jinfo/JInfoRunningProcessFlagTest.java
> sun/tools/jmap/heapconfig/JMapHeapConfigTest.java
> These tests have been removed in JDK-8155091
> 
> Please review the patch to delete these tests from ProblemList.txt.
> 
> bug:
> https://bugs.openjdk.java.net/browse/JDK-8161970
> https://bugs.openjdk.java.net/browse/JDK-8157664
> 
> webrev: http://cr.openjdk.java.net/~amlu/8161970-8157664/webrev.00/
> 
> Thanks,
> Amy
> 
> --- old/test/ProblemList.txt  2016-08-02 13:44:34.0 +0800
> +++ new/test/ProblemList.txt  2016-08-02 13:44:34.0 +0800
> @@ -318,7 +318,7 @@
>  
>  
>  
> -# jdk_tools
> +# core_tools
>  
>  tools/pack200/CommandLineTests.java 
> 7143279,8059906 generic-all
>  
> @@ -368,20 +368,14 @@
>  
>  sun/tools/jcmd/TestJcmdSanity.java  8031482 
> windows-all
>  
> -sun/tools/jmap/heapconfig/JMapHeapConfigTest.java   
> 8072131,8132452 generic-all
> -
>  sun/tools/jstatd/TestJstatdExternalRegistry.java8046285 
> generic-all
>  
>  sun/tools/jps/TestJpsJar.java   8160923 
> generic-all
>  
>  sun/tools/jps/TestJpsJarRelative.java   6456333 
> generic-all
>  
> -sun/tools/jinfo/JInfoRunningProcessFlagTest.java6734748 
> generic-all
> -
>  sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java8057732 
> generic-all
>  
> -sun/tools/jinfo/JInfoSanityTest.java8059035 
> generic-all
> -
>  demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java   8151899 
> generic-all
>  
>  
> @@ -391,9 +385,3 @@
>  com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java   8141370 
> linux-i586,macosx-all
>  
>  
> -
> -# core_tools
> -
> -tools/jlink/JLinkOptimTest.java 8159264 
> generic-all
> -
> -
> 
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

Re: JDK 9 RFR of 8161970, 8157664: Remove 4 tools tests from ProblemList.txt

2016-08-02 Thread Sundararajan Athijegannathan

+1 for the jlink test being removed from the problem test.

-Sundar

On 8/2/2016 11:27 AM, Amy Lu wrote:
> tools/jlink/JLinkOptimTest.java
> This test has been removed in JDK-8160829
>
> sun/tools/jinfo/JInfoSanityTest.java
> sun/tools/jinfo/JInfoRunningProcessFlagTest.java
> sun/tools/jmap/heapconfig/JMapHeapConfigTest.java
> These tests have been removed in JDK-8155091
>
> Please review the patch to delete these tests from ProblemList.txt.
>
> bug:
> https://bugs.openjdk.java.net/browse/JDK-8161970
> https://bugs.openjdk.java.net/browse/JDK-8157664
>
> webrev: http://cr.openjdk.java.net/~amlu/8161970-8157664/webrev.00/
>
> Thanks,
> Amy
>
> --- old/test/ProblemList.txt  2016-08-02 13:44:34.0 +0800
> +++ new/test/ProblemList.txt  2016-08-02 13:44:34.0 +0800
> @@ -318,7 +318,7 @@
>  
>  
>  
> -# jdk_tools
> +# core_tools
>  
>  tools/pack200/CommandLineTests.java 
> 7143279,8059906 generic-all
>  
> @@ -368,20 +368,14 @@
>  
>  sun/tools/jcmd/TestJcmdSanity.java  8031482 
> windows-all
>  
> -sun/tools/jmap/heapconfig/JMapHeapConfigTest.java   
> 8072131,8132452 generic-all
> -
>  sun/tools/jstatd/TestJstatdExternalRegistry.java8046285 
> generic-all
>  
>  sun/tools/jps/TestJpsJar.java   8160923 
> generic-all
>  
>  sun/tools/jps/TestJpsJarRelative.java   6456333 
> generic-all
>  
> -sun/tools/jinfo/JInfoRunningProcessFlagTest.java6734748 
> generic-all
> -
>  sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java8057732 
> generic-all
>  
> -sun/tools/jinfo/JInfoSanityTest.java8059035 
> generic-all
> -
>  demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java   8151899 
> generic-all
>  
>  
> @@ -391,9 +385,3 @@
>  com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java   8141370 
> linux-i586,macosx-all
>  
>  
> -
> -# core_tools
> -
> -tools/jlink/JLinkOptimTest.java 8159264 
> generic-all
> -
> -
>

RE: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly

2016-08-02 Thread Amit Sapre

Hello,
I have made changes as David suggested.

Here is the new webrev link. 
http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.01/ 

Thanks,
Amit

-Original Message-
From: David Holmes 
Sent: Monday, August 01, 2016 12:33 PM
To: Amit Sapre; serviceability-dev
Subject: Re: RFR : JDK-8162530 : 
src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't 
handle JNI exceptions properly

Hi Amit,

On 1/08/2016 4:10 PM, Amit Sapre wrote:
> Hello,
>
>
>
> Please review JNI exception handling related changes.
>
> Bug id : https://bugs.openjdk.java.net/browse/JDK-8162530
>
> Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.00/

Sorry but that's wrong way to fix this. We should never just blindly clear 
exceptions and continue as if they never happened. If an exception is pending 
after one of these JNI calls the method should return immediately and allow the 
exception to propagate to the java code.

Thanks,
David

>
>
> Thanks,
>
> Amit
>

Re: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory

Re: RFR 8160833: ClassesByName2Test.java and RedefineCrossEvent.java failing with jtreg tip

(S) RFR: 8159461: bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or JavaThread

Re: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly

Re: RFR 8160833: ClassesByName2Test.java and RedefineCrossEvent.java failing with jtreg tip

RE: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory

RE: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory

Re: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory

Re: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory

RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory

Re: JDK 9 RFR of 8161970, 8157664: Remove 4 tools tests from ProblemList.txt

Re: JDK 9 RFR of 8161970, 8157664: Remove 4 tools tests from ProblemList.txt

RE: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly

13 matches

Site Navigation

Mail list logo

Footer information