RFR: 8349559: Compiler interface doesn't need to store protection domain

Ioi Lam iklam at openjdk.org
Fri Feb 7 20:13:11 UTC 2025


On Thu, 6 Feb 2025 17:14:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The compiler interface has a protection_domain field that it uses for matching in its version of not-yet loaded classes, but class loading only uses (class, class-loader) as an identifier for loaded classes so the compiler interface should do the same.  From the code, I can't see any situation where the protection_domain wouldn't match if name and class loader match.  Actually I think the code was for this case: if you match (name, classLoader) with a calling class with the same classLoader and a different protectionDomain, the code should not match the class without going through the SystemDictionary to call checkPackageAccess() for the second protectionDomain.  Since checkPackageAccess is now removed with the security manager, this extra lookup is now unnecessary and we match just class name, classLoader pairs.
> 
> Tested with tier1-7.

Looks fine to me.
I don't know why the original code was caching the PD.  name+loader is already unique. You can’t have two accessing_klasses with the same name+loader but different PDs.

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23496#pullrequestreview-2602736996


More information about the hotspot-compiler-dev mailing list