Revise implicit team activation

[stephan]

The language definition states that "when the control flow is passed to a team or one of its roles, the team is implicitly activated for the current thread (OTJLD §5.3)."

This approach entails two difficulties:

• It is not easily possible to determine those exact method calls where the control flow actually enters the team, because such analysis would require both the caller and the callee to be available at the same point.
• Weaving implicit team activation into all methods that could mark entering the team causes performance penalties both during weaving and during execution.

As an example for difficulties arising from the first item, consider this program fragment:

public class MyBase {
    public void bm1() { /*...*/; bm2(); /*...*/ }
    public void bm2() { /*...*/ }
}
public team class MyTeam {
    public class MyRole playedBy MyBase {
        rm1 -> bm1;
        rm2 <- replace bm2;
        callin void rm2() {
            MyTeam.this.deactivate();
            rm1();
            MyTeam.this.activate();
        }
    }
}

The intention here was to intercept base method bm2() and during the execution of rm2() invoke another base method (bm1()). Because bm1() calls bm2() attempt is made to inhibit the recursion back into the callin method by temporarily deactivating the team. However, this program does not work as intended, because the callout method rm1() is actually a public method (inherits public-ness from its base method bm1()), and as a public role method it implicitly activates the team -- thus the statement MyTeam.this.deactivate() is effectless and infinit recursion is entered.

As a solution to both issues I propose to change implicit activation as follows:

• Implicit activation should become configurable, e.g., using a new annotation @ImplicitActivation. This annotation can be attached to individual methods or a class. In the latter case it applies to all contained methods that can be called from outside the team (judging by the visibility rules for methods of a team or a role).
• By changing the default behavior to no implicit activation, the bulk of all OT/J programs could be sped up significantly.

The proposal implies a change in the language semantics, i.e., existing programs may show different behavior after the change. However, it appears that implicit activation is a feature that very few programs actually make use of.

This ticket is targeted for next yearly release, so clients have time to consider the implication of the change, and perhaps even vote against the change.

[stephan]

Implemented in r22779 as follows:

• A new marker annotation @ImplicitTeamActivation, applicable to methods and types.
• A new runtime property ot.implicit.team.activation with these values:
  • NEVER: implicit activation globally disabled
  • ALWAYS: the old mode, triggering implicit activation at all applicable locations
  • ANNOTATED: in this mode only explicitly annotated elements trigger implicit activation.

Tests are in 5.3.16-otjld-implicit-activation-annotation-1 ff.

[stephan]

Micro benchmarks similar to those by haeder confirmed the expected speedup:

Hotspot VM 1.6.0_16:

• speedup by a factor between 1.25 and 1.92

IBM J9 VM SR 6

• speedup by a factor between 2.97 and 5.03

Interestingly, in a simple scenario involving a callin method binding triggered from a call to the base method the Hotspot VM outperformed the J9. However, when manually implementing the same behavior (incl. lifting and invoking the role method), the results reversed: J9 was significantly faster.

[stephan]

OTJLD has been updated in r22899.