2024-05-28 02:55 AEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000093mercuryBugpublic2009-09-22 17:35
Assigned Tozs 
Product Version 
Target VersionFixed in Version 
Summary0000093: large ground terms optimisation and unique modes
DescriptionThe 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 InformationOn 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(uo_regression1.response(bound((uo_regression1.status_ok)),
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'.
TagsNo tags attached.
Attached Files




petdr (developer)

A workaround for this bug is to increase the threshold to a sufficiently large number.

--from-ground-term-threshold 100000


zs (developer)

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.


zs (developer)

Fix committed 22 Sep 2009.

-Issue History
Date Modified Username Field Change
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
2009-04-27 12:10 petdr 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
+Issue History