Extra allocations in `*TextFormatWriter` because of Java 8 target

オープン

#2,075 2026年4月29日に作成コメント 10 件リアクション 1 件担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度: 5/5
見積もり時間: 1週間以上
初心者へのやさしさ: 35/100

issue の種類: 機能追加
明瞭さ: 説明が足りない
活発さ: 静か
技術スタック: java
領域: build-system, release

調査の方向性

リンク先の行にある OpenMetricsTextFormatWriter.java から始め、プロジェクトが Java 8 をどのようにターゲットとしているかを確認してください。次に、issue に記載されている artifact の公開と multi-release JAR の選択肢を調査してください。関連する TextFormatWriter コード全体でこれらのアロケーションを削減するための、文書化され maintainer に承認されたアプローチが得られれば完了です。

索引モデルが issue の本文から書いたものです。

説明

See this line of code:

https://github.com/prometheus/client_java/blob/fa68aa7789c53d54ea1783f120194a3feae7e7b8/prometheus-metrics-exposition-textformats/src/main/java/io/prometheus/metrics/expositionformats/OpenMetricsTextFormatWriter.java#L412

Because of the Java 8 target, the string concatenation gets compiled to something like new StringBuilder().append(name).append(suffix).toString(), which allocates the memory at least twice (for the buffer in the StringBuilder and for the resulting string).

If the code was compiled for at least Java 9, it would use StringConcatFactory, which in this case would allocate the memory only for the resulting string.

Would the maintainers consider publishing multiple artifacts for different Java targets, or using multi-release JARs for the purpose of this and similar optimizations?

主要言語: Java
スター: 2.3k
フォーク: 833
平均マージ: 2日 16時間
マージ済み PR（30日）: 86

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
リポジトリをフォークし、ブランチを切って変更します。
issue 番号を参照したプルリクエストを送ります。

prometheus/client_java のほかの issue

OpenTelemetry bridge: classic histograms exported with +Inf boundary included, violating counts == boundaries + 1 contract オープン

難易度 2/5 1〜3時間初心者へのやさしさ 82/100

prometheus/client_java#2416 · コメント 1 件 · 2026年8月24日に作成
Switch Micrometer compatibility workflow to upstream once typed-descriptor path becomes default オープン

難易度 1/5 1時間未満初心者へのやさしさ 86/100

prometheus/client_java#2182 · 2026年6月3日に作成
Proposal: Prometheus HTTP API client module (prometheus-metrics-api-client) オープン

難易度 5/5 1週間以上初心者へのやさしさ 35/100

prometheus/client_java#2306 · コメント 9 件 · リアクション 4 件 · 2026年7月16日に作成
Improve Summary quantiles with DataSketches オープン

難易度 5/5 1週間以上初心者へのやさしさ 32/100

prometheus/client_java#2084 · コメント 3 件 · 2026年5月1日に作成
Classic-only histogram: consider synchronized block instead of multi-LongAdder for observe() hot path オープン

prometheus/client_java#1915 · 担当者 1 名 · 2026年2月25日に作成

prometheus/client_java の issue をすべて見る

似ている issue

Document Hot Rod migration version compatibility for Data Grid 8.6 オープン

難易度 2/5 1〜3時間初心者へのやさしさ 82/100

infinispan/infinispan#18150 · 2026年9月21日に作成
[BUG] Route53Resolver: CreateResolverEndpoint requires IpAddressRequests, but the AWS member is IpAddresses, so no SDK client can call it オープン

難易度 2/5 1〜3時間初心者へのやさしさ 84/100

floci-io/floci#4108 · 2026年9月21日に作成
[BUG] RestGetModelHandlerIT.testGetModel_whenModelIDIsInValid_thenFail depends on test order and fails when run alone オープン

untriaged

難易度 2/5 1〜3時間初心者へのやさしさ 82/100

opensearch-project/k-NN#3597 · 2026年9月21日に作成
Concurrent builder skips 'verify' phase when running 'mvn install' オープン

bug

難易度 2/5 1〜3時間初心者へのやさしさ 88/100

apache/maven#13230 · コメント 1 件 · 2026年9月21日に作成
ComponentGeNRTL leaves lnGamma stale after computing gamma オープン

bug

難易度 2/5 1〜3時間初心者へのやさしさ 82/100

equinor/neqsim#3899 · コメント 1 件 · 2026年9月21日に作成

Java の issue をもっと見る