Some offhand questions

[Dan Heidinga]

> - Profile/Archive score: I've been thinking that maybe a profile/archive score would be something useful to have at some
> point. The goal with such a "score" would be to report back to the user how much information from the archive was
> effectively used during a production run so that they have some insight about how "good" was the training run used to
> create the archive. The score for an archive could be an [weighted] aggregate of the scores of specific parts of the archive.
> We could also use the scores, in the future, if we choose to work on something to "merge" or "combine" multiple archives.

There are two things I can think of that may be interesting to track  that shouldn’t be too expensive:
- how many of the AOTCache preloaded classes get initialized in a given production run as a proxy for how applicable the preloaded / prelinked class base is
- how many of the AOTCache aot’d methods are used in the a given run.

Did you have other thoughts on how such a score could be computed?

> - Condensers: I've been asked recently about the idea of condensers. As far as I understand there is nothing implemented
>  on the lines of that idea. Is this something that we still plan to work in the future?

The premain efforts have been our primary area of investigation given the unreasonable effectiveness of training runs.  Observing the application and optimizing based on those observations fits naturally with the rest of the Hotspot design – after all, Hotspot is named for observing programs to find the most profitable areas (“hot spots”) to compile.  There are actually a lot overlap between what can be done with the two techniques – for example, I wrote a prototype to replace the runtime LambdaMetaFactory class generation with statically generated classes but found a long tail of behaviour differences (hidden vs non-hidden classes, stack trace differences, nest members, etc).  Training runs can also pre-generate the lambda classes using the LambdaMetaFactory and doing so avoids that long tail of behaviour differences.

Condensers are an area we may come back to more in the future as there are other problems – class path scanning for one – that can be optimized statically without the behaviour difference bug tail.

--Dan

From: leyden-dev <leyden-dev-retn at openjdk.org> on behalf of Cesar Soares Lucas <Divino.Cesar at microsoft.com>
Date: Friday, August 23, 2024 at 6:09 PM
To: Leyden-dev Maillist <leyden-dev at openjdk.org>
Cc: Brian Stafford <Brian.Stafford at microsoft.com>, Mat Carter <Matthew.Carter at microsoft.com>
Subject: Some offhand questions
Hello!

I've a few questions that I'd like to ask your opinion about.

- Signed Jars: As far as I understand, we currently don't include classes from signed jars in the CDS archive. What is the reason for that? I had the impression that being able to archive such classes would be important given that many .jars are signed?!

- Profile/Archive score: I've been thinking that maybe a profile/archive score would be something useful to have at some point. The goal with such a "score" would be to report back to the user how much information from the archive was effectively used during a production run so that they have some insight about how "good" was the training run used to create the archive. The score for an archive could be an [weighted] aggregate of the scores of specific parts of the archive. We could also use the scores, in the future, if we choose to work on something to "merge" or "combine" multiple archives.

- Condensers: I've been asked recently about the idea of condensers. As far as I understand there is nothing implemented on the lines of that idea. Is this something that we still plan to work in the future?

- Recompilation: I've been reviewing the changes in the @premain branch, and I came across this piece of code [1] and was puzzled by it. Why do we recompile the code at every compilation level? There is a lot I still don't understand about the implementation in premain, but what I was expecting was that at some point in the code we would just "dump" the code cache and that would be our "AOT compiled code".


Thanks,
Cesar

[1] https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/compiler/precompiler.cpp#L234
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240826/4ab68098/attachment.htm>