harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [DRLVM][Threading/GC] thread info initialization problem
Date Tue, 10 Oct 2006 15:32:00 GMT
On 10/9/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()).

>From what I recall, #3 is how DRLVM used to bootup.  One "gottcha" to look
for during early boot is the need to allocate an object before the vtable of
its class is created.  vtable ptrs would need to be written to the objects
long after original allocation.  #3 is OK with me.  We still need to figure
out the GC boot sequence for MMTk/DRLVM.  It probably changes the same code
as above.  But I don't want to tie GCV5 design decisions to MMTk porting at
this point.

Harmony-dev email is kind of clumsy for debating where gc_init(),
gc_init_raw(), etc need to be placed in the boot code.  Maybe hack on this
area of the system and put it in a JIRA.  If the list likes it, commit it.

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

Weldon Washburn
Intel Middleware Products Division

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message