Add some missing posts

[personal/website.git] / 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 3bab03aca4f473733bb2d6e09c6d2e664a7b2ec3..aa58a03b046bb8d88d4792986023e5a098b479aa 100644 (file)
--- 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 :).
 
-__ http://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!).
 
-__ http://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.
 
-__ http://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 :