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-boun...@openjdk.java.net> On Behalf > Of Doerr, Martin > Sent: Montag, 2. Dezember 2019 16:13 > To: core-libs-dev@openjdk.java.net; security-dev <security- > d...@openjdk.java.net> > Cc: Lindenmaier, Goetz <goetz.lindenma...@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
