RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v6]

[John R Rose]

On Fri, 15 Nov 2024 23:43:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored.  With the removal of the Security Manager in JEP 486, this code no longer does anything.
>> 
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Handle merge conflicts in new resolve_instance_class calls.
>  - Merge branch 'master' into protection-domain
>  - Purge last references to SecurityManager.
>  - More obsolete code.  Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS).
>  - Found more obsolete security manager code.
>  - More purging of AccessController, AccessControlContext and some stackwalking questions.
>  - David comments.
>  - Remove some more includes.
>  - 8341916: Remove ProtectionDomain related hotspot code and tests

Changes requested by jrose (Reviewer).

src/hotspot/share/classfile/systemDictionary.hpp line 41:

> 39: // represented as null.
> 40: 
> 41: // The underlying data structure is an concurrent hash table (Dictionary) per

typo: s/an concurrent/a concurrent/

src/hotspot/share/classfile/systemDictionary.hpp line 245:

> 243:   // compute java_mirror (java.lang.Class instance) for a type ("I", "[[B", "LFoo;", etc.)
> 244:   // Either the accessing_klass or the CL can be non-null, but not both.
> 245:   // Callee will fill in CL from the accessing klass, if they are needed.

The two comment lines ("Either … Callee …") should be one line:


+ // Callee will fill in CL from the accessing klass, if the CL is needed.

src/hotspot/share/prims/jvm.cpp line 169:

> 167:     while (!vfst.at_end()) {
> 168:       Method* m = vfst.method();
> 169:       if (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass())) {

We are no longer skipping AC frames, but user code will continue to use AC calls, even if they are silly.  Will this affect any existing caller-sensitive calculations?  The failure mode would be that a "get-caller-class" query would return AC.class, not the caller of the AC method.

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

PR Review: https://git.openjdk.org/jdk/pull/22064#pullrequestreview-2440266470
PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1844882878
PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1844883410
PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1844884671