JEP 132: More-prompt finalization

[Kirk Pepperdine]

Hi Tony,


> 
> That was an easy guru status. :-)

I might agree but prior to reading that simple bullet point, this problem wouldn't have been found. So, Guru in the big pond.. not the small one that you live in ;-)

> 
>>>  for removing the calls and performance was noticeable quicker!
>> Tony dropped a nice diagnostic into the GC logs and it's a bullet point in my GC log seminars.
> 
> You're very welcome. :-)
> 
>> There is something that I've not investigated so I might start by asking.. why does RMI call System.gc()?
> 
> (Jon's email pre-empted me but I'll finish the thought)
> 
> RMI has a distributed GC that relies on reference processing to allow each node to recognize that some objects are unreachable so it can notify a remote node (or nodes) that some remote references to them do not exist any more. The remote node might then be able to reclaim objects that are only remotely reachable. (Or this is how I understood it at least.)
> 
> RMI used to call System.gc() once a minute (!!!) but after some encouragement from yours truly they changed the default to once an hour (this is configurable using a property). Note that a STW Full GC is not really required as long as references are processed. So, in CMS (and G1), a concurrent cycle is fine which is why we recommend to use -XX:+ExplicitGCInvokesConcurrent in this case.
> 
> I had been warned by the RMI folks against totally disabling those System.gc()'s (e.g., using -XX:+DisableExplicitGC) given that if Full GCs / concurrent cycles do not otherwise happen at a reasonable frequency then remote nodes might experience memory leaks since they will consider that some otherwise unreachable remote references are still live. I have no idea how severe such memory leaks would be. I guess they'd be very application-dependent.
> 
> An additional thought that just occurred to me: instead of calling System.gc() every hour what RMI should really be doing is calling System.gc() every hour provided no old gen GC has taken place during the last hour. This would be relatively easy to implement by accessing the old GC counter through the GC MXBeans.

Ok, I'm reading this with a 38 degree temp so maybe that's why I'm not getting it, my brain is slow…. I've looked at the link Jon provided.. very nice but still leaves me puzzled. Wouldn't simply implementing Unreferenced  be enough to trigger the clean up? I would imagine a broken pipe or some other fault should cause the distributed objects to be dereferenced (i.e. become collectable). At the end of the day, this seems like calling System.gc() in Servlet.destroy().

Regards,
Kirk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20111228/67c0142b/attachment.html