Do you ever daydream about the incredibly wild optimizations a garbage collector could do if it had the direct control over virtual memory layout an operating system does
-
Do you ever daydream about the incredibly wild optimizations a garbage collector could do if it had the direct control over virtual memory layout an operating system does
What sort of control beneficial to GC cannot be achieved using mmap?
-
@mcc No, but I have had similar daydreams about what a compiler could do it it targeted CPU microcode rather than being limited to the x86 instruction set.
That sounds a little bit like the idea behind RISC. Somehow it wasn't the huge success it was hyped up to.
-
Do you ever daydream about the incredibly wild optimizations a garbage collector could do if it had the direct control over virtual memory layout an operating system does
@mcc years of "lemma theorem proof" computer science has left me comically unprepared to engage with this question
-
@mcc No, but I have had similar daydreams about what a compiler could do it it targeted CPU microcode rather than being limited to the x86 instruction set.
@h0m54r@mastodon.social Sounds like you might enjoy the belt-oriented https://millcomputing.com/docs/
-
@h0m54r how do you feel about itanium
@mcc I’m sad I never had the chance to use it… but I feel like you’d want to still have access to your complex instruction set for most things, just also be able to drop down a level for hyper optimising your really hot functions.
-
What sort of control beneficial to GC cannot be achieved using mmap?
@kasperd can modern mmaps result in virtual memory address blocks at a designated address? there's just lots of things you can do if you can rely on comparison between pointers or assuming your memory arena is contiguous.
I have not been awake long enough to get a cite but certain VMs are 32 bit instead of 64 bit, eating the 4GB memory limit, just so they can pull shenanigans along these lines with addressing modes
-
@kasperd can modern mmaps result in virtual memory address blocks at a designated address? there's just lots of things you can do if you can rely on comparison between pointers or assuming your memory arena is contiguous.
I have not been awake long enough to get a cite but certain VMs are 32 bit instead of 64 bit, eating the 4GB memory limit, just so they can pull shenanigans along these lines with addressing modes
@kasperd Like mmmaaaybbbe I could find a mmap mode where I pre-mmap a 32GB buffer but it doesn't actually assign those pages until I stop using them? I guess?
-
Do you ever daydream about the incredibly wild optimizations a garbage collector could do if it had the direct control over virtual memory layout an operating system does
@mcc does daydreaming of a world where garbage collection is the operating system’s job count
-
@kasperd Like mmmaaaybbbe I could find a mmap mode where I pre-mmap a 32GB buffer but it doesn't actually assign those pages until I stop using them? I guess?
You can use MAP_FIXED to get a range on a specific address. The address you specify that way does get rounded down to a multiple of the page size, but other than that it's used as is.
A zero value for address has a special meaning, so if you absolutely want to map at address 0 you need to ask for address 1 rounded down. Though some kernels won't permit that in the default configuration.
You can ask for more memory ahead of time. I am pretty sure the kernel only allocates the physical memory on the first write. However things get a little tricky with respect to over-commitment and such. As I understand it, the kernel will refuse the allocation if there is no way it could ever give you all of that memory. But I think the default is that when there is any doubt the kernel will let the allocation go through and kill the process later if it doesn't have memory after all. (I am not saying that's a good default.)
There is also the possibility of allocating a memory range with no permissions and then use mprotect to make parts of the range read and writable later. In that case it would make sense to me if the kernel only updates the count of committed memory once you make it writable, I don't know if that's actually what happens, but it should be easy to test.
I have used the approach of using mmap to allocate a range with no read or write permissions and then make a small range in the middle read-write with mprotect. My reason for using it has been to have guard pages around certain buffers as a security measure. It provides an extra layer of protection against buffer overflow vulnerabilities.
For some advanced use cases it can make sense to map a range with no privileges and later change the protection of the range from within a SIGSEGV handler when that address is accessed.
-
You can use MAP_FIXED to get a range on a specific address. The address you specify that way does get rounded down to a multiple of the page size, but other than that it's used as is.
A zero value for address has a special meaning, so if you absolutely want to map at address 0 you need to ask for address 1 rounded down. Though some kernels won't permit that in the default configuration.
You can ask for more memory ahead of time. I am pretty sure the kernel only allocates the physical memory on the first write. However things get a little tricky with respect to over-commitment and such. As I understand it, the kernel will refuse the allocation if there is no way it could ever give you all of that memory. But I think the default is that when there is any doubt the kernel will let the allocation go through and kill the process later if it doesn't have memory after all. (I am not saying that's a good default.)
There is also the possibility of allocating a memory range with no permissions and then use mprotect to make parts of the range read and writable later. In that case it would make sense to me if the kernel only updates the count of committed memory once you make it writable, I don't know if that's actually what happens, but it should be easy to test.
I have used the approach of using mmap to allocate a range with no read or write permissions and then make a small range in the middle read-write with mprotect. My reason for using it has been to have guard pages around certain buffers as a security measure. It provides an extra layer of protection against buffer overflow vulnerabilities.
For some advanced use cases it can make sense to map a range with no privileges and later change the protection of the range from within a SIGSEGV handler when that address is accessed.
@kasperd Thank you, this is not something I have read up on and is a great basis for future research. Here's an important question: Do *both* Linux mmap and the Windows equivalents offer these capabilities? Because my use cases invariably need to target both
-
@mcc does daydreaming of a world where garbage collection is the operating system’s job count
-
@glyph One thing I wonder is if we'd even need protected memory in that world. Per se. Or if we could throw out process protected memory and use the protected memory capabilities of the CPU for something entirely other
-
You can use MAP_FIXED to get a range on a specific address. The address you specify that way does get rounded down to a multiple of the page size, but other than that it's used as is.
A zero value for address has a special meaning, so if you absolutely want to map at address 0 you need to ask for address 1 rounded down. Though some kernels won't permit that in the default configuration.
You can ask for more memory ahead of time. I am pretty sure the kernel only allocates the physical memory on the first write. However things get a little tricky with respect to over-commitment and such. As I understand it, the kernel will refuse the allocation if there is no way it could ever give you all of that memory. But I think the default is that when there is any doubt the kernel will let the allocation go through and kill the process later if it doesn't have memory after all. (I am not saying that's a good default.)
There is also the possibility of allocating a memory range with no permissions and then use mprotect to make parts of the range read and writable later. In that case it would make sense to me if the kernel only updates the count of committed memory once you make it writable, I don't know if that's actually what happens, but it should be easy to test.
I have used the approach of using mmap to allocate a range with no read or write permissions and then make a small range in the middle read-write with mprotect. My reason for using it has been to have guard pages around certain buffers as a security measure. It provides an extra layer of protection against buffer overflow vulnerabilities.
For some advanced use cases it can make sense to map a range with no privileges and later change the protection of the range from within a SIGSEGV handler when that address is accessed.
If you want to see truly absurd usage of some of the possibilities, there is this video on how one guy managed to achieve 17 592 722 915 310 recursive calls on the stack.
- YouTube
Auf YouTube findest du die angesagtesten Videos und Tracks. Außerdem kannst du eigene Inhalte hochladen und mit Freunden oder gleich der ganzen Welt teilen.
(www.youtube.com)
-
@mcc does daydreaming of a world where garbage collection is the operating system’s job count
@glyph@mastodon.social @mcc@mastodon.social That's just called shell scripting. -
Do you ever daydream about the incredibly wild optimizations a garbage collector could do if it had the direct control over virtual memory layout an operating system does
@mcc i recently saw this, which i thought was a clever use of only userspace-level control over virtual memory layout https://github.com/plasma-umass/Mesh
-
@glyph@mastodon.social @mcc@mastodon.social That's just called shell scripting.
-
@mcc i recently saw this, which i thought was a clever use of only userspace-level control over virtual memory layout https://github.com/plasma-umass/Mesh
-
@glyph One thing I wonder is if we'd even need protected memory in that world. Per se. Or if we could throw out process protected memory and use the protected memory capabilities of the CPU for something entirely other
@mcc on the one hand, in principle, of course not! you can validate everything once at the garbage collector level, put the GC in the kerrnel, use formal methods or whatever and bob's your uncle, everything would be so fast!
on the other hand, in practice, I have been in the room (usually at PyCon) where garbage collector bugs are being diagnosed and fixed, and from that experience, "no, this must never happen"
-
@mcc on the one hand, in principle, of course not! you can validate everything once at the garbage collector level, put the GC in the kerrnel, use formal methods or whatever and bob's your uncle, everything would be so fast!
on the other hand, in practice, I have been in the room (usually at PyCon) where garbage collector bugs are being diagnosed and fixed, and from that experience, "no, this must never happen"
@glyph I've been thinking a lot in recent years about the unikernel environment
-
