|
| 1 | +# GraalVM JRE |
| 2 | +The GraalVM JRE provides Java runtimes from [GraalVM][] project. No versions of the JRE are available be default due to licensing restrictions. Instead you will need to create a repository with the GraalVM JREs in it and configure the buildpack to use that repository. Unless otherwise configured, the version of Java that will be used is specified in [`config/graal_vm_jre.yml`][]. |
| 3 | + |
| 4 | +<table> |
| 5 | + <tr> |
| 6 | + <td><strong>Detection Criterion</strong></td> |
| 7 | + <td>Unconditional. Existence of a single bound Volume Service will result in Terminal heap dumps being written. |
| 8 | + <ul> |
| 9 | + <li>Existence of a Volume Service service is defined as the <a href="http://docs.cloudfoundry.org/devguide/deploy-apps/environment-variable.html#VCAP-SERVICES"><code>VCAP_SERVICES</code></a> payload containing a service who's name, label or tag has <code>heap-dump</code> as a substring.</li> |
| 10 | + </ul> |
| 11 | + </td> |
| 12 | + </tr> |
| 13 | + <tr> |
| 14 | + <td><strong>Tags</strong></td> |
| 15 | + <td><tt>open-jdk-like-jre=⟨version⟩, open-jdk-like-memory-calculator=⟨version⟩, jvmkill=⟨version⟩</tt></td> |
| 16 | + </tr> |
| 17 | +</table> |
| 18 | +Tags are printed to standard output by the buildpack detect script |
| 19 | + |
| 20 | +**NOTE:** Unlike the [OpenJDK JRE][], this JRE does not connect to a pre-populated repository. Instead you will need to create your own repository by: |
| 21 | + |
| 22 | +1. Downloading the GraalVM JRE binary (in TAR format) to an HTTP-accesible location |
| 23 | +1. Uploading an `index.yml` file with a mapping from the version of the JRE to its location to the same HTTP-accessible location |
| 24 | +1. Configuring the [`config/graal_vm_jre.yml`][] file to point to the root of the repository holding both the index and JRE binary |
| 25 | +1. Configuring the [`config/components.yml`][] file to disable the OpenJDK JRE and enable the GraalVM JRE |
| 26 | + |
| 27 | +For details on the repository structure, see the [repository documentation][repositories]. |
| 28 | + |
| 29 | +## Configuration |
| 30 | +For general information on configuring the buildpack, including how to specify configuration values through environment variables, refer to [Configuration and Extension][]. |
| 31 | + |
| 32 | +The JRE can be configured by modifying the [`config/graal_vm_jre.yml`][] file in the buildpack fork. The JRE uses the [`Repository` utility support][repositories] and so it supports the [version syntax][] defined there. |
| 33 | + |
| 34 | +To use GraalVM JRE instead of OpenJDK without forking java-buildpack, set environment variable and restage: |
| 35 | + |
| 36 | +```bash |
| 37 | +cf set-env <app_name> JBP_CONFIG_COMPONENTS '{ jres: [ "JavaBuildpack::Jre::GraalVmJRE" ] }' |
| 38 | +cf set-env <app_name> JBP_CONFIG_GRAAL_VM_JRE '{ jre: { repository_root: "<INTERNAL_REPOSITORY_URI>" } }' |
| 39 | +cf restage <app_name> |
| 40 | +``` |
| 41 | + |
| 42 | +| Name | Description |
| 43 | +| ---- | ----------- |
| 44 | +| `jre.repository_root` | The URL of the GraalVM repository index ([details][repositories]). |
| 45 | +| `jre.version` | The version of Java runtime to use. Candidate versions can be found in the the repository that you have created to house the JREs. |
| 46 | +| `jvmkill.repository_root` | The URL of the `jvmkill` repository index ([details][repositories]). |
| 47 | +| `jvmkill.version` | The version of `jvmkill` to use. Candidate versions can be found in the listings for [bionic][jvmkill-bionic]. |
| 48 | +| `memory_calculator` | Memory calculator defaults, described below under "Memory". |
| 49 | + |
| 50 | +### Additional Resources |
| 51 | +The JRE can also be configured by overlaying a set of resources on the default distribution. To do this, add files to the `resources/graal_vm_jre` directory in the buildpack fork. |
| 52 | + |
| 53 | +#### Custom CA Certificates |
| 54 | +To add custom SSL certificates, add your `cacerts` file to `resources/graal_vm_jre/lib/security/cacerts`. This file will be overlayed onto the GraalVM distribution. |
| 55 | + |
| 56 | +### `jvmkill` |
| 57 | +The `jvmkill` agent runs when an application has experience a resource exhaustion event. When this event occurs, the agent will print out a histogram of the first 100 largest types by total number of bytes. |
| 58 | + |
| 59 | +```plain |
| 60 | +Resource exhaustion event: the JVM was unable to allocate memory from the heap. |
| 61 | +ResourceExhausted! (1/0) |
| 62 | +| Instance Count | Total Bytes | Class Name | |
| 63 | +| 18273 | 313157136 | [B | |
| 64 | +| 47806 | 7648568 | [C | |
| 65 | +| 14635 | 1287880 | Ljava/lang/reflect/Method; | |
| 66 | +| 46590 | 1118160 | Ljava/lang/String; | |
| 67 | +| 8413 | 938504 | Ljava/lang/Class; | |
| 68 | +| 28573 | 914336 | Ljava/util/concurrent/ConcurrentHashMap$Node; | |
| 69 | +``` |
| 70 | + |
| 71 | +It will also print out a summary of all of the memory spaces in the JVM. |
| 72 | + |
| 73 | +```plain |
| 74 | +Memory usage: |
| 75 | + Heap memory: init 65011712, used 332392888, committed 351797248, max 351797248 |
| 76 | + Non-heap memory: init 2555904, used 63098592, committed 64815104, max 377790464 |
| 77 | +Memory pool usage: |
| 78 | + Code Cache: init 2555904, used 14702208, committed 15007744, max 251658240 |
| 79 | + PS Eden Space: init 16252928, used 84934656, committed 84934656, max 84934656 |
| 80 | + PS Survivor Space: init 2621440, used 0, committed 19398656, max 19398656 |
| 81 | + Compressed Class Space: init 0, used 5249512, committed 5505024, max 19214336 |
| 82 | + Metaspace: init 0, used 43150616, committed 44302336, max 106917888 |
| 83 | + PS Old Gen: init 43515904, used 247459792, committed 247463936, max 247463936 |
| 84 | +``` |
| 85 | + |
| 86 | +If a [Volume Service][] with the string `heap-dump` in its name or tag is bound to the application, terminal heap dumps will be written with the pattern `<CONTAINER_DIR>/<SPACE_NAME>-<SPACE_ID[0,8]>/<APPLICATION_NAME>-<APPLICATION_ID[0,8]>/<INSTANCE_INDEX>-<TIMESTAMP>-<INSTANCE_ID[0,8]>.hprof` |
| 87 | + |
| 88 | +```plain |
| 89 | +Heapdump written to /var/vcap/data/9ae0b817-1446-4915-9990-74c1bb26f147/pcfdev-space-e91c5c39/java-main-application-892f20ab/0-2017-06-13T18:31:29+0000-7b23124e.hprof |
| 90 | +``` |
| 91 | + |
| 92 | +### Memory |
| 93 | +The total available memory for the application's container is specified when an application is pushed. |
| 94 | +The Java buildpack uses this value to control the JRE's use of various |
| 95 | +regions of memory and logs the JRE memory settings when the application starts or restarts. |
| 96 | +These settings can be influenced by configuring |
| 97 | +the `stack_threads` and/or `class_count` mappings (both part of the `memory_calculator` mapping), |
| 98 | +and/or Java options relating to memory. |
| 99 | + |
| 100 | +Note: If the total available memory is scaled up or down, the Java buildpack will re-calculate the JRE memory settings the next time the application is started. |
| 101 | + |
| 102 | +#### Total Memory |
| 103 | + |
| 104 | +The user can change the container's total memory available to influence the JRE memory settings. |
| 105 | +Unless the user specifies the heap size Java option (`-Xmx`), increasing or decreasing the total memory |
| 106 | +available results in the heap size setting increasing or decreasing by a corresponding amount. |
| 107 | + |
| 108 | +#### Loaded Classes |
| 109 | + |
| 110 | +The amount of memory that is allocated to metaspace and compressed class space (or, on Java 7, the permanent generation) is calculated from an estimate of the number of classes that will be loaded. The default behaviour is to estimate the number of loaded classes as a fraction of the number of class files in the application. |
| 111 | +If a specific number of loaded classes should be used for calculations, then it should be specified as in the following example: |
| 112 | + |
| 113 | +```yaml |
| 114 | +class_count: 500 |
| 115 | +``` |
| 116 | +
|
| 117 | +#### Headroom |
| 118 | +
|
| 119 | +A percentage of the total memory allocated to the container to be left as headroom and excluded from the memory calculation. |
| 120 | +
|
| 121 | +```yaml |
| 122 | +headroom: 10 |
| 123 | +``` |
| 124 | +
|
| 125 | +#### Stack Threads |
| 126 | +
|
| 127 | +The amount of memory that should be allocated to stacks is given as an amount of memory per thread with the Java option `-Xss`. If an explicit number of threads should be used for the calculation of stack memory, then it should be specified as in the following example: |
| 128 | + |
| 129 | +```yaml |
| 130 | +stack_threads: 500 |
| 131 | +``` |
| 132 | + |
| 133 | +Note that the default value of 250 threads is optimized for a default Tomcat configuration. If you are using another container, especially something non-blocking like Netty, it's more appropriate to use a significantly smaller value. Typically 25 threads would cover the needs of both the server (Netty) and the threads started by the JVM itself. |
| 134 | + |
| 135 | +#### Java Options |
| 136 | + |
| 137 | +If the JRE memory settings need to be fine-tuned, the user can set one or more Java memory options to |
| 138 | +specific values. The heap size can be set explicitly, but changing the value of options other |
| 139 | +than the heap size can also affect the heap size. For example, if the user increases |
| 140 | +the maximum direct memory size from its default value of 10 Mb to 20 Mb, then this will |
| 141 | +reduce the calculated heap size by 10 Mb. |
| 142 | + |
| 143 | +#### Memory Calculation |
| 144 | +Memory calculation happens before every `start` of an application and is performed by an external program, the [Java Buildpack Memory Calculator]. There is no need to `restage` an application after scaling the memory as restarting will cause the memory settings to be recalculated. |
| 145 | + |
| 146 | +The container's total available memory is allocated into heap, metaspace and compressed class space (or permanent generation for Java 7), |
| 147 | +direct memory, and stack memory settings. |
| 148 | + |
| 149 | +The memory calculation is described in more detail in the [Memory Calculator's README]. |
| 150 | + |
| 151 | +The inputs to the memory calculation, except the container's total memory (which is unknown at staging time), are logged during staging, for example: |
| 152 | +``` |
| 153 | +Loaded Classes: 13974, Threads: 300, JAVA_OPTS: '' |
| 154 | +``` |
| 155 | + |
| 156 | +The container's total memory is logged during `cf push` and `cf scale`, for example: |
| 157 | +``` |
| 158 | + state since cpu memory disk details |
| 159 | +#0 running 2017-04-10 02:20:03 PM 0.0% 896K of 1G 1.3M of 1G |
| 160 | +``` |
| 161 | + |
| 162 | +The JRE memory settings are logged when the application is started or re-started, for example: |
| 163 | +``` |
| 164 | +JVM Memory Configuration: -XX:MaxDirectMemorySize=10M -XX:MaxMetaspaceSize=99199K \ |
| 165 | + -XX:ReservedCodeCacheSize=240M -XX:CompressedClassSpaceSize=18134K -Xss1M -Xmx368042K |
| 166 | +``` |
| 167 | + |
| 168 | +[`config/components.yml`]: ../config/components.yml |
| 169 | +[`config/graal_vm_jre.yml`]: ../config/graal_vm_jre.yml |
| 170 | +[Configuration and Extension]: ../README.md#configuration-and-extension |
| 171 | +[Java Buildpack Memory Calculator]: https://github.com/cloudfoundry/java-buildpack-memory-calculator |
| 172 | +[jvmkill-bionic]: https://java-buildpack.cloudfoundry.org/jvmkill/bionic/x86_64/index.yml |
| 173 | +[Memory Calculator's README]: https://github.com/cloudfoundry/java-buildpack-memory-calculator |
| 174 | +[OpenJDK JRE]: jre-open_jdk_jre.md |
| 175 | +[GraalVM]: https://www.graalvm.org/ |
| 176 | +[repositories]: extending-repositories.md |
| 177 | +[version syntax]: extending-repositories.md#version-syntax-and-ordering |
| 178 | +[Volume Service]: https://docs.cloudfoundry.org/devguide/services/using-vol-services.html |
0 commit comments