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

8324781: runtime/Thread/TestAlwaysPreTouchStacks.java failed with Expected a higher ratio between stack committed and reserved #18592

Open
wants to merge 14 commits into
base: master
Choose a base branch
from

Conversation

limingliu-ampere
Copy link
Contributor

@limingliu-ampere limingliu-ampere commented Apr 3, 2024

The testcase failed on Oracle CI since JDK-8315923. The root cause is that Oracle CI runs Linux-5.4.17-UEK where the value of MADV_POPULATE_WRITE (23) is used as MADV_DONTEXEC which is not supported by upstream. This PR solves the testcase failure by checking versions of kernels first, and checking the availability of MADV_POPULATE_WRITE when they are not older than 5.14.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed (2 reviews required, with at least 2 Reviewers)

Issues

  • JDK-8324781: runtime/Thread/TestAlwaysPreTouchStacks.java failed with Expected a higher ratio between stack committed and reserved (Bug - P2)
  • JDK-8325218: gc/parallel/TestAlwaysPreTouchBehavior.java fails (Bug - P3)(⚠️ The fixVersion in this issue is [23] but the fixVersion in .jcheck/conf is 24, a new backport will be created when this pr is integrated.)

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/18592/head:pull/18592
$ git checkout pull/18592

Update a local copy of the PR:
$ git checkout pull/18592
$ git pull https://git.openjdk.org/jdk.git pull/18592/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 18592

View PR using the GUI difftool:
$ git pr show -t 18592

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/18592.diff

Webrev

Link to Webrev Comment

@limingliu-ampere
Copy link
Contributor Author

/issue add 8325218

@bridgekeeper
Copy link

bridgekeeper bot commented Apr 3, 2024

👋 Welcome back limingliu-ampere! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented Apr 3, 2024

@limingliu-ampere This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8324781: runtime/Thread/TestAlwaysPreTouchStacks.java failed with Expected a higher ratio between stack committed and reserved
8325218: gc/parallel/TestAlwaysPreTouchBehavior.java fails

Reviewed-by: stefank, jsjolen

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 572 new commits pushed to the master branch:

  • 0e4d4a0: 8320725: AArch64: C2: Add "requires_strict_order" flag for floating-point add and mul reduction
  • badf1cb: 8331675: gtest CollectorPolicy.young_min_ergo_vm fails after 8272364
  • 4d6064a: 8333649: Allow different NativeCall encodings
  • fe9c63c: 8333931: Problemlist serviceability/jvmti/vthread/CarrierThreadEventNotification
  • 41c88bc: 8333756: java/lang/instrument/NativeMethodPrefixApp.java failed due to missing intrinsic
  • 3a01b47: 8330205: Initial troff manpage generation for JDK 24
  • 9691153: 8329141: Obsolete RTM flags and code
  • 13642cb: 8333828: Use value javadoc tag in java.lang.{Float, Double}
  • b254762: 8333829: ProblemList sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8333317
  • b68609f: 8333779: Parallel: Remove Summary phase related debug print during Full GC
  • ... and 562 more: https://git.openjdk.org/jdk/compare/819f3d6fc70ff6fe54ac5f9033c17c3dd4326aa5...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@stefank, @jdksjolen) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the rfr Pull request is ready for review label Apr 3, 2024
@openjdk
Copy link

openjdk bot commented Apr 3, 2024

@limingliu-ampere
Adding additional issue to issue list: 8325218: gc/parallel/TestAlwaysPreTouchBehavior.java fails.

@openjdk
Copy link

openjdk bot commented Apr 3, 2024

@limingliu-ampere The following label will be automatically applied to this pull request:

  • hotspot-runtime

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added the hotspot-runtime hotspot-runtime-dev@openjdk.org label Apr 3, 2024
@mlbridge
Copy link

mlbridge bot commented Apr 3, 2024

Copy link
Member

@stefank stefank left a comment

Choose a reason for hiding this comment

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

I have looked at this a bit and have a few comments.

Comment on lines 3056 to 3066
page_size = os::vm_page_size();
} else if (err == 0) {
page_size = 0;
}
if (UseMadvPopulateWrite) {
log_debug(gc, os)("Called madvise(" PTR_FORMAT ", " SIZE_FORMAT ", %d):"
" error='%s' (errno=%d), when THPMode::always=%d and"
" UseTransparentHugePages=%d",
p2i(first), len, MADV_POPULATE_WRITE, os::strerror(err),
err, (int)(HugePages::thp_mode() == THPMode::always),
(int)UseTransparentHugePages);
Copy link
Member

Choose a reason for hiding this comment

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

This function has become quite messy: It checks UseMadvPopulateWrite tree times. It mutates the input variable. It logs even when no failure occurred (This might be a bug).

I'd much prefer if we could straighten out the code into something like this (I've not tried to compile this):

size_t os::pd_pretouch_memory(void* first, void* last, size_t page_size) {
  if (HugePages::thp_mode() != THPMode::always && !UseTransparentHugePages) {
    // No THP. Use the platform-independent pretouch memory code.
    return page_size;
  }

  if (!UseMadvPopulateWrite) {
    // Use small pages with the platform-independent pretouch memory code.
    // When using THP we need to always pre-touch using small pages as the
    // OS will initially always use small pages.
    return os::vm_page_size();
  }

  const size_t len = pointer_delta(last, first, sizeof(char)) + page_size;
  if (::madvise(first, len, MADV_POPULATE_WRITE) != -1) {
    // Succeeded
    // 0 signals that the platform-independent pretouch memory code should not run.
    return 0;
  }

  // madvise failed
  int err = errno;
  
  log_debug(gc, os)("Called madvise(" PTR_FORMAT ", " SIZE_FORMAT ", %d):"
                    " error='%s' (errno=%d), when THPMode::always=%d and"
                    " UseTransparentHugePages=%d",
                    p2i(first), len, MADV_POPULATE_WRITE, os::strerror(err),
                    err, (int)(HugePages::thp_mode() == THPMode::always),
                    (int)UseTransparentHugePages);

  if (err == EINVAL) {
    // Not supported. When using THP we need to always pre-touch using
    // small pages as the OS will initially always use small pages.
    return os::vm_page_size();
  }

  assert(false, "Unexpected  error='%s' (errno=%d)",os::strerror(err), err);
  return page_size;
}

It is unclear to me why a failure with EINVAL should return small pages but other failures should return another page size. Why would we get EINVAL if we already performed the correct checks when setting up UseMadvPopulateWrite? Or is the problem that we skip performing the necessary checks if the user forcefully sets UseMadvPopulateWrite on the command line? Maybe we shouldn't allow that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is unclear to me why a failure with EINVAL should return small pages but other failures should return another page size.

Thanks to point it out. It is a mistake.

FLAG_SET_DEFAULT(UseMadvPopulateWrite, (::madvise(0, 0, MADV_POPULATE_WRITE) == 0));
}
}
log_debug(gc, os)("UseMadvPopulateWrite=%d", (int)(UseMadvPopulateWrite ? 1 : 0));
Copy link
Member

Choose a reason for hiding this comment

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

Is this temporary debugging code? We have -XX:+PrintFlagsFinal to check the resulting flag values.


// Check the availability of MADV_POPULATE_WRITE.
FLAG_SET_DEFAULT(UseMadvPopulateWrite, (::madvise(0, 0, MADV_POPULATE_WRITE) == 0));
Linux::version_init();
Copy link
Member

Choose a reason for hiding this comment

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

check_pax() and Linux::version_init() are unrelated things. Please add a blankline between them.

@@ -4821,6 +4822,20 @@ jint os::init_2(void) {
}
}

// Check the availability of MADV_POPULATE_WRITE.
if (FLAG_IS_DEFAULT(UseMadvPopulateWrite) && UseMadvPopulateWrite) {
Copy link
Member

Choose a reason for hiding this comment

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

Should we really allow the user to forcefully set this and trigger a path that is not going to be correct on old kernels?

… turns on UseMadvPopulteWrite when not supported
Copy link
Member

@stefank stefank left a comment

Choose a reason for hiding this comment

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

Thanks for the updates. I have a few more comments.

Comment on lines 4836 to 4838
if (!FLAG_IS_DEFAULT(UseMadvPopulateWrite) && !supportMadvPopulateWrite)
warning("Platform is supposed not to support MADV_POPULATE_WRITE, "
"disabling using it to pretouch (-XX:-UseMadvPopulateWrite)");
Copy link
Member

Choose a reason for hiding this comment

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

I don't see the code that disables UseMadvPopulateWrite. Is it missing?

The warning message is a bit awkward. Could it be changed to something like: "Platform does not support MADV_POPULATE_WRITE, disabling using it to pretouch memory (-XX:-UseMadvPopulateWrite)"

Could you also make sure to use {} even for single statement if blocks?

Comment on lines 179 to 180
long os::Linux::_release_major = -1;
long os::Linux::_release_minor = -1;
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't this be named something like _kernel_release_*?

*major = -1;
*minor = -1;

void os::Linux::version_init() {
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't this be named something like kernel_release_init?

Comment on lines 382 to 387
long* set_v = major;
while (*minor == -1 && walker != nullptr) {
long* set_v = &_release_major;
while (_release_minor == -1 && walker != nullptr) {
if (isdigit(walker[0])) {
*set_v = strtol(walker, &walker, 10);
set_v = minor;
set_v = &_release_minor;
} else {
++walker;
}
Copy link
Member

Choose a reason for hiding this comment

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

I can't tell if this code is correct or not.

  • When is walker ever nullptr?
  • Don't wee need error handling for strtol?

Maybe this is all pre-existing issues, but I'd like to get someone else to review and sign off on this code.

Copy link
Contributor

Choose a reason for hiding this comment

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

Not typical code for me either.

Quoting my man pages:

     If endptr is  not NULL, strtol() stores the address  of the first
     invalid character  in *endptr.  If  there were no digits  at all,
     strtol()  stores  the original  value  of  nptr in  *endptr  (and
     returns  0).  In  particular, if  *nptr is  not \[aq]\0\[aq]  but
     **endptr is \[aq]\0\[aq] on return, the entire string is valid.

Given a string such as 2.6.5, each strtol will put walker at a new . and as minor is always set the condition in the loop will become false. The walker will never be null. Looking at the documentation, we don't need error-handling for the strtol call (won't over/underflow and will be a valid version revision).

Copy link
Contributor

Choose a reason for hiding this comment

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

Basic fix: change walker != nullptr to walker[0] != '\0' and add a test case for this.

Comment on lines 100 to 103
static void kernel_version(long* major, long* minor) {
*major = _release_major;
*minor = _release_minor;
}
Copy link
Member

Choose a reason for hiding this comment

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

Do we really wan this function now, or could this be just plain getters?:

static long kernel_release_major() {
  return _kernel_release_major;
}
static long kernel_release_minor() {
  return _kernel_release_minor;
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

systemMemoryBarrier_linux.cpp uses this function. If the interface was changed here, the patch would involve some unrelated things.

Copy link
Member

Choose a reason for hiding this comment

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

Right. But you are changing the entire kernel_version() implementation and associated functions. Maybe that should be done as an initial, separate change then? Splitting this out into two RFE:s might make it easier to review as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If it requires an initial change, I will prefer discussing the interface here. On the one hand, there is just one additional place to call the function, so the change would not be big. On the other hand, I'm not a author yet.

Copy link
Member

Choose a reason for hiding this comment

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

Hmm. Thinking about this a bit more. Why do we even need to make the changes to the kernel release parsing code? It is so that we don't have to parse it more than once, right? If that's the case I don't think that's important for this PR. You could just revert all those changes, get this PR reviewed and integrated, and then, if you want, propose a new PR that makes the kernel release parsing changes. I think that would be the smoothest path forward.

@stefank
Copy link
Member

stefank commented Apr 8, 2024

/reviewers 2 reviewer

@openjdk
Copy link

openjdk bot commented Apr 8, 2024

@stefank
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 2 Reviewers).

Comment on lines 4832 to 4843
struct utsname buffer;
int ret = uname(&buffer);
if (ret != 0) {
log_warning(os)("uname(2) failed to get kernel version: %s",
os::errno_name(ret));
}

long major = -1, minor = -1;
bool supportMadvPopulateWrite =
(ret == 0 &&
(sscanf(buffer.release, "%ld.%ld", &major, &minor) == 2) &&
(major > 5 || (major == 5 && minor >= 14)) &&
Copy link
Member

Choose a reason for hiding this comment

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

Why isn't this using the os::Linux::kernel_version() function?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just not get the idea. Previous discussions mentioned the problems of kernel_version, so I used an alternative method. Using kernel_version here is fine with me.

Copy link
Member

Choose a reason for hiding this comment

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

FYI: @jdksjolen is going to fix kernel_version with #18697.

Copy link
Member

@stefank stefank left a comment

Choose a reason for hiding this comment

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

This looks good to me now. Could we get a second Reviwer for this change?

Linux::kernel_version(&major, &minor);
bool supportMadvPopulateWrite =
((major > 5 || (major == 5 && minor >= 14)) &&
(::madvise(0, 0, MADV_POPULATE_WRITE) == 0));
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't this be checking MADV_POPULATE_WRITE_value?

I still can't get my head around the possible compile time values versus the potential runtime interpretation of the MADV_POPULATE_WRITE value.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For example, Linux 5.4-UEK does not support populating pages, and MADV_POPULATE_WRITE is not defined there. However, the kernel internally interprets 23 as MADV_DONEXEC, while 23 is a value used by upstream kernels as MADV_POPULATE_WRITE. MADV_POPULATE_WRITE_value is used by hotspot internally, and used for compiling JDK properly when MADV_POPULATE_WRITE is not defined. MADV_POPULATE_WRITE_value was suggested there: #15781 (comment)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Additionally, if MADV_POPULATE_WRITE is defined but not the same as MADV_POPULATE_WRITE_value, there will be a build failure, so hotspot is guaranteed to use 23 here regardless of compile time or runtime. 23 may not be interpreted as MADV_POPULATE_WRITE by a downstream kernel. A known case is a downstream of pre-5.14 kernel, so the version of kernel is checked here. This patch does not have tricks on advice numbers.

Copy link
Member

Choose a reason for hiding this comment

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

Okay the comment:

 // Some downstream kernels recognize MADV_POPULATE_WRITE_value as another

made me think we needed to check the "value" version but I see now they are already guaranteed to be the same.

@limingliu-ampere
Copy link
Contributor Author

/label add hotspot,hotspot-gc

@openjdk openjdk bot added hotspot hotspot-dev@openjdk.org hotspot-gc hotspot-gc-dev@openjdk.org labels Apr 18, 2024
@openjdk
Copy link

openjdk bot commented Apr 18, 2024

@limingliu-ampere
The hotspot label was successfully added.

The hotspot-gc label was successfully added.

Copy link
Member

@stefank stefank left a comment

Choose a reason for hiding this comment

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

Good that you found that !UseTransparentHugesPages bug.

Copy link
Contributor

@jdksjolen jdksjolen left a comment

Choose a reason for hiding this comment

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

LGTM, thank you.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label May 6, 2024
@limingliu-ampere
Copy link
Contributor Author

/integrate

@openjdk openjdk bot added the sponsor Pull request is ready to be sponsored label May 7, 2024
@openjdk
Copy link

openjdk bot commented May 7, 2024

@limingliu-ampere
Your change (at version fe98ec0) is now ready to be sponsored by a Committer.

@limingliu-ampere
Copy link
Contributor Author

Hi, @stefank and @jdksjolen, could you please sponsor this?

@stefank
Copy link
Member

stefank commented May 22, 2024

I'm running this through our tier1-tier3 testing now.

@limingliu-ampere
Copy link
Contributor Author

Hi, @stefank did the testing run fine?

@tstuefe
Copy link
Member

tstuefe commented Jun 6, 2024

Just stating this here, I don't like the fact that this patch punishes all Distros for a problem that only exists in UEK kernel. This is not a problem with the mainline kernel.

@cnqpzhang
Copy link
Contributor

To clarify, the current revised patch does NOT add any if-cond to check UEK, instead it enhances the check of the readiness of MADV_POPULATE_WRITE on 5.14 and beyond (stated by Linux kernel official docs). In addition, the two test cases failing on UEK kernel can also be a justification that the condition of having supportMadvPopulateWrite needs to be strengthened. We could not say that it is a problem only exists in UEK kernel, in theory every distros could backport part of MADV_POPULATE_WRITE function from 5.14 to previous version or reuse any madv op code there, which is out of our control or our testing coverage.

Therefore, having the >=5.14 check can be a safer way to all.

@tstuefe
Copy link
Member

tstuefe commented Jun 6, 2024

To clarify, the current revised patch does NOT add any if-cond to check UEK, instead it enhances the check of the readiness of MADV_POPULATE_WRITE on 5.14 and beyond (stated by Linux kernel official docs). In addition, the two test cases failing on UEK kernel can also be a justification that the condition of having supportMadvPopulateWrite needs to be strengthened. We could not say that it is a problem only exists in UEK kernel, in theory every distros could backport part of MADV_POPULATE_WRITE function from 5.14 to previous version or reuse any madv op code there, which is out of our control or our testing coverage.

The problem does not exist for other kernels if they don't break binary compatibility with the mainline kernel. Which UEK does by introducing new madvise flags that occupy numerical slots that should be unoccupied. A clean downstream kernel can downport MADV_POPULATE_WRITE without problems since there will be no numerical clash.

Now, even if a clean downstream kernel were to downport support for MADV_POPULATE_WRITE, we would not benefit from it.

Therefore, having the >=5.14 check can be a safer way to all.

The real issue is a clash with UEK-proprietary flags. Adding proprietary flags is not a good practice. More clashes are waiting to happen, including clashes with the far more dangerous MADV_DOEXEC.

I worry that someone, at some point, may add an innocous patch in the future using one of these and trigger usage of MADV_DOEXEC. I would feel better if we had clear safeguards to prevent that.

@cnqpzhang
Copy link
Contributor

cnqpzhang commented Jun 6, 2024

The real issue is a clash with UEK-proprietary flags. Adding proprietary flags is not a good practice. More clashes are waiting to happen, including clashes with the far more dangerous MADV_DOEXEC.

Thanks @tstuefe, agree with you on this point, so having >=5.14 check is a way to protect JVM from accidentally executing unexpected/dangerous ops like MADV_DOEXEC, although the if-cond is not an elegant code snippet to OpenJDK. @limingliu-ampere and I did not have tests (or any downport experiments) on pre-5.14 so we are not sure if a downport support for MADV_POPULATE_WRITE would normally function or practically benefit.

@stefank @jdksjolen what's your opinion?
In the change suggested by @tstuefe , the pretouch function on UEK pre-5.14 would keep the bug until oracle/linux-uek#23 gets fixed by UEK, while -XX:-UseMadvPopulateWrite will be added to the two test cases so failures will be gone (hidden). Please share your comments, thanks.

@tstuefe
Copy link
Member

tstuefe commented Jun 6, 2024

Meanwhile, I am warming to the current approach. I understand that this it avoids referring to individual downstream vendors, which I agree may be brittle.

My main concern is to prevent future flag mismatches. Therefore, my proposal is to do what this patch does, but in a more generic way. Essentially, encoding that for certain flags, we cannot rely on older kernel correctly ignoring them. But we assume that downstream kernel vendors will at least fix conflicts when they merge in flags from mainline. We sacrifice the ability to benefit from vendor-specific backports, but that is the compromise.

The flags I'd like to guard for now are:

  1. UEK7: MADV_DONTNEED_LOCKED -> MADV_DOEXEC
  2. UEK7: MADV_COLLAPSE -> MADV_DONTEXEC
  3. UEK6: MADV_POPULATE_READ -> MADV_DOEXEC
  4. UEK6: MADV_POPULATE_WRITE -> MADV_DONTEXEC

If the vendor keeps up its routine of just shifting the proprietary flags to the end of the numerical MADV range for each new mainline flag, we will continue to have problems and this list may grow.

The mechanism could be very close to what @limingliu-ampere does now, only a tad more generic. E.g.:

bool os::Linux::can_use_madvise_flag(int someflag) { 
  // have a hardcoded array of { flag, kernel version } tupels. 
  // Search it for someflag, and if found, return false if host kernel version is older than the encoded version. 
  // Otherwise return true.
}

and then maybe wrap the madvise call with something like this:

bool os::Linux::checked_madvise(..., someflag) {
  assert(can_use_madvise_flag(someflag))
  call real madvise
}

in addition to something like this in initialization:

if (UseMadvPopulateWrite && ! can_use_madvise_flag(MADV_POPULATE_WRITE)) {
   FLAG_SET_ERGO(UseMadvPopulateWrite, false);
}

Do you like this, does this make sense?

@openjdk openjdk bot removed the sponsor Pull request is ready to be sponsored label Jun 7, 2024
@cnqpzhang
Copy link
Contributor

FYI,

oracle/linux-uek#23 has recently fixed the madv flag conflict issue, at the three concerned branches: UEK7U2, UEK6U3, and UEK5U5.

- #define MADV_DOEXEC	22		/* do inherit across exec */
- #define MADV_DONTEXEC	23		/* don't inherit across exec */
+ #define MADV_DOEXEC	201		/* do inherit across exec */
+ #define MADV_DONTEXEC	202		/* don't inherit across exec */

uek7/u2: oracle/linux-uek@6064722
uek6/u3: oracle/linux-uek@b5974a1
uek5/u5: oracle/linux-uek@818b8c8

- UEK has fixed the compatibility with upstream kernels;
- Pretouch behaviors will be covered by other tests.
@openjdk openjdk bot removed the ready Pull request is ready to be integrated label Jun 11, 2024
@openjdk openjdk bot added the ready Pull request is ready to be integrated label Jun 11, 2024
@limingliu-ampere
Copy link
Contributor Author

Hi, @tstuefe. Could you please take a look? The patch had been limited to testcases, as there were already fixes in UEK and you created a ticket to cover pretouch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot hotspot-dev@openjdk.org hotspot-gc hotspot-gc-dev@openjdk.org hotspot-runtime hotspot-runtime-dev@openjdk.org ready Pull request is ready to be integrated rfr Pull request is ready for review
6 participants