On Tue, 4 Aug 2026 10:32:18 GMT, Serguei Spitsyn <[email protected]> wrote:
>> Shiv Shah has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Explain per-test why a platform thread is used
>
> test/hotspot/jtreg/vmTestbase/nsk/jdb/thread/thread002/thread002.java line
> 108:
>
>> 106: for (int i = 0; i < threadIds.length; i++) {
>> 107: count = new Paragrep(switchReplies[i]).find(THREAD_NAME +
>> "#" + i);
>> 108: if (count == 0) {
>
> Q: I see a potential issue (Is it pre-existed?). It seems, this test has an
> assumption that the GDB`getThreadIds()` and `getThreadIdsByName()` return
> thread IDs in a correct order matching this: `MyThread#0`, `MyThread#1`, etc.
> I'm not sure it is the case. Should we double check this? If the returned
> order can be different then I'm thinking if we can add a comment with a
> warning about this potential problem or just fix the issue.
It’s not pre-existing, it’s this change. the old check counted each
MyThread#i[1] prompt across the whole session log, which didn’t care about id
order; when I re-keyed it to each switch reply it started assuming
getThreadIdsByName returns ids in creation order, and nothing guarantees that.
I fixed now rather than commented by resolving each id by its exact name
(MyThread#i) and asserting that thread’s switch reply matches no ordering
assumption left, and a duplicate or missing name fails explicitly instead of
passing by luck.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32142#discussion_r3714858515
