On 10/9/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()).
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Weldon Washburn Intel Middleware Products Division
