P4
On x64, we use at most 922 bytes for the MethodHandlesAdapterBlob (with -XX:+VerifyMethodHandles) in product builds, and 2006 bytes in debug builds. And a bit less on 32-bit x86. So the current sizing of 32k/152k is somewhat excessive.
At some point JSR 292 was reworked so that most stubs are generated lazily by JITs as they're needed, leaving only a handful of small interpreter entry point stubs to be generated eagerly on startup here.
This appear to be sufficient for both 32- and 64-bit:
enum /* platform_dependent_constants */ {
adapter_code_size = 1000 DEBUG_ONLY(+ 2000)
};
Obviously saves a small chunk of memory, and the JVM starts up around 8us faster according to my measurements.
Other platforms could most likely be adjusted, too, but exactly how requires some hands-on experimentation.
At some point JSR 292 was reworked so that most stubs are generated lazily by JITs as they're needed, leaving only a handful of small interpreter entry point stubs to be generated eagerly on startup here.
This appear to be sufficient for both 32- and 64-bit:
enum /* platform_dependent_constants */ {
adapter_code_size = 1000 DEBUG_ONLY(+ 2000)
};
Obviously saves a small chunk of memory, and the JVM starts up around 8us faster according to my measurements.
Other platforms could most likely be adjusted, too, but exactly how requires some hands-on experimentation.
