Suppress error warning in HotSpot backports

Volker Simonis volker.simonis at
Tue Mar 18 18:48:16 UTC 2014

On Tue, Mar 18, 2014 at 7:24 PM, Andrew Haley <aph at> wrote:
> On 03/18/2014 05:53 PM, Volker Simonis wrote:
>> On Tue, Mar 18, 2014 at 5:39 PM, Andrew Haley <aph at> wrote:
>>> On 03/18/2014 03:00 PM, Volker Simonis wrote:
>>>> The warning is OK, just the wording is misleading.
>>>> The '-XX:MaxPermSize' option is a VM (i.e. HotSpot option) so it only
>>>> depends on the actual HS version and not on the JDK version.
>>>> After Oracle decided to not follow the express model any more (i.e.
>>>> downport new HS versions to old Java releases) for them "8.0" is
>>>> equivalent to "HS 25".
>>>> So you could change the wording to say something like "..was removed
>>>> in this version of HotSpot". But if you run a HS 25 in Java 7 the
>>>> warning is definitely reasonable and useful because the
>>>> '-XX:MaxPermSize' option will be simply ignored (because the PermGen
>>>> is gone).
>>> Is that ever something other than noise, though?  What use is that
>>> message to a user?
>> The message is that the 'MaxPermSize' option became useless and the
>> user may want to use -XX:MetaspaceSize and/or -XX:MaxMetaspaceSize if
>> he has special requirements regarding class meta data. And/or he may
>> wants to rethink his Java memory configuration.
> Hmm.  That's not really what it says, though.
> My thought is that tools like Netbeans, the Java build itself, etc,
> are covered with -XX:MaxPermSize usages.  These are needed, and people
> aren't going to want to remove them, and neither are they going to
> want their screen full of warnings.  Would you?

But that's exactly the point  - with HS25 they aren’t needed because
there is no PermGen any more and the VM can now freely load classes
unless you run out of physical memory (or set MaxMetaspaceSize which
is 2^64/2^32 by default).

So if people upgrade to Java 8 they will need to remove this option or
live with the warning.

>>>> So do you plan do release a version of OpenJDK 7 with HS25?
>>> We sure do.  There's no way that we're back-porting AArch64 to
>>> HS24.
>>>> I think we want to do the same for our commercial SAP JVM, although
>>>> I'm pretty sure this will require some considerable tweaking. And
>>>> Oracle will be probably reluctant to integrate such changes into
>>>> HS25, because they don't want to downport it to Java 7 as far as I
>>>> know. Not to speak about the fact that you'll have to maintain your
>>>> own 7u-forest
>>> That's OK.  We can do that.
>>>> because the official one will probably never contain a HS25.
>>> Well, that depends.  If some evil security bug comes along that
>>> requires a chunk 'o rewriting, Oracle may find the motivation.
>>> But this piece of code just seems wrong to me: it's not that
>>> unusual to back-port HotSpot releases.
>> Well, I'm just the messenger, but Oracle folks have been quite clear
>> in communicating this.
> OK.
>> And you may have noticed, that the hsx-project
>> will be dissolved
>> (
>> after jdk8 has been released (which should be actually today:)
> Sure, I know, but ... why does that matter?

Because there will be no place any more, where you can stabilize a
specific HS version - at least not in the OpenJDK forests. Every Java
8 update will have its own HS version which is a clone of the HS25 in
8u-dev at some point in time.

And there will be just one HS version for Java 9 (in jdk9/hs/hotspot).

So if you'd like to downport a new HS version from 9 to 8 youll need
to clone jdk9/hs/hotspot and stabilize that clone. But there’s
currently neither a project nor a repository for such a task in the
OpenJDK. The same applies if you'd like to downport a HS from 8 to 7 -
you'd need to clone jdk8u/hotspot and stabilize that for 7. But again,
there's no infrastructure for that any more - that was previously done
in the various hsx repositories (i.e. hsx/hsx24, hsx//hsx25, ..). But
they will be made read-only after the Java 8 release.

> Andrew.

More information about the hotspot-dev mailing list