RFR: 8272854: split runtime/CommandLine/PrintTouchedMethods.java test

Igor Ignatyev iignatyev at openjdk.java.net
Thu Oct 21 04:29:08 UTC 2021


On Wed, 20 Oct 2021 21:06:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this patch that extracts part of `runtime/CommandLine/PrintTouchedMethods.java` test to `runtime/CommandLine/PrintTouchedMethodsJcmd.java`?
>> 
>> from JBS:
>>> part of `runtime/CommandLine/PrintTouchedMethods.java` test can be done in a driver mode and ignore external flags, while another part should be executed in an othervm mode. to make execution mode efficient, the test can be split into two.
>> 
>> testing: ``runtime/CommandLine/` on `{linux,windows,macos}-x64`
>> 
>> -- Igor
>
> test/hotspot/jtreg/runtime/CommandLine/PrintTouchedMethodsJcmd.java line 47:
> 
>> 45:         output.shouldContain("PrintTouchedMethodsJcmd.main:([Ljava/lang/String;)V");
>> 46:       } catch (RuntimeException e) {
>> 47:         output.shouldContain("Unknown diagnostic command");
> 
> I think this is an existing bug. Do we need this catch block? TouchedMethodsDCmd is always enabled as long as the current JVM has INCLUDE_SERVICES is true. If INCLUDE_SERVICES is false, the jcmd connection will fail, and you will get a different error, like 
> 
> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /proc/18810/root/tmp/.java_pid18810: target process 18810 doesn't respond within 10500ms or HotSpot VM not loaded
> 
> 
> The catch block will incorrectly ignore the problem if the VM is incorrectly modified and the TouchedMethodsDCmd is inadvently excluded.

I agree that it doesn't seem we need the catch block here. yet I'd prefer to remove it by a separate RFE.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5231


More information about the hotspot-runtime-dev mailing list