harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] what's next?
Date Wed, 21 Jun 2006 00:41:47 GMT
On 6/20/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> On 6/20/06, Geir Magnusson Jr <geir@pobox.com> wrote:
> >
> > >Build and dependency issues aside, what are the next functional
> > >enhancements / features for DRLVM?
> >
> > >I think #1 is to get it to function with Java 5 classfiles, so we can
> > >make the switch throughout the project.
> >
> > Geir,
>
>   Good question. By next, I guess we mean in the relatively
> near future...Some thoughts that come to mind in addition to 1.5 are:
>  1. We should start running classlibraries and existing api tests against
> the DRLVM bits. This is sure to identify bugs/issues that will need
> addressing.
>  2. We need to achieve completeness in the DRLVM VM functionality.....we
> don't handle stack overflows well, efficient unmanagd heap management
> issues, there is functional completenes needed in the verifier, optimized
> locks( thin, deflatable, jit optimized ), improvements in JVMTI support as
> Gregory points out.
>  3. In garbage collection, one thread that Weldon has already started is
> MMTk integration which looks promising, but while we finish that work, it
> may also make sense to substitute the existing rudimentary GC with a more
> functional one with better performance that can work as the default GC
> outside the MMTk integrated suite.

+1  (+2 if we port an existing gc from another jvm)

> 4. We should also look at enhancements to the JITs ...and other than support
> for new platforms ( 64 bit , down level platforms that support x87 but not
> SSE* instructions..based on the minimum machine model we want to support eg
> a pentium III running Windows/Linux )some of this work would benefit from
> performance guidance...helpers should be inlined, some of the
> optimizations eg., devirtualization perfected, polling to support
> collection should consume less overhead, more optimized JNI invocation at
> some point.

This brings up a good point.  Performance is important but the subject
of this thread is, "...what are the next functional enhancements?"
Should the scope be broadened to include performance goals?  If true,
perhaps start a discussion on this topic.


> 5. This is also in reference to the other thread you started about goals for
> Harmony, it may help to establish some vectors that are important for us in
> Harmony eg., among...1.5 and TCK compatibility, performance( benchmarking ),
> startup time, memory footprint, and that in some sense will determine the
> priorities. The  work to be done will fall out of this.
>
> Feedback most welcome :-)
>
> Thanks,
> Rana
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message