Request for Review (XS): 7143760 Memory leak in GarbageCollectionNotifications

[David Holmes]

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
>>
>
>