Let's look at the simple Java code in the following snippet:

final public class Main
{
    private int temp()
    {
         return(true ? null : 0);  // No compiler error - the compiler allows a return value of null in a method signature that returns an int.
    }

    private int same()
    {
        if(true)
        {
            return(null);  // The same is not possible with if, and causes a compile-time error - incompatible types.
        }
        else
        {
            return(0);
        }
    }

    public static void main(String[] args)
    {
        Main m=new Main();
        System.out.println(m.temp());
        System.out.println(m.same());   
     }
}

In this simplest of Java code, the temp() method issues no compiler error even though the return type of the function is int, and we are trying to return the value null (through the statement return(true ? null : 0);). When compiled, this obviously causes the run time exception NullPointerException.

However, it appears that the same thing is wrong if we represent the ternary operator with an if statement (as in the same() method), which does issue a compile-time error! Why?

The compiler interprets null as a null reference to an Integer, applies the autoboxing/unboxing rules for the conditional operator (as described in the Java Language Specification, 15.25), and moves happily on. This will generate a Null Pointer Exception at run time, which you can confirm by trying it.

I got this question in an interview the other day and would like to know some best possible answers(I did not answer very well haha):

Scenario: There is a webpage that is monitoring the bytes sent over a some network. Every time a byte is sent the recordByte() function is called passing that byte, this could happen hundred of thousands of times per day. There is a button on this page that when pressed displays the last 100 bytes passed to recordByte() on screen (it does this by calling the print method below).

The following code is what I was given and asked to fill out:

public class networkTraffic {
    public void recordByte(Byte b){
    }
    public String print() {
    }
}

What is the best way to store the 100 bytes? A list? Curious how best to do this.

Something like this (circular buffer) :

Byte buffer[100];
int index;
public void recordByte(Byte b) {
   index = (index + 1) % 100;
   buffer[index] = b; 
}

public void print() {
   for(int i = index; i < index + 100; i++) {
       System.out.print(buffer[i % 100]);
   }
}

The benefits of using a circular buffer:

1. You can reserve the space statically. In a real-time network application (VoIP, streaming,..)this is often done because you don't need to store all data of a transmission, but only a window containing the new bytes to be processed.
2. It's fast: can be implemented with an array with read and write cost of O(1).

I'm studying for the OCPJP exam, and so I have to understand every little strange detail of Java. This includes the order in which the pre- and post-increment operators apply to variables. The following code is giving me strange results:

int a = 3;

a = (a++) * (a++);

System.out.println(a); // 12

Shouldn't the answer be 11? Or maybe 13? But not 12!

FOLLOW UP:

What is the result of the following code?

int a = 3;

a += (a++) * (a++);

System.out.println(a);

After the first a++ a becomes 4. So you have 3 * 4 = 12.

(a becomes 5 after the 2nd a++, but that is discarded, because the assignment a = overrides it)

When I run the following code:

public class Test {

  Test(){
    System.out.println("1");
  }

  {
    System.out.println("2");
  }

  static {
    System.out.println("3");
  }

  public static void main(String args[]) {
    new Test();
  }
}

I expect to get the output in this order:

1
2
3

but what I got is in reverse order:

3
2
1

Can anyone explain why it is output in reverse order?

================

Also, when I create more than one instance of Test:

new Test();
new Test();
new Test();
new Test();

static block is executed only at first time.

It all depends on the order of execution of initialization statements. Your test demonstrates that this order is:

1. Static initialization blocks
2. Instance initialization blocks
3. Constructors

Edit

Thanks for the comments, now I can quote the appropriate part in the JVM specification. Here it is, the detailed initialization procedure.

I ran into this question in an interview and couldn't come up with a solution. I know the vice versa can be done as shown in What does the "+=" operator do in Java?

So the question was like below.

..... x = .....;
..... y = .....;

x += y; //compile error
x = x + y; //works properly

Try this code

Object x = 1;
String y = "";

x += y; //compile error
x = x + y; //works properly

not entirely sure why this works, but the compiler says

The operator += is undefined for the argument type(s) Object, String

and I assume that for the second line, toString is called on the Object.

EDIT:

It makes sense as the += operator is meaningless on a general Object. In my example I cast an int to an Object, but it only depends on x being of type Object:

Object x = new Object();

It only works if x is Object though, so I actually think it is more that String is a direct subclass of Object. This will fail for x + y:

Foo x = new Foo();

for other types that I have tried.

In the following example, one thread is sending "messages" via a ByteBuffer which is the consumer is taking. The best performance is very good but its not consistent.

public class Main {
    public static void main(String... args) throws IOException {
        for (int i = 0; i < 10; i++)
            doTest();
    }

    public static void doTest() {
        final ByteBuffer writeBuffer = ByteBuffer.allocateDirect(64 * 1024);
        final ByteBuffer readBuffer = writeBuffer.slice();
        final AtomicInteger readCount = new PaddedAtomicInteger();
        final AtomicInteger writeCount = new PaddedAtomicInteger();

        for(int i=0;i<3;i++)
            performTiming(writeBuffer, readBuffer, readCount, writeCount);
        System.out.println();
    }

    private static void performTiming(ByteBuffer writeBuffer, final ByteBuffer readBuffer, final AtomicInteger readCount, final AtomicInteger writeCount) {
        writeBuffer.clear();
        readBuffer.clear();
        readCount.set(0);
        writeCount.set(0);

        Thread t = new Thread(new Runnable() {
            @Override
            public void run() {
                byte[] bytes = new byte[128];
                while (!Thread.interrupted()) {
                    int rc = readCount.get(), toRead;
                    while ((toRead = writeCount.get() - rc) <= 0) ;
                    for (int i = 0; i < toRead; i++) {
                        byte len = readBuffer.get();
                        if (len == -1) {
                            // rewind.
                            readBuffer.clear();
//                            rc++;
                        } else {
                            int num = readBuffer.getInt();
                            if (num != rc)
                                throw new AssertionError("Expected " + rc + " but got " + num) ;
                            rc++;
                            readBuffer.get(bytes, 0, len - 4);
                        }
                    }
                    readCount.lazySet(rc);
                }
            }
        });
        t.setDaemon(true);
        t.start();
        Thread.yield();
        long start = System.nanoTime();
        int runs = 30 * 1000 * 1000;
        int len = 32;
        byte[] bytes = new byte[len - 4];
        int wc = writeCount.get();
        for (int i = 0; i < runs; i++) {
            if (writeBuffer.remaining() < len + 1) {
                // reader has to catch up.
                while (wc - readCount.get() > 0) ;
                // rewind.
                writeBuffer.put((byte) -1);
                writeBuffer.clear();
            }
            writeBuffer.put((byte) len);
            writeBuffer.putInt(i);
            writeBuffer.put(bytes);
            writeCount.lazySet(++wc);
        }
        // reader has to catch up.
        while (wc - readCount.get() > 0) ;
        t.interrupt();
        t.stop();
        long time = System.nanoTime() - start;
        System.out.printf("Message rate was %.1f M/s offsets %d %d %d%n", runs * 1e3 / time
                , addressOf(readBuffer) - addressOf(writeBuffer)
                , addressOf(readCount) - addressOf(writeBuffer)
                , addressOf(writeCount) - addressOf(writeBuffer)
        );
    }

    // assumes -XX:+UseCompressedOops.
    public static long addressOf(Object... o) {
        long offset = UNSAFE.arrayBaseOffset(o.getClass());
        return UNSAFE.getInt(o, offset) * 8L;
    }

    public static final Unsafe UNSAFE = getUnsafe();
    public static Unsafe getUnsafe() {
        try {
            Field field = Unsafe.class.getDeclaredField("theUnsafe");
            field.setAccessible(true);
            return (Unsafe) field.get(null);
        } catch (Exception e) {
            throw new AssertionError(e);
        }
    }

    private static class PaddedAtomicInteger extends AtomicInteger {
        public long p2, p3, p4, p5, p6, p7;

        public long sum() {
//            return 0;
            return p2 + p3 + p4 + p5 + p6 + p7;
        }
    }
}

prints the timings for the same block of data. The numbers at the end are the relative addresses of the objects which show they are layed out in cache the same each time. Running longer tests of 10 shows that a given combination produces the same performance repeatedly.

Message rate was 63.2 M/s offsets 136 200 264
Message rate was 80.4 M/s offsets 136 200 264
Message rate was 80.0 M/s offsets 136 200 264

Message rate was 81.9 M/s offsets 136 200 264
Message rate was 82.2 M/s offsets 136 200 264
Message rate was 82.5 M/s offsets 136 200 264

Message rate was 79.1 M/s offsets 136 200 264
Message rate was 82.4 M/s offsets 136 200 264
Message rate was 82.4 M/s offsets 136 200 264

Message rate was 34.7 M/s offsets 136 200 264
Message rate was 39.1 M/s offsets 136 200 264
Message rate was 39.0 M/s offsets 136 200 264

Each set of buffers and counter are tested three times and those buffers appear to give similar results. SO I believe there is something about the way these buffers are layed out in memory I am not seeing.

Is there anything which might give the higher performance more often? It looks like a cache collision but I can't see where this could be happening.

BTW: M/s is millions of messages per second and is more than anyone is likely to need, but it would be good to understand how to make it consistently fast.

---

EDIT: Using synchronized with wait and notify makes the result much more consistent. But not faster.

Message rate was 6.9 M/s
Message rate was 7.8 M/s
Message rate was 7.9 M/s
Message rate was 6.7 M/s
Message rate was 7.5 M/s
Message rate was 7.7 M/s
Message rate was 7.3 M/s
Message rate was 7.9 M/s
Message rate was 6.4 M/s
Message rate was 7.8 M/s

---

EDIT: By using task set, I can make the performance consistent if I lock the two threads to change the same core.

Message rate was 35.1 M/s offsets 136 200 216
Message rate was 34.0 M/s offsets 136 200 216
Message rate was 35.4 M/s offsets 136 200 216

Message rate was 35.6 M/s offsets 136 200 216
Message rate was 37.0 M/s offsets 136 200 216
Message rate was 37.2 M/s offsets 136 200 216

Message rate was 37.1 M/s offsets 136 200 216
Message rate was 35.0 M/s offsets 136 200 216
Message rate was 37.1 M/s offsets 136 200 216

If I use any two logical threads on different cores, I get the inconsistent behaviour

Message rate was 60.2 M/s offsets 136 200 216
Message rate was 68.7 M/s offsets 136 200 216
Message rate was 55.3 M/s offsets 136 200 216

Message rate was 39.2 M/s offsets 136 200 216
Message rate was 39.1 M/s offsets 136 200 216
Message rate was 37.5 M/s offsets 136 200 216

Message rate was 75.3 M/s offsets 136 200 216
Message rate was 73.8 M/s offsets 136 200 216
Message rate was 66.8 M/s offsets 136 200 216

---

EDIT: It appears that triggering a GC will shift the behaviour. These show repeated test on the same buffer+counters with a manually trigger GC halfway.

faster after GC

Message rate was 27.4 M/s offsets 136 200 216
Message rate was 27.8 M/s offsets 136 200 216
Message rate was 29.6 M/s offsets 136 200 216
Message rate was 27.7 M/s offsets 136 200 216
Message rate was 29.6 M/s offsets 136 200 216
[GC 14312K->1518K(244544K), 0.0003050 secs]
[Full GC 1518K->1328K(244544K), 0.0068270 secs]
Message rate was 34.7 M/s offsets 64 128 144
Message rate was 54.5 M/s offsets 64 128 144
Message rate was 54.1 M/s offsets 64 128 144
Message rate was 51.9 M/s offsets 64 128 144
Message rate was 57.2 M/s offsets 64 128 144

and slower

Message rate was 61.1 M/s offsets 136 200 216
Message rate was 61.8 M/s offsets 136 200 216
Message rate was 60.5 M/s offsets 136 200 216
Message rate was 61.1 M/s offsets 136 200 216
[GC 35740K->1440K(244544K), 0.0018170 secs]
[Full GC 1440K->1302K(244544K), 0.0071290 secs]
Message rate was 53.9 M/s offsets 64 128 144
Message rate was 54.3 M/s offsets 64 128 144
Message rate was 50.8 M/s offsets 64 128 144
Message rate was 56.6 M/s offsets 64 128 144
Message rate was 56.0 M/s offsets 64 128 144
Message rate was 53.6 M/s offsets 64 128 144

---

EDIT: Using @BegemoT's library to print the core id used I get the following on a 3.8 GHz i7 (home PC)

Note: the offsets are incorrect by a factor of 8. As the heap size was small, the JVM doesn't multiply the reference by 8 like it does with a heap which is larger (but less than 32 GB).

writer.currentCore() -> Core[#0]
reader.currentCore() -> Core[#5]
Message rate was 54.4 M/s offsets 3392 3904 4416
writer.currentCore() -> Core[#0]
reader.currentCore() -> Core[#6]
Message rate was 54.2 M/s offsets 3392 3904 4416
writer.currentCore() -> Core[#0]
reader.currentCore() -> Core[#5]
Message rate was 60.7 M/s offsets 3392 3904 4416

writer.currentCore() -> Core[#0]
reader.currentCore() -> Core[#5]
Message rate was 25.5 M/s offsets 1088 1600 2112
writer.currentCore() -> Core[#0]
reader.currentCore() -> Core[#5]
Message rate was 25.9 M/s offsets 1088 1600 2112
writer.currentCore() -> Core[#0]
reader.currentCore() -> Core[#5]
Message rate was 26.0 M/s offsets 1088 1600 2112

writer.currentCore() -> Core[#0]
reader.currentCore() -> Core[#5]
Message rate was 61.0 M/s offsets 1088 1600 2112
writer.currentCore() -> Core[#0]
reader.currentCore() -> Core[#5]
Message rate was 61.8 M/s offsets 1088 1600 2112
writer.currentCore() -> Core[#0]
reader.currentCore() -> Core[#5]
Message rate was 60.7 M/s offsets 1088 1600 2112

You can see that the same logical threads are being used, but the performance varies, between runs, but not within a run (within a run the same objects are used)

---

I have found the problem. It was a memory layout issue but I could see a simple way to resolve it. ByteBuffer cannot be extended so you can't add padding so I create an object I discard.

    final ByteBuffer writeBuffer = ByteBuffer.allocateDirect(64 * 1024);
    final ByteBuffer readBuffer = writeBuffer.slice();
    new PaddedAtomicInteger();
    final AtomicInteger readCount = new PaddedAtomicInteger();
    final AtomicInteger writeCount = new PaddedAtomicInteger();

Without this extra padding (of the object which is not used), the results look like this on a 3.8 GHz i7.

Message rate was 38.5 M/s offsets 3392 3904 4416
Message rate was 54.7 M/s offsets 3392 3904 4416
Message rate was 59.4 M/s offsets 3392 3904 4416

Message rate was 54.3 M/s offsets 1088 1600 2112
Message rate was 56.3 M/s offsets 1088 1600 2112
Message rate was 56.6 M/s offsets 1088 1600 2112

Message rate was 28.0 M/s offsets 1088 1600 2112
Message rate was 28.1 M/s offsets 1088 1600 2112
Message rate was 28.0 M/s offsets 1088 1600 2112

Message rate was 17.4 M/s offsets 1088 1600 2112
Message rate was 17.4 M/s offsets 1088 1600 2112
Message rate was 17.4 M/s offsets 1088 1600 2112

Message rate was 54.5 M/s offsets 1088 1600 2112
Message rate was 54.2 M/s offsets 1088 1600 2112
Message rate was 55.1 M/s offsets 1088 1600 2112

Message rate was 25.5 M/s offsets 1088 1600 2112
Message rate was 25.6 M/s offsets 1088 1600 2112
Message rate was 25.6 M/s offsets 1088 1600 2112

Message rate was 56.6 M/s offsets 1088 1600 2112
Message rate was 54.7 M/s offsets 1088 1600 2112
Message rate was 54.4 M/s offsets 1088 1600 2112

Message rate was 57.0 M/s offsets 1088 1600 2112
Message rate was 55.9 M/s offsets 1088 1600 2112
Message rate was 56.3 M/s offsets 1088 1600 2112

Message rate was 51.4 M/s offsets 1088 1600 2112
Message rate was 56.6 M/s offsets 1088 1600 2112
Message rate was 56.1 M/s offsets 1088 1600 2112

Message rate was 46.4 M/s offsets 1088 1600 2112
Message rate was 46.4 M/s offsets 1088 1600 2112
Message rate was 47.4 M/s offsets 1088 1600 2112

with the discarded padded object.

Message rate was 54.3 M/s offsets 3392 4416 4928
Message rate was 53.1 M/s offsets 3392 4416 4928
Message rate was 59.2 M/s offsets 3392 4416 4928

Message rate was 58.8 M/s offsets 1088 2112 2624
Message rate was 58.9 M/s offsets 1088 2112 2624
Message rate was 59.3 M/s offsets 1088 2112 2624

Message rate was 59.4 M/s offsets 1088 2112 2624
Message rate was 59.0 M/s offsets 1088 2112 2624
Message rate was 59.8 M/s offsets 1088 2112 2624

Message rate was 59.8 M/s offsets 1088 2112 2624
Message rate was 59.8 M/s offsets 1088 2112 2624
Message rate was 59.2 M/s offsets 1088 2112 2624

Message rate was 60.5 M/s offsets 1088 2112 2624
Message rate was 60.5 M/s offsets 1088 2112 2624
Message rate was 60.5 M/s offsets 1088 2112 2624

Message rate was 60.5 M/s offsets 1088 2112 2624
Message rate was 60.9 M/s offsets 1088 2112 2624
Message rate was 60.6 M/s offsets 1088 2112 2624

Message rate was 59.6 M/s offsets 1088 2112 2624
Message rate was 60.3 M/s offsets 1088 2112 2624
Message rate was 60.5 M/s offsets 1088 2112 2624

Message rate was 60.9 M/s offsets 1088 2112 2624
Message rate was 60.5 M/s offsets 1088 2112 2624
Message rate was 60.5 M/s offsets 1088 2112 2624

Message rate was 60.7 M/s offsets 1088 2112 2624
Message rate was 61.6 M/s offsets 1088 2112 2624
Message rate was 60.8 M/s offsets 1088 2112 2624

Message rate was 60.3 M/s offsets 1088 2112 2624
Message rate was 60.7 M/s offsets 1088 2112 2624
Message rate was 58.3 M/s offsets 1088 2112 2624

Unfortunately there is always the risk that after a GC, the objects will not be laid out optimally. The only way to resolve this may be to add padding to the original class. :(

I'm not an expert in the area of processor caches but I suspect your issue is essentially a cache issue or some other memory layout problem. Repeated allocation of the buffers and counters without cleaning up the old objects may be causing you to periodically get a very bad cache layout, which may lead to your inconsistent performance.

Using your code and making a few mods I have been able to make the performance consistent (my test machine is Intel Core2 Quad CPU Q6600 2.4GHz w/ Win7x64 - so not quite the same but hopefully close enough to have relevant results). I've done this in two different ways both of which have roughly the same effect.

First, move creation of the buffers and counters outside of the doTest method so that they are created only once and then reused for each pass of the test. Now you get the one allocation, it sits nicely in the cache and performance is consistent.

Another way to get the same reuse but with "different" buffers/counters was to insert a gc after the performTiming loop:

for ( int i = 0; i < 3; i++ )
    performTiming ( writeBuffer, readBuffer, readCount, writeCount );
System.out.println ();
System.gc ();

Here the result is more or less the same - the gc lets the buffers/counters be reclaimed and the next allocation ends up reusing the same memory (at least on my test system) and you end up in cache with consistent performance (I also added printing of the actual addresses to verify reuse of the same locations). My guess is that without the clean up leading to reuse you eventually end up with a buffer allocated that doesn't fit into the cache and your performance suffers as it is swapped in. I suspect that you could do some strange things with order of allocation (like you can make the performance worse on my machine by moving the counter allocation in front of the buffers) or creating some dead space around each run to "purge" the cache if you didn't want to eliminate the buffers from a prior loop.

Finally, as I said, processor cache and the fun of memory layouts aren't my area of expertise so if the explanations are misleading or wrong - sorry about that.

I want to write a backend system for a web site (it'll be a custom search-style service). It needs to be highly concurrent and fast. Given my wish for concurrency, I was planning on using a functional language such as Haskell or Scala.

However, speed is also a priority. http://shootout.alioth.debian.org/ results appear to show that Java is almost as fast as C/C++, Scala is generally pretty good, but Haskell ranges from slower to a lot slower for most tasks.

Does anyone have any performance benchmarks/experience of using Haskell vs Scala vs Java for performing highly concurrent tasks?

Some sites I've seen suggest that Scala has memory leaks which could be terrible for long running services such as this one.

What should I write my service in, or what should I take into account before choosing (performance and concurrency being the highest priorities)?

Thanks

This question is superficially about performance of code compiled with GHC vs code running on the JVM. But there are a lot of other factors that come into play.

People

• Is there a team working on this, or just you?
  • How familiar/comfortable is that team with these languages?
  • Is this a language you (all) want to invest time in learning?
• Who will maintain it?

Behavior

• How long is this project expected to live?
• When, if ever, is downtime acceptable?
• What kind of processing will this program do?
  • Are there well-known libraries that can aid you in this?
  • Are you willing to roll your own library? How difficult would this be in that language?

Community

• How much do you plan to draw from open source?
• How much do you plan to contribute to open source?
• How lively and helpful is the community
  • on StackOverflow
  • on irc
  • on Reddit
  • working on open source components that you might make use of

Tools

• Do you need an IDE?
• Do you need code profiling?
• What kind of testing do you want to do?
• How helpful is the language's documentation? And for the libraries you will use?
• Are there tools to fill needs you didn't even know you had yet?

There are a million and one other factors that you should consider. Whether you choose Scala, Java, or Haskell, I can almost guarantee that you will be able to meet your performance requirements (meaning, it probably requires approximately the same amount of intelligence to meet your performance requirements in any of those languages). The Haskell community is notoriously helpful, and my limited experience with the Scala community has been much the same as with Haskell. Personally I am starting to find Java rather icky compared to languages that at least have first-class functions. Also, there are a lot more Java programmers out there, causing a proliferation of information on the internet about Java, for better (more likely what you need to know is out there) or worse (lots of noise to sift through).

tl;dr I'm pretty sure performance is roughly the same. Consider other criteria.

I have implemented a simple parallel merge sort algorithm in Java. This cuts the array into equal sections and pass them to be sorted independently by each thread. After the array segments are sorted, the sorted lists are joined. The last join operation is done in a single thread. Because there is no shared resource, so no synchronization is used. When two threads are used there is performance gain almost 66%. When i use 4 threads, then the time takes does not differ from the two thread one. I am on linux 2.6.40.6-0.fc15.i686.PAE, and an Intel Core i5 .

I am benchmarking time with the unix time command (array is assigned random integers). At the end of the sorting i am checking if the array ordering is correct or not (not parallel).

1 Thread

$echo "100000000" | time -p java mergeSortTest

Enter n: 
[SUCCESS]

real 40.73
user 40.86
sys 0.22

2 Threads

$ echo "100000000" | time -p java mergeSortTest

Enter n: 
[SUCCESS]

real 26.90
user 49.65
sys 0.48

4 Threads

$ echo "100000000" | time -p java mergeSortTest

Enter n: 
[SUCCESS]

real 25.13
user 76.53
sys 0.43

The CPU usage is around 80% to 90% when using 4 threads, and around 50% when using 2 threads, and around 25% when using single thread.

I was expecting a speedup when run in 4 threads. Am i wrong anywhere.

UPDATE 1

Here is the code: http://pastebin.com/9hQPhCa8

UPDATE 2 I have a Intel Core i5 second generation processor.

Output of cat /proc/cpuinfo | less (only core 0 is shown).

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
stepping        : 7
cpu MHz         : 800.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 x2apic popcnt xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips        : 4589.60
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

The Core i5 has 2 cores and hyperthreading technology so it seems that it has 4 cores. Those extra two logical cores will not help nearly as much as two physical cores since your sorting algorithm does a good job at keeping the CPU busy.

Since you asked for a "credible" source, I will point to an article from the Intel website that I read a while back: performance-insights-to-intel-hyper-threading-technology. In particular note the following section on "limitations of hyperthreading":

Extremely compute-efficient applications. If the processor's execution resources are already well utilized, then there is little to be gained by enabling Intel HT Technology. For instance, code that already can execute four instructions per cycle will not increase performance when running with Intel HT Technology enabled, as the process core can only execute a maximum of four instructions per cycle.

Also note this section about the memory subsystem contention:

Extremely high memory bandwidth applications. Intel HT Technology increases the demand placed on the memory subsystem when running two threads. If an application is capable of utilizing all the memory bandwidth with Intel HT Technology disabled, then the performance will not increase when Intel HT Technology is enabled. It is possible in some circumstances that performance will degrade, due to increased memory demands and/or data caching effects in these instances. The good news is that systems based on the Nehalem core with integrated memory controllers and Intel® QuickPath Interconnects greatly increase available memory bandwidth compared to older Intel CPUs with Intel HT technology. The result is that the number of applications that will experience a degradation using Intel HT Technology on the Nehalem core due to lack of memory bandwidth is greatly reduced.

Other interesting points can be found in the Intel Guide for Developing Multithreaded Applications. Here is another snippet from detecting-memory-bandwidth-saturation-in-threaded-applications:

As an increasing number of threads or processes share the limited resources of cache capacity and memory bandwidth, the scalability of a threaded application can become constrained. Memory-intensive threaded applications can suffer from memory bandwidth saturation as more threads are introduced. In such cases, the threaded application won’t scale as expected, and performance can be reduced.

I've got a collection of Duck objects and I'd like to sort them using multiple keys.

class Duck {
    DuckAge age; //implements Comparable
    DuckWeight weight; //implements Comparable
    String name;
}
List<Duck> ducks = Pond.getDucks();

eg. I want to sort them primarily by their weights, and secondarily by their age. If two ducks have the exact same weight and the exact same age, then let's differentiate them using their names as a tertiary key. I might do something like this:

Collections.sort(ducks, new Comparator<Duck>(){
    @Override
    public int compare(Duck d1, Duck d2){
        int weightCmp = d1.weight.compareTo(d2.weight);
        if (weightCmp != 0) {
            return weightCmp;
        }
        int ageCmp = d1.age.compareTo(d2.age);
        if (ageCmp != 0) {
            return ageCmp;
        }
        return d1.name.compareTo(d2.name);
    }
});

Well I do this quite frequently, but this solution doesn't smell right. It doesn't scale well, and it's easy to mess up. Surely there must be a better way of sorting Ducks using multiple keys! Does anybody know of a better solution?

EDIT removed unnecessary else branches

It doesn't look too bad. Using Guava, you might simply do this:

return ComparisonChain.start()
     .compare(d1.weight, d2.weight)
     .compare(d1.age, d2.age)
     .compare(d1.name, d2.name)
     .result();

which is more elegant. Apache commons-lang has a similar construct (CompareToBuilder).

My question is an extension to this one: Java: volatile guarantees and out-of-order execution

To make it more concrete, let's say we have a simple class which can be in two states after it is initialized:

class A {
    private /*volatile?*/ boolean state;
    private volatile boolean initialized = false;

    boolean getState(){
        if (!initialized){
            throw new IllegalStateException();
        }
        return state;
    }

    void setState(boolean newState){
        state = newState;
        initialized = true;
    }
}

The field initialized is declared volatile, so it introduces happen-before 'barrier' which ensures that reordering can't take place. Since the state field is written only before initialized field is written and read only after the initialized field is read, I can remove the volatile keyword from declaration of the state and still never see a stale value. Questions are:

1. Is this reasoning correct?
2. Is it guaranteed that the write to initialized field won't be optimized away (since it changes only the first time) and the 'barrier' won't be lost?

3. Suppose, instead of the flag, a CountDownLatch was used as an initializer like this:

   class A {
       private /*volatile?*/ boolean state;
       private final CountDownLatch initialized = new CountDownLatch(1);
   
       boolean getState() throws InterruptedException {
           initialized.await();
           return state;
       }
   
       void setState(boolean newState){
           state = newState;
           initialized.countdown();
       }
   }
   

   Would it still be alright?

Your code is (mostly) correct and it is a common idiom.

// reproducing your code
class A

    state=false;              //A
    initialized=false;        //B

    boolean state;
    volatile boolean initialized = false;        //0

    void setState(boolean newState)
        state = newState;                        //1
        initialized = true;                      //2

    boolean getState()
        if (!initialized)                        //3
            throw ...;
        return state;                            //4

Line #A #B are pseudo code for writing default values to variables (aka zeroing the fields). We need to include them in a strict analysis. Note that #B is different from #0; both are executed. Line #B is not considered a volatile write.

All volatile accesses(read/write) on all variables are in a total order. We want to establish that #2 is before #3 in this order, if #4 is reached.

There are 3 writes to initialized: #B, #0 and #2. Only #2 assigns true. Therefore if #2 is after #3, #3 cannot read true (this is probably due to the no out-of-thin-air guarantee which I don't fully understand), then #4 can't be reached.

Therefore if #4 is reached, #2 must be before #3 (in the total order of volatile accesses).

Therefore #2 happens-before #3 (a volatile write happens-before a subsequent volatile read).

By programming order, #1 happens-before #2, #3 happens-before #4.

By transitivity, therefore #1 happens-before #4.

Line#A, the default write, happens-before everything (except other default writes)

Therefore all accesses to variable state are in a happens-before chain: #A -> #1 -> #4. There is no data race. The program is correctly synchronized. Read #4 must observe write #1

There is a little problem though. Line #0 is apparently redundant, since #B already assigned false. In practice, a volatile write is not negligible on performance, therefore we should avoid #0.

Even worse, the presence of #0 can cause undesired behavior: #0 can occur after #2! Therefore it may happen that setState() is called, yet subsequent getState() keep throwing errors.

This is possible if the object is not safely published. Suppose thread T1 creates the object and publishes it; thread T2 gets the object and calls setState() on it. If the publication is not safe, T2 can observe the reference to the object, before T1 has finished initializing the object.

You can ignore this problem if you require that all A objects are safely published. That is a reasonable requirement. It can be implicitly expected.

But if we don't have line #0, this won't be a problem at all. Default write #B must happens-before #2, therefore as long as setState() is called, all subsequent getState() will observe initialized==true.

In the count down latch example, initialized is final; that is crucial in guaranteeing safe publication: all threads will observe a properly initialized latch.

Here's my issue: given these classes

class A {}
class B extends A {}

This code compiles:

    List<Class<? extends A>> list = Arrays.asList(B.class, A.class);

And this does not:

    List<Class<? extends A>> anotherList = Arrays.asList(B.class);

What gives?

In the first example, the inferred type of the Arrays.asList() call is List<Class<? extends A>>, which is obviously assignable to a variable of the same type.

In the second example, the type of the right side is List<Class<B>>. While Class<B> is assignable to Class<? extends A>, List<Class<B>> is not assignable to List<Class<? extends A>>. It would be assignable to List<? extends Class<? extends A>>.

The reason for this is the same one as why a List<B> isn't assignable to List<A>. If it was, it would make the following (not-typesafe) code possible:

List<Class<B>> bs = new ArrayList<B>();
List<Class<? extends A>> as = bs;
as.add(A.class);

Obviously, Java doesn't support unsigned number types natively, and that's not going to change soon (comments starting in 2002). However, when working with databases, such as MySQL, they may come in handy every now and then. There are a lot of questions dealing with how to simulate unsigned numbers. For example:

• unsigned short in java
• Java: Unsigned numbers
• Understanding Java unsigned numbers

All of them superficially describe how it could be done. But is there any library actually going all the way and implementing suitable wrappers for UByte, UShort, UInteger, ULong? Preferably, those wrappers would extend java.lang.Number and provide an arithmetic API similar to that of java.math.BigInteger.

As can be seen in this document, there's a lot to think of, and a lot that can go wrong (e.g. how to bitwise shift, how to multiply, etc), so I don't want to do it myself. Also, I don't want to just use the next higher type (e.g. Short instead of Byte, etc.). I want the notion of an 8-bit, 16-bit, 32-bit, 64-bit number preserved, for best interaction with databases, for instance.

UPDATE:

Before you answer! Consider that I know all the workarounds, but I'd really really like to have exactly those 4 types with exactly the above properties. And maybe someone has already done that, so that's why I ask. No need to remind me of the workarounds.

If there isn't any library doing precisely what I need, then I'm going to roll my own. I'll call it jOOU (U for Unsigned):

http://code.google.com/p/joou/

I understand that some may think this is overkill, but I'm not in for a religious discussion. I'd really like to have precisely those wrappers wrapping what other languages call ubyte, ushort, uint, ulong.

Of course, contributions to the arithmetics / bitwise operation implementations are very welcome!

I'm currently trying to submit my app to the Amazon Marketplace. Today I received the following email from the App Testing team:

Your recent submission of RSS Alarm is pending due to the following reason(s):

We are having trouble publishing your app to test. Your APK appears to have the following file included in it: .settings/org.eclipse.core.resources.prefs Please remove this file and resubmit your APK.

Please correct the issue(s) we found with your app submission so we may continue working to get it in the Appstore.

Thing is, I can't see how the .settings folder made it into the APK build in the first place. It's not listed in either my Android settings nor my Java build path settings. So where am I going wrong with this?

Screenshots:

Many thanks.

From working in a team environment I've made it a habit of keeping my application source and resources in a separate directory tree from my workspace and project settings. For example:

/home/workspaces/projectname

/home/sources/projectname

I don't know if this is your exact problem but I think it might help keep Eclipse meta-data from being built with your code.

I'd like to write Java classes in the Xtend language (simply because its way more terse), and have it compile back down into Java classes of which I can use in my Java project. Just like coffeescript. How can I do this?

I tried creating an Xtend file just as I would do with a new class, however I get this error:

Mandatory library bundle 'org.eclipse.xtext.xbase.lib' not found on the classpath.

This disables intellisense (autocompletion). Also, even if I do get that working, how can I have it compile to a Java class?

Having tried the same thing, I can confirm that enabling the Xtend Nature and adding the three Xtend libraries (mentioned earlier, 'org.eclipse.xtext.xtend2.lib', 'org.eclipse.xtext.xbase.lib' and 'com.google.inject') to the project's libraries makes the Xtend code compile, at least. However, I am also having trouble with the R class.

On closer inspection, it looks like the problem with the R class is not with it being located in a different directory. Copying the file to the main source dir with a different name doesn't change anything. Rather, it looks like the problem is with the R class being a static final class, containing several static final subclasses. If I create a simple plain-Java wrapper class that wraps a reference to R.layout.main (for example) inside a normal method, and call that from my Xtend code, then it does accept it and happily compiles.

After that, the next issue I came across was the Android compiler complaining about duplicate about.html and plugin.properties files in 'org.eclipse.xtext.xtend2.lib', 'org.eclipse.xtext.xbase.lib' and 'com.google.inject'. That is relatively easy to fix, by removing those files from two of the three .jar files. I'm not sure if it breaks anything later on, but now at least I have a working snippet of Xtend code running on the Android emulator.

Java Code

In Java code I have class called IdentificationResult which has 3 members:

1. enrollmentID
2. enrollmentSettings
3. identParams.

Here is the class:

package com.vito.android.framework.service;

class IdentificationResult
{
    class IdentParams {
        byte[] otp;
        String seedId;
    }

    String enrollmentID;
    String enrollmentSettings;
    List<IdentParams> identParams;
}

In the main class I have function IdentificationResult GetAuthenticationStatus( ), here is the main Class:

public class TokenManager 
{
    /* Some code goes here ... */

    public IdentificationResult GetAuthenticationStatus( )
    {
        /* Function do some actions here ... */
        return new IdentificationResult;
    }
}

---

C++ Code

I call Java method from my C++ code in this way

void GetAuthenticationStatus( )
{
    // Attach current thread.
    JNIEnv *env = NULL;
    m_javaVM->AttachCurrentThread( env, NULL );
    if( env == NULL ) {
        return -1;
    }

    jclass clazz = NULL;
    clazz = env->GetObjectClass( m_classObject );
    if( clazz == NULL ) {
        return -1;
    }

    // Get class method.
    jmethodID clazzMethod = NULL; 
    env->GetMethodID( clazz, "GetAuthenticationStatus", "(V;)Lcom/vito/android/framework/service/IdentificationResult;" );
    if( clazzMethod == NULL ) {
        return VCS_RESULT_ERROR;
    }

    // Call Java 'GetAuthenticationStatus' function.
    jobject methodReturnObj = env->CallObjectMethod( m_classObject, clazzMethod );

    // Get IdentificationResult Class from Object.
    jclass identifyResultClass = env->GetObjectClass( methodReturnObj );
    if( identifyResultClass == NULL ) 
    {
        return -1;
    }

    // Get identParams.
    jfieldID fieldID = env->GetFieldID( identifyResultClass , "identParams", "***1. Question***");
    if( fieldID == NULL ) {
        return -1;
    }
    else
    {
        *** 2. Question *** 
    }

}

---

Questions

1. What I must write here to get List<IdentParams> field ID?

2. How I can Get or Set field value?

Okay, I have solve the problem and want to share result with you, here is solution:

    fieldID = env->GetFieldID( identifyResultClass , "identParams", "Ljava/util/List;" );
    if( fieldID != NULL ) 
    {
        // Find "java/util/List" Class (Standard JAVA Class).
        jclass listClass = env->FindClass( "java/util/List" );
        if( listClass == NULL ) {
            DBG_WARNING(DBG_CTX, ("Can't Find Class \"java/util/List\".\n"));
            return -1;
        }

        // Get List object field.
        jobject listObject = env->GetObjectField( methodReturnObj, fieldID );
        if( listObject == NULL ) {
            DBG_WARNING(DBG_CTX, ("Can't get ObjectField for \"List\".\n"));
            return -1;
        }

        // Get "java.util.List.get(int location)" MethodID
        jmethodID getMethodID = env->GetMethodID( listClass, "get", "(I)Ljava/lang/Object;" );
        if( getMethodID == NULL ) {
            DBG_WARNING(DBG_CTX, ("Can't get MethodID for \"java.util.List.get(int location)\".\n"));
            return -1;
        }

        // Get "int java.util.List.size()" MethodID
        jmethodID sizeMethodID = env->GetMethodID( listClass, "size", "()I" );
        if( sizeMethodID == NULL ) {
            DBG_WARNING(DBG_CTX, ("Can't get MethodID for \"int java.util.List.size()\".\n"));
            return -1;
        }

        // Call "int java.util.List.size()" method and get count of items in the list.
        int listItemsCount = (int)env->CallIntMethod( listObject, sizeMethodID );
        DBG_DISPLAY(DBG_CTX,("List has %i items\n", listItemsCount));

        for( int i=0; i<listItemsCount; ++i )
        {
            // Call "java.util.List.get" method and get IdentParams object by index.
            jobject identParamsObject = env->CallObjectMethod( listObject, getMethodID, i - 1 );
            if( identParamsObject == NULL )
            {
                DBG_WARNING(DBG_CTX, ("Can't get Object from \"identParamsObject\" at index %i.\n", i - 1));
            }


        }

Thanks to @Joop Eggen he gives me great idea !!!

I have an ORACLE SQL sctipt with several queries and tables, and I wan to run that script from my java program at the starting of the program to ensure that everything is on the right place. I found a code to run the script, but it doesn't work for some reason. Can anyone provide me samples so that I can follow it.

This is what I found :

try {
    String line;
    Process p = Runtime.getRuntime().exec ("psql -U sas -d oracle -h @localhost -f Lab_05_Tables.sql");
    BufferedReader input =new BufferedReader(new InputStreamReader(p.getInputStream()));

    while ((line = input.readLine()) != null) {        
        System.out.println(line);
    }
    input.close();
}
catch (Exception err) {
    err.printStackTrace();
}

But it doesn't work though.

Error

java.io.IOException: Cannot run program "psql": CreateProcess error=2, The system     
cannot find the file specified

It would be much better, if you have resources, to port SQLs from your script into Java program itself.

See Java JDBC tutorial.