assets/developer-notes/stephanie-gawroriski/2016/04/08.mkd

   1 # 2016/04/08
   2
   3 ## 09:30
   4
   5 Actually, my compute machine will need two pass-through values. It will need
   6 to know the current thread along with the variable states.
   7
   8 ## 10:10
   9
  10 I wonder if it would be possible to have random access pack200 files, provided
  11 they are not compressed. It should be possible to expose them as a ZIP file or
  12 archive of sorts. pack200 is rather compact. The uncompressed pack file is
  13 smaller than the JAR also, especially with debugging information removed. If
  14 pack200 is supported, then they can be used as a smaller JAR for example if
  15 it is worth it to.
  16
  17 ## 10:19
  18
  19 As an example, I can add to the ZIP compressor to detect pack200 files and
  20 then the files would be fake ZIPed. When a class or other file is requested
  21 then that will be decoded and handled into an input stream. The ZIP support
  22 would be a part of the JVM binary, but if it supports pack200 then it is
  23 possible that there can be more user space in very constrained systems. For
  24 example, all of the input JARs could be pack200ed and placed in a ROM and
  25 then used that way.
  26
  27 ## 10:41
  28
  29 Correction, it is not the ZIP compressor, but the ZIP archive support which I
  30 currently use for the interpreter for reading ZIPs from the classpath. Having
  31 pack200 supported like this however, would be a nice bonus. For example, on
  32 some systems there might not be enough room for a compressed JAR. However if on
  33 average an uncompressed pack200 is smaller than the JAR, then there will be
  34 considerable space savings. However, this depends on the pack200 format if it
  35 is possible to kludge archive-like access on top of it. If it is viable and
  36 does not require a large amount of memory then I would do it. It is possible
  37 that an alternative format could be developed.
  38
  39 ## 11:18
  40
  41 Need to test the sliding byte window to make sure it operates correctly.
  42
  43 ## 11:24
  44
  45 I also need a way to just run a single test rather than all of them.
  46
  47 ## 13:25
  48
  49 Looks like I run out of memory in my sliding byte window tester.
  50
  51 ## 13:42
  52
  53 I suppose my sliding byte window code is rather horrible since the sliding
  54 window class is full of errors while the arrays are fine.
  55
  56 ## 13:47
  57
  58 Ok, so for the sliding window I will just use my chunked byte buffer. In the
  59 chunked code I will just add an array variant and then I can have array support
  60 later on for a bit.
  61
  62 ## 14:10
  63
  64 So far it looks like my redone and simplified (using the chunked buffer code
  65 now) sliding window code works. However, I believe there are far too many tests
  66 being done on it at once.
  67
  68 ## 14:11
  69
  70 Actually to really test it, I should write double the amount of bytes in it
  71 that way I know the actual sliding works. Although doing it on the base byte
  72 array will be a bit slow.
  73
  74 ## 14:19
  75
  76 And the thing which I like to see is this:
  77
  78         PASS extraio.inflater@d
  79
  80 This means my inflater woes were caused by the sliding window code. So I
  81 suppose this means that I no longer need to use the -0 flag when running the
  82 tests and such.
  83
  84 ## 14:22
  85
  86 I should make sure that the interpreter tests can run with the new sliding
  87 window code. The classes I load should be read correctly, hopefully. I must
  88 now remove all of the debug printing stuff.
  89
  90 ## 14:25
  91
  92 Seems my inflate code is somewhat slow. I could speed it up in the future
  93 however.
  94
  95 ## 14:36
  96
  97 To make the inflate decompression faster, the following needs to happen:
  98
  99  * Support bulk operations in the sliding window and chunk buffers so that
 100    many calls are not made to access buffer data using single bytes at a time.
 101