Some questions about the JfrBuffer flush mechanism

[Markus Gronlund]

Hi Denghui,

thank you for your observation. I think you are correct.

There could be a problem here on hardware having weaker memory models, in that the store to _pos is made visible to Thread B before the contents it represents are made fully visible (store reordering). The lack of a fence at this location is mainly premised on the fact _pos becomes visible "eventually" and that is ok, at least at a higher level. However, as I understand your argument, it is not ok if _pos becomes visible out-of-order with the contents.

I agree and think there is a need to add a barrier (OrderAccess::storestore() ) just before setting _pos to a new value.

Do you want to submit a fix for this? I can also prepare a fix into mainline that you can backport.

Thanks again for your observation
Markus

-----Original Message-----
From: Denghui Dong <denghui.ddh at alibaba-inc.com> 
Sent: den 12 november 2019 10:43
To: hotspot-jfr-dev <hotspot-jfr-dev at openjdk.java.net>
Subject: Some questions about the JfrBuffer flush mechanism

Hi team,
There is a moment that a thread A writes event data to it's thread-local Jfrbuffer, and other thread B flushes the content of the JfrBuffer to file concurrently.

The pos of the JfrBuffer will be updated by the thread A after an event is written done(jfrStorageAdapter.hpp commit),

the thread B will flush the content between the top and pos of the JfrBuffer(jfrStorage.cpp ThreadLocalConcurrentWriteOperation).

The question is how to ensure that the content flushed by the thread B is correct.

There is no release store when the thread A updates the value of pos, and no load acquire when the flush thread read the value of pos.

So is it possible that the thread B reads the new value of pos, but can't read the correct value between the top and pos of the JfrBuffer.

My platform is x86-64 (tso), so I can't write a case to verify it.

Thanks,
Denghui Dong