harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [DRLVM][Threading/GC] thread info initialization problem
Date Tue, 10 Oct 2006 06:27:32 GMT
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 <xiaofeng.li@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message