condy and enums
Liam Miller-Cushon
cushon at google.com
Wed Oct 11 23:08:00 UTC 2023
Thanks! Responses inline,
On Tue, Oct 10, 2023 at 8:24 AM - <liangchenblue at gmail.com> wrote:
> Hello Liam,
> I think your approach is quite nice. For your information, for non-static
> arguments like an invocation, we can compile a static factory method that
> returns an enum instance or use ConstantBootstraps.invoke as the non-static
> argument's bootstrap method. The invokestatic-putstatic sequence is 6 bytes
> as well.
>
> If there are too many arguments, condy bootstrap method arguments may run
> into the constant pool size limit, though unlikely.
>
Using static factory methods seems like it could be a nice way to use condy
more consistently for language levels that support it, instead of switching
back and forth between the two strategies depending on whether or not
constant arguments were present.
> Condy might be more costly than a plain invocation at runtime compared to
> plain new-dup-init sequence, without caching or precomputation involved. We
> need to check the initialization performance of these new enums.
>
I collected some simple performance measurements of an enum with 4000
constants with and without the new strategy. The results were pretty
stable, and condy came out ~0.07s faster. The startup performance
implications definitely deserve more investigation and scrutiny, but those
initial numbers seem encouraging.
The benchmark was roughly:
enum C {
C1,
// <snip>
C4000;
public static void main(String[] args) {
System.out.println(C.values().length);
}
}
> For the bootstrapping issue, I've left a comment on your draft PR; I think
> it should be controlled via a compiler flag like StringConcat.
>
Done, thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231011/5558ee4d/attachment.htm>
More information about the compiler-dev
mailing list