RFR (M) CR 8050147: StoreLoad barrier interferes with stack usages

[Aleksey Shipilev]

On 08/29/2014 01:41 AM, John Rose wrote:
>> This makes me uneasy for two reasons:
>>
>> a) We only need to do this for x86. ifdef'ing the generic
>> LIR_Assembler/Compile code seems odd. Can we pro-actively bang for an
>> additional cache line for all platforms?
> 
> I do think we could do this, although there are ways it could bite us later.
> 
> It would need a comment saying that it matters for x86, and is thought to be harmless for other chips.  That way if someone wants to change it later on they will know the constraints.
> 
> But, to be more verbose but also more future-proof, let's add another function to these files:
>   hotspot/src/os_cpu/*/vm/os_*.hpp
> 
>     /* amount beyond the callee frame size that we bang the stack; see JDK-@@ */
>     static int extra_bang_size_in_bytes() { return VM_Version::L1_line_size(); }
> 
>> b) The cache line size here does seem like a magic number, and I would
>> like to move the StoreLoad SP offset calculation somewhere -- but where
>> to? VM_Version seems to be too generic to handle the x86-specific case.
>> Putting it in assembler(_x86) seems to introduce the artificial
>> dependency between the machine-neutral and machine-dependent parts of
>> the compiler.
> 
> The function above could easily couple to x86-specific logic.

That's a nice suggestion! Let me try that.

Thanks,
-Aleksey.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140829/664aa6c7/signature.asc>