[llvm-dev] OrcV1 removal

[Lang Hames via llvm-dev]

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/20200916/ba038d30/attachment.html>