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

[Daniel Jeliński]

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