I have discovered this issue when I was investigating why
my implementation of I don't remember what demonstrates
10x worse performance then I expected.
I had a class with empty constructor and a dozen of private fields
initialized by null.
I used JRockit 1.5 - rather a modern VM.
AFAIK JLS does not require additional bytecodes but the task
of optimizing away is not that simple in general
Anyway we can think about redundant initialization as a bad style,
like unused imports or never-read local variables.
Thanks,
Mikhail
2006/3/10, Arzhan Kinzhalin <[EMAIL PROTECTED]>:
> Mikhail,
>
> It's great that we consider performance of the API lib. Let me give
> you just a couple of things to keep in mind in addition to your
> observation.
>
> Firstly, it all depends on the VM implementation which executes the
> code. For modern VMs, bytecode is far from what is actually executed,
> unless you force a VM to interpret. A JIT compiler may eliminate
> exessive bytecodes. For instance, it would be natural for a VM to
> allocate space for an object and fill it with zeroes which yeilds
> Java's default field values. JIT may rely on it and throw away
> explicit initialization to default values.
>
> Secondly, even if both allocation mechanism and JIT are not very smart
> or if the VM interprets the bytecode, consider the case when test is
> only created once during application lifecycle. Impact would be about
> zero. On another hand, if creation of test objects takes, say, 70% of
> the application execution time, optimization of the constructor would
> give dramatic improvement.
>
> So, your suggestion could give from zero to a few tens percent boost.
> In order to determine how much exactly, we need a context. Context is
> always required when performance is questioned.
>
> Thanks,
> Arzhan
> Intel Middleware Products Division
>
> On 3/10/06, Robin Garner <[EMAIL PROTECTED]> wrote:
> > Mikhail Loenko wrote:
> >
> > >Hello
> > >
> > >May be it is obvious and everybody knows it from babyhood, but anyway...
> > >
> > >Everybody knows that this two examples of code do the same:
> > >class test {
> > > public Object field = null;
> > >}
> > >
> > >and
> > >
> > >class test {
> > > public Object field;
> > >}
> > >
> > >But if you disassemble these two classes, you'll see that the first example
> > >has a 6 instruction constructor:
> > >
> > > 0: aload_0
> > > 1: invokespecial #1; //Method java/lang/Object."<init>":()V
> > > 4: aload_0
> > > 5: aconst_null
> > > 6: putfield #2; //Field field:Ljava/lang/Object;
> > > 9: return
> > >
> > >while the second one has only 3 of them:
> > > 0: aload_0
> > > 1: invokespecial #1; //Method java/lang/Object."<init>":()V
> > > 4: return
> > >
> > >So having explicit assignments of default values slows down constructor.
> > >
> > >Thanks,
> > >Mikhail
> > >
> > >
> > Mikhail,
> >
> > Is this something a bytecode compiler should be able to optimize away,
> > or is there something in the JLS that requires the additional bytecodes
> > to be generated ? Have you measured the impact (I suspect it is
> > negligible).
> >
> > cheers
> >
>
