RSS

From Java Source to Bare Metal, Part Four: The Battle of Eight Cores

12 Jan

Episode 52

This is the fourth and final episode of our little Hobbit’s journey through layers of abstraction of web application and all its foundations down to hardware. Starting in episode 49, we traveled all the way from Java code, web framework, web server, Java virtual machine, container, operating system through Internet Protocol Suite. It’s time to meet the Bare Metal.

smaug-the-hobbit-dragon.png.jpg

The Hobbit paced across maze of corridors and shafts inside the mountain to finally emerge through the main gate and run down the valley to breathe a fresh air. A moment later he froze, turned around, looked up and realized his grievous mistake. The Physical Dragon was not above the Lake City anymore. He was lurking at the mountain side, just above the gate, piercing terrified Hobbit with his gaze.  

Fire and Water: The Bare Metal

Everything we talked about up to this point was basically software. Now it’s time to look into our Hobbit whereabouts from the physical machine point of view. We started with an assumption, that we have a reference to the Hobbit object in our Java code. The object lives on JVM heap, which is a part of virtual memory allocated to JVM process, which in turn is mapped onto physical memory. Our interest in the Hobbit thus started somewhere inside one of RAM dies of our physical system.

lake-town2

Data and program both reside in RAM after being loaded there from hard drive, network or other source. Program consists of list of CPU instructions to be executed, like transferring data from memory into registers, performing mathematical operations on them, wiggling bits, checking conditions and jumping around. Modern CPUs have over 200 instructions, some of them very specialized. If the Hobbit would be used extensively, it can actually be moved from RAM memory into processor cache. In order to improve efficiency, processors have up to three levels of cache, each one smaller but faster than the previous. There are various strategies to move pieces of data around, depending on access patterns. If we were to perform operations on the data fields inside Hobbit, their values would be temporarily stored in processor registers, the fastest type of memory we have on our disposal.

How the Hobbit travels between RAM and CPU? They are both sitting on a motherboard, which provide a system bus interface to connect them. Historically, in order to fetch data from RAM, there was a separate motherboard chip called north bridge. Currently it’s a part of CPU – an Integrated Memory Controller. Its job is to manage reading from and writing to memory and it communicates using multiplexer circuit sending requests for particular memory cell value to demultiplexer unit on the RAM die. So we know a little how the Hobbit moves around our hardware when being handled by our program, but what’s with all that network stack and actual physical medium now?

Smaug1.jpg

The Physical Dragon spread its gargantuan wings and leaned back on hind legs as if to present all its might to the petrified Hobbit. It seemed, that the entire area of the ancient creature’s skin is covered by thick metal armor plates. Moment later, the Dragon jumped forward, landed just in front of the Hobbit pounding the ground heavily. He carefully grabbed the Hobbit with its claws, as the poor one tried to crawl away in despair. Then the dragon slammed its wings and launched into the air, quickly leaving the Lonely Mountain behind.

The Gathering of the Clouds: The Electric Wire

In the previous episode, we talked about Internet Protocol Suite and OSI networking model. While the first ends at network layer, the second mentions also the physical layer, so the level at which we describe how to send particular bits of the message into the world using electricity, light, radio waves or courier animals. What exactly can be the Physical Layer, and how it relates to what we already know?

smaug-attacks-lake-town.jpg

The Internet Protocol Suite is typically implemented in software up to the Link Layer. Hardware implementations also exist, but they are aimed at specialized network devices like routers or hardware firewalls. Physical layer is the most diverse, there are multitude of ways in which computers can communicate with one other. Let’s name just a few to give us a glimpse of the variety: 1-Wire, Bluetooth, GSM air interface, IRDA, USB or WiFi. The most interesting standard, from our point of view, is the collection of Ethernet Physical Layer specifications, focusing currently on fiber channels and unshielded twisted pair cables. The UTP cable is what is most likely sticking out of typical PC, in order to connect it to the local network and further to the internet.

We should now look into how to deliver the Hobbit to Network Interface Controller, or more colloquially: the network card. Traditionally, on the mother board, between RAM and the NIC, sat a chip called the south bridge. In case of Intel architecture, it later evolved into Platform Controller Hub and currently is starting to be incorporated into CPU itself. Anyway, the job of this unit is to take care about all computer system peripherals, including networking. There are many strategies to do that, but basically the idea is, that operating system takes a bunch of bytes and tells the NIC software driver to take over. The NIC driver orders the NIC hardware to push the data, bit by bit down the wire, or whatever it has there.

SmaugDeath1.jpg

Example of Ethernet Physical Layer standard are 100BASE-T or 10GBASE-T, which define how to send data at 100MB/s or 10GB/s respectively using category 5e or 6e unshielded twisted pair cable. The specification dictates the exact cable type, required electrical properties, mode of operation, bit rates, voltages, signals or maximum cable length. The particular NIC, like Intel X540-T2 is an implementation of this standard in the form of physical device, be it a separate network card in PCI socket, or a chip integrated into motherboard along with appropriate ports. It’s like servlet standard being specification, and Tomcat server being an implementation. Finally, our Hobbit, nested in all the higher layer headers like an onion and chopped to separate bits, is ready to leave the physical machine.

The Last Stage

The dragon, sailing steadily through the air, suddenly jerked, twisted his body and roared loudly. He took a sharp turn and at the same time let go of surprised Hobbit, who suddenly found himself in the void. Hobbits’ heart pounded violently as he started to accelerate down, plunging into the cloud. Then, he heard a shriek coming from the east. A much smaller dragon appeared out of nowhere and gently grabbed falling Hobbit with its paws. The small dragon climbed the sky quickly and emerged above the clouds. The hobbit watched in awe, as they glided towards mysterious lands beyond the clouds, far away over the horizon.

The response is out in the internet, approaching awaiting client. That’s the end of this journey. In the four-part story, we accompanied our Hobbit through the following chapters:

If put together, this would be my longest article on this blog by far. I hope you enjoyed this mashup with Tolkien universe, and found here something useful, or at least interesting. See you next week!

crazy_crossover___smaug_vs_night_fury_by_thejuras-d7gtu33

image source

 
Leave a comment

Posted by on January 12, 2017 in Technology

 

Tags: , , , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: