On 10/18/07, Tim Ellison <[EMAIL PROTECTED]> wrote: > 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.
They look like a lot, I agree :-) but 2 out of 3 have been in development for some time. These are not new items as such. The 64 bit heap support is. > > Any reason why class unloading should not be default on now? Yes, no reason at all. HARMONY-4931 switches it on. > > Regards, > Tim > >
