harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <Robin.Gar...@anu.edu.au>
Subject Re: [arch] VMCore / Component Model
Date Tue, 20 Sep 2005 04:26:17 GMT
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.

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.

cheers
Robin




Mime
View raw message