New JEP: Classfile Processing API

[Per Bothner]

On 6/19/22 11:21, Brian Goetz wrote:
> Hello Per!
> 
> Nice to hear from you again.
> 
>> An aside (and not telling you anything new I'm sure) but a "fixup" post-processing pass
>> is probably preferable to doing the code-generation twice: It's hard for the latter to use
>> a mix of short and long jumps as needed.
> 
> Yeah, it's unfortunate either way.  It turns out that 99+% of methods have no long jumps, either because they're shorter than 32K, or are longer but lucky.  So the retry approach is based on an optimistic assumption; we save having to do the fixup + compression pass almost all the time, at the cost of running the generation twice a tiny fraction of the time.

Fair enough - though if yu have a method larger than 32K you really don't want to
needlessly push the limit above 64K.  Unless the library has a mechanism to
deal with really large methods.

Kawa has a testsuite that fails because it compiles to larger than 64K.
(This is partly because each test is macro-expanded excessively.
It is fixable in various ways; I've been putting off dealing with it,
as I don't spend a lot of time on Kawa these days.)
I've argued before that this JVM limit should be fixed - unless there is
a library that can work around it in a reasonable way.

One other optimization that processFixups handles is eliminating
jumps to jumps.  I found them painful to deal with otherwise.
(In my recollection - this code appears to be from 2004.)
I realize the JIT can deal with such infelicities in the bytecode,
but I feel uncomfortable generating bloated bytecode.
-- 
	--Per Bothner
per at bothner.com   http://per.bothner.com/