Memory Low Tour

The runtime library uses the Java memory manager to check whether the used memory exceeds a threshold. Currently a threshold of 85% of the maximum memory granted to the runtime library has been hard-coded. When the threshold is exceeded the runtime library will signal a memory low to all console threads. Threads not associated with a Jekejeke console window are not signalled.

We can distinguish two important modes of a thread. Either a thread is running and executing code. Or a thread is blocking and waiting for an event. To indicate the existence of a signal the runtime library will also interrupt the console threads. This allows for the console threads to escape the blocking. We will demonstrate in the following how both a blocking and non-blocking console thread are signalled memory low.

For the blocking thread we open an additional console window. We simply execute a read statement, which will normally block until the end-user has given some text:

Picture 14: The Blocking Thread

For the non-blocking thread we will compute the factorial via the Peano axioms. The Prolog text for the factorial is given in the appendix.

Picture 15: The Non-Blocking Thread

Each subsequent answer will gradually need more memory to produce its result. Eventually the threshold will be reached and a memory low error will be raised:

Picture 16: Error shown by the First Thread

The runtime library will not bother with determining a victim. The current implementation is such that it will signal all console threads blindly. As a result the second thread will also abort with a memory low error:

Picture 17: Error shown by the Second Thread

Although all console threads are signalled at the same moment, it might take some time until a console thread shows the error message. When a Jekejeke Prolog thread has accepted a signal it will throw the signal as an error. The thread will then first be busy with undoing its data structures and the execution of eventual catch blocks.