> Costin:
>
> Is there any way to find out how many objects are created in the JVM?
>
> I remember seeing something similar on a pre-release version of MacOS X: it
> sampled the number of objects of the different core classes that were
> allocated at any moment.
>
> Otherwise, how do you find out how many objects are allocated by the
> container with each request?
There are 3 ways:
- verbosegc. Java will report how many objects it reclaims on each GC. All
you have to do is send many requests (100.000 or more ), add all the
numbers reported in GC and divide. It's an estimate, but works ( for big
numbers )
- -hprof will generate a big log file with all allocations ( then a grep
or something can give you exact informations ). You can also find who is
creating the garbage.
- OptimizeIt ( commercial - I think they have an eval version ) - it's
great if you can get it. It does almost the same thing as -hprof, but it's
a nice GUI and you save a lot of time. ( and it works on Linux :-)
As a side note - almost all performance improvements between 3.1 and 3.2
was due to recycling and avoiding garbage. One of the biggest changes in
3.3 was replacing Strings with MessageBytes - that also saved on
byte->char conversion, which is extremely expensive,
and hopefully will allow us to resolve the charset problems, since
the conversion to char can be delayed until we know the real charset ).
Right now there are around 10-20 objects per request, all created by
modules ( and almost all can be avoided - by fixing the modules ). The
only problem is that I don't think it's worth it - the time can be used in
better ways, and the improvement will not be very significant.
There are few hotspots in 3.3 that will give more performance
, and I expect we can add 20-30% more performance with only small
changes in modules ( so that can be done after 3.3 is released ), but I'm
not very motivated to do that - it is very important to set a goal and
stop when you reach it. A speed comparable with Apache standalone is
decent, and I see little reason to go further (even if it is possible and
even easy ).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
