Memory management: unlimited solution with thread state persistence

At Problem section we stated:

We have specified the problem, next sections explain the solution. Our problem does not have only one possible solution. Actually, we have found two kinds of solutions:

• Solutions based on limited access to resources: we establish some limits to users, threads, requests, … in order to ensure that there is no leak.
• Solutions based on unlimited access to resources: we modify our core design, our use cases (dataClay threads, execution classes, models) or which services we provide to ensure that there are no leaks. Each solution must explain how it satisfies each predicate.

Unlimited solution: Thread state persistence

Let’s imagine that one node has no memory available. What should we do? This solution proposes the persistence of the state of the threads. We propose extending the Java virtual machine in order to be able to persist the state of a thread. Also, this extension allows us to stop the thread at any point (loops, …). The idea is to persist the threads whenever is necessary in order to release the resources. Let’s satisfy each predicate explained in The Problem section:

Predicate 1: No memory leak caused by variables kept alive by the stack

Since we will persist the threads, the state of the stack will be also persisted and we will release the stack so the GC will be able to clean those variables.

• Remote executions: Any thread that is waiting for a remote call to finish can be persisted and recovered later. Therefore the memory retained by them is released.
• All memory filled by objects kept alive by stacks: We could persist any thread that is using too much memory in order to allow other threads to work.

Predicate 2: No memory leak caused by alive threads

There will be no leak here since if we have too many threads, we could persist some of them and recover them whenever we want (policies, but that’s another problem, Resource contention).

• Iterative execution: We could persist the threads using too much memory.
• Recursive execution: We could persist the threads waiting. So, this solution solves our problem. However there are many problems:
• The extension of the JVM requires our code to be maintained, for each JVM version and, since the changes must be applied to native code, for each native OS.
• The extension of the JVM could cause security issues.

** This solution was discarded because we do not want to depend on JVM **