JPPF Issue Tracker
star_faded.png
Please log in to bookmark issues
enhancement_small.png
CLOSED  Enhancement JPPF-45  -  Class loader enhancements
Posted Aug 19, 2012 - updated Sep 27, 2012
action_vote_minus_faded.png
1
Votes
 action_vote_plus_faded.png
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Enhancement
  • Status
     
    		 Closed
  • Assigned to
    lolo4j
  • Progress
       
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
    lolo4j
  • Owned by
    Not owned by anyone
  • Category
    Core
  • Resolution
    RESOLVED
  • Priority
    Normal
  • Targetted for
    icon_milestones.png JPPF 3.2
Issue description
This is about improving the performmnce of the class loader, especially in the nodes. Current ideas are:
  • limitation of class loader requests to a single thread needs to be addressed
  • possiblity of batching requests, accumulating requests until a periodic task sends them to the server
  • batching should also allow to find and remove duplicate requests (e.g. if 2 threads request loading of the same class), and decrease network traffic
  • caching of classes not found, so after the 1st request ClassNotFoundException can be thrown without looking up any further



#6
Comment posted by
lolo4j
Aug 29, 06:49
Caching of resources not previously found may cause a problem when dynamically adding elements to the class loader's classpath. In some cases, it is possible that the new classpath elements contain resources that were previously not found. In this scenario, we must provide a way to (partially) clear the cache. For now, I propose that we add an API to the AbstractJPPFClassLoader to do so, as it is the user's responsibility to update the classpath and then determine when the cache should be cleared.
#7
Comment posted by
lolo4j
Sep 02, 09:21
Implemented a first working version of the batching of class loader requests. Some things may be broken and more testing is definitely required.

Also, so far the class loading performance is still slightly slower than in 3.1.x. Some tuning will have to be done.

Changes committed to SVN revision 2356
#8
Comment posted by
lolo4j
Sep 02, 10:16
Implemented a first version of the caching of class loader misses, to avoid looking up again resources that are known to not be found. Currently, the code is using an in-memory soft references cache, and the performance improvement is quite impressive.

Also added an API AbstractJPPFClassLoader.clearNotFoundCache() to enable clearing the cache when libraries (jars or folders) are dynamically added to the class loader's classpath.

Changes committed to SVN revision 2357