Add log.singletons and .verbose to track singleton class creation. #5515
Conversation
Singleton objects, usually created via `extend` or `def obj.meth`, frequently waste CPU cycles and memory. It's also easy to accidentally trigger an object to become a singleton. These properties will make it easy to track all singleton classes created by an application, along with an optional stack trace.
|
@guizmaii This is the flag I was mentioning. Run JRuby with |
|
loos good - hopefully real-world (app) usable as well ... seems like it would be, back-trace makes it so |
|
@kares Yeah I think it will be useful. If we see tons of new singleton classes being created long after an app has booted up, that's a red flag. We can flip the verbose flag and see where it's happening. I am only logging the JVM trace here, though...perhaps I should log a "full" trace with interpreted Ruby frames intact? It's going to be LONG either way. |
|
since kares also looked at this I just merged since I see no issues with this and think it will be useful |
|
How can I test this ? Is is something easy to compile locally JRuby and then use this locally compiled version ? |
|
@guizmaii Yes, check out my branch (headius/jruby) and you can build and use it. Alternatively you can pick it up from nightly builds (https://www.jruby.org/nightly) |
|
Ok thanks @headius. I'll try with the nightly builds I think :) |
|
@headius this links on the https://www.jruby.org/nightly page seem to be broken: https://www.dropbox.com/s/8b481izefs10apk/Screenshot%202018-12-18%2016.24.40.png?dl=0 |
Singleton objects, usually created via
extendordef obj.meth,frequently waste CPU cycles and memory. It's also easy to
accidentally trigger an object to become a singleton. These
properties will make it easy to track all singleton classes
created by an application, along with an optional stack trace.