Skip to content

Adds methods for setting TagMap.Entry directly on AgentSpan/DDSpan#10472

Merged
dougqh merged 41 commits intomasterfrom
dougqh/fdirect-apis-for-tagmap-entry
Feb 5, 2026
Merged

Adds methods for setting TagMap.Entry directly on AgentSpan/DDSpan#10472
dougqh merged 41 commits intomasterfrom
dougqh/fdirect-apis-for-tagmap-entry

Conversation

@dougqh
Copy link
Contributor

@dougqh dougqh commented Jan 29, 2026

What Does This Do

Adds methods to TagMap.Entry to create entries directly
Adds methods to AgentSpan / DDSpan to set TagMap.Entry(Reader) directly

Motivation

The intention is to enable reuse of TagMap.Entry objects to further reduce allocation
Those improvements have been prototyped and shown to be beneficial, but will be done in separate pull requests

I'd originally hoped to make reuse of TagMap.Entry-s hidden from instrumentation by adding in caches behind the scenes, but that approach didn't pan out. The caches were beneficial when memory was scarce, but harmful when memory is plentiful.

So for now, the simplest approach is to expose APIs, so TagMap.Entry-s can be used directly in the key places where doing so is beneficial. Examples include static meta information, git related tags, db connection info, etc

Additional Notes

It will probably also make sense to extend these changes to TraceSegment; however, TagMap isn't currently visible to TraceSegment at build time. To keep this pull request simple, changing TraceSegment is left to another pull request

Contributor Checklist

Jira ticket: [PROJ-IDENT]

dougqh added 16 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.
@dougqh dougqh requested review from a team as code owners January 29, 2026 15:48
@dougqh dougqh requested review from mcculls and mtoffl01 and removed request for a team January 29, 2026 15:48
@dougqh dougqh added comp: core Tracer core type: enhancement Enhancements and improvements tag: performance Performance related changes labels Jan 29, 2026
- tests exposed missing TagMap.Entry.create for boolean
- added explanatory strings to some asserts
dougqh and others added 2 commits February 5, 2026 09:55
Co-authored-by: Alexey Kuznetsov <alexey.kuznetsov@datadoghq.com>
Using DisplayName to improve readability instead of separating prefix / suffix with underscore
}

public void setTag(TagMap.EntryReader entry) {
if (entry == null) return;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want a similar check in setMetric?

Copy link
Contributor Author

@dougqh dougqh Feb 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point.
I cannot quite decide how I want to handle null here.
In general, I'm not a fan of defensive checks everywhere, but letting nulls flow through does make sense in a lot of cases.

I guess I'll add the same check in setMetric.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've decided to go a step further and have TagMap.Entry.create handle null values by returning null.
That will provide the nice property of allowing null to flow through TagMap.Entry.create and into AgentSpan.setTag / setMetric.

That will simplify the Git related changes that build on this.

- setMetric not guards against null
- TagMap.create now allows null - and returns null in response

The intention is to let null values benignly flow through TagMap.Entry.create into AgentSpan.setTag / setMetric
Fixing oversight of creating newAnyEntry rather newObjectEntry in create(tag, CharSequence)
Changed tests to use camel case - using DisplayName for test report readabilty
…aDog/dd-trace-java into dougqh/fdirect-apis-for-tagmap-entry
@dougqh dougqh merged commit ea4114a into master Feb 5, 2026
545 checks passed
@dougqh dougqh deleted the dougqh/fdirect-apis-for-tagmap-entry branch February 5, 2026 20:32
@github-actions github-actions bot added this to the 1.60.0 milestone Feb 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp: core Tracer core mergequeue-status: removed tag: performance Performance related changes type: enhancement Enhancements and improvements

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants