Index: xdocs/subcomponents/classlibrary/RMIprovider.html =================================================================== --- xdocs/subcomponents/classlibrary/RMIprovider.html (revision 520778) +++ xdocs/subcomponents/classlibrary/RMIprovider.html (working copy) @@ -25,44 +25,28 @@
- -- Revision History -
- -- Purpose -
- - - - -- About -
- -- RMI URLs -
-- Binding Registry Contexts and Remote Objects -
-- References -
+ +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.
+
[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">
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 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? -
- -+
+This section gives an insight into debugging the DRL virtual machine version 1.0 and provides tips on resolving non-standard debugging issues.
-This section gives instructions on different scenarios of debugging the VM source code.
-- For ordinary tests, start the ij executable with the debugger enabled, as follows: -
-- On Windows*
-For ordinary tests, start the ij executable with the debugger enabled, as follows:
+
vm\build\vm.sln. - On Linux*
-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>
- Back to top -
-- To attach to the running VM process, do the following: -
-- On Windows*
--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 -
-This section includes some tips on optimizing the debug process and getting more debug information.
-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.
-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 -
-- On Windows*
-+ +
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*
-+
gdb command print and specify the stack_dump or
st_print in the interpreter or the JIT compiler mode respectively.
-
- - On Windows* / IA-32
-+
_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.
-__asm {int 3}
-
+__asm {int 3}
+- Back to top -
-
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.
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*
-+
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 WindowIn 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*
-+
/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. -
-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
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.
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().
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.
The following flags control tracing compilation of a method:
@@ -412,13 +385,10 @@ + +- Back to top -
-The following flags trace run-time life of the method:
- Back to top -
-To identify one or more problematic methods with another stable JIT compiler, use @@ -488,10 +455,7 @@ to break execution at the specified bytecode instruction or at the entry point of the specified method.
-- Back to top -
-@@ -716,7 +680,7 @@
* Other brands and names are the property of their respective owners.
- +