anchor.diff:          JBP_CONFIG_OPEN_JDK_JRE: '[memory_calculator: {memory_sizes: {native: 150m}}]'
       ```
   
  -    In this example, `150m` of the overall available `1G` are reserved for anything that is not `heap`, `metaspace`, or `permgen`. In less common cases, this may come from companion processes started by the JVM, such as the [Process API](https://docs.oracle.com/javase/8/docs/api/java/lang/Process.html).
  -
  -* **Cause 2 - High thread count**: Java threads in the JVM can cause memory errors at the Garden level. When an app is under a heavy load, it uses a high number of threads and consumes a significant amount of memory.
  +    This example shows that `150m` of the overall available `1G` is reserved for anything that is not `heap`, `metaspace`, or `permgen`. In less common cases, this may come from companion processes started by the JVM, such as the [Process API](https://docs.oracle.com/javase/8/docs/api/java/lang/Process.html).
  +
  +* **Cause 2 - High thread count**: Java threads in the JVM can cause memory errors at the Garden level. When an app is under heavy load, it uses a high number of threads and consumes a significant amount of memory.
   
   * **Solution 2**: Set the reserved memory for stack traces to the correct value for your app.
  -
  -    You can use the `stack` [setting](https://github.com/cloudfoundry/java-buildpack/blob/master/docs/jre-open_jdk_jre.md#memory-sizes) of the memory calculator to configure the amount of 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 estimated max thread count for an app is `800` and the amount of memory to represent the deepest stacktrace of a Java thread is `512KB`, you can configure the memory calculator as follows:
  +<br>
  +<br>You can use the `stack` [setting](https://github.com/cloudfoundry/java-buildpack/blob/master/docs/jre-open_jdk_jre.md#memory-sizes) of the memory calculator to configure the amount of space the JVM reserves for each Java thread. You must multiply this value by the number of threads your app requires. Specify the number 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 you estimate the max thread count for an app at `800` and the amount of memory needed to represent the deepest stacktrace of a Java thread is `512KB`, configure the memory calculator as follows:
   
       ```
       ---
  
positive.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 error appears when the JVM allocates more OS-level memory than the quota requested by the app, such as [through the manifest](https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#memory).
  
  * **Cause 1 - Insufficient native memory**: This error commonly means that the JVM requires more `native` memory. In the scope of the Java buildpack and the memory calculator, the term `native` means the memory required for the JVM to work, along with forms of memory not covered in the other classifications of the memory calculator. 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.
  
  * **Solution 1**: Determine how much `native` memory a Java app needs by [measuring it](https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html) with realistic workloads and fine-tuning it accordingly.
  You can then configure the Java buildpack using the `native` [setting](https://github.com/cloudfoundry/java-buildpack/blob/master/docs/jre-open_jdk_jre.md#memory-sizes) of the memory calculator, as in the example below:
  
negative.code:     </pre>
  
      You can determine whether or not the path was specified for a previously
      pushed application by examining the application deployment manifest,
      `manifest.yml`.
      If the `path` attribute specifies the current directory, the manifest
      includes a line like the following:
  
      ```
      path: .
      ```
      To re-push just the WAR, do one of the following:
  
      * Delete `manifest.yml` and run `cf push` again, specifying the location of 
      the WAR using the `-p` flag.
      * Edit the `path` argument in `manifest.yml` to point to the WAR, and
      re-push the application.
  
  