RFR: 8339307: jhsdb jstack could not trace FFM upcall frame [v4]
Chris Plummer
cjplummer at openjdk.org
Wed Sep 4 06:14:34 UTC 2024
On Wed, 4 Sep 2024 00:33:06 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:
>> test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackUpcall.java line 57:
>>
>>> 55:
>>> 56: private static void runJstackInLoop(LingeredApp app) throws Exception {
>>> 57: for (int i = 0; i < MAX_ITERATIONS; i++) {
>>
>> What is the reason for doing 20 iterations. Is it because you are waiting for THREAD_NAME to enter the sleep() call? If so, we've addressed this in the past for the general case of wanting to do a "stable"stack trace by using the LingeredApp's SteadyStateThread. LingeredApp.startApp() will not return until this thread has become stable (blocked). Maybe you can do something similar with THREAD_NAME.
>
> TBH this testcase is based on TestJhsdbJstackMixed.java , so I'm not stick this code. I will fix to use SteadyStateThread.
Ok. I think TestJhsdbJstackMixed has a loop because it's trying to get a stack trace at a point when the thread is executing at a PC that used result in an SA exception (which is now fixed).
SteadyStateThread might be a bit tricky to integrate into this test since the test has no control over what the thread does. Possibly with a new LIngeredApp subclass you could control SteadyStateThread to call your FFM code.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20789#discussion_r1743127430
More information about the serviceability-dev
mailing list