问题
On this link it is said that:
These pauses are the result of an inevitable requirement to compact the heap to free up space. Collectors use different strategies to delay these events, but compaction is inevitable for all commercial available collectors.
I was under the impression that if you keep the memory footprint of your application constant then there is no need for GC compaction to occur, in other words, it will only happen if you keep adding and collecting objects. If you have a big enough heap with enough free space, why would you ever need to compact when you are not creating any holes (i.e. not generating any trash) ?
I understand that keeping a constant memory footprint for a Java application is not easy, but it is possible with the right profiling tools, bootstrapping and discipline.
So isn't it reasonable to assume that with a constant memory footprint a Java application can run without any GC-introduced latencies, in other words, with no GC pauses?
EDIT: By constant memory footprint I mean a steady state as mentioned by Ajay George, when no more objects are created or de-referenced. If you keep creating objects you will eventually run out of memory and if you keep de-referencing objects you will eventually trigger the GC. So the ultimate goal is to startup, warmup, force a full GC and then enter steady state for production time.
回答1:
I was under the impression that if you keep the memory footprint of your application constant then there is no need for GC compaction to occur, in other words, it will only happen if you keep adding and collecting objects.
The moment your object is getting de-referenced (eligible for Garbage Collection) there is scope for compaction to occur. This is because of the fact that you start fragmenting your heap, much like your hard drive getting fragmented.
So isn't it reasonable to assume that with a constant memory footprint a Java application can run without any GC-introduced latencies, in other words, with no GC pauses?
GC introduced latencies are a result of the type of GC algorithms used. It is orthogonal to concept of having a constant memory footprint. Well, if you are considering the case that your app does not create or de-reference objects and has obtained a sort of steady state then maybe. Ideally this will not be the case, since most of the objects are short-lived.
Having said that, with Azul's Pauseless Collection algorithms, this might be just possible. There is an excellent discussion on that here .
回答2:
No, compaction is not really necessary, many garbage collectors don't compact, a case in point is CPython, objects never move in memory.
Compacting garbage collectors do offer one great advantage -- they get fragmented memory back.
If you don't compact, your process memory usage never goes down, because if a 4K page still has a 16-byte None in it, it cannot be freed. Steady state doesn't help here, because in a garbage collected system, steady state implies a lot of garbage being generated and recycled. Steady state being equal amounts thereof. CPython handles that through object generations (newly created objects are much more likely to become garbage).
Finally there are incremental garbage collectors, or if you went bleeding edge research, pauseless concurrent hardware-assisted garbage collectors http://www.cs.purdue.edu/homes/hosking/ismm2000/papers/heil.pdf, one commercially available http://www.azulsystems.com/products/zing/whatisit
回答3:
I believe what they mean when they say "compaction is inevitable" they simply mean that a good GC will perform compaction eventually for typical memory allocation patterns.
I don't know about Java specifically (and it probably depends on what JVM you use) but most languages will not invoke the GC at all unless you are allocating or deallocating memory. Very often it is only during allocation (as that is the only time more free memory is needed) and of course also when called explicitly.
So, for your rather strange definition of "stable state" where no allocations happen and no garbage is even generated there is no reason to invoke the GC at all if it has already done a full collection/compaction. Trying to compact the heap would of course be a waste of time in that case.
来源：https://stackoverflow.com/questions/13486917/is-compaction-really-inevitable-for-all-jvm-gc-implementations