Proposal: Support for GraalVM Native

[sgammon]

This changeset proposes support for invocation of Closure Compiler on the command line, via a GraalVM Native Image binary.

Using the rules_graal package, there is now a target for the compiler in native binary form. Downstream, projects can load a bzl file to download a binary distribution for their platform, and run Closure in their own projects without needing to build the compiler.

Included is a small benchmark tool which compares a fresh native vs. JVM copy on your own system. In preliminary tests (in SIMPLE mode only, for now), macOS M1 sees about 70% faster compile time versus execution through a JVM.

Enclosed arch support:

• Linux x86_64
• macOS arm64
• macOS x86_64
• Windows x86_64

Building and testing

Clone with:

git clone git@github.com:sgammon/closure-compiler.git -b native && cd ./closure-compiler

Build with:

bazel build //:compiler_native

Benchmark with:

make -C native/bench reports

Impact & Benchmark results

Impact to the Bazel build: about 60s. About 3s if the non-native compiler is built directly. Running a SIMPLE-mode compilation against react, lodash, and jquery, averaged over 50 iterations, is shown below:

Test Environment (macOS)

• OS: macOS 12.4 Monterey
• Arch: ARM64 M1
• Bazel: 5.1.1

make -C native/bench reports

| Bundle: react.development
|
| Build times:
| - JVM:    1692ms
| - Native: 507ms
| -------------------
| Diff:     1185ms (+70%)


| Bundle: lodash
|
| Build times:
| - JVM:    2254ms
| - Native: 807ms
| -------------------
| Diff:     1447ms (+64%)


| Bundle: jquery
|
| Build times:
| - JVM:    2237ms
| - Native: 789ms
| -------------------
| Diff:     1448ms (+65%)

Test Environment (Linux)

• OS: Ubuntu 20.04
• Arch: x86_64 (AMD Milan, T2D on GCE)
• Bazel: 5.1.1

| Bundle: react.development
|
| Build times:
| - JVM:    3151ms
| - Native: 942ms
| -------------------
| Diff:     2209ms (+70%)

| Bundle: lodash
|
| Build times:
| - JVM:    4292ms
| - Native: 1795ms
| -------------------
| Diff:     2497ms (+58%)

| Bundle: jquery
|
| Build times:
| - JVM:    3991ms
| - Native: 1587ms
| -------------------
| Diff:     2404ms (+60%)

Using the binaries in downstream Bazel projects

In your WORKSPACE:

http_archive(
    name = "closure_compiler",
    sha256 = "875afc7f2dd95a03eb2dda1f978767bb35a89318e2cc28232f265238bc428dbf",
    strip_prefix = "closure-compiler-9de8c8e04149c068c7a24f540b69073edab5e1c5/defs",
    url = "https://github.com/sgammon/closure-compiler/archive/9de8c8e04149c068c7a24f540b69073edab5e1c5.tar.gz",
)

load("@closure_compiler//:closure_bindist.bzl", "closure_compiler_bindist_repository")

closure_compiler_bindist_repository(
    name = "closure",
    version = "v20220612",
)

Then, from inside your project:

bazel run @closure//:compiler -- --help

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[sgammon]

dear google,

if there is interest in merging this fork/PR, please let me know and I'm happy to help produce binaries for Windows and x86 macOS, and perhaps crafting some benchmarks for more advanced use of closure.

[brad4d]

@sgammon
https://github.com/google/closure-compiler-npm
Already builds Graal-compiled versions of the compiler and makes them available via NPM.

I believe we would really prefer to keep such OSS-specific custom build logic there.

Perhaps you would like to see if there are improvements you could make to the way it is building Graal-based binaries?

[sgammon]

@brad4d understood, i was not aware of that and will take a look. however, the intent of contributing this here was to provide an easy binary invocation from Bazel-native projects downstream. i'll give this a try through rules_nodejs, but using that infrastructure just to load the Closure binary involves downloading a lot of rule code that otherwise might not be needed (for instance, in JVM projects like ours).