Conversation

Notices

1. Embed this notice
   asm & tamsyn & forth, oh my! (millihertz@oldbytes.space)'s status on Friday, 10-Mar-2023 15:23:52 JST asm & tamsyn & forth, oh my!

   i'm not entirely sure that letting our computers develop a galloping addiction to virtual memory, no matter how much physical memory they have, was such a good idea, given the parallel replacement of spinning rust that wears out with age by solid-state media that wears out with write cycles

   i mean, yes, i can see how virtual memory might have been relevant when we had 16MB machines. but we have 16GB machines now, and as far as i can tell the only use cases for virtual memory are "we don't have to load all 237 shared libraries into memory at once" and "our memory leaks end up swapped out".

   especially in these days of pervasive managed environments, like Java or ART or CLR. virtual memory has to be subservient to the garbage collector (eg ZGC using the ability to map pages several times), otherwise they end up at cross purposes. and even then, page faults are massively more expensive than tests and conditional branches!

   • clacke likes this.
   • Embed this notice
     clacke (clacke@libranet.de)'s status on Friday, 10-Mar-2023 15:28:28 JST clacke

     in reply to
     @millihertz Overcommitting RAM and optimizing cache use is a nice thing I think, so i don't want to run without swap, but it would definitely be cool if GCs and virtual memory could cooperate better.
     
     I read recently that systemd is gaining the capability to politely ask processes (i.e. send an event) to reduce their RAM use, that's pretty cool (insert side note about ways that systemd is uncool).
     
     How cache-oblivious are GCs these days generally? Can they discard memory without first paging it all in again?
   • Embed this notice
     clacke (clacke@libranet.de)'s status on Friday, 10-Mar-2023 16:50:30 JST clacke

     in reply to
     @millihertz Bring back artisanal coding.
   • Embed this notice
     asm & tamsyn & forth, oh my! (millihertz@oldbytes.space)'s status on Friday, 10-Mar-2023 16:50:34 JST asm & tamsyn & forth, oh my!

     in reply to

     • clacke

     @clacke

     ¹ not least because those of us who grew up with very limited amounts of memory to play with understand very well that mitigations of running out of memory are not only possible, but extremely useful - and frankly, just good manners!

     pettter repeated this.
   • Embed this notice
     asm & tamsyn & forth, oh my! (millihertz@oldbytes.space)'s status on Friday, 10-Mar-2023 16:50:36 JST asm & tamsyn & forth, oh my!

     in reply to

     • clacke

     @clacke overcommitting RAM is a necessity given that for a long time the standard C advice was "assume malloc() succeeds, because if it doesn't you're dead anyway" and an alarming amount of stuff is written like that. including, basically, the entire userspace of linux :-( but it's an indication of shoddy coding, nonetheless¹

     as for GCs - at some point they all end up tracing the heap, which necessitates paging it all in. the best-performing modern GCs then immediately move those objects to the end of the heap and mark them forwarded, and fix up the pointers on every load so that the system never sees a stale pointer.. but still, parallel to that are tracer threads whose job it is to walk the entire heap and ensure that all live objects are copied out. again, the best modern GCs have early-release systems which can recover pages as soon as the last object is copied off them... assuming they only contain live objects, of course!

     the Azul C4 paper is well worth a read

   • Embed this notice
     asm & tamsyn & forth, oh my! (millihertz@oldbytes.space)'s status on Friday, 10-Mar-2023 16:51:52 JST asm & tamsyn & forth, oh my!

     in reply to

     • clacke

     @clacke the only GC technology that really plays nicely with (a) virtual memory, and (b) being a userspace process is refcounting, because it doesn't need global knowledge. but because it doesn't have global knowledge, it also can't collect cycles (although that problem has been worked on - basically, tracing any object whose refcount has been decremented to a non-zero value can identify it as part of a cycle) and can't make assumptions about which objects it can treat as private (forcing all refcount ops to be globally synchronised - hence Apple's M1 optimising this at the silicon level, because it can't be optimised anywhere else)

     clacke likes this.
   • Embed this notice
     clacke (clacke@libranet.de)'s status on Friday, 10-Mar-2023 16:52:45 JST clacke

     in reply to
     > refcount ops to be globally synchronised - hence Apple's M1 optimising this at the silicon level
     @millihertz Wow! What does it do?
   • Embed this notice
     clacke (clacke@libranet.de)'s status on Friday, 10-Mar-2023 16:55:50 JST clacke

     in reply to
     I can easily imagine some blog post about some low-level framework or language runtime going "to achieve X we have to take extreme measures such as ..." and some Old reading it and going "but that's just what coding is".
   • Embed this notice
     asm & tamsyn & forth, oh my! (millihertz@oldbytes.space)'s status on Friday, 10-Mar-2023 17:40:28 JST asm & tamsyn & forth, oh my!

     in reply to

     • clacke

     @clacke basically, if an object is uncontended, atomic operations are as fast as non-atomic ops - in contrast to Intel, where they're always consideraby slower... i suspect because of the Intel vs ARM memory consistency models

     clacke likes this.
   • Embed this notice
     asm & tamsyn & forth, oh my! (millihertz@oldbytes.space)'s status on Friday, 10-Mar-2023 17:41:40 JST asm & tamsyn & forth, oh my!

     in reply to

     • clacke
     • Paolo Redaelli

     @paoloredaelli @clacke https://www.azul.com/sites/default/files/images/c4_paper_acm.pdf - for some reason Azul have put it behind a prywall, but left the direct link out in the open for Google to find... oh well

     clacke likes this.
     clacke repeated this.
   • Embed this notice
     Paolo Redaelli (paoloredaelli@mastodon.uno)'s status on Friday, 10-Mar-2023 17:41:41 JST Paolo Redaelli

     in reply to

     • clacke

     @millihertz
     Where can we read Azul C4 paper?
     @clacke

     clacke repeated this.
   • Embed this notice
     asm & tamsyn & forth, oh my! (millihertz@oldbytes.space)'s status on Friday, 10-Mar-2023 17:41:44 JST asm & tamsyn & forth, oh my!

     in reply to

     • clacke

     @clacke the refcount still has to be done, of course - on uniprocessor refcounted systems like early Smalltalk it was noted that refcounts can consume 30% of runtime, as well as hitting random unbounded pauses when a huge tree of objects has to be freed at once - but clang can do a fair bit of static deduction about liveness, and automatically insert refcounts where that runs out, which as far as i can tell basically gives the effect of deferred and coalesced refcounting, which can eliminate something like 99% of refcount ops to begin with

     clacke likes this.
   • Embed this notice
     clacke (clacke@libranet.de)'s status on Friday, 10-Mar-2023 17:43:27 JST clacke

     in reply to
     @millihertz To summarize:
     
     What's better: Refcounting, runtime liveness checks or static liveness checks?
     
     All of the above!
   • Embed this notice
     asm & tamsyn & forth, oh my! (millihertz@oldbytes.space)'s status on Friday, 10-Mar-2023 17:45:31 JST asm & tamsyn & forth, oh my!

     in reply to

     • clacke
     • Paolo Redaelli

     @paoloredaelli @clacke also, it has competition - the ZGC collector developed by Oracle, and Shenandoah by Red Hat; the details differ, but they all use some combination of concurrent tracing and copying and reference load barriers

     i guess all the fun GC development seems to be happening in Java with massive heaps, because Java is the most widely used GC'd system, and also the one used in the largest installations; that's a shame, because there are peculiarities to the Java environment (finalisation, universal synchronisation, unboxed values by default) that may not apply to other platforms (eg Lisp, Smalltalk)

     really i wish people would start doing serious work on GCs for tiny heaps (eg 16-bit addressable) rather than going "oh, naive mark & sweep can collect the whole heap in 2ms, Our Work Here Is Done™"

     clacke likes this.
   • Embed this notice
     clacke (clacke@libranet.de)'s status on Friday, 10-Mar-2023 17:51:14 JST clacke

     in reply to

     • Paolo Redaelli
     @millihertz @paoloredaelli Do these modern GCs also mix in arena allocation? You enter a code block, we statically know some data that will never escape the block and we know its upper bound size, so an instance of the code block gets its own arena of X pages and we just throw away the arena when we exit the block?
     
     Hmm, that sounds a lot like stack allocation. If nothing escapes, is there ever a reason not to use stack allocation? Maybe if the data is huge?
   • Embed this notice
     clacke (clacke@libranet.de)'s status on Friday, 10-Mar-2023 17:53:54 JST clacke

     in reply to

     • badsynthesis
     @badsynthesis @millihertz If the working set doesn't fit in RAM you're toast, of course.
     
     But the JVM could have seldom-referenced data that should be paged out and allow some file system blocks to stay in RAM.
   • Embed this notice
     badsynthesis (badsynthesis@infosec.exchange)'s status on Friday, 10-Mar-2023 17:53:56 JST badsynthesis

     in reply to

     • clacke

     @clacke @millihertz Last I looked into and experimented with this, hm around 2020? It was that if your JVM starts using offloading pages to disk cache the whole machine is toast and you might as well restart because it's quicker than waiting for it to recover.