harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: M4?
Date Fri, 19 Oct 2007 16:36:20 GMT
On 10/18/07, Tim Ellison <t.p.ellison@gmail.com> 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
>
>

Mime
View raw message