RFR(XS): 8028109: compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java crashes in RT_Baseline

[Vladimir Kozlov]

Last version is not good because it may hide bug when wrong address 
matches byte_map_base value. Original Tom's fix also hides problems.

MacroAssembler::g1_write_barrier_post() and store_check_part_2() are 
used only in interpreter. It does not make sense to optimize it. Note, 
x86 has limited throughput for address calculations. And one instruction 
is only generated if this address is 32-bit which may be not true then 
you have to move it into register too.

Anyway, we can go case by case and avoid ExternalAddress in 64-bit VM 
because code allows us to do that:

In both cases in c1_Runtime1_x86.cpp and in 
MacroAssembler::g1_write_barrier_post() there is separate lea() 
instruction for LP64 which could be replaced with mov to load constant.

MacroAssembler::store_check_part_2() is different case which we may 
prefer to use in other cases. Note, as_Address(ArrayAddress adr) 
generates lea() instruction again. Which means code for 32-bit VM in 
c1_Runtime1_x86.cpp generates 2 lea instructions and not one:

__ leal(card_addr, __ as_Address(ArrayAddress(cardtable, index)));

What I am saying is lets use mov instruction to load byte_map_base 
instead of usiong ExternalAddress because we don't need relocation for 
it and because in reality (with all past fixes) we will generate the 
same number of instructions.

Regards,
Vladimir

On 11/19/13 7:59 AM, Albert Noll wrote:
> Hi Roland,
>
> thanks for pointing this out. Here is a patch that executes the assert
> only if
> the address we are checking is not byte_map_base. This might not be the
> most
> elegant solution, but at least it seems to work.
>
> Here is the new webrev:
> http://cr.openjdk.java.net/~anoll/8028109/webrev.01/
>
> Best,
> Albert
>
>
> On 11/19/2013 10:00 AM, Roland Westrelin wrote:
>>> Solution: Change 'ExternalAddress' to 'AddressLiteral' that generates
>>> no relocation information for
>>>                byte_map_base. Other platforms also AddressLiteral
>>> without relocation information.
>> As mentioned in the thread here:
>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005151.html
>>
>> in this message:
>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-April/005161.html
>>
>>
>> not using ExternalAddress disables rip relative addressing.
>> This said, I’m not sure what a clean fix for this would be.
>>
>> Roland.
>