Improvement: Optimize CompressingRequestBody memory usage by removing Okio and redundant buffering

まず profiling-uploader のコード内で CompressingRequestBody.attemptWrite を見つけ、現在の Okio のコピー経路、圧縮ストリーム、バッファリングを確認します。Java 8 互換のストリームコピー動作を検証し、変更によって圧縮出力、ストリームの所有権、意図したメモリ削減が維持されることを確認します。

Library Name

dd-java-agent (profiling-uploader)

Library Version(s)

v1.54.0

Describe the feature you'd like

I propose optimizing CompressingRequestBody.attemptWrite to reduce memory allocation.

Currently, the implementation uses Okio for stream copying and wraps the compression stream with an extra BufferedOutputStream. This results in excessive object creation (Segments, Buffers) and double buffering overhead.

Suggested Implementation:
I suggest replacing Okio with a standard Java IO loop using a fixed-size byte[] buffer and removing the redundant outer BufferedOutputStream.

  private void attemptWrite(@Nonnull InputStream inputStream, @Nonnull OutputStream outputStream)
      throws IOException {
    // Keep the inner buffer to aggregate compressed bytes before sending to the socket
    OutputStream bufferedInnerStream = new BufferedOutputStream(outputStream) {
      @Override
      public void close() throws IOException {
        flush(); // Prevent closing the underlying stream
      }
    };

    // Remove the outer BufferedOutputStream.
    // Direct writing to the compression stream is efficient enough with a 8KB copy buffer.
    OutputStream processingStream = isCompressed(inputStream)
        ? bufferedInnerStream
        : outputStreamMapper.apply(bufferedInnerStream);

    try (OutputStream out = processingStream) {
      byte[] buffer = new byte[8192];
      int bytesRead;
      while ((bytesRead = inputStream.read(buffer)) != -1) {
        out.write(buffer, 0, bytesRead);
      }
    }
    // implicit close() on processingStream finalizes compression and flushes the inner stream
  }

Is your feature request related to a problem?

Yes. While profiling our application, we noticed that CompressingRequestBody.attemptWrite is a major contributor to heap usage.

In our specific profile, this method accounted for approximately 94% of the Heap Live Size. The heavy use of Okio intermediate objects for simple stream copying seems to be the primary cause.

Please see the attached Flame Graph for evidence:

Describe alternatives you've considered

Using InputStream.transferTo(OutputStream) is an option for Java 9+, but the proposed byte-array loop ensures compatibility with Java 8, which I believe the agent still supports.

Additional context

Note: I am not a native English speaker, so I used an AI assistant to help draft this issue to ensure clarity. Thank you for your understanding.