RFR[9](XS): 8037298: Export HotSpots 'optimized' (i.e. not-product) configuration in the top-level configure/makefile

[Magnus Ihse Bursie]

On 2014-03-13 16:04, Volker Simonis wrote:
> Hi,
>
> could somebody please review this small change which exports HotSpots
> 'optimized' (i.e. not-product) configuration in the top-level
> configure/makefile:
>
> http://cr.openjdk.java.net/~simonis/webrevs/8037298/
> https://bugs.openjdk.java.net/browse/JDK-8037298
>
> The HotSpot offers a so called 'optimized' configuration which is
> actually the same as a product build, but without setting '-DPRODUCT'.
> That means that an 'optimized' HotSpot VM offers additional command
> line options and functionality which is not present in an actual
> product build.
>
> While the 'product' configuration is exported in the top-level
> configure/make system as "--with-debug-level=release" the , this was
> not the case for the 'optimized' configuration.
>
> I think I need a sponsor for this change because it requires the
> regeneration of common/autoconf/generated-configure.sh as well as of
> the closed generated configure files.

Hi Volker,

Unfortunately, this is more of a mine field than what first looks will 
tell. :(

The problem here is that the DEBUG_LEVEL variable that is set by 
--with-debug-level is used for setting *both* the Hotspot debug level 
and the JDK debug level.

In JDK, the only real difference is between "debug" and "release", so 
the existing "fastdebug" and "slowdebug" are generally considered to be 
"debug", in contrast to "release".

Maybe it was incorrect to introduce a single debug level for the whole 
product -- maybe we should have kept a separate hotspot-debug-level and 
a jdk-debug-level. In a way, that makes sense. On the other hand, it 
also makes sense to try to unify the product as a whole. So I'm a bit 
ambivalent here. But here we are now; while it is possible to change 
this now I'd rather avoid it.

If you introduce "optimized" as a new level, this will affect all the 
existing code as well that checks the DEBUG_LEVEL. So you will need to 
determine how this should be interpreted by the JDK part of the build. 
With your patch as it looks today, the effects will be a bit random. 
Most of the time, we check if debug level is release or not, where the 
"not" case (currently fastdebug and slowdebug) is bunched together and 
treated as a general debug case. Your "optimized" level would end up 
there. Probably correct, but that depends on what you want to achieve. 
In a few cases we explicitely look for slowdebug or fastdebug, and 
consider the alternative as release; there your optimized level will be 
treated as release.

It might very well be that this treatment of optimized as a mix between 
debug and release is what's needed here, but the decisions should be 
made explicitely. You should at least check the uses of DEBUG_LEVEL in 
flags.m4 and NativeCompilation.gmk.

Also, how would you feel about naming the level "optdebug" instead of 
"optimized"? I think that would make things clearer in the rest of the 
build, since then you'd have three debug levels: "[slow|fast|opt]debug" 
in contrast to "release", and anything that is not explicitely a release 
build is some kind of debug build -- not intended for shipping. It would 
make it possible to keep the abilitiy in the make files to check 
DEBUG_LEVEL to see if it contains "debug". And I believe it would make 
it more clear to future jdk make file developers to understand that this 
is some kind of debug (i.e. non-release) build.

/Magnus







I'm not convinced this is the best way to achieve what you want.

The "debug levels" in the configure system is not really the same as the 
"configurations" in hotspot. The optimized configuration in hotspot is 
really, from the configuration point of view, a release build 
(DEBUG_LEVEL=release), but at the same time, it is telling hotspot not 
to disable non-product functionality.