A question about the present condition/plans of Dynamic Max Memory Limit

[Katsutomo Sekiguchi (Fujitsu)]

Hi Thomas,

Thank you for quick reply. I got the current situation.

I believe that it needs a chunk of address space for MaxHeapSize even if
it only allocate heaps up to CurrentMaxHeapSize.
In other words, do you mean it reserve an address space of MaxHeapSize
and commit a physical memory to CurrentMaxHeapSize instead of MaxHeapSize
then control the amount of physical memory by changing CurrentMaxHeapSize?

Maybe, I think we must figure out somehow to feed back current conditions like
heap usage as input to change CurrentMaxHeapSize.

Regards,
Kats Sekiguchi

-----Original Message-----
From: hotspot-gc-dev <hotspot-gc-dev-retn at openjdk.org> On Behalf Of Thomas Schatzl
Sent: Thursday, February 2, 2023 6:10 PM
To: hotspot-gc-dev at openjdk.org
Subject: Re: A question about the present condition/plans of Dynamic Max Memory Limit

Hi,

On 02.02.23 08:21, Katsutomo Sekiguchi (Fujitsu) wrote:
> Dear Thomas Schatzl,
> 
> I'm interested in JEP-8204088.
> Let me ask you two questions.
> 
> First, according to "RFR-8204088: Dynamic Max Memory Limit" (*1), I believe that there is the JEP-8204088 implementation in (*2) as modified files.
> So, max_heap_size and Java.lang.Runtime#maxMemory() are implemented to adopt CurrentMaxHeapSize. However, it is not known where CurrentMaxHeapSize will be updated, and it does not appear to be implemented yet.
> Where can I find the latest implementation of JEP-8204088?
> 
> *1: 
> https://mail.openjdk.org/pipermail/hotspot-gc-dev/2018-June/022454.htm
> l
> *2: http://cr.openjdk.java.net/~tschatzl/jelastic/cmx/
> 

The latest known, open patch is at your link [2].

> Second, could you tell me more specifically about your future plans for JEP-8204088?
> So, are there any technical barriers?

Nobody has proposed a patch that can be discussed further.

There has been additional discussion about a more encompassing proposal from J. Joo on this list[A], with Dynamic Max Memory Limit being a part.

As a response of mine[B] indicates ("From what I understand the main issue is thinking about and defining interaction with existing Min/Initial/MaxHeapSize flags (e.g. [1]).

SoftMaxHeapSize otherwise seems to be relatively unproblematic.

Iirc specifically for the Current/HardMaxHeapSize flag, the implementation needs to be thought through in more detail. There is an initial list of problems ([2]) that should be worked through and defined as it has much more external impact.")

There are no particular technical problems, but nobody has stepped up to actually tackle them as far as I am aware. Contributions are welcome :)

Hth,
   Thomas

[A]
https://mail.openjdk.org/pipermail/hotspot-gc-dev/2022-September/040096.html
[B]
https://mail.openjdk.org/pipermail/hotspot-gc-dev/2022-September/040207.html