RFR: 8301564: Non-C-heap allocated ResourceHashtable keys and values must have trivial destructor

[Coleen Phillimore]

On Tue, 31 Jan 2023 23:23:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> To ensure we don't have memory leaks or other more serious memory management bugs, I added static asserts to check that the `K` and `V` types for `ResourceHashtableBase` must have trivial destructors if the table is not `C_HEAP` allocated. Thanks to @JornVernee for the original assert code.
> 
> The asserts actually found a problem with `ClassLoaderStatsClosure::StatsTable`. The space used by the `oop` in the freed hashtable may be trashed when `-XX:+CheckUnhandledOops` is enabled, so live objects that reuse the same space may be corrupted. (I tried but couldn't get it to fail).
> 
> I also had to change `CodeBuffer::SharedTrampolineRequests` because it's `V` type is `LinkListImpl<int>`, which has a non-trivial destructor. (Note: in this case, the destructor doesn't do anything; we can probably make it go away with C++-20. See https://stackoverflow.com/questions/40094871/sfinae-away-a-destructor)
> 
> Testing with tier1~4 + builds-tier5

Looks good. Glad there weren't more hashtables breaking this assumption.

src/hotspot/share/classfile/classLoaderStats.hpp line 115:

> 113: 
> 114:   typedef ResourceHashtable<oop, ClassLoaderStats,
> 115:                             256, AnyObj::C_HEAP, mtInternal,

There's an mtStatistics NMT category, can you use that for this? and the instance below?

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

Marked as reviewed by coleenp (Reviewer).

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