New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix TypeCache dead lock #902
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some unintended Android changes slipped in
@raphw Could that be the issue that I saw in #897, see travis log : https://travis-ci.org/mockito/mockito/jobs/194254780#L360-L366 |
No, that is a flaky test as we rely on triggering a garbage collection which is something we do not controll on a VM even though there is a good chance to. We should ideally rerun this test multiple times upon a failure. @TimvdLippe I fixed the accidental pre-commit. |
OK. Agreed. |
@@ -13,6 +13,8 @@ | |||
|
|||
class TypeCachingBytecodeGenerator extends ReferenceQueue<ClassLoader> implements BytecodeGenerator { | |||
|
|||
private final Object BOOTSTRAP_LOCK = new Object(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this field intended to be constant? If not, it should have lower case name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is true, this should be lower case but yes, it should be an instance constant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However this lock should not be static.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great!
I could trace the problem to more eager resolution of types in Java u31 upon loading where concurrent mock creation with locking on the class level causes a dead lock. This can happen in other VM implementations but can be solved with a more granular lock on our type cache.
This fixes #892.