<div dir="ltr"><div class="gmail_default" style="font-family:monospace">This is desperately needed!</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">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.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">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.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">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!<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 2, 2024 at 12:15 PM Jaroslav Bachorík <<a href="mailto:jaroslav.bachorik@datadoghq.com">jaroslav.bachorik@datadoghq.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<br><br>The focus will be on three key enhancements:<br><br>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.<br><br>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.<br><br>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.<br><br>To implement these enhancements, the "Skogsluft" will extend Java's profiling capabilities in JFR with the following approaches:<br><br>Development of a cross-platform stackwalker that integrates native and Java stack frames, ensuring compatibility and efficiency across different operating systems.<br><br>Design and integration of a scheduler for CPU sampling that adapts to the underlying operating system's capabilities, offering both precision and performance.<br><br>Extension of the JFR API to support easy and flexible labelling of threads, ensuring that these labels are consistently captured in profiling data.<br><br>I am looking for an OpenJDK group willing to sponsor this project and provide a person to lead this project.<br><br>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.<br><br>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.<br><br>With regards,<div><br></div><div>Jaroslav Bachorik</div></div>
</blockquote></div>