Re: RFR(XS) 8241696: ProblemList gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java due to JDK-8241293

[Christian Tornqvist]

Hi Chris,

Looks good, thanks for fixing this.

Thanks,
Christian

> On Mar 26, 2020, at 1:27 PM, Chris Plummer  wrote:
> 
> Hello,
> 
> Please review the following:
> 
> https://bugs.openjdk.java.net/browse/JDK-8241696
> 
> diff --git a/test/hotspot/jtreg/ProblemList.txt 
> b/test/hotspot/jtreg/ProblemList.txt
> --- a/test/hotspot/jtreg/ProblemList.txt
> +++ b/test/hotspot/jtreg/ProblemList.txt
> @@ -85,7 +85,7 @@
>  gc/stress/gclocker/TestGCLockerWithParallel.java 8180622 generic-all
>  gc/stress/gclocker/TestGCLockerWithG1.java 8180622 generic-all
>  gc/stress/TestJNIBlockFullGC/TestJNIBlockFullGC.java 8192647 generic-all
> -gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java 8193639 solaris-all
> +gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java 8193639,8241293 
> solaris-all,macosx-x64
> 
> thanks,
> 
> Chris
> 

Re: RFR(T): 8241532: ProblemList tests from 8241530 on OSX

[Christian Tornqvist]

Looks good, thanks for doing this.

Thanks,
Christian

> On Mar 24, 2020, at 10:01 AM, Daniel D. Daugherty 
>  wrote:
> 
> Greetings,
> 
> I have a trivial review for ProblemListing some tests.
> 
> We're having some network issues with the new OSX 10.15 machines that
> are being addressed. In the mean time, I'm trying to reduce the noise
> in the CI in Tier5 and Tier6 so I'm ProblemListing the affected tests:
> 
> $ hg diff
> diff -r 23dab0354eb0 test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txtTue Mar 24 17:39:52 2020 +0100
> +++ b/test/jdk/ProblemList.txtTue Mar 24 12:57:43 2020 -0400
> @@ -604,6 +604,10 @@
>  com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java 8030957 
> aix-all
>  com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java 8030957 
> aix-all
> 
> +sun/management/jdp/JdpDefaultsTest.java 8241530 macosx-all
> +sun/management/jdp/JdpJmxRemoteDynamicPortTest.java 8241530 macosx-all
> +sun/management/jdp/JdpSpecificAddressTest.java 8241530 macosx-all
> +
>  
> 
>  # jdk_jmx
> @@ -924,6 +928,9 @@
> 
>  com/sun/jdi/InvokeHangTest.java 8218463 linux-all
> 
> +com/sun/jdi/JdwpAttachTest.java 8241530 macosx-all
> +com/sun/jdi/JdwpListenTest.java 8241530 macosx-all
> +
>  
> 
>  # jdk_time
> 
> Thanks, in advance, for any comments, questions or suggestions.
> 
> Dan
> 

Re: RFR 8149790: NegativeArraySizeException with hprof

[Christian Tornqvist]

Hi George,

This looks good.

Thanks,
Christian

> On Aug 14, 2017, at 11:31 AM, George Triantafillou 
>  wrote:
> 
> Please review this change to fix NegativeArraySizeException test failures 
> with hprof:
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8149790 
> 
> webrev: 
> http://cr.openjdk.java.net/~gtriantafill/8149790-webrev/webrev/index.html 
> 
> The original patch was contributed by Andreas Eriksson.  Tested locally on 
> Linux-x64 and with RBT tiers 2 through 5.
> Thanks.
> 
> -George

RE: RFR: JDK-8165114: stale reference to hotspot test Test8028623.java

[Christian Tornqvist]

Do we still need the compact groups? I thought the @modules selection in
jtreg will make sure that we don't run tests where the module isn't
available.

-Original Message-
From: serviceability-dev
[mailto:serviceability-dev-boun...@openjdk.java.net] On Behalf Of David
Holmes
Sent: Friday, September 2, 2016 4:46 AM
To: Sharath Ballal <sharath.bal...@oracle.com>;
serviceability-dev@openjdk.java.net
Subject: Re: RFR: JDK-8165114: stale reference to hotspot test
Test8028623.java

On 2/09/2016 5:47 PM, Sharath Ballal wrote:
> Hi David,
> I had a similar doubt and checked with Christian Tornqvist regarding 
> the
same.  He mentioned that the directory containing the new test is already
part of two test groups, hence I need not add anything for the new test.
>
> The sun/tools folder is part of two test groups:
>
> jdk_launcher = \
> tools/launcher \
> sun/tools
>
> svc_tools = \
> com/sun/tools/attach \
> sun/tools \
> -sun/tools/java \
> -sun/tools/jrunscript \
> sun/jvmstat \
> demo/jvmti

The test needs to remain in the needs_compact3 group, neither of the above
groups contribute to that.

David
-

>
> -Sharath Ballal
>
>
>
> -Original Message-
> From: David Holmes
> Sent: Friday, September 02, 2016 1:07 PM
> To: Sharath Ballal; serviceability-dev@openjdk.java.net
> Subject: Re: RFR: JDK-8165114: stale reference to hotspot test
Test8028623.java
>
> Hi Sharath,
>
> On 1/09/2016 6:00 PM, Sharath Ballal wrote:
>> Hello,
>>
>> Please review this fix to remove stale test reference:
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8165114
>>
>> Webrev: http://cr.openjdk.java.net/~sballal/8165114/webrev.00/
>
> If the test has moved then the entry has to move from
hotspot/test/TEST.groups to jdk/test/TEST.groups.
>
> Thanks,
> David
>
>>
>>
>> -Sharath Ballal
>>
>>
>>
>>
>>

RE: JDK-8164943: sun/tools/jhsdb/HeapDumpTest failed with Can't find library: /test/lib/share/classes

[Christian Tornqvist]

Hi Sharath,

 

This looks good, thanks for fixing this.

 

Thanks,

Christian

 

From: serviceability-dev
[mailto:serviceability-dev-boun...@openjdk.java.net] On Behalf Of Sharath
Ballal
Sent: Thursday, September 1, 2016 12:37 AM
To: serviceability-dev@openjdk.java.net
Subject: RFR: JDK-8164943: sun/tools/jhsdb/HeapDumpTest failed with Can't
find library: /test/lib/share/classes

 

Please review this fix to change /test/lib/share/classes to /test/lib/ in
the test:

 

Issue: https://bugs.openjdk.java.net/browse/JDK-8164943 

 

Webrev: http://cr.openjdk.java.net/~sballal/8164943/webrev.00/ 

 

-Sharath Ballal

RE: PING! Re: RFR(XS): JDK-8160923: sun/tools/jps/TestJpsJar.java fails due to ClassNotFoundException: jdk.testlibrary.ProcessTools

[Christian Tornqvist]

Hi Dmitry,

You don't need to explicitly build JpsHelper, I also noticed that you're using 
ProcessTools and OutputAnalyzer from /lib/testlibrary , would it make sense to 
change this to use the /test/lib ones and simply have:

@library /test/lib  

?

Thanks,
Christian
-Original Message-
From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-boun...@openjdk.java.net] 
On Behalf Of Dmitry Samersoff
Sent: Tuesday, August 23, 2016 3:02 PM
To: Ioi Lam ; serviceability-dev@openjdk.java.net; 
hotspot-runtime-dev 
Subject: Re: PING! Re: RFR(XS): JDK-8160923: sun/tools/jps/TestJpsJar.java 
fails due to ClassNotFoundException: jdk.testlibrary.ProcessTools

Ioi,

Thank you for review.

Hmm. It looks like changes below solves the problem.

- * @build jdk.testlibrary.* JpsHelper JpsBase
+ * @build JpsHelper JpsBase

I'm running rbt job to verify it.

-Dmitry

On 2016-08-23 16:10, Ioi Lam wrote:
> Hi Dmitry,
>
> Why are you adding /test/lib:
>
> - * @library /lib/testlibrary
> + * @library /lib/testlibrary /test/lib
>
> The only class used by jdk/test/sun/tools/jps/*.java in /test/lib is here:
>
> TestJpsSanity.java:import jdk.test.lib.apps.LingeredApp;
>
> But TestJpsSanity.java is not use by this test -- I ran the test with 
> your patch in a clean jtreg directory and the test passed, but I don't 
> see TestJpsSanity.class, or any jdk.test.lib.* class.
>
> So I don't think you need to add /test/lib.
>
> - Ioi
>
> On 8/23/16 5:34 AM, Dmitry Samersoff wrote:
>> On 2016-08-17 10:51, Dmitry Samersoff wrote:
>>> Everybody,
>>>
>>> Please review the changes:
>>>
>>>http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.01/
>>>
>>> -Dmitry
>>>
>>
>


--
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: RFR:8153978:New test to verify the modules info as returned by the JVMTI

[Christian Tornqvist]

Hi Alexander,

 

This looks good, thanks for adding this :)

 

Thanks,

Christian

 

From: Alexander Kulyakhtin [mailto:alexander.kulyakh...@oracle.com] 
Sent: Friday, July 22, 2016 8:57 AM
To: christian.tornqv...@oracle.com
Cc: serguei.spit...@oracle.com; serviceability-dev@openjdk.java.net
Subject: Re: RFR:8153978:New test to verify the modules info as returned by the 
JVMTI

 

Hi Christian,

Yes, my intention was to check the equality of the returned data.

I've changed line 68 to:

Asserts.assertEquals(Layer.boot().modules(), getModulesJVMTI());

and removed line 90 since it's not needed.

As to the  line 76, that is how Netbeans has formatted the code. I've changed 
it to have {} on the same line now.

Please, find the updated review at: 
http://cr.openjdk.java.net/~akulyakh/8153978_7/test/serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java.html

Best regards,
Alexander



- Original Message -
From: christian.tornqv...@oracle.com <mailto:christian.tornqv...@oracle.com> 
To: alexander.kulyakh...@oracle.com <mailto:alexander.kulyakh...@oracle.com> , 
serguei.spit...@oracle.com <mailto:serguei.spit...@oracle.com> 
Cc: serviceability-dev@openjdk.java.net 
<mailto:serviceability-dev@openjdk.java.net> 
Sent: Friday, July 22, 2016 3:50:09 PM GMT +03:00 Iraq
Subject: RE: RFR:8153978:New test to verify the modules info as returned by the 
JVMTI




Hi Alexander,

 

As Serguei said, the lines 68 and 90 doesn’t check the results so they should 
either do that or be removed. If you remove those lines, you can remove the 
filtering out of unnamed modules in getModulesJVMTI as well since that will no 
longer be necessary.

 

Minor style thing, move the } on 76 to be on the same line as the opening {. 

 

Thanks,

Christian

 

From: Alexander Kulyakhtin [mailto:alexander.kulyakh...@oracle.com] 
Sent: Friday, July 22, 2016 7:40 AM
To: serguei.spit...@oracle.com <mailto:serguei.spit...@oracle.com> 
Cc: christian.tornqv...@oracle.com <mailto:christian.tornqv...@oracle.com> ; 
serviceability-dev@openjdk.java.net 
<mailto:serviceability-dev@openjdk.java.net> 
Subject: Re: RFR:8153978:New test to verify the modules info as returned by the 
JVMTI

 

Hi Sergey,

Thank you very much for the review.  I'm going to wait for any other findings 
today and, if everything is fine, will push the fix then.

Best regards,
Alexander

- Original Message -
From: serguei.spit...@oracle.com <mailto:serguei.spit...@oracle.com> 
To: alexander.kulyakh...@oracle.com <mailto:alexander.kulyakh...@oracle.com> , 
christian.tornqv...@oracle.com <mailto:christian.tornqv...@oracle.com> 
Cc: serviceability-dev@openjdk.java.net 
<mailto:serviceability-dev@openjdk.java.net> 
Sent: Friday, July 22, 2016 11:31:13 AM GMT +03:00 Iraq
Subject: Re: RFR:8153978:New test to verify the modules info as returned by the 
JVMTI

Alexander,

A thumbs up on the push.
I leave it up to you and Christian to tweak and polish the test if you think it 
is necessary.

Thank you a lot for working on it!

Thanks,
Serguei


On 7/21/16 14:05, serguei.spit...@oracle.com 
<mailto:serguei.spit...@oracle.com>  wrote:

On 7/21/16 11:35, serguei.spit...@oracle.com 
<mailto:serguei.spit...@oracle.com>  wrote:

Hi Alexander,

JvmtiGetAllModulesTest.java

  It looks pretty good but it would be nice if there is any chance to simplify 
even more.
  However, I can't suggest anything at the moment.


  67 // Verify that JVMTI reports exactly the same info as Java regarding the 
named modules
  68 Layer.boot().equals(getModulesJVMTI()); 69 
  . . .
  89 // Verify the consistency of the whole JVMTI report again
  90 Layer.boot().equals(getModulesJVMTI()); 91 

 The above lines can be removed.
 They even do not check the result of comparison.

Thanks,
Serguei




 


libJvmtiGetAllModulesTest.c

  Unneeded indent for all lines.
  Otherwise, it is good.

Thanks,
Serguei



On 7/21/16 10:14, Alexander Kulyakhtin wrote:

Christian, Sergey,

I've modified the test per your findings. Now it is one java file and one C 
file only.

Please, find the updated review at:

Webrev:  http://cr.openjdk.java.net/~akulyakh/8153978_6/ 
<http://cr.openjdk.java.net/%7Eakulyakh/8153978_6/> 

Thank you very much for your help.

Best regards,
Alexander


- Original Message -
From: serguei.spit...@oracle.com <mailto:serguei.spit...@oracle.com> 
To: christian.tornqv...@oracle.com <mailto:christian.tornqv...@oracle.com> , 
alexander.kulyakh...@oracle.com <mailto:alexander.kulyakh...@oracle.com> 
Cc: serviceability-dev@openjdk.java.net 
<mailto:serviceability-dev@openjdk.java.net> 
Sent: Thursday, July 21, 2016 6:39:21 PM GMT +03:00 Iraq
Subject: Re: RFR:8153978:New test to verify the modules info as returned by the 
JVMTI

On 7/21/16 08:29, Christian Tornqvist wrote:

Hi Alexander,

 

>The JVMTI always reports 3 unnamed modules: the boot module, the 

RE: RFR:8153978:New test to verify the modules info as returned by the JVMTI

[Christian Tornqvist]

Hi Alexander,

 

As Serguei said, the lines 68 and 90 doesn’t check the results so they should 
either do that or be removed. If you remove those lines, you can remove the 
filtering out of unnamed modules in getModulesJVMTI as well since that will no 
longer be necessary.

 

Minor style thing, move the } on 76 to be on the same line as the opening {. 

 

Thanks,

Christian

 

From: Alexander Kulyakhtin [mailto:alexander.kulyakh...@oracle.com] 
Sent: Friday, July 22, 2016 7:40 AM
To: serguei.spit...@oracle.com
Cc: christian.tornqv...@oracle.com; serviceability-dev@openjdk.java.net
Subject: Re: RFR:8153978:New test to verify the modules info as returned by the 
JVMTI

 

Hi Sergey,

Thank you very much for the review.  I'm going to wait for any other findings 
today and, if everything is fine, will push the fix then.

Best regards,
Alexander

- Original Message -
From: serguei.spit...@oracle.com <mailto:serguei.spit...@oracle.com> 
To: alexander.kulyakh...@oracle.com <mailto:alexander.kulyakh...@oracle.com> , 
christian.tornqv...@oracle.com <mailto:christian.tornqv...@oracle.com> 
Cc: serviceability-dev@openjdk.java.net 
<mailto:serviceability-dev@openjdk.java.net> 
Sent: Friday, July 22, 2016 11:31:13 AM GMT +03:00 Iraq
Subject: Re: RFR:8153978:New test to verify the modules info as returned by the 
JVMTI

Alexander,

A thumbs up on the push.
I leave it up to you and Christian to tweak and polish the test if you think it 
is necessary.

Thank you a lot for working on it!

Thanks,
Serguei


On 7/21/16 14:05, serguei.spit...@oracle.com 
<mailto:serguei.spit...@oracle.com>  wrote:

On 7/21/16 11:35, serguei.spit...@oracle.com 
<mailto:serguei.spit...@oracle.com>  wrote:

Hi Alexander,

JvmtiGetAllModulesTest.java

  It looks pretty good but it would be nice if there is any chance to simplify 
even more.
  However, I can't suggest anything at the moment.


  67 // Verify that JVMTI reports exactly the same info as Java regarding the 
named modules
  68 Layer.boot().equals(getModulesJVMTI()); 69 
  . . .
  89 // Verify the consistency of the whole JVMTI report again
  90 Layer.boot().equals(getModulesJVMTI()); 91 

 The above lines can be removed.
 They even do not check the result of comparison.

Thanks,
Serguei





 


libJvmtiGetAllModulesTest.c

  Unneeded indent for all lines.
  Otherwise, it is good.

Thanks,
Serguei



On 7/21/16 10:14, Alexander Kulyakhtin wrote:

Christian, Sergey,

I've modified the test per your findings. Now it is one java file and one C 
file only.

Please, find the updated review at:

Webrev:  http://cr.openjdk.java.net/~akulyakh/8153978_6/ 
<http://cr.openjdk.java.net/%7Eakulyakh/8153978_6/> 

Thank you very much for your help.

Best regards,
Alexander


- Original Message -
From: serguei.spit...@oracle.com <mailto:serguei.spit...@oracle.com> 
To: christian.tornqv...@oracle.com <mailto:christian.tornqv...@oracle.com> , 
alexander.kulyakh...@oracle.com <mailto:alexander.kulyakh...@oracle.com> 
Cc: serviceability-dev@openjdk.java.net 
<mailto:serviceability-dev@openjdk.java.net> 
Sent: Thursday, July 21, 2016 6:39:21 PM GMT +03:00 Iraq
Subject: Re: RFR:8153978:New test to verify the modules info as returned by the 
JVMTI

On 7/21/16 08:29, Christian Tornqvist wrote:

Hi Alexander,

 

>The JVMTI always reports 3 unnamed modules: the boot module, the system module 
>and the application module. 

>The Java API does not report any unnamed modules.

 

I’ll leave this up to you if this is something that we need to verify or not, 
the code for doing this is also overcomplicated and can be reduced to a simple 
assertGTE.


The rule is that there is one unnamed module per a class loader.
The options are: to test this rule or remove the check.
For simplicity is better to remove this check as unclear.

Thanks,
Serguei




 

>This should be doable without using JAR's and custom loaders by using 
>Layer.defineModules(), see the examples in 
>jdk/test/java/lang/reflect/Layer/BasicLayerTest.java

>The test has been written from the user perspective. The user loads a new 
>module in the form of jar using the ModuleLoader.loadModule() API. Then the 
>test checks that JVMTI does return the info about that loaded module.

>Probably, defining the module using Layer.defineModules would not be the same 
>as loading the module using ModuleLoader.loadModule(), since the JVMTI 
>GetAllModules() returns the info about all the currently loaded modules.

>As the JVMTI spec says: "GetAllModules: Return an array of all modules loaded 
>in the virtual machine.", it does not mention defining modules.

 

There are several ways to get modules loaded/defined, the Layer.defineModules 
is part of the official Java API and is one of them. It doesn’t matter to JVMTI 
if they come from JAR files on disk or if they’re defined using a Java API, so 
I suggest you go with Lay

RE: RFR:8153978:New test to verify the modules info as returned by the JVMTI

[Christian Tornqvist]

Hi Alexander,

 

>The JVMTI always reports 3 unnamed modules: the boot module, the system module 
>and the application module. 

>The Java API does not report any unnamed modules.

 

I’ll leave this up to you if this is something that we need to verify or not, 
the code for doing this is also overcomplicated and can be reduced to a simple 
assertGTE.

 

>This should be doable without using JAR's and custom loaders by using 
>Layer.defineModules(), see the examples in 
>jdk/test/java/lang/reflect/Layer/BasicLayerTest.java

>The test has been written from the user perspective. The user loads a new 
>module in the form of jar using the ModuleLoader.loadModule() API. Then the 
>test checks that JVMTI does return the info about that loaded module.

>Probably, defining the module using Layer.defineModules would not be the same 
>as loading the module using ModuleLoader.loadModule(), since the JVMTI 
>GetAllModules() returns the info about all the currently loaded modules.

>As the JVMTI spec says: "GetAllModules: Return an array of all modules loaded 
>in the virtual machine.", it does not mention defining modules.

 

There are several ways to get modules loaded/defined, the Layer.defineModules 
is part of the official Java API and is one of them. It doesn’t matter to JVMTI 
if they come from JAR files on disk or if they’re defined using a Java API, so 
I suggest you go with Layer.defineModules.

 

Thanks,

Christian

 

From: Alexander Kulyakhtin [mailto:alexander.kulyakh...@oracle.com] 
Sent: Thursday, July 21, 2016 10:04 AM
To: Serguei Vladimirovich Spitsyn ; 
christian.tornqv...@oracle.com
Cc: serviceability-dev@openjdk.java.net
Subject: Re: RFR:8153978:New test to verify the modules info as returned by the 
JVMTI

 

Christian,

Thank you very much for your comments. I have some concerns about the proposed 
changes:

@45 & @67 

Why is this check needed? Why are there least 3 unnamed modules?
The JVMTI always reports 3 unnamed modules: the boot module, the system module 
and the application module. 
The Java API does not report any unnamed modules.

@54

This should be doable without using JAR's and custom loaders by using 
Layer.defineModules(), see the examples in 
jdk/test/java/lang/reflect/Layer/BasicLayerTest.java
The test has been written from the user perspective. The user loads a new 
module in the form of jar using the ModuleLoader.loadModule() API. Then the 
test checks that JVMTI does return the info about that loaded module.
Probably, defining the module using Layer.defineModules would not be the same 
as loading the module using ModuleLoader.loadModule(), since the JVMTI 
GetAllModules() returns the info about all the currently loaded modules.
As the JVMTI spec says: "GetAllModules: Return an array of all modules loaded 
in the virtual machine.", it does not mention defining modules.

Could you, please, clarify these points for me so I fix the test appropriately?

Best regards,
Alexander

 





- Original Message -
From: christian.tornqv...@oracle.com  
To: alexander.kulyakh...@oracle.com  , 
serviceability-dev@openjdk.java.net 
 
Sent: Wednesday, July 20, 2016 8:11:14 PM GMT +03:00 Iraq
Subject: RE: RFR:8153978:New test to verify the modules info as returned by 
   the JVMTI




Hi Alexander,

 

This test is unnecessarily complicated, it could be simplified a lot.

JvmtiGetAllModulesTest.java

 

Move getModulesNative() into JvmtiGetAllModulesTest.java and have it return a 
Set to be able to use equals later

 

@27  * @compile JvmtiGetAllModulesTest.java

No need for this, jtreg will compile it for you

  

@45 & @67 

Why is this check needed? Why are there least 3 unnamed modules?

 

@50

Change this to: assertTrue(Layer.boot().equals(getModulesNative()));

 

@54

This should be doable without using JAR's and custom loaders by using 
Layer.defineModules(), see the examples in 
jdk/test/java/lang/reflect/Layer/BasicLayerTest.java

 

@65

Change this to an assertTrue using the layer containing the new module, similar 
to the change @50

 

@73

No need for this method

 

@81

Change this method to use the Layer.defineModules() method to define a module 
instead, this eliminates the need for external JAR's 

 

@98

No need for this method

 

If you use Layer.defineModules(), the following files can be removed:

JarBuilder.java

JavaModulesInfo.java

JvmtiModulesInfo.java

ModuleLoader.java 

ModulesInfo.java 

module-info.java

 

Thanks,

Christian

 

From: serviceability-dev [mailto:serviceability-dev-boun...@openjdk.java.net] 
On Behalf Of serguei.spit...@oracle.com  
Sent: Monday, May 2, 2016 6:06 PM
To: Alexander Kulyakhtin  >; Serviceability-Dev 

RE: Jigsaw Enhancement RFR: 8159145 Add JVMTI function GetModuleByPackageName

[Christian Tornqvist]

Hi Serguei,

 

>Will check if this works well in this case.

>The unique error messages are already printed in the native code.

 

Yes, they’re printed on stdout/stderr but the test will fail with a “Test 
failed” exception and our failure matching system wouldn’t be able to tell why 
it failed. It’d be a lot nicer if it’d just throw an exception when one of the 
checks in the native code failed.

 

Thanks,

Christian

 

From: serguei.spit...@oracle.com [mailto:serguei.spit...@oracle.com] 
Sent: Tuesday, June 21, 2016 10:59 AM
To: Christian Tornqvist <christian.tornqv...@oracle.com>; 'Alan Bateman' 
<alan.bate...@oracle.com>; serviceability-dev@openjdk.java.net; 'Alexander 
Kulyakhtin' <alexander.kulyakh...@oracle.com>; hotspot-...@openjdk.java.net
Subject: Re: Jigsaw Enhancement RFR: 8159145 Add JVMTI function 
GetModuleByPackageName

 

Hi Christian,

Thank you for looking at it!


On 6/21/16 04:56, Christian Tornqvist wrote:

Hi Serguei,

 

I’ve only looked at the test code so far, here are some comments:

 

* You’re not allowed to call System.exit in a jtreg test. If something fails, 
you need to throw an exception.


Ok, an exception is Ok with me.




* Instead of a run() method you could simply collapse all this into the main 
method like this:

 

assertEQ(check(), 0);


Will check if this works for me.







 

* Would it make sense to throw exceptions with useful error messages from the 
JNI code instead of returning failed status codes? Our error matching system 
would work a lot better with unique error messages.


Will check if this works well in this case.
The unique error messages are already printed in the native code. 

Thanks,
Serguei




 

Thanks,

Christian

 

From: serguei.spit...@oracle.com <mailto:serguei.spit...@oracle.com>  
[mailto:serguei.spit...@oracle.com] 
Sent: Tuesday, June 21, 2016 6:49 AM
To: Alan Bateman  <mailto:alan.bate...@oracle.com> <alan.bate...@oracle.com>; 
serviceability-dev@openjdk.java.net 
<mailto:serviceability-dev@openjdk.java.net> ; Christian Törnqvist  
<mailto:christian.tornqv...@oracle.com> <christian.tornqv...@oracle.com>; 
Alexander Kulyakhtin  <mailto:alexander.kulyakh...@oracle.com> 
<alexander.kulyakh...@oracle.com>; hotspot-...@openjdk.java.net 
<mailto:hotspot-...@openjdk.java.net>  Developers  
<mailto:hotspot-...@openjdk.java.net> <hotspot-...@openjdk.java.net>
Subject: Re: Jigsaw Enhancement RFR: 8159145 Add JVMTI function 
GetModuleByPackageName

 

On 6/21/16 03:23, Alan Bateman wrote:

 

 

On 21/06/2016 10:54, serguei.spit...@oracle.com 
<mailto:serguei.spit...@oracle.com>  wrote:


Please, review the Jigsaw fix for the enhancement:
  https://bugs.openjdk.java.net/browse/JDK-8159145


The Hotspot webrev:
  
http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/

The Jdk webrev:
  
http://javaweb.sfbay.sun.com/java/svc/ss45998/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/

Serguei - can you put the patches on cr.openjdk.java.net?


Sorry.
My initial plan was to write an nsk.jvmti test and review it on a confidential 
mailing list.
It is why I put the webrevs on the non-public server.
Forgot to switch the server when the test was converted into the jtreg format.

The public webrevs are:

Hotspot:
  
http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/
 
<http://cr.openjdk.java.net/%7Esspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.1/>
 

Jdk:
  
http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/
 
<http://cr.openjdk.java.net/%7Esspitsyn/webrevs/2016/hotspot/8159145-jigsaw-jvmti-pkg.jdk1/>
 


Thanks,
Serguei







-Alan

 

 

RE: RFR:8153978:New test to verify the modules info as returned by the JVMTI

[Christian Tornqvist]

Hi Serguei,

 

Yes, this is path is set in the make files/scripts that run jtreg. 

 

Thanks,

Christian

 

From: serguei.spit...@oracle.com [mailto:serguei.spit...@oracle.com] 
Sent: Tuesday, June 21, 2016 5:39 AM
To: Christian Tornqvist <christian.tornqv...@oracle.com>; 'Alexander 
Kulyakhtin' <alexander.kulyakh...@oracle.com>
Cc: serviceability-dev@openjdk.java.net
Subject: Re: RFR:8153978:New test to verify the modules info as returned by the 
JVMTI

 

On 6/21/16 01:54, serguei.spit...@oracle.com 
<mailto:serguei.spit...@oracle.com>  wrote:

Ok, I've found how to work around my problem below.

The flag -nativepath needs to be passed to the jtreg:
  
-nativepath:/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/test/hotspot/jtreg/native


Question:
   Is this flag passed when the jtreg tests are run in the nightly?
   Do I have to adjust anything in order to make new test with the native agent 
to pass in nightly?

Thanks,
Serguei





Thanks,
Serguei


On 6/21/16 00:46, serguei.spit...@oracle.com 
<mailto:serguei.spit...@oracle.com>  wrote:

Hi Christian and Alexander,

Not sure if my code is correct but I can not pass through the following agent 
library load error:

Error occurred during initialization of VM
Could not find agent library GetModuleByPkgTest1 on the library path, with 
error: libGetModuleByPkgTest1.so: cannot open shared object file: No such file 
or directory


I'm using the following shell script to run my test:

#!/bin/sh

IMAGES=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images
JAVA_HOME=$IMAGES/jdk
export LD_LIBRARY_PATH=$IMAGES/test/hotspot/jtreg/native

# /java/re/jtreg/4.2/nightly/binaries/jtreg/bin/jtreg \

/java/re/jtreg/4.2/promoted/latest/binaries/jtreg/bin/jtreg \
 -J-Dtest.java.opts='-Xmixed -server' \
 -jdk ${JAVA_HOME} -Dtest.java.opts='-Xmixed -server' \
 
/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java



The jtreg lines are:

% cat -50 
test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java
/*
 * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
 * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
 */

/**
 * @test
 * @summary Verifies the JVMTI GetModuleByPackageName API
 * @compile GetModuleByPkgTest1.java
 * @run main/othervm -agentlib:GetModuleByPkgTest1 GetModuleByPkgTest1
 */
 . . .

Please, let me know if you see anything wrong in my testing environment.
Below is the full .jtr log.

Thanks,
Serguei

cat ./JTwork/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.jtr
#Test Results (version 2)
#Tue Jun 21 00:33:26 PDT 2016
#checksum:265f9695e52dbedb
#-testdescription-
$file=/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java
$root=/var/tmp/sspitsyn/jdk9/hotspot/test
keywords=othervm
run=USER_SPECIFIED compile GetModuleByPkgTest1.java\nUSER_SPECIFIED 
main/othervm -agentlib\:GetModuleByPkgTest1 GetModuleByPkgTest1\n
source=GetModuleByPkgTest1.java
title=Verifies the JVMTI GetModuleByPackageName API

#-environment-

#-testresult-
description=file\:/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java
elapsed=2061 0\:00\:02.061
end=Tue Jun 21 00\:33\:26 PDT 2016
environment=regtest
execStatus=Failed. Unexpected exit from test [exit code\: 1]
hostname=sc11137378.us.oracle.com
javatestOS=Linux 3.2.0-55-generic (amd64)
javatestVersion=4.4
jtregVersion=jtreg 4.2 fcs b02
script=com.sun.javatest.regtest.RegressionScript 
sections=script_messages compile build main
start=Tue Jun 21 00\:33\:24 PDT 2016
test=serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java
testJDK=/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk
user.name=sspitsyn
work=/var/tmp/sspitsyn/tst/jdk9/JTwork/serviceability/jvmti/GetModuleByPackageName

#section:script_messages
--messages:(5/324)--
JDK under test: 
/var/tmp/sspitsyn/jdk9/build/linux-x86_64-normal-server-fastdebug/images/jdk
java version "9-internal"
Java(TM) SE Runtime Environment (fastdebug build 
9-internal+0-2016-06-09-145126.sspitsyn.jdk9)
Java HotSpot(TM) 64-Bit Server VM (fastdebug build 
9-internal+0-2016-06-09-145126.sspitsyn.jdk9, mixed mode)


#section:compile
--messages:(4/233)--
command: compile 
/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName/GetModuleByPkgTest1.java
reason: User specified action: run compile GetModuleByPkgTest1.java 
Mode: othervm
elapsed time (seconds): 1.7
--configuration:(4/227)--
javac compilation environment
  class path: 
/var/tmp/sspitsyn/jdk9/hotspot/test/serviceability/jvmti/GetModuleByPackageName 
  
/var/tmp/sspitsyn/tst/jdk9/JTwork/classes/serviceability/jvmti/GetModuleByPackageName
 

--rerun:(21/1677)*--
DI

RE: RFR:8153978:New test to verify the modules info as returned by the JVMTI

[Christian Tornqvist]

Hi Serguei,

 

We’re currently using jtreg 4.2 b02, so you should be able to do this.

 

Thanks,

Christian

 

From: serviceability-dev [mailto:serviceability-dev-boun...@openjdk.java.net] 
On Behalf Of serguei.spit...@oracle.com
Sent: Friday, June 17, 2016 7:39 PM
To: Alexander Kulyakhtin 
Cc: serviceability-dev@openjdk.java.net
Subject: Re: RFR:8153978:New test to verify the modules info as returned by the 
JVMTI

 

Hi Alexander,

I'm curious if the jtreg 4.2 is out and this test can be pushed now?
I'd want to use the same pattern to write the Jigsaw related JVMTI tests.

Thanks,
Serguei


On 5/5/16 04:25, Alexander Kulyakhtin wrote:

Sergey,

Thank you very much for the review. 
I will be pushing the fix as soon as jtreg 4.2 is out, since 4.2  has the fix 
for CODETOOLS-7901662, required for this test.

Best regards,
Alexander

From: serguei.spit...@oracle.com  
To: alexander.kulyakh...@oracle.com  
Cc: serviceability-dev@openjdk.java.net 
 , aleksey.voyti...@oracle.com 
 
Sent: Wednesday, May 4, 2016 11:31:07 PM GMT +03:00 Iraq
Subject: Re: RFR:8153978:New test to verify the modules info as returned by the 
JVMTI

Hi Alexander,

It looks good.
Thank you for making the changes!

Thanks,
Serguei



On 5/4/16 05:17, Alexander Kulyakhtin wrote:

Hi Sergey,

Thank you very much for the review.

Please, find the updated webrev with your findings corrected at: 
http://cr.openjdk.java.net/~akulyakh/8153978_02/index.html 
 

Best regards,
Alexander

- Original Message -
From: serguei.spit...@oracle.com  
To: alexander.kulyakh...@oracle.com  , 
serviceability-dev@openjdk.java.net 
 
Cc: aleksey.voyti...@oracle.com  
Sent: Tuesday, May 3, 2016 1:06:05 AM GMT +03:00 Iraq
Subject: Re: RFR:8153978:New test to verify the modules info as returned by the 
JVMTI

Hi Alexander,


Could you, fix a couple of minor issues?

test/serviceability/jvmti/GetModulesInfo/JvmtiGetAllModulesTest.java

  58 for(Module mod : my.modules()) {
  59 if(!jvmtiModules.contains(mod)) {
 
  A space is missed after the 'for' and 'if' keywords.


test/serviceability/jvmti/GetModulesInfo/ModulesInfo.java.

  31 boolean compareExcludingUnnamed(ModulesInfo other) {
 
  I'd suggest to call it compareNamed.


Otherwise, the new test looks great.
Thanks a lot for taking care about it!

Thanks,
Serguei



On 4/29/16 06:12, Alexander Kulyakhtin wrote:

Hi, 
 
Could you, please, review these test-only changes (adding a new test).
 
CR: https://bugs.openjdk.java.net/browse/JDK-8153978 "New test to verify the 
modules info as returned by the JVMTI"
Webrev: http://cr.openjdk.java.net/~akulyakh/8153978_01/ 
 
 
The new test verifies that JVMTI returns the correct info about the modules 
loaded at the application startup. 
It also verifies that the returned info is consistent with the same info 
returned by the Java API.
It then loads a new named module and checks the correctness of the JVMTI info 
again.
 
Due to a tools issue https://bugs.openjdk.java.net/browse/CODETOOLS-7901662 the 
test can only be pushed in when the updated jtreg is released.
The test passes fine with the nightly jtreg build, containing the 
CODETOOLS-7901662 fix.
 
Best regards,
Alexander

 

 

 

Re: RFR(XXS): 8156777: [TESTBUG] test/testlibrary_tests/SimpleClassFileLoadHookTest.java requires non minimal VM

[Christian Tornqvist]

Hi Leonid,

Change looks good.

Thanks,
Christian

> On May 11, 2016, at 12:36 PM, Leonid Mesnik  wrote:
> 
> Hi 
> 
> Could you please review this extra small fix which add @requires to the 
> single test. This test is not compatible with minimal VM even it doesn't 
> require any specific modules outside compact2. So I've just added 
> corresponding @requires.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8156777
> 
> Tested by manual jtreg execution with -minimal/-client/default vm options. 
> 
> Fix inlined:
> --- a/test/testlibrary_tests/SimpleClassFileLoadHookTest.java Wed May 11 
> 02:32:14 2016 -0400
> +++ b/test/testlibrary_tests/SimpleClassFileLoadHookTest.java Wed May 11 
> 19:24:34 2016 +0300
> @@ -24,7 +24,7 @@
>  /*
>   * @test
>   * @library /testlibrary
> - *
> + * @requires vm.flavor != "minimal"
>   * @run main/othervm/native -agentlib:SimpleClassFileLoadHook=Foo,XXX,YYY
>   *  SimpleClassFileLoadHookTest
>   */
> 
> Leonid

RE: RFR(XS) 8155727: java/util/concurrent/locks/Lock/TimedAcquireLeak.java timeouts.

[Christian Tornqvist]

Hi Harold,

This looks good, thanks for fixing this!

Thanks,
Christian

-Original Message-
From: serviceability-dev [mailto:serviceability-dev-boun...@openjdk.java.net] 
On Behalf Of harold seigel
Sent: Friday, April 29, 2016 2:01 PM
To: serviceability-dev@openjdk.java.net
Subject: RFR(XS) 8155727: java/util/concurrent/locks/Lock/TimedAcquireLeak.java 
timeouts.

Hi,

Please review this extra small fix for test TimedAcquireLeak.java.  The test 
was broken by the recent change to add module information to the JMAP class 
histogram.  This fixes the test's regular expression to handle the possible 
additional module information.

Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8155727/

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

Thanks! Harold

RE: RFR: JDK-8151196 Several tests fail due to test library not found

[Christian Tornqvist]

Hi Staffan,

Looks good, thanks for fixing this.

Thanks,
Christian

-Original Message-
From: serviceability-dev
[mailto:serviceability-dev-boun...@openjdk.java.net] On Behalf Of Staffan
Larsen
Sent: Wednesday, March 9, 2016 5:03 AM
To: Bengt Rutisson 
Cc: serviceability-dev@openjdk.java.net; hotspot-gc-...@openjdk.java.net
Subject: Re: RFR: JDK-8151196 Several tests fail due to test library not
found

Good catch. Incremental change:

diff --git a/test/gc/g1/plab/TestPLABResize.java
b/test/gc/g1/plab/TestPLABResize.java
--- a/test/gc/g1/plab/TestPLABResize.java
+++ b/test/gc/g1/plab/TestPLABResize.java
@@ -27,7 +27,7 @@
  * @summary Test for PLAB resizing
  * @requires vm.gc=="G1" | vm.gc=="null"
  * @requires vm.opt.FlightRecorder != true
- * @library /testlibrary /../../test/lib /
+ * @library /testlibrary /test/lib /
  * @modules java.management
  * @build ClassFileInstaller
  *sun.hotspot.WhiteBox

> On 9 mars 2016, at 10:54, Bengt Rutisson 
wrote:
> 
> 
> Hi Staffan,
> 
> Changes look good.
> 
> However it looks like this test has the same issue, right?
>
http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/59d3a69564dc/test/gc/g1
/plab/TestPLABResize.java
> 
> It is currently ignored, but we should probably fix it too...
> 
> Thanks,
> Bengt
> 
> On 2016-03-09 10:47, Staffan Larsen wrote:
>> Please review this small fix to some tests with the wrong paths in
them. Tested locally with jtreg 4.1 b12 and b13.
>> 
>> Thanks,
>> /Staffan
>> 
>> 
>> $ hg diff
>> diff --git a/test/gc/g1/plab/TestPLABPromotion.java
b/test/gc/g1/plab/TestPLABPromotion.java
>> --- a/test/gc/g1/plab/TestPLABPromotion.java
>> +++ b/test/gc/g1/plab/TestPLABPromotion.java
>> @@ -27,7 +27,7 @@
>>   * @summary Test PLAB promotion
>>   * @requires vm.gc=="G1" | vm.gc=="null"
>>   * @requires vm.opt.FlightRecorder != true
>> - * @library /testlibrary /../../test/lib /
>> + * @library /testlibrary /test/lib /
>>   * @modules java.management
>>   * @build ClassFileInstaller
>>   *sun.hotspot.WhiteBox
>> diff --git a/test/serviceability/dcmd/gc/HeapDumpAllTest.java
b/test/serviceability/dcmd/gc/HeapDumpAllTest.java
>> --- a/test/serviceability/dcmd/gc/HeapDumpAllTest.java
>> +++ b/test/serviceability/dcmd/gc/HeapDumpAllTest.java
>> @@ -35,7 +35,7 @@
>>   * @build jdk.test.lib.hprof.*
>>   * @build jdk.test.lib.hprof.model.*
>>   * @build jdk.test.lib.hprof.parser.*
>> - * @build jdk.test.lib.hprof.utils.*
>> + * @build jdk.test.lib.hprof.util.*
>>   * @build HeapDumpTest
>>   * @run testng HeapDumpAllTest
>>   */
>> diff --git a/test/serviceability/dcmd/gc/HeapDumpTest.java
b/test/serviceability/dcmd/gc/HeapDumpTest.java
>> --- a/test/serviceability/dcmd/gc/HeapDumpTest.java
>> +++ b/test/serviceability/dcmd/gc/HeapDumpTest.java
>> @@ -51,7 +51,7 @@
>>   * @build jdk.test.lib.hprof.*
>>   * @build jdk.test.lib.hprof.model.*
>>   * @build jdk.test.lib.hprof.parser.*
>> - * @build jdk.test.lib.hprof.utils.*
>> + * @build jdk.test.lib.hprof.util.*
>>   * @run testng HeapDumpTest
>>   */
>>  public class HeapDumpTest {
> 

RE: RFR: JDK-8075586: add @modules as needed to the open hotspot tests

[Christian Tornqvist]

Hi Alex,

I assume you've run all the tests and that they are still passing? 

The @module changes looks good.  As Lois pointed out, you need to update the 
copyrights and this should be done as part of this change.

Thanks,
Christian

-Original Message-
From: serviceability-dev [mailto:serviceability-dev-boun...@openjdk.java.net] 
On Behalf Of Alexander Kulyakhtin
Sent: Tuesday, March 24, 2015 10:05 AM
To: lois.fol...@oracle.com
Cc: hotspot-...@openjdk.java.net; serviceability-dev@openjdk.java.net; 
alexandre.il...@oracle.com
Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests

Lois,

Thank you very much for your findings. 

We are going to remove the blank comments as you have suggested. If possible, 
however, we would prefer to pursue the copyrights issue under a different CR as 
this is another and not strictly related bulk change, which, probably, can be 
best achieved by an unrelated, script. 

I believe, there already is a separate CR for updating the copyrights. However 
if there's no such CR we are going to create a new one.

Do you think it could be possible to have a separate CR for the copyrights 
issue (and if necessary to submit a new one)?

Best regards,
Alex 


- Original Message -
From: lois.fol...@oracle.com
To: yekaterina.kantser...@oracle.com
Cc: serviceability-dev@openjdk.java.net, staffan.lar...@oracle.com, 
hotspot-...@openjdk.java.net, alexander.kulyakh...@oracle.com, 
alexandre.il...@oracle.com
Sent: Tuesday, March 24, 2015 3:57:54 PM GMT +04:00 Abu Dhabi / Muscat
Subject: Re: RFR: JDK-8075586: add @modules as needed to the open hotspot tests


This looks good, thank you for making these changes!  A couple of comments that 
I don't feel need another webrev but should be fixed before pushing.

 - copyrights on all the tests need to be updated
 - the following tests have a blank comment line before the new @modules 
line that could be removed
   test/gc/metaspace/TestMetaspacePerfCounters.java
   test/runtime/contended/Basic.java
   test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java
   test/compiler/cpuflags/RestoreMXCSR.java
   test/compiler/debug/VerifyAdapterSharing.java

Thanks,
Lois

On 3/24/2015 8:09 AM, Yekaterina Kantserova wrote:
 Notifying hotspot-dev as well.

 // Katja



 On 03/24/2015 11:48 AM, Alexander Kulyakhtin wrote:
 Could the reviewers, please, have a look at the proposed changes below?

 In addition, we are going to make a change to the TEST.ROOT file as 
 indicated by Staffan in the mail below.

 Do you think the changes (plus the one-line change to the TEST.ROOT) 
 can be pushed into the jdk?

 Best regards,
 Alex

 - Original Message -
 From: staffan.lar...@oracle.com
 To: alexander.kulyakh...@oracle.com
 Cc: serviceability-dev@openjdk.java.net, alexandre.il...@oracle.com
 Sent: Friday, March 20, 2015 7:39:10 PM GMT +04:00 Abu Dhabi / Muscat
 Subject: Re: RFR: JDK-8075586: add @modules as needed to the open 
 hotspot tests

 I haven’t looked at the changes in detail, but please change the 
 requiredVersion in TEST.ROOT to 4.1 b11 as part of this change.

 Thanks,
 /Staffan

 On 20 mar 2015, at 13:16, Alexander Kulyakhtin 
 alexander.kulyakh...@oracle.com wrote:

 Hi,

 Could you, please, review the fix below.

 CR: https://bugs.openjdk.java.net/browse/JDK-8075586
 webrev: 
 http://cr.openjdk.java.net/~tpivovarova/akulyakh/8075586/webrev.00/

 The fix adds @modules keyword to the existing hotspot tests, as 
 needed, so that the tests can access the required API when the new 
 modular architecture is in place.

 Best regards,
 Alex

RE: RFR(XXS): 8074905: Exclude aarch64 from Visual Studio projectcreator.make

[Christian Tornqvist]

Hi Markus,

 

This looks good, thanks for fixing this.

 

Thanks,

Christian

 

From: serviceability-dev
[mailto:serviceability-dev-boun...@openjdk.java.net] On Behalf Of Markus
Gronlund
Sent: Tuesday, March 10, 2015 5:02 PM
To: hotspot-runtime-...@openjdk.java.net;
serviceability-dev@openjdk.java.net
Subject: RFR(XXS): 8074905: Exclude aarch64 from Visual Studio
projectcreator.make

 

Greetings,

 

Please review this small update to the Visual Studio projectcreator.make in
order to exclude aarch64 files.

 

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

Webrev: http://cr.openjdk.java.net/~mgronlun/8074905/webrev01/

 

 

Thanks

Markus

RE: RFR(XXS): 8068584: Compiler attach tests should be quarantined

[Christian Tornqvist]

Looks good.

Thanks,
Christian

-Original Message-
From: serviceability-dev [mailto:serviceability-dev-boun...@openjdk.java.net] 
On Behalf Of Mattias Tobiasson
Sent: Thursday, January 8, 2015 7:45 AM
To: Mikael Auno; serviceability-dev@openjdk.java.net
Subject: Re: RFR(XXS): 8068584: Compiler attach tests should be quarantined

Thanks for the explanation.
I have moved the @ignore tags to directly before the first @run tag.

webrev: http://cr.openjdk.java.net/~ykantser/8068584/webrev.01/
http://cr.openjdk.java.net/%7Eykantser/8068584/webrev.01/

Mattias


On 01/08/2015 11:21 AM, Mikael Auno wrote:
 On 2015-01-08 11:04, Mattias Tobiasson wrote:
 Hi,
 Could I please have a review of this bug quarantine.

 bug: https://bugs.openjdk.java.net/browse/JDK-8068584
 webrev: http://cr.openjdk.java.net/~ykantser/8068584/webrev.00/

 Thanks,
 Mattias

 Mattias,

 In the two **/Launcher.java tests, you must place @ignore after the 
 @library line, otherwise there will be a Parse Exception: `@library'
 must appear before first `@run'. (The error message is, to say the 
 least, a bit unintuitive until you figure out that @ignore is just 
 an alias for @run ignore.)

 Mikael

RE: 8055677 java/lang/instrument/RedefineBigClass.sh RetransformBigClass.sh start failing after JDK-8055012

[Christian Tornqvist]

Hi Staffan,

This looks good, thanks for fixing this.

Thanks,
Christian

-Original Message-
From: serviceability-dev
[mailto:serviceability-dev-boun...@openjdk.java.net] On Behalf Of Staffan
Larsen
Sent: Thursday, August 21, 2014 6:16 AM
To: serviceability-dev@openjdk.java.net
Subject: RFR: 8055677 java/lang/instrument/RedefineBigClass.sh
RetransformBigClass.sh start failing after JDK-8055012

This failure happens because the test look for the string Exception in the
output of the program to signal a failure. With the improved version of NMT,
the output from NMT sometimes includes this string in a stack trace. The
solution I've implemented is to redirect the NMT output to a file instead of
having it on stdout.

bug: https://bugs.openjdk.java.net/browse/JDK-8055677
webrev: http://cr.openjdk.java.net/~sla/8055677/webrev.00/

Thanks,
/Staffan

RFR(XS): 8055012 - [TESTBUG] NMTHelper fails to parse NMT output

[Christian Tornqvist]

Hi,

 

This is a small update to NMTHelper.java to make it work with recent changes
in the NMT implementation that changed the output format a bit.

 

I've tested the change locally using
java\lang\instrument\RedefineBigClass.sh and
java\lang\instrument\RetransformBigClass.sh

 

Webrev doesn't seem to like whitespace-only changes so I can't post a
webrev, I'm pasting the diff here instead:

 

diff -r 362a6ea9bc84 test/java/lang/instrument/NMTHelper.java

--- a/test/java/lang/instrument/NMTHelper.java  Thu Aug 14 15:54:04 2014
-0700

+++ b/test/java/lang/instrument/NMTHelper.java  Fri Aug 15 10:43:15 2014
-0400

@@ -32,8 +32,8 @@

 executeDcmd(vmNativeMemory, baseline);

 }

 

-// Total:  reserved=3484685KB  +293KB, committed=266629KB +293KB

-private static Pattern totalLine = Pattern.compile(^Total:
reserved=\\d+KB  .*KB, committed=\\d+KB (.*)KB$);

+// Total: reserved=3484685KB +293KB, committed=266629KB +293KB

+private static Pattern totalLine = Pattern.compile(^Total:
reserved=\\d+KB .*KB, committed=\\d+KB (.*)KB$);

 

 public static long committedDiff() throws Exception {

 String res = (String) executeDcmd(vmNativeMemory, detail.diff);

 

Bug:

https://bugs.openjdk.java.net/browse/JDK-8055012

 

Thanks,

Christian

RE: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java fails intermittently

[Christian Tornqvist]

I can't remember if there was a reason for doing it like this, but it seems
reasonable to not catch the InterruptedException in getOutput().

 

Thanks,

Christian

 

From: Staffan Larsen [mailto:staffan.lar...@oracle.com] 
Sent: Friday, June 27, 2014 4:49 AM
To: shanliang
Cc: Jaroslav Bachorik; serviceability-dev@openjdk.java.net
serviceability-dev@openjdk.java.net; Christian Tornqvist
Subject: Re: RFR JDK-8031554: com/sun/tools/attach/BasicTests.java fails
intermittently

 

It does look suspicious to catch and ignore the InterruptedException,
especially since the OutputAnalyzer constructor will fail in this case. 

 

Christian is the original author of these classes: do you know if there is a
good rationale for doing this? Or should we propagate the
InterruptedException?

 

Thanks,

/Staffan

 

On 26 jun 2014, at 17:24, shanliang shanliang.ji...@oracle.com
mailto:shanliang.ji...@oracle.com  wrote:





Jaroslav Bachorik wrote:



Hi Shanliang,

On 06/26/2014 03:15 PM, shanliang wrote:



Hi,

Today ProcessTools.executeProcess has the code:
new OutputAnalyzer(pb.start());

and OutputAnalyzer constructor calls immediately:
exitValue = process.exitValue();

the test got exception because the process did not end.


Are you sure about this?

The OutputAnalyzer constructor, before calling process.exitValue(), calls
ProcessTools.getOutput(process) which actually does process.waitFor()

Good catch!




A probable explanation would be that process.waitFor() gets interrupted
without the target process actually ending.

Either the result of ProcessTools.getOutput() should be checked for null to
detect this situation or ProcessTools.getOutput() should throw a more
aggressive exception when waitFor() gets interrupted.

It was possible beacause of an InterruptedException, but maybe a Process
issue too.

process.waitFor() was called by the test main thread, I am wondering who
wanted to interrupt this thread?

Not know why ProcessTools.getOutput() catches InterruptedException and then
returns null, are there some other tests dependent to this behavior?
otherwise better to not catch InterruptedException.

I think to keep this modification, it will allow us to get more information
if the bug is reproduced, if getting an InterruptedException then we need to
do more investigation for why, if no exception then we may rise a question
to process.waitFor().

Shanliang




-JB-





So a direct solution for the test is not to call:
   ProcessTools.executeTestJvm(args);

but:
ProcessBuilder pb =
ProcessTools.createJavaProcessBuilder(Utils.addTestJavaOpts(args));
Process process = pb.start();
process.waitFor();
OutputAnalyzer output = new OutputAnalyzer(process);

here we do waiting:
process.waitFor();
before constructing an OutputAnalyzer.

ProcessTools is a tool class we may have same issue for other tests
using this class. So we may need to improve the test library.

bug: https://bugs.openjdk.java.net/browse/JDK-8031554
webrev: http://cr.openjdk.java.net/~sjiang/JDK-8031554/00/


Thanks,
Shanliang

 

hg: hsx/hotspot-rt/hotspot: 8023796: [TESTBUG] Add -XX:-TransmitErrorReport to runtime/6888954/vmerrors.sh

[christian . tornqvist]

Changeset: cc4f5f8d885e
Author:mseledtsov
Date:  2013-10-06 16:13 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cc4f5f8d885e

8023796: [TESTBUG] Add -XX:-TransmitErrorReport to runtime/6888954/vmerrors.sh
Summary: added -XX:-TransmitErrorReport to the test
Reviewed-by: stefank, ctornqvi

! test/runtime/6888954/vmerrors.sh
! test/runtime/memory/ReserveMemory.java

hg: hsx/hotspot-rt/hotspot: 8025671: Test name changed, test list not updated. Test6878713.sh

[christian . tornqvist]

Changeset: d574419c5372
Author:mseledtsov
Date:  2013-10-02 15:17 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d574419c5372

8025671: Test name changed, test list not updated. Test6878713.sh
Summary: Removed the obsolete test from the test group file
Reviewed-by: sla, ctornqvi, dholmes

! test/TEST.groups

hg: hsx/hotspot-rt/hotspot: 2 new changesets

[christian . tornqvist]

Changeset: 5b1191bf0b4b
Author:ctornqvi
Date:  2013-09-25 17:47 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5b1191bf0b4b

8024677: [TESTBUG] Move tests for classes in /testlibrary
Summary: Moved the tests to /testlibrary_tests and updated TEST.groups
Reviewed-by: dholmes, sla

! test/TEST.groups
- test/testlibrary/AssertsTest.java
- test/testlibrary/OutputAnalyzerReportingTest.java
- test/testlibrary/OutputAnalyzerTest.java
+ test/testlibrary_tests/AssertsTest.java
+ test/testlibrary_tests/OutputAnalyzerReportingTest.java
+ test/testlibrary_tests/OutputAnalyzerTest.java

Changeset: c1fbf21c7397
Author:ctornqvi
Date:  2013-09-25 17:47 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c1fbf21c7397

8024492: [TESTBUG] Test library class Platform.java needs to include methods 
for missing OS's and architectures
Summary: Added methods for 32bit, arm, ppc, x64 and x86
Reviewed-by: zgu, hseigel, mseledtsov

! test/testlibrary/com/oracle/java/testlibrary/Platform.java

RE: 7196151: ParserTest SEGv on solaris

[Christian Tornqvist]

Looks good!

 

Thanks,

Christian

 

From: hotspot-runtime-dev-boun...@openjdk.java.net
[mailto:hotspot-runtime-dev-boun...@openjdk.java.net] On Behalf Of Peter
Allwin
Sent: Tuesday, September 17, 2013 11:44 AM
To: serviceability-dev@openjdk.java.net;
hotspot-runtime-...@openjdk.java.net
Subject: RFR: 7196151: ParserTest SEGv on solaris

 

Hello!

 

Please review this small fix for an issue where jio_snprintf may be called
with a null argument causing SEGV on Solaris. This can occur if to_string is
called on a GenDCmdArgumentchar* with no default value.

 

cr: http://cr.openjdk.java.net/~allwin/7196151/webrev.00/

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

 

 

serviceability/ParserTest.java reproduces this issue and the fix has been
verified with this test.

 

 

Thanks!

/peter

hg: hsx/hotspot-rt/hotspot: 2 new changesets

[christian . tornqvist]

Changeset: 88d6b9a1c27c
Author:mseledtsov
Date:  2013-09-17 20:09 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/88d6b9a1c27c

8016029: test runtime/6878713/Test6878713.sh failed
Summary: Rewrote test in Java; updated the test condition to reflect latest 
changes in the source
Reviewed-by: dholmes, ctornqvi

- test/runtime/6878713/Test6878713.sh
- test/runtime/6878713/testcase.jar
+ test/runtime/ClassFile/OomWhileParsingRepeatedJsr.java
+ test/runtime/ClassFile/testcase.jar

Changeset: 6f45933aef35
Author:mseledtsov
Date:  2013-09-17 20:20 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/6f45933aef35

7149464: [TESTBUG] Test runtime/7020373/Test7020373.sh failed to clean up files 
after test
Summary: Re-wrote in Java, this also eliminated temporary result file; set 
upper limit on malloc'd memory
Reviewed-by: dcubed, dholmes, ccheung

- test/runtime/7020373/Test7020373.sh
- test/runtime/7020373/testcase.jar
+ test/runtime/ClassFile/JsrRewriting.java
+ test/runtime/ClassFile/JsrRewritingTestCase.jar

RE: RFR: 8020962: dump loaded java classes when vm crash

[Christian Tornqvist]

I agree with Coleen, this change should not be added to the JVM. 

Though I'd like to have the tool to create this archive from a core/mdmp. If 
this is not already present in any of the j*-tools we might want to look into 
adding it, please work with the serviceability team to determine where this 
would be best suited.

Thanks,
Christian

-Original Message-
From: Coleen Phillimore [mailto:coleen.phillim...@oracle.com] 
Sent: Monday, August 12, 2013 5:44 PM
To: Yumin Qi
Cc: Christian Tornqvist; serviceability-dev@openjdk.java.net 
serviceability-dev@openjdk.java.net; 'hotspot compiler'; 'David Holmes'; 
hotspot-runtime-...@openjdk.java.net
Subject: Re: RFR: 8020962: dump loaded java classes when vm crash


Yumin,

I don't think this change should be added to the JVM for the following reasons.

1. Error handling should only contain safe actions.   We have concerns 
that the SA is not that stable and would prevent getting a real core 
file in many error situations.   You couldn't have tested all error 
situations because these are usually the things we don't know about.   
You also mention that there are currently bugs preventing this feature from 
working in your first email.

2. I am not convinced that having a separate jar file with loaded classes (is 
it a list that SA generates?) would be collected by an error 
reporter.   If it's collected, I don't see how helpful it would be.  
Also a customer may not want their classes disclosed in error reporting.

3.  This doesn't seem important enough to include as a new feature in 
jdk8 release, which is feature-complete.   I don't see a customer 
request for it.

Coleen

On 08/12/2013 01:00 PM, Yumin Qi wrote:
 Chris, David

   Yes. This can be after crash with core file, but some time no core 
 file generated (also if the error could not repeat, we will never got 
 information again), so dumping  target process is also a choice. To 
 avoid more confusion, this step was launched at the very last moment, 
 just before raise abort to exit. At this moment, if client process 
 could not attach to the target process it will exit right away.

 Answers to David:

 Note that the SA is only present in a full JDK, not a JRE (full or 
 compact profile).
   Yes, in code, if no sa-jdi.jar found, skip fork.

 - What mechanism will the SA try to use to query the VM?

   After successfully attached to target process, SA will read via proc 
 APIs and vmStructs (named TYPEDB) to iterate  memory of system 
 dictionary read (only)  from target process to dump class information.

 - What if the state of the crashed VM stops the SA from being able to 
 attach properly (ie both processes hang)?

   That should be an attaching API problem. We haven't watched such 
 case happened so far.

 - What if it the SA also crashes, will it launch a third VM then a 
 fourth etc?

   Definitely don't want to see this happened in a chain. The solution 
 may use a property such as 
 sun.jvm.hotspot.DumpLoadedClasses.dumpingInProcess=true to pass into 
 SA process, at launching call, check if the property set, if set, do 
 not fork. When SA process died, it will generate core file first, note 
 the target process still waiting for its exit, so when target exit, 
 the core file (if both use default core as name) will be override by 
 target. The SA process will only leave a hs_err_pid*.log file. (? read 
 such property in handler is possible?)

  Also what is the nature of this dump? How big is it? Where will it go?
  The jars includes *app.jar and *boot.jar, the later usually can be 
 ignored (rt.jar etc system jars) unless it's rewritten by JVMTI agent.
 The app.jar will contain all classes by customer, so we can do 
 whatever we can to the jar.


 Thanks
 Yumin


 On 8/12/2013 5:51 AM, Christian Tornqvist wrote:
 Hi Yumin,

 The idea is to do as little as possible in the VM error handler, 
 since we've crashed for some reason we don't know what state the 
 process is in and we have to be extremely careful in when we're 
 gathering the information. This seems like a step that is risky for 
 all of the reasons David mentioned below.

 It's also information that can easily be extracted post-mortem from 
 the core/mdmp using the method you described for OSX, so gathering 
 this at the time of a crash seems like an unnecessary risk.

 Thanks,
 Christian

 -Original Message-
 From: hotspot-compiler-dev-boun...@openjdk.java.net
 [mailto:hotspot-compiler-dev-boun...@openjdk.java.net] On Behalf Of 
 David Holmes
 Sent: Monday, August 12, 2013 1:56 AM
 To: Yumin Qi
 Cc: hotspot compiler; hotspot-runtime-...@openjdk.java.net
 Subject: Re: RFR: 8020962: dump loaded java classes when vm crash

 Hi Yumin,

 Note that the SA is only present in a full JDK, not a JRE (full or 
 compact profile).

 I have quite a few concerns with this:

 We already do a lot of things that are not valid to be done from a 
 signal handling context but this really takes that to an extreme.
 Doing fork-exec from

hg: hsx/hotspot-rt/hotspot: 3 new changesets

[christian . tornqvist]

Changeset: fa57c8104b76
Author:ctornqvi
Date:  2013-08-02 18:12 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/fa57c8104b76

8009585: test/runtime/7196045 times out
Summary: test/runtime/7196045 times out
Reviewed-by: dholmes, mseledtsov

- test/runtime/7196045/Test7196045.java
+ test/runtime/InternalApi/ThreadCpuTimesDeadlock.java

Changeset: 0f209afdfcf8
Author:ctornqvi
Date:  2013-08-02 18:26 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/0f209afdfcf8

Merge


Changeset: d02de8cac823
Author:ctornqvi
Date:  2013-08-02 22:34 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d02de8cac823

Merge

- test/runtime/7196045/Test7196045.java

hg: hsx/hotspot-rt/hotspot: 3 new changesets

[christian . tornqvist]

Changeset: 9bd314787fad
Author:mseledtsov
Date:  2013-08-01 22:15 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9bd314787fad

8020614: OutputAnalyzer.shouldHaveExitValue() should print stdout/stderr output
Summary: OutputAnalyzer.shouldHaveExitValue() should print stdout/stderr output
Reviewed-by: kvn, ctornqvi, dholmes

+ test/testlibrary/OutputAnalyzerReportingTest.java
! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java
! test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java

Changeset: c01913206da5
Author:ctornqvi
Date:  2013-08-01 22:20 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c01913206da5

8014294: Assert in ThreadTimesClosure::do_thread() due to use of naked oop 
instead of handle
Summary: Assert in ThreadTimesClosure::do_thread() due to use of naked oop 
instead of handle
Reviewed-by: coleenp, sspitsyn

! src/share/vm/services/management.cpp

Changeset: 81e0f17ade64
Author:ctornqvi
Date:  2013-08-01 22:25 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/81e0f17ade64

8009407: runtime/8000968/Test8000968.sh has incorrect check for proper config
Summary: runtime/8000968/Test8000968.sh has incorrect check for proper config
Reviewed-by: coleenp, mseledtsov, sspitsyn, hseigel

- test/runtime/8000968/Test8000968.sh
+ test/runtime/CompressedOops/CompressedKlassPointerAndOops.java

RFR(S) 8014294: Assert in ThreadTimesClosure::do_thread() due to use of naked oop instead of handle

[Christian Tornqvist]

Small fix for an assertion due to a use of a naked oop, reproduces with the
original regression test. The fix has been tested by running vm.quick
locally on my Windows machine and using the original regression test.

 

Webrev:

http://cr.openjdk.java.net/~ctornqvi/webrev/8014294/webrev.00/

 

Bug:

http://bugs.sun.com/view_bug.do?bug_id=8014294

 

Thanks,

Christian

hg: hsx/hotspot-rt/hotspot: 2 new changesets

[christian . tornqvist]

Changeset: 2e8f19c2feef
Author:allwin
Date:  2013-07-12 18:43 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2e8f19c2feef

7162400: Intermittent java.io.IOException: Bad file number during 
HotSpotVirtualMachine.executeCommand
Summary: Intermittent java.io.IOException: Bad file number during 
HotSpotVirtualMachine.executeCommand
Reviewed-by: dcubed, dholmes, sspitsyn, mgerdin, ctornqvi, dsamersoff

! src/os/bsd/vm/attachListener_bsd.cpp
! src/os/linux/vm/attachListener_linux.cpp
! src/os/solaris/vm/attachListener_solaris.cpp
! src/os/windows/vm/attachListener_windows.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/services/attachListener.hpp
+ test/serviceability/attach/AttachWithStalePidFile.java
+ test/serviceability/attach/AttachWithStalePidFileTarget.java

Changeset: c0cb474be37e
Author:ctornqvi
Date:  2013-07-12 20:47 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c0cb474be37e

Merge

RE: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand

[Christian Tornqvist]

Looks good, thanks for taking the time to write a test for this!

Thanks,
Christian

-Original Message-
From: hotspot-runtime-dev-boun...@openjdk.java.net
[mailto:hotspot-runtime-dev-boun...@openjdk.java.net] On Behalf Of Peter
Allwin
Sent: den 11 juli 2013 10:14
To: serviceability-dev@openjdk.java.net;
hotspot-runtime-...@openjdk.java.net
Subject: RE: RFR 7162400: Intermittent java.io.IOException: Bad file
number during HotSpotVirtualMachine.executeCommand

Hello,

Thank you everyone for the feedback, I've incorporated the recommendations
into a new revision:

http://cr.openjdk.java.net/~allwin/7162400/webrev.02/

Changes:
 - Fixed speling misteaks
 - Added jtreg regression test using Mikael's excellent suggestion of
-XX:+PauseAtStartup, tested locally on linux and solaris.
 - Reverted use of MAX_PATH+1 vs. UNIX_MAX_PATH


Also thanks to Christian Törnqvist for helping out with the jtreg test!

/peter

 -Original Message-
 From: Mikael Gerdin [mailto:mikael.ger...@oracle.com]
 Sent: Tuesday, July 9, 2013 7:13 PM
 To: Peter Allwin
 Cc: serviceability-dev@openjdk.java.net; hotspot-runtime-
 d...@openjdk.java.net
 Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad file
number
 during HotSpotVirtualMachine.executeCommand

 On 07/09/2013 05:25 PM, Peter Allwin wrote:
  Mikael,
 
  That's a good point, unfortunately attach uses
  os::get_temp_directory which is hardcoded to use /tmp. We could add
  a whitebox API to allow us to override this but now we're on the
  border to noreg-hard land again
 IMO.
 
  Any other opinions on this?

 Can you use the -XX:+PauseAtStartup vm flag it will create a
 vm.paused.pid file in the current work directory. You could extract
 the
pid,
 touch the correct attach file in /tmp and then remove the vm.paused to
 let the VM resume.

 I didn't check if PauseAtStartup stops the VM early enough though.

 An alternate, even more hacky approach is to do something like (in
bash):
 (bash -c 'echo $$; touch /tmp/.java_pid$$; exec java -version') Where
 you can extract the pid of the subshell process with $$ and then exec
 into the java launcher and keep the same pid (at least on Linux,
 unsure about the Solaris launcher).

 /Mikael

 
 
  Thanks!
 
  /peter
 
  -Original Message-
  From: Mikael Gerdin [mailto:mikael.ger...@oracle.com]
  Sent: Tuesday, July 9, 2013 2:49 PM
  To: Peter Allwin
  Cc: serguei.spit...@oracle.com; daniel.daughe...@oracle.com;
  serviceability-dev@openjdk.java.net; hotspot-runtime-
  d...@openjdk.java.net
  Subject: Re: RFR 7162400: Intermittent java.io.IOException: Bad
  file
  number
  during HotSpotVirtualMachine.executeCommand
 
  Peter,
 
  On 2013-07-09 14:25, Peter Allwin wrote:
  Hello!
 
  It is reproducible by letting the test create .java_pid* files for
  all possible process id's on the system, setting correct access
  flags, launching the target VM and attempting to connect. There
  are some caveats though but it should be doable.
 
  I'll convert the repro script to JTREG and add it to the webrev.
 
  It's probably not a good idea to have a test which taints the
  system with
  stale
  .java_pid* files.
  If the test execution times out and the script isn't allowed to
  clean up I imagine that other subsequent executions could fail.
  Is there a way to tell the attach api to use a specific directory
  so you
  won't
  need to taint /tmp?
 
  /Mikael
 
 
  Thanks for the reviews!
 
  /peter
 
  *From:*serguei.spit...@oracle.com
  [mailto:serguei.spit...@oracle.com]
  *Sent:* Tuesday, July 9, 2013 1:26 AM
  *To:* daniel.daughe...@oracle.com
  *Cc:* Peter Allwin; serviceability-dev@openjdk.java.net;
  hotspot-runtime-...@openjdk.java.net
  *Subject:* Re: RFR 7162400: Intermittent java.io.IOException: Bad
  file number during HotSpotVirtualMachine.executeCommand
 
  Ok, thanks!
 
  Peter, did you manage to reproduce this issue with your script?
  If so, then, please, include it into the bug report and remove the
  noreg-sqe label.
 
  It is Ok if you did not reproduce it, though.
 
  Thanks,
  Serguei
 
 
  On 7/8/13 4:20 PM, Daniel D. Daugherty wrote:
 
   I definitely don't insist... :-)
 
   BTW, I noticed this in Peter's e-mail:
 
Testing:
JPRT, reproducing script on Solaris, Linux.
 
   so maybe Peter already has this covered with reproducing
script...
 
   Dan
 
   On 7/8/13 5:07 PM, serguei.spit...@oracle.com
   mailto:serguei.spit...@oracle.com wrote:
 
   Dan,
 
   Dan, thank you for the recommendation.
   But I'm still not sure it is a right thing to do.
   Even though, there are multiple test cases associated
  with
this
   bug they
   can not be used to verify that fix because an additional
  condition
   must be present as well.
   This condition is a presence of stale door file which is
not
   that easy to reproduce.
 
   However, if you insist then I can change the lable to the
  

RE: RFR 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand

[Christian Tornqvist]

Hi Peter,

 

Looks good, thanks for fixing this.

 

Thanks,

Christian

 

From: hotspot-runtime-dev-boun...@openjdk.java.net
[mailto:hotspot-runtime-dev-boun...@openjdk.java.net] On Behalf Of Peter
Allwin
Sent: den 8 juli 2013 09:55
To: serviceability-dev@openjdk.java.net;
hotspot-runtime-...@openjdk.java.net
Subject: RFR 7162400: Intermittent java.io.IOException: Bad file number
during HotSpotVirtualMachine.executeCommand

 

Hello!

 

Looking for reviews of this change:

http://cr.openjdk.java.net/~allwin/7162400/webrev.01/

 

For CR:

http://bugs.sun.com/view_bug.do?bug_id=7162400

https://jbs.oracle.com/bugs/browse/JDK-7162400

 

Summary:

This change addresses an issue in the Attach API on Solaris, Linux and BSD
where an attaching application can receive IOExceptions such as Bad file
number (Solaris), Connection refused (Linux/BSD), or well-known file is
not secure. 

 

The attach process uses a file in the temporary directory as a door
(Solaris) or domain socket (Linux,BSD) to communicate with the VM. In
certain circumstances stale files can be left in the file system which can
cause the attaching application to believe that the VM is ready to receive a
connection when it's not. With this change the stale file will be removed
during VM startup.

 

Note that there is still an issue if we don't have permission to remove the
stale file, the attaching process will fail to connect.

 

 

Testing:

JPRT, reproducing script on Solaris, Linux.

 

Credits:

Thanks to Staffan Larsen who worked on this issue with me.

 

 

 

Regards,

Peter

hg: hsx/hotspot-rt/hotspot: 3 new changesets

[christian . tornqvist]

Changeset: 2bffd20a0fcc
Author:ctornqvi
Date:  2013-06-13 21:57 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2bffd20a0fcc

8016065: Write regression test for 7167142
Summary: Regression tests written for both test cases (.hotspotrc and 
.hotspot_compiler). Also reviewed by mikhailo.seledt...@oracle.com
Reviewed-by: zgu, coleenp

+ test/runtime/CommandLine/CompilerConfigFileWarning.java
+ test/runtime/CommandLine/ConfigFileWarning.java

Changeset: 1e9094165098
Author:ctornqvi
Date:  2013-06-13 22:00 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1e9094165098

8015324: Create tests for CDS feature
Summary: Wrote tests for use of CDS with ObjectAlignmentInBytes CL option
Reviewed-by: coleenp, ctornqvi, hseigel
Contributed-by: Mikhailo Seledtsov mikhailo.seledt...@oracle.com

+ test/runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java
+ test/runtime/SharedArchiveFile/CdsSameObjectAlignment.java
+ test/testlibrary/com/oracle/java/testlibrary/Platform.java
! test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java

Changeset: a0a47b2649a2
Author:ctornqvi
Date:  2013-06-14 13:11 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a0a47b2649a2

Merge

hg: hsx/hotspot-rt/hotspot: 6726963: multi_allocate() call does not CHECK_NULL and causes crash in fastdebug bits

[christian . tornqvist]

Changeset: efe8b7d64424
Author:ctornqvi
Date:  2013-05-31 20:24 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/efe8b7d64424

6726963: multi_allocate() call does not CHECK_NULL and causes crash in 
fastdebug bits
Summary: Using CHECK_NULL when calling multi_allocate() from the corresponding 
reflection code; added test for this condition
Reviewed-by: dholmes, minqi
Contributed-by: Mikhailo Seledtsov mikhailo.seledt...@oracle.com

! src/share/vm/runtime/reflection.cpp
+ test/runtime/memory/MultiAllocateNullCheck.java

hg: hsx/hotspot-rt/hotspot: 8015329: Print reason for failed MiniDumpWriteDump() call

[christian . tornqvist]

Changeset: a213d425d87a
Author:ctornqvi
Date:  2013-05-28 15:08 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a213d425d87a

8015329: Print reason for failed MiniDumpWriteDump() call
Summary: Printing both result from GetLastError and text representation of 
error. Also changed so that we produce dumps by default on client versions of 
Windows when running with a debug build. Also reviewed by 
peter.all...@oracle.com
Reviewed-by: sla, dholmes

! src/os/windows/vm/os_windows.cpp

hg: hsx/hotspot-rt/hotspot: 8008169: test/runtime/7158804/Test7158804.sh has bad copyright header

[christian . tornqvist]

Changeset: 243469d929e6
Author:ctornqvi
Date:  2013-05-16 15:31 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/243469d929e6

8008169: test/runtime/7158804/Test7158804.sh has bad copyright header
Summary: Re-wrote test in Java in addition to fixing the Copyright notice. Also 
reviewed by leonid.mes...@oracle.com
Reviewed-by: coleenp, ctornqvi
Contributed-by: Mikhailo Seledtsov mikhailo.seledt...@oracle.com

- test/runtime/7158804/Test7158804.sh
+ test/runtime/CommandLine/ConfigFileParsing.java

hg: hsx/hotspot-rt/hotspot: 8014511: runtime/RedefineObject/TestRedefineObject.java has incorrect classname in @run tag

[christian . tornqvist]

Changeset: 17db82f22f1e
Author:ctornqvi
Date:  2013-05-16 17:54 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/17db82f22f1e

8014511: runtime/RedefineObject/TestRedefineObject.java has incorrect classname 
in @run tag
Summary: Corrected the class name
Reviewed-by: coleenp, ctornqvi, hseigel
Contributed-by: Mikhailo Seledtsov mikhailo.seledt...@oracle.com

! test/runtime/RedefineObject/TestRedefineObject.java

hg: hsx/hotspot-rt/hotspot: 8009577: Test test/closed/runtime/classunload broken

[christian . tornqvist]

Changeset: 33bcd9ead1d5
Author:ctornqvi
Date:  2013-05-07 21:36 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/33bcd9ead1d5

8009577: Test test/closed/runtime/classunload broken
Summary: Fixed tests to use new way of utilizing the WB API, fixed issue with 
where custom classloader got the classes from
Reviewed-by: collins, mgerdin, zgu

+ test/runtime/ClassUnload/KeepAliveClass.java
+ test/runtime/ClassUnload/KeepAliveClassLoader.java
+ test/runtime/ClassUnload/KeepAliveObject.java
+ test/runtime/ClassUnload/KeepAliveSoftReference.java
+ test/runtime/ClassUnload/UnloadTest.java
+ test/runtime/ClassUnload/classes/test/Empty.java
+ test/runtime/testlibrary/ClassUnloadCommon.java

hg: hsx/hotspot-rt/hotspot: 8009125: Add NMT tests for Virtual Memory operations

[christian . tornqvist]

Changeset: 3b890cd4da64
Author:ctornqvi
Date:  2013-04-03 21:41 +0200
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3b890cd4da64

8009125: Add NMT tests for Virtual Memory operations
Summary: Tests added for Reserve/Commit/Uncommit/Unreserve operations
Reviewed-by: zgu, mgerdin

! src/share/vm/prims/whitebox.cpp
- test/runtime/NMT/AllocTestType.java
+ test/runtime/NMT/MallocTestType.java
+ test/runtime/NMT/ThreadedMallocTestType.java
+ test/runtime/NMT/ThreadedVirtualAllocTestType.java
+ test/runtime/NMT/VirtualAllocTestType.java
! test/testlibrary/OutputAnalyzerTest.java
! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java
! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java

RE: Review Request: 8002118: WindbgDebuggerLocal should not try to load 64-bit debug libraries for 32-bit JVM

[Christian Tornqvist]

I'm quite certain there will never be a \Program Files (x64)\. On 64bit systems 
there's \Program Files\ and \Program Files (x86)\, on a 32bit systems there 
will only be a \Program Files\. So it would make sense to add \Program Files 
(x86)\ if we're running a 32bit JVM since we might be on a 64bit version of 
Windows.

Thanks,
Christian

-Original Message-
From: hotspot-dev-boun...@openjdk.java.net 
[mailto:hotspot-dev-boun...@openjdk.java.net] On Behalf Of Peter Allwin
Sent: den 27 mars 2013 17:29
To: serviceability-dev@openjdk.java.net; hotspot-...@openjdk.java.net
Subject: Review Request: 8002118: WindbgDebuggerLocal should not try to load 
64-bit debug libraries for 32-bit JVM

Webrev:
http://cr.openjdk.java.net/~sla/peter/8002118/webrev.01/

CR:
http://bugs.sun.com/view_bug.do?bug_id=8002118
https://jbs.oracle.com/bugs/browse/JDK-8002118


Problem is that on Windows we probe for dbghelp.dll on a number of different 
places, and that list always included \Program Files\Debugging Tools for 
Windows (x64) even if we're running x86, leading to an UnsatisfiedLinkError 
during load.

Fix is to add the ...(x64) path only if we're on amd64, and ...(x86) only if 
we're on x86. The affected tests have been verified to work with this fix.


Thanks to Staffan for helping out and hosting the webrev!

Regards,

/peter

hg: hsx/hotspot-rt/hotspot: 2 new changesets

[christian . tornqvist]

Changeset: c342fbdf8a70
Author:ctornqvi
Date:  2013-03-24 09:11 +0100
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c342fbdf8a70

8008454: test/runtime/NMT/PrintNMTStatistics is broken
Summary: Added @run tag so that it actually runs the test, also fixed broken 
command line and incorrect parsing. Also reviewed by gerard.ziem...@oracle.com
Reviewed-by: mgerdin, zgu

! test/runtime/NMT/PrintNMTStatistics.java

Changeset: 9c8e53c7bed0
Author:ctornqvi
Date:  2013-03-24 09:21 +0100
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9c8e53c7bed0

Merge

- make/test/Queens.java

hg: hsx/hotspot-rt/hotspot: 8010084: Race in runtime/NMT/BaselineWithParameter.java

[christian . tornqvist]

Changeset: a649f6511c04
Author:ctornqvi
Date:  2013-03-20 08:17 +0100
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a649f6511c04

8010084: Race in runtime/NMT/BaselineWithParameter.java
Summary: Added a waitFor() on the process
Reviewed-by: mgerdin, sla, zgu

! test/runtime/NMT/BaselineWithParameter.java

hg: hsx/hotspot-rt/hotspot: 8007982: some runtime/CommandLine/ tests fail on 32-bit platforms

[christian . tornqvist]

Changeset: 1feda2e9f044
Author:ctornqvi
Date:  2013-03-20 20:40 +0100
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1feda2e9f044

8007982: some runtime/CommandLine/ tests fail on 32-bit platforms
Summary: Changed tests to use platform independent flags
Reviewed-by: collins, hseigel, zgu

! test/runtime/CommandLine/BooleanFlagWithInvalidValue.java
! test/runtime/CommandLine/FlagWithInvalidValue.java
! test/runtime/CommandLine/NonBooleanFlagWithInvalidBooleanPrefix.java

hg: hsx/hotspot-rt/hotspot: 8007434: Write tests for 8006298

[christian . tornqvist]

Changeset: 3a88007634b0
Author:ctornqvi
Date:  2013-02-08 10:42 +0100
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/3a88007634b0

8007434: Write tests for 8006298
Summary: Four tests written for 8006298
Reviewed-by: mgerdin, coleenp

+ test/runtime/CommandLine/BooleanFlagWithInvalidValue.java
+ test/runtime/CommandLine/FlagWithInvalidValue.java
+ test/runtime/CommandLine/NonBooleanFlagWithInvalidBooleanPrefix.java
+ test/runtime/CommandLine/UnrecognizedVMOption.java

hg: hsx/hotspot-rt/hotspot: 3 new changesets

[christian . tornqvist]

Changeset: 4102b59539ce
Author:ctornqvi
Date:  2013-02-01 23:48 +0100
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4102b59539ce

8005012: Add WB APIs to better support NMT testing
Summary: Add WB API functions to enable better NMT testing
Reviewed-by: dholmes, zgu

! src/share/tools/whitebox/sun/hotspot/WhiteBox.java
! src/share/vm/memory/allocation.hpp
! src/share/vm/prims/whitebox.cpp
! src/share/vm/services/memBaseline.cpp
! src/share/vm/services/memPtr.cpp
! src/share/vm/services/memPtr.hpp
! src/share/vm/services/memRecorder.cpp
! src/share/vm/services/memRecorder.hpp
! src/share/vm/services/memTrackWorker.cpp
! src/share/vm/services/memTrackWorker.hpp
! src/share/vm/services/memTracker.cpp
! src/share/vm/services/memTracker.hpp

Changeset: 4460acf8687b
Author:ctornqvi
Date:  2013-02-02 07:24 +0100
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4460acf8687b

Merge


Changeset: 9fe95b01ad32
Author:ctornqvi
Date:  2013-02-02 08:46 +0100
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9fe95b01ad32

Merge

hg: hsx/hotspot-rt/hotspot: 8006413: Add utility classes for writing better multiprocess tests in jtreg

[christian . tornqvist]

Changeset: 9be6cde7919d
Author:ctornqvi
Date:  2013-01-25 10:14 +0100
URL:   http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/9be6cde7919d

8006413: Add utility classes for writing better multiprocess tests in jtreg
Summary: Add a few utility classes to test/testlibrary to support multi process 
testing in jtreg tests. Added a test case for one of the utility classes. Also 
reviewed by Vitaly Davidovich
Reviewed-by: brutisso, dholmes, vlivanov, nloodin, mgerdin

+ test/testlibrary/OutputAnalyzerTest.java
+ test/testlibrary/com/oracle/java/testlibrary/JDKToolFinder.java
+ test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java
+ test/testlibrary/com/oracle/java/testlibrary/OutputBuffer.java
+ test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java
+ test/testlibrary/com/oracle/java/testlibrary/StreamPumper.java

hg: jdk7/hotspot-rt/hotspot: 7018366: hotspot/runtime_erro Fix for 7014918 does not build using MVC 2003

[christian . tornqvist]

Changeset: b83527d0482d
Author:ctornqvi
Date:  2011-02-10 12:55 +0100
URL:   http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b83527d0482d

7018366: hotspot/runtime_erro Fix for 7014918 does not build using MVC 2003
Summary: Looking at API_VERSION_NUMBER define to see what version of 
dbghelp.h/imagehlp.h is included to determine what MINIDUMP_TYPEs are defined 
in the header file
Reviewed-by: acorn, brutisso, sla

! src/os/windows/vm/os_windows.cpp

hg: jdk7/hotspot-rt/hotspot: 7014918: Improve core/minidump handling in Hotspot

[christian . tornqvist]

Changeset: 63d374c54045
Author:ctornqvi
Date:  2011-02-09 11:08 +0100
URL:   http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/63d374c54045

7014918: Improve core/minidump handling in Hotspot
Summary: Added Minidump support on Windows, enabled large page core dumps when 
coredump_filter is present and writing out path/rlimit for core dumps.
Reviewed-by: poonam, dsamersoff, sla, coleenp

! src/os/linux/vm/os_linux.cpp
+ src/os/posix/vm/os_posix.cpp
! src/os/windows/vm/os_windows.cpp
! src/os/windows/vm/os_windows.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/os.hpp
! src/share/vm/utilities/vmError.cpp
! src/share/vm/utilities/vmError.hpp