ccristian / caliper

Automatically exported from code.google.com/p/caliper
Apache License 2.0
0 stars 0 forks source link

Existence of finalizer causes experiment to fail (@ instrument=micro) #264

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
During prototyping of an object pool [1], I added a finalizer on the handle to 
detect resource leaks (e.g. due to race conditions). When running a simple 
benchmark with Caliper 1.0b1 it consistently failed by exceeding the trial 
period. I temporarily reverted 0.5rc1 whose behavior differs enough that my 
benchmark worked.

Later when actually performance tuning and my tests were robust, I removed the 
finalizer. This improved performance as expected, as well as let 1.0b1 succeed.

[1] https://github.com/ben-manes/multiway-pool

Original issue reported on code.google.com by Ben.Manes@gmail.com on 14 Jul 2013 at 10:38

GoogleCodeExporter commented 9 years ago
Is there a reduced test case that can reproduce this issue?  There are so many 
versions of what "added a finalizer" can mean, that I'm not quite sure where to 
start with this.

Original comment by gak@google.com on 15 Jul 2013 at 5:10

GoogleCodeExporter commented 9 years ago
I can write one this evening, but effectively creating many objects with 
Object.finalize() methods, which has GC implications. 

Original comment by Ben.Manes@gmail.com on 15 Jul 2013 at 5:29

GoogleCodeExporter commented 9 years ago
Reproduced:
https://gist.github.com/ben-manes/6005989

Basically if you do any work in an Object's finalize() then Caliper's 
instrumentation of the GC probably causes the Finalizer thread to not be able 
to keep up, resulting in a timeout.

Original comment by Ben.Manes@gmail.com on 16 Jul 2013 at 5:42

GoogleCodeExporter commented 9 years ago
Yeah, that's definitely no good. 

Original comment by gak@google.com on 16 Jul 2013 at 5:06