5 Coding Hacks to Reduce GC Overhead
takipiblog.com
takipiblog.com
Currently the Java GC works splendidly with lots of short-lived, small immutable classes. Using this approach can be far better for performance than worrying about telling the ArrayList constructor how many elements the list will probably have.
I imagine that there's going to be novice programmers whose takeaway from the article is "Hashmaps with ints as keys are slow" or "String concatenation in Java is slow".
It would solve the problem with "stop the world" GC dynamics and increase concurrent collecting performance while also adding native fibers to the JVM (and thus make it possible to write highly concurrent software in Java much more easy).
Updating an object in the global heap to point to a thread-local heap can cause unbounded work to be done before that update as the entire pointed-to structure has to be copied into the global heap first. GC designers really hate write barriers (sections of code that are performed before a pointer is updated) that perform unbounded work.
What you should do: allocate one read buffer with a capacity > expected length, overwrite-read into it, copy the data into a fresh capacity == actual length byte array, parse the copy, empty and reuse the read buffer.
What you definitely shouldn't do, despite it being tempting: allocate a read buffer each time and pass the whole thing around.
using (ByteBuffer buffer = pool.AllocateBuffer(128 * 1024))
{
// use buffer.array
}
String result = foo() + arg;
result += boo();
System.out.println(“result = “ + result);