Java Reference
In-Depth Information
Before discussing the specifics of code generation for method calls, we point
out that the interface o
ered by an Invokingnode serves to decouple it fromany
specific AST representation. For example,
n
.
getInstance( ) returns the node
whose computation evaluates to the instance on which the method should
be called, if it is a non-static method. Similarly,
n
.
getParams( ) returns an
iteration of the method's explicit parameters. Decoupling the AST's represen-
tation from its interfaces follows sound software-engineering principles and
is observed wherever possible in this chapter.
ff
For most languages, invoking a method requires not only the name of
the method, but also some information about the method's parameters, return
value, and object instance on which the call is made. The SignatureVisitor
accepts the Invokingnode to develop the
method signature
, which is retrieved
at Marker
35
. For some languages, the method call's signature is just the
beginning of identifying the actual method that will be invoked. For example,
if a parameter is supplied as type int and the only method that otherwise
matches the signature expects that parameter as type double, then that method
may su
ce for the call by
widening
the actual parameter an int to a double.
Marker
36
is charged with finding the method that su
ces for the signature
developed at Marker
35
. If none is available, or if the choice of method is
ambiguous, then an error is reported.
The code generated for a method call depends on the following attributes
of an Invokingnode:
•
The method may return a value, in which case a resource must be allo-
cated to hold the results. Marker
37
sets aside a resource if the invoked
method is not void.
For zero-address targets such as the JVM, the result will be returned on
TOS when the invoked method returns. In that case, no resource needs
to be reserved explicitly for the result.
•
The method may be static, in which case the parameters are exactly as
presented in the method call, or the method may be invoked on an object
instance, denoted here as the method's
receiver
. The code for evaluating
the receiver is generated at Marker
38
.
Most runtime architectures treat the receiver as an extra parameter, in
addition to the parameters explicitly provided. For example, the JVM
architecture specifies that the receiver should be passed as the first pa-
rameter to a non-static method.
•
Themethodmay be
virtual
, inwhich case the runtime type of the receiver
plays an important role in the method call. The VM may have internal
support for determining amethod call based on the receiver; for example,
the JVM has an invokevirtual instruction.
If no such instruction is
