Status of JEP-8204088/JDK-8236073

[Rodrigo Bruno]

Hi Thomas,

On Mon, 23 Aug 2021 at 11:05, Thomas Schatzl <thomas.schatzl at oracle.com>
wrote:

> Hi Rodrigo,
>
> On 18.08.21 09:36, Rodrigo Bruno wrote:
> > Hi Thomas, Hi Man,
> >
> > On Mon, 2 Aug 2021 at 16:49, Thomas Schatzl <thomas.schatzl at oracle.com
> > <mailto:thomas.schatzl at oracle.com>> wrote:
> [...]
> >
> >     Fwiw, these two are fairly independent issues, and the main problem
> >     with
> >     the proposed CurrentMaxHeapSize patch has been that the change is not
> >     atomic in the sense that the changes simply modify the global heap
> size
> >     variable without regard whether and when it is accessed. That may
> >     result
> >     in fairly nasty races as different components of the GC may then
> have a
> >     different notion of what the current max heap size actually is at the
> >     moment.
> >
> >
> > That is true. However, we could easily do the update to
> > CurrentMaxHeapSize inside a VMOperation to ensure an atomic change. This
> > is not in the current patch but it is probably a simple change. Right?
>
> Unfortunately, not, at least when I looked last time. There did not seem
> to be a way to trigger a VM operation based on the change of a variable
> using a jcmd command.
>
> An intermediate step of just polling that variable (in a g1 service
> task) and then triggering it or just waiting until the next gc (which is
> probably best, particular wrt to decreases in heap size) could be options.
>

That is a very good point. Waiting for the next GC might actually be the
best option because we would (if I am not mistaken) always need a GC before
a heap expansion/shrinkage.

Do you think the patch would be considered if we proposed a newer version
fixing this issue?

cheers,
rodrigo


>
> Thanks,
>    Thomas
>


-- 
rodrigo-bruno.github.io