[Picking up and finishing off https://github.com/openjdk/jdk/pull/32519 for 
Coleen]

Remove the upcall to addClass during class loading. The comment says it's only 
so GC can keep classes alive while the class loader is alive. We have other 
ways to do that. There were some JVMTI tests in the past that failed without 
this vector but today seems to be only one test. Maybe there's some code that 
has a dependency on this in heap walking.
Tested tier1-6

---------
- [x] I confirm that I make this contribution in accordance with the [OpenJDK 
Interim AI Policy](https://openjdk.org/legal/ai).

-------------

Commit messages:
 - review comments
 - Use Alan's suggested spec changes.
 - Add an implementation note to JVMTI_HEAP_REFERENCE_OTHER, and make the old 
Heap function return true not false.
 - Remove JVMTI_REFERENCE_HEAP_OTHER for old Heap 1.0 call.  Exclude hidden 
classes from compatible class walk.
 - Fix wording in test. Not a special root reference.
 - Add JVMTI_REFERENCE_OTHER for classes found in from the class loader.
 - fix copyright
 - This is why I picked JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT.  It's what it used 
to return.
 - hack mirrors into class loader for referring class loader
 - Update src/hotspot/share/classfile/systemDictionary.cpp
 - ... and 10 more: https://git.openjdk.org/jdk/compare/6120f1b2...ec7cdc90

Changes: https://git.openjdk.org/jdk/pull/32890/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=32890&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8391308
  Stats: 457 lines in 11 files changed: 403 ins; 41 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/32890.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/32890/head:pull/32890

PR: https://git.openjdk.org/jdk/pull/32890

Reply via email to