llvm dev - Mar 2016 - Status of Garbage Collection with Statepoints in LLVM

Hi Martin,

Philip covered all of it very well, I'll just add one minor comment:
> More generally, can I back up and ask an important question?  Do you have
to
> support deoptimization (i.e. osr side exits) in any form? If you do,
you'll
> probably want to avoid the PlaceSafepoints utility pass.  If you need to
PlaceSafepoints is inadequate only if you have asynchronous
invalidation -- i.e. thread X is spinning in a long running loop while
thread Y loaded a class that makes the code running in thread X
invalid, so thread X needs to be polling for deopt safepoints.  If all
your invalidation events are synchronous then deopt bundles +
PlaceSafepoints should be enough for both deoptimization and precise
relocating GC.

If you don't need to *poll* for safepoints at all (perhaps the entire
VM is fully single threaded, so you safepoint only on allocation),
then PlaceSafepoints is not needed at all, and you can directly run
RewriteStatepointsForGC.

-- Sanjoy

On 4 Mar 2016, at 01:02, Sanjoy Das via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> PlaceSafepoints is inadequate only if you have asynchronous
> invalidation -- i.e. thread X is spinning in a long running loop while
> thread Y loaded a class that makes the code running in thread X
> invalid, so thread X needs to be polling for deopt safepoints.  If all
> your invalidation events are synchronous then deopt bundles +
> PlaceSafepoints should be enough for both deoptimization and precise
> relocating GC.
Presumably this also depends on the memory model that your language provides. 
If it’s something like Go, where no happens-before relationships are established
between threads by any mechanism other than explicit synchronisation (atomics or
message passing), then it’s perfectly fine for a thread in a long-running loop
that doesn’t contain any safepoints to see a stale copy for a very long time.

David

Thank you very much for the quick answers :)

> Though it turned out that:
>   * the pass for inserting statepoints is hard-coded to only work with
> samples and CLR (see [placesafepoints])
>   * the pass for rewriting statepoints is hard-coded to only work with
> samples and CLR (see [rewritestatepoints])
>
> In both cases, you're are going to need to introduce your own
GCStrategy
type.  We don't have a good way to ask questions about the GCStrategy
instance from IR transformation passes yet - it's on my long term todo, but
got stalled due to > some infrastructure issues - so we had to match names
in a couple of places.  I think you found both of them.

I did have my own GCStrategy type, but these two passes are currently
silently ignoring any strategies which don't have the right name. It would
be great if an error could be reported instead, but I saw the todo's to
address this.

> More generally, can I back up and ask an important question?  Do you have
to support deoptimization (i.e. osr side exits) in any form? If you do,
you'll probably want to avoid the PlaceSafepoints utility pass.  If you
need to support this case,
> let me know and we can share some code which hasn't made it upstream
yet.
We don't have any plans for deoptimizations right now.


  * the only backend supporting statepoints right now seems to be
64-bit
> intel (see [backend-x64])
>
> Since the ARM backend (and e.g. 32-bit intel) doesn't seem to have
support
> for lowering statepoints-using IR, we were rather disappointed.
>
> This is explicitly documented:
http://llvm.org/docs/Statepoints.html#supported-architectures
> Adding support for ARM (32?, 64?) shouldn't be too complicated.  If you
search for STATEPOINT in lib/Target/X86, you'll see there are only a small
handful of places which need architectural support.
> Most of the complexity is in the generic CodeGen parts.
> Adding support for 32 bit x86 should be even easier.  If I'm reading
the
code correctly, it looks like the only issue is in generating the right
call sequence.

That's good news :)

> One thing I want to ask: have you implemented inlining?  One thing we
found was that the relative importance of how we represented safepoints
dropped substantially once
> we got aggressive inlining in place.  Essentially, all of our hot
safepoints disappeared or became inliner bugs.  :)

We haven't implemented inlining. Currently we do a feasibility experiment
to find out if LLVM would be a good option for our problem (and GC is one
big hurdle to pass, the other one is probably exceptions which we haven't
looked at yet -- code size also matters to us).
Since we are in control of lowering source language to IR, inlining could
happen before we generate IR and/or on the IR-level via LLVM inlining, but
since we would use it in an AOT rather than a JIT setting for a dynamic
language, there are many calls where the receiver is not known at compile
time (maybe profile-based guarded optimization would be an option).


Is there any timeline for the statepoints support in
LLVM?
>
> Not explicitly.  This is directly driven by those of us using and
contributing to them.  As we find problems in our use cases, we fix them.
> Just to give some context, we (Azul) have reached what we believe to be a
stable state and are mostly focused on (non-gc related) performance
issues.
> Not all of our changes have made it upstream - specifically, the
gc-pointer distinction and exception handling mentioned in the list above -
but most of
> them have.  On the platform we care about (x86-64) and the configurations
we use (early poll insert, late rewriting), things appear stable.

Are the changes you have on top of LLVM ToT available somewhere (some of
the issues on the list seem to be relevant to us as well)?
May I ask: Do you use it in a production system already?


Is there a list of things that currently work / don't work with
safepoints?
>
> There wasn't a public list.  Rather than replying with one here,
I've
added to the statepoint documentation with the start of such a
list.
> http://llvm.org/docs/Statepoints.html#problem-areas-and-active-work
> If you have questions on any of these, please ask.
Thanks a lot for adding this.


Sidenote: It would be beneficial for users if the
[statepoints]
> documentation would highlight the current status and limitations.
>
> If you have suggestions for documentation fixes, please let me know. 
I'm
happy to either review changes or make the changes myself if you point out
problems.

One thing I ran into is the silent ignoring of GCStrategy's with wrong
name, but that seems to be already on the list.

> p.s. We're happy to talk on the phone or in person about these topics
as
well.  Having a higher bandwidth conversation can be quite
helpful.
> Let me know if you're interested in arranging such a meeting.  Or, if
you're local to the bay area, consider coming to one of the
socials.
> Sanjoy and I both generally attend and either of us can answer further
questions you might have.

Thanks for the offer :)
We'll spend a bit more time experimenting with the 64-bit intel
implementation for now and see how far we get with it. We might reach out
if we have more questions on the way.

On Fri, Mar 4, 2016 at 9:48 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk>
wrote:
> On 4 Mar 2016, at 01:02, Sanjoy Das via llvm-dev <llvm-dev at
lists.llvm.org>
> wrote:
> >
> > PlaceSafepoints is inadequate only if you have asynchronous
> > invalidation -- i.e. thread X is spinning in a long running loop while
> > thread Y loaded a class that makes the code running in thread X
> > invalid, so thread X needs to be polling for deopt safepoints.  If all
> > your invalidation events are synchronous then deopt bundles +
> > PlaceSafepoints should be enough for both deoptimization and precise
> > relocating GC.
>
> Presumably this also depends on the memory model that your language
> provides.  If it’s something like Go, where no happens-before relationships
> are established between threads by any mechanism other than explicit
> synchronisation (atomics or message passing), then it’s perfectly fine for
> a thread in a long-running loop that doesn’t contain any safepoints to see
> a stale copy for a very long time.
>
> David
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160307/63df335f/attachment.html>