JDK-8277822: Remove debug-only heap overrun checks in os::malloc and friends #6554

tstuefe · 2021-11-25T09:15:27Z

After integrating C heap overrun checks into NMT (https://bugs.openjdk.java.net/browse/JDK-8275320), we can now remove debug-only guarding memory for os::malloc() and friends.

This will:

reduce complexity of os::malloc, os::free, os::realloc (especially that one since realloc is tricky)
saves 48 bytes per malloc in debug builds. In my experiences this can sum up to a quite substantial overhead compared to release builds, especially since malloc allocations are often fine grained.
reduce behavioral differences between debug and release builds wrt memory layout and allocation paths.

Currently, we have always-on heap overrun checks in debug VMs. In order to preserve this feature after the patch, NMT is switched always on per default in debug builds (but can be switched off if needed, as opposed to the baked-in debug-only guards today).

We use NMT level summary here, which is very cheap since we don't track stacks, we just count some numbers in NMT categories. Memory overhead will still be a lot less than what we paid before with the quite generous debug-only guards.

Finally, this would also be a good coverage test for NMT.

For more information, please refer to the umbrella JBS (https://bugs.openjdk.java.net/browse/JDK-8275301).

Memory stomp reports are better now since NMT buffer overrun reporting (see JDK-8275320) is better.

Before:

[0.051s][warning][malloc,free] ## nof_mallocs = 11948, nof_frees = 2017
[0.051s][warning][malloc,free] ## memory stomp:
[0.051s][warning][malloc,free] GuardedMemory(0x00007fb3115ea560) base_addr=0x00007fb30c1df630 tag=0x0000000000000000 user_size=4096 user_data=0x00007fb30c1df650
[0.051s][warning][malloc,free]   Header guard @0x00007fb30c1df630 is OK
[0.051s][warning][malloc,free]   Trailer guard @0x00007fb30c1e0650 is BROKEN
[0.051s][warning][malloc,free]   User data appears to be in use
# To suppress the following error report, specify this argument

Old reporting was susceptible to C-heap corruption: a sufficiently corrupted C-heap caused the libc to abort before reporting was completed:

thomas@starfish:/shared/projects/openjdk/jdk-jdk/output-fastdebug$ ./images/jdk/bin/java -XX:+UseNewCode
[0.047s][warning][malloc,free] ## nof_mallocs = 11948, nof_frees = 2017
[0.047s][warning][malloc,free] ## memory stomp:
java: malloc.c:2379: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.
Aborted (core dumped)

The new reports, done by NMT, print out a hex dump of the corrupted area, before calling into libc. So this printout is something we always get, even if C-heap is corrupted beyond help:

thomas@starfish:/shared/projects/openjdk/jdk-jdk/output-fastdebug$ ./images/jdk/bin/java -XX:+UseNewCode
NMT Block at 0x00007f33c01a8e70, corruption at: 0x00007f33c01a9e80: 
0x00007f33c01a8df0:   00 00 00 00 00 00 00 00 75 00 00 00 00 00 00 00
0x00007f33c01a8e00:   50 00 00 00 00 00 00 00 00 00 00 00 01 00 9e e9
0x00007f33c01a8e10:   a8 b2 46 c6 33 7f 00 00 d0 7a 11 c0 33 7f 00 00
0x00007f33c01a8e20:   f0 4e 11 c0 33 7f 00 00 50 50 52 c6 33 7f 00 00
0x00007f33c01a8e30:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a8e40:   00 00 00 00 00 00 00 00 a0 ae 52 c6 33 7f 00 00
0x00007f33c01a8e50:   ff b7 f7 c5 33 7f 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a8e60:   e8 8e 00 00 00 00 00 00 25 10 00 00 00 00 00 00
0x00007f33c01a8e70:   00 10 00 00 00 00 00 00 00 00 00 00 0f 00 9e e9
0x00007f33c01a8e80:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a8e90:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a8ea0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a8eb0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a8ec0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a8ed0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a8ee0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
...
0x00007f33c01a9e00:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9e10:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9e20:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9e30:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9e40:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9e50:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9e60:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9e70:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9e80:   00 00 00 00 00 00 00 00 81 01 00 00 00 00 00 00
0x00007f33c01a9e90:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9ea0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9eb0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9ec0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9ed0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9ee0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00007f33c01a9ef0:   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
# To suppress the following error report, specify this argument

At first glance it seems that "nof_mallocs" etc are missing from this output. This is true, I removed them. They are not needed since the hs-err file contains an NMT summary report, which has more and finer grained information than that.

Tests:

GHAs (the windows failures are related to 8241403: "JavaThread::get_thread_name() should be ThreadSMR-aware")
we tested this patch for several days in SAP nightlies
manual tests x64 and x86 Linux

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8277822: Remove debug-only heap overrun checks in os::malloc and friends

Reviewers

Coleen Phillimore (@coleenp - Reviewer)
Zhengyu Gu (@zhengyu123 - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6554/head:pull/6554
$ git checkout pull/6554

Update a local copy of the PR:
$ git checkout pull/6554
$ git pull https://git.openjdk.java.net/jdk pull/6554/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 6554

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6554.diff

bridgekeeper · 2021-11-25T09:16:19Z

👋 Welcome back stuefe! 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 · 2021-11-25T09:18:33Z

@tstuefe 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.

…iends

mlbridge · 2021-11-30T09:55:42Z

Webrevs

bridgekeeper · 2022-01-04T18:09:33Z

@tstuefe This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

…-checks-in-os-malloc-and-friends

coleenp

This looks like a very nice cleanup, although I have a couple of questions.

coleenp · 2022-01-14T18:56:11Z

src/hotspot/share/runtime/os.cpp

+}
+static void break_if_ptr_caught(void* ptr) {
+  if (p2i(ptr) == (intptr_t)MallocCatchPtr) {
+    log_warning(malloc, free)("ptr caught: " PTR_FORMAT, p2i(ptr));


If this is the same as MallocCatchPtr, doesn't this output simply print MallocCatchPtr?

I don't understand what this does. ie. please tell what it does in a comment.

If this is the same as MallocCatchPtr, doesn't this output simply print MallocCatchPtr?

Yes

I don't understand what this does. ie. please tell what it does in a comment.

Oh, I did not invent it, I just unified the various places where before we checked MallocCatchPtr. E.g. here:

jdk/src/hotspot/share/runtime/os.cpp

Lines 700 to 703 in fb8fdc0

if ((intptr_t)ptr == (intptr_t)MallocCatchPtr) {

log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));

breakpoint();

}

The coding is old, I believe it predates the OpenJDK. I would love to get rid of MallocCatchPtr, if nobody uses it anymore.

coleenp · 2022-01-14T18:56:11Z

src/hotspot/share/runtime/os.cpp

@@ -38,7 +38,6 @@
 #include "logging/log.hpp"
 #include "logging/logStream.hpp"
 #include "memory/allocation.inline.hpp"
-#include "memory/guardedMemory.hpp"


Should this file now be deleted if not used?

I see it's used in jniCheck.cpp - was it double-guarded ? It's ok to leave this maybe to investigate for another time.

jniCheck.cpp was double guarded, yes. It's also horrible since it does a complete copy of the user buffer, including payload. I'd love to throw it away, have actually planned for it. But people get suspicious if I remove too much in a single RFE, therefore I wanted to keep this for a separate discussion. The discussion, in this case, is that we would have to bind NMT=enabled to -XcheckJni to get NMT to take care of overflow checks.

Hm, yes, I see maybe it's not a good idea since NMT is enabled by default only on debug and Xcheck:jni is a product level feature. Maybe Xcheck:jni can turn on NMT though. I suppose that would be ok.

I had the same thought, but it would be good to have this discussion separately.

coleenp · 2022-01-14T18:56:11Z

src/hotspot/share/runtime/os.cpp

+
+  const NMT_TrackingLevel level = MemTracker::tracking_level();
+
+  // If NMT is enabled, this checks for heap overwrites, then de-accounts the old block.


Could you provide a link where NMT checks for heap overwrites to save me looking for it? Thanks.

openjdk · 2022-01-14T18:57:10Z

@tstuefe 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:

8277822: Remove debug-only heap overrun checks in os::malloc and friends

Reviewed-by: coleenp, zgu

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 25 new commits pushed to the master branch:

3edcb13: 8280018: Remove obsolete VM_GenCollectFullConcurrent
9e536b6: 8280032: Update jib-profiles.js to use JMH 1.34 devkit
71ca85f: 8278831: Use table lookup for the last two bytes in Integer.getChars
431bd9a: 8280001: Serial: Add documentation to heap memory layout
a30aa52: 8279958: Provide configure hints for Alpine/apk package managers
590eb86: 8280016: gc/g1/TestShrinkAuxiliaryData30 test fails on large machines
c619666: 8276673: Optimize abs operations in C2 compiler
fef8f2d: 8279797: JFR: Show .jfc options in JFR.start help
9a18190: 8280048: Missing comma in copyright header
22b7295: 7001973: java/awt/Graphics2D/CopyAreaOOB.java fails
... and 15 more: https://git.openjdk.java.net/jdk/compare/965c64bca713446e7e513170aa9138a8a5eec5de...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.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

tstuefe · 2022-01-14T19:15:46Z

Hi Coleen,

thanks for looking at this! I already had given up hope :)

Could you provide a link where NMT checks for heap overwrites to save me looking for it? Thanks.

Sure. This came all with https://bugs.openjdk.java.net/browse/JDK-8275320.

Upon free (either one of os::free or os::realloc) we call, if NMT is enabled, MallocTracker::record_free -> MallocHeader::release() -> MallocHeader::check_block_integrity(). There, both header and footer canary of the block-to-be-freed are checked, as well as some other stuff.

jdk/src/hotspot/share/services/mallocTracker.cpp

Lines 160 to 220 in fb8fdc0

    
           void MallocHeader::check_block_integrity() const { 
        
           #define PREFIX "NMT corruption: " 
        
             // Note: if you modify the error messages here, make sure you 
        
             // adapt the associated gtests too. 
        
             // Weed out obviously wrong block addresses of NULL or very low 
        
             // values. Note that we should not call this for ::free(NULL), 
        
             // which should be handled by os::free() above us. 
        
             if (((size_t)p2i(this)) < K) { 
        
               fatal(PREFIX "Block at " PTR_FORMAT ": invalid block address", p2i(this)); 
        
             } 
        
             // From here on we assume the block pointer to be valid. We could 
        
             // use SafeFetch but since this is a hot path we don't. If we are 
        
             // wrong, we will crash when accessing the canary, which hopefully 
        
             // generates distinct crash report. 
        
             // Weed out obviously unaligned addresses. NMT blocks, being the result of 
        
             // malloc calls, should adhere to malloc() alignment. Malloc alignment is 
        
             // specified by the standard by this requirement: 
        
             // "malloc returns a pointer which is suitably aligned for any built-in type" 
        
             // For us it means that it is *at least* 64-bit on all of our 32-bit and 
        
             // 64-bit platforms since we have native 64-bit types. It very probably is 
        
             // larger than that, since there exist scalar types larger than 64bit. Here, 
        
             // we test the smallest alignment we know. 
        
             // Should we ever start using std::max_align_t, this would be one place to 
        
             // fix up. 
        
             if (!is_aligned(this, sizeof(uint64_t))) { 
        
               print_block_on_error(tty, (address)this); 
        
               fatal(PREFIX "Block at " PTR_FORMAT ": block address is unaligned", p2i(this)); 
        
             } 
        
             // Check header canary 
        
             if (_canary != _header_canary_life_mark) { 
        
               print_block_on_error(tty, (address)this); 
        
               fatal(PREFIX "Block at " PTR_FORMAT ": header canary broken.", p2i(this)); 
        
             } 
        
           #ifndef _LP64 
        
             // On 32-bit we have a second canary, check that one too. 
        
             if (_alt_canary != _header_alt_canary_life_mark) { 
        
               print_block_on_error(tty, (address)this); 
        
               fatal(PREFIX "Block at " PTR_FORMAT ": header alternate canary broken.", p2i(this)); 
        
             } 
        
           #endif 
        
             // Does block size seems reasonable? 
        
             if (_size >= max_reasonable_malloc_size) { 
        
               print_block_on_error(tty, (address)this); 
        
               fatal(PREFIX "Block at " PTR_FORMAT ": header looks invalid (weirdly large block size)", p2i(this)); 
        
             } 
        
             // Check footer canary 
        
             if (get_footer() != _footer_canary_life_mark) { 
        
               print_block_on_error(tty, footer_address()); 
        
               fatal(PREFIX "Block at " PTR_FORMAT ": footer canary broken at " PTR_FORMAT " (buffer overflow?)", 
        
                     p2i(this), p2i(footer_address())); 
        
             } 
        
           #undef PREFIX 
        
           }

I also added an ASCII picture of the NMT headers:

jdk/src/hotspot/share/services/mallocTracker.hpp

Lines 240 to 292 in fb8fdc0

    
           /* 
        
            * Malloc tracking header. 
        
            * 
        
            * If NMT is active (state >= minimal), we need to track allocations. A simple and cheap way to 
        
            * do this is by using malloc headers. 
        
            * 
        
            * The user allocation is preceded by a header and is immediately followed by a (possibly unaligned) 
        
            *  footer canary: 
        
            * 
        
            * +--------------+-------------  ....  ------------------+-----+ 
        
            * |    header    |               user                    | can | 
        
            * |              |             allocation                | ary | 
        
            * +--------------+-------------  ....  ------------------+-----+ 
        
            *     16 bytes              user size                      2 byte 
        
            * 
        
            * Alignment: 
        
            * 
        
            * The start of the user allocation needs to adhere to malloc alignment. We assume 128 bits 
        
            * on both 64-bit/32-bit to be enough for that. So the malloc header is 16 bytes long on both 
        
            * 32-bit and 64-bit. 
        
            * 
        
            * Layout on 64-bit: 
        
            * 
        
            *     0        1        2        3        4        5        6        7 
        
            * +--------+--------+--------+--------+--------+--------+--------+--------+ 
        
            * |                            64-bit size                                |  ... 
        
            * +--------+--------+--------+--------+--------+--------+--------+--------+ 
        
            * 
        
            *           8        9        10       11       12       13       14       15          16 ++ 
        
            *       +--------+--------+--------+--------+--------+--------+--------+--------+  ------------------------ 
        
            *  ...  |   bucket idx    |     pos idx     | flags  | unused |     canary      |  ... User payload .... 
        
            *       +--------+--------+--------+--------+--------+--------+--------+--------+  ------------------------ 
        
            * 
        
            * Layout on 32-bit: 
        
            * 
        
            *     0        1        2        3        4        5        6        7 
        
            * +--------+--------+--------+--------+--------+--------+--------+--------+ 
        
            * |            alt. canary            |           32-bit size             |  ... 
        
            * +--------+--------+--------+--------+--------+--------+--------+--------+ 
        
            * 
        
            *           8        9        10       11       12       13       14       15          16 ++ 
        
            *       +--------+--------+--------+--------+--------+--------+--------+--------+  ------------------------ 
        
            *  ...  |   bucket idx    |     pos idx     | flags  | unused |     canary      |  ... User payload .... 
        
            *       +--------+--------+--------+--------+--------+--------+--------+--------+  ------------------------ 
        
            * 
        
            * Notes: 
        
            * - We have a canary in the two bytes directly preceding the user payload. That allows us to 
        
            *   catch negative buffer overflows. 
        
            * - On 32-bit, due to the smaller size_t, we have some bits to spare. So we also have a second 
        
            *   canary at the very start of the malloc header (generously sized 32 bits). 
        
            * - The footer canary consists of two bytes. Since the footer location may be unaligned to 16 bits, 
        
            *   the bytes are stored individually. 
        
            */

that may clarify things. We have two canaries, one in the header directly preceding the user payload, one following the user payload.

coleenp · 2022-01-14T19:28:08Z

thanks for looking at this! I already had given up hope :)

Lots of large reviews seem to fallen through the cracks for me. I'd just noticed it. I'd also missed the NMT change. I think this is a nice cleanup. Hopefully @zhengyu123 can review this also.

tstuefe · 2022-01-14T19:37:57Z

thanks for looking at this! I already had given up hope :)

Lots of large reviews seem to fallen through the cracks for me. I'd just noticed it. I'd also missed the NMT change. I think this is a nice cleanup. Hopefully @zhengyu123 can review this also.

Thank you. It is not that urgent, we missed jdk18 already. OTOH, larger cleanups like this are better placed at the start of a new release anyway, so no harm done.

coleenp · 2022-01-14T22:33:04Z

Yes, much better as a JDK 19 change.

zhengyu123

LGTM

dholmes-ora · 2022-01-18T01:33:07Z

src/hotspot/share/runtime/globals.hpp

@@ -543,7 +543,7 @@ const intx ObjectAlignmentInBytes = 8;
          "compression. Otherwise the level must be between 1 and 9.")      \
          range(0, 9)                                                       \
                                                                            \
-  product(ccstr, NativeMemoryTracking, "off",                               \
+  product(ccstr, NativeMemoryTracking, DEBUG_ONLY("summary") NOT_DEBUG("off"), \


Hi Thomas,

I'm a bit concerned about always enabling part of NMT in debug as that affects the bulk of our hotspot testing. What is the potential overhead from enabling NMT this way? We would need to run this patch through our CI to ensure it doesn't introduce any issues.

Cheers,
David

Hi David,

I understand your concern. I have had this patch in our internal tests enabled for several months now, but am fine with you guys doing more tests.

My arguments for this:

using NMT in debug builds in place of the old hard wired fences should be less overhead, not more. NMT is quite frugal. NMT=summary does:

increase the counter per NMT category (basically atomic-incing a number in a static array)

add and populate a malloc header and a footer
That's it. We did the same thing before. The old code atomically increased two global counters (inc_stat_counter), then added a header and a footer. Only the old header/footer had been much larger than what NMT does. So we use less memory, not more, in debug.

Another argument for this is that NMT is important. It gets used by support, typically in stressful situations. I rather have it thoroughly tested as part of our internal tests. I am not sure that we have ironed out every single NMT issue. NMT feels very stable to me, but there may be lingering issues. But then we should fix them.

All that said, I'd be happy for you to give this patch a spin in your CI. I can hold off the push for a bit.

Cheers, Thomas

Thanks for the additional info Thomas. I will run it through our CI and report back.

I'm seeing a timeout with langtools tier1 test tools/javac/failover/CheckAttributedTree.java on macosx-aarch64. It timed out after 9m. I'll try a few re-runs.

10 re-runs all passed fine - maximum time 3m01s. A re-run on the same machine as previously timed-out was only 47s. So I think we are generally good to go here. Thanks.

Thanks for doing this David.

tstuefe · 2022-01-19T11:14:40Z

Thanks @coleenp, @zhengyu123 and @dholmes-ora

Tests at SAP went through smoothly too.

/integrate

openjdk · 2022-01-19T11:16:12Z

Going to push as commit 39b1d75.
Since your change was applied there have been 65 commits pushed to the master branch:

5af7f25: 8274811: Remove superfluous use of boxing in java.base
44fe958: 6465404: some problems in CellEditor related API docs
b0496b0: 8279970: two AppCDS tests fail after JDK-8261455
4eb4f94: 8279956: Useless method Scheduling::ComputeLocalLatenciesForward()
4f4da3b: 8275318: loaded_classes_do may see ArrayKlass before InstanceKlass is loaded
3a421e4: 8280122: SupportedGroupsExtension should output "named groups" rather than "versions"
1a20628: 8248404: AArch64: Remove uses of long and unsigned long
46fd683: 8176567: nsk/jdi/ReferenceType/instances/instances002: TestFailure: Unexpected size of referenceType.instances(nsk.share.jdi.TestInterfaceImplementer1): 11, expected: 10
e314a4c: 8280124: Reduce branches decoding latin-1 chars from UTF-8 encoded bytes
bdfa15d: 8250801: Add clhsdb "threadcontext" command
... and 55 more: https://git.openjdk.java.net/jdk/compare/965c64bca713446e7e513170aa9138a8a5eec5de...master

Your commit was automatically rebased without conflicts.

openjdk · 2022-01-19T11:16:25Z

@tstuefe Pushed as commit 39b1d75.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

tstuefe force-pushed the JDK-8277822-Remove-debug-only-heap-overrun-checks-in-os-malloc-and-friends branch from 44ed71c to 9f0e0d7 Compare Nov 25, 2021

openjdk bot added the hotspot-runtime hotspot-runtime-dev@openjdk.org label Nov 25, 2021

tstuefe force-pushed the JDK-8277822-Remove-debug-only-heap-overrun-checks-in-os-malloc-and-friends branch 4 times, most recently from e6163f8 to f0bca7a Compare Nov 26, 2021

JDK-8277822-Remove-debug-only-heap-overrun-checks-in-os-malloc-and-fr…

a571f6d

…iends

tstuefe force-pushed the JDK-8277822-Remove-debug-only-heap-overrun-checks-in-os-malloc-and-friends branch from f0bca7a to a571f6d Compare Nov 30, 2021

tstuefe marked this pull request as ready for review Nov 30, 2021

openjdk bot added the rfr Pull request is ready for review label Nov 30, 2021

initialize newly malloced memory

0085c24

tstuefe added 2 commits Jan 13, 2022

Merge branch 'master' into JDK-8277822-Remove-debug-only-heap-overrun…

2d24cb1

…-checks-in-os-malloc-and-friends

Merge branch 'master' into JDK-8277822-Remove-debug-only-heap-overrun…

78ee112

…-checks-in-os-malloc-and-friends

coleenp approved these changes Jan 14, 2022

View changes

openjdk bot added the ready Pull request is ready to be integrated label Jan 14, 2022

zhengyu123 approved these changes Jan 17, 2022

View changes

dholmes-ora reviewed Jan 18, 2022

View changes

openjdk bot added the integrated Pull request has been integrated label Jan 19, 2022

openjdk bot closed this Jan 19, 2022

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jan 19, 2022

JDK-8277822: Remove debug-only heap overrun checks in os::malloc and friends #6554

JDK-8277822: Remove debug-only heap overrun checks in os::malloc and friends #6554

tstuefe commented Nov 25, 2021 •

edited by openjdk bot

bridgekeeper bot commented Nov 25, 2021

openjdk bot commented Nov 25, 2021

mlbridge bot commented Nov 30, 2021 •

edited

bridgekeeper bot commented Jan 4, 2022

coleenp left a comment

coleenp Jan 14, 2022

coleenp Jan 14, 2022 •

edited

tstuefe Jan 14, 2022

coleenp Jan 14, 2022

coleenp Jan 14, 2022

tstuefe Jan 14, 2022

coleenp Jan 14, 2022

tstuefe Jan 14, 2022

coleenp Jan 14, 2022

openjdk bot commented Jan 14, 2022 •

edited

tstuefe commented Jan 14, 2022

coleenp commented Jan 14, 2022

tstuefe commented Jan 14, 2022

coleenp commented Jan 14, 2022

zhengyu123 left a comment

dholmes-ora Jan 18, 2022

tstuefe Jan 18, 2022

dholmes-ora Jan 18, 2022

dholmes-ora Jan 18, 2022

dholmes-ora Jan 18, 2022

coleenp Jan 18, 2022

tstuefe commented Jan 19, 2022

openjdk bot commented Jan 19, 2022

openjdk bot commented Jan 19, 2022

	if ((intptr_t)ptr == (intptr_t)MallocCatchPtr) {
	log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
	breakpoint();
	}


		const NMT_TrackingLevel level = MemTracker::tracking_level();

		// If NMT is enabled, this checks for heap overwrites, then de-accounts the old block.

JDK-8277822: Remove debug-only heap overrun checks in os::malloc and friends #6554

JDK-8277822: Remove debug-only heap overrun checks in os::malloc and friends #6554

Conversation

tstuefe commented Nov 25, 2021 • edited by openjdk bot

Progress

Issue

Reviewers

Reviewing

bridgekeeper bot commented Nov 25, 2021

openjdk bot commented Nov 25, 2021

mlbridge bot commented Nov 30, 2021 • edited

Webrevs

bridgekeeper bot commented Jan 4, 2022

coleenp left a comment

Choose a reason for hiding this comment

coleenp Jan 14, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

openjdk bot commented Jan 14, 2022 • edited

tstuefe commented Jan 14, 2022

coleenp commented Jan 14, 2022

tstuefe commented Jan 14, 2022

coleenp commented Jan 14, 2022

zhengyu123 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tstuefe commented Jan 19, 2022

openjdk bot commented Jan 19, 2022

openjdk bot commented Jan 19, 2022

tstuefe commented Nov 25, 2021 •

edited by openjdk bot

mlbridge bot commented Nov 30, 2021 •

edited

coleenp Jan 14, 2022 •

edited

openjdk bot commented Jan 14, 2022 •

edited