The Blog-Health-o-Meter™ reads Wow.

Crunchy numbers

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 8,600 times in 2010. That’s about 21 full 747s.

In 2010, there were 28 new posts, growing the total archive of this blog to 71 posts. There were 34 pictures uploaded, taking up a total of 10mb. That’s about 3 pictures per month.

The busiest day of the year was December 6th with 941 views. The most popular post that day was Questions you should ask your interviewer.

Where did they come from?

The top referring sites in 2010 were dzone.com, jroller.com, facebook.com, stumbleupon.com, and en.wordpress.com.

Some visitors came searching, mostly for c++ bool “== true”, netpace, java 7 automatic resource management, who has the biggest brain swf, and secure code.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

Questions you should ask your interviewer December 2010
7 comments

How to write Secure Java Code October 2010
15 comments and 2 Likes on WordPress.com

How websites handle multiple users simultaneously? October 2010
5 comments

Why Double Checked Locking is flawed October 2010
20 comments and 1 Like on WordPress.com,

QA Friendly Java Profiler November 2010
1 comment

It is just a rant about how not to conduct an interview and also realize that interviews shouldn’t be taken lightly especially when it comes to interviewing a senior person. Anyways here goes the story…

Once upon a time in there was a Oracle Financials person (yea I would call him person) was given the task to develop a Oracle Financials for a Customer in Java. Without showing any concerns the person went on to find Java resources from the local market. He was referred different people and was so excited about developing the team that he didn’t even reviewed the resumes forwarded to him and just went on calling people for the interview. Again in excitement he didn’t even care to send out official emails for interview schedule and company address etc.

Anyways the process went on and a senior resource was called for the interview. Here comes the interesting part of the story – the actual interview conversation:

Q: So how are you? Did you have any problems finding our office?
A: Hi, I am very good. Yes, I did had problems finding the office. There is no board identifying the office. (The only landmark near the office is actually a vegetable shop and a burger shop) Anyways I am here.

Q: So can you tell me about your experience?
A: Yea, I am working on JEE for past N years and have worked on these many technologies…

Q: (Interrupting the interviewee) You haven’t worked on Eclipse?!?!
A: (Thinking why is he asking for the IDE?!?!) Yes I have worked on Eclipse. It is basically a RCP but the biggest reason for its fame is as the premier Java IDE. But you can use any IDE if you are talking about it as an IDE. Its up to the user/developer what IDE he wants to work on as almost everyone has its own preferences.

Q: So you worked in this company as well?
A: Yea, I worked there as a [Job Title] and worked for N years. Major responsibilities were…

Q: (Again Interrupting) Did you know this guy there? He worked as [his Job Title]
A: While I was there he wasn’t there. I guess he joined after I left. (Thinking either this guy is totally dumb or hes really smart as this was a good attempt to verify if I actually worked there or not)

Q: So why are you looking to switch from your current employer?
A: (Amazed – anyways till this time it was clear that this guy is dumb) I think you guys called me for a discussion. Anyways basic reasons for any switch are:
1) Learning Opportunities.
2) Growth.
3) Monetary benefits.

Q: So how much are you earning?
A: My basic salary is this much and I am entitled to these benefits.

Q: Actually we are looking for a Software Engineer…
A: (Totally shocked and angry at the same time) Wait. Did you had the time to check my resume? I am not interested in joining as a Software Engineer. I would like to tell you somethings that should have been followed so that the waste of time that is going on here wouldn’t have happened. The standard process is to send an email and tell the person that you are hiring/interviewing for this position so that there isn’t a waste of time. Here the interviewer started to give all sort of reasons of why he wasn’t following the procedure and started to blame different people. Oh – wow so you are blaming your own team that they don’t do what they are supposed to do. Just imagine what he would have been saying after hiring. This is definitely a NO in the interview process – Never do that in front of the resource you are hiring. Tells a lot about your personality.

Q: If you have any questions I am here to answer.
A: (Thinking although this was a total waste of time anyways lets ask about the business and his experience – never waste an opportunity) Yea, I have many. Heres the conversation:

Q: Please tell me about the products and business are of the company?
A: We are in Investment Banking. We provide support for banks in this area.

Q: Which part of Investment Banking are you guys in and are there any plans to grow/enter in any other areas?
A: We are in every part of Investment banking. We are hiring for a project where the customer wants us to develop (the already developed product) in Java. Proudly saying We say Yes to everything the customer says.

Q: So actually customer is deciding what the company does?
A: Yea, it is the Customer who takes decision.

Q: How much experience do yo have? Can you please give a brief introduction of yourself.
A: I have 12+ years of experience in Oracle Financials. And I worked in this this this countries before coming back here.

Q: How much experience in Java?
A: None. I have never worked on Java (feeling very proud about this statement)

Q: So who is the Architect of this Application?
A: The Guy in front of you.

Closing remarks by the interviewee – So you are the Architect of an application in a technology that you haven’t worked on. This answered all the questions as to why he was very concerned about using Eclipse. As he himself has no idea of Java so he thought Eclipse was Java.

I guess this was it. This Guy Infront of You answered every question asked and completely silenced that interviewee. Good work on that

1. Always try to eat the credit of others. And obviously if you are lucky this news will get to the people whos credit you ate. When this happens make sure that you try your best to convince them that what a good job they did and how impressed you were by their efforts.
   But make sure that you don’t have to appreciate anyone on writing and keep these discussions off the records i.e, written emails, letter of appreciations are not appreciated at all.
2. Pay them as low as possible. When they come crying that their salary is not even comparable to their peers in the market convince them that they are working on a very unique project and they won’t be able to find anything similar in the market. If that doesn’t work tell them that it is always bad to take money as the motivation factor and working for money won’t get them high up the career ladder.
3. Last but not the least. Whenever they make any mistake make sure that you told this to them – yea that is a good thing – but theres a twist here. Don’t tell this to them in Person, pinpoint them in front of everyone so that every other person also knows that mistakes are not appreciated here.

These are just the starting points but I am pretty sure that these will do the job more often then not. Feel free to share thoughts, suggestions and share the Golden rules you have come across to make this the ultimate Golden List for making the lives of the Employees a living hell.

In such situations the interview is the best possible source for information. Good interviewers always takes candidate’s question and answer these honestly. So one should not waste this opportunity, you must be 100% sure about the company you are applying for as you will be spending a part of your life there so never take these decisions light heartedly. I have compiled a set of questions that should always be asked in order to judge how good the company is. Since I am a developer (Technical Architect to be exact) these questions are mostly related to development processes.

Inquire if the company has presence in other countries? and if they have any development centers else where?
This tells if the company believes in offshore model or not. Off shoring is done to reduce cost and shows good business sense. But there are exceptions. Some company’s just have marketing offices in other countries, in any case you need to be sure that you are going to get constant work in future or in other words is there are any chance of your work getting off-shored or not.

If the company has more than one development centers and you happen to be applying for the one than make sure that you ask about the presence of the CTO or any of the owners at the place where you are applying.
The answer to this tells a lot about the amount and type of work you are going to get. If there is a presence of the CTO in your part then it shows that they are serious about developing/growing this offshore center. If there is no presence then you are done. Mark my words, no matter how good this job sounds you won’t have interesting work to do or in other words you won’t be involved in mission critical tasks. Most probably your job description will be (obviously not written on your offer letter – these things are written between the lines) a bug fixer or trash cleaner The main reason why I am saying this is because all the decisions will be made in other part of the world and since you are not there you won’t be part of these meetings and analysis sessions.

There are exceptions as properly managing the offshore model needs a lot of time from these decision makers. But most of these people are not that good at it. They start off with the offshore model to save cost but as soon as they have secured some good investment they don’t pay much attention to it and in the end the team at that center is orphaned and there is not much charm in that job.

Inquire about how much involved is CTO/Executives/Directors in the code i.e., do they actually write code?
The answer shows how much they trust the team. Just imagine that CTO/Executive/Director wrote some code which is based on some assumption which in the near future is not going to hold true or in short doesn’t qualify as good code. Just imagine how hard it will be to change that code. Sometimes the whole framework or basis of the product is written by them. These frameworks/code sometimes contain some basic flaws and it takes nerves of steel to propose changes in such pieces of code. First the code is written by the CTO and if you propose a change in his code that suggestion is taken personally (there are exceptions but usually that is not the case) and you cannot imagine at what level he is going to go to protect his code from getting wiped out. I usually call this as the married to code syndrome. So make sure that the CTO/CEO of company you are targeting are not affected by that syndrome.

How does the company manages the offshore development?
Do they have separate offshore managers? What about the meetings?
Are the developers in the offshore center involved in the analysis phase of the development?
Where are most of the customers situated?
It is not easy to get the answers right during the interview and most of the time you find the real answers only after joining and this is pretty late. In my opinion it is best to ask these questions straight away and you can come to the conclusion by comparing the answers with the answers of you previous questions. If the CTO is very much involved in coding phase then there is not much of the analysis phase in the offshore center. If the customers are also far away from the offshore center then also, you are not going to get much customer exposure. If there is a 12–hour time difference between the offshore center and where the owners are then there is very high chance that there aren’t going to many meetings. As the owners (CTO/managers) will have to take pain in staying up late for you so that you can understand the requirements and come up with a quality solution. Usually this never happens and the offshore center is merely a bug-fixing department and nothing else.

I think these are some of the most important questions that you should ask the interviewer and take your decision accordingly as you future depends on it.

Here are some of the videos of the Parks:

From natural areas with native flora to picnic areas and highly sculpted horticulture masterpieces, Niagara Parks has it all. The diverse plant collections number in the thousands and the Park provides a fitting backdrop for the beauty of the Falls.

As I was stepping through the code using the eclipse debugger i found a call to a method getUniqueName() which was taking a hell of a time to return and the CPU was going mad while I was waiting for the call to return. Inside the method I found this beautifu piece of code that I would like to share with everyone. Here is the master piece:

private String getUniqueName(String baseName, BranchObject newBranch)
{
    String retVal = baseName;
    IBranchLink [] branches = m_javaCommand.getUtilBranches();

    for (int iCheck = 1; iCheck < Integer.MAX_VALUE; iCheck++)
    {
        for (int iBranch = 0; iBranch < branches.length; iBranch++)
        {
            BranchObject branch = (BranchObject)branches[iBranch];
            if ((newBranch != branch) && branch.toString().equals(retVal))
            {
                retVal += iCheck;
            }
            else
            {
                break;
            }
        }
    }
}

The purpose of the code was to search for a unique name to be given to the object that was created wnen the save button was hit on the swing window. For example if the base name is Image then this code will search out the objects to see if there is any object named Image if yes then it tries Image1 and then Image2 until it finds a unique name. Altough the code above doesn’t do this but there is one obvious mistake in the code.

I have fixed the problem but lets see if anyone out there can find the most obvious mistake in the code which was trying was driving the CPU crazy?

public void fillSlots(String s, ScriptEntity.ScriptEntityType t, int startHour, int startMinute, int frequency)
{
    frequency = frequency / MINUTES_IN_ONE_HOUR;
    if (frequency == 0) {
        return;
    }

    int iX = startMinute / MINUTES_IN_ONE_SLOT; 
    // X index: 0 minute -- iX (0); 15 minute -- iX (1);
    // 30 minute -- iX (2); 45 minute -- iX (3).
    int iY = startHour % Y_INDEX; // Y index

    for (int i = iY; i < Y_INDEX; ) {
        fillSlot(s, t, iX);
        i =+ frequency;
    }
}

Hint: Infinite loop !!!

I was having a discussion with the QA manager about this and I was asked to recommend JProfiler to the management so that a license could be acquired. To be frank I am not a very big fan of JProfiler. I usually don’t go with these commercial profilers unless the tools available with the JDK are simply not enough – which is rare. Even in that situation I use the YourKit Java Profiler. This is when I was asked “Is it QA friendly?“

Well, this seems to me a wrong question because:

• The profilers are never QA firendly as their target audience is never QA people, they are meant for the developers as its the developers who have written all the code and they who know their code the best and can put all the information to good use that the profilers produce.
• Since the developers know how their code works they know what to profile and what not to profile. Profilers usually make the product slow and it really helps if you know what to profile. As you you don’t waste a lot of time waiting for the test case to complete and analyzing results.
• QA generally regards everything as bug, if the profiler produces a dump having tons of byte[] than QA files this as a bug/root cause of the load issues. But in fact this can be wrong. And developers have to find out the root cause by themselves and it turns out that they end up wasting time finding the root cause of a problem which never existed.

So in my opinion all these activities should be left to the developers and the QA should act as a helping hand in these scenarios coming up with a reproducible test case that the developrs can use to find out the root cause be it using profilers or reviewing the code.

Before moving forward lets first talk about what is Double Checked Locking. To understand where the double-checked locking idiom originated, you must understand the common singleton creation idiom, which is illustrated below:

import java.util.*;
class Singleton
{
  private static Singleton instance;
  private Vector v;

  private Singleton()
  {
    v = new Vector();
    v.addElement(new Object());
  }

  public static Singleton getInstance()
  {
    if (instance == null)          //1
      instance = new Singleton();  //2
    return instance;               //3
  }
}

The design for this class is suitable for single thread usage but when it comes to multi-thread usage. Since threads can get preempted we can have multiple instances of Singleton object. The solution is to protect the getInstance() method through synchronization as shown below:

  public static synchronized Singleton getInstance()
  {
    if (instance == null)          //1
      instance = new Singleton();  //2
    return instance;               //3
  }

This code works perfectly fine for multi-threaded access to getInstance() method. But if you look at the code deeply, synchronization is required only once, when the variable is initialized. Rest of the time there is no need for synchronization and hence we get the synchronization overhead for other threads since the whole method is synchronized.

In an effort to make this method more efficient (avoiding the synchronization on common, the read path) an idiom called Double Checked Locking was born. The idea is to avoid the costly synchronization for all invocations of the method except the first. The cost of synchronization differs from JVM to JVM. In the early days, the cost could be quite high. As more advanced JVMs have emerged, the cost of synchronization has decreased, but there is still a performance penalty for entering and leaving a synchronized method or block. Regardless of the advancements in JVM technology, programmers never want to waste processing time unnecessarily.

Here is how DCL is implemented:

public static Singleton getInstance()
{
  if (instance == null)
  {
    synchronized(Singleton.class) {  //1
      if (instance == null)          //2
        instance = new Singleton();  //3
    }
  }
  return instance;
}

The theory behind double-checked locking is that the second check at //2 makes it impossible for two different Singleton objects to be created and we also avoid the synchronization overhead for the most frequent read path by check at // 1.

The theory behind DCL is perfect but reality is entirely different. The problem with double-checked locking is that there is no guarantee it will work on single or multi-processor machines. The issue of the failure of double-checked locking is not due to implementation bugs in JVMs but to the current Java platform memory model. The memory model allows what is known as “out-of-order writes” and is a prime reason why this idiom fails.

What is out of order writes?

To illustrate the problem, you need to re-examine line //3 from the code above. This line of code creates a Singleton object and initializes the variable instance to refer to this object. The problem with this line of code is that the variable instance can become non-null before the body of the Singleton constructor executes.

Before explaining how this happens, accept this fact for a moment while examining how this breaks the double-checked locking idiom. Consider the following sequence of events with the code above:

• Thread 1 enters the getInstance() method.
• Thread 1 enters the synchronized block at //1 because instance is null.
• Thread 1 proceeds to //3 and makes instance non-null, but before the constructor executes. Thread 1 is preempted by thread 2.
• Thread 2 checks to see if instance is null. Because it is not, thread 2 returns the instance reference to a fully constructed, but partially initialized, Singleton object.
• Thread 2 is preempted by thread 1. Thread 1 completes the initialization of the Singleton object by running its constructor and returns a reference to it.

These sequence of events results in a period of time where Thread 2 returned an object whose constructor had not executed. To show how this occurs, consider the following pseudo code for the line: instance = new Singleton();

mem = allocate();             //Allocate memory for Singleton object.
instance = mem;               //Note that instance is now non-null, but
                              //has not been initialized.
ctorSingleton(instance);      //Invoke constructor for Singleton passing
                              //instance.

This pseudo code is not only possible, but is exactly what happens on some JIT compilers. To prove the point I am showing a stripped down version of getInstance() method and its assembly code.

class Singleton
{
  private static Singleton instance;
  private boolean inUse;
  private int val;

  private Singleton()
  {
    inUse = true;
    val = 5;
  }
  public static Singleton getInstance()
  {
    if (instance == null)
      instance = new Singleton();
    return instance;
  }
}

Here is the assembly code for the above code:

;asm code generated for getInstance
054D20B0   mov         eax,[049388C8]      ;load instance ref
054D20B5   test        eax,eax             ;test for null
054D20B7   jne         054D20D7
054D20B9   mov         eax,14C0988h
054D20BE   call        503EF8F0            ;allocate memory
054D20C3   mov         [049388C8],eax      ;store pointer in
                                           ;instance ref. instance
                                           ;non-null and ctor
                                           ;has not run
054D20C8   mov         ecx,dword ptr [eax]
054D20CA   mov         dword ptr [ecx],1   ;inline ctor - inUse=true;
054D20D0   mov         dword ptr [ecx+4],5 ;inline ctor - val=5;
054D20D7   mov         ebx,dword ptr ds:[49388C8h]
054D20DD   jmp         054D20B0

For those who are not hands on Assembly language here is a summary of the code sequence:

• The first two lines of assembly code at B0 and B5 load the instance reference from memory location 049388C8 into eax and test for null. This corresponds to the first line of the getInstance() method.
• The first time this method is called, instance is null and the code proceeds to B9.
• The code at BE allocates the memory from the heap for the Singleton object and stores a pointer to that memory in eax.
• The next line, C3, takes the pointer in eax and stores it back into the instance reference at memory location 049388C8. As a result, instance is now non-null and refers to a valid Singleton object.
• However, the constructor for this object has not run yet, which is precisely the situation that breaks double-checked locking.
• Then at line C8, the instance pointer is dereferenced and stored in ecx.
• Lines CA and D0 represent the inline constructor storing the values true and 5 into the Singleton object.
• If this code is interrupted by another thread after executing line C3 but before completing the constructor, double-checked locking fails.

Not all JIT compilers generate the code as above. Some generate code such that instance becomes non-null only after the constructor executes. However, this does not mean you should use double-checked locking in these instances. There are other reasons it could fail. In addition, you do not always know which JVMs your code will run on, and the JIT compiler could always change to generate code that breaks this idiom.

So how do we solve the issue. Some developers come up with the following code:

        public static Singleton getInstance() {
		if (instance == null) {
		    instance = this.getInstanceSlow();
		}
		return instance;
	}

	private static synchronized Singleton getInstanceSlow() {
		if (instance == null) {
		    instance = new Singleton();
		}
		return instance;
	}

In other words, delegate the locking to another method. This is entirely equivalent to the inline version, and fails for the same reasons.

Volatile?

Another idea is to use the keyword volatile for the variables inst and instance. According to the JLS , variables declared volatile are supposed to be sequentially consistent, and therefore, not reordered. But two problems occur with trying to use volatile to fix the problem with double-checked locking:

1. The problem here is not with sequential consistency. Code is being moved, not reordered.
2. Many JVMs do not implement volatile correctly regarding sequential consistency anyway.

The second point is worth expanding upon. Consider the code:

class Test
{
  private volatile boolean stop = false;
  private volatile int num = 0;

  public void foo()
  {
    num = 100;    //This can happen second
    stop = true;  //This can happen first
    //...
  }

  public void bar()
  {
    if (stop)
      num += num;  //num can == 0!
  }
  //...
}

According to the JLS, because stop and num are declared volatile, they should be sequentially consistent. This means that if stop is ever true, num must have been set to 100. However, because many JVMs do not implement the sequential consistency feature of volatile, you cannot count on this behavior. Therefore, if Thread 1 called foo and Thread 2 called bar concurrently, Thread 1 might set stop to true before num is set to 100. This could lead thread 2 to see stop as true, but num still set to 0. There are additional problems with volatile and the atomicity of 64-bit variables, I wont go in to the details as it is out of scope for this post.

This is it from me for now. Stay tuned for the next post in which I will discuss various solutions available for fixing this and pros and cons of those solution.

Until then Happy Coding !