-
Bug
-
Resolution: Fixed
-
P3
-
8u92, 9
-
b124
-
generic
-
os_x
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8183736 | 8u161 | Anton Tarasov | P3 | Resolved | Fixed | b01 |
JDK-8166360 | 8u152 | Anton Tarasov | P3 | Resolved | Fixed | b01 |
JDK-8192473 | emb-8u161 | Anton Tarasov | P3 | Resolved | Fixed | b01 |
A JNI local is generally deleted when:
1) the JNI method returns
2) it's wrapped in PushLocalFrame/PopLocalFrame calls
3) DeleteLocalRef is called
The problem is that a JNI local can be created inside an endless message pump (then the 1st point doesn't work), or out of the push/pop block (2nd doesn't work). Then the only way to avoid its leaking is to delete it manually.
(For instance, seeJDK-8145984 where missed JNI locals caused memory leaks.)
There're two more JNI locals to delete:
- AWTWindow.m, sendEvent: platformWindow
- CGraphicsEnv.m, displaycb_handle: graphicsEnv
1) the JNI method returns
2) it's wrapped in PushLocalFrame/PopLocalFrame calls
3) DeleteLocalRef is called
The problem is that a JNI local can be created inside an endless message pump (then the 1st point doesn't work), or out of the push/pop block (2nd doesn't work). Then the only way to avoid its leaking is to delete it manually.
(For instance, see
There're two more JNI locals to delete:
- AWTWindow.m, sendEvent: platformWindow
- CGraphicsEnv.m, displaycb_handle: graphicsEnv
- backported by
-
JDK-8166360 [macosx] two JNI locals to delete in AWTWindow.m, CGraphicsEnv.m
-
- Resolved
-
-
JDK-8183736 [macosx] two JNI locals to delete in AWTWindow.m, CGraphicsEnv.m
-
- Resolved
-
-
JDK-8192473 [macosx] two JNI locals to delete in AWTWindow.m, CGraphicsEnv.m
-
- Resolved
-