Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

I often see repeated messages like this in my log:

Method exceeds compiler instruction limit: 29278 in void com.xxxxxxapp.xxxxxx.MyGLRenderer.onDrawFrame(javax.microedition.khronos.opengles.GL10)
Method exceeds compiler instruction limit: 29278 in void com.xxxxxxapp.xxxxxx.MyGLRenderer.onDrawFrame(javax.microedition.khronos.opengles.GL10)
Method exceeds compiler instruction limit: 29278 in void com.xxxxxxapp.xxxxxx.MyGLRenderer.onDrawFrame(javax.microedition.khronos.opengles.GL10)

Breaking the code down typically gives the same message with a smaller number:

Method exceeds compiler instruction limit: 22400 in void com.xxxxxxapp.xxxxxx.MyGLRenderer.onDrawFrame(javax.microedition.khronos.opengles.GL10)

I thought 64000 was the magic number to keep under here. My game code has always appeared to run fine despite nagging messages like this, and it's not just in the opengl onDrawFrame method. I've gotten similar messages in my update method for well under 64K, although update code is easier to break down than drawing code.

Searches for 'Method exceeds compiler instruction limit' have just gotten me links to the dreaded 'Dalvik compiler limit on 64K methods' error. Do I have to keep ignoring this?

This happens because of Compiler::IsPathologicalCase:

Skip compilation for pathologically large methods - either by instruction count or num vregs.

Dalvik uses 16-bit uints for instruction and register counts. We'll limit to a quarter of that, which also guarantees we cannot overflow our 16-bit internal Quick SSA name space.

Source: compiler.cc.

16-bit uint can represent a maximum value of 65535, divided by 4, equals 16383.75.

Raising the target level from Dalvik to ART might circumvent it; because Dalvik and javax.microedition.khronos.opengles.GL10 seem to be incompatible, due to instruction count.

The register count is being checked after that, therefore this doesn't seem to the issue here.

Patching compiler.cc would also be an option, despite not a good one.

  • when 4 would be 2, this would permit double the amount.

  • when not return true it should also proceed with the compilation.

    This is the check, which is at fault:

    if (accessor.InsnsSizeInCodeUnits() >= UINT16_MAX / 4) {
      LOG(INFO) << "Method exceeds compiler instruction limit: "
                << accessor.InsnsSizeInCodeUnits()
                << " in " << dex_file.PrettyMethod(method_idx);
      return true;
    

    Disclaimer: without the least guarantee of "no side effects".

    @Androidcoder probably not your's but the compilation altogether. stripping unused methods also might help; just no clue if this happens before or after that check happens. the optimal solution would be to get below the 16k instruction count. – Martin Zeitler Mar 2, 2019 at 19:22 Stripping unused methods doesn't matter, because this error is triggered when the method is called. Compilation fails the first time the method is called, so the next call is also the "first" and fails again, and the next, and the next… Compiling a large method takes CPU time and battery power, so doing this in a loop is quite a problem. (In my case it concerns parsing using javacc and a middlingly complex grammar. Hello there, search engines.) – arnt Jun 8, 2020 at 11:00 As the "method exceeds compiler instruction limit" entry it is only logged at the "Info" level, is it only an advisory that does not actually impact app functionality? What harm is caused? – mike47 Jan 28 at 15:54 It causes that method to be interpreted, ie. it runs more slowly. This may or may not be a problem. Most functions don't contain performance hotspots, after all. – arnt Mar 3 at 15:17 The question concerns the number of instructions in a single method; android's limit is lower than the JVM's limit. Multidex deals with the number of methods in an application. – arnt Jun 8, 2020 at 10:52

    Thanks for contributing an answer to Stack Overflow!

    • Please be sure to answer the question. Provide details and share your research!

    But avoid

    • Asking for help, clarification, or responding to other answers.
    • Making statements based on opinion; back them up with references or personal experience.

    To learn more, see our tips on writing great answers.

  •