RFR: JDK-8152666: The new Hotspot Build System

[Erik Joelsson]

On 2016-04-17 12:37, David Holmes wrote:
> I missed all the fun while I was on vacation and have still not yet 
> had a chance to look at the actual code, but have one query ...
Yeah, bad timing, but time was also running out. There is still time for 
adjustments of course.
>
> On 6/04/2016 7:10 PM, Erik Joelsson wrote:
>> Hello Dan and thank you for the review! I know it's a lot to chew 
>> through.
>>
>> I have incorporated your changes and published a new webrev:
>> http://cr.openjdk.java.net/~erikj/8152666/webrev.02/
>>
>> On 2016-04-05 20:10, Daniel D. Daugherty wrote:
>>>
>>>
>>> > The new build supports the following variants:
>>> >
>>> >  * server (C1+C2)
>>>
>>> The above "server" variant is the "tiered server". Does the new
>>> build system support the "C2 server" variant? What about the
>>> 32-bit server and 64-bit server build variants? For example,
>>> on Linux you can have:
>>>
>>>   * C1/Client, 32-bit
>>>   * C2/Server, 32-bit
>>>   * Tiered (C1 & C2), 32-bit
>>>   * C2/Server, 64-bit
>>>   * Tiered (C1 + C2), 64-bit
>>>
>>> The above wide range of variants is also true for Win*.
>>>
>> There is a way to achieve this even if it's not as straight forward.
>> It's controlled through the new "jvm-feature" setting. To build a
>> completely custom set of features for a jvm, you set the
>> --with-jvm-variants=custom and then define the full feature set using
>> --with-jvm-features=compiler2,... For "server, client, core, minimal,
>> zero and zeroshark" there is a predefined set of features while the
>> custom variant has no features by default.
>
> It isn't clear to me how Tiered fits into this scheme. Even in the old 
> hotspot build Tiered is managed as a variant of building C2 with 
> another make variable controlling tiered or non-tiered.
>
In the new build, tiered is simply defined as enabling both the 
compiler1 and the compiler2 "features". If you look in the old build 
tiered.make, the only thing it does is setting both -DCOMPILER2 and 
-DCOMPILER1 on CFLAGS. From what I can tell, there is no other 
meaningful way of interpreting enabling both c1 and c2 in the same jvm.
> It is also unclear to me what a "jvm variant" is if compiler2 etc are 
> all considered features - is a variant a predefined set of features?
>
Yes, that is essentially what a variant is, but it's also in part a way 
of naming a particular jvm, since we can sometimes build multiple 
variants in the same build. In theory we could enhance the configure UI 
for this to be able to arbitrarily define any number of variants to be 
built together, name them arbitrary things and define an arbitrary set 
of features for each one. The build itself would support such a scheme 
at this point (the internal variables are general enough), but in 
reality, I don't think we are really interested in supporting that. Also 
the source code is certainly not setup to handle any combination of 
features today.

What configure supports now is picking certain valid combinations of 
variants to build. Enable or disable certain features through 
specialized parameters. Enabling certain other features through the 
--with-jvm-features argument. Note that --with-jvm-features will apply 
to all variants currently being built. Finally there is the custom 
variant, which by default has no features, where you may create your own 
special combination if you really want to.

/Erik