Skip to content

Fix --fstdalloc on OpenBSD#835

Open
omegametabroccolo wants to merge 1 commit intokoka-lang:devfrom
omegametabroccolo:obsd-stdalloc
Open

Fix --fstdalloc on OpenBSD#835
omegametabroccolo wants to merge 1 commit intokoka-lang:devfrom
omegametabroccolo:obsd-stdalloc

Conversation

@omegametabroccolo
Copy link
Copy Markdown
Contributor

@omegametabroccolo omegametabroccolo commented Nov 12, 2025

OpenBSD removed malloc_usable_size from libc in version 6.5, we need to keep track of each allocation's size ourselves. Of course doing this adds some memory overhead, especially when doing lots of small allocations, but I think it's better than nothing. The test suite runs fine on my OpenBSD -current machine when adding --fstdalloc to commonFlags in test/Spec.hs.

@daanx
Copy link
Copy Markdown
Member

daanx commented Dec 5, 2025

Thanks! .. but yikes, that can cause a lot of overhead just to support constructor contexts (which are the only feature that need to copy arbitrary blocks). As an aside, do you need to use the standard allocator on FreeBSD?

@omegametabroccolo
Copy link
Copy Markdown
Contributor Author

As an aside, do you need to use the standard allocator on FreeBSD?

I don't know about FreeBSD, but assuming you meant OpenBSD, mimalloc works just fine, I'd just like to be able to use the system's allocator which comes with a bunch of security features.

constructor contexts (which are the only feature that need to copy arbitrary blocks)

Maybe we could make constructor contexts carry their own size so that all other allocations don't have to. That seems a bit more involved than this PR though, especially if we don't want to have an impact on systems that do have a way to get an allocation's size. I'll try to look into it.

@daanx
Copy link
Copy Markdown
Member

daanx commented Dec 6, 2025

Ah yes, OpenBSD. We can't really have just constructor contexts carry their size as they can switch between the actual type (say list) and their context. We could perhaps optimize a bit: for any regular type that does not have "raw" fields (like int64 etc) we can determine the size from the scan filed in the header. Only for types with raw fields (that follow the scan fields) we need to have the size. However, perhaps there is some clever thing we can do here.. but not sure. Also, perhaps a bit too much just to support OpenBSD -- the current PR solves it as well :-) I'll ponder it a bit more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants