Date: Thu, 29 Jul 1999 11:12:51 -0600 From: Nate Williams <nate@mt.sri.com> To: Gunther Schadow <gunther@aurora.rg.iupui.edu> Cc: java@FreeBSD.ORG Subject: Re: JVM optimazations? Message-ID: <199907291712.LAA07732@mt.sri.com> In-Reply-To: <199907291701.MAA28086@aurora.rg.iupui.edu> References: <199907291701.MAA28086@aurora.rg.iupui.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> I am wondering whether someone has looked into the JVM code to figure
> out whether it could not somehow be optimized at a specific point.
> I have read that the two most costly operations in Java are object
> creation and array creation.
The former I can understand, the latter I can not.
> Because all the fancy patterns and the designs of OO purists are
> heavily wasteful of many little objects and helper objects (factories,
> iterators, etc.) having a fast object allocation in JVM could speed
> things up quite significantly.
This is one of the things Sun did in JDK1.2, and even more so in
HotSpot.
> For numbers here's a comparison of costs of actions in Java taken from
> Bruce Eckel's "Thinking in Java" pp. 831f:
>
> Operation Example Normalized time
> ------------------------------- ---------------
> Local assignment i = n; 1.0
> Instance assignment
> this.i = n; 1.2
> int increment i++; 1.5
> byte increment b++; 2.0
> short increment s++; 2.0
> float increment f++; 2.0
> double increment d++; 2.0
> Empty loop while(true) n++; 2.0
> Ternary expression
> (x<0) ? -x : x 2.2
> Math call Math.abs(x); 2.5
> Array assignment a[0] = n; 2.7
> long increment l++; 3.5
> Method call funct( ); 5.9
> throw and catch exception
> try{ throw e; } catch(e){} 320
These are expensive, but have been sped up greatly in newer version of
the JDK (even in JDK1.1), as long as the exceptions aren't thrown.
> synchronized method call
> synchMethod( ); 570
This is also faster in newer versions of the JDK (even in 1.1), and is
*much* faster in JDK1.2/HotSpot.
> New Object new Object( ); 980
> New array new int[10]; 3100
This one makes sense, since it's creating 11 objects (one array object,
and 10 int objects). Array creation isn't so expensive here as creating
objects.
> As you can see, a new object is *very* expensive (not to mention the
> array here, which may be dependent on the costly object creation
> anyway.)
I agree.
> I wonder whether this is a law of nature or whether it is
> optimizeable. Imagine what impact a reduction of object allocation
> time by only 30% would have!!
>
> >From my old Anatomy of LISP school we used to manage the heap with a
> free list and an allocation from the freelist was totally cheap:
We do this in our code (after profiling of course) on heavily used
objects. We find those objects that have a high creation/deletion rate,
and throw an 'object cache', which sped up our appliation by a few
percentage, but when under load caused the system to no longer thrash
itself to death.
But, doing this generically is a difficult chore, since you don't know
the size of the objects in Java ahead of time. Also, most of the cost
is associated with GC and heap compaction, at least that's what they
told us at JavaOne. :)
In many of the newer VM's and JIT's, they are moving towards a 'train'
algorithm for allocating memory. The heap is broken up into different
'cars', and memory is only allocated out of the first car. If an object
lives longer than a certain threshold, it moves onto another 'car' in
the train, and so on.
Each 'car' in the train is GC'd at a different rate. This allows the GC
to be much more effecient, therefore it allows the allocator to be able
to have access to a much more continuous heap, thus making for faster
allocations. (No need to GC or compact the heap most of the time, and
when it's done it occurs at a much faster rate since the GC has a much
smaller data set to work with.)
> I have no JVM source code or I would look into it sometime. Is the
> source redistributeable now (it wasn't a year ago or so, where you had
> to do a special signup with SUN.)
You still do, but now all that is involved is filling out a form on the
WWW page followed by an immediate download of the JDK1.2 sources.
Sun has gone to what they call a 'Community Source License', which means
that they own it, but you can look it and do whatever you want with it,
as long as you pay them when you deploy it to your customers. :)
Nate
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-java" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907291712.LAA07732>