JDK-8246020 : -XX:+UsePerfData is enabled by default and slows down VM bootstrap by 6%
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 15
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2020-05-27
  • Updated: 2025-02-14
  • Resolved: 2025-02-14
Related Reports
Relates :  
JDK-8134615 - Some MXBeans rely on UsePerfData being enabled
Relates :  
JDK-8241678 - Remove PerfData sampling via StatSampler
Relates :  
JDK-8348402 - PerfDataManager stalls shutdown for 1ms
Relates :  
JDK-8255231 - Avoid upcalls when initializing the statSampler
Relates :  
JDK-8076103 - Writing to the mmaped PerfData file hsperfdata can cause long stalls on Linux
Relates :  
JDK-8246019 - PerfClassTraceTime slows down VM start-up
Description
UsePerfData is enabled by default by hotspot, even though the collected performance data is rarely used. 

Maybe we should disable the data collection by default??

0.038613 - 0.036185 = 2.43 ms
1.0 - (0.036185 / 0.038613) = 6.29%

===========

Performance counter stats for 'bin/java -XX:+UsePerfData -version' (100 runs):

             52.95 msec task-clock                #    1.371 CPUs utilized            ( +-  0.62% )
               205      context-switches          #    0.004 M/sec                    ( +-  0.99% )
                12      cpu-migrations            #    0.232 K/sec                    ( +-  1.91% )
             2,690      page-faults               #    0.051 M/sec                    ( +-  0.05% )
       128,363,276      cycles                    #    2.424 GHz                      ( +-  0.16% )
        80,560,141      stalled-cycles-frontend   #   62.76% frontend cycles idle     ( +-  0.22% )
        63,528,144      stalled-cycles-backend    #   49.49% backend cycles idle      ( +-  0.26% )
        95,515,717      instructions              #    0.74  insn per cycle         
                                                  #    0.84  stalled cycles per insn  ( +-  0.12% )
        18,532,475      branches                  #  350.026 M/sec                    ( +-  0.13% )
           968,290      branch-misses             #    5.22% of all branches          ( +-  0.15% )

          0.038613 +- 0.000335 seconds time elapsed  ( +-  0.87% )


 Performance counter stats for 'bin/java -XX:-UsePerfData -version' (100 runs):

             51.93 msec task-clock                #    1.435 CPUs utilized            ( +-  0.46% )
               204      context-switches          #    0.004 M/sec                    ( +-  0.96% )
                13      cpu-migrations            #    0.247 K/sec                    ( +-  1.99% )
             2,678      page-faults               #    0.052 M/sec                    ( +-  0.04% )
       126,073,436      cycles                    #    2.428 GHz                      ( +-  0.14% )
        79,016,450      stalled-cycles-frontend   #   62.67% frontend cycles idle     ( +-  0.18% )
        62,262,828      stalled-cycles-backend    #   49.39% backend cycles idle      ( +-  0.22% )
        93,900,452      instructions              #    0.74  insn per cycle         
                                                  #    0.84  stalled cycles per insn  ( +-  0.13% )
        18,227,636      branches                  #  350.991 M/sec                    ( +-  0.13% )
           956,777      branch-misses             #    5.25% of all branches          ( +-  0.15% )

          0.036185 +- 0.000221 seconds time elapsed  ( +-  0.61% )
Comments
I'm closing as WNF. It would be nice to have this off by default and interested parties turn it on explicitly but digging through the issues will take some time and this hasn't been a priority for us to fix for a long time, and likely won't be. If someone wants to reopen and work through the issues, feel free to reopen this.
14-02-2025
As a data point: a lot of our services run with -XX:-UsePerfData. I believe big projects like Hadoop disable it in their launch scripts. There are still costs in creating counters/data and shutting the whole thing down. To be clear, I am not objecting to closing this as WNF, just saying if any interested party wants to re-open in the future and work through all the kinks to get us to what I would consider a good final state (UsePerfData disabled by default), I would not mind that either. But also brace yourselves, because I suspect the list of issues Coleen has above would only grow as we (re)start digging... Today it indeed looks way too much hassle for the amount of gain we'll get after fixing spot issues with UsePerfData.
05-02-2025
I started investigating this issue because it's been on our list for a long time and to see if it was a good idea to turn off UsePerfData by default and just always create the hsperfdata_username file unconditionally, so that the attaching jcmds work. With some research, it looks like some of these perf counters are being used and explaining the UsePerfData flag switch might be difficult to explain and may surprise users like the ones in JDK-8134615. The ones remaining don't seem to hurt performance noticeably. I think we should take the approach to deprecate/remove ones that aren't being used like you did in JDK-8348833 and leave UsePerfData on by default. Also https://bugs.openjdk.org/browse/JDK-8069149?focusedId=14184762&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14184762 Which it seems we can't do. I'm going to close this as WNF.
05-02-2025
I think a significant part of -XX:+UsePerfData impact on short end-to-end tests got eliminated with JDK-8348402.
05-02-2025
I did the measurement with /tmp on ext4, which may be related to the slow down. See JDK-8076103
05-01-2023
From memory there are some issues around initialization, and IIRC there is Java code that hooks into the perf counters which seems ignorant of the fact -UsePerfData may have disabled them. Update: I found the initialization bug I was thinking of - JDK-8163437 - but it wasn't quite what I recalled and most of the issues were subsequently addressed in JDK-8151815. Update 2: These are the Java side bugs I was thinking of: JDK-8069149, JDK-8134615
05-01-2023
Part of the slow down has been addressed by JDK-8255231 (Avoid upcalls when initializing the statSampler)
05-01-2023
[~dholmes] could you elaborate what that bug is?
05-01-2023
There's a bug somewhere( which I can't locate) about the fact that a lot of the perf code is unaware of the potential for -UsePerfData. We had to fix a number of these for SE Embedded.
04-01-2023
I think it's OK to keep -XX:+UsePerfData as the default for now. However, today if you truly don't want to use UsePerfData, it's problematic to specify -XX:-UsePerfData. If you do so, the JVM will no longer create the /tmp/hsperfdata_$USER/$PID file. As a result, when using "jcmd", you cannot use the program's name (its main class). You must use its numerical PID. It's really unfortunately for jcmd to be tied to -XX:+UsePerfData in this way. Perhaps in the short term, we can have a new flag like -XX:-CollectPerfData so we will still generate the /tmp/hsperfdata_$USER/$PID but otherwise don't actually collect the perfdata. This will be useful for apps who really want to squeeze out every bit of start-up time. In the long run, we should do a survey and revisit the default value for UsePerfData. I believe UsePerfData was initially defaulted to false, and in JDK 1.4 (?) the default value is changed to true, because people believe it has such low overhead that nobody will care. However, we have optimized the VM a lot since then, so an insignificant overhead in the past has now started to bother us.
18-06-2020
I don't think IDE's are at all relevant to UsePerfData, or how the underlying monitoring data is used in the field.
18-06-2020
The usage of UsePerfData is common for cloud services. It's been used for years for monitoring and collecting performance data. Fast deployment is one side, monitoring is another side that's equally or even more (in some cases) important. Please see more comments above for issues called out for disabling UsePerfData by default.
17-06-2020
Most of applications do not use this feature to collect performance data. With cloud services, fast deployment is important since today serverless services are more popular. Optimizing particular code related to UsePerfData will introduce more code and complexity. We should investigate how it will affect the existing tests. I think most of IDEs have their own performance tools not using this flag.
17-06-2020
Just to be clear while this is in hotspot code we do not solely own the PerfCounters. This is an API that exists for collecting perf data on running VMs. Forcing everyone to now turn this on could be a significant impediment to application deployers. Any such change would need a CSR request and a detailed explanation of the compatibility ramifications of doing this.
27-05-2020
Following are some considerations/input for not disabling it by default: Hsperfdata is used commonly to collect performance data. That's the case for cloud usages as well. Disabling it by default would not help runtime performance in practices. Developers would need to explicitly enable it with an extra command-line option, or have to modify the downstream VM. Disabling it by default may also introduce risks as the test coverage might become smaller. Looking into improvement for UsePerfData related code instead may be a good idea.
27-05-2020