| Overload resolution and dynamic dispatch patch [message #870171] |
Mon, 07 May 2012 06:59  |
 Ed Willink
Messages: 7669
Registered: July 2009 |
Senior Member |
|
|
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi<br>
<br>
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.)<br>
<br>
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. <br>
<br>
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.<br>
<br>
To preserve compatibility the cache option is no caching, and
dynamic dispatch is no dynamism.<br>
<br>
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.<br>
<br>
In summary<br>
<br>
<b>Overloads<br>
</b><br>
This is a very simple fix localized to AbstractTypeChecker; (first
[378577] commit). It is a clear fix so a legacy option is not
needed.<br>
<br>
<b>Dynamic Dispatch</b><br>
<br>
With an evaluator only cache, this is relatively simple; the legacy
behaviour option avoids loss of performance and change of behaviour.<br>
<br>
<b>Impact Analyzer</b><br>
<br>
Seems to be broken by dynamic dispatch. Any solution other than
switching to dependency analysis?<br>
<br>
<b>Analysis Cache<br>
</b><br>
Although useful, seems to have too many dangers.<br>
<br>
----<br>
So I think the following changes are needed.<br>
<br>
a) remove the option to enable the analysis cache from the UI, allow
applications to enable it programmatically<br>
b) enable the evaluator to create a cache if the analyzer cannot
share one<br>
<br>
I'll commit a change for the above in a couple of hours.<br>
<br>
Regards<br>
<br>
Ed Willink<br>
</body>
</html>
|
|
|
|
| Re: Overload resolution and dynamic dispatch patch [message #870213 is a reply to message #870171] |
Mon, 07 May 2012 09:55  |
Axel Uhl
Messages: 41
Registered: July 2009 |
Member |
|
|
We may consider adjusting the impact analyzer by granting it access to the dynamic dispatch cache. It may, however, lead to a situation where an operation hasn't been evaluated in a given environment yet, hence no cache entry is present for the operation, and hence the look up would provide the IA with too few operation bodies to analyze.
I claim that generally, without having evaluated all expressions on all objects, ensuring that all relevant operation bodies have been evaluated at least once, no EMF-based approach can determine a change impact because expressions affected by the change may simply not be known by the environment.
A cleaner, probably not entirely satisfying approach may involve equipping the IA with a set of EPackage objects which define the "universe" of metamodels to be considered by the IA. The IA could then, at some start-up cost, determine the operation bodies to be considered.
Opinions?
-- Axel
|
|
|
Powered by
FUDForum. Page generated in 0.04441 seconds
] 
Search
Help
Register
Login
Home
