Home Original page

Reuse TagMap.Entry objects in BaseDecorator by dougqh · Pull Request #10501 · DataDog/dd-trace-java

added 30 commits

January 12, 2026 14:33
EntryIterator and EntryChangeIterator are arguably redundant
Fixed bug TagValueConversions.toBoolean
Could cause LegacyTagMap.EntryReader to produce incorrect answers to some queries

For simplicity, now treating Byte and Short as Integer.  That will make calling code doing primitive handling simpler.

Fleshing out tests -- more tests to come
Coverage for byte, short, float, and double
Adding methods to AgentSpan / DDSpan that take TagMap.Entry/Reader objects directly

This will enable TagMap.Entry reuse which can reduce memory allocation/GC pressure
Methods are intended to be used to create TagMap.Entry objects for repeatedly used values

Overloads are provided for all the supported types to be easier for developers not familiar with TagMap internals.  Internally, TagMap still uses the more explicit new<X>Entry methods.
Removing statics that were previously moved to TagValueConversions
- tests exposed missing TagMap.Entry.create for boolean
- added explanatory strings to some asserts
…aDog/dd-trace-java into dougqh/fdirect-apis-for-tagmap-entry

ygree

@dougqh

@dougqh

@dougqh

@dougqh 

…/dd-trace-java into dougqh/basedecorator-entry-reuse

@dougqh 

Code is now calling setTag(TagMap.Entry) or setMetric(TagMap.Entry)

Since these tests use mocks rather than checking span contents, I had to update them to account for the change
…/dd-trace-java into dougqh/basedecorator-entry-reuse

@dougqh

dougqh

dougqh

@dougqh

@dougqh

@dougqh 

This file no longer needs to change with the caching approach, and this serves as a useful test that the behavior hasn't been altered

@dougqh