RFR: 8292914: Drop the counter from lambda class names
John Rose
john.r.rose at oracle.com
Wed Feb 22 22:55:17 UTC 2023
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>
More information about the core-libs-dev
mailing list