RFR(S): 8153267: nmethod's exception cache not multi-thread safe

Doerr, Martin martin.doerr at sap.com
Mon Apr 4 12:27:49 UTC 2016

Hi Christian,

thanks for taking a look.

I had checked the other places which use set_exception_cache. They either set it to NULL or to an unmodified pre-existing object (which gets released after creation by a cumulative memory barrier after my change). Both should be ok.

I have seen many places in hotspot where we have a set_... function and a release_set_... one. So I thought this was kind of common practice.
But I don’t have a strong opinion on it.
Best regards,

From: Christian Thalinger [mailto:christian.thalinger at oracle.com]
Sent: Freitag, 1. April 2016 18:34
To: Doerr, Martin <martin.doerr at sap.com>
Cc: hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR(S): 8153267: nmethod's exception cache not multi-thread safe

On Apr 1, 2016, at 2:37 AM, Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>> wrote:

Hello everyone,

we have found a concurrency problem with the nmethod’s exception cache. Readers of the cache may read stale data on weak memory platforms.

The writers of the cache are synchronized by locks, but there may be concurrent readers: The compiler runtimes use nmethod::handler_for_exception_and_pc to access the cache without locking.
Therefore, the nmethod's field _exception_cache needs to be volatile and adding new entries must be done by releasing stores. (Loading seems to be fine without acquire because there's an address dependency from the load of the cache to the usage of its contents which is sufficient to ensure ordering on all openjdk platforms.)

I also added a minor cleanup: I changed nmethod::is_alive to read the volatile field _state only once. It is certainly undesired to force the compiler to load it from memory twice.

Webrev is here:

Does it make sense to keep:

   void set_exception_cache(ExceptionCache *ec)    { _exception_cache = ec; }
or would it be safer to always do the store-release even when clearing the cache?

Please review. I will also need a sponsor.

Best regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160404/b15e4cae/attachment-0001.html>

More information about the hotspot-compiler-dev mailing list