[llvm-dev] OrcV1 removal

[Lang Hames via llvm-dev]

Hi All,

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.

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.

-- Lang.

On Mon, Sep 21, 2020 at 9:51 PM Lang Hames <lhames at gmail.com> wrote:

> 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/20200924/e6380438/attachment.html>