You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the future, the optimized memory mode will be enabled by default, since only
290
-
exceptional cases need concurrent access to the metric state. It turns out that
291
-
the objects holding the metric state (`MetricData` in OpenTelemetryJava terms)
292
-
account forvirtually all of the memory allocation in the collect cycle. By
293
-
reusing these (along with other internal objects used to hold state), **we
294
-
reduced the memory allocation of the core metric SDK by over 99%**.See
288
+
[environment variable](/docs/languages/java/configuration/).In the future, the
289
+
optimized memory mode will be enabled by default, since only exceptional cases
290
+
need concurrent access to the metric state. It turns out that the objects
291
+
holding the metric state (`MetricData` in OpenTelemetryJava terms) account for
292
+
virtually all of the memory allocation in the collect cycle. By reusing these
293
+
(along with other internal objects used to hold state), **we reduced the memory
294
+
allocation of the core metric SDK by over 99%**.See
295
295
[this blog post](https://medium.com/@asafmesika/optimizing-java-observability-opentelemetrys-new-memory-mode-reduces-memory-allocations-by-99-98-e0062eccdc3f)
0 commit comments