On Sep 20, 2013, at 8:29 AM, Vladimir Ivanov <vladimir.x.iva...@oracle.com> wrote:
> John, > > I don't see much value in documenting buggy behavior of early JDK7 in JDK8 > code. So, I would remove it. OK. I think I had it in mainly to make sure the unit tests did something interesting. > Regarding the test: > 31 * @run main/othervm/timeout=3600 > - why do you have timeout set to 1h? Copy-and-paste from some other test. Removed. > I like the idea how you count events. > > As a suggestion for enhancement - maybe it's more reliable to check the > "type" of event as well? To ensure that particular class was initialized. Good idea. But since each unique init event is stored in a separate variable, it's easy to check this without explicit event types. I did the following, for each of the six test cases: @@ -150,9 +150,11 @@ } private static int runFoo() throws Throwable { + assertEquals(Init1Tick, 0); // Init1 not initialized yet int t1 = tick("runFoo"); int t2 = (int) INDY_foo().invokeExact(); int t3 = tick("runFoo done"); + assertEquals(Init1Tick, t2); // when Init1 was initialized assertEquals(t1+2, t3); // exactly two ticks in between assertEquals(t1+1, t2); // init happened inside return t2; — John > Best regards, > Vladimir Ivanov > > On 9/20/13 1:38 AM, John Rose wrote: >> On Sep 12, 2013, at 7:24 PM, John Rose <john.r.r...@oracle.com >> <mailto:john.r.r...@oracle.com>> wrote: >> >>> Please review this change for a change to the JSR 292 implementation: >>> >>> http://cr.openjdk.java.net/~jrose/8024599/webrev.00/ >>> >>> Summary: Align MH semantic with bytecode behavior of constructor and >>> static member accesses, regarding <clinit> invocation. >>> >>> The change is to javadoc and unit tests, documenting and testing some >>> corner cases of JSR 292 APIs. >> >> I have a reviewer (Alex Buckley) for the documentation changes, but I >> would also like a quick code review for the unit test. >> >> Also, there is a code insertion (predicated on a "false" symbolic >> constant) which serves to document the buggy JDK 7 behavior. I'm not >> particularly attached to it, so I'm open to either a yea or nay on >> keeping it. Leaning nay at the moment. >> >> — John >> >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev@openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev