my only question is what does this bytecode look like and how is it different from machine code? 

also when it "feeds" the processor this machine code what does that look like?

Java is both a compiled and interpreted language. While the javac tool takes the source code .java files you writes and compiles them to bytecode .class files, the JVM interprets this bytecode to produce machine code. This machine code is then fed to the CPU to ultimately process or run your program.

To maximize performance, Java utilizes a just-in-time (JIT) compiler to dynamically compile bytecode to machine code.  This JIT compiler is baked into the JVM and works automatically without any developer intervention.

While developers rarely need to concern themselves with the inner workings of this JIT, it's beneficial to understand what's happening under the hood.  This starts with understanding the difference between compiled vs interpreted languages..

Preface: Compiled vs Interpreted Languages

Languages like C and C++ are compiled languages.  These languages compile source code into an executable binary file that runs directly on the processor (CPU).

Compiled languages are good because they don't require any overhead during runtime.  Unlike an interpreted language, compiled code doesn't need to be evaluated at runtime.  This makes compiled languages generally faster than interpreted languages.

Compiled languages can be bad because they lack portability.  The compiled binary output is often specific to a certain architecture or platform.  The compiled output of your program may work on this machine but not that machine etc.

Compiled languages are also slower on startup and during testing.  This is because they need to be compiled first!

Languages like php, Python, and JavaScript are interpreted languages.  These languages rely on a separate program (the interpreter) to "interpret" the code during runtime.

Instead of compiling the source code upfront, interpreted languages read source code line by line, generating the binary instructions through the interpreter itself.  This makes it possible for interpreted languages to be "platform agnostic" meaning they can run on different platforms the same way.

Interpreted languages are good because they are portable.  You can download php for Mac, Windows, etc and your program will execute the same way.

Interpreted languages are bad because they take longer to execute code.  Unlike a compiled language, interpreters can't feed compiled code directly to a processor.  They have to "interpret" the source code line by line.

Interpreted languages make for faster startup times.  You don't have to wait for the compile step when your program starts.

The JIT compiler allows Java to be both a compiled and interpreted language.  It combines the performance advantage of a compiled language with the flexibility of an interpreted language.

When your Java program executes, the JVM interprets bytecode as part of code analysis and optimization.  It then uses this analysis to dynamically compile and store frequently reused methods to avoid interpreting the same bytecode over and over.

What does this JIT compiler look like?  Where does it live? How does it work?

The JIT compiler is part of the JVM that continuously runs to optimize performance.  While the JVM interprets bytecode, the JIT analyses execution and dynamically compiles frequently executed bytecode to machine code.  This prevents the JVM from having to interpret the same bytecode over and over.

The JIT compiler is not some separate application you download and run alongside your program.  It is simply a description of functionality that exists within the JVM.

The source code you write (.java) is compiled by javac to bytecode. When your program executes, the JVM starts interpreting this bytecode.

The interpreter translates the bytecode into machine code and feeds it to the CPU for processing.  While this happens, the JIT profiles and analyses the code execution.  It tracks the most frequently called methods and dynamically compiles these to machine code at runtime.

This dynamic process prevents the interpreter from having to "interpret" the same methods over and over.  Instead of having to translate bytecode to machine code, the interpreter can instead leverage cached machine code instructions from memory.

This is what makes Java both a compiled and interpreted language.  While the JVM initially interprets code, the JIT compiler works to selectively compile frequently executed code "just in time".

This gives Java the advantage of interpreted languages (faster startup times, more portability) and compiled languages (faster execution, optimized performance).

Client Side, Server Side, and Tiered Compilers

Before Java 8, you could specify either client or server JIT compilers.  While client compilers were better suited for apps having fewer resources available, server compilers worked better for long running apps.

A client side application may be more sensitive to startup time and have fewer resources available for code optimizations and JIT overhead.   A server side application may be long running and more appropriate for heavier optimizations and longer compile times.

The key difference between the two is the level of optimization and profiling. While profiling allows the JIT to better optimize the machine code it sends to the processor, it comes with a performance cost. Client side compilers minimize profiling to reduce overhead and startup time whereas server side compilers rely more heavily on profiling and optimizations.

Beginning with Java 8, the JVM takes a "tiered approach" where both client side and server side techniques are used.  During execution, the JVM initially interprets the bytecode.  It tracks frequently used methods and optimizes code based on the client side (C1) approach.  The JIT continuously analyzes execution and migrates to more of a server side (C2) approach for additional optimizations.

While modern Java installs utilize the tiered approach of combining C1 and C2 compilers, the C2 compiler is dated and hard to maintain.  For these reasons, the Graal JIT compiler was developed as part of a larger GraalVm project.

The Graal JIT compiler is written in Java, giving it the advantage of IDE integration, exception handling, and integration with profilers and debuggers.

The Graal JIT compiler also allows ahead of time (AOT) compiling where execution code is compiled upfront.  This reduces startup time experienced with the conventional JIT compiler.

There is a popular misconception that you can "download" a JIT compiler for Java.  While older versions allowed you to install a JIT as a plugin, all standard Java installations include the JIT compiler as part of the JVM.

As the JIT dynamically compiles code to machine language, it also performs optimizations on your source code to maximize performance.  Following are some examples of these optimizations:

The JIT compiler will optimize the original myMethod() through several steps...

Notice how the get() method is replaced with directly accessing the value. This eliminates method invocations and improves efficiency.

By setting z = a, the compiler reduces the latencies of accessing b.value to improve performance.

Notice how this optimization removes unnecessary variables. Since z ultimately just equals a the JIT compiler removes it altogether.

Since a = a is redundant, the JIT compiler simply removes this "dead code" during optimization.

Apart from these steps, JIT compiler also includes other optimizations like:

Let's say you have a basic null check like:

If JIT notices myVar is never called with null then it will remove this code altogether.

Let's say you have an if..else branch like this:

If the JIT compiler notices that x < y more often than not, it will reverse the branch...

If you have a nested loop, the JIT compiler will unroll it to minimize assembly jumps..

The JIT Compiler in Java including what is the JIT compiler, how the JIT compiler works, JIT compiler optimizations and more.

The JIT Compiler in Java

Garbage collection in Java is non-deterministic.  This means you never really know when GC is going to run in Java.

Remember that GC is an automatic process.  It kind of does it's own thing and runs on it's own threads.  Java is designed for you not to be manually managing memory...

Can we call garbage collector forcefully in Java

Can we call garbage collector forcefully in Java?

This applies only to full time employees but:

Salary ranges from $60 - $150k with junior level representing the lower end and principle the upper end. Of course there are outliers where individuals can make upwards of $400k. 

there is also something to be said for benefits. Lots of competitive employers will offer not only competitive salaries but also great health insurance and even stock options. You really have to look at the full package. 

also remember there is a low and high end to every level. While some engineers may have the same title, they can be separated by decades of experience sometimes.

Is it possible to find software engineer salaries below $50k. The answer is yes but you get what you pay for. Off shore developers have their benefits but are very difficult to coordinate with. 

good people who want the best for your company’s mission are worth the investment. Don’t underestimate what you can do with just a few good engineers. 

Software Engineer Salary?

I am a self taught programmer. It took me 3 years to build and manage my own blog. While there are millions of blogs out there, managing the full stack implementation of that is a great foundation to full stack development. 

This project along with enrollment in a 9 week intensive training course got me my first developer job. 

progressing to the senior level is it’s own challenge. This can take years to achieve and also requires a bit or “right place right time” meaning you stick around at the same place long enough to show your worth your weight. 

so the entire journey obviously continues but I’d say close to a decade gets you to that mastery level you’d seek as a career long goal. 

How long does it take to become a software engineer

How long does it take to become a software engineer?

BE CAREFUL WITH $lookup

Why? Because it goes against everything MongoDb.  Remember that MongoDb is a non-relational data store.  This means it excels with large amounts of unstructured data requiring quick lookups.

When you use $lookup you are performing a join on two different collections. This is STRUCTURED data. If you design a whole schema around a "schemaless" data store then you shouldn't be getting paid to do what you do :)

Relational data stores still have their place.  While there is a lot of hype around NoSQL, iOT, and cloud (buzz words), good old MySQL and other RDBMS are still widely used in production ...and at SCALE.

wow...these examples made $lookup actually make sense.  some of the other stuff out there makes it really hard to understand the simple fact that these are basically "joins" in MongoDb.

Although now I am wondering ..if you are performing these lookups or joins in Mongo, are you really using Mongo as intended?



Steve Jennings

while these examples are great, it's also important to understand performance implications of using $lookup.  Be sure to check out this higher-level take on using $lookup with MongoDB...

https://www.stackchief.com/blog/%24lookup%20in%20MongoDB

stackchief

Tatjana Stankovic

Ammar Sayed

MongoDB $lookup examples including pipeline example, joins, and $lookup with conditions.  Quickly understand $lookup aggregations with these examples and explanations

StackChiefOG

my only question is what does this bytecode look like and how is it different from machine code?

Yes but this is NOT recommended...

This applies only to full time employees but:

I am a self taught programmer. It took me 3 years to build and manage my own blog. While there are millions of blogs out there, managing the full stack implementation of that is a great foundation to full stack development.

BE CAREFUL WITH <span class='code-bite'>$lookup</span>