-
Bug
-
Resolution: Fixed
-
P2
-
8u20, 8u40, 9
-
b26
-
Not verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8056672 | emb-9 | Unassigned | P2 | Resolved | Fixed | b26 |
JDK-8063520 | 8u45 | Martin Doerr | P2 | Resolved | Fixed | b01 |
JDK-8051774 | 8u40 | Goetz Lindenmaier | P2 | Closed | Fixed | b01 |
JDK-8070804 | emb-8u47 | Martin Doerr | P2 | Resolved | Fixed | team |
JDK-8168596 | openjdk7u | Martin Doerr | P2 | Resolved | Fixed | master |
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.
We consider this fix critical as it leads to severe errors in VMs built on AIX with xlC12.
For example jvm2008/sunflow does a wrong resolve and then throws an incompatible
class change error. This happens about every second try to run this benchmark.
- backported by
-
JDK-8056672 Concurrency problem in PcDesc cache
- Resolved
-
JDK-8063520 Concurrency problem in PcDesc cache
- Resolved
-
JDK-8070804 Concurrency problem in PcDesc cache
- Resolved
-
JDK-8168596 Concurrency problem in PcDesc cache
- Resolved
-
JDK-8051774 Concurrency problem in PcDesc cache
- Closed