<div dir="ltr"><span class="im" style="font-size:12.8px"><div><span style="color:rgb(34,34,34);font-size:12.8px">Thank you very much for the quick answers :)</span><br></div></span><span class="im" style="font-size:12.8px"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Though it turned out that:<br> * the pass for inserting statepoints is hard-coded to only work with samples and CLR (see [placesafepoints])<br> * the pass for rewriting statepoints is hard-coded to only work with samples and CLR (see [rewritestatepoints])<br></blockquote></span><span style="font-size:12.8px">> 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.</span><br style="font-size:12.8px"><br>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.<div><br><br><span style="font-size:12.8px">> 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,</span><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">let me know and we can share some code which hasn't made it upstream yet.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">We don't have any plans for deoptimizations right now.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span><div><span class="im" style="font-size:12.8px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> * the only backend supporting statepoints right now seems to be 64-bit intel (see [backend-x64])<br><br>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.<br></blockquote></span><span style="font-size:12.8px">> This is explicitly documented: </span><a href="http://llvm.org/docs/Statepoints.html#supported-architectures" rel="noreferrer" target="_blank" style="font-size:12.8px">http://llvm.org/docs/Statepoints.html#supported-architectures</a><br style="font-size:12.8px"><br><span style="font-size:12.8px">> 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.</span></div><div><span style="font-size:12.8px">> Most of the complexity is in the generic CodeGen parts.</span></div><div><span style="font-size:12.8px">> 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.</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">That's good news :)</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> 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 </span></div><div><span style="font-size:12.8px">> we got aggressive inlining in place. Essentially, all of our hot safepoints disappeared or became inliner bugs. :)</span></div><div><span class="im" style="font-size:12.8px"><font color="#222222"><br></font></span></div><div><span class="im" style="font-size:12.8px"><font color="#222222">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).</font></span></div><div><span class="im" style="font-size:12.8px"><font color="#222222">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).<br></font><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Is there any timeline for the statepoints support in LLVM?<br></blockquote></span><span style="font-size:12.8px">> 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.</span><br style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> 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.</span></div><div><span style="font-size:12.8px">> 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</span></div><div><span style="font-size:12.8px">> them have. On the platform we care about (x86-64) and the configurations we use (early poll insert, late rewriting), things appear stable.</span><span class="im" style="font-size:12.8px"><br><br><span style="color:rgb(34,34,34);font-size:12.8px">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)?</span></span></div><div><span class="im" style="font-size:12.8px"><span style="color:rgb(34,34,34);font-size:12.8px">May I ask: Do you use it in a production system already?</span><br><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Is there a list of things that currently work / don't work with safepoints?<br></blockquote></span><span style="font-size:12.8px">> 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.</span><br style="font-size:12.8px">> <a href="http://llvm.org/docs/Statepoints.html#problem-areas-and-active-work" rel="noreferrer" target="_blank" style="font-size:12.8px">http://llvm.org/docs/Statepoints.html#problem-areas-and-active-work</a><br style="font-size:12.8px"><span style="font-size:12.8px">> If you have questions on any of these, please ask.</span><span class="im" style="font-size:12.8px"><br><br><span style="color:rgb(34,34,34);font-size:12.8px">Thanks a lot for adding this.</span></span></div><div><span class="im" style="font-size:12.8px"><font color="#222222"><br></font><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">Sidenote: It would be beneficial for users if the [statepoints] documentation would highlight the current status and limitations.</span><br></blockquote></span><span style="font-size:12.8px">> 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.</span></div></div></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">One thing I ran into is the silent ignoring of GCStrategy's with wrong name, but that seems to be already on the list.</span></div><div><br></div><div><br></div><div><span style="font-size:12.8px">> 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. </span></div><div><span style="font-size:12.8px">> 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.</span></div><div><span style="font-size:12.8px">> Sanjoy and I both generally attend and either of us can answer further questions you might have.</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Thanks for the offer :)</span></div><div><span style="font-size:12.8px">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.</span><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 4, 2016 at 9:48 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 4 Mar 2016, at 01:02, Sanjoy Das via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> PlaceSafepoints is inadequate only if you have asynchronous<br>
> invalidation -- i.e. thread X is spinning in a long running loop while<br>
> thread Y loaded a class that makes the code running in thread X<br>
> invalid, so thread X needs to be polling for deopt safepoints. If all<br>
> your invalidation events are synchronous then deopt bundles +<br>
> PlaceSafepoints should be enough for both deoptimization and precise<br>
> relocating GC.<br>
<br>
</span>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.<br>
<span class="HOEnZb"><font color="#888888"><br>
David<br>
<br>
<br>
</font></span></blockquote></div><br></div>