Review request for JDK-8146274: Thread spinning on WeakHashMap.getEntry() with concurrent use of nashorn

Attila Szegedi szegedia at gmail.com
Fri Jan 15 15:37:44 UTC 2016


Excellent. I knew you’re thorough as usual :-)

> On Jan 15, 2016, at 4:36 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Thanks for the review.
> 
> Just synchronizing WeakPropertyMapSet methods would not be sufficient, as there is a method that returns the keyset, which is then iterated by the calling code. I could have refactored that (adding 4 listener methods to WeakPropertyMapSet that iterate the keyset internally).
> 
> I chose to go the other way based on observing that very few collections are actually copied at runtime, and it's mostly a one-time thing (once the property maps stabilize, so do the listeners).
> 
> Hannes
> 
> Am 2016-01-15 um 16:06 schrieb Attila Szegedi:
>> +1. I presume you considered it and decided that copying the weak maps is better than sharing WeakPropertyMapSet objects and making their methods synchronized.
>> 
>>> On Jan 15, 2016, at 12:49 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
>>> 
>>> Please review:
>>> 
>>> Webrev: http://cr.openjdk.java.net/~hannesw/8146274/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146274
>>> 
>>> I was not able to reproduce the issue although I tried my best to follow the instructions. However, it is pretty clear that the issue is that the cause for the concurrent modification exception is the sharing of  WeakPropertyMapSets between PropertyMapListeners.
>>> 
>>> Thanks,
>>> Hannes
> 



More information about the nashorn-dev mailing list