Fully revoked classes found. Instances of classes were revoked more times than the user configured limit.
The following classes were disabled from using biased locking:
- io.grpc.netty.shaded.io.netty.channel.DefaultChannelPromise
The following instances of classes were revoked more than the user configured limit for this rule (limit=15, not including disabled classes):
- java.util.Vector (28)
- javax.management.NotificationFilterSupport (28)
- javax.management.ObjectName (24)
- java.lang.Thread (16)
Biased locking is a technique used by the JVM to decrease the cost of uncontended locking to near lock free performance. A thread can bias a lock object to itself, making subsequent locking by the same thread very inexpensive. If the lock starts being used by other threads, the bias can either be revoked, rebiased towards the other thread, or revoked from being biased again for the rest of the runtime of the JVM.
Having a lot of revoked classes need not be a problem, but can provide opportunities for optimizations, tuning and design improvements. For example, if you have a lot of contention during the startup of your application, the revocation costs may be significant, and you may want to delay the enablement of biased locking using the '-XX:BiasedLockingStartupDelay=<time in ms>' flag. For applications that heavily depend on contended locking, and cannot be redesigned, it may be beneficial to turn off biased locking altogether ('-XX:-UseBiasedLocking'). For benchmarking, you may want to set '-XX:BiasedLockingStartupDelay' to zero.
The following classes were filtered out: [java.lang.ref.ReferenceQueue$Lock]