SquirrelJME/SquirrelJME

# 2016/05/31

## 08:08

Thinking about it, package is probably better called module so it does not
conflict with the meaning of Java's package.

## 08:42

Next thing to do is to start the IPC that the launcher will use to control
the kernel. Then following that is starting the actual launcher. Then once
the launcher is started, it will then start the main program if one was
requested.

## 09:52

The process and thread list would likely best be an `ArrayList` so that
when processes or threads are looked up by their ID, they can used a binary
search instead of a linear search.

## 09:57

I must disallow thread and process IDs of zero.

## 10:25

Each process can have its own `KernelIPCAlternative`. This would simplify
the implementation and would also remove the need to have a single lock for
every socket that exists. This way when there are many threads communicating
with each other, they do not have to block each other.

## 10:32

When it comes to the sockets, they can be shared between different
alternatives. So for example when one alternative connects to another, they
both just have a single `KernelIPCSocket` which they share for communication
between each other. One issue however are the socket ID numbers, they would
need to handle having multiple IDs depending if they are the client or the
server. However, technically the socket IDs are only needed with cross
communication. There are also 2 billion socket IDs available. For simplicity
the client and server can share the same socket ID. However, each side needs
its own receive and send buffers anyway. Also sharing IDs could cause
confusion when it comes to the side which is receiving its data. So as a rule,
the sockets cannot have the same handle number used on the client or server.

## 10:43

Then the server itself for server sockets and just use a new `KernelIPCServer`
since servers do not have any send or receive logic at all. Then I need an
interface which will handle the client and server handles.

## 10:52

Actually the connected socket does not even need to know if its a client or
server, it just needs to know if it is primary or secondary socket.

## 14:07

Thinking about it, having primary and secondary IDs for sockets could be a bit
confusing. I could limit the total number of sockets to 32,768 although that
would be a bit bad. It would just be simpler for the client sockets to instead
use a single identifier.

## 14:12

Having the primary and secondary identifiers would also complicate things when
processes are removed as there would be a shared set of handles which can
cause issues if lots of sockets are created.

## 14:23

Also, duplicating the identifier generation code for the third time, so it
becomes a class now.

## 14:51

An idea to have so that socket read operations do not block forever, would be
to have a sleep in them for the amount of time left for reading, but when data
is received there could be an interrupt of sleep performed. However, this would
affect everything that sleeps even when it is not waiting on the data.
Alternatively the best choice would be to always return immediately. In general
most users and myself would want non-blocking sockets for IPC since that is
in the general case faster, although the locks can be a bit spinny.

## 16:21

Actually what I can do is after a server socket is connected, the server can
be closed. If the clients remain connected without being closed when the server
closes means that I only have to accept once and not have a accept closing
means. If a client connects and the server closes the socket before a connect
happens then the connection would just fail. Also for clearing I will need a
not a socket kind of thing to occur. Alternatively if a socket does not exist
the returned error code could be connection refused or just connection closed.
So if the user-space tries a raw socket read of a random socket number it will
just report it as closed. The only issue with this is that the client could
open 2 billion sockets, close a very early one which is then reused on
overflow. To the kernel this should have no effect, but to the running
userspace program things could get weird.

## 16:46

So the question is now, how do I want to handle setting up the interpreter so
that processes and then threads can be created for execution? Each created
instance of the interpreter should act as its own process since each
process needs to be garbage collected and such. There also has to be hooks to
the kernel potentially so that garbage collection can be performed and such.
However, there is one major difference between the standard interpreter and
the rerecording one. The standard interpreter can just use the host garbage
collector and references for the most part. The rerecording one will have to
keep the objects ordered and have garbage collection performed at known
locations such as when `System.gc()` is called or when memory is expired. I
would suppose there would be two kinds of garbage collection. `System.gc()`
would only touch objects which have no references to them at all, but will
keep `WeakReference`. A full one could remove `WeakReference`es also. However
this may complicate things so it might be best to just have a single garbage
collector. This GC would be stop everything since it makes sense. The GC could
affect all objects within the execution engine. So then the kernel class which
is currently just Object for the execution engine should be an interface
instead which has stuff such as garbage collection.

## 18:11

I have this idea to write simulators to test the system. Another idea I have is
writing hypervisors so native code can be run. I could have for example a
virtual machine of sorts running. I do wonder though about the Nintendo 64.
Since it uses MIPS and that is Pompek and Goldberg capable (it should be
anyway) it might be possible to do synchronized online multiplayer N64 gaming.

## 20:27

The 64Drive allows write access to the cartridge ROM, the 64Drive is also 64MiB
in size. So this means that any unused ROM area could be used as extra RAM.

## 22:35

The month is almost over. I will have to do a synopsis of what has been done
over this current month. The past week or more I have been getting in more
commits. I suppose a better sleep cycle works wonders when programming. I still
do not have an interpreter yet however. But with the multiple refactors the
code is far cleaner than what it would have been. It would also work much
better compared to before. So generally there has been a great improvement.
I did implement manifests and PNG support however. But the major thing that
occured was that the code is now much cleaner and much better.