<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Thomas,<br>
<br>
On 6/22/16 3:01 PM, Thomas Schatzl wrote:<br>
</div>
<blockquote cite="mid:1466622063.2387.4.camel@oracle.com"
type="cite">
<pre wrap="">Hi,
On Wed, 2016-06-22 at 14:34 -0400, Derek White wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Thomas,
Thanks for the comments! Questions below...
</pre>
</blockquote>
<pre wrap="">[...]
</pre>
<blockquote type="cite">
<pre wrap="">Maybe this only causes problems when the object is allocated in
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">the
old gen (perhaps because it is large). Is there some other path
for
large arrays, so we don't have a barrier for every array
allocation?
I hope I'm missing something...
</pre>
</blockquote>
<pre wrap="">I do not know for CMS, but G1's humongous objects do have a
storestore barrier at the correct place (and it should have the
corresponding at the reader side). These are the only direct old
gen allocations G1 ever does.
</pre>
</blockquote>
<pre wrap="">
Where is this barrier used? I thought the header setting was done up
at CollectedHeap::array_allocate(), outside of G1 code?
</pre>
</blockquote>
<pre wrap="">
CollectedHeap::array_allocate() is not used for humongous objects, but
G1CollectedHeap::humongous_obj_allocate().</pre>
</blockquote>
<br>
That can't be right - G1CollectedHeap::humongous_obj_allocate()
doesn't set the object header (it doesn't even know the Klass). It <i>clears</i>
the object header, and does the storestore before updating the heap
region bookkeeping that makes the new object scannable. At that
point the new object is a valid uninitialized object.<br>
<br>
<tt>G1CollectedHeap::humongous_obj_allocate() is called by</tt><tt><br>
</tt><tt> Universe::heap()->mem_allocate() is called
by </tt><tt><br>
</tt><tt> CollectedHeap::common_mem_allocate_noinit() is called by
various</tt><tt><br>
</tt><tt> CollectedHeap::XXX_allocate()</tt><br>
<br>
But what Kim is concerned about is the ordering of setting the
object header (lock and klass fields) and setting either the array
length or the "oop_size" field of a java.lang.Class instance. We
(GC) never want to see an object with a non-zero klass in the header
and an unset array length or oop_size. These fields are set up in
CollectedHeap::post_allocation_install_obj_klass() (and neighbors),
but there is no ordering enforced between the stores.<br>
<br>
I think we're primarily worried by concurrent GC threads (G1 or CMS)
seeing these new objects as they are being created. So we aren't
concerned about young gen objects. There's some evidence that CMS is
synchronizing access between allocators and concurrent scanners (see
below), but I don't know if there are similar issues with G1.<br>
<blockquote cite="mid:1466622063.2387.4.camel@oracle.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">In any case, as soon as CMS uses this method for old gen
allocation, it needs to have the necessary barriers (obviously).
</pre>
</blockquote>
<pre wrap="">I think for CMS, reading and writing are protected by the
cms_space->freelistLock(). For example,
the CMS sweeper holds the freelistLock. The Java thread trying to
allocate requests, then gets the freelistLock(), and the sweeper
re-aquires the freelistLock() before resuming the sweep (and
reading).
So I'd think that there are plenty of fences for CMS?
</pre>
</blockquote>
<pre wrap="">
I would imagine that the exact ordering of the reads of these variables
is important, not necessarily that before or after there are fences.
Additional fences may only decrease the occurrences of this issue.
Of course, if it is the case that both threads synchronize on the free
list lock for allocation and reading respectively in the old gen, the
code is fine.</pre>
</blockquote>
I think this is the case. Certainly for concurrent sweeping.<br>
<blockquote cite="mid:1466622063.2387.4.camel@oracle.com"
type="cite">
<pre wrap="">
Thanks,
Thomas
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>