Return-Path: Delivered-To: apmail-harmony-commits-archive@www.apache.org Received: (qmail 21058 invoked from network); 8 Apr 2008 13:41:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 8 Apr 2008 13:41:24 -0000 Received: (qmail 80024 invoked by uid 500); 8 Apr 2008 13:41:24 -0000 Delivered-To: apmail-harmony-commits-archive@harmony.apache.org Received: (qmail 80010 invoked by uid 500); 8 Apr 2008 13:41:24 -0000 Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list commits@harmony.apache.org Received: (qmail 80000 invoked by uid 99); 8 Apr 2008 13:41:24 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Apr 2008 06:41:24 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.3] (HELO eris.apache.org) (140.211.11.3) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Apr 2008 13:40:38 +0000 Received: by eris.apache.org (Postfix, from userid 65534) id E11451A9844; Tue, 8 Apr 2008 06:40:56 -0700 (PDT) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r645916 [2/2] - in /harmony/standard/site: docs/subcomponents/drlvm/ docs/subcomponents/drlvm/images/ xdocs/subcomponents/drlvm/ xdocs/subcomponents/drlvm/images/ Date: Tue, 08 Apr 2008 13:40:48 -0000 To: commits@harmony.apache.org From: nadinem@apache.org X-Mailer: svnmailer-1.0.8 Message-Id: <20080408134056.E11451A9844@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Modified: harmony/standard/site/xdocs/subcomponents/drlvm/ThreadManager.html URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/subcomponents/drlvm/ThreadManager.html?rev=645916&r1=645915&r2=645916&view=diff ============================================================================== --- harmony/standard/site/xdocs/subcomponents/drlvm/ThreadManager.html (original) +++ harmony/standard/site/xdocs/subcomponents/drlvm/ThreadManager.html Tue Apr 8 06:40:43 2008 @@ -21,7 +21,7 @@ - + Thread Manager Description @@ -93,15 +93,16 @@ - - Initial version - - - Nadya Morozova, Andrey Chernyshev: document created. - - - June 5, 2006 - + Initial version + Nadya Morozova, Andrey Chernyshev: document created. + June 5, 2006 + + + Update 1 + Nadya Morozova, Pavel Rebriy: update of graphics + and text, Java* layer is now part of VM core, Porting component restructured, + all scenarios rewritten + March 20, 2008 @@ -218,9 +219,8 @@ Interfaces section below.

- Basic layers in the thread manager -

+ Basic layers in the thread manager

Figure 1: Threading Subsystem

@@ -240,8 +240,8 @@ [3] specifications
  • - Portable implementation mostly based on the Apache Porting Layer - [4] + Portable implementation mostly based on DRLVM and Apache Porting + Layers [4]
  • Compliance with the Harmony hythread interface [
  • - Monitor optimizations specific to the just-in-time (JIT) compiler - supplied with DRLVM -
  • + Optimizations specific to the just-in-time (JIT) compiler + supplied with DRLVM +

    - Thread Manager in VM + Thread Manager in DRLVM

    Figure 2 below demonstrates the interaction of the thread manager with @@ -266,25 +266,22 @@

  • The VM core to access information on object layout and for binding between java.lang.Thread objects and - appropriate native threads. For that, the thread manager queries - the thread_externals.h interface of the VM core. -
  • + appropriate native threads.
  • - The garbage collector to serve thread manipulation requests + The garbage collector (GC) to serve thread manipulation requests for root set enumeration and garbage collection activities. GC - works with the native layer of the thread manager. + works with the native and Java* layers of the thread manager.
  • The porting layer to interact with the underlying system and enable portability for threading. The TM - native layer queries functions of the APR interfaces and the - apr_thread_ext interface. + native layer queries functions of the PORT and APR interfaces.
  • - The just-in-time compiler to provide optimized threading + The just-in-time compiler (JIT) to provide optimized threading functions, called VM helpers, for JIT-compiled code. The thread manager exports this functionality via the - thread_helpers interface of the Java* + thread_helpers.h interface of the Java* layer.
  • @@ -301,17 +298,19 @@

    The thread manager code is mostly platform-independent and relies on the underlying porting layer to adjust to platform specifics. The - current TM implementation is written on top of the Apache Porting - Layer (APR) with certain extensions added to it. The - platform-dependent TM parts are the VM helpers package, which is tied - to the specific architecture, and the APR extensions package, which is - partially tied with the OS API. + current TM implementation is written on top of DRLVM and Apache Porting + Layers (APR). The + platform-dependent TM parts are the VM helpers' package, which is tied + to the specific architecture, and the porting layer extensions package, + which is partially tied with the OS API.

    - APR-based porting enables compilation of the thread manager code on - every platform where APR is available. The current version of the - thread manager supports the Linux* and Windows* IA-32 platforms. + DRLVM-based and APR-based porting layers enable compilation of the thread + manager code on every platform where porting is available. The current + version of the thread manager supports the Linux* and + Windows* OSes on x86 and x86_64 platforms, and Linux* OS on IA-64 + platforms.

    Back to Top @@ -340,7 +339,7 @@

    The native interface is inspired by the Harmony hythread module. This is a low-level layer that provides Java*-like threading functionality, such as interruption + href="#*">*-like native threading functionality, such as interruption support for waiting operations (for example, wait, park, join and sleep) and helps establish correct interaction of threads with the garbage collector. @@ -350,11 +349,11 @@ The native interface consists of the following function sets:

    - hythread.h + open/hythread.h

    - Functions of the hythread set [8] responsible for: + Consists of functions of the hythread set [8] responsible for the following:

    • @@ -374,11 +373,12 @@

    - hythread_ext.h + open/hythread_ext.h

    - Set of functions extending the hythread set responsible - for: + Includes the description of native thread structures and the set of functions + extending the hythread set + responsible for the following:

    • @@ -443,10 +443,10 @@ The functions of the Java* interface take Java* objects as parameters and can be easily used to implement kernel classes, JNI or JVMTI function sets. The Java* interface consists of 3 parts: + href="#*">* interface consists of the following parts:

      - jthread.h + open/jthread.h

      Functions supporting java.lang.Object and @@ -479,7 +479,7 @@

    - ti_thread.h + open/ti_thread.h

    Functions supporting various JVMTI functions and the @@ -508,13 +508,24 @@ Raw monitors -

    - thread_helpers.h +

    VM core interface

    +

    thread_manager.h

    +

    Includes the description of thread structures and functions providing + accesstors to them:

    +
      +
    • Accessors to Java* TM data
    • +
    • Attacher/detacher Java* thread.
    • +
    • Convertors from Java* to native and vise versa.
    • +
    +

    thread_helpers.h

    - Functions providing the stubs that help to optimize the performance - due to tighter TM and JIT integration. -

    + Consists of functions providing the assembly code stubs that help to optimize + the performance due to tighter TM and JIT integration:

    +
      +
    • Generator for Thread Local Storage (TLS) accessor
    • +
    • Generators for monitor functions
    • +

    Back to Top

    @@ -525,9 +536,8 @@ The thread manager data structures are typically not exposed: external VM components access these structures via opaque pointers instead. The pointers are defined in the public header files - hythread.h, hythread_ext.h, - jthread.h and ti_thread.h. Structures - themselves are described in the thread_private.h file. + hythread.h, jthread.h and ti_thread.h. + Structures themselves are described in the hythread_ext.h, and thread_manager.h files.

  • Function hythread_attach() registers the current - thread in the thread manager, so that threading operations can be - performed over this thread via the native layer. -
  • -
  • - Function jthread_attach() associates the current - thread with the appropriate java.lang.Thread object, - so that threading operations can be performed over this thread via - the Java* layer. + native thread in the thread manager, so that threading operations can + be performed over this thread via the native layer.
  • +
  • Function hythread_detach() unregisters the current native + thread.
  • +
  • Function jthread_attach() associates the current Java* thread + with the appropriate java.lang.Thread object, so that threading + operations can be performed over this thread via the Java* layer. +
  • +
  • Function jthread_detach() disjoins the current Java* thread + from the thread manager.
  • Depending on the attaching function, the thread manager operates with two types of threads: -

    +

    • Native thread attached to the native layer of the thread @@ -599,375 +611,8 @@ implementation-specific and is not exposed to other components.

      - The following figure shows the thread control structure of a native - attached thread described by the type HyThread: -

      -

      - Structure of a native thread not registered in TM -

      -

      - Figure 3: Native Thread -

      -

      - The following table lists the data fields making up the thread control - structure of a native thread: -

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      - Data Field - - Description -
      - Suspension -
      - IDATA - - suspend_request - - Number of suspend requests made for this thread. -
      - int16 - - suspend_disable_count - - Flag indicating that the thread can safely be suspended. -
      - hylatch_t - - safe_region_event - - Event used to notify interested threads when a thread enters a - safe region. -
      - hysem_t - - resume_event - - Event used to notify a suspended thread that it needs to wake - up. -
      - hythread_event_callback_proc - - safepoint_callback - - Function to be executed at a safe point on resuming a thread. -
      - Basic manipulation fields -
      - hythread_group_t - - group - - Group for this thread equal to the address of the head of the - list of threads for this group.
      - Groups are used to quickly iterate over lists of threads. - Examples: Java* threads, GC private threads. -
      - hythread_t - - next - - Pointer to the next thread within the group. -
      - hythread_t - - prev - - Pointer to the last thread within the group. -
      - apr_thread_t * - - os_handle - - Handle to the OS thread. -
      - void * - - private_data - - Placeholder for any data to be associated with this thread. The - Java* layer uses this field to store - Java-specific context. -
      - Boolean - - exit_request - - Flag indicating that a request to exit has been received. -
      - IDATA - - exit_value - - Exit value of this thread. -
      - Synchronization support -
      - hysem_t - - park_event - - Event for parking threads. -
      - hysem_t - - sleep_event - - Event for sleeping threads. -
      - hylatch_t - - join_event - - Event reserved for threads that invoke join. -
      - hycond_t - - current_condition - - Current conditional variable that the thread is waiting on. Used - for interrupting. -
      - State -
      - IDATA - - state - - Thread state. Holds thread state flags as defined in the JVMTI - specification [2] plus additional - flags. -
      - Attributes -
      - char * - - name - - Name of the thread, can be used for debugging. -
      - IDATA - - priority - - Hint to the scheduler about thread priority. -
      - IDATA - - daemon - - Checks whether this thread is a daemon. -
      - Other -
      - IDATA - - thread_id - - ID for this thread. The maximum number of threads is governed by - the size of the lock word record. See section Thin Monitors for details on the lock - word structure. -
      - apr_pool_t * - - pool - - Memory pool, where this thread is allocated. -
      - apr_threadattr_t * - - apr_attrs - - APR thread attributes. -
      - hythread_entrypoint_t - - start_proc - - Procedure that describes thread body to be executed. -
      - void * - - start_proc_args - - Arguments to be passed to the thread body. -
      - void * - - thread_local_storage - - Array representing the thread local storage. -
      - void * - - big_local_storage - - Extension to the standard local storage slot. -
      -

      - For details on thread control structures, see the - thread_private.h header file supplied with the source - bundle. -

      +For details on thread control structures, see Doxygen +documentation hosted on the website.

      Back to Top

      @@ -978,188 +623,18 @@

      A thread control structure of a Java* thread is defined by the JVMTIThread type and holds mostly JVMTI - information specific to that thread, as shown in Figure 4 below. + information specific to that thread, as shown in Figure 3 below.

      -

      +

      Structure of the Java* Attached thread

      - Figure 4: Java* Attached Thread + Figure 3: Java* Attached Thread

      - The following table lists the data fields making up the thread control - structure of a Java* thread: -

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      - Data Field - - Description -
      - JNIEnv * - - jenv - - JNI environment variable associated with this Java* thread. -
      - jthread - - thread_object - - The object jthread associated with - hythread_t. -
      - hycond_t - - monitor_condition - - Conditional variable used to wait/notify Java* - monitors. -
      - jthrowable - - stop_exception - - Exception to be thrown in a stopped thread. -
      - jlong - - blocked_time - - Time duration of the thread blocked on a monitor, in - nanoseconds. -
      - jlong - - waited_time - - Time duration of the thread waiting on a monitor, in - nanoseconds. -
      - JVMTILocalStorage - - jvmti_local_storage - - JVMTI local storage. -
      - jobject - - contended_monitor - - Monitor that this thread is blocked on. -
      - jobject - - wait_monitor - - Monitor that this thread is waiting on. -
      - jobject * - - owned_monitors - - Monitors owned by this thread. -
      - int - - owned_monitors_nmb - - The counter for the monitors owned by the thread. -
      - apr_pool_t * - - pool - - APR pool for this structure. -
      - jobject - - thread_ref - - Weak reference to the corresponding - java.lang.Thread instance. -
      -

      - For details on thread control structures, see the - thread_private.h header file supplied with the source - bundle. -

      -

      - The data structures associated with a thread attached to a - java.lang.Thread object and for a standalone (unattached) - thread are shown in Figures 3 and 4 respectively. -

      + For details on thread control structures, see Doxygen + documentation hosted on the website.

      Back to Top

      @@ -1171,14 +646,14 @@ for example, groups of Java* threads and GC threads not visible for Java* applications. Each thread maintained by the thread manager belongs to a specific thread group, - as shown in Figure 5. + as shown in Figure 4.

      Threads distributed into thread groups, for example a group of Java* threads and a group of GC threads

      - Figure 5: Thread Groups + Figure 4: Thread Groups

      The thread manager provides a set of functions for iterating over the @@ -1198,33 +673,32 @@ The thread manager synchronizers are functional modules used for thread synchronization. Certain synchronizers have internal data structures associated with them, others can only delegate function - calls to the appropriate synchronizers provided by APR. The current - implementation of synchronizers within the thread manager is based on - two fundamental primitives: the conditional variable and the mutex, as - shown in Figure 6. + calls to the appropriate synchronizers provided by the porting layer. The + current implementation of synchronizers within the thread manager is based + on two fundamental primitives: the conditional variable and the lock, + as shown in Figure 5.

      Implementing the thread synchronizer in TM

      - Figure 6: Components of the TM Synchronizer + Figure 5: Components of the TM Synchronizer

      The elements in the figure have the following meaning:

        -
      • - The APR conditional variable and APR mutex are basic primitives - provided by the Apache Portable Runtime. +
      • The conditional variable and lock are basic primitives + provided by the porting layer.
      • - The TM conditional variable and TM mutex wrap appropriate APR + The TM conditional variable and TM lock wrap appropriate porting primitives by adding the wait interruption support. These synchronizers also ensure that a thread enters the safe suspension mode when it is put into a wait state using the conditional variable or when the thread is blocked while - acquiring a mutex. + acquiring a lock.
      • The thin monitor is an inflatable lock @@ -1250,9 +724,9 @@

      - The above hierarchy is optimized for APR code re-use. Other + The above hierarchy is optimized for porting code re-use. Other implementations of the Thread Manager component are also possible and - can utilize a different set of APR synchronizers. + can utilize a different set of porting synchronizers.

      Note @@ -1335,7 +809,7 @@ border="0" />

      - Figure 7: Lock Word Structure: Contention Bit is 0 + Figure 6: Lock Word Structure: Contention Bit is 0

      • @@ -1368,7 +842,7 @@ src="images/inflated_lockword.gif" />

        - Figure 8: Lock Word Structure: Contention Bit is 1 + Figure 7: Lock Word Structure: Contention Bit is 1

        • @@ -1395,8 +869,7 @@ alt="Inflated thin monitor" border="0" />

          - Figure 9: Thin and Fat Monitor Relationship -

          + Figure 8: Fat Monitor

          Back to Top

          @@ -1413,7 +886,7 @@ Lock reservation

          - Figure 10: Acquiring a Thin Lock + Figure 9: Acquiring a Thin Lock

          First, the thread uses the reservation bit to check whether the @@ -1459,16 +932,15 @@ After creating a new thread, the Thread() constructor creates a new native thread and initializes thread control structures - HyThread and JVMTIThread. + VM_thread and HyThread as part of VM_thread.

        • The user application then calls the - java.lang.Thread.start() method of kernel classes - within the VM core component. + java.lang.Thread.start() method.
        • - The java.lang.Thread.start() method delegates the call - to the jthread_create() function of the Javajava.lang.Thread.start() method executes the jthread_create() function + of the Java* layer in the thread manager via the java.lang.VMThreadManager.start() function.
        • @@ -1478,43 +950,36 @@
        • The jthread_create_with_function() function calls - hythread_create() supplying wrapper_proc + hythread_create_ex() supplying jthread_wrapper_start_proc() as a new thread body procedure.
        • - The hythread_create() function delegates the call to - the apr_thread_create() function of the APR porting - layer, which does the actual fork and creates a new thread. The - wrapper_proc argument is supplied as the thread body - at this step. -
        • -
        • - The newly created thread begins to execute - thread_start_proc(), which, in its turn, runs the - wrapper_proc() function. -
        • -
        • - The function wrapper_proc() performs the required - registration of the new thread with other components by sending the - vm_attach event to VM core and by calling the - jvmti_send_thread_start_end_event() function, which - sends the JVMTI_EVENT_THREAD_START event. -
        • -
        • - The function wrapper_proc() calls the + The hythread_create_ex() function executes + the os_thread_create() function of the porting + layer, which does the actual fork and creates a new thread. The newly created + thread begins to execute + jthread_wrapper_start_proc(). +
        • +
        • + The function jthread_wrapper_start_proc() performs + the required registration of the new thread in the thread group, allocates + VM_thread pool, creates + the top-level M2N frame and local handles, initiates thread stack info + and JNI thread environment. If needed, the function performs JVMTI callback + by sending the JVMTI_EVENT_THREAD_START event. +
        • +
        • After thread initialization, the function jthread_wrapper_start_proc() executes + the java.lang.Thead.run() method, which makes the user-defined body of the new Java* thread. -
        • +
        • - After Thread.run() has finished, the thread is - unregistered with other components by calling the - jvmti_send_thread_start_end_event() function, which - sends the JVMTI_EVENT_THREAD_END and then the - vm_detach events. -
        • + After java.lang.Thread.run() has finished, the function jthread_wrapper_start_proc() unsets + the thread in the thread group and de-allocates VM_thread data. + If needed, the function performs JVMTI callback by sending the JVMTI_EVENT_THREAD_END event.

          - The following figure illustrates the detailed sequence of thread + The following figures illustrate the detailed sequence of thread creation and completion:

          @@ -1522,15 +987,20 @@ src="images/ThreadCreation.gif" />

          - Figure 11: Java* Thread Life Cycle -

          + Figure 10: Java* Thread Life Cycle +

          +

          +

          Figure 11: New Java* Thread + + +Life Cycle

          Note

          - The native thread control structures (such as, HyThread - and JVMTIThread) are not de-allocated once the new thread - body is finished. The thread manager creates a weak reference for each + The native thread control structures, such as VM_thread, are + not de-allocated once the new thread body is finished. The thread manager + creates a weak reference for each java.lang.Thread object supplying its internal reference queue. The garbage collector places a reference into that queue when a specific java.lang.Thread object is garbage-collected. @@ -1548,9 +1018,9 @@ Suspension

    - One of the important features that the native layer adds for APR - threading is safe suspension. This mechanism ensures that the - suspended thread can be safely explored by the garbage collector + One of the important features that the native layer adds for threading in + the porting layer is safe suspension. This mechanism ensures that + the suspended thread can be safely explored by the garbage collector during the enumeration of live references. If a thread holds some system-critical locks, such as the locks associated with the native heap memory, safe suspension can keep it running even during the @@ -1595,26 +1065,14 @@ The T2 thread undergoes the following:

      -
    1. - Thread T2 periodically calls the hythread_safe_point() - function to designate the points of safe suspension.
      - If a suspension request has been set previously for T2, this - method notifies the T1 thread and then waits until T1 resumes it by - calling hythread_resume(T2). -
    2. -
    3. - When the T2 thread enters a safe region, it calls the - hythread_suspend_ensable() function, which decrements - the suspend_disable_count state flag.
      - If a suspension request has been previously set for T2, T1 is - notified about T2 having reached a safe region. -
    4. -
    5. - When T2 leaves a safe region, it calls the - hythread_suspend_disable() function. This function - increments the suspend_disable_count state flag. -
    6. -
    +
  • T2 thread marks itself with functions + hythread_suspend_enable() and hythread_suspend_disable() + in order to denote a safe region of code. T2 thread may also call hythread_safe_point() + method to denote a selected point where safe suspension is possible.
  • +
  • If a suspension request has been set, T2 thread reaches the end of + safe point and gets blocked in hythread_safe_point() method + until T1 resumes it by calling hythread_resume(T2).
  • +

    A typical example of the safe suspension scenario takes place when the garbage collector suspends a Java* thread to @@ -1740,49 +1198,34 @@ keeps the lock data. The process of locking Java* monitors is shown on Figure 16 below.

    -

    - When a synchronized section occurs in Java* code, the - following steps are taken: -

    -
      -
    1. - The code generated by the JIT compiler calls the - hythread_monitor_enter() helper function provided by - the thread manager. The helper function provides a chunk of code - (stub) that can be in-lined by the JIT compiler directly into the - generated assembly code. -
    2. -
    3. - The hythread_monitor_enter() helper calls the - vm_object_get_lockword_addr() function of VM core - component to find out the physical address of the lock word within - the Java* object. -
    4. -
    5. - The helper calls the thin_monitor_try_lock() function - in order to acquire the lock associated with the object. -
    6. -
    7. - In case the lock is acquired, the helper returns. This is the fast - path to acquiring the Java* monitor. In this - scenario, the helper does not need to switch between Java* and native frames and the - thin_monitor_try_enter() function is called directly - involving no Java* objects.
      - Otherwise, the helper code enters a slow path by switching between - Java* and native code (see the actions of pushing - an M2nFrame and creating the local handle in the figure below). -
    8. -
    9. - The helper calls the jthread_monitor_enter() function, - which works with the Java* object as with JNI - code. -
    10. +

      The code generated by the JIT compiler calls the gen_restore_monitor_enter() + helper function. The helper function provides a chunk of code (stub) that + can be inlined by the JIT compiler directly into the generated assembly + code.

      +
        +
      1. The helper function argument is a physical address of the lock + word within the Java* object.
      2. +
      3. The first step of helper is to perform + a fast path of acquiring the lock associated with the object. The action + is the same as thread manager does in hythread_thin_monitor_try_enter() + function.
      4. +
      5. The helper tries to follow the fast path. If the lock is acquired and + the monitor is not contended, the helper returns. The helper does not need + to switch between Java* and + native frames and operates directly involving no Java* objects.
      6. +
      7. If the lock is not acquired, the helper continues by entering a slow + path, which switches between Java* and + native code. The slow path actions are pushing an M2nFrame and creating + the local handle (see in the figure below).
      8. +
      9. The helper calls the jthread_monitor_enter() + function, which works with the Java* object + as with JNI code.
      -

      - slow and fast paths to locking a Java* monitor +

       

      +

      + slow and fast paths to locking a Java* monitor

      Figure 16: Locking Java* Monitors

      Modified: harmony/standard/site/xdocs/subcomponents/drlvm/images/JavaAttached.gif URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/subcomponents/drlvm/images/JavaAttached.gif?rev=645916&r1=645915&r2=645916&view=diff ============================================================================== Binary files - no diff available. Modified: harmony/standard/site/xdocs/subcomponents/drlvm/images/Monitors.gif URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/subcomponents/drlvm/images/Monitors.gif?rev=645916&r1=645915&r2=645916&view=diff ============================================================================== Binary files - no diff available. Added: harmony/standard/site/xdocs/subcomponents/drlvm/images/NewJavaThread.gif URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/subcomponents/drlvm/images/NewJavaThread.gif?rev=645916&view=auto ============================================================================== Binary file - no diff available. Propchange: harmony/standard/site/xdocs/subcomponents/drlvm/images/NewJavaThread.gif ------------------------------------------------------------------------------ svn:mime-type = application/octet-stream Modified: harmony/standard/site/xdocs/subcomponents/drlvm/images/Synchronizer_mutex.gif URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/subcomponents/drlvm/images/Synchronizer_mutex.gif?rev=645916&r1=645915&r2=645916&view=diff ============================================================================== Binary files - no diff available. Modified: harmony/standard/site/xdocs/subcomponents/drlvm/images/ThreadCreation.gif URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/subcomponents/drlvm/images/ThreadCreation.gif?rev=645916&r1=645915&r2=645916&view=diff ============================================================================== Binary files - no diff available. Modified: harmony/standard/site/xdocs/subcomponents/drlvm/images/ThreadingSystem.gif URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/subcomponents/drlvm/images/ThreadingSystem.gif?rev=645916&r1=645915&r2=645916&view=diff ============================================================================== Binary files - no diff available. Modified: harmony/standard/site/xdocs/subcomponents/drlvm/images/inflated_thin_monitor.gif URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/subcomponents/drlvm/images/inflated_thin_monitor.gif?rev=645916&r1=645915&r2=645916&view=diff ============================================================================== Binary files - no diff available. Modified: harmony/standard/site/xdocs/subcomponents/drlvm/images/tm_in_vm.gif URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/subcomponents/drlvm/images/tm_in_vm.gif?rev=645916&r1=645915&r2=645916&view=diff ============================================================================== Binary files - no diff available.