|
|
Subscribe / Log in / New account

Rejuvenating Autoconf

Rejuvenating Autoconf

Posted Oct 28, 2020 8:01 UTC (Wed) by smurf (subscriber, #17840)
In reply to: Rejuvenating Autoconf by dvdeug
Parent article: Rejuvenating Autoconf

> just like all systems linked together that want to pass floating point numbers have to use the same FP system.

Surprise, there's a FP format standard which everybody uses these days because, well, there's no good reason not to.

There's no such thing as a GC standard because there are a lot of different trade-offs to be made. Plus, not every GC supports every memory model. Refcounting or not? Incremental? Would mark+sweep work, would it kill your cache, or would the machie swap to death? You need an upper bound on GC latency? You want weak pointers? Can you use them as they are or do you need to lock them? Moveable memory? If so, do you use handles (i.e. pointer-to-pointer) or does the GC patch your pointers? How does the GC find pointers in the first place, assuming that it needs to? Do you support destructors, can they re-establish a reference, do they run again if *that* gets deleted?

How do you support destructors when the language requires them but the system GC doesn't have that concept? Answer: you run your own GC on top. No other choice, assuming that crippling the language is not an option.

> I don't see how this is different from the Linux kernel starting before a single byte of your code is executed.

Linux isn't interested in your code and which GC it uses, if any. Dalvik and ART are. A more appropriate referent would be the language's runtime library, not Linux. Except that the Linux libc runtime doesn't do any garbage collection …


to post comments

Rejuvenating Autoconf

Posted Oct 28, 2020 8:34 UTC (Wed) by smurf (subscriber, #17840) [Link]

Addendum: While Linux isn't interested in your code, the reverse is false, your code should definitely be interested in Linux, or rather in the environment it's running in. GCing on a lightly-loaded non-memory-starved system is far easier to do than the same thing on a busy system that's swapping. Yet different trade-offs are required for a system that's tight on memory but not swapping because it's embedded and doesn't *have* swap.


Copyright © 2024, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds