RFR(S): 8220348: [ntintel] asserts about copying unalinged array

[Thomas Stüfe]

Hi Martin,

this makes sense. This is the right way to force alignment. I do not like
the platform code in the shared file but do not think this is a big deal.

+#if defined (_WIN32) && defined (_MSC_VER)

Why do you think we need _MSC_VER too? Is OpenJDK on Windows even buildable
with anything other than VC++?

Cheers, Thomas

On Mon, Dec 2, 2019 at 4:14 PM Doerr, Martin <martin.doerr at sap.com> wrote:

> Hi,
>
> I'd like to propose a fix for an old issue on 32 bit Windows (also for an
> 11u backport):
> https://bugs.openjdk.java.net/browse/JDK-8220348
>
> Some jdk native methods use jni_SetLongArrayRegion with a stack allocated
> buffer.
> jni_SetLongArrayRegion uses Copy::conjoint_jlongs_atomic which requires
> jlongs to be 8 byte aligned (asserted).
> However, Windows 32 bit only uses 4 byte alignment for jlong arrays by
> default.
> I found such issues in the following files:
> src/java.prefs/windows/native/libprefs/WindowsPreferences.c
> src/java.security.jgss/share/native/libj2gss/GSSLibStub.c
> I suggest to use __declspec(align(8)) there.
>
> Webrev:
> http://cr.openjdk.java.net/~mdoerr/8220348_ntintel_stack_align/webrev.00/
> Please review.
>
> I think using 8 byte alignment is not a disadvantage for 64 bit.
>
> I guess there are still people interested in this platform with jdk14.
> Otherwise I could contribute it as 11u only fix.
>
> Is there a better way to force 8 byte alignment for jlongs or jlong arrays
> on stack?
> Best regards,
> Martin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20191204/e74be729/attachment.htm>