[m-rev.] for review: Box no-tag types in the Java back-end

[Michael Wybrow]

On Wed, 15 Jan 2003, Michael Wybrow wrote:
> 
> On Mon, 13 Jan 2003, Fergus Henderson wrote:
> > 
> > On 13-Jan-2003, Michael Wybrow <mjwybrow at cs.mu.OZ.AU> wrote:
> > > 
> > > +++ handle_options.m	13 Jan 2003 03:09:29 -0000
> > > @@ -411,6 +411,11 @@
> > > +	%   - box no-tag types
> > > +	%         We require no-tag types to be boxed since in Java there
> > > +	%         are some types (such as java.lang.String) that can't be
> > > +	%         cast to another type and then successfully cast back to
> > > +	%         their original type.
> > 
> > Could you please explain in more detail?
> 
> Ok, that didn't make a lot sense.  The problem actually comes about
> because for a type
> 
> 	:- type domain_error ---> domain_error(string).
> 
> the Java back-end generates something like:
> 
> 	public static class domain_error_0
> 	{
> 	    public static class domain_error_1 extends m.domain_error_0
> 	    {
> 	        public java.lang.String F1 = null;
> 
> 	        public domain_error_1(java.lang.String F1)
> 	        {
> 	            ((domain_error_0.domain_error_1) (this)).F1 = F1;
> 	        }
> 	    }
> 	}
> 
> This is fine, though with unboxed no-tag types it generates code that
> attempts not to use this boxing.  Something like the following:
> 
> 	mercury.math.domain_error_0 V_7_59 = null;
> 	java.lang.String V_8_60 = (java.lang.String) "int:'//'";
> 
> 	V_7_59 = (mercury.math.domain_error_0) V_8_60;
> 
> The final line is a compile time error since the String cannot be cast to
> mercury.math.domain_error_0.
> 
> 
> > What's the problem with casting from java.lang.String to
> > java.lang.Object and back again?
> 
> Nothing.  This is the only type you can cast java.lang.String to and back
> again.  But you can't cast the java.lang.Object to something else between
> and then cast it back to java.lang.Object before finally casting it back
> to a String -- the compiler doesn't consider this a problem but you get a
> ClassCastException at runtime from the java.lang.Object back to
> java.lang.String cast.
> 
> Preventing unboxing of no-tag types generates code that makes use of
> domain_error_1 instead of trying to cast to domain_error_0.  I assumed
> this was the correct solution to the problem.  As suggested, we could
> theoretically represent no-tag types with a java.lang.Object and this
> would allow us not to do boxing.  Having looked at the mlds though, it
> does not appear there is enough information to identify these types at
> the point of code generation.  My guess is that implementing this would
> require changes to the mlds rather than the back-end, which is probably
> a bit out of my league ATM.  Personally I think it might be easier just
> turn on boxed no-tag types for the Java back-end.  Thoughts?
> 

I never got a reply to this post.

Would it be ok to commit this change with the updated comment shown
in the following diff?

Michael


Index: handle_options.m
===================================================================
RCS file: /home/mercury1/repository/mercury/compiler/handle_options.m,v
retrieving revision 1.169
diff -u -r1.169 handle_options.m
--- handle_options.m	11 Feb 2003 02:14:25 -0000	1.169
+++ handle_options.m	11 Feb 2003 02:29:38 -0000
@@ -402,6 +402,10 @@
 	%   - using no tags
 	%	  Because Java doesn't provide any mechanism for tagging
 	%	  pointers.
+	%   - box no-tag types
+	%         We require no-tag types to be boxed since in Java 
+	%         java.lang.Object is the only type that all other types
+	%         can be successfully cast to and then cast back from.
 	%   - store nondet environments on the heap
 	%         Because Java has no way of allocating structs on the stack.
 	%   - no static ground terms
@@ -425,6 +429,7 @@
 		globals__io_set_option(nondet_copy_out, bool(yes)),
 		globals__io_set_option(det_copy_out, bool(yes)),
 		globals__io_set_option(num_tag_bits, int(0)),
+		globals__io_set_option(unboxed_no_tag_types, bool(no)),
 		globals__io_set_option(static_ground_terms, bool(no)),
 		globals__io_set_option(put_nondet_env_on_heap, bool(yes)),


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