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, 28 Jun 2006 18:27:59 GMT
Hi Andrey,

I think all of what you propose is worth doing.  Some of the items
might be low priority since they don't directly map to a requirement
or spec.  It seems 3, 4, 6 and 7 fall in the low priority category.

Some additional observations:

3) Eliminate C++ exceptions support is a good idea for several
reasons.  First, operating systems traditionally avoid implementing in
C++.  Eliminating C++ from DRLVM will make it more conducive to VM/OS
integration.  Second, there is the possibility that JVM implementation
will migrate to Java.  In other words, the parts of the VM that need
"C++" features might end up being rewritten in Java and using Java
exception handling.  Bottom line: mix/matching Java/C/C++ inside the
VM is a burden with a small long term payback.

4) This item becomes much simpler if C++ code is re-coded in Java.

On 6/28/06, Andrey Chernyshev <a.y.chernyshev@gmail.com> wrote:
> Hello,
> In addition to the already proposed generic tasks like 5.0 support or
> concurrent GC mentioned by Ivan, I'd like to add some more specific
> things that might be interesting for people to look at as well:
> (1) Complete Java bytecode verifier
> Class structure verification and subroutines (e.g. finally blocks) has
> to be added to the bytecode verifier in order to make it
> full-functional (as required by JVMS spec).
> (2) Handling out of C memory conditions
> VM must throw OutOfMemoryException when there is a lack of C memory.
> For example, if local or global handle cannot be allocated then OOME
> should be thrown ¨C OutOfMemoryException must be thrown (this is
> required by JNI/JVMTI spec).
> (3) Eliminate C++ exceptions support
> §³urrently some parts of VM and native part of kernel classes are
> complied with C++ exception support which gives an extra overhead. One
> of the issues is that some parts are using MS implementation of STL
> which requires C++ exception support. MS STL has to be replaced with
> something else.
> (4) Destructive stack unwinding - perhaps it needs to be eliminated from VM.
> In certain cases VM performs stack unwinding up to the nearest M2N
> frame and just jumps to that point. If some C++ objects are available
> on stack, destructors for these objects won't be called. This may
> affect VM stability under stress conditions.
> (5) Unicode support
> Currently VM doesn't support classes/field/names which utilize
> character other than ASCII. Handling of the Unicode names will likely
> be needed for certification. This impacts class loader, natives
> support, JNI and JVMTI components. Another issue is that VM would not
> understand the command line args (like class name and start arguments)
> if they are written with unicode characters.
> (6) String internal implementation could be moved to Java.
> Internal representation of strings is currently kept in the native
> class loading code (string pool). To enable efficient resource
> deallocation, they better be moved to Java code such that GC/class
> unloading can operate with strings more efficiently.
> (7) Unify C Memory management.
> Native memory is currently allocated in DRLVM by ~10 different means
> at different places. Some of examples are using APR memory pools, C
> mallocs, C++ new operator e.t.c. This complicates the communication
> between the different modules within DRLVM since there is no
> consideration how to deallocate the memory being allocated by other
> component and may trigger memory leaks in the system.
> I wonder if there could be any ideas how the memory management
> approach could be unified in the DRLVM? It may also help to monitor
> and eliminate possible memory leaks in the system.
> (8) Complete JNI and JVMTI implementations.
> JNI and JVMTI specs are currently not completely implemented. For
> example, JNI is missing weak references implementation, invocation
> API. JVMTI is missing RedefineClasses function.
> ...
> There certainly other gaps which I'm not aware of ;)
> Any thoughts which of the above could be worth doing?
> Thanks,
> Andrey.
> On 6/21/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.
> > 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.
> > 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
> >
> >
> --
> Andrey Chernyshev
> Intel Middleware Products Division

Weldon Washburn
Intel Middleware Products Division
View raw message