RFR(M) : 7104565 : trim jprt build targets

[Coleen Phillimore]

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