API to release JVM resources

[hrj]

This API might be useful for long running apps (but see question below).

Before closing() the JS heap size is about 250 MB. After closing(), it becomes 10MB (most of this residual 10MB is browser native data, such as JIT compiled JS code, etc).

---

Question: Is the JVM instance automatically retained by doppio in some global context. Ideally, the close() API shouldn't be required, because when the JVM instance becomes unreachable, the resources it holds should also become unreachable.

[jvilk]

While I'm OK with this change, it should not be necessary, as the resources should free once the JVM is garbage collected.

One possibility is that a callback is registered somewhere that closes over the JVM instance, perhaps in a native method. If you take a heap snapshot in Chrome, it should show you the GC roots of where the JVM instance is still referenced from!

[hrj]

The JVM instance seems to be held by this piece of code in jvm.ts:

    // Perform bootup tasks, and then trigger the callback function.
    util.asyncSeries(bootupTasks, (err?: any): void => {
      // XXX: Without setImmediate, the firstThread won't clear out the stack
      // frame that triggered us, and the firstThread won't transition to a
      // 'terminated' status.
      setImmediate(() => {
        if (err) {
          this.status = JVMStatus.TERMINATED;
          cb(err);
        } else {
          this.status = JVMStatus.BOOTED;
          cb(null, this);
        }
      });
    });

I am not able to wrap my head around this. The bootup tasks are created in the constructor, some of which refer to this in complicated ways. Is it possible that the garbage collector gets confused when the chain of references is too long / complex? I definitely am confused by it :)

---

I have a hunch this has something to do with ThreadPool.emptyCallback. I am investigating it.

[hrj]

Superseded by #436