-
Bug
-
Resolution: Fixed
-
P2
-
17, 18
-
b14
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8300189 | 17.0.7-oracle | Thomas Schatzl | P2 | Closed | Fixed | b03 |
JDK-8300858 | 17.0.7 | Goetz Lindenmaier | P2 | Resolved | Fixed | b01 |
JDK-8300190 | 11.0.19-oracle | Thomas Schatzl | P2 | Closed | Fixed | b03 |
JDK-8301049 | 11.0.19 | Goetz Lindenmaier | P2 | Resolved | Fixed | b01 |
JDK-8300188 | 8u371 | Thomas Schatzl | P2 | Closed | Fixed | b03 |
JDK-8300583 | 7u381 | Poonam Bajaj Parhar | P2 | Closed | Fixed | b03 |
if (_discovery_is_mt) {
[1] add_to_discovered_list_mt(*list, obj, discovered_addr);
} else {
[2] // We do a raw store here: the field will be visited later when processing
// the discovered references.
oop current_head = list->head();
// The last ref must have its discovered field pointing to itself.
oop next_discovered = (current_head != NULL) ? current_head : obj;
assert(discovered == NULL, "control point invariant");
RawAccess<>::oop_store(discovered_addr, next_discovered);
list->set_head(obj);
list->inc_length(1);
log_develop_trace(gc, ref)("Discovered reference (" INTPTR_FORMAT ": %s)", p2i(obj), obj->klass()->internal_name());
}
[2] argues that there is no need for a barrier because we visit this later when processing the discovered references *during gc*.
However, some G1 code sets _discovery_is_mt to false for concurrent precleaning (in G1ConcurrentMark::preclean()). This causes missing barriers in G1.
[1] executes a barrier always, just because we are using multiple threads, even during gc when it is not required.
This adds overhead for parallel gc and G1 during GC.
I.e. there is a confusion between "atomicity" and "degree of parallelism" in this code.
- backported by
-
JDK-8300858 Reference discovery is confused about atomicity and degree of parallelism
- Resolved
-
JDK-8301049 Reference discovery is confused about atomicity and degree of parallelism
- Resolved
-
JDK-8300188 Reference discovery is confused about atomicity and degree of parallelism
- Closed
-
JDK-8300189 Reference discovery is confused about atomicity and degree of parallelism
- Closed
-
JDK-8300190 Reference discovery is confused about atomicity and degree of parallelism
- Closed
-
JDK-8300583 Reference discovery is confused about atomicity and degree of parallelism
- Closed
- relates to
-
JDK-8273185 Rename the term "atomic" in ReferenceProcessor
- Resolved
- links to
-
Commit openjdk/jdk11u-dev/f4c5bdf0
-
Commit openjdk/jdk17u-dev/b7be2bd0
-
Commit openjdk/jdk/fb5b144e
-
Review openjdk/jdk11u-dev/1678
-
Review openjdk/jdk17u-dev/1073
-
Review openjdk/jdk/5314