[runningcode]

📜 Description

DefaultCompositePerformanceCollector sampled CPU and memory every 100ms on a java.util.Timer, the last java.util.Timer in the SDK. Timer schedules on the wall clock. After a backward clock step it stopped sampling until the clock caught back up, so transactions and profiles got no CPU or memory data for that stretch. The 30s collection-budget check runs in the same task, so it stalled too.

The loop now runs on options.getTimerExecutorService(), which schedules on System.nanoTime(), the same executor SentryTracer uses for its idle and deadline timeouts:

• ISentryExecutorService only has a one-shot schedule(), so each run reschedules itself after 100ms. That is a fixed delay, the same as the old Timer.schedule(task, delay, period).
• A generation counter, bumped in close() under timerLock, stops a run that is already in flight from rescheduling a chain that was cancelled. That matters when the run itself times out the last transaction and so closes the collector.
• close() cancels the pending run with Future.cancel(false), like Timer.cancel() did.
• The scheduling catches only RejectedExecutionException (thrown once the executor is shut down), and logs after timerLock is released.

Only scheduling changes. Every sample is stamped and computed as before, so no metric, duration or API changes. As a side effect, the collector no longer creates and destroys a thread for each burst of transactions.

💡 Motivation and Context

This is based on #5816 (JAVA-653), which made the same change to save a thread and was closed without review.

The 30s budget fix in this class (#6101) is only on 9.x.x. Expect a small conflict the next time main is merged into 9.x.x.

• resolves: Move the performance collector's sampling loop off java.util.Timer #6584
• resolves: JAVA-837

💚 How did you test it?

DefaultCompositePerformanceCollectorTest now runs on a real executor wrapped to record schedule delays, instead of a spied Timer. collector times out after 30 seconds fails without the generation counter: the run that stops the last transaction would reschedule itself. All 20 tests in that class and 120 in SentryTracerTest pass.

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.
• Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.

🔮 Next steps

None for this class on main.

#skip-changelog

🤖 Generated with Claude Code

[linear-code]

JAVA-837

[sentry]

📲 Install Builds

Android

🔗 App Name	App ID	Version	Configuration
SDK Size	io.sentry.tests.size	8.64.0 (1)	release

⚙️ sentry-android Build Distribution Settings