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

[David Holmes]

On Mon, 3 Oct 2022 06:30:40 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider:
> 
> verify() is called by GC in safepoint so it should use the corresponding scanning method.
> verify_and_compare_entries() can wait for until there is no resize.
> 
> This makes these methods always succeed, passes t1-t6.

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.

Thanks.

src/hotspot/share/classfile/stringTable.cpp line 606:

> 604: // This verification is part of Universe::verify() and needs to be quick.
> 605: void StringTable::verify() {
> 606:   Thread* thr = Thread::current();

You don't need `thr` now

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

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