See JDK-8269537 for the underlying cause. [~kbarrett]'s comment in JDK-8269537: to avoid the memset you either need to not value-initialize, or ensure the class has a user-defined default constructor.

In JDK-8292267, by simply rearranging the code, I can cause the JVM to crash because we have the sequence: operator new -> memset -> ResourceObj()

(This happens with gcc-11.2.0)

ObjectMonitorsHashtable::ObjectMonitorsHashtable():
   [...]
   0x00007ffff7452529 <+25>: call 0x7ffff60c2dd0 <ResourceObj::operator new(unsigned long, ResourceObj::allocation_type, MEMFLAGS)>
   0x00007ffff745252e <+30>: mov %rax,%rbx
   0x00007ffff7452531 <+33>: test %rax,%rax
   0x00007ffff7452534 <+36>: je 0x7ffff7452571 <ObjectMonitorsHashtable::ObjectMonitorsHashtable()+97>
   0x00007ffff7452536 <+38>: mov $0x2058,%edx
   0x00007ffff745253b <+43>: xor %esi,%esi
   0x00007ffff745253d <+45>: mov %rax,%rdi
=> 0x00007ffff7452540 <+48>: call 0x7ffff5d43510 <memset@plt>
   0x00007ffff7452545 <+53>: mov %rbx,%rdi
   0x00007ffff7452548 <+56>: call 0x7ffff60c34c0 <ResourceObj::ResourceObj()>
   [...]

=================
Proposed fix:

[1] Do not value-initialize here in synchronizer.hpp

  ObjectMonitorsHashtable() : _ptrs(new (ResourceObj::C_HEAP, mtThread) PtrTable()), _key_count(0), _om_count(0) {}

=>

  ObjectMonitorsHashtable() : _ptrs(new (ResourceObj::C_HEAP, mtThread) PtrTable), _key_count(0), _om_count(0) {}

[2] Use a non-default constructor:

  FixedResourceHashtableStorage() : _table() {}

=>

  FixedResourceHashtableStorage() { memset(_table, 0, sizeof(_table)); }