On 10/02/2012 7:59 PM, Dmitry Samersoff wrote:
Frederic,
GCNotificationRequest *request = getRequest();
request variable also leaks memory because it will never be deleted on
CHECK return path. Could you fix it too?
Further:
211 JavaCalls::call_virtual(&result,
212 gc_mbean_klass,
213 vmSymbols::createGCNotification_name(),
214
vmSymbols::createGCNotification_signature(),
215 &args,
216 CHECK);
217 if (HAS_PENDING_EXCEPTION) {
218 CLEAR_PENDING_EXCEPTION;
219 }
220
221 delete request;
The CHECK at @216 will cause a return if there is an exception pending
so 217-219 is dead code. This also indicates some confusion about what
exceptions this method can leave pending. Or it may be that the CHECK at
#216 was meant to be just THREAD. ??
(Strange this is the second example I've seen of this today!)
David
-Dmitry
On 2012-02-10 13:27, Frederic Parain wrote:
Here's a small fix (one line) for CR 7143760 Memory leak in
GarbageCollectionNotifications
There's a missing HandleMark at the beginning of the
GCNotifier::sendNotificatin() method. Without this HandleMark, all
handles used when creating GC notifications are kept alive causing a
double leak: in the Java heap and in the thread local handle area of the
service thread.
Here's the CR:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7143760
(Warning, the changeset referenced in the CR is not the
one containing the original bug).
Here's the webrev:
http://cr.openjdk.java.net/~fparain/7143760/webrev.00/
Thanks,
Fred
