Details
-
Type:
Bug
-
Status: Resolved
-
Priority:
P3
-
Resolution: Fixed
-
Affects Version/s: 8u92, 9
-
Fix Version/s: 9
-
Component/s: client-libs
-
Labels:
-
Subcomponent:
-
Resolved In Build:b124
-
CPU:generic
-
OS:os_x
Backports
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8166360 | 8u152 | Anton Tarasov | P3 | Resolved | Fixed | b01 |
| JDK-8183736 | 8u161 | Anton Tarasov | P3 | Resolved | Fixed | b01 |
| JDK-8192473 | emb-8u161 | Anton Tarasov | P3 | Resolved | Fixed | b01 |
Description
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
Attachments
Issue Links
- backported by
-
JDK-8166360 [macosx] two JNI locals to delete in AWTWindow.m, CGraphicsEnv.m
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-