harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject [DRLVM][Threading/GC] thread info initialization problem
Date Tue, 10 Oct 2006 06:16:24 GMT
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