Would'nt the garbage collection cause page-in references as objects are collected and co-located? Thus negatively affecting performance on page sensitive (e.g. CICS....) middleware/applications.
Seems the advice to avoid garbage collection is sound to me (from a performance perspective). <snip> I have seen the advice to avoid garbage collection in batch from IBMers before. I don't understand it, and I am curious to know where it is coming from. I doubt it is endorsed by the JVM developers. I suspect it might just be that suddenly we can measure memory management overhead, where it is more difficult in other languages. Garbage collection is Java's way of returning unused memory for reuse. You could reduce memory management overhead of a batch C++ program by removing all delete statements, and increasing the virtual storage available until it never ran out. You COULD, but no-one would recommend it as good practice. Overallocating the heap to avoid garbage collection is basically the same thing. Applications tend to evolve and grow over time. If you deliberately set up your application to avoid GC, you may be in for a rude shock when the application grows and one day GC is triggered. There can also be performance advantages from GC. GC moves objects together in storage, making it much more likely that your application data will be in the processor caches. If GC keeps your data in processor cache it will perform much better than if it's scattered across a GB of storage. </snip> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
