This guide applies to the substratevm directory.
substratevmis anmxsuite for GraalVM Native Image. It provides the native-image tool that is part of GraalVM.- Most code lives under
src/, with one directory per module, for examplesrc/com.oracle.svm.core,src/com.oracle.svm.hosted,src/com.oracle.svm.graal, andsrc/com.oracle.svm.test. - Java sources are typically under
src/<module>/src/com/oracle/.... - Use
docs/for developer documentation,ci/for CI configuration, andmx.substratevm/for suite metadata. - Treat
mxbuild/,svmbuild/, andsources/as generated output.
Run commands from this directory.
mx build: compile the suite; run this before tests or image builds so changed sources are rebuilt.mx checkstyle: validate style and formatting expectations before sending a change.mx native-unittest [options]: runs tests for this suite.mx helloworld [options]: quick smoke test with a basic hello-world application.mx native-image [options] -cp <classpath> <mainClass>: use this as thenative-imagebuild-tool when building an image is requested as part of substratevm development workflows.
If a failure looks inconsistent with the checked-out sources, run mx clean and then mx build before deeper debugging.
Do not run mx commands concurrently; parallel runs can produce misleading failures.
- If you touch documented behavior, update
docs/. - Do not commit generated output from
mxbuild/,svmbuild/,graal_dumps/, orsources/. - Be careful when changing
mx native-unittest/svmjunitfeature registration. Features added to the shared native test image affect unrelated tests too. - Do not register production ImageSingletons or other global runtime markers from shared
svmjunittest features. In particular, avoid making the shared test image look like a different product or launch mode, such as alibjvmimage. - If a test needs product-specific global state, prefer a targeted image or test-specific setup over adding that state to the global native-unit-test feature list in
mx.substratevm/mx_substratevm.py.