[drlvm] Development plan (was: Re: [drlvm] dynamic object layout)

[Robin Garner <ro...@anu.edu.au>]

> We have a really difficult job to do in the next 7.5 months - to get to
> a compatible 1.0* - so I'd like to encourage people to remain as focused
> as we can to get to that point.  That doesn't mean this isn't fun, but
> the way I see it, we have a few focused months of efforts before we
> begin TCK testing, and we probably need to make some hard choices to
> delay stuff.  We're a mighty community, but a relatively small one, so
> the more of us rowing in the same direction, the better.

Is there a planned set of performance features for the 1.0 release of
harmony/DRLVM ?  I've had a quick look and can't seem to find it.  From
where I sit, reading (bits of) the mailing list, performance tweaks seem
to be thrown into the mix as people think of them rather than in a
coordinated way.  I hope I'm wrong, and that somewhere there is a plan :)

It would be good to see a list of the features that people see as being
critical to improving DRLVM's performance, and to be able to contribute to
it as a whole, rather than just on a point by point basis.

One resource I would also like to see developed is an archive of
performance feature tests, so that we can refer to an empirical record of
the cost/benefit of certain changes (for example, the cost of adding an
additional word to the object header).  Making this available, along with
patches that would allow the experiment to be reproduced seems to me like
it would be valuable.

Where this connects specifically with the 'dynamic object layout' thread
is that I was wondering what the cost of DRLVM's object model is, vs one
where the fields of all objects/arrays are at a fixed offset from the
object pointer.  This kind of object model makes adding header fields (at
the start of the object) trivial, and I'm thinking it might help
performance too.

cheers,
Robin

Re: [drlvm] Development plan

["Geir Magnusson Jr." <ge...@pobox.com>]

Robin Garner wrote:
>> We have a really difficult job to do in the next 7.5 months - to get to
>> a compatible 1.0* - so I'd like to encourage people to remain as focused
>> as we can to get to that point.  That doesn't mean this isn't fun, but
>> the way I see it, we have a few focused months of efforts before we
>> begin TCK testing, and we probably need to make some hard choices to
>> delay stuff.  We're a mighty community, but a relatively small one, so
>> the more of us rowing in the same direction, the better.
> 
> Is there a planned set of performance features for the 1.0 release of
> harmony/DRLVM ?  I've had a quick look and can't seem to find it.  From
> where I sit, reading (bits of) the mailing list, performance tweaks seem
> to be thrown into the mix as people think of them rather than in a
> coordinated way.  I hope I'm wrong, and that somewhere there is a plan :)
> 
> It would be good to see a list of the features that people see as being
> critical to improving DRLVM's performance, and to be able to contribute to
> it as a whole, rather than just on a point by point basis.
> 

Sure - we've done two iterations of this in a rather informal way, but 
up until recently, we've had a major influx of new donations that were 
helping make DRLVM complete.

In the last two months or so, we've done a good job transitioning to no 
bulk donations, all individual contributions, and many small (and some 
large) nips and tucks working on bugs.

For example, the recent efforts to get the DRLVM + classlib to pass the 
classlib unit tests is one such example.

I think I'd characterize our efforts right now as "stabilization", but 
it certainly would be good to start listing the feature set that people 
believe is needed going forward to making DRLVM compatible, stable and 
performant, in that order.

> One resource I would also like to see developed is an archive of
> performance feature tests, so that we can refer to an empirical record of
> the cost/benefit of certain changes (for example, the cost of adding an
> additional word to the object header).  Making this available, along with
> patches that would allow the experiment to be reproduced seems to me like
> it would be valuable.

Yes - we've have been going that direction for a while.  We have the 
"build-test" infrastructure that has been slowly augmented, and there is 
the harmonytest.org as a good start for collection.

> 
> Where this connects specifically with the 'dynamic object layout' thread
> is that I was wondering what the cost of DRLVM's object model is, vs one
> where the fields of all objects/arrays are at a fixed offset from the
> object pointer.  This kind of object model makes adding header fields (at
> the start of the object) trivial, and I'm thinking it might help
> performance too.

Both would be good.  I think Weldon's point was simply that we need to 
be careful and deliberate about making such core changes in light of our 
quest for compatibility, stability and performance.

Right now, I'm reasonably satisfied with performance, and am worried 
about compatibility and stability.  A commercial-grade, production-ready 
VM is our goal right now.

geir