Get<Primitive>ArrayElements and zero-sized arrays

[Thomas Stüfe]

On Wed, Aug 18, 2021 at 6:54 AM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
> On 18/08/2021 2:29 pm, Thomas Stüfe wrote:
> > Hi,
> >
> > in jni.cpp, in DEFINE_GETSCALARARRAYELEMENTS, we return a non-NULL write
> > protected special marker address in case the array was zero sized.
> >
> > Is there a particular reason to still allow read access from that
> address?
> > The change history does not tell since the code seems to be older than
> the
> > mercurial history.
>
> It was introduced by this issue:
>
> https://bugs.openjdk.java.net/browse/JDK-4804447
>
>
Thanks for the history!



> Is there a reason to not return a readable address?
>
>
I was wondering in what scenario reading from that address would constitute
a valid operation. The code seems deliberate with the comment. We write
protect the address to catch code which writes to it, so it seems
asymmetrical to allow reading.

If we forbid all-access, not only writing, we could just replace the
reserve and protect calls with a known-to-be-invalid constant address (e.g.
for most OSes, a non-NULL but very low address within the first page would
do). Which would show up better in cores. We also could assert on
ReleaseXXXArrayElements that this special value should not be freed. We
cannot do this now since AFAICS get_bad_address() can be racy and the page
initialized more than once if several threads enter this function
simultaneously.

Though looking at the code I see we never commit that page, so we may
already crash on read access depending on how the OS handles reading from
uncommitted memory. On AIX this would work, on Windows too since
os::protect_memory() would commit the underlying page.

Cheers, Thomas


> Cheers,
> David
>
> > Thanks, Thomas
> >
>