X-Git-Url: https://git.llucax.com/personal/website.git/blobdiff_plain/026ddd134c2a47ab83069548c56f2e3d4cc04464..5a226a8f0e5cb4e134ee7aa9f86dfd4281049bc2:/source/blog/posts/2010/09/09-truly-concurrent-gc-using-eager-allocation.rst

diff --git a/source/blog/posts/2010/09/09-truly-concurrent-gc-using-eager-allocation.rst b/source/blog/posts/2010/09/09-truly-concurrent-gc-using-eager-allocation.rst
index c83da26..aa58a03 100644
--- a/source/blog/posts/2010/09/09-truly-concurrent-gc-using-eager-allocation.rst
+++ b/source/blog/posts/2010/09/09-truly-concurrent-gc-using-eager-allocation.rst
@@ -6,7 +6,7 @@ collection, in the sense that all the threads of the *mutator* (the program
 itself) can run in parallel with the collector (well, only the mark phase to be
 honest :).
 
-__ https://llucax.com.ar/blog/blog/tag/cdgc?sort=+date
+__ /blog/blog/tag/cdgc?sort=+date
 
 You might want to read a `previous post`__ about CDGC where I achieved some sort
 of concurrency by making only the *stop-the-world* time very short, but the
@@ -17,7 +17,7 @@ allocation request (it was triggered because the memory was exhausted), while
 any other thread needing any GC service needed to acquire the global GC lock
 (damn global GC lock!).
 
-__ https://llucax.com.ar/blog/blog/post/-4c9dd5b5
+__ /blog/blog/post/-4c9dd5b5
 
 To avoid this issue, I took a simple approach that I call *eager allocation*,
 consisting on spawn the mark phase concurrently but allocating a new memory pool
@@ -211,7 +211,7 @@ voronoi get a **30% speed boost**! That's not bad, not bad at all...
 If you want to try it, the repository__ has been updated with this last changes
 :). If you do, please let me know how it went.
 
-__ https://git.llucax.com.ar/w/software/dgc/cdgc.git
+__ https://git.llucax.com/w/software/dgc/cdgc.git
 
 
 .. vim: set et sw=3 sts=3 :