Reserving an extra slot on the stack

[Andrew Haley]

On 25/01/18 15:23, David Lloyd wrote:
> On Thu, Jan 25, 2018 at 9:13 AM, Andrew Haley <aph at redhat.com> wrote:
>> On 25/01/18 14:59, David Lloyd wrote:
>>> For an experiment I'm working on, I'd like to modify the JVM to
>>> reserve one reference-sized slot (which eventually should be visible
>>> to GC) on every stack frame at a fixed well-known offset (such that I
>>> can reach it via Unsafe from Java-space).  But it appears that the
>>> stack layout code is pretty deep in per-CPU areas.  Is there a generic
>>> mechanism that I've missed?  Like some way to make the compiler act as
>>> if there were one extra local variable or something like that?
>>
>> Each compiler does its own stack layout.  The only thing that's fixed
>> is the calling convention.  To make this work you'd need to change C1,
>> C2, and the template interpreter.  As it happens, the interpreter has
>> an unused slot on most architectures, so you can have that for free.
>> Do you actually need to test your experiment with C1 and C2?
> 
> Eventually, yes: the cache would exist for performance purposes, so
> I'd want to ensure that performance is actually improved.

So every frame has an extra slot, and you want that slot to be easy to
find.  That's trivial to do in the interpreter and not terribly hard
in C1, slightly harder in C2.  The easiest thing to do would be to add
a fixed slot just beneath the return address in the compiler code.  On
x86 and AArch64, the return address is stashed at the very highest
address in the frame.  You can fairly easily tweak the code that
builds and tears down the method context to adjust the size.

None of this can be done in portable code, though: you'll have to
tweak the back end.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671