harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Harmony Wiki] Update of "KnownNonBugIssuesAndLimitations" by Vladimir Beliaev
Date Fri, 15 Feb 2008 18:18:23 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Harmony Wiki" for change notification.

The following page has been changed by Vladimir Beliaev:
http://wiki.apache.org/harmony/KnownNonBugIssuesAndLimitations

------------------------------------------------------------------------------
  
  '''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.
  
- '''4. JVMTI agent thread should not be seen to thread group queries.'''[[BR]] According
to [http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#RunAgentThread JVMTI specification]
the thread group of the thread is ignored -- specifically, the thread is not added to the
thread group and the thread is not seen on queries of the thread group at either the Java
programming language or JVM TI levels.
+ '''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.
  
- '''5. Field sorting and field compaction are currently disabled.'''[[BR]] Class fields in
a Java heap can be ordered and aligned differently. This should be optimized for storage space
and access speed, see[http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/class_support/Class.cpp?view=co
vm/vmcore/src/class_support/Class.cpp]:49.
+ '''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.
  
- '''6. 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.
+ '''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.
  
- '''7. 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.
- 
- '''8. 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.
- 
- '''9. 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]]
  This is because tagging is implemented by storing tag pointer in object directly.
  
- '''10. Get rid of duplicated simple types definitions where applicable'''[[BR]]
+ '''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 
  or JVMTI. VM sources should preferably be cleared from non C, non JNI, or non JVMTI 
  types where applicable.
  
- '''11. Make native symbols lookup more optimal'''[[BR]]
+ '''9. Make native symbols lookup more optimal'''[[BR]]
  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.
  
- '''12. Get rid of two different ids for thread'''[[BR]]
+ '''10. Get rid of two different ids for thread'''[[BR]]
  There are two different ids for one thread now - one returned by java.lang.Thread.getId()
and the other returned by hythread_get_id(native thread). 
  They have to be the same. 
  

Mime
View raw message