RFR: JDK-8201483 Make it possible to disable JVM features

David Holmes david.holmes at oracle.com
Fri Apr 13 13:40:29 UTC 2018

On 13/04/2018 5:40 PM, Magnus Ihse Bursie wrote:
> On 2018-04-12 23:30, David Holmes wrote:
>> On 12/04/2018 11:33 PM, Magnus Ihse Bursie wrote:
>>> On 2018-04-12 14:15, David Holmes wrote:
>>>> Hi Magnus,
>>>> On 12/04/2018 9:39 PM, Magnus Ihse Bursie wrote:
>>>>> It is currently easy to add new JVM features to the JVM build, but 
>>>>> it is not possible to remove features.
>>>>> With this change, features can be both added or removed from the 
>>>>> default set. They are added using --with-jvm-features=f1,f2 and 
>>>>> removed using --with-jvm-features=-f1,-f2. The syntax can be 
>>>>> combined, so --with-jvm-features=dtrace,-nmt will enable dtrace but 
>>>>> disable native memory tracking.
>>>> I need to point out that we have never tested disabling individual 
>>>> VM features likes this. They are either all on, or all off for the 
>>>> minimal VM! There may be implicit dependencies between features.
>>> Well, I have. :-) However, I don't do that regularly, and changes 
>>> might very well have crept in. As always, if you build something 
>>> non-standard that is not regularly tested, you're on your own.
>> Feels to me like you've taken away the safety-fence and are 
>> encouraging people to attempt these unsupported configurations. 
>> Whether that was your intent or not.
> It is always possible to configure something that does not work. :-) We 
> can make it more easy to do the right thing, but if we were to make 
> impossible everything that has not been tested, then we would also make 
> things impossible that are needed for some use cases.

I don't buy that.

> Wrt JVM features, this has *always* been possible. If you use 
> "--with-jvm-variants=custom --with-jvm-features=jvmti,nmt" then you 
> *are* going to build an almost (or fully?) useless JVM. In fact, this 
> method made it *much* harder to try to get a functioning JVM without a 
> specific feature.

I have no recollection of jvm variant "custom" being introduced.

> I think I should update the build documentation regarding JVM features 
> though, and I can definitely add some wisely worded warnings about 
> unsupported combinations of features, especially if removing them.

If you can document what the allowed configurations are then you should 
be able to add constraints that only allows supported sets of features. 
This is what the original set of JVM variants provided - it was fixed 
not arbitrary! As I said I don't recall you adding the "custom" option. :(

>>> In any case, the purpose of this is not so much to disable existing 
>>> JVM features (after all, no one has really been missing this 
>>> functionality), as to pave the way for the upcoming patch for 
>>> including/excluding individual GCs.
>> Surely a GC selection flag would have sufficed.
> It was the common agreement of both the build team and the GC folks 
> responsive for the upcoming selectively GC inclusion patch, that this 
> was better handled as JVM features than a separate GC flag.

Maybe something that affects all of hotspot should have been discussed 
more broadly.


> /Magnus
>> David
>>> /Magnus
>>>> David
>>>>> I also included some additional code cleanup and fixes, such as 
>>>>> printing the JVM feature set at the summary.
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201483
>>>>> WebRev: 
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8201483-disable-JVM-features/webrev.01 

More information about the build-dev mailing list