[LLVMdev] [RFC] New StackMap format proposal (StackMap v2)

[Swaroop Sridhar]

Please see inline.

From: Philip Reames [mailto:listmail at philipreames.com]
Sent: Tuesday, July 14, 2015 10:35 PM
To: Andrew Trick; Swaroop Sridhar
Cc: Juergen Ributzka; LLVM Dev; Lang Hames; Phil Pizlo; Sanjoy Das; Russell Hadley
Subject: Re: [RFC] New StackMap format proposal (StackMap v2)

[…]

1)      Offset of the start of the call instruction if the call instruction occurs within a code-range that allows full interruption (that is, all instructions in a range are considered safe-points)

If the JIT requires knowledge of call's encoding, it should probably be emitting the call instruction itself within the patchable space reserved by LLVM.


Note that the patchpoint may include a mov in addition to call, so the patchpoint address is not the same as the call address.

Just to be clear, the problem with (2) has nothing to do with StackMaps.  It has to do with the fact our entire backend confuses pointers and non-pointers.  To have option (2), I believe we'd need to effectively have a stackmap for every instruction.  That's a lot more work than anyone has serious proposed to date.  :)


Yes. Fully interruptible code will effectively need a StackMap at every instruction.
Many compilers targeting CLR runtime generate fully-interruptible code ranges for performance critical code (ex: hot loops where it is very expensive to place a safepoint-poll to yield control to the GC). CLR GCTables use certain compact representation techniques so that the image size stays small.
Anyway, I did not mean to suggest that LLVM should support for fully-interruptible code – at least not in the short term.

[…]

Therefore, it is helpful to have Call-Site size specified in StackMapRecord.
I agree with Andy, that the call-site size should include all bytes between the start of the call instruction and the start of the next instruction.

I suggested this because we want to support a dynamic callback that determines the patchpoint size (given the set of register arguments), and it would be nice to record that decision within the stack map. This is important information for any code that is responsible for patching because it must patch over all reserved bytes.

The alternative would be for LLVM to emit the call at the end and record just the size of the call instruction encoding. That seems like a silly, x86-specific waste of stackmap space though. The JIT can either do the encoding and keep track of the info, or a small nop+move_immediate decoder can figure it out for all reasonable cases.
I would argue in favor of recording the number of bytes recorded for patching.  I think that gives us everything we need in practice.  Any non-destructive or concurrent patch mechanism is going to need extremely fine grained control anyways.  Trying to do that partly within LLVM and partly without just seems like a mistake.

To clarify my understanding of your proposal,
If we have a statepoint intrinsic, whose call instruction encodes to 5 bytes. Will the call-site size recorded in the StackMap be:

(a)    5 bytes, if the num-patch-bytes argument to the statepoint is 0

(b)   10 bytes,  if the num-patch-bytes argument to the statepoint is 10?

Thanks,
Swaroop.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150716/876864e2/attachment.html>