RFR: 8282900: runtime/stringtable/StringTableCleaningTest.java verify unavailable at this moment

[Robbin Ehn]

On Tue, 4 Oct 2022 04:18:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Using `do_scan` in verify seems appropriate as it is at a safepoint as you note. But the code says that the `resize_lock` may be dropped to allow a safepoint, but I can't see where exactly this dropping occurs? If we were to drop in the middle of a resize then it need not follow that the CHT can be scanned safely at a safepoint. ??
> 
> Why is it okay to have `verify_and_compare_entries` wait? What thread, doing what action, will it be waiting for? The fact it is only used during VM shutdown somewhat mitigates concerns as we only have to establish that one case is correct.
> 

When we are resizing some data (nodes) can be reached from both old table and new table.
(a concurrent scan could visits data (nodes) multiple time.
During a safepoint data/nodes are exclusively accessible from old or new table.
Safepoint scanning thus scans first old table and then new table. 

The ServiceThread does the resizing, and only doing 4096 buckets at the time before safepoint checking.
The exact code would in "StringTable::grow(...)" when calling "gt.pause(jt)".

The ServiceThread is stopped by the final VM_Exit which happens after "before_exit".

> Thanks.

#

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

PR: https://git.openjdk.org/jdk/pull/10527