Trying to grasp current architecture. Is this accurate?

198 views
Skip to first unread message

John Davis

unread,
Oct 4, 2024, 10:30:36 AM10/4/24
to v8-users
Hello

I'm giving a talk regarding the z/OS UNIX port of v8.  I'm more familiar with the build process and usage.  Less familiar with the actual architecture.  With that said, this is what I have come up with based upon the v8 docs blog and various presentations over the years.

Would this be accurate?  Any suggestions  or edits is appreciated.

Jakob Kummerow

unread,
Oct 7, 2024, 7:06:30 AM10/7/24
to v8-u...@googlegroups.com
For JavaScript:

[ JS source] --(parser)--> [ AST ] --(Ignition bytecode generator)--> [ bytecode ]
[ bytecode ] --(Ignition bytecode interpreter)--> {execution}
As a given function gets increasingly hotter (as determined by certain counters/budgets embedded into it):
[ bytecode ] --(Sparkplug non-optimizing compiler)--> [ unoptimized machine code ] --> {execution}
[ bytecode ] --(Maglev fast optimizing compiler)--> [ mostly-optimized machine code ] --> {execution}
[ bytecode ] --(Turbofan thorough optimizing compiler)--> [ fully optimized machine code] --> {execution}

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}

Comparing the above to the draft graph as currently posted on GitHub:
- Ignition does not produce machine code
- I'm not sure what the "Profile (C1 Compiler?)" box is supposed to be
- I'm not sure what the dotted arrows are supposed to mean

As a general tip, it may help to visually distinguish boxes that are transformers (e.g. "parser") from boxes that are data consumed and produced by these transformers (e.g. "AST").


This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/3f25f7e3-8e85-4685-8667-269ad7e7a08an%40googlegroups.com.
Message has been deleted

John Davis

unread,
Oct 8, 2024, 5:45:06 AM10/8/24
to v8-users
Hello Jakob,

Many thanks Jacob!  Those are awesome clarifications.  I updated the diagram and included your comments here:


Thank you for clarifying 

John

Reply all
Reply to author
Forward
0 new messages