Displaying 4 results from an estimated 4 matches for "createresourcetrack".
Did you mean:
createresourcetracker
2020 Sep 16
4
OrcV1 removal
...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 mul...
2020 Sep 16
2
OrcV1 removal
...;t really do the same for resource trackers, if I understand this
> correctly. Sketching out what I'd need to do to test postgres, so I
> don't waste time going in the wrong direction:
1) Add API for management (create, destroy) a non-default resource tracker
> (i.e. JITDylib::createResourceTracker)
> 3) Add JITDylib::clear() wrapper
> 2) LLVMOrcLLJITAdd{LLVMIRModule,ObjectFile} would need a new argument
> (defaulting to NULL for the default resource tracker?) to specify the
> resource tracker
> 4) LLJIT would need to grow the underlying support methods
That's all...
2020 Sep 24
2
OrcV1 removal
...anager* -- 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
>> singl...
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