The unmarshal_unsafe README warns that "data received from the wire has to be left untouched for the lifetime of the message." This covers the correctness constraint but not the memory one: because unsafe.String points into the input []byte, the entire buffer is kept alive by GC as long as any string field is reachable, even after the message is discarded.
This is an inherent trade-off, not a bug, but it can surprise users who store individual fields (e.g., an ID) in a long-lived cache without realizing the full serialized blob stays pinned.
I'd like to add a note to the README warning, something like:
Additionally, because string fields point directly into the input buffer via unsafe.String, the entire input []byte is kept alive by the garbage collector as long as any string or bytes field from the deserialized message is reachable. If you store individual fields beyond the message's lifetime, consider strings.Clone() or the unique field option (Go 1.23+).
Happy to submit a PR if this sounds reasonable.
Related:
The
unmarshal_unsafeREADME warns that "data received from the wire has to be left untouched for the lifetime of the message." This covers the correctness constraint but not the memory one: becauseunsafe.Stringpoints into the input[]byte, the entire buffer is kept alive by GC as long as any string field is reachable, even after the message is discarded.This is an inherent trade-off, not a bug, but it can surprise users who store individual fields (e.g., an ID) in a long-lived cache without realizing the full serialized blob stays pinned.
I'd like to add a note to the README warning, something like:
Happy to submit a PR if this sounds reasonable.
Related:
unmarshal_unsafefeature #103