Summary: | query: IndexWriter.LongIndex reverse should also use a threadsafe cache? | ||
---|---|---|---|
Product: | [Tools] MAT | Reporter: | Jason Koch <jkoch> |
Component: | Core | Assignee: | Project Inbox <mat.core-inbox> |
Status: | CLOSED MOVED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | andrew_johnson |
Version: | 1.15 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | All | ||
Whiteboard: |
Description
Jason Koch
2023-12-31 17:04:10 EST
Do you know where IndexWriter.LongIndex.reverse() is used? It wasn't changed because it didn't seem to be used in a multi-threaded way. We could go through the API working out which ones are thread-safe, but might need input from the adopter community to see what is important. > Do you know where IndexWriter.LongIndex.reverse() is used? Good question. I modified the code to throw an exception, and only and 8 tests failed: - longIndexCollector4[index size 6] - longIndexCollector4[index size 999,999] - longIndexCollector4[index size 1,000,000] - longIndexCollector4[index size 1,000,001] - longIndexCollector4[index size 1,999,999] - longIndexCollector4[index size 2,000,000] - longIndexCollector4[index size 2,000,001] - longIndexCollector4[index size 1,000] So it would appear the code is currently unused in any of the test cases. Further, when I look at the code paths. - LongIndex is abstract static class. - IndexWriter.LongIndexCollector extends it and uses the LongIndex impl - IndexWriter.LongIndexStreamer (and PosIndexStreamer) extends it and uses the LongIndex impl - IndexReader.LongIndexReader extends it and provides its own reverse() implementation As far as I can tell, the writeTo() all return a LongIndexReader which has its own impl. The LongIndexCollector and LongIndexStreamer are never used with a reverse() call. Identifier::reverse is also called but it has its own implementation too! > We could go through the API working out which ones are thread-safe, but might need input from the adopter community to see what is important. On one hand, I think upgrading something not-thread-safe to thread-safe seems wise. On the other, Hyrum's Law is also at play here, given majority of the parser classes are not thread-safe and only being made thread-safe as a result of demands from hprof parser. I'm only aware of one extension (Mat-Calcite-Plugin), and one app over the top (JIFA) that rely on MAT. Is there a catalogue available? So it would appear the code is currently unused in any of the *end to end* / integration test cases. This issue has been migrated to https://github.com/eclipse-mat/org.eclipse.mat/issues/47. |