RFR(S): 8050972: Concurrency problem in PcDesc cache
vitalyd at gmail.com
Thu Jul 17 16:39:18 UTC 2014
Is volatile enough though if the entries are read/written concurrently?
What about needing, e.g., store-store barriers when writing an entry into
Sent from my phone
On Jul 17, 2014 11:20 AM, "Doerr, Martin" <martin.doerr at sap.com> wrote:
> Hi Vladimir,
> the following line should also work:
> PcDesc* volatile _pc_descs[cache_size];
> But we thought that the typedef would improve readability.
> The array elements must be volatile, not the PcDescs which are pointed to.
> Best regards,
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf
> Of Vladimir Kozlov
> Sent: Donnerstag, 17. Juli 2014 17:09
> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net
> Subject: Re: RFR(S): 8050972: Concurrency problem in PcDesc cache
> Hi Goetz,
> What is the reason for new typedef?
> On 7/17/14 1:54 AM, Lindenmaier, Goetz wrote:
> > Hi,
> > This webrev fixes an important concurrency issue in nmethod.
> > Please review and test this change. I please need a sponsor.
> > http://cr.openjdk.java.net/~goetz/webrevs/8050972-pcDescConc/webrev-01/
> > This should be fixed into 8u20, too.
> > The entries of the PcDesc cache in nmethods are not declared as
> volatile, but they are accessed and modified by several threads
> concurrently. Some compilers (namely xlC 12 on AIX) duplicate some memory
> accesses to non-volatile fields. In this case, this has led to the
> situation that a thread had successfully matched a pc in the cache, but
> returned the reloaded value which was already overwritten by another thread.
> > Best regards,
> > Martin and Goetz.
More information about the hotspot-dev