Reported by Carl Ritson on the researchers mailing list:
For debugging I recently wrote a test that endless creates and
terminates threads (attached as ThreadTest3.java). This test
consistently crashes JikesRVM after about 450,000 threads have been
created. The crash occurs when pthread_create fails due to a lack of
resources, or as it turns out, a lack of memory.
Digging around in sys.C it seems some allocation is done with C++
primitives (new/delete) and the rest with malloc/free. There doesn't
appear to be an obvious reason for this.
There also seem to be two distinct memory leaks:
1. the memory allocated for the parameters passed to the new thread
via pthread_create is not freed.
2. the signal handling stack can be allocated twice, once by
sysThreadStartup and once by sysSetupHardwareTrapHandler; however,
only the stack allocated by sysThreadStartup will be release when a
Attached is a patch which attempts to address these issues with
(mostly) minimal changes:
A. uses of new/delete are replaced with malloc/free.
B. all calls to malloc/free pass via (existing) checking functions to
check for address space overlaps.
C. thread parameters are releases at thread termination.
D. thread termination checks for the presence of an alternate signal
stack and release it if present.
For (2)/(D) I suspect that the signal stack should only be allocated
once by sysThreadStartup and not by sysSetupHardwareTrapHandler.
However I haven't fully investigated what the separation of concerns
between these methods should be.
With these changes memory leakage appears to have stopped for the test code.