llvm dev - Oct 2013 - [LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal

On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com>
wrote:
> On 10/17/13 10:39 PM, Andrew Trick wrote:
>> This is a proposal for adding Stackmaps and Patchpoints to LLVM. The
>> first client of these features is the JavaScript compiler within the
>> open source WebKit project.
>> 
> I have a couple of comments on your proposal.  None of these are major
enough to prevent submission.
> 
> - As others have said, I'd prefer an experimental namespace rather than
a webkit namespace.  (minor)
> - Unless I am misreading your proposal, your proposed StackMap intrinsic
duplicates existing functionality already in llvm.  In particular, much of the
StackMap construction seems similar to the Safepoint mechanism used by the
in-tree GC support.  (See CodeGen/GCStrategy.cpp and CodeGen/GCMetadata.cpp). 
Have you examined these mechanisms to see if you can share implementations?
> - To my knowledge, there is nothing that prevents an LLVM optimization pass
from manufacturing new pointers which point inside an existing data structure. 
(e.g. an interior pointer to an array when blocking a loop)  Does your StackMap
mechanism need to be able to inspect/modify these manufactured temporaries?  If
so, I don't see how you could generate an intrinsic which would include this
manufactured pointer in the live variable list.  Is there something I'm
missing here?
These stackmaps have nothing to do with GC.  Interior pointers are a problem
unique to precise copying collectors.

In particular, the stackmaps in this proposal are likely to be used for
capturing only a select subset of state and that subset may fail to include all
possible GC roots.  These stackmaps are meant to be used for reconstructing
state-in-bytecode (where bytecode = whatever your baseline execution engine is,
could be an AST) for performing a deoptimization, if LLVM was used for compiling
code that had some type/value/behavior speculations.
> - Your patchpoint mechanism appears to be one very specialized use of a
patchable location.  Would you mind renaming it to something like patchablecall
to reflect this specialization?
The top use case will be heap access dispatch inline cache, which is not a call.

You can also use it to implement call inline caches, but that's not the only
thing you can use it for.

-Filip

> 
> Yours,
> Philip
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On 10/22/13 10:34 AM, Filip Pizlo wrote:
> On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com>
wrote:
>
>> On 10/17/13 10:39 PM, Andrew Trick wrote:
>>> This is a proposal for adding Stackmaps and Patchpoints to LLVM.
The
>>> first client of these features is the JavaScript compiler within
the
>>> open source WebKit project.
>>>
>> I have a couple of comments on your proposal.  None of these are major
enough to prevent submission.
>>
>> - As others have said, I'd prefer an experimental namespace rather
than a webkit namespace.  (minor)
>> - Unless I am misreading your proposal, your proposed StackMap
intrinsic duplicates existing functionality already in llvm.  In particular,
much of the StackMap construction seems similar to the Safepoint mechanism used
by the in-tree GC support.  (See CodeGen/GCStrategy.cpp and
CodeGen/GCMetadata.cpp).  Have you examined these mechanisms to see if you can
share implementations?
>> - To my knowledge, there is nothing that prevents an LLVM optimization
pass from manufacturing new pointers which point inside an existing data
structure.  (e.g. an interior pointer to an array when blocking a loop)  Does
your StackMap mechanism need to be able to inspect/modify these manufactured
temporaries?  If so, I don't see how you could generate an intrinsic which
would include this manufactured pointer in the live variable list.  Is there
something I'm missing here?
> These stackmaps have nothing to do with GC.  Interior pointers are a
problem unique to precise copying collectors.
I would argue that while the use of the stack maps might be different, 
the mechanism is fairly similar.  In general, if the expected semantics 
are the same, a shared implementation would be desirable.  This is more 
a suggestion for future refactoring than anything else.

I agree that interior pointers are primarily a problem for relocating 
collectors. (Though I disagree with the characterization of it being 
*uniquely* a problem for such collectors.)  Since I was unaware of what 
you're using your stackmap mechanism for, I wanted to ask.  Sounds like 
this is not an intended use case for you.
>
> In particular, the stackmaps in this proposal are likely to be used for
capturing only a select subset of state and that subset may fail to include all
possible GC roots.  These stackmaps are meant to be used for reconstructing
state-in-bytecode (where bytecode = whatever your baseline execution engine is,
could be an AST) for performing a deoptimization, if LLVM was used for compiling
code that had some type/value/behavior speculations.
Thanks for the clarification.  This is definitely a useful mechanism.  
Thank you for contributing it back.
>
>> - Your patchpoint mechanism appears to be one very specialized use of a
patchable location.  Would you mind renaming it to something like patchablecall
to reflect this specialization?
> The top use case will be heap access dispatch inline cache, which is not a
call.
> You can also use it to implement call inline caches, but that's not the
only thing you can use it for.
Er, possibly I'm misunderstanding you.  To me, a inline call cache is a 
mechanism to optimize a dynamic call by adding a typecheck+directcall 
fastpath.  (i.e. avoiding the dynamic dispatch logic in the common 
case)  I'm assuming this what you mean with the term "call inline 
cache", but I have never heard of a "heap access dispatch inline 
cache".  I've done a google search and didn't find a definition. 
Could
you point me to a reference or provide a brief explanation?

Philip

On Oct 22, 2013, at 1:48 PM, Philip R <listmail at philipreames.com>
wrote:
> On 10/22/13 10:34 AM, Filip Pizlo wrote:
>> On Oct 22, 2013, at 9:53 AM, Philip R <listmail at
philipreames.com> wrote:
>> 
>>> On 10/17/13 10:39 PM, Andrew Trick wrote:
>>>> This is a proposal for adding Stackmaps and Patchpoints to
LLVM. The
>>>> first client of these features is the JavaScript compiler
within the
>>>> open source WebKit project.
>>>> 
>>> I have a couple of comments on your proposal.  None of these are
major enough to prevent submission.
>>> 
>>> - As others have said, I'd prefer an experimental namespace
rather than a webkit namespace.  (minor)
>>> - Unless I am misreading your proposal, your proposed StackMap
intrinsic duplicates existing functionality already in llvm.  In particular,
much of the StackMap construction seems similar to the Safepoint mechanism used
by the in-tree GC support. (See CodeGen/GCStrategy.cpp and
CodeGen/GCMetadata.cpp).  Have you examined these mechanisms to see if you can
share implementations?
>>> - To my knowledge, there is nothing that prevents an LLVM
optimization pass from manufacturing new pointers which point inside an existing
data structure.  (e.g. an interior pointer to an array when blocking a loop) 
Does your StackMap mechanism need to be able to inspect/modify these
manufactured temporaries?  If so, I don't see how you could generate an
intrinsic which would include this manufactured pointer in the live variable
list.  Is there something I'm missing here?
>> These stackmaps have nothing to do with GC.  Interior pointers are a
problem unique to precise copying collectors.
> I would argue that while the use of the stack maps might be different, the
mechanism is fairly similar.
It's not at all similar.  These stackmaps are only useful for
deoptimization, since the only way to make use of the live state information is
to patch the stackmap with a jump to a deoptimization off-ramp.  You won't
use these for a GC.
> In general, if the expected semantics are the same, a shared implementation
would be desirable.  This is more a suggestion for future refactoring than
anything else.
I think that these stackmaps and GC stackmaps are fairly different beasts. 
While it's possible to unify the two, this isn't the intent here.  In
particular, you can use these stackmaps for deoptimization without having to
unwind the stack.
> 
> I agree that interior pointers are primarily a problem for relocating
collectors. (Though I disagree with the characterization of it being *uniquely*
a problem for such collectors.)  Since I was unaware of what you're using
your stackmap mechanism for, I wanted to ask.  Sounds like this is not an
intended use case for you.
>> 
>> In particular, the stackmaps in this proposal are likely to be used for
capturing only a select subset of state and that subset may fail to include all
possible GC roots.  These stackmaps are meant to be used for reconstructing
state-in-bytecode (where bytecode = whatever your baseline execution engine is,
could be an AST) for performing a deoptimization, if LLVM was used for compiling
code that had some type/value/behavior speculations.
> Thanks for the clarification.  This is definitely a useful mechanism. 
Thank you for contributing it back.
>> 
>>> - Your patchpoint mechanism appears to be one very specialized use
of a patchable location.  Would you mind renaming it to something like
patchablecall to reflect this specialization?
>> The top use case will be heap access dispatch inline cache, which is
not a call.
>> You can also use it to implement call inline caches, but that's not
the only thing you can use it for.
> Er, possibly I'm misunderstanding you.  To me, a inline call cache is a
mechanism to optimize a dynamic call by adding a typecheck+directcall fastpath.
Inline caches don't have to be calls.  For example, in JavaScript, the
expression "o.f" is fully dynamic but usually does not result in a
call.  The inline cache - and hence patchpoint - for such an expression will not
have a call in the common case.

Similar things arise in other dynamic languages.  You can have inline caches for
arithmetic.  Or for array accesses.  Or for any other dynamic operation in your
language.
>  (i.e. avoiding the dynamic dispatch logic in the common case)  I'm
assuming this what you mean with the term "call inline cache", but I
have never heard of a "heap access dispatch inline cache".  I've
done a google search and didn't find a definition.  Could you point me to a
reference or provide a brief explanation?
Every JavaScript engine does it, and usually the term "inline cache"
in the context of JS engines implies dispatching on the shape of the object in
order to find the offset at which a field is located, rather than dispatching on
the class of an object to determine what method to call.

-Filip
> 
> Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131022/88102040/attachment.html>