[
https://issues.apache.org/jira/browse/LUCENE-5887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-5887:
----------------------------------
Description:
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 WeakIdentityMap, the remaining one is the
ByteBuffer stuff in MMapDirectory. Unfortunately I have still no idea how to
remove that one... :(
was:
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... :(
> 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
>
> Attachments: LUCENE-5887.patch
>
>
> 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 WeakIdentityMap, 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]
