der of items returned from this iterator in the first place, but it turns out that many applica-
tions made that mistake. For compatibility reasons, then, the more efficient implementation
did not override the original implementation, and it is necessary to set the AggressiveOpts
flag to get the better implementation.
Since Java 8 removes these classes, the bug compatibility they preserve may break when up-
grading—which is an indication to write better code in the first place.
Enabling the AggressiveOpts flag affects some other minor tunings of the JVM.
Setting the AggressiveOpts flag enables the AutoFill flag, which by default is false in
JDK 7 though 7u4, when the default is set to true . That flag enables some better loop optim-
izations by the compiler. Similarly, this flag also enables the DoEscapeAnalysis flag (that is
also set by default in JDK 7u4 and later versions).
The AutoBoxCacheMax flag (default 128) is set to 20,000—that enables more values to be
autoboxed, which can slightly improve performance for certain applications (at the expense
of using slightly more memory). The value of the BiasedLockingStartupDelay is reduced
from its default of 2,000 to 500, meaning that biased locking will start sooner after the ap-
plication begins execution.
Finally, this flag enables the OptimizeStringConcat flag, which allows the JVM to optim-
ize the use of StringBuilder objects—in particular, the StringBuilder objects that are
created (by the javac compiler) when writing code like this:
String s = obj1 + ":" + obj2 + ":" + obj3 ;
The javac compiler translates that code into a series of append() calls on a string builder.
When the OptimizeStringConcat flag is enabled, the JVM just-in-time compiler can op-
timize away the creation of the StringBuilder object itself. The OptimizeStringConcat
flag is false by default in JDK 7 until 7u4, when the default becomes true .