RFR: 8167446: Add back PermGenSize and MaxPermGenSize

[Jeremy Manson]

For context, at Google, production services are carefully
memory-limited. If we run over the memory limit, we get a memory limit
exceeded error, which isn't very informative.

Admins historically made a calculation that looked like:

memory limit = max heap size + perm gen size + native memory overhead.

Historically, we would carefully size the heap, the perm gen, and the
service's memory limit.  If you ran out of permgen space, you would get a
nice clear OOME instead of a mysterious memory exceeded error.

(Note that this has meant that we have many, many thousands of scripts that
specify MaxPermSize.  We haven't done anything about it because it's a
relatively major undertaking!  This thread inspired me to throw together
some ideas, though.)

When we transitioned to Java 8, we had two choices:

- Let the PermSize flags do nothing.  If there is a class leak, users who
spent time doing this size calculation will get mysterious memory exceeded
errors instead of a clear error.

- Make the PermSize flags map to the MetaspaceSize flags.  Extra room is
available for the Metaspace, but if there is a class leak, then the users
will get clear OOMEs.  Plus, the system doesn't actually use the extra room
unless it needs it, so users who have seen a drop in memory consumption can
adjust their requirements downward appropriately.

We went with option 2.

(Also, we don't adjust the CompressedClassSpaceSize flag.  I thought it was
proportional to the MetaspaceSize, if that was specified?)

Jeremy

On Thu, Oct 13, 2016 at 5:36 AM, Coleen Phillimore <
coleen.phillimore at oracle.com> wrote:

>
>
> On 10/11/16 8:03 PM, Jeremy Manson wrote:
>
> FYI: At Google, to ease the transition, we just made those flags *mean*
> MetaspaceSize and MaxMetaspaceSize.  We got no complaints (as far as I
> know).
>
>
> We didn't want to do that, although we suggested that initial settings
> could be the same as PermSize and MaxPermSize.   I think PermGen was more
> compact than Metaspace is, so I don't think we want to set these as
> limits.  Plus, I think you give MaxPermSize for a different reason than you
> give MaxMetaspaceSize.   One is because the allocation is fixed so you need
> to specify as much as you need, and the other is not to overwhelm your
> machine because the allocation is not fixed at startup.   I'm glad you
> haven't had complaints though.
>
> thanks,
> Coleen
>
>
> Jeremy
>
> On Tue, Oct 11, 2016 at 3:10 PM, Coleen Phillimore <
> coleen.phillimore at oracle.com> wrote:
>
>>
>> I think this looks great.  If we decide to never remove these options at
>> some point in the future, we can change the last element in the array to
>> undefined.
>>
>> Thanks for doing this so quickly, Max.
>> Coleen
>>
>>
>>
>> On 10/11/16 5:29 PM, Max Ockner wrote:
>>
>>>
>>> New webrev: http://oklahoma.us.oracle.com/~mockner/webrev/8167446.02
>>>   - Added a test
>>>   - Adjusted the obsolete field on both flags.
>>>
>>> On 10/11/2016 2:31 PM, harold seigel wrote:
>>>
>>>> Hi Max,
>>>>
>>>> Can you add a small test?  It would prevent someone else from removing
>>>> the options.
>>>>
>>>> I have added a simple test.
>>>
>>> Thanks, Harold
>>>>
>>>>
>>>> On 10/11/2016 1:44 PM, Max Ockner wrote:
>>>>
>>>>> Hello,
>>>>> Please Review this small change.
>>>>>
>>>>> http://cr.openjdk.java.net/~mockner/8167446/
>>>>> https://bugs.openjdk.java.net/browse/JDK-8167446
>>>>>
>>>>> Added PermSize and MaxPermSize to obsolete flags table. They are
>>>>> recognized but ignored.
>>>>>
>>>>> The bug title says "PermGenSize" and "MaxPermGenSize" but the comment
>>>>> says "PermSize" and MaxPermSize". Which one is correct?
>>>>>
>>>>> Tested both options on java -version. Nothing happens, but I don't get
>>>>> an "Unrecognized ..." error.
>>>>>
>>>>> Thanks,
>>>>> Max
>>>>>
>>>>
>>>>
>>>
>>
>
>