[9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

[John Rose]

On Sep 5, 2014, at 7:07 AM, Morris Meyer <morris.meyer at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140905/1519ab8e/attachment.html>