<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 6/28/16 11:26 AM, Thomas Schatzl
wrote:<br>
</div>
<blockquote cite="mid:1467127617.2303.1.camel@oracle.com"
type="cite">
<pre wrap="">Hi again,
On Tue, 2016-06-28 at 15:09 +0200, Thomas Schatzl wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
On Mon, 2016-06-27 at 10:10 -0400, Derek White wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
I'd like to split out the memory fence issue from the race fixed by
this webrev. I think the fence issue may require more performance
testing and several attempts to get something satisfactory.
New bug created:
JDK-8160369 Memory fences needed around setting and reading
object lengths.
How do reviewers feel about this patch to fix the initial race
condition?
</pre>
</blockquote>
<pre wrap=""> looking at the 02 webrev:
</pre>
</blockquote>
<pre wrap="">
another question:
- <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/gc">http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/gc</a>
/shared/collectedHeap.inline.hpp.frames.html
Why does CollectedHeap::post_allocation_setup_class() use
post_allocation_install_obj_klass() instead of
post_allocation_setup_common(), effectively skipping setup of the mark
word?
</pre>
</blockquote>
<br>
Hi Thomas,<br>
<br>
I rewrote this in webrev.03 after your earlier comments, so this is
a moot point, but the webrev.02 version it called both<span
class="new"> <tt>post_allocation_setup_no_klass_install()</tt> <i>AND</i>
</span><span class="new"><tt>post_allocation_install_obj_klass()</tt>.
So it did the mark work also. At one point I was concerned that
post_allocation_setup_common() did the object zeroing, so I tried
to avoid that call (unnecessarily).<br>
<br>
- Derek<br>
</span>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<pre>
</pre>
</body>
</html>