The database produced when running the tool on OMR and on OpenJ9 are inconsistent. When running the tool on OpenJ9, it automatically has to run on OMR, hence the database produced when running the tool on OMR independently is expected to be a subset of the database generated from running the tool on OpenJ9. The only difference between both databases should be classes and functions related to the testing language used when running OMR independently (TestCompiler namespace), however when comparing both databases, there are more classes that are found in the OMR database but not in the OpenJ9 one.
While ignoring classes that are in the TestCompiler or testing namespaces, I found 97 classes that are found in the OMR database but not in the OpenJ9 one. Although none of these classes are extensible, some of them were part of the OMR and TR namespace (like OMR::Monitor, OMR::UnionType, TR::IlType, TR::FrontEnd...).
The database produced when running the tool on OMR and on OpenJ9 are inconsistent. When running the tool on OpenJ9, it automatically has to run on OMR, hence the database produced when running the tool on OMR independently is expected to be a subset of the database generated from running the tool on OpenJ9. The only difference between both databases should be classes and functions related to the testing language used when running OMR independently (
TestCompiler
namespace), however when comparing both databases, there are more classes that are found in the OMR database but not in the OpenJ9 one.While ignoring classes that are in the
TestCompiler
ortesting
namespaces, I found 97 classes that are found in the OMR database but not in the OpenJ9 one. Although none of these classes are extensible, some of them were part of theOMR
andTR
namespace (likeOMR::Monitor
,OMR::UnionType
,TR::IlType
,TR::FrontEnd
...).The used script can be found here