Understanding you GC goals:

Application Throughput

– What is the % of time you are willing to hand over to GC activity?
– Typically Application throughput should be 95%+ and correspondingly GC throughput should be <5%

Pause time

– What idividual pauses you are willing to put up with?  For example, “2 ~3 second pauses a day and  rest < 100ms”

Footprint (Heapsize)

– How much heap you can allocate/afford?  Ok understand, memory is cheap now a days but could be expensive in virtualised environments.

Garbage Collector Policy:

For large server applications

-XX:+UseParallelGC 
     - parallel (throughput) garbage collector

 -XX:+UseConcMarkSweepGC 
     - concurrent (low pause time) garbage collector (also known as CMS)
 
-XX:+UseG1GC 
     - Garbage First Garbage Collector, G1 is designed to be a low configuration, low pause collector for large heaps, Use G1 when you have loads of memory and don’t care too much about burning CPU.
     - Only available from jdk7 onwards.

For smaller applications and systems

-XX:+UseSerialGC serial garbage collector

Useful Options:

-XX:MaxGCPauseMillis=200
 -XX:+DisableExplicitGC
 -XX:+UnlockDiagnosticVMOptions
 -XX:+PrintFlagsFinal
 -XX:+UnlockExperimentalVMOptions
 

-Xss128k

Reduces the default maximum thread stack size, which allows more of the process' virtual memory address space to be used by the Java heap.

-XX:+UseParallelGC

Selects the parallel garbage collector for the new generation of the Java heap (note: this is generally the default on server-class machines)

-XX:ParallelGCThreads=20

Reduces the number of garbage collection threads. The default would be equal to the processor count, which would probably be unnecessarily high on a 32 thread capable system.

-XX:+UseParallelOldGC

Use the parallel old generation collector. Certain phases of an old generation collection can be performed in parallel, speeding up a old generation collection.

-XX:+AggressiveOpts

Turns on point performance optimizations that are expected to be on by default in upcoming releases. The changes grouped by this flag are minor changes to JVM runtime compiled code and not distinct performance features (such as BiasedLocking and ParallelOldGC). This is a good flag to try the JVM engineering team's latest performance tweaks for upcoming releases. Note: this option is experimental! The specific optimizations enabled by this option can change from release to release and even build to build. You should reevaluate the effects of this option with prior to deploying a new release of Java.

-XX:+UseBiasedLocking

Enables a technique for improving the performance of uncontended synchronization. An object is "biased" toward the thread which first acquires its monitor via a monitorenter bytecode or synchronized method invocation; subsequent monitor-related operations performed by that thread are relatively much faster on multiprocessor machines. Some applications with significant amounts of uncontended synchronization may attain significant speedups with this flag enabled; some applications with certain patterns of locking may see slowdowns, though attempts have been made to minimize the negative impact.

-XX:+UseConcMarkSweepGC -XX:+UseParNewGC

Selects the Concurrent Mark Sweep collector. This collector may deliver better response time properties for the application (i.e., low application pause time). It is a parallel and mostly-concurrent collector and and can be a good match for the threading ability of an large multi-processor systems.

-XX:SurvivorRatio=8

Sets survivor space ratio to 1:8, resulting in larger survivor spaces (the smaller the ratio, the larger the space). Larger survivor spaces allow short lived objects a longer time period to die in the young generation.

-XX:TargetSurvivorRatio=90

Allows 90% of the survivor spaces to be occupied instead of the default 50%, allowing better utilization of the survivor space memory.

-XX:MaxTenuringThreshold=31

Allows short lived objects a longer time period to die in the young generation (and hence, avoid promotion). A consequence of this setting is that minor GC times can increase due to additional objects to copy. This value and survivor space sizes may need to be adjusted so as to balance overheads of copying between survivor spaces versus tenuring objects that are going to live for a long time. The default settings for CMS are SurvivorRatio=1024 and MaxTenuringThreshold=0 which cause all survivors of a scavenge to be promoted. This can place a lot of pressure on the single concurrent thread collecting the tenured generation. Note: when used with -XX:+UseBiasedLocking, this setting should be 15.

Enable "ResourceManagement" to use the WebLogic Server "Resource Consumption Management" feature. 
To enable "ResourceManagement", you must specify the following JVM options in the WebLogic Server instance in which the JVM runs

-XX:+UnlockCommercialFeatures
-XX:+ResourceManagement

Some Examples:

-Xms2048m -Xmx2048m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+DisableExplicitGC -XX:+PrintGCDetails and -XX:+PrintGCTimeStamps -verbosegc -Xloggc:gc-log.log -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M

I found this article to be very useful,

Tuning Garbage Collection for Mission-Critical Java Applications – From MGM Technology Partners

Controlling GC pauses with the GarbageFirst Collector