source/proj/dgc/bugs.csv

   1 #,Status,Project,Tracker,Priority,Subject,Assigned to,Category,Target version,Author,Start,Due date,% Done,Estimated time,Created,Updated,Severity,Description
   2 50,New,D Garbage Collector Research,Task,Normal,Fix List.opApply() to be able to support removal of the head of the list,Leandro Lucarella,"","",Leandro Lucarella,05/15/2009,"",0,"",05/15/2009 12:13 am,05/15/2009 12:13 am,Major,List.opApply() is supposed to work even when nodes are removed in the loop. But there is a bug that break the list if the first node is removed.
   3 49,Done,D Garbage Collector Research,Task,Normal,Write a trivial but fully working GC,Leandro Lucarella,"","",Leandro Lucarella,04/11/2009,04/27/2009,100,50.0,04/18/2009 05:49 pm,04/27/2009 12:21 am,Minor,"The idea is:\r
   4 \r
   5 # Improve my understanding about how a GC is written from the ground up\r
   6 # Ease the learning curve for other people wanting to learn how to write a D GC\r
   7 # Serve as documentation (will be fully documented)\r
   8 # Serve as a benchmarking base (to see how better is an implementation compared to the dumbest and simplest implementation ever =)\r
   9 \r
  10 There is a lot of literature on GC algorithms, but there is almost no literature of the particularities on implementing a GC in D (how to handle the stack, how finalize an object, etc.). The idea of this GC implementation is to tackle this. The collection and allocation algorithms are really simple so you can pay attention to the other stuff."
  11 47,New,D Garbage Collector Research,Task,Low,See if getting rid of the commit()/decommit() stuff improves Linux performance,Leandro Lucarella,"","",Leandro Lucarella,05/23/2009,"",0,"",04/10/2009 02:35 am,04/10/2009 02:35 am,Minor,"See ""Understanding the current GC, part III"":https://llucax.com/blog/blog/post/-243ec069 for details."
  12 46,New,D Garbage Collector Research,Task,Normal,Rewrite the current GC implementation,Leandro Lucarella,"","",Leandro Lucarella,05/09/2009,"",0,"",04/09/2009 09:43 pm,04/09/2009 09:43 pm,Minor,The current GC implementation is much more complex than it should be. A complete rewrite maintaining all the current design should not be too hard to do.
  13 45,New,D Garbage Collector Research,Task,High,Review the cloning and very concurrent GC papers,Leandro Lucarella,"","",Leandro Lucarella,04/11/2009,04/12/2009,0,4.0,04/05/2009 03:24 am,04/09/2009 09:57 pm,Major,"I have already read the papers ""Nonintrusive Cloning Garbage Collector with Stock Operating System Support"":http://www.cs.purdue.edu/homes/grr/snapshot-gc.ps and ""Very Concurrent Mark-&-Sweep Garbage Collection without Fine-Grain Synchronization"":http://doc.cat-v.org/inferno/concurrent_gc/.\r
  14 \r
  15 A combination of this 2 papers is what I'm most interested in implement so far, I have to write a better plan and description about what I want to do."
  16 44,New,D Garbage Collector Research,Task,Low,See how hard could it be to implement a precise GC in LDC,Leandro Lucarella,"","",Leandro Lucarella,05/09/2009,"",0,"",04/05/2009 03:18 am,04/05/2009 03:58 am,Major,"A simple approximation to a precise GC is explained in the paper ""Accurate Garbage Collection in an Uncooperative Environment"":https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.5570 (see the ""blog post"":https://llucax.com/blog/blog/post/-1ac779b for more info).\r
  17 \r
  18 Another simple approach is to use a _pinning flag_ to mark objects that can be moved (this should happen when a pointer to the object is stored in the stack, registers or any other memory that don't have type information available, or ambiguous, like unions). Heap objects should have type information available.\r
  19 \r
  20 This open the doors to moving GCs."
  21 43,New,D Garbage Collector Research,Task,Low,See how hard could be to implement read/write barriers in LDC,Leandro Lucarella,"","",Leandro Lucarella,05/09/2009,"",0,"",04/05/2009 03:06 am,04/05/2009 03:58 am,Major,"Having read/write barriers as part of the runtime can be very useful for, for example, gather statistics on how frequent are pointers updates to analyze how bad it could be for a reference counting or incremental/generational collectors (and to actually implement them).\r
  22 \r
  23 Some information is available in this ""LDC mailing list thread"":http://groups.google.com/group/ldc-dev/browse_thread/thread/ad305b6ad8e7f443."
  24 42,New,D Garbage Collector Research,Task,Normal,Optimize the current GC implementation,Leandro Lucarella,"","",Leandro Lucarella,05/09/2009,"",0,"",04/05/2009 02:58 am,04/11/2009 01:38 pm,Major,"There should be some optimization opportunities in the current GC implementations, as shown in this ""blog post"":https://llucax.com/blog/blog/post/7bdad55d.\r
  25 \r
  26 Profiling the GC can be a good start point for looking at optimization opportunities."
  27 41,Done,D Garbage Collector Research,Task,Immediate,Finish the current GC implementation analysis,Leandro Lucarella,"","",Leandro Lucarella,04/05/2009,04/10/2009,100,18.0,04/05/2009 02:55 am,04/11/2009 01:51 am,Major,"The blog post ""Understanding the current GC"":https://llucax.com/blog/blog/post/250bf643 describes how the heap and GC structures are organized in the current GC implementation, but there is no analysis on the allocation, marking and sweeping phases."
  28 40,New,D Garbage Collector Research,Task,Normal,Plug Boehm-Demers-Weiser GC into D,Leandro Lucarella,"","",Leandro Lucarella,05/09/2009,"",0,"",04/05/2009 02:50 am,04/05/2009 03:58 am,Major,"""Boehm-Demers-Weiser Conservative Garbage Collector"":http://www.hpl.hp.com/personal/Hans_Boehm/gc/ is one of the most optimized, state of the art conservative collector, with optional parallel marking (to allow preemptive incremental collection).\r
  29 \r
  30 This collector is usually a point of comparison for any conservative collector, and it could be very nice to know how the current (and future) GC implementation(s) for D performs comparing to it."
  31 39,Assigned,D Garbage Collector Research,Task,Urgent,Make the GC able to gather some statistics,Leandro Lucarella,"","",Leandro Lucarella,05/01/2009,"",10,"",04/05/2009 02:35 am,05/01/2009 09:14 pm,Blocker,"In order to do benchmarks, it should be possible to get statistics about the GC performance.\r
  32 \r
  33 Some values that are usually used to measure a GC performance include:\r
  34 * Size of the heap requested by the program\r
  35 * Effective size of the heap (to measure the GC size overhead)\r
  36 * Pause time for each collection\r
  37 * Maximum collection pause time\r
  38 * Total collection pause time"
  39 38,New,D Garbage Collector Research,Task,Low,Make LDC phobos compatible,Leandro Lucarella,"","",Leandro Lucarella,04/18/2009,"",0,40.0,04/05/2009 01:06 am,04/27/2009 12:23 am,Major,"The situation in D ecosystem is really bad because of the ""Tango"":http://www.dsource.org/projects/tango vs. ""Phobos"":http://www.dsource.org/projects/phobos situation. It's already hard enough to find updated working programs written in D to just limit to either library.\r
  40 \r
  41 There are 2 ways to add ""LDC"":http://www.dsource.org/projects/ldc Phobos compatibility:\r
  42 # Making ""Tangobos"":http://www.dsource.org/projects/tangobos compatible with LDC (*easier*, have some ""incompatibilities"":http://www.dsource.org/projects/tangobos#Usage)\r
  43 # Making LDC use ""druntime"":http://www.dsource.org/projects/druntime as the runtime library and making both Phobos and Tango druntime compatible (*harder*, preferred)"
  44 37,Assigned,D Garbage Collector Research,Task,Urgent,Make a D GC benchmark suite,Leandro Lucarella,"","",Leandro Lucarella,05/01/2009,"",20,"",04/05/2009 12:56 am,05/01/2009 09:16 pm,Critical,"A benchmark suite is *essential* tool to quantify any improvement to the D GC.\r
  45 \r
  46 The benchmark suite have to be complete, including both trivial programs that let you see how the GC performs for a very specific problem, and _big_ real-world programs that let to see how the GC performs in the real world.\r
  47 \r
  48 For this benchmarks, some metrics should be collected, including:\r
  49 * Total program run time\r
  50 * Total program run time disabling the GC (to measure an approximation to the GC time overhead)\r
  51 * Size of the heap requested by the program\r
  52 * Effective size of the heap (to measure the GC size overhead)\r
  53 * Pause time for each collection\r
  54 * Maximum collection pause time\r
  55 * Total collection pause time\r
  56 \r
  57 See the ""D GC Benchmark Suite"":https://llucax.com/blog/blog/post/-1382f6a3 blog post for more details."