Memory Safe Languages in Android 13

Re:Memory Safe Languages in Android 13 by kaba0 on Friday December 02, 2022 @12:06PM (#33833247)

An OS will always need some tiny assembly part, as some instructions needed for the kernel simply never gets generated by compilers. Also, an OS itself is pretty much a garbage collector for resources, it could very well reuse/link into its own GC for better performance.

Are we really talking about the “price” of managed code, when C code is chock-full of linked list data structures? A list of boxed objects is more cache-friendly than that. It is simply not always that performance sensitive to begin with (e.g. does it really matter if it queries the available display connectors in 0.0001s or 10x that?)

Regarding MirageOS, they actually achieved better performance by using a managed language than contemporary C OSs for select tasks. This is possible due to context switches being very expensive, and a managed env can get away with (some?) of those.

[ Parent | on HN ]

Re:Memory Safe Languages in Android 13 by jstimpfle on Friday December 02, 2022 @12:26PM (#33833586)

Those linked lists give some nice guarantee that significantly simplify a lot of code and give some guarantees that you just can't have otherwise.

Context switching can be expensive, but I don't see what's specific about managed envs about that. Fundamentally you have to have trust in code, and need to have the hardware support to enforce authenticity of the trusted code in order to avoid context switching. Maybe a promising development is CPUs growing more and more cores, and more and more kernel resources being available through io_uring and similar interfaces.

[ Parent | on HN ]