Given this program:

    class Test {
        public static void main(String[] args) {
            try {
                throw new NullPointerException();
            } catch (NullPointerException npe) {
                System.out.println(&quot;In catch&quot;);
            } finally {
                System.out.println(&quot;In finally&quot;);
            }
        }
    }

Sun&#39;s `javac` (v 1.6.0_24) produces the following bytecode:

    public static void main(java.lang.String[]);

            // Instantiate / throw NPE
       0:   new     #2;         // class NullPointerException
       3:   dup
       4:   invokespecial   #3; // Method NullPointerException.&quot;&lt;init&gt;&quot;:()V
       7:   athrow
    
            // Start of catch clause
       8:   astore_1
       9:   getstatic       #4; // Field System.out
       12:  ldc     #5;         // &quot;In catch&quot;
       14:  invokevirtual   #6; // Method PrintStream.println
       17:  getstatic       #4; // Field System.out
    
            // Inlined finally block
       20:  ldc     #7;         // String In finally
       22:  invokevirtual   #6; // Method PrintStream.println
       25:  goto    39
    
            // Finally block
            // store &quot;incomming&quot; exception(?)
       28:  astore_2
       29:  getstatic       #4; // Field System.out
       32:  ldc     #7;         // &quot;In finally&quot;
       34:  invokevirtual   #6; // Method PrintStream.println
    
            // rethrow &quot;incomming&quot; exception
       37:  aload_2
       38:  athrow
    
       39:  return

With the following exception table:

      Exception table:
       from   to  target type
         0     8     8   Class NullPointerException
         0    17    28   any
        28    29    28   any

&lt;br/&gt;
My question is: **Why on earth does it include that last entry in the exception table?!** 
&lt;br/&gt;&lt;br/&gt;
As I understand it, it basically says &quot;*if the `astore_2` throws an exception, catch it, and retry the same instruction*&quot;.

Such entry is produced even with empty try / catch / finally clauses such as

    try {} catch (NullPointerException npe) {} finally {}


----------

**Some observations**

- Eclipse compiler does not produce any such exception table entry
- The JVM spec does not document any runtime exceptions for [the `astore` instruction](http://java.sun.com/docs/books/jvms/second_edition/html/Instructions2.doc.html#astore).
- I know that it is legal for the JVM to throw `VirtualMachineError` for any instruction. I guess the peculiar entry prevents any such errors from propagating out from that instruction.

Strange exception table entry produced by Sun&#39;s javac

The Java static compiler (javac) inlines some static final variables and brings the values directly to the constant pool. Consider the following example. Class A defines some constants (public static final variables):

    public class A {
        public static final int INT_VALUE = 1000;
        public static final String STRING_VALUE = &quot;foo&quot;;
    }

Class B uses these constants:

    public class B {
        public static void main(String[] args) {
            int i = A.INT_VALUE;
            System.out.println(i);
            String s = A.STRING_VALUE;
            System.out.println(s);
        }
    }

When you compile class B, javac gets the values of these constants from class A and inlines these values in B.class. As a result, the dependency B had to class A at the compile time is erased from the bytecode. This is a rather peculiar behavior because you are baking in the values of these constants **at the time of compilation**. And you would think that this is one of the easiest things that the JIT compiler can do at runtime.

Is there any way or any hidden compiler option that lets you disable this inlining behavior of javac? For the background, we&#39;re looking into doing bytecode analysis for dependency purposes, and it is one of the few cases where bytecode analysis fails to detect compile-time dependencies. Thanks!

**Edit**: this is a vexing issue because normally we don&#39;t control all the source (e.g. third-party libraries that define constants). We&#39;re interested in detecting these dependencies from the perspective of **using** the constants. Since the reference is erased from the code that **uses** the constants, there is no easy way to detect them, short of doing source code analysis.




is it possible to disable javac&#39;s inlining of static final variables?

I have been investigating this error for a whole three days, but still no progress. I hope I can get some tips from here. 

What I am trying to do is to inline a MethodNode into a MethodHandle Call Site (#5, #17, and #30) with ASM library. For simplification, the MethodHandle at #5 references a static method ``static Functions.isFooString(String)boolen``. 

At the call site, the instruction before inlining is like 

        //Before
      stack=3, locals=3, args_size=3
         0: aload_0
         1: getfield      #15                 // Field guard:Ljava/lang/invoke/MethodHandle;
         4: aload_1
         5: invokevirtual #29                 // Method java/lang/invoke/MethodHandle.invokeExact:(Ljava/lang/String;)Z
         8: ifeq          24
        11: aload_0
        12: getfield      #17                 // Field trueTarget:Ljava/lang/invoke/MethodHandle;
        15: aload_1
        16: aload_2
        17: invokevirtual #31                 // Method java/lang/invoke/MethodHandle.invokeExact:(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
        20: checkcast     #33                 // class java/lang/String
        23: areturn
        24: aload_0
        25: getfield      #19                 // Field falseTarget:Ljava/lang/invoke/MethodHandle;
        28: aload_1
        29: aload_2
        30: invokevirtual #31                 // Method java/lang/invoke/MethodHandle.invokeExact:(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
        33: checkcast     #33                 // class java/lang/String
        36: areturn
       StackMapTable: number_of_entries = 1
       frame_type = 24 /* same */
     Exceptions:
        throws java.lang.Throwable

The inlining rule is that copy inline&#39;s body into the call site after storing the arguments to local variables. After inlining, the instruction list is: 

      //After
    Classfile /C:/temp/DYNGuardWithTestHandle1439587569404.class
      Last modified Aug 14, 2015; size 913 bytes
      MD5 checksum 055a99d52cb622a7e86c59de79347f3e
    public class DYNGuardWithTestHandle1439587569404 extends java.lang.invoke.BaseTemplate
      minor version: 0
      major version: 51
      flags: ACC_PUBLIC, ACC_SUPER
    Constant pool:
       #1 = Utf8               DYNGuardWithTestHandle1439587569404
       #2 = Class              #1             // DYNGuardWithTestHandle1439587569404
       #3 = Utf8               java/lang/invoke/BaseTemplate
       #4 = Class              #3             // java/lang/invoke/BaseTemplate
       #5 = Utf8               guard
       #6 = Utf8               Ljava/lang/invoke/MethodHandle;
       #7 = Utf8               trueTarget
       #8 = Utf8               falseTarget
       #9 = Utf8               &lt;init&gt;
      #10 = Utf8               (Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodHandle;)V
      #11 = Utf8               ()V
      #12 = NameAndType        #9:#11         // &quot;&lt;init&gt;&quot;:()V
      #13 = Methodref          #4.#12         // java/lang/invoke/BaseTemplate.&quot;&lt;init&gt;&quot;:()V
      #14 = NameAndType        #5:#6          // guard:Ljava/lang/invoke/MethodHandle;
      #15 = Fieldref           #2.#14         // DYNGuardWithTestHandle1439587569404.guard:Ljava/lang/invoke/MethodHandle;
      #16 = NameAndType        #7:#6          // trueTarget:Ljava/lang/invoke/MethodHandle;
      #17 = Fieldref           #2.#16         // DYNGuardWithTestHandle1439587569404.trueTarget:Ljava/lang/invoke/MethodHandle;
      #18 = NameAndType        #8:#6          // falseTarget:Ljava/lang/invoke/MethodHandle;
      #19 = Fieldref           #2.#18         // DYNGuardWithTestHandle1439587569404.falseTarget:Ljava/lang/invoke/MethodHandle;
      #20 = Utf8               eval
      #21 = Utf8               invokeExact
      #22 = Utf8               (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
      #23 = Utf8               java/lang/Throwable
      #24 = Class              #23            // java/lang/Throwable
      #25 = Utf8               test/code/jit/asm/methodhandle/Functions
      #26 = Class              #25            // test/code/jit/asm/methodhandle/Functions
      #27 = Utf8               isFooString
      #28 = Utf8               (Ljava/lang/String;)Z
      #29 = NameAndType        #27:#28        // isFooString:(Ljava/lang/String;)Z
      #30 = Methodref          #26.#29        // test/code/jit/asm/methodhandle/Functions.isFooString:(Ljava/lang/String;)Z
      #31 = Utf8               printTrueTarget
      #32 = NameAndType        #31:#22        // printTrueTarget:(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
      #33 = Methodref          #26.#32        // test/code/jit/asm/methodhandle/Functions.printTrueTarget:(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
      #34 = Utf8               java/lang/String
      #35 = Class              #34            // java/lang/String
      #36 = Utf8               java/lang/Object
      #37 = Class              #36            // java/lang/Object
      #38 = Utf8               printFalseTarget
      #39 = NameAndType        #38:#22        // printFalseTarget:(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
      #40 = Methodref          #26.#39        // test/code/jit/asm/methodhandle/Functions.printFalseTarget:(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
      #41 = Utf8               Code
      #42 = Utf8               StackMapTable
      #43 = Utf8               Exceptions
    {
      final java.lang.invoke.MethodHandle guard;
        descriptor: Ljava/lang/invoke/MethodHandle;
        flags: ACC_FINAL
    
      final java.lang.invoke.MethodHandle trueTarget;
        descriptor: Ljava/lang/invoke/MethodHandle;
        flags: ACC_FINAL
    
      final java.lang.invoke.MethodHandle falseTarget;
        descriptor: Ljava/lang/invoke/MethodHandle;
        flags: ACC_FINAL
    
      public DYNGuardWithTestHandle1439587569404(java.lang.invoke.MethodHandle, java.lang.invoke.MethodHandle, java.lang.invoke.MethodHandle);
        descriptor: (Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodHandle;)V
        flags: ACC_PUBLIC
        Code:
          stack=2, locals=4, args_size=4
             0: aload_0
             1: invokespecial #13                 // Method java/lang/invoke/BaseTemplate.&quot;&lt;init&gt;&quot;:()V
             4: aload_0
             5: aload_1
             6: putfield      #15                 // Field guard:Ljava/lang/invoke/MethodHandle;
             9: aload_0
            10: aload_2
            11: putfield      #17                 // Field trueTarget:Ljava/lang/invoke/MethodHandle;
            14: aload_0
            15: aload_3
            16: putfield      #19                 // Field falseTarget:Ljava/lang/invoke/MethodHandle;
            19: return
    
      public void eval();
        descriptor: ()V
        flags: ACC_PUBLIC
        Code:
          stack=0, locals=1, args_size=1
             0: return
    
      public java.lang.String invokeExact(java.lang.String, java.lang.String) throws java.lang.Throwable;
        descriptor: (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
        flags: ACC_PUBLIC
        Code:
          stack=3, locals=8, args_size=3
             0: aload_0
             1: getfield      #15                 // Field guard:Ljava/lang/invoke/MethodHandle;
             4: aload_1
             5: astore_3
             6: aload_3
             7: invokestatic  #0                  // #0
            10: fload_2
            11: nop
            12: iconst_0
            13: swap
            14: pop
            15: ifeq          44
            18: aload_0
            19: getfield      #17                 // Field trueTarget:Ljava/lang/invoke/MethodHandle;
            22: aload_1
            23: aload_2
            24: astore        4
            26: astore        5
            28: aload         5
            30: aload         4
            32: invokestatic  #33                 // Method test/code/jit/asm/methodhandle/Functions.printTrueTarget:(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
            35: goto          38
            38: swap
            39: pop
            40: checkcast     #35                 // class java/lang/String
            43: areturn
            44: aload_0
            45: getfield      #19                 // Field falseTarget:Ljava/lang/invoke/MethodHandle;
            48: aload_1
            49: aload_2
            50: astore        6
            52: astore        7
            54: aload         7
            56: aload         6
            58: invokestatic  #40                 // Method test/code/jit/asm/methodhandle/Functions.printFalseTarget:(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
            61: goto          64
            64: swap
            65: pop
            66: checkcast     #35                 // class java/lang/String
            69: areturn
          StackMapTable: number_of_entries = 1
            frame_type = 254 /* append */
              offset_delta = 44
              locals = [ class java/lang/Object, class java/lang/Object, class java/lang/Object ]
        Exceptions:
          throws java.lang.Throwable
    
    }

Clearly, the #5 (before)in the original instruction is replaced by WRONG instructions #7--#12 (after), which should not exist here. Instead, there should only be one instruction, here: 

       invokestatic Method test/code/jit/asm/methodhandle/Functions.isFooString:(Ljava/lang/String;)Z;

Worse, the #7 of the invokeExact(after) is completely illegal which caused the JVM crash down. 
The other two instructions #17 and #30 (before) are correctly substituted. 

It is clear from the generated bytecodes, but this is different from the behavior defined by my code. The way to build the MethodNode is: 

       MethodNode buildMethod(...){
         ...
        access=ACC_PUBLIC+ACC_STATIC;
        String owner = Type.getType(definingClass).getInternalName();
    	String desc = type.toMethodDescriptorString();
    	MethodNode methodNode = new MethodNode(Opcodes.ASM5, access, mhName, type.toString(), null, null);
    	if(name.equals(&quot;isFooString&quot;)){
    		methodNode.instructions.add(new VarInsnNode(Opcodes.ALOAD, 0));
    		System.out.println(&quot;owner=&quot;+owner+&quot; name=&quot;+name+&quot;  desc=&quot;+desc);
           //owner=test/code/jit/asm/methodhandle/Functions name=isFooString  desc=(Ljava/lang/String;)Z
    		methodNode.instructions.add(new MethodInsnNode(Opcodes.INVOKESTATIC, owner, name, desc, false));
    		methodNode.instructions.add(new InsnNode(Opcodes.IRETURN));
    		return methodNode;
    	}
    	
    	AbstractInsnNode insn = new MethodInsnNode(originIsFindVirtual?Opcodes.INVOKEVIRTUAL: Opcodes.INVOKESTATIC, owner, name, desc, false);
    	Type[] args = Type.getArgumentTypes(desc);
    	
    	for(Type arg : args){
    		AbstractInsnNode node = new VarInsnNode(arg.getOpcode(Opcodes.ILOAD), start);
    		start += arg.getSize();
    		methodNode.instructions.add(node);
    	}
    	methodNode.instructions.add(insn);
    	int Return = Type.getReturnType(desc).getOpcode(Opcodes.IRETURN);
    	
    	methodNode.instructions.add(new InsnNode(Return));
    	return methodNode;
        }

And InliningAdapter: 


    //The full version can be accessed by https://github.com/xushijie/InlineMethod/blob/typeinference/src/main/java/code/jit/asm/core/InliningAdapter.java
    public class InliningAdapter extends RemappingMethodAdapter{

    /** The main task in the Constructor is to store pushed parameters of the MethodNode to a new local variables and store the remaining arguments of the stack to another temporary stacks in case of exceptions in the MethodNode */ 
    public InliningAdapter(LocalVariablesSorter lvsMV, int acc, String desc,
    Remapper remapper, Label end, MethodContext context) {
       super(acc, desc, lvsMV, remapper);
       lvs = lvsMV;
       mv = context.getRawMV();
       this.end = end;
       _context = context;
       List&lt;Type&gt; types = _context.getOperandStack();
       int offset = ((acc &amp; Opcodes.ACC_STATIC) != 0 ? 0 : 1);
       Type[] args = Type.getArgumentTypes(desc);
       for (int i = args.length - 1; i &gt;= 0; i--) {
          super.visitVarInsn(args[i].getOpcode(Opcodes.ISTORE), i + offset);
       }
       int poped = args.length;
       if (offset &gt; 0) {
       poped++;
       super.visitVarInsn(Opcodes.ASTORE, 0);
       }
       int left = types.size() - poped - 1;
       while (left &gt; 0) {
       // NON-parameters in the stack =&gt; pop up too and restore back after
       // complete.
       int variable = newLocal(types.get(left));
       int opcode = types.get(left).getOpcode(Opcodes.ISTORE);
       __callerstacks.add(0, new StackEle(types.get(left), variable)); //    |--&gt;TOP
       mv.visitVarInsn(opcode, variable);
       left--;
       }
    }

	@Override
    public void visitMethodInsn(final int opcode, final String owner,
            final String name, final String desc, final boolean itf) {
		System.out.println(&quot;[Callee: ] invokeVirtual &quot;+ owner +&quot;  &quot;+name+&quot;  &quot;+ desc);
		_context.getRawMV().visitMethodInsn(opcode, owner, name, desc, itf);
        //_context.getRawMV() is a MethodWriter. and the value of the (owner, name, desc) is /.//Functions, isFooString, (String;)Z, which is correct. 
    }

	@Override
	public void visitVarInsn(final int opcode, final int var) {
        //I confirm this method is not invoked after visitMethodInsn. 
		super.visitVarInsn(opcode, var + firstLocal);
	}
    }

For each invokevirtual instruction (#5, #17. #30) in the original bytecodes, it is like: 
   
    mn = buildMethodNode(...);
    mn.accept(new InliningAdapter(this,
    					opcode == Opcodes.INVOKESTATIC ? Opcodes.ACC_STATIC : 0, desc,  _context));  //mn is my constructed MethodNode previsouly, which contains one method invocation. 

To resolve the issue( the parameters for the first visited ``invokestatic`` is missing and some illegal instructions are added). I debug my code (Sorry I cannot post all of it here because there are too many files), and it monitors all parameters that are written to the MethodWriter in the``visitMethodInsn`` of the ``InliningAdapter``. It proves that all these values (Functions, isFooString, (String;)Z) are correct, which are the same as my expectation. 

So my questions are: 
 

 - Is there something wrong in my MethodNode builder? 
 - What kinds of reasons can result to this issue?  There are also other similar cases, where the first ``invokevirtual`` instructions are wrongly substituted by something like, nop, fdouble, and asatore (These substitutions do not exist in my code). 

 - Also, I confirm the override method ``visitMethodInsn`` is not invoked after the ``visitMethodInsn`` before ``accept`` completes. That means, the wrong instructions, i.e., #10 ``fload`` and #12 ``iconst``, are not from the built MethodNode. 

 - I made another try that disable the inlining of the first invokevirtual (#5 //Before). The generated class succeeds and can be launched. For me, it looks like the problem is at ``isFooString`` MethodNode  building.



Method invocation instruction (invokevirtual/invokestatic) is substituted by some unexpected instructions

Python has a flag `-O` that you can execute the interpreter with. The option will generate &quot;optimized&quot; bytecode (written to .pyo files), and given twice, it will discard docstrings. From Python&#39;s man page:

&gt; -O Turn on basic optimizations.  This changes the  filename  extension 
&gt; for  compiled  (bytecode)  files from .pyc to .pyo.  Given twice,
&gt; causes docstrings to be discarded.

This option&#39;s two major features as I see it are:

* Strip all assert statements. This trades defense against corrupt program state for speed. But don&#39;t you need a ton of assert statements for this to make a difference? Do you have any code where this is worthwhile (and sane?)

* Strip all docstrings. In what application is the memory usage so critical, that this is a win? Why not push everything into modules written in C?


What is the use of this option?
Does it have a real-world value?

What is the use of Python&#39;s basic optimizations mode? (python -O)

The design of GHC is based on something called STG, which stands for &quot;spineless, tagless G-machine&quot;.

Now G-machine is apparently short for &quot;graph reduction machine&quot;, which defines how laziness is implemented. Unevaluated thunks are stored as an expression tree, and executing the program involves _reducing_ these down to normal form. (A _tree_ is an acyclic graph, but Haskell&#39;s pervasive recursion means that Haskell expressions form general _graphs_, hence graph-reduction and not tree-reduction.)

What is less clear are the terms &quot;spineless&quot; and &quot;tagless&quot;.

1. I _think_ that &quot;spineless&quot; refers to the fact that function applications do not have a &quot;spine&quot; of function application nodes. Instead, you have an object that names the function called and points to all of its arguments. Is that correct?

2. I thought that &quot;tagless&quot; referred to constructor nodes not being &quot;tagged&quot; with a constructor ID, and instead case-expressions are resolved using a jump instruction. But now I&#39;m not sure that&#39;s correct. Instead, it seems to refer to the fact that nodes aren&#39;t tagged with their evaluation state. Can anyone clarify which (if any) of these interpretations is correct?


Understanding STG

I know that PHP is compiled to byte code before it is run on the server, and then that byte code can be cached so that the whole script doesn&#39;t have to be re-interpreted with every web access.

But can you &quot;compile&quot; PHP code and upload a binary-ish file, which will just be run by the byte code interpreter?


Can you &quot;compile&quot; PHP code and upload a binary-ish file, which will just be run by the byte code interpreter?

I have the following Java class

    public class HelloWorld {
      public static void main(String []args) {
      }
    }

When I compile this file and run a sha256 on the resulting class file I get 

&lt;!-- language: lang-none --&gt;

    9c8d09e27ea78319ddb85fcf4f8085aa7762b0ab36dc5ba5fd000dccb63960ff  HelloWorld.class

Next I modified the class and added a blank line like this: 

    public class HelloWorld {

      public static void main(String []args) {
      }
    }

Again I ran a sha256 on the output expecting to get the same result but instead I got 

&lt;!-- language: lang-none --&gt;

    11f7ad3ad03eb9e0bb7bfa3b97bbe0f17d31194d8d92cc683cfbd7852e2d189f  HelloWorld.class

I have read on [this TutorialsPoint article][1] that:

&gt; A line containing only white space, possibly with a comment, is known as a blank line, and Java totally ignores it.

So my question is, since Java ignores blank lines why is the compiled bytecode different for both programs?

Namely the difference in that in `HelloWorld.class` a `0x03` byte is replaced by a `0x04` byte.

  [1]: https://www.tutorialspoint.com/java/java_basic_syntax.htm

Why does a Java class compile differently with a blank line?

The following Java program takes on average between 0.50 secs and 0.55 secs to run:

    public static void main(String[] args) {
        long startTime = System.nanoTime();
        int n = 0;
        for (int i = 0; i &lt; 1000000000; i++) {
            n += 2 * (i * i);
        }
        System.out.println((double) (System.nanoTime() - startTime) / 1000000000 + &quot; s&quot;);
        System.out.println(&quot;n = &quot; + n);
    }

If I replace `2 * (i * i)` with `2 * i * i`, it takes between 0.60 and 0.65 secs to run. How come?

I ran each version of the program 15 times, alternating between the two. Here are the results:

     2*(i*i)  |  2*i*i
    ----------+----------
    0.5183738 | 0.6246434
    0.5298337 | 0.6049722
    0.5308647 | 0.6603363
    0.5133458 | 0.6243328
    0.5003011 | 0.6541802
    0.5366181 | 0.6312638
    0.515149  | 0.6241105
    0.5237389 | 0.627815
    0.5249942 | 0.6114252
    0.5641624 | 0.6781033
    0.538412  | 0.6393969
    0.5466744 | 0.6608845
    0.531159  | 0.6201077
    0.5048032 | 0.6511559
    0.5232789 | 0.6544526

The fastest run of `2 * i * i` took longer than the slowest run of `2 * (i * i)`. If they had the same efficiency, the probability of this happening would be less than `1/2^15 * 100% = 0.00305%`.


Why is 2 * (i * i) faster than 2 * i * i in Java?

Just wondering if anyone has tried using new Java 7 language features with Android?
I know that Android reads the bytecode that Java spits out and turns it to dex. So I guess my question is can it understand the bytecode of Java 7?

Java 7 language features with Android

Are there currently (Java 6) things you can do in Java bytecode that you can&#39;t do from within the Java language?

I know both are Turing complete, so read &quot;can do&quot; as &quot;can do significantly faster/better, or just in a different way&quot;.

I&#39;m thinking of extra bytecodes like `invokedynamic`, which can&#39;t be generated using Java, except that specific one is for a future version.

Bytecode features not available in the Java language

As a sort of follow up to the question called [Differences between MSIL and Java bytecode?][1], what is the (major) differences or similarity in how the Java Virtual Machine works versus how the &lt;del&gt;.NET Framework&lt;/del&gt; Common Language Runtime (CLR) works?

Also, is the &lt;del&gt;.NET framework&lt;/del&gt; CLR a &quot;virtual machine&quot; or does it not have the attributes of a virtual machine? 



  [1]: https://stackoverflow.com/questions/95163/differences-between-msil-and-java-bytecode

Java&#39;s Virtual Machine and CLR

I have decided to check out Emacs, and I liked it very much. Now, I&#39;m using the [Emacs Starter Kit][1], which sort of provides better defaults and some nice customizations to default install of Emacs.

I have customized it a little, added some stuff like [yasnippet][2], [color-themes][3], [unbound][4], and other stuff. I&#39;ve set up a [github repository][5] where I keep all of the customizations so I can access them from multiple places or in case something goes bad and I lose my .emacs.d directory.

All of this is very nice, but there is a problem: Emacs takes about 1-2 seconds to load. AFAIK I can compile individual .el files with M-x byte-compile-file to .elc, and it works. But there are a lot of .el files, and I wonder if there is a way to compile them all with a simple command or something, to speed up the loading of Emacs. My Emacs is not always open, and I open and close it quite frequently, especially after I&#39;ve set it up as a default editor for edit command in Total Commander to get used to it faster (yeah, windows xp here).

My Emacs version is 22.3. And yes, the default Emacs installation without any customizations fires up instantly.

I am not sure which version is preferred when loading, the .el or compiled .elc one by the way O.o

So, is there an elisp command or Emacs command line switch to make Emacs byte-compile everything in .emacs.d directory?


  [1]: http://github.com/technomancy/emacs-starter-kit/tree/master
  [2]: http://code.google.com/p/yasnippet/
  [3]: http://www.nongnu.org/color-theme/
  [4]: http://www.emacswiki.org/emacs/unbound.el
  [5]: http://github.com/Irwin1138/emacs-starter-kit/tree/master

How do I byte-compile everything in my .emacs.d directory?

How is pattern matching in Scala implemented at the bytecode level?

Is it like a series of `if (x instanceof Foo)` constructs, or something else? What are its performance implications?

For example, given the following code (from [Scala By Example][1] pages 46-48), how would the equivalent Java code for the `eval` method look like?

    abstract class Expr
    case class Number(n: Int) extends Expr
    case class Sum(e1: Expr, e2: Expr) extends Expr

    def eval(e: Expr): Int = e match {
      case Number(x) =&gt; x
      case Sum(l, r) =&gt; eval(l) + eval(r)
    }

P.S. I can read Java bytecode, so a bytecode representation would be good enough for me, but probably it would be better for the other readers to know how it would look like as Java code.

P.P.S. Does the book [Programming in Scala][2] give an answer to this and similar questions about how Scala is implemented? I have ordered the book, but it has not yet arrived.

  [1]: http://www.scala-lang.org/docu/files/ScalaByExample.pdf
  [2]: http://www.amazon.com/Programming-Scala-Comprehensive-Step-step/dp/0981531601


How is pattern matching in Scala implemented at the bytecode level?

My understanding is that C/C++ produces native code to run on a particular machine architecture.  Conversely, languages like Java and C# run on top of a virtual machine which abstracts away the native architecture.  Logically it would seem impossible for Java or C# to match the speed of C++ because of this intermediate step, however I&#39;ve been told that the latest compilers (&quot;hot spot&quot;) can attain this speed or even exceed it.

Perhaps this is more of a compiler question than a language question, but can anyone explain in plain English how it is possible for one of these virtual machine languages to perform better than a native language?

C++ performance vs. Java/C#

I&#39;m confused about machine code and native code in the context of .NET languages.

What is the difference between them? Are they the same?


What is the difference between native code, machine code and assembly code?

&gt; **Possible Duplicate:**  
&gt; [Is there a java classfile / bytecode editor to edit instructions?](https://stackoverflow.com/questions/3308351/is-there-a-java-classfile-bytecode-editor-to-edit-instructions)  

&lt;!-- End of automatically inserted text --&gt;

Java source code is compiled into bytecode, which is actually in the class file. Is it possible  to view bytecode of a compiled class?
 
If it is possible, can it be edited?

Is there an eclipse plugin for that available?

Is it possible to view bytecode of Class file?

What is exactly the function of Python&#39;s Global Interpreter Lock?
Do other languages that are compiled to bytecode employ a similar mechanism?

Why the Global Interpreter Lock?

I have a doubt, whether the unused imports and unused objects in Java code create any performance impact?

Suppose an object is initialized and never used, what happens?
And what is the cost of unused imports?

Does unused import and objects have a performance impact

I&#39;m new to .Net and I&#39;m trying to understand the basics first. What is the difference between MSIL and Java bytecode?

Differences between MSIL and Java bytecode?

I&#39;m going through MSIL and noticing there are a lot of [nop][1] instructions in the MSIL.

The MSDN article says they take no action and are used to fill space if the opcode is patched. They&#39;re used a lot more in debug builds than release builds.

I know that these kinds of statements are used in assembly languages to align later instructions, but why are MSIL nops needed in MSIL?

(Editor&#39;s note: the accepted answer is about machine-code NOPs, not MSIL/CIL NOPs which the question originally asked about.)


  [1]: http://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes.nop.aspx

What&#39;s the purpose of the CIL nop opcode?

I have some difficulty to understand LookUpSwitch and TableSwitch in Java bytecode.

If I understand well, both LookUpSwitch and TableSwitch correspond to the `switch` statement of Java source? Why one JAVA statement generates 2 different bytecodes? 

Jasmin documentation of each:

- [LookupSwitch][1] 
- [tableswitch][2]
- [both][3]

  [1]: https://www.vmth.ucdavis.edu/incoming/Jasmin/ref--41.html
  [2]: https://www.vmth.ucdavis.edu/incoming/Jasmin/ref-tableswi.html
  [3]: http://jasmin.sourceforge.net/instructions.html

Difference between JVM&#39;s LookupSwitch and TableSwitch?

The `invokedynamic` instruction is used to help the VM determine the method reference at runtime instead hardwiring it at compile time. 

This is useful with dynamic languages where the exact method and argument types aren&#39;t known until runtime. But that isn&#39;t the case with Java lambdas. They are translated to a static method with well defined arguments. And this method can be invoked using `invokestatic`.

So then what is the need of `invokedynamic` for lambdas, especially when there is a performance hit?


Why are Java 8 lambdas invoked using invokedynamic?

Why does one long string take MORE space than lots of small strings?

I have Java 6 and 7 installed on my machine. Gradle uses 1.7 (checked using `gradle -v`). But I need to compile my code to be compatible with Java 1.6. As far as I understand the documentation I can use the `sourceCompatibility` property to do so (and indirectly the `targetCompatibility` which defaults to the  `sourceCompatibility`).

So I added the following line to my build file (on the root level, not in any closure):

    sourceCompatibility = 1.6

(to be sure I also added the `targetCompatibility = 1.6` in some trials, but that should not make a difference)


To check whether the result was actually compatible with 1.6 I unzipped the resulting jar, `cd` into the `WEB-INF/classes` folder and used `javap -verbose` on the first `.class` file I encountered. But no matter whether I set the target compatibility or whether I used 1.5 instead of 1.6 or whether I specified it as string (`&#39;1.6&#39;`), each time the result of javap was

    minor version: 0
    major version: 51

Afaik this means it is Java 1.7 Bytecode, which is wrong.

Any ideas why the `sourceCompatibility`-setting doesn&#39;t work? Or is `javap` not the correct way to check the compatibility?


**UPDATE:**
Yes, this is actually a multi-project build but I only checked one of the subprojects&#39; build results. In this subproject&#39;s build file I made the mentioned changes to be sure they are actually applied. In addition, I added the following in the root project&#39;s build file (as @Vidya proposed as well):

    allprojects {
        sourceCompatibility = 1.6
        targetCompatibility = 1.6
    }

But this didn&#39;t help either.

**UPDATE 2:**
I checked the setting of sourceCompatibility with this snippet in the relevant build.gradle files:

    compileJava.doFirst {
        println &quot;source compatibility &quot; + sourceCompatibility
    }

It revealed that my sourceCompatibility is set to 1.7 although I tried to set it to 1.6. When I extracted the simplest subproject and built in on its own the sourceCompatibility is set correctly and the Java Byte code is compatible to 1.6. However, even this sub-project uses the wrong sourceCompatibility when used in the multi project build.


BTW: The plugins I use in some of the sub projects are: `java`, `war`, `jetty`, `gwt`

**UPDATE 3:**
I changed the built scripts to just use the java plugin (and thus just construct some jars) and removed the usage of the `war`, `jetty` and `gwt` plugin. But still all the projects are set to sourceCompatibility 1.7 despite me setting it in the `allprojects` section and in some of the sub projects. All that is left now in the build scripts is the declaration of some decencies (maven, files and other sub projects), the declaration of the repositories to use, the declaration of some others tasks (that the build-task does not depend on, so it shouldn&#39;t be affected) and the configuration of the manifest file for the created jar files (I add a specification and an implementation version and title to the manifest file). 

I don&#39;t see how any of that would affect the sourceCompatibility setting.

Gradle sourceCompatibility has no effect to subprojects

From what I&#39;ve read, there is a llvm program that converts java bytecode to llvm&#39;s intermediate form called class2llvm. My question is, how do I access this. What front end do I have to install in order to access this. 

VMkit is their implementation of a JVM, but I am looking for how to compile the java source code with llvm, not how to run it.

Is there a llvm java front end that converts java source to llvm&#39;s intermediate form?

I&#39;ve got some code that uses try with resources and in jacoco it&#39;s coming up as only half covered. All the source code lines are green, but I get a little yellow symbol telling me that only 4 of 8 branches are covered.

![enter image description here][1]

I&#39;m having trouble figuring out what all the branches are, and how to write code that covers them. Three possible places throw `PipelineException`. These are `createStageList()`, `processItem()` and the implied `close()`

 1. Not throwing any exceptions, 
 1. throwing an exception from `createStageList()`
 1. throwing an exception from `processItem()`
 1. throwing an exception from `close()`
 1. throwing an exception from `processItem()` and `close()`

I can&#39;t think of any other cases, yet I still only have 4 of 8 covered.

Can someone explain to me why it&#39;s 4 of 8 and is there anyway to hit all 8 branches? I&#39;m not skilled with decyrpting/reading/interpreting byte code, but maybe you are... :) I&#39;ve already seen https://github.com/jacoco/jacoco/issues/82, but neither it nor the issue it references help very much (other than noting that this is due to compiler generated blocks)

Hmm, just as I finish writing this I had a thought on what case(s) might not be not tested by what I mention above... I&#39;ll post an answer if I got it right. I&#39;m sure this question and it&#39;s answer will help someone in any case.

**EDIT:** Nope, I didn&#39;t find it. Throwing RuntimeExceptions (not handled by the catch block) didn&#39;t cover any more branches

  [1]: http://i.stack.imgur.com/SggR6.png

8 branches for try with resources - jacoco coverage possible?

I&#39;ve recently been looking at The [Java Virtual Machine Specifications][1] (JVMS) to try to better understand the what makes my programs work, but I&#39;ve found a section that I&#39;m not quite getting...

Section [4.7.4][2] describes the *StackMapTable* Attribute, and in that section the document goes into details about stack map frames. The issue is that it&#39;s a little wordy and I learn best by example; not by reading.

I understand that the first stack map frame is derived from the method descriptor, but I don&#39;t understand how (which is supposedly explained [here][3].) Also, I don&#39;t entirely understand what the stack map frames do. I would assume they&#39;re similar to blocks in Java, but it appears as though you can&#39;t have stack map frames inside each other.

Anyway, I have two specific questions:

  -  What do the stack map frames do?
  -  How is the first stack map frame created?

and one general question:

  -  Can someone provide an explanation less wordy and easier to understand than the one given in the JVMS?


  [1]: http://docs.oracle.com/javase/specs/jvms/se8/html/index.html
  [2]: http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.4
  [3]: http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.10.1.6

What is a stack map frame

There are three opcodes to invoke Java methods. It is clear that invokeStatic is just for static method invocation.

As far as I know invokespecial is used when invoking constructor and private methods. So, do we need to differenticate private and public method invocation at run time? It could be invoked with same opcode say invokevirtual?

Does JVM deals with private and public method definition? As far as I know  public and private keywords is just needed at development phase for encapsulation?


All Bytecode Solutions on Gang of Coders

Total of 28 Bytecode Solutions

Strange exception table entry produced by Sun's javac

is it possible to disable javac's inlining of static final variables?