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:
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.
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:
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:
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.