We are working on replacing the BasicHashtable and Hashtable implementations in the runtime. The SA has these classes defined, and the function allEntriesDo (like the JVMTI function) but they are unused by the SA.
The only reason to use the Dictionary in the ClassLoaderData is to see which classes initiate loading for other classes. This is viewable inside GDB if you really need it. It's an implementation detail that is unlikely to be the cause of crash logs and core files in the field.
I think there used to be a caller for ClassLoaderDataGraph.allEntriesDo. The hprof and useful class dump functionality uses classesDo, which uses the ClassLoaderData::_klasses field to iterate, not the dictionary.
The only reason to use the Dictionary in the ClassLoaderData is to see which classes initiate loading for other classes. This is viewable inside GDB if you really need it. It's an implementation detail that is unlikely to be the cause of crash logs and core files in the field.
I think there used to be a caller for ClassLoaderDataGraph.allEntriesDo. The hprof and useful class dump functionality uses classesDo, which uses the ClassLoaderData::_klasses field to iterate, not the dictionary.
- blocks
-
JDK-8269986 Remove +3 from Symbol::identity_hash()
-
- Resolved
-
- relates to
-
JDK-8324274 SA throws WrongTypeException because of static field check
-
- Closed
-