-
Bug
-
Resolution: Fixed
-
P2
-
9
-
b158
-
Not verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8175762 | 10 | Claes Redestad | P2 | Resolved | Fixed | b02 |
Investigating JDK-8174817, there was a few troubling finds in the jimage code:
ImageReader.reader is non-volatile, and there appears to be no effective guard to ensure it's safely published (even though it's created under a lock), thus it might be possible for a thread to observe the reader field as null and thus interpret the reader as closed in some situations.
There's also a race in ImageReaderFactory managed by getting, checking, opening and doing a putIfAbsent (the ImageReader who lose the race will be closed); this could be implemented better using computeIfAbsent
ImageReader.reader is non-volatile, and there appears to be no effective guard to ensure it's safely published (even though it's created under a lock), thus it might be possible for a thread to observe the reader field as null and thus interpret the reader as closed in some situations.
There's also a race in ImageReaderFactory managed by getting, checking, opening and doing a putIfAbsent (the ImageReader who lose the race will be closed); this could be implemented better using computeIfAbsent
- backported by
-
JDK-8175762 ImageReader is not thread-safe
-
- Resolved
-
- relates to
-
JDK-8174817 NoClassDefFoundError happened intermittently in some unrelated tests
-
- Closed
-