New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[cxxmodules] Fix failing runtime_cxxmodules tests by preloading modules #1814
Conversation
@phsft-bot build just on slc6/gcc62 with flags -Druntime_cxxmodules=On -Dctest_test_exclude_none=on |
core/metacling/src/TCling.cxx
Outdated
@@ -1258,7 +1274,32 @@ TCling::TCling(const char *name, const char *title) | |||
// Load libc and stl first. | |||
LoadModules({"libc", "stl"}, *fInterpreter); | |||
|
|||
LoadModules({"ROOT_Foundation_C", "ROOT_Config", "ROOT_Foundation_Stage1_NoRTTI", "Core", "RIO"}, *fInterpreter); | |||
// Load core modules | |||
std::vector<std::string> CoreModules = {"ROOT_Foundation_C","ROOT_Config","ROOT_Foundation_Stage1_NoRTTI", "Core", "RIO"}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe that'd be better being a std::set<const char*>?
core/metacling/src/TCling.cxx
Outdated
if (!ModuleName.empty() && std::find(CoreModules.begin(), CoreModules.end(), ModuleName) == CoreModules.end()) { | ||
if (M->IsSystem && !M->IsMissingRequirement) | ||
LoadModule(ModuleName, *fInterpreter); | ||
else if (!M->IsSystem && !M->IsMissingRequirement) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should check for filenames, i.e. if the module is present on disk as a pcm file.
core/metacling/src/TCling.cxx
Outdated
LoadModules(CoreModules, *fInterpreter); | ||
|
||
// Otherwise module conflicts between rootcling and root | ||
if (!fromRootCling) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This check can likely go away if we check if the module is already built (i.e. if it has an on-disk representing pcm). This way rootcling will become more efficient by building a module, while reusing the previously build ones.
@phsft-bot build just on slc6/gcc62 with flags -Druntime_cxxmodules=On -Dctest_test_exclude_none=on |
1 similar comment
@phsft-bot build just on slc6/gcc62 with flags -Druntime_cxxmodules=On -Dctest_test_exclude_none=on |
Starting build on |
Starting build on |
@phsft-bot build just on slc6/gcc62 with flags -Druntime_cxxmodules=On -Dctest_test_exclude_none=on |
Starting build on |
Build failed on slc6/gcc62. Errors:
Failing tests:
And 32 more |
Starting build on |
@phsft-bot build just on slc6/gcc62 with flags -Druntime_cxxmodules=On -Dctest_test_exclude_none=On |
Starting build on |
@phsft-bot build just on slc6/gcc62 with flags -Druntime_cxxmodules=On -Dctest_test_exclude_none=On -DCMAKE_BUILD_TYPE=Release |
Starting build on |
6c6900e
to
4c864d1
Compare
Starting build on |
@phsft-bot build just on slc6/gcc62 with flags -Druntime_cxxmodules=On -Dctest_test_exclude_none=On |
Starting build on |
@phsft-bot build just on slc6/gcc62 with flags -DLLVM_BUILD_TYPE=Debug -Droofit=Off -Druntime_cxxmodules=On -DCMAKE_VERBOSE_MAKEFILE:BOOL=On -Dctest_test_exclude_none=On |
Starting build on |
@phsft-bot build just on slc6/gcc62 with flags -DLLVM_BUILD_TYPE=Debug -Droofit=Off -Druntime_cxxmodules=On -DCMAKE_VERBOSE_MAKEFILE:BOOL=On -Dctest_test_exclude_none=On |
Starting build on |
Build failed on ubuntu16/native. Failing tests: |
Build failed on centos7/gcc7. Failing tests: |
Build failed on centos7/gcc62. Failing tests: |
Build failed on slc6/gcc48. Failing tests: |
Build failed on centos7/gcc7. Failing tests: |
Build failed on slc6/gcc52. Failing tests: |
Build failed on slc6/gcc49. Failing tests: |
Build failed on slc6/gcc48. Failing tests: |
Build failed on slc6/clang39. Warnings:
Failing tests: |
Build failed on mac1013/native. Warnings:
Failing tests: |
…ized decls Preloading all the modules has several advantages. 1. We do not have to rely on rootmap files which don't support some features (namespaces and templates) 2. Lookup would be faster because we don't have to do trampoline via rootmap files. Autoloading libraries when decls are deserialized gives us correctness. However we still need to optimize the performance by reducing the amount of loaded libraries and improving Clang performance.
Starting build on |
Build failed on ubuntu16/native. Failing tests: |
Build failed on centos7/gcc7. Failing tests: |
Build failed on centos7/gcc62. Failing tests: |
Build failed on slc6/gcc48. Failing tests: |
Build failed on slc6/clang39. Failing tests: |
Build failed on slc6/gcc52. Failing tests: |
Build failed on mac1013/native. Failing tests: |
Build failed on slc6/gcc48. Failing tests: |
Build failed on slc6/gcc49. Failing tests: |
Build failed on centos7/gcc7. Failing tests: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Could a comment be added here on why the failure "projectroot.roottest.root.meta.roottest_root_meta_execUnloading_auto" does not prevent merging? (i.e. what is the plan to resolve it (upcoming fix in ROOT or ROOTTEST or revert this PR or something else?) ... in the meantime this will show up in all master builds including new PRs ... ) |
To answer my own question: The test needed to be updated and was updated by root-project/roottest#180. Several PR and incremental failed due to the (unavoidable) lag between this PR being merged in and the roottest PR being merged in. |
Currently, 36 tests are failing for runtime modules:
https://epsft-jenkins.cern.ch/view/ROOT/job/root-nightly-runtime-cxxmodules/
We want to make these test pass so that we can say that the runtime modules is
finally working.
This patch enables ROOT to preload all modules at startup time. In my
environment, this patch fixes 14 tests for runtime cxxmodules.
Preloading all the modules has several advantages. 1. We do not have to
rely on rootmap files which don't support some features (namespaces and
templates) 2. Lookup would be faster because we don't have to do
trampoline via rootmap files.
The only disadvantage of preloading all the modules is the startup time performance.
root.exe -q -l memory.C
This is a release build without modules:
This is a release build with modules, with this patch:
As you can see, preloading all the modules makes both time and memory 2
to 3 times worse at a startup time.
Edit : With hsimple.C
root.exe -l -b tutorials/hsimple.C -q ~/CERN/ROOT/memory.C
Release build without modules:
Release build with modules, with this patch:
However, it is a matter of course that we get slower startup time if we
try to load all the modules at startup time, not on-demand. I haven't had a good benchmark for this but, in theory, it reduces execution time instead as we're anyway loading modules after the startup.