Rana Dasgupta wrote: > Before deciding on a duration, or posting plans on the Wiki, it may be > worthwhile to list some of the items that we want to do before the > next rollout...The duration would possibly fall out of that? With some > of these, we could either stretch the duration to whatever is adequate > if we want the feature, or branch the tree if we need to some time > before release. Here are some DRLVM features that would be good to > finish. > > 1. Improve 64 bit support ( eg., supporting heapsizes upto native > limit instead of compressed heaps only ), and enabling better > performance and code generation for compressed heaps. This is a > largish item. > > 2. Cocurrent GC. Xiao Feng could add some estimate of dev work, but > it's not small. > > 3. The threading changes that Weldon and Pavel Rebiry have been doing. > Another biggish item. > > 4. Class unloading needs no new work, other than bug fixes as we find them. > > 5. Some more work on magic classes? How much? > > 6. Some bugs/subfeature needs that have been sitting in JIRA for a > while, eg., non local lock inflation to unblock applications like > Resin > > There are similarly, several classlibrary items, I am sure.
I would suggest it is optimistic to attempt to stabilize three+ major pieces of work in a single iteration. Any reason why class unloading should not be default on now? Regards, Tim
