P4
JNI handle blocks are allocated on the (infrequent) VM->Java transition, and the handle block is simply reset on the (frequent) Java->Native transistion.
Currently, the interpreter and C1 and C2 resets the handle block on entry to the native method. This is not incorrect, but all local JNI handles allocated during the native call are kept alive until the next native call entry (which may never occur), so this could be a substantial memory leak.
Instead, the interpreter and C1 and C2 should reset the the handles block on exit from the native call. It would probably be a good idea to add verification code checking that the handle block is indeed reset on native method entry.
Grep for JNIHandleBlock::top_offset_in_bytes to see all usages.
I assigned this to the interpreter category, please reassign to C1 and C2 before marking as fixed.
steffen.grarup@eng 2000-10-23
Currently, the interpreter and C1 and C2 resets the handle block on entry to the native method. This is not incorrect, but all local JNI handles allocated during the native call are kept alive until the next native call entry (which may never occur), so this could be a substantial memory leak.
Instead, the interpreter and C1 and C2 should reset the the handles block on exit from the native call. It would probably be a good idea to add verification code checking that the handle block is indeed reset on native method entry.
Grep for JNIHandleBlock::top_offset_in_bytes to see all usages.
I assigned this to the interpreter category, please reassign to C1 and C2 before marking as fixed.
steffen.grarup@eng 2000-10-23