Hi Magnus,
thanks for your detailed comments.
I generally agree with your analysis of the problem.
However, as you correctly noticed, the 'optimized' configuration is
actually a "HotSpot only" concept. It is used to enable extra
options/functionality which should not be shipped to the customer.
Everything flagged with "#ifndef PRODUCT" in HotSpot is enabled by
default in the "slowdebug" and "fastdebug" configuration - so no
problem. But the Hotspot has this extra configuration called
'optimized' which is exactly like a release build, but with the extra,
"#ifndef PRODUCT" stuff enabled. This may be useful for example for
testing/benchmarking new functionality (i.e. you don't want to
benchmark with a debug build).
There's no general 'optimized' concept for the jdk and the other
repositories as far as I can see. The "PRODUCT" macro is only used in
src/share/native/com/sun/java/util/jar/pack/* within the 'jdk/'
repository (and it is used there with a DEBUG/ASSERT semantics).
I'd therefore propose to slightly modify my change as follows:
optimized )
DEBUG_LEVEL="release"
VARIANT="OPT"
FASTDEBUG="false"
DEBUG_CLASSFILES="false"
BUILD_VARIANT_RELEASE="-optimized"
HOTSPOT_DEBUG_LEVEL="optimized"
HOTSPOT_EXPORT="optimized"
;;
Notice that 'DEBUG_LEVEL' is now reset to "release" for the
'optimized' configuration. And this is actually exactly what we want:
an optimized JDK which behaves exactly like a release version but with
the extra "NOT_PRODUCT" features of HotSpot.Thanks for catching this.
I've slightly changed the description of the 'optimized' configuration
to make it clear that it only applies to the HotSpot build. And I now
also print the exact HotSpot debug level in the configuration summary
to make it clear what we are actually building. Here's the new webrev:
http://cr.openjdk.java.net/~simonis/webrevs/8037298_2/
Altogether, I think this change will be mostly helpful to Hotspot
engineers and won't bother others too much:)
Regards,
Volker
On Fri, Mar 14, 2014 at 10:44 AM, Magnus Ihse Bursie
<magnus.ihse.bur...@oracle.com> wrote:
> 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.
