<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div dir="ltr" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Great question!</div>
<div dir="ltr" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="ltr" style="font-family: Aptos, Arial, Helvetica, sans-serif; color: rgb(0, 0, 0);">
<span style="font-size: 12pt;">> </span><span style="font-size: 16px; background-color: rgb(255, 255, 255);">if we need to think ahead to having to treat AOT archives more carefully than the runtime </span></div>
<div dir="ltr" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 16px; color: rgb(0, 0, 0);">
<span style="background-color: rgb(255, 255, 255);">> classpath as features that cache compiled code begin to land?</span></div>
<div dir="ltr" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 16px; color: rgb(0, 0, 0);">
<span style="background-color: rgb(255, 255, 255);"><br>
</span></div>
<div dir="ltr"><span style="background-color: rgb(255, 255, 255);">Even without compiled code, the cache needs to be treated with the same care as jars on the classpath and the JDK executables / shared libraries. This is nothing new, just standard care for
deployment artifacts.</span></div>
<div dir="ltr"><span style="background-color: rgb(255, 255, 255);"><br>
</span></div>
<div dir="ltr" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 16px; color: rgb(0, 0, 0);">
<span style="background-color: rgb(255, 255, 255);">> Our job is made so much easier if we only need to be concerned about the provenance of</span></div>
<div dir="ltr" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 16px; color: rgb(0, 0, 0);">
<span style="background-color: rgb(255, 255, 255);">> an AOT archive, but when a colleague asked me about runtime decrypted secrets finding</span></div>
<div dir="ltr" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 16px; color: rgb(0, 0, 0);">
<span style="background-color: rgb(255, 255, 255);">> their way into static fields for example, I realised I didn't have an complete understanding</span></div>
<div dir="ltr" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 16px; color: rgb(0, 0, 0);">
<span style="background-color: rgb(255, 255, 255);">> of how far the caching of compiled code might go.</span></div>
<div dir="ltr" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 16px; color: rgb(0, 0, 0);">
<span style="background-color: rgb(255, 255, 255);"><br>
</span></div>
<div dir="ltr"><span style="background-color: rgb(255, 255, 255);">Cached AOT code doesn’t constant fold statics today so it can’t accidentally encode them into compiled code. A very limited set of classes are initialized in the assembly phase - which is a
requirement to have persisted objects - which further limits the possibility of secrets being accidentally recorded in the cache. </span></div>
<div dir="ltr"><span style="background-color: rgb(255, 255, 255);"><br>
</span></div>
<div dir="ltr"><span style="background-color: rgb(255, 255, 255);">During my JVMLS talk this year [0], I touched on the challenges of persisting objects and dealing with identity. Security is another aspect that makes heap snapshots difficult to deal with.</span></div>
<div dir="ltr"><span style="background-color: rgb(255, 255, 255);"><br>
</span></div>
<div dir="ltr"><span style="background-color: rgb(255, 255, 255);">—</span><span style="font-size: 16px; background-color: rgb(255, 255, 255);">Dan</span></div>
<div dir="ltr"><span style="background-color: rgb(255, 255, 255);"><br>
</span></div>
<div dir="ltr"><span style="background-color: rgb(255, 255, 255);">[0] </span><span style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><a href="https://inside.java/2025/10/21/jvmls-assembling-project-leyden/#:~:text=Dan%20Heidinga%20on%20October%2021,Shopping" data-outlook-id="08cab4c2-358b-4f70-a463-2ec07569fa0b">https://inside.java/2025/10/21/jvmls-assembling-project-leyden/#:~:text=Dan%20Heidinga%20on%20October%2021,Shopping</a></span><span style="background-color: rgb(255, 255, 255);"> </span></div>
<div dir="ltr" style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="mail-editor-reference-message-container">
<div dir="ltr" class="ms-outlook-mobile-reference-message skipProofing"></div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="text-align: left; padding: 3pt 0in 0in; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) currentcolor currentcolor; font-family: Aptos; font-size: 12pt; color: black;">
<b><br>
<p style="font-family:Calibri;font-size:10pt;color:#000000;margin:5pt;font-style:normal;font-weight:normal;text-decoration:none;" align="Left">
Confidential – Oracle Internal<br>
</p>
From: </b>leyden-dev <leyden-dev-retn@openjdk.org> on behalf of Danny Thomas <dannyt@netflix.com><br>
<b>Date: </b>Sunday, November 2, 2025 at 11:10 PM<br>
<b>To: </b>leyden-dev@openjdk.org <leyden-dev@openjdk.org><br>
<b>Subject: </b>Potential for sensitive runtime information to land in AOT archives<br>
<br>
</div>
<div dir="ltr" class="ms-outlook-mobile-reference-message skipProofing">Hi folks,</div>
<div dir="ltr" class="ms-outlook-mobile-reference-message skipProofing"><br>
</div>
<div dir="ltr" class="ms-outlook-mobile-reference-message skipProofing">We're thinking ahead to caching compiled code and other optimisations that might include runtime information that wouldn't otherwise be available if you had access to the application classpath.
I caught Dan's JavaOne talk recently, and it sounds like the assembly phase is intended to be hermetic and avoid exactly this kind of complication, but wanted to ask explicitly if we need to think ahead to having to treat AOT archives more carefully than the
runtime classpath as features that cache compiled code begin to land?<br>
<br>
Our job is made so much easier if we only need to be concerned about the provenance of an AOT archive, but when a colleague asked me about runtime decrypted secrets finding their way into static fields for example, I realised I didn't have an complete understanding
of how far the caching of compiled code might go.</div>
<div dir="ltr" class="ms-outlook-mobile-reference-message skipProofing"><br>
Cheers,<br>
Danny</div>
</div>
</body>
</html>