>From sheer gut instinct (and nothing rational), it seems better to try and manage the race in the reading of the size in the from-space field (you know<br>when you've read a negative size that you've lost a race; add appropriate asserts to see that the object is forwarded,<br>
use the size from the post-copy image, and bail out), than it is to mess with the length of the to-space image. Just sheer gut instinct -- the pre-image is<br>something we can play with once we have copied it (or have safely won the race to copy it and know we are the<br>
only ones who will be modifying it). The post-copy image is the pristine thing that we typically don't want to mess<br>with lest we screw up. OK, I am waving my hands wildly and this is not always true. But still, see if you can manage the<br>
race in the reading of the pre-image without undue cost.<br><br>I'll think about it too at bed-time today :-)<br><br>Happy Holidays!<br>-- ramki<br><br><div class="gmail_quote">On Fri, Dec 23, 2011 at 12:37 AM, Tony Printezis <span dir="ltr"><<a href="mailto:tony.printezis@oracle.com">tony.printezis@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I have some bad news, it turns out that there's a subtle race in the code. I've been testing the marking changes for quite a while now (which rely on this patch) and I got a single failure. I'm pretty sure it's the race I describe below. BTW, there's a question at the end of the e-mail. :-)<br>

<br>
Let's assume two threads, A and B, are racing to forward the same object array X. Consider the following interleaving:<br>
<br>
Thread A:<br>
is X forwarded? no<br>
<br>
Thread B:<br>
is X forwarded? no<br>
size = X.size();<br>
X' = allocate size<br>
try to forward X to X'? yes<br>
copy X to X'<br>
chunk X, X.length is negative<br>
<br>
Thread A:<br>
size = X.size(); -> BOOM, as size() just read a negative length<br>
<br>
Interesting this race exists today but it's benign due to either careful design or sheer luck. When A reads size = X.size() it will actually get a smaller size than the actual size of X and will allocate a chunk smaller than X (!!!). However, given that X is already forwarded it won't need to copy it and will undo the allocation. So, no harm done.<br>

<br>
Question: Is there a reason why we use the from-space length field to encode the next index instead of the to-space length field? If we used the latter we can simplify the code by quite a lot. I can't immediately think of any issues that this might cause.<span class="HOEnZb"><font color="#888888"><br>

<br>
Tony</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 12/21/2011 5:25 PM, Tony Printezis wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
I have two code reviews (thanks to John and Ramki!). Can I push or is anybody else still looking at this?<br>
<br>
Tony<br>
<br>
On 12/14/2011 05:17 PM, Tony Printezis wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
Can I have a couple of code review for this small change?<br>
<br>
<a href="http://cr.openjdk.java.net/%7Etonyp/7121623/webrev.0/" target="_blank">http://cr.openjdk.java.net/~<u></u>tonyp/7121623/webrev.0/</a><br>
<br>
The CR has a bit more explanation. The short version is that I'm now encoding the "start index of the next chunk" in the from-space length field of a chunked array (say *that* quickly!) as a negative value to always be able to distinguish it from the real length. This will simplify the code for the CR John is currently working on (6484965) but it's a small, self-contained change so it's good to get it code reviewed and pushed separately.<br>

<br>
Tony<br>
<br>
<br>
</blockquote></blockquote>
</div></div></blockquote></div><br>