This PR implemented thread.interrupt in commit ce1e331. It also refactored some existing runtime code and fix several synchronization issues. Now, the reflection concurrency tests also pass.
However, there are still two problems that might happen in reflection concurrency tests if we run a longer ConcurrentReflectionTest (increase the number of iteration), but neither of them are due to multithreading or concurrency.
The first one is in method reflection. If we run a method invocation through reflection lots of times, JDK will switch to a different MethodAccessor which calls several unimplemented JVM methods (DefineClass...). I believe this is Java's JIT behavior. To avoid this, either we need to patch the JDK to prevent the switching from happening or we have to implement those methods in JVM.
The second one happens in both method reflection and field reflection. If we keep invoking field.getType() or method.getReturnType() for thousands of times, a segfault will be thrown. It happened nondeterministically. I believe either we are not correctly allocating the memory using GC or we somehow overwrite objects in runtime. I wrote ReflectionMemoryTest.java to reproduce this problem.
As mentioned in #56, the second issue mentioned above could not be resolved easily. It existed even before the concurrency support. I believe we could ignore it for now and potentially fix it in the future PR.
This PR implemented thread.interrupt in commit ce1e331. It also refactored some existing runtime code and fix several synchronization issues. Now, the reflection concurrency tests also pass.
However, there are still two problems that might happen in reflection concurrency tests if we run a longer ConcurrentReflectionTest (increase the number of iteration), but neither of them are due to multithreading or concurrency.
The first one is in method reflection. If we run a method invocation through reflection lots of times, JDK will switch to a different
MethodAccessor
which calls several unimplemented JVM methods (DefineClass
...). I believe this is Java's JIT behavior. To avoid this, either we need to patch the JDK to prevent the switching from happening or we have to implement those methods in JVM.The second one happens in both method reflection and field reflection. If we keep invoking
field.getType()
ormethod.getReturnType()
for thousands of times, a segfault will be thrown. It happened nondeterministically. I believe either we are not correctly allocating the memory using GC or we somehow overwrite objects in runtime. I wroteReflectionMemoryTest.java
to reproduce this problem.