Displaying 5 results from an estimated 5 matches for "resourcekey".
2020 Apr 20
2
ORC JIT Weekly #12
...patch to prioritize work
by type, e.g. prioritizing stubs and other trivial-to-materialize symbols.
Finally, I hope to spend next week working on support for removable code in
OrcV2, which is one of the big missing features from OrcV1. I expect the
API to end up looking something like this:
using ResourceKey = const class ResourceTracker*;
class ResourceTracker {
public:
// Return the key for this tracker (just its address)
ResourceKey getKey() { return this; }
// Emit all not-yet-emitted symbols covered by this tracker.
Expected<SymbolMap> emit();
// Remove all symbols covered by thi...
2020 Sep 16
4
OrcV1 removal
...sts 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...
2020 Sep 24
2
OrcV1 removal
...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::getDefaultResourceT...
2020 Sep 07
2
OrcV1 removal
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
2020 Sep 16
2
OrcV1 removal
...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,...