J2ME, dead code not removed

Started by
12 comments, last by Thygrrr 17 years, 8 months ago
Quote:Original post by Multiverse
I'm not allowed to use any preprocessing


Thats why ;)
Advertisement
Preprocessing really sucks, too. I'm trying to get away from it, but apparently, it's not completely possible unless you can live with code bloat.

Here is an example I compiled. In fact, I read that javac doesn't optimize, and Sun even documents it that way. nmi wasn't precisely right; it was just a lucky exception. For example, Switch statements won't work gracefully. In short, that means you will either end up with really long if/then/elseif/... statements, or you need to do without any kind of "sophisticated" configuration of your bytecode by means of final fields.

public class Config{    public static final int     VALUE1 = 0;    public static final int     VALUE2 = 1;    public static final int     VALUE3 = 2;        public static void test()    {        switch (VALUE1)        {            case VALUE2:                System.out.println("final int switch statement");            default:                System.out.println("nothing");        }    }}


As you see, the switch statement remains entirely intact...



public class de.mef.auto.Config extends java.lang.Object{public static final int VALUE1;public static final int VALUE2;public static final int VALUE3;public de.mef.auto.Config();  Code:   0:   aload_0   1:   invokespecial   #16; //Method java/lang/Object."<init>":()V   4:   returnpublic static void test();  Code:   0:   iconst_0   1:   tableswitch{ //1 to 1                1: 20;                default: 28 }   20:  getstatic       #23; //Field java/lang/System.out:Ljava/io/PrintStream;   23:  ldc     #29; //String final int switch statement   25:  invokevirtual   #31; //Method java/io/PrintStream.println:(Ljava/lang/String;)V   28:  getstatic       #23; //Field java/lang/System.out:Ljava/io/PrintStream;   31:  ldc     #37; //String nothing   33:  invokevirtual   #31; //Method java/io/PrintStream.println:(Ljava/lang/String;)V   36:  return}




However, good news: Here's what jikes did:

public class de.mef.auto.Config extends java.lang.Object{public static final int VALUE1;public static final int VALUE2;public static final int VALUE3;public static void test();  Code:   0:   getstatic       #22; //Field java/lang/System.out:Ljava/io/PrintStream;   3:   ldc     #24; //String nothing   5:   invokevirtual   #30; //Method java/io/PrintStream.println:(Ljava/lang/String;)V   8:   returnpublic de.mef.auto.Config();  Code:   0:   aload_0   1:   invokespecial   #33; //Method java/lang/Object."<init>":()V   4:   return}


[Edited by - Thygrrr on August 11, 2006 9:06:20 AM]
Quote:In fact, I read that javac doesn't optimize


Java is a JIT language...it isn't fully compiled until runtime when it is compiled for the specific device in which it is running on.
I know, and I also know that Java, at runtime, can perform breathtaking optimizations specifically adapted to the platform the VM is running on. Optimal register and cache usage determined at runtime, from observing program behaviour, for example. Object creation path is somewhere around 50 instructions in Java 1.6, which is totally awesome. Commonplace C++ heap managers require much more than that.

Still, I do believe that some moderate, trivial optimizations should be made at compile time.

Furthermore, please note that this is for mobile devices - Java VM 1.1, hardly any HI implementations out yet, etc. pp. These VMs mostly interpret the byte code rather dumbly.

This topic is closed to new replies.

Advertisement