Bug #5651
open
Garbage collection of xsl:key indexes
Applies to branch:
11, trunk
Fixed in Maintenance Release:
Description
When Saxon builds an index in support of an xsl:key definition, or an implicit xsl:key generated by the XSLT/XQuery optimizer, the intent is that the key remains in memory so long as BOTH the source document AND the compiled stylesheet or query remain in memory.
This appears not to be working. If we run the same query 1000 times against the same source document, we're seeing the index built 95 times. This suggests the garbage collector is destroying it and we're having to rebuild it the next time it's used.
We use WeakReferences to support this policy, and it looks as if we're getting it wrong.
Note: we also need to check how this works on Saxon-CS, as it's probably different.
I was pointing to this fact years ago. :-)
I remember then I suggested to store key data in document info owned by it, and index it by unique id associated with key definition. That I'd might be dynamic if it depends on parameters.
Alternatively you can invent weak hash map by multiple weak keys, similar to WeakStore.java.
Thanks, Vladimir. It's always disappointing to learn that a user has been aware of a problem with our products for years when we weren't aware of it ourselves. But it probably happens a lot.
And thanks for the pointer to WeakStore.java. Is it possible to adapt it so that a resource becomes eligible for garbage collection when either of the objects pointing to it is garbage-collected, rather than when both of them are?
it possible to adapt it so that a resource becomes eligible for garbage collection when either of the objects pointing to it is garbage-collected, rather than when both of them are?
I think this is how it is working.
That class uses composite key where each component is stored as weak reference.
When any part is collected then whole key will appear in the cleanup ReferenceQueue, and map entry is reclaimed on next call to pull.
It's always disappointing to learn that a user has been aware of a problem with our products for years when we weren't aware of it ourselves.
See old thread https://saxonica.plan.io/boards/3/topics/2655
I've added a unit test WeakStoreTest.java that confirms that data is freed from WeakStore, if any part of key is garbage collected.
Please register to edit this issue
Also available in: Atom
PDF
.