Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] Partial IA code generated evaluation 
Hi Axel

A happy new year. [It seems that mail.eclipse.org has had a 5 day break.]
As highlighted by Philipp in Bug 366229, the lack of Java-like run-time polymorphism is clearly a bug, which I've just fixed.
In practice there are relatively few overloaded methods (in the library) and some of these are 'overloaded' in the specification for editorial clarity of behaviour but actually redirected to a common multi-morphic implementation.
Complete OCL documents potentially allow new overloads or 'underloads' to be introduced making one-off analysis difficult. However there may often be a clear transition between model definition and model usage beyond which the model does not change and so a final analysis can be used to identify numerous non-overloaded operations.
For code generation such a final analysis will give very useful performance (and perhaps size) gains since currently every operation call requires the two phases, locate dynamic implementation, dispatch dynamic implementation. Allowing simple logical, numeric and string operators to be inlined is obviously beneficial. The code generator therefore needs an annotating pre-analysis to set useful flags such as 'final' and identify common sub-expressions more reliably. This analysis could be shared with the IA.
I'm not convinced that the IA needs to fully consider all possible paths. Surely at some point polymorphic object x has a known type Z for which the dynamic overload of X::f is known to be provided by Y::f, so the IA need consider only the corrolaries of Y::f and detect the change of x so that an alternative overload is considered after the change; at any point the overload is known. There is perhaps a trade-off between the excessive impact detected by a single multi-morphic analysis of all X::f overloads and the transition costs to adjust notifications when the mono-morphic X::f changes to the mono-morphic Y::f. But suppose X::f has ten dependencies, and Y::f has twelve, eight of which are shared with X::f; then when X::f changes to Y::f you disable two and activate four dependencies. Perhaps there is no trade-off; carrying gratuitous disabled dependencies for all possible derived X::f probably has quadratic or worse maintenance costs, so any transition should just re-use shared, remove old and install new dependencies. 

    Regards

        Ed




On 28/12/2011 08:41, Axel Uhl wrote:
Another challenge in porting the IA to Pivot will be the semantics of OperationCallExp in the presence of redefinitions in subclasses. In OCL Ecore the somewhat bizarre, yet easy to handle for IA, semantics are that calling an OCL-defined operation from Java through the Ecore APIs will behave polymorphically, while evaluating an OperationCallExp will evaluate the expression in the statically-bound referredOperation.
For porting to IA, the traceback for an OperationCallExp would need to compute and join all traceback paths of all possible redefinitions.
How about redefinition of derived properties in subclasses? Is this possible with Pivot? 

Best,
-- Axel

On 12/23/2011 10:25 PM, Ed Willink wrote:

Hi Axel

On 23/12/2011 20:23, Axel Uhl wrote:

It would be very difficult to change the partial evaluation required
by the IA to partially evaluate compiled expressions. It would require
a capability to inject variable values into the evaluation context,
and it depends on a specific exception to be thrown when a VariableExp
is evaluated without the respective variable being in the context.
This kind of support would probably require some careful and tricky
preparation for the compilation.

The code generator currently does Static Single Assignment with almost
no evaluation context as such. Everything is on the stack, sometimes as
final variables to support visibility to nested iterator bodies.

A a = ... ;
B b = ... ;
C c = ... ;

Presumably for partial evaluation this needs to be changed to

if (cache.a == null) cache.a = ... ;
if (cache.b == null) cache.b = ... ;
if (cache.c == null) cache.c = ... ;

with cache an instance of an auto-generated class passed into the
evaluation routine.

class Cache {
A a = null;
B b = null;
C c = null;
...
}

potentially with nested caches for nested iterations.

If necessary variable reads can be differently coded.

Regards

Ed
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev



_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1901 / Virus Database: 2109/4718 - Release Date: 01/02/12

Back to the top