On Sep 5, 2014, at 7:07 AM, Morris Meyer <morris.me...@oracle.com> wrote:
> That assert in a static method could be pulled out to a static block.
>
> Regarding the asserts in the LambdaForms code, my feeling is that in code
> that is still in the process of being refactored, that they are critical to
> maintain integrity. After the dust settles, creating a debugging subclass
> used for testing, and moving some of the asserts to unit tests might be
> helpful for performance.
That's a good point. Isolating debug/assert code into special classes (such as
inner classes) can avoid loading that code at all, in the normal case. That
might help startup a little, and help organize the code for some purposes.
As a very local optimization, I like to put complex assertion logic into a
subroutine which is called only by assert code, and which therefore is
completely dead in most cases. For example, an accessor of
LambdaForm.NamedFunction:
MemberName member() {
assert(assertMemberIsConsistent());
return member;
}
// Called only from assert.
private boolean assertMemberIsConsistent() { ... }
Usually it is good style to place the assert logic subroutine right next to the
main logic that it tests, but (as Morris says, after the dust has settled) it
may be reasonable to move it into an associated inner class or package-local
class.
— John_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
