fastdebug vs jvmg

[Daniel D. Daugherty]

One clarification:

 > (especially as jvmg was dropped for a while and only came back
 > when it was thought we might extend hotspot-express to JDK 5!)

The "jvmg" build config was never dropped. Some of the platforms
in the internal JPRT system still build three configs: product,
fastdebug and jvmg. Just to make things confusing: the "jvmg" config
is called the "debug" config on Windows. I really, really hope that
the new build-infra system will fix that naming anomaly.

What was dropped was the generation and use of binaries with the
"_g" suffix, e.g., java_g, libjvm_g.so, etc. HotSpot did bring that
back for a while in a limited form and it is about to go away again:

     7153050 remove crufty '_g' support from HotSpot repo

Ron Durbin is putting the finishes touches on his fix for 7153050.

One reminder:

When Full Debug Symbols (FDS) is enabled, product and fastdebug
builds use the same debug and optimization flags. So the big
difference between product and fastdebug is now just the asserts
and any NOT_PRODUCT code.

Dan



On 12/5/12 9:57 PM, David Holmes wrote:
> First note that Jesper's email is from Oct 31 and only just turned up! 
> Either that or he has a clock issue on his system :)
>
> On 6/12/2012 8:25 AM, Kelly O'Hair wrote:
>> On Oct 31, 2012, at 5:26 AM, Jesper Wilhelmsson wrote:
>>> Then I reconfigured with --enable-debug.
>>>
>>> --enable-debug currently configures hotspot to build with the build 
>>> target fastdebug. fastdebug isn't really fast since asserts are 
>>> turned on, and it can't be used for debugging since the code is 
>>> optimized, so the name is a bit misleading. Personally I always use 
>>> jvmg when debugging and testing.
>>
>> But the debug build has asserts on too, doesn't it? It should.
>>
>>>
>>> I asked around the Stockholm office and it seems as most people here 
>>> would prefer jvmg. It seems as jvmg is very slow on Mac so those who 
>>> work on Mac only uses jvmg when debugging for real, not for regular 
>>> testing, but otherwise fastdebug is rarely used here.
>>
>> A long time ago, in a land far far away, fastdebug was pretty good on 
>> Solaris, using dbx, worked really well, not perfect but pretty good.
>> Since then, Linux was added, and gdb is needed, and Mac too, so we 
>> have many native code debuggers to deal with now.
>> Also since then, machines have gotten faster, and disks are fatter 
>> and faster, and maybe fastdebug has lost it's benefit.
>> Testing the debug build is pretty impossible, or was, it just was way 
>> too slow, maybe 100x slower than a product build.
>> But fastdebug was possible, maybe 10x slower than a product build.
>> So I have always assumed that fastdebug was faster than a debug build.
>> But who knows what the performance is now. I think I was always 
>> looking at an entire JDK built with product vs. debug vs. fastdebug
>> not just hotspot, although hotspot was usually the piece that cause 
>> performance issues.
>
> I admit we probably haven't run a comparison against fastdebug and 
> jvmg recently (especially as jvmg was dropped for a while and only 
> came back when it was thought we might extend hotspot-express to JDK 
> 5!) but I think the hotspot team will be shocked to discover that 
> fastdebug is slower than jvmg. fastdebug is supposed to be faster than 
> debug because it still uses the OPT_CFLAGS, not DEBUG_CFLAGS, while 
> also allowing a certain level of debugging (and having asserts enabled 
> as does jvmg).
>
> David
> -----
>
>> If all this has changed, then we should re-consider what we build and 
>> test.
>>
>> I think it was always agreed that the asserts were invaluable, so we 
>> need to keep that on in some build.
>>
>> -kto
>>
>>>
>>> Cheers,
>>> /Jesper
>>>
>>