• New Feature
  • Status: Open
  • 2 Major
  • Resolution:
  • interfaces
  • Reporter: steve
  • May 14, 2008
  • 1
  • Watchers: 2
  • December 16, 2011


We might be able to tell that the removed object isn’t going to be used and not retrieve it at all.


Tim Eck 2008-05-14

correct me if this isn’t what you’re talking about…So lets think about the remove(Object) on java.util.Map that returns an Object. If the calling code ignores the return value, we could maybe make a different invocation that would not require faulting the removed object. example:

void foo(Map m, Object key) {
m.remove(key); // return value ignored }

Steve Harris 2008-05-14

Yep, that’s what I’m talking about.

Steve Harris 2008-05-15

tim pointed out that we can’ do the “call another method” approach because of interfaces. We can do some sort of thread local approach (turn off retrief) or wrap the object in a don’t retrieve wrapper, I like the former better.

Fiona OShea 2008-05-15

If we have time to get to it.

Terracotta User 2008-11-19

Could we do the same thing for put? Would that improve performance?

Chris Dennis 2009-02-06

Implementation of this requires knowledge of any locking (named or auto) that has been applied to the Map classes (I’m thinking particularly of Hashtable here) - this means we need to be able to inspect the bootjar config at runtime (and know that it is correct). DEV-2176 and DEV-2259 are the JIRAs for these features.

Fiona OShea 2009-03-05

Needs further discussion per Chris’ comments