[m-rev.] for review: bug fix for `--grade java'

Fergus Henderson fjh at cs.mu.OZ.AU
Tue Feb 19 16:38:26 AEDT 2002


Estimated hours taken: 1
Branches: main

Fix a bug where building with grade `java' or `il' was incorrectly
causing the compiler to generate code to do heap reclamation on failure.

compiler/globals.m:
	Add new procedures globals__set_get_method and
	globals__io_set_gc_method, for use by handle_options.m.
	Also add some comments.

compiler/handle_options.m:
	For the IL and Java back-ends, set the GC method to `none',
	and disable heap reclamation on failure.
	Also add some comments explaining why the various options
	are implied by `--target il' and `--target java'.

Workspace: /home/ceres/fjh/mercury
Index: compiler/globals.m
===================================================================
RCS file: /home/mercury1/repository/mercury/compiler/globals.m,v
retrieving revision 1.47
diff -u -d -r1.47 globals.m
--- compiler/globals.m	11 Nov 2001 10:10:16 -0000	1.47
+++ compiler/globals.m	19 Feb 2002 05:37:53 -0000
@@ -31,6 +31,14 @@
 			% Do not go via C, instead generate GCC's internal
 			% `tree' data structure.
 			% (Work in progress.)
+
+	% The GC method specifies how we do garbage collection.
+	% This is only relevant for the C and asm back-ends;
+	% when compiling to IL or Java, where the target language
+	% implementation handles garbage collection automatically,
+	% the gc_method is set to `none'.  (XXX Maybe we should
+	% have a different alternative for that case?)
+	% 
 :- type gc_method
 	--->	none
 	;	conservative
@@ -76,6 +84,9 @@
 :- pred globals__set_options(globals::in, option_table::in, globals::out)
 	is det.
 
+:- pred globals__set_gc_method(globals::in, gc_method::in, globals::out)
+	is det.
+
 :- pred globals__set_trace_level(globals::in, trace_level::in, globals::out)
 	is det.
 :- pred globals__set_trace_level_none(globals::in, globals::out) is det.
@@ -151,6 +162,9 @@
 :- pred globals__io_set_option(option::in, option_data::in,
 	io__state::di, io__state::uo) is det.
 
+:- pred globals__io_set_gc_method(gc_method::in,
+	io__state::di, io__state::uo) is det.
+
 :- pred globals__io_set_trace_level(trace_level::in,
 	io__state::di, io__state::uo) is det.
 
@@ -259,6 +273,9 @@
 
 globals__set_options(Globals, Options, Globals ^ options := Options).
 
+globals__set_gc_method(Globals, GC_Method,
+	Globals ^ gc_method := GC_Method).
+
 globals__set_trace_level(Globals, TraceLevel,
 	Globals ^ trace_level := TraceLevel).
 globals__set_trace_level_none(Globals,
@@ -413,6 +430,14 @@
 		% XXX there is a bit of a design flaw with regard to
 		% uniqueness and io__set_globals
 	{ unsafe_promise_unique(Globals1, Globals) },
+	globals__io_set_globals(Globals).
+
+globals__io_set_gc_method(GC_Method) -->
+	globals__io_get_globals(Globals0),
+	{ globals__set_gc_method(Globals0, GC_Method, Globals1) },
+	{ unsafe_promise_unique(Globals1, Globals) },
+		% XXX there is a bit of a design flaw with regard to
+		% uniqueness and io__set_globals
 	globals__io_set_globals(Globals).
 
 globals__io_set_trace_level(TraceLevel) -->
Index: compiler/handle_options.m
===================================================================
RCS file: /home/mercury1/repository/mercury/compiler/handle_options.m,v
retrieving revision 1.130
diff -u -d -r1.130 handle_options.m
--- compiler/handle_options.m	13 Feb 2002 04:30:56 -0000	1.130
+++ compiler/handle_options.m	19 Feb 2002 05:34:10 -0000
@@ -279,11 +279,40 @@
 
 	globals__io_set_option(num_tag_bits, int(NumTagBits)),
 
-	% Generating IL implies high-level code, turning off nested functions,
-	% using copy-out for nondet output arguments,
-	% using zero tags, boxing enums, disabling no_tag_types and no
-	% static ground terms.
+	% Generating IL implies:
+	%   - gc_method `none' and no heap reclamation on failure
+	%	  Because GC is handled automatically by the .NET CLR
+	%	  implementation.
+	%   - high-level code
+	%	  Because only the MLDS back-end supports
+	%	  compiling to IL, not the LLDS back-end.
+	%   - turning off nested functions
+	%	  Because IL doesn't support nested functions.
+	%   - using copy-out for nondet output arguments
+	%	  For reasons explained in the paper "Compiling Mercury
+	%	  to the .NET Common Language Runtime"
+	%   - using no tags
+	%	  Because IL doesn't provide any mechanism for tagging
+	%	  pointers.
+	%   - boxing enums and disabling no_tag_types
+	%	  These are both required to ensure that we have a uniform
+	%	  representation (`object[]') for all data types,
+	%	  which is required to avoid type errors for code using
+	%	  abstract data types.
+	%	  XXX It should not be needed once we have a general solution
+	%	  to the abstract equivalence type problem.
+	%   - store nondet environments on the heap
+	%         Because Java has no way of allocating structs on the stack.
+	%   - no static ground terms
+	%         XXX Previously static ground terms used to not work with
+	%             --high-level-data.  But this has been (mostly?) fixed now.
+	%             So we should investigate re-enabling static ground terms.
 	( { Target = il } ->
+		globals__io_set_gc_method(none),
+		globals__io_set_option(reclaim_heap_on_nondet_failure,
+			bool(no)),
+		globals__io_set_option(reclaim_heap_on_semidet_failure,
+			bool(no)),
 		globals__io_set_option(highlevel_code, bool(yes)),
 		globals__io_set_option(gcc_nested_functions, bool(no)),
 		globals__io_set_option(nondet_copy_out, bool(yes)),
@@ -307,16 +336,42 @@
 			bool(yes))
 	),
 
-	% Generating Java implies high-level code, turning off nested functions,
-	% using copy-out for both det and nondet output arguments,
-	% using no tags, not optimizing tailcalls, no static ground terms and
-	% store nondet environments on the heap.
-	% XXX no static ground terms should be eliminated in a later
-	%     version.
-	% XXX Optimized tailcalls currently cause compilation errors in the
-	%     Java back-end because javac is unwilling to compile unreachable
-	%     code they generate. For this reason they have been disabled.
+	% Generating Java implies
+	%   - gc_method `none' and no heap reclamation on failure
+	%	  Because GC is handled automatically by the Java
+	%	  implementation.
+	%   - high-level code
+	%	  Because only the MLDS back-end supports
+	%	  compiling to Java, not the LLDS back-end.
+	%   - high-level data
+	%	  Because it is more efficient,
+	%	  and better for interoperability.
+	%	  (In theory --low-level-data should work too,
+	%	  but there's no reason to bother supporting it.)
+	%   - turning off nested functions
+	%	  Because Java doesn't support nested functions.
+	%   - using copy-out for both det and nondet output arguments
+	%	  Because Java doesn't support pass-by-reference.
+	%   - using no tags
+	%	  Because Java doesn't provide any mechanism for tagging
+	%	  pointers.
+	%   - store nondet environments on the heap
+	%         Because Java has no way of allocating structs on the stack.
+	%   - not optimizing tailcalls
+	%         XXX Optimized tailcalls currently cause compilation errors
+	%             in the Java back-end because javac is unwilling to
+	%             compile unreachable code they generate.
+	%	      For this reason they have been disabled.
+	%   - no static ground terms
+	%         XXX Previously static ground terms used to not work with
+	%             --high-level-data.  But this has been (mostly?) fixed now.
+	%             So we should investigate re-enabling static ground terms.
 	( { Target = java } ->
+		globals__io_set_gc_method(none),
+		globals__io_set_option(reclaim_heap_on_nondet_failure,
+			bool(no)),
+		globals__io_set_option(reclaim_heap_on_semidet_failure,
+			bool(no)),
 		globals__io_set_option(highlevel_code, bool(yes)),
 		globals__io_set_option(highlevel_data, bool(yes)),	
 		globals__io_set_option(gcc_nested_functions, bool(no)),

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------



More information about the reviews mailing list