[tungleduyxyz]

Summary

Closes #125.

Utils.underscore (3 regex gsub! + tr!) and Utils.camelize run for every JSON key of every Kill Bill response (Resource.from_json) and every attribute of every serialized model (Resource#to_hash, and so #== and #hash), and nothing was cached. The inputs are a small, fixed set of attribute names. In JFR profiles of Kaui on JRuby these conversions were the top allocation and CPU sources (details in #125).

This PR:

• memoizes both conversions
• removes a redundant second underscore call per key
• fixes a pre-existing polynomial regex (ReDoS) in underscore, flagged by CodeQL, which takes 36.8 s on JRuby for a 50,000-character input

Changes

• lib/killbill_client/utils.rb
  • New Utils::ConversionCache: thread-safe memoization with lock-free reads of a frozen Hash and copy-on-write updates under a Mutex. No new runtime dependency.
  • underscore and camelize use it, with separate caches for camelize(..., :lower) and :upper. The previous implementations are kept as underscore_uncached / camelize_uncached, used to fill the caches.
  • Each cache is capped at 10,000 entries. Past that, values are still computed correctly, just not cached. This bounds memory if keys ever come from untrusted input, e.g. Resource.new(hash) built from form params.
  • ReDoS fix: /([A-Z]+)([A-Z][a-z])/ => '\1_\2' is replaced by the equivalent /([A-Z])(?=[A-Z][a-z])/ => '\1_' (details below).
• lib/killbill_client/models/resource.rb: instantiate_record_from_json no longer calls underscore again on name before the setter call, because name is already underscored at the top of the loop (and underscore is idempotent; there's a spec for that).
• spec/killbill_client/utils_spec.rb (new, 30 examples):
  • output identical to the previous implementation on real Kill Bill attribute names, including CBA, accountCBA, HTTPResponse, X-Killbill-ApiKey, Foo::BarBaz, already-underscored input, nil and symbols
  • output identical to the original regex on tricky inputs and 2,000 random strings
  • linear time on 50,000 capitals
  • frozen and shared results; not affected by later mutation of the input string
  • upper and lower camelize cached separately
  • the size cap
  • concurrent use from 8 threads
  • a JSON → model → to_hash round trip, including an unknown attribute being ignored
• benchmark/conversions.rb (new, stdlib only): times underscore, from_json and to_hash on a synthetic list of 300 invoices × 3 items (~1 MB of JSON, roughly a large account). It reports allocations per operation on CRuby. Run it on two checkouts to compare.

ReDoS fix (CodeQL rb/polynomial-redos)

The second regex in underscore, /([A-Z]+)([A-Z][a-z])/, backtracks from every position on a long run of capital letters with no lower case letter. It is already on master: this PR only moved it into underscore_uncached, which is why CodeQL reported it as new here. In Kaui, Resource.new(hash) is built from form params, so input of that shape can reach it, and caching doesn't help on the first call for a given key.

"A" * n	old regex, JRuby 10.0.6.0	new regex, JRuby 10.0.6.0
5,000	267 ms	1.8 ms
20,000	5,585 ms	1.9 ms
50,000	36,824 ms	5.1 ms

CRuby's engine happens to handle this pattern (2 ms for 20,000). The replacement inserts _ after a capital that is followed by a capital + lower case letter, which is exactly what the old pattern did (HTTPResponse → HTTP_Response, ABCdEFg → AB_CdE_Fg). Its output is identical on 200,000 random strings (CRuby) and 100,000 (JRuby), and on the edge cases in the specs.

Behaviour change to note

underscore and camelize now return frozen, shared strings. Nothing in this gem mutates them, and Kaui doesn't call KillBillClient::Utils directly (I checked killbill-admin-ui). Any external code calling these helpers and mutating the result in place would need to dup it first.

Benchmark

benchmark/conversions.rb, master (5d66ece) vs this branch, two runs each:

	CRuby 3.3.6: master	CRuby 3.3.6: branch	JRuby 10.0.6.0: master	JRuby 10.0.6.0: branch
from_json, 300 invoices	172–206 ms	32–36 ms	142–151 ms	44–46 ms
allocations / invoice	2,200	221	—	—
to_hash, 300 invoices	107–115 ms	13–17 ms	40–47 ms	18–22 ms
allocations / invoice	2,170	7	—	—
underscore, 63k calls	155–161 ms	10–12 ms	76–106 ms	24–43 ms

JRuby ran in the official jruby:10.0.6.0-jdk21 image (default flags, 40 iterations after 5 warm-up rounds). Absolute numbers depend on the machine; the ratios are what matter. These numbers were measured before the ReDoS fix, which only changes the uncached path (first call per key).

Testing

• rake test:spec: 84 examples, 0 failures (54 existing + 30 new) on CRuby 3.3.6, JRuby 10.0.6.0 (Docker jruby:10.0.6.0-jdk21) and JRuby 9.4.15.0 (the CI version)
• CI on the first commit: all 12 test jobs (CRuby 3.2/3.3, JRuby 9.4.15.0 × MySQL/PostgreSQL, including remote specs against Kill Bill) passed; the CodeQL alert is addressed by the second commit

Follow-ups (not in this PR)

• Performance: simplify instantiate_record_from_json (hot path when parsing every Kill Bill response) and add an isolated benchmark #126: flatten instantiate_record_from_json (per-class lookup table, no rescue nil control flow, cached setter symbols), plus benchmarks on real payloads
• After a release, bump killbill-client in Kaui / kaui-standalone and re-profile with JFR (Performance: compare G1 vs ZGC vs Shenandoah under load, measure Kaui's live working set, and share JFR recordings killbill-admin-ui-standalone#137)

🤖 Generated with Claude Code