4

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.

TraderJoeChicago
  • 6,205
  • 8
  • 50
  • 54
  • Compaction avoids [eventual/degenerate] fragmentation. Try that with C++ and `new` ("trash" enters by allocation of objects in a manner that *can* create holes). –  Nov 21 '12 at 05:42
  • 2
    @pst Even if allocation of objects creates holes, there should be no need for compaction if your memory is not growing and if you still have a good percentage of free space not counting the holes, right? – TraderJoeChicago Nov 21 '12 at 05:48
  • @SergioOliveiraJr.most of your Objects are short lived. So it is inevitable that you hit that upper bound. For argument's sake, yes maybe if you have a large enough heap this should not be a problem. – Ajay George Nov 21 '12 at 05:52
  • @Ajay George The goal is not to create any short lived object (or garbage) after you enter the steady state. A full GC can be forced before the steady state but no GC is wanted after it. That's the point of the steady state. – TraderJoeChicago Nov 21 '12 at 06:00
  • 1
    What you said is possible right, so...? it is not conflicting with what described in the quoted text. Moreover, I believe it is almost impossible to create a steady-state app as you said, especially in Java, we relies on a lot of dynamically created objects (most immutable objects falls into this, including String) – Adrian Shum Nov 21 '12 at 07:27

3 Answers3

2

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 .

Community
  • 1
  • 1
Ajay George
  • 11,759
  • 1
  • 40
  • 48
  • When I said constant memory footprint I meant exactly this "steady state" you mentioned. I added this clarification to the question. After the application enters the steady state no object can be de-referenced. – TraderJoeChicago Nov 21 '12 at 06:06
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

Dima Tisnek
  • 11,241
  • 4
  • 68
  • 120
0

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.

aij
  • 5,903
  • 3
  • 37
  • 41