v8port needs your help topic ideas

[netskink]

Previously, @MikeFultonDev had an excellent suggestion regarding getting input from the community regarding the Google Developer Advocate for v8port. He suggested using this forum to get additional input and it was helpfull. In that vein, I thought I would do a similar process for the upcoming talk at IBM Tech Xchange in October.

Here is the original abstract:

The IBM open source organization, "z/OS Open Tools", hosts a collection of Linux tools that are 
ported to z/OS Unix System Services. A recent addition to the collection is Google’s Chromium 
V8 JavaScript engine and supporting tools. Successfully porting the engine and tools required a 
collaborative effort between Broadcom and IBM. Ongoing efforts to upstream the work to Google 
are in progress. Additional work needs to be done to complete the port - not all features work to 
the same degree as on other platforms. This joint talk with Igor Todorovski of IBM is to publicize 
the effort and seek contributions from other developers. This is an opportunity to contribute to 
open source projects that benefit the whole z/OS Open Tools and USS community.

At this point Gaby Baghdadi has completed the upstream effort but the remaining goal of growing the community for v8 on USS remains. With that said, I intend to give a brief intro to v8port but I'm wondering if there is anything in particular you might find useful during this presentation. ie. this presentation is for you, what would you like to know/see/understand? What it is? How to contribute? How to use? etc?

John

[IgorTodorovskiIBM]

A couple of thoughts:

• How is the V8 port leveraged currently. You can mention IBM's Node.js product and your product.
• Describe the porting challenges (i.e several different components, using zoslib to overcome C LE issues, depot_tools, etc)
• How does V8 compare to other Javascript backends like SpiderMonkey
• An interactive demo would be cool, perhaps of the components, the build, the buildenv configuration, and then an example of running d8

[netskink]

Excellent. This aligns with what I was thinking. Many thanks Igor!

[netskink]

Place holder for architecture diagram.

[netskink]

Post Jacob Kummerow Review 1

Additional clarification from Jacob

The fact that the compilers consume bytecode is just an internal optimization, they could alternatively start with the AST again, as bytecode and AST are similarly expressive. There are multiple reasons why it's convenient to make them consume bytecode:

• the bytecode is much more compact than the AST, so storing the AST until later optimization would cost a lot more memory
• re-parsing the source to re-generate the AST (if not storing it) would cost more CPU time
• when generating bytecode from the AST, we perform a few steps of desugaring, so it's convenient to not have to reimplement that logic elsewhere too
• to simplify things, Ignition and Sparkplug use the same stack frame layout, which means they have to stay very closely in sync, which is easier to achieve by making Sparkplug consume bytecode as input
  I'm pointing this out because in my experience this is a detail that tends to confuse audiences, so it may be worth pointing out that it's just an internal detail, and not important for the overall concept.

For Wasm it's a similar principle, but only two compilers:

• [ Wasm wire bytes] --(Liftoff single-pass compiler)--> [ unoptimized machine code ] --> {execution}
• If a given function gets hot enough:
• [ Wasm wire bytes ] --(Turbofan optimizing compiler)--> [ optimized machine code] --> {execution}

[jakobkummerow]

I would additionally point out that heap and stack aren't exactly part of Ignition; even for profiling counters that's a rather debatable characterization. The heap doesn't have much to do with the function compilation/execution pipeline, it's just where objects are stored. Every activated function is on the stack, no matter which tier it's in currently.

[netskink]

Thanks @jakobkummerow

I've updated the document.