Before this bug is fixed in threading part, for any people who are interested in GCv5, please use patch below for workaround, just to add two lines.
GCv5 only works in Windows at the moment. Please get it in latest SVN, and patch it with http://issues.apache.org/jira/browse/HARMONY-1785 for write barrier support. Then build and run with command line options: java -Xem:jet -Djit.JET.arg.wb4c=true -Dvm.dlls=gc_gen.dll If the heap size is too small to hold the application, go ahead to increase it in <working_vm>/vm/gc_gen/src/gen/gen.cpp line 30: max_heap_size_bytes. Patch for threading bug work around: Index: src/thread/mutator.cpp =================================================================== --- src/thread/mutator.cpp (revision 454392) +++ src/thread/mutator.cpp (working copy) @@ -27,6 +27,8 @@ { /* FIXME:: NOTE: gc_info is uncleared */ Mutator *mutator = (Mutator *) gc_information; + /* FIXME:: initialize twice!!! */ + if( mutator->gc) return; mutator->free = NULL; mutator->ceiling = NULL; mutator->curr_alloc_block = NULL; Index: src/common/gc_for_vm.cpp =================================================================== --- src/common/gc_for_vm.cpp (revision 454392) +++ src/common/gc_for_vm.cpp (working copy) @@ -33,7 +33,7 @@ p_global_gc = gc; gc_gen_initialize((GC_Gen*)gc, min_heap_size_bytes, max_heap_size_bytes); /* initialize the main thread*/ - // gc_thread_init(vm_get_gc_thread_local()); + gc_thread_init(vm_get_gc_thread_local()); return; } Thanks, xiaofeng On 10/10/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
Hi, when I tested with GCv5 in DRLVM, I found there is design issue in threading part. That is, after gc is initiated (gc_init) in runtime, the main thread can't allocate object based on its allocation context (thread local gc info), because the allocation context is not initialized (gc_thread_init) until very late when Java_java_lang_VMThreadManager_attach is invoked. This new design (previously the main thread allocation context is initialized right after gc initialized) looks not very reasonable, because it means the main thread can't really allocate object even after gc is initialized. I wonder why we chose this new design. I read GCv4.1 code, it has a work around to avoid the problem. That is, to actually initialize the main thread's allocation context in first time allocation. The workaround works, but has following problems: 1. the same thread (main thread) will initialize its allocation context again later when calling Java_java_lang_VMThreadManager_attach; 2. the logic that the main thread can't allocate object normally after gc is initialized is problematic. And the logic that letting Java_java_lang_VMThreadManager_attach to initialize the main thread allocation context is also confusing. 3. in a generational GC, the mutator (the main thread)'s allocation has to be initialized for those early objects allocation because they may be put into different spaces but write barrier can't catch them without properly initialized allocation context. There are some altermative solutions: 1. get back the gc_thread_init() invocation right after gc_init(). This requires some change in the calling sequence of Java_java_lang_VMThreadManager_attach. 2. have a special space manager to allocate the early objects (bootstrapping objects). Then all the allocation request should better be distincted from the normal one gc_alloc(). For example, we can use gc_alloc_raw(), which has no thread local gc info passed in arguments, since the info is not initialized yet. 3. only call gc_init() when the bootstrapping is finished. Before that, call another function gc_init_raw() for early object allocations, which are accomplished with gc_alloc_raw(). We need decide when is the right calling point for gc_init() (and of course gc_thread_init()). Either solution is fine to me, but the third one is my favorite. Comments? Thanks, xiaofeng
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
