JDK-8249822 : SymbolPropertyTable creates an extra OopHandle per entry
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-07-21
  • Updated: 2022-12-01
  • Resolved: 2020-07-24
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.
JDK 16
16 b08Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
  SymbolPropertyEntry* new_entry(unsigned int hash, Symbol* symbol, intptr_t symbol_mode) {
    SymbolPropertyEntry* entry = (SymbolPropertyEntry*) Hashtable<Symbol*, mtSymbol>::new_entry(hash, symbol);
    // Hashtable with Symbol* literal must increment and decrement refcount.
    symbol->increment_refcount();
    entry->set_symbol_mode(symbol_mode);
    entry->set_method(NULL);
    entry->set_method_type(NULL);
    return entry;
  }

Since the SymbolPropertyEntry constructor isn't called, the fields need to be explicitly zeroed.

void SymbolPropertyEntry::set_method_type(oop p) {
  _method_type = OopHandle(OopStorageSet::vm_global(), p);
}

set_method_type creates a new OopHandle for NULL.  There's an test when it's called in SystemDictionary that the value of the oop is NULL but not that the entry is_empty(), so there we call this again and create another OopHandle.

I found this because I also added an assert to the assignment operator to prevent leaking OopHandles.  This was [~eosterlund] 's idea from reviewing JDK-8249768 (which doesn't leak OopHandles).
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/a36b9f6adbf2 User: coleenp Date: 2020-07-24 11:46:42 +0000
24-07-2020