[Vm-dev] [Pharo-project] Plan/discussion/communication around new object format

David T. Lewis lewis at mail.msen.com
Fri Jun 15 00:49:32 UTC 2012

On Fri, Jun 15, 2012 at 01:15:15AM +0200, Igor Stasenko wrote:
> On 14 June 2012 23:44, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> > But so you know what the performance overhead is? ??In VisualWorks it was < 5% over a wide range of benchmarks (e.g. real benchmarks such as recompile the system).
> >
> Yes i remember this number.
> But, lets pose the *right* question:
>  - guys we have extra 5% of performance to waste,
> what feature you would like to spend it on?

It seems to me that some of the topics being discussed here might benefit
from empirical measurements. For example, a particular object header format
might have an effect on the speed of walking through the object memory heap.
In such a case, it would be relatively easy to take measurements to estimate
the actual performance that might be expected without actually doing a complete
implementation. The process might look something like this:

- Trace an image to the desired new format. Do not worry about making it
functional, just make it good enough that objects in the traced image can
be reached with #objectAfter:

- Hack the interpreter code just enough to make #objectAfter: work with the
new object format. Do not worry about making a functional VM.

- Generate a new "VM" that gets just far enough to load the image into an
object memory. Turn off inlining when generating the "VM" so that a profiler
can see where the time is being spent. Arrange for the "VM" to go immediately
into a loop that walks through the object memory from firstAccessibleObject
to end of memory (see StackInterpreter>>allAccessibleObjectsOkay for example).
Loop for a few thousand iterations through the heap, then exit.

- Profile it (gprof). See where the time goes and how long it takes to run
to completion.

- Compare the results obtained with various object header strategies.

Experiments like this might produce some very useful insights. It would be a
lot of work for one person to do all the research on this, but it seems to me
that we now have quite a few interested and competent VM hackers who might be
willing to pitch in to obtain empirical data.

Any interest?


More information about the Vm-dev mailing list