Re: multiple outputs in Java

Tim Harris <tlh20@cam.ac.uk>
18 Dec 2000 00:36:22 -0500

          From comp.compilers

Related articles
multiple outputs in Java fjh@cs.mu.OZ.AU (2000-12-11)
Re: multiple outputs in Java jimbo@radiks.net (2000-12-13)
Re: multiple outputs in Java tlh20@cam.ac.uk (Tim Harris) (2000-12-18)
| List of all articles for this month |
From: Tim Harris <tlh20@cam.ac.uk>
Newsgroups: comp.compilers
Date: 18 Dec 2000 00:36:22 -0500
Organization: University of Cambridge Computer Laboratory
References: 00-12-048 00-12-054
Keywords: Java
Posted-Date: 18 Dec 2000 00:36:22 EST

> fjh@cs.mu.OZ.AU (Fergus Henderson) wrote:
>> One issue that has arisen is that our source language
>> allows procedures with multiple output arguments
>> (a.k.a. multiple return values). What's the best way
>> to compile this to Java?


  <jimbo@radiks.net> wrote:
>You might want to return all values as Vectors (java.util.Vector)
>or arrays of a particular object type. ( Vector access is
>more expensive at run-time than an array. )


I can't immediately find any published comparisons on different
possible strategies. I would imagine that the relative costs of using
arrays or instances to contain multiple return values will vary
substantially between JVM implementations -- e.g. whether the
allocation can be made on the stack, how efficiently the array or
instance can be initialized, whether the two options have the same
space costs in terms of house-keeping information, whether
bounds-checks, null-pointer checks or array-store checks can be
omitted, etc.


One of the OOPSLA '99 papers on escape analysis (I think Blanchet's)
used the instance-based idiom as one of the examples to convert to
stack allocation. I'm not sure whether that kind of analysis is now
typical in current implementations.


My gut reaction is that a reasonable approach would be to define
classes for each combination of return types and for the caller to
pass an instance to the called method. That means that the same
instance can be used in the caller if (e.g.) the call occurs within a
loop. It might also be more amenable to stack allocation -- perhaps
someone who's done work in that area can comment more authoritatively!


I've not looked at any large Mercury programs in detail -- what kinds
of situations do multiple return values tend to be used? Is it worth
avoiding multiple returns by inlining or by identifying unused return
values and compiling separate versions, each of which only returns the
single value that's actually used?


Tim


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.