<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">On 15 Feb 2023, at 10:34, Mandy Chung wrote:</p>
</div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><p dir="auto">On Wed, 15 Feb 2023 17:32:38 GMT, David M. Lloyd <duke@openjdk.org> wrote:</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #999999; color: #999999;"><p dir="auto">The class generated for lambda proxies is now defined as a hidden class. This means that the counter, which was used to ensure a unique class name and avoid clashes, is now redundant. In addition to performing redundant work, this also impacts build reproducibility for native image generators which might already have a strategy to cope with hidden classes but cannot cope with indeterminate definition order for lambda proxy classes.</p>
<p dir="auto">This solves JDK-8292914 by making lambda proxy names always be stable without any configuration needed. This would also replace #10024.</p>
</blockquote><p dir="auto">we want the generated classes to be dumped for debugging before the hidden class is defined e.g. to troubleshoot class loading issue (see `-Djdk.internal.lambda.dumpProxyClasses=<path>` system property)</p>
<br></blockquote></div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">I agree with David that the extra counter is a problem. Further, I think it will continue to be a problem in any likely Leyden use cases, precisely because it blocks reproducibility and predictability. So, although Brian is right that there are likely to be more problems like it in the future, and we will surely want a comprehensive solution, I think removing the counter is legitimate incremental progress, not likely to be contradicted by future developments.</p>
<p dir="auto">While I’m agreeing with everybody here I’ll also agree with Mandy: We need a simple debugging story, and the global counter make it simple. But surely there are other things we could do as well, including using the global counter to name the dump file but <em>not</em> to name the class itself. That is, don’t pollute the HC classfile bytes with the counter “noise” but by all means use it to sequence debugging activities.</p>
<p dir="auto">Maybe even better, we could use the “decorated” class name assigned by the JVM, <em>after</em> the HC is loaded, to form the dump file name. One easy way to do this is rename the dump file after the JVM loads the HC and picks the decoration.</p>
<p dir="auto">(Note that the decoration is just the I-hash of the class mirror of the HC, and <em>also</em> has the good property that it does <em>not</em> pollute the classfile bytes. It’s OK that each fresh invocation of the JVM is likely to choose a different decoration, as long as we don’t try to predict it statically. This means backtraces cannot be fully predicted statically; tough luck there.)</p>
<p dir="auto">Another way to handle it is ask the JVM to do the file dumping. This might seem excessively indirect, given the simple thing we do now in the Java code, but… we probably want to be able to ask the JVM (for Leyden training runs) to report all class files loaded (especially those dynamically generated!) so we can analyze them and do good stuff with them.</p>
<p dir="auto">This implies that, whether or not we dump HC files from Java code, the <em>JVM also has to dump them</em> somewhere or other.</p>
<p dir="auto">Where this takes me is: The responsibility for dumping HC contents should be moved from Java code to the JVM.</p>
<p dir="auto">I still think removing the counter is a good step in isolation, but (as Brian says) the root issue is that we want good reporting of HC contents for more than just ad hoc debugging. So we need to think more broadly about how to preserve and report HC classfile contents, for Leyden as well as ad hoc debugging.</p>
</div></div></body>
</html>