Skip to main content

Inhibit inlining of subroutines (jsr/ret) in the preverifier

2 replies [Last post]
Anonymous

Hello!

I'm working on a project, Cibyl[1], where I've recently experimented
with generating a lot of code in subroutines. I have a couple of test
cases which has quite large methods, and when adding the subroutine
code, I was surprised to see that these would not pass the
preverification phase anymore. It was surprising since the same classes
worked fine when executing in a non-J2ME Java environment (Midpath).

So I downloaded the preverifier code (thanks!) and started looking at
what could cause this. The reason it fails is that the preverifier
inlines the subroutines, which I suppose is fine in most cases - but I
have hundreds of subroutine calls so this means my method sizes will go
throgh the roof.

In particular, preverification now fails on a "short" goto, where the
offset becomes too large because of the inlined subroutine. I'd say
this is a general bug in the preverifier, since even a single
subroutine can cause this problem if placed wrongly.

To the questions then: I found the -Xni option which should turn this
off, but I see from the code that this is not yet implemented. Has this
been implemented before/working and is there source code left from
that?. I've tried to quickly implement this myself, but so far been
unable to get working classes out of it. Are there any pointers on
where to look for this?

Thanks,
// Simon
[1] http://cibyl.googlecode.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: dev-help@phoneme.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Hinkmond Wong

Hi Simon,

I'm cc'ing your message to the feature@phoneme.dev.java.net mail alias,
just in case your question is not seen on the less viewed
dev@phoneme.dev.java.net mail alias.

Thanks,
Hinkmond

Simon Kagstrom wrote:
> Hello!
>
> I'm working on a project, Cibyl[1], where I've recently experimented
> with generating a lot of code in subroutines. I have a couple of test
> cases which has quite large methods, and when adding the subroutine
> code, I was surprised to see that these would not pass the
> preverification phase anymore. It was surprising since the same classes
> worked fine when executing in a non-J2ME Java environment (Midpath).
>
>
> So I downloaded the preverifier code (thanks!) and started looking at
> what could cause this. The reason it fails is that the preverifier
> inlines the subroutines, which I suppose is fine in most cases - but I
> have hundreds of subroutine calls so this means my method sizes will go
> throgh the roof.
>
> In particular, preverification now fails on a "short" goto, where the
> offset becomes too large because of the inlined subroutine. I'd say
> this is a general bug in the preverifier, since even a single
> subroutine can cause this problem if placed wrongly.
>
>
> To the questions then: I found the -Xni option which should turn this
> off, but I see from the code that this is not yet implemented. Has this
> been implemented before/working and is there source code left from
> that?. I've tried to quickly implement this myself, but so far been
> unable to get working classes out of it. Are there any pointers on
> where to look for this?
>
> Thanks,
> // Simon
> [1] http://cibyl.googlecode.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@phoneme.dev.java.net
> For additional commands, e-mail: dev-help@phoneme.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: dev-help@phoneme.dev.java.net

billp
Offline
Joined: 2006-09-19
Points: 0

When the preverifier was written (1999?) one primary goal was to make the in-VM part of the verifier simple to implement. Accordingly, they decided that eliminating the jsr opcode (via inlining) would be one way to do this. A J2ME VM (like KVM or phoneME feature) would fail to verify a class that had JSR opcodes in the bytecode stream. So even if you could get the -Xni option working, the resulting class would not pass VM verification.
As to the problem you are having, are you saying that the preverifier is always using a 'goto' opcode and perhaps needs to sometimes use a 'goto_w' opcode if the offset is > 16 bits?
That is probably fixable.