Index: xdocs/subcomponents/classlibrary/RMIprovider.html =================================================================== --- xdocs/subcomponents/classlibrary/RMIprovider.html (revision 520778) +++ xdocs/subcomponents/classlibrary/RMIprovider.html (working copy) @@ -25,44 +25,28 @@ - -

DRL RMI Registry Service Provider for JNDI

-

- Revision History -

-

- About This Document -

-

- Purpose -

-

- Intended Audience -

-

- Documentation Conventions -

-

- RMI Provider Overview -

-

- RMI Provider in DRL -

-

- About -

-

- Environment Properties -

-

- RMI URLs -

-

- Binding Registry Contexts and Remote Objects -

-

- References -

+ +

DRL RMI Registry Service Provider for JNDI

+
    +
  1. Revision History
  2. +
  3. About This Document +
      +
    1. Purpose
    2. +
    3. Intended Audience
    4. +
    5. Documentation Conventions
    6. +
    +
  4. +
  5. RMI Provider Overview
  6. +
  7. RMI Provider in DRL +
      +
    1. About
    2. +
    3. Environment Properties
    4. +
    5. RMI URLs
    6. +
    7. Binding Registry Contexts and Remote Objects
    8. +
    +
  8. +
  9. References
  10. +

Revision History

@@ -89,7 +73,7 @@ March 23, 2006 - + Formatting update @@ -184,7 +168,7 @@ java.naming.factory.initial
-

+

Specifies the RMI registry service provider class name as the initial context factory to be used by the javax.naming.InitialContext class.

@@ -199,7 +183,7 @@ property, which specifies the location of the RMI registry for the usage of the initial context. Otherwise, the initial context you created can only resolve complete RMI URLs. -

+

@@ -247,7 +231,7 @@ "http://java.sun.com/j2se/1.5.0/docs/guide/rmi/spec/rmiTOC.html" target= "_blank">http://java.sun.com/j2se/1.5.0/docs/guide/rmi/spec/rmiTOC.html

-

+

[3] Sun's RMI Provider, http://java.sun.com/j2se/1.5.0/docs/guide/jndi/jndi-rmi.html Index: xdocs/subcomponents/drlvm/debugging_VM_and_JIT.html =================================================================== --- xdocs/subcomponents/drlvm/debugging_VM_and_JIT.html (revision 520778) +++ xdocs/subcomponents/drlvm/debugging_VM_and_JIT.html (working copy) @@ -22,66 +22,77 @@ "text/html; charset=ISO-8859-1"> Debugging DRL Virtual Machine and JIT Compiler - -

- Debugging the DRL Virtual Machine and the JIT Compiler -

+ +

Debugging the DRL Virtual Machine and the JIT Compiler

+
    +
  1. About This Document
  2. +
  3. Debugging the Virtual Machine +
      +
    1. How to Debug the VM +
        +
      1. Basic Debugging Steps
      2. +
      3. Attaching the Debugger to the Live Process
      4. +
      +
    2. +
    3. How to Get More of Your Debugging +
        +
      1. Configuration of Tracing
      2. +
      3. Native Stack Examination
      4. +
      5. Java* Stack Examination
      6. +
      7. Setting Smart Breakpoints
      8. +
      9. Handling Java* Threads as Native Threads
      10. +
      11. Debugging Deadlocks with the + CriticalSection Synchronization Primitive
      12. +
      13. Getting a Class Name for an Object
      14. +
      +
    4. +
    +
  4. +
  5. Debugging the Jitrino.JET Baseline Compiler +
      +
    1. How to Enable Tracing in Jitrino.JET
    2. +
    3. How to Configure Trace Logging +
        +
      1. Group 1: Compilation Results Tracing
      2. +
      3. Group 2: Run-time Execution Tracing
      4. +
      +
    4. +
    5. How to Get More of Your Tracing +
        +
      1. Tracing Example
      2. +
      +
    6. +
    +
  6. +
+

About This Document

This document gives practical instructions on how to debug the DRL virtual machine and its baseline just-in-time compiler Jitrino.JET. For a definition of components and details on their internal structure, consult the - DRL Virtual Machine Developer’s Guide supplied with the DRLVM image. + DRL Virtual Machine Developer’s Guide supplied with the DRLVM image.

The document includes two groups of debugging tips, one for VM tips, and the other for JIT compiler tips, as shown below.

-

- Debugging the Virtual Machine -

-

- How to debug the VM? -

-

- How to get more of your debugging? -

-

- Debugging the Jitrino.JET Baseline Compiler -

-

- How to enable tracing in Jitrino.JET? -

-

- How to configure trace logging? -

-

- How to get more of your tracing? -

-

Back to top -

-

- Debugging the Virtual Machine -

-

+

Back to top

+

Debugging the Virtual Machine

+

This section gives an insight into debugging the DRL virtual machine version 1.0 and provides tips on resolving non-standard debugging issues.

-

- How to debug the VM? -

+

Back to top

+

How to Debug the VM

This section gives instructions on different scenarios of debugging the VM source code.

-

- Basic Debugging Steps -

-

- For ordinary tests, start the ij executable with the debugger enabled, as follows: -

-

- On Windows*

-
    +

    Basic Debugging Steps

    +

    For ordinary tests, start the ij executable with the debugger enabled, as follows:

    +
    +
    On Windows*
    +
    1. Start Microsoft Visual Studio* and open the solution file vm\build\vm.sln.
    2. Open the source code that you need to debug, set breakpoints and perform all other @@ -93,10 +104,9 @@
    3. Start debugging via the menu Debug > Start, click NO in the popup dialog offering to build the project.
    4. -
    -

    - On Linux*

    -
      +
    +
    On Linux*
    +
    1. Set up the LD_LIBRARY_PATH to point to the deploy/jre/bin directory. Change the working directory to the location of the VM executable and run: @@ -110,61 +120,41 @@ run <your_params>
    2. -
    +
+ +

Attaching the Debugger to the Live Process

- Back to top -

-

- Attaching the Debugger to the Live Process -

-

- To attach to the running VM process, do the following: -

-

- On Windows*

-
    + To attach to the running VM process, do the following:

    +
    On Windows*
    +
    1. Start Visual Studio* .
    2. Go Debug > Processes.
    3. Select the VM process and click Attach.
      If you built the VM in the debug mode, the Microsoft Debug Runtime window appears. Click the Debug button to go to the crash point.
    4. -
    -

    - On Linux*

    -

    +

+
On Linux*
+
Run: -

-
-gdb –p <PID of ij>
-
-

+

gdb –p <PID of ij>
+ If the VM crashed during execution, use the core dump to analyze the crash: -

-
-gdb ij core
-
+
gdb ij core
+
+

Back to top

+

How to Get More from Your Debugging

- Back to top -

-

- How to get more from your debugging? -

-

This section includes some tips on optimizing the debug process and getting more debug information.

-

- Configuration of tracing -

+

Configuration of Tracing

Consult the Getting Started - guide delivered with DRLVM bundle for information on VM standard and non-standard + guide delivered with DRLVM bundle for information on VM standard and non-standard configuration options. Tracing-related options might be useful for debugging purposes.

-

- Native stack examination -

+

Native Stack Examination

The debugger might draw the stack incorrectly when the JIT or native stubs are involved. To avoid this, set esp as the memory location and 4-byte integer values as the output @@ -195,79 +185,66 @@ call stack in the Call Stack window. If you have found a wrong call site, repeat the instruction from step 2. -

- Back to top -

-

- Java* stack examination -

-

- On Windows*

-

+ +

Java* Stack Examination

+
On Windows*
+
Running the VM in the interpreter mode, you can get Java* methods stack trace almost at any point of execution. For that, break the execution of the VM and select the Interpreter frame in the Visual Studio* Call Stack window. Then, in the watch window, add the watch stack_dump(). The stack dump appears in VM output window. Running the VM in the JIT mode, use the st_print() function for the same purpose. -

-

- On Linux*

-

+

+
On Linux*
+
Use the gdb command print and specify the stack_dump or st_print in the interpreter or the JIT compiler mode respectively. -

-

- Setting smart breakpoints -

-

- On Windows* / IA-32

-

+

+ +

Setting Smart Breakpoints

+
On Windows* / IA-32
+
Place breakpoints in source code by inserting calls to the _CrtDbgBreak() function. Placing the call inside a condition calls the function only for the specified case you need to debug. Analogously, you can use the Windows* API function DebugBreak() or print INT 3. -

+

Note

- This requires recompiling the VM.

-

- On Linux*

-

+ This requires recompiling the VM.

+
+ On Linux*
+
Run the following: -

-
-__asm {int 3}
-
+
__asm {int 3}
+
+ +

+ Handling Java* Threads as Native Threads

- Back to top -

-

- Handling Java* threads as native threads -

-

DRL VM has 1:1 mapping between native threads visible in the debugger and Java* threads.
+ href="#*">* threads.
To work with Java* threads individually, freeze the threads you do not need with the help of the debugger, and continue execution of other threads.

-

- Debugging deadlocks with the CriticalSection synchronization primitive +

+ Debugging Deadlocks with the CriticalSection Synchronization Primitive

The CriticalSection primitive is a common cause of deadlocks. If the code has stopped at a critical section, you can try to find the thread that owns this primitive.

-

- On Windows*

-

+

+
On Windows*
+
The file WinNT.H located in <PlatformSDK>\Include contains the definition for the structure _RTL_CRITICAL_SECTION, which contains the description of the CriticalSection primitive. You can get the owning thread for the CriticalSection primitive in a number of ways, as indicated below. -

+

Lookup in Memory

@@ -286,7 +263,7 @@

Visual Studio* displays thread IDs in decimal representation.

- In the watch window

+ In the Watch Window

In the watch window of Visual Studio*, insert the following:

@@ -295,24 +272,19 @@

Where <cs-ptr> is the address of your critical section -

-

- On Linux*

-

+

+
On Linux*
+
The file /usr/include/bits/pthreadtypes.h contains the description of the pthread_mutex_t type. To get the ID of the thread owning the CriticalSection primitive, in gdb execute: -

-
-x/4w <address of your mutex primitive>
-
+
x/4w <address of your mutex primitive>

The third word in the output contains the owning thread descriptor you are looking for. -

-

- Getting a class name for an object -

+

+

+ Getting a Class Name for an Object

You can often need to find out the class name for a Java* object used in VM code. For example, you may need to get the class name for an object of @@ -333,15 +305,16 @@ Back to top

- Debugging the Jitrino.JET Baseline Compiler + Debugging the Jitrino.JET Baseline Compiler

To use debugging and tracing in Jitrino.JET, use the debug build or the release build with the JET_PROTO macro defined. See the file jdefs.h for a definition of the available flags.

+

Back to top

- How to enable tracing in Jitrino.JET? + How to Enable Tracing in Jitrino.JET

Currently, Jitrino.JET provides no interface or command line to control tracing @@ -351,8 +324,9 @@ compiled, and the instance variable m_fname contains its fully qualified name with no signature. Obtain these options through a call to Compiler::m_infoBlock.get_flags().

+

Back to top

- How to configure trace logging? + How to Configure Trace Logging

Tracing flags control compilation results output and trace run-time execution, as @@ -360,9 +334,8 @@ the ij executable starts: compilation results are in jet.log, and run-time output is in jet.rt.log.

-

- Group 1: Compilation Results Tracing -

+

+ Group 1: Compilation Results Tracing

The following flags control tracing compilation of a method:

@@ -412,13 +385,10 @@

+ +

+ Group 2: Run-time Execution Tracing

- Back to top -

-

- Group 2: Run-time Execution tracing -

-

The following flags trace run-time life of the method: