Missing store barrier with OptimizeStringConcat

[Christian Thalinger]

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
>>