generational zgc issues

[Stefan Karlsson]

Hi Alen,

On 2023-11-13 19:05, Alen Vrečko wrote:
> Hello everyone,
>
> o) young gen reference processor
>
> A bit puzzled by reading in a thread on the list:
>
> > mentioning that we decided to not ship a young generation reference 
> processor for 21
> Unless you made changes to ByteBuffer#allocateDirect it uses reference 
> processor to free native memory. If I am not mistaking just using 
> standard library API such as Files.readAllBytes will in some cases do 
> BB#allocateDirect in the internals.
> Or maybe I am misunderstanding something? I made a toy program and 
> indeed I could easily get a situation where 20% of reference handlers 
> are not called like ever.
> This will cause issues for code that is using reference handlers.

The reference processing will happen when the GC performs a major 
collection, which collects both the young and old generation. If you add 
a System.gc() you should see that the reference processor is kicking in 
for your program. Could you share your toy program?

> o) seeing weird byte[] corruption in production
> On CentOS 7 Generational works fine. No issues observed. But on Alma 
> Linux 9.2 either reading byte[] from file or sending byte[] over the 
> network corrupts the byte[]. Didn't investigate at all. Just observed 
> corruption in some cases for some byte[] arrays - not all - just some. 
> On the same Alma Linux 9.2 without generational zgc no byte[] 
> corruption is observed and everything works fine as before.

It's hard to say if this is a ZGC bug, compiler bug, OS bug, etc. Here 
are some suggestions for how to help pin-point the problem:
1) Could you provide the output from 'java -version'?
2) Is it possible to reproduce this with a small reproducer?
3) What CPU is this running on?
4) Does it happen with -XX:UseAVX=0
5) Do you know the sizes of the corrupted byte[]s? Do you know the 
offset to where it is corrupted?

StefanK

> To me Generational ZGC looks more like an experimental feature for 
> now. I am a bit surprised it doesn't require the extra flag to unlock 
> experimental features.
> Thanks
> Alen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/zgc-dev/attachments/20231113/d6b75e0a/attachment.htm>