[7u60] RFR 8024648 : 8016131 breaks Zero port

[David Holmes]

I have a concern here.

First this general situation is a mess. We started adding the new-build 
support in hs24 but JDK 8 is using hs25, so all this SPEC and 
JVM_VARIANT stuff is completely unwanted in JDK 7u. My preference here 
would be to get this stuff backed out of 7u and return to a completely 
configure-ignorant build system. That said I'm not sure that is really 
the issue with ZERO/SHARK builds.

My concern with the proposed patch is that defs.make is not intended to 
be included by every other Makefile and/or .make file. We all know by 
now that the hotspot build system is complex, convoluted and fragile. 
When you do a hotspot build there are multiple nested sub-makes 
involved, as well as build file generation and use. The "big picture" 
intent is that defs.make contains all the high-level stuff needed by the 
"top" level makefile targets. buildtree.make will then generate other 
.make files using that information. It is very difficult to see exactly 
which .make file will get used by which phase of the overall build. 
Unfortunately this leads to a tendency where if a "low-level" file needs 
access to X, which is defined in defs.make, then the "solution" is just 
to include defs.make in that file. We did the same thing for 
buildtree.make in JDK 8. But I have reservations about also doing it for 
gcc.make and vm.make. I think it is the wrong solution - we should be 
passing the needed variables/values through the files generated by 
buildtree.make.

If this was to go ahead as-is I would want to know that there has been a 
comparison of all the build commands before and after to ensure no 
unintended changes have been introduced. A set of successful builds is 
not in itself sufficient.

David

On 7/02/2014 8:10 AM, Alejandro E Murillo wrote:
> I  forgot to change the "subject".
> The change is and has been approved for 7u60 (hs24.60)
> Thanks
>
> Alejandro
>
> On 2/6/2014 3:03 PM, Alejandro E Murillo wrote:
>>
>> can we get 2  hotspot reviewers quickly  check this change ?
>> thanks
>> Alejandro
>>
>> -------- Original Message --------
>> Subject:     Re: Question on 8024648 : 8016131 breaks Zero port
>> Date:     Thu, 6 Feb 2014 16:21:29 -0500 (EST)
>> From:     Andrew Hughes <gnu.andrew at redhat.com>
>> To:     Alejandro E Murillo <alejandro.murillo at oracle.com>
>> CC:     Seán Coffey <sean.coffey at oracle.com>, Omair Majid
>> <omajid at redhat.com>, jdk7u-dev at openjdk.java.net
>>
>>
>>
>> ----- Original Message -----
>>
>>
>> Here's the webrev:
>>
>> http://cr.openjdk.java.net/~andrew/jdk7u/8024648/
>>
>> My OpenJDK username is andrew (should already be included in the commit)
>>
>> The changes are as follows:
>>
>> * Bring in defs.make to a number of makefiles which expect
>> JVM_VARIANT_ZERO
>> or JVM_VARIANT_ZEROSHARK to be set, but don't parse the makefile that
>> sets
>> it. This is a regression caused by the new build which instead sets these
>> via configure and $(SPEC). There is code for handling the old build
>> (ZERO_BUILD=true) in defs.make but it isn't brought in. (see 7141246)
>> * Update the call_wrapper function following 8024648.
>>
>> I've updated the bug summary to reflect that it fixes changes from both
>> bugs, but we can split them into two separate bugs if you prefer. Without
>> the 7141246 fix, the build fails in seconds.
>>
>> With the webrev applied:
>>
>> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java -version
>> openjdk version "1.7.0-internal"
>> OpenJDK Runtime Environment (build
>> 1.7.0-internal-andrew_2014_02_06_19_43-b00)
>> OpenJDK 64-Bit Zero VM (build 24.80-b01, interpreted mode)
>>
>> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java HelloWorld
>> Hello World
>>
>>
>