The memory monitor can be invoked from within the development environment. The memory usage pattern highly depends on the JVM. Supposed the class path is correctly set, the easiest to start the memory monitor is to first consult the Prolog text ‘memory.p’. The memory monitor can then be invoked by the predicate start_monitor:
?- ['jekdev/study/memory/memory.p']. Yes ?- start_monitor. Yes
The typical memory usage pattern when the system is idle can be seen below. The system will consume memory objects by the frame thread itself. These memory objects will slowly eat up the memory until a larger garbage collection happens. The slope of the saw tooth depends on the effectiveness of the smaller garbage collections. The frequency of the saw tooth depends on the trigger condition for the larger garbage collection. Further 64-bit architectures might use more memory than 32-bit architectures.
Picture 3: System Idle Memory Usage Pattern
We might now run a little test and verify the memory low alarm of Jekejeke Prolog. On both the Swing platform the runtime library and the development environment install a usage threshold. On the Android platform we have not yet figured out how to implement the threshold. We will run the factorial and look at the memory usage pattern. The threshold is 85% of the total memory. For a total memory of 512 m Bytes this amounts to 435 m Bytes.
We have run the following query:
?- fac(X,_). X = n ; X = s(n) ; X = s(s(n)) ; X = s(s(s(n))) ; X = s(s(s(s(n)))) ; X = s(s(s(s(s(n))))) ; X = s(s(s(s(s(s(n)))))) ; X = s(s(s(s(s(s(s(n))))))) ; X = s(s(s(s(s(s(s(s(n)))))))) ; X = s(s(s(s(s(s(s(s(s(n))))))))) ; Error: Execution aborted since memory threshold exceeded. add / 3 add / 3 mul / 3 mul / 3 mul / 3 mul / 3 mul / 3 mul / 3 fac / 2
Picture 4: Memory Low Alarm Memory Usage Pattern
The above picture shows the memory usage pattern before and after the memory low alarm. All the queries for factorial do not use much more memory than 100 m Bytes up to the factorial of 8. The query for the factorial 9 then goes through the roof. Since the frame thread granularity is relatively low, we do not exactly see the peek that causes alarm. After the alarm the smaller garbage collections have already return some memory. But the system will remain with a high memory usage until a large garbage collection turns in.
In case there is no more use for the memory monitor the frame can simply be closed. It is also possible to first close the development environment. The memory monitor frame will then not automatically close, since we did not register with some event from the development environment. The JVM will only organically exit when all frames from the development environment have been closed and the memory monitor has been closed as well.