> John Rose suggests in 
> https://github.com/openjdk/jdk/pull/26802#issuecomment-3201402304 that 
> ClassFile API should validate Utf8Entry length eagerly upon construction. 
> Currently we validate upon writing to bytes, which avoids validation 
> overhead. However, given that most class file utf8 data are shorter than 1/3 
> of the max length, which is always an encodable length, the performance 
> impact should be low.
> 
> Preventing the creation of unrepresentable UTF8 entries can prevent passing 
> such invalid instances around, making such problems easier to debug than a 
> failure at building.
> 
> Tier 1-3 seems clear. The performance impact to jdk.classfile.Write or any of 
> the regularly run transformation benchmarks seems neutral, less than 5% 
> perturbations.
> 
> I will update docs to reflect this change, given how widespread this is 
> across JDK - it seems the only exempt classes are Signature, ClassSignature, 
> and MethodSignature.

Chen Liang has updated the pull request incrementally with one additional 
commit since the last revision:

  Update comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27281/files
  - new: https://git.openjdk.org/jdk/pull/27281/files/8973a15d..15858087

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27281&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27281&range=01-02

  Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27281/head:pull/27281

PR: https://git.openjdk.org/jdk/pull/27281

Reply via email to