So, what does the code from Series About Java Concurrency – Pt. 3 do? As it turns out, there isn’t a single answer: If you are using a recent Oracle VM the behavior of the program seems to depend on whether your VM runs in server or client mode. In client mode the program will most likely stop after roughly 2.5s as one would naively expect. In server mode however, the program just loops forever. The update to stop in line 24 never gets visible to the main thread. This isn’t a bug, but perfectly legal behavior according to the Java Memory Model, which allows optimizing

while(!stop)

into

while(true)

Synchronization is not just about avoiding data races; it is also needed to avoid reading stale data. This may sound weired, but allows the VM as well as the CPU to apply powerful optimizations (for example Out-of-order execution) that would otherwise be impossible or very hard to implement.

One way to fix our shiny little program is by using the synchronized keyword as demonstrated below:

package com.wordpress.mlangc.concurrent;

public class PleaseWait
{
    private static final long MILLIS_TO_WAIT = 2500;
    private static boolean stop = false;

    private static synchronized boolean isStop()
    {
        return stop;
    }

    private static synchronized void setStop(boolean stop)
    {
        PleaseWait.stop = stop;
    }

    public static void main(String[] args)
    {
        Thread timer = new Thread(new Runnable()
        {
            public void run()
            {
                try
                {
                    Thread.sleep(MILLIS_TO_WAIT);
                }
                catch(InterruptedException e)
                {
                    // We are already exiting the thread.
                }
                finally
                {
                    setStop(true);
                    System.out.println("Stop requested.");
                }
            }
        });

        timer.start();

        long start = System.currentTimeMillis();
        while(!isStop())
            ; // <-- Do nothing.

        long stoppedAfter = System.currentTimeMillis() - start;
        System.out.printf("Stopped after %dms.\n", stoppedAfter);
    }
}

It is important to note that both the setter and the getter are synchronized using the same lock. Synchronizing only the setter method is not enough!

While the code above works reasonably well, we can still do better because we don’t need mutual exclusion, but just want to ensure that main thread sees what the timer thread does. This can be accomplished quite easily by declaring stop to be volatile. The volatile keyword makes sure that the main thread always sees to most recent value of stop without any additional uses of synchronized. Following this advice, we end up with something like this:

package com.wordpress.mlangc.concurrent;

public class PleaseWait
{
    private static final long MILLIS_TO_WAIT = 2500;
    private static volatile boolean stop = false;

    public static void main(String[] args)
    {
        Thread timer = new Thread(new Runnable()
        {
            public void run()
            {
                try
                {
                    Thread.sleep(MILLIS_TO_WAIT);
                }
                catch(InterruptedException e)
                {
                    // We are already exiting the thread.
                }
                finally
                {
                    stop = true;
                    System.out.println("Stop requested.");
                }
            }
        });

        timer.start();

        long start = System.currentTimeMillis();
        while(!stop)
            ; // <-- Do nothing.

        long stoppedAfter = System.currentTimeMillis() - start;
        System.out.printf("Stopped after %dms.\n", stoppedAfter);
    }
}

The only difference to the broken version from Series About Java Concurrency – Pt. 3 is the volatile keyword in line 6.

Last but not least I want to state clearly that this article is not about the proper way to implement task cancellation, which is a nontrivial topic of it’s own. If parts of this post are new to you, I strongly suggest that you grab yourself a copy of the excellent book Java Concurrency in Practice and read at least the first chapter called Fundamentals thoroughly. By doing so you are almost certainly saving yourself from nasty surprises or frustrating debugging session in the future.

package com.wordpress.mlangc.concurrent;

public class PleaseWait
{
    private static final long MILLIS_TO_WAIT = 2500;
    private static boolean stop = false;

    public static void main(String[] args)
    {
        Thread timer = new Thread(new Runnable()
        {
            public void run()
            {
                try
                {
                    Thread.sleep(MILLIS_TO_WAIT);
                }
                catch(InterruptedException e)
                {
                    // We are already exiting the thread.
                }
                finally
                {
                    stop = true;
                    System.out.println("Stop requested.");
                }
            }
        });

        timer.start();

        long start = System.currentTimeMillis();
        while(!stop)
            ; // <-- Do nothing.

        long stoppedAfter = System.currentTimeMillis() - start;
        System.out.printf("Stopped after %dms.\n", stoppedAfter);
    }
}

The solution, together with explanations will be published in the near future.

#include <string>
#include <iostream>

using namespace std;

namespace {

    inline string stringify(const bool value)
    {
        return (value ? "true" : "false");
    }

    struct Struct
    {
        long l;
        bool u;
    };
}

int main()
{
    Struct s;

    if(true != s.u)
        cout << stringify(true) << " != " << stringify(s.u) << endl;
}

Now type g++ stringify.cc -o stringify and run the generated executable. Here is what you might see on some platforms:

$ ./stringify
true != true

Yes, you got that right true != true! I get this behaviour with g++-4.3 and g++-4.4 on Gentoo (x86 and x86_64) as well as with g++-4.1 and g++-4.4 on Ubuntu 9.10 (x86_64). Before attempting to explain what happened here, I want to summarize a few additional facts:

• Several attempts to make this program shorter without ending up with something boring failed.
• Turning on optimization causes g++ optimize all if statements away (especially the implicit one in stringify) under the assumption that s.u is false, which again leads to a much more sane output.
• I could not reproduce this with icc-11.1.

So, what happened? Is g++ broken? Actually the answer is no. Accessing uninitialized memory leads to undefined behavior, and undefined means undefined. In fact the C++0x Final Committee Draft contains a footnote that explicitly mentions the oddity we have just seen:

47) Using a bool value in ways described by this International Standard as “undefined,” such as by examining the value of an
uninitialized automatic object, might cause it to behave as if it is neither true nor false.

This is not that surprising if one considers that at assembler level, a bool is not represented by a single bit, but at least by a byte. An uninitialized byte might have 256 different values, and not just two. One could of course consistently map 0 to false and everything else to true, but this is not what g++ does. To see what I mean, take a look at the following assembler snippet, that g++ generated for the if statement in line 24:

movzbl  -40(%rbp), %eax  # move s.u to eax.
xorl    $1, %eax         # xor eax with 1.
testb	%al, %al         # check if the low byte of eax is 0.
je      .L8              # jump to .L8 if so.

If the jump is taken, the body of the if statement in line 24 is skipped, otherwise it is executed. Now the xorl in line 2 switches the lowest bit in eax, leaving all other bits unchanged. Therefore s.u is considered to be equal to true if and only if it has the byte value 0×01.

Now lets take a look at the assembler that represents the ternary operator in stringify:

cmpb $0, -36(%rbp)    # compare the argument with 0.
je   .L2              # jump to .L2 if the argument is 0.
movl $.LC0, %eax      # store "true" in eax.
jmp  .L3              # jump out.
.L2:
     movl $.LC1, %eax # store "false" in eax.
.L3:

Here g++ maps 0 to false and every other value to true. This means that if the actual byte value of s.u is for example 0xFF (which for some reason is what cgdb keeps telling me locally), the if in line 24 will be taken as if s.u was false, but stringify will behave as if s.u was true.

package com.wordpress.mlangc.arrays;

import java.util.Arrays;

public class ArraysToList
{
    public static void main(final String[] args)
    {
        System.out.println(
                Arrays.asList(new String[] { "a", "b" }));

        System.out.println(
                Arrays.asList(new Integer[] { 1, 2 }));

        System.out.println(
                Arrays.asList(new int[] { 1, 2 }));

        System.out.println(
                Arrays.asList(new String[] { "a", "b" }, "c"));
    }
}

As the Javadocs for Arrays.asList are quite vague, I can’t blame you for having some difficulties coming to a conclusion, so here is the answer step by step:

• Line 9 prints “[a, b]“ to our shiny little console which is pretty much what one would expect from a sane API, so we are happy.
• The same is true for line 12 which results in “[1, 2]“.
• Line 15 however is different, not only because 15 is not 12, but also because an int is not an Integer, and therefore prints “[[I@39172e08]“ to our console, that is not shiny anymore. Instead of a list containing two Integer objects, we got a list containing the array as its sole element.
• After what we have seen above, it should not take you by surprise that line 18 results in another mess that looks like “[[Ljava.lang.String;@20cf2c80, c]“.

So, what happened? The first two print statements worked as expected, because the Java Language Specification states that calling a method with signature foo(T… t) like foo(new T[] { bar, baz }) is semantically equivalent to foo(bar, baz). In Arrays.asList T is a type parameter, so it has to be an Object, and this is not true for int, but for int[]. Thats why the statement in line 16 is equivalent to

Arrays.asList(new Object[] { new int[] { 1, 2 } })

Last but not least, the statement in line 19 called for trouble from the very beginning. We told the compiler that we want a list containing an array of strings and a string, which is exactly what we got.

So far for the explanation, but there is something else we can learn from that: The real source of confusion is not that varargs feature is badly designed; I would rather say that the opposite is true. The problem is that Arrays.asList violates EffJava2 Item 42, which explains clearly, in fact giving Arrays.asList as a bad example, why you should be quite careful when designing APIs that use Java varargs. I won’t repeat the reasoning of the book here, as you really should read it yourself, but for the sake of completeness I have to point out that the problematic statements from above would have been rejected by the compiler back in the old days of Java 1.4, which was a good thing. We can still use Arrays.asList today, but doing so safely requires us to be aware of the subtillities we are facing. Here are a few rules for converting arrays to lists, that guarantee nothing unexpected happens:

• If you convert to a list just to convert to a string, use Arrays.toString instead. It does what you want all the time and also works for arrays of primitives.
• If you want to convert an array of primitives to a list of boxed primitives, take advantage of Apache Commons Lang, which most likely is a dependency of your project already anyway, and use ArrayUtils.toObject like this:

  List<Integer> list = Arrays.asList(ArrayUtils.toObject(new int[] { 1, 2 }));
  

  Note however that lists of boxed primitives should not generally be preferred over arrays containing primitives.

• If you want to convert an array of object references, use Arrays.asList directly:

   List<String> list =
             Arrays.asList(new String[] { "a", "b" });
  

  Don’t forget to make sure that the people you work with won’t emulate you carelessly.

Of course, you can also choose to just remember that Arrays.asList might behave unexpectedly and use plain for loops instead, but that clutters your code and comes with a performance penalty.

cout << PrintType<int const* const**&>() << endl;

Note that we cannot use typeid, as typeid(T).name() is not required to print anything meaningful, and in practice doesn’t. As long as we don’t support function pointers, the problem from above can be solved rather easily using template specializations, although it requires quite some typing:

#ifndef HH_PRINT_TYPE
#define HH_PRINT_TYPE

#include <ostream>
#include <boost/tr1/type_traits.hpp>
#include <boost/lexical_cast.hpp>

namespace mine {

    template<class T_> struct PrintType
    {
        // Never used directly.
    };

    /**
     * For plain types we don't know.
     *
     * Could be enhanced by using type_traits.
     */
    template<class T_>
    std::ostream& operator<<(std::ostream& os, PrintType<T_>)
    {
        os << "T";
        return os;
    };

    /**
     * For void.
     */
    template<>
    std::ostream& operator<<(std::ostream& os, PrintType<void>)
    {
        os << "void";
        return os;
    };

    /**
     * For int.
     */
    template<>
    std::ostream& operator<<(std::ostream& os, PrintType<int>)
    {
        os << "int";
        return os;
    };

    /**
     * For char.
     */
    template<>
    std::ostream& operator<<(std::ostream& os, PrintType<char>)
    {
        os << "char";
        return os;
    };

    /**
     * For const qualified types.
     */
    template<class T_>
    std::ostream& operator<<(std::ostream& os, PrintType<T_ const>)
    {
        os << PrintType<T_>() << " const";
        return os;
    };

    /**
     * For volatile qualified types.
     */
    template<class T_>
    std::ostream& operator<<(std::ostream& os, PrintType<T_ volatile>)
    {
        os << PrintType<T_>() << " volatile";
        return os;
    };

    /**
     * For const volatile qualified types.
     */
    template<class T_>
    std::ostream& operator<<(std::ostream& os, PrintType<T_ const volatile>)
    {
        os << PrintType<T_>() << " const volatile";
        return os;
    };

    /**
     * For reference types.
     */
    template<class T_>
    std::ostream& operator<<(std::ostream& os, PrintType<T_&>)
    {
        os << PrintType<T_>() << "&";
        return os;
    };

    /**
     * For pointers.
     */
    template<class T_>
    std::ostream& operator<<(std::ostream& os, PrintType<T_*>)
    {
        os << PrintType<T_>() << "*";
        return os;
    }

    /**
     * For pointers to members.
     */
    template<class ClassT_, class MemberT_>
    std::ostream& operator<<(std::ostream& os, PrintType<MemberT_ ClassT_::*>)
    {
        os << PrintType<MemberT_>() << " " << PrintType<ClassT_>() << "::*";
        return os;
    }

    /**
     * Helper function for array types.
     */
    template<std::size_t SizeP_, class T_>
    std::string printDimensions(PrintType<T_[SizeP_]>)
    {
        return
            "[" + boost::lexical_cast<std::string>(SizeP_) + "]"
            + printDimensions(PrintType<T_>());
    }

    /**
     * Ends the recursion started by printDimensions(PrintType<T_[SizeP_]>).
     */
    template<class T_>
    std::string printDimensions(PrintType<T_>)
    {
        return "";
    }

    /**
     * For arrays.
     */
    template<std::size_t SizeP_, class T_>
    std::ostream& operator<<(std::ostream& os, PrintType<T_[SizeP_]>)
    {
        os << PrintType<typename std::tr1::remove_all_extents<T_>::type>()
           << printDimensions(PrintType<T_[SizeP_]>());

        return os;
    }

    /**
     * For const arrays.
     */
    template<std::size_t SizeP_, class T_>
    std::ostream& operator<<(std::ostream& os, PrintType<const T_[SizeP_]>)
    {
        os << "const " << PrintType<T_[SizeP_]>();
        return os;
    }

    /**
     * For volatile arrays.
     */
    template<std::size_t SizeP_, class T_>
    std::ostream& operator<<(std::ostream& os, PrintType<volatile T_[SizeP_]>)
    {
        os << "volatile " << PrintType<T_[SizeP_]>();
        return os;
    }

    /**
     * For const volatile arrays.
     */
    template<std::size_t SizeP_, class T_>
    std::ostream& operator<<(
            std::ostream& os,
            PrintType<const volatile T_[SizeP_]>)
    {
        os << "const volatile " << PrintType<T_[SizeP_]>();
        return os;
    }
}
#endif

Of course, we are still missing quite a few full specializations but adding them is trivial. In fact, the only part of the code above that is slightly tricky is the part between line 120 and 147, that supports pretty-printing of potentially multi dimensional arrays. Also note the explicit overloads for const volatile at lines 80 and 172. Without them we would get ambiguity errors if trying to pretty print a type that is qualified as such.

While this is all very nice and impressive, the code above still fails us miserably if we do something like

 cout << mine::PrintType<int(int, char, void*)>() << endl;

or even

 cout << mine::PrintType<int(SomeClass::*)(int, char, void*, ...)>() << endl;

as we didn’t yet add support for function pointers. We can of course fix this by adding more specializations, but as functions can take a nearly arbitrary number of arguments (the C++0x Final Committee Draft suggests implementations to support at least 256), doing this in C++03 would be a rather unpleasant experience. Using C++0x variadic templates on the other hand side, supporting function types is not a big deal (as soon as one understands how variadic templates work ):

#ifdef __GXX_EXPERIMENTAL_CXX0X__ //<-- set by gcc for '-std=c++0x'.
    /**
     * Helper struct for printing parameter lists.
     *
     * @tparam StartsP_
     *  true iff we are at the start of the list (needed to omit
     *  commas in the output).
     * @tparam ArgsT_
     *  the actual arguments.
     */
    template<bool StartsP_, class... ArgsT_> struct PrintParameters
    {
        // Never used directly.
    };

    /**
     * For parameter lists.
     */
    template<bool StartsP_, class ArgT, class... ArgsT_>
    std::ostream& operator<<(
            std::ostream& os,
            PrintParameters<StartsP_, ArgT, ArgsT_...>)
    {
        os << (StartsP_ ? "" : ", ")
           << PrintType<ArgT>()
           << PrintParameters<false, ArgsT_...>();

        return os;
    }

    /**
     * Terminates the recursion.
     */
    template<bool StartsP_>
    std::ostream& operator<<(std::ostream& os, PrintParameters<StartsP_>)
    {
        return os;
    }

    /**
     * For function pointers.
     */
    template<class RetT_, class... ArgsT_>
    std::ostream& operator<<(std::ostream& os, PrintType<RetT_(ArgsT_...)>)
    {
        os << PrintType<RetT_>()
           << "(" << PrintParameters<true, ArgsT_...>() << ")";

        return os;
    }

    /**
     * For member functions.
     */
    template<class ClassT_, class RetT_, class... ArgsT_>
    std::ostream& operator<<(
            std::ostream& os,
            PrintType<RetT_(ClassT_::*)(ArgsT_...)>)
    {
        os << PrintType<RetT_>()
           << "(" << PrintType<ClassT_>()
           << "::*)(" << PrintParameters<true, ArgsT_...>() << ")";

        return os;
    }

    /**
     * For parameter lists with varargs.
     */
    template<bool StartsP_, class... ArgsT_> struct PrintParamtersWithVarArgs
    {
        // Never used directly.
    };

    /**
     * For function pointers with varargs.
     */
    template<class RetT_, class... ArgsT_>
    std::ostream& operator<<(
            std::ostream& os,
            PrintType<RetT_(ArgsT_... ...)>)
    {
        os << PrintType<RetT_>()
           << "(" << PrintParameters<true, ArgsT_...>() << "...)";

        return os;
    }

    /**
     * For member functions with varargs.
     */
    template<class RetT_, class ClassT_, class... ArgsT_>
    std::ostream& operator<<(
            std::ostream& os,
            PrintType<RetT_(ClassT_::*)(ArgsT_... ...)>)
    {
        os << PrintType<RetT_>()
           << "(" << PrintType<ClassT_>()
           << "::*)(" << PrintParameters<true, ArgsT_...>() << "...)";

        return os;
    }

    /**
     * For rvalue references (for completeness).
     */
    template<class T_>
    std::ostream& operator<<(std::ostream& os, PrintType<T_&&>)
    {
        os << PrintType<T_>() << "&&";
        return os;
    };
#endif

The main workhorse in the code above is the operator at line 19, that calls itself recursively in line 26 until it eventually degenerates into the operator defined at line 34. Also note the double ellipsis in lines 81 and 95: The first one unpacks the template parameter list, the second one is for old style varargs.

Last but not least: Feel free to come up with suggestions or comments.

• pcrecpp exposes one of the most crippled C++ APIs I’ve ever seen and is poorly documented, although it is shipped with PCRE and has been provided by Google.
• PCRE++ looks much much saner, but fails to properly separate compiled patterns from match results, although the underlying C API does exactly that.

Being accustomed to the very well designed java.util.regex API, I was left with no other choice than to write a C++ wrapper myself. Luckily the PCRE C API isn’t that bad at all and well documented (although you should really spend at least one hour reading the man page carefully while experimenting with small examples, as the API is definitely neither self explanatory nor fool proof). Finally it took me about 8 hours to design, implement and test this C++ API, that is roughly modelled after java.util.regex, and migrate existing code to it. I’m seriously considering putting an extended and overworked version of this API in a standalone library as soon as I have time.

   /**
     * A callable implementation that allows exception propagation between
     * threads for boost::tread.
     */
    class Callable
    {
        public:

        /**
         * Default copy constructor.
         *
         * @attention
         *  Should not be invoked from different threads with the same objects.
         */
        Callable(const Callable&) = default;

        /**
         * Default assignment operator.
         *
         * @attention
         *  Should not be invoked from diffenrent threads with the same objects.
         */
        Callable& operator=(const Callable&) = default;

        /**
         * To be called by boost::thread.
         */
        void operator()() const;

        /**
         * Rethrows pending exceptions.
         */
        void rethrowIfPending() const;

        /**
         * Returns true iff an exception is pending.
         */
        bool isExceptionPending() const;

        virtual ~Callable() = default;

        protected:

        Callable();

        /**
         * Does the actual work.
         *
         * @attention
         *  Exceptions thrown from this method will be catched in operator()(),
         *  and can be rethrown by rethrowIfPending() const.
         */
        virtual void doWork() const = 0;

        private:

        struct ExceptionContainer
        {
            std::exception_ptr exceptionPtr;
        };

        std::tr1::shared_ptr<boost::recursive_mutex> m_exceptionMutex;
        std::tr1::shared_ptr<ExceptionContainer> m_exception;
    };

Note that the only reason we explicitly declared a copy constructor and an assignment operator is for the comments above them. Luckily the C++0x feature Defaulted and Deleted Functions allows us to omit some boilerplate code here. But lets move to the more interesting, and less documented private part of the declaration above: Because boost::thread invokes a copy of our Callable, we cannot store pending exceptions in the class directly if we want them to be visible from outside. To solve this problem, we actually store them in a tr1::shared_ptr to a helper struct. Last but not least, we use a boost::recursive_mutex to guard the stored exception. Here is the implementation (the full source is here):

    void Callable::operator()() const
    {
       try
       {
           doWork();
       }
       catch(...)
       {
           boost::recursive_mutex::scoped_lock lock(*m_exceptionMutex);
           m_exception->exceptionPtr = current_exception();
       }
    }

    void Callable::rethrowIfPending() const
    {
        boost::recursive_mutex::scoped_lock lock(*m_exceptionMutex);
        if(isExceptionPending())
            rethrow_exception(m_exception->exceptionPtr);
    }

    bool Callable::isExceptionPending() const
    {
        boost::recursive_mutex::scoped_lock lock(*m_exceptionMutex);
        return (exception_ptr() != m_exception->exceptionPtr);
    }

    Callable::Callable()
        : m_exceptionMutex(new boost::recursive_mutex()),
          m_exception(new ExceptionContainer)
    {

    }

Using the C++0x features std::current_exception() in line 10 and std::rethrow_exception in line 18, thats all that needs to be done. The careful reader might notice, that Callable isn’t entirely thread save itself: Coping or assigning Callable instances that share internal state from within multiple threads will most likely result in undefined behavior, because tr1::shared_ptr is not thread save. In theory, C++0x contains APIs for accessing shared_ptr instances atomically from within multiple threads, but they are not available with gcc-4.4. Of course, I could have implemented a thread save reference counter in the Callable class directly, but that doesn’t seem worth the effort, as manipulating identical Callable instances from multiple threads is an error anyway. Last but not least: Here is a unit test for the code above, that also illustrates how it is meant to be used.

How can you reliably obtain the size of a random Java object? Well, there are basically two answers: You can use a hack that is outlined here, or you can use Instrumentation.getObjectSize(Object obj). Still, obtaining an implementation of Instrumentation and transversing object graphs is far more work than I want to invest. Luckily there is java.sizeOf which does exactly that for us. java.sizeOf basically is a Java agent and a library to access the functionality of it, packaged into a single class called SizeOf. To see what it can do, I wrote this small program:

package com.wordpress.mlangc.sizeof;

import java.lang.reflect.Array;
import java.util.ArrayList;
import java.util.Collection;
import java.util.List;

import net.sourceforge.sizeof.SizeOf;

public class TestSizeOf
{
    private static final String WTF = ":-O";
    private static final int SIZE = 1024;

    public static void main(final String[] args)
    {
        SizeOf.skipStaticField(true);

        printSize(new Object());
        printSize(Integer.valueOf(0));
        printSize(new int[SIZE]);

        List<Integer> intList = new ArrayList<Integer>(SIZE);
        for(int i = 0; i != SIZE; ++i)
            intList.add(i);
        printSize(intList);
    }

    private static void printSize(final Object obj)
    {
        System.out.println("sizeof(" + describeObject(obj) + "): "
                + SizeOf.humanReadable(SizeOf.deepSizeOf((obj))));
    }

    private static String describeObject(final Object obj)
    {
        Class<?> clazz = obj.getClass();
        StringBuilder sb = new StringBuilder(clazz.getCanonicalName());
        if(clazz.isArray())
        {
            if(!sb.toString().endsWith("[]"))
                throw new AssertionError(WTF);
            sb.insert(sb.length() - 1, Array.getLength(obj));
        }
        else if(obj instanceof Collection<?>)
        {
            Collection<?> collection = (Collection<?>) obj;
            sb.append("<")
              .append(extractGenericTypeFromCollectionHack(collection))
              .append(">")
              .append("[")
              .append(collection.size())
              .append("]");
        }
        return sb.toString();
    }

    private static String extractGenericTypeFromCollectionHack(final Collection<?> collection)
    {
        //It is impossible to do this reliably because of type erasure;
        //for our purposes however, this simple hack,
        //that just inspects the first element, should do nicely.
        if(collection.isEmpty())
            return "?";
        return collection.iterator().next().getClass().getCanonicalName();
    }
}

Then I executed the code above like this (the -javaagent option is important):

$ java -javaagent:${LIB_PATH}/SizeOf.jar com.wordpress.mlangc.sizeof.TestSizeOf
JAVAGENT: call premain instrumentation for class SizeOf
sizeof(java.lang.Object): 16.0b
sizeof(java.lang.Integer): 24.0b
sizeof(int[1024]): 4.0234375Kb
sizeof(java.util.ArrayList<java.lang.Integer>[1024]): 32.0625Kb

So, yes a plain and mostly useless Java Object consumes 16bytes on my system (x86_64 with sun-jdk-1.6.0_17) – thats already 4 int values! An Integer object swallows 24bytes (I would have guessed 20 = 16 + 4 – maybe this has something to do with alignment?), which is 6 int values. An array of 1024 int values needs 4kb as it should, but an ArrayList<Integer> swallows 32kb = 24kb + 8kb and therefore consumes unbelievable 8 times more memory than the array.

So what do I suggest considering the disturbing facts outlined above?

• Prefer primitive types to boxed primitives as suggested by EffJava2 Item 49. Not only are they more efficient, the fact that they cannot be null makes them more attractive for other reasons too (albeit not always).
• If you use wrapped primitives, prefer autoboxing or the Foo.valueOf(foo f) factory methods to direct constructors calls, as this is (citing the Javadocs) “likely to yield significantly better space and time performance by caching frequently requested values”. This is especially important for Boolean, where autoboxing or valueOf(…) never creates a new object.
• Be aware of the fact, that Collections containing boxed primitives are huge memory wasters compared to arrays, even when caching is considered, but keep in mind, that premature optimization is the root of all evil.

Prefer lists to arrays unless you have a very good reason not to.

This was mostly in reaction to Lists are overrated, which has since been edited. Before anything else, l want to state clearly that I still stick to that statement. Unfortunately, due deficiencies in the Java language design and standard library APIs, some of these “good reasons” are not obvious:

Lists containing lots of boxed primitives are huge memory wasters: This isn’t really surprising, if you just do the math. Imagine you have 1024 integers. If you store them in an int array, you should be able to get away with about 4kb of memory. But storing them in a list of boxed primitives will take at least 8kb on a 32bit system, and at least 12kb on a 64bit system, because we now also need an additional object reference for every int value we store. Last but not least, we also need an implementation dependent amount of storage for 1024 Java objects, that make matters even worse. Note that this reasoning isn’t limited to Collections, but to boxed primitives in general (see also Item 49 “Prefer primitive types to boxed primitives” in EffJava2).

Collections.sort(…) favors idiots over experts: Let me cite the relevant Javadocs:

This implementation dumps the specified list into an array, sorts the array, and iterates over the list resetting each element from the corresponding position in the array. This avoids the n2 log(n) performance that would result from attempting to sort a linked list in place.

So, yes, the implementors of the Java standard library favor programmers who are clueless enough to sort huge linked lists, over programmers that did their homework. In fact, this simple Qicksort implementation, that sorts the given List in place, outperforms Collections.sort(…) by about 20% for ArrayList<Integer> and doesn’t needlessly allocate possibly huge amounts of memory:

static <T extends Comparable<? super T>> void qsort(final List<T> list)
{
    qsort(list, 0, list.size());
}

private static <T extends Comparable<? super T>> void qsort(final List<T> list, final int start, final int end)
{
    // Handle simple cases:
    if(end - start < 2)
        return;

    if(end - start == 2)
    {
        if(list.get(start).compareTo(list.get(end - 1)) > 0)
            swap(list, start, end - 1);
        return;
   }

   // Select a new pivot:
   int i1 = start;
   int i2 =  start + (end - start)/2;
   int i3 = end - 1;
   T p1 = list.get(i1);
   T p2 = list.get(i2);
   T p3 = list.get(i3);

   int pivotInd = -1;
   if(p1.compareTo(p2) == -p1.compareTo(p3))
       pivotInd = i1;
   else if(p2.compareTo(p1) == -p2.compareTo(p3))
       pivotInd = i2;
   else
       pivotInd = i3;
   T pivot = list.get(pivotInd);

   // Partition the list using the selected pivot:
   swap(list, pivotInd, end - 1);
   int storeInd = start;
   for(int i = start; i != end - 1; ++i)
   {
       if(pivot.compareTo(list.get(i)) > 0)
           swap(list, i, storeInd++);
    }
    swap(list, storeInd, end - 1);

    // Recurse:
    qsort(list, start, storeInd);
    qsort(list, storeInd + 1, end);
}

private static <T> void swap(final List<T> list, final int i1, final int i2)
{
    T tmp = list.get(i1);
    list.set(i1, list.get(i2));
    list.set(i2, tmp);
}

If you don’t believe me, try it yourself – but please don’t use this code in production without testing it thoroughly.