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.
