Hi Andrew,

Whether or not the jsr instruction is used is -target specific; version 50.0 class files from -target 6 and later do not support jsr/ret since stackmaps are used.

I haven't delved into the OpenJDK 6 build before writing this email, but I suspect some of the classes in rt.jar are compiled with -target 5, but javac in OpenJDK 6 defaults to -target 6 so you wouldn't see jsr instructions from a stock compile.

Sufficiently recent versions of javap will emit the classfile version under the -verbose flag.

HTH,

-Joe

[1] "Source, target, class file version decoder ring,"
http://blogs.oracle.com/darcy/entry/source_target_class_file_version

On 02/02/2012 04:46 AM, Andrew Haley wrote:
I'm sorry for the cross-post, but I don't know exactly who to
address this to.

Just to save you time reading all this: the javac in OpenJDK 6
generates jsr instructions, but only if you compile a great many
source files in one go.  This affects rt.jar.  I'm trying to find
out why.

If you build OpenJDK6 and do this:

happy:jdk6 $ javap -c -bootclasspath build/linux-amd64/classes/ -classpath 
build/linux-amd64/classes/ java.util.concurrent/PriorityBlockingQueue | grep jsr
    48:  jsr     62
    56:  jsr     62
    17:  jsr     28
    23:  jsr     28
    74:  jsr     87
  ...

you'll see lots of jsr instructions.  Why is this?  It seems that if
you compile the .java file this doesn't happen:

happy:jdk6 $ ./build/linux-amd64/j2sdk-image/jre/bin/java -Xmx896m -Xms128m 
-XX:PermSize=32m -XX:MaxPermSize=160m 
-Xbootclasspath/p:./build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar 
-jar ./build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar -g -source 1.5 
-target 5 -encoding ascii 
-Xbootclasspath:/local/openjdk/jdk6/build/linux-amd64/classes -sourcepath 
/local/openjdk/jdk6/build/linux-amd64/gensrc:/local/openjdk/jdk6/jdk/src/solaris/classes:/local/openjdk/jdk6/jdk/src/share/classes
 -d /tmp
/local/openjdk/jdk6/jdk/src/share/classes/java/util/concurrent/PriorityBlockingQueue.java

happy:jdk6 $  javap -c -bootclasspath /tmp -classpath /tmp 
java.util.concurrent/PriorityBlockingQueue | grep jsr

No jsr instructions this time.

So, I try the compile again, but with the full list of classes in .classes.list:

  $  $ /local/openjdk/jdk6/build/linux-amd64/j2sdk-image/jre/bin/java -Xmx896m 
-Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m 
-Xbootclasspath/p:/local/openjdk/jdk6/build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar
 -jar 
/local/openjdk/jdk6/build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar -g 
-source 1.5 -target 5 -encoding ascii 
-Xbootclasspath:/local/openjdk/jdk6/build/linux-amd64/classes -sourcepath
/local/openjdk/jdk6/build/linux-amd64/gensrc:/local/openjdk/jdk6/jdk/src/solaris/classes:/local/openjdk/jdk6/jdk/src/share/classes
 -d /tmp 
@/local/openjdk/jdk6/build/linux-amd64/tmp/java/java.lang/java/.classes.list

  $  javap -c -bootclasspath /tmp -classpath /tmp 
java.util.concurrent/PriorityBlockingQueue | grep jsr | head -5
    48:  jsr     62
    56:  jsr     62
    17:  jsr     28
    23:  jsr     28
    74:  jsr     87

Lots of jsrs.

Now the really weird bit: if I edit classes.list to contain only a
small subset of the files and run the command again,

  $ grep java.util.concurrent 
/local/openjdk/jdk6/build/linux-amd64/tmp/java/java.lang/java/.classes.list>  
classes.concurrent

  $ /local/openjdk/jdk6/build/linux-amd64/j2sdk-image/jre/bin/java -Xmx896m 
-Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m 
-Xbootclasspath/p:/local/openjdk/jdk6/build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar
 -jar 
/local/openjdk/jdk6/build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar -g 
-source 1.5 -target 5 -encoding ascii 
-Xbootclasspath:/local/openjdk/jdk6/build/linux-amd64/classes -sourcepath
/local/openjdk/jdk6/build/linux-amd64/gensrc:/local/openjdk/jdk6/jdk/src/solaris/classes:/local/openjdk/jdk6/jdk/src/share/classes
 -d /tmp @classes.concurrent

  $  javap -c -bootclasspath /tmp -classpath /tmp 
java.util.concurrent/PriorityBlockingQueue | grep jsr | head -5

... no jsr instructions.

I realize that OpenJDK 6 is nearing EOL, but this behaviour is so bizarre
that I'd appreciate some input!

Thanks,
Andrew.

Reply via email to