vmkit: JIT function stubs exhausted

[edwintorok]

Bugzilla Link	3084
Version	unspecified
OS	Linux
Depends On	#3455

Extended Description

Attached testcase.

~/project/llvm-svn/vmkit/Release/bin/jnjvm Invoker
JIT ran out of memory for function stubs!
Aborted

Why this is important: when you run an application server and redeploy a .war/.ear multiple times, often memory is leaked.
Sun's JVM runs out of Permgen space after 36 iterations, VMKit runs out of function stubs.

VMKit could do better and not run out of memory :)

[llvmbot]

Well, how is stub memory leaked? Are you freeing both code and stub memory regions associated with dead functions?

[edwintorok]

Well, how is stub memory leaked? Are you freeing both code and stub memory
regions associated with dead functions?

"leak" may not be the correct term here, see #​3083 for the real issue.

The problem is that if many classes with many methods are loaded by vmkit, without running the garbage collector [], at some point the memory for stubs is exhausted. Then LLVM simply dies.
A better solution (instead of dieing), would be to call VMKit, and tell it to free as many stubs as it can (i.e. run the garbage collector []), and then hopefully there will be memory left to create more stubs.

If it is still unable to create more stubs, VMKit could throw a Java OutOfMemoryError, instead of dieing.

For the particular case in my testcase, VMKit could free the classloader, and all code+stub of classes loaded by that, because the classloader is not used outside the loop (and a new one is created at each iteration).
Currently it can't do that (well it could try to garbage collect at each iteration, but that would incur too much overhead probably).

[*] I assume that VmKit's garbage collector will garbage collect unused classloaders, and then it will free the code+stub of each method of each class loaded by that classloader.
The problem in Sun's JVM is that classes can be referenced by classes loaded by other classloaders, and thus even if the classloader is unused, it can't be freed, because a class it has loaded is still being referenced, and if the classloader is still there all other classes's code remains there.

[llvmbot]

Yes, some kind of callback would be desirable. So that the VM knows it's running out of memory on the jit side. Maybe the allocationFunctionStub could just return 0.

[llvmbot]

Yes, some kind of callback would be desirable. So that the VM knows it's
running out of memory on the jit side. Maybe the allocationFunctionStub could
just return 0.

It would be a good idea to have a virtual function in JITMemoryManager class called by allocStub(), make the DefaultJITMemoryManager visible, and then inherit from it and override this method with a cleanup or registered callback method.

Aaron