assets/developer-notes/stephanie-gawroriski/2017/02/24.mkd

   1 # 2017/02/24
   2
   3 ## 12:11
   4
   5 One thing I will need to consider is garbage collection. I want a good and
   6 simple garbage collector, but one which does not add complication and is not
   7 slow. I also want to potentially avoid having safe zones for threads to park
   8 when GC is happening. I want to avoid reference counting. I also want to
   9 avoid scanning the stack and register values for objects.
  10
  11 ## 17:03
  12
  13 The non-bootstrap JARs in the target should be in their own directory. This
  14 would have far better results because I could potentially add third party
  15 JARs and such.
  16
  17 ## 17:49
  18
  19 I do wonder how I will implement the `StreamProcessor` along with the
  20 supporting the helper classes needed for inflating compressed data.
  21
  22 ## 18:07
  23
  24 I will need a simple but efficient stream processor.
  25
  26 ## 18:09
  27
  28 I suppose a direct approach will work. Basically the `StreamProcessor` reads
  29 input bytes and stores them somewhere after they are processed. So the class
  30 then will just purely be for reading. The output stream can just be mapped
  31 similarly.
  32
  33 ## 18:21
  34
  35 Actually, from `StreamProcessor` and `StreamProcessorInputStream` I am going
  36 to have the same code or just wrapped code. Read from some source and do stuff
  37 with it.
  38
  39 ## 19:01
  40
  41 Ok so I have been thinking, `StreamProcessor` is a bad idea. It will just
  42 complicate things and right now only two classes will use it, for inflate and
  43 deflate. Also in the most common cases, one will never `OutputStream` inflate
  44 and `InputStream` deflate. So there is not much point in having these classes
  45 at all. The stream processing is just over engineered and will just complicate
  46 the implementation greatly.