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.

Sign up for GitHub

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

Jump to bottom

implement __aligned_malloc() and __aligned_free() #59

Merged
merged 6 commits into from
May 9, 2024
Merged

implement __aligned_malloc() and __aligned_free() #59

merged 6 commits into from
May 9, 2024

Conversation

gabylb
Copy link
Member

@gabylb gabylb commented May 7, 2024 •
edited
Loading

  • implement __aligned_malloc() and __aligned_free(): call posix_memalign() if building with -mzos-target=zosv3r1 on z/OS 3.1, in which case __aligned_free() calls free(); otherwise use a local implementation to align memory from malloc()
  • fix include_next typo: on LE 3.1 zos-io.cc fails to pick up LOCK_* definitions from the system's sys/file.h
  • fix conflicts with system's time.h: __clockid_t is defined in sys/types.h if >= v2r5, CLOCK_REALTIME and CLOCK_MONOTONIC are already defined in the system's time.h if >= v2r5

@gabylb gabylb self-assigned this May 7, 2024
@gabylb gabylb force-pushed the posix_memalign branch 3 times, most recently from e0700ed to 8bfd5e7 Compare May 7, 2024 18:35
@perry-ca
Copy link
Collaborator

perry-ca commented May 7, 2024

Be careful with this. Plan out your LE 3.1 migration strategy and include it in the changes. Consider these points:

  • someone may just take an application built on 2.4/2.5 and run it un recompiled on LE 3.1
  • someone recompiling their application on LE 3.1
  • someone recompiling zoslib on LE 3.1
    The answers may be straight forward but just make sure nothing is going to break.

IgorTodorovskiIBM
IgorTodorovskiIBM approved these changes May 7, 2024
View reviewed changes
Copy link
Collaborator

@IgorTodorovskiIBM IgorTodorovskiIBM left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

gabylb added a commit that referenced this pull request May 7, 2024
@gabylb
remove unneeded comment
d743b4c 
See #59 (comment)
@gabylb
Copy link
Member Author

gabylb commented May 7, 2024

Be careful with this. Plan out your LE 3.1 migration strategy and include it in the changes. Consider these points:

  • someone may just take an application built on 2.4/2.5 and run it un recompiled on LE 3.1
  • someone recompiling their application on LE 3.1
  • someone recompiling zoslib on LE 3.1
    The answers may be straight forward but just make sure nothing is going to break.

Thanks. I've removed the comment; another issue is someone already using those new __aligned_malloc and __aligned_free, so they can't be removed.

@perry-ca
Copy link
Collaborator

perry-ca commented May 7, 2024

You should still put in support for LE 3.1. My comment wasn't based on the FIXME comment. It was just a general observation and experience with these kinds of features. Subtle things can cause problems down the road. The nice thing here is you can put the 3.1 support in and test the various combinations.

@gabylb
Copy link
Member Author

gabylb commented May 7, 2024

You should still put in support for LE 3.1.

Let's say we have a posix_memalign() that works on LE 3.1 (original) as well as a zoslib implementation for prior versions. How would one free the allocated memory that would work on all LE versions, without having macros in the calling app that decide which version of free to call?

@perry-ca
Copy link
Collaborator

perry-ca commented May 7, 2024

I'd either put a #if in the header to map __align_malloc to posix_memalign or change the implementation in the cpp file to use posix_memalign instead of the hack if targeting LE 3.1. You can tell if you are targeting LE 3.1 by including features.h and then checking the TARGET_LIB macro.

I think both of these are safe. Test them to make sure.

@gabylb
Copy link
Member Author

gabylb commented May 7, 2024

posix_memalign() has different args and return value, as documented here, and requires free() to free its memory, which cannot be used when memory is allocated on LE prior to 3.1, and guards in the app I'm working to check the LE version are not acceptable.

@perry-ca
Copy link
Collaborator

perry-ca commented May 8, 2024

posix_memalign() has different args and return value, as documented here, and requires free() to free its memory, which cannot be used when memory is allocated on LE prior to 3.1, and guards in the app I'm working to check the LE version are not acceptable.

I'd change the parameter list for __aligned_malloc() to match posix_memalign() so it acts as a replacement. This will also make it easier for people to switch between the two. And on LE 3.1, you would make __aligned_free() call free().

gabylb added 3 commits May 8, 2024 18:36
@gabylb
implement __aligned_malloc() and __aligned_free()
2c06e96 
Call posix_memalign() if building with `-mzos-target=zosv3r1` on z/OS 3.1,
in which case `__aligned_free()` calls `free()`. Otherwise use a local
implementation to align memory from `malloc()`.
@gabylb
fix include_next typo
3178c2e 
On LE 3.1 zos-io.cc fails to pick up LOCK_* definitions from the
system's sys/file.h.
@gabylb
fix conflicts with system's time.h
e29fb70 
__clockid_t is defined in sys/types.h if >= v2r5,
CLOCK_REALTIME and CLOCK_MONOTONIC are already defined
in the system's time.h if >= v2r5.
perry-ca
perry-ca reviewed May 9, 2024
View reviewed changes
Copy link
Collaborator

@perry-ca perry-ca left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. I made one minor nit about features.h

src/zos.cc Outdated
@@ -26,6 +25,7 @@
#include <dlfcn.h>
#include <errno.h>
#include <fcntl.h>
#include <features.h>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you included other system headers you don't need to include this one directly.

@gabylb
add assert for offset in __aligned_malloc
19a0e41 
Also remove unneeded include of features.h since other
system headers already include it.
@gabylb gabylb requested a review from perry-ca May 9, 2024 18:36
perry-ca
perry-ca approved these changes May 9, 2024
View reviewed changes
Copy link
Collaborator

@perry-ca perry-ca left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

IgorTodorovskiIBM
IgorTodorovskiIBM approved these changes May 9, 2024
View reviewed changes
Copy link
Collaborator

@IgorTodorovskiIBM IgorTodorovskiIBM left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for adding the time.h fixes

gabylb added 2 commits May 9, 2024 15:52
@gabylb
check size and alignment values
a8634ee 
This is for the local implementation to behave the same
way in terms of the argument values and return.
@gabylb
test __aligned_malloc with alignment 0
51fe556
@gabylb
Copy link
Member Author

gabylb commented May 9, 2024

I made minor change after you approved, please review the last 2 commits. Thanks.

perry-ca
perry-ca approved these changes May 9, 2024
View reviewed changes
Copy link
Collaborator

@perry-ca perry-ca left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

src/zos.cc
@@ -3104,10 +3104,16 @@ extern "C" void *__aligned_malloc(size_t size, size_t alignment) {
return ptr;
return nullptr;
#else
if (size == 0)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might give different behaviour from malloc(0) or posix_memalign(&ptr, align, 0).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to posix_memalign on z/OS: "If size was specified to 0, posix_memalign() returns zero and sets memptr to a null pointer."

@gabylb gabylb merged commit 52679a3 into main May 9, 2024
@gabylb gabylb deleted the posix_memalign branch May 9, 2024 21:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@IgorTodorovskiIBM IgorTodorovskiIBM IgorTodorovskiIBM approved these changes

@perry-ca perry-ca perry-ca approved these changes

Assignees

@gabylb gabylb

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@gabylb @perry-ca @IgorTodorovskiIBM