DSTM with GC is Working
Yay!
I finally got DSTM working with garbage collection under Solaris. I almost cried tears of joy! Fortuantely, since I abided by the ANSI C standard, I didn't have much trouble porting the code to Solaris.
For the question on whether to use or not to use garbage collection. What I had in mind what to test the code which is running correctly with garbage collection, and compare it to the leaky manual memory allocation code then see which version is performing better.
If the leaky version performed better than the garbage collected one, then it would be worthwhile trying to figure out where the leaks were and fix them. But if the garbage collected one performed better, then it would be pointless to fix the leaks but we should just stick to the garbage collected one.
So, what results did I get from my tests? (I should note that the manual memory allocation was was even relaxed a bit more to allow for more memory leaks in hopes of better performance).
I used my first DSTM test case which basically increments and decrements a counter equally (thus the counter should end up with the same value it started with). I tried it on both with 1000 increments and 1000 decrements. Then tried it again with 991000 increments and decrements. The result was that it performs signifinctly better (twice as much) with garbage collection rather than manual memory allocations. I was expecting better performance but this was way better than i thought.
What this means is that we should definitely proceed with the Garbage Collector based implementation.
Things to do: compare the performance of DSTM in Java vs C and see if there are any significant differences. I would think that the Java implementation might actually perform better than the C one simply because of the better Garbage Management available there.
Another thing to do: write a makefile to do all the compiling and building.
Results
Quick note of the system I was using: Sun One Studio 10 on a Solaris Sparc machine.
Manual Memory Management
1000 Increments and 990 Decrements
RSS (Memory used): 1064 kbytes
Time: 0:00
991000 Increments and 990990 Decrements
RSS (Memory used): 47736 kbytes
Time: 0:15
Garbage Collection
1000 Increments and 990 Decrements
RSS (Memory used): 1728 kbytes
Time: 0:00
991000 Increments and 990990 Decrements
RSS (Memory used): 1792 kbytes
Time: 0:08
Some useful commads that I used
To find out the running processses execution time as well as their memory utilization:-
ps -ly
To compile the code (for every file):-
cc -c test.c
To build the project with garbage collection:-
cc atomic.o locator.o readtable.o thread.o transaction.o contention.o readset.o test.o tobject.o utility.o -lgc -z muldefs -o test
The -z muldefs is to allow for the multiple definition of some global constants, and the -lgc is to load the garbage collector library (this should come AFTER all the source files)
Note: You definitely should create a makefile instead.
Why is Garbage Collection Faster
A couple of articles that might shed some light:-
http://www.memorymanagement.org/faq.html#delete.speed
http://www.memorymanagement.org/faq.html#gc.speed
Good Garbage Collection References:-
http://www.iecc.com/gclist/GC-faq.html
http://www.memorymanagement.org/faq.html
http://www.hpl.hp.co.uk/personal/Hans_Boehm/gc/
Read this paper:-
ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps
I finally got DSTM working with garbage collection under Solaris. I almost cried tears of joy! Fortuantely, since I abided by the ANSI C standard, I didn't have much trouble porting the code to Solaris.
For the question on whether to use or not to use garbage collection. What I had in mind what to test the code which is running correctly with garbage collection, and compare it to the leaky manual memory allocation code then see which version is performing better.
If the leaky version performed better than the garbage collected one, then it would be worthwhile trying to figure out where the leaks were and fix them. But if the garbage collected one performed better, then it would be pointless to fix the leaks but we should just stick to the garbage collected one.
So, what results did I get from my tests? (I should note that the manual memory allocation was was even relaxed a bit more to allow for more memory leaks in hopes of better performance).
I used my first DSTM test case which basically increments and decrements a counter equally (thus the counter should end up with the same value it started with). I tried it on both with 1000 increments and 1000 decrements. Then tried it again with 991000 increments and decrements. The result was that it performs signifinctly better (twice as much) with garbage collection rather than manual memory allocations. I was expecting better performance but this was way better than i thought.
What this means is that we should definitely proceed with the Garbage Collector based implementation.
Things to do: compare the performance of DSTM in Java vs C and see if there are any significant differences. I would think that the Java implementation might actually perform better than the C one simply because of the better Garbage Management available there.
Another thing to do: write a makefile to do all the compiling and building.
Results
Quick note of the system I was using: Sun One Studio 10 on a Solaris Sparc machine.
Manual Memory Management
1000 Increments and 990 Decrements
RSS (Memory used): 1064 kbytes
Time: 0:00
991000 Increments and 990990 Decrements
RSS (Memory used): 47736 kbytes
Time: 0:15
Garbage Collection
1000 Increments and 990 Decrements
RSS (Memory used): 1728 kbytes
Time: 0:00
991000 Increments and 990990 Decrements
RSS (Memory used): 1792 kbytes
Time: 0:08
Some useful commads that I used
To find out the running processses execution time as well as their memory utilization:-
ps -ly
To compile the code (for every file):-
cc -c test.c
To build the project with garbage collection:-
cc atomic.o locator.o readtable.o thread.o transaction.o contention.o readset.o test.o tobject.o utility.o -lgc -z muldefs -o test
The -z muldefs is to allow for the multiple definition of some global constants, and the -lgc is to load the garbage collector library (this should come AFTER all the source files)
Note: You definitely should create a makefile instead.
Why is Garbage Collection Faster
A couple of articles that might shed some light:-
http://www.memorymanagement.org/faq.html#delete.speed
http://www.memorymanagement.org/faq.html#gc.speed
Good Garbage Collection References:-
http://www.iecc.com/gclist/GC-faq.html
http://www.memorymanagement.org/faq.html
http://www.hpl.hp.co.uk/personal/Hans_Boehm/gc/
Read this paper:-
ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps
posted by Fuad at
12:10 PM
0 Comments:
Post a Comment
<< Home