Suppress error warning in HotSpot backports

David Holmes david.holmes at oracle.com
Wed Mar 19 08:21:16 UTC 2014


On 19/03/2014 4:13 PM, Volker Simonis wrote:
> On Tuesday, March 18, 2014, Andrew Haley <aph at redhat.com> wrote:
>
>> On 03/18/2014 06:48 PM, Volker Simonis wrote:
>>> On Tue, Mar 18, 2014 at 7:24 PM, Andrew Haley <aph at redhat.com<javascript:;>>
>> wrote:
>>>>
>>>> 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.
>>
>> But this is Java 7.
>
>
> Yes, but with HS25 which makes  it behave exactly like Java 8 in this
> respect!

So you also have to be aware that after the demise of hotspot express we 
may not have a JDK version check in place around code that is actually 
dependent on the JDK version. IIRC there was no actual removal of all 
those JDK_version checks, but new pieces of code may not have them. I 
can't say for sure either way.

Caveat emptor.

David
-----

> So once again: if people upgrade to Java 8 OR Java 7 with HS 25 they will
> need to remove this option or live with the warning
>
> By the way, that's the price you have to pay if you are using -XX options.
> It would be the same if you would switch to IBM J9 which of course is Java
> compatible but doesn't know about PermGen.
>
>
>>>>> And you may have noticed, that the hsx-project
>>>>> will be dissolved
>>>>> (
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-December/011973.html
>> )
>>>>> 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.
>>
>> Oh, I see.  I had no intention of using HSX for this, so it hadn't
>> occurred to me that it might be a problem.
>>
>> Andrew.
>>
>>


More information about the hotspot-dev mailing list