db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Nulling out variables for GC
Date Fri, 23 Feb 2007 17:17:05 GMT
Knut Anders Hatlen wrote:
> Daniel John Debrunner <djd@apache.org> writes:
> 
>> Knut Anders Hatlen wrote:
>>> djd@apache.org writes:
>>>
>>>>  		if ((pageData == null) || (pageData.length !=
>>>> pageSize))          {
>>>> +            // Give a chance for gc to release the old buffer
>>>> +            pageData = null;  			pageData = new
>>>> byte[pageSize];
>>> Out of curiosity (I have seen similar code changes go in before), why
>>> does pageData need to be set to null to be garbage collected? Is this
>>> a workaround for a bug on a certain JVM? If so, it would be good to
>>> document it in a comment.
>> So the idea is to allow the old value of pageData garbage collected
>> before the allocation of the new array, rather than after.
>> Here's the thinking ...
>>
>> Say on entry pageData is a reference to an 8k array, but the code
>> needs a 16k array. With pageData = new byte[16384] I believe the
>> semantics of Java require the non-atomic ordering be:
>>
>>      allocate 16k array
>>      set the field pageData to the newly allocated buffer.
>>
>> Thus that order requires that the code at some point has a reference
>> to both arrays and thus the 8k array cannot be garbage collected until
>> after the field is set. I believe this to be the case because if the
>> new byte[16384] throws OutOfMemoryError then pageData must remain set
>> to the old value (8k array).
>>
>> So (in an extreme case) if the vm only had 10k of free memory the
>> allocation would fail, but if pageData is nulled out before the new
>> then the free memory can jump to 18k and the allocation succeed.
>>
>> So maybe this is incorrect thinking?
>> Do the JVM's have some special optimizations to not require this?
> 
> Hmm, that's interesting. A small test case indicated that you're
> right. Thanks for clearing it up!
> 
> Perhaps the comment could be more verbose? I think it would be better
> if it said that it gave gc a chance to release the old buffer before
> it allocates the new buffer. It's a bit confusing as it stands now (to
> me at least), since gc does have a chance to release the buffer if the
> next statement doesn't fail.

Will do. I also think that this should *not* be a general coding style, 
  just selective where the object to be gc'ed may be large. For example 
in the datatype code for a binary object, the value may change from a 
30Mb array to a 2 byte array, so nulling out the reference before 
creating a new one is good. Also I don't know what happens if the 
variable is one that would go out of scope if an exception was thrown, 
because in that situation the jvm could remove the reference to the old 
object before it tries to allocate the new object.


Dan.



Mime
View raw message