On Tue, 25 Mar 2025 15:27:05 GMT, David M. Lloyd <d...@openjdk.org> wrote:
>> Provide method overloads to the ClassFile interface of the >> java.lang.classfile API which allow parsing of classes found in memory >> segments, as well as allowing built class files to be output to them. > > David M. Lloyd has updated the pull request incrementally with two additional > commits since the last revision: > > - Shorten method names > - Minor doc adjustment A simple test to run a program with a single lambda in it did not cause the `MemorySegment` class to be loaded (as verified with `-verbose:class`), so there should be no regression in that regard. Since the JDK code paths do not run through the new APIs, I would expect the only possible performance impact to come from the non-functional common code refactoring (extracting common methods) on the write side. So, I've run `ClassfileBenchmark` to ensure that no regression is happening there. With patch: Benchmark Mode Cnt Score Error Units ClassfileBenchmark.parse thrpt 5 52340.143 ± 492.543 ops/s ClassfileBenchmark.transformWithAddedNOP thrpt 5 11550.745 ± 146.057 ops/s ClassfileBenchmark.transformWithNewCP thrpt 5 7625.322 ± 50.366 ops/s ClassfileBenchmark.transformWithSharedCP thrpt 5 23755.083 ± 310.914 ops/s Without patch: Benchmark Mode Cnt Score Error Units ClassfileBenchmark.parse thrpt 5 52365.455 ± 649.145 ops/s ClassfileBenchmark.transformWithAddedNOP thrpt 5 11546.367 ± 105.941 ops/s ClassfileBenchmark.transformWithNewCP thrpt 5 7589.033 ± 66.221 ops/s ClassfileBenchmark.transformWithSharedCP thrpt 5 23729.577 ± 159.890 ops/s It looks like they are all solidly within the margin of error. If there are any other tests you'd like me to run (or different parameters etc.) please let me know. If this all looks ok, @asotona could you please review the CSR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24139#issuecomment-2758219000
