Details
-
Bug
-
Resolution: Fixed
-
P3
-
8
-
None
-
b98
-
generic
-
generic
-
Verified
Description
[imported from kenai]
I am filing this bug from code reading. When we delete an element of array, DeletedArrayFilter's delete is called - which sets the right bit in BitVector. But, the element in the underlying array data does not seem to be cleared - which I believe leaks memory.
var arr = [3, { foo : 44 }, 56];
delete arr[1];
print(arr[1]);
while arr[1] is undefined, the object { foo: 44 } is still there in the underlying ArrayData of DeletedArrayFilter instance.
Jim says: I've been thinking about this one since the implementation. I think in the case of Object array, we can do the traditional store of undefined and empties in the array and not use filters. The only requirement is that when we "get" or convert, we translate empties to undefined.
Maybe the better alternative is to add setEmpty(int index) to ArrayData and call it from DeleteArrayFilter.delete. This is needed since we don't know the underlying data type.
I am filing this bug from code reading. When we delete an element of array, DeletedArrayFilter's delete is called - which sets the right bit in BitVector. But, the element in the underlying array data does not seem to be cleared - which I believe leaks memory.
var arr = [3, { foo : 44 }, 56];
delete arr[1];
print(arr[1]);
while arr[1] is undefined, the object { foo: 44 } is still there in the underlying ArrayData of DeletedArrayFilter instance.
Jim says: I've been thinking about this one since the implementation. I think in the case of Object array, we can do the traditional store of undefined and empties in the array and not use filters. The only requirement is that when we "get" or convert, we translate empties to undefined.
Maybe the better alternative is to add setEmpty(int index) to ArrayData and call it from DeleteArrayFilter.delete. This is needed since we don't know the underlying data type.