Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Marshal.AllocHGlobal alignment #33228

Closed
tmds opened this issue Mar 5, 2020 · 6 comments
Closed

Marshal.AllocHGlobal alignment #33228

tmds opened this issue Mar 5, 2020 · 6 comments
Labels
area-System.Runtime.InteropServices documentation Documentation bug or enhancement, does not impact product or test code
Milestone

Comments

@tmds
Copy link
Member

tmds commented Mar 5, 2020

Documentation doesn't specify the alignment of allocated memory returned by Marshal.AllocHGlobal. What is the expected alignment? Does it change based on machine bitness/OS?

Perhaps it's interesting to have an overload that accepts alignment as an argument (cfr posix_memalign)?

cc @adamsitnik

@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added area-System.Runtime.InteropServices untriaged New issue has not been triaged by the area owner labels Mar 5, 2020
@tmds
Copy link
Member Author

tmds commented Mar 5, 2020

For Linux, the implementation calls malloc (LocalAlloc -> HeapAlloc -> PAL_malloc -> malloc).

This is documented to be aligned as

functions return a pointer to the allocated memory that is suitably aligned for any kind of variable.

So this property will also hold for AllocHGlobal: if you want to allocate for a native struct with C types, you can assume AllocHGlobal returns something with proper alignment.

For Linux/x64, alignment is 16, that is alignment of long double.
For Linux/x86, alignment is 8. that is alignment of long long (long double is aligned at 4).

@jkotas
Copy link
Member

jkotas commented Mar 5, 2020

Documentation doesn't specify the alignment of allocated memory

Could you please submit documentation edit to make this clear now that you have found the answer?

it's interesting to have an overload that accepts alignment as an argument

Could you please create a new API proposal issue on this? FWIW, I am not sure whether it is a good idea to make it overload. I think it would need to be a new pair of alloc/free methods to make it implementable cross-platform (e.g. see last post in https://stackoverflow.com/questions/33696092/whats-the-correct-replacement-for-posix-memalign-in-windows).

@jkotas jkotas added the documentation Documentation bug or enhancement, does not impact product or test code label Mar 5, 2020
@tmds
Copy link
Member Author

tmds commented Mar 5, 2020

We know what it does on Linux now. We still need the answer for Windows. It may also be different on macOS (it uses something other than malloc).

@tmds
Copy link
Member Author

tmds commented Mar 5, 2020

Created #33244 for API proposal.

@jeffschwMSFT jeffschwMSFT added this to the Future milestone Mar 5, 2020
@jeffschwMSFT jeffschwMSFT removed the untriaged New issue has not been triaged by the area owner label Mar 5, 2020
@GrabYourPitchforks
Copy link
Member

On Windows this function calls the Win32 API LocalAlloc. The MSDN docs for that function don't explicitly call out an alignment, but historically this has been at least 8-byte aligned. I'd be shocked if the OS team ever broke this assumption given the massive compatibility hit it'd incur. See also https://web.archive.org/web/20160204192037/https://support.microsoft.com/en-us/kb/286470.

@jkotas
Copy link
Member

jkotas commented May 4, 2021

Superseded by #33244

@jkotas jkotas closed this as completed May 4, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Jun 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Runtime.InteropServices documentation Documentation bug or enhancement, does not impact product or test code
Projects
None yet
Development

No branches or pull requests

5 participants