|View Issue Details [ Jump to Notes ]||[ Issue History ] [ Print ]|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000093||mercury||Bug||public||2009-04-08 13:27||2009-09-22 17:35|
|Target Version||Fixed in Version|
|Summary||0000093: large ground terms optimisation and unique modes|
|Description||The optimised handling of large ground terms (23 Dec) breaks mode checking when the term being constructed is declared to be unique. When the term is large enough for the optimisation to kick in, the term is assumed to be non-unique.|
I tracked this as far as "TermInst = bound(shared, [BoundInst])," in modecheck_ground_term_construct_goal_loop.
|Additional Information||On the attached example the error message is:|
uo_regression1.m:035: In clause for `init_message = uo':
uo_regression1.m:035: mode error: argument 1 had the wrong instantiatedness.
uo_regression1.m:035: Final instantiatedness of `HeadVar__1' was
uo_regression1.m:035: bound((maybe.no)), bound((maybe.no)),
uo_regression1.m:035: bound((maybe.no)), bound((maybe.no))))',
uo_regression1.m:035: expected final instantiatedness was `unique'.
|Tags||No tags attached.|
A workaround for this bug is to increase the threshold to a sufficiently large number.
This is not so much as a bug as an issue that arises because we have not (yet) resolved the tension between two competing optimizations. Opt1 is replacing code that constructs ground terms at runtime with references to static ground terms; opt2 is compile time garbage collection. Opt1 requires ground terms to be non-unique; opt2 requires ground terms to be unique. When I implemented the special handling of large ground terms, I obviously did what opt1 wants, since opt2 did not yet work anyway. Just as obviously, deciding between unique and non-unique based only on the size of the term is not a good idea, but what should the criterion be?
I think all ground terms should be non-unique, and ctgc should introduce code that makes unique copies of ground terms whenever it needs them. It has to think about this possibility *anyway*, because it has to balance the gain in speed from ctgc against the loss in speed from having to build the ground term from scratch each time. Asking it to record the result of its analysis in the form of a call to a copy predicate, or in the form of replacing a from_ground term scope with a conjunction of construct_dynamically unifications, doesn't sound like asking too much.
|Fix committed 22 Sep 2009.|
|2009-04-08 13:27||wangp||New Issue|
|2009-04-08 13:27||wangp||File Added: uo_regression1.m|
|2009-04-08 13:28||wangp||Status||new => assigned|
|2009-04-08 13:28||wangp||Assigned To||=> zs|
||Note Added: 0000165|
|2009-04-27 13:53||zs||Note Added: 0000166|
|2009-09-22 17:35||zs||Note Added: 0000188|
|2009-09-22 17:35||zs||Status||assigned => resolved|
|2009-09-22 17:35||zs||Resolution||open => fixed|