You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, thanks for maintaining these bindings. I was wondering if you can update your submodule of mimalloc from v1.6.7 to v2.0.0 to take advantage of the improvements.
It's currently pointed at master, which has the same code as v2.0.0 (the only patch it doesn't have that the v2.0.0 tg has is a change to the cmake build script, which we no longer use).
@errantmind appears to be correct:
master: latest stable release.
dev: development branch for mimalloc v1.
dev-slice: development branch for mimalloc v2 with a new algorithm for managing internal mimalloc pages.
The currect cc build script also only works for master and dev while dev-slice, which is being referred to here as V2, does not. I think it would be better to use feature flags for development branches though rather than use dev over the stable release.
Hey, I'm on mobile right now so my ability to look into this is limited.. but it looks like the submodule is pointed at master which is not the 2.0 (dev-slice) branch upstream. Can anyone verify?
Though, i still think that it could be useful for some to be able to switch between versions if they need to. Since there arn't that much differences between the two, and it keeps working, it could be useful for some to be able to switch between v1 and v2 if they want/need to. But also use the latest version of either the dev or dev-slice branch. Maybe it's even an idea that people can select the version by tags and those tags can be set via en ENV variable as is done for many crates which bind to external libraries.
If not set, it will just use the defaults, else it will try to pull that tag/hash and use that, which is all up-to the developer who is changing that.
Activity
[-]Update from sys from v1.6.7 to v2.0.0[/-][+]Update submodule from v1.6.7 to v2.0.0[/+]thomcc commentedon Mar 8, 2021
It's currently pointed at master, which has the same code as v2.0.0 (the only patch it doesn't have that the v2.0.0 tg has is a change to the cmake build script, which we no longer use).
errantmind commentedon Mar 16, 2021
Are you sure? It looks like v2.0.0 comes from the dev-slice branch which is 200 commits ahead of Master
ryancinsight commentedon Mar 19, 2021
@errantmind appears to be correct:
master: latest stable release.
dev: development branch for mimalloc v1.
dev-slice: development branch for mimalloc v2 with a new algorithm for managing internal mimalloc pages.
The currect cc build script also only works for master and dev while dev-slice, which is being referred to here as V2, does not. I think it would be better to use feature flags for development branches though rather than use dev over the stable release.
ajeetdsouza commentedon May 26, 2022
mimalloc 2.0.0 is now stable. We can just upgrade the dependency rather than make a feature.
CC @errantmind @thomcc @ryancinsight @BlackDex
thomcc commentedon May 26, 2022
It looks like the submodule is pointed at 2.0.6 already.
ajeetdsouza commentedon May 26, 2022
My bad, didn't see that. Can we close this issue and the related PRs, in that case?
errantmind commentedon May 28, 2022
Hey, I'm on mobile right now so my ability to look into this is limited.. but it looks like the submodule is pointed at master which is not the 2.0 (dev-slice) branch upstream. Can anyone verify?
BlackDex commentedon Jun 4, 2022
The sub-module currently links to https://github.com/microsoft/mimalloc/tree/f2712f4a8f038a7fb4df2790f4c3b7e3ed9e219b which is the exact same hash as the tag
v2.0.6, so the current version of mimalloc_rust links to the latest v2 tagged version, which is nice 😄 .Though, i still think that it could be useful for some to be able to switch between versions if they need to. Since there arn't that much differences between the two, and it keeps working, it could be useful for some to be able to switch between v1 and v2 if they want/need to. But also use the latest version of either the
devordev-slicebranch. Maybe it's even an idea that people can select the version by tags and those tags can be set via en ENV variable as is done for many crates which bind to external libraries.If not set, it will just use the defaults, else it will try to pull that tag/hash and use that, which is all up-to the developer who is changing that.