harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [drlvm][modularity proposal] change current vm/gc query interface for better flexibility and performance
Date Tue, 15 Jan 2008 00:03:54 GMT
On Jan 14, 2008 11:53 PM, Salikh Zakirov <salikh@gmail.com> wrote:
> 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

Salikh, that's something I am thinking. The problem with current
component manager design is, it knows nothing about GC internals,
while the GC function selection is within GC internals. It needs a
manager solely managing GC. As the initial step, it's inside the same
DLL with GC. I'd like to gradually factor out its responsibility along
with the time. I once also thought about putting certain part of GC
manager into VM core based on existing infrastructure. But I have not
thought it through clearly at the moment, so probably it's better to
start from my current proposal.

Thanks,
xiaofeng

-- 
http://xiao-feng.blogspot.com

Mime
View raw message