vote: future of primordials

[gireeshpunathil]

prior art for getting upto speed:

nodejs/node#30697
https://youtu.be/CYv575Bps9M
https://www.youtube.com/watch?v=XPRWSXKLdrY

• Possible goals
  • tamper-free the entire process
  • tamper-free just module loading
  • selectively, based on performance
  • something else, other than tamper-free
• Possible approaches
  • migrate to primordials
  • migrate to C++
  • something else

to reduce complexity, I have taken the liberty to remove some of the unpopular options, based on my understanding after listening to various discussions; but if you think an important option is missing, pls let me know!

don't start voting upfront, we need to better qualify the option 1 - with the relevant subset of modules . please suggest what you think those are. (pining @ljharb and @bmeck too for their input here)

voting starts in 2 weeks from now.

[targos]

What does "implement" mean?

[gireeshpunathil]

What does "implement" mean?

migrate, may be a better word?

[ljharb]

Option 1 is more like “migrate for a subset only, other core modules X this pattern” where X is “may” or “may not” or “must” or “must not”.

Option 2 is maybe “migrate for all, evaluate performance cliffs as one-offs”?

Option 3’s status quo is a bit tricky to define; it’s kind of already option 2 but there’s no consensus on it, it seems?

[gireeshpunathil]

thanks @ljharb and @targos . reworded to reflect the meaning. option 3 is different from 2 in that:

• in 2, we continue migrating, but with evaluating tradeoffs
• in 3, we just freeze everything, until a new approach arrives (such as a language semantics?)

[ljharb]

Is "freeze everything" the status quo? I thought that was "use primordials whenever possible, be careful of hot paths, and avoid primordials in hot paths".

[gireeshpunathil]

AFAIK, we stopped migration work for a while, since we started to see the performance ditch. To avoid confusion, let me reword the option to leave the migration where it is right now.

[mcollina]

would recommend using a vote similar to what we used for Promises where there were multiple choices.

[gireeshpunathil]

would recommend using a vote similar to what we used for Promises where there were multiple choices.

@mcollina - agreed in theory; just wondering how do we do it on a github issue (IIRC, promise voting was done through a google survey form or something?)

[aduh95]

For the Corepack vote (and the Promise one apparently, but I wasn't around), we used San Francisco RCV via OpaVote: #1012 (comment). Maybe we could use it again?

[gireeshpunathil]

@ljharb and @bmeck - regarding #1104 (comment) , do you have proposals for specific modules, under option 1 ? that is, the modules that you recommend as

• should be migrated
• should not be migrated
• may be / may not be migrated
  ?

[ljharb]

@gireeshpunathil personally, i want them all migrated. the subset that was referred to there afaik was "things in the loader subsystem" i believe? @bmeck can speak to this.

[BridgeAR]

I believe the TSC has to decide upon what modules should be migrated and we should have different voting options for those.

The current mentioned voting options are open for further discussions and that's something I would rather prevent.
I would like to also list pros and cons next to entries, if possible. I imply that Evaluate when a better alternative emerges is applicable to all of these options.

As such, I suggest to be very specific with our voting options. Here are a couple of suggestions:

1. Fully migrate module loaders and policy code to primordials and undo everything else (code used from other modules would not be tamper proof)
2. Fully migrate module loaders and policy code to the C++ layer and undo all primordials
   3. Migrate all modules to primordials
   4. Migrate all Node.js code to C++
3. Undo all primordials
   6. Ask the community in a similar fashion as we did with unhandled rejections
   7. Move the REPL code execution into a child process to keep the REPL from working even if the runtime itself would crash due to manipulation from the executed REPL code
   8. 1. or 2. and move the REPL code execution into a child process to keep the REPL from working even if the runtime itself would crash due to manipulation from the executed REPL code
   9. Do not port any further code to primordials but do not explicitly remove existing primordials either
4. Make sure the module loaders and policy code is tamper proof and undo all primordials in other code parts
5. Ask the community about tamper proofness, performance and Node.js contributor experience (maintainability of Node.js core).

Benefits may be one of:

a) Tamper free code loading and or execution (tampering with JS code is not going to influence the runtime itself, just the application code)
b) Performant code (primordials potentially slow down runtime code)
c) Regular JavaScript code that may be understood by most JS developers (have a lower entry barrier for new contributions)
d) TBD ...

[gireeshpunathil]

@BridgeAR - I believe these many options will confuse voters and make it harder for the TSC to converge on a stable opinion. Presence of these many (and technically may be more permutations of these?) options made us to sit and brainstorm in the first place, so as to:

• weed out some of the obviously poor choices (such as migrate all, migrate none etc.)
• identify the most prominent ones and their rationales

so as to help TSC take the most reasonable action on this.

(I won't make it to tomorrow's TSC due to its timing, but appreciate if this comment is reviewed)

[gireeshpunathil]

modified the options based on the discussion in the last TSC meeting - by separating the goal, and the approaches; thereby reducing the complexity of options.

@BridgeAR - does it look good to you? if not, pls bring your views in the upcoming sitting, then we can refine it as applicable, and then go for voting.