search for: resourcekey

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,...