harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Chernyshev" <a.y.chernys...@gmail.com>
Subject Re: [drlvm] what's next?
Date Wed, 28 Jun 2006 17:05:31 GMT

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?


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
View raw message