<div dir="ltr">Hi Per and Thomas,<div><br></div><div>thank you for your comments.</div><div><br></div><div>I think it is possible to implement this feature using the service thread or using a separate thread.</div><div>I see some pros and cons of having a separate thread:</div><div><br></div><div>Pros:</div><div>- using the service thread exposes something that is G1 specific to the rest of the JVM. </div><div>Thus, using a separate thread, hides this feature from the outsite.</div><div><br></div><div>Cons:</div><div>- Having a manageable timeout is a bit more tricky to implement in a separate/dedicated thread. </div><div>We need to be able to handle switch on and off. It might require some variable pooling.</div><div>- It requires some more memory.</div><div><br></div><div>Regardless of the path taken, I can prepare a new version of the patch whenever we decide on this.</div><div><br></div><div>cheers,</div><div>rodrigo</div></div><br><div class="gmail_quote"><div dir="ltr">Per Liden <<a href="mailto:per.liden@oracle.com">per.liden@oracle.com</a>> escreveu no dia sexta, 7/09/2018 à(s) 11:58:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Thomas,<br>
<br>
On 09/07/2018 10:10 AM, Thomas Schatzl wrote:<br>
[...]<br>
>    overnight I thought a bit of the implementation, and given the<br>
> problem with heap usage of the new thread, and the requirement of being<br>
> able to turn on/off that feature by a managed variable, the best change<br>
> would probably reusing the service thread as you did in the initial<br>
> change.<br>
<br>
I'm not convinced that this should be handled outside of G1. If there's <br>
a need to have the flag manageable at runtime (is that really the <br>
case?), you could just always start the G1DetectIdleThread and have it <br>
check the flag. I wouldn't worry too much about the memory overhead for <br>
the stack.<br>
<br>
cheers,<br>
Per<br>
</blockquote></div>