Tim wrote (re: GC changes):
It's an issue of time. I tried testing out the changes (which seem to function adequately from the limited testing I managed to do) but there appeared to be a massive performance hit.
I just verified it and like I suspected, the performance hit has absolutely nothing to do with the GC changes. We lost a decent amount of speed somewhere - anyone having ideas? Here are the micro benchmarks from my machine:
3.7.1: ~200,000,000 bytecodes/sec; 5,800,000 sends/sec' 3.8.1: ~150,000,000 bytecodes/sec; 5,000,000 sends/sec'
(this is fairly consistent, regardless of whether the GC changes are applied or not)
Second issue is _my_ time of course. I have fulltime work right now on a quite different issue and plenty of 'spare time' things that have to be done, like most of us.
No problem. Just as long as we share a repository - it is only problematic because things somehow "get to you" and then at some point you point to a new version at your website and that process isn't very transparent. If we'd use a shared repository (squeaksource?) we could fold in changes as we see fit and then have a place where it's clear what the latest version is.
Third issue is that Ian pretty much has the vm baton right now to do whatever the next step of 64bitting is; I imagine getting some C type stuff in to make an equivalent >2Gb address fix for Ned's earlier code is among the work. Now you control that somewhat, being his leader. Once that is passed back I can try to get on with dealing with the gc code changes etc. I was hoping to be with you dealing with this right now but that damn passport still hasn't arrived.
I talked to Ian - as far as he is concerned the changes are finished. There is still lots of stuff to be done but this falls into the responsibility of either the VM or the plugin maintainer (like, for example, making the LargeInt plugin work on 64bit).
Cheers, - Andreas