0

Imagine a stateless web application that processes many requests, say a thousand per sec. All data that we create inside the processing cycle will be immediately discarded at the end. The app will use serialization/deserialization a lot, so we create and discard about 50-200kb on each request. I think it could put a big pressure on garbage collector, because GC will have to discard a large amount of short-living objects. Does it make sense to implement a pool of byte arrays to reuse them for serialization/deserialization purposes? Did anybody have such experience?

vladich
  • 568
  • 6
  • 9

1 Answers1

3

The garbage collection mechanism is built on the premise that a lot of objects created exist for a very short period of time. The first pool of objects is called the Eden Space (see this SO answer for the origin of the name) and is monitored regularly. So I would expect the garbage collector would be able to handle this.

Like most (all?) performance questions, I would measure your particular use case before applying premature optimisations. Numerous configurations are available for tuning garbage collection including parallel GC strategies (noting your 'stop the world' comment below)

Community
  • 1
  • 1
Brian Agnew
  • 268,207
  • 37
  • 334
  • 440
  • Thanks Brian. You are right in theory (and for most applications). But there are some use cases where GC is not so efficient, that's why some people implement off-heap storages etc. Amount of memory the app will allocate means we will have full GC calls pretty frequently, that means stop the world for some time. My question was mostly about real experience with reducing of GC pauses. It can be done by VM tuning, but we can only postpone Full GC calls for some time and make them less frequent, but not for much. – vladich Sep 18 '12 at 22:59
  • I think you meant concurrent GC instead of parallel, right? Parallel just means it will use many threads instead of one. And no strategy prevents stop the world anyway, even concurrent collector can only mark objects concurrently. When it compacts the heap, it stops the app anyway. – vladich Sep 18 '12 at 23:11