RFR: 8292914: Drop the counter from lambda class names

[John Rose]

On 15 Feb 2023, at 10:34, Mandy Chung wrote:

> On Wed, 15 Feb 2023 17:32:38 GMT, David M. Lloyd <duke at openjdk.org> 
> wrote:
>
>> 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.
>>
>> This solves JDK-8292914 by making lambda proxy names always be stable 
>> without any configuration needed. This would also replace #10024.
>
> 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)
>

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.

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 *not* 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.

Maybe even better, we could use the “decorated” class name assigned 
by the JVM, *after* 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.

(Note that the decoration is just the I-hash of the class mirror of the 
HC, and *also* has the good property that it does *not* 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.)

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.

This implies that, whether or not we dump HC files from Java code, the 
*JVM also has to dump them* somewhere or other.

Where this takes me is:  The responsibility for dumping HC contents 
should be moved from Java code to the JVM.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230222/0d306d2f/attachment-0001.htm>