Nagle's algorithm and delayed acks...

...don't work well together. I finally understood why from Richard Steven's UNP book.

In a nutshell,

S(ender) sends a packet, and cannot send the second one if the second one's size is less than the MSS (maximum segment size) until the first is acknowledged (Nagle). R(eceiver) receives the first packet, but cannot acknowledge it until the receiver app tries to send data on which the ACK can piggyback (Delayed ACK). S waits, R waits - until the delayed ACK timer on R times out.

No more PermGen in the JDK

PermGen space is familiar to anybody who has debugged memory issues in large JEE applications. Starting with JDK 8, it is being removed. The JDK Enhancement Proposal says "remove", but it's more like it's being moved to native memory outside the JVM.

The goal as mentioned in the JEP is "to remove the need to tune the size of the permanent generation."

The beginnings of the change are already in JDK7, with interned strings being no longer part of the PermGen, but of the main Java heap - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6962931

There's a summary of changes in the OpenJDK mailing list
http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-September/006679.html

What does this mean for Java developers? Well, at least the following
- There will no longer be any need to set the sizes of the Perm Gen space with JVM startup parameters.
- The class metadata previously stored in the PermGen will now be stored in a native memory space called "Metaspace".
- The default maximum size of the metaspace will be limited only by the available memory on the machine. However, it can be limited by using the MaxMetaspaceSize option.
- It's not entirely clear yet as to how debugging tools like jmap and jhat will change, if at all, as a result of this, or if it will bring in more complications.

And of course, if you have classloader-leaks-based OutOfMemory problems in your application, they are not magically going away. They will just be transferred to another space with more memory than is allocated to your JVM now.

I could not find any reference to the origin of the term "metaspaces" except in this paper (PDF) - http://www.ssw.uni-linz.ac.at/General/Staff/TS/optimized_class_metadata_memory_management_in_a_jvm.draft.pdf
Familiarity with the JVM's memory management strategies is required to understand it - which I don't have currently - so it's on my to-read list as of now.