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 <[EMAIL PROTECTED]> wrote:
On 6/20/06, Geir Magnusson Jr <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Andrey Chernyshev Intel Middleware Products Division
