X-Git-Url: http://git.osdn.net/view?a=blobdiff_plain;f=docs%2Fverifier.html;h=276967f72a023ffe283deb229b2b7233aecb9ac8;hb=refs%2Fheads%2Fjb-x86;hp=21bbdf0f4beb7f5f7577f4d3d3d7b20a903b2819;hpb=7c71561148b4f153e9f7af23ef6b5aa007f7de75;p=android-x86%2Fdalvik.git

diff --git a/docs/verifier.html b/docs/verifier.html
index 21bbdf0f4..276967f72 100644
--- a/docs/verifier.html
+++ b/docs/verifier.html
@@ -100,6 +100,43 @@ should make it impossible to, say, pass a value outside the range
 [-128, 127] to a function that takes a <code>byte</code> as an argument.
 
 
+<h2>Monitor Verification</h2>
+
+<p>
+If a method locks an object with a <code>synchronized</code> statement, the
+object must be unlocked before the method returns.  At the bytecode level,
+this means the method must execute a matching <code>monitor-exit</code>
+for every <code>monitor-enter</code> instruction, whether the function
+completes normally or abnormally.  The bytecode verifier optionally
+enforces this.
+
+<p>
+The verifier uses a fairly simple-minded model.  If you enter a monitor
+held in register N, you can exit the monitor using register N or any
+subsequently-made copies of register N.  The verifier does not attempt
+to identify previously-made copies, track loads and stores through
+fields, or recognize identical constant values (for example, the result
+values from two <code>const-class</code> instructions on the same class
+will be the same reference, but the verifier doesn't recognize this).
+
+<p>
+Further, you may only exit the monitor most recently entered.  "Hand
+over hand" locking techniques, e.g. "lock A; lock B; unlock A; unlock B",
+are not allowed.
+
+<p>
+This means that there are a number of situations in which the verifier
+will throw an exception on code that would execute correctly at run time.
+This is not expected to be an issue for compiler-generated bytecode.
+
+<p>
+For implementation convenience, the maximum nesting depth of
+<code>synchronized</code> statements has been set to 32.  This is not
+a limitation on the recursion count.  The only way to trip this would be
+to have a single method with more than 32 nested <code>synchronized</code>
+statements, something that is unlikely to occur.
+
+
 <h2>Verification Failures</h2>
 
 <p>