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 
Ed,

happy new year to you too.
366229 fixes polymorphism aspects for Pivot, not for Ecore/mature, correct? What about the related Ecore/mature bug 339952? Once this gets fixes, IA needs to move too. Once IA gets ported to Pivot, it needs to consider the full realm of all possible operation bodies too. 

Best,
-- Axel

On 1/3/2012 8:09 AM, Ed Willink wrote:

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




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

Back to the top