The direct-threaded interpreter has several race conditions. Any place the bytecode is rewritten during execution is not thread-safe. The fix is to do all field and method resolution when compiling to direct-threaded form. Release: unknown
Responsible-Changed-From-To: unassigned->tromey Responsible-Changed-Why: I have a patch I'm testing.
FWIW that patch has long since gone missing :-( Perhaps this problem can most easily be solved using the new __sync built-ins.
Despite what the original report says, we don't really want to resolve all entries when compiling. Also it would be best to avoid any kind of synchronization at all. One idea would be to 'or' the argument to one of these instructions with 0x1 when the datum is unresolved. This can be tested reasonably quickly. And, since these lookups are all idempotent, it does not matter if two threads happen to do a small amount of redudant lookup work.
Subject: Bug 8995 Author: aph Date: Fri Aug 22 16:17:19 2008 New Revision: 139493 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139493 Log: Fix PR#. 2008-08-22 Andrew Haley <aph@redhat.com> PR libgcj/8995: * interpret-run.cc (REWRITE_INSN): Null this macro. * include/jvm.h (class _Jv_Linker): Declare resolve_mutex, init. (read_cpool_entry, write_cpool_entry): New functions. * link.cc (_Jv_Linker::resolve_mutex): new. (_Jv_Linker::init): New function. (_Jv_Linker::resolve_pool_entry): Use {read,write}_cpool_entry to ensure atomic access to constant pool entries. Modified: trunk/libjava/ChangeLog
Subject: Bug 8995 Author: aph Date: Fri Aug 22 16:04:29 2008 New Revision: 139492 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139492 Log: 2008-08-22 Andrew Haley <aph@redhat.com> PR libgcj/8895: * interpret-run.cc (REWRITE_INSN): Null this macro. * include/jvm.h (class _Jv_Linker): Declare resolve_mutex, init. (read_cpool_entry, write_cpool_entry): New functions. * link.cc (_Jv_Linker::resolve_mutex): new. (_Jv_Linker::init): New function. (_Jv_Linker::resolve_pool_entry): Use {read,write}_cpool_entry to ensure atomic access to constant pool entries. Modified: trunk/libjava/ChangeLog trunk/libjava/include/jvm.h trunk/libjava/interpret-run.cc trunk/libjava/link.cc
Subject: Bug 8995 Author: aph Date: Fri Aug 22 16:57:11 2008 New Revision: 139494 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139494 Log: 2008-08-22 Andrew Haley <aph@redhat.com> PR libgcj/8995: * interpret-run.cc (REWRITE_INSN): Null this macro. * include/jvm.h (class _Jv_Linker): Declare resolve_mutex, init. (read_cpool_entry, write_cpool_entry): New functions. * link.cc (_Jv_Linker::resolve_mutex): new. (_Jv_Linker::init): New function. (_Jv_Linker::resolve_pool_entry): Use {read,write}_cpool_entry to ensure atomic access to constant pool entries. Modified: branches/gcc-4_3-branch/libjava/ChangeLog branches/gcc-4_3-branch/libjava/include/jvm.h branches/gcc-4_3-branch/libjava/interpret-run.cc branches/gcc-4_3-branch/libjava/link.cc
Subject: Bug 8995 Author: aph Date: Tue Sep 23 13:51:58 2008 New Revision: 140593 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140593 Log: 2008-09-17 Andrew Haley <aph@redhat.com> PR libgcj/8995: * defineclass.cc (_Jv_ClassReader::handleCodeAttribute): Initialize thread_count. * include/java-interp.h (_Jv_InterpMethod::thread_count): New field. (_Jv_InterpMethod::rewrite_insn_mutex): New mutex. (_Jv_InterpFrame:: _Jv_InterpFrame): Pass frame_type. * interpret.cc (ThreadCountAdjuster): New class. (_Jv_InterpMethod::thread_count): New field. (_Jv_InitInterpreter): Initialize rewrite_insn_mutex. Increment and decrement thread_count field in methods. * interpret-run.cc (REWRITE_INSN): Check thread_count <= 1. (REWRITE_INSN): Likewise. Declare a ThreadCountAdjuster. * java/lang/reflect/natVMProxy.cc (run_proxy): Initialize frame type as frame_proxy. Modified: trunk/libjava/ChangeLog trunk/libjava/defineclass.cc trunk/libjava/include/java-interp.h trunk/libjava/interpret-run.cc trunk/libjava/interpret.cc trunk/libjava/java/lang/reflect/natVMProxy.cc
*** Bug 37051 has been marked as a duplicate of this bug. ***
.