More https fixes

[personal/website.git] / source / blog / posts / 2010 / 08 / 14-memory-allocation-patterns.rst

diff --git a/source/blog/posts/2010/08/14-memory-allocation-patterns.rst b/source/blog/posts/2010/08/14-memory-allocation-patterns.rst
index e2a58271730c883543181cae3b844cbb53d97dac..c8d344245c4566e1a5f2c1c8c3ef61741df5e7fc 100644 (file)
--- a/source/blog/posts/2010/08/14-memory-allocation-patterns.rst
+++ b/source/blog/posts/2010/08/14-memory-allocation-patterns.rst
@@ -27,13 +27,13 @@ affected by changes like `memory addresses returned by the OS`__ or by
 some information about how much and what kind of memory are requested by the
 different benchmarks.
 
-__ http://www.llucax.com.ar/blog/blog/post/-7a56a111
-__ http://www.llucax.com.ar/blog/blog/post/1490c03e
+__ https://www.llucax.com.ar/blog/blog/post/-7a56a111
+__ https://www.llucax.com.ar/blog/blog/post/1490c03e
 
 I used the information provided by the ``malloc_stats_file`` CDGC__ option, and
 generated some stats.
 
-__ http://www.llucax.com.ar/blog/blog/post/-2c067531
+__ https://www.llucax.com.ar/blog/blog/post/-2c067531
 
 The analysis is done on the allocations requested by the program (calls to
 ``gc_malloc()``) and contrasting that with the real memory allocated by the GC.
@@ -58,7 +58,7 @@ of the blocks). So the idea here is to measure two major things:
 * The extra amount of memory wasted by the GC when using precise mode because it
   stores the type information pointer at the end of the blocks.
 
-__ http://www.llucax.com.ar/blog/blog/post/250bf643
+__ https://www.llucax.com.ar/blog/blog/post/250bf643
 
 I've selected a few representative benchmarks. Here are the results: