IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This fixes a PyROOT performance regression between 6.02 and 6.04, seen by ATLAS.
(cherry picked from commit ba4b0df02a91be4102e62fc76038711d188f07f3)
Conflicts:
interpreter/cling/lib/Interpreter/Value.cpp
This prevents:
==4150== Possible data race during write of size 8 at 0xCC136F0 by thread #3
==4150== Locks held: none
==4150== at 0x146EC214: llvm::SmallVectorTemplateBase<cling::IncrementalExecutor::CXAAtExitElement, false>::grow(unsigned long) (in /afs/cern.ch/cms/sw/ReleaseCandidates/volB/slc6_amd64_gcc491/lcg/root/6.02.00-lnjiaj2/lib/libCling.so)
==4150== by 0x146E9DE3: cling::IncrementalExecutor::AddAtExitFunc(void (*)(void*), void*, cling::Transaction const*) (in /afs/cern.ch/cms/sw/ReleaseCandidates/volB/slc6_amd64_gcc491/lcg/root/6.02.00-lnjiaj2/lib/libCling.so)
==4150== by 0x160A5044: ???
==4150== by 0x160A67D6: ???
==4150== by 0x160A6783: ???
==4150== by 0x145E76D3: TCling::ExecuteWithArgsAndReturn(TMethod*, void*, void const**, int, void*) const (in /afs/cern.ch/cms/sw/ReleaseCandidates/volB/slc6_amd64_gcc491/lcg/root/6.02.00-lnjiaj2/lib/libCling.so)
Conflicts:
interpreter/cling/lib/Interpreter/IncrementalExecutor.cpp
On some platforms, global destructors are registered through a call to
__cxa_atexit(dtor, 0/*args*/, __dso_handle). While __cxa_atexit can be resolved
by the regular MemoryManager, __dso_handle (representing the "current shared
library" such that the corresponding atexit function can be called on its
dlclose) can not be resolved by MCJIT. Instead, we provide our own, poining to
the ExecutionEngine, which in turn holds a "current module" that corresponds in
spirit to the shared library handle.
__cxa_atexit, on the other hand, needs to be re-wired: the interpreter needs to
destruct globals upon its destruction, and those globals from a certain module
when that module is unloaded.
Both is done through a custom MemoryManager, significantly reducing the
complexity of the previous ("JIT without MC") implementation.
The custom MemoryManager also forwards in case of a unknown symbols to the LazyFunctionCreators instead of using the generic
ExecutionEngine::InstallLazyFunctionCreator() which has no effect with MCJIT.
MCJIT needs to finalize modules. To simplify the interface with MCJIT, each
transaction now has its own module. It gets created when the previous module
gets passed to the execution engine; the first one is created by
clang::CreateLLVMCodeGen(). CodeGen now releases the module such that it can be
added to the execution engine.
This enables simple use cases of cling with MCJIT; most notably cross-module
linking is still missing.
