[m-rev.] For review: Bug fix for Java grade RTTI definitions

[Fergus Henderson]

On 24-Feb-2004, James Goddard <goddardjames at yahoo.com> wrote:
> Bug fix for Java grade RTTI definitions.
> 
> compiler/rtti_to_mlds.m:
> 	Re-ordered the output of definitions so that subdefinitions always
> 	appear before the definition which uses them.
> 	This is neccessary because in Java, static intializers are performed at
> 	runtime in textual order, and if a definition relies on another static
> 	variable for its constructor but said variable has not been
> 	initialized, then it is treated as `null' by the JVM with no warning.
> 	This change should not effect the other back-ends.

I can see a couple of problems with this.

One is that this change would cause the Java back-end to rely on
an undocumented invariant of the MLDS, namely that there be no
forward references to static (i.e. "one_copy") data structures.
In general it is not a good idea for back-ends to rely on undocumented
invariants of the intermediate data structures, because such invariants
tend get broken during maintenance.  So at very least, any invariants
which you want to rely on should be carefully documented in mlds.m
and also in the code which produces them (in this case rtti_to_mlds.m)
or which relies on them (mlds_to_java.m).

Also, I don't think that this change is going to completely solve
the problem, because in general these definitions might be cyclic.
For example, if you have types

	:- type foo ---> f(bar) ; g.
	:- type bar ---> f2(foo) ; g2.

then the RTTI definitions for these types will be cyclic.
Your patch will solve some of the forward reference problems,
but even if there are no forward references within the RTTI definitions
for a single type, there will still be forward references between the
RTTI for different types, e.g. in this case from the RTTI for the field
types of the f/1 constructor to the type_ctor_info for the bar/0 type.

In cases where the definitions are cyclic, there is no single-pass order
of initialization which would avoid referring to uninitialized variables.
Instead, I think we will need to do the initialization in two phases:
first allocate all of the objects, then fill in the fields.
See make_class_constructor_class_member in mlds_to_il.m for
how we do this in the .NET back-end.

If you don't have time to solve this properly, please put in some XXX
comments in appropriate places explaining the problem and perhaps outlining
our intended solution.

-- 
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
--------------------------------------------------------------------------