Hi,I'm working on improving the support for ConcurrentHashMap so that locking is better optimized and that read locks are used when appropriate. To do this, ConcurrentHashMap$Segment should extend ReentrantReadWriteLock instead of the current ReentrantLock. However, when I simply rewrite the Segment class to extend ReentrantReadWriteLock and add the appropriate methods, I get a JVM crash. I started to investigate, and this crash doesn't happen if I continue to extend ReentrantLock and instead create a local var in the Segment class for the ReentrantReadWriteLock and delegate all the methods of ReentrantLock to the local variable. The locking wasn't working yet (since the applicators had to be changed accordingly), but at least the JVM wasn't crashing anymore. However, it feels quite dirty to continue to be extending ReentrantLock just to prevent the JVM from crashing. I tried searching through the source code and the classes in the bootjar for references to the CHM segments that might explicitly cast to ReentrantLock, but I couldn't find any.
I thus tried to duplicate the public interface of ReentrantLock as much as possible through method stubs (see attached diff). Even when I implement all the interfaces that ReentrantLock implements and add the required methods, I get a JVM crash when having a CHM$Segment class that only extends java.lang.Object (see attached crash log). It seems that during class loading, the JVM is using a CHM for the verification of the security domain, and then executes some JVM code during the constructor of CHM which causes the crash. Now I can't find anything in the CHM constructor, nor with Jad or javap that looks fishy. I also tried with different JVMs (MacOSX - simply prints 'Bus error' and Linux - at least gives the crash log) and different versions (1.5 and 1.6) to see if I could get more info, but nothing changes.
Does anyone have any ideas? If you want to duplicate this, apply the diff to trunk, generate a bootjar, and execute any main class with the bootjar after the java command, no need to specify anything TC related (java -Xbootclasspath/p:/path/to/dso-boot-xyz.jar your.Main).
Thanks for any insights that you can provide. Take care, Geert
hs_err_pid6452.log
Description: Binary data
tc.diff
Description: Binary data
-- Geert Bevin Terracotta - http://www.terracotta.org Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com
_______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
