How to try Static Hermes

[philipheinser]

Are there binaries distributed to try out Static Hermes or should you build it by yourself from the branch?

[shihabmridha]

I cloned the repo, switched to static_h branch, and built the project using this document. It generates hermes and shermes in the build/bin/ directory. But, when I run the following code using the hermes index.js command I get the following error.

> hermes index.js
LLVM ERROR: Generating HBC bytecode disabled in Static Hermes

You can execute static-hermes bin though using the command below.

> shermes -typed -exec ./index.js
6 ms, 3.7330486176528693e+164

Code I tried to execute:

function bench (lc, fc) {
    var n, fact;
    var res = 0;
    while (--lc >= 0) {
        n = fc;
        fact = n;
        while (--n > 1)
            fact *= n;
        res += fact;
    }
    return res;
}

let t1 = Date.now();
var res = bench(4e6, 100);
print(Date.now() - t1, "ms,", res);

Unrelated (without the print function call):
time shermes -typed -exec index.js
0.12s user 0.09s system 22% cpu 0.938 total
time node index.js
0.42s user 0.03s system 85% cpu 0.532 total
time bun index.js
0.30s user 0.03s system 89% cpu 0.363 total

[tmikov]

time shermes -typed -exec index.js

Just want to point out that this is measuring the time to compile and link a native binary on disk.

[tmikov]

There are no binaries, and be warned: it is not ready to be tried out, since what works or doesn't is not documented, or it may even change or regress from commit to commit.

With that said, if you insist on trying it, you need to build it.

[gauravgautamapptile]

Hello, I am also very curious about static hermes. I tried to compile it and run it and was able to do some things. I noted down my steps here: https://medium.com/@gautam1168/compiling-typescript-to-native-code-0238d69ca582

I am not sure if sharing this is not appreciated since I am obviously not familiar with hermes and so might have done many things that could mislead someone. If that is the case you can delete my comment or I will if you tell me to.

[tmikov]

We absolutely welcome posts like this and thank you for sharing it.

I would add just a few clarifications:

1. The instructions in your blog post compile Static Hermes in debug mode, so it will be very slow.
2. The C output is a temporary feature to simplify our development (C code is easier to understand than LLVM IR). You can use -g to annotate it with #line directives, which actually enable you to partially debug the original JS in a native debugger.
3. TypeScript support is experimental and incomplete (but we are always improving it).

[thejustinwalsh]

I was able to get the benchmarks building using the following...

cmake -S hermes/benchmarks -B build_benchmarks -DHERMES_BUILD=/absolute/path/to/hermes/build -DHERMES_SRC=/absolute/path/to/hermes
cmake --build ./build_benchmarks 

The raytracer benchmark is a wonderful example of a full application using shermes, as it has bindings to ImGui, and uses sokol to get a window and rendering context setup.

I was going to take a stab at some Raylib bindings after I dig into ffigen a bit deeper.

[tmikov]

Really cool! BTW, we are still working on the performance of that benchmark, it will get faster.

[gauravgautamapptile]

Hello, I had not even expected that my post will be read by so many people including yourself. This email made my morning. I will update my post tonight to note how to compile in release mode. And I was going to try debugging using visual studio. I will attempt to get the typescript code to show up in my native debugger. Thankyou for that pointer. Yours sincerely, Gaurav Gautam

…

On Thu, 5 Oct 2023 at 23:15, Tzvetan Mikov ***@***.***> wrote: We absolutely welcome posts like this and thank you for sharing it. I would add just a few clarifications: 1. The instructions in your blog post compile Static Hermes in debug mode, so it will be very slow. 2. The C output is a temporary feature to simplify our development (C code is easier to understand than LLVM IR). You can use -g to annotate it with #line directives, which actually enable you to partially debug the original JS in a native debugger. 3. TypeScript support is experimental and incomplete (but we are always improving it). — Reply to this email directly, view it on GitHub <#1137 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBZ6O4CSECQVWXDZS4AHJJTX53W27AVCNFSM6AAAAAA5N3XTHCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TEMBRGUZTS> . You are receiving this because you commented.Message ID: ***@***.***>

[thejustinwalsh]

I spent an evening creating a turn-key example of using shermes with typescript here:
https://github.com/thejustinwalsh/sh-raylib

I tried my best to automate a bunch of concepts found in the other examples...

• CMake generates the raylib ffi files and concats the results with the includes as a part of the build process
• Using FetchContent for both hermes and raylib to make it easier to setup the workspace
• VSCode creature comforts

hello-world: https://github.com/thejustinwalsh/sh-raylib/blob/main/src/hello-world/hello-world.ts

bunny-mark: https://github.com/thejustinwalsh/sh-raylib/blob/main/src/bunny-mark/bunny-mark.ts

Not for the faint of heart, but lots of fun to hack on!
If you are familiar with C/C++ and CMake, you will feel right at home. I had to refactor my bunny-mark.ts code a few times to work around things that were not implemented or produced unexpected results.

I still don't understand a good strategy for managing the lifetimes of the heap allocations vs the JS objects that rely on them.

I hope this helps anyone else who is interested in hacking on it.
If there are ways that you would prefer I contribute back, LMK, at this point, I am not sure if making extra noise with bugs and failing tests is warranted.

[thejustinwalsh]

@tmikov 🥳

Runtime	FPS	CPU	GPU	Memory
C	90	68%	84%	48 MB
Static Hermes	90	70%	84%	53 MB

Your changes have made this demo run at native speed. This is next level, amazing! 🚀

For the audience:

• I assumed I could only use a class with babel-transform plugins like the ones used in @react-native/babel-preset, as the docs have it listed as planned on Hermes main. This is closer to the original implementation as well, so it is a better 1:1 comparison.
• I didn't know about _sh_ptr_write_c_uint and my first attempt at this code failed when I was attempting to do pointer math with the wrong helpers. This is the way.
• This is more concise and carries the intention better, love it.

TLDR; Static Hermes is fast!

[quadband]

What does the “inline” literal expression do in the makeColor function? What is interpreting it?

[tmikov]

It marks the function as inline, so it will be inlined at every call site, regardless of its size or other heuristics.

[quadband]

Thank you. Is this Hermes Static only? I spent the last half hour trying to find a reference to it and didn’t have any luck. I appreciate you answering.

[tmikov]

Yes, it is Static Hermes only, but does no harm in other engines. It will be documented eventually, when we are close to release.

[jerrygreen]

I really want some npm install -g shermes or something.

[HarunaMahjong]

@tmikov Is there a plan for Static Hermes to support JIT compilation for bytecode that has not been AOT compiled into machine code?

[tmikov]

@HarunaMahjong there are no plans to ever implement an advanced speculating JIT similar to JSC or v8.

[HarunaMahjong]

@tmikov And one more thing to ask. Will Static Hermes support TypeScript? If so, will it compile TypeScript into JavaScript with all type information removed, or will it use some of the type information included in TypeScript for AOT compilation to native binary in Static Hermes?

This is already supported, with initial types contributed by Amazon, I believe, and a few more community contributions have happened here as well. It uses the type information to inform the AOT compilation.

@thejustinwalsh, I would like to find information about the initial types contributed by Amazon and TypeScript. Could you please provide some links?

[gauravgautamapptile]

@HarunaMahjong im not sure if this is what you are looking for but this commit has what looks like a typescript parser: https://github.com/facebook/hermes/blob/6a842d01016d86dca63d8247f9853c3c7b33ba1e/lib/Parser/JSParserImpl-ts.cpp

There are other PR's merged later on that touch this file that are from someone from amazon: #1115
#1173

From what I can understand of this (which is not much since its c++ code), its creating some AST that contains the type information. I don't know at which point this goes into the compiler though, it is much beyond my ability. However Ill try a shot in the dark:

1. This JSParserImpl-ts.cpp is an implementation of JSParser which is being linked with shermes.cpp in one of the make files
2. If you follow the #includes in shermes.cpp you will eventually get to JSParserImpl-ts.cpp. They are connected in some way.
3. In shermes.cpp there is a line which goes parsedAST = convertTSToFlow(*context, parsedAST); where the input is the AST from the typescript parser.
4. This function is invoked from compileFromCommandLineOptions, which I think is what actually compiles the ts files.
5. compileFromCommandLineOptions takes the ast and converts it to IR in the line that goes generateIRFromESTree(&M, semCtx, flowContext, ast);
6. This stores the IR in the variable M which is then passed to functions that seem like are invoking llvm in later steps like runCustomOptimizationPasses(M, cli::CustomOptimize) and runFullOptimizationPasses(M).
7. Then the PM (the passmanager) is adding what looks like optimization passes like PM.addLowerGeneratorFunction(), PM.addFunctionAnalysis();.
8. I hit a deadend if I try to get my IDE to show the code for these passes though.

So, I guess hermes will take the typescript file and convert it to an ast which was provided by the PR's above. Then convert it to a flow-ast, and then to an IR which is then optimized using optimization passes that may or may not be defined inside this codebase itself (i cannot tell). How exactly the types in the flow ast help the compiler is not known to me. But I guess it might be either helping the function that is generating the IR or it is affecting the kind of IR that is generated by that function.

To your point, I don't think this is converting typescript to javascript at any point. But the typescript ast is being converted to flow ast though. After that it goes to the llvm IR I think and never comes back to text form.

[HarunaMahjong]

@gauravgautamapptile Wow, that's a really long response. Thanks to you, I can get a rough idea of the content. Really, thank you so much.

[gauravgautamapptile]

I was trying to run the code in the 300x benchmark and I was able to follow the article. I wasn't able to setup lldb properly to step through the assembly though. Stepping would be ideal in trying to understand the compiled output instead of just looking at the assembly dumps. I am able to step through using vscode and I can see some of the things mentioned in the article there.

but is it not possible to make it step into the javascript function? I can step through the assembly but the debugger isn't able to show me the location in the javascript code. The breakpoint in the bench function doesn't fire. Only the other one does. And if I try to debug the executable using lldb console I am still not able to see the source by running list.

I created the executable using this command

~/workingdir_hermes/build_release/bin/shermes -g -o bench bench.js

and there is a bench.dSYM file in the directory alongside the bench executable so I think the debugging symbols are there. But somehow my lldb can't figure it out maybe? Im new to trying to debug assembly so is there something obvious Im missing here?

[SichangHe]

2700 commits ahead of main. Did you guys write any documentation 😅?

[vExcess]

@gauravgautamapptile
I can't seem to get FFI working. Whenever I run shermes -typed -exec -lmyfunc.o ./yourfile.ts I get /usr/bin/ld: cannot find -lmyfunc.o: No such file or directory. I have tried everything I can think of
shermes -typed -exec -llib/myfunc.o ./yourfile.ts
shermes -typed -exec -Llib -llib/myfunc.o ./yourfile.ts
shermes -typed -exec -lmyfunc.o ./yourfile.ts // copied the myfunc.o to the base directory
shermes -typed -exec -lmyfunc.o -Wc,-Llib,-lmyfunc.o ./yourfile.ts

Nothing works. Everything logs /usr/bin/ld: cannot find -lmyfunc.o: No such file or directory.

Lastly I tried shermes -typed -exec -lmyfunc.o -Wc,-Wl,--verbose ./yourfile.ts This should make shermes cause cc to cause the linker to be verbose, but I got another error cc: error: unrecognized command-line option ‘-Wl’; did you mean ‘-W’? even though cc --help shows that it is in fact a valid command-line option -Wl,<options> Pass comma-separated <options> on to the linker.. So I replaced it with -W and it dumped a bunch of data, but none of it indicates why the linker is failing.

Has Static Hermes changed the way that I have to link my .o file? Also I am 100% certain that the myfunc.o does in fact exist.

It'd be nice if Meta wrote documentation for the project.

[tmikov]

@vExcess please note that TextDecoder and TextEncoder are not part of the EcmaScript spec and as such no JS engine is expected to support them. Functionality like that is provided by a JS runtime like Node, Deno, Bun, a browser, etc.

It was never our projects goal to be a JS runtime - that is an undertaking of quite a different nature. Note that none of the runtimes I mentioned above are developed by the v8 or JSC teams respectively. They are separate projects, often by unrelated organizations, using the JS engine.

With that said, we are open to packaging some non-ECMAScript functionality with Hermes, for convenience. See #1072. We are hoping that the community may be able to contribute some as well.

[vExcess]

@gauravgautamapptile
I finished my article. It's a long read, but I hope it can be helpful to anyone else trying to use static hermes. Hopefully other people can get use out of the TextDecoder and TextEncoder I've ported to be shermes compatible.
https://vexcess.github.io/blog/creating-a-native-app-in-typescript

Unfortunately I was not able to get my project working. I'm hoping the static hermes devs might take a look at it and figure out why it's seg faulting at 0x00007ffff7e9388a in _sh_fastarray_load () from /home/vexcess/shermes-linux-x86_64/build_release/lib/libhermesvm.so

But I'll be taking a break from the project for a while and will be focusing on a different project where me and a few other people are attempting to create a new web browser purely in Zig.

[tmikov]

@vExcess I would be happy to help you figure out why it is crashing. Do you have a minimal repro?

[vExcess]

@tmikov
I stripped down my script to be minimal
https://github.com/vExcess/lnstat/blob/main/src-shermes/minimal.ts

It seems the seg fault is happening at args[i] because i is beyond the length of the array. i should never be out of bounds though because there is a i < args.length. But the reason it's not being stopped by this is because args.length returns 1.93239734168964e-310. But this value changes every run indicating that it's a garbage value. args is declared as args = Array_slice(process.argv, 2, process.argv.length). This makes me think something is going wrong in the Array_slice function. The function is pretty simple and works outside of shermes. Its contents are

let subArr = [];
for (let i = start; i < stop; i++) {
    subArr.push(self[i]);
}
return subArr;

My guesses of what could be going wrong are

1. shermes has a bug in the part of the code that looks up the length of an array
   or
2. shermes has a bug in its implementation of Array.prototype.push that corrupts that array
   or
3. shermes GC is prematurely freeing the array so that accessing it is returning garbage data

Edit: I should probably mention to run ./build-minimal.sh from the src-shermes directory to build the executable and then you can run ./minimal

[avp]

Thanks for the repro, this is a case of incomplete type-inference behavior as it relates to SH's current implementation of "fast arrays", combined with incomplete runtime typechecking behavior. The type inference and runtime type checking are still works in progress.

Doing let subArr = []; isn't allocating a SH fast typed array (instead, it's making an ordinary untyped JS array), but the typechecker thinks one is being returned from your slice function. Eventually, either [] should be inferred to be string[] instead of an untyped JS array, or the runtime typecheck should throw a JS error with a good message.

As a workaround, I think you can do

let subArr: string[] = [];

for now.

[ishaan1995]

I was trying to run the static hermes from the static_h branch. Compiled the binary and starting using it and it worked exceptionally well.
I wanted to experiment more and play around setTimeout & promises but it failed with following error

code:

setTimeout(() => {
  print("hello world!")
}, 250);

Command: ./shermes -typed -exec main.ts

Error:

main.ts:12:1: warning: the variable "setTimeout" was not declared in anonymous function
setTimeout(() => {
^~~~~~~~~~
Uncaught ReferenceError: Property 'setTimeout' doesn't exist
    at global (native)

Is this expected? Sorry I am new to this and could not find any docs around same in the repo.
Fyi, tried with both debug & release build process, got same error each time.

[tmikov]

setTimeout() is not provided by Hermes/Static Hermes - the event loop and related functionality needs to be provided by the integrator. One simple example can be seen here: https://github.com/tmikov/hermes-jsi-demos/tree/master/evloop

[vExcess]

Not to discourage shermes. But after being unsuccessful in trying to compile my TypeScript using shermes (see my above post), I rewrote my project in Dart instead. Dart is garbage collected and supports dynamic typing and as a result it was fairly straightforward to rewrite my code into Dart. Unlike shermes, Dart also has a standard library for things like setTimeout. The important thing though is that Dart compiles directly to native binary which means it already does what shermes is trying to accomplish. Although compiling JS directly to native using shermes would be more efficient, I think it would be far easier to take advantage of all the work Google has put into Dart and make a JS to Dart transpiler instead. There doesn't seem to be any JS to Dart transpiler in existence, but there is a TS to Dart transpiler https://github.com/dart-archive/ts2dart/. Granted it hasn't been updated in 8 years and both TS and Dart have changed significantly since then so I doubt it's very operational anymore. But if TS to Dart was possible 8 years ago, then I'm sure that today it would be possible to create a new JS to Dart transpiler that is at least more operational than shermes is today. I would love to get started on a JS to Dart transpiler right now, but I'm focusing on creating a FOSS version of MS Paint 3D because Microsoft is killing it on November 4th. If after Nov 4th nobody else has created a JS to Dart transpiler, then I'll probably get started on making one.

[tmikov]

But if TS to Dart was possible 8 years ago, then I'm sure that today it would be possible to create a new JS to Dart transpiler that is at least more operational than shermes is today.

@vExcess i think you are severely underestimating the challenges associated with compiling the actual semantics of TypeScript, which is fundamentally based on structural typing, as a statically typed language. The challenges of supporting type-safe generics, compatibility of lambdas, etc. You are possibly also underestimating the value, as well as the difficulty, of compatibility with existing JavaScript and mixing it with the typed language. None of these can be addressed by a TS to Dart converter.

With Static Hermes we are trying to accomplish a very ambitious task (at least that is how it looks to us) which takes time and effort. As we have stated many times, the typed frontend is not ready for public consumption yet.

Dart is a great language developed from scratch with very different constraints. If it meets your requirements, you should definitely use it. Additionally, if you believe you can achieve and exceed the goals that we have set for Static Hermes by writing a TS to Dart transpiler, you should try that and publish it under a permissive license. If you find innovative ways to solve the complex problems we are facing, we will gladly adopt your solutions.

[jroweboy]

I couldn't decide if this is an appropriate place to request features for static hermes, so apologies if this isn't the right place. I ran into the error error: Legacy JS classes not supported (yet)

I'm not sure if you need any sample projects that use native JS classes, but while Zod itself is written in typescript, when its compiled to JS and uploaded to NPM, the library does use them.

[tmikov]

We are very close to landing support for legacy JS classes. They are much slower than SH's "typed classes", but they are part of the language.

[tkpeach]

How can I try static hermes with reactive-native on my mobile device?