Use a simpler approach to compute class flags #4269
Conversation
* The concerned core classes are all subclasses of Object, so there is only one set of shared flags and no need to decide that at runtime with complex logic. * Avoids loading core classes in Constants.java.
|
0.006s is not a very substantial gain for essentially reversing my Flag Registry change completely. The purpose of this registry is to avoid user error when adding new flags, which will become important as we have more specialized object forms. Your version makes it easy (again) to mess up a flag and accidentally be using it for two things, possibly by overlapping a superclass. I think we can deal with the Constants issue another way. |
|
FWIW, I intended to do a code-generation pass to make the constants in Constants be truly literal constants, since these flags can be determined at build time. That would keep the safety of the registry and address your concerns. We could also just move these constants elsewhere. |
|
I was mostly interested in the simplicity of the approach, since it seems these flags didn't change in a long time. But indeed, if many flags are added then the current system is safer. I was in particular looking at how JRuby+Truffle uses these constants, but there is now a different Constants.java to help AOT compilation. |
so there is only one set of shared flags and no need
to decide that at runtime with complex logic.
jruby -vis a tiny bit faster now: 0.083s vs 0.089s.@headius Could you have a look at this?
This avoids loading a good part of JRuby classic just when using the Constants :)