Develop Reference

Memory regions of Java program?

I haven't deep dive into how Java treats memory when a program is running as I have been in working at application level. I recently had one instance in which I needed to know owing to performance issues of application.
I have been aware of "stack" , "heap" regions of memory and I thought this is the model of a Java program. However, it turns out that it is much more, and beyond that.
For example, I came across terms like: Eden, s0, s1, Old memory and so on. I was never aware of these terminologies prior.
As Java is / have been changing and so may be these terminologies are/aren't relevant as of Java 8.
Can anyone guide where to get this information and under what circumstance we need to know them? Are these part of main memory that is RAM.

Eden, s0, s1, Old memory and other memory areas exist only in the context of the specific garbage collector implementation e.g. generational collectors like G1 will divide the heap into mentioned areas however non-generational collectors like ZGC will not.
Start by reviewing the main garbage collectors in the JVM:
ParNew
CMS
G1
ZGC / Shenandoah / Azul C4
and then try to understand related concepts:
Thread-local allocation buffers (TLAB)
Escape analysis
String constant pools, string interning, string de-duplication
Permanent generation vs Metaspace
Object layout e.g. why boolean is not taking 1 bit (word tearing)
Native memory e.g. JNI or off-heap memory access
I don't believe that there is a single website that will explain the full JVM memory management approach.

Java, as defined by the Java Language Specification and the Java Virtual Machine Specification talks about the stack and the heap (as well as the method area).
Those are the things that are needed to describe, conceptually, what makes a Java Virtual Machine.
If you wanted to implement a JVM you'd need to implement those in some way. They are just as valid in Java 13 as they were back in Java 1. Nothing has fundamentally changed about how those work.
The other terms you mentioned (as well as "old gen", "new gen", ...) are memory areas used in the implementation of specific garbage collection mechanisms, specifically those of implemented in the Oracle JDK / OpenJDK.
All of those areas are basically specific parts of the heap. The exact way the heap is split into those areas is up to the garbage collector to decide and knowing about them shouldn't be necessary unless you want to tweak your garbage collector.
Since garbage collectors change between releases and new garbage collector approaches are implemented regularly (as this is one of the primary ways to speed up JVMs), the concrete terms used here will change over the years.

Which VMs or GCs support JNI pinning?

Get<PrimitiveType>ArrayElements family of functions are documented to either copy arrays, or pin them in place (and, in so doing, prevent a compacting garbage collector from moving them). It is documented as a safer, less-restrictive alternative to GetPrimitiveArrayCritical. However, I'd like to know which VMs and/or garbage collectors (if any) actually pin arrays instead of copying them.

Older IBM JVMs pinned (1.4 and before - ie: NOT the current IBM J9 JVM) but since then, they have not. In general, JVMs don't like pinning as it really messes up copying garbage collectors, which is what most production JVMs do today. I'm not 100% up to date (ie: latest Java 7 builds), but historically HotSpot didn't either (for the same generational GC reasons).
Be aware: a JVM that pins today might not tomorrow, and vice versa, so you need to write your code to handle it both ways, just like the base Java libraries do.

Shenandoah supports pinning (although it is not clear if it does so when using Get*ArrayElements or only when Get*Critical): https://shipilev.net/jvm-anatomy-park/9-jni-critical-gclocker/

Is there a cookbook guide for GC problems?

Almost everyone eventually runs into GC issues with Java.
Is there a cookbook guide or semi-automated tool to tune GC for Java?
My rationale is this:
Almost anyone eventually has these problems
There are many possible factors (say 20) out of which only a few affect your problem.
Most people don't know how to identify the key factors so GC tuning is more like a black art than a science.
Not everyone uses a HotSpot VM. Different Sun versions have different GC characteristics.
There is little incentive to experiment (like run the VM with slightly different settings every day to see how they play out).
So the question really is: Is there something that I can use in a check-list manner? Or maybe even a tool that analyzes GC logs or heap dumps and gives me specific hints where to look (instead of telling me "95% of the data is allocated in objects of the type byte[]" which is basically useless).
Related questions:
Appropriate Tomcat 5.5 start-up parameters to tune JVM for extremely high demand, large heap web application? which is very specific. My question is more wide.
What are the best garbage collection settings for client side? Again very narrow scope
Does anyone know of a good guide to configure GC in Java? HotSpot only
JVM memory management & garbage collection book? is 80% there but I'm missing the checklist/cookbook/for-dummies approach.

Out of various resources I have compiled a sanity checklist that I use to analyze GC behavior and performance of my applications. These guidelines are general and apply to any vendor-specific JVM but contain also HotspotVM-specific information for illustration.
Disable Explicit GC. Explicit GC is a bad coding practice, it never helps. Use -XX:+DisableExplicitGC.
Enable Full GC logging. Lightweight yet powerful.
Compute Live Data Set, Allocation Rate, and Promotion Rate. This will tell you if you need a bigger Heap or if your eg. Young Gen is too small, or if your Survivor spaces are overflowing, etc.
Compute total GC time, it should be <5% of total running time.
Use -XX:+PrintTenuringDistribution -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=jvm.log -XX:+HeapDumpOnOutOfMemoryError -Xloggc:gc.log -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -showversion
Consider additional means of collecting information about your GC. Logging is fine but there are sometimes available lightweight command-line tools that will give you even more insight. Eg. jstat for Hotspot which will show you occupation/capacity of Eden, Survivor and Old Gen.
Collect Class Histograms These are lightweigh and will show you the content of the heap. You can take snapshots whenever you notice some strange GC activity, or you can take them before/after Full GC:
Content of the OldGen space: You can find out which objects reside in the OldGen. You need to print histograms before and after Full GC. And since a YoungGen collection is executed before the Full GC, these Histograms will show you the content of the Old generation. Use -XX:+PrintClassHistogramBeforeFullGC -XX:+PrintClassHistogramAfterFullGC.
Detecting prematurely promoted objects: To determine if any instances are promoted early, you need to study the Histograms to see which classes are expected to reside in the OldGen and which classes should be seen only in the YoungGen. This cannot be done automatically, you need to reason about the purpose of each class and its instance to determine if the object is temporary or not.
Consider different GC Algorithm. The VMs usually come with several different GC implementations that are providing various tradeoffs : throughput, footprint, pause-less/short-pauses, real-time, etc. Consider the options you have and pick the one that suites your needs.
Beware of finalize(). Check that GC keeps up with classes using finalize(). The execution of this method may be quite costly and this can impact GC and application throughput.
Heap Dumps. This is the first step that is heavyweight and will impact the running application. Collect the Heap Dump to further study the heap content or to confirm a hypothesis observed in step 4.
Resources used:
Books:
Java Performance - practical guide
The Garbage Collection Handbook - theory explained
Talks/Articles:
Java One 2012 Advanced JVM Tuning
From Java code to Java heap
Java One 2012 G1 Garbage Collector Performance Tuning
Garbage Collection Tuning Guide
Mailing Lists:
OpenJDK Hotspot GC Use

References for various GC information:
Oracle
Tuning Garbage Collection with the 5.0 Java[tm] Virtual Machine
and this also
Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning
IBM
Fine Tuning Garbage Collection [link dead]
Extensible Verbose Toolkit
SAP JVM
Memory Management (Garbage Collection)
Detecting Memory Leaks
Detecting Hanging / Looping VMs
Analyzing Out-of-Memory Situations
Sorry I don't know much about SAP but have provided some things I have found.
As for a cookbook, tuning is most likely application specific at this level, but it is an interesting topic.
ADDENDUM
You also mentioned analysis tools. Some candidates are listed here:
Know of any Java garbage collection log analysis tools?

java basics garbage collection

is garbage collection algorithm in java "vendor implemented?"

From the introduction paragraph to Chapter 3 of the Java Virtual Machine Specification:
For example, the memory layout of
run-time data areas, the
garbage-collection algorithm used, and
any internal optimization of the Java
virtual machine instructions (for
example, translating them into machine
code) are left to the discretion of
the implementor. [emphasis mine]

Yes, and not only that, each JVM can contain more than one garbage collection strategy:
Sun
JRockit
IBM

Definitely vendor dependent. GCJ and the Sun VM use totally different garbage collectors, for example.

Yes. The Java VM Spec's don't say anything specific about garbage collection. Each vendor has their own implementation for performing GC. In fact, each vendor will have multiple GC policies that can be best chosen for a particular task.
Example
A GC tuned for throughput may not be good for real-time systems since they will have erratic (and often longer) pause times which are not predictable. Non-predictability is a killer for real-time application.
Some GC's such as the ones from Oracle and IBM are very tunable and can be tune based on your application's run-time memory characteristics.
The internals of GC are not too complicated at a higher level. Many algorithms that began in the early days of LISP are still in use today.
Read this (http://nd.edu/~dthain/courses/cse40243/spring2006/gc-survey.pdf "GC Introduction") for a good introduction to Garbage Collection at a moderately high-level.

Yes. The Java VirtualMachine Specification don't say anything specific about garbage collection. Each vendor has their own implementation for performing the task.
each can automatically calls garbage collector, then we didn't need manual calls for garbage collection

Updating from Java 1.4.2 to Java 6 (both Sun VMs) results in slower performance

I've just upgraded some old Java source which has been running on a Sun Java 1.4.2 VM to Sun Java (JRE) 6 VM. More or less the only thing I had to change was to add explicit datatypes for some abstract objects (Hashmap's, Vector's and so on). The code itself it quite memory intensive, using up to 1G of heap memory (using -Xmx1024m as a parameter to start the VM).
Since I read alot about better performance on newer Java VM's, this was one of the reasons I did this upgrade.
Can anyone think of a reason why the performance is worse in my case now (just in general, of course, since you can't take a look at the code)?
Has anyone some advice for a non Java guru what to look for if I wanted to optimize (speed wise) existing code? Any hints, recommended docs, tools?
Thanks.

Not much information here. But here are a couple of things you might want to explore:
Start the VM with Xmx and Xms as the same value (in your case 1024M)
Ensure that the server jvm dll is being used to start the virtual machine.
Run a profiler to see what objects are hogging memory or what objects are not being garbage collected
Hook up your VM with the jconsole and trace through the objects

If your application nearly runs out of free space, garbage collection time may dominate computation time.
Enable gc debugging to look for this. Or, even better, simply start jconsole and attach it to your program.

Theoretically it could be that you application consumes more memory, because there were changes to the way Strings share their internal char[]. Less sharing is done after 1.4.
Check my old blog at http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/5100 (new blog is here)
I would compare the Garbage Collector logs to see whether memory usage is really the problem.
If that doesn't help, us a profiler such as Yourkit to find the differences.

Definitely use a profiler on the app (YourKit is great)...it's easy to waste a lot of time guessing at the problem when most of the time you'll be able to narrow it down really quickly in the profiler.