RFR: JDK-8270308: Amalloc aligns size but not return value (take 2) [v2]

Thomas Stuefe stuefe at openjdk.java.net
Thu Jul 22 13:02:48 UTC 2021


On Thu, 22 Jul 2021 11:44:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I strongly agree that _max and the chunk boundaries should be aligned to 64bit alignment. But as I wrote, that would cause more widespread changes. I would just duplicate the work I did with my first proposal https://github.com/openjdk/jdk/pull/4784. Which already exists, and it does do all you requested. Maybe take a look at that? If you like it, I propose we put this minimal patch through and later use my first PR as a base for a better cleanup.
>> 
>> The current behavior for Amalloc(0) is non-malloc-standard: it returns a non-unique-non-NULL address (since the next allocation returns the same address). When I worked on the first proposal I tried to fix this too. First tried to return NULL, which does not work, callers assume that's an OOM. Then by returning a unique pointer, but I did not like the memory waste. The true fix would be to disallow size==0 and fix callers not to allocate 0 bytes. But I believe that memory allocated with size==0 is not used, since it would be overwritten by the next allocation.
>> 
>> I'll modify the patch and do a size==0->size=1 for 32bit only. Let's hope that does not blow up arena sizes too much.
>> 
>> About std::max_align_t, can we use that? I hard-coded malloc align in a number of places.
>
> Can you just assert that size > 0 for Amalloc?

Unfortunately not, since that is actually done. I would have to hunt down callers which do this. That is maybe worthwhile, but would be a larger change.

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

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


More information about the hotspot-dev mailing list