Replace WeakSet usage with JDK equivalent and deprecate class.

[mbien]

Instead of updating WeakSet (#8380) we deprecate it for removal and replace all usage.
Once the build starts failing we can still decide what to do with it.

• WeakSet is now deprecated for removal
• usage can be replaced with WeakHashMap and Collections.newSetFromMap()

part of #8257

have to take a good look at all usages which used putifAbsent, some might need tweaks

• ElementHandle deduplicaiton mechanism can be replicated using a WeakHashMap and storing the handle as key and as WeakReference-wrapped value. This way the old element can be extracted if there is a match, while allowing the map to shring if the handles aren't used anymore. Not 100% sure yet what overhead this is supposed to avoid though since the ElementHandle is created in all paths, but an old handle is returned on hit while discarding the new one.
• WebLogicConfiguration removed the cache since it was redundant. The caller is cached. Someone liked caches.

main difference is that all calls to WeakSet#add were implemented via putIfAbsent. This is not the case in WeakHashMap, however, during the typical use case (e.g listener storage) this should not make a difference.

[mbien]

trying to figure out what the purpose of the ElementHandle deduplication code is. Its not for instance comparison reasons, since

$a == $b
:: $a instanceof org.netbeans.api.java.source.ElementHandle
&& $b instanceof org.netbeans.api.java.source.ElementHandle
&& !isNullLiteral($b)
=>
$a.equals($b)
;;

$a != $b
:: $a instanceof org.netbeans.api.java.source.ElementHandle 
&& $b instanceof org.netbeans.api.java.source.ElementHandle
&& !isNullLiteral($b)
=>
!$a.equals($b)
;;

produced no relevant hits.

Here is the original commit emilianbold/netbeans-releases@3dab461 referencing https://bz.apache.org/netbeans/show_bug.cgi?id=197743

https://bz.apache.org/netbeans/show_bug.cgi?id=197743#c2 indicates it was one of the changes to attempt to reduce memory consumption in large files.

Will check if this deduplication cache could be removed again. A new handle has to be created first before checking if it is already there (no construction overhead reduction) and secondly the Object itself is just two constants: ElementKind and a String array for its signatures. Would have been good to still have the original performance test file for this (Big.java). Edit: this must be it https://bz.apache.org/netbeans/show_bug.cgi?id=194816, test project attached.

[mbien]

removed the ElementHandle deduplicaiton code after testing with the original reproducer project (added to the reprorepo).

this spawned two more PRs to tackle performance problems I noticed while playing with that test project:

• Remove source level query from javadoc hint. #8417
• Implement Preferences cache for java hints. #8418

filed issue for third scaling problem:

• JSEmbeddingProvider is using up CPU time in java files without JS #8419

[mbien]

planning to get this PR in as soon as possible after RC3

[mbien]

I am running this together with some of the performance enhancement PRs and everything is working fine. I was mostly worried about the removal of the ElementHandle deduplication code but even synthetic tests with an unreasonable amount of fields/methods/inner classes which hit the code path often do fine.

So my current thinking is that we can indeed remove the deduplication (see second commit with the "problem cases" ElementHandle#create).

edit: will refresh this PR with a rebase - no other changes

[mbien]

almost forgot about this PR. Planning to merge this ASAP to make progress with #8257. since there is still much to do in #8256. Last chance to review ;)

[lkishalmi]

Let's go for this!

[neilcsmith-net]

Looks sane, not tested.

Had a concern at first about the explicit sizing of the WeakHashMaps but see that WeakSet used the same load factor logic. I'm curious how many of those capacities are correct, but better to merge matching existing behaviour.

[mbien]

those sizing values are a "false friend", somewhat similar to String#replaceAll. It is likely that they don't do what some authors thought they would do, but in practice it probably doesn't matter all that much. Post JDK 21 bump this should be all changed to [Map|SetImpl]#newFoo[Map|Set] More details with a short demonstrator is on an old blog entry I once wrote.

[neilcsmith-net]

Yes, I know - that's what caught my eye looking at this. Funnily enough your blog post was one of the first things that popped up when I searched for the JDK 19+ methods to check the difference in behaviour! 😄

[mbien]

thanks for the review!