Memory Leaks
Like I anticipated yesterday - there are memory leaks. Plus I discovered yet another portion of the code that needs to be locked.
The cause of the memory leak is obvious, but the solution isn't. What's causing the leak is when I increment the reference counter for the Locator objects, I do not decrement it if the object fails to aquire it. The simple solution might seem to be just to decrement it, but if I do decrement it later if I fail, all hell breaks loose. I don't know why exactly but judging by previous similar problems this indicates that I actually need to lock yet another portion of the code.
Another portion which had to be locked was where you get the committed version of the object from the locator. When that happens, you attempt to clear the old object from memory (since if it's committed then it's no longer valid). However, if two threads enter that portion of code simultaniously and attempt to clear that portion of code concurrently then we have a problem - which I'm afraid can only be solved by locking.
Nick Hay pointed out an interesting research paper about multi-threaded Garbage Collection at http://www.cs.technion.ac.il/~erez/Papers/cgc9.pdf . GC for multithreaded programs is not trivial. But Nick poitned out that Transactional Memory behaves in a certain predictable pattern, so a specific garbage collecotor for TM might be written.
Moreover, I was thinking that an interesting area of research would be hardware assisted garbage collectors. Just a thought.
All in all, my current DSTM implementation is looking ugly, and I am not sure whether I should proceed as it is or find a garbage collector.
You know what... I think for the time being I will trying to get it working with the minimum number of locks possible, then when that (hopefully) works, try to figure out a way to elude all these locks.
Moreover, investigating garbage collectors,, and maybe finding a simple one might be a good idea.
special case nick
The cause of the memory leak is obvious, but the solution isn't. What's causing the leak is when I increment the reference counter for the Locator objects, I do not decrement it if the object fails to aquire it. The simple solution might seem to be just to decrement it, but if I do decrement it later if I fail, all hell breaks loose. I don't know why exactly but judging by previous similar problems this indicates that I actually need to lock yet another portion of the code.
Another portion which had to be locked was where you get the committed version of the object from the locator. When that happens, you attempt to clear the old object from memory (since if it's committed then it's no longer valid). However, if two threads enter that portion of code simultaniously and attempt to clear that portion of code concurrently then we have a problem - which I'm afraid can only be solved by locking.
Nick Hay pointed out an interesting research paper about multi-threaded Garbage Collection at http://www.cs.technion.ac.il/~erez/Papers/cgc9.pdf . GC for multithreaded programs is not trivial. But Nick poitned out that Transactional Memory behaves in a certain predictable pattern, so a specific garbage collecotor for TM might be written.
Moreover, I was thinking that an interesting area of research would be hardware assisted garbage collectors. Just a thought.
All in all, my current DSTM implementation is looking ugly, and I am not sure whether I should proceed as it is or find a garbage collector.
You know what... I think for the time being I will trying to get it working with the minimum number of locks possible, then when that (hopefully) works, try to figure out a way to elude all these locks.
Moreover, investigating garbage collectors,, and maybe finding a simple one might be a good idea.
special case nick
posted by Fuad at
10:49 AM
0 Comments:
Post a Comment
<< Home