Skip to main content

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

4 replies [Last post]
Anonymous

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
terrencebarr
Offline
Joined: 2004-03-04

Simon,

To follow up: Large subroutines can be a problem from an optimization perspective, especially for the JIT compiler and the related memory management. So, generally, you want to avoid very large methods - which is also good design practice. You may want to see if you can structure your translation algorithms to produce more fine grain byte code streams.

-- Terrence

olegpliss
Offline
Joined: 2006-11-09

javac v.1.4.2 or new versions with -target=1.4.2 do not generate jsr/ret bytecodes. These bytecodes are not valid for a compliant CLDC VM. So they may never get to JIT compiler.

Preverifier inlines subroutines to make legacy bytecodes compatible with new VMs. Yes, the preverifier does not cover all the cases. But if you use jasm or generate bytecodes today, you must be aware of this limitation. It is in the CLDC spec.

olegpliss
Offline
Joined: 2006-11-09

According to CLDC Spec., Section 5.3.1.1 "Verification process", the preverifier must:
[i]Inline all subroutines and remove all the jsr (JVMS p. 304, jsr_w (JVMS p. 305), ret (JVMS p. 352) and wide ret (JVMS p. 360) bytecodes from the classfile. Each method containing these instructions is replaced with semantically equivalent bytecode not containing the jsr, jsr_w, ret and wide ret bytecodes.[/i]

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: feature-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: feature-help@phoneme.dev.java.net