RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v3]
Ioi Lam
iklam at openjdk.org
Fri Aug 22 17:24:18 UTC 2025
On Fri, 22 Aug 2025 14:07:43 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:
>> This code basically adds an entrypoint in the `SharedSecrets` class for other JDK core lib classes to call into package-private API in this package. It doesn't do anything else.
>>
>> There are several other classes where we have to do the same `SharedSecrets` set-up.
>>
>>
>> @AOTRuntimeSetup
>> private static void runtimeSetup() {
>> SharedSecrets.setJavaNetURLAccess(
>> new JavaNetURLAccess() {
>> @Override
>> public URLStreamHandler getHandler(URL u) {
>> return u.handler;
>> }
>> }
>> );
>> }
>
> I'm less worried about this particular `runtimeSetup` implementation and more with what it implies. Namely that we have URL instances - with particular URLStreamHandlers associated with them - running around in the archived heap. If in production, a different URLStreamHandler is configured for a given URL, we'll get two different sets of validation logic for assembly time URLs vs production run URLs.
>
> Are we able to limit the protocols that we create URLs for? I'm reaching for some way to contain the potential issue to something smaller that we can reason about
I added a check that URLs can be cache only if they use the `file` and `jtr` protocols, whose `URLStreamHandlers` cannot be overridden by the application.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2294262042
More information about the hotspot-dev
mailing list