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