Missing store barrier with OptimizeStringConcat

[Vladimir Kozlov]

Yes, I reviewed it.

Thanks,
Vladimir

On 9/30/13 2:24 PM, Christian Thalinger wrote:
> The change looks good.  I'm going to push this today.  Vladimir, are you also a reviewer?
>
> On Sep 27, 2013, at 11:07 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> Thank you Axel for reporting this problem. I created bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8025599
>>
>> Do you have small test to show the problem so we can include it into our regression tests?
>>
>> Regards,
>> Vladimir
>>
>> On 9/27/13 5:46 AM, Siebenborn, Axel wrote:
>>> Hi,
>>>
>>> I investigated several sporadic crashes during GC with stale oops. In each of the cases, the wrong oop is the value
>>> field of String objects. While the String object is in old generation, the oop of the value field points to an unused
>>> area of the young generation.
>>>
>>> The crashes occur with -XX:-ReduceInitialCardMarks and -XX:+OptimizeStringConcat.
>>>
>>> I noticed, that the oop of the char array is written to the String object without GC store barriers.
>>>
>>> This is not a problem in most cases, as both objects are just allocated. However, it may happen that the String object
>>> is allocated via the runtime call on the slow path. During a GC at the end of the runtime call, the String object can be
>>> promoted to old gen, whereas the char array remains in the young gen. In this case the missing barrier is a problem for
>>> the next YoungGC, because the old-to-young oop will be neither scanned nor updated.
>>>
>>> (With ReduceInitialCardMarks enabled, the missing store barriers are handled at the end of the runtime call.)
>>>
>>> I created a webrev with a possible fix:
>>>
>>> http://www.sapjvm.com/as/webrevs/string_opts/
>>>
>>> Regards,
>>>
>>> Axel
>>>
>