It seems you’ve already made up your mind and nothing anyone says will change that :). The volatile I mentioned isn’t due to concurrency of userspace threads, but to avoid the optimizer from eliminating read/write…
Lest someone gets the wrong idea, Rust makes _mutable_ globals painful to work with; readonly is fine. As for hardware DMA’able memory, it’s true that it adds friction to work with in Rust. But C or C++ would fall into…
Sorry, that was my mistake - it has pre-write barriers for SATB but not actual read barriers. However, ZGC will have read barriers and if Shenandoah ever gets integrated into Hotspot, it has them too.
G1 has read barriers for SATB marking. Whether a read barrier is used or not is a function of which GC is used so can’t really say “Hotspot doesn’t use read barriers”.
No, it’s sadly true. EA may scalarize the allocation but this optimization falls apart very easily in Hotspot.
.NET doesn’t have interior pointer. Any `ref` must be on the stack and that’s tracked in the stackmap. You cannot have a ref as a field.
That's all true, but I think we're talking past each other a bit. My point isn't about what mechanics would be used or the type of memory order specified (that's the irrelevant part), but merely to highlight that this…
Note that I didn't mention anything about it being automatic. It's merely a case of being more explicit about what may happen to the value. Sequential consistency is irrelevant to the example I gave of a single valued…
> Concurrency is not special here I beg to differ. Concurrency comes with its own bag of hazards, as I mentioned in my reply to burntsushi. Comparing its invariants with Vec's length invariant/HashMap's RH invariant,…
Only because I've had several people ask me how Rust handles memory ordering after they've learned of Sync. Sync documentation focuses very narrowly on there being no data races against the type that implements it.…
> I guess I don't see the difference At a high and general level, yeah, it's all "unsafe". But, most conversations about unsafe don't talk about this aspect. So while what you say is true, I'm merely pointing out that…
I suppose my point was that auto-deriving Sync may not have been such a great idea :). I understand the rationale for it but it does open up traps for people to fall into.
Yeah, I understand and what I expected to be the answer. My point is that when people talk about Sync not allowing data races, there's the asterisk attached to that statement. That footnote is that publishing code,…
I think it's fair to question a type being auto-derived to be Sync if only individual fields are Sync. It may lead to improper sharing of a reference to this value where threadsafety across fields is needed. That would…
Right, but my question isn't about T itself, but rather how it's published to another thread. The example I gave is of a plain struct with no atomics or any other synchronization types internally. A &T is auto-derived…
Ok, that's what I figured - thanks. That does bring up the question, though, whether it's correct to say that a Sync type doesn't permit data races. In the example I gave above, publishing a Sync struct incorrectly can…
Somewhat tangential, but what ensures memory visibility in Rust? Say I allocate a struct (heap or stack), and then pass an immutable reference to a function that takes T: Sync. Assume the struct itself is Sync (e.g.…
> I may have misunderstood Ralf's bug. Is it really the case that MutexGuard<T> was seen as Sync if T was Send, rather that Sync? Wouldn't that be a bigger problem than just the case of MutexGuard? So T: Sync if &T:…
Sure, but that space isn't just Java anymore anyway. Also, what's an (non-toy) environment where developer productivity and safety/correctness don't matter? I always find that statement bizarre when talking about…
It all depends on what time scale we're talking about since "very fast" is relative. High performance native systems don't use (in any meaningful manner) naive malloc/free, so that comparison is somewhat moot. I hear…
You should've made it explicit then that you're referring to slow HFT -- the post I was replying to drew no such distinction apart from saying the "extreme end" uses FPGAs. Obviously if young gen GC pauses aren't an…
Yes, Azul has a similar feature (ReadyNow). This is nontrivial because lots of optimizations depend on class load ordering and runtime profile information.
Tiered JITs are meant to allow slower and more aggressive optimizations to be done on truly hot code. However, you're right in that they still cannot spend as much time or resources as an AOT compiler.
Devirtualization is mostly an issue for Java since everything is virtual by default and the language doesn't have support for compile time monomorphization. While C++ code does use virtuals, it's nowhere near the amount…
The fantastic standard library mostly goes away because it allocates. It's possible to write Java code that doesn't allocate in steady state, but the coding style becomes terrible (e.g. overuse of primitives, mutable…
It seems you’ve already made up your mind and nothing anyone says will change that :). The volatile I mentioned isn’t due to concurrency of userspace threads, but to avoid the optimizer from eliminating read/write…
Lest someone gets the wrong idea, Rust makes _mutable_ globals painful to work with; readonly is fine. As for hardware DMA’able memory, it’s true that it adds friction to work with in Rust. But C or C++ would fall into…
Sorry, that was my mistake - it has pre-write barriers for SATB but not actual read barriers. However, ZGC will have read barriers and if Shenandoah ever gets integrated into Hotspot, it has them too.
G1 has read barriers for SATB marking. Whether a read barrier is used or not is a function of which GC is used so can’t really say “Hotspot doesn’t use read barriers”.
No, it’s sadly true. EA may scalarize the allocation but this optimization falls apart very easily in Hotspot.
.NET doesn’t have interior pointer. Any `ref` must be on the stack and that’s tracked in the stackmap. You cannot have a ref as a field.
That's all true, but I think we're talking past each other a bit. My point isn't about what mechanics would be used or the type of memory order specified (that's the irrelevant part), but merely to highlight that this…
Note that I didn't mention anything about it being automatic. It's merely a case of being more explicit about what may happen to the value. Sequential consistency is irrelevant to the example I gave of a single valued…
> Concurrency is not special here I beg to differ. Concurrency comes with its own bag of hazards, as I mentioned in my reply to burntsushi. Comparing its invariants with Vec's length invariant/HashMap's RH invariant,…
Only because I've had several people ask me how Rust handles memory ordering after they've learned of Sync. Sync documentation focuses very narrowly on there being no data races against the type that implements it.…
> I guess I don't see the difference At a high and general level, yeah, it's all "unsafe". But, most conversations about unsafe don't talk about this aspect. So while what you say is true, I'm merely pointing out that…
I suppose my point was that auto-deriving Sync may not have been such a great idea :). I understand the rationale for it but it does open up traps for people to fall into.
Yeah, I understand and what I expected to be the answer. My point is that when people talk about Sync not allowing data races, there's the asterisk attached to that statement. That footnote is that publishing code,…
I think it's fair to question a type being auto-derived to be Sync if only individual fields are Sync. It may lead to improper sharing of a reference to this value where threadsafety across fields is needed. That would…
Right, but my question isn't about T itself, but rather how it's published to another thread. The example I gave is of a plain struct with no atomics or any other synchronization types internally. A &T is auto-derived…
Ok, that's what I figured - thanks. That does bring up the question, though, whether it's correct to say that a Sync type doesn't permit data races. In the example I gave above, publishing a Sync struct incorrectly can…
Somewhat tangential, but what ensures memory visibility in Rust? Say I allocate a struct (heap or stack), and then pass an immutable reference to a function that takes T: Sync. Assume the struct itself is Sync (e.g.…
> I may have misunderstood Ralf's bug. Is it really the case that MutexGuard<T> was seen as Sync if T was Send, rather that Sync? Wouldn't that be a bigger problem than just the case of MutexGuard? So T: Sync if &T:…
Sure, but that space isn't just Java anymore anyway. Also, what's an (non-toy) environment where developer productivity and safety/correctness don't matter? I always find that statement bizarre when talking about…
It all depends on what time scale we're talking about since "very fast" is relative. High performance native systems don't use (in any meaningful manner) naive malloc/free, so that comparison is somewhat moot. I hear…
You should've made it explicit then that you're referring to slow HFT -- the post I was replying to drew no such distinction apart from saying the "extreme end" uses FPGAs. Obviously if young gen GC pauses aren't an…
Yes, Azul has a similar feature (ReadyNow). This is nontrivial because lots of optimizations depend on class load ordering and runtime profile information.
Tiered JITs are meant to allow slower and more aggressive optimizations to be done on truly hot code. However, you're right in that they still cannot spend as much time or resources as an AOT compiler.
Devirtualization is mostly an issue for Java since everything is virtual by default and the language doesn't have support for compile time monomorphization. While C++ code does use virtuals, it's nowhere near the amount…
The fantastic standard library mostly goes away because it allocates. It's possible to write Java code that doesn't allocate in steady state, but the coding style becomes terrible (e.g. overuse of primitives, mutable…