Object Oriented Programming with Java and Javascript

Hello fellow readers, it’s been a while since last time I blogged so here’s a quick post to review some basic OOP concepts, three of them to be more precise: Inheritance, Polymorphism and Encapsulation.

First you need to know what a class  is, it is that piece of code that you can use to instantiate objects, here’s an example in Java:

public class Beer {
    String name;
    double alcoholUnits;
}

And a similar example in Javascript*:

var Beer = function() {
    var name;
    var alcohol_units;
}

*Which is not really a “class” per se as JS doesn’t have classes, but functions can be defined in specific ways so they can be instantiated as objects.

 

Here’s how you would test the Javascript version  in your browser (Chrome’s Developer Tools or Firefox’s Firebug):

So, moving on to Inheritance and Polymorphism, let’s use the following Friday Quiz question to illustrate these concepts:

Santa sometimes helps the elves making toys.  He can make 30 toys per hour.  In order to prevent getting bored, he starts each day building 50 trains and then makes 50 aeroplanes.  Then he switches back to trains, and alternates until the end of the day.  If he starts work at 8:00 am, at what time will he finish his 108th train?

public class SantaToys {
    static Toy train = new Train();
    static Toy aeroplane = new Aeroplane();
                
    public static void main(String[] args) {
        Toy toyInProduction = train;
                
        for (double numOfToys=0;true;++numOfToys) {
                                                
            if(toyInProduction.counter!=0 && toyInProduction.counter % 30 == 0){
                if (toyInProduction instanceof Train){
                    toyInProduction = aeroplane;
                    toyInProduction.increment();
                } else {
                    toyInProduction = train;
                    toyInProduction.increment();
                }
            } else {
                toyInProduction.increment();                                
            }
            
            if(toyInProduction.counter>=108){
                System.out.println("it took " + numOfToys/30 + " hours to create 108 trains!");
                break;
            }
        }
    }
}
class Toy {
    public int counter = 0;        
    public void increment() {
        this.counter++;
    }
}
class Train extends Toy {                
}
class Aeroplane extends Toy {        
}

Let’s talk about what’s going on there, if you skip the “SantaToys” class and focus on the last 3 classes within this little program: Toy, Train and Aeroplane, you will find an example of inheritance in OOP.

Toy is in a higher level of abstraction and both Train and Aeroplane are specializations of that base class, i.e., Train and Aeroplane are toys (duh). So the cool thing about Inheritance is that it organize the entities involved in a given context and facilitates the coding process.

The subclasses inherit the attributes and methods of the parent class, in this case, both Train and Aeroplane will have their own “counter” attribute and the “increment()” method, which means, the results of the increment method will affect only that specific instance, if we increment the counter for a Train object, that means the integer value within the counter variable will be incremented for this instance only (this is another aspect of OOP languages, they have mechanisms to refer to object instances, usually with keywords like this or self). Even if you call the method from a reference variable defined through an abstract class (Toy), the correct increment method will be determined during runtime, so it’s like having a Toy that can transform itself when some action is invoked, that’s what we call Polymorphism.

Polymorphism is achieved when you use an abstract reference of an object to invoke some functionality and, as a result of the mapping of the reference variable on the stack and the actual object’s instance in the heap, different methods will be executed. Refer to the toy analogy above if this one is too boring.

So, just for the fun of it, how about implementing the same in Javascript? 😀

var Toy = function() {
        this.counter = 0;
    this.increment = function() {
        this.counter++;
    }
}
var Train = function() {}
Train.prototype = new Toy();
var Aeroplane = function() {}
Aeroplane.prototype = new Toy();

var num_toys = 0;
var train = new Train();
var aerop = new Aeroplane();

var toy_in_production = train;

for(var num_toys=0;true;++num_toys) {
    if(toy_in_production.counter != 0 && toy_in_production.counter % 30 == 0) {
        if(toy_in_production instanceof Train) {
            toy_in_production = aerop;
            toy_in_production.increment();
        } else {
            toy_in_production = train;
            toy_in_production.increment();
        }
    } else {
        toy_in_production.increment();
    }

    if(toy_in_production.counter==108) {
        console.log("it took " + num_toys/30 + " hours to create 108 trains!");
        break;
    }
}

In Javascript, we don’t use the “extends” notation to define subclasses, instead we use prototypical inheritance to link objects in a hierarchy (there are other methods to achieve inheritance with Javascript, e.g., call() & apply() or object masquerading, but I prefer this one), in Javascript every object’s constructor has a ‘prototype’ property and, in cool browsers like Firefox and Chrome, you can see a property called __proto__ that is a reference to the prototype property of the object’s constructor, Czech this out!

If we link this property to a bunch of key/value pairs, we can inject new properties into an object but if we assign a new object to the prototype property, then the assigned object (Toy) becomes the “parent object” of the owner of the prototype property (instance of Train|Aeroplane), that’s because, when we invoke an object’s method, the Javascript interpreter will search for that method within the object itself, if it can’t find it, it will search for it inside the prototype and it will keep doing that until it finds the method (or just returns undefined), here’s an example:

Toy.prototype
Object {}
Toy.prototype.newFunction = function() { return "meh"; }
function () { return "meh"; }
train.newFunction()
"meh"

See what happened there? I have added a new function(method) to Toy and I have invoked the new function from the sub-object (train), Train doesn’t have the new function but its parent-object does, so the interpreter walked the Prototype Chain to find the method we were looking for.

Now that we understand inheritance with Javascript, the rest is pretty much the same, we can increment the specific instances of Toy through polymorphism and get to the result we want.

Now let’s move on to our final topic: Encapsulation.

Imagine an application that manages sensitive data from a group of People (e.g., Big Company or a Bank), we can write the following classes to accomplish this objective.

public class Test {
    
    public static void main(String args[]) {
        CarbonBasedLifeform joeBloggs = new CarbonBasedLifeform("Joe Bloggs", "987-65-4320");
        System.out.println(joeBloggs.name);
    }
}
class CarbonBasedLifeform {
    String name;
    String SSN;
    
    public CarbonBasedLifeform(String name, String SSN) {
        this.name = name;
        this.SSN = SSN;
    }
}

In this code we create a class called “CarbonBasedLifeform” and we created an instance, Joe Bloggs, now imagine that some other programmer is adding more stuff to the program and they start messing around with some of this data, what if they change Joe’s Social Security Number? Or even his name? We don’t have anything to protect the access to the attributes of the class, so it can be easily done:

joeBloggs.SSN = "0987654321";

If people could just modify each other’s documents and alter personal data like that, what an odd, disturbing world that would be. Joe is the only one that can go through the bureaucratic loops to get a new documents, this stuff is private, that’s why it is a common practice to add modifiers to the class attributes along with special methods to control the access to their values, i.e., the Getters & Setters:

class CarbonBasedLifeform {
    private String name;
    private String SSN;
    
    public CarbonBasedLifeform(String name, String SSN) {
        this.name = name;
        this.SSN = SSN;
    }
    
    public String getName() {
        return this.name;
    }
    public void setName(String name) {
        this.name = name;
    }
    public String getSSN() {
        return this.SSN;
    }
    public void setSSN(String SSN) {
        if(verifyRedTape())
            this.SSN = SSN;        
    }
}

Now, the other classes can’t change Joe’s attributes directly, because the attributes are marked as private and the methods provide a mechanism to control how other classes interact with this data, that is known as Encapsulation or, in other words, don’t touch Joe’s privates!

In this example, the value will only be modified after Joe verifies the red tape involving his Social Security Number:

joeBloggs.setSSN("0987654321");

BTW, C# offers an interesting approach to write the same in a less verbose way.

private string name;
public string Name
{
    set { this.name = value; }
    get { return this.name; }
}

With Javascript, things are not so simple because, as Douglas Crockford described: “objects are collections of name-value pairs”, so we can dynamically define any property to any object any time we want, one approach that can be used to hide the value of a variable is to use Closures:

var Person = (function () {  
    var SSN = "";
    
    function Person(name, SSN) {
	this.name = name;
	
        /* Preventing any changes on the SSN property */
	Object.defineProperty(this, 'SSN', {
            value: "",
            writable : false,
            enumerable : true,
            configurable : false
        });

        this.getSSN = function() {
            return SSN;
        };
        this.setSSN = function(ssn) {
		    console.log("Check red tape here");
            SSN = ssn;
        };
	this.setSSN(SSN);
    }
    return Person;
})();

When the object is instantiated, it executes the IEF (Immediately-Executed Function) and returns the inner “Person” function that holds a special reference to the variable SSN in the outer function (i.e., closure), this variable can only be accessed by the public methods within the object that is returned, so it simulates the behaviour demonstrated in the Java class.

var p = new Person("Marcelo","444");h 
Check red tape here 
undefined
var p2 = new Person("Joe","777");
Check red tape here
undefined
p
Person {name: "Marcelo", SSN: "", getSSN: function, setSSN: function}
p2
Person {name: "Joe", SSN: "", getSSN: function, setSSN: function}
p.setSSN("111")
Check red tape here
undefined
p2.setSSN("222")
Check red tape her
undefined
p.getSSN()
"111"
p2.getSSN()
"222"
p.SSN = "999"
"999"
p.SSN
""

In summary, the encapsulation is used to protect the data within an object and also to  manage the access to this data, although it is not recommended to blindly create getters & setters for all your objects without a good reason, it is a common practice in OOP and, specifically for Java, Object Relational Mapping (ORM) frameworks (e.g., Hibernate) rely on this coding convention in order to abstract the database interaction using the objects’ instances.

So that’s it for today, please share your comments below and let me know if you liked today’s post. Excelsior!

Nashorn and the JVM Monitoring Challenge – PART 2

Hello and welcome to the second part of the “Nashorn and the JVM Monitoring Challenge” series, we will continue our quest to unveil what kind of chaotic things we will see once the JVM starts processing the bytecode that is executing untyped dynamic languages.

Let’s start with some good news: You don’t have to follow the OpenJDK Build instructions to start playing with Nashorn anymore, it was finally integrated to an early build of the Oracle’s JDK 8, I haven’t tried myself (Still playing in Ubuntu 12 with OpenJDK 8) but it should be there.

So, let’s get started, the agenda for today is going to be:

1. Running a test script with the Nashorn Javascript engine
2. Understanding Invokedynamic (It should be helpful to dive more into what we are going to see later)
3. Monitor the JVM while running a Nashorn application

Running a test script

The Nashorn engine can be loaded in a Java class and then, with the instance of the ScriptEngine object, use the eval() method to execute Javascript code. Just write and compile the following class:

import javax.script.*;
public class EvalFile {
 public static void main(String[] args) throws Exception {
     // create a script engine manager
     ScriptEngineManager factory = new ScriptEngineManager();
     // create JavaScript engine
     ScriptEngine engine = factory.getEngineByName("nashorn");
     // evaluate JavaScript code from given file - specified by first argument
     engine.eval(new java.io.FileReader(args[0]));
 }
}

Once you have your ‘EvalFile’ class ready, create a dummy .js file just to give it a try, write something like:

print('Hello World');

Then you can execute this script like this:

java -cp nashorn.jar:. EvalFile dummy.js

In order to speed things up, I’ve created an alias to invoke the ‘jjs’ command-line tool so I don’t have to use this EvalFile class.

$alias jjs='/var/jdk8/openjdk8/nashorn/bin/jjs'

now, the .js file can be executed like this:

jjs dummy.js

Moving on, my test script here will only be used to explore how we can keep track of the chain of function calls and the number/size of objects that are being allocated into the JVM’s heap, if you really want to experience the power of Nashorn, you can refer to the official ‘Java Scripting Programmer’s Guide‘.

This test comprises two files:

— Model.js —

function Person(name, address, phone) {
    this.name = name;
    this.address = address;
    this.phone = phone;
    this.sayHello = function() {
        return "Hi, my name is " + this.name;
    }
}

— testNashorn.js —

#!/usr/bin/jjs
#
var Thread = java.lang.Thread;
load("./Model.js");
print("Welcome to testNashorn.js");
var people = [];
for(var i=0;i<100;i++){
    var p = new Person("Marcelo","Caucaia Street 17","+353 086 5555555");
    people.push(p);
}
//Lots of objects were allocated into memory at this point 
Thread.sleep(30000);
var myFunction = function(){
    var text = people[0].sayHello();
    print(text);
};
myFunction();

The first one (Model.js) is where I’m declaring my Person “Class”, 3 attributes and 1 meth.. sorry, function, the second file (testNashorn.js) is the actual program, it first transforms the Thread Java class into a Javascript variable, then loads the Model.js, i.e., runs the Javascript code inside that file and prepares our Person() function/constructor, it declares an empty objects array and enters a loop instruction that is going to create 100 objects in memory, after the ‘for’ loop, as I will need a second to trigger my script to generate a heap dump, I decided to add a ‘Thread.sleep(30000)’ there (30 secs is more than enough), once the program awakes, it declares a function (myFunction) that is going to print the value returned by the ‘sayHello()’ function from the first object stored in the ‘people’ array, this function is then called right afterwards.

Now, we can run the program:

jjs testNashorn.js

The output should be something like this:

Welcome to testNashorn.js
[30 sec pause]
Hi, my name is Marcelo

That’s it, we have our test script, let’s move on to the second topic.

Understanding invokedynamic

Ok, we already know that the Nashorn Javascript engine is 100% compliant with ECMA-262 5.1 and it is fully implemented with the new “invokedynamic” bytecode instruction, therefore, is faster and more compliant than Mozilla’s Rhino, but what’s invokedynamic?

Executing Java code is not the JVM’s solely purpose, every Java code is compiled into bytecode and this is the piece that gets consumed and processed by the JVM, if a programming language can be compiled to bytecode than its instructions can be interpreted by the JVM (e.g., Closure or Scala). The bytecode is an efficient simplified form of non-human-readable code that is executed closer to machine-level instructions, i.e., better performance.

The JVM has approximately 200 “opcodes” to perform invocation of instructions, handle access to fields and control objects and arrays. The following table presents the types of invocation bytecode operations that were available before JDK version 7:

Opcode	Usage
Invokestatic	For static methods
Invokevirtual	For non-private instance methods
Invokespecial	For private instance
Invokeinterface	For the receiver that implements the interface

A simple invocation to a method starts from a given “Call Site”, which is from where the request is initiated; it is assembled with the name of the method, the signature (access level, modifiers and return type) and the arguments that are processed by this method, the JVM will process this Call Site information and go through a set of operations: It is going to look for that method’s code within memory (Lookup), check if the types involved in the operations match (Type Checking), invokes the actual code (Branch) and then caches the location of that method so, if it is going to be needed again soon, the JVM already knows that memory address and speeds up the process (Cache).

The new “Invokedynamic” bytecode operation allows the JVM to customize how the resources for the Call Site are assembled (dynamically) and also perform a different set of operations within the JVM so the field or method can be accessed (invoked). Instead of the regular Call Site, it integrates bytecode (invokedynamic operation with name and signature) with a bootstrap method, this is the component that will connect the Call Site with the “Method Handle”, once the handle finds the correct way of making this invocation occurs, the JVM will optimize the operation and the invokedynamic bytecode will be attached to the “Target Method” to avoid processing all these steps again. In a scenario where a scripting language that is running within the JVM needs to access a specific function, it is going to initiate the process by providing the bootstrap method with the invokedynamic instructions (name of the function followed by arguments and the return type), the JVM will look for the function within a Method Table (list of functions that are not associated to any object or class) based on the arguments that are defined at runtime (Lookup), once it finds the function, it will perform some language-specific type checking (Type Checking) and then it will finish the bootstrap process connecting the Call Site with the Method Handle so it can be executed (Branch), this connection is performed only once but Call Sites can be connected to new Method Handles.

If you want a more in depth explanation, I strongly recommend this blog post here:

http://niklasschlimm.blogspot.ie/2012/02/java-7-complete-invokedynamic-example.html

Monitoring the JVM while running a Nashorn application

We have reached the last part today’s post, it’s time to diagnose the Rhinoceros (or… at least, try).

Let’s start with some Thread Dumps: if we run our testNashorn.jjs and take a few thread dumps (using the instructions documented in our previous post), this is what we get once we load them into our Thread Dump analyzer:

That’s it, say goodbye to the good-old readable stack trace. On this first analysis we reinforced once more how this change of paradigm will affect the way Java Performance Analysis and Troubleshooting is done nowadays, the chain of execution presented on the stack trace of the “Main” thread resembles bytecode instructions, the best clue to easily identify what initiated each set of instructions is the name of the Javascript file that is declared in the “jdk.nashorn.internal.scripts.Script” class (it can be found at the bottom of the stack trace), there are some familiar things there like the JVM native and internal threads but the rest got pretty cryptic for me.

So, what’s our alternative? As far as I know, there isn’t any. We can only use some arguments to run the program and get some debug data that is supposed to give us some clues as to where the calls are coming from, but it is not very clear. I believe that, if we grok the concepts behind ‘invokedynamic’, we can use the “–print-code” Nashorn argument and produce some debugging output that can be interpreted based on the dynamic calls that are generated by the Nashorn engine:

We can also get more verbose results with the following command:

jjs -Dnashorn.debug=true -Dnashorn.methodhandles.debug.stacktrace=true --log=codegen:info testNashorn.js

What if the program hangs during the execution of a particular function? Under the development phase is pretty easy to just attach a debugger and step through the function calls but what if we are troubleshooting something in the production environment? I’m not sure if we have a valid alternative to that, if you have any ideas, please share on the comment section below.

What about Heap Dumps? Let’s see what we get when we take a Heap Dump during the execution of our testNashorn.js script:

Yep, it also got a little weird here. Since we don’t have packages and typed classes, there’s no way to easily track down where are our “Classes” and the number/size of objects associated to them, I did some investigation and found this “jdk.nashorn.internal.scripts.JO” object that apparently serves as a wrapper to the objects created through Javascript functions, the downside is that it doesn’t separate the objects based on its “Class” (at least I didn’t find any parameter that pointed me anywhere near the “jdk.nashorn.internal.scripts.Script$Person” object), so if you have 100 instances of ‘Person’ and 100 instances of ‘Car’, they will be mingled in this sea of ‘JO’ instances (I haven’t tested other object forms yet, e.g., Object Literals; not sure if we would see something different). So, how do we easily keep track of the size of objects created from a given function()? Well, we could rely on the format of the attributes and play with OQL (Object Query Language) and isolate a given set of objects to determine how much space they are taking up, but that’s just messy. Currently, there are a few DEBUG parameters documented in “$OPENJDK8_HOME/nashorn/docs/DEVELOPER_README“, some of them are quite interesting and might provide the answers we need, e.g.:

print(Debug.map(p));
print(Debug.dumpCounters());

Now, to conclude this post, I leave you with a message from Jim Laskey, this is one of the replies that he sent me when I was questioning his team about these concerns:

“The next round of development will be focusing on tools, so what you are trying to accomplish will get easier. You have an opportunity to provide us guidance on this…. Stack crawls will get better once we start working on debugging APIs.”.

So there you have it, if you are interested in contribute to these debug APIs I hope this post can provide some guidance and/or raise awareness on the difficulties that we might face in a near future where we will be troubleshooting Nashorn-based enterprise applications.

Good Nashorning everyone! 😀

Nashorn and the JVM monitoring challenge – Part 1

 

Before we start Nashorning, I would like to contextualize what I’m trying to do here, I was curious about what kind of data we would see while monitoring a JVM executing the Nashorn Javascript engine, considering the deep technical details behind these untyped dynamic chaotic scripting languages, we should see something interesting, right? So, moved by curiosity, I’ve downloaded the OpenJDK 8 to start playing with Nashorn and dig more into that. I will share the results of my research but first, let’s talk about how JVM monitoring is done today.

 

—

 

Why do we monitor the JVM? Two reasons: Performance & Benchmarking.

 

Performance: What if your application is slow? Hanging? Is it crashing all of a sudden? Is there some specific event that freezes the entire system for a moment? Yeah.. you must find the root cause of this bottleneck, but how? Don’t worry, I will present a few tools/commands and share a bunch of vague conjectures to leave you even more confused some cool info to get you started on this amazing world of the JVM Monitoring, are you psyched?

 

Benchmarking: That’s when you take note of a given set of statistics that were generated while monitoring the system was being monitored and then you can use this report to compare how things change over time, i.e., after new patches, releases, etc. It’s an interesting way to avoid being caught with your pants down, if the system is changing over time you need to check if the resources you have will handle the work load.

 

I want to cover 3 things today:

1) Thread Dumps

2) Heap Dumps

3) Profilers

 

Cool, now… let’s see some code, shall we?

 

Thread Dump analysis

 

import java.io.BufferedInputStream;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
public class TestRaceCondition {
    public static void main(String[] args) {
        for (int i = 0; i < 10; i++) {
            new MyFileReader().start();
        }
    }
}
class MyFileReader extends Thread {
    public static int num = 0;

    public void run() {
        try {
            BufferedInputStream reader = new BufferedInputStream(
            new FileInputStream("/home/themarcelor/someFile.txt"));
            readThisFile(reader);
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        }
    }
    public static synchronized void readThisFile(BufferedInputStream reader){
        try {
            while (reader.available() > 0) {
                System.out.print((char) reader.read());
            }
           System.out.println(num++);
           Thread.sleep(20000);
        } catch (IOException e) {
            e.printStackTrace();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

 

This code is going to create 10 threads and read the contents of “somFile.txt”, you can easily create a dummy file somewhere in your machine and adapt the code to read its lines, now.. let it create a few threads and then let’s take some Thread Dumps.

 

Questions: Why are we doing this? What is a Thread Dump?   Answer: We are doing this to illustrate how a multi-threading program can, sometimes, face a situation where a given resource will be ‘locked’ by another activity or it won’t be available due to external factors, e.g., a number of connections were borrowed from a JDBC Connection Pool and the database can’t accept any more connections, there will be several threads/transactions waiting on the queue to be processed (just like our threads that will be waiting to read ‘someFile.txt’), that might slow down some activities in your system.   A Thread Dump is like a picture of whatever is going on inside the JVM, it’s a full report of all the Java objects/classes that are being executed at that specific moment, i.e., a bunch of stack traces containing the state of the threads along with information about locks.

 

Now, let’s create a small script to generate Thread Dumps:

 

#!/bin/sh
SLEEP=$1
PID=$2
while : ; do
  date
  kill -3 $PID
  sleep $SLEEP
done

 

This can be executed like this:

 

./takeThreadDumps.sh 5 4321

 

It is going to trigger the SIGQUIT signal against the Process Identifier (PID) 4321 every 5 seconds, it’s interesting to take multiple thread dumps because it help us analyze what happened within a given time-frame, we can identify what has been running for the last 10, 15 or 20 seconds, if some ExecuteThread: ’16’ that is processing some DB activity (e.g., oracle.jdbc.driver.T4CXAResource.doRollback (T4CXAResource.java:648) ) is showing up in 2 Thread Dumps that were taken in the interval of 10 seconds, something strange is going on.. you better call the DBA.

 

Yes, that’s for linux users, if you are a Windows user ( 😦 ) then you can run the Java command through your DOS prompt and hit [Ctrl] + [Break] to manually generate Thread Dumps, but it’s best to just use a command-line tool called ‘jstack’, it’s OS-independent, e.g.:

 

$JAVA_HOME/bin/jstack [PID] > td.txt

 

If you open one of these Thread Dump files, you are going to see something like this:

 

2013-05-22 12:30:43
Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.7-b01 mixed mode):
“Attach Listener” daemon prio=10 tid=0x00007fddec001000 nid=0x491d waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
“DestroyJavaVM” prio=10 tid=0x00007fde04009000 nid=0x48dc waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
“Thread-5” prio=10 tid=0x00007fde04221000 nid=0x48ef waiting on condition [0x00007fdde36e6000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at MyFileReader.readThisFile(TestRaceCondition.java:40)
– locked <0x00000000db9c5f20> (a java.lang.Class for MyFileReader)
at MyFileReader.run(TestRaceCondition.java:28)

 

It’s perfectly possible to analyze the file without any tools, or even write some code to ‘squeeze’ the long running threads throughout a given set of Thread Dumps files, however, some tools can speed up the process by organizing the data to make it easier for our eyes, for that, I recommend a too called ThreadLogic. Here’s a screenshot of its interface loaded with a Thread Dump from our ‘TestRaceCondition’ program:

 

 

So, as you can see, it categorizes the threads to facilitate the analysis, e.g., a useful command there can be found under “tools > Find long running threads…”, I won’t dive too much on its features as it’s pretty intuitive.

 

Now, about the Thread Dump Analysis: If you are a Java programmer, all this stuff will be processed by your brain naturally as you already understand Java Threads concepts, such as: synchronized, ‘Wait() & notify()’, sleep(), etc. If you are not a programmer, well.. I personally believe that every IT professional should strive to master two pillars: Code and Infrastructure, I know many programmers that hate network, server stuff and many systems engineers that hate programming, this has to stop. Anyway, let’s not digress on this philosophical matter,  if you are not a programmer and want some rules of thumb I only have one for you: Look at the monitors.

 

Imagine the JVM monitor as a supervisor of a construction site, 3 guys need to dig a ditch but they only have one shovel, so they need to take turns (synchronized), the first one grabs (locks/acquire the monitor) the shovel (resource) and the supervisor makes sure that they don’t make a mess and try to do the same thing at the same time (corrupt resource), when the worker gets tired he drops the shovel (release) and call the next guy (notify) that was waiting (wait, duh), some of them can take a nap (sleep) and some of them might wish to keep digging until they finish their part of the job and then allow someone else to take over (join). I hope you got the gist, here’s an image to illustrate this pathetic analogy (yeah.. that thing on the right-side it’s a monitor).

 

 

Now, based on these concepts that you learned here, check the Tread Dumps again and share your impressions in the comments section, even better, share your personal experiences with Thread Dump analysis, I bet everyone would find this interesting.

 

Heap Dump analysis

 

Heap Dumps are ‘snapshots’ of heap usage, i.e., tables of data indicating how many classes/objects are loaded, how much memory the classes/objects are using and what references they have between each other, these Heap Dump files store information in a very specific format and can only be visualized with Heap Dump Analysis tools, e.g., “Eclipse Memory Analyzer” or “IBM HeapAnalyzer”.

 

This post is getting quite lenghty so I’m glad I have a bunch of other posts ready to cover this section:

 

• JVM & Garbage Collection
• Main Garbage Collection Algorithms
• Permanent Generation
• Garbage Collection logs
• Young Generation
• Out Of Memory Errors and Heap Dumps

 

Profilers

 

Here is where we do the real monitoring, the recording and analysis of the JVM’s internal data is done through a set of tools called ‘profilers’, Profiling is a mechanism whereby one of these tools connect to the JVM through the Java Virtual Machine Tool Interface (JVMTI) to retrieve information about cool JVM stuff, like Threads  and Memory (heap) usage.

It also allows a system administrator to send commands to Managed Beans through Java Management Extensions (JMX) methods.

Ok, let’s get down to business, run your java program with the following JVM arguments:

 

java -Dcom.sun.management.jmxremote.port = 9080 -Dcom.sun.management.jmxremote.authenticate = false -Dcom.sun.management.jmxremote.ssl = false TestRaceCondition

 

Now you should pick your Profiler, there are many implementations that work with JVMTI, here are a few options:

• JRockit Mission Control
• Visual VM
• JConsole
• Eclipse TPTP

 

JRockit is my favorite (which should be replaced by Java Mission Control soon), the interface is very practical and it’s full of features (Czech out the video!), Visual VM is simpler but has a cool GC log viewer plugin, I’m not a big fan of jConsole but it’s shipped with older versions of the JDK so it might come in handy, Eclipse TPTP gives that feeling of working within the same space, which is good but you will need to download too many things to start using it (it’s pretty cool though), in summary: they’re all awesome! It depends on your mood.

 

—

Ok, that’s it for today, in the next part of the “Nashorn and the JVM monitoring challenge” series, we will learn more about ‘invokedynamic’ and the bizarre results that we get when we try to monitor/troubleshoot Nashorn-based applications.

 

Cheers!

Musings about Nashorn

The Nashorn Javascript engine that will be integrated in the JDK 8 may be, in a near future, the technology that will serve as a foundation for a wide range of enterprise solutions, the increasing adoption of the Javascript language for unorthodox practices, such as, server-side programming, is now a strong topic of discussion among developers, I had the opportunity to attend to Brazil JS in Fortaleza (CE, Brazil) back in 2011 and the whole thing seemed like a Fashion Show to me. Until that event, I didn’t have the chance to experience any of that during my life as an IT professional so I felt like I was just looking at a bunch of crazy trends:

My favorite presentation was the one entitled, in portuguese, “Javascript por debaixo dos panos” (which would be something like: Javascript “under the hood” or “behind the curtains”, you got the idea), Douglas Campos was the only one that mentioned the usage of well-consolidated Java libraries within Javascript engines running within the JVM, I didn’t know about Nashorn back then but the idea of reusing the wheel sounds very attractive, I noticed the giggles around me while he was talking about it, because the f*ing hypsters created a bias towards Java, or …Jabol, since some of them were referring to it as the new COBOL. Yeah… we have a complete redesign of GC, Project Coin, NIO, Lambdas and there are people that still feel that Java is not evolving. Lexically, perhaps, not that much, but the platform itself have a lot to offer and I believe the multi-language paradigm is yet to show its true power.

So, why Javascript?

• It’s … “easy” to use (if you are not using its true syntaxic power): If you ever did some web programming you know the basics to start writing some code and it offers a wide-range of “IDEs”, any Notepad++, Emacs, TextMate or Eclipse is enough to get you started.
• It’s easily extensible with Object-Oriented-Programming features and prototyping: There are many frameworks that you might have used, e.g., JQuery, Dojo, it’s interesting to see the power of the language when you have a chance to dive in some of their functions.
• This last bullet point might seem a little bit subjective but It is naturally bond to the Web: Javascript was created to work with web pages, it was integrated with all browsers, had its engine redesigned by Google (yep, the famous V8 JS Engine), it allowed Microsoft to create something that didn’t crash with a blue screen of death (AJAX) and, in more “recent” developments, has been used in a famous implementation of server-side Javascript, Node.JS.

In summary, studying Nashorn is very fun: exploring the technology, downloading/building the openJDK, running the samples, writing my demo application to test JVM monitoring and, specially, annoying Jim, Marcus and Attila throughout the process.

Yeah, that’s it for today. Stay tuned for more posts about Nashorn.

Nashorn Talk in Brazil!

Since its creation in 1995, the Java platform is constantly revolutionizing the paradigm of Software Development technologies. When everyone wanted to use a robust server-side language that could run on the client-side, the Applet was created to attend this demand, when all the Common Gateway Interface (CGI) scripts (e.g., Perl) were presenting scalability issues, the Servlets were created to work as a single-process multi-threaded solution to server-side data processing, then the industry was flooded with Application Servers, Web Services technologies and Middleware Solutions that gave more power to the Java Enterprise Edition (J2EE) platform, many services, libraries, frameworks and Application Programming Interfaces (APIs) were created and even inspired other technologies that were implemented for other languages (e.g., NHibernate and Log4Net libraries created for the .NET platform), the necessity to reuse these well-consolidated libraries allied with the advent of dynamic scripting languages like Python, Ruby and specially Javascript culminated in a point where new technologies had to be created to accommodate this integration: Jython, JRuby and Mozilla’s Rhino Javascript engine that is executed within the Java Virtual Machine (JVM) itself.

To organize these initiatives, in 2006, the Java Specification Request 223 (JSR-223), entitled as “Scripting for the Java Platform”, was created to allow the execution of scripts on the server-side JVM. Later in 2008 Sun Microsystems, before its acquisition by Oracle, created the “Da Vinci Machine Project” to develop support for dynamic languages on the JVM. Then, in November of 2012, Oracle announced the Nashorn open-source project as part of the OpenJDK. Nashorn is going to replace Rhino as the official Javascript Engine for the JVM that will be shipped with the Java Development Kit version 8.

I had the opportunity to give a talk about this new technology in an event from Brazil’s most prestigious JUG, the “Ceará Java Users Group” (CEJUG), the “Coffee with Tapioca” happens every 2 months and gathers a large number of active members with usually two speakers per event, I had the pleasure to meet Helio Frota, Roberto Coelho, Paulo Junior and the other speaker, Guilherme Bahia (Czech out his game!), that gave an amazing presentation about Android Game Development. Everyone got very interested in hearing more about Nashorn, perhaps that will be the beginning of an evangelization saga.

Since Javascript is becoming more and more strong in the software development world, either for its simple syntax or dynamic features, the adoption of Nashorn-based enterprise solutions can become a reality soon, based on this fact, more study is necessary on how this change of paradigm will affect the way Enterprise Performance Monitoring is performed.

I will prepare more posts related to Nashorn within the upcoming weeks.

Cheers!