Implications of "synthetic" methods?
Charles Oliver Nutter
execution does it alter?
- Charlie
John Wilson
>
> Is there any purpose to marking a method synthetic? What aspects of
> execution does it alter?
I don't think it has any runtime effect. The main benefit I see is
that IDEs ignore synthetic methods when doing stuff like code
completion.
John Wilson
Rémi Forax
> Is there any purpose to marking a method synthetic? What aspects of
> execution does it alter?
>
but only by the compiler.
By example, accessor methods (access$xxx) are marked synthetic so
they only can be called by javac.
> - Charlie
>
Rémi
John Rose
compiler behind the user's back.
If you are trying to extract meaningful symbols (meaningful for
humans) from an API, ignore synthetics.
The JVM doesn't care about the synthetic bit, just as it doesn't care
what either the user
or the compiler "meant" by a particular method.
If you are implementing a language, and you need to emit a JVM class
with some members
meaningful for humans and others purely internal to the
implementation, consider marking
the latter synthetic. Alternatively, you could make them private, if
your design allows.
Examples of synthetics would be a field like 'this$1' in an inner
class which points to
the outer instance, or a synthetic class nested inside an interface
which carries
a method (a trait method?) associated with that interface.
An empty constructor implicitly generated for a Java class is *not*
synthetic, since it
is defined by the language as being there whether or not the user
writes it.
Nor is <clinit>, because (I guess) of history.
-- John
Rémi Forax
> Synthetic methods (and other members) are added by the language
> compiler behind the user's back.
> If you are trying to extract meaningful symbols (meaningful for
> humans) from an API, ignore synthetics.
>
> The JVM doesn't care about the synthetic bit, just as it doesn't care
> what either the user
> or the compiler "meant" by a particular method.
>
> ...
> -- John
>
Rémi
John Rose
> Is reflection ignore synthetic bit too ?
No, there are isSynthetic queries, and the system preserves the
synthetic attribute at runtime.
Reflection presents some information about the source-code form of
the program.
Other marginal oddities which the JVM ignores apart from reflection
are the isBridge and isVarArgs bits.
I would expect dynamic languages would be interested in them,
again because of what they mean about programmer intentions.
-- John
Charles Oliver Nutter
Well what about the possibility of making these bits useful as VM hints
in the future? Would there be any value in that?
I ask because I'd hoped setting a method synthetic might hurry along
inlining or omit it from stack traces.
- Charlie
John Rose
> Well what about the possibility of making these bits useful as VM
> hints
> in the future? Would there be any value in that?
> I ask because I'd hoped setting a method synthetic might hurry along
> inlining or omit it from stack traces.
Stack trace filtering is a good RFE, I suppose.
Even better would be a richer stack trace API in Java.
I've been toying with this a little. More later, time permitting.
The existing inlining heuristics already tend to favor the existing
synthetic methods. (Very short methods get inlined.)
Good inlining advice is hard to create and hard to use, like any
optimization advice. That said, the JVM could probably use
better user-settable knobs. Saying "inline all synthetics"
would be uninteresting in the present cases (I think)
and would cause language implementors to use "synthetic"
as a proxy for "inline this, really!" leading to all sorts of
contortions.
A better design point would be a robust way to record
a wide range of optimization decisions in actual JVM runs,
and then a way to feed them back to future runs.
Next, add tools for the stored profiles, to allow aggregation,
generalization, filtering, and hand-tweaking.
The first part is already present in Hotspot, awaiting
enterprising analysts. It is called +LogCompilation.
The file format is totally private and subject to change,
but quite an interesting blob of bad XML. The purpose
is field debugging of the JVM, but the information
is quite interesting, if you really care about optimization
decisions.
-- John
P.S. LogCompilation is a diagnostic "-XX" option; see:
http://article.gmane.org/gmane.comp.java.openjdk.hotspot.devel/213
John Wilson
I generate a synthetic method for every non private method in an Ng
class. Preferentially inlining these methods would probably pessimise
the performance of the program.
Omitting from a stack trace would be nice. Groovy catches and edits
stack traces at the moment (with an option to leave the trace alone
for debugging purposes). Actually I'd like to have a way of reporting
the name of my synthetic method as the name of the real method it
"shadows".
John Wilson
Charles Oliver Nutter
> The first part is already present in Hotspot, awaiting
> enterprising analysts. It is called +LogCompilation.
> The file format is totally private and subject to change,
> but quite an interesting blob of bad XML. The purpose
> is field debugging of the JVM, but the information
> is quite interesting, if you really care about optimization
> decisions.
Is that in the public, non-debug releases of, say, Java 6? I'd love to
see what compilation logs might show running JRuby stuff. For the moment
I basically trust in what you all have taught me about how to structure
code well for the JVM...it would be nice to have some feedback from the
JVM itself.
- Charlie
John Rose
> John Rose wrote:
>> The first part is already present in Hotspot, awaiting
>> enterprising analysts. It is called +LogCompilation.
>> The file format is totally private and subject to change,
>> but quite an interesting blob of bad XML. The purpose
>> is field debugging of the JVM, but the information
>> is quite interesting, if you really care about optimization
>> decisions.
>
> Is that in the public, non-debug releases of, say, Java 6? I'd love to
> see what compilation logs might show running JRuby stuff.
Since it is intended for field debugging, it does in fact work in all
Hotspot JVMs.
It is definitely a tool for JVM wizards, though, and comes with no
support,
no guarantee of fitness or foulness for any particular use or abuse...
YMMV, YYY (yada, yada, yada).
-- John
Charles Oliver Nutter
Just the way I like my tools; unsupported, unintelligible, and
infinitely useful once you figure out how to use them.
- Charlie
John Wilson
-XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation
(isn't Google wonderful!)
John Wilson
parren
> On Sep 13, 2007, at 2:55 AM, Charles Oliver Nutter wrote:
>
> > John Rose wrote:
> >> The first part is already present in Hotspot, awaiting
> >> enterprising analysts. It is called +LogCompilation.
>
> Since it is intended for field debugging, it does in fact work in all
> Hotspot JVMs.
Ubuntu Feisty:
$ java -XX:+LogCompilation
Unrecognized VM option '+LogCompilation'
Could not create the Java virtual machine.
$ java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Server VM (build 1.6.0-b105, mixed mode)
What am I doing wrong?
-peo
Tobias Ivarsson
you forgot the "-XX:+UnlockDiagnosticVMOptions" part
-peo
Attila Szegedi
> A better design point would be a robust way to record
> a wide range of optimization decisions in actual JVM runs,
> and then a way to feed them back to future runs.
> Next, add tools for the stored profiles, to allow aggregation,
> generalization, filtering, and hand-tweaking.
Yes, that'd really be something helpful -- I often think how having to
make all measurements and decisions when a Java program is launched
repeatedly is wasteful. Of course, I'm also aware how differences such as
different input can make any prerecorded assumptions invalid, but still...
On a sidenote, how'd you correlate classes between runs? My gut feeling
says that the best thing you could do is use a composite key made up from
class name and a cryptographic digest (say, 160-bit SHA1) of the .class
file. Actually, a 160-bit SHA1 in itself could probably be enough, but
just to be on the safe side...
>
> The first part is already present in Hotspot, awaiting
> enterprising analysts. It is called +LogCompilation.
> The file format is totally private and subject to change,
> but quite an interesting blob of bad XML.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
LOL
Attila.
--
home: http://www.szegedi.org
weblog: http://constc.blogspot.com
John Rose
On a sidenote, how'd you correlate classes between runs?
Charles Oliver Nutter
> On Wed, 12 Sep 2007 21:27:19 +0200, John Rose <John...@Sun.COM> wrote:
>
>> A better design point would be a robust way to record
>> a wide range of optimization decisions in actual JVM runs,
>> and then a way to feed them back to future runs.
>> Next, add tools for the stored profiles, to allow aggregation,
>> generalization, filtering, and hand-tweaking.
>
> Yes, that'd really be something helpful -- I often think how having to
> make all measurements and decisions when a Java program is launched
> repeatedly is wasteful. Of course, I'm also aware how differences such as
> different input can make any prerecorded assumptions invalid, but still...
I think it's worth bringing up that there's a particular aspect of
running JVM bytecode that's largely ignored by the optimization community...
Yes, we realize it takes some time to start up, and there are efforts to
reduce that raw startup cost.
However, a much more painful cost is how long it takes to become
performant...the users that are willing to wait a second or two for the
JVM to start up are definitely NOT willing to wait another five to ten
seconds for performance to really hit its stride. And that's where we
get stuck trying to write these language implementations and related tools.
Saving something--anything--off so that that "slow-to-fast" delay is
reduced would go a huge way toward making Java's performance myths go away.
- Charlie