RFR: 8374308: ImageBufferCache does not work as intended [v4]
Alan Bateman
alanb at openjdk.org
Tue Jan 6 12:12:25 UTC 2026
On Tue, 6 Jan 2026 11:23:29 GMT, David Beaumont <duke at openjdk.org> wrote:
>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>>
>> simplifying allocation and argument checks
>
> src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 373:
>
>> 371: throw new InternalError("Image file channel not open");
>> 372: }
>> 373: ByteBuffer buffer = ByteBuffer.allocate(checkedSize);
>
> I changed this to just "allocate" (not "allocateDirect") after carefully reading up on direct buffers.
> It's just possible this might have an observable effect (positive or negative) on either performance or memory pressure, so I'm happy to change it back if people are worried.
>
> It's the only bit of this change that I think might not be a guaranteed no-op.
It avoids allocating direct memory and leaving it to GC reference processing to free, so I think better than just removing the caching.
It should have no impact on usage at runtime, at least not the main stream platforms that are 64-bit and thus memory map the jimage file. On 64-bit, the built-in class loaders and other usages at runtime use slices of the mapping rather rather than allocate.
I think ARM is the only 32-bit port that is still maintained to some degree. 32-bit, and jrtfs when targeting a different run-time image, and the only cases that will use file I/O. I would expect at least some tests for javac -system should exercise this code, and we should have a few jimage tests that run with `-Djdk.image.map.all=false` to exercise this code (maybe we need more). If you want, you could increase confidence by testing with `TEST_OPTS_JAVA_OPTIONS=-Djdk.image.map.all=false`. Also since we are early in JDK 27 it means there is time for course correction in case any creepy crawlies come out of the woodwork.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29043#discussion_r2664718547
More information about the core-libs-dev
mailing list