Index: docs/subcomponents/drlvm/JVMTI-PopFrame.html =================================================================== --- docs/subcomponents/drlvm/JVMTI-PopFrame.html (revision 0) +++ docs/subcomponents/drlvm/JVMTI-PopFrame.html (revision 0) @@ -0,0 +1,545 @@ + + + + + + + + + + + + + + + + + + + + + + + + Apache Harmony - JVMTI Implementation of Pop Frame + + + + + + + + + + + + + +
+ + +
+ +Apache Harmony +
+
+
+ + + + + + + + + + + + +
+
+
+

+ JVMTI Pop Frame +

+

+ Here is a description of how popping a frame is currently + implemented in the DRLVM tool interface (JVMTI). For a + definition of the pop frame functionality, consult the JVMTI + specification [1]. For generic + information on JVMTI in the DRL virtual machine and for definition + of related terms, see the developer's + guide. +

+ +

+ Introduction +

+ +

Popping a stack frame becomes necessary when execution is in a native + function and a managed-to-native + frame (M2nFrame) is on the stack. This means that the JVMTI + component pops the M2nFrame and the Java frame above it. A frame is popped + each time the JVMTI function PopFrame() is + called. The current pop-frame implementation is based on the exception + handling mechanism for transferring execution control. This way, VM pops + frames on the current thread only. To pop frames on other threads, VM + uses the M2nFrame flag system and callbacks.

+ + +

+ How to Pop a Frame +

+ +

To pop a frame on the current thread, refer to the following core + functions: +

+ + + + + + + + + + + + + + + + + +
+ + Function Name + + + Role +
+ + + jvmti_jit_prepare_pop_frame + + + + + Finds register context for the previous frame using the + stack iterator. +
+ + + jvmti_jit_complete_pop_frame + + + + + Transfers control to the saved register context for the + popped frame. + +
+ + + jvmti_ji_do_pop_frame + + + + + Transfers control to the previous frame. This function is + a simple and fast combination of sequential calls of + jvmti_jit_prepare_pop_frame and + jvmti_jit_complete_pop_frame. + +
+

The state of a frame with regard to popping is indicated in the + frame_type + field. This field can have the following values:

+ + + + + + + + + + + + + + + + + + + + + +
+ + Flag Name + + + + Meaning +
+ + + FRAME_UNPOPABLE + + + + + The frame cannot be popped. + +
+ + + FRAME_POPABLE + + + + + The frame can be popped but is not. + +
+ + + FRAME_POP_NOW + + + + + The frame is popped and the state of VM can be + unpredictable and unexpected. JVMTI cannot work in this + state and waits until the popped frame is resumed and the + frame state is changed. + +
+ + + FRAME_POP_DONE = + FRAME_POPABLE |FRAME_POP_NOW + + + + + The frame is popped now but VM state is OK and JVMTI can + work without thread resume. + +
+

+ In the current implementation, popping a frame goes in the + following way: +

+
    +
  1. + VM suspends the popped thread in one of these functions: + thread_suspend_disable() or in hythread_safe_point(). +
  2. +
  3. + The JVMTI Agent calls PopFrame() and does the following: +
      +
    1. + Checks that the flag for the topmost M2nFrame is set to FRAME_POPABLE, + which means that the frame can be popped. +
    2. +
    3. + Changes the flag + to FRAME_POP_NOW. +
    4. +
    5. + Sets the safe point for the callback function. The suspended thread + executes the callback while staying in the function where the + thread is suspended. +
    6. +
    +
  4. +
  5. + The callback + function pops the frame in one of the following ways depending on + the function and on area of the stack: +
      +
    1. + For hythread_safe_point(): +
        +
      1. + VM finds the register + context for the previous frame and saves it in the current M2nFrame. + The frame type flag changed to FRAME_POP_DONE. +
      2. +
      3. + VM exits the safe point and checks the frame status. If + the frame is popped, VM transfers control to the saved register + context. Otherwise, VM exits normally. +
      4. +
      +
    2. +
    3. + For the suspend_disable() function in an + unwindable + area of the stack + : +
        +
      1. + The callback explicitly calls hythread_safe_point() to + stop the current thread in the safe point and wait until + the thread is resumed by another thread. +
      2. +
      3. + When the thread is resumed, the callback pops the frame + for the current thread and transfers control to the previous + frame. +
      4. +
      +
    4. +
    5. + For the suspend_disable() function in a + non-unwindable + area of the stack + : +
        +
      1. + VM raises a special exception object and waits for the end + of the area. +
      2. +
      3. + After exiting the area, VM checks whether the exception + is set and pops the frame for the current thread and transfers + control to the previous frame. +
      4. +
      +
    6. +
    +
  6. +
+ + +

+ Implementation Specifics +

+ +
    +
  • Because the implementation re-uses the exception scheme, popping + a frame does not transfer control to the beginning of the bytecode + invoke instruction, but to the native call instruction. This is possible + because the JIT compiles an invoke instruction into + several native instructions including the call.
    + A better way of handling the operation is to make VM transfer + control to the beginning of the invoke instruction block.
  • +
  • In the exception handling mechanism, control is returned to the + instruction pointer (IP) after the call instruction. This way, VM + must find the call IP of the previous instruction by using + information on JIT calling conventions.
    +It is advisory to move the corresponding functionality to JIT so that VM has no data +on JIT calling conventions.
  • +
  • Object references in popped frames can become outdated during + garbage collection because VM components do not enumerate the stack + for such frames. For GC purposes, JVM TI enumerates popped frames + until the thread is resumed and control is transferred.
  • +
  • Due to specifics of the current thread manager implementation, + the pop frame cannot guarantee synchronization of thread-suspend + states across different threads. This way, if Thread A suspends + Thread B, the current implementation cannot guarantee that Thread + B is not resumed by another thread. In such a situation, operation of + Thread A can be unstable because it relies on Thread B being + suspended.
  • +
+ + +

+ Related Information +

+ +

[1] JVM + Tool Interface Specification, http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html

+ +

Back to top

+ +
+
+
+
+ Copyright © 2003-2006, The Apache Software Foundation +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + Index: xdocs/subcomponents/drlvm/JVMTI-PopFrame.xml =================================================================== --- xdocs/subcomponents/drlvm/JVMTI-PopFrame.xml (revision 0) +++ xdocs/subcomponents/drlvm/JVMTI-PopFrame.xml (revision 0) @@ -0,0 +1,263 @@ + + + + + JVMTI Implementation of Pop Frame + Harmony Documentation Team + + + + +
+

+ Here is a description of how popping a frame is currently + implemented in the DRLVM tool interface (JVMTI). For a + definition of the pop frame functionality, consult the JVMTI + specification [1]. For generic + information on JVMTI in the DRL virtual machine and for definition + of related terms, see the developer's + guide. +

+ + +

Popping a stack frame becomes necessary when execution is in a native + function and a managed-to-native + frame (M2nFrame) is on the stack. This means that the JVMTI + component pops the M2nFrame and the Java frame above it. A frame is popped + each time the JVMTI function PopFrame() is + called. The current pop-frame implementation is based on the exception + handling mechanism for transferring execution control. This way, VM pops + frames on the current thread only. To pop frames on other threads, VM + uses the M2nFrame flag system and callbacks.

+
+ +

To pop a frame on the current thread, refer to the following core + functions: +

+ + + + + + + + + + + + + + + + + +
+ Function Name + Role
+ jvmti_jit_prepare_pop_frame + + Finds register context for the previous frame using the + stack iterator.
+ jvmti_jit_complete_pop_frame + + Transfers control to the saved register context for the + popped frame. +
+ jvmti_ji_do_pop_frame + + Transfers control to the previous frame. This function is + a simple and fast combination of sequential calls of + jvmti_jit_prepare_pop_frame and + jvmti_jit_complete_pop_frame. +
+

The state of a frame with regard to popping is indicated in the + frame_type + field. This field can have the following values:

+ + + + + + + + + + + + + + + + + + + + + +
+ Flag Name + + Meaning
+ FRAME_UNPOPABLE + + The frame cannot be popped. +
+ FRAME_POPABLE + + The frame can be popped but is not. +
+ FRAME_POP_NOW + + The frame is popped and the state of VM can be + unpredictable and unexpected. JVMTI cannot work in this + state and waits until the popped frame is resumed and the + frame state is changed. +
+ FRAME_POP_DONE = + FRAME_POPABLE |FRAME_POP_NOW + + The frame is popped now but VM state is OK and JVMTI can + work without thread resume. +
+

+ In the current implementation, popping a frame goes in the + following way: +

+
    +
  1. + VM suspends the popped thread in one of these functions: + thread_suspend_disable() or in hythread_safe_point(). +
  2. +
  3. + The JVMTI Agent calls PopFrame() and does the following: +
      +
    1. + Checks that the flag for the topmost M2nFrame is set to FRAME_POPABLE, + which means that the frame can be popped. +
    2. +
    3. + Changes the flag + to FRAME_POP_NOW. +
    4. +
    5. + Sets the safe point for the callback function. The suspended thread + executes the callback while staying in the function where the + thread is suspended. +
    6. +
    +
  4. +
  5. + The callback + function pops the frame in one of the following ways depending on + the function and on area of the stack: +
      +
    1. + For hythread_safe_point(): +
        +
      1. + VM finds the register + context for the previous frame and saves it in the current M2nFrame. + The frame type flag changed to FRAME_POP_DONE. +
      2. +
      3. + VM exits the safe point and checks the frame status. If + the frame is popped, VM transfers control to the saved register + context. Otherwise, VM exits normally. +
      4. +
      +
    2. +
    3. + For the suspend_disable() function in an + unwindable + area of the stack + : +
        +
      1. + The callback explicitly calls hythread_safe_point() to + stop the current thread in the safe point and wait until + the thread is resumed by another thread. +
      2. +
      3. + When the thread is resumed, the callback pops the frame + for the current thread and transfers control to the previous + frame. +
      4. +
      +
    4. +
    5. + For the suspend_disable() function in a + non-unwindable + area of the stack + : +
        +
      1. + VM raises a special exception object and waits for the end + of the area. +
      2. +
      3. + After exiting the area, VM checks whether the exception + is set and pops the frame for the current thread and transfers + control to the previous frame. +
      4. +
      +
    6. +
    +
  6. +
+
+ + + +
    +
  • Because the implementation re-uses the exception scheme, popping + a frame does not transfer control to the beginning of the bytecode + invoke instruction, but to the native call instruction. This is possible + because the JIT compiles an invoke instruction into + several native instructions including the call.
    + A better way of handling the operation is to make VM transfer + control to the beginning of the invoke instruction block.
  • +
  • In the exception handling mechanism, control is returned to the + instruction pointer (IP) after the call instruction. This way, VM + must find the call IP of the previous instruction by using + information on JIT calling conventions.
    +It is advisory to move the corresponding functionality to JIT so that VM has no data +on JIT calling conventions.
  • +
  • Object references in popped frames can become outdated during + garbage collection because VM components do not enumerate the stack + for such frames. For GC purposes, JVM TI enumerates popped frames + until the thread is resumed and control is transferred.
  • +
  • Due to specifics of the current thread manager implementation, + the pop frame cannot guarantee synchronization of thread-suspend + states across different threads. This way, if Thread A suspends + Thread B, the current implementation cannot guarantee that Thread + B is not resumed by another thread. In such a situation, operation of + Thread A can be unstable because it relies on Thread B being + suspended.
  • +
+
+ + +

[1] JVM + Tool Interface Specification, http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html

+
+
+ +
\ No newline at end of file