RFR(M) : 7104565 : trim jprt build targets

Coleen Phillimore coleen.phillimore at oracle.com
Wed Apr 10 08:50:50 PDT 2013


This change is really good.  Thank you for picking it up.  I have a few 
comments:

I think people still use "profiled", or at least Vlad asked me about it 
yesterday.   Were the rules already gone?  I'm not particularly attached 
to it but our other means of profiling the VM might not be available on 
all platforms.   I think people should chime up if they want it.

make/linux/makefiles/defs.make - just a comment.   There should be a 
make/xnix directory for these duplicated files.  They are the same for 
bsd/linux and solaris, aren't they?

I don't understand the concern with generateJVMOffsets.cpp performance.  
I think this is a tool for dtrace or ptrace.  For the 
os/bsd/dtrace/generateJvmOffsets.cpp can you fix bellow on line 70 like 
you did on solaris.

I was somewhat surprised with how few #ifdef DEBUG conditionals there 
are.  But there is still DEBUG_ONLY macros.  I think you said in another 
mail that these eventually should change to ASSERT_ONLY() but 
DEBUG_ONLY() seems fine for now.   So this isn't as confusing as not 
knowing whether to use #ifdef DEBUG vs. ifdef ASSERT.

I didn't see anything in this change that would make fastdebug run 
significantly slower since we use it for testing, but this was the 
original purpose of #ifdef DEBUG.   Fastdebug is neither fast nor 
debuggable, but is a lot faster than jvmg (oops I mean debug) because at 
least functions are inlined on all platforms.   So fastdebug is still 
valuable for running tests, 'debug' is still valuable for debugging and 
product is what we ship so I don't see any going away.   btw. optimized 
even though it bit rots is still useful too.  I wish JPRT builds would 
include an optimized build.

Thanks for doing this pile-o-fun!
Coleen

On 4/10/2013 11:09 AM, David Chase wrote:
> On 2013-04-10, at 9:20 AM, Karen Kinnear <karen.kinnear at oracle.com> wrote:
>
>> David,
>>
>> I did not read the webrev - I just wanted to make sure I understood the goals:
>>
>> Are you leaving product alone.
> Leaving product alone.
>
>> Leaving fastdebug alone, removing debug, and renaming jvmg
>> to debug - which will continue to have debug and assert and all the symbols jvmg used to have?
> Debug and Fastdebug should be compiled from the same source and flags (ASSERT defined for both), and debug should be the same as what we now call jvmg, but fastdebug will compiled with optimization on.
> Fastdebug is (not-)modified in the sense that it no longer defines FASTDEBUG, but all the occurrences of "defined(FASTDEBUG)" or defined(DEBUG)" have been replaced with "defined(ASSERT)".
>
>> And when we do a debug build from jdk level, what will that build?
> New build currently attempts to build a jvmg, and goes through these rules to build "debug" instead:
>
> --------
> # Compatibility for transition to new naming
> warn_jvmg_deprecated:
> 	echo "Warning: The jvmg target has been replaced with debug"
> 	echo "Warning: Please update your usage"
>
> jvmg: warn_jvmg_deprecated debug
> --------
>
> Next turn of the RFE crank is to replace those other uses of "jvmg" with "debug" and eventually retire those deprecated rules.
>
> A second goal is to prune the JPRT targets -- if debug is just like fastdebug, only slower, then we don't need to test debug builds.
> (Complaining about the time taken in testing is what got this pile-o-fun dropped in my lap.)
>
> David
>



More information about the hotspot-dev mailing list