review (S) for 6958485: fix for 6879921 was insufficient

[Tom Rodriguez]

It should assert in a fastdebug vm.  Nothing bad will happen in a product VM, at least for that test case.

tom

On Jun 8, 2010, at 12:39 AM, Volker Simonis wrote:

> Hi Tom,
> 
> I was just wondering how the testcase should fail. I tried with
> 1.7.0-ea-b96 (hs 19.0-b02) on Linux_amd64 and 1.6.0_20-b02 (hs
> 16.3-b01) on Solaris_sparc (both 32 and 64 bit) without problems. Is
> the test specific to hs17 or does it not always fail?
> 
> Regards,
> Volker
> 
> On Fri, Jun 4, 2010 at 7:18 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
>> http://cr.openjdk.java.net/~never/6958485
>> 
>> 6958485: fix for 6879921 was insufficient
>> Reviewed-by:
>> 
>> 6879921 fixed a case where the superword optimization was attempting
>> to handle arrays of oops which we shouldn't allow.  A guard was
>> inserted in stmts_can_pack which fixed the original issue.  Testing
>> with bigapps has shown that there are other paths where this problem
>> can manifest.  In particular this pattern:
>> 
>>  dst[i] = (src[i] != null ? false : true);
>> 
>> shows that are_adjacent_refs can be reached through est_savings,
>> skipping the added is_java_primitive guard.  The fix is to put an
>> is_java_primitive guard into are_adjacent_refs to guard the data_size
>> calls.  Tested with new testcase.
>>