In our Android application we experience "freezes" on some of GC_BRIDGE calls.
When that happens, we see the following in logs:
[monodroid-gc] GC cleanup summary: 2994 objects tested - resurrecting 151. [Mono] GC_BRIDGE num-objects 2994 num_hash_entries 627215 sccs size 580329 init 0.00ms df1 1722.13ms sort 965.77ms dfs2 5635.07ms setup-cb 226.27ms free-data 1022.01ms user-cb 89.15ms clenanup 5.57ms links 4864549/4864549/194960546/140 dfs passes 8644474/8346351 [Mono] GC_MINOR: (Nursery full) pause 1766.82ms, total 1767.00ms, bridge 7947.04ms promoted 32K major 43360K los 1499K
I suspect, num_hash_entries value (627215) is too big.
However, if we call
GC.Collect() manually it's always quick with something like the following in logs:
[Mono] GC_BRIDGE num-objects 197 num_hash_entries 287 sccs size 274 init 0.00ms df1 1.17ms sort 0.33ms dfs2 0.98ms setup-cb 0.16ms free-data 0.17ms user-cb 43.32ms clenanup 1.32ms links 5674306/5674306/218541494/140 dfs passes 10084180/9736021
Going through docs there's very few information about GC_BRIDGE, basically the following:
num-objects is the number of bridge objects this pass is considering, and num_hash_entries is the number of objects processed during this invocation of the bridge code..
What is the bridge object (it's certainly something different from GREF's, and according to GREF logging, we have no problems with GREF)? What could increase the number of them to over 600K? Why during explicit
GC.Collect() there's much less of them? Is there a way to cause this 'huge' GC_BRIDGE manually?