[llvm-dev] OrcV1 removal

[Lang Hames via llvm-dev]

Hi All,

I'll be re-hashing this in more detail in this week's ORC Weekly update,
> hopefully with examples and cleaner code.


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 (
https://github.com/lhames/llvm-project/blob/orcv1-removal/llvm/unittests/ExecutionEngine/Orc/ResourceTrackerTest.cpp
).

-- Lang.

On Wed, Sep 16, 2020 at 11:52 AM Lang Hames <lhames at gmail.com> wrote:

> Hi All,
>
> I've updated the orcv1 removal branch (
> https://github.com/lhames/llvm-project/tree/orcv1-removal) 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.
>
> 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:
>
> *ResourceTracker* -- Your handle to remove code from a JITDylib. Also
> allows tracking to be merged onto another tracker (reducing the
> administrative overhead required for tracking).
> *ResourceKey* -- An opaque key associated with each tracker.
> *ResourceManager* -- A listener interface to be notified when resources
> associated with a given key should be removed.
>
> 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.
>
> 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.
>
> 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.
>
> Calling JITDylib::clear() will call remove on all trackers created by the
> JITDylib (including the default one).
>
> 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.
>
> 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.
>
> 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).
>
> I'll be re-hashing this in more detail in this week's ORC Weekly update,
> hopefully with examples and cleaner code.
>
> Regards,
> Lang.
>
> On Mon, Sep 7, 2020 at 9:26 PM Lang Hames <lhames at gmail.com> wrote:
>
>> Hi Andres,
>>
>> The orcv1-removal branch is now available (with OrcV1 removed) at
>> https://github.com/lhames/llvm-project/tree/orcv1-removal. I'll get to
>> work on the removable code feature -- hopefully I'll have something for you
>> to test soon.
>>
>> Regards,
>> Lang.
>>
>> On Mon, Sep 7, 2020 at 1:55 PM Lang Hames <lhames at gmail.com> wrote:
>>
>>> Hi Andres,
>>>
>>> Postgres uses removable code support and Orcv1. I does make me quite
>>>> worried to see a phase where there'll be no viable way of using both in
>>>> llvm.  Why isn't the right answer here to at lest develop the
>>>> replacement as a set of patches / as a branch that then can be merged as
>>>> a whole / shortly after each other, rather than just starting to develop
>>>> a replacement after the removal.
>>>
>>>
>>> That sounds good to me. I'll create a branch called 'orcv1-removal' for
>>> this shortly.
>>>
>>> Regards,
>>> Lang.
>>>
>>> On Mon, Sep 7, 2020 at 12:53 PM Andres Freund <andres at anarazel.de>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> On 2020-09-06 23:16:00 -0700, Lang Hames wrote:
>>>> > The time has finally come to remove OrcV1. I expect to remove it some
>>>> time
>>>> > after the 14th of September. This will remove all the legacy layers,
>>>> legacy
>>>> > utilities, the old Orc C bindings, and OrcMCJITReplacement.
>>>> ExecutionEngine
>>>> > and MCJIT will *not* be affected by this.
>>>> >
>>>> > I had hoped to have removable code enabled before deleting OrcV1, but
>>>> it
>>>> > turns out that implementing removable code in OrcV2 without
>>>> simultaneously
>>>> > breaking it in OrcV1 is difficult. Instead my plan is to delete OrcV1
>>>> and
>>>> > implement removable code in OrcV2 as quickly as possible. I think
>>>> this is
>>>> > the fastest path to where we want to be.
>>>> >
>>>> > If you're on llvm master, still using the legacy layers, and you
>>>> *don't*
>>>> > need removable code support, then I would encourage you to switch
>>>> over as
>>>> > soon as you're able. If you *do* need removable code support then you
>>>> may
>>>> > have to wait a few weeks for it to land.
>>>> >
>>>> > If you have any questions about the removal please let me know!
>>>>
>>>> Postgres uses removable code support and Orcv1. I does make me quite
>>>> worried to see a phase where there'll be no viable way of using both in
>>>> llvm.  Why isn't the right answer here to at lest develop the
>>>> replacement as a set of patches / as a branch that then can be merged as
>>>> a whole / shortly after each other, rather than just starting to develop
>>>> a replacement after the removal.
>>>>
>>>> Greetings,
>>>>
>>>> Andres Freund
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200921/1f273b33/attachment.html>