3 ms·

So... the second thread needs to wait for the GC in order to modify the map concurrently? I mean, it is an optimization for the most common case (single-threade

by tomp 11y ago

So... the second thread needs to wait for the GC in order to modify the map concurrently? I mean, it is an optimization for the most common case (single-threaded access), but it imposes a quite high penalty for concurrent access... Although I could imagine a similar "signaling" mechanism, where each thread would periodically read a single snychronized variable, to check if there's any additional "re-synchronisation" work it needs to do. But I'm guessing that CPUs are implemented that way anyways.

chrisseaton 11y ago
> So... the second thread needs to wait for the GC in order to modify the map concurrently? No nobody needs to wait for a GC, but we use the same mechanism that the GC does. > Although I could imagine a similar "signaling" mechanism, where each thread would periodically read a single synchronised variable And that's how the GC already works. Except instead of a variable normally a 'test' instruction is used on a page of memory, and instead of setting the variable, the permission on the page are changed triggering a page fault.
- tomp 11y ago
  > Except instead of a variable normally a 'test' instruction is used on a page of memory, and instead of setting the variable, the permission on the page are changed triggering a page fault. Which GCs do that? The only one I know is Azul's Pauseless JVM GC, but that's a kind of a special case, given that it needs support from the kernel.
  - chrisseaton 11y ago
    All of HotSpot's GCs for example. Here's a survey of different approaches for stopping in GC. http://dl.acm.org/authorize.cfm?key=N98613 http://dl.acm.org/authorize.cfm?key=N98613 Also note that Azul almost certainly has the same mechanism to do things like stop the world for dynamic class loading, even if it isn't using it for GC when running the pauseless collector. And Section 4 and 5 of this paper talks a bit more about it's implemented http://chrisseaton.com/rubytruffle/icooolps15-safepoints/safepoints.pdf http://chrisseaton.com/rubytruffle/icooolps15-safepoints/saf....
    - tomp 11y ago
      Thanks, I'll check these out!

by tomp 11y ago

chrisseaton 11y ago

> So... the second thread needs to wait for the GC in order to modify the map concurrently? No nobody needs to wait for a GC, but we use the same mechanism that the GC does. > Although I could imagine a similar "signaling" mechanism, where each thread would periodically read a single synchronised variable And that's how the GC already works. Except instead of a variable normally a 'test' instruction is used on a page of memory, and instead of setting the variable, the permission on the page are changed triggering a page fault.

tomp 11y ago
> Except instead of a variable normally a 'test' instruction is used on a page of memory, and instead of setting the variable, the permission on the page are changed triggering a page fault. Which GCs do that? The only one I know is Azul's Pauseless JVM GC, but that's a kind of a special case, given that it needs support from the kernel.
- chrisseaton 11y ago
  All of HotSpot's GCs for example. Here's a survey of different approaches for stopping in GC. http://dl.acm.org/authorize.cfm?key=N98613 http://dl.acm.org/authorize.cfm?key=N98613 Also note that Azul almost certainly has the same mechanism to do things like stop the world for dynamic class loading, even if it isn't using it for GC when running the pauseless collector. And Section 4 and 5 of this paper talks a bit more about it's implemented http://chrisseaton.com/rubytruffle/icooolps15-safepoints/safepoints.pdf http://chrisseaton.com/rubytruffle/icooolps15-safepoints/saf....
  - tomp 11y ago
    Thanks, I'll check these out!