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

Jamsheed C m jamsheed.c.m at oracle.com
Mon Apr 4 06:14:14 UTC 2016

Hi Martin,

"nmethod's exception cache not multi-thread safe"  bug is fixed in b107
bug id: https://bugs.openjdk.java.net/browse/JDK-8143897
fix changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f918c20107d9
discussion link: 

Best Regards,

On 4/1/2016 6:07 PM, Doerr, Martin 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:
> http://cr.openjdk.java.net/~mdoerr/8153267_exception_cache/webrev.00/
> Please review. I will also need a sponsor.
> Best regards,
> Martin

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

More information about the hotspot-compiler-dev mailing list