Differences between revisions 28 and 29
Revision 28 as of 2008-09-04 01:31:58
Size: 6196
Editor: LigangWang
Comment: None of spec of JVM/JavaLan/JVMTI requires two IDs to be same and no real issue.
Revision 29 as of 2009-09-20 21:55:29
Size: 6208
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
'''1. Stack tracing/dumping is half-dead.'''[[BR]] Post-mortem stack trace is printed on Linux@ia32 only; thread dump (as printed out on "Ctrl-\" or "Ctrl-Break") lacks thread info (e.g. name, group, monitors held, etc) and skips native threads; some (inlined) methods may be missing in reported exception stacks. In general, this area has a lot of broken or half-made code and needs big cleanup & refactoring. '''1. Stack tracing/dumping is half-dead.'''<<BR>> Post-mortem stack trace is printed on Linux@ia32 only; thread dump (as printed out on "Ctrl-\" or "Ctrl-Break") lacks thread info (e.g. name, group, monitors held, etc) and skips native threads; some (inlined) methods may be missing in reported exception stacks. In general, this area has a lot of broken or half-made code and needs big cleanup & refactoring.
Line 3: Line 3:
'''2. When OOME is thrown it has no stack trace.''' [[BR]]OOME object is pre-allocated and contains no stack trace. When OOME condition is detected, the pre-allocated object is used, and no stack trace elements are created. So, OOME always has a null stack trace. '''2. When OOME is thrown it has no stack trace.''' <<BR>>OOME object is pre-allocated and contains no stack trace. When OOME condition is detected, the pre-allocated object is used, and no stack trace elements are created. So, OOME always has a null stack trace.
Line 5: Line 5:
'''3. JVMTI API functions should not call Java code.'''[[BR]] If JVMTI functions call some Java code directly, like it is done currently in [http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#GetThreadInfo GetThreadInfo] function, or indirectly, like using JNI [http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/functions.html#wp16027 FindClass], it may easily lead to infinite recursion. Calling Java code may result in some JVMTI events, which call agent callbacks, and these callbacks may use the same JVMTI API functions again. A workaround to this problem may be to disable any JVMTI events when calling Java code. A better solution would be not to call any Java code from JVMTI functions. '''3. JVMTI API functions should not call Java code.'''<<BR>> If JVMTI functions call some Java code directly, like it is done currently in [[http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#GetThreadInfo|GetThreadInfo]] function, or indirectly, like using JNI [[http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/functions.html#wp16027|FindClass]], it may easily lead to infinite recursion. Calling Java code may result in some JVMTI events, which call agent callbacks, and these callbacks may use the same JVMTI API functions again. A workaround to this problem may be to disable any JVMTI events when calling Java code. A better solution would be not to call any Java code from JVMTI functions.
Line 7: Line 7:
'''4. JNI function [http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/functions.html#ensure_local_capacity EnsureCapacity] always returns success.''' [[BR]]This function according to the specification ensures that at least some numbers of local references can be allocated. But in fact this function doesn't do anything, it always returns success. It looks like this function is actually obsolete and RI allows allocating any number of local references regardless of whether their number was ensured or not. '''4. JNI function [[http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/functions.html#ensure_local_capacity|EnsureCapacity]] always returns success.''' <<BR>>This function according to the specification ensures that at least some numbers of local references can be allocated. But in fact this function doesn't do anything, it always returns success. It looks like this function is actually obsolete and RI allows allocating any number of local references regardless of whether their number was ensured or not.
Line 9: Line 9:
'''5. JVMTI functions don't check for invalid jmethodID arguments.'''[[BR]] According to the specification, functions accepting such arguments should return {{{JVMTI_ERROR_INVALID_METHODID}}}. But there is no easy method to check these identifiers for validness since in DRLVM these are just heap pointers to {{{Method}}} type structs. To check these values correctly, keep a cache of all loaded methods. '''5. JVMTI functions don't check for invalid jmethodID arguments.'''<<BR>> According to the specification, functions accepting such arguments should return {{{JVMTI_ERROR_INVALID_METHODID}}}. But there is no easy method to check these identifiers for validness since in DRLVM these are just heap pointers to {{{Method}}} type structs. To check these values correctly, keep a cache of all loaded methods.
Line 11: Line 11:
'''6. JVMTI functions which get/set local variables don't check for variable type.'''[[BR]] Functions like [http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#GetLocalObject GetObjectField] should return {{{JVMTI_ERROR_TYPE_MISMATCH}}} if they are called for a local variable, which is not a type object. To implement it, create type maps for all methods, either verifier or JIT can do this. Note, that this requires some interface for JVMTI. '''6. JVMTI functions which get/set local variables don't check for variable type.'''<<BR>> Functions like [[http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#GetLocalObject|GetObjectField]] should return {{{JVMTI_ERROR_TYPE_MISMATCH}}} if they are called for a local variable, which is not a type object. To implement it, create type maps for all methods, either verifier or JIT can do this. Note, that this requires some interface for JVMTI.
Line 13: Line 13:
'''7. JVMTI capability can_tag_objects can only be requested at OnLoad phase, and by at most one environment.'''[[BR]] '''7. JVMTI capability can_tag_objects can only be requested at OnLoad phase, and by at most one environment.'''<<BR>>
Line 16: Line 16:
'''8. Get rid of duplicated simple types definitions where applicable'''[[BR]]
The content of [
http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/vm/include/open/types.h?view=markup open/types.h] should be freed from types duplicated in JNI
'''8. Get rid of duplicated simple types definitions where applicable'''<<BR>>
The content of
[[http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/vm/include/open/types.h?view=markup|open/types.h]] should be freed from types duplicated in JNI
Line 21: Line 21:
'''9. Make native symbols lookup more optimal'''[[BR]] '''9. Make native symbols lookup more optimal'''<<BR>>
Line 31: Line 31:
If the issue is not valid, please remove it.[[BR]] If the issue is not valid, please remove it.<<BR>>
Line 34: Line 34:
After this check we can add the up-to-date issues to the [http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/README.txt?view=co README file] to save important info. After this check we can add the up-to-date issues to the [[http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/README.txt?view=co|README file]] to save important info.
Line 37: Line 37:
'''1.''' In certain cases, the following error might be produced:[[BR]]
{{{java.lang.InternalError: Error -1 getting next zip entry}}}[[BR]]
The error might appear during compilation of the kernel classes in a Harmony self-hosting environment due to the problems with the zip support module. A simple workaround is to restart the build or build the kernel classes separately by using the following command:[[BR]]
'''1.''' In certain cases, the following error might be produced:<<BR>>
{{{java.lang.InternalError: Error -1 getting next zip entry}}}<<BR>>
The error might appear during compilation of the kernel classes in a Harmony self-hosting environment due to the problems with the zip support module. A simple workaround is to restart the build or build the kernel classes separately by using the following command:<<BR>>
Line 59: Line 59:
'''4.''' The following methods have no effect:[[BR]]
{{{Runtime.traceInstructions(bool)}}}[[BR]]
{{{Runtime.traceMethodCalls(bool)}}}[[BR]]
'''4.''' The following methods have no effect:<<BR>>
{{{Runtime.traceInstructions(bool)}}}<<BR>>
{{{Runtime.traceMethodCalls(bool)}}}<<BR>>

1. Stack tracing/dumping is half-dead.
Post-mortem stack trace is printed on Linux@ia32 only; thread dump (as printed out on "Ctrl-\" or "Ctrl-Break") lacks thread info (e.g. name, group, monitors held, etc) and skips native threads; some (inlined) methods may be missing in reported exception stacks. In general, this area has a lot of broken or half-made code and needs big cleanup & refactoring.

2. When OOME is thrown it has no stack trace.
OOME object is pre-allocated and contains no stack trace. When OOME condition is detected, the pre-allocated object is used, and no stack trace elements are created. So, OOME always has a null stack trace.

3. JVMTI API functions should not call Java code.
If JVMTI functions call some Java code directly, like it is done currently in GetThreadInfo function, or indirectly, like using JNI FindClass, it may easily lead to infinite recursion. Calling Java code may result in some JVMTI events, which call agent callbacks, and these callbacks may use the same JVMTI API functions again. A workaround to this problem may be to disable any JVMTI events when calling Java code. A better solution would be not to call any Java code from JVMTI functions.

4. JNI function EnsureCapacity always returns success.
This function according to the specification ensures that at least some numbers of local references can be allocated. But in fact this function doesn't do anything, it always returns success. It looks like this function is actually obsolete and RI allows allocating any number of local references regardless of whether their number was ensured or not.

5. JVMTI functions don't check for invalid jmethodID arguments.
According to the specification, functions accepting such arguments should return JVMTI_ERROR_INVALID_METHODID. But there is no easy method to check these identifiers for validness since in DRLVM these are just heap pointers to Method type structs. To check these values correctly, keep a cache of all loaded methods.

6. JVMTI functions which get/set local variables don't check for variable type.
Functions like GetObjectField should return JVMTI_ERROR_TYPE_MISMATCH if they are called for a local variable, which is not a type object. To implement it, create type maps for all methods, either verifier or JIT can do this. Note, that this requires some interface for JVMTI.

7. JVMTI capability can_tag_objects can only be requested at OnLoad phase, and by at most one environment.
This is because tagging is implemented by storing tag pointer in object directly.

8. Get rid of duplicated simple types definitions where applicable
The content of open/types.h should be freed from types duplicated in JNI or JVMTI. VM sources should preferably be cleared from non C, non JNI, or non JVMTI types where applicable.

9. Make native symbols lookup more optimal
Currently the native symbols are resolved in reverse order for registered libraries (i.e. newly loaded lib is prepended to the list). So vmcore.dll is always requested in the last place. Besides, on Windows OS-specific mangling is tried as a last resort. Therefore, most native functions during startup are found in a least effective way.


?KNOWN ISSUES?

Please look through the issues mentioned below to determine their validity.

If the issue is not valid, please remove it.
If the issue is valid, please mark it +1.

After this check we can add the up-to-date issues to the README file to save important info.

Building in a self-hosting environment:

1. In certain cases, the following error might be produced:
java.lang.InternalError: Error -1 getting next zip entry
The error might appear during compilation of the kernel classes in a Harmony self-hosting environment due to the problems with the zip support module. A simple workaround is to restart the build or build the kernel classes separately by using the following command:
build.bat -DCOMPONENTS=vm.kernel_classes

General restrictions:

1. The number of threads must be lower than 800.

2. Java heap memory must not be greater than 1.3 GB.

3. Code must not enter the same monitor more than 256 times.

4. The real object hash code has only 6 bits.

Partially implemented features:

1. JVMTI implementation does not provide full argument validity checks. Specifically, the VM might crash when passing invalid Java objects or JNI identifiers as arguments to JVMTI API functions.

2. JVMTI API function groups for local variable access and stack inspection in the JIT-enabled mode have not been tested for adequate operation.

3. Tracing of method calls and instructions is not supported.

4. The following methods have no effect:
Runtime.traceInstructions(bool)
Runtime.traceMethodCalls(bool)

5. The java.lang.ref.SoftReference class implementation does not follow the intent of the specification and is currently equivalent to the java.lang.ref.WeakReference class.

Jitrino restrictions:

1. Parallel compilation and calls for resolution during a compilation session may lead to re-entering Jitrino from different or the same hread. In our experience, Jitrino works normally in such cases. However, certain Jitrino parts, such as timers and certain logging system features are not designed to be re-enterable. This restriction is not applicable to normal runs in the default mode with logging and timers disabled.

KnownNonBugIssuesAndLimitations (last edited 2009-09-20 21:55:29 by localhost)