JEP 132: More-prompt finalization

[Kirk Pepperdine]

Hi Tony,

Temp is back to normal and I'm much better.

On 2012-01-05, at 5:12 PM, Tony Printezis wrote:

> Kirk,
> 
> Trying to clean my inbox post-holidays.... I hope your temperature is now back no normal. :-)
> 
> On 12/28/2011 11:21 AM, Kirk Pepperdine wrote:
>> 
>> 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().
> 
> I'm also not sure I understand your point above about simply implementing Unreferenced. Consider the following:
> 
> Host 1: has object A
> Host 2: has object B that has a remote reference to A
> 
> Host 1 does not know anything about what's happening in Host 2. The only thing it has been told is that there's a remote reference to object A. When Host 2 discovers that B is dead it has to somehow tell Host 1 that the remote reference to A does not exist any more. This will allow Host 1 to collect A as long as it's not otherwise unreachable. If Host 2 crashes, that message will never be sent. Not sure what happens in that case, I assume hosts have to frequently refresh the remote references so the ref to A will not be refreshed and eventually be considered dead?

If host2 dies, I would assume that the socket connection it had opened with host1 would break. But that is an exceptional case. In the functional case, B will dereference A which should pass a single along to the B proxy running in host 1 that A should be dereferenced.  If B is collected in Host2, B proxy should be released and collected in Host1 via normal dereferencing. I don't see a need to call System.gc().

Kirk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120105/44f31bf2/attachment.html