[m-rev.] for review: change the way IO actions are handled in the declarative debugger

[Julien Fischer]

On Wed, 15 Jun 2005, Ian MacLarty wrote:

> For review by anyone.
>
> Estimated hours taken: 4
> Branches: main
>
> Do not build an IO action map to pass around to predicates in the
> declarative debugger that need access to IO actions.
> Instead look these up directly in the IO state.
> When using the declarative debugger to debug the Mercury compiler invoked
> on typecheck.m, which generates about 2.3 million IO actions,
> this change reduces the memory consumption by roughly half and reduces
> the delay between the end of execution trace generation and the asking of the
> first question from about 30 seconds to about 2 seconds.
>
That's great.
(Out of curiosity how does it do with make_hlds.m, which is about three
times the size of typecheck.m?)

> Use the --force-disable-tracing option to turn off tracing in the browser
> directory, even in .debug and .decldebug grades.
>
Don't forget that you'll need to let that change bootstrap on all of
our machines before committing this.

> browser/MDB_FLAGS.in:
> 	Turn off tracing for all code in the browser directory.
>
> browser/declarative_analyser.m:
> 	Remove the IO action map from the analyser state.
>
> 	Reformat a comment.
>
> browser/declarative_debugger.m:
> 	Do not initialise the IO action map, since it no longer exists.
>
> 	For final atoms, record a range of IO action numbers, instead
>	a list of IO actions.  The actions themselves can be looked up from
> 	the numbers when needed.
>
> browser/declarative_edt.m:
> 	Remove references to the IO action map.
>
> browser/declarative_tree.m:
> 	Remove references to the IO action map.

Rewrite that as:

	browser/declarative_edt.m:
	browser/declarative_tree.m:
		Remove references to the IO action map.
>
> browser/declarative_user.m:
> 	Look up tabled IO actions directly in the IO state when they need to be
> 	displayed.
>
> 	Implement a predicate, find_tabled_io_action, which finds a particular
> 	tabled IO action given a range of IO action numbers and the sought
> 	tabled IO action number.
> 	Change several predicates to use the above instead of looking for
> 	the IO actions in a list.
>
> 	Implement a predicate, count_tabled_io_actions, which counts how many
> 	tabled and untabled IO actions are in a range of IO action numbers.
> 	Modify some predicates to use above.
>
> browser/io_action.m:
> 	Remove the io_action_map type and predicates used to construct values
> 	of this type.
>
> 	Add a new predicate, get_maybe_io_action,  which looks up a possibly
> 	untabled IO action number and returns the IO action if it was tabled.
> 	The type returned by this predicate is maybe_tabled_io_action, which
> 	has two functors: tabled/1 and untabled/1.  The argument of the
> 	untabled/1 functor is pointless, since it's just the IO action number,
> 	which is required to look up the return value of get_maybe_io_action
> 	in the first place.  Remove the pointless argument.
>
> 	Add a new type, io_action_range, for recording a range of IO actions.
>
> 	Add an explicit `may_call_mercury' assertion to the pickup_io_action
> 	foreign proc.
>
> trace/mercury_trace_declarative.c:
> 	Do not keep track of the start and finish IO action numbers for
> 	the generated portions of the EDT and do not pass these to the
> 	frontend.  We still record the current IO action number at each
> 	CALL and EXIT event.
>
> 	Fix a bug in the progress indicator which is exposed when event
> 	numbers become very big.
>

That looks fine.

Julien.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------