harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Shimansky (JIRA)" <j...@apache.org>
Subject [jira] Created: (HARMONY-1534) [drlvm] [jvmti] Fixed initialization of JVMTI property, access to local variables in JIT mode and removed wrong assertion for single step start
Date Thu, 21 Sep 2006 23:23:24 GMT
[drlvm] [jvmti] Fixed initialization of JVMTI property, access to local variables in JIT mode
and removed wrong assertion for single step start
-----------------------------------------------------------------------------------------------------------------------------------------------

                 Key: HARMONY-1534
                 URL: http://issues.apache.org/jira/browse/HARMONY-1534
             Project: Harmony
          Issue Type: Improvement
            Reporter: Gregory Shimansky


This small patch fixed the following bugs in JVMTI

- It used to be interpreter the default mode when JVMTI is enabled because JIT functionality
was not implemented to a usable extent. When JVMTI was enabled on the command line interpreter
was enabled automatically. Later then it was required to create a special property for JIT,
it was added just in the place where interpreter property was set. But this isn't really correct
since if -Dvm.use_interpreter property is specified explicitly on the command line then JVMTI
vm.jvmti_enabled property ins't set. The fix just removes check for interpreter property because
now we're trying to fully support JVMTI in both JIT and interpreter modes.

- Getting and setting local variables in JIT mode  is fixed. The null reference case was not
handled correctly in the code. A reference which has a null object is not allowed in drlvm,
it should be a null pointer or a heap pointer which is contained inside of a reference. The
ugly interface with JIT always requires a pointer, so setting a null reference for it requires
creating a local pointer pointing to a null :)

- When starting and stopping single step when all threads are suspended thread manager iterator
sometimes gives out threads with null vm_thread (VM TLS pointer). It appears that these threads
are just started ones. So there is no need for assertion that threads is not alive (in thread
manager terms it is alive, just birthing). So I've removed assertions and added comments.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message