RFR(M) : 7104565 : trim jprt build targets

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Apr 9 23:31:01 PDT 2013

On 4/9/13 10:34 PM, David Holmes wrote:
> On 10/04/2013 2:41 PM, Vladimir Kozlov wrote:
>> David, the only difference between debug and fastdebug VM builds should
>> be optimization level.
> Ok.
> Looking at stackMapFrame.hpp the changeset that added the "ifdef DEBUG" was
> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4ee06e614636
> and it seems to me that perhaps it should have been
> "ifndef PRODUCT" based on the fact that it appears to be a refactoring
> of NOT_PRODUCT code. (The only difference being whether or not it is
> included in the optimized build.)

Thank you, David, for finding this. I think, the intention of changes 
was to not include it into optimized build but may be there was 
confusion about DEBUG vs ASSERT.

We need a brave soul :) and general agreement to do global renaming 
after we done with 7uX (currently we still do backports from hs25 into 

We can rename ASSERT to DEBUG_VM (not DEBUG to avoid conflicts with 
external include files like in llvmHeaders.hpp). Then we can change low 
case macro name assert() to upper case ASSERT() to avoid other external 
conflicts found recently. And remove low case debug_only() macro to use 
only upper case.

I hope such changes will resolve our concerns/confusions. But changes 
will be big and will take time.

We can consider David's C. current changes as a move in that direction.


> Thanks,
> David
>> The fastdebug VM uses the same -O4 (or -O3) as
>> product build which forces inlining and other optimization and helps
>> with VM speed. Debug VM compiled without any optimizations and does not
>> inline (we need this to be able debug). It is a lot slower then
>> fastdebug VM and because of that can't be used for testing. There should
>> be no other differences between debug and fastdebug VM.
>> All checks done in debug VM should be done in fastdebug VM, period!
>>>>> The changes in src/share/vm/shark/llvmHeaders.hpp need to be confirmed
>>>>> by the shark folk (if they haven't already). (And of course depend on
>>>>> -DDEBUG being eradicated.)
>>>> Oracle is not supporting shark! They are on this mailing alias. We
>>>> discussing this for long time already. We hear nothing from them. If
>>>> they find problems later they will send a patch and we use it.
>>> As long as this shouldn't break their build (which it shouldn't). But
>>> based on that view you could have simply left this untouched.
>> It looks like that code tries to preserve our DEBUG across llvm include
>> files. Yes, you are right - we can leave it.
>> David C., please, undo changes in llvmHeaders.hpp.
>> Thanks,
>> Vladimir
>>> Thanks,
>>> David
>>>> Thanks,
>>>> Vladimir
>>>>> Thanks,
>>>>> David
>>>>> -----
>>>>> On 10/04/2013 9:01 AM, David Chase wrote:
>>>>>> On 2013-04-09, at 5:26 PM, Vladimir Kozlov
>>>>>> <vladimir.kozlov at oracle.com> wrote:
>>>>>>> One note: in frame_sparc.cpp remove 'jvmg' in the line you modified
>>>>>>> since we will not build jvmg.
>>>>>> done
>>>>>>> And question: did you use mercurial commands to remove and rename
>>>>>>> jvm.make and debug.make? We need to use hg commands to preserve
>>>>>>> changes history for jvmg.make (it has more changesets then old
>>>>>>> debug.make).
>>>>>>> I just want to confirm because sometimes webrev may not show
>>>>>>> correctly what was done to sources. I mean you need to do:
>>>>>>> hg remove debug.make
>>>>>>> hg rename jvmg.make debug.make
>>>>>>> and then edit debug.make
>>>>>> To be sure:
>>>>>> 10009  hg revert make/{solaris,bsd,linux}/makefiles/jvmg.make
>>>>>> 10010  zip -9 ../safemakes.zip
>>>>>> make/{solaris,bsd,linux}/makefiles/debug.make
>>>>>> 10011  hg revert make/{solaris,bsd,linux}/makefiles/debug.make
>>>>>> 10012  hg remove make/{solaris,bsd,linux}/makefiles/debug.make
>>>>>> 10013  for i in solaris bsd linux ; do hg rename
>>>>>> make/$i/makefiles/{jvmg,debug}.make; done
>>>>>> 10014  unzip -l ../safemakes.zip
>>>>>> 10015  unzip ../safemakes.zip
>>>>>> And the new-and-improved diffs:
>>>>>> http://cr.openjdk.java.net/~drchase/7104565/webrev.06-new/

More information about the hotspot-dev mailing list