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