Imported From: https://issues.scala-lang.org/browse/SI-3745?orig=1
Reporter: @jrudolph
See #1133

@jrudolph said:
The underlying problem is that for forward jumps FJBG has to reserve space for the offset before the offset is known. If the offset later turns out to be too big, FJBG can't insert the wide offset any more.

@jrudolph said:
I already tried fixing it, but there is no easy fix available, since that's pretty much by design.

The problem is, that for forward jumps the target address is not available when the jump bytecode is emitted. So fjbg collects a list of target positions to fill in later when all the information are available. The problem is that there are two kinds of GOTO instructions. One, GOTO, that is 3 bytes long that uses two bytes for specifying the offset for the target, and GOTO_W, which is 5 bytes loI already tried fixing it, but there is no easy fix available, since that's pretty much by design.

The problem is, that for forward jumps the target address is not available when the jump bytecode is emitted. So fjbg collects a list of target positions to fill in later when all the information are available. The problem is that there are two kinds of GOTO instructions. One, GOTO, that is 3 bytes long that uses two bytes for specifying the offset for the target, and GOTO_W, which is 5 bytes long and uses 4 of them to specify the offset for the target. But for the patching mechanism to work you have to know beforehand which one you want to use. And you cannot easily change a GOTO to GOTO_W later on because you would have to insert bytes into the bytecode stream which isn't possible because it would invalidate all the targets going into the area after the insertion. And even if you would track all targets it isn't even said that you are done in one iteration because changing a bunch of GOTOs into GOTO_W could trigger the need for even more GOTOs to be changed.

Given the fact, that only unconditional branching (GOTO) has a wide variant, and all other conditional branching not, it is generally not certain that you could use all the available bytecode space at all, without having to resort to some kind of an optimization algorithm laying out the basic code blocks in a way to minimize the relative jumping offsets.

@jrudolph said:
I've just looked into ASM and how they are doing things. They have quite a sophisticated method doing all this relocation stuff in [http://websvn.ow2.org/filedetails.php?repname=asm&path=%2Ftrunk%2Fasm%2Fsrc%2Forg%2Fobjectweb%2Fasm%2FMethodWriter.java MethodWriter.resizeInstructions].

It could well be, that migrating code generation to ASM would be easier than fixing that single issue in fjbg.

@paulp said:
Replying to [comment:3 jrudolph]:

I've just looked into ASM and how they are doing things. They have quite a sophisticated method doing all this relocation stuff in [http://websvn.ow2.org/filedetails.php?repname=asm&path=%2Ftrunk%2Fasm%2Fsrc%2Forg%2Fobjectweb%2Fasm%2FMethodWriter.java MethodWriter.resizeInstructions].

It could well be, that migrating code generation to ASM would be easier than fixing that single issue in fjbg.

I've been tempted to do that more than once (see #611 and http://github.com/paulp/ssbg for some past traversals) and I find it highly likely it'd be worth it. This further improves the argument. I couldn't get to it anytime soon, but if you were looking for something to do...

@lrytz said:
can maybe be solved by computing an upper bound for the code size before targetting labels

@SethTisue said:
n/a anymore, FJBG is history