Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[mdt-ocl.dev] Fwd: Overload resolution and dynamic dispatch patch


-------- Original Message --------
Subject: Overload resolution and dynamic dispatch patch
Date: Mon, 07 May 2012 07:59:43 +0100
From: Ed Willink <ed@xxxxxxxxxxxxx>
Reply-To: ed@xxxxxxxxxxxxx
Organization: EclipseCorner
Newsgroups: eclipse.modeling.mdt.ocl


Hi

bug/378577 provides a solution for overload resolution and dynamic dispatch. (Rather than reviewing each of the 12 commits, I suggest just synchronizing against master and viewing the 22 file diffs, many of which are trivial. Otherwise you'll needlessly follow the evolution of OperationCache to CachedTypeCheckerImpl to CachedTypeChecker and the introduction and renaming of the all.overloads option.)

In principle the changes are quite easy because there is a single point in the control flow at which issue could be addressed. This means that built-in operations are dynamically dispatchable to overloads too. Unfortunately this incurs a cost on every operation call making the dispatch cache mandatory if we are to avoid significant performance degradation. Fortunately everything seem localised in the TypeChecker, so providing a cache here helps both analyzer and evaluator.

There are many downsides to an analyzer cache; it has to be on the current environment since it is in the current environment that additional operations or properties may be added. About 20 unit tests fail if the cache is on the root environment. So if an application churns environments, new caches are created and the lazy set up costs may not be justified. Iterators created nested environments, that don't actually need a separate cache, so maybe some API trick is needed to allow these to share a parent cache. Nicolas Rouquette is about to submit a patch for QVTo that provides lookup caches; this maybe made redundant by the OCL caches or just interact very badly. The additional operation and property facilities require the cache to be invalidated (naively - I didn't go for a smart impact driven update) whenever the environment changes. I suspect that QVTo and Acceleo may use additional features and so without review their code could interact badly with an OCL cache. Imagine; a parser encounters a helper operation, invalidates the cache, parses the body, populating the cache, then trashes the cache again for the next helper operation. Revised code will be two pass parsing; pass one locates all declarations and holds the cache bypassed; pass 2 will enable the cache and analyze expressions. The legacy Complete OCL parser has a bugzilla outstanding to do this so that it can resolve forward references.

To preserve compatibility the cache option is no caching, and dynamic dispatch is no dynamism.

Because of the dangers enabling caching unthinkingly for analysis, it may be irresponsible to offer the interactive option to enable the cache. If and when QVTo or Acceleo choose to exploit the cache then they can enable it programmatically.

In summary

Overloads

This is a very simple fix localized to AbstractTypeChecker; (first [378577] commit). It is a clear fix so a legacy option is not needed.

Dynamic Dispatch

With an evaluator only cache, this is relatively simple; the legacy behaviour option avoids loss of performance and change of behaviour.

Impact Analyzer

Seems to be broken by dynamic dispatch. Any solution other than switching to dependency analysis?

Analysis Cache

Although useful, seems to have too many dangers.

----
So I think the following changes are needed.

a) remove the option to enable the analysis cache from the UI, allow applications to enable it programmatically
b) enable the evaluator to create a cache if the analyzer cannot share one

I'll commit a change for the above in a couple of hours.

    Regards

        Ed Willink


Back to the top