RFR: JDK-8152666: The new Hotspot Build System

[David Holmes]

On 18/04/2016 5:28 PM, Erik Joelsson wrote:
>
>
> 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.

There was also Variant=tiered and the FORCED_TIERED variable - but yes 
the only time COMPILER1 and COMPILER2 are defined is when building 
tiered. I'll need to examine this bit closer.

Thanks,
David


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