StringBuilding optimization bug since Java 7 update 4

[Charlie Hunt]

Thanks for confirming.   Fwiw, I added a "work around" comment to the blog entry.

I'm sure one of the HotSpot compiler engineers will file a bug for it.
 
On Jun 22, 2012, at 9:12 AM, Damjan Jovanovic wrote:

> In JDK 1.7.0_04 amd64 and 1.7.0_05 x86, both on Ubuntu 12.04 amd64:
> 
> -XX:+OptimizeStringConcat reproduces the bug in the Javac example from
> http://riven8192.blogspot.com/2012/06/hotspot-bug-in-java-7u4-7u5-7u6rc-with.html
> -XX:-OptimizeStringConcat works correctly (it should infinite loop)
> 
> Regards
> 
> On Fri, Jun 22, 2012 at 3:47 PM, Charlie Hunt <chunt at salesforce.com> wrote:
>> Could you try your experiment with -XX:-OptimizeStringConcat to see if the
>> unexpected behavior goes away?
>> 
>> IIRC, -XX:+OptimizeStringConcat was made the default in 7u4.
>> 
>> charlie ...
>> 
>> On Jun 21, 2012, at 4:39 PM, Skip Balk wrote:
>> 
>> Dear HotSpot developers,
>> 
>> 
>> This is the first time I post anything on any mailinglist, so please forgive
>> me if my message is not quite up to the standards you are used to.
>> 
>> Last week, I encountered a bug in simple String concatenation, like:
>> 
>> String s = "test";
>>     s = s+s;
>>     s = s+s;
>>     s = s+s;
>> 
>> yielding the string: "nullnulltesttest" instead of
>> "testtesttesttesttesttesttesttest". The first Java version that seems to
>> suffer from this bug is Java 7u4, and is confirmed to occur in 7u5, 7u6(rc).
>> It has been further reproduced on 32bit, 64bit, clientvm and servervm.
>> 
>> After a few thousand (interpreted) runs of this code, it starts to give
>> these incorrect results, leading me to assume that a HotSpot optimisation is
>> the root cause of this problem, which is backed by the fact that when
>> running the java process with the -Xint argument, the bug does not occur.
>> 
>> Unfortunately, today I discovered that with my trivial sourcecode, the issue
>> only occured with the Eclipse compiler. The Javac output seemed to be
>> 'friendly' to HotSpot.
>> 
>> Upon further investigation, it turned out that "s=s+s" was compiled to
>> different bytecode by Javac and Eclipse:
>>     Eclipse: s = new StringBuilder(String.valueOf(s)).append(s).toString();
>>     Javac:   s = new StringBuilder().append(s).append(s).toString();
>> When writing the version Eclipse produces in Java sourcecode, the javac
>> compiler also produced the bytecode that made HotSpot trip.
>> 
>> Without further ado: here are the full code-dumps (both for eclipse and
>> javac)
>>     http://riven8192.blogspot.com/2012/06/hotspot-bug-in-java-7u4-7u5-7u6rc-with.html
>> 
>> "javap -c" output, with sourcecode containing "s=s+s"
>>     Javac:   http://pastebin.com/raw.php?i=pC3kRC6c
>>     Eclipse: http://pastebin.com/raw.php?i=Pbj0fyZ8
>> 
>> Console output:
>>     Java Version: 23.0-b21
>>     Failed at iteration: 11983
>>     Length mismatch: 16 <> 32
>>     Expected: "testtesttesttesttesttesttesttest"
>>     Actual:   "nullnulltesttest"
>> 
>> Last but not least, this bug seems to be triggered by the empty-for-loop,
>> which leads me to believe this is a case of too aggresive dead code removal.
>> I hope you can
>> 
>> 
>> With kind regards,
>>     Riven (http://www.java-gaming.org/ administrator)
>> 
>>