Dixi quod…
>>(This is what I found trying to build openjdk-20, but it’ll be
>>needed in 21 as well. Even getting to this point took 13½ days
>>already…)
>
>And turns out that this isn’t the cause.
>
>In 17, we’ve got src/hotspot/share/memory/allocation.hpp to
>align all CHeapObj, StackObj, MetaspaceObj, etc. classes; this
>is gone in 21. So this needs to be brought back instead.
Hmmhmm. Since I’m having to build/debug 20 first…
… in 20, StackObj has its alignment bumped manually,
but CHeapObj doesn’t. MetaspaceObj does, ResourceObj
and ArenaObj don’t, AnyObj does.
So I’m guessing we will want to fix up the allocators instead?
(Though raising the alignment for cases where people allocate
them on the stack may still be useful…)
ArenaObj… is not allocated‽
resource_allocate_bytes uses Thread::current()->resource_area()->allocate_bytes
which uses Amalloc which seems to align well.
AllocateHeap uses os::malloc which uses ::malloc (C function?)
in NMT and normal cases. Huh. MallocHeader is 16 bytes, also okay.
The glibc texinfo docs say…
| The address of a block returned by ‘malloc’ or ‘realloc’ in GNU systems
| is always a multiple of eight (or sixteen on 64-bit systems). If you
… so that should *also* be okay?! Unless that’s not true, anyway…
#define SIZE_SZ (sizeof (INTERNAL_SIZE_T))
#define MALLOC_ALIGNMENT (2 * SIZE_SZ < __alignof__ (long double) \
? __alignof__ (long double) : 2 * SIZE_SZ)
… it should.
So where does the unaligned _futex_barrier member in the
class LinuxWaitBarrier : public CHeapObj<mtInternal> come from?
AFAICS, the caller is:
WaitBarrier* SafepointSynchronize::_wait_barrier;
_wait_barrier = new WaitBarrier(vmthread);
With:
typedef LinuxWaitBarrier WaitBarrierDefault;
template <typename WaitBarrierImpl>
class WaitBarrierType : public CHeapObj<mtInternal> {
WaitBarrierImpl _impl;
…
}
typedef WaitBarrierType<WaitBarrierDefault> WaitBarrier;
So the “new WaitBarrier” should call CHeapObj::operator new(size_t size)
TTBOMK (IANAC++Programmer) which calls CHeapObjBase::operator new(size,
mtInternal)
= AllocateHeap(size, mtInternal)…
Hmmm. But, oops, I see something more:
src/hotspot/share/services/mallocTracker.hpp: static const size_t
overhead_per_malloc = sizeof(MallocHeader) + sizeof(uint16_t);
That would dealign things… but MallocTracker::record_malloc
only adds sizeof(MallocHeader) and has an assert (unsure if
NDEBUG though) that checks alignment…
I am lost. I can *see* an under-aligned futex barrier in strace.
19270 futex(0xcf80078a, FUTEX_WAKE_PRIVATE, 2147483647) = -1 EINVAL (Invalid
argument)
I cannot see how, though.
FWIW, /tmp/buildd/openjdk-20-20.0.2+9/build/jdk/bin/java \
-XX:NativeMemoryTracking=summary -version also crashes, same
with an explicit -XX:NativeMemoryTracking=off :/
I’ll recompile with re-enabled alignment on the missing base
classes like we have in 17. But if someone has ideas ’til then…
Mraw,
//mirabilos
--
<igli> exceptions: a truly awful implementation of quite a nice idea.
<igli> just about the worst way you could do something like that, afaic.
<igli> it's like anti-design. <mirabilos> that too… may I quote you on that?
<igli> sure, tho i doubt anyone will listen ;)
