premain: negative lookup cache for class loaders

[David Lloyd]

On Thu, Jan 11, 2024 at 4:15 PM John Rose <john.r.rose at oracle.com> wrote:

> [...] But, a *failed* lookup is not recorded anywhere. So every distinct
> lookup must start again from first principles and fail all over again. For
> some workloads this costs a small but measurable percentage of startup time.
>
> The story is different for the local CONSTANT_Class entries in any given
> classfile: The JVMS mandates that both successful and failed lookups are
> recorded on the first attempt (per CP entry per se, not globally and not
> per class). Global usage includes both use of Class.forName and the “back
> end” logic for CP entry resolution. CP resolution is performed at most once
> per CP entry, and (win or lose) is made sticky on the CP itself, locally.
>
> To summarize, we can say that, for class lookup, both success and failure
> are “sticky” locally, and success is “sticky” globally, but failure is “not
> sticky” globally.
>
We have implemented a negative lookup cache in the past in certain of our
middleware products' custom class loaders, and while they *can* help, I
seem to recall that we had some trouble with cache explosion in some
scenarios involving certain frameworks. We abandoned that approach quite a
long time ago though in favor of a more optimized index-by-package scheme
which ensures that all lookups, success or failure, run in (more or less)
constant time, which had essentially eliminated the issue for us for that
use case.

FWIW I do think that it could be potentially nifty to constant-fold
negative lookup cases where that is possible.


-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240116/6ba339b8/attachment.htm>