harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salikh Zakirov <sal...@gmail.com>
Subject Re: [drlvm][modularity proposal] change current vm/gc query interface for better flexibility and performance
Date Mon, 14 Jan 2008 15:53:35 GMT
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


Mime
View raw message