RFR(M) : 7104565 : trim jprt build targets

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Apr 10 09:27:40 PDT 2013


On 4/10/13 8:50 AM, Coleen Phillimore wrote:
> 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.

Nobody use 'profiled' for long time and you can't build it. You may be 
mistaking it for 'optimized' which we still use and it is not touched by 
these changes.

> 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?

They are different now. There was discussion long ago to combine all of 
them into one make/posix. But it is a different task.

> 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.

There is confusion about ASSERT and DEBUG_ONLY() usage. We should move 
in an other direction - rename ASSERT to DEBUG_VM, then DEBUG_ONLY() 
will fit perfectly. But it is big change and outside the scope of these 

> 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.

'optimized' is still used to collect VM statistics. And it is not rots. 
Yes, sometimes we broke its build but we are fixing it.


> 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