# GC Published articles for GC. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## JDK 27 Runtime Updates Release Notes DevFeed: [JDK 27 Runtime Updates Release Notes]() Original publisher: [Read original article]() Author: Billy Korando Published: 2026-09-12T00:00:00Z Content type: release Language: en Sources: [Inside Java]() Topics: [JDK 27](), [Release notes](), [releases](), [Java]() Tags: [env-file-security](), [gc](), [jdk-27](), [memory](), [net-conf](), [passwords](), [performance](), [release](), [release-notes]() ### AI overview This article reviews runtime updates in JDK 27, including G1GC becoming the default garbage collector in all cases, Compact Object Headers being enabled by default, and improved JFR redaction and filtering for sensitive information such as passwords and API keys. ### Source excerpt Let's review the performance updates, new runtime features, and other changes to existing features that are in the JDK 27 release! ## Using OxCaml to implement type-safe reference counting between OCaml and Python DevFeed: [Using OxCaml to implement type-safe reference counting between OCaml and Python]() Original publisher: [Read original article]() Author: Nicolas Trangez Published: 2026-06-15T00:00:00Z Content type: tutorial Language: en Sources: [Jane Street]() Topics: [OCaml](), [Python](), [Programming language](), [Programming](), [Data analysis](), [Machine learning]() Tags: [compiler](), [gc](), [memory](), [memory-management](), [ocaml](), [parallelism](), [programming-language](), [python]() ### AI overview Jane Street describes using OxCaml extensions to implement type-safe reference counting between OCaml and Python. The approach addresses delayed deallocation when objects cross the language boundary, including for large data frames and scarce resources such as GPU memory. ### Source excerpt Jane Street is known for being an OCaml shop, but for years now Python has been our second major programming language, acting as the primary tool for data analysis and (especially importantly these days) machine learning. Most of our traders and researchers think and write in Python, even as the majority of our infrastructure is written in OCaml. ## Testing Java Memory Management with Chronicle-FIX using AI DevFeed: [Testing Java Memory Management with Chronicle-FIX using AI]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2026-06-05T09:03:26Z Content type: article Language: en Sources: [Vanilla Java]() Topics: [Java](), [Testing](), [Benchmark](), [Artificial Intelligence]() Tags: [ai](), [benchmark](), [benchmarks](), [claude](), [code](), [codex](), [gc](), [java](), [low-latency](), [opinion](), [testing](), [ubuntu](), [ubuntu-24-04]() ### AI overview This article reports on using Codex to create and test a JLBH benchmark for Chronicle-FIX from documentation and sample code. On a Java 25.0.2 system running Ubuntu, the benchmark measured half-round-trip latency of 2.4 to 3.7 microseconds, with about 11 microseconds at the 99.999th percentile under Parallel GC. The author presents AI as useful for benchmark code and experimentation, while cautioning that business logic generally requires substantial human authorship or rewriting. ### Source excerpt While I am sceptical of using AI for release code, it has plenty of uses that previously weren't practical, such as determining how easy your software is to use. If an AI can "figure it out" with a few hints, then you are on the right track. For me, the value of AI is what you learn using it. For more Techincal Information on Chronicle-FIX What AI Does Well and What It Doesn't Claude and Codex are effective for producing idiomatic code; for low-latency code, it needs a significant body of example code. In this case, it was able to utilise sample code for benchmarks. If it was being used to write business logic, it would need the code to be mostly complete examples, and then it could write variations on that. If you were starting, it would be better to either; a) get it to write something functionally correct with the expectation you would rewrite it again manually, or b) write the code yourself and use AI to assist you in improving it. The AI Benchmark Trial I gave Codex (GPT-5.5) the task of writing a JLBH benchmark for Chronicle-FIX from documentation and sample code, testing the round-trip latency of W -> D and D -> 8 messages. The throughput is 50K/s each way. The W market data message is ~512 bytes, and the D new order signal and '8' execution reports are a small ~160 bytes. The test is run for 15 minutes each. I verified the benchmark was written but avoided hand-tuning it; then I asked it to trial different GC options, expecting they wouldn't make much difference, since the application is low GC; however, there might still be some difference. The system is using Java 25.0.2 on a Ryzen 9 9955HX3D with 64 GiB of RAM in a laptop running Ubuntu 24.04.04 LTS. A significant difference between JMH and JLBH benchmark harness is that JLBH supports many concurrent asyncrhonous inflight actions whereas JMH tests one action at a time. The Results The half-round-trip time (RTT/2) was between 2.4 and 3.7 microseconds (< 0.004 milliseconds). For the recommended Parallel GC, t ## Recent lld/ELF performance improvements DevFeed: [Recent lld/ELF performance improvements]() Original publisher: [Read original article]() Published: 2026-04-12T07:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [LLVM](), [Benchmark](), [benchmarking](), [clang](), [Chromium]() Tags: [2026](), [benchmark](), [chromium](), [clang](), [gc](), [gdb](), [improvements](), [linker](), [lld](), [llvm](), [macos](), [overhead](), [patches](), [performance]() ### AI overview This article reports LLVM lld/ELF linker performance improvements from parallelizing link phases and reducing task-runtime overhead. Benchmarks show a 1.34x speedup over lld 22.1 for a Release+Asserts clang link and a 1.09x speedup for a Chromium debug link, while mold and wild remain faster in the comparisons described. ### Source excerpt Updated in 2026-05. Since the LLVM 22 branch was cut, I've landed patches that parallelize more link phases and cut task-runtime overhead. This post compares current main against lld 22.1, mold, and wild. Headline: a Release+Asserts clang --gc-sections link is 1.34x as fast as lld 22.1; Chromium debug with --gdb-index is 1.09x as fast. mold and wild are still ahead -- the last section explains why. ## wastrel milestone: full hoot support, with generational gc as a treat DevFeed: [wastrel milestone: full hoot support, with generational gc as a treat]() Original publisher: [Read original article]() Author: Andy Wingo Published: 2026-04-09T13:48:04Z Content type: article Language: en Sources: [wingolog]() Topics: [WebAssembly](), [scheme](), [toolchain](), [gcc]() Tags: [binaries](), [garbage-collection](), [gc](), [gcc](), [hoot](), [optimization](), [repl](), [scheme](), [spidermonkey](), [toolchain](), [treats](), [v8](), [wasm](), [wastrel](), [web](), [webassembly]() ### AI overview The article describes a Wastrel milestone: compiling WebAssembly files produced by the Hoot Scheme toolchain into native binaries, including a console-based read-eval-print loop. It covers the build process, runtime modules, binary size, dependencies, and initial performance observations. ### Source excerpt Hear ye, hear ye: Wastrel and Hoot means REPL! Which is to say, Wastrel can now make native binaries out of WebAssembly files as produced by the Hoot Scheme toolchain, up to and including a full read-eval-print loop. Like the REPL on the Hoot web page, but instead of requiring a browser, you can just run it on your console. Amazing stuff! try it at home First, we need the latest Hoot. Build it from source, then compile a simple REPL: echo '(import (hoot repl)) (spawn-repl)' > repl.scm ./pre-inst-env hoot compile -fruntime-modules -o repl.wasm repl.scm This takes about a minute. The resulting wasm file has a pretty full standard library including a full macro expander and evaluator. Normally Hoot would do some aggressive tree-shaking to discard any definitions not used by the program, but with a REPL we don't know what we might need. So, we pass -fruntime-modules to instruct Hoot to record all modules and their bindings in a central registry, so they can be looked up at run-time. This results in a 6.6 MB Wasm file; with tree-shaking we would have been at 1.2 MB. Next, build Wastrel from source, and compile our new repl.wasm: wastrel compile -o repl repl.wasm This takes about 5 minutes on my machine: about 3 minutes to generate all the C, about 6.6MLOC all in all, split into a couple hundred files of about 30KLOC each, and then 2 minutes to compile with GCC and link-time optimization (parallelised over 32 cores in my case). I have some ideas to golf the first part down a bit, but the the GCC side will resist improvements. Finally, the moment of truth: $ ./repl Hoot 0.8.0 Enter `,help' for help. (hoot user)> "hello, world!" => "hello, world!" (hoot user)> statics When I first got the REPL working last week, I gasped out loud: it's alive, it's alive!!! Now that some days have passed, I am finally able to look a bit more dispassionately at where we're at. Firstly, let's look at the compiled binary itself. By default, Wastrel passes the -g flag to GCC, which results in bi ## Wastrel Compiles Hoot Scheme-to-WebAssembly Output DevFeed: [Wastrel Compiles Hoot Scheme-to-WebAssembly Output]() Original publisher: [Read original article]() Author: Andy Wingo Published: 2026-03-31T20:34:23Z Content type: article Language: en Sources: [wingolog]() Topics: [WebAssembly](), [Compiler](), [scheme]() Tags: [accidentally-quadratic](), [aot](), [bigint](), [bignums](), [compiler](), [compilers](), [exception-handling](), [exceptions](), [gc](), [gcc](), [gmp](), [hoot](), [igalia](), [library](), [maps](), [precision](), [scheme](), [standard](), [tail-calls](), [wasm](), [wastrel](), [webassembly](), [whippet]() ### AI overview The article describes recent work on Wastrel, an ahead-of-time WebAssembly compiler, including compiling output from the Hoot Scheme-to-Wasm compiler. It covers implementing bignum operations with mini-gmp and updating Hoot to use standardized WebAssembly exception handling. ### Source excerpt Good day! Today (tonight), some notes on the last couple months of Wastrel, my ahead-of-time WebAssembly compiler. Back in the beginning of February, I showed Wastrel running programs that use garbage collection, using an embedded copy of the Whippet collector, specialized to the types present in the Wasm program. But, the two synthetic GC-using programs I tested on were just ported microbenchmarks, and didn't reflect the output of any real toolchain. In this cycle I worked on compiling the output from the Hoot Scheme-to-Wasm compiler. There were some interesting challenges! bignums When I originally wrote the Hoot compiler, it targetted the browser, which already has a bignum implementation in the form of BigInt, which I worked on back in the day. Hoot-generated Wasm files use host bigints via externref (though wrapped in structs to allow for hashing and identity). In Wastrel, then, I implemented the imports that implement bignum operations: addition, multiplication, and so on. I did so using mini-gmp, a stripped-down implementation of the workhorse GNU multi-precision library. At some point if bignums become important, this gives me the option to link to the full GMP instead. Bignums were the first managed data type in Wastrel that wasn't defined as part of the Wasm module itself, instead hiding behind externref, so I had to add a facility to allocate type codes to these "host" data types. More types will come in time: weak maps, ephemerons, and so on. I think bignums would be a great proposal for the Wasm standard, similar to stringref ideally (sniff!), possibly in an attenuated form. exception handling Hoot used to emit a pre-standardization form of exception handling, and hadn't gotten around to updating to the newer version that was standardized last July. I updated Hoot to emit the newer kind of exceptions, as it was easier to implement them in Wastrel that way. Some of the problems Chris Fallin contended with in Wasmtime don't apply in the Wastrel case: sinc ## Kubo 0.40.0 adds reproducible CID Profiles, import cleanup, diagnostics, and gateway improvements DevFeed: [Kubo 0.40.0 adds reproducible CID Profiles, import cleanup, diagnostics, and gateway improvements]() Original publisher: [Read original article]() Author: Ipfs Published: 2026-02-25T00:00:00Z Content type: release Language: en Sources: [IPFS]() Topics: [Software](), [sharding](), [Go Language](), [configuration]() Tags: [gc](), [go](), [memory](), [release](), [release-notes](), [sharding]() ### AI overview Kubo 0.40.0 introduces reproducible file imports through CID Profiles, automatic cleanup of interrupted flatfs operations, improved connectivity diagnostics and gateway behavior, and reduced memory usage and garbage-collection overhead through its Go 1.26 toolchain. ### Source excerpt Just released: Kubo 0.40.0! ## Comparing Java ZGC and G1 for Tail Latency in a Quarkus Microservice DevFeed: [Comparing Java ZGC and G1 for Tail Latency in a Quarkus Microservice]() Original publisher: [Read original article]() Published: 2025-09-17T15:09:00Z Content type: article Language: en Sources: [Gunnar Morling]() Topics: [Java](), [benchmarking](), [Quarkus](), [Databases]() Tags: [benchmarking](), [gc](), [java](), [lts](), [performance](), [postgres](), [quarkus](), [sample]() ### AI overview This article compares Java's ZGC and G1 garbage collectors using default settings in a sample Quarkus microservice that reads data from a Postgres database. The benchmark applies 1,000 requests per second and measures request latencies on a four-core, 4 GB RAM instance. The supplied excerpt does not include the comparison results. ### Source excerpt Table of Contents ZGC Allocation Stalls Summary In the "Let's Take a Look at...!" blog series I am exploring interesting projects, developments and technologies in the data and streaming space. This can be KIPs and FLIPs, open-source projects, services, relevant improvements to Java and the JVM, and more. The idea is to get some hands-on experience, learn about potential use cases and applications, and understand the trade-offs involved. If you think there's a specific subject I should take a look at, let me know in the comments below. Java 25 was released earlier this week, and it is the first Java release with long-term support (LTS) which ships with Generational ZGC as the one (and only) flavor of the ZGC garbage collector. ZGC itself is a relatively new concurrent collector, originally added in Java 11. ## 0.6.6: Memory Management Improvements DevFeed: [0.6.6: Memory Management Improvements]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2025-03-19T16:11:00Z Content type: release Language: en Sources: [Red]() Topics: [Red](), [Compiler]() Tags: [gc](), [improvements](), [memory](), [memory-management](), [release]() ### AI overview Red 0.6.6 introduces low-level memory-management and garbage-collection improvements. The release adds management for unused external resources such as image buffers and font handles, and replaces conservative native-stack scanning with a more precise approach supported by compiler-generated frame hints. ### Source excerpt This new milestone brings many low-level improvements to Red's memory management and garbage collecting. Most of those are long-planned additions needed to complete the internal memory model and make it robust enough for the future stable Red v1.0. First, here is a simplified overview of the Red memory model (existing parts in green color, new parts in orange, non-Red parts in blue): All Red values are stored in series. Some Red values require one or more buffers to hold their content. The values can never reference a buffer directly, but only through a node reference, to enable relocation when expanding the series buffer or when moving it around during compaction by the GC. Now let's dive into the hairy details! External resources GC The Red/View engine backends rely on external resources provided by the OS. Among those resources, some are linked to face! or font! object and require special care when those objects are not reachable anymore. So far, our GC (Garbage Collector) was not able to release such resources (images bitmap buffers and fonts handles), as unreachable Red aggregate values are seeing as simple series during the sweeping GC stage. In order to improve that, we have added an external resources manager, that will track and free unused resources, allowing now unrestricted images and fonts usage! Accurate GC The Red GC relies on allocated memory walking and native stack scanning to identify live Red values. Scanning the native stack can be challenging. The scanner used so far a conservative approach, which is simpler, but can lead to corruptions or crashes in rare cases (e.g. a floating point number being mistaken for a series or node pointer). Moreover, such approach precluded from having a nodes frame GC, as there was no way to accurately identify node pointers on the stack. This is now solved. The plan was always to make it precise when getting closer to a Red v1.0 and that's what we did in this release. In order to achieve that, several key addition ## Using Different Size Pools in Ruby Garbage Collection DevFeed: [Using Different Size Pools in Ruby Garbage Collection]() Original publisher: [Read original article]() Author: Pat Shaughnessy Published: 2025-02-11T00:00:00Z Content type: tutorial Language: en Sources: [Pat Shaughnessy]() Topics: [Ruby]() Tags: [array](), [gc](), [ruby](), [updating-ruby-under-a-microscope]() ### AI overview An excerpt from an updated Ruby garbage-collection chapter explains how to use GC.stat_heap in Ruby 3.2 and later to inspect size-pool statistics while allocating arrays of different capacities. ### Source excerpt I've started working on a new edition of Ruby Under a Microscope that covers Ruby 3.x. I'm working on this in my spare time, so it will take a while. Leave a comment or drop me a line and I'll email you when it's finished. The Ruby team has done ## Demystifying Java Object Sizes: Compact Headers, Compressed Oops, and Beyond DevFeed: [Demystifying Java Object Sizes: Compact Headers, Compressed Oops, and Beyond]() Original publisher: [Read original article]() Author: Peter Lawrey (noreply@blogger.com) Published: 2024-12-10T16:51:00Z Content type: article Language: en Sources: [Vanilla Java]() Topics: [Java](), [systems](), [Code](), [Concurrency]() Tags: [code](), [gc](), [info](), [java](), [jvm](), [low-latency](), [memory](), [object](), [opinion](), [performance](), [threads]() ### AI overview An article explaining how Java object sizes are affected by Compressed Oops and Compact Object Headers. It describes estimating object sizes with JVM memory measurements, while accounting for TLAB allocation, garbage collection, and concurrent allocations. It also summarizes JEP 450's proposed reduction of object headers to 64 bits on supported 64-bit platforms. ### Source excerpt Introduction Measuring an object's size in Java is not straightforward. The platform encourages you to consider references and abstractions rather than raw memory usage. Still, understanding how objects fit into memory can yield significant benefits, especially for high-performance, low-latency systems. Over time, the JVM has introduced optimisations like Compressed Ordinary Object Pointers (Compressed Oops) and, more recently, Compact Object Headers. Each of these can influence how large or small your objects appear. Understanding these factors helps you reason about memory usage more concretely. Measuring Object Sizes In principle, you can estimate an object's size by creating instances and observing changes in the JVM's free memory. However, you must neutralise certain factors to get consistent results. For example, turning off TLAB allocation (-XX:-UseTLAB) makes memory usage more directly observable. Repeated measurements and median calculations can reduce the impact of GC and concurrent allocations. A GC can occur while you are creating your object. This will result in more free memory at the end than when you started. I ignore any negative sizes in this test ;) Other threads in the system could use memory at the same time. I perform multiple test and take the median, which removes any outliers. Below is a rough approach: long before = usedMemory(); Object obj = createYourObject(); long after = usedMemory(); long approximateSize = after - before; This test SizeofTest.java is a simple test which creates a number of objects and measures the memory used to create each object. This is usually the same as the amount of memory the object retains for simple objects. Approximate layout of an object Memory Region Description Size (Bytes) Mark Word Header information including identity hash code, lock state, and GC metadata 8 bytes (on 64-bit JVMs) Class Pointer (Klass Pointer) Reference to the object's class metadata, used internally by the JVM Typically 4 bytes with C ## Eliminating Intermediate Array Allocations DevFeed: [Eliminating Intermediate Array Allocations]() Original publisher: [Read original article]() Published: 2024-09-30T02:06:28Z Content type: tutorial Language: en Sources: [Aaron Patterson]() Topics: [Ruby](), [Code](), [tagged pointers](), [math]() Tags: [array](), [code](), [function](), [gc](), [ruby](), [tagged-pointers]() ### AI overview This Ruby article explains how to measure object allocations with GC.stat and distinguishes code that never, sometimes, or always allocates. It focuses on why an intermediate array used in certain min or max calculations can be allocated on the stack and discarded without requesting a new object from the garbage collector. ### Source excerpt Recently I gave a talk at RailsWorld (hopefully they'll post the video soon), and part of my presentation was about eliminating allocations in tokenizers. I presented a simple function for measuring allocations: def allocations x = GC.stat(:total_allocated_objects) yield GC.stat(:total_allocated_objects) - x end Everything in Ruby is an object, but not all objects actually make allocations. We can use the above function to measure allocations made in a block. Here are some examples of code that never allocate: p allocations { true } # => 0 p allocations { false } # => 0 p allocations { nil } # => 0 p allocations { :hello } # => 0 p allocations { 1 } # => 0 p allocations { 2.3 } # => 0 p allocations { 0xFFFF_FFFF_FFFF_FFFF } # => 0 Literals like booleans, nil, symbols, integers, and floats are represented internally to CRuby as "tagged pointers" and they don't allocate anything when executed. Here is an example of code that sometimes allocates: # Depends on the size of the number p allocations { 1 + 2 } # => 0 p allocations { 0x3FFF_FFFF_FFFF_FFFF + 1 } # => 1 # Depends on `frozen_string_literal` p allocations { "hello!" } # => 0 or 1 Math on integers generally doesn't allocate anything, but it depends on the integer. When a number gets large enough, CRuby will allocate an object to represent that number. On 64 bit platforms, the largest whole number we can represent without allocating is 0x3FFF_FFFF_FFFF_FFFF. String literals will sometimes allocate, but it depends on the frozen_string_literal setting in your program. Here is an example of code that always allocates: p allocations { [1, 2] } # => 1 p allocations { { a: :b } } # => 1 p allocations { Object.new } # => 1 p allocations { "foo"[0, 1] } # => 1 Hopefully these examples are fairly straightforward. Arrays, hashes, objects, string slices, etc will allocate an object. Eliminating Intermediate Array Allocations At the Shopify after-party at RailsWorld, someone asked me a really great question. Their codebase ha ## Rendering the Java heap as a Treemap DevFeed: [Rendering the Java heap as a Treemap]() Original publisher: [Read original article]() Author: Pierre-Yves Ricau Published: 2024-09-25T04:37:22Z Content type: tutorial Language: en Sources: [Py's blog]() Topics: [Java](), [Graphs]() Tags: [android](), [computer-science](), [garbage-collection](), [gc](), [graph-theory](), [java](), [kotlin](), [memory](), [memory-management]() ### AI overview An exploration of Java heap dumps that explains shallow size, retained size, garbage-collection roots, and dominators. It also demonstrates using Shark and Graphviz to explore heap and view hierarchies. ### Source excerpt Exploring heap dumps I have investigated many heap dumps over the years, and I usually switch back and forth between two tools: YourKit Java Profiler to poke around the heap and look for interesting things (ask your company to buy a license!) Shark... ## 重新思考 Go：Slice 只是「操作视图」 DevFeed: [重新思考 Go：Slice 只是「操作视图」]() Original publisher: [Read original article]() Author: Joway Published: 2024-03-30T00:00:00Z Content type: article Language: zh Sources: [Random Thoughts]() Topics: [Go Language](), [bug]() Tags: [copy](), [gc](), [go](), [slices](), [tech]() ### AI overview This article examines Go slices as views over underlying memory rather than memory representations. It explains how subslices can retain oversized buffers, pointer elements can remain referenced after removal, and certain allocation patterns can cause unnecessary memory clearing. It concludes by discussing Go 1.21's slices package as a safer way to manipulate slices. ### Source excerpt 重新思考 Go 系列：这个系列希望结合工作中在 Go 编程与性能优化中遇到过的问题，探讨 Go 在语言哲学、底层实现和现实需求三者之间关系与矛盾。 Go 在语法级别上提供了 Slice 类型作为对底层内存的一个「操作视图」: var sh []any // ==> internal struct of []any type SliceHeader struct { Data uintptr Len int Cap int } 编程者可以使用一些近似 Python 的语法来表达对底层内存边界的控制: ## Stressing the JVM GC on Android DevFeed: [Stressing the JVM GC on Android]() Original publisher: [Read original article]() Author: Amanjeet Singh Gurtatta Published: 2024-03-10T08:49:55Z Content type: tutorial Language: en Sources: [Amanjeet Singh]() Topics: [Android](), [Java](), [Code](), [now-in-android]() Tags: [adb](), [android](), [android-vitals](), [anr](), [fragmentation](), [gc](), [java](), [leak](), [memory](), [memory-leak](), [mobile](), [mobile-performance](), [now-in-android](), [outofmemory](), [performance](), [stress](), [stresstest]() ### AI overview This tutorial describes GCStress, a Java application that deliberately creates garbage-collection pressure through repeated random byte-array allocations and cache removals. It explains how to integrate it into Google's Now in Android app, trigger it with an Android broadcast and adb, and observe effects such as skipped UI frames, possible ANRs, and potential out-of-memory errors. ### Source excerpt This post talks about a way to stress Java garbage collector. ## Investigating a Ruby Memory Leak in the HEY App DevFeed: [Investigating a Ruby Memory Leak in the HEY App]() Original publisher: [Read original article]() Author: Jacopo Beschi Published: 2024-03-07T18:00:00Z Content type: tutorial Language: en Sources: [37signals Dev]() Topics: [Memory Leaks](), [Ruby](), [App](), [Server]() Tags: [app](), [gc](), [load-balancer](), [memory-leak](), [ruby](), [trace]() ### AI overview This article describes how a team investigated a slow Ruby memory leak in the HEY app. It covers analyzing Ruby heap allocation statistics, extracting heap dumps with rbtrace, enabling object allocation tracing, and comparing dumps over time while limiting the diagnostic impact to one app host. ### Source excerpt What I learned on the journey chasing a tricky memory leak in HEY. ## Avoid Java double brace initialization DevFeed: [Avoid Java double brace initialization]() Original publisher: [Read original article]() Author: Pierre-Yves Ricau Published: 2023-06-27T20:58:00Z Content type: tutorial Language: en Sources: [Py's blog]() Topics: [Java](), [Code](), [Android]() Tags: [android](), [class](), [classes](), [code](), [constructor](), [crash-reporting](), [gc](), [global](), [implementation](), [java](), [leak](), [leakcanary](), [lifecycle](), [memory](), [memory-leak](), [object](), [patterns](), [subclass]() ### AI overview This tutorial explains how Java double brace initialization can cause memory leaks. An anonymous HashMap subclass implicitly retains its outer Activity, so a breadcrumb stored by a singleton BugSnag client can keep a destroyed Android Activity in memory. The article recommends avoiding the pattern and using explicit initialization or Kotlin. ### Source excerpt TL;DR Avoid doing this: new HashMap() {{ put("key", value); }}; Leak Trace I was recently looking at the following leak trace from LeakCanary: ┬─── │ GC Root: Global variable in native code │ ├─ com.bugsnag.android.AnrPlugin instan... ## Investigation of a Gradle and IntelliJ IDEA Memory Leak DevFeed: [Investigation of a Gradle and IntelliJ IDEA Memory Leak]() Original publisher: [Read original article]() Author: Pierre-Yves Ricau Published: 2022-10-12T17:26:46Z Content type: tutorial Language: en Sources: [Py's blog]() Topics: [Gradle](), [Memory Leaks](), [IntelliJ IDEA](), [Java](), [Graphs]() Tags: [garbage-collection](), [gc](), [gradle](), [graph](), [idea](), [intellij](), [java](), [leak](), [memory](), [memory-leak](), [performance]() ### AI overview A team investigation examines a Gradle process memory leak during project import in IntelliJ IDEA. The article describes heap analysis using dominator trees, pending finalization, and paths from GC roots. ### Source excerpt 👋 Hi, this is P.Y., I work as an Android Engineer at Block. This article shares a team investigation by Tony Robalik, Pablo Baxter, Roger Hu and myself into a recent Gradle / IntelliJ memory leak. O ## Effective Kotlin Item 53: Eliminate obsolete object references DevFeed: [Effective Kotlin Item 53: Eliminate obsolete object references]() Original publisher: [Read original article]() Published: 2021-09-13T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Memory Leaks](), [Kotlin](), [Android](), [classes](), [function]() Tags: [android](), [gc](), [how-to](), [kotlin](), [memory](), [memory-leaks](), [workshop-learning-programming]() ### AI overview This article explains how obsolete object references can cause memory leaks in Java and Android applications. It discusses retaining large or no-longer-needed objects, including activities stored in companion objects or top-level properties, and shows how stale references in a stack implementation keep removed elements reachable by the Garbage Collector. ### Source excerpt How to help our garbage collector and avoid memory leaks. ## Comparing OCaml's best-fit and next-fit memory allocators DevFeed: [Comparing OCaml's best-fit and next-fit memory allocators]() Original publisher: [Read original article]() Author: Stephen Dolan Published: 2020-09-15T00:00:00Z Content type: article Language: en Sources: [Jane Street]() Topics: [OCaml](), [Benchmark](), [configuration]() Tags: [benchmark](), [benchmarks](), [garbage-collection](), [gc](), [memory](), [memory-management](), [performance]() ### AI overview This article examines how to compare OCaml's best-fit and next-fit memory allocators in a garbage-collected system. Benchmarks show that best-fit can trade slightly slower execution for lower memory use, and that varying garbage-collection settings reveals a broader space-time performance trade-off. ### Source excerpt Since version 4.10, OCaml offers a new best-fit memory allocator alongside its existing default, the next-fit allocator. At Jane Street, we've seen a big improvement after switching over to the new allocator. This post isn't about how the new allocator works. For that, the best source is these notes from a talk by its author. Instead, this post is about just how tricky it is to compare two allocators in a reasonable way, especially for a garbage-collected system. ## Announcing Shark: Smart Heap Analysis Reports for Kotlin DevFeed: [Announcing Shark: Smart Heap Analysis Reports for Kotlin]() Original publisher: [Read original article]() Author: P-Y Ricau Published: 2019-08-06T19:00:00Z Content type: release Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [Kotlin](), [Android](), [Library](), [Graphs](), [Caching](), [Command-line interface]() Tags: [android](), [cache](), [cli](), [engineering](), [fragments](), [gc](), [graph](), [io](), [kotlin](), [library](), [memory](), [performance](), [performance-tuning]() ### AI overview The article announces Shark, a standalone Kotlin heap-analysis library that powers LeakCanary 2. It describes an indexed, on-demand approach to reading hprof heap dumps, using low and constant memory, an LRU cache, and layered components for heap analysis and Android-specific reporting. The reported benchmark parsed heap dumps and found shortest paths from GC roots to leaking objects six times faster than perflib while using ten times less memory. ### Source excerpt The heap analyzer that powers LeakCanary 2 ## RubyKaigi and the Path to Ruby 3 DevFeed: [RubyKaigi and the Path to Ruby 3]() Original publisher: [Read original article]() Author: Shannon Skipper Published: 2019-05-06T19:00:00Z Content type: article Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [Ruby](), [Programming language](), [Concurrency](), [Optimization]() Tags: [3](), [analysis](), [concurrency](), [engineering](), [garbage-collection](), [gc](), [optimization](), [performance](), [programming](), [programming-language](), [ruby]() ### AI overview This article reports on RubyKaigi discussions about Ruby 3, focusing on planned improvements in performance, concurrency, and static analysis. It describes ongoing garbage collector work intended to improve memory performance, reduce pauses, limit heap fragmentation, and improve copy-on-write behavior. ### Source excerpt Performance, Concurrency, and Static Analysis in Ruby ## Modern C++ for C Programmers: Part 5 DevFeed: [Modern C++ for C Programmers: Part 5]() Original publisher: [Read original article]() Published: 2018-07-25T09:26:51Z Content type: tutorial Language: en Sources: [Bert Hubert's writings]() Topics: [C++](), [C](), [Programming]() Tags: [algorithms](), [c](), [c-plus-plus](), [code](), [compiler](), [containers](), [gc](), [memory-leaks](), [modern](), [programming]() ### AI overview Part 5 of a tutorial series for C programmers explains modern C++ memory-management techniques, including reference counting, std::move, copy elision, return value optimization, smart pointers, and garbage collection trade-offs. ### Source excerpt Welcome back! In part 4 we went over the nitty-gritty of lambdas and how to store them, we explored the relation between the various C++ algorithms and containers, plus we took a stroll through some non-standard containers with exceptional capabilities. Note: part 1 is here. In this probably final part 5, we'll be going over some of the most powerful stuff in modern C++: "perfect" reference counting and the concept of std::move. ## TIP: Use Weak References DevFeed: [TIP: Use Weak References]() Original publisher: [Read original article]() Author: Shai Almog Published: 2017-10-16T00:00:00Z Content type: tutorial Language: en Sources: [CodeName One]() Topics: [Java](), [Objective-C](), [Swift]() Tags: [gc](), [java](), [memory](), [object]() ### AI overview This tutorial explains how weak references work in Java garbage-collected environments. It describes how they allow objects, such as memory-intensive images, to be reclaimed when needed, and discusses Codename One's weak-reference APIs and platform limitations. ### Source excerpt One of the less familiar features of Java is the mess of weak/soft/phantom references. This is a confusing mess and it's compounded by the fact that other languages (such as the reference counting Swift/Objective-C) have used these terms with a different meaning. To simplify this weak references in a garbage collected language allows you to keep a pointer (reference) to an object that won't force it to stay in RAM. [Next page]()