uobjnew(8)

πŸ“¦
version 0.35.0 Β· 2 versions
, in debian bookworm, debian trixie, opensuse-leap 16.0, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

✨ uobjnew(8) β€” System Manager's Manual ✨

uobjnew, cobjnew, javaobjnew, rubyobjnew, tclobjnew β€” summarize object allocations in high-level languages πŸ¦‹

🌸 NAME 🌸

okay so the name section is basically the family tree 🧚 these are all the same tool wearing different outfits, one per language: uobjnew, cobjnew, javaobjnew, rubyobjnew, and tclobjnew. they all count object allocations in high-level languages πŸ’…

πŸ’– SYNOPSIS πŸ’–

cobjnew [-h] [-C TOP_COUNT] [-S TOP_SIZE] [-v] pid [interval]
javaobjnew [-h] [-C TOP_COUNT] [-S TOP_SIZE] [-v] pid [interval]
rubyobjnew [-h] [-C TOP_COUNT] [-S TOP_SIZE] [-v] pid [interval]
tclobjnew [-h] [-C TOP_COUNT] [-S TOP_SIZE] [-v] pid [interval]
uobjnew [-h] [-C TOP_COUNT] [-S TOP_SIZE] [-v] [-l {c,java,ruby,tcl}]
pid [interval]

πŸŽ€ DESCRIPTION πŸŽ€

bestie, this one is so good 😭 uobjnew watches object allocations in high-level languages (and yes, that includes malloc πŸ™ˆ) and then gives you a summary of the most-allocated types, ranked by how many objects there are or how many bytes they eat.

the tool leans on USDT probes that are baked into lots of high-level languages, like C, Java, Ruby, and Tcl. so your runtime has to be instrumented with those probes first πŸ”₯ sometimes that means building from source with a USDT-specific flag, like --enable-dtrace or --with-dtrace. and for Java, the process has to be launched with the -XX:+ExtendedDTraceProbes flag, or it's a no-go πŸ’€

also, this uses BPF, so only the root user can run it. sorry not sorry πŸ‘‘

🧚 REQUIREMENTS 🧚

you'll need CONFIG_BPF and bcc 🌈

✨ OPTIONS ✨

  • -C TOP_COUNT β€” show the top object types, sorted by how many instances there are πŸ“
  • -S TOP_SIZE β€” show the top object types, sorted by size instead πŸ’œ
  • -v β€” dump the BPF program that gets generated, for debugging πŸ”
  • {c,java,ruby,tcl} β€” the language you want to trace πŸ¦‹
  • pid β€” the process ID you're tracing 🫢
  • interval β€” wait this many seconds, then print the summary and bounce. if you skip it, the tool just keeps going until you hit Ctrl+C ⭐

🌷 EXAMPLES 🌷

trace object allocations in a Ruby process:

# uobjnew ruby 148

trace allocations from malloc and print the top 10 by total size (this one is giving main character energy πŸ‘‘):

# uobjnew -S 10 c 1788

πŸ’… FIELDS πŸ’…

  • TYPE β€” the object type being allocated. for C (malloc), this is the block size πŸŽ€
  • ALLOCS β€” how many objects got allocated 🧁
  • BYTES β€” how many bytes got allocated 🌈

πŸ”₯ OVERHEAD πŸ”₯

⚠️ okay this part is serious. object allocation events happen constantly, so this tool can add a real amount of overhead. use it with caution, and test it before you even think about running it in production πŸ™ˆ

that said, even thousands of allocations per second should give you reasonable overhead when you're debugging a problem, so it's not a total disaster 🫢

πŸ¦‹ SOURCE πŸ¦‹

this comes from bcc πŸ’–

πŸ”— https://github.com/iovisor/bcc

also check the bcc distribution for a companion _example.txt file. it has example usage, output, and commentary for this tool, and it's honestly a vibe πŸ“š

🌈 OS 🌈

Linux 🐧

πŸ™ˆ STABILITY πŸ™ˆ

unstable, still in development. so it's not fully baked yet, babe πŸ§ͺ

πŸ‘‘ AUTHOR πŸ‘‘

written by Sasha Goldshtein ✨

πŸ’œ SEE ALSO πŸ’œ

ustat(8), ugc(8), memleak(8) β€” iykyk 🫢


the whole page is from USER COMMANDS, dated 2018-10-09, and it's the manual for uobjnew(8), sourced from bcc. go forth and count your allocations, queen πŸ‘‘πŸ’–πŸ¦‹βœ¨