RFR(S): 8220348: [ntintel] asserts about copying unalinged array
Langer, Christoph
christoph.langer at sap.com
Wed Dec 4 14:39:56 UTC 2019
Hi Martin,
thanks for looking into this and coming up with this patch. The test failures were quite annoying 😊
In hotspot, there is coding to define a macro "ATTRIBUTE_ALIGNED(x)". I'd rather like to see that we define such a macro in the JDK code as well and use it. I think it would make the code more readable. Other than that, +1
Cheers
Christoph
> -----Original Message-----
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> Of Doerr, Martin
> Sent: Montag, 2. Dezember 2019 16:13
> To: core-libs-dev at openjdk.java.net; security-dev <security-
> dev at openjdk.java.net>
> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Subject: [CAUTION] RFR(S): 8220348: [ntintel] asserts about copying
> unalinged array
>
> 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.0
> 0/
> 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
More information about the security-dev
mailing list