Adds methods for setting TagMap.Entry directly on AgentSpan/DDSpan#10472
Merged
Adds methods for setting TagMap.Entry directly on AgentSpan/DDSpan#10472
Conversation
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
dougqh
commented
Jan 29, 2026
- tests exposed missing TagMap.Entry.create for boolean - added explanatory strings to some asserts
This was referenced Feb 2, 2026
dd-trace-core/src/main/java/datadog/trace/core/DDSpanContext.java
Outdated
Show resolved
Hide resolved
internal-api/src/test/java/datadog/trace/api/TagMapEntryTest.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Alexey Kuznetsov <alexey.kuznetsov@datadoghq.com>
Using DisplayName to improve readability instead of separating prefix / suffix with underscore
mcculls
reviewed
Feb 5, 2026
| } | ||
|
|
||
| public void setTag(TagMap.EntryReader entry) { | ||
| if (entry == null) return; |
Contributor
There was a problem hiding this comment.
Do we want a similar check in setMetric?
Contributor
Author
There was a problem hiding this comment.
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.
Contributor
Author
There was a problem hiding this comment.
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.
mcculls
approved these changes
Feb 5, 2026
- 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)
…aDog/dd-trace-java into dougqh/fdirect-apis-for-tagmap-entry
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
type:and (comp:orinst:) labels in addition to any useful labelsclose,fixor any linking keywords when referencing an issue.Use
solvesinstead, and assign the PR milestone to the issueJira ticket: [PROJ-IDENT]