afs commented on code in PR #3517:
URL: https://github.com/apache/jena/pull/3517#discussion_r2441269232
##########
jena-arq/src/main/java/org/apache/jena/sparql/engine/join/AbstractIterHashJoin.java:
##########
@@ -234,13 +234,11 @@ protected void closeSubIterator() {
if ( JoinLib.JOIN_EXPLAIN ) {
String x = String.format(
"HashJoin: LHS=%d RHS=%d Results=%d Table=%s",
- s_countProbe, s_countScan, s_countResults,
- hashTable.toString()) ;
+ s_countProbe, s_countScan, s_countResults, hashTable)
;
System.out.println(x) ;
}
// In case it's a peek iterator.
iterStream.close() ;
- hashTable.clear();
Review Comment:
The heap subsystem is more than just GC'ing. Clearing objects can release
memory earlier (minor GC) or (unlikely here) th eheap sees short lived objects
and does effectively a malloc free.
It is hard to tell if it makes a real difference, but it isn't complicated
to do here.
And `hashTable = null;` It would also be an internal consistency check to
make sure it isn't mistakenly reused.
This is single thread code so a simple solution
```java
if ( hashTable != null ) {
hashTable.clear();
hashTable = null;
}
```
either harmless or may be an advantage.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
