RFR: bug: Timely Reducing Unused Committed Memory

Rodrigo Bruno rbruno at gsd.inesc-id.pt
Fri Sep 7 15:37:54 UTC 2018


Hi Per and Thomas,

thank you for your comments.

I think it is possible to implement this feature using the service thread
or using a separate thread.
I see some pros and cons of having a separate thread:

Pros:
- using the service thread exposes something that is G1 specific to the
rest of the JVM.
Thus, using a separate thread, hides this feature from the outsite.

Cons:
- Having a manageable timeout is a bit more tricky to implement in a
separate/dedicated thread.
We need to be able to handle switch on and off. It might require some
variable pooling.
- It requires some more memory.

Regardless of the path taken, I can prepare a new version of the patch
whenever we decide on this.

cheers,
rodrigo

Per Liden <per.liden at oracle.com> escreveu no dia sexta, 7/09/2018 à(s)
11:58:

> Hi Thomas,
>
> On 09/07/2018 10:10 AM, Thomas Schatzl wrote:
> [...]
> >    overnight I thought a bit of the implementation, and given the
> > problem with heap usage of the new thread, and the requirement of being
> > able to turn on/off that feature by a managed variable, the best change
> > would probably reusing the service thread as you did in the initial
> > change.
>
> I'm not convinced that this should be handled outside of G1. If there's
> a need to have the flag manageable at runtime (is that really the
> case?), you could just always start the G1DetectIdleThread and have it
> check the flag. I wouldn't worry too much about the memory overhead for
> the stack.
>
> cheers,
> Per
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20180907/c983f531/attachment.html>


More information about the hotspot-gc-dev mailing list