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

[Thomas Schatzl]

Hi,

On 02.02.23 12:31, Katsutomo Sekiguchi (Fujitsu) wrote:
> 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.

   making the heap expansion follow CurrentMaxHeapSize instead of 
MaxHeapSize is not that big of an issue. Existing code already handles 
committing and uncommitting just fine if you use the new variable.

I.e. the only difference having a CurrentMaxHeapSize or not is instead 
of expanding until MaxHeapSize, only allow heap expansion (and 
allocation) up to CurrentMaxHeapSize.

E.g. in the patch you gave [1], the hunk at @@ -1148,7 +1148,8 @@ in 
g1CollectedHeap.cpp limited that for heap expansion.
It also handled other cases where G1 would try to expand.

The real problems (to me) seem to be located in other users of "max heap 
size" value in the VM.

An initial review of mine noticed quite a few issues and questions with 
that implementation ([2]) that ought to be addressed in one way or 
another; briefly looking over them the comments still seem very much 
applicable.

[1] http://cr.openjdk.java.net/~tschatzl/jelastic/cmx/
[2] https://mail.openjdk.org/pipermail/hotspot-gc-dev/2018-June/022472.html

Hth,
   Thomas