harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: [arch] VMCore / Component Model
Date Tue, 20 Sep 2005 12:40:02 GMT

On Sep 20, 2005, at 12:26 AM, Robin Garner wrote:

> I think it's important not to take Tim's point about performance too
> lightly here.  There are some key interfaces between components that
> can't afford the overhead of a function call, let alone an indirect
> call via a function pointer.
> Three instances that come to mind are:
> - Allocation.  For best performance, the common case of a new() needs
>   to be inlined directly into the compiled code.
> - Write barrier (and read barrier if we need one).  The common case
>   of a write barrier should be a handful of instructions.
> - Yield points.  Again should inline down to a couple of instructions.

> I'd be interested in any approaches you may have thought of for these
> interfaces.

Are these things the components would worry about, or can an  
optimizer deal with these "later" if possible?

Now, I'm really just making this up as I go along... what some people  
call "thinking out loud", but I won't grace this with the term  
"thinking".  I've never written or been inside VM internals, so I'm  
inventing out of whole cloth here...

In earlier discussions of componentization, I kept imagining a model  
where we have a defined set of capabilities that a component could  
optionally implement.  There would be a required set, as well as  
optional ones.  (This thinking is inspired by the old MSFT COM  

In the case of a memory manager, a required one would be the  
"interface" containing the function pointers for a memory management.

An optional one would be "NativeInlineConversion" or something, where  
an optimizer could find a new() and if it doesn't support the native  
inlineing, use the function call into the component, and if it does,  
ask the component for the bit of complied code to use.

I'll sketch these out in code once we get David's code contributed  
properly into JIRA and we register his ACQ.

> On Mon, 2005-09-19 at 19:46 +0200, David Tanzer wrote:
>> Today I have added some additional Information to the Wiki page.
>> We should also consider using C++ and abstract classes to maintain  
>> our
>> component model. While this would make inter-component communication
>> slightly slower it would be easier to maintain. We should also think
>> about using an existing component model like OSGi.
>> The model I posted provides pretty fast communication between  
>> components
>> without sacrificing too much flexibility, but it is maybe not as  
>> easy to
>> maintain as a clean, object-oriented implementation (i.e. C++). We  
>> could
>> discuss how important these aspects are to us, i.e. how much runtime
>> efficiency we are willing to sacrifice for maintainability and
>> flexibility and vice-versa.
> First order of priority, IMO, is to decide what are the performance
> critical components, and what are not.  For the infrequent cases,  
> we can
> afford a heavy-weight approach, for those that happen every few
> bytecodes, we need to be lean and mean.

Is this the kind of optimization you want to do now, or do we want to  
put together a structure that supports it for later?


Geir Magnusson Jr                                  +1-203-665-6437

View raw message