You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by na...@apache.org on 2007/03/19 15:12:08 UTC
svn commit: r519951 [5/5] - in /harmony/standard/site: docs/
docs/subcomponents/classlibrary/ docs/subcomponents/drlvm/ xdocs/
xdocs/subcomponents/classlibrary/ xdocs/subcomponents/drlvm/
Modified: harmony/standard/site/xdocs/subcomponents/classlibrary/compat.xml
URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/subcomponents/classlibrary/compat.xml?view=diff&rev=519951&r1=519950&r2=519951
==============================================================================
--- harmony/standard/site/xdocs/subcomponents/classlibrary/compat.xml (original)
+++ harmony/standard/site/xdocs/subcomponents/classlibrary/compat.xml Mon Mar 19 07:12:06 2007
@@ -1,7 +1,5 @@
<?xml version="1.0" encoding="UTF-8"?>
-
<!--
-
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
@@ -32,7 +30,7 @@
<big>
<em>
The following guidelines are currently PROPOSED and being discussed on the
- development mailing list <code>dev@harmony.apache.org</code>. Please
+ development mailing list <code>dev@harmony.apache.org</code>. Please
direct comments and questions there.
</em>
</big>
@@ -52,16 +50,13 @@
effort is producing a set of class library code that is compatible with
<a href="http://java.sun.com/j2se/1.5.0/docs/api/index.html">
the Java SE 5.0 API
- specification
- </a>.
+ specification</a>.
</p>
<p>
At times (discussed below) it is necessary to augment the specification based on the
- behavior of the reference implementation (RI) of the Java SE 5.0 specification. In
+ behavior of the reference implementation (RI) of the Java SE 5.0 specification. In
such cases we use <a href="http://java.sun.com/j2se/1.5.0/download.jsp">
- the latest
- official release of the Java SE 5.0 RI
- </a>.
+ the latest official release of the Java SE 5.0 RI</a>.
</p>
<p>
We are aware that there are other compliant implementations of Java 5.0 available
@@ -73,66 +68,56 @@
<p>
The following general guidelines apply when developing class library code for Apache
Harmony:
- <ul>
- <li>
- <b>Comply with the Java Specification</b>
- <p>
- In the first instance we follow the description of each part of the class
- library given in the <a href="#referenceImpl">Java specification</a>. To
- the large part, this adequately describes the behavior of the class library
- implementation including methods, exceptions, and serialization. However,
- where the specification is silent on a particular issue facing the implementor,
- or the described behavior is clearly illogical, then we follow the behavior
- of the reference implementation.
- </p>
- </li>
- <li>
- <b>Follow the Reference Implementation</b>
- <p>
- The Reference Implementation (RI) is used to resolve issues that are not
- adequately addressed in the specification. In such cases we use the RI as a
- guide to the compliant and expected behavior; however, developers <em>must</em>
- ensure that the behaviour of the RI is determined soley through exercising the
- public Java APIs -- specifically we avoid any notion of reverse engineering or
- exposition of the RI's implementation by exercising non-API types and methods.
- </p>
- <p>
- There are a few occasions where both the specification is quiet on a given
- issue, and the RI exhibits behaviour that we would consider illogical. In such
- cases we discuss the issue on
- <a href="../../mailing.html">
- the Harmony developers'
- mailing list
- </a>, and code the class libraries to do what the development community
- conclude is "the logical thing".
- </p>
- </li>
- <li>
- <b>Do "the Logical Thing"</b>
- <p>
- The final decision about how a piece of code should behave, on those rare occasions
- where the specification and RI do not provide a satisfactory answer, is reached
- by concensus on the Harmony developers' mailing list. Each issue is debated based
- on it's individual circumstances, but the developers are aware that breaking popular
- applications is invariably not "the logical thing" to do.
- <p>
- </p>
- Once a decision has been made it is documented in the code comments and an issue
- raised in <a href="http://issues.apache.org/jira/browse/HARMONY">
- the Harmony JIRA issue
- tracking system
- </a> to record the conclusion. It should be noted that very few issues
- need to be resolved this way.
- </p>
- </li>
- </ul>
</p>
+ <dl>
+ <dt>Comply with the Java Specification</dt>
+ <dd>
+ In the first instance we follow the description of each part of the class
+ library given in the <a href="#referenceImpl">Java specification</a>. To
+ the large part, this adequately describes the behavior of the class library
+ implementation including methods, exceptions, and serialization. However,
+ where the specification is silent on a particular issue facing the implementor,
+ or the described behavior is clearly illogical, then we follow the behavior
+ of the reference implementation.
+ </dd>
+ <dt>Follow the Reference Implementation</dt>
+ <dd>
+ The Reference Implementation (RI) is used to resolve issues that are not
+ adequately addressed in the specification. In such cases we use the RI as a
+ guide to the compliant and expected behavior; however, developers <em>must</em>
+ ensure that the behaviour of the RI is determined soley through exercising the
+ public Java APIs -- specifically we avoid any notion of reverse engineering or
+ exposition of the RI's implementation by exercising non-API types and methods.
+ <br />
+ There are a few occasions where both the specification is quiet on a given
+ issue, and the RI exhibits behaviour that we would consider illogical. In such
+ cases we discuss the issue on <a href="../../mailing.html">
+ the Harmony developers' mailing list</a>, and code the class libraries to
+ do what the development community
+ conclude is "the logical thing".
+ </dd>
+ <dt>
+ <b>Do "the Logical Thing"</b>
+ </dt>
+ <dd>
+ The final decision about how a piece of code should behave, on those rare occasions
+ where the specification and RI do not provide a satisfactory answer, is reached
+ by concensus on the Harmony developers' mailing list. Each issue is debated based
+ on it's individual circumstances, but the developers are aware that breaking popular
+ applications is invariably not "the logical thing" to do.
+ <br />
+ Once a decision has been made it is documented in the code comments and an issue
+ raised in <a href="http://issues.apache.org/jira/browse/HARMONY">
+ the Harmony JIRA issue tracking system</a> to record the conclusion. It should be
+ noted that very few issues need to be resolved this way.
+ </dd>
+ </dl>
</subsection>
<subsection name="Exception-throwing compatibility">
<p>
There are a number of methods in the Java specification that describe the conditions under
- which exceptions are thrown. However, in most cases the specification does not describe all possible
+ which exceptions are thrown. However, in most cases the specification does not describe all possible
exceptions that may be thrown, the order of exception throwing (i.e. where there are multiple
conditions that would result in an exception), and so on.
</p>
@@ -143,60 +128,56 @@
<p>
Harmony
<b>classlib</b> developers write test cases that deliberately cause exceptions to be thrown
- so that we can match exception behaviour like-for-like. Harmony class library code throws exceptions
+ so that we can match exception behaviour like-for-like. Harmony class library code throws exceptions
of the same runtime class (or a subtype of that runtime class) as the RI, other than
in cases where the RI throws non-public types whereupon Harmony will throw an exception with the same public supertype.
</p>
<p>
Generally, we could refer to the following steps.
+ </p>
+ <dl>
+ <dt>If RI is compliant with the Java Specification</dt>
+ <dd>
+ We shall follow RI's behavior, that is, throws exactly the same exception or a subclass of the exception.
+ </dd>
<ul>
<li>
- <b>If RI is compliant with the Java Specification</b>
- <p>
- We shall follow RI's behavior, that is, throws exactly the same exception or a subclass of the exception.
- <ul>
- <li>
- But there are some cases that RI throws an implementation specific exception,
- which is not in the Java Specification, we shall throw an equivalent Harmony specific exception,
- or its superclass in the Java Specification.
- <p>
- <i>
- e.g., If RI throws sun.io.MalformedInputException,
- we could throw org.apache.harmony.io.MalformedInputException or java.io.CharConversionException.
- </i>
- </p>
- </li>
- </ul>
+ But there are some cases that RI throws an implementation specific exception,
+ which is not in the Java Specification, we shall throw an equivalent Harmony specific exception,
+ or its superclass in the Java Specification.
+ <p class="example">Example</p>
+ <p class="exampletext">
+ If RI throws <code>sun.io.MalformedInputException</code>,
+ we can throw <code>org.apache.harmony.io.MalformedInputException</code>
+ or <code>java.io.CharConversionException</code>.
</p>
</li>
- <li>
- <b>If RI is not compliant with the Java Specification</b>
- <p>
+ </ul>
+ <dt>If RI is not compliant with the Java Specification</dt>
+ <dd>
+ <ul>
+ <li>
+ If the Java Specification describes the exceptional situation explicitly,
+ and RI throws different kind of exception or even does not throw any exception,
+ we shall discuss them case by case in harmony-dev mailing list.
<ul>
- <li>
- If the Java Specification describes the exceptional situation explicitly,
- and RI throws different kind of exception or even does not throw any exception,
- we shall discuss them case by case in harmony-dev mailing list.
- <ul>
- <li>If we decide to follow RI, we will raise an "Non-bug differences from Spec" JIRA.</li>
- <li>If we decide to follow the Java Specification, we will raise an "Non-bug differences from RI" JIRA.</li>
- </ul>
- </li>
- <li>
- If the Java Specification does NOT describe the exceptional situation explicitly,
- and RI's behavior is either hard to reproduce or illogical, we shall discuss them case by case.
- And we may decide to:
- <ul>
- <li>Follow RI</li>
- <li>Follow the Java Specification</li>
- <li>Implement the functions in our own way</li>
- </ul>
- </li>
+ <li>If we decide to follow RI, we will raise an "Non-bug differences from Spec" JIRA.</li>
+ <li>If we decide to follow the Java Specification, we will raise an "Non-bug differences from RI" JIRA.</li>
</ul>
- </p>
- </li>
- </ul>
- </p>
+ </li>
+ <li>
+ If the Java Specification does NOT describe the exceptional situation explicitly,
+ and RI's behavior is either hard to reproduce or illogical, we shall discuss them case by case.
+ And we may decide to:
+ <ul>
+ <li>Follow RI</li>
+ <li>Follow the Java Specification</li>
+ <li>Implement the functions in our own way</li>
+ </ul>
+ </li>
+ </ul>
+ </dd>
+ </dl>
</subsection>
<subsection name="Serialization compatibility">
@@ -205,8 +186,8 @@
implementation (RI).
</p>
<p>
- The Java Specification describes the serialized form of many Java types. Where given, <b>classlib</b> will follow
- the specified serialized form. When the serialized form is <u>not</u> given we will ensure that the
+ The Java Specification describes the serialized form of many Java types. Where given, <b>classlib</b> will follow
+ the specified serialized form. When the serialized form is NOT given we will ensure that the
serialization data is compatible with the RI by ensuring that objects serialized from the RI
can be read by Harmony's <b>classlib</b> code, and vice versa.
</p>
Modified: harmony/standard/site/xdocs/subcomponents/classlibrary/pkgnaming.xml
URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/subcomponents/classlibrary/pkgnaming.xml?view=diff&rev=519951&r1=519950&r2=519951
==============================================================================
--- harmony/standard/site/xdocs/subcomponents/classlibrary/pkgnaming.xml (original)
+++ harmony/standard/site/xdocs/subcomponents/classlibrary/pkgnaming.xml Mon Mar 19 07:12:06 2007
@@ -1,7 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
-
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
@@ -49,28 +48,18 @@
by the project development team, and as such the project attributes the following
meaning to package names.
</p>
-
<subsection name="All Packages Belong to a Specific Module">
<p>
Each Java package is owned by a specific module of the Harmony class library.
The module name immediately follows the <code>org.apache.harmony</code> prefix.
</p>
- <pre>
- org.apache.harmony.<b><module></b>
- </pre>
-
+ <pre>org.apache.harmony.<b><module></b></pre>
<p class="example">
Example
</p>
- <p class="exampletext">
- <pre>
- org.apache.harmony.luni
- org.apache.harmony.security
- </pre>
-
- </p>
+ <pre>org.apache.harmony.luni
+org.apache.harmony.security</pre>
</subsection>
-
<subsection name="Package Names within a Module">
<p>
Modules are free to use whatever package names they choose with the
@@ -82,49 +71,49 @@
The following package name segements are <b>reserved</b> to indicate the meanings
defined below:
</p>
- <ul>
- <li>
+ <dl>
+ <dt>
<code>
org.apache.harmony.<modulename>.<b>internal</b>
</code>
- <p>
- Packages with this prefix are implementation packages for use within
- the given module. Types and fields that are visible within these
- packages <em>MUST NOT</em> be used outside the module itself.
- Some runtime environments may enforce this reduced visibility scope.
- </p>
- </li>
- <li>
+ </dt>
+ <dd>
+ Packages with this prefix are implementation packages for use within
+ the given module. Types and fields that are visible within these
+ packages <em>MUST NOT</em> be used outside the module itself.
+ Some runtime environments may enforce this reduced visibility scope.
+ </dd>
+ <dt>
<code>
org.apache.harmony.<modulename>.<b>tests</b>
</code>
- <p>
- Packages with this prefix contain test code that is not part of the
- module API or implementation. Some builds may not include these
- packages. See <a href="testing.html">Testing conventions in the Apache Harmony Classlib</a>
- for details.
- </p>
- </li>
- <li>
+ </dt>
+ <dd>
+ Packages with this prefix contain test code that is not part of the
+ module API or implementation. Some builds may not include these
+ packages. See <a href="testing.html">Testing conventions in the Apache Harmony Classlib</a>
+ for details.
+ </dd>
+ <dt>
<code>
org.apache.harmony.<modulename>.<b>examples</b>
</code>
- <p>
- Packages with this prefix contain example code that is not part of the
- module API or implementation. Some builds may not include these
- packages.
- </p>
- </li>
- <li>
+ </dt>
+ <dd>
+ Packages with this prefix contain example code that is not part of the
+ module API or implementation. Some builds may not include these
+ packages.
+ </dd>
+ <dt>
<code>
org.apache.harmony.<modulename>.<b><anything_else></b>
</code>
- <p>
- All other packages within a module contain internal APIs that may
- be referenced from any module.
- </p>
- </li>
- </ul>
+ </dt>
+ <dd>
+ All other packages within a module contain internal APIs that may
+ be referenced from any module.
+ </dd>
+ </dl>
<p>
In practice, this means that module developers are free to change the code within an
<code>internal</code> package without expecting any consequences beyond the module
Modified: harmony/standard/site/xdocs/subcomponents/classlibrary/ser_testing.xml
URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/subcomponents/classlibrary/ser_testing.xml?view=diff&rev=519951&r1=519950&r2=519951
==============================================================================
--- harmony/standard/site/xdocs/subcomponents/classlibrary/ser_testing.xml (original)
+++ harmony/standard/site/xdocs/subcomponents/classlibrary/ser_testing.xml Mon Mar 19 07:12:06 2007
@@ -1,7 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
-
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
@@ -24,9 +23,7 @@
<title>Framework for Testing Serialization</title>
<author email="dev@harmony.apache.org">Harmony Documentation Team</author>
</properties>
-
<body>
-
<section name="Framework for Testing Serialization">
<p>
<big>
@@ -86,28 +83,19 @@
conventions
</a>
</li>
-
<li>
Add the <code>testSerializationCompatibility</code> method to a unit test
</li>
-
<li>
Invoke one of the methods, mentioned above, with corresponding arguments
</li>
</ul>
-
<p class="example">Example</p>
-
- <pre>
- public void testSerializationCompatibility()
- throws Exception {
-
- SerializationTest.verifyGolden(this, new SomeSerializableClass());
- }
- </pre>
-
-
- <h3>Self-Testing</h3>
+<pre>public void testSerializationCompatibility()
+throws Exception {
+SerializationTest.verifyGolden(this, new SomeSerializableClass());
+}</pre>
+ <h3>Self-Testing</h3>
<p>
Verifies that an object can be smoothly serialized and deserialized on
Harmony implementation.<br/>
@@ -144,21 +132,14 @@
</ul>
<p class="example">Example</p>
- <pre>
- public void testSerializationSelf() throws Exception {
-
- SerializationTest.verifySelf(new SomeSerializableClass(),
- new MyComparator());
- }
- </pre>
-
-
+<pre>public void testSerializationSelf() throws Exception {
+SerializationTest.verifySelf(new SomeSerializableClass(),
+new MyComparator());
+}</pre>
<h3>Negative Testing</h3>
<big>
<em>TBD</em>
</big>
-
-
<p class="class">
Interface <a name="assert">
<code>SerializableAssert</code>
@@ -170,80 +151,61 @@
test has to implement the interface. The interface has only
one method to be implemented:
</p>
-
- <pre>void assertDeserialized(Serializable reference, Serializable test);</pre>
-
-
+<pre>void assertDeserialized(Serializable reference, Serializable test);</pre>
</subsection>
-
<subsection name="Placement and Naming Conventions for Resource Files">
<p>
The resource files should follow the next <a name="conventions">conventions</a>:
</p>
-
<ul>
<li>
Root folder for resource files is <code><module root>/src/test/resources/serialization</code>
</li>
-
<li>
Relative path to a resource file <em>MUST</em> match a test's package name
</li>
-
<li>
A resource file <em>MUST</em> start with a test's name
</li>
-
<li>
A resource file <em>MUST</em> contain keywords pointing out to testing scenario
<ol>
-
<li>
<code><golden></code> keyword is used for files generated on RI
</li>
-
<li>
<code><harmony></code> keyword is used for files generated on
Harmony implementation
</li>
-
<li>
<code><negative></code> keyword is used for files that contain
broken serial form
</li>
-
</ol>
</li>
-
<li>
A resource file name <em>MUST</em> contain some index
<p class="note">Note</p>
<p class="notetext">If only one file exists, the index is not required.</p>
-
</li>
-
<li>
Extension for resource files is <code>ser</code>
-
<p class="example">Example</p>
<p class="exampletext">
For the test <code>org.apache.harmony.tests.java.lang.SomeClassTest</code>,
we have the following resource files:
</p>
- <pre>
- modules/luni/src/test/resources/serialization
- |
- \---org/apache/harmony/tests/java/lang
- |
- \---SomeClassTest.golden.0.ser
- SomeClassTest.golden.1.ser
- SomeClassTest.golden.2.ser
- SomeClassTest.harmony.0.ser
- SomeClassTest.harmony.1.ser
- SomeClassTest.negative.ser
- </pre>
+<pre>modules/luni/src/test/resources/serialization
+|
+\---org/apache/harmony/tests/java/lang
+|
+\---SomeClassTest.golden.0.ser
+ SomeClassTest.golden.1.ser
+ SomeClassTest.golden.2.ser
+ SomeClassTest.harmony.0.ser
+ SomeClassTest.harmony.1.ser
+ SomeClassTest.negative.ser</pre>
</li>
-
</ul>
</subsection>
</section>
Modified: harmony/standard/site/xdocs/subcomponents/classlibrary/testing.xml
URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/subcomponents/classlibrary/testing.xml?view=diff&rev=519951&r1=519950&r2=519951
==============================================================================
--- harmony/standard/site/xdocs/subcomponents/classlibrary/testing.xml (original)
+++ harmony/standard/site/xdocs/subcomponents/classlibrary/testing.xml Mon Mar 19 07:12:06 2007
@@ -1,7 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
-
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
@@ -24,13 +23,11 @@
<title>Testing Conventions in the Apache Harmony Classlib</title>
<author email="dev@harmony.apache.org">Harmony Documentation Team</author>
</properties>
-
<body>
-
<section name="Testing Conventions Used in the Apache Harmony Class Library">
<p>
- This document describes PROPOSED placement and package naming conventions for
- different types of Harmony class library tests.
+ <big><i>This document describes PROPOSED placement and package naming conventions for
+ different types of Harmony class library tests.</i></big>
</p>
<p>
The Harmony class library code is organized into modules that might have their own
@@ -53,53 +50,32 @@
on RI or other compliant implementations are separated from the imlpementation-independent
tests that must pass on RI and all conformant implementations.
</p>
-
- <pre>
- <modulename>/src/test/<b>impl</b> - Harmony specific tests<br/>
- <modulename>/src/test/<b>api</b> - Implementation-independent tests
- </pre>
-
+<pre><modulename>/src/test/<b>impl</b> - Harmony specific tests
+<modulename>/src/test/<b>api</b> - Implementation-independent tests</pre>
<p>
Special-purpose tests like stress tests or tests that require special configuration are
separated from general-purpose tests.
</p>
- <pre>
- <modulename>/src/test/<b>stress</b>
- </pre>
-
- <p>
+<pre><modulename>/src/test/<b>stress</b></pre>
+ <p>
Tests are not separated by functionality under test, for example, tests against <code>clone()</code>
- methods are <b>not</b> separated from tests against <code>equals()</code> methods.
-
+ methods are NOT separated from tests against <code>equals()</code> methods.
Classpath tests are separated from bootclasspath tests on a directory level:
</p>
-
- <pre>
- <modulename>/src/test/api/<b>java</b> - Classpath tests<br/>
- <modulename>/src/test/api/<b>java.injected</b> - Bootclasspath tests
- </pre>
-
- <p>
+<pre><modulename>/src/test/api/<b>java</b> - Classpath tests
+<modulename>/src/test/api/<b>java.injected</b> - Bootclasspath tests</pre>
+ <p>
Find more details <a href="#Package and Class Names for Different Types of the Tests">
- below
- </a>.
- </p>
-
-
+ below</a>.
+ </p>
<p>
Some modules might have platform specific tests that are in the case separated on a directory
level:
</p>
-
- <pre>
- <modulename>/src/test/api/<b>common</b><br/>
- <modulename>/src/test/api/<b>windows</b><br/>
- <modulename>/src/test/api/<b>linux</b>
- </pre>
-
-
+<pre><modulename>/src/test/api/<b>common</b>
+<modulename>/src/test/api/<b>windows</b>
+<modulename>/src/test/api/<b>linux</b></pre>
</subsection>
-
<subsection name="Package and Class Names for Different Types of the Tests">
<p>
If the test is designed to be run from bootclasspath, then its package is the same
@@ -112,42 +88,30 @@
<li>
If the package under test belongs to a public package, for example, it
is a part of the API specification, then the test's package is:
- <pre>
- org.apache.harmony.<modulename>.tests.<b><package under test></b>
- </pre>
+<pre>org.apache.harmony.<modulename>.tests.<b><package under test></b></pre>
<p class="example">Example</p>
-
- <pre>
- org.apache.harmony.luni.tests.<b>java.lang</b><br/>
- org.apache.harmony.crypto.tests.<b>javax.crypto</b><br/>
- org.apache.harmony.auth.tests.<b>org.ietf.jgss</b>
- </pre>
+<pre>org.apache.harmony.luni.tests.<b>java.lang</b>
+org.apache.harmony.crypto.tests.<b>javax.crypto</b>
+org.apache.harmony.auth.tests.<b>org.ietf.jgss</b></pre>
</li>
<li>
If the package under test belongs to <code>org.apache.harmony</code>
namespace so that class's package is:
- <pre>
- org.apache.harmony.<modulename>.<b><rest of the package name></b>
- </pre>
+<pre>org.apache.harmony.<modulename>.<b><rest of the package name></b></pre>
then the test's package is:
- <pre>
- org.apache.harmony.<modulename>.tests.<b><rest of the package name></b>
- </pre>
+<pre>org.apache.harmony.<modulename>.tests.<b><rest of the package name></b></pre>
<p class="example">Example</p>
- <p class="notetext">
+ <p class="exampletext">
<code>org.apache.harmony.luni.internal.net.www.protocol</code> - package under test<br/>
<code>org.apache.harmony.luni.tests.internal.net.www.protocol</code> - package for the test
</p>
-
</li>
</ol>
-
-
<p>
To avoid collision of test results for various type of tests, reflect a test type in a test name.
</p>
<p class="example">Example</p>
- <p class="notetext">
+ <p class="exampletext">
To separate the <code>impl</code> test results from
the <code>api</code> ones, the <code>impl</code> test names end with
<code>_ImplTest</code>:<br/>
@@ -160,8 +124,6 @@
</code> - Implementation specific bootclasspath
test for <code>javax.crypto.Cipher</code>
</p>
-
-
</subsection>
</section>
</body>
Modified: harmony/standard/site/xdocs/subcomponents/drlvm/TM.xml
URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/subcomponents/drlvm/TM.xml?view=diff&rev=519951&r1=519950&r2=519951
==============================================================================
--- harmony/standard/site/xdocs/subcomponents/drlvm/TM.xml (original)
+++ harmony/standard/site/xdocs/subcomponents/drlvm/TM.xml Mon Mar 19 07:12:06 2007
@@ -26,4 +26,4 @@
<body>
<docinclude name="subcomponents/drlvm/ThreadManager.html"/>
</body>
-</document>
+</document>
Modified: harmony/standard/site/xdocs/subcomponents/drlvm/ThreadManager.html
URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/subcomponents/drlvm/ThreadManager.html?view=diff&rev=519951&r1=519950&r2=519951
==============================================================================
--- harmony/standard/site/xdocs/subcomponents/drlvm/ThreadManager.html (original)
+++ harmony/standard/site/xdocs/subcomponents/drlvm/ThreadManager.html Mon Mar 19 07:12:06 2007
@@ -30,108 +30,53 @@
<h1>
<a id="top" name="top"></a>Thread Manager
</h1>
-
- <p class="TOCHeading">
- <a href="#RevisionHistory">1. Revision History</a>
- </p>
-
- <p class="TOCHeading">
- <a href="#About_This_Document">2. About this Document</a>
- </p>
- <p class="TOC">
- <a href="#Purpose">2.1 Purpose</a>
- </p>
- <p class="TOC">
- <a href="#Intended_Audience">2.2 Intended Audience</a>
- </p>
- <p class="TOC">
- <a href="#Documentation_Conventions">2.3 Documentation Conventions</a>
- </p>
- <p class="TOC">
- <a href="#Using_this_document">2.4 Using this Document</a>
- </p>
- <p class="TOCHeading">
- <a href="#Overview">2. Overview</a>
- </p>
- <p class="TOC">
- <a href="#Key_Feature">2.1 Key Features</a>
- </p>
- <p class="TOC">
- <a href="#TM_in_VM">2.2 Thread Manager in VM</a>
- </p>
- <p class="TOC">
- <a href="#Portability">2.3 Portability</a>
- </p>
- <p class="TOCHeading">
- <a href="#Achitecture">4. Architecture</a>
- </p>
- <p class="TOC">
- <a href="#Exported_Interfaces">4.1 Exported interfaces</a>
- </p>
- <blockquote>
- <p class="TOC">
- <a href="#Native_Layer">4.1.1 Native Interface</a>
- </p>
- <p class="TOC">
- <a href="#Java_interface">4.1.2 Java* Interface</a>
- </p>
- </blockquote>
- <p class="TOC">
- <a href="#Data_Structures">4.2 Data structures</a>
- </p>
- <p class="TOC">
- <a href="#Thread_Control_Structure">4.3 Thread control structures</a>
- </p>
- <blockquote>
- <p class="TOC">
- <a href="#Native_Structure">4.3.1 Native Thread Structure</a>
- </p>
- <p class="TOC">
- <a href="#Java_Structure">4.3.2 Java* Thread Structure</a>
- </p>
- </blockquote>
- <p class="TOC">
- <a href="#Thread_Group">4.4 Thread Groups</a>
- </p>
- <p class="TOC">
- <a href="#Synchronizer">4.5 Synchronizers</a>
- </p>
- <p class="TOC">
- <a href="#Monitors">4.6 Monitors</a>
- </p>
- <blockquote>
- <p class="TOC">
- <a href="#MonitorInflation">4.6.1 Inflation Technique</a>
- </p>
- <p class="TOC">
- <a href="#Thin_monitors">4.6.2 Monitor Structure</a>
- </p>
- <p class="TOC">
- <a href="#AcquireMonitor">4.6.3 Acquiring a Monitor</a>
- </p>
- </blockquote>
- <p class="TOCHeading">
- <a href="#Usage_Scenarios">5. Usage scenarios</a>
- </p>
- <p class="TOC">
- <a href="#Thread_lifecycle">5.1 Java* Thread Life Cycle</a>
- </p>
- <p class="TOC">
- <a href="#Thread_suspension">5.2 Thread Suspension</a>
- </p>
- <p class="TOC">
- <a href="#Stop-the-world_Suspension">5.3 Stop-the-world Thread
- Suspension</a>
- </p>
- <p class="TOC">
- <a href="#Thread_locking">5.4 Thread Locking</a>
- </p>
- <p class="TOC">
- <a href="#Monitor_scenarios">5.5 Monitor Enter and Exit</a>
- </p>
- <p class="TOCHeading">
- <a href="#References">6. References</a>
- </p>
+ <ol class="TOC">
+ <li><a href="#RevisionHistory">1. Revision History</a></li>
+ <li><a href="#About_This_Document">2. About this Document</a>
+ <ol>
+ <li><a href="#Purpose">2.1 Purpose</a></li>
+ <li><a href="#Intended_Audience">2.2 Intended Audience</a></li>
+ <li><a href="#Documentation_Conventions">2.3 Documentation Conventions</a></li>
+ <li><a href="#Using_this_document">2.4 Using this Document</a></li>
+ </ol></li>
+ <li><a href="#Overview">3. Overview</a>
+ <ol>
+ <li><a href="#Key_Feature">3.1 Key Features</a></li>
+ <li><a href="#TM_in_VM">3.2 Thread Manager in VM</a></li>
+ <li><a href="#Portability">3.3 Portability</a></li>
+ </ol></li>
+ <li><a href="#Achitecture">4. Architecture</a>
+ <ol>
+ <li><a href="#Exported_Interfaces">4.1 Exported interfaces</a>
+ <ul>
+ <li><a href="#Native_Layer">4.1.1 Native Interface</a></li>
+ <li><a href="#Java_interface">4.1.2 Java* Interface</a></li>
+ </ul></li>
+ <li><a href="#Data_Structures">4.2 Data structures</a></li>
+ <li><a href="#Thread_Control_Structure">4.3 Thread control structures</a>
+ <ul>
+ <li><a href="#Native_Structure">4.3.1 Native Thread Structure</a></li>
+ <li><a href="#Java_Structure">4.3.2 Java* Thread Structure</a></li>
+ </ul></li>
+ <li><a href="#Thread_Group">4.4 Thread Groups</a></li>
+ <li><a href="#Synchronizer">4.5 Synchronizers</a></li>
+ <li><a href="#Monitors">4.6 Monitors</a>
+ <ul>
+ <li><a href="#MonitorInflation">4.6.1 Inflation Technique</a></li>
+ <li><a href="#Thin_monitors">4.6.2 Monitor Structure</a></li>
+ <li><a href="#AcquireMonitor">4.6.3 Acquiring a Monitor</a></li>
+ </ul></li>
+ </ol></li>
+ <li><a href="#Usage_Scenarios">5. Usage scenarios</a>
+ <ol>
+ <li><a href="#Thread_lifecycle">5.1 Java* Thread Life Cycle</a></li>
+ <li><a href="#Thread_suspension">5.2 Thread Suspension</a></li>
+ <li><a href="#Stop-the-world_Suspension">5.3 Stop-the-world Thread Suspension</a></li>
+ <li><a href="#Thread_locking">5.4 Thread Locking</a></li>
+ <li><a href="#Monitor_scenarios">5.5 Monitor Enter and Exit</a></li>
+ </ol></li>
+ <li><a href="#References">6. References</a></li>
+ </ol>
<h1>
<a id="RevisionHistory" name="RevisionHistory"></a>1. Revision History
</h1>
@@ -1910,6 +1855,7 @@
</p>
</body>
</html>
+
Modified: harmony/standard/site/xdocs/subcomponents/drlvm/debugging_VM_and_JIT.html
URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/subcomponents/drlvm/debugging_VM_and_JIT.html?view=diff&rev=519951&r1=519950&r2=519951
==============================================================================
--- harmony/standard/site/xdocs/subcomponents/drlvm/debugging_VM_and_JIT.html (original)
+++ harmony/standard/site/xdocs/subcomponents/drlvm/debugging_VM_and_JIT.html Mon Mar 19 07:12:06 2007
@@ -36,33 +36,28 @@
The document includes two groups of debugging tips, one for VM tips, and the other
for JIT compiler tips, as shown below.
</p>
- <p>
- <a href="#Debugging_VM">Debugging the Virtual Machine</a>
+ <p class="TOCHeading">
+ <a href="#Debugging_VM">Debugging the Virtual Machine</a>
</p>
- <blockquote>
- <p>
- <a href="#How_to_debug_VM">How to debug the VM?</a>
+<p class="TOC">
+ <a href="#How_to_debug_VM">How to debug the VM?</a>
</p>
- <p>
+<p class="TOC">
<a href="#Extended_Debug_VM">How to get more of your debugging?</a>
</p>
- </blockquote>
- <p>
+<p class="TOCHeading">
<a href="#Debugging_JIT">Debugging the Jitrino.JET Baseline Compiler</a>
</p>
- <blockquote>
- <p>
- <a href="#Enable_Tracing">How to enable tracing in Jitrino.JET?</a>
+<p class="TOC">
+ <a href="#Enable_Tracing">How to enable tracing in Jitrino.JET?</a>
</p>
- <p>
+<p class="TOC">
<a href="#Config_Trace_Logging">How to configure trace logging?</a>
</p>
- <p>
+<p class="TOC">
<a href="#Extend_Trace_JIT">How to get more of your tracing?</a>
</p>
- </blockquote>
- <p>
- <a href="#top">Back to top</a>
+ <p><a href="#top">Back to top</a>
</p>
<h1>
<a name="Debugging_VM">Debugging the Virtual Machine</a>
@@ -723,5 +718,6 @@
</p>
</body>
</html>
+
Modified: harmony/standard/site/xdocs/subcomponents/drlvm/debugging_VM_and_JIT.xml
URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/subcomponents/drlvm/debugging_VM_and_JIT.xml?view=diff&rev=519951&r1=519950&r2=519951
==============================================================================
--- harmony/standard/site/xdocs/subcomponents/drlvm/debugging_VM_and_JIT.xml (original)
+++ harmony/standard/site/xdocs/subcomponents/drlvm/debugging_VM_and_JIT.xml Mon Mar 19 07:12:06 2007
@@ -1,11 +1,11 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
- contributor license agreements. See the NOTICE file distributed with
+ contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
- the License. You may obtain a copy of the License at
+ the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
@@ -14,7 +14,6 @@
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-
-->
<document>
@@ -23,9 +22,7 @@
<title>Debugging VM and JIT</title>
<author email="dev@harmony.apache.org">Harmony Documentation Team</author>
</properties>
-
<body>
<docinclude name="subcomponents/drlvm/debugging_VM_and_JIT.html"/>
</body>
-
</document>
Modified: harmony/standard/site/xdocs/subcomponents/drlvm/emguide.xml
URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/subcomponents/drlvm/emguide.xml?view=diff&rev=519951&r1=519950&r2=519951
==============================================================================
--- harmony/standard/site/xdocs/subcomponents/drlvm/emguide.xml (original)
+++ harmony/standard/site/xdocs/subcomponents/drlvm/emguide.xml Mon Mar 19 07:12:06 2007
@@ -38,33 +38,27 @@
Execution Manager (EM) is a component in DRLVM that controls
profile collection and recompilation processes.
<br/>
-For detailed information on EM, see the
- <a href="EM.html">
- Execution Manager Component Description
- </a>.
+For detailed information on EM, see the <a href="EM.html">Execution Manager Component Description</a>.
</p>
</subsection>
<subsection name="2. EM Configuration File">
<p>
The set of JIT compilers and profile collectors used at run time and their
- relations is stored in the <i>EM configuration file</i>.
+relations is stored in the <i>EM configuration file</i>.
During the VM initialization phase, EM uses hard-coded configuration or reads
-it from the config file, if specified.
-<br/>
-You can use the following command-line option to make EM read its
-configuration from the file:<br/>
-<code>-Xem:<path to configuration file></code>
-<br/>
-or <br/>
-<code>-Dem.properties=<configuration.file.path></code>
-</p>
+it from the config file, if specified.</p>
+<p>You can use the following command-line option to make EM read its configuration from the file:</p>
+<pre>-Xem:<path to configuration file></pre>
+or
+<pre>-Dem.properties=<configuration.file.path></pre>
+
<p>
-The following is a line-by-line description of the default EM configuration.
-These configuration settings can be used as a prototype to create
+The following is a line-by-line description of the default EM configuration.
+These configuration settings can be used as a prototype to create
new custom EM configuration files.
The default configuration is:
</p>
-<p><pre>
+<pre>
chains=chain1,chain2
chain1.jits=JET_CLINIT
@@ -84,78 +78,67 @@
JET_DPGO_PROFILE. mode=SYNC
JET_DPGO_PROFILE.entryThreshold=10000
JET_DPGO_PROFILE.backedgeThreshold=100000
-</pre></p>
-<p>A line-by-line description of the settings follows. </p>
+</pre>
+<p>A line-by-line description of the settings follows.</p>
<pre>
chains=chain1,chain2
</pre>
<p>
-Every EM configuration file must define the <code>chains</code> property
+Every EM configuration file must define the <code>chains</code> property
to indicate sequences of JIT compilers to be used to compile and/or recompile
- a method. In this example, two recompilation chains are set for the system:
-<code>chain1</code> and <code>chain2</code>. EM analyzes chains until it has
-chosen the chain for the method.
+ a method. In this example, two recompilation chains are set for the system:
+<code>chain1</code> and <code>chain2</code>. EM analyzes chains until it has
+chosen the chain for the method.
</p>
<pre>
chain1.jits=JET_CLINIT
chain2.jits=JET_DPGO,OPT
</pre>
<p>
-In this case, <code>chain1</code> has one JIT compiler
+In this case, <code>chain1</code> has one JIT compiler
<code>JET_CLINIT</code>, and <code>chain2</code> has
two compilers: <code>JET_DPGO</code> and <code>OPT</code>.
-Using these JIT names, EM reads JIT-specific configuration
-and passes the names to JIT instances during initialization.
-A compiler instance can use its name to distinguish between
-its own properties and those of other JITs. <br/>
-</p>
-<p>
-<b>Note:</b> Jitrino, the current default DRLVM JIT compiler,
-selects Jitrino.JET (fast, non-optimizing compiler) if the name
-starts with the <code>JET</code> prefix. Otherwise, the JIT
-instance is treated as Jitrino.OPT.
-</p>
+Using these JIT names, EM reads JIT-specific configuration
+and passes the names to JIT instances during initialization.
+A compiler instance can use its name to distinguish between
+its own properties and those of other JITs.</p>
+<p class="note">Note</p>
+ <p class="notetext">Jitrino, the current default DRLVM JIT compiler,
+ selects Jitrino.JET (fast, non-optimizing compiler) if the name
+ starts with the <code>JET</code> prefix. Otherwise, the JIT
+ instance is treated as Jitrino.OPT.</p>
<pre>
chain1.filter=+::<clinit>
chain1.filter=-
</pre>
<p>
Method filters are used to select methods that will be compiled
- by the first JIT in a chain.
+by the first JIT in a chain.
In this example, the first line configures <code>chain1</code>
-to accept all <code><clinits></code> methods
-and the second line - to refuse to compile all other methods. <br />
-The order of filters for every chain is significant. Chain
- filters can be considered as if-else clauses: <br/>
+to accept all <code><clinits></code> methods
+and the second line - to refuse to compile all other methods </p>
+<p>The order of filters for every chain is significant. Chain
+filters can be considered as if-else clauses:<br/>
If a filter matches a method, EM stops examining other filters
- and analyzes the first sign in the filter: <br/>
+and analyzes the first sign in the filter:</p>
<ul>
-<li>For a <code>+</code>, EM requests the first JIT in the
-chain to compile the method. </li>
-<li>For a <code>-</code>, EM tries the next chain in the list. </li>
+<li>For a <code>+</code>, EM requests the first JIT in the
+chain to compile the method.</li>
+<li>For a <code>-</code>, EM tries the next chain in the list.</li>
</ul>
-If no filter has matched the compilation request, EM considers
-that the method is accepted to be compiled by the chain.
-<br/>
-Here is a format of all currently supported method filters.
-</p><br/>
+ <p>
+If no filter has matched the compilation request, EM considers
+that the method is accepted to be compiled by the chain.
+Here is a format of all currently supported method filters.
+</p>
<table>
<tr>
-<td>
-<b>Filter Type</b>
-</td>
-<td>
-<b>Filter Format </b>
-</td>
-<td>
-<b>Filter Examples </b>
-</td>
+<th class="TableHeading">Filter Type</th>
+<th class="TableHeading">Filter Format</th>
+<th class="TableHeading">Filter Examples</th>
</tr>
-
<tr>
-<td>
-Name filter
-</td>
+<td>Name filter</td>
<td>
<class-name>::<method_name><signature>
</td>
@@ -175,9 +158,9 @@
NUMB or NUM1B..NUM2B
</td>
<td>
-'<i>+10B..100B</i>' accepts all methods of bytecode size in range of
+'<i>+10B..100B</i>' accepts all methods of bytecode size in range of
[10..100].<br/>
-'<i>-20B</i>' rejects all methods of bytecode size equal to 20.
+'<i>-20B</i>' rejects all methods of bytecode size equal to 20.
</td>
</tr>
@@ -195,116 +178,104 @@
</tr>
</table>
-<br/>
-<p>
-<b>Note:</b> The sequential method number could be changed from run
-to run in multithreaded environments.
-</p>
-<p><pre>
+
+<p class="note">Note</p>
+ <p class="notetext">The sequential method number could be changed from run
+to run in multithreaded environments.</p>
+<pre>
JET_CLINIT.file=<path to dll>
JET_DPGO.file=<path to dll>
OPT.file=<path to dll>
-</pre></p>
+</pre>
<p>
For every JIT, the configuration file must define the location of the library
- file location.
-Multiple JIT compilers can be associated with the same library.
-For example, all paths can point to the same jit.dll file.
-</p>
-<p><pre>
+file location. Multiple JIT compilers can be associated with the same library.
+For example, all paths can point to the same jit.dll file.</p>
+<pre>
JET_DPGO.genProfile=JET_DPGO_PROFILE
JET_DPGO_PROFILE.profilerType=ENTRY_BACKEDGE_PROFILER
OPT.useProfile=JET_DPGO_PROFILE
-</pre></p>
+</pre>
<p>
-These settings define profile collection and recompilation event
-configuration for two JIT compilers: <code>JET_DPGO</code>
+These settings define profile collection and recompilation event
+configuration for two JIT compilers: <code>JET_DPGO</code>
and <code>OPT</code>.
-The first line configures <code>JET_DPGO</code> to generate a
-profile <code>JET_DPGO_PROFILE</code>,
-with the type of associated profile collector specified in the
-second line. <code>ENTRY_BACKEDGE_PROFILER</code>
-is the built-in DRL EM profile collector type.
-In the third line, the <code>OPT</code> compiler is configured
+The first line configures <code>JET_DPGO</code> to generate a
+profile <code>JET_DPGO_PROFILE</code>,
+with the type of associated profile collector specified in the
+second line. <code>ENTRY_BACKEDGE_PROFILER</code>
+is the built-in DRL EM profile collector type.
+In the third line, the <code>OPT</code> compiler is configured
to use the new profile.
-After reading these configuration settings, the execution
-manager does the following: <br/>
+After reading these configuration settings, the execution
+manager does the following:</p>
<ol>
-<li>Instantiates the profile collector of the type
-<code>ENTRY_BACKEDGE_PROFILER</code>. </li>
-<li>Checks whether the <code>JET_DPGO</code> JIT can generate
+<li>Instantiates the profile collector of the type
+<code>ENTRY_BACKEDGE_PROFILER</code>.</li>
+<li>Checks whether the <code>JET_DPGO</code> JIT can generate
method profiles of this type; if so, requests the JIT to enable
- profile generation. </li>
-<li>Checks whether the <code>OPT JIT</code> can use method
-profiles of this type. </li>
-<li>Registers the profile collector as active. </li>
+ profile generation.</li>
+<li>Checks whether the <code>OPT JIT</code> can use method
+profiles of this type.</li>
+<li>Registers the profile collector as active.</li>
</ol>
-</p>
-<p><pre>
+<pre>
JET_DPGO_PROFILE. mode=SYNC
JET_DPGO_PROFILE.entryThreshold=10000
-JET_DPGO_PROFILE.backedgeThreshold=100000
-</pre></p>
+JET_DPGO_PROFILE.backedgeThreshold=100000
+</pre>
<p>
-The last 4 lines contain the configuration of the <code>JET_DPGO_PROFILE</code>
- profiler. These properties are specific for every profile collector type.
-The first option runs entry-backedge profile mode in the SYNC mode: counters
-check is done during the code execution. Use ASYNC to run counters
-checking in a separate thread. The last 2 options set the profile readiness
-threshold. Once the profile is ready, EM dispatches the method for
+The last four lines contain the configuration of the <code>JET_DPGO_PROFILE</code>
+profiler. These properties are specific for every profile collector type.
+The first option runs entry-backedge profile mode in the SYNC mode: counters
+check is done during the code execution. Use ASYNC to run counters
+checking in a separate thread. The last 2 options set the profile readiness
+threshold. Once the profile is ready, EM dispatches the method for
recompilation with the next JIT in the current chain.
</p>
</subsection>
<subsection name="3. EM Tracing Options">
<p>
-Use the following command-line options to trace EM events:
-<br/>
-<code>-verbose:em</code> dumps all EM events.<br/>
-<code>-verbose:em.JIT_NAME</code> dumps only JIT named
-"<code>JIT_NAME</code>" related events. <br/>
-<code>-verbose:em.profiler.PROFILER_NAME</code> dumps only profiler
- "<code>PROFILER_NAME</code>" related events.<br/>
+Use the following command-line options to trace EM events:</p>
+<ul>
+<li><code>-verbose:em</code> dumps all EM events.</li>
+<li><code>-verbose:em.JIT_NAME</code> dumps only JIT named "<code>JIT_NAME</code>" related events.</li>
+<li><code>-verbose:em.profiler.PROFILER_NAME</code> dumps only profiler "<code>PROFILER_NAME</code>"
+related events.</li>
+</ul>
+<p class="example">
+Example
</p>
- <p class="example">
- Example
- </p>
- <p class="exampletext">
+<p class="exampletext">
For the default EM configuration file,
-<br/><code>
--verbose:em.OPT
-</code><br/> dumps all methods names that are compiled with
-Jitrino.OPT. According to the configuration details, these methods
-are hot methods.
-</p>
- <p class="exampletext">Alternatively, you can get almost the same information by using
-the following:
-<br/><code>
--verbose:em.profiler.JET_DPGO_PROFILE
-</code><br/> additionally dumps information about hot method profiles.
-</p>
+<code>-verbose:em.OPT</code>dumps all methods names that are compiled with
+Jitrino.OPT. According to the configuration details, these methods
+are hot methods.<br />
+Alternatively, you can get almost the same information by using
+the following:
+<code>-verbose:em.profiler.JET_DPGO_PROFILE</code> additionally dumps
+information about hot method profiles.</p>
- <p class="example">Examples of output:</p>
-<br/>
-<code>
-C:\tools\decapo>c:\tools\harmony0706\bin\java.exe -verbose:em.OPT -jar dacapo-beta051009.jar xalan<br/>
-EM: recompile start:[OPT n=1] java/io/ByteArrayOutputStream::write(I)V<br/>
-EM: recompile done:[OPT n=1] java/io/ByteArrayOutputStream::write(I)V<br/>
-EM: recompile start:[OPT n=2] java/lang/String::hashCode()I<br/>
-EM: recompile done:[OPT n=2] java/lang/String::hashCode()I<br/>
-...<br/>
-C:\tools\decapo>c:\tools\harmony0706\bin\java.exe -verbose:em.profiler.JET_DPGO_PROFILE -jar dacapo-beta051009.jar xalan<br/>
-EM: entry-backedge profiler intialized: JET_DPGO_PROFILE entry threshold:10000 backedge threshold:100000 mode:SYNC<br/>
-EM: profiler[JET_DPGO_PROFILE] profile is ready [e:10000 b:0] java/io/ByteArrayOutputStream::write(I)V<br/>
-EM: profiler[JET_DPGO_PROFILE] profile is ready [e:10000 b:59575] java/lang/String::hashCode()I<br/>
-EM: profiler[JET_DPGO_PROFILE] profile is ready [e:10000 b:0] java/lang/String::length()I<br/>
-EM: profiler[JET_DPGO_PROFILE] profile is ready [e:10000 b:0] java/lang/String::charAt(I)C<br/>
-EM: profiler[JET_DPGO_PROFILE] profile is ready [e:10000 b:0] java/nio/charset/Charset::isLetter(C)Z<br/>
-EM: profiler[JET_DPGO_PROFILE] profile is ready [e:10000 b:0] java/nio/charset/Charset::isDigit(C)Z<br/>
-EM: profiler[JET_DPGO_PROFILE] profile is ready [e:10000 b:0] java/nio/Buffer::remaining()I<br/>
-EM: profiler[JET_DPGO_PROFILE] profile is ready [e:10000 b:0] java/util/HashMap::getModuloHash(Ljava/lang/Object;)I<br/>
-... <br/>
-</code>
-<br/>
+<p class="example">Examples of output:</p>
+<pre>
+C:\tools\decapo>c:\tools\harmony0706\bin\java.exe -verbose:em.OPT -jar dacapo-beta051009.jar xalan
+EM: recompile start:[OPT n=1] java/io/ByteArrayOutputStream::write(I)V
+EM: recompile done:[OPT n=1] java/io/ByteArrayOutputStream::write(I)V
+EM: recompile start:[OPT n=2] java/lang/String::hashCode()I
+EM: recompile done:[OPT n=2] java/lang/String::hashCode()I
+...
+C:\tools\decapo>c:\tools\harmony0706\bin\java.exe -verbose:em.profiler.JET_DPGO_PROFILE -jar dacapo-beta051009.jar xalan
+EM: entry-backedge profiler intialized: JET_DPGO_PROFILE entry threshold:10000 backedge threshold:100000 mode:SYNC
+EM: profiler[JET_DPGO_PROFILE] profile is ready [e:10000 b:0] java/io/ByteArrayOutputStream::write(I)V
+EM: profiler[JET_DPGO_PROFILE] profile is ready [e:10000 b:59575] java/lang/String::hashCode()I
+EM: profiler[JET_DPGO_PROFILE] profile is ready [e:10000 b:0] java/lang/String::length()I
+EM: profiler[JET_DPGO_PROFILE] profile is ready [e:10000 b:0] java/lang/String::charAt(I)C
+EM: profiler[JET_DPGO_PROFILE] profile is ready [e:10000 b:0] java/nio/charset/Charset::isLetter(C)Z
+EM: profiler[JET_DPGO_PROFILE] profile is ready [e:10000 b:0] java/nio/charset/Charset::isDigit(C)Z
+EM: profiler[JET_DPGO_PROFILE] profile is ready [e:10000 b:0] java/nio/Buffer::remaining()I
+EM: profiler[JET_DPGO_PROFILE] profile is ready [e:10000 b:0] java/util/HashMap::getModuloHash(Ljava/lang/Object;)I
+...
+</pre>
</subsection>
<subsection name="4. More EM Configuration Samples">
<p>
@@ -317,34 +288,34 @@
prefix in the name is a Jitrino.JET instance. <br/>
Another difference in these configurations are options passed to the JIT compiler.
</p>
-<p><i>These configurations have only one JIT and no profile collection or recompilation.</i></p>
+<p class="class">These configurations have only one JIT and no profile collection or recompilation.</p>
<p><b>
<code>-Xem:jet</code> - the baseline compiler mode configuration</b></p>
-<p><pre>
+<pre>
chains=chain1
chain1.jits=JET
JET.file=<path to dll>
-</pre></p>
+</pre>
<p><b>
<code>-Xem:opt</code> - the client-static mode configuration</b></p>
-<p><pre>
+<pre>
chains=chain1
chain1.jits=CS_OPT
OPT.file=<path to dll>
-</pre></p>
+</pre>
<p><b>
<code>-Xem:server_static</code> - the server-static mode configuration</b></p>
-<p><pre>
+<pre>
chains=chain1
chain1.jits=SS_OPT
OPT.file=<path to dll>
-</pre></p>
-<br/>
-<p><i>These configurations use recompilation and collect profiles.</i></p>
+</pre>
+
+<p class="class">These configurations use recompilation and collect profiles.</p>
<p><b>
<code>-Xem:client</code> - the default configuration, or client dynamic</b></p>
-<p><pre>
+<pre>
chains=chain1,chain2
chain1.jits=JET_CLINIT
chain2.jits=JET_DPGO,CD_OPT
@@ -369,11 +340,11 @@
EB_PROF.mode=SYNC
EB_PROF.entryThreshold=10000
EB_PROF.backedgeThreshold=100000
-</pre></p>
+</pre>
<p><b>
<code>-Xem:server</code> - the server mode configuration, or server dynamic</b></p>
-<p><pre>
+<pre>
chains=chain1,chain2
chain1.jits=JET_CLINIT
chain2.jits=SD1_OPT,SD2_OPT
@@ -394,7 +365,7 @@
SD1_OPT.genProfile=EDGE_PROF
SD2_OPT.useProfile=EDGE_PROF
-</pre></p>
+</pre>
<p class="note">Note</p>
<p class="notetext">To run VM in the intereter mode, use the <code>-Xint</code>
Modified: harmony/standard/site/xdocs/subcomponents/drlvm/encoder_library.xml
URL: http://svn.apache.org/viewvc/harmony/standard/site/xdocs/subcomponents/drlvm/encoder_library.xml?view=diff&rev=519951&r1=519950&r2=519951
==============================================================================
--- harmony/standard/site/xdocs/subcomponents/drlvm/encoder_library.xml (original)
+++ harmony/standard/site/xdocs/subcomponents/drlvm/encoder_library.xml Mon Mar 19 07:12:06 2007
@@ -30,7 +30,7 @@
<subsection name="Contents">
<ol>
<li>
- <a href="#1. Revision History">Revision Ristory</a>
+ <a href="#1. Revision History">Revision History</a>
</li>
<li><a href="#2. About this document">About
this Document</a> </li>
@@ -66,26 +66,26 @@
<subsection name="1. Revision History">
- <table>
- <tr>
- <th class="TableHeading">Version</th>
-
- <th class="TableHeading">Version Information</th>
-
- <th class="TableHeading">Date</th>
- </tr>
-
- <tr>
- <td class="TableCell">Initial version</td>
-
- <td class="TableCell">
- Alexander Astapchuk, Svetlana
- Konovalova: document created.
- </td>
-
- <td class="TableCell">January 30, 2007</td>
- </tr>
- </table>
+ <table>
+ <tr>
+ <th class="TableHeading">Version</th>
+
+ <th class="TableHeading">Version Information</th>
+
+ <th class="TableHeading">Date</th>
+ </tr>
+
+ <tr>
+ <td class="TableCell">Initial version</td>
+
+ <td class="TableCell">
+ Alexander Astapchuk, Svetlana
+ Konovalova: document created.
+ </td>
+
+ <td class="TableCell">January 30, 2007</td>
+ </tr>
+ </table>
</subsection>
<subsection name="2. About this Document">
@@ -331,8 +331,7 @@
- <a name="6.1 Usage Model"><b>6.1 Usage Model</b></a>
-
+ <h3><a name="6.1 Usage Model"><b>6.1 Usage Model</b></a></h3>
<p>
The base encoding interface
<code>EncoderBase::encode()</code> is a common generic
@@ -385,7 +384,7 @@
<code>vm/vmcore/include/jvmti_dasm.h</code>.
</p>
- <a name="6.2 Under the Hood"><b>6.2 Under the Hood</b></a>
+ <h3><a name="6.2 Under the Hood"><b>6.2 Under the Hood</b></a></h3>
<p>
The engine gets its input as an operation and a set of
@@ -453,7 +452,6 @@
...
}</pre>
-
<p>
The static data that is a set of bytes is copied into the
output buffer with no analysis.<br />
@@ -476,4 +474,4 @@
</subsection>
</section>
</body>
-</document>
\ No newline at end of file
+</document>