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?

@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?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7748

Reply via email to