jit

How does a virtual machine generate native machine code on the fly and execute it? Assuming you can figure out what are the native machine op-codes you want to emit, how do you go about actually running it? Is it something as hacky as mapping the mnemonic instructions to binary codes, stuffing it into an char* pointer and casting it as a function and executing? Or would you generate a temporary shared library (.dll or .so or whatever) and load it into memory using standard functions like LoadLibrary ? You can just make the program counter point to the code you want to execute. Remember that

I got the below assembly list as result for JIT compilation for my java program. mov 0x14(%rsp),%r10d inc %r10d mov 0x1c(%rsp),%r8d inc %r8d test %eax,(%r11) ; <--- this instruction mov (%rsp),%r9 mov 0x40(%rsp),%r14d mov 0x18(%rsp),%r11d mov %ebp,%r13d mov 0x8(%rsp),%rbx mov 0x20(%rsp),%rbp mov 0x10(%rsp),%ecx mov 0x28(%rsp),%rax movzbl 0x18(%r9),%edi movslq %r8d,%rsi cmp 0x30(%rsp),%rsi jge 0x00007fd3d27c4f17 My understanding the test instruction is useless here because the main idea of the test is The flags SF, ZF, PF are modified while the result of the AND is discarded. and here we don't

After recently upgrading to .net 4.6 we discovered a bug where RyuJit produces incorrect results, we were able to work around the issue for now by adding useLegacyJit enabled="true" to the app.config. How can I debug the machine code generated by the following? I created a new console project in VS 2015 RTM, set to Release, Any CPU, unchecked Prefer 32 bit, running with and without debugger attached produces the same result. using System; using System.Runtime.CompilerServices; namespace ConsoleApplication2 { class Program { static void Main(string[] args) { Console.WriteLine(Calculate());

I wrote a server application in Java 8, and running it with java 1.8.0u25. It works fine for the first several hours, but after it gets about 5k~10k requests, a thread of the VM process uses 100% of one of the CPUs. So I tried jstack for the VM process to check what the problematic thread was, and it showed that the thread(thread id was 14303=0x37df) was "C2 CompilerThread0": "C2 CompilerThread0" #6 daemon prio=9 os_prio=0 tid=0x00002aaabc12a000 nid=0x37df runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE And with jstack -m , the stack trace of the thread was as the following: ---

We recently had a situation where one of our production JVMs would randomly freeze. The Java process was burning CPU, but all visible activity would cease: no log output, nothing written to the GC log, no response to any network request, etc. The process would persist in this state until restarted. It turned out that the org.mozilla.javascript.DToA class, when invoked on certain inputs, will get confused and call BigInteger.pow with enormous values (e.g. 5^2147483647), which triggers the JVM freeze. My guess is that some large loop, perhaps in java.math.BigInteger.multiplyToLen, was JIT'ed