[m-dev.] for review: zero uninstantiated fields of constructions

David Overton dmo at cs.mu.OZ.AU
Fri Jun 4 14:41:52 AEST 1999


On Wed, May 26, 1999 at 07:18:25PM EST, Thomas Conway wrote:
> On Wed, May 26, 1999 at 03:32:02PM EST, David Overton wrote:
> > > Tyson suggested that the problem is due to the fact that when we create
> > > the cell on the heap the tail cell contains garbage which the boehm gc
> > > garbage collector may interpret as a pointer.
> > > Setting the tail cell to zero gives us the required speedup,
> > > if only just!
> > > 
> > > run.nolco.vn:       251950 ms
> > > run.lco.vn.zero:    249833 ms
> > > 
> > 
> > I'll change the code generator to do this.
> 
> Make sure it has a separate switch to enable or disable this
> since the accurate collector (when it copes with such data structures)
> won't need the cell to be zeroed and so you can avoid the work.
> 
I've made this change.  Here are some timings for compiling
make_hlds.m with various compilers (all compiled in the asm_fast.gc grade,
running on murlibobo):

compiler built with -O6

202.841u 1.062s 3:24.12 99.8%   9+494k 0+239io 0pf+0w
201.909u 0.991s 3:23.39 99.7%   9+494k 0+267io 0pf+0w
203.158u 1.001s 3:24.50 99.8%   9+493k 0+256io 0pf+0w

-O6 --optimize-constructor-last-call (no zeroing of uninstantiated fields)

192.669u 1.110s 3:19.69 97.0%   9+503k 703+251io 0pf+0w
193.836u 0.901s 3:15.18 99.7%   9+503k 44+254io 0pf+0w
192.275u 0.909s 3:13.78 99.6%   9+502k 45+261io 0pf+0w

-O6 --optimize-constructor-last-call (with zeroing of uninstantiated fields)

192.454u 1.039s 3:19.13 97.1%   9+502k 694+249io 0pf+0w
192.948u 0.871s 3:14.51 99.6%   9+503k 45+253io 0pf+0w
191.979u 0.959s 3:13.48 99.7%   9+503k 45+241io 0pf+0w

So for a large program, zeroing of uninstantiated fields doesn't seem
to make a huge amount of difference, but is probably still worthwhile.

Tom, would you like to review this?

Estimated hours taken: 1

compiler/unify_gen:
	When using conservative GC, zero uninstantiated fields of
	construction unifications so that the GC doesn't think they
	are pointers.


Index: unify_gen.m
===================================================================
RCS file: /home/mercury1/repository/mercury/compiler/unify_gen.m,v
retrieving revision 1.83.2.14
diff -u -r1.83.2.14 unify_gen.m
--- 1.83.2.14	1999/06/03 01:39:19
+++ unify_gen.m	1999/06/03 15:33:51
@@ -736,9 +736,25 @@
 		code_info__acquire_reg_for_var(Var, Reg),
 		code_info__set_var_reference_location(Var, Reg),
 		code_info__produce_variable(LHSVar, Code0, RVal),
-		{ Code1 = node(
-			[assign(Reg, mem_addr(heap_ref(RVal, Tag, FieldNum))) -
-				"place reference in reg"]) },
+		code_info__get_globals(Globals),
+		{ globals__get_gc_method(Globals, GCMethod) },
+		{ GCMethod = conservative ->
+			% For the conservative GC, we need to zero
+			% uninstantiated fields so the GC doesn't think they
+			% are pointers.
+			ZeroCode = node([
+				assign(field(yes(Tag), RVal, 
+					const(int_const(FieldNum))),
+					const(int_const(0)))
+					- "zero uninstantiated field"
+				])
+		;
+			ZeroCode = empty
+		},
+		{ Code1 = tree(ZeroCode, node([
+			assign(Reg, mem_addr(heap_ref(RVal, Tag, FieldNum)))
+				- "place reference in reg"
+			])) },
 		{ Code2 = tree(Code0, Code1) }
 	;
 		{ Code2 = empty }
-- 
David Overton       Department of Computer Science & Software Engineering
MEngSc Student      The University of Melbourne, Australia
+61 3 9344 9159     http://www.cs.mu.oz.au/~dmo
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list