On Fri, 12 Apr 2024 11:41:17 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
> Yes, we are concerned with that, especially for a possible future where > Lilliput is the sole default. Atm we can address about 4 million classes. > There are thoughts about making this number of classes infinite, but if > possible we would like to avoid that complexity. 4M classes should be enough for everyone :-) Either way this PR shouldn't make the situation worse. I think for expressions of high arity the average number of classes generated by the current strategy is likely larger than 1. Forcing generation of exactly one class per such call site is thus unlikely to be worse. But since it depends on app having a parameter to adjust the level at which we fall back to simple bytecode generation seems reasonable. There's a range of possible follow-up enhancements to reduce classes generated. For example we could generate classes where constants are injected rather than hardcoded and cache/reuse those classes at different call-sites. Further out we could pre-generate classes (one per arity) containing methods for known signatures when dumping CDS archives or running jlink plugins so that there's little to no bytecode generation at runtime and a bound number of classes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18690#issuecomment-2051734530
