RFR(XS): 8028109: compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java crashes in RT_Baseline
Vladimir Kozlov
vladimir.kozlov at oracle.com
Tue Nov 19 11:36:40 PST 2013
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.
>
More information about the hotspot-compiler-dev
mailing list