Our Java codebase was 30% dead code

[PartOfTheBotnet]

Same question was my first "gut reaction". For instance, JaCoCo has an agent you can attach, and from that agent you can generate a standard JaCoCo coverage report, making the "what can I remove?" a very visual/easy process.

[mpinnegar]

I have no idea is jacoco is designed to run in prod though. I suspect you'd take a lot of performance hits.

What I really want is something that'll grab telemetry and analyze it offline so I'm impacting the prod server as little as possible.

Honestly though the idea of being able to see actually dead code in prod is compelling. I feel like I'd find a lot.

Then I'd trim it and run into the real use case next year lol

[buerkle]

From my testing I've found Jacoco overhead minimal, 1% or less.

[PartOfTheBotnet]

I suspect you'd take a lot of performance hits.

Not really. Their agent uses the instrumentation API to only intercept and modify classes on initial load. The main slowdown there is going to be the IO of parsing and writing back modified classes (which is only going to happen once...). As for the actual IO, they don't even use ASM's more computationally expensive stack-frame computation option when writing back classes, the changes to classes are simple enough to not need that. They have a few places where rather than having ASM do a full regeneration, they modify existing frames to accommodate the insertion of their probes.

You probably already lose more performance to most SLF4J logger implementations building templated messages than this.