Call for Discussion: New Project: Skogsluft

[David Alayachew]

This is desperately needed!

I am struggling with a performance problem related to
java.io.File.getCanonicalPath/getCanonicalFile(). Long story short, the
call is offensively slow on my computer, but it seems that the problem
exists in the native call to Windows. Visual VM and JFR immediately jumped
me to offending method call above, but they could only point me to the Java
code. Once it became clear that the issue was in the native method, neither
of these tools was any help.

My current solution is to go marching up and down the source code on github
to look through C++ Windows implementation of the Java method, and see if I
can find the problem. It has been 4 weeks and counting. I am no C++
programmer, so I don't know what to look for, and it ends up requiring me
to march down every path. And that's ignoring the fact that I have no good
way to measure each method call to see which one is slow.

I will continue down this long path, and I intend to solve this problem,
even if I must do it the long way, but this project would have saved me the
weeks of time I spent thus far, and weeks I plan to continue to spend on
this problem. I very much hope that this comes to fruition!

On Fri, Feb 2, 2024 at 12:15 PM Jaroslav Bachorík <
jaroslav.bachorik at datadoghq.com> wrote:

> I hereby invite discussion of a new Project, "Skogsluft," whose primary
> goal will be to improve Java's profiling capabilities within Java Flight
> Recorder (JFR). This project aims to introduce advanced profiling features
> that bridge the gap between Java and native code execution, and offer more
> precise and flexible profiling options.
>
> The focus will be on three key enhancements:
>
> 1. An improved stackwalker, capable of seamlessly walking mixed
> Java/native stacks. This will provide developers with a more coherent view
> of the stack traces, especially in applications where Java and native codes
> are interwoven.
>
> 2. A flexible CPU sampler scheduler. On Linux, this will be based on
> perf_event_open or timer_create systems, and on MacOS, we will utilize
> itimer. For other operating systems, the system will fall back to standard
> execution samples. This enhancement aims to offer more accurate and
> adaptable CPU sampling, taking into account the diverse environments in
> which Java applications run.
>
> 3. Labelling support for JFR. This will allow developers to set per-thread
> key-value labels that are automatically incorporated into any JFR event.
> Such labelling will provide richer context in profiling data, enabling more
> targeted analysis and debugging.
>
> To implement these enhancements, the "Skogsluft" will extend Java's
> profiling capabilities in JFR with the following approaches:
>
> Development of a cross-platform stackwalker that integrates native and
> Java stack frames, ensuring compatibility and efficiency across different
> operating systems.
>
> Design and integration of a scheduler for CPU sampling that adapts to the
> underlying operating system's capabilities, offering both precision and
> performance.
>
> Extension of the JFR API to support easy and flexible labelling of
> threads, ensuring that these labels are consistently captured in profiling
> data.
>
> I am looking for an OpenJDK group willing to sponsor this project and
> provide a person to lead this project.
>
> For the "Skogsluft" this Project will start with a clone of the current
> JDK main-line release, JDK 23, and track main-line releases going forward.
> The project will involve creating a separate repository for the development
> of these new profiling features, ensuring they are compatible and
> well-integrated with existing JFR functionalities.
>
> The "Skogsluft" is expected to deliver the features over time, in a series
> of JEPs (JDK Enhancement Proposals) that will likely span multiple feature
> releases. The aim is to eventually integrate these profiling improvements
> into the standard JDK distributions, enhancing the capabilities of JFR and
> providing developers with more powerful tools for performance analysis and
> debugging.
>
> With regards,
>
> Jaroslav Bachorik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/discuss/attachments/20240209/f4c06fd6/attachment.htm>