<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>[Request for Comment]</p>
<p>This is a follow-on to some discussion that's been taking place
on bug <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8160369">https://bugs.openjdk.java.net/browse/JDK-8160369</a>.</p>
<p>From Thomas:<br>
</p>
<p>
<blockquote type="cite">
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
Regular objects also need the barriers. I.e. the writing of the
layout helper of the Klass must happen before publishing the
Klass pointer to internal data structures (i.e. it is accessible
by the mutator threads). Regular (huge) objects may be allocated
directly into the old gen too. The issue is a bit simpler here,
because we can assume that there is an implicit loadload barrier
when the reader accesses the layout helper. Also, at least in
G1, regular objects are always allocated through the runtime.
<br>
</blockquote>
Hi Thomas,</p>
<p>I think we might be in agreement about what should happen, but
are differing in terms.</p>
<p>I agree that when creating the C++ Klass object, we should have a
storestore barrier between setting the layout helper field and
publishing the Klass to the world. It sounds unlikely that a
concurrent GC would ever see a store that stayed out-of-order
through Klass creation, loading, initialization, and instance
allocation, but I'd rather avoid that bug now :-)</p>
<p>And I agree that the implicit loadload barrier in code like
oop->klass()->layout_helper() is sufficient for the
processors we care about.</p>
<p>I'm not sure what you mean with the phrase "Regular objects also
need the barriers" though. Do you mean in
CollectedHeap::obj_allocate(), like we're adding to array_alloc()
and class_alloc()? What is being written here that needs ordering?<br>
<blockquote type="cite">
And java.lang.Class instances also only need the barrier if
allocated into the old gen (afaik they are not).
<br>
</blockquote>
</p>
<p>Interesting point. It turns out that huge java.lang.Class
instances <i>can</i> get allocated in the old gen. Also, Colleen
mentioned that it might be nice if we could allocate all
java.lang.Class instances directly in the old gen.</p>
<p>It might be a good idea to only do the memory barriers when the
object is in the old gen, but I'm not sure how the cost of testing
this at runtime compares to the cost of the barriers themselves.
I've been assuming that, statistically speaking, CollectedHeap::<i>foo</i>_allocate()
is only called for old gen allocations, and the rest are handled
by the compiled code or interpreter. Modulo a pile of corner
cases.<br>
</p>
<p>Similarly, we use memory barriers only when we're using a
concurrent GC, if the cost trade-off made sense.<br>
<blockquote type="cite">
Also those "other" cases where the layout helper is < 0, and
we take the virtual call must be considered too (whatever these
are) to make sure that a loadload barrier is executed (assuming
that instances of these kind can be somehow allocated in old
gen).
<br>
</blockquote>
</p>
<p>I think the virtual calls for oop_size() end up using the layout
helper (after all), using the array length, or using the oop_size
field. So resolving the issue of ordering the length field or
oop_size field should be sufficient.</p>
<p>Thanks for looking at this issue!<br>
</p>
<p> - Derek</p>
<p><br>
</p>
<p>FYI - I have two stabs at fixing this issue:</p>
<p><a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~drwhite/8160369/webrev.02">http://cr.openjdk.java.net/~drwhite/8160369/webrev.02</a> - Minimal
barriers, but I'm not sure it's catching everything.</p>
<p><a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~drwhite/8160369/webrev.03">http://cr.openjdk.java.net/~drwhite/8160369/webrev.03</a> - Smaller
patch, possibly overly conservative.</p>
<p>In both cases, I've used the call to oopDesc::klass_or_null() as
a flag that the caller is some part of concurrent GC that is
written to safely handle partially initialized objects. If
klass_or_null() is called in other circumstances then my patches
are doing too many barriers...<br>
</p>
<p><br>
</p>
</body>
</html>