3 ms·

If you look at the tricks needed to shrink it to 64 bits then you'll see why this is hard. Consider that this object header has to contain: - GC state bits. -

If you look at the tricks needed to shrink it to 64 bits then you'll see why this is hard. Consider that this object header has to contain: - GC state bits. - The class metadata, i.e. pointer to a Class<> object. - Lock data, including possibly a pointer to a lock. - Possibly, an identity hash code. - Possibly, a GC forwarding pointer. Several of these are pointers! If you're on a 64 bit machine, just one* of them implemented naively if immediately 64 bits. In other words Java object headers provide a lot of stuff. To pack the whole thing down to just 64 bits requires a lot of clever implementation tricks, exploiting what exact combinations can appear, etc. Also note that this overhead isn't Java specific. In C++ you have malloc headers and then the C++ vtable pointer, in many cases. So just running "new SomeObj()" in C++ will immediately blow you past the heap overhead of Java after this JEP is merged, and if you need to add a lock and/or reference count to catch up with the Java feature set then you're at multiples of it.

yakubin 4y ago
1. C++ doesn’t use vtables for classes which do not have virtual methods (in practice most of them). And vtables are shared between objects of the same type. 2. “Malloc headers”? Malloc usually stores metadata in freed data. 3. C++ developers don’t call “new” for every single object, the way Java devs do. Idiomatic code defaults to allocating fixed-size objects inline (on stack or in a pre-existing bigger allocation), not in a separate allocation. 4. In C++ there are other ways to allocate dynamic memory than “new”. Arena allocators, directly calling mmap/VirtualAlloc/whatever makes sense in a given case.
- origin_path 4y ago
  Yes, I know C++, I didn't say that's the only way to allocate objects in C++, just that if you do write a heap allocated object that has virtual methods (a pretty common thing to want to do), then the metadata for that will be larger than 64 bits. Your malloc storing metadata non-adjacent to the allocation doesn't change the fact that there is some, and it has to be stored.

yakubin 4y ago

1. C++ doesn’t use vtables for classes which do not have virtual methods (in practice most of them). And vtables are shared between objects of the same type. 2. “Malloc headers”? Malloc usually stores metadata in freed data. 3. C++ developers don’t call “new” for every single object, the way Java devs do. Idiomatic code defaults to allocating fixed-size objects inline (on stack or in a pre-existing bigger allocation), not in a separate allocation. 4. In C++ there are other ways to allocate dynamic memory than “new”. Arena allocators, directly calling mmap/VirtualAlloc/whatever makes sense in a given case.

origin_path 4y ago
Yes, I know C++, I didn't say that's the only way to allocate objects in C++, just that if you do write a heap allocated object that has virtual methods (a pretty common thing to want to do), then the metadata for that will be larger than 64 bits. Your malloc storing metadata non-adjacent to the allocation doesn't change the fact that there is some, and it has to be stored.