-
Bug
-
Resolution: Fixed
-
P2
-
repo-valhalla
The current code used to preload classes was written in the early days of project Valhalla, when value types were always null-free, had no super-types, and preloading was mandatory for fields of those types in order to detect circularity issues. Since its inception, the current implementation suffers from two issues:
1 - it has no support for concurrent class loading during circularity detection
2 - it sometimes performs too much work, processing a class twice before detecting a circularity issue.
The value types model has evolved over time, and preloading operations now include some speculative loadings, where any loading issue must be silently discarded and not impact the loading of the current class.
With this new model, issue #2 mentioned above is becoming a critical issue, as the fact to process a class twice while discarding speculative loads failures can lead to attempts to define a class twice (detected by class loader constraints). Unfortunately, the successful definition of the class is the one from the speculative load, while the initial load fails because of the already defined class.
Since the initial model, the type hierarchy rules have evolved too, introducing super-types for value types (j.l.Object or abstract value classes), requiring now that the circularity detection for fields works in coordination with the existing circularity detection all classes have for their super-types.
And speculative loads are likely to trigger more loadings that the previous model, making issue #1 more probable.
The solution to address all those issues is to remove the special code to load value types with circularity detection, and to generalize the existing code used to load super types in order to make it fit to handle all loading requiring circularity detection. This approach would reduce the amount of code, will use only one kind of marker to detect circularity and only one queue to deal with concurrent class loading.
1 - it has no support for concurrent class loading during circularity detection
2 - it sometimes performs too much work, processing a class twice before detecting a circularity issue.
The value types model has evolved over time, and preloading operations now include some speculative loadings, where any loading issue must be silently discarded and not impact the loading of the current class.
With this new model, issue #2 mentioned above is becoming a critical issue, as the fact to process a class twice while discarding speculative loads failures can lead to attempts to define a class twice (detected by class loader constraints). Unfortunately, the successful definition of the class is the one from the speculative load, while the initial load fails because of the already defined class.
Since the initial model, the type hierarchy rules have evolved too, introducing super-types for value types (j.l.Object or abstract value classes), requiring now that the circularity detection for fields works in coordination with the existing circularity detection all classes have for their super-types.
And speculative loads are likely to trigger more loadings that the previous model, making issue #1 more probable.
The solution to address all those issues is to remove the special code to load value types with circularity detection, and to generalize the existing code used to load super types in order to make it fit to handle all loading requiring circularity detection. This approach would reduce the amount of code, will use only one kind of marker to detect circularity and only one queue to deal with concurrent class loading.
- duplicates
-
JDK-8326596 [lworld] Class preloading code cannot support speculative class loads nor concurrent class loads
-
- Closed
-