GROOVY-8067: Possible deadlock when creating new ClassInfo entries in the cache #489
Conversation
| } | ||
| } | ||
| modifiedExpandos.add(this); | ||
| } |
There was a problem hiding this comment.
Removed because it appeared to be a duplicate of the logic above. Only if the previous strongMetaClass value was an expando would it have been added to the modifiedExpandos, so the iteration/removal above should have taken care of removing this ClassInfo from the modifiedExpandos and there's no reason to iterate again.
|
that looks very promising to me +1 |
|
|
||
| } | ||
|
|
||
| private final class Iter implements Iterator<T> { |
There was a problem hiding this comment.
think this can be made a static nested class
| Class<?> newClass = (cls == null) ? createRandomClass() : cls; | ||
| try { | ||
| startLatch.await(); | ||
| } catch (InterruptedException ie) { |
There was a problem hiding this comment.
can use ThreadUtils.awaite()
|
@blackdrag @paulk-asert do you have any reservations about adding a new sub-project for the manual/stress tests? I tried to work them into |
|
no reservations on my side |
jwagenleitner
force-pushed
the
groovy8067-mclq
branch
from
538b9be
to
e1faf50
Compare
As suggested in PR #484 removed the locking on the
ManagedLinkedListby creating a newManagedConcurrentLinkedQueue.Also added a
stresssubproject for tests that employ many threads, need GC, or just in general try to break things and take a long time. These require a special property to be set in order to run, otherwise they will be skipped. I tried to work it out in theperformancesubproject, but that seems to be very specialized for the compiler tests. Open to suggestions on a better way to handle these types of tests.