Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@harmony.apache.org
From: Salikh Zakirov <salikh@gmail.com>
Subject: Re: [drlvm][modularity proposal] change current vm/gc query interface
 for better flexibility and performance
Date: Tue, 15 Jan 2008 00:53:35 +0900
Lines: 32
Message-ID: <fmg0i0$2v0$1@ger.gmane.org>
References: <9623c9a50801121827r6033d1d8jeb38c390fd966eba@mail.gmail.com>
	 <e0f125db0801130827r121f76f6uea22869a8d1dffe@mail.gmail.com>
 <9623c9a50801132314v27011bd9l1a92a59aee2f8cb7@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
User-Agent: Thunderbird 2.0.0.9 (X11/20071205)
In-Reply-To: <9623c9a50801132314v27011bd9l1a92a59aee2f8cb7@mail.gmail.com>
Sender: news <news@ger.gmane.org>

Xiao-Feng Li wrote:
> On Jan 14, 2008 12:27 AM, Pavel Pervov <pmcfirst@gmail.com> wrote:
>> Xiao-Feng,
>>
>> I'm supporting the idea of filling interface table on the side of the
>> component.
>>
>> Generifying this idea, I'd suggest creating JNI-like table-of-functions
>> interface and fill it with single call to a component (GC in your case).
>> Then VM can unpack the structure if it can provide some performance
>> benefits.
> 
> Using a function table probably works as well. We can try it at the beginning.
> 
> Btw, basically my current idea (initial, not mature) is to have a
> memory manager (MM) which manages a couple of different garbage
> collectors. The garbage collectors can be in same DLL or different
> ones. It's MM's responsibility to decide using which DLL and which
> function implementation inside the DLL. This probably can help the
> switch between compressed and uncompressed ref GCs. That's a long term
> goal though.

How about trying out existing "Component Manager" infrastructure?
It was designed with flexibility in mind, so hopefully having several different
GC implementations in single DLL would not be an issue.
It implements exactly what was discussed: creating and filling interface
table on the side of the component. And VM-side function table (void (*gc_init)() etc.)
can be filled by copying function pointers from component-provided function table.

Currently, EM is loaded using component manager, the code is in
vm/vmcore/src/init/vm_init.cpp, function process_properties_dlls;
see also vm/em/src/em_intf.cpp