-
Bug
-
Resolution: Unresolved
-
P3
-
repo-leyden
Unless archived code contains class initialization barriers, it can be used only when all relevant classes are initialized. As it is implemented now, compiler runtime uses training data (CompileTrainingData::_init_deps) to determine when archived code can be loaded. But there are no guarantees that archived code and training data match. It can manifest as failures during archived code loading attempts or code which is never loaded.
Both in 1.5-step and 4-step training workflows, training data is gathered separately from archived code generation. Unless compilers closely follow training data contents and try to recreate the same set of dependencies for archived code, there's a chance that archived code will have different dependencies.
Alternative solution would be to use dependency information specific to archived code. It implies some duplication (between training data and archived code), but it would provide the most accurate data. Moreover, archived code already embeds information about init dependencies (see not_init bit in SCCReader::write_klass()/SCCReader::read_klass()), but it's hard to quickly access it when the decision to load code is made.
Both in 1.5-step and 4-step training workflows, training data is gathered separately from archived code generation. Unless compilers closely follow training data contents and try to recreate the same set of dependencies for archived code, there's a chance that archived code will have different dependencies.
Alternative solution would be to use dependency information specific to archived code. It implies some duplication (between training data and archived code), but it would provide the most accurate data. Moreover, archived code already embeds information about init dependencies (see not_init bit in SCCReader::write_klass()/SCCReader::read_klass()), but it's hard to quickly access it when the decision to load code is made.