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.