On Fri, 15 Nov 2024 23:43:33 GMT, Coleen Phillimore <[email protected]> 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
