RFR: JDK-8152666: The new Hotspot Build System
erik.joelsson at oracle.com
Mon Apr 18 07:28:09 UTC 2016
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
>> I have incorporated your changes and published a new webrev:
>> 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
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.
More information about the build-dev