ExecutionAttributes default HashMap capacity causes repeated resize during every DynamoDB request

[batrived]

Summary

ExecutionAttributes wraps a new HashMap<>() with default initial capacity (16 buckets). By the time a DynamoDB request finishes executing through all pipeline stages and interceptors, approximately 30–40 attributes have been inserted. This causes 2–3 resize+rehash cycles on every single request, which shows up as measurable CPU overhead in production profiling.

Evidence

Using async-profiler on a JanusGraph server with a DynamoDB-heavy read workload (Query-dominated, ~thousands of DynamoDB calls/sec, SDK version 2.42.28):

• AwsExecutionContextBuilder.invokeInterceptorsAndCreateExecutionContext: 6.44% cumulative CPU of total JVM CPU
• HashMap.resize() appears in the hot path within that subtree
• ExecutionAttributes.getAttribute: 1.62% cumulative CPU — repeated map lookups against a recently-resized table

Relevant code

ExecutionAttributes.java constructs new HashMap<>() with no initial capacity hint.

Proposed fix

Pre-size the HashMap to avoid resizes. Based on the number of attributes inserted during a typical DynamoDB request (~30–40), an initial capacity of 64 would prevent all resize cycles:

// Before
private final Map<ExecutionAttribute<?>, Object> attributes = new HashMap<>();

// After
private final Map<ExecutionAttribute<?>, Object> attributes = new HashMap<>(64);

Alternatively, a custom open-addressing map keyed on ExecutionAttribute identity (they are singletons) could be even more efficient.

Impact

This is a zero-risk, one-line change that eliminates repeated memory allocation and rehashing on every SDK request. On high-throughput DynamoDB workloads the savings are proportional to request rate.

[batrived]

Correction on entry count: The initial estimate of ~30–40 entries was too high — the actual count is approximately ~17 entries added to ExecutionAttributes per DynamoDB request. An initial capacity of 32 (the next power of 2 above 17, accounting for the 0.75 load factor threshold) would be sufficient to avoid any resizes.

Related issue: #6848 tracks the complementary problem that ExecutionInterceptorChain is also reconstructed per-request despite the interceptor list being static. Both issues share the same parent hotspot: AwsExecutionContextBuilder.invokeInterceptorsAndCreateExecutionContext (6.44% cumulative CPU).

[batrived]

Correction: the real bottleneck is String-based hashing, not just HashMap resize

After drilling deeper into the profile with a focused filter on ExecutionAttributes, the actual breakdown within that subtree is:

Method	Flat CPU
HashMap.getNode	0.62%
String.hashCode	0.36%
ExecutionAttribute.storage	0.34%
HashMap.putVal	0.27%
HashMap.resize	0.22%
ExecutionAttribute.hashCode (cum)	0.63%

HashMap.resize is real (0.22% flat) and pre-sizing would help, but the dominant overhead is String.hashCode being called on every getAttribute() and putAttribute() call. ExecutionAttribute uses its name string for hashCode(), so every map lookup involves hashing a string.

Since ExecutionAttribute<?> instances are singletons (static final constants declared once), the map key is always the same object reference. Switching from HashMap to IdentityHashMap — or an array indexed by a fixed integer attribute ID — would:

1. Eliminate all string hashing cost entirely (use reference identity instead)
2. Be O(1) with no hash collision risk
3. Also solve the resize issue (IdentityHashMap can be pre-sized, or an array is fixed-size)

The pre-sizing suggestion in the original issue description is a valid incremental fix, but the higher-leverage change is using identity-based lookup since the keys are singletons.