RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool
Kevin Walls
kevin.walls at oracle.com
Thu Jan 15 14:18:19 UTC 2015
Hi,
This is a review request for a change in JVMTI, where we os::free() some
objects where we should delete them. The problem was logged against 7,
though it exists up to the present day, below is a diff in current
latest http://hg.openjdk.java.net/jdk9/hs-rt/hotspot
Testing:
I've used a native JVMTI agent to call GetConstantPool() during an
object allocation callback. Memory usage does appear less after the
change, it can be 5-6MB in a trivial testcase with a small number of
allocations monitored, each inoking GetConstantlPool().
(In my test agent the GetConstantPool() call returns a JVMTI error 101
after a fairly short time and a relatively small number of allocations
are monitored.)
If this is OK to submit without testcase that's great. I don't see
other examples of native agents in the standard hotspot tests.
bug
https://bugs.openjdk.java.net/browse/JDK-8035938
diff:
$ hg diff src/share/vm/prims/jvmtiClassFileReconstituter.hpp
diff --git a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp
b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp
--- a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp
+++ b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp
@@ -68,11 +68,11 @@
~JvmtiConstantPoolReconstituter() {
if (_symmap != NULL) {
- os::free(_symmap);
+ delete _symmap;
_symmap = NULL;
}
if (_classmap != NULL) {
- os::free(_classmap);
+ delete _classmap;
_classmap = NULL;
}
}
Thanks
Kevin
More information about the serviceability-dev
mailing list