Java VM tuning - Xbatch and -Xcomp

11,033

Generally speaking, it's always preferable to let HotSpot compiler tune itself. Even using Server VM (-server) is default for 64bits and some 'server-class' machines.

-Xbatch was intended mostly for debugging as described in Steve Goldman's blog you pointed:

So the -Xbatch switch is not a particularly useful switch even in the pre-mustang days. It is somewhat useful for jvm developers since it tends to make a run more predictable and reproducible.

-Xcomp removes the ability to gather information for efficient compilation. From an Alex Turner's post:

One might think that -Xcomp would be a good idea from a performance point of view. However, it is not! The JIT compiler uses those 1000 iterations before compilation to gather information on how the method should be compiled for optimal efficiency. -Xcomp removes its ability to do so and thus we can actually see performance slip.

Without performance in mind, I've never seen using those flags to detect missing dependencies (and it may not work if some code is still interpreted) so IMHO, I would get rid of both.

Share:
11,033
adrian
Author by

adrian

Updated on June 03, 2022

Comments

  • adrian
    adrian almost 2 years

    I am looking at the JVM configuration options for running Alfresco, mainly this document on the Alfresco Wiki. One of the recommendations is to use the JVM flags -Xcomp and -Xbatch. The justification of this is:

    If you wish to have Hotspot precompile the classes, you can add [-Xcomp and -Xbatch]. This will, however, significantly increase the server startup time, but will highlight missing dependencies that can be hit later.

    From what I have read elsewhere about the -Xcomp and -Xbatch flags, I am wondering whether they really provide any benefit.

    • -Xcomp gets HotSpot to compile all code beforehand with maximum optimization, thus foregoing any profiling that the VM will get through the standard running of the system.
    • -Xbatch stops background compiling, meaning the thread which caused the code to be compiled blocks until the compile is complete. However, after the compile is finished, the previously-blocked thread will not run the compiled code, it will still run the interpreted code. This was a change in Java 6 (Mustang) – before Mustang, threads blocked for compiling by the presence of the -Xbatch flag were guaranteed to run in the compiled code as soon as the compile was completed. Therefore, I am guessing that the recommendation of the -Xbatch flag is a relic of running Alfresco on older VMs.

    Does anyone have any thoughts? My inclination is to get rid of these two flags and rely on the VM to get things right.

    I would like to add two things, first of all that I don't yet have access to an Alfresco instance to test this on and secondly I don't really know what spec of machine is hosting Alfresco other than that by looking at the other configuration options it must be a 64 bit VM. Despite this, I hope the community will have some useful input, perhaps from a general HotSpot-tuning point of view.