8218812: vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed

[Jean Christophe Beyler]

Hi Daniil,

If we accept that by default compiler threads should not show up in
GetAllThreads, then the webrev looks good to me.

However, I believe a while ago we talked about in this mailing list about a
longer and broader conversation about what to do about Graal compiler
threads and even stack traces containing graal stacks. Is this the right
way to go in that broader case?

Perhaps I'm complicating the review of this but I just would like a better
idea of how Graal compiler threads are to be handled across the board in
the terms of these tests and our profiling tools in general,
Jc

On Thu, Mar 7, 2019 at 9:41 AM Daniil Titov <daniil.x.titov at oracle.com>
wrote:

> Please review a change that fixes this test.
>
> The problem here is that the test checks the number of threads and with
> Graal on additional threads the test doesn't expect are started and cause
> the test fail.
>
> The fix introduces a new capability " can_show_compiler_threads" that
> affects whether Java compiler threads are retuned with JVMTI GetAllThreads
> call. By default this capability is off. The fix also adds "
> HotSpotGraalManagement Bean Registration" thread to the list of the threads
> the tests must ignore.
>
> Webrev: http://cr.openjdk.java.net/~dtitov/8218812/webrev.01
> Bug: https://bugs.openjdk.java.net/browse/JDK-8218812
>
> Mach5 tier1, tier2 and tier3 tests successfully passed with this change.
>
> Thanks!
> -Daniil
>
>
>
>
>

-- 

Thanks,
Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190307/cae17785/attachment.html>