8186248 - Allow more flexibility in selecting Heap % of available RAM

David Holmes david.holmes at oracle.com
Wed Aug 23 02:00:09 UTC 2017


On 23/08/2017 6:05 AM, Bob Vandette wrote:
> 
>> On Aug 22, 2017, at 3:50 PM, White, Derek <Derek.White at cavium.com> wrote:
>>
>> Hi Bob,
>>
>> Do you want to add the old flags to the special_jvm_flags list, to get "deprecated" warnings? Or will that come later after CCC-like approval?
>>
> 
> Lets see what others in the VM runtime team have to say about deprecation.

If the new flags are intended as replacements for the old flags, then 
the old flags should be deprecated when the new flags are introduced. I 
would suggest tests be updated to use the new flags at the same time, to 
avoid the deprecation warnings.

David

> I added Deprecation to the old flag descriptions but there are some hotspot
> jtreg tests that use the old flags and I don’t think we want warnings to come out
> while running these tests.
> 
> If I cause the warnings, then I’ll need to change all uses of these old flags in these
> tests as well.  I was expecting to do that in the next release.  Perhaps I can
> use deprecated_in(11).
> 
> Bob.
> 
> 
>> - Derek
>>
>>> -----Original Message-----
>>> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-
>>> bounces at openjdk.java.net] On Behalf Of Bob Vandette
>>> Sent: Tuesday, August 22, 2017 2:22 PM
>>> To: hotspot-runtime-dev at openjdk.java.net runtime <hotspot-runtime-
>>> dev at openjdk.java.net>; hotspot-gc-dev at openjdk.java.net
>>> Subject: RFR: 8186248 - Allow more flexibility in selecting Heap % of available
>>> RAM
>>>
>>> Please review the updated webrev which adds new VM flags to allow for the
>>> manual selection of Heap size based on a percentage of total available
>>> memory.
>>>
>>> This version deprecates the existing fractional options and allows the new %
>>> based flags to override.
>>>
>>> http://cr.openjdk.java.net/~bobv/8186248/webrev.01/
>>> <http://cr.openjdk.java.net/~bobv/8186248/webrev.01/>
>>>
>>> Bob.
>>>
>>>
>>>> On Aug 17, 2017, at 12:36 AM, David Holmes <David.Holmes at oracle.com>
>>> wrote:
>>>>
>>>> On 17/08/2017 1:29 PM, Bob Vandette wrote:
>>>>> I saw that but wasn't sure it needed the added flexibility since its probably
>>> ok that initial sizes are 50% or less.
>>>>
>>>> I'd go for consistency.
>>>>
>>>> Also now you will need to guard against values < 1, I think.
>>>>
>>>> There may be an option checking test that will need updating as well.
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>> Bob.
>>>>>> On Aug 16, 2017, at 5:04 PM, David Holmes <david.holmes at oracle.com>
>>> wrote:
>>>>>>
>>>>>> Hi Bob,
>>>>>>
>>>>>>> On 17/08/2017 3:32 AM, Bob Vandette wrote:
>>>>>>> Please review this simple two line fix which allows more
>>>>>>> flexibility in selecting the % of system RAM to be used by the Heap.  This
>>> just changes two int variables to doubles.
>>>>>>> RFE:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8186248
>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8186248>
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~bobv/8186248
>>>>>>> <http://cr.openjdk.java.net/~bobv/8186248>
>>>>>>
>>>>>> Wouldn't you also want/need to change the type of InitialRAMFraction?
>>>>>>
>>>>>> Note: jdk10/hs is currently closed to changes as we prepare to push up
>>> to jdk10/jdk10.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Bob.
>>
> 



More information about the hotspot-gc-dev mailing list