JDK-8195744 : Avoid calling ClassLoader.checkPackageAccess if security manager is not installed
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 10
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2018-01-19
  • Updated: 2020-07-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Related Reports
Relates :  
Relates :  
During class resolution, the JVM calls ClassLoader.checkPackageAccess(), and then updates DictionaryEntry::_pd_set accordingly.


    if (HAS_PENDING_EXCEPTION) return;
    dictionary->add_protection_domain(d_index, d_hash, klass,
                                      protection_domain, THREAD);

However, when the security manager is not installed, ClassLoader.checkPackageAccess() does nothing:


    private void checkPackageAccess(Class<?> cls, ProtectionDomain pd) {
        final SecurityManager sm = System.getSecurityManager();
        if (sm != null) {
            ... do some checks ....

So the JVM is making all these Java upcalls and maintaining a complicated cache for nothing. This causes slow down both in class loading time, as well as in GC pauses.

Preliminary benchmarking shows about 1.5% speed up when running hello world in clojure.
The security manager may be installed at runtime via System::setSecurityManager. JDK-8191053 proposes to provide a mechanism to flag that security manager is immutable in this execution. This way will enable reliable optimization when the VM can call java_lang_System::has_security_manager() to determine the security manager is null and skip the upcall to ClassLoader::checkPackageAccess.

I really want to get rid of the pd cache altogether (or move it into Java code). However, that may have a performance impact. See http://hg.openjdk.java.net/jdk/hs/file/5264a11d3753/src/hotspot/share/classfile/dictionary.cpp#l366 InstanceKlass* Dictionary::find(unsigned int hash, Symbol* name, Handle protection_domain) { NoSafepointVerifier nsv; int index = hash_to_index(hash); DictionaryEntry* entry = get_entry(index, hash, name); if (entry != NULL && entry->is_valid_protection_domain(protection_domain)) { return entry->instance_klass(); } else { return NULL; } } If we get rid of the cache, when a security manager is installed, we would have to make an upcall to ClassLoader.checkPackageAccess for each call to Dictionary::find(). Doing that may significantly slowed down class resolution.