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
infrastructure...)
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
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
