> 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
