anchor.diff:  
   ### <a id='memory-troubleshoot'></a>Troubleshoot Out Of Memory ###
   
  -A Java application can be killed due to memory issues at the level of either the Garden container or the JVM.
  -
  -In case the JVM cannot garbage-collect enough space to ensure the allocation of a data-structure, it will fail with an [java.lang.OutOfMemoryError](https://docs.oracle.com/javase/8/docs/api/java/lang/OutOfMemoryError.html).
  -The `java.lang.OutOfMemoryError` will show up in the logs of the application and can be retrieved via the `cf logs` command.
  -For example:
  -
  -<pre class="terminal">
  -$ cf logs APP-NAME --recent
  -
  -2016-06-20T09:18:51.00+0100 [APP/0] OUT java.lang.OutOfMemoryError: Metaspace   
  -</pre>
  -
  -In the example above, the issue comes from the JVM having an under-sized `metaspace`.
  -Failures in other memory pools, e.g., `heap` are of course also possible.
  -This type of issues are solved by [correcting the configurations](#memory) of the JVM.
  -
  -The termination of the Java process by the Garden container is somewhat more subtle.
  -The Garden container will terminate the Java process when the actual OS-level memory the JVM has <strong>allocated</strong> (i.e., actually "taken" from the OS) more memory than the quota requested by the application, e.g., [via the manifest](https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#memory).
  -It will look like the following:
  +A Java app may crash because of insufficient memory on the Garden container or the JVM. See the following sections for help diagnosing the issue.
  +
  +#### JVM 
  +
  +* **Error**: `java.lang.OutOfMemoryError`. See the following example.
  +    <pre class="terminal">
  +    $ cf logs APP-NAME --recent
  +    2016-06-20T09:18:51.00+0100 [APP/0] OUT java.lang.OutOfMemoryError: Metaspace   
  +    </pre>
  +* **Cause**: If the JVM cannot garbage-collect enough space to ensure the allocation of a data-structure, it fails with [java.lang.OutOfMemoryError](https://docs.oracle.com/javase/8/docs/api/java/lang/OutOfMemoryError.html). In the example above, JVM has an under-sized `metaspace`. You may see failures in other memory pools, such as `heap`.
  +* **Solution**: Correct the configurations of the JVM. See [Allocate Sufficient Memory](#memory).
  +
  +#### Garden Container
  +
  +The Garden container terminates the Java process when the actual OS-level memory the JVM has <strong>allocated</strong> (i.e., actually "taken" from the OS) more memory than the quota requested by the application, e.g., [via the manifest](https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#memory). See the following example error:
   
   <pre class="terminal">
   $ cf events APP-NAME
  
positive.code:     JBP_CONFIG_OPEN_JDK_JRE: '[memory_calculator: {stack_threads: 800, memory_sizes: {native: 150m, stack: 512k}}]'
  </pre>
  
  In the example above (which skips any setting not directly related to native memory and threads), the overall memory amount reserved by the JVM for representing the stacks of Java threads is `800 * 512k = 400m`.
  Additional `150m` of the overall available `1G` are reserved anything that is not `heap`, `metaspace` or `permgen` (the "precursor" of `metaspace` on pre-Java 8 JVMs).
  
  The right settings for `stack` and `stack_threads` depend on the application's code (including, of course, the libraries it uses).
  For example, the maximum amount of threads an application may use under load depends on the application implementation.
  It may even be the case that an application has factually no upper limit, e.g., by [cavalier usage](http://dev.bizo.com/2014/06/cached-thread-pool-considered-harmlful.html) of [`CachedThreadPool` executors](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors.html#newCachedThreadPool--).
  The same, of course, applies to how "deep" the thread stacks can be, and thus how much space the JVM should reserve for each of them.
  
  ### <a id='upload'></a>Troubleshoot Failed Upload ###
  
  
negative.code: 2016-06-20T09:18:51.00+0100   app.crash     app-name      index: 0, reason: CRASHED, exit_description: out of memory, exit_status: 255
  </pre>
  
  This type of error commonly means that the JVM requires more `native` memory.
  In less common cases, this may come from companion processes started by the JVM, e.g., via the [Process API](https://docs.oracle.com/javase/8/docs/api/java/lang/Process.html).
  
  In the scope of the Java buildpack and the `memory calculator`, the term `native` means all memory allocated by the JVM that cannot be restrained specifically. This includes the memory footprint of OS-level threads, [direct NIO buffers](https://docs.oracle.com/javase/8/docs/api/java/nio/ByteBuffer.html), code cache, program counters, and more.
  It is difficult to determine how much `native` memory a Java app needs. A best practice is to [measure it](https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html) with realistic workloads and fine-tune it accordingly.
  The memory calculator supports configuration via the [`native` setting](https://github.com/cloudfoundry/java-buildpack/blob/master/docs/jre-open_jdk_jre.md#memory-sizes)
  
  A particularly important setting to deal with memory errors at Garden level is the footprint of Java threads in the JVM.
  The stack traces of Java threads are stored outside the heap.
  The JVM reserves a fixed amount of memory space for every thread, which normally one can configure with the [`stack` setting](https://github.com/cloudfoundry/java-buildpack/blob/master/docs/jre-open_jdk_jre.md#memory-sizes) of the memory calculator.
  
  The `stack` setting of the memory calculator configures how much space the JVM reserves for each Java thread. You must multiply this value by how many threads your app requires. You can specify the amount of threads in the [`stack_threads` setting](https://github.com/jdeoliveira/mule-cf-java-buildpack/blob/master/docs/jre-open_jdk_jre.md#memory) of the memory calculator.
  For example, if the estimation of the maximum amount of threads by an application is `800` and the amount of memory to represent the deepest stacktrace of a Java thread is `512KB`, the memory calculator can be configured with:
  
  <pre>
  