Description
This is a feature.
Profiling of deployment of large EAR with tens of EJB module reveals, that significant amount of deployment time was spend in filesystem access, especially on Windows. Thousands of calls were made to File.exists() and File.isDirectory. This was caused by ASURLClassLoader, which delegated all of resource existence checks to filesystem and FileArchive doing recursive folder scanning.
ASURLClassLoader did have map, that should serve as cache, but it cached positive lookups, whereas negative lookups are more expensive -- because every possible class source is scanned in order, and therefore there may be tens of negative lookups until positive one is found. Also, the use of this map was disabled because of generated folders.
This PR replaces these hot code paths:
ASURLClassloaderwalks each class folder and caches up to three levels of subdirectories. This give precise enough hit rate to avoid file misses- Since some of the folders contained generated classes, which are constructed after classloader is created, it will watch for filesystem changes to extend its set of prefixes.
FileArchiveuses file tree walking instead of recursive calls to file methods
Testing
New tests
DirWatcherTest tests the new decider for possibly valid files.
Testing Performed
Existing unit tests for FileArchive.
Ran against private large .ear with following results:
[Payara 5.191] [INFO] [] [javax.enterprise.system.core] [
app was successfully deployed in 72 787 milliseconds.]]
[Payara 5.194-SNAPSHOT] [INFO] [] [javax.enterprise.system.core] [[
app was successfully deployed in 51 453 milliseconds.]]
Test suites executed
Keeping that for Jenkins.
Testing Environment
Windows 10, 1.8.0_221, Maven 3.6.2
Notes for Reviewers
The PR only affects performance of directory-based classloaders (i. e. EJB generated folders, WEB-INF/classes), handling of JAR files is unaffected.
该提问来源于开源项目：payara/Payara
