[Feature Request]: An option to disable memory cage and pointer compression

[WillAvudim]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem Description

It's not uncommon for a desktop computer nowadays to have 64GB memory. There is a large array of desktop applications dealing with ML, image processing, rendering, e.g. displaying financial charts or annotation tools for medical images that require large datasets to be loaded in-memory and accessed for every mouse move (e.g. to display the precomputed inference of the hierachical bayesian network for this point in time, which is kept in a huge Float32Array).
Such desktop applications do not benefit from the security context, we run with nodeResolution set to true, in fact, here's the exact config we run with:

  const mainWindow = new BrowserWindow({
    width: 2800,
    height: 2000,
    webPreferences: {
      // Electron memory cage is enforced starting with version 21:
      // https://github.com/electron/electron/issues/35241
      preload: path.join(__dirname, "index_preload_njs.js"),
      // preload: "/storage/mono/out/electron/preload.js",
      contextIsolation: false,
      nodeIntegration: true,
      nodeIntegrationInWorker: true,
      nodeIntegrationInSubFrames: true,
      sandbox: false,
      webSecurity: false,
      allowRunningInsecureContent: true,
      additionalArguments: [
        // Most likely doesn't take effect and can be removed.
        "-r",
        "ts-node/register/transpile-only",
      ]
    }
  })

There is no user code to run. Obviously, we do not include any hosted 3rd party content. All .js files limited to well-known frameworks (Vue3, react, etc) and vetted before getting incorporated into the code base and referenced directly. We do not benefit from the security benefits that you currently promote, it's simply unnecessary for us, it is the memory that the Renderer can immediately access we are after.

I understand that maintaining such a build, especially with your insane pace of releases (we can only attempt to upgrade every few years, VSCode was behind for several years before they could catch up with you), would waste a lot of time unnecessarily.

Proposed Solution

Would it be possible to provide an infrequent, e.g. once in 2-3 years, build without memory caging and, if possible, without memory compression?

Alternatives Considered

There is a thread currently discussing the problem: #35241
And, apparently, the top two alternatives considered so far are to switch to the web and drop Electron entirely, or use "a native webview widget in a QT application". Neither can be done without massive rewrites of the application.

Additional Information

Well, we actually love Electron overall, and we do want to continue using it going forward. Please help us leverage the entire available memory from the Renderer, it's vital to many applications.

[ckerr]

This is a worthwhile addition to the conversation, but #35801 already exists for this discussion (and is linked to in the memory cage blog post) so it would be better to float this idea there where it can be seen by everyone who's already watching 35801.

I'm closing this ticket as a duplicate for that procedural reason.