2016/04/08

09:30

Actually, my compute machine will need two pass-through values. It will need
to know the current thread along with the variable states.

10:10

I wonder if it would be possible to have random access pack200 files, provided
they are not compressed. It should be possible to expose them as a ZIP file or
archive of sorts. pack200 is rather compact. The uncompressed pack file is
smaller than the JAR also, especially with debugging information removed. If
pack200 is supported, then they can be used as a smaller JAR for example if
it is worth it to.

10:19

As an example, I can add to the ZIP compressor to detect pack200 files and
then the files would be fake ZIPed. When a class or other file is requested
then that will be decoded and handled into an input stream. The ZIP support
would be a part of the JVM binary, but if it supports pack200 then it is
possible that there can be more user space in very constrained systems. For
example, all of the input JARs could be pack200ed and placed in a ROM and
then used that way.

10:41

Correction, it is not the ZIP compressor, but the ZIP archive support which I
currently use for the interpreter for reading ZIPs from the classpath. Having
pack200 supported like this however, would be a nice bonus. For example, on
some systems there might not be enough room for a compressed JAR. However if on
average an uncompressed pack200 is smaller than the JAR, then there will be
considerable space savings. However, this depends on the pack200 format if it
is possible to kludge archive-like access on top of it. If it is viable and
does not require a large amount of memory then I would do it. It is possible
that an alternative format could be developed.

11:18

Need to test the sliding byte window to make sure it operates correctly.

11:24

I also need a way to just run a single test rather than all of them.

13:25

Looks like I run out of memory in my sliding byte window tester.

13:42

I suppose my sliding byte window code is rather horrible since the sliding
window class is full of errors while the arrays are fine.

13:47

Ok, so for the sliding window I will just use my chunked byte buffer. In the
chunked code I will just add an array variant and then I can have array support
later on for a bit.

14:10

So far it looks like my redone and simplified (using the chunked buffer code
now) sliding window code works. However, I believe there are far too many tests
being done on it at once.

14:11

Actually to really test it, I should write double the amount of bytes in it
that way I know the actual sliding works. Although doing it on the base byte
array will be a bit slow.

14:19

And the thing which I like to see is this:

PASS extraio.inflater@d

This means my inflater woes were caused by the sliding window code. So I
suppose this means that I no longer need to use the -0 flag when running the
tests and such.

14:22

I should make sure that the interpreter tests can run with the new sliding
window code. The classes I load should be read correctly, hopefully. I must
now remove all of the debug printing stuff.

14:25

Seems my inflate code is somewhat slow. I could speed it up in the future
however.

14:36

To make the inflate decompression faster, the following needs to happen:

Support bulk operations in the sliding window and chunk buffers so that
many calls are not made to access buffer data using single bytes at a time.