[m-rev.] Java back-end milestone

[Peter Ross]

On Wed, Dec 03, 2003 at 02:44:01AM +1100, Fergus Henderson wrote:
> On 02-Dec-2003, Peter Ross <pro at missioncriticalit.com> wrote:
> > On Tue, Dec 02, 2003 at 08:59:37PM +1100, Fergus Henderson wrote:
> > > Index: compiler/mlds_to_java.m
> > > +%	RTTI: currently we generate RTTI data which compiles,
> > > +%		but which is not actually usable.  The class
> > > +%		hierarchy of the RTTI classes in java/runtime/*.java
> > > +%		needs quite a bit of work.  It is implemented in a way
> > > +%		that mirrors what we do for C, but in C we rely on being
> > > +%		able to coerce between different types that have the same
> > > +%		initial fields (e.g. FA_TypeInfo_Struct and TypeInfo_Struct),
> > > +%		and that doesn't work in Java.
> > 
> > Shouldn't the RTTI for java be very similar to what is done for the .NET
> > backend?  After all both backends have similar problems.
> 
> Ideally yes, but for historical reasons this is currently not the case.
> 
> The RTTI for the .NET back-end uses a low-level data representation, IIUC,
> but in the long run it would be nicer to use a high-level data
> representation.  For the Java back-end, we have gone straight to
> a high-level data representation for both RTTI and ordinary data types.
> 
Yes it definitely would be nicer to use a high level representation.
Zoltan was planning on producing a version of the RTTI entirely
implemented in Mercury, but that doesn't appear to be materializing.
Using the low-level representation on the IL backend is painful, which
is why I devoted a lot of time to writing the algorithms for RTTI in
Mercury and using only C# to access the actual fields in the RTTI.  I
assumed that this work would also have been useful for the Java backend.

> AFAIK the .NET back-end also mirrors what we do for C, in that the layouts
> of the RTTI data types match the layouts used for C.  But the .NET back-end
> does so using a low-level representation (i.e. object[]) rather than
> named types.  This means that the coercions mentioned above don't cause
> any trouble.
> 
Yes that is correct, I assumed incorrectly that the java backend would
do something similar.

> > I did a lot of work on implementing a lot of the RTTI in Mercury (see
> > rtti_implementation.m).  All that it should require is that one
> > implements the foreign_proc functions which are used to access various
> > fields in the RTTI structures.
> 
> Firstly, the documentation in rtti_implementation.m says
> 
> 	% This module is not complete, currently only enough functionality is
> 	% present to implement type_info comparisons and unifications (which
> 	% is enough to get univ working).
> 
> If that is not correct, could you please update it?
> 
No that is no longer correct.  However I am no longer sure how much
functionality has been implemented (it was a long time ago and I
essentially was just fixing a test case a time in test suite), but I
believe most of it except for that required to construct types.  I will
try and work it out and update the comment.

> Secondly, there are 50 different procedures defined in C# in
> rtti_implementation.m.  That's quite a lot.  So implementing all of
> those in Java would be quite a bit of work, even if it wasn't for the
> issue of low-level vs high-level data.
> 
They are essentially all accessor functions, and the Java implementation
should simply be the same as the C# implementation so IMO the
implementation work should be on the order of 1 day.

In summary, it appears that you have an implementation decision for the
Java backend.
    * Keep developing a high level RTTI.
    * Reuse the work done for the IL backend.
    * Wait for zs to implement outputting the RTTI structures in Mercury.

My personal preference is the third option.  However I think you should
seriously look at the second option as this would lead us to only having
two RTTI implementations rather than a third with all the associated
maintenance headaches.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------