JDK-8259627 : Potential memory leaks in JVMTI after JDK-8227745
- Type: Bug
- Component: hotspot
- Sub-Component: jvmti
- Affected Version: 16,17
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- Submitted: 2021-01-12
- Updated: 2021-05-12
- Resolved: 2021-01-15
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 16 | JDK 17 |
|---|---|
| 16.0.2Fixed | 17 b06Fixed  |
Related Reports
|
Relates :
|
Description
SonarCloud reports the potential bug:
Potential leak of memory pointed to by 'owned_monitors_list'
...in code like this:
jvmtiError
JvmtiEnv::GetOwnedMonitorInfo(JavaThread* java_thread, jint* owned_monitor_count_ptr, jobject** owned_monitors_ptr) {
...
// growable array of jvmti monitors info on the C-heap
GrowableArray<jvmtiMonitorStackDepthInfo*> *owned_monitors_list =
new (ResourceObj::C_HEAP, mtServiceability) GrowableArray<jvmtiMonitorStackDepthInfo*>(1, mtServiceability);
EscapeBarrier eb(true, calling_thread, java_thread);
if (!eb.deoptimize_objects(MaxJavaStackTraceDepth)) {
return JVMTI_ERROR_OUT_OF_MEMORY;
}
There are other instances, all of them near new blocks added by JDK-8227745.
Comments
|