<div dir="ltr">Hi All,<div><br></div><div>The Kaleidoscope tutorials have now been updated on the orcv1-removal branch. I will try to summarise the state of the work and provide some examples in the ORC JIT Weekly mailout tomorrow. The short version is that I think this is ready to land on the mainline.</div><div><br></div><div>If anyone wants to check out the OrcV1 removal branch and provide feedback now is the time. Otherwise I will aim to land the work in the mainline early next week.</div><div><br></div><div>-- Lang.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 21, 2020 at 9:51 PM Lang Hames <<a href="mailto:lhames@gmail.com">lhames@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi All,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I'll be re-hashing this in more detail in this week's ORC Weekly update, hopefully with examples and cleaner code.</blockquote><div><br></div><div>Time got away from me last week unfortunately. I'm still landing unit tests and cleanups on the OrcV1 removal branch, but I hope to put out an ORC Weekly update on Friday covering the latest developments. In the meantime you can find some very basic example usage in llvm/unittests/ExecutionEngine/Orc/ResourceTrackerTest.cpp (<a href="https://github.com/lhames/llvm-project/blob/orcv1-removal/llvm/unittests/ExecutionEngine/Orc/ResourceTrackerTest.cpp" target="_blank">https://github.com/lhames/llvm-project/blob/orcv1-removal/llvm/unittests/ExecutionEngine/Orc/ResourceTrackerTest.cpp</a>).</div><div><br></div><div>-- Lang. </div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 16, 2020 at 11:52 AM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi All,<div><br></div><div>I've updated the orcv1 removal branch (<a href="https://github.com/lhames/llvm-project/tree/orcv1-removal" target="_blank">https://github.com/lhames/llvm-project/tree/orcv1-removal</a>) with an initial patch for removable code. If anyone wants to follow along with the development or share thoughts on the design you're very welcome to.</div><div><br></div><div>I'll be adding tests and comments this week, but for anyone who wants to take an early look the main elements are defined in Core.h:</div><div><br></div><div><i>ResourceTracker</i> -- Your handle to remove code from a JITDylib. Also allows tracking to be merged onto another tracker (reducing the administrative overhead required for tracking).</div><div><i>ResourceKey</i> -- An opaque key associated with each tracker.</div><div><i>ResourceManager</i> -- A listener interface to be notified when resources associated with a given key should be removed.</div><div><br></div><div>Each JITDylib will have a default tracker (accessible via JITDylib::getDefaultResourceTracker), and allow creation of new trackers (via JITDylib::createResourceTracker). When adding a MaterializationUnit to a JITDylib (with JITDylib::define, or a Layer's add method) you can optionally specify a tracker to associate with that unit. If no tracker is specified the default tracker for the target JITDylib will be used. A single tracker can be associated with multiple units the remove and transferTo operations (see below) will apply to all associated units.</div><div><br></div><div>You can call ResourceTracker::remove at any time to remove all symbols and resources associated with a tracker. Any active compiles associated with the tracker will receive an error when they try to update the JIT state via their MaterializationResponsibility, and will not be able to associate resources with the tracker's associated ResourceKey.</div><div><br></div><div>You can call ResourceTracker::transferTo at any time. This will transfer tracking of all associated symbols and resources to the destination tracker. Any active compiles associated with the tracker will be reassociated with the destination tracker, and all future resources will be associated with the destination tracker. Merging trackers can reduce administrative overhead, especially when merging onto the default tracker for the JITDylib, which has a more compact representation for ownership of symbols.</div><div><br></div><div>Calling JITDylib::clear() will call remove on all trackers created by the JITDylib (including the default one).</div><div><br></div><div>ResourceTrackers have shared ownership, but the ExecutionSession and JITDylib do not retain ownership (except for the default tracker). If you release all pointers to a tracker its resources will be automatically transferred (via transferTo) to the default tracker for the JITDylib.</div><div><br></div><div>ResourceManagers (usually Layers) can call MaterializationResponsibility::withKeyDo(...) to associate a ResourceKey with JIT resources (e.g. allocated memory) in a way that is safe even if remove/transferTo is called on the same tracker from other threads.</div><div><br></div><div>A note for those of you who've been following along with the ORC Weekly emails: I had previously convinced myself that we'd only be able to do JITDylib at a time removal. This scheme is more flexible than that -- I'm hoping it ends up being a nice compromise. If you ignore tracking in your API it is effectively JITDylib-at-a-time (through the default tracker), but if you do want to do fine grained removal you can, you just assume responsibility for properly handling dependencies (i.e. not removing anything that the JIT program might still be using).</div><div><br></div><div>I'll be re-hashing this in more detail in this week's ORC Weekly update, hopefully with examples and cleaner code.</div><div><br></div><div>Regards,</div><div>Lang. </div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 7, 2020 at 9:26 PM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Andres,<div><br></div><div>The orcv1-removal branch is now available (with OrcV1 removed) at <a href="https://github.com/lhames/llvm-project/tree/orcv1-removal" target="_blank">https://github.com/lhames/llvm-project/tree/orcv1-removal</a>. I'll get to work on the removable code feature -- hopefully I'll have something for you to test soon.</div><div><br></div><div>Regards,</div><div>Lang.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 7, 2020 at 1:55 PM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Andres,<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Postgres uses removable code support and Orcv1. I does make me quite<br>worried to see a phase where there'll be no viable way of using both in<br>llvm.  Why isn't the right answer here to at lest develop the<br>replacement as a set of patches / as a branch that then can be merged as<br>a whole / shortly after each other, rather than just starting to develop<br>a replacement after the removal.</blockquote></div><div><br></div><div>That sounds good to me. I'll create a branch called 'orcv1-removal' for this shortly.</div><div><br></div><div>Regards,</div><div>Lang. </div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 7, 2020 at 12:53 PM Andres Freund <<a href="mailto:andres@anarazel.de" target="_blank">andres@anarazel.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On 2020-09-06 23:16:00 -0700, Lang Hames wrote:<br>
> The time has finally come to remove OrcV1. I expect to remove it some time<br>
> after the 14th of September. This will remove all the legacy layers, legacy<br>
> utilities, the old Orc C bindings, and OrcMCJITReplacement. ExecutionEngine<br>
> and MCJIT will *not* be affected by this.<br>
> <br>
> I had hoped to have removable code enabled before deleting OrcV1, but it<br>
> turns out that implementing removable code in OrcV2 without simultaneously<br>
> breaking it in OrcV1 is difficult. Instead my plan is to delete OrcV1 and<br>
> implement removable code in OrcV2 as quickly as possible. I think this is<br>
> the fastest path to where we want to be.<br>
> <br>
> If you're on llvm master, still using the legacy layers, and you *don't*<br>
> need removable code support, then I would encourage you to switch over as<br>
> soon as you're able. If you *do* need removable code support then you may<br>
> have to wait a few weeks for it to land.<br>
> <br>
> If you have any questions about the removal please let me know!<br>
<br>
Postgres uses removable code support and Orcv1. I does make me quite<br>
worried to see a phase where there'll be no viable way of using both in<br>
llvm.  Why isn't the right answer here to at lest develop the<br>
replacement as a set of patches / as a branch that then can be merged as<br>
a whole / shortly after each other, rather than just starting to develop<br>
a replacement after the removal.<br>
<br>
Greetings,<br>
<br>
Andres Freund<br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>