Function and variable inlining on Sun javac

[Ronald Fischer]

The Java language specification explicitly allows function and variable inlining
for certain cases, such as final functions and final variables.

Relating to this, I would like to know how Sun's Java Compiler deals with this.
Does it actually do inlining? What about calls to (non-final, non-static)
functions in different packages? May these be inlined too?

I tried to search Sun's Java Docs, but did not find anything useful.

Ronald

 

[Thomas Weidenfeller]

The Java language specification explicitly allows function and variable inlining
for certain cases, such as final functions and final variables.

Relating to this, I would like to know how Sun's Java Compiler deals with this.
Does it actually do inlining? What about calls to (non-final, non-static)
functions in different packages? May these be inlined too?

Chances are, some Sun guy who sometimes frequents this group and who
knows "a little bit" about the compiler will give you a much better
answer. My knowledge is from some old discussions.

IIRC a lot of optimizations have in fact been been removed from the
compiler and left to the JIT compiler in the runtime. The compiler's
optimizations did make it harder for the JIT compiler, so they had to go.

You will see that constants like "static final bool DEBUG = false" will
be inlined, but that's all I have seen recently.

/Thomas

 

[=?ISO-8859-1?Q?Daniel_Sj=F6blom?=]

The Java language specification explicitly allows function and variable inlining
for certain cases, such as final functions and final variables.

Relating to this, I would like to know how Sun's Java Compiler deals with this.
Does it actually do inlining?

It inlines primitive and string constants, since it actually *has* to do
that. Switch wouldn't work if it didn't inline such constants.

Some time ago, javac also attempted to inline some final methods, but it
actually generated illegal bytecode many times, so the feature was
discarded (see below.)

What about calls to (non-final, non-static)
functions in different packages? May these be inlined too?

No. It is not possible in general, because of the language spec
constraints on binary compatibility and the nature of dynamic linking:

QUOTE

13.4.20 Method and Constructor Body

Changes to the body of a method or constructor do not break
compatibility with pre-existing binaries.

We note that a compiler cannot expand a method inline at compile time.

The keyword final on a method does not mean that the method can be
safely inlined; it means only that the method cannot be overridden. It
is still possible that a new version of that method will be provided at
link time. Furthermore, the structure of the original program must be
preserved for purposes of reflection.

In general we suggest that implementations use late-bound (run-time)
code generation and optimization.

UNQUOTE

Note that inlining of final methods is only legal at runtime:

QUOTE

8.4.3.3 final Methods

At run time, a machine-code generator or optimizer can "inline" the body
of a final method .... Such inlining cannot be done at compile time
unless it can be guaranteed that Test and Point will always be
recompiled together, so that whenever Point-and specifically its move
method-changes, the code for Test.main will also be updated.

UNQUOTE

 

[Roedy Green]

The inlining is done by Hotspot. What is really remarkable is that a
new class being loaded may invalidate previous inlining. Hotspot has
to revert to interpretation in mid-flight and then gradually rehotspot
without the inlining for the newly overridden method.