Refinements to AssociatedConverterImpl.cache

[jglick]

I saw some thread dumps from a heavily loaded server that were all inside loadClass from AssociatedConverterImpl and noticed several things in sources that could be improved:

• ClassValue can be used as of Java 7 for this sort of cache based on Class. (Basically anything using Map<Class, T> with compute-on-first-load caching semantics.) This is simpler, and also allows garbage collection of classes (though for XStream types we would not expect the class loaders to be removed during a Jenkins session).
• The common case on a cache miss is that there is not any such converter. But then constructing the ClassNotFoundException is relatively expensive, especially fillInStackTrace. Suffices to short-circuit this by checking whether the corresponding *.class file even exists.
• Every XStream2 instance maintains its own cache, and thus has to do its own class loading (including negative cache misses) for every type that comes up in XML. There are normally several instances in the system, and while many types are only ever used in one, some (like PersistedList) may be used generically. I suspect this may have actually been the issue in the observed thread dumps, in conjunction with a bug in a proprietary plugin that leads to numerous XStream2 instances being constructed.

Testing done

Started Jenkins and did basic stuff (created a project, ran builds, saved global config) with some printlns verifying when cache misses were resolved and how.

Proposed changelog entries

• Refinements to class loading behavior looking up special formatters for XML configuration files.

Maintainer checklist

Before the changes are marked as ready-for-merge:

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[basil]

Nice optimization. Thanks for the PR!

substantive modification since then

[NotMyFault]

o, nice!

[basil]

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback. Please see the merge process documentation for more information about the merge process. Thanks!

[basil]

Causes JENKINS-72067.