Project

Profile

Help

Bug #5651

open

Garbage collection of xsl:key indexes

Added by Michael Kay about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Low
Assignee:
Category:
-
Sprint/Milestone:
-
Start date:
2022-08-18
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
11, trunk
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:

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.

Actions #1

Updated by Vladimir Nesterovsky about 1 month ago

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.

Actions #2

Updated by Michael Kay about 1 month ago

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?

Actions #3

Updated by Vladimir Nesterovsky about 1 month ago

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

Actions #4

Updated by Vladimir Nesterovsky about 1 month ago

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