On 11/03/2022 4:50 pm, Thomas Stuefe wrote:
On Fri, 11 Mar 2022 05:59:00 GMT, David Holmes <david.hol...@oracle.com> wrote:
Thanks for pointing this out. I ran more tests and found that on certain
platforms, there are other structures that have problems with uninitialized
gaps. I ended up changing `os::malloc()` to zero the buffer when running with
-Xshare:dump. Hopefully one extra check of `if (DumpSharedSpaces)` doesn't
matter too much for regular VM executions because `os::malloc()` already has a
high overhead.
This is raising red flags for me sorry. Every user of the JDK is now paying a penalty
because of something only needed when dumping the shared archive. It might not be much
but it is the old "death by a thousand cuts".
Well, he does it for `DumpSharedSpaces` only. Are you really worried about that
one load+conditional jump?
As I said (and I'm not the only one who says this :) ) "death by a
thousand cuts".
@iklam: I dislike the fact that CDS terminology is now in os::malloc. I would give this
another flag, "ZapMalloc" or similar, and maybe merge it with the
`DEBUG_ONLY(memset(..uninitBlockPad))` above.
Is there any way to tell the OS to pre-zero all memory provided to the current
process, such that we could set that when dumping and not have to check on each
allocation?
No. Malloced memory is not provided by the OS but by the glibc, and it may be
polluted with whatever the allocator did with it (eg pointers to chain free
blocks), or by prior user payload.
Glibc has a specific tunable, `glibc.malloc.perturb`, that initializes malloc
memory to a given value, but you cannot directly set the value. It is very
handy to check for uninitialized memory. Always wanted to add some tests that
used it, but never got around. But obviously its nothing you could do in
production.
And I have to wonder how easy it would be to re-introduce non-deterministic
values in these data structures that are being dumped. Does malloc itself even
guarantee to return the same set of addresses for the same sequence of requests
in different executions of a program?
No, of course not. Non-Java threads may still run concurrently, no? System
libraries do malloc too. But are pointer *values* even the problem?
I assumed that pointer values could be the problem, even if not
presently, but apparently all the pointers get rewritten to use offsets
from the known base of the shared archive - so not an issue.
Cheers,
David
-------------
PR: https://git.openjdk.java.net/jdk/pull/7748
