harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [drlvm][modularity proposal] change current vm/gc query interface for better flexibility and performance
Date Thu, 24 Jan 2008 12:16:49 GMT
Xiao Feng, I'm sorry for late answer.

Thanks for your interest to the component manager. To avoid designing
things "solely" for some component the component manger provided
callback registration mechanism, so your component can adjust all
environment as it likes using its own utility functions. It also can
request exposed interfaces from other components. For example, if you
need to add helpers to the boot classpath you just need to request
some VM interfaces.

Thanks.

On Jan 15, 2008 3:03 AM, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
>
> 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
>



-- 
With best regards,
Alexei,
ESSD, Intel

Mime
View raw message