-
Notifications
You must be signed in to change notification settings - Fork 7
β Why generation number in heap dump are in random order?
When you read heap dump you have lines like this :
{"address":"0x7fb27108e3e8", "type":"IMEMO", "class":"0x7fb26aa79cd8", "references":["0x7fb26aa7aa20", "0x7fb26aa7b0b0", "0x7fb26aa7a9d0"], "file":"/Users/bti/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.5.2/lib/active_record/attributes.rb", "line":106, "method":"reset_column_information", "generation":53, "memsize":40, "flags":{"wb_protected":true, "old":true, "uncollectible":true, "marked":true}}
We can read on How I spent two weeks hunting a memory leak that:
you can enable object creation tracing, and for each newly created object the location where it was instantiated (source file, line) will be saved and accessible later.
I generated a heap dump from a ruby program... and extract generation number in the dump with jq
.
$ cat tmp/2017-04-10T19:32:45+02:00-heap.dump | jq 'select(.generation != null) | "\(.generation) "' -j
... 57 57 57 57 58 51 58 58 58 58 58 51 58 58 58 58 58 58 51 58 58 58 58 58 51 58 51 51 51 51 51 51 51 51 51 51 ...
As you can see generation number are in random order. After watching Methods of Memory Management in MRI by Aaron Patterson it's a normal behavior to realocate in other generation.
In order to classify objects as new or old the GC does the following: whenever it marks an object in a mark-phase (which means that the object will survive this GC run) it promotes it to the old generation. Watching and Understanding the Ruby 2.1 Garbage Collector at Work
A generational GC (also known as ephemeral GC) divides objects into generations and, on most cycles, will place only the objects of a subset of generations into the initial white (condemned) set. Tracing garbage collection
As Koichi said :
Generation is an age of an object. If you measure ages of people walking in a street, it will be random numbers.