Enable Compact Object Headers (JEP 519)

[mbien]

• sets -XX:+UseCompactObjectHeaders for JEP 519 which is supported from JDK 25 and later
• NB sets -XX:+IgnoreUnrecognizedVMOptions already which means it will be silently ignored on older JDKs
• (experimental on EOL JDK 24, but it won't enable there without also setting the flag to enable experimental options - which we don't do)

sidenote: I think corretto backported the feature to JDK 17 and 21 too, but all vendors should ship it on 25 and later

tested it on NB since JDK 24 without issues

[neilcsmith-net]

I'm inclined against doing this, particularly with options that cannot be overridden later on the CLI. The less JDK options we have in the configuration file the better. For anyone using an installer package (which is probably the majority of our user base), the .conf file should be treated as uneditable. It's possible for the user to copy and edit netbeans.conf in the userdir, and providing an option to apply / edit options there might be better. A note of useful options, like this one, to improve performance might be good, as well as how to add them. Perhaps on the download page?

[mbien]

i think this could be overridden by passing the same option with - again? (-J-XX:-UseCompactObjectHeaders )

edit: unless you want to tinker with JVM settings (experimenting with more niche features, swapping GC out etc) - why would someone want to override JVM options of the IDE? I think that the vast majority will use the defaults. I do also agree that "less is better" regarding flags - I did also remove some in the past. However, I would put this in the same category as string deduplication which seems to apply well for the IDE setting. (although I actually never tried to run NB without string deduplication, maybe that wisdom is outdated by now)

[mbien]

$ jdk-26/bin/java -XX:+UseCompactObjectHeaders -XX:+UseCompactObjectHeaders -XX:+PrintFlagsFinal -version | grep "command line"
     bool PrintFlagsFinal                          = true                                      {product} {command line}
     bool UseCompactObjectHeaders                  = true                           {product lp64_product} {command line}

$ jdk-26/bin/java -XX:+UseCompactObjectHeaders -XX:-UseCompactObjectHeaders -XX:+PrintFlagsFinal -version | grep "command line"
     bool PrintFlagsFinal                          = true                                      {product} {command line}
     bool UseCompactObjectHeaders                  = false                          {product lp64_product} {command line}

edti: let me try with NB. downloading the dev build

[neilcsmith-net]

I tried to find some documentation on whether using - worked or not. I didn't try it, though. If that's working, I have slightly less concern here.

why would someone want to override JVM options of the IDE? I think that the vast majority will use the defaults.

100%. Although that could also be an argument for JVM defaults. If there are new options that we think might provide benefit to the IDE, then suggesting people try them is a way to get feedback from the minority who do like to tinker.

[mbien]

devbuild testrun.sh:

netbeans/bin/netbeans --userdir /tmp/nb24282437907 --jdkhome /home/mbien/dev/java/jdk-26.0.0.35.2-corretto -J-Dnetbeans.projects.dir=/tmp\
 -J-XX:+PrintFlagsFinal

$ sh testrun.sh | grep "command line"
     bool HeapDumpOnOutOfMemoryError               = true                                   {manageable} {command line}
    ccstr HeapDumpPath                             = /tmp/nb24282437907/var/log/heapdump.hprof         {manageable} {command line}
     bool IgnoreUnrecognizedVMOptions              = true                                      {product} {command line}
     bool PrintFlagsFinal                          = true                                      {product} {command line}
     intx ThreadStackSize                          = 2048                                   {pd product} {command line}
     bool UseCompactObjectHeaders                  = true                           {product lp64_product} {command line}
     bool UseStringDeduplication                   = true                                      {product} {command line}

now with:

netbeans/bin/netbeans --userdir /tmp/nb24282437907 --jdkhome /home/mbien/dev/java/jdk-26.0.0.35.2-corretto -J-Dnetbeans.projects.dir=/tmp\
 -J-XX:+PrintFlagsFinal -J-XX:-UseCompactObjectHeaders

$ sh testrun.sh | grep "command line"
     bool HeapDumpOnOutOfMemoryError               = true                                   {manageable} {command line}
    ccstr HeapDumpPath                             = /tmp/nb24282437907/var/log/heapdump.hprof         {manageable} {command line}
     bool IgnoreUnrecognizedVMOptions              = true                                      {product} {command line}
     bool PrintFlagsFinal                          = true                                      {product} {command line}
     intx ThreadStackSize                          = 2048                                   {pd product} {command line}
     bool UseCompactObjectHeaders                  = false                          {product lp64_product} {command line}
     bool UseStringDeduplication                   = true                                      {product} {command line}

[mbien]

why would someone want to override JVM options of the IDE? I think that the vast majority will use the defaults.

100%. Although that could also be an argument for JVM defaults.

well yes it is. But we also want to provide the best defaults if there is this option. E.g I remember NB being an early adopter of G1 GC back when it started to be the better option to CMS.

The compact headers flag safes 5-15% of memory footprint in my experience measuring other applications (in extreme cases more). This is difficult to reliably measure for NB since it has a lot going on there. But I use it since NB 25 (when it was experimental on JDK 24) without problems. I thought @lkishalmi was also using it.

[lkishalmi]

Running Compact Object Headers from Java 24. It works well so far.

Also using this setting in a Micronaut microservice in production with Java 25, if that counts...

[lkishalmi]

I regard this similar to the -XX:+UseStringDeduplication.