RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool

[Kevin Walls]

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