Adding class loading lock to JBoss Modules

[pmm]

We are running into https://bugs.openjdk.java.net/browse/JDK-8232997. In our case this results in a JVM crash when loading custom JFR event classes. The cause seems to be when multiple threads end up calling #defineClass for the same custom JFR event class then JVM crashes. This seems to be caused by a particularity of JBoss Modules in that it doesn't acquire a class loading lock, instead it allows for a small race condition which is handled by catching LinkageError. This does not seem to work for custom JFR event classes (it is fixed in JDK 14).

We are in talks with our vendor to get the fix back ported from JDK 14 to JDK 11 but that may take a while. As a work around we are considering making our own fork of JBoss Modules to do

synchronized (getClassLoadingLock(name))

around loading a class to void concurrent calls to #defineClass for the same class. Apart from the possible performance penatly do you see any other problems with this fix?

If you want to reproduce the issue have a look at:

GitHub - marschall/jfr-crasher: A reproducer for crashing JFR

[ctomc]

dmlloyd might be able to help.

[dmlloyd]

You can try it out, I think there may be a chance of deadlock though.  It's really hard to say for sure.

[pmm]

dmlloyd  wrote:

You can try it out, I think there may be a chance of deadlock though.  It's really hard to say for sure.

Right, but because we're acquiring a class level lock per ModuleClassLoader that would require a circular dependency between classes in different modules that have circular dependencies between themselves, correct?

These classes would by definition have to be in different JARs but be compiled against each other. I guess that's possible but quite hard to pull off. JUnit 4 requiring hamcrest classes and hamcrest requiring JUnit 4 classes comes to mind.