perf(intellij): implement GsonService singleton to reduce memory allocation

[houssemzaier]

Description

The IntelliJ plugin created 31+ new Gson() instances throughout the codebase:

• 28 instances in IdeProtocolClient (message handling hot path)
• 3 instances across ContinueBrowser and CoreMessenger

Each instantiation incurred object allocation overhead, reflection-based initialization cost, and GC pressure.

Solution

Created an application-scoped GsonService singleton following IntelliJ Platform's Light Service pattern.

Implementation:

@Service(Service.Level.APP)
class GsonService {
    val gson: Gson = Gson()
}

// Usage in regular classes with default parameter
class IdeProtocolClient(
    ...,
    private val gsonService: GsonService = service<GsonService>()
)

Performance Impact

• Before: 31+ Gson objects per session, repeated reflection overhead
• After: 1 singleton for entire application, reduced GC pressure, improved message handling performance

Files Changed

4 files modified:

• GsonService.kt (new) - Application-scoped singleton service
• IdeProtocolClient.kt - Replaced 28 Gson instantiations
• CoreMessenger.kt - Replaced 1 Gson instantiation
• ContinueBrowser.kt - Replaced 2 Gson instantiations

All changes are backward compatible.

Closes #8452

Checklist

• I have read the contributing guide
• I have updated/created relevant tests
• Code follows project conventions (Conventional Commits)

Tests

All existing tests pass. The singleton pattern maintains the same Gson behavior while reducing memory allocation. Constructor injection with default parameters ensures backward compatibility.

---

Summary by cubic

Introduce a GsonService application singleton to replace 31+ new Gson() allocations. Reduces GC pressure and speeds up hot-path message handling, addressing Linear #8452.

• Refactors
  • Added application-scoped GsonService that exposes a single Gson instance.
  • Updated IdeProtocolClient, CoreMessenger, and ContinueBrowser to inject GsonService via default constructor (service()).
  • Centralized JSON handling without behavior changes.

^{Written for commit dc0e86e. Summary will update automatically on new commits.}

[houssemzaier]

I have read the CLA Document and I hereby sign the CLA

[cubic-dev-ai]

No issues found across 4 files

[RomneyDa]

@houssemzaier looks like several e2e tests are failing. Have you been able to run this locally?

[RomneyDa]

@houssemzaier looks good but failing tests

[houssemzaier]

Hi @RomneyDa! 👋

I've rebased on the latest main branch. I noticed some test failures in the CLI checks, but they appear to be unrelated to the Gson changes in this PR.

Why I think these are unrelated:

This PR only touches 4 Kotlin files in the IntelliJ extension (extensions/intellij/), while all the failing tests are CLI UI tests in extensions/cli/src/ui/__tests__/TUIChat*.test.tsx:

• TUIChat.fileSearch.test.tsx - @ file search handling
• TUIChat.slashCommands.test.tsx - slash command filtering (3 tests)
• TUIChat.editMessage.test.tsx - message edit feature

All 5 failures are specifically on the test (macos-latest, 24) job.

I also noticed that 8 out of the last 10 PRs in the CLI PR Checks workflow have been failing with similar issues, which suggests this might be a broader flaky test issue or CI environment problem rather than something introduced by these changes.

Are these known flaky tests on macOS with Node 24, or should I investigate further?

Thanks for reviewing! 🙏

[RomneyDa]

@houssemzaier the mac 24 is known flake, thanks for rebasing!