Some questions about the JfrBuffer flush mechanism

[Markus Gronlund]

Yes, please do that.

 

Thanks

Markus

 

From: Denghui Dong <denghui.ddh at alibaba-inc.com> 
Sent: den 12 november 2019 14:40
To: hotspot-jfr-dev <hotspot-jfr-dev at openjdk.java.net>; Markus Gronlund <markus.gronlund at oracle.com>
Subject: Re: Some questions about the JfrBuffer flush mechanism

 

Hi Markus,

  Thanks for your reply, and I think that I can fix this problem, should I file an issue in JBS first ?

 

Thanks,

Denghui Dong

------------------------------------------------------------------

From:Markus Gronlund <HYPERLINK "mailto:markus.gronlund at oracle.com"markus.gronlund at oracle.com>

Send Time:2019年11月12日(星期二) 21:14

To:董登辉(卓昂) <HYPERLINK "mailto:denghui.ddh at alibaba-inc.com"denghui.ddh at alibaba-inc.com>; hotspot-jfr-dev <HYPERLINK "mailto:hotspot-jfr-dev at openjdk.java.net"hotspot-jfr-dev at openjdk.java.net>

Subject:RE: Some questions about the JfrBuffer flush mechanism

 

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 <HYPERLINK "mailto:denghui.ddh at alibaba-inc.com"denghui.ddh at alibaba-inc.com> 
Sent: den 12 november 2019 10:43
To: hotspot-jfr-dev <HYPERLINK "mailto:hotspot-jfr-dev at openjdk.java.net"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