|
[
Permlink
| « Hide
]
Manish Khettry added a comment - 18/Feb/06 11:42 AM
It looks like elements from the sorts vector in RAMTransaction are never removed. dropSort merely nulls out the element. If you repeatedly open/execute/close a query that uses a sorter you will leak one reference every iteration.
Is the comment about the sort memory being used in AccessManger an observation about the original test program?
Yes sorts currently require one array entry per sort per transaction. At end of transaction this memory is freed. When originally coded the expectation was small number of sorts per transaction. Note it is not as simple as shrinking the array in dropSort, as the array index is currently the "sort id". So a little more work would be necessary. A couple of options: 1) see if we could reuse sort id's. 2) allocate sort id's differently and then probably store sort in hash table rather than array/vector Any idea if this is the "only" remaining growing memory issue for this test. The growth should be only one array entry per statement, the contents are null'd so garbage collection should happen on everything else. Yes, it is from the original test program. BTW, I added a conn.commit() to the original program-- so it basically looks like this:
while (true) { ps = conn.prepareStatement(sql); rs = ps.executeQuery(); // read from rs. conn.commit(); // close rs, ps } and it still runs out of memory. Shouldn't doing a commit create a new transaction? The problem seems to be that RAMTransaction.sorts is only cleared when the connection is closed, not when the transaction is committed. RAMTransaction.commit() calls closeControllers() with closeHeldControllers=false, so sorts.removeAllElements() is not called on commit.
One simple solution is to remove all trailing null elements from the sorts vector on commit. That should leave the held controllers open and not interfere with the sort ids. While it does not solve the general case (a held controller may prevent space reclaimation at the start of the vector), it does solve the most common cases. With that change, the test program completed without running out of memory (-Xmx10M).
Attaching a patch which implements reuse of sort identifiers, as suggested by Mike.
I have successfully run the repro for The patch is ready for review. Thanks! I think the patch looks good. Is there a reason why freeSortIds cannot be a valid ArrayList at all times? If it was, you would not need the null-tests. I guess always having a valid ArrayList would increase footprint unnecessarily if it is rarely used. Is that added footprint still a problem if freeSortIds is initialized to an ArrayList with zero capacity (new ArrayList(0))?
+1 to commit Thanks for reviewing the patch, Dyre. I agree with your comment about freeSortIds and null tests. Uploading a new patch which initializes freeSortIds when the sorts vector is initialized. Since freeSortIds is only used when sorts != null, no tests for freeSortIds != null are needed. I have started a derbyall run.
Committed to trunk with revision 467578.
Committed to 10.2 with revision 467580. Linking
This issue is resolved and has not been updated in the last 12 months (since 24/Jan/07).
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Sub-task
Closed
Major
