RFR(M) : 7104565 : trim jprt build targets

Wed Apr 10 10:43:11 PDT 2013

 > There are a lot of #ifdef ASSERTs in the code.   It is bigger and more
 > disruptive to change these to DEBUG_VM or (why not) simply DEBUG.

Unfortunately DEBUG is used by external include files. For example, in 
llvm - that is why we have that DEBUG preserve code in 
shark/llvmHeaders.hpp.

 >> 'optimized' is still used to collect VM statistics. And it is not
 >> rots. Yes, sometimes we broke its build but we are fixing it.
 >
 > Well, it does break a lot!  It should be a JPRT build target because
 > this is completely avoidable.   Not with this change.   Next time it
 > breaks someone should fix it and add it to be a JPRT build target.

Agree, at least on platforms which are not bottleneck for JPRT job.

Thanks,
Vladimir

On 4/10/13 10:02 AM, Coleen Phillimore wrote:
> On 4/10/2013 12:27 PM, Vladimir Kozlov wrote:
>> Coleen,
>>
>> 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.
>
> If it doesn't build now, then, yes it should be removed.   Two people
> asked me about it recently though, so it might be the only way to
> profile the vm on some platforms.
>
>>
>>>
>>> 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.
>>
>
> Yes, bug id JDK-7015652 <https://jbs.oracle.com/bugs/browse/JDK-7015652>
>>>
>>> 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 changes.
>
> There are a lot of #ifdef ASSERTs in the code.   It is bigger and more
> disruptive to change these to DEBUG_VM or (why not) simply DEBUG.
>>
>>>
>>> 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.
>>
>
> Well, it does break a lot!  It should be a JPRT build target because
> this is completely avoidable.   Not with this change.   Next time it
> breaks someone should fix it and add it to be a JPRT build target.
>
> Coleen
>> Thanks,
>> Vladimir
>>
>>>
>>> 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
>>>>
>>>
>