91–100 of 189 posts
Please, no. Shared-by-default heap memory is one of the greatest mistakes ever made in language design. We need a better design justification than it's the easiest thing to implement right now.
Earlier quoted context omitted.
You say fun, but what you mean is twisted mess.
WebKit uses threads. WebKit is not a twisted mess.
Besides, WebKit doesn't do fine-grained parallelism on the level of parallel styling or parallel layout. My colleague Manish came up to me after a long back-and-forth conversation with bz to figure out which objects were thread-safe and told me "the biggest lesson of Stylo is that adding parallelism to a previously large sequential C++ project is basically impossible". That's because large-scale projects invariably fail to properly document the precise synchronization invariants that each object must uphold in order to function properly. They settle for blanket statements like "the entire render tree is single threaded only" which, while conservatively a correct statement, essentially gives up on fine-grained tracking and makes it very hard to add parallelism later.
By contrast, when you lift concurrency guarantees into the type system, the compiler essentially enforces that the documentation on thread safety is always up to date. This makes it way easier to start with sequential code and add parallelism (and/or concurrency) later as real-world profiling indicates fruitful optimization opportunities.
I think you're way too casually dismissing the very real problems that unrestricted shared state has.
Yeah, and lets have the gazillion scripts, loaded by your usual favourite news site, spawn 10 threads each... For browsers, this is a bad idea. The biggest advantage of the event loop approach is that it is somewhat deterministic. With threads, that determinism goes out of the window. Lock-management? No way I do that for Browsers. I will quit working on client-side code if that is becoming a requirement! Threads for…
For that matter, anyone who'd like to have "fun" with concurrency and lock management in browser-side JS is free to play around with recurring asynchronous data fetching cached in localStorage when multiple browser tabs are open. Spoiler: locks are the wrong approach and you should be relying on events/callbacks instead. Oddly enough, that's similar to my gut feeling about Threads in JS.
They mean parallelism, right? Concurrency is what JS is already known for.
Of course the language can be made to support it. Given the way Javascript is used, the question is whether supporting it will create a big mess. They have some good ideas. One is that variables can be marked as restricted to one thread. That should be the default. Other languages could benefit from that feature. Python, for example. If you want to get rid of the Global Interpreter Lock, knowing which variables can't…
I think it would be weird if objects were thread-restricted by default. Concurrency is most fun when it's easy for a thread to access an object it wants.
Earlier quoted context omitted.
WebKit uses threads. WebKit is not a twisted mess.
I mean, you could say the same thing about assembly language programs. "Either static or dynamic typing is needed to prevent large programs from becoming a twisted mess" is a pretty uncontroversial statement today, despite the fact that there were some very high quality large assembly language programs written back in the DOS days. Besides, WebKit doesn't do fine-grained parallelism on the level of parallel styling o…
I think you’re way too casually dismissing how awesome shared memory is.
Earlier quoted context omitted.
Can you be very specific?
When told that multi-threaded access is hard and messy, "X program uses threads and it's not a mess" is not an argument -- for one because nobody said X program is a mess. Threads being messy is not a transitive property. Nobody doing threads ever said that they are not messy or that multi-thread access and locking et al are easy.
Earlier quoted context omitted.
The justification is that when you have an array of 100000 elements and split it into into isolated chunks that can be processed without any synchronisation and then marshall it into json and then actually do the computation and then marshall the result into a json string and marshall it back into a javascript array is very wasteful. Heck even when I'm passing immutable messages I'd still implement it via shared memo…
Fork/join on arrays and trees would be an easier to manage model, IMO.
What's not quite clear to me is whether "the cell never moves" is one of the assumptions that actually goes into making this work or not. And if it is, how that plays with a compacting or generational collector, where you do in fact want the cell to move.
From the standpoint of the concurrency scheme I'm proposing, it's OK to move the cell in the GC. Then it becomes a standard GC moving problem. In JSC we don't move cells for other reasons, and the point of saying that they don't move is that the object model itself does not require the cell to ever move.
Earlier quoted context omitted.
I mean, you could say the same thing about assembly language programs. "Either static or dynamic typing is needed to prevent large programs from becoming a twisted mess" is a pretty uncontroversial statement today, despite the fact that there were some very high quality large assembly language programs written back in the DOS days. Besides, WebKit doesn't do fine-grained parallelism on the level of parallel styling o…
WebKit does a lot of fine grained parallelism. I think you’re way too casually dismissing how awesome shared memory is.