Windows profiling [was: Re: Call for Discussion: New Project: Skogsluft]

[David Alayachew]

Thank you for the help Daniel!

And if this is something that JFR simply won't be able to do, then that is
fine. I am merely pointing out that this is a much desired feature or
project. And more specifically, that there is a very important use case for
it.

On Mon, Feb 12, 2024 at 4:45 AM Daniel Jeliński <djelinski1 at gmail.com>
wrote:

> Hi David,
> If you build your own JDK (that is, you have the pdb files available),
> Windows Performance Toolkit will profile your native code. As far as I
> could tell, Windows does not provide any good way for an application
> to profile itself, so it may be impossible to produce equivalent
> quality profiling in JFR.
>
> See here for a great UI and a good intro to ETW:
>
> https://randomascii.wordpress.com/2015/04/14/uiforetw-windows-performance-made-easier/
>
> Regards,
> Daniel
>
>
>
>
> pt., 9 lut 2024 o 19:18 David Alayachew <davidalayachew at gmail.com>
> napisał(a):
> >
> > 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/20240212/1c523593/attachment-0001.htm>