media-source VS V8

It depends heavily on the website we're talking about but there's generally a lot going on when streaming video on the web.

Usually what happens at the core is that JavaScript will download video, audio and subtitles progressively through small chunks of data called "segments" and push them to JS-exposed buffers called 'SourceBuffer'. Deciding which chunk to download, downloading them and pushing them already require a lot of JavaScript (for example, you need to decide which video and audio quality to download through adaptive algorithms, which tend to be quite complex, moreover there's also a lot of media events that needs reaction to, like when seeking, rebuffering, changing track etc.). You also have a lot of JavaScript there to limit risks of playback stalling and if you have DRMs, a lot of JavaScript there to be able to recuperate the right decryption keys (an operation you generally wish to finish as soon as possible as it is often the last step before playback).

On some websites, you might want to play with as low latency as possible between the broadcaster and the user. In those cases, you might want to optimize your JS code, have very small checking intervals, and you might again prefer to run as much code as possible in a worker to avoid rebuffering due to the risk of the main thread being too occupied doing other things to push media segments.

Even on non-low-latency contents, some websites which already have a lot of JavaScript running beside video playback such as at least Facebook and YouTube pushed browsers for quite some time now to be able to use the main JavaScript media streaming APIs in a worker (https://github.com/w3c/media-source/issues/175), e.g. in another thread.

You could also have complex contents (lot of audio and subtitles languages, many audio and video qualities, multiple decryption keys, long duration etc.) that may lead to big performance and memory issue when parsing them on the JS-side. Those contents are usually described through a file named "manifest" or "playlist" which in this case can take a lot of resources to process (the document can be up to a huge 15MB XML where I work), often leading either the linked JavaScript to run in a worker or to use webassembly (a solution we chosed). Even more if you consider live contents, where this document might have to be regularly refreshed.

You might also want to apply some processing on the media played, for example transmuxing mpeg-ts segments to MP4 ones so they can be played by more browsers. Those are very frequent operations that can be performance-sensitive and are also often performed in another thread.

Again it very much depends on the website and I mainly know the use cases I personally encountered. Generally, adaptive media player are very complex JavaScript beasts.

Also performance issues and poor memory management from the browser-side can lead to a lot of issues. A recurring issue at my work is bad performance leading through side-effect to a very poor quality being played (due to the high overhead in loading segments, pushing them to the buffer etc.).

All these would suffer without a powerful and featureful JS engine like we generally have today on most browsers.

https://chromium.googlesource.com/v8/v8.git/+/HEAD/include/c...

Due to the nature of web engine workloads migrating objects to being GC'd isn't performance negative (as most people would expect). With care it can often end up performance positive.

There are a few tricks that Oilpan can apply. Concurrent tracing helps a lot (e.g. instead of incrementing/decrementing refs, you can trace on a different thread), in addition when destructing objects, the destructors typically become trivial meaning the object can just be dropped from memory. Both these free up main thread time. (The tradeoff with concurrent tracing is that you need atomic barriers when assigning pointers which needs care).

This is on top of the safey improvements you gain from being GC'd vs. smart pointers, etc.

One major tradeoff that UAF bugs become more difficult to fix, as you are just accessing objects which "should" be dead.

> If that standard library would be written in JS, a new browser (or rather a new JS engine being a part of the browser) could just use some existing implementation

That sounds great, but I'm doubtful of the simplicity behind this approach.

If my understanding is correct, v8 has transitioned to C++[0] and Torque[1] code to implement the standard library, as opposed to running hard-coded JavaScript on setting up a new context.

I suspect this decision was made as a performance optimization, as there would obviously be a non-zero cost to parsing arbitrary JavaScript. Therefore, I doubt a JavaScript-based standard library would be an acceptable solution here.

[0]: https://github.com/v8/v8/tree/main/src/runtime

C++ lets you write anything you can imagine, and the language features and standard library often facilitate that. The committee espouses the view that they want to provide many "zero [runtime] cost," abstractions. Anybody can contribute to the language, although the committee process is often slow and can be political, each release the surface area and capability of the language gets larger.

I believe Hazard Pointers are slated for C++26, and these will add a form "free later, but not quite garbage collection" to the language. There was a talk this year about using hazard pointers to implement a much faster std::shared_ptr.

It's a language with incredible depth because so many different paradigms have been implemented in it, but also has many pitfalls for new and old users because there are many different ways of solving the same problem.

I feel that in C++, more than any other language, you need to know the actual implementation under the hood to use it effectively. This means knowing not just what the language specifies, but can occaissionally require knowing what GCC or Clang generate on your particular hardware.

Many garbage collected languages are written in or have parts of their implementations in C++. See JS (https://github.com/v8/v8)and Java GC (https://github.com/openjdk/jdk/tree/36de19d4622e38b6c00644b0...)

I am not an expert on Java (or C++), so if someone knows better or can add more please correct me.

Remember that we earlier established that every source gets parsed into an AST at some point before it gets compiled or interpreted. For example, platforms like Nodejs and chromium-based browsers use Gooogle's V8 engine behind the scenes to run JavaScript and of course, some AST parsing is always involved before the interpreter kicks in. I looked V8's source and I discovered it uses its own internal parser to achieve this.

In the source code of the Node.js opensource project, lib folder contains JavaScript code, mostly wrappers over C++ and function definitions. On the contrary, src folder contains C++ implementations of the functions, which pulls dependencies from the V8 project, the libuv project, the zlib project, the llhttp project, and many more - which are all placed at the deps folder.

Here is the implementation of of Array. prototype.map in V8. It's written in a language called Torque which appears to be a special language just for the v8 engine.

It sounds like you want to know how JavaScript is implemented in the browser. The thing is, there is no universal implementation for JavaScript. JavaScript defines a specification that must be adhered to, and then each browser vendor can implement it in whatever way they see fit, as long as it does the specified things. For example (and I'm not saying this is the case) it's entirely possible for Chrome to implement Array.sort() using merge sort, while Firefox implements it as quick sort. You can try to find the source code for the implementation in a certain browser, but that will not be universal. I imagine you can find out how it works in Chrome somewhere in https://chromium.googlesource.com/v8/v8.git, though I'm not sure exactly where.