RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v2]

[Kevin Walls]

On Wed, 17 Sep 2025 12:59:13 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> We should clarify:
>> These fields are not a public interface, but the JVM has to maintain them due to other software's expectations?
>> 
>> Async-Profiler is great, but is this change the right solution? Are there other fields which other software would have liked to stay around, and what else can not be removed?
>> 
>> Curious how did Async-Profiler break when these are removed?  Is it a crash that Async-Profiler needs to workaround, or is there less information in the collected profile.
>
> @kevinjwalls Right, VMStructs is not a public supported interface, the JVM is not obliged to maintain it. Yet, some external tools (async-profiler and eBPF based profilers) softly rely on that in the lack of standard supported alternatives. At the same time, we are improving OpenJDK built-in capabilities that can eventually serve as such an alternative. A recent example is JEP 509: JFR CPU-Time Profiling. It's still a long path until JFR or other built-in tools can satisfy today's demand; in the meantime, VMStructs provides a temporary solution.
> 
> VMStructs is a reasonable trade-off, very cheap from the maintenance perspective as opposed to AsyncGetCallTrace (async-profiler no longer depends on the latter). To emphasize, we do not expect others to maintain VM structures that async-profiler relies on, that is our (profiler + Corretto) responsibility. Infrequent changes will be small, localized and safe, like in this PR.
> 
> As for the question how async-profiler breaks: if it is an optional feature (like here), it gracefully reduces functionality. Async-profiler attempts to detect essential VM changes and fail fast to prevent from crashing at runtime.

Thanks @apangin  Andrei 

I thought we should be open and explicit about this, good to have that exchange in the review.  Async-Profiler knew what it was getting into. 8-)


In the comment being added above, what is it appropriate to say...

Saying "should not removed... they can be used by external tools" as an instruction seems like an overreach. Maybe more like:

"These CI fields are retained in VMStructs for the benefit of external tools, to ease their migration to a future alternative."

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27318#issuecomment-3303157325