Uwe Schindler created LUCENE-5887:
-------------------------------------

             Summary: Remove horrible WeakIdentityMap caching in 
AttributeFactory, AttributeSource and VirtualMethod
                 Key: LUCENE-5887
                 URL: https://issues.apache.org/jira/browse/LUCENE-5887
             Project: Lucene - Core
          Issue Type: Improvement
            Reporter: Uwe Schindler
            Assignee: Uwe Schindler
             Fix For: 5.0, 4.10


Especially the use case in AttributeFactory is horrible:
Because of ClassLoader issues we cannot hold strong references (see LUCENE-5640 
for explanation), we need WeakIdentityMap<Class, WeakReference<someVal>>. You 
could say: let's use a strong value for stuff like MethodHandles (used in 
AttributeFactory), but because those have a strong reference to the class, our 
reference to key would be strong, so garbage collector can no longer unload the 
class. This is why we use the WeakReference also on the value.

The problem is if the value is something like a MethodHandle, which itsself has 
hard reference to (so it gets garbage collected). Then the cache is useless.

In DefaultAttributeFactory I decided, to make methodhandles strong references, 
but then I needed to restrict it to our own classloader, otherwise we would 
have strong references to foreign classloaders.

Since Java 7 there is java.lang.ClassValue, that fixes the following JVM bug: 
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6389107

See also: http://stackoverflow.com/questions/7444420/classvalue-in-java-7

In fact internally, there is a also a WeakReference/WeakHashMap used, but only 
as fallback - and its only one globally, used by many other JVM internals, too. 
By default it has a very fast path and the call to ClassValue.get() is 
incredibly fast. This should therefore also improve AttributeFactory 
alltogether.

Next to AttributeFactory, I also improved the Interfaces cache of 
AttributeSource (this one assigns an array of Attribute interfaces to an 
AttributeImpl). The other one is VirtualMethod (assigns its own 
implementationDistance for every seen subclass).

This also removes almost all uses of VirtualIdentityMap, the remaining one is 
the ByteBuffer stuff in MMapDirectory. Unfortunately I have still no idea how 
to remove that one... :(



--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to