From mail at smogura.eu Fri Jan 1 08:37:02 2021 From: mail at smogura.eu (=?utf-8?B?UmFkb3PFgmF3IFNtb2d1cmE=?=) Date: Fri, 1 Jan 2021 08:37:02 +0000 Subject: Support for 64-bit pointers Message-ID: <043D75D3-7490-4B3D-89B6-B8CFD28283CE@smogura.eu> Hi all, I hope this message finds you well & first of all thank you all for wonderful implementation this can be major addition to JDK. I was working / checking JDK 16 foreign implementation, and realised that it may not support all 64bit pointers. In current version of implementation (many places), there?s a lot of range checks. However longs in Java are signed, and C pointers are unsigned so, at least for x86-64 architectures this should be taken on account, otherwise we would not be able to address whole memory in straightforward way (largest block size is 2^31, can directly address upper half of memory). Can I suggest: * The range checks using comparison operators should be replaced by Long.compareUnsigned; * Remove checks if lower bound / upper bound is negative - negative values represent upper half of memory * Remove checks and usage of Long.MAX_VALUE - i.e. MemorySegment.allocateRestricted uses EVRYTING which is bounded to (0, Long.MAX), but should be to (0, -1), or (0, 0xFFFFFFFF_FFFFFFFF). Kind regards, Rado From duke at openjdk.java.net Fri Jan 1 11:02:19 2021 From: duke at openjdk.java.net (duke) Date: Fri, 1 Jan 2021 11:02:19 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 12 new changesets Message-ID: <3861c836-7710-48c6-83d8-4325f5bf6df5@openjdk.org> Changeset: 97c99b5d Author: Guoxiong Li Committer: Jonathan Gibbons Date: 2020-12-26 17:30:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/97c99b5d 8216400: improve handling of IOExceptions in JavaCompiler.close() 8069116: improve fatal error handling in JavaCompiler Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java + test/langtools/tools/javac/fatalErrors/ImproveFatalErrorHandling.java Changeset: 779ee110 Author: Xiaohong Gong Committer: Ningsheng Jian Date: 2020-12-28 02:44:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/779ee110 8257147: [TESTBUG] Set a larger default loop count for the VectorAPI jtreg tests Reviewed-by: psandoz ! test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte128VectorTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Double128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double128VectorTests.java ! test/jdk/jdk/incubator/vector/Double256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double256VectorTests.java ! test/jdk/jdk/incubator/vector/Double512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double512VectorTests.java ! test/jdk/jdk/incubator/vector/Double64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double64VectorTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Float128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float128VectorTests.java ! test/jdk/jdk/incubator/vector/Float256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float256VectorTests.java ! test/jdk/jdk/incubator/vector/Float512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float512VectorTests.java ! test/jdk/jdk/incubator/vector/Float64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float64VectorTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Int128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int128VectorTests.java ! test/jdk/jdk/incubator/vector/Int256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int256VectorTests.java ! test/jdk/jdk/incubator/vector/Int512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int512VectorTests.java ! test/jdk/jdk/incubator/vector/Int64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int64VectorTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Long128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long128VectorTests.java ! test/jdk/jdk/incubator/vector/Long256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long256VectorTests.java ! test/jdk/jdk/incubator/vector/Long512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long512VectorTests.java ! test/jdk/jdk/incubator/vector/Long64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long64VectorTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Short128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short128VectorTests.java ! test/jdk/jdk/incubator/vector/Short256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short256VectorTests.java ! test/jdk/jdk/incubator/vector/Short512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short512VectorTests.java ! test/jdk/jdk/incubator/vector/Short64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short64VectorTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java ! test/jdk/jdk/incubator/vector/VectorReshapeTests.java ! test/jdk/jdk/incubator/vector/templates/Unit-header.template ! test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template Changeset: e2aa724a Author: Jonathan Gibbons Date: 2020-12-24 17:32:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e2aa724a 8258941: Test specify the Classpath exception in the header Reviewed-by: vromero ! test/langtools/lib/combo/tools/javac/combo/CompilationTestCase.java ! test/langtools/tools/javac/lint/JdkInternalAbuseOfVbc.out ! test/langtools/tools/javac/lint/SomeVbc.java ! test/langtools/tools/javac/records/RecordCompilationTests.java ! test/langtools/tools/javac/records/RecordMemberTests.java ! test/langtools/tools/javac/records/VarargsRecordsTest.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java Changeset: 3f67afd3 Author: Prasanta Sadhukhan Date: 2020-12-24 18:50:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3f67afd3 8251377: [macos11] JTabbedPane selected tab text is barely legible Reviewed-by: prr ! src/java.desktop/macosx/classes/apple/laf/JRSUIUtils.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaImageFactory.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m Changeset: fb607f16 Author: Sergey Bylokhov Date: 2020-12-26 05:52:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fb607f16 8245922: [macos] Taskbar.Feature.ICON_BADGE_NUMBER no longer supported on MacOS Reviewed-by: kcr, prr ! src/java.desktop/macosx/classes/apple/laf/JRSUIUtils.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CTaskbarPeer.java Changeset: 881bceb9 Author: Guoxiong Li Committer: Vicente Romero Date: 2020-12-28 15:32:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/881bceb9 8258662: JDK 17ea: Crash compiling instanceof check involving sealed interface Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java + test/langtools/tools/javac/sealed/T8258662/T8258662.java Changeset: 07c93fab Author: Jesper Wilhelmsson Date: 2020-12-29 05:24:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/07c93fab Merge ! src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m Changeset: 8435f0da Author: Guoxiong Li Committer: Jonathan Gibbons Date: 2020-12-30 17:20:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8435f0da 8258525: Some existing tests should use /nodynamiccopyright/ instead of the standard header Reviewed-by: jjg ! test/langtools/tools/javac/4917091/Test256a.java ! test/langtools/tools/javac/4917091/Test256a.out ! test/langtools/tools/javac/4917091/Test256b.java ! test/langtools/tools/javac/4917091/Test256b.out ! test/langtools/tools/javac/6979683/TestCast6979683_BAD34.java ! test/langtools/tools/javac/6979683/TestCast6979683_BAD34.java.errlog ! test/langtools/tools/javac/6979683/TestCast6979683_BAD35.java ! test/langtools/tools/javac/6979683/TestCast6979683_BAD35.java.errlog ! test/langtools/tools/javac/6979683/TestCast6979683_BAD36.java ! test/langtools/tools/javac/6979683/TestCast6979683_BAD36.java.errlog ! test/langtools/tools/javac/6979683/TestCast6979683_BAD37.java ! test/langtools/tools/javac/6979683/TestCast6979683_BAD37.java.errlog ! test/langtools/tools/javac/6979683/TestCast6979683_BAD38.java ! test/langtools/tools/javac/6979683/TestCast6979683_BAD38.java.errlog ! test/langtools/tools/javac/6979683/TestCast6979683_BAD39.java ! test/langtools/tools/javac/6979683/TestCast6979683_BAD39.java.errlog ! test/langtools/tools/javac/7023703/T7023703neg.java ! test/langtools/tools/javac/7023703/T7023703neg.out ! test/langtools/tools/javac/7024568/T7024568.java ! test/langtools/tools/javac/7024568/T7024568.out ! test/langtools/tools/javac/AnonStaticMember_1.java ! test/langtools/tools/javac/AnonStaticMember_1.out ! test/langtools/tools/javac/ClassCycle/ClassCycle1a.out ! test/langtools/tools/javac/ClassCycle/ClassCycle1b.java ! test/langtools/tools/javac/ClassCycle/ClassCycle2a.out ! test/langtools/tools/javac/ClassCycle/ClassCycle2b.java ! test/langtools/tools/javac/ClassCycle/ClassCycle3a.out ! test/langtools/tools/javac/ClassCycle/ClassCycle3b.java ! test/langtools/tools/javac/T6326693/FinalVariableAssignedToInCatchBlockTest.java ! test/langtools/tools/javac/T6326693/FinalVariableAssignedToInCatchBlockTest.out ! test/langtools/tools/javac/T6326754.java ! test/langtools/tools/javac/T6326754.out ! test/langtools/tools/javac/T6356530/SerializableAbstractClassTest.java ! test/langtools/tools/javac/T6356530/SerializableAbstractClassTest.out ! test/langtools/tools/javac/T8171332/Buggy.java ! test/langtools/tools/javac/T8171332/Processor.out ! test/langtools/tools/javac/T8171528/DuplicatedAnnotatedPackagesTest.out ! test/langtools/tools/javac/T8171528/pkg1/package-info.java ! test/langtools/tools/javac/T8171528/pkg2/package-info.java ! test/langtools/tools/javac/T8222035/MinContextOpTest.java ! test/langtools/tools/javac/T8222035/MinContextOpTest_A.out ! test/langtools/tools/javac/T8222035/MinContextOpTest_B.out ! test/langtools/tools/javac/T8255968/T8255968_1.java ! test/langtools/tools/javac/T8255968/T8255968_1.out ! test/langtools/tools/javac/T8255968/T8255968_10.java ! test/langtools/tools/javac/T8255968/T8255968_10.out ! test/langtools/tools/javac/T8255968/T8255968_11.java ! test/langtools/tools/javac/T8255968/T8255968_11.out ! test/langtools/tools/javac/T8255968/T8255968_12.java ! test/langtools/tools/javac/T8255968/T8255968_12.out ! test/langtools/tools/javac/T8255968/T8255968_13.java ! test/langtools/tools/javac/T8255968/T8255968_13.out ! test/langtools/tools/javac/T8255968/T8255968_14.java ! test/langtools/tools/javac/T8255968/T8255968_14.out ! test/langtools/tools/javac/T8255968/T8255968_15.java ! test/langtools/tools/javac/T8255968/T8255968_15.out ! test/langtools/tools/javac/T8255968/T8255968_16.java ! test/langtools/tools/javac/T8255968/T8255968_16.out ! test/langtools/tools/javac/T8255968/T8255968_2.java ! test/langtools/tools/javac/T8255968/T8255968_2.out ! test/langtools/tools/javac/T8255968/T8255968_3.java ! test/langtools/tools/javac/T8255968/T8255968_3.out ! test/langtools/tools/javac/T8255968/T8255968_4.java ! test/langtools/tools/javac/T8255968/T8255968_4.out ! test/langtools/tools/javac/T8255968/T8255968_5.java ! test/langtools/tools/javac/T8255968/T8255968_5.out ! test/langtools/tools/javac/T8255968/T8255968_6.java ! test/langtools/tools/javac/T8255968/T8255968_6.out ! test/langtools/tools/javac/T8255968/T8255968_7.java ! test/langtools/tools/javac/T8255968/T8255968_7.out ! test/langtools/tools/javac/TryWithResources/ResourceInterface.java ! test/langtools/tools/javac/TryWithResources/ResourceInterface.out ! test/langtools/tools/javac/analyzer/AnalyzerMandatoryWarnings.java ! test/langtools/tools/javac/analyzer/StuckLambdas.java ! test/langtools/tools/javac/analyzer/StuckLambdas.out ! test/langtools/tools/javac/annotations/clinit/AnnoWithClinitFail.java ! test/langtools/tools/javac/annotations/clinit/AnnoWithClinitFail.out ! test/langtools/tools/javac/annotations/default/Derr.java ! test/langtools/tools/javac/annotations/default/Derr.out ! test/langtools/tools/javac/annotations/default/Eerr.java ! test/langtools/tools/javac/annotations/default/Eerr.out ! test/langtools/tools/javac/annotations/neg/InvalidPackageAnno.out ! test/langtools/tools/javac/annotations/neg/bar/package-info.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeParameter.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeParameter.out ! test/langtools/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeUse.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeUse.out ! test/langtools/tools/javac/annotations/repeatingAnnotations/DuplicateErrors.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/DuplicateErrors.out ! test/langtools/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.out ! test/langtools/tools/javac/annotations/typeAnnotations/6967002/T6967002.java ! test/langtools/tools/javac/annotations/typeAnnotations/6967002/T6967002.out ! test/langtools/tools/javac/annotations/typeAnnotations/DeclVsUseErrorMessage.java ! test/langtools/tools/javac/annotations/typeAnnotations/DeclVsUseErrorMessage.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/TypeVariableMissingTA.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/TypeVariableMissingTA.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/common/receiver/StaticThings.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/common/receiver/StaticThings.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/target/DotClass.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/target/DotClass.out ! test/langtools/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.java ! test/langtools/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.out ! test/langtools/tools/javac/cast/6270087/T6270087neg.java ! test/langtools/tools/javac/cast/6270087/T6270087neg.out ! test/langtools/tools/javac/cast/6932571/T6932571neg.java ! test/langtools/tools/javac/cast/6932571/T6932571neg.out ! test/langtools/tools/javac/danglingDep/DepX.java ! test/langtools/tools/javac/danglingDep/DepX.out ! test/langtools/tools/javac/defaultMethods/static/Static02.java ! test/langtools/tools/javac/defaultMethods/static/Static02.out ! test/langtools/tools/javac/defaultMethods/static/import/StaticImport2.java ! test/langtools/tools/javac/defaultMethods/static/import/StaticImport2.out ! test/langtools/tools/javac/defaultMethods/static/import/StaticImport3.java ! test/langtools/tools/javac/defaultMethods/static/import/StaticImport3.out ! test/langtools/tools/javac/depOverrides/doccomment/B3.java ! test/langtools/tools/javac/depOverrides/doccomment/I.java ! test/langtools/tools/javac/depOverrides/doccomment/P.java ! test/langtools/tools/javac/depOverrides/doccomment/Test1B3.out ! test/langtools/tools/javac/depOverrides/doccomment/Test1I.out ! test/langtools/tools/javac/depOverrides/doccomment/Test2P.out ! test/langtools/tools/javac/diags/EagerInitCheck.out ! test/langtools/tools/javac/diags/IEagerInitCheck.java ! test/langtools/tools/javac/generics/7022054/T7022054pos1.java ! test/langtools/tools/javac/generics/7022054/T7022054pos1.out ! test/langtools/tools/javac/generics/7022054/T7022054pos2.java ! test/langtools/tools/javac/generics/7022054/T7022054pos2.out ! test/langtools/tools/javac/generics/inference/6650759/T6650759m.java ! test/langtools/tools/javac/generics/inference/6650759/T6650759m.out ! test/langtools/tools/javac/generics/typevars/5060485/Compatibility.java ! test/langtools/tools/javac/generics/typevars/5060485/Compatibility.out ! test/langtools/tools/javac/generics/typevars/5060485/Compatibility02.java ! test/langtools/tools/javac/generics/typevars/5060485/Compatibility02.out ! test/langtools/tools/javac/generics/wildcards/6886247/T6886247_2.java ! test/langtools/tools/javac/generics/wildcards/6886247/T6886247_2.out ! test/langtools/tools/javac/generics/wildcards/7034495/T7034495.java ! test/langtools/tools/javac/generics/wildcards/7034495/T7034495.out ! test/langtools/tools/javac/generics/wildcards/AssignmentDifferentTypes.java ! test/langtools/tools/javac/generics/wildcards/AssignmentDifferentTypes.out ! test/langtools/tools/javac/generics/wildcards/AssignmentSameType.java ! test/langtools/tools/javac/generics/wildcards/AssignmentSameType.out ! test/langtools/tools/javac/generics/wildcards/neg/CastFail.java ! test/langtools/tools/javac/generics/wildcards/neg/CastFail.out ! test/langtools/tools/javac/generics/wildcards/neg/CastWarn.java ! test/langtools/tools/javac/generics/wildcards/neg/CastWarn.out ! test/langtools/tools/javac/importChecks/ImportCanonical1.out ! test/langtools/tools/javac/importChecks/ImportCanonical2.java ! test/langtools/tools/javac/importChecks/ImportCanonicalSameName/ImportCanonicalSameName.java ! test/langtools/tools/javac/importChecks/ImportCanonicalSameName/ImportCanonicalSameName.out ! test/langtools/tools/javac/importChecks/ImportsObservable.java ! test/langtools/tools/javac/importChecks/ImportsObservable.out ! test/langtools/tools/javac/importOnDemand/ImportOnDemandConflicts.out ! test/langtools/tools/javac/importOnDemand/p1/Object.java ! test/langtools/tools/javac/importOnDemand/p1/String.java ! test/langtools/tools/javac/importOnDemand/p2/Boolean.java ! test/langtools/tools/javac/importscope/ImportInaccessible.java ! test/langtools/tools/javac/importscope/ImportInaccessible.out ! test/langtools/tools/javac/lambda/ExceptionsInLambda.java ! test/langtools/tools/javac/lambda/ExceptionsInLambda.out ! test/langtools/tools/javac/lambda/Intersection02.java ! test/langtools/tools/javac/lambda/Intersection02.out ! test/langtools/tools/javac/lambda/MethodReference25.java ! test/langtools/tools/javac/lambda/MethodReference25.out ! test/langtools/tools/javac/lambda/MethodReference56.java ! test/langtools/tools/javac/lambda/MethodReference56.out ! test/langtools/tools/javac/lambda/MethodReference58.java ! test/langtools/tools/javac/lambda/MethodReference58.out ! test/langtools/tools/javac/lambda/MethodReference60.java ! test/langtools/tools/javac/lambda/MethodReference60.out ! test/langtools/tools/javac/lambda/MostSpecific04.java ! test/langtools/tools/javac/lambda/MostSpecific04.out ! test/langtools/tools/javac/lambda/MostSpecific05.java ! test/langtools/tools/javac/lambda/MostSpecific05.out ! test/langtools/tools/javac/lambda/MostSpecific08.java ! test/langtools/tools/javac/lambda/MostSpecific08.out ! test/langtools/tools/javac/lambda/TargetType01.java ! test/langtools/tools/javac/lambda/TargetType01.out ! test/langtools/tools/javac/lambda/TargetType36.java ! test/langtools/tools/javac/lambda/TargetType36.out ! test/langtools/tools/javac/lambda/TargetType68.java ! test/langtools/tools/javac/lambda/TargetType68.out ! test/langtools/tools/javac/lambda/UnderscoreAsIdent.java ! test/langtools/tools/javac/lambda/UnderscoreAsIdent8.out ! test/langtools/tools/javac/lambda/UnderscoreAsIdent9.out ! test/langtools/tools/javac/lambda/inaccessibleMref01/InaccessibleMref01.java ! test/langtools/tools/javac/lambda/inaccessibleMref01/InaccessibleMref01.out ! test/langtools/tools/javac/lambda/methodReference/MethodRefStuck.java ! test/langtools/tools/javac/lambda/methodReference/MethodRefStuck.out ! test/langtools/tools/javac/lambda/methodReference/MethodRefStuckParenthesized.java ! test/langtools/tools/javac/lambda/methodReference/MethodRefStuckParenthesized.out ! test/langtools/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarHandle_neg.java ! test/langtools/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarHandle_neg.out ! test/langtools/tools/javac/lambda/speculative/A.java ! test/langtools/tools/javac/lambda/speculative/Main.out ! test/langtools/tools/javac/limits/ArrayDims2.java ! test/langtools/tools/javac/limits/ArrayDims2.out ! test/langtools/tools/javac/limits/ArrayDims4.java ! test/langtools/tools/javac/limits/ArrayDims4.out ! test/langtools/tools/javac/limits/ArrayDims5.java ! test/langtools/tools/javac/limits/ArrayDims5.out ! test/langtools/tools/javac/limits/CodeSize.java ! test/langtools/tools/javac/limits/CodeSize.out ! test/langtools/tools/javac/limits/LongName.java ! test/langtools/tools/javac/limits/LongName.out ! test/langtools/tools/javac/limits/PoolSize1.java ! test/langtools/tools/javac/limits/PoolSize1.out ! test/langtools/tools/javac/limits/PoolSize2.java ! test/langtools/tools/javac/limits/PoolSize2.out ! test/langtools/tools/javac/limits/StringLength.java ! test/langtools/tools/javac/limits/StringLength.out ! test/langtools/tools/javac/overrridecrash/A.java ! test/langtools/tools/javac/overrridecrash/B.out ! test/langtools/tools/javac/parser/SingleCommaAnnotationValueFail.java ! test/langtools/tools/javac/parser/SingleCommaAnnotationValueFail.out ! test/langtools/tools/javac/parser/T4881269.java ! test/langtools/tools/javac/parser/T4881269.out ! test/langtools/tools/javac/patterns/CastConversionMatch.java ! test/langtools/tools/javac/patterns/NullsInPatterns.java ! test/langtools/tools/javac/patterns/NullsInPatterns.out ! test/langtools/tools/javac/patterns/PatternVariablesAreNonFinal.java ! test/langtools/tools/javac/patterns/PatternVariablesAreNonFinal.out ! test/langtools/tools/javac/plugin/showtype/Identifiers.java ! test/langtools/tools/javac/processing/TestMultipleErrors.java ! test/langtools/tools/javac/processing/errors/TestParseErrors/ParseErrors.java ! test/langtools/tools/javac/processing/errors/TestParseErrors/TestParseErrors.out ! test/langtools/tools/javac/processing/model/element/TestMissingElement/InvalidSource.java ! test/langtools/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.ref ! test/langtools/tools/javac/processing/model/trees/BrokenEnumConstructor.java ! test/langtools/tools/javac/processing/model/trees/BrokenEnumConstructor.out ! test/langtools/tools/javac/processing/model/util/directSupersOfErr/C1.java ! test/langtools/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.ref ! test/langtools/tools/javac/recovery/LocalVarHiding.java ! test/langtools/tools/javac/recovery/LocalVarHiding.out ! test/langtools/tools/javac/sourcePath2/SourcePath2.out ! test/langtools/tools/javac/sourcePath2/p/SourcePath2A.java ! test/langtools/tools/javac/staticImport/6695838/T6695838.out ! test/langtools/tools/javac/staticImport/6695838/a/Foo.java ! test/langtools/tools/javac/switchexpr/EmptySwitch.java ! test/langtools/tools/javac/switchexpr/EmptySwitch.out ! test/langtools/tools/javac/switchexpr/WarnWrongYieldTest.java ! test/langtools/tools/javac/switchexpr/WarnWrongYieldTest.out ! test/langtools/tools/javac/switchexpr/WrongBreakTest.java ! test/langtools/tools/javac/switchexpr/WrongBreakTest.out ! test/langtools/tools/javac/switchexpr/WrongYieldTest.java ! test/langtools/tools/javac/switchexpr/WrongYieldTest.out ! test/langtools/tools/javac/switchextra/SwitchArrowBrokenConstant.java ! test/langtools/tools/javac/switchextra/SwitchStatementArrow.java ! test/langtools/tools/javac/varargs/5088429/T5088429Neg01.java ! test/langtools/tools/javac/varargs/5088429/T5088429Neg01.out ! test/langtools/tools/javac/varargs/5088429/T5088429Neg02.java ! test/langtools/tools/javac/varargs/5088429/T5088429Neg02.out ! test/langtools/tools/javac/varargs/VarargsOverride.java ! test/langtools/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.java ! test/langtools/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.out ! test/langtools/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary.java ! test/langtools/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary1.out ! test/langtools/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary2.out ! test/langtools/tools/javac/warnings/MaxDiagsRecompile.all.out ! test/langtools/tools/javac/warnings/MaxDiagsRecompile.java ! test/langtools/tools/javac/warnings/MaxDiagsRecompile.max1.out ! test/langtools/tools/javac/warnings/MaxWarnsRecompile.all.out ! test/langtools/tools/javac/warnings/MaxWarnsRecompile.java ! test/langtools/tools/javac/warnings/MaxWarnsRecompile.max1.out Changeset: f5ee3565 Author: Jamil Nimeh Date: 2020-12-31 18:03:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f5ee3565 8179503: Java should support GET OCSP calls Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/provider/certpath/OCSP.java + test/jdk/java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java ! test/jdk/java/security/testlibrary/SimpleOCSPServer.java Changeset: 9f738f77 Author: duke Date: 2021-01-01 11:00:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f738f77 Automatic merge of jdk:master into master Changeset: 59f5071c Author: duke Date: 2021-01-01 11:00:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/59f5071c Automatic merge of master into foreign-memaccess+abi Changeset: cb88e056 Author: duke Date: 2021-01-01 11:01:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cb88e056 Automatic merge of foreign-memaccess+abi into foreign-jextract From duke at openjdk.java.net Fri Jan 1 11:03:06 2021 From: duke at openjdk.java.net (duke) Date: Fri, 1 Jan 2021 11:03:06 GMT Subject: git: openjdk/panama-foreign: foreign-memaccess+abi: 11 new changesets Message-ID: <026ab93c-d200-4099-a5cd-1e0808bf1dc1@openjdk.org> Changeset: 97c99b5d Author: Guoxiong Li Committer: Jonathan Gibbons Date: 2020-12-26 17:30:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/97c99b5d 8216400: improve handling of IOExceptions in JavaCompiler.close() 8069116: improve fatal error handling in JavaCompiler Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java + test/langtools/tools/javac/fatalErrors/ImproveFatalErrorHandling.java Changeset: 779ee110 Author: Xiaohong Gong Committer: Ningsheng Jian Date: 2020-12-28 02:44:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/779ee110 8257147: [TESTBUG] Set a larger default loop count for the VectorAPI jtreg tests Reviewed-by: psandoz ! test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte128VectorTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Double128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double128VectorTests.java ! test/jdk/jdk/incubator/vector/Double256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double256VectorTests.java ! test/jdk/jdk/incubator/vector/Double512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double512VectorTests.java ! test/jdk/jdk/incubator/vector/Double64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double64VectorTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Float128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float128VectorTests.java ! test/jdk/jdk/incubator/vector/Float256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float256VectorTests.java ! test/jdk/jdk/incubator/vector/Float512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float512VectorTests.java ! test/jdk/jdk/incubator/vector/Float64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float64VectorTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Int128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int128VectorTests.java ! test/jdk/jdk/incubator/vector/Int256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int256VectorTests.java ! test/jdk/jdk/incubator/vector/Int512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int512VectorTests.java ! test/jdk/jdk/incubator/vector/Int64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int64VectorTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Long128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long128VectorTests.java ! test/jdk/jdk/incubator/vector/Long256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long256VectorTests.java ! test/jdk/jdk/incubator/vector/Long512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long512VectorTests.java ! test/jdk/jdk/incubator/vector/Long64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long64VectorTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Short128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short128VectorTests.java ! test/jdk/jdk/incubator/vector/Short256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short256VectorTests.java ! test/jdk/jdk/incubator/vector/Short512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short512VectorTests.java ! test/jdk/jdk/incubator/vector/Short64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short64VectorTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java ! test/jdk/jdk/incubator/vector/VectorReshapeTests.java ! test/jdk/jdk/incubator/vector/templates/Unit-header.template ! test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template Changeset: e2aa724a Author: Jonathan Gibbons Date: 2020-12-24 17:32:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e2aa724a 8258941: Test specify the Classpath exception in the header Reviewed-by: vromero ! test/langtools/lib/combo/tools/javac/combo/CompilationTestCase.java ! test/langtools/tools/javac/lint/JdkInternalAbuseOfVbc.out ! test/langtools/tools/javac/lint/SomeVbc.java ! test/langtools/tools/javac/records/RecordCompilationTests.java ! test/langtools/tools/javac/records/RecordMemberTests.java ! test/langtools/tools/javac/records/VarargsRecordsTest.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java Changeset: 3f67afd3 Author: Prasanta Sadhukhan Date: 2020-12-24 18:50:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3f67afd3 8251377: [macos11] JTabbedPane selected tab text is barely legible Reviewed-by: prr ! src/java.desktop/macosx/classes/apple/laf/JRSUIUtils.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaImageFactory.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m Changeset: fb607f16 Author: Sergey Bylokhov Date: 2020-12-26 05:52:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fb607f16 8245922: [macos] Taskbar.Feature.ICON_BADGE_NUMBER no longer supported on MacOS Reviewed-by: kcr, prr ! src/java.desktop/macosx/classes/apple/laf/JRSUIUtils.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CTaskbarPeer.java Changeset: 881bceb9 Author: Guoxiong Li Committer: Vicente Romero Date: 2020-12-28 15:32:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/881bceb9 8258662: JDK 17ea: Crash compiling instanceof check involving sealed interface Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java + test/langtools/tools/javac/sealed/T8258662/T8258662.java Changeset: 07c93fab Author: Jesper Wilhelmsson Date: 2020-12-29 05:24:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/07c93fab Merge ! src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m Changeset: 8435f0da Author: Guoxiong Li Committer: Jonathan Gibbons Date: 2020-12-30 17:20:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8435f0da 8258525: Some existing tests should use /nodynamiccopyright/ instead of the standard header Reviewed-by: jjg ! test/langtools/tools/javac/4917091/Test256a.java ! test/langtools/tools/javac/4917091/Test256a.out ! test/langtools/tools/javac/4917091/Test256b.java ! test/langtools/tools/javac/4917091/Test256b.out ! test/langtools/tools/javac/6979683/TestCast6979683_BAD34.java ! test/langtools/tools/javac/6979683/TestCast6979683_BAD34.java.errlog ! test/langtools/tools/javac/6979683/TestCast6979683_BAD35.java ! test/langtools/tools/javac/6979683/TestCast6979683_BAD35.java.errlog ! test/langtools/tools/javac/6979683/TestCast6979683_BAD36.java ! test/langtools/tools/javac/6979683/TestCast6979683_BAD36.java.errlog ! test/langtools/tools/javac/6979683/TestCast6979683_BAD37.java ! test/langtools/tools/javac/6979683/TestCast6979683_BAD37.java.errlog ! test/langtools/tools/javac/6979683/TestCast6979683_BAD38.java ! test/langtools/tools/javac/6979683/TestCast6979683_BAD38.java.errlog ! test/langtools/tools/javac/6979683/TestCast6979683_BAD39.java ! test/langtools/tools/javac/6979683/TestCast6979683_BAD39.java.errlog ! test/langtools/tools/javac/7023703/T7023703neg.java ! test/langtools/tools/javac/7023703/T7023703neg.out ! test/langtools/tools/javac/7024568/T7024568.java ! test/langtools/tools/javac/7024568/T7024568.out ! test/langtools/tools/javac/AnonStaticMember_1.java ! test/langtools/tools/javac/AnonStaticMember_1.out ! test/langtools/tools/javac/ClassCycle/ClassCycle1a.out ! test/langtools/tools/javac/ClassCycle/ClassCycle1b.java ! test/langtools/tools/javac/ClassCycle/ClassCycle2a.out ! test/langtools/tools/javac/ClassCycle/ClassCycle2b.java ! test/langtools/tools/javac/ClassCycle/ClassCycle3a.out ! test/langtools/tools/javac/ClassCycle/ClassCycle3b.java ! test/langtools/tools/javac/T6326693/FinalVariableAssignedToInCatchBlockTest.java ! test/langtools/tools/javac/T6326693/FinalVariableAssignedToInCatchBlockTest.out ! test/langtools/tools/javac/T6326754.java ! test/langtools/tools/javac/T6326754.out ! test/langtools/tools/javac/T6356530/SerializableAbstractClassTest.java ! test/langtools/tools/javac/T6356530/SerializableAbstractClassTest.out ! test/langtools/tools/javac/T8171332/Buggy.java ! test/langtools/tools/javac/T8171332/Processor.out ! test/langtools/tools/javac/T8171528/DuplicatedAnnotatedPackagesTest.out ! test/langtools/tools/javac/T8171528/pkg1/package-info.java ! test/langtools/tools/javac/T8171528/pkg2/package-info.java ! test/langtools/tools/javac/T8222035/MinContextOpTest.java ! test/langtools/tools/javac/T8222035/MinContextOpTest_A.out ! test/langtools/tools/javac/T8222035/MinContextOpTest_B.out ! test/langtools/tools/javac/T8255968/T8255968_1.java ! test/langtools/tools/javac/T8255968/T8255968_1.out ! test/langtools/tools/javac/T8255968/T8255968_10.java ! test/langtools/tools/javac/T8255968/T8255968_10.out ! test/langtools/tools/javac/T8255968/T8255968_11.java ! test/langtools/tools/javac/T8255968/T8255968_11.out ! test/langtools/tools/javac/T8255968/T8255968_12.java ! test/langtools/tools/javac/T8255968/T8255968_12.out ! test/langtools/tools/javac/T8255968/T8255968_13.java ! test/langtools/tools/javac/T8255968/T8255968_13.out ! test/langtools/tools/javac/T8255968/T8255968_14.java ! test/langtools/tools/javac/T8255968/T8255968_14.out ! test/langtools/tools/javac/T8255968/T8255968_15.java ! test/langtools/tools/javac/T8255968/T8255968_15.out ! test/langtools/tools/javac/T8255968/T8255968_16.java ! test/langtools/tools/javac/T8255968/T8255968_16.out ! test/langtools/tools/javac/T8255968/T8255968_2.java ! test/langtools/tools/javac/T8255968/T8255968_2.out ! test/langtools/tools/javac/T8255968/T8255968_3.java ! test/langtools/tools/javac/T8255968/T8255968_3.out ! test/langtools/tools/javac/T8255968/T8255968_4.java ! test/langtools/tools/javac/T8255968/T8255968_4.out ! test/langtools/tools/javac/T8255968/T8255968_5.java ! test/langtools/tools/javac/T8255968/T8255968_5.out ! test/langtools/tools/javac/T8255968/T8255968_6.java ! test/langtools/tools/javac/T8255968/T8255968_6.out ! test/langtools/tools/javac/T8255968/T8255968_7.java ! test/langtools/tools/javac/T8255968/T8255968_7.out ! test/langtools/tools/javac/TryWithResources/ResourceInterface.java ! test/langtools/tools/javac/TryWithResources/ResourceInterface.out ! test/langtools/tools/javac/analyzer/AnalyzerMandatoryWarnings.java ! test/langtools/tools/javac/analyzer/StuckLambdas.java ! test/langtools/tools/javac/analyzer/StuckLambdas.out ! test/langtools/tools/javac/annotations/clinit/AnnoWithClinitFail.java ! test/langtools/tools/javac/annotations/clinit/AnnoWithClinitFail.out ! test/langtools/tools/javac/annotations/default/Derr.java ! test/langtools/tools/javac/annotations/default/Derr.out ! test/langtools/tools/javac/annotations/default/Eerr.java ! test/langtools/tools/javac/annotations/default/Eerr.out ! test/langtools/tools/javac/annotations/neg/InvalidPackageAnno.out ! test/langtools/tools/javac/annotations/neg/bar/package-info.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeParameter.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeParameter.out ! test/langtools/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeUse.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeUse.out ! test/langtools/tools/javac/annotations/repeatingAnnotations/DuplicateErrors.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/DuplicateErrors.out ! test/langtools/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.out ! test/langtools/tools/javac/annotations/typeAnnotations/6967002/T6967002.java ! test/langtools/tools/javac/annotations/typeAnnotations/6967002/T6967002.out ! test/langtools/tools/javac/annotations/typeAnnotations/DeclVsUseErrorMessage.java ! test/langtools/tools/javac/annotations/typeAnnotations/DeclVsUseErrorMessage.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/TypeVariableMissingTA.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/TypeVariableMissingTA.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/common/receiver/StaticThings.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/common/receiver/StaticThings.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/target/DotClass.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/target/DotClass.out ! test/langtools/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.java ! test/langtools/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.out ! test/langtools/tools/javac/cast/6270087/T6270087neg.java ! test/langtools/tools/javac/cast/6270087/T6270087neg.out ! test/langtools/tools/javac/cast/6932571/T6932571neg.java ! test/langtools/tools/javac/cast/6932571/T6932571neg.out ! test/langtools/tools/javac/danglingDep/DepX.java ! test/langtools/tools/javac/danglingDep/DepX.out ! test/langtools/tools/javac/defaultMethods/static/Static02.java ! test/langtools/tools/javac/defaultMethods/static/Static02.out ! test/langtools/tools/javac/defaultMethods/static/import/StaticImport2.java ! test/langtools/tools/javac/defaultMethods/static/import/StaticImport2.out ! test/langtools/tools/javac/defaultMethods/static/import/StaticImport3.java ! test/langtools/tools/javac/defaultMethods/static/import/StaticImport3.out ! test/langtools/tools/javac/depOverrides/doccomment/B3.java ! test/langtools/tools/javac/depOverrides/doccomment/I.java ! test/langtools/tools/javac/depOverrides/doccomment/P.java ! test/langtools/tools/javac/depOverrides/doccomment/Test1B3.out ! test/langtools/tools/javac/depOverrides/doccomment/Test1I.out ! test/langtools/tools/javac/depOverrides/doccomment/Test2P.out ! test/langtools/tools/javac/diags/EagerInitCheck.out ! test/langtools/tools/javac/diags/IEagerInitCheck.java ! test/langtools/tools/javac/generics/7022054/T7022054pos1.java ! test/langtools/tools/javac/generics/7022054/T7022054pos1.out ! test/langtools/tools/javac/generics/7022054/T7022054pos2.java ! test/langtools/tools/javac/generics/7022054/T7022054pos2.out ! test/langtools/tools/javac/generics/inference/6650759/T6650759m.java ! test/langtools/tools/javac/generics/inference/6650759/T6650759m.out ! test/langtools/tools/javac/generics/typevars/5060485/Compatibility.java ! test/langtools/tools/javac/generics/typevars/5060485/Compatibility.out ! test/langtools/tools/javac/generics/typevars/5060485/Compatibility02.java ! test/langtools/tools/javac/generics/typevars/5060485/Compatibility02.out ! test/langtools/tools/javac/generics/wildcards/6886247/T6886247_2.java ! test/langtools/tools/javac/generics/wildcards/6886247/T6886247_2.out ! test/langtools/tools/javac/generics/wildcards/7034495/T7034495.java ! test/langtools/tools/javac/generics/wildcards/7034495/T7034495.out ! test/langtools/tools/javac/generics/wildcards/AssignmentDifferentTypes.java ! test/langtools/tools/javac/generics/wildcards/AssignmentDifferentTypes.out ! test/langtools/tools/javac/generics/wildcards/AssignmentSameType.java ! test/langtools/tools/javac/generics/wildcards/AssignmentSameType.out ! test/langtools/tools/javac/generics/wildcards/neg/CastFail.java ! test/langtools/tools/javac/generics/wildcards/neg/CastFail.out ! test/langtools/tools/javac/generics/wildcards/neg/CastWarn.java ! test/langtools/tools/javac/generics/wildcards/neg/CastWarn.out ! test/langtools/tools/javac/importChecks/ImportCanonical1.out ! test/langtools/tools/javac/importChecks/ImportCanonical2.java ! test/langtools/tools/javac/importChecks/ImportCanonicalSameName/ImportCanonicalSameName.java ! test/langtools/tools/javac/importChecks/ImportCanonicalSameName/ImportCanonicalSameName.out ! test/langtools/tools/javac/importChecks/ImportsObservable.java ! test/langtools/tools/javac/importChecks/ImportsObservable.out ! test/langtools/tools/javac/importOnDemand/ImportOnDemandConflicts.out ! test/langtools/tools/javac/importOnDemand/p1/Object.java ! test/langtools/tools/javac/importOnDemand/p1/String.java ! test/langtools/tools/javac/importOnDemand/p2/Boolean.java ! test/langtools/tools/javac/importscope/ImportInaccessible.java ! test/langtools/tools/javac/importscope/ImportInaccessible.out ! test/langtools/tools/javac/lambda/ExceptionsInLambda.java ! test/langtools/tools/javac/lambda/ExceptionsInLambda.out ! test/langtools/tools/javac/lambda/Intersection02.java ! test/langtools/tools/javac/lambda/Intersection02.out ! test/langtools/tools/javac/lambda/MethodReference25.java ! test/langtools/tools/javac/lambda/MethodReference25.out ! test/langtools/tools/javac/lambda/MethodReference56.java ! test/langtools/tools/javac/lambda/MethodReference56.out ! test/langtools/tools/javac/lambda/MethodReference58.java ! test/langtools/tools/javac/lambda/MethodReference58.out ! test/langtools/tools/javac/lambda/MethodReference60.java ! test/langtools/tools/javac/lambda/MethodReference60.out ! test/langtools/tools/javac/lambda/MostSpecific04.java ! test/langtools/tools/javac/lambda/MostSpecific04.out ! test/langtools/tools/javac/lambda/MostSpecific05.java ! test/langtools/tools/javac/lambda/MostSpecific05.out ! test/langtools/tools/javac/lambda/MostSpecific08.java ! test/langtools/tools/javac/lambda/MostSpecific08.out ! test/langtools/tools/javac/lambda/TargetType01.java ! test/langtools/tools/javac/lambda/TargetType01.out ! test/langtools/tools/javac/lambda/TargetType36.java ! test/langtools/tools/javac/lambda/TargetType36.out ! test/langtools/tools/javac/lambda/TargetType68.java ! test/langtools/tools/javac/lambda/TargetType68.out ! test/langtools/tools/javac/lambda/UnderscoreAsIdent.java ! test/langtools/tools/javac/lambda/UnderscoreAsIdent8.out ! test/langtools/tools/javac/lambda/UnderscoreAsIdent9.out ! test/langtools/tools/javac/lambda/inaccessibleMref01/InaccessibleMref01.java ! test/langtools/tools/javac/lambda/inaccessibleMref01/InaccessibleMref01.out ! test/langtools/tools/javac/lambda/methodReference/MethodRefStuck.java ! test/langtools/tools/javac/lambda/methodReference/MethodRefStuck.out ! test/langtools/tools/javac/lambda/methodReference/MethodRefStuckParenthesized.java ! test/langtools/tools/javac/lambda/methodReference/MethodRefStuckParenthesized.out ! test/langtools/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarHandle_neg.java ! test/langtools/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarHandle_neg.out ! test/langtools/tools/javac/lambda/speculative/A.java ! test/langtools/tools/javac/lambda/speculative/Main.out ! test/langtools/tools/javac/limits/ArrayDims2.java ! test/langtools/tools/javac/limits/ArrayDims2.out ! test/langtools/tools/javac/limits/ArrayDims4.java ! test/langtools/tools/javac/limits/ArrayDims4.out ! test/langtools/tools/javac/limits/ArrayDims5.java ! test/langtools/tools/javac/limits/ArrayDims5.out ! test/langtools/tools/javac/limits/CodeSize.java ! test/langtools/tools/javac/limits/CodeSize.out ! test/langtools/tools/javac/limits/LongName.java ! test/langtools/tools/javac/limits/LongName.out ! test/langtools/tools/javac/limits/PoolSize1.java ! test/langtools/tools/javac/limits/PoolSize1.out ! test/langtools/tools/javac/limits/PoolSize2.java ! test/langtools/tools/javac/limits/PoolSize2.out ! test/langtools/tools/javac/limits/StringLength.java ! test/langtools/tools/javac/limits/StringLength.out ! test/langtools/tools/javac/overrridecrash/A.java ! test/langtools/tools/javac/overrridecrash/B.out ! test/langtools/tools/javac/parser/SingleCommaAnnotationValueFail.java ! test/langtools/tools/javac/parser/SingleCommaAnnotationValueFail.out ! test/langtools/tools/javac/parser/T4881269.java ! test/langtools/tools/javac/parser/T4881269.out ! test/langtools/tools/javac/patterns/CastConversionMatch.java ! test/langtools/tools/javac/patterns/NullsInPatterns.java ! test/langtools/tools/javac/patterns/NullsInPatterns.out ! test/langtools/tools/javac/patterns/PatternVariablesAreNonFinal.java ! test/langtools/tools/javac/patterns/PatternVariablesAreNonFinal.out ! test/langtools/tools/javac/plugin/showtype/Identifiers.java ! test/langtools/tools/javac/processing/TestMultipleErrors.java ! test/langtools/tools/javac/processing/errors/TestParseErrors/ParseErrors.java ! test/langtools/tools/javac/processing/errors/TestParseErrors/TestParseErrors.out ! test/langtools/tools/javac/processing/model/element/TestMissingElement/InvalidSource.java ! test/langtools/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.ref ! test/langtools/tools/javac/processing/model/trees/BrokenEnumConstructor.java ! test/langtools/tools/javac/processing/model/trees/BrokenEnumConstructor.out ! test/langtools/tools/javac/processing/model/util/directSupersOfErr/C1.java ! test/langtools/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.ref ! test/langtools/tools/javac/recovery/LocalVarHiding.java ! test/langtools/tools/javac/recovery/LocalVarHiding.out ! test/langtools/tools/javac/sourcePath2/SourcePath2.out ! test/langtools/tools/javac/sourcePath2/p/SourcePath2A.java ! test/langtools/tools/javac/staticImport/6695838/T6695838.out ! test/langtools/tools/javac/staticImport/6695838/a/Foo.java ! test/langtools/tools/javac/switchexpr/EmptySwitch.java ! test/langtools/tools/javac/switchexpr/EmptySwitch.out ! test/langtools/tools/javac/switchexpr/WarnWrongYieldTest.java ! test/langtools/tools/javac/switchexpr/WarnWrongYieldTest.out ! test/langtools/tools/javac/switchexpr/WrongBreakTest.java ! test/langtools/tools/javac/switchexpr/WrongBreakTest.out ! test/langtools/tools/javac/switchexpr/WrongYieldTest.java ! test/langtools/tools/javac/switchexpr/WrongYieldTest.out ! test/langtools/tools/javac/switchextra/SwitchArrowBrokenConstant.java ! test/langtools/tools/javac/switchextra/SwitchStatementArrow.java ! test/langtools/tools/javac/varargs/5088429/T5088429Neg01.java ! test/langtools/tools/javac/varargs/5088429/T5088429Neg01.out ! test/langtools/tools/javac/varargs/5088429/T5088429Neg02.java ! test/langtools/tools/javac/varargs/5088429/T5088429Neg02.out ! test/langtools/tools/javac/varargs/VarargsOverride.java ! test/langtools/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.java ! test/langtools/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.out ! test/langtools/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary.java ! test/langtools/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary1.out ! test/langtools/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary2.out ! test/langtools/tools/javac/warnings/MaxDiagsRecompile.all.out ! test/langtools/tools/javac/warnings/MaxDiagsRecompile.java ! test/langtools/tools/javac/warnings/MaxDiagsRecompile.max1.out ! test/langtools/tools/javac/warnings/MaxWarnsRecompile.all.out ! test/langtools/tools/javac/warnings/MaxWarnsRecompile.java ! test/langtools/tools/javac/warnings/MaxWarnsRecompile.max1.out Changeset: f5ee3565 Author: Jamil Nimeh Date: 2020-12-31 18:03:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f5ee3565 8179503: Java should support GET OCSP calls Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/provider/certpath/OCSP.java + test/jdk/java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java ! test/jdk/java/security/testlibrary/SimpleOCSPServer.java Changeset: 9f738f77 Author: duke Date: 2021-01-01 11:00:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f738f77 Automatic merge of jdk:master into master Changeset: 59f5071c Author: duke Date: 2021-01-01 11:00:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/59f5071c Automatic merge of master into foreign-memaccess+abi From duke at openjdk.java.net Fri Jan 1 11:03:47 2021 From: duke at openjdk.java.net (duke) Date: Fri, 1 Jan 2021 11:03:47 GMT Subject: git: openjdk/panama-foreign: master: 10 new changesets Message-ID: Changeset: 97c99b5d Author: Guoxiong Li Committer: Jonathan Gibbons Date: 2020-12-26 17:30:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/97c99b5d 8216400: improve handling of IOExceptions in JavaCompiler.close() 8069116: improve fatal error handling in JavaCompiler Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java + test/langtools/tools/javac/fatalErrors/ImproveFatalErrorHandling.java Changeset: 779ee110 Author: Xiaohong Gong Committer: Ningsheng Jian Date: 2020-12-28 02:44:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/779ee110 8257147: [TESTBUG] Set a larger default loop count for the VectorAPI jtreg tests Reviewed-by: psandoz ! test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte128VectorTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Double128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double128VectorTests.java ! test/jdk/jdk/incubator/vector/Double256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double256VectorTests.java ! test/jdk/jdk/incubator/vector/Double512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double512VectorTests.java ! test/jdk/jdk/incubator/vector/Double64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double64VectorTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Float128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float128VectorTests.java ! test/jdk/jdk/incubator/vector/Float256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float256VectorTests.java ! test/jdk/jdk/incubator/vector/Float512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float512VectorTests.java ! test/jdk/jdk/incubator/vector/Float64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float64VectorTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Int128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int128VectorTests.java ! test/jdk/jdk/incubator/vector/Int256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int256VectorTests.java ! test/jdk/jdk/incubator/vector/Int512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int512VectorTests.java ! test/jdk/jdk/incubator/vector/Int64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int64VectorTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Long128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long128VectorTests.java ! test/jdk/jdk/incubator/vector/Long256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long256VectorTests.java ! test/jdk/jdk/incubator/vector/Long512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long512VectorTests.java ! test/jdk/jdk/incubator/vector/Long64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long64VectorTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Short128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short128VectorTests.java ! test/jdk/jdk/incubator/vector/Short256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short256VectorTests.java ! test/jdk/jdk/incubator/vector/Short512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short512VectorTests.java ! test/jdk/jdk/incubator/vector/Short64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short64VectorTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java ! test/jdk/jdk/incubator/vector/VectorReshapeTests.java ! test/jdk/jdk/incubator/vector/templates/Unit-header.template ! test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template Changeset: e2aa724a Author: Jonathan Gibbons Date: 2020-12-24 17:32:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e2aa724a 8258941: Test specify the Classpath exception in the header Reviewed-by: vromero ! test/langtools/lib/combo/tools/javac/combo/CompilationTestCase.java ! test/langtools/tools/javac/lint/JdkInternalAbuseOfVbc.out ! test/langtools/tools/javac/lint/SomeVbc.java ! test/langtools/tools/javac/records/RecordCompilationTests.java ! test/langtools/tools/javac/records/RecordMemberTests.java ! test/langtools/tools/javac/records/VarargsRecordsTest.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java Changeset: 3f67afd3 Author: Prasanta Sadhukhan Date: 2020-12-24 18:50:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3f67afd3 8251377: [macos11] JTabbedPane selected tab text is barely legible Reviewed-by: prr ! src/java.desktop/macosx/classes/apple/laf/JRSUIUtils.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaImageFactory.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m Changeset: fb607f16 Author: Sergey Bylokhov Date: 2020-12-26 05:52:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fb607f16 8245922: [macos] Taskbar.Feature.ICON_BADGE_NUMBER no longer supported on MacOS Reviewed-by: kcr, prr ! src/java.desktop/macosx/classes/apple/laf/JRSUIUtils.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CTaskbarPeer.java Changeset: 881bceb9 Author: Guoxiong Li Committer: Vicente Romero Date: 2020-12-28 15:32:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/881bceb9 8258662: JDK 17ea: Crash compiling instanceof check involving sealed interface Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java + test/langtools/tools/javac/sealed/T8258662/T8258662.java Changeset: 07c93fab Author: Jesper Wilhelmsson Date: 2020-12-29 05:24:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/07c93fab Merge ! src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m Changeset: 8435f0da Author: Guoxiong Li Committer: Jonathan Gibbons Date: 2020-12-30 17:20:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8435f0da 8258525: Some existing tests should use /nodynamiccopyright/ instead of the standard header Reviewed-by: jjg ! test/langtools/tools/javac/4917091/Test256a.java ! test/langtools/tools/javac/4917091/Test256a.out ! test/langtools/tools/javac/4917091/Test256b.java ! test/langtools/tools/javac/4917091/Test256b.out ! test/langtools/tools/javac/6979683/TestCast6979683_BAD34.java ! test/langtools/tools/javac/6979683/TestCast6979683_BAD34.java.errlog ! test/langtools/tools/javac/6979683/TestCast6979683_BAD35.java ! test/langtools/tools/javac/6979683/TestCast6979683_BAD35.java.errlog ! test/langtools/tools/javac/6979683/TestCast6979683_BAD36.java ! test/langtools/tools/javac/6979683/TestCast6979683_BAD36.java.errlog ! test/langtools/tools/javac/6979683/TestCast6979683_BAD37.java ! test/langtools/tools/javac/6979683/TestCast6979683_BAD37.java.errlog ! test/langtools/tools/javac/6979683/TestCast6979683_BAD38.java ! test/langtools/tools/javac/6979683/TestCast6979683_BAD38.java.errlog ! test/langtools/tools/javac/6979683/TestCast6979683_BAD39.java ! test/langtools/tools/javac/6979683/TestCast6979683_BAD39.java.errlog ! test/langtools/tools/javac/7023703/T7023703neg.java ! test/langtools/tools/javac/7023703/T7023703neg.out ! test/langtools/tools/javac/7024568/T7024568.java ! test/langtools/tools/javac/7024568/T7024568.out ! test/langtools/tools/javac/AnonStaticMember_1.java ! test/langtools/tools/javac/AnonStaticMember_1.out ! test/langtools/tools/javac/ClassCycle/ClassCycle1a.out ! test/langtools/tools/javac/ClassCycle/ClassCycle1b.java ! test/langtools/tools/javac/ClassCycle/ClassCycle2a.out ! test/langtools/tools/javac/ClassCycle/ClassCycle2b.java ! test/langtools/tools/javac/ClassCycle/ClassCycle3a.out ! test/langtools/tools/javac/ClassCycle/ClassCycle3b.java ! test/langtools/tools/javac/T6326693/FinalVariableAssignedToInCatchBlockTest.java ! test/langtools/tools/javac/T6326693/FinalVariableAssignedToInCatchBlockTest.out ! test/langtools/tools/javac/T6326754.java ! test/langtools/tools/javac/T6326754.out ! test/langtools/tools/javac/T6356530/SerializableAbstractClassTest.java ! test/langtools/tools/javac/T6356530/SerializableAbstractClassTest.out ! test/langtools/tools/javac/T8171332/Buggy.java ! test/langtools/tools/javac/T8171332/Processor.out ! test/langtools/tools/javac/T8171528/DuplicatedAnnotatedPackagesTest.out ! test/langtools/tools/javac/T8171528/pkg1/package-info.java ! test/langtools/tools/javac/T8171528/pkg2/package-info.java ! test/langtools/tools/javac/T8222035/MinContextOpTest.java ! test/langtools/tools/javac/T8222035/MinContextOpTest_A.out ! test/langtools/tools/javac/T8222035/MinContextOpTest_B.out ! test/langtools/tools/javac/T8255968/T8255968_1.java ! test/langtools/tools/javac/T8255968/T8255968_1.out ! test/langtools/tools/javac/T8255968/T8255968_10.java ! test/langtools/tools/javac/T8255968/T8255968_10.out ! test/langtools/tools/javac/T8255968/T8255968_11.java ! test/langtools/tools/javac/T8255968/T8255968_11.out ! test/langtools/tools/javac/T8255968/T8255968_12.java ! test/langtools/tools/javac/T8255968/T8255968_12.out ! test/langtools/tools/javac/T8255968/T8255968_13.java ! test/langtools/tools/javac/T8255968/T8255968_13.out ! test/langtools/tools/javac/T8255968/T8255968_14.java ! test/langtools/tools/javac/T8255968/T8255968_14.out ! test/langtools/tools/javac/T8255968/T8255968_15.java ! test/langtools/tools/javac/T8255968/T8255968_15.out ! test/langtools/tools/javac/T8255968/T8255968_16.java ! test/langtools/tools/javac/T8255968/T8255968_16.out ! test/langtools/tools/javac/T8255968/T8255968_2.java ! test/langtools/tools/javac/T8255968/T8255968_2.out ! test/langtools/tools/javac/T8255968/T8255968_3.java ! test/langtools/tools/javac/T8255968/T8255968_3.out ! test/langtools/tools/javac/T8255968/T8255968_4.java ! test/langtools/tools/javac/T8255968/T8255968_4.out ! test/langtools/tools/javac/T8255968/T8255968_5.java ! test/langtools/tools/javac/T8255968/T8255968_5.out ! test/langtools/tools/javac/T8255968/T8255968_6.java ! test/langtools/tools/javac/T8255968/T8255968_6.out ! test/langtools/tools/javac/T8255968/T8255968_7.java ! test/langtools/tools/javac/T8255968/T8255968_7.out ! test/langtools/tools/javac/TryWithResources/ResourceInterface.java ! test/langtools/tools/javac/TryWithResources/ResourceInterface.out ! test/langtools/tools/javac/analyzer/AnalyzerMandatoryWarnings.java ! test/langtools/tools/javac/analyzer/StuckLambdas.java ! test/langtools/tools/javac/analyzer/StuckLambdas.out ! test/langtools/tools/javac/annotations/clinit/AnnoWithClinitFail.java ! test/langtools/tools/javac/annotations/clinit/AnnoWithClinitFail.out ! test/langtools/tools/javac/annotations/default/Derr.java ! test/langtools/tools/javac/annotations/default/Derr.out ! test/langtools/tools/javac/annotations/default/Eerr.java ! test/langtools/tools/javac/annotations/default/Eerr.out ! test/langtools/tools/javac/annotations/neg/InvalidPackageAnno.out ! test/langtools/tools/javac/annotations/neg/bar/package-info.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeParameter.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeParameter.out ! test/langtools/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeUse.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/DefaultTargetTypeUse.out ! test/langtools/tools/javac/annotations/repeatingAnnotations/DuplicateErrors.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/DuplicateErrors.out ! test/langtools/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.java ! test/langtools/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.out ! test/langtools/tools/javac/annotations/typeAnnotations/6967002/T6967002.java ! test/langtools/tools/javac/annotations/typeAnnotations/6967002/T6967002.out ! test/langtools/tools/javac/annotations/typeAnnotations/DeclVsUseErrorMessage.java ! test/langtools/tools/javac/annotations/typeAnnotations/DeclVsUseErrorMessage.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/TypeVariableMissingTA.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/TypeVariableMissingTA.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/common/receiver/StaticThings.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/common/receiver/StaticThings.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/target/DotClass.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/target/DotClass.out ! test/langtools/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.java ! test/langtools/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.out ! test/langtools/tools/javac/cast/6270087/T6270087neg.java ! test/langtools/tools/javac/cast/6270087/T6270087neg.out ! test/langtools/tools/javac/cast/6932571/T6932571neg.java ! test/langtools/tools/javac/cast/6932571/T6932571neg.out ! test/langtools/tools/javac/danglingDep/DepX.java ! test/langtools/tools/javac/danglingDep/DepX.out ! test/langtools/tools/javac/defaultMethods/static/Static02.java ! test/langtools/tools/javac/defaultMethods/static/Static02.out ! test/langtools/tools/javac/defaultMethods/static/import/StaticImport2.java ! test/langtools/tools/javac/defaultMethods/static/import/StaticImport2.out ! test/langtools/tools/javac/defaultMethods/static/import/StaticImport3.java ! test/langtools/tools/javac/defaultMethods/static/import/StaticImport3.out ! test/langtools/tools/javac/depOverrides/doccomment/B3.java ! test/langtools/tools/javac/depOverrides/doccomment/I.java ! test/langtools/tools/javac/depOverrides/doccomment/P.java ! test/langtools/tools/javac/depOverrides/doccomment/Test1B3.out ! test/langtools/tools/javac/depOverrides/doccomment/Test1I.out ! test/langtools/tools/javac/depOverrides/doccomment/Test2P.out ! test/langtools/tools/javac/diags/EagerInitCheck.out ! test/langtools/tools/javac/diags/IEagerInitCheck.java ! test/langtools/tools/javac/generics/7022054/T7022054pos1.java ! test/langtools/tools/javac/generics/7022054/T7022054pos1.out ! test/langtools/tools/javac/generics/7022054/T7022054pos2.java ! test/langtools/tools/javac/generics/7022054/T7022054pos2.out ! test/langtools/tools/javac/generics/inference/6650759/T6650759m.java ! test/langtools/tools/javac/generics/inference/6650759/T6650759m.out ! test/langtools/tools/javac/generics/typevars/5060485/Compatibility.java ! test/langtools/tools/javac/generics/typevars/5060485/Compatibility.out ! test/langtools/tools/javac/generics/typevars/5060485/Compatibility02.java ! test/langtools/tools/javac/generics/typevars/5060485/Compatibility02.out ! test/langtools/tools/javac/generics/wildcards/6886247/T6886247_2.java ! test/langtools/tools/javac/generics/wildcards/6886247/T6886247_2.out ! test/langtools/tools/javac/generics/wildcards/7034495/T7034495.java ! test/langtools/tools/javac/generics/wildcards/7034495/T7034495.out ! test/langtools/tools/javac/generics/wildcards/AssignmentDifferentTypes.java ! test/langtools/tools/javac/generics/wildcards/AssignmentDifferentTypes.out ! test/langtools/tools/javac/generics/wildcards/AssignmentSameType.java ! test/langtools/tools/javac/generics/wildcards/AssignmentSameType.out ! test/langtools/tools/javac/generics/wildcards/neg/CastFail.java ! test/langtools/tools/javac/generics/wildcards/neg/CastFail.out ! test/langtools/tools/javac/generics/wildcards/neg/CastWarn.java ! test/langtools/tools/javac/generics/wildcards/neg/CastWarn.out ! test/langtools/tools/javac/importChecks/ImportCanonical1.out ! test/langtools/tools/javac/importChecks/ImportCanonical2.java ! test/langtools/tools/javac/importChecks/ImportCanonicalSameName/ImportCanonicalSameName.java ! test/langtools/tools/javac/importChecks/ImportCanonicalSameName/ImportCanonicalSameName.out ! test/langtools/tools/javac/importChecks/ImportsObservable.java ! test/langtools/tools/javac/importChecks/ImportsObservable.out ! test/langtools/tools/javac/importOnDemand/ImportOnDemandConflicts.out ! test/langtools/tools/javac/importOnDemand/p1/Object.java ! test/langtools/tools/javac/importOnDemand/p1/String.java ! test/langtools/tools/javac/importOnDemand/p2/Boolean.java ! test/langtools/tools/javac/importscope/ImportInaccessible.java ! test/langtools/tools/javac/importscope/ImportInaccessible.out ! test/langtools/tools/javac/lambda/ExceptionsInLambda.java ! test/langtools/tools/javac/lambda/ExceptionsInLambda.out ! test/langtools/tools/javac/lambda/Intersection02.java ! test/langtools/tools/javac/lambda/Intersection02.out ! test/langtools/tools/javac/lambda/MethodReference25.java ! test/langtools/tools/javac/lambda/MethodReference25.out ! test/langtools/tools/javac/lambda/MethodReference56.java ! test/langtools/tools/javac/lambda/MethodReference56.out ! test/langtools/tools/javac/lambda/MethodReference58.java ! test/langtools/tools/javac/lambda/MethodReference58.out ! test/langtools/tools/javac/lambda/MethodReference60.java ! test/langtools/tools/javac/lambda/MethodReference60.out ! test/langtools/tools/javac/lambda/MostSpecific04.java ! test/langtools/tools/javac/lambda/MostSpecific04.out ! test/langtools/tools/javac/lambda/MostSpecific05.java ! test/langtools/tools/javac/lambda/MostSpecific05.out ! test/langtools/tools/javac/lambda/MostSpecific08.java ! test/langtools/tools/javac/lambda/MostSpecific08.out ! test/langtools/tools/javac/lambda/TargetType01.java ! test/langtools/tools/javac/lambda/TargetType01.out ! test/langtools/tools/javac/lambda/TargetType36.java ! test/langtools/tools/javac/lambda/TargetType36.out ! test/langtools/tools/javac/lambda/TargetType68.java ! test/langtools/tools/javac/lambda/TargetType68.out ! test/langtools/tools/javac/lambda/UnderscoreAsIdent.java ! test/langtools/tools/javac/lambda/UnderscoreAsIdent8.out ! test/langtools/tools/javac/lambda/UnderscoreAsIdent9.out ! test/langtools/tools/javac/lambda/inaccessibleMref01/InaccessibleMref01.java ! test/langtools/tools/javac/lambda/inaccessibleMref01/InaccessibleMref01.out ! test/langtools/tools/javac/lambda/methodReference/MethodRefStuck.java ! test/langtools/tools/javac/lambda/methodReference/MethodRefStuck.out ! test/langtools/tools/javac/lambda/methodReference/MethodRefStuckParenthesized.java ! test/langtools/tools/javac/lambda/methodReference/MethodRefStuckParenthesized.out ! test/langtools/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarHandle_neg.java ! test/langtools/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarHandle_neg.out ! test/langtools/tools/javac/lambda/speculative/A.java ! test/langtools/tools/javac/lambda/speculative/Main.out ! test/langtools/tools/javac/limits/ArrayDims2.java ! test/langtools/tools/javac/limits/ArrayDims2.out ! test/langtools/tools/javac/limits/ArrayDims4.java ! test/langtools/tools/javac/limits/ArrayDims4.out ! test/langtools/tools/javac/limits/ArrayDims5.java ! test/langtools/tools/javac/limits/ArrayDims5.out ! test/langtools/tools/javac/limits/CodeSize.java ! test/langtools/tools/javac/limits/CodeSize.out ! test/langtools/tools/javac/limits/LongName.java ! test/langtools/tools/javac/limits/LongName.out ! test/langtools/tools/javac/limits/PoolSize1.java ! test/langtools/tools/javac/limits/PoolSize1.out ! test/langtools/tools/javac/limits/PoolSize2.java ! test/langtools/tools/javac/limits/PoolSize2.out ! test/langtools/tools/javac/limits/StringLength.java ! test/langtools/tools/javac/limits/StringLength.out ! test/langtools/tools/javac/overrridecrash/A.java ! test/langtools/tools/javac/overrridecrash/B.out ! test/langtools/tools/javac/parser/SingleCommaAnnotationValueFail.java ! test/langtools/tools/javac/parser/SingleCommaAnnotationValueFail.out ! test/langtools/tools/javac/parser/T4881269.java ! test/langtools/tools/javac/parser/T4881269.out ! test/langtools/tools/javac/patterns/CastConversionMatch.java ! test/langtools/tools/javac/patterns/NullsInPatterns.java ! test/langtools/tools/javac/patterns/NullsInPatterns.out ! test/langtools/tools/javac/patterns/PatternVariablesAreNonFinal.java ! test/langtools/tools/javac/patterns/PatternVariablesAreNonFinal.out ! test/langtools/tools/javac/plugin/showtype/Identifiers.java ! test/langtools/tools/javac/processing/TestMultipleErrors.java ! test/langtools/tools/javac/processing/errors/TestParseErrors/ParseErrors.java ! test/langtools/tools/javac/processing/errors/TestParseErrors/TestParseErrors.out ! test/langtools/tools/javac/processing/model/element/TestMissingElement/InvalidSource.java ! test/langtools/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.ref ! test/langtools/tools/javac/processing/model/trees/BrokenEnumConstructor.java ! test/langtools/tools/javac/processing/model/trees/BrokenEnumConstructor.out ! test/langtools/tools/javac/processing/model/util/directSupersOfErr/C1.java ! test/langtools/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.ref ! test/langtools/tools/javac/recovery/LocalVarHiding.java ! test/langtools/tools/javac/recovery/LocalVarHiding.out ! test/langtools/tools/javac/sourcePath2/SourcePath2.out ! test/langtools/tools/javac/sourcePath2/p/SourcePath2A.java ! test/langtools/tools/javac/staticImport/6695838/T6695838.out ! test/langtools/tools/javac/staticImport/6695838/a/Foo.java ! test/langtools/tools/javac/switchexpr/EmptySwitch.java ! test/langtools/tools/javac/switchexpr/EmptySwitch.out ! test/langtools/tools/javac/switchexpr/WarnWrongYieldTest.java ! test/langtools/tools/javac/switchexpr/WarnWrongYieldTest.out ! test/langtools/tools/javac/switchexpr/WrongBreakTest.java ! test/langtools/tools/javac/switchexpr/WrongBreakTest.out ! test/langtools/tools/javac/switchexpr/WrongYieldTest.java ! test/langtools/tools/javac/switchexpr/WrongYieldTest.out ! test/langtools/tools/javac/switchextra/SwitchArrowBrokenConstant.java ! test/langtools/tools/javac/switchextra/SwitchStatementArrow.java ! test/langtools/tools/javac/varargs/5088429/T5088429Neg01.java ! test/langtools/tools/javac/varargs/5088429/T5088429Neg01.out ! test/langtools/tools/javac/varargs/5088429/T5088429Neg02.java ! test/langtools/tools/javac/varargs/5088429/T5088429Neg02.out ! test/langtools/tools/javac/varargs/VarargsOverride.java ! test/langtools/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.java ! test/langtools/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.out ! test/langtools/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary.java ! test/langtools/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary1.out ! test/langtools/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary2.out ! test/langtools/tools/javac/warnings/MaxDiagsRecompile.all.out ! test/langtools/tools/javac/warnings/MaxDiagsRecompile.java ! test/langtools/tools/javac/warnings/MaxDiagsRecompile.max1.out ! test/langtools/tools/javac/warnings/MaxWarnsRecompile.all.out ! test/langtools/tools/javac/warnings/MaxWarnsRecompile.java ! test/langtools/tools/javac/warnings/MaxWarnsRecompile.max1.out Changeset: f5ee3565 Author: Jamil Nimeh Date: 2020-12-31 18:03:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f5ee3565 8179503: Java should support GET OCSP calls Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/provider/certpath/OCSP.java + test/jdk/java/security/cert/CertPathValidator/OCSP/GetAndPostTests.java ! test/jdk/java/security/testlibrary/SimpleOCSPServer.java Changeset: 9f738f77 Author: duke Date: 2021-01-01 11:00:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f738f77 Automatic merge of jdk:master into master From fw at deneb.enyo.de Fri Jan 1 13:04:36 2021 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 01 Jan 2021 14:04:36 +0100 Subject: Support for 64-bit pointers In-Reply-To: <043D75D3-7490-4B3D-89B6-B8CFD28283CE@smogura.eu> (=?utf-8?Q?=22Rados=C5=82aw?= Smogura"'s message of "Fri, 1 Jan 2021 08:37:02 +0000") References: <043D75D3-7490-4B3D-89B6-B8CFD28283CE@smogura.eu> Message-ID: <87eej4erkr.fsf@mid.deneb.enyo.de> * Rados?aw Smogura: > In current version of implementation (many places), there?s a lot of > range checks. However longs in Java are signed, and C pointers are > unsigned so, at least for x86-64 architectures this should be taken > on account, otherwise we would not be able to address whole memory > in straightforward way (largest block size is 2^31, can directly > address upper half of memory). The x86-64 architecture actually has signed addresses in the sense that some number of upper bits of pointers must match the sign bit. On Linux, userspace addresses always have a zero sign bit. I think this is not true on Solaris. I don't know about Windows. On some architectures, C struggles with similar issues because ptrdiff_t is signed and does not cover the entire address space. It's therefore undefined to create objects whose size is greater than what can be expressed as a ptrdiff_t value, despite the underlying architecture supporting this. From mail at smogura.eu Fri Jan 1 17:46:55 2021 From: mail at smogura.eu (=?utf-8?B?UmFkb3PFgmF3IFNtb2d1cmE=?=) Date: Fri, 1 Jan 2021 17:46:55 +0000 Subject: Support for 64-bit pointers In-Reply-To: <87eej4erkr.fsf@mid.deneb.enyo.de> References: <043D75D3-7490-4B3D-89B6-B8CFD28283CE@smogura.eu>, <87eej4erkr.fsf@mid.deneb.enyo.de> Message-ID: Hi Florian, That?s correct, even more there?s only 48 bits addressable. I?m not sure what I was thinking - I was doing some performance checks and was concerned that unrestricted access looked like doing range checks and... well found this unrelated topic. However just to mention, some Linux distribution uses vsyscalls (which is going to be deprecated) and this is mapped to the tail of memory ([1] nice asm code) So even it?s not addressable it?s usable. I?m not sure if it?s worth handling. Kind regards, Rado [1] https://stackoverflow.com/questions/7266813/how-does-the-gettimeofday-syscall-work On Jan 1, 2021, at 2:04 PM, Florian Weimer wrote: ?* Rados?aw Smogura: In current version of implementation (many places), there?s a lot of range checks. However longs in Java are signed, and C pointers are unsigned so, at least for x86-64 architectures this should be taken on account, otherwise we would not be able to address whole memory in straightforward way (largest block size is 2^31, can directly address upper half of memory). The x86-64 architecture actually has signed addresses in the sense that some number of upper bits of pointers must match the sign bit. On Linux, userspace addresses always have a zero sign bit. I think this is not true on Solaris. I don't know about Windows. On some architectures, C struggles with similar issues because ptrdiff_t is signed and does not cover the entire address space. It's therefore undefined to create objects whose size is greater than what can be expressed as a ptrdiff_t value, despite the underlying architecture supporting this. From leerho at gmail.com Fri Jan 1 18:42:10 2021 From: leerho at gmail.com (leerho) Date: Fri, 1 Jan 2021 10:42:10 -0800 Subject: Support for 64-bit pointers In-Reply-To: References: <043D75D3-7490-4B3D-89B6-B8CFD28283CE@smogura.eu> <87eej4erkr.fsf@mid.deneb.enyo.de> Message-ID: Hi Rados?aw & Florian, On a related topic, I have wished for years that Java would finally support unsigned integral types (byte, short, int, and long). I'm sure that I'm not the first to mention this, so forgive me if this has been hashed out before. But I do not understand why there would be resistance to this. For example, packing and unpacking "C-struct" -like data structures is a PITA in Java, Bytes and shorts have to be masked when upcasting to ints and ints have to be masked when upcasting to longs all because of the automatic sign-extension. Not having unsigned types creates a ripe area for bugs that can be hard to find. Is there any hope of Java finally getting full support of unsigned types? Cheers, and Happy New Year, Lee. On Fri, Jan 1, 2021 at 9:49 AM Rados?aw Smogura wrote: > Hi Florian, > > That?s correct, even more there?s only 48 bits addressable. > > I?m not sure what I was thinking - I was doing some performance checks and > was concerned that unrestricted access looked like doing range checks > and... well found this unrelated topic. > > However just to mention, some Linux distribution uses vsyscalls (which is > going to be deprecated) and this is mapped to the tail of memory ([1] nice > asm code) > > So even it?s not addressable it?s usable. I?m not sure if it?s worth > handling. > > Kind regards, > Rado > > [1] > https://stackoverflow.com/questions/7266813/how-does-the-gettimeofday-syscall-work > > On Jan 1, 2021, at 2:04 PM, Florian Weimer wrote: > > ?* Rados?aw Smogura: > > In current version of implementation (many places), there?s a lot of > range checks. However longs in Java are signed, and C pointers are > unsigned so, at least for x86-64 architectures this should be taken > on account, otherwise we would not be able to address whole memory > in straightforward way (largest block size is 2^31, can directly > address upper half of memory). > > The x86-64 architecture actually has signed addresses in the sense > that some number of upper bits of pointers must match the sign bit. > On Linux, userspace addresses always have a zero sign bit. I think > this is not true on Solaris. I don't know about Windows. > > On some architectures, C struggles with similar issues because > ptrdiff_t is signed and does not cover the entire address space. It's > therefore undefined to create objects whose size is greater than what > can be expressed as a ptrdiff_t value, despite the underlying > architecture supporting this. > From youngty1997 at gmail.com Fri Jan 1 18:56:18 2021 From: youngty1997 at gmail.com (Ty Young) Date: Fri, 1 Jan 2021 12:56:18 -0600 Subject: Support for 64-bit pointers In-Reply-To: References: <043D75D3-7490-4B3D-89B6-B8CFD28283CE@smogura.eu> <87eej4erkr.fsf@mid.deneb.enyo.de> Message-ID: <833daef4-862c-170b-18cd-2b34a20443f8@gmail.com> Agreed, Java really needs unsigned types. Besides this specific issue, there is also a major issue representing unsigned types in a high-level API such as the previous Pointer API or my current API. In order to represent a 1-byte unsigned number(byte) you would have to use a 2-byte signed number(short), which distorts APIs and creates confusion as an API user. If a function header says that you need an unsigned long then Java should be able to pass an actual unsigned long type to it. On 1/1/21 12:42 PM, leerho wrote: > Hi Rados?aw & Florian, > > On a related topic, I have wished for years that Java would finally support > unsigned integral types (byte, short, int, and long). I'm sure that I'm > not the first to mention this, so forgive me if this has been hashed out > before. But I do not understand why there would be resistance to this. > For example, packing and unpacking "C-struct" -like data structures is a > PITA in Java, Bytes and shorts have to be masked when upcasting to ints > and ints have to be masked when upcasting to longs all because of the > automatic sign-extension. Not having unsigned types creates a ripe area > for bugs that can be hard to find. > > Is there any hope of Java finally getting full support of unsigned types? > > Cheers, and Happy New Year, > > Lee. > > > > On Fri, Jan 1, 2021 at 9:49 AM Rados?aw Smogura wrote: > >> Hi Florian, >> >> That?s correct, even more there?s only 48 bits addressable. >> >> I?m not sure what I was thinking - I was doing some performance checks and >> was concerned that unrestricted access looked like doing range checks >> and... well found this unrelated topic. >> >> However just to mention, some Linux distribution uses vsyscalls (which is >> going to be deprecated) and this is mapped to the tail of memory ([1] nice >> asm code) >> >> So even it?s not addressable it?s usable. I?m not sure if it?s worth >> handling. >> >> Kind regards, >> Rado >> >> [1] >> https://stackoverflow.com/questions/7266813/how-does-the-gettimeofday-syscall-work >> >> On Jan 1, 2021, at 2:04 PM, Florian Weimer wrote: >> >> ?* Rados?aw Smogura: >> >> In current version of implementation (many places), there?s a lot of >> range checks. However longs in Java are signed, and C pointers are >> unsigned so, at least for x86-64 architectures this should be taken >> on account, otherwise we would not be able to address whole memory >> in straightforward way (largest block size is 2^31, can directly >> address upper half of memory). >> >> The x86-64 architecture actually has signed addresses in the sense >> that some number of upper bits of pointers must match the sign bit. >> On Linux, userspace addresses always have a zero sign bit. I think >> this is not true on Solaris. I don't know about Windows. >> >> On some architectures, C struggles with similar issues because >> ptrdiff_t is signed and does not cover the entire address space. It's >> therefore undefined to create objects whose size is greater than what >> can be expressed as a ptrdiff_t value, despite the underlying >> architecture supporting this. >> From info at j-kuhn.de Fri Jan 1 20:23:09 2021 From: info at j-kuhn.de (Johannes Kuhn) Date: Fri, 1 Jan 2021 21:23:09 +0100 Subject: Unsigned Integers (was: Support for 64-bit pointers) In-Reply-To: <833daef4-862c-170b-18cd-2b34a20443f8@gmail.com> References: <043D75D3-7490-4B3D-89B6-B8CFD28283CE@smogura.eu> <87eej4erkr.fsf@mid.deneb.enyo.de> <833daef4-862c-170b-18cd-2b34a20443f8@gmail.com> Message-ID: To chime in - there is already limited support for unsigned int / unsigned long. The short version is: You have to explicitly call Long.toUnsignedString or Long.divideUnsigned. Same for int. So far, so good. But there are some missing things: * Math.addExactUnsigned - should throw if there is an **unsigned** overflow. * Double.fromUnsignedLong - Turning an unsigned long into a double. * Byte.toUnsignedString * Double.toUnsignedLong - Turning a double into an unsigned long. I agree that using unsigned currently is clunky. There are some ways to work with that, sure, but the picture is not yet complete. The big problem with separate unsigned types is backwards comparability: if you have an array of unsigned bytes, but the api requires byte[], then you better can convert between those two representations without copying. So, IMHO, ask the amber guys for that. - Johannes PS.: I already intended to address those things in an other feedback mail, but this thread came first, so... On 01-Jan-21 19:56, Ty Young wrote: > Agreed, Java really needs unsigned types. Besides this specific issue, > there is also a major issue representing unsigned types in a high-level > API such as the previous Pointer API or my current API. In order to > represent a 1-byte unsigned number(byte) you would have to use a 2-byte > signed number(short), which distorts APIs and creates confusion as an > API user. If a function header says that you need an unsigned long then > Java should be able to pass an actual unsigned long type to it. > > > On 1/1/21 12:42 PM, leerho wrote: >> Hi Rados?aw & Florian, >> >> On a related topic, I have wished for years that Java would finally >> support >> unsigned integral types (byte, short, int, and long).? I'm sure that I'm >> not the first to mention this, so forgive me if this has been hashed out >> before.? But I do not understand why there would be resistance to this. >> For example, packing and unpacking "C-struct" -like data structures is a >> PITA in Java,? Bytes and shorts have to be masked when upcasting to ints >> and ints have to be masked when upcasting to longs all because of the >> automatic sign-extension.?? Not having unsigned types creates a ripe area >> for bugs that can be hard to find. >> >> Is there any hope of Java finally getting full support of unsigned types? >> >> Cheers, and Happy New Year, >> >> Lee. >> >> >> >> On Fri, Jan 1, 2021 at 9:49 AM Rados?aw Smogura wrote: >> >>> Hi Florian, >>> >>> That?s correct, even more there?s only 48 bits addressable. >>> >>> I?m not sure what I was thinking - I was doing some performance >>> checks and >>> was concerned that unrestricted access looked like doing range checks >>> and... well found this unrelated topic. >>> >>> However just to mention, some Linux distribution uses vsyscalls >>> (which is >>> going to be deprecated) and this is mapped to the tail of memory ([1] >>> nice >>> asm code) >>> >>> So even it?s not addressable it?s usable. I?m not sure if it?s worth >>> handling. >>> >>> Kind regards, >>> Rado >>> >>> [1] >>> https://stackoverflow.com/questions/7266813/how-does-the-gettimeofday-syscall-work >>> >>> >>> On Jan 1, 2021, at 2:04 PM, Florian Weimer wrote: >>> >>> ?* Rados?aw Smogura: >>> >>> In current version of implementation (many places), there?s a lot of >>> range checks. However longs in Java are signed, and C pointers are >>> unsigned so, at least for x86-64 architectures this should be taken >>> on account, otherwise we would not be able to address whole memory >>> in straightforward way (largest block size is 2^31, can directly >>> address upper half of memory). >>> >>> The x86-64 architecture actually has signed addresses in the sense >>> that some number of upper bits of pointers must match the sign bit. >>> On Linux, userspace addresses always have a zero sign bit.? I think >>> this is not true on Solaris.? I don't know about Windows. >>> >>> On some architectures, C struggles with similar issues because >>> ptrdiff_t is signed and does not cover the entire address space.? It's >>> therefore undefined to create objects whose size is greater than what >>> can be expressed as a ptrdiff_t value, despite the underlying >>> architecture supporting this. >>> From org.openjdk at io7m.com Fri Jan 1 20:52:47 2021 From: org.openjdk at io7m.com (Mark Raynsford) Date: Fri, 1 Jan 2021 20:52:47 +0000 Subject: Unsigned Integers (was: Support for 64-bit pointers) In-Reply-To: References: <043D75D3-7490-4B3D-89B6-B8CFD28283CE@smogura.eu> <87eej4erkr.fsf@mid.deneb.enyo.de> <833daef4-862c-170b-18cd-2b34a20443f8@gmail.com> Message-ID: <20210101205139.58ca5e7a@sunflower.int.arc7.info> On 2021-01-01T21:23:09 +0100 Johannes Kuhn wrote: > To chime in - there is already limited support for unsigned int / > unsigned long. The issue here is the lack of primitive classes, and those are being worked on in Valhalla. We can define all of the operations required to make a class behave almost identically to an unsigned integer today - as long as we're willing to live with the values of that class having the same performance characteristics as the primitive wrappers (Integer, Double, etc). I have no doubt whatsoever that Java will sprout all kinds of new numeric types (unsigned, complex, etc) when Valhalla is ready, but it's not ready yet. Unsigned types won't happen as part of Panama. -- Mark Raynsford | https://www.io7m.com From info at j-kuhn.de Fri Jan 1 21:20:57 2021 From: info at j-kuhn.de (Johannes Kuhn) Date: Fri, 1 Jan 2021 22:20:57 +0100 Subject: Unsigned Integers (was: Support for 64-bit pointers) In-Reply-To: <20210101205139.58ca5e7a@sunflower.int.arc7.info> References: <043D75D3-7490-4B3D-89B6-B8CFD28283CE@smogura.eu> <87eej4erkr.fsf@mid.deneb.enyo.de> <833daef4-862c-170b-18cd-2b34a20443f8@gmail.com> <20210101205139.58ca5e7a@sunflower.int.arc7.info> Message-ID: <6b7f5cff-bd1e-3020-8e8a-4f3e710c9356@j-kuhn.de> Custom primitive types are just half of the story - even if you can define your own ubyte, existing APIs probably won't accept your ubyte[]. The problem is converting your ubyte[] to byte[] - and if the object header of the array says "I'm an array of ubyte", then you can't simply change that. So, while Valhalla may indeed bring cheap custom types - switching to a custom type would break compatibility with existing APIs. And changing the type of all elements in an array is not so easy with Java - who reifies the array type in the object header. Haskell gets away with its coerce - because it erases all type information at runtime. And that's why you can't cast or do some kind of instanceof in Haskell. Different tradeoff. On 01-Jan-21 21:52, Mark Raynsford wrote: > On 2021-01-01T21:23:09 +0100 > Johannes Kuhn wrote: > >> To chime in - there is already limited support for unsigned int / >> unsigned long. > > The issue here is the lack of primitive classes, and those are being > worked on in Valhalla. We can define all of the operations required to > make a class behave almost identically to an unsigned integer today - > as long as we're willing to live with the values of that class having > the same performance characteristics as the primitive wrappers > (Integer, Double, etc). > > I have no doubt whatsoever that Java will sprout all kinds of new > numeric types (unsigned, complex, etc) when Valhalla is ready, but it's > not ready yet. Unsigned types won't happen as part of Panama. > Yes, unsigned fist-class types won't happen as part of Panama. As I wrote, I see this more as language feature - so "__unsigned byte[]" and "byte[]" are interchangeable - otherwise it would either be useless or make existing APIs incompatible. - Johannes From youngty1997 at gmail.com Fri Jan 1 22:24:10 2021 From: youngty1997 at gmail.com (Ty Young) Date: Fri, 1 Jan 2021 16:24:10 -0600 Subject: Unsigned Integers (was: Support for 64-bit pointers) In-Reply-To: References: <043D75D3-7490-4B3D-89B6-B8CFD28283CE@smogura.eu> <87eej4erkr.fsf@mid.deneb.enyo.de> <833daef4-862c-170b-18cd-2b34a20443f8@gmail.com> Message-ID: <6fc28ead-834c-d601-bbcb-83d2fc15a054@gmail.com> Sprinkling about a dozen methods onto the various number classes seems like a unelegant, kicking the? (metaphorical) can down the road approach IMO when adding actual unsigned types "Just Works(TM)". I think the MemoryAccess class/current jextract is a good example of why kicking the (metaphorical) can down the road instead of fixing the actual issue(that Panama needs a higher level API) is a bad idea. I'm not sure how having unsigned types would affect existing code, unless this is somekind of low-level technical issue? ubyte, ushort, uint, ulong are all different from their signed variants. If code that used byte[] worked before it should continue to work in the future, I would think. I don't remember if anyone has said Valhalla is an absolute requirement for Panama to be shipped, I only remember it being said that it can benefit in regards to reducing the memory cost of MemoryLayout types. If current Panama is wired so that an unsigned byte is actually a short(as they are with VarHandles, IIRC) could Panama even change it in the future without breaking backwards compatibility, assuming Panama is released before Valhalla? The same could be asked about a high level API too I think: if the lower level parts of Panama are shipped first and a higher level API is worked on after the fact then what happens if some major API issue is found in the lower level parts(MemoryAddress/MemorySegment)? I thought for the longest time that the Java only memory access parts of Panama was going to be shipped first, then ABI, jextract, maybe some high level API if it's deemed necessary/possible, and finally non-C APIs but the java memory access parts and the ABI have been mixed in a single repository and the old ones abandoned. On 1/1/21 2:23 PM, Johannes Kuhn wrote: > To chime in - there is already limited support for unsigned int / > unsigned long. > > The short version is: You have to explicitly call > Long.toUnsignedString or Long.divideUnsigned. Same for int. > > So far, so good. But there are some missing things: > * Math.addExactUnsigned - should throw if there is an **unsigned** > overflow. > * Double.fromUnsignedLong - Turning an unsigned long into a double. > * Byte.toUnsignedString > * Double.toUnsignedLong - Turning a double into an unsigned long. > > I agree that using unsigned currently is clunky. > There are some ways to work with that, sure, but the picture is not > yet complete. > > The big problem with separate unsigned types is backwards > comparability: ?if you have an array of unsigned bytes, but the api > requires byte[], then you better can convert between those two > representations without copying. So, IMHO, ask the amber guys for that. > > - Johannes > > PS.: I already intended to address those things in an other feedback > mail, but this thread came first, so... > > On 01-Jan-21 19:56, Ty Young wrote: >> Agreed, Java really needs unsigned types. Besides this specific >> issue, there is also a major issue representing unsigned types in a >> high-level API such as the previous Pointer API or my current API. In >> order to represent a 1-byte unsigned number(byte) you would have to >> use a 2-byte signed number(short), which distorts APIs and creates >> confusion as an API user. If a function header says that you need an >> unsigned long then Java should be able to pass an actual unsigned >> long type to it. >> >> >> On 1/1/21 12:42 PM, leerho wrote: >>> Hi Rados?aw & Florian, >>> >>> On a related topic, I have wished for years that Java would finally >>> support >>> unsigned integral types (byte, short, int, and long).? I'm sure that >>> I'm >>> not the first to mention this, so forgive me if this has been hashed >>> out >>> before.? But I do not understand why there would be resistance to this. >>> For example, packing and unpacking "C-struct" -like data structures >>> is a >>> PITA in Java,? Bytes and shorts have to be masked when upcasting to >>> ints >>> and ints have to be masked when upcasting to longs all because of the >>> automatic sign-extension.?? Not having unsigned types creates a ripe >>> area >>> for bugs that can be hard to find. >>> >>> Is there any hope of Java finally getting full support of unsigned >>> types? >>> >>> Cheers, and Happy New Year, >>> >>> Lee. >>> >>> >>> >>> On Fri, Jan 1, 2021 at 9:49 AM Rados?aw Smogura >>> wrote: >>> >>>> Hi Florian, >>>> >>>> That?s correct, even more there?s only 48 bits addressable. >>>> >>>> I?m not sure what I was thinking - I was doing some performance >>>> checks and >>>> was concerned that unrestricted access looked like doing range checks >>>> and... well found this unrelated topic. >>>> >>>> However just to mention, some Linux distribution uses vsyscalls >>>> (which is >>>> going to be deprecated) and this is mapped to the tail of memory >>>> ([1] nice >>>> asm code) >>>> >>>> So even it?s not addressable it?s usable. I?m not sure if it?s worth >>>> handling. >>>> >>>> Kind regards, >>>> Rado >>>> >>>> [1] >>>> https://stackoverflow.com/questions/7266813/how-does-the-gettimeofday-syscall-work >>>> >>>> >>>> On Jan 1, 2021, at 2:04 PM, Florian Weimer wrote: >>>> >>>> ?* Rados?aw Smogura: >>>> >>>> In current version of implementation (many places), there?s a lot of >>>> range checks. However longs in Java are signed, and C pointers are >>>> unsigned so, at least for x86-64 architectures this should be taken >>>> on account, otherwise we would not be able to address whole memory >>>> in straightforward way (largest block size is 2^31, can directly >>>> address upper half of memory). >>>> >>>> The x86-64 architecture actually has signed addresses in the sense >>>> that some number of upper bits of pointers must match the sign bit. >>>> On Linux, userspace addresses always have a zero sign bit. I think >>>> this is not true on Solaris.? I don't know about Windows. >>>> >>>> On some architectures, C struggles with similar issues because >>>> ptrdiff_t is signed and does not cover the entire address space.? It's >>>> therefore undefined to create objects whose size is greater than what >>>> can be expressed as a ptrdiff_t value, despite the underlying >>>> architecture supporting this. >>>> From sirinath1978m at gmail.com Sun Jan 3 11:14:07 2021 From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena) Date: Sun, 3 Jan 2021 16:44:07 +0530 Subject: Parity with C/C++ & Fortran Standard Library, Intrinsics, Pragmas, Built-ins and Platform Specific Functions Message-ID: Hello, Some time the motivation to call C/C++ would be to use some of the built in functions, intrinsics, pragmas and platform specific functions. Writing simple functions to access these types of functionality may be an inconvenience even with the introduction of Panama. So it is possible to have a package (perhaps like javax.intrinsics.*) which provides similar functionality in Java without every one having to roll out native code for simple native code like just to call a C/C++ or Fortran library function, Intrinsics, Pragmas, Built-ins. GCC and Clang being portable many of the this functionality would be portable. Also they need not match what is available in a particular C/C++ implementation but should be generic while being a super set of functionality w.r.t. any give C/C++ & Fortran implementation. It can follow the approach used in SIMDe (https://github.com/simd-everywhere/simde) project, but not limited just to SIMD intrinsics. Also the code should feel idiomatic Java. Many of the functionality that might need to be visited from the Standard Libraries are what are intrincsified or low level or through otherwise not available in Java. Simple interface to calling native code is great! But being able to avoid it altogether but nevertheless achieving the same results in portable manner is even better! Suminda From jorn.vernee at oracle.com Mon Jan 4 10:46:26 2021 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Mon, 4 Jan 2021 11:46:26 +0100 Subject: Obtain MemorySegment from MemoryAddress for a given MemoryLayout In-Reply-To: <923683D7-2617-4053-923D-A3A687F58146@gmail.com> References: <923683D7-2617-4053-923D-A3A687F58146@gmail.com> Message-ID: Hi, On 28/12/2020 19:15, Sebastian Stenzel wrote: > During my latest experiments with Panama, I have to deal a lot with MemoryAddresses pointing to structs, that I need to access from Java: > > Let's say I have demo.h declaring my_struct: > > ``` > struct my_struct { > int foo; > }; > > ``` > > If I run jextract on demo.h, it'll generate code that allows me to get "foo" from a segment, but not from an address: > > ``` > int getFooFromMyStruct(MemoryAddress addr) { > var segment = demo_h.my_struct.ofAddressRestricted(addr); // is there a better way, if I know the layout for sure? > return demo_h.my_struct.foo$get(segment); // segment required here > } > ``` > > Now I'm wondering, if there is any safe (read: not restricted) way to obtain a MemorySegment for a given layout and address? No, there is no non-restricted variant for turning a MemoryAddress into a MemorySegment. The latter is directly dereferencable from Java (hence that being the required type for the getter), while the former is not. The conversion from a MemoryAddress to a MemorySegment needs to essentially attach a size to a pointer to define a region of dereferencable memory, but there is no way to mechanically check that the size being attached is actually correct. So, dereferencing the resulting MemorySegment can still result in crashes and/or silent memory corruption, and hence it is restricted functionality. Jorn From jorn.vernee at oracle.com Mon Jan 4 11:00:34 2021 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Mon, 4 Jan 2021 12:00:34 +0100 Subject: jextract generates downcallHandles where I need upcallStubs In-Reply-To: <533CD426-AE72-4943-BF55-DDE8E27C6E6A@gmail.com> References: <9951DC24-1AA1-4DDA-9352-72F0433FE6EB@gmail.com> <30533a6c-d3dd-fe7e-fcbf-e137ad7f4f7e@oracle.com> <67137C76-E70A-4826-8811-EC4001609C58@gmail.com> <533CD426-AE72-4943-BF55-DDE8E27C6E6A@gmail.com> Message-ID: <95c3e061-93c0-40bc-d4cd-4293e958648a@oracle.com> On 28/12/2020 13:13, Sebastian Stenzel wrote: > >> On 28. Dec 2020, at 12:38, Maurizio Cimadamore wrote: >> >> >> >> On 26/12/2020 09:23, Sebastian Stenzel wrote: >>>> On 15. Dec 2020, at 12:31, Maurizio Cimadamore > wrote: >>>> >>>> Now, it's true that the function pointer type behind "readdir" takes its own function pointer (filler), but that shouldn't be a concern when creating the upcall for (1) - a function pointer is just some MemoryAddress parameter that the upcall receives (and that the runtime of the libfuse library will provide). And, it is true that, in this case jextract will also generate functional interfaces for e.g. the filler upcall, but you don't have to use them in this case (since the filler function pointer will never be generated by you - but by the library) - of course jextract sees a function pointer and generates the corresponding functional interface, it has no way to know which party will allocate the function pointer. >>> After experimenting with the latest snapshot version of Panama, I was now able to implement aforementioned readdir() method. However I still don't manage to use the filler function. >>> >>> jextract will generate a Java method interface from readdir [1] that looks like this: >>> >>> ``` >>> int readdir(MemoryAddress path, MemoryAddress buf, MemoryAddress filler, long offset, MemoryAddress fi) >>> ``` >>> >>> Note that the filler is merely a MemoryAddress. From within my Java implementation I'd need to call filler, however in order to create a downcallHandle from this address, I'd need to know the FunctionDescriptor, which is kept package-private within the code generated by jextract. >>> >>> It would be even easier, if there was some way to retrieve a MethodHandle from a given MemoryAddress and a known FunctionDescriptor. >>> >>> Or am I missing something, again? >> So, if I understand correctly, what you need here is to pass a function pointer to the routine that does the "filling" - which is probably a Java upcall. >> > No, it's a downcall from within an upcall method (more on this below). >> Since `fuse_fill_dir_t` is defined as a function type, there should be a functional interface generated for that parameter (probably called something like readdir$filler). If you don't see the functional interface, it is possible you might be missing the fix for: >> >> https://github.com/openjdk/panama-foreign/pull/424 >> Which, judging from the date in which it has been integrated, it is not part of the EA. >> >> Are you in a position to do a build of the Panama repo? If so, you could try if the functional interface is generated in that case. >> >> We plan to spin up another EA as soon as IntelliJ is updated to support Java 16 in full. >> >> Cheers >> Maurizio >> >> > Hi, > > first of all, I did build the latest version myself and can confirm, that the upcall interfaces for function pointers are being generated now. ?? > > I.e. we now get `fuse_h.fuse_operations.readdir` with the correct signature mentioned in my previous email. I can now implement this method, but from within its implementation I need to make a downcall (!) invocation of the "filler" function passed as the second param of the method. > > Only an upcall interface for this method gets generated (`fuse_h.fuse_fs_readdir$filler`), which is incorrect in this case. In order to retrieve a downcall handle, I need to pass this address to CLinker together with the Java MethodType and the C FunctionDescriptor. However the FunctionDescriptor is kept package-private in `fuse_h_constants_4.fuse_fs_readdir$filler$FUNC()` and the MethodType is hidden in some string representation. > > Maybe seeing this implementation helps to understand the role of readdir (upcall) and the filler callback (downcall): > > https://github.com/skymatic/fuse-panama/blob/b56bb6782f52499279883672972e53ec38942934/src/main/java/de/skymatic/fusepanama/examples/HelloFileSystem.java#L79-L81 > > Best regards > Sebastian I think I understand the problem; You have some upcall/callback that takes a function pointer as MemoryAddress, and would like to make it callable, and it would be useful if jextract, but the MethodType and FunctionDescriptor associated with the function pointers type are non-accessible. FWIW, these were accessible in the past, but making them inaccessible was done on purpose to see what kind of use-cases would pop up. In this case, I think it would be useful if jextract generated a helper method for converting a MemoryAddress that is a function pointer into a MethodHandle (or a functional interface instance), so it is easier to call from Java as well. e.g. add something like this to the generated function interfaces for function pointer types: ??? public interface myHeader$foo$f { ??????? ... ??????? public static myHeader$foo$f ofAddress(MemoryAddress); ??? } That would than call the linker with the right MethodType and FunctionDescriptor for you. Does that sound like it would work for your use case? Jorn From maurizio.cimadamore at oracle.com Mon Jan 4 11:23:31 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 4 Jan 2021 11:23:31 +0000 Subject: Panama source code fails to compile In-Reply-To: <9045aa0c-5454-3b18-13a1-b39252a29622@gmail.com> References: <5ea52f78-f853-57df-7c7f-fa299b091c55@gmail.com> <409652537.261382.1609190287324.JavaMail.zimbra@u-pem.fr> <9a74ba5e-523a-e96d-4e60-8d66b6e0516f@gmail.com> <9045aa0c-5454-3b18-13a1-b39252a29622@gmail.com> Message-ID: <30df2329-2332-1b6f-bc5f-6fb40974ca60@oracle.com> As usual, I find the tone of some of these emails way over the top. We do have CI, both internally and externally. I don't think the GitHub test was triggered during the merge, so the external CI did not run in this case. Our internal CI ran as usual and did not report any error - likely, as Remi said, because of a difference in the compiler being used. I confirm that the problem can be reproduced on my system also - which also sports a relatively recent GCC compiler (9.3.0). > Just a little annoyed, sorry. I try to always use the latest builds so > I don't have to constantly make large code changes, although there > hasn't been many changes lately, which is odd. Is Panama's API nearly > complete? What's the state of Panama at this point? That's why we have binary snapshots :-) We just released one before Christmas: https://jdk.java.net/panama/ As discussed in a related thread, this is compatible with the API in 16, so you can use jextract from there and then just use a 16 EA. While this EA does not contain few jextract-related fixes, it is recommended for most usages compared to the latest repo bits - especially because the latest bits are unusable at least on IntelliJ (changes to support strong encapsulation break the IDE which does not, as of yet, officially supports Java 16). We will release another Panama EA when the IDE situation has been cleared. As for the state of the API, as the API is incubating we consider it to be our best shot _so far_, but things might still change given targeted feedback. Of course, the more we are iterating, the less substantial API changes you are seeing. Cheers Maurizio On 29/12/2020 21:12, Ty Young wrote: > Yes, mostly. Things happen, especially on holidays when everyone has > things to do and places to be. I was going to wait until after the new > year to bring it up, but I had seen JDK developers replying to things > so I figured they were back. > > > A proper CI could have at least warned that there is an issue, just > like other previous issues. Having newer JDK builds would be a benefit > to projects like Panama as it reduces the hurdle to try out recent > versions, especially those on Windows. Again, probably screaming into > the void on the CI thing. > > > On 12/29/20 5:21 AM, Samuel Audet wrote: >> Hi, >> >> I think the point is that this could have been prevented with proper >> CI. Since the repos are now on GitHub, OpenJDK could easily benefit >> from GitHub Actions... >> >> Samuel >> >> On Tue, Dec 29, 2020, 16:39 David Holmes > > wrote: >> >> ??? On 29/12/2020 1:06 pm, Ty Young wrote: >> ??? > >> ??? > On 12/28/20 3:18 PM, Remi Forax wrote: >> ??? >> ----- Mail original ----- >> ??? >>> De: "Ty Young" > ??? > >> ??? >>> ?: "panama-dev at openjdk.java.net >> ??? '" >> ??? > >> ??? >>> Envoy?: Lundi 28 D?cembre 2020 22:06:58 >> ??? >>> Objet: Panama source code fails to compile >> ??? >>> Just an FYI, the Panama source code have been broken since >> before >> ??? >>> Christmas with this error: >> ??? >>> >> ??? >>> >> ??? >>> panama-foreign/src/hotspot/share/oops/methodData.cpp:1616:6: >> ??? error: >> ??? >>> redefinition of 'static bool >> ??? MethodData::profile_memory_access(const >> ??? >>> methodHandle&, int)' >> ??? >>> ??1616 | bool MethodData::profile_memory_access(const >> ??? methodHandle& m, >> ??? >>> int bci) { >> ??? >>> ?????? |????? ^~~~~~~~~~ >> ??? >>> >> /run/media/ty/Windows_Linux_Shared/OpenJDK/panama-foreign/src/hotspot/share/oops/methodData.cpp:1604:6: >> >> ??? >>> >> ??? >>> note: 'static bool MethodData::profile_memory_access(const >> ??? >>> methodHandle&, int)' previously defined here >> ??? >>> ??1604 | bool MethodData::profile_memory_access(const >> ??? methodHandle& m, >> ??? >>> int bci) { >> ??? >>> ?????? | >> ??? >>> >> ??? >>> >> ??? >>> I tried building using the usual `bash configure >> ??? >>> --disable-warnings-as-errors` and `make images` on (Arch) >> ??? Linux. I am >> ??? >>> able to compile the standard JDK from source just fine. >> ??? >>> >> ??? >>> >> ??? >>> I know I'm probably (metaphorically) screaming into the void >> ??? here but... >> ??? >>> people often have data caps and JDK source code is *A LOT*. >> Not to >> ??? >>> mention the CPU and memory requirements needed to compile it >> in a >> ??? >>> reasonable amount of time, which are massive. I suggested >> ??? months ago on >> ??? >>> the skara-dev list on having build succeeded/failed badges >> and/or >> ??? >>> automatic JDK builds but apparently no one is interested >> ??? because it >> ??? >>> hasn't been added. Is making sure your code compiles & runs >> ??? before you >> ??? >>> push it not a requirement for JDK developers or something? I >> ??? understand >> ??? >>> it was Christmas but this has happened a few times now. >> ??? >> Usually for this kind of error, it's because you are compiling >> ??? with a >> ??? >> c++ compiler more recent than the one used by the CI, >> ??? >> so the bug flies under the radar. >> ??? > >> ??? > >> ??? > There is clearly a duplicate declaration: >> ??? > >> ??? > >> ??? > >> https://github.com/openjdk/panama-foreign/blob/5a8d47fd226708e46f56ec82294e9c786f6850c1/src/hotspot/share/oops/methodData.cpp#L1604 >> >> >> ??? > >> ??? > >> ??? > >> ??? > and >> ??? > >> ??? > >> ??? > >> https://github.com/openjdk/panama-foreign/blob/5a8d47fd226708e46f56ec82294e9c786f6850c1/src/hotspot/share/oops/methodData.cpp#L1616 >> >> >> ??? > >> ??? > >> ??? > >> ??? > are the same. Git blame shows that the duplicate was added 17 >> ??? days ago: >> ??? > >> ??? > >> ??? > >> https://github.com/openjdk/panama-foreign/blame/5a8d47fd226708e46f56ec82294e9c786f6850c1/src/hotspot/share/oops/methodData.cpp#L1616 >> >> >> >> ??? I think I see what happened. >> >> ??? JDK-8257692 was fixed in the panama-foreign repo in foreign-jextract >> ??? branch. >> >> ??? JDK-8258242 was fixed in the mainline JDK and contained some of >> ??? the same >> ??? code changes. >> >> ??? A few days before Christmas there was an auto-merge between >> ??? panama-foreign and mainline JDK, and that is when the duplicate code >> ??? chunk has arisen. >> >> ??? David >> ??? ----- >> >> ??? > >> ??? > >> ??? > and removing the duplicate allows the JDK to build correctly. >> ??? > >> ??? > >> ??? > So, no, this has nothing to do with the distro or the compiler I >> ??? use. >> ??? > I've already been through this blame game nonsense on swing-dev >> ??? with JDK >> ??? > developers when they broke literally every Swing application >> ??? that used >> ??? > GTK L&F on Arch Linux, lets not do it again, please. >> ??? > >> ??? > >> ??? >> >> ??? >>> >> ??? >>> Just a little annoyed, sorry. I try to always use the latest >> ??? builds so I >> ??? >>> don't have to constantly make large code changes, although >> ??? there hasn't >> ??? >>> been many changes lately, which is odd. Is Panama's API nearly >> ??? complete? >> ??? >>> What's the state of Panama at this point? >> ??? >> R?mi >> From maurizio.cimadamore at oracle.com Mon Jan 4 11:33:05 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 4 Jan 2021 11:33:05 +0000 Subject: Unsigned Integers In-Reply-To: <20210101205139.58ca5e7a@sunflower.int.arc7.info> References: <043D75D3-7490-4B3D-89B6-B8CFD28283CE@smogura.eu> <87eej4erkr.fsf@mid.deneb.enyo.de> <833daef4-862c-170b-18cd-2b34a20443f8@gmail.com> <20210101205139.58ca5e7a@sunflower.int.arc7.info> Message-ID: <00660ae1-05b9-9b91-b05d-c0035a9aa5ec@oracle.com> On 01/01/2021 20:52, Mark Raynsford wrote: > I have no doubt whatsoever that Java will sprout all kinds of new > numeric types (unsigned, complex, etc) when Valhalla is ready, but it's > not ready yet. Unsigned types won't happen as part of Panama. This is the correct answer. Valhalla will give us new ammo to define the data types we need to interact with C in a more natural way. As for bound checks, we are aware of some of the limitations of the current system, and the fact that it might not work correctly with negative addresses - that said, there's just a lot of constraints to work with, as not all bound checks routines are optimized in the same way (for instance, it matters as to whether the bound check is done using long or ints, at the moment, which causes complexity in the implementation). So, doing the "right" thing in the implementation would almost surely result in a big performance regression. None of these problems are unsolvable, but we will tackle this particular issue when we have a clearer picture of how unrolling optimizations involving long loops will work (this work is currently in progress). Cheers Maurizio From maurizio.cimadamore at oracle.com Mon Jan 4 11:42:49 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 4 Jan 2021 11:42:49 +0000 Subject: Unsigned Integers In-Reply-To: <6fc28ead-834c-d601-bbcb-83d2fc15a054@gmail.com> References: <043D75D3-7490-4B3D-89B6-B8CFD28283CE@smogura.eu> <87eej4erkr.fsf@mid.deneb.enyo.de> <833daef4-862c-170b-18cd-2b34a20443f8@gmail.com> <6fc28ead-834c-d601-bbcb-83d2fc15a054@gmail.com> Message-ID: On 01/01/2021 22:24, Ty Young wrote: > I don't remember if anyone has said Valhalla is an absolute > requirement for Panama to be shipped, I only remember it being said > that it can benefit in regards to reducing the memory cost of > MemoryLayout types. If current Panama is wired so that an unsigned > byte is actually a short(as they are with VarHandles, IIRC) could > Panama even change it in the future without breaking backwards > compatibility, assuming Panama is released before Valhalla? The same > could be asked about a high level API too I think: if the lower level > parts of Panama are shipped first and a higher level API is worked on > after the fact then what happens if some major API issue is found in > the lower level parts(MemoryAddress/MemorySegment)? Valhalla is NOT a requirement for Panama to ship. We can update what jextract generates w/o breaking compatibility (of course to get better Valhalla-ized API you might need to re-extract, or maybe there is some flag). In other words, I see a more direct relationship between Valhalla and jextract than I see it between Valhalla and the core low level memory access/linker APIs. > > > I thought for the longest time that the Java only memory access parts > of Panama was going to be shipped first, then ABI, jextract, maybe > some high level API if it's deemed necessary/possible, and finally > non-C APIs but the java memory access parts and the ABI have been > mixed in a single repository and the old ones abandoned. The memory access part is the most mature, true - but it does not exist in a vacuum. We wanted to have a round of incubation including both, because it's very likely that uses of the memory access coming from the foreign function side of things are very different from usages of the memory access API in isolation (which are likely similar to what you would do with the ByteBuffer API). And we need to get both side of the interaction right. So, in terms of how APIs might be _finalized_ you might well see the memory access being finalized earlier than the linker API. Since now both APIs are integrated into upstream 16, it simply didn't make a lot of sense to keep having two panama branches for the different APIs. We already explained all this here: https://mail.openjdk.java.net/pipermail/panama-dev/2020-December/011499.html Maurizio From sebastian.stenzel at gmail.com Mon Jan 4 11:31:05 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Mon, 4 Jan 2021 12:31:05 +0100 Subject: jextract generates downcallHandles where I need upcallStubs In-Reply-To: <95c3e061-93c0-40bc-d4cd-4293e958648a@oracle.com> References: <95c3e061-93c0-40bc-d4cd-4293e958648a@oracle.com> Message-ID: <4BB7ADEE-4C31-4EC9-B72A-7A3C0693D3D5@gmail.com> Yes, this is exactly what I need! Thank you for responding so promptly to feedback! :) > Am 04.01.2021 um 12:00 schrieb Jorn Vernee : > > ?On 28/12/2020 13:13, Sebastian Stenzel wrote: >> >>>> On 28. Dec 2020, at 12:38, Maurizio Cimadamore wrote: >>> >>> >>> >>> On 26/12/2020 09:23, Sebastian Stenzel wrote: >>>>> On 15. Dec 2020, at 12:31, Maurizio Cimadamore > wrote: >>>>> >>>>> Now, it's true that the function pointer type behind "readdir" takes its own function pointer (filler), but that shouldn't be a concern when creating the upcall for (1) - a function pointer is just some MemoryAddress parameter that the upcall receives (and that the runtime of the libfuse library will provide). And, it is true that, in this case jextract will also generate functional interfaces for e.g. the filler upcall, but you don't have to use them in this case (since the filler function pointer will never be generated by you - but by the library) - of course jextract sees a function pointer and generates the corresponding functional interface, it has no way to know which party will allocate the function pointer. >>>> After experimenting with the latest snapshot version of Panama, I was now able to implement aforementioned readdir() method. However I still don't manage to use the filler function. >>>> >>>> jextract will generate a Java method interface from readdir [1] that looks like this: >>>> >>>> ``` >>>> int readdir(MemoryAddress path, MemoryAddress buf, MemoryAddress filler, long offset, MemoryAddress fi) >>>> ``` >>>> >>>> Note that the filler is merely a MemoryAddress. From within my Java implementation I'd need to call filler, however in order to create a downcallHandle from this address, I'd need to know the FunctionDescriptor, which is kept package-private within the code generated by jextract. >>>> >>>> It would be even easier, if there was some way to retrieve a MethodHandle from a given MemoryAddress and a known FunctionDescriptor. >>>> >>>> Or am I missing something, again? >>> So, if I understand correctly, what you need here is to pass a function pointer to the routine that does the "filling" - which is probably a Java upcall. >>> >> No, it's a downcall from within an upcall method (more on this below). >>> Since `fuse_fill_dir_t` is defined as a function type, there should be a functional interface generated for that parameter (probably called something like readdir$filler). If you don't see the functional interface, it is possible you might be missing the fix for: >>> >>> https://github.com/openjdk/panama-foreign/pull/424 >>> Which, judging from the date in which it has been integrated, it is not part of the EA. >>> >>> Are you in a position to do a build of the Panama repo? If so, you could try if the functional interface is generated in that case. >>> >>> We plan to spin up another EA as soon as IntelliJ is updated to support Java 16 in full. >>> >>> Cheers >>> Maurizio >>> >>> >> Hi, >> >> first of all, I did build the latest version myself and can confirm, that the upcall interfaces for function pointers are being generated now. ?? >> >> I.e. we now get `fuse_h.fuse_operations.readdir` with the correct signature mentioned in my previous email. I can now implement this method, but from within its implementation I need to make a downcall (!) invocation of the "filler" function passed as the second param of the method. >> >> Only an upcall interface for this method gets generated (`fuse_h.fuse_fs_readdir$filler`), which is incorrect in this case. In order to retrieve a downcall handle, I need to pass this address to CLinker together with the Java MethodType and the C FunctionDescriptor. However the FunctionDescriptor is kept package-private in `fuse_h_constants_4.fuse_fs_readdir$filler$FUNC()` and the MethodType is hidden in some string representation. >> >> Maybe seeing this implementation helps to understand the role of readdir (upcall) and the filler callback (downcall): >> >> https://github.com/skymatic/fuse-panama/blob/b56bb6782f52499279883672972e53ec38942934/src/main/java/de/skymatic/fusepanama/examples/HelloFileSystem.java#L79-L81 >> >> Best regards >> Sebastian > I think I understand the problem; > > You have some upcall/callback that takes a function pointer as MemoryAddress, and would like to make it callable, and it would be useful if jextract, but the MethodType and FunctionDescriptor associated with the function pointers type are non-accessible. FWIW, these were accessible in the past, but making them inaccessible was done on purpose to see what kind of use-cases would pop up. > > In this case, I think it would be useful if jextract generated a helper method for converting a MemoryAddress that is a function pointer into a MethodHandle (or a functional interface instance), so it is easier to call from Java as well. e.g. add something like this to the generated function interfaces for function pointer types: > > public interface myHeader$foo$f { > ... > public static myHeader$foo$f ofAddress(MemoryAddress); > } > > That would than call the linker with the right MethodType and FunctionDescriptor for you. > > Does that sound like it would work for your use case? > > Jorn From jorn.vernee at oracle.com Mon Jan 4 11:45:41 2021 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Mon, 4 Jan 2021 12:45:41 +0100 Subject: jextract generates downcallHandles where I need upcallStubs In-Reply-To: <4BB7ADEE-4C31-4EC9-B72A-7A3C0693D3D5@gmail.com> References: <95c3e061-93c0-40bc-d4cd-4293e958648a@oracle.com> <4BB7ADEE-4C31-4EC9-B72A-7A3C0693D3D5@gmail.com> Message-ID: Ok :) I've filed: https://bugs.openjdk.java.net/browse/JDK-8259054 Thanks for the feedback! Jorn On 04/01/2021 12:31, Sebastian Stenzel wrote: > Yes, this is exactly what I need! Thank you for responding so promptly to feedback! :) > >> Am 04.01.2021 um 12:00 schrieb Jorn Vernee : >> >> ?On 28/12/2020 13:13, Sebastian Stenzel wrote: >>>>> On 28. Dec 2020, at 12:38, Maurizio Cimadamore wrote: >>>> >>>> >>>> On 26/12/2020 09:23, Sebastian Stenzel wrote: >>>>>> On 15. Dec 2020, at 12:31, Maurizio Cimadamore > wrote: >>>>>> >>>>>> Now, it's true that the function pointer type behind "readdir" takes its own function pointer (filler), but that shouldn't be a concern when creating the upcall for (1) - a function pointer is just some MemoryAddress parameter that the upcall receives (and that the runtime of the libfuse library will provide). And, it is true that, in this case jextract will also generate functional interfaces for e.g. the filler upcall, but you don't have to use them in this case (since the filler function pointer will never be generated by you - but by the library) - of course jextract sees a function pointer and generates the corresponding functional interface, it has no way to know which party will allocate the function pointer. >>>>> After experimenting with the latest snapshot version of Panama, I was now able to implement aforementioned readdir() method. However I still don't manage to use the filler function. >>>>> >>>>> jextract will generate a Java method interface from readdir [1] that looks like this: >>>>> >>>>> ``` >>>>> int readdir(MemoryAddress path, MemoryAddress buf, MemoryAddress filler, long offset, MemoryAddress fi) >>>>> ``` >>>>> >>>>> Note that the filler is merely a MemoryAddress. From within my Java implementation I'd need to call filler, however in order to create a downcallHandle from this address, I'd need to know the FunctionDescriptor, which is kept package-private within the code generated by jextract. >>>>> >>>>> It would be even easier, if there was some way to retrieve a MethodHandle from a given MemoryAddress and a known FunctionDescriptor. >>>>> >>>>> Or am I missing something, again? >>>> So, if I understand correctly, what you need here is to pass a function pointer to the routine that does the "filling" - which is probably a Java upcall. >>>> >>> No, it's a downcall from within an upcall method (more on this below). >>>> Since `fuse_fill_dir_t` is defined as a function type, there should be a functional interface generated for that parameter (probably called something like readdir$filler). If you don't see the functional interface, it is possible you might be missing the fix for: >>>> >>>> https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign/pull/424__;!!GqivPVa7Brio!J-6YWuppnGWMdR3PNyRSNx1s4qCeg43C12hkrqhXVKWEyg9KuljJm6JSAX0UXkg_$ >>>> Which, judging from the date in which it has been integrated, it is not part of the EA. >>>> >>>> Are you in a position to do a build of the Panama repo? If so, you could try if the functional interface is generated in that case. >>>> >>>> We plan to spin up another EA as soon as IntelliJ is updated to support Java 16 in full. >>>> >>>> Cheers >>>> Maurizio >>>> >>>> >>> Hi, >>> >>> first of all, I did build the latest version myself and can confirm, that the upcall interfaces for function pointers are being generated now. ?? >>> >>> I.e. we now get `fuse_h.fuse_operations.readdir` with the correct signature mentioned in my previous email. I can now implement this method, but from within its implementation I need to make a downcall (!) invocation of the "filler" function passed as the second param of the method. >>> >>> Only an upcall interface for this method gets generated (`fuse_h.fuse_fs_readdir$filler`), which is incorrect in this case. In order to retrieve a downcall handle, I need to pass this address to CLinker together with the Java MethodType and the C FunctionDescriptor. However the FunctionDescriptor is kept package-private in `fuse_h_constants_4.fuse_fs_readdir$filler$FUNC()` and the MethodType is hidden in some string representation. >>> >>> Maybe seeing this implementation helps to understand the role of readdir (upcall) and the filler callback (downcall): >>> >>> https://urldefense.com/v3/__https://github.com/skymatic/fuse-panama/blob/b56bb6782f52499279883672972e53ec38942934/src/main/java/de/skymatic/fusepanama/examples/HelloFileSystem.java*L79-L81__;Iw!!GqivPVa7Brio!J-6YWuppnGWMdR3PNyRSNx1s4qCeg43C12hkrqhXVKWEyg9KuljJm6JSAWp0vKfq$ >>> >>> Best regards >>> Sebastian >> I think I understand the problem; >> >> You have some upcall/callback that takes a function pointer as MemoryAddress, and would like to make it callable, and it would be useful if jextract, but the MethodType and FunctionDescriptor associated with the function pointers type are non-accessible. FWIW, these were accessible in the past, but making them inaccessible was done on purpose to see what kind of use-cases would pop up. >> >> In this case, I think it would be useful if jextract generated a helper method for converting a MemoryAddress that is a function pointer into a MethodHandle (or a functional interface instance), so it is easier to call from Java as well. e.g. add something like this to the generated function interfaces for function pointer types: >> >> public interface myHeader$foo$f { >> ... >> public static myHeader$foo$f ofAddress(MemoryAddress); >> } >> >> That would than call the linker with the right MethodType and FunctionDescriptor for you. >> >> Does that sound like it would work for your use case? >> >> Jorn From luhenry at microsoft.com Mon Jan 4 13:48:40 2021 From: luhenry at microsoft.com (Ludovic Henry) Date: Mon, 4 Jan 2021 13:48:40 +0000 Subject: BLAS and Vector API In-Reply-To: <7264552B-57D9-40CD-92CA-7BBFA7FD7324@ORACLE.COM> References: , <7264552B-57D9-40CD-92CA-7BBFA7FD7324@ORACLE.COM> Message-ID: Hi Adam, Following your last message, I?ve added FMA and it allowed for a speedup (thanks for the tip!). I?ve also improved the performance of all the other operators, and it now beats the java implementation for all of them. You can find development at [1] and the latest version JMH results at [2]. On some of these benchmarks, the vector implementation beats the native implementation whatever the size of the input (ex: ddot, sdot, daxpy), or only on small inputs (ex: dsyr, dspr, dspmv, dscal). But the dgemm (matrix-matrix multiply) operation is clearly where there is the most work to do, most likely on the algorithm itself and not necessarily on the Vector API. Over the holiday break, I?ve also started to implement most operations in Java without the Vector API [3], and I?m faster than F2jBLAS on all implemented operations. Once I?m done with all these operations, I?ll rebase the VectorizedBLAS implementation on JavaBLAS and infuse some of the learnings. I?ll also explore using the Foreign Linker API to wrap the OpenBLAS library without going through JNI. I?m curious whether it?s going to lead to performance improvements. Thank you, Ludovic [1] https://github.com/luhenry/blas/commits/master/blas/src/main/java/dev/ludovic/blas/VectorizedBLAS.java [2] https://github.com/luhenry/blas/releases/tag/v0.1.8 [3] https://github.com/luhenry/blas/blob/master/blas/src/main/java/dev/ludovic/blas/JavaBLAS.java From: Adam Pocock Sent: Thursday, 17 December 2020 19:21 To: Ludovic Henry Cc: panama-dev at openjdk.java.net; Bernhard Urban-Forster; Monica Beckwith Subject: Re: BLAS and Vector API Hi Ludovic, This is very interesting. Did you try using the FMA operation for the various dot operations? The last time I benchmarked this (which was a few years ago) I think doing an fma into a vector to aggregate the values and then doing a single reduce lanes at the end was faster. I?m hoping to get some time early next year to try and vectorise Tribuo?s (https://tribuo.org) linear algebra package to give a baseline for machine learning workloads. It would be interesting to compare that to your work. I?ve had good results from earlier prototypes which accelerated simple linear algebra operations for other ML workloads. Thanks, Adam -- Adam Pocock Principal Member of Technical Staff Machine Learning Research Group Oracle Labs, Burlington, MA On 17 Dec 2020, at 06:55, Ludovic Henry > wrote: Hello, As I?ve continued to learn more about the Vector API, I searched for a real-life application that would benefit from it. I then looked into Spark and how they use BLAS for their ML operations. BLAS is kind of an ideal application for the Vector API as it?s all Matrices and Vectors operations with native types (double and float mainly). I then created the vectorizedblas project [1] (with the associated benchmarking suite at [2]) to develop such algorithms and try to improve over the performance of both the java (f2j) and native BLAS implementations. I?ve also submitted a PR to Spark [3] to accelerate the java implementation using the same implementation. The goal here isn?t to replace the native BLAS right away, as there is still a lot of work to match the performance, but to accelerate Sparks in deployments not using the native BLAS implementation. You can find the results of a run of the vectorizedblas benchmark suite at [4]. Some of the vectorized implementations are slower evidently because my implementation is na?ve. But some other benchmarks are slower with no clear-cut reasons (why is ddot faster but not sdot? It doesn?t seem to be memory alignement as I?ve tested with -XX:ObjectAlignmentInBytes=16 with no improvements). The goal of this work is two-fold: 1. add a benchmarking suite for the Vector API that tests another real-life application (ML) with an easily accessible native implemantion for comparison sake, and 2. accelerate Spark workload out of the box, and eventually remove the dependency on the native BLAS implementation (or leave it only as a rarely-used fallback). >From this work, I?ve noticed something which I think would be valuable in the Vector API. Even though memory alignement is an important aspect of ensuring high level of performance, there is no way to easily ?align? the loops. There is `VectorSpecies.loopBound` to know when to stop the vectorized loop, but it?s missing a `VectorSpecies.loopAlign` to know when to _start_ the vectorized loop based on the address of the array you?re loading data from. I imagine the following code: ``` int i = 0; for (; i < DMAX.loopAlign(x, n); i += 1) { x[i] = x[i] * alpha; } for (; i < DMAX.loopBound(n); i += DMAX.length()) { DoubleVector vx = DoubleVector.fromArray(DMAX, x, i); vx.lanewise(VectorOperators.MUL, alpha) .intoArray(x, i); } for (; i < n; i += 1) { x[i] = x[i] * alpha; } ``` I hope this help in the further development of the Vector API, and I welcome any feedback on the vectorizedblas project. Thank you, Ludovic [1] https://github.com/luhenry/vectorizedblas [2] https://github.com/luhenry/vectorizedblas/tree/master/benchmarks [3] https://github.com/apache/spark/pull/30810 [4] https://gist.github.com/luhenry/2cda93cb40f3edef76cb499c896608a9 From samuel.audet at gmail.com Mon Jan 4 14:52:53 2021 From: samuel.audet at gmail.com (Samuel Audet) Date: Mon, 4 Jan 2021 23:52:53 +0900 Subject: BLAS and Vector API In-Reply-To: References: <7264552B-57D9-40CD-92CA-7BBFA7FD7324@ORACLE.COM> Message-ID: Hi, Ludovic, On 1/4/21 10:48 PM, Ludovic Henry wrote: > I?ll also explore using the Foreign Linker API to wrap the OpenBLAS library without going through JNI. I?m curious whether it?s going to lead to performance improvements. No, not yet, it won't, since that still uses JNI: https://github.com/microsoft/onnxruntime/pull/4329#issuecomment-673848183 Samuel From maurizio.cimadamore at oracle.com Mon Jan 4 16:11:37 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 4 Jan 2021 16:11:37 +0000 Subject: [foreign-memaccess] musing on the memory access API Message-ID: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> Hi, now that the foreign memory access API has been around for an year, I think it?s time we start asking ourselves if this is the API we want, and how comfortable we are in finalizing it. Overall, I think that there are some aspects of the memory access API which are definitively a success: * memory layouts, and the way they connect with dereference var handles is definitively a success story, and now that we have added even more var handle combinators, it is really possible to get crazy with expressing exotic memory access * the new shape of memory access var handle as (MemorySegment, long)->X makes a lot of sense, and it allowed us to greatly simplify and unify the implementation (as well as to give users a cheap way to do unsafe dereference of random addresses, which they sometimes want) * the distinction between MemorySegment and MemoryAddress is largely beneficial - and, when explained, it?s pretty obvious where the difference come from: to do dereference we need to attach bounds (of various kinds) to a raw pointer - after we do that, dereference operations are safe. I think this model makes it very natural to think about which places in your program might introduce invalid assumptions, especially when dealing with native code I also think that there are aspects of the API where it?s less clear we made the right call: * slicing behavior: closing the slice closes everything. This was mostly a forced move: there are basically two use cases for slices: sometimes you slice soon after creation (e.g. to align), in which case you want the new slice to have same properties as the old one (e.g. deallocate on close). There are other cases where you are just creating a dumb sub-view, and you don?t really want to expose close() on those. This led to the creation of the ?access modes? mechanism: each segment has some access modes - if the client wants to prevent calls to MemorySegment::close it can do so by /restricting/ the segment, and removing the corresponding CLOSE access mode (e.g. before the segment is shared with other clients). While this allows us to express all the use cases we care about, it seems also a tad convoluted. Moreover, the client wrapping a MemorySegment inside a TWR is always unsure as to whether the segment will support close() or not. * not all segments are created equal: some memory segments are just dumb views over memory that has been allocated somewhere else - e.g. a Java heap array or a byte buffer. In such cases, it seems odd to feature a close() operation (and I might add even having thread-confinement, given the original API did not feature that to begin with). Sidebar: on numerous occasions it has been suggested to solve issues such as the one above by allowing close() to be a no-op in certain cases. While that is doable, I?ve never been too conviced about it, mainly because of this: |MemorySegment s = ... s.close(); assertFalse(s.isAlive()); // I expect this to never fail!!!! | In other words, a world where some segments are stateful and respond accordingly to close() requests and some are not seems very confusing to me. * the various operations for managing confinement of segments is rapidly turning into an distraction. For instance, recently, the Netty guys have created a port on top of the memory access API, since we have added support for shared segment. Their use of shared segment was a bit strange, in the sense that, while they allocated a segment in shared mode, they wanted to be able to confine the segment near where the segment is used, to catch potential mistakes. To do so, they resorted to calling handoff on a shared segment repeatedly, which performance-wise doesn?t work. Closing a shared segment (even if just for handing it off to some other thread) is a very expensive operation which needs to be used carefully - but the Netty developers were not aware of the trade-off (despite it being described in the javadoc - but that?s understandable, as it?s pretty subtle). Of course, if they just worked with a shared segment, and avoided handoff, things would have worked just fine (closing shared segments is perfectly fine for long lived segments). In other words, this is a case where, by featuring many different modes of interacting with segments (confined, shared) as well as ways to go back and forth between these states, we create extra complexity, both for ourselves and for the user. I?ve been thinking quite a bit about these issues, trying to find a more stable position in the design space. While I can?t claim to have found a 100% solution, I think I might be onto something worth exploring. On a recent re-read of the C# Span API doc [1], it dawned on me that there is a sibling abstraction to the Span abstraction in C#, namely Memory [2]. While some of the reasons behind the Span vs. Memory split have to do with stack vs. heap allocation (e.g. Span can only be used for local vars, not fields), and so not directly related to our design choices, I think some of the concepts of the C# solution hinted at a possibly better way to stack the problem of memory access. We have known at least for the last 6 months that a MemorySegment is playing multiple roles at once: a MS is both a memory allocation (e.g. result of a malloc, or mmap), and a /view/ over said memory. This duplicity creates most of the problem listed above, as it?s clear that, while close() is a method that should belong to an allocation abstraction, it is less clear that close() should also belong to a view-like abstraction. We have tried, in the past, to come up with a 3-pronged design, where we had not only MemorySegment and MemoryAddress, but also a MemoryResource abstraction from which /all/ segments were derived. These experiments have failed, pretty much all for the same reason: the return on complexity seemed thin. Recently, I found myself going back slightly to that approach, although in a quite different way. Here?s the basic idea I?m playing with: * introduce a new abstraction: AllocationHandle (name TBD) - this wraps an allocation, whether generated by malloc, mmap, or some future allocator TBD (Jim?s QBA?) * We provide many AllocationHandle factories: { confined, shared } x { cleaner, no cleaner } * AllocationHandle is thin: just has a way to get size, alignment and a method to release memory - e.g. close(); in other words, AllocationHandle <: AutoCloseable * crucially, an AllocationHandle has a way to obtain a segment /view/ out of it (MemorySegment) * a MemorySegment is the same thing it used to be, /minus/ the terminal operations (|close|, |handoff|, ? methods) * we still keep all the factories for constructing MemorySegments out of heap arrays and byte buffer * there?s no way to go from a MemorySegment back to an AllocationHandle This approach solves quite few issues: * Since MemorySegment does not have a close() method, we don?t have to worry about specifying what close() does in problematic cases (slices, on-heap, etc.) * There is an asymmetry between the actor which does an allocation (the holder of the AllocationHandle) and the rest of the world, which just deals with (non-closeable) MemorySegment - this seems to reflect how memory is allocated in the real world (one actor allocates, then shares a pointer to allocated memory to some other actors) * AllocationHandles come in many shapes and form, but instead of having dynamic state transitions, users will have to choose the flavor they like ahead of time, knowing pros and cons of each * This approach removes the need for access modes and restricted views - we probably still need a readOnly property in segments to support mapped memory, but that?s pretty much it Of course there are also things that can be perceived as disadvantages: * Conciseness. Code dealing in native memory segments will have to first obtain an allocation handle, then obtaining a segment. For instance, code like this: |try (MemorySegment s = MemorySegment.allocateNative(layout)) { ... MemoryAccess.getIntAtOffset(s, 42); ... } | Will become: |try (AllocationHandle ah = AllocationHandle.allocateNativeConfined(layout)) { MemorySegment s = ah.asSegment(); ... MemoryAccess.getIntAtOffset(s, 42); ... } | * It would be no longer possible for the linker API to just allocate memory and return a segment based on that memory - since now the user cannot free that memory anymore (no close method in segments). We could solve this either by having the linker API return allocation handle or, better, by having the linker API accepting a NativeScope where allocation should occur (since that?s how clients are likely to interact with the API point anyway). In fact, we have already considered doing something similar in the past (doing a malloc for each struct returned by value is a performance killer in certain contexts). * At least in this form, we give up state transitions between confined and shared. Users will have to pick in which side of the world they want to play with and stick with it. For simple lexically scoped use cases, confined is fine and efficient - in more complex cases, shared might be unavoidable. While handing off an entire AllocationHandle is totally doable, doing so (e.g. killing an existing AH instance to return a new AH instance confined on a different thread) will also kill all segments derived from the original AH. So it?s not clear such an API would be very useful: to be able to do an handoff, clients will need to pass around an AllocationHandle, not a MemorySegment (like now). Note that adding handoff operation directly on MemorySegment, under this design, is not feasible: handoff is a terminal operation, so we would allow clients to do nonsensical things like: 1. obtain a segment 2. create two identical segments via slicing 3. set the owner of the two segments to two different threads For this reason, it makes sense to think about ownership as a property on the /allocation/, not on the /view/. * While the impact of these changes on client using memory access API directly is somewhat biggie (no TWR on heap/buffer segments, need to go through an AllocationHandle for native stuff), clients of extracted API are largely unchanged, thanks to the fact that most of such clients use NativeScope anyway to abstract over how segments are allocated. Any thoughts? I think the first question is as to whether we?re ok with the loss in conciseness, and with the addition of a new (albeit very simple) abstraction. [1] - https://docs.microsoft.com/en-us/dotnet/api/system.span-1?view=net-5.0 [2] - https://docs.microsoft.com/en-us/dotnet/standard/memory-and-spans/memory-t-usage-guidelines ? From maurizio.cimadamore at oracle.com Mon Jan 4 16:22:23 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 4 Jan 2021 16:22:23 +0000 Subject: BLAS and Vector API In-Reply-To: References: <7264552B-57D9-40CD-92CA-7BBFA7FD7324@ORACLE.COM> Message-ID: <73bdce09-f9ca-896a-c68e-d39705cf846c@oracle.com> On 04/01/2021 14:52, Samuel Audet wrote: > Hi, Ludovic, > > On 1/4/21 10:48 PM, Ludovic Henry wrote: >> I?ll also explore using the Foreign Linker API to wrap the OpenBLAS >> library without going through JNI. I?m curious whether it?s going to >> lead to performance improvements. > > No, not yet, it won't, since that still uses JNI: > https://github.com/microsoft/onnxruntime/pull/4329#issuecomment-673848183 Where did you get this information from? The comment you quote shows my reply and then you somehow (erroneously) inferring that the linker API is based on JNI. The Foreign Linker API support has very little to do with JNI support. Of course, since some of the stuff the VM has to do to go from Java to native are the same, performances might not be too different (unless state transitions are removed, which is possible with the linker API). Maurizio > > Samuel From youngty1997 at gmail.com Mon Jan 4 16:58:50 2021 From: youngty1997 at gmail.com (Ty Young) Date: Mon, 4 Jan 2021 10:58:50 -0600 Subject: Panama source code fails to compile In-Reply-To: <30df2329-2332-1b6f-bc5f-6fb40974ca60@oracle.com> References: <5ea52f78-f853-57df-7c7f-fa299b091c55@gmail.com> <409652537.261382.1609190287324.JavaMail.zimbra@u-pem.fr> <9a74ba5e-523a-e96d-4e60-8d66b6e0516f@gmail.com> <9045aa0c-5454-3b18-13a1-b39252a29622@gmail.com> <30df2329-2332-1b6f-bc5f-6fb40974ca60@oracle.com> Message-ID: On 1/4/21 5:23 AM, Maurizio Cimadamore wrote: > As usual, I find the tone of some of these emails way over the top. > > We do have CI, both internally and externally. I don't think the > GitHub test was triggered during the merge, so the external CI did not > run in this case. Our internal CI ran as usual and did not report any > error - likely, as Remi said, because of a difference in the compiler > being used. FWIW the changes were never merged into foreign-jextract(master) as far as I can tell, only foreign-memaccess+abi. The point I was making about the CLI is so people outside of Oracle know what's working or isn't. This time around it was a bad merge that introduced a duplicate function, which is the most trivial of trivial fixes, but I've in the past seen wrong/non-existant constructors called in Java code before too, in which case waiting and letting JDK developers fix it is best I think. > > I confirm that the problem can be reproduced on my system also - which > also sports a relatively recent GCC compiler (9.3.0). > >> Just a little annoyed, sorry. I try to always use the latest builds >> so I don't have to constantly make large code changes, although there >> hasn't been many changes lately, which is odd. Is Panama's API nearly >> complete? What's the state of Panama at this point? > > That's why we have binary snapshots :-) > > We just released one before Christmas: > > https://jdk.java.net/panama/ > > As discussed in a related thread, this is compatible with the API in > 16, so you can use jextract from there and then just use a 16 EA. > > While this EA does not contain few jextract-related fixes, it is > recommended for most usages compared to the latest repo bits - > especially because the latest bits are unusable at least on IntelliJ > (changes to support strong encapsulation break the IDE which does not, > as of yet, officially supports Java 16). We will release another > Panama EA when the IDE situation has been cleared. Those builds are generally too old and the changes from one to the next can be massive. For the longest time it pointed to the old Pointer API despite it being long abandoned. Things only happen to be better now because Panama hasn't received major changes in months. There are more IDEs out there than Intellij. I use Netbeans which, while increasingly buggy as time goes on, does mostly work and was not affected by the changes you mention. It handles JDK builds built-fron-source surprisingly well actually, so long as you use those builds as your boot JDK and Dr. Deprecator decided to take a vacation for the JDK development cycle. > > As for the state of the API, as the API is incubating we consider it > to be our best shot _so far_, but things might still change given > targeted feedback. Of course, the more we are iterating, the less > substantial API changes you are seeing. I did a casual look over some of the code and there are a number of mostly minor cleanups and API modifications that could be made IMO, although only one so far that I've seen could probably be called major: - AbstractLayout could be modified to use generics so that all layout types no longer need to override standard MemoryLayout withers. The Javadoc bug that prevented this from being done has long since been fixed(JDK-8224052) in JDK 14. I've made the changes already here: https://github.com/BlueGoliath/panama-foreign/commit/186ef819cd6e0da7d075c16926322a188f5846d8 Although I'm waiting on my OCA to be verified(does it need to be?) before I do anymore pull requests other than: https://github.com/openjdk/panama-foreign/pull/427 Which I can remove if someone needs me to. - Padding layout should probably be a subclass of ValueLayout and just override methods as needed. Having every memory layout have a isPadding() method doesn't make much sense. The PaddingLayout class can then be moved to an internal package as there is no way to create an instance outside of ofPaddingBits as an API user. The same could be done for AbstractLayout. - GroupLayout should probably be split into StructLayout and UnionLayout. This is the biggest change, but it simplifies the code, provides better clarity on what's actually being represented, and allows for future struct/union specific operations to be added without adding a bunch of if(!isUnion) throw new UnsupportedOperationException(); type code. This is just from me skimming the surface API code after submitting the OCA, there are probably more changes although I doubt there is anything major. > > Cheers > Maurizio > > > On 29/12/2020 21:12, Ty Young wrote: >> Yes, mostly. Things happen, especially on holidays when everyone has >> things to do and places to be. I was going to wait until after the >> new year to bring it up, but I had seen JDK developers replying to >> things so I figured they were back. >> >> >> A proper CI could have at least warned that there is an issue, just >> like other previous issues. Having newer JDK builds would be a >> benefit to projects like Panama as it reduces the hurdle to try out >> recent versions, especially those on Windows. Again, probably >> screaming into the void on the CI thing. >> >> >> On 12/29/20 5:21 AM, Samuel Audet wrote: >>> Hi, >>> >>> I think the point is that this could have been prevented with proper >>> CI. Since the repos are now on GitHub, OpenJDK could easily benefit >>> from GitHub Actions... >>> >>> Samuel >>> >>> On Tue, Dec 29, 2020, 16:39 David Holmes >> > wrote: >>> >>> ??? On 29/12/2020 1:06 pm, Ty Young wrote: >>> ??? > >>> ??? > On 12/28/20 3:18 PM, Remi Forax wrote: >>> ??? >> ----- Mail original ----- >>> ??? >>> De: "Ty Young" >> ??? > >>> ??? >>> ?: "panama-dev at openjdk.java.net >>> ??? '" >>> ??? > >>> ??? >>> Envoy?: Lundi 28 D?cembre 2020 22:06:58 >>> ??? >>> Objet: Panama source code fails to compile >>> ??? >>> Just an FYI, the Panama source code have been broken since >>> before >>> ??? >>> Christmas with this error: >>> ??? >>> >>> ??? >>> >>> ??? >>> panama-foreign/src/hotspot/share/oops/methodData.cpp:1616:6: >>> ??? error: >>> ??? >>> redefinition of 'static bool >>> ??? MethodData::profile_memory_access(const >>> ??? >>> methodHandle&, int)' >>> ??? >>> ??1616 | bool MethodData::profile_memory_access(const >>> ??? methodHandle& m, >>> ??? >>> int bci) { >>> ??? >>> ?????? |????? ^~~~~~~~~~ >>> ??? >>> >>> /run/media/ty/Windows_Linux_Shared/OpenJDK/panama-foreign/src/hotspot/share/oops/methodData.cpp:1604:6: >>> >>> >>> ??? >>> >>> ??? >>> note: 'static bool MethodData::profile_memory_access(const >>> ??? >>> methodHandle&, int)' previously defined here >>> ??? >>> ??1604 | bool MethodData::profile_memory_access(const >>> ??? methodHandle& m, >>> ??? >>> int bci) { >>> ??? >>> ?????? | >>> ??? >>> >>> ??? >>> >>> ??? >>> I tried building using the usual `bash configure >>> ??? >>> --disable-warnings-as-errors` and `make images` on (Arch) >>> ??? Linux. I am >>> ??? >>> able to compile the standard JDK from source just fine. >>> ??? >>> >>> ??? >>> >>> ??? >>> I know I'm probably (metaphorically) screaming into the void >>> ??? here but... >>> ??? >>> people often have data caps and JDK source code is *A LOT*. >>> Not to >>> ??? >>> mention the CPU and memory requirements needed to compile it >>> in a >>> ??? >>> reasonable amount of time, which are massive. I suggested >>> ??? months ago on >>> ??? >>> the skara-dev list on having build succeeded/failed badges >>> and/or >>> ??? >>> automatic JDK builds but apparently no one is interested >>> ??? because it >>> ??? >>> hasn't been added. Is making sure your code compiles & runs >>> ??? before you >>> ??? >>> push it not a requirement for JDK developers or something? I >>> ??? understand >>> ??? >>> it was Christmas but this has happened a few times now. >>> ??? >> Usually for this kind of error, it's because you are compiling >>> ??? with a >>> ??? >> c++ compiler more recent than the one used by the CI, >>> ??? >> so the bug flies under the radar. >>> ??? > >>> ??? > >>> ??? > There is clearly a duplicate declaration: >>> ??? > >>> ??? > >>> ??? > >>> https://github.com/openjdk/panama-foreign/blob/5a8d47fd226708e46f56ec82294e9c786f6850c1/src/hotspot/share/oops/methodData.cpp#L1604 >>> >>> >>> >>> >>> ??? > >>> ??? > >>> ??? > >>> ??? > and >>> ??? > >>> ??? > >>> ??? > >>> https://github.com/openjdk/panama-foreign/blob/5a8d47fd226708e46f56ec82294e9c786f6850c1/src/hotspot/share/oops/methodData.cpp#L1616 >>> >>> >>> >>> >>> ??? > >>> ??? > >>> ??? > >>> ??? > are the same. Git blame shows that the duplicate was added 17 >>> ??? days ago: >>> ??? > >>> ??? > >>> ??? > >>> https://github.com/openjdk/panama-foreign/blame/5a8d47fd226708e46f56ec82294e9c786f6850c1/src/hotspot/share/oops/methodData.cpp#L1616 >>> >>> >>> >>> >>> >>> ??? I think I see what happened. >>> >>> ??? JDK-8257692 was fixed in the panama-foreign repo in >>> foreign-jextract >>> ??? branch. >>> >>> ??? JDK-8258242 was fixed in the mainline JDK and contained some of >>> ??? the same >>> ??? code changes. >>> >>> ??? A few days before Christmas there was an auto-merge between >>> ??? panama-foreign and mainline JDK, and that is when the duplicate >>> code >>> ??? chunk has arisen. >>> >>> ??? David >>> ??? ----- >>> >>> ??? > >>> ??? > >>> ??? > and removing the duplicate allows the JDK to build correctly. >>> ??? > >>> ??? > >>> ??? > So, no, this has nothing to do with the distro or the compiler I >>> ??? use. >>> ??? > I've already been through this blame game nonsense on swing-dev >>> ??? with JDK >>> ??? > developers when they broke literally every Swing application >>> ??? that used >>> ??? > GTK L&F on Arch Linux, lets not do it again, please. >>> ??? > >>> ??? > >>> ??? >> >>> ??? >>> >>> ??? >>> Just a little annoyed, sorry. I try to always use the latest >>> ??? builds so I >>> ??? >>> don't have to constantly make large code changes, although >>> ??? there hasn't >>> ??? >>> been many changes lately, which is odd. Is Panama's API nearly >>> ??? complete? >>> ??? >>> What's the state of Panama at this point? >>> ??? >> R?mi >>> From ach at activeviam.com Mon Jan 4 17:29:39 2021 From: ach at activeviam.com (Antoine Chambille) Date: Mon, 4 Jan 2021 18:29:39 +0100 Subject: Foreign memory access hot loop benchmark In-Reply-To: <72ab9217-c638-88b9-b8fc-9ec91fab4cf6@oracle.com> References: <0d33e2cc-1585-0fc2-8a9f-231f6c888b69@oracle.com> <3c26c12c-23e0-a99f-03cd-afd6996c6478@oracle.com> <7ca53e08-3b3d-0db3-0493-1ecb0e44b79d@oracle.com> <0c431324-68b5-c0b0-3ced-5119ab51def9@oracle.com> <72ab9217-c638-88b9-b8fc-9ec91fab4cf6@oracle.com> Message-ID: Thank you Maurizio, for looking into this. This is a good find, I've just updated and rebuilt the panama JDK, I confirm that the big slowdown with manually unrolled loop and memory handles has disappeared for the AddBenchmark.unrolledMHI_v2 benchmark. But it is apparently still present in one last case: AddBenchmark.unrolledMHI Maybe another missing annotation? Benchmark Mode Cnt Score Error Units AddBenchmark.scalarArray thrpt 5 5270072.806 ? 43618.821 ops/s AddBenchmark.scalarArrayHandle thrpt 5 5155791.142 ? 122147.967 ops/s AddBenchmark.scalarMHI thrpt 5 2215595.625 ? 27044.786 ops/s AddBenchmark.scalarMHI_v2 thrpt 5 2165838.557 ? 48477.364 ops/s AddBenchmark.scalarUnsafe thrpt 5 2057853.572 ? 21064.385 ops/s AddBenchmark.unrolledArray thrpt 5 6346056.064 ? 304425.251 ops/s AddBenchmark.unrolledArrayHandle thrpt 5 1991324.025 ? 39434.066 ops/s AddBenchmark.unrolledMHI thrpt 5 206541.946 ? 4031.057 ops/s AddBenchmark.unrolledMHI_v2 thrpt 5 2240957.905 ? 24239.357 ops/s AddBenchmark.unrolledUnsafe thrpt 5 2185038.207 ? 27611.150 ops/s benchmark source code: https://github.com/chamb/panama-benchmarks/blob/master/memory/src/main/java/com/activeviam/test/AddBenchmark.java // CODE OF THE REMAINING SLOW BENCHMARK static final VarHandle MHI = MemoryLayout.ofSequence(SIZE, MemoryLayouts.JAVA_DOUBLE) .varHandle(double.class, MemoryLayout.PathElement.sequenceElement()); @Benchmark public void unrolledMHI(Data state) { final MemorySegment is = state.inputSegment; final MemorySegment os = state.outputSegment; for(int i = 0; i < SIZE; i+=4) { MHI.set(os, (long) (i), (double) MHI.get(is, (long) (i)) + (double) MHI.get(os, (long) (i))); MHI.set(os, (long) (i+1), (double) MHI.get(is, (long) (i+1)) + (double) MHI.get(os, (long) (i+1))); MHI.set(os, (long) (i+2), (double) MHI.get(is, (long) (i+2)) + (double) MHI.get(os, (long) (i+2))); MHI.set(os, (long) (i+3), (double) MHI.get(is, (long) (i+3)) + (double) MHI.get(os, (long) (i+3))); } } Best, -Antoine On Wed, Nov 25, 2020 at 1:42 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > I did some investigation, and, during the problematic benchmark we were > hitting some inline thresholds, as evidenced by `-XX:PrintInlining`: > > @ 92 jdk.incubator.foreign.MemoryAccess::getLongAtIndex (12 bytes) > NodeCountInliningCutoff > @ 96 jdk.incubator.foreign.MemoryAccess::setLongAtIndex (13 bytes) > NodeCountInliningCutoff > @ 111 jdk.incubator.foreign.MemoryAccess::getLongAtIndex (12 bytes) > NodeCountInliningCutoff > @ 120 jdk.incubator.foreign.MemoryAccess::getLongAtIndex (12 bytes) > NodeCountInliningCutoff > @ 124 jdk.incubator.foreign.MemoryAccess::setLongAtIndex (13 bytes) > NodeCountInliningCutoff > > The problem is that the static accessors in MemoryAccess are lacking a > @ForceInline annotation. This is being addressed here: > > https://github.com/openjdk/panama-foreign/pull/401 > > Thanks > Maurizio > > > On 25/11/2020 11:51, Maurizio Cimadamore wrote: > > > > On 24/11/2020 11:19, Antoine Chambille wrote: > >> If I look at the slow benchmark in detail, I observe that the first > >> two warmups run at the expected speed, but then it slows down 20x. > >> Very strange, it's almost as if some JIT optimization is suddenly > >> turned off: > > > > This is something I've observed in the past as well, in some cases, > > when playing with VH. > > > > We'll take a look. > > > > Thanks > > Maurizio > > > From ach at activeviam.com Mon Jan 4 17:31:55 2021 From: ach at activeviam.com (Antoine Chambille) Date: Mon, 4 Jan 2021 18:31:55 +0100 Subject: Foreign memory access hot loop benchmark In-Reply-To: References: <0d33e2cc-1585-0fc2-8a9f-231f6c888b69@oracle.com> <3c26c12c-23e0-a99f-03cd-afd6996c6478@oracle.com> <7ca53e08-3b3d-0db3-0493-1ecb0e44b79d@oracle.com> <0c431324-68b5-c0b0-3ced-5119ab51def9@oracle.com> <72ab9217-c638-88b9-b8fc-9ec91fab4cf6@oracle.com> Message-ID: *(using fixed width font ;)* Thank you Maurizio, for looking into this. This is a good find, I've just updated and rebuilt the Panama JDK, I confirm that the big slowdown with manually unrolled loop and memory handles has disappeared for the AddBenchmark.unrolledMHI_v2 benchmark. But it is apparently still present in one last case: AddBenchmark.unrolledMHI Maybe another missing annotation? Benchmark Mode Cnt Score Error Units AddBenchmark.scalarArray thrpt 5 5270072.806 ? 43618.821 ops/s AddBenchmark.scalarArrayHandle thrpt 5 5155791.142 ? 122147.967 ops/s AddBenchmark.scalarMHI thrpt 5 2215595.625 ? 27044.786 ops/s AddBenchmark.scalarMHI_v2 thrpt 5 2165838.557 ? 48477.364 ops/s AddBenchmark.scalarUnsafe thrpt 5 2057853.572 ? 21064.385 ops/s AddBenchmark.unrolledArray thrpt 5 6346056.064 ? 304425.251 ops/s AddBenchmark.unrolledArrayHandle thrpt 5 1991324.025 ? 39434.066 ops/s AddBenchmark.unrolledMHI thrpt 5 206541.946 ? 4031.057 ops/s AddBenchmark.unrolledMHI_v2 thrpt 5 2240957.905 ? 24239.357 ops/s AddBenchmark.unrolledUnsafe thrpt 5 2185038.207 ? 27611.150 ops/s benchmark source code: https://github.com/chamb/panama-benchmarks/blob/master/memory/src/main/java/com/activeviam/test/AddBenchmark.java // CODE OF THE REMAINING SLOW BENCHMARK static final VarHandle MHI = MemoryLayout.ofSequence(SIZE, MemoryLayouts.JAVA_DOUBLE) .varHandle(double.class, MemoryLayout.PathElement.sequenceElement()); @Benchmark public void unrolledMHI(Data state) { final MemorySegment is = state.inputSegment; final MemorySegment os = state.outputSegment; for(int i = 0; i < SIZE; i+=4) { MHI.set(os, (long) (i), (double) MHI.get(is, (long) (i)) + (double) MHI.get(os, (long) (i))); MHI.set(os, (long) (i+1), (double) MHI.get(is, (long) (i+1)) + (double) MHI.get(os, (long) (i+1))); MHI.set(os, (long) (i+2), (double) MHI.get(is, (long) (i+2)) + (double) MHI.get(os, (long) (i+2))); MHI.set(os, (long) (i+3), (double) MHI.get(is, (long) (i+3)) + (double) MHI.get(os, (long) (i+3))); } } Best, -Antoine On Mon, Jan 4, 2021 at 6:29 PM Antoine Chambille wrote: > Thank you Maurizio, for looking into this. > > This is a good find, I've just updated and rebuilt the panama JDK, I > confirm that the big slowdown with manually unrolled loop and memory > handles has disappeared for the AddBenchmark.unrolledMHI_v2 benchmark. But > it is apparently still present in one last case: AddBenchmark.unrolledMHI > > Maybe another missing annotation? > > Benchmark Mode Cnt Score Error > Units > AddBenchmark.scalarArray thrpt 5 5270072.806 ? 43618.821 > ops/s > AddBenchmark.scalarArrayHandle thrpt 5 5155791.142 ? 122147.967 > ops/s > AddBenchmark.scalarMHI thrpt 5 2215595.625 ? 27044.786 > ops/s > AddBenchmark.scalarMHI_v2 thrpt 5 2165838.557 ? 48477.364 > ops/s > AddBenchmark.scalarUnsafe thrpt 5 2057853.572 ? 21064.385 > ops/s > AddBenchmark.unrolledArray thrpt 5 6346056.064 ? 304425.251 > ops/s > AddBenchmark.unrolledArrayHandle thrpt 5 1991324.025 ? 39434.066 > ops/s > AddBenchmark.unrolledMHI thrpt 5 206541.946 ? 4031.057 > ops/s > AddBenchmark.unrolledMHI_v2 thrpt 5 2240957.905 ? 24239.357 > ops/s > AddBenchmark.unrolledUnsafe thrpt 5 2185038.207 ? 27611.150 > ops/s > > > benchmark source code: > > https://github.com/chamb/panama-benchmarks/blob/master/memory/src/main/java/com/activeviam/test/AddBenchmark.java > > > // CODE OF THE REMAINING SLOW BENCHMARK > static final VarHandle MHI = MemoryLayout.ofSequence(SIZE, > MemoryLayouts.JAVA_DOUBLE) > .varHandle(double.class, > MemoryLayout.PathElement.sequenceElement()); > > @Benchmark > public void unrolledMHI(Data state) { > final MemorySegment is = state.inputSegment; > final MemorySegment os = state.outputSegment; > > for(int i = 0; i < SIZE; i+=4) { > MHI.set(os, (long) (i), (double) MHI.get(is, (long) (i)) + > (double) MHI.get(os, (long) (i))); > MHI.set(os, (long) (i+1), (double) MHI.get(is, (long) (i+1)) + > (double) MHI.get(os, (long) (i+1))); > MHI.set(os, (long) (i+2), (double) MHI.get(is, (long) (i+2)) + > (double) MHI.get(os, (long) (i+2))); > MHI.set(os, (long) (i+3), (double) MHI.get(is, (long) (i+3)) + > (double) MHI.get(os, (long) (i+3))); > } > } > > > > Best, > -Antoine > > > > > > > > On Wed, Nov 25, 2020 at 1:42 PM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> I did some investigation, and, during the problematic benchmark we were >> hitting some inline thresholds, as evidenced by `-XX:PrintInlining`: >> >> @ 92 jdk.incubator.foreign.MemoryAccess::getLongAtIndex (12 bytes) >> NodeCountInliningCutoff >> @ 96 jdk.incubator.foreign.MemoryAccess::setLongAtIndex (13 bytes) >> NodeCountInliningCutoff >> @ 111 jdk.incubator.foreign.MemoryAccess::getLongAtIndex (12 bytes) >> NodeCountInliningCutoff >> @ 120 jdk.incubator.foreign.MemoryAccess::getLongAtIndex (12 bytes) >> NodeCountInliningCutoff >> @ 124 jdk.incubator.foreign.MemoryAccess::setLongAtIndex (13 bytes) >> NodeCountInliningCutoff >> >> The problem is that the static accessors in MemoryAccess are lacking a >> @ForceInline annotation. This is being addressed here: >> >> https://github.com/openjdk/panama-foreign/pull/401 >> >> Thanks >> Maurizio >> >> >> On 25/11/2020 11:51, Maurizio Cimadamore wrote: >> > >> > On 24/11/2020 11:19, Antoine Chambille wrote: >> >> If I look at the slow benchmark in detail, I observe that the first >> >> two warmups run at the expected speed, but then it slows down 20x. >> >> Very strange, it's almost as if some JIT optimization is suddenly >> >> turned off: >> > >> > This is something I've observed in the past as well, in some cases, >> > when playing with VH. >> > >> > We'll take a look. >> > >> > Thanks >> > Maurizio >> > >> > > From maurizio.cimadamore at oracle.com Mon Jan 4 18:25:37 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 4 Jan 2021 18:25:37 +0000 Subject: [foreign-memaccess] musing on the memory access API In-Reply-To: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> References: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> Message-ID: <2aa88b7d-f18e-fa84-6432-c1181674c734@oracle.com> Apologizes - this email was not meant for public consumption (as the somewhat informal tone suggests). That said, since there's nothing in here which has not been discussed in this mailing list in the past, in one way or another, we might as well discuss it :-) On 04/01/2021 16:11, Maurizio Cimadamore wrote: > Hi, > now that the foreign memory access API has been around for an year, I > think it?s time we start asking ourselves if this is the API we want, > and how comfortable we are in finalizing it. Overall, I think that > there are some aspects of the memory access API which are definitively > a success: > > ?* > > ?? memory layouts, and the way they connect with dereference var > ?? handles is definitively a success story, and now that we have added > ?? even more var handle combinators, it is really possible to get crazy > ?? with expressing exotic memory access > > ?* > > ?? the new shape of memory access var handle as (MemorySegment, > ?? long)->X makes a lot of sense, and it allowed us to greatly simplify > ?? and unify the implementation (as well as to give users a cheap way > ?? to do unsafe dereference of random addresses, which they sometimes > want) > > ?* > > ?? the distinction between MemorySegment and MemoryAddress is largely > ?? beneficial - and, when explained, it?s pretty obvious where the > ?? difference come from: to do dereference we need to attach bounds (of > ?? various kinds) to a raw pointer - after we do that, dereference > ?? operations are safe. I think this model makes it very natural to > ?? think about which places in your program might introduce invalid > ?? assumptions, especially when dealing with native code > > I also think that there are aspects of the API where it?s less clear > we made the right call: > > ?* > > ?? slicing behavior: closing the slice closes everything. This was > ?? mostly a forced move: there are basically two use cases for slices: > ?? sometimes you slice soon after creation (e.g. to align), in which > ?? case you want the new slice to have same properties as the old one > ?? (e.g. deallocate on close). There are other cases where you are just > ?? creating a dumb sub-view, and you don?t really want to expose > ?? close() on those. This led to the creation of the ?access modes? > ?? mechanism: each segment has some access modes - if the client wants > ?? to prevent calls to MemorySegment::close it can do so by > ?? /restricting/ the segment, and removing the corresponding CLOSE > ?? access mode (e.g. before the segment is shared with other clients). > ?? While this allows us to express all the use cases we care about, it > ?? seems also a tad convoluted. Moreover, the client wrapping a > ?? MemorySegment inside a TWR is always unsure as to whether the > ?? segment will support close() or not. > > ?* > > ?? not all segments are created equal: some memory segments are just > ?? dumb views over memory that has been allocated somewhere else - e.g. > ?? a Java heap array or a byte buffer. In such cases, it seems odd to > ?? feature a close() operation (and I might add even having > ?? thread-confinement, given the original API did not feature that to > ?? begin with). > > Sidebar: on numerous occasions it has been suggested to solve issues > such as the one above by allowing close() to be a no-op in certain > cases. While that is doable, I?ve never been too conviced about it, > mainly because of this: > > |MemorySegment s = ... s.close(); assertFalse(s.isAlive()); // I > expect this to never fail!!!! | > > In other words, a world where some segments are stateful and respond > accordingly to close() requests and some are not seems very confusing > to me. > > ?* the various operations for managing confinement of segments is > ?? rapidly turning into an distraction. For instance, recently, the > ?? Netty guys have created a port on top of the memory access API, > ?? since we have added support for shared segment. Their use of shared > ?? segment was a bit strange, in the sense that, while they allocated a > ?? segment in shared mode, they wanted to be able to confine the > ?? segment near where the segment is used, to catch potential mistakes. > ?? To do so, they resorted to calling handoff on a shared segment > ?? repeatedly, which performance-wise doesn?t work. Closing a shared > ?? segment (even if just for handing it off to some other thread) is a > ?? very expensive operation which needs to be used carefully - but the > ?? Netty developers were not aware of the trade-off (despite it being > ?? described in the javadoc - but that?s understandable, as it?s pretty > ?? subtle). Of course, if they just worked with a shared segment, and > ?? avoided handoff, things would have worked just fine (closing shared > ?? segments is perfectly fine for long lived segments). In other words, > ?? this is a case where, by featuring many different modes of > ?? interacting with segments (confined, shared) as well as ways to go > ?? back and forth between these states, we create extra complexity, > ?? both for ourselves and for the user. > > I?ve been thinking quite a bit about these issues, trying to find a > more stable position in the design space. While I can?t claim to have > found a 100% solution, I think I might be onto something worth > exploring. On a recent re-read of the C# Span API doc [1], it dawned > on me that there is a sibling abstraction to the Span abstraction in > C#, namely Memory [2]. While some of the reasons behind the Span vs. > Memory split have to do with stack vs. heap allocation (e.g. Span can > only be used for local vars, not fields), and so not directly related > to our design choices, I think some of the concepts of the C# solution > hinted at a possibly better way to stack the problem of memory access. > > We have known at least for the last 6 months that a MemorySegment is > playing multiple roles at once: a MS is both a memory allocation (e.g. > result of a malloc, or mmap), and a /view/ over said memory. This > duplicity creates most of the problem listed above, as it?s clear > that, while close() is a method that should belong to an allocation > abstraction, it is less clear that close() should also belong to a > view-like abstraction. We have tried, in the past, to come up with a > 3-pronged design, where we had not only MemorySegment and > MemoryAddress, but also a MemoryResource abstraction from which /all/ > segments were derived. These experiments have failed, pretty much all > for the same reason: the return on complexity seemed thin. > > Recently, I found myself going back slightly to that approach, > although in a quite different way. Here?s the basic idea I?m playing > with: > > ?* introduce a new abstraction: AllocationHandle (name TBD) - this > ?? wraps an allocation, whether generated by malloc, mmap, or some > ?? future allocator TBD (Jim?s QBA?) > ?* We provide many AllocationHandle factories: { confined, shared } x { > ?? cleaner, no cleaner } > ?* AllocationHandle is thin: just has a way to get size, alignment and > ?? a method to release memory - e.g. close(); in other words, > ?? AllocationHandle <: AutoCloseable > ?* crucially, an AllocationHandle has a way to obtain a segment /view/ > ?? out of it (MemorySegment) > ?* a MemorySegment is the same thing it used to be, /minus/ the > ?? terminal operations (|close|, |handoff|, ? methods) > ?* we still keep all the factories for constructing MemorySegments out > ?? of heap arrays and byte buffer > ?* there?s no way to go from a MemorySegment back to an AllocationHandle > > This approach solves quite few issues: > > ?* Since MemorySegment does not have a close() method, we don?t have to > ?? worry about specifying what close() does in problematic cases > ?? (slices, on-heap, etc.) > ?* There is an asymmetry between the actor which does an allocation > ?? (the holder of the AllocationHandle) and the rest of the world, > ?? which just deals with (non-closeable) MemorySegment - this seems to > ?? reflect how memory is allocated in the real world (one actor > ?? allocates, then shares a pointer to allocated memory to some other > ?? actors) > ?* AllocationHandles come in many shapes and form, but instead of > ?? having dynamic state transitions, users will have to choose the > ?? flavor they like ahead of time, knowing pros and cons of each > ?* This approach removes the need for access modes and restricted views > ?? - we probably still need a readOnly property in segments to support > ?? mapped memory, but that?s pretty much it > > Of course there are also things that can be perceived as disadvantages: > > ?* Conciseness. Code dealing in native memory segments will have to > ?? first obtain an allocation handle, then obtaining a segment. For > ?? instance, code like this: > > |try (MemorySegment s = MemorySegment.allocateNative(layout)) { ... > MemoryAccess.getIntAtOffset(s, 42); ... } | > > Will become: > > |try (AllocationHandle ah = > AllocationHandle.allocateNativeConfined(layout)) { MemorySegment s = > ah.asSegment(); ... MemoryAccess.getIntAtOffset(s, 42); ... } | > > ?* > > ?? It would be no longer possible for the linker API to just allocate > ?? memory and return a segment based on that memory - since now the > ?? user cannot free that memory anymore (no close method in segments). > ?? We could solve this either by having the linker API return > ?? allocation handle or, better, by having the linker API accepting a > ?? NativeScope where allocation should occur (since that?s how clients > ?? are likely to interact with the API point anyway). In fact, we have > ?? already considered doing something similar in the past (doing a > ?? malloc for each struct returned by value is a performance killer in > ?? certain contexts). > > ?* > > ?? At least in this form, we give up state transitions between confined > ?? and shared. Users will have to pick in which side of the world they > ?? want to play with and stick with it. For simple lexically scoped use > ?? cases, confined is fine and efficient - in more complex cases, > ?? shared might be unavoidable. While handing off an entire > ?? AllocationHandle is totally doable, doing so (e.g. killing an > ?? existing AH instance to return a new AH instance confined on a > ?? different thread) will also kill all segments derived from the > ?? original AH. So it?s not clear such an API would be very useful: to > ?? be able to do an handoff, clients will need to pass around an > ?? AllocationHandle, not a MemorySegment (like now). Note that adding > ?? handoff operation directly on MemorySegment, under this design, is > ?? not feasible: handoff is a terminal operation, so we would allow > ?? clients to do nonsensical things like: > > 1. obtain a segment > 2. create two identical segments via slicing > 3. set the owner of the two segments to two different threads > > For this reason, it makes sense to think about ownership as a property > on the /allocation/, not on the /view/. > > ?* While the impact of these changes on client using memory access API > ?? directly is somewhat biggie (no TWR on heap/buffer segments, need to > ?? go through an AllocationHandle for native stuff), clients of > ?? extracted API are largely unchanged, thanks to the fact that most of > ?? such clients use NativeScope anyway to abstract over how segments > ?? are allocated. > > Any thoughts? I think the first question is as to whether we?re ok > with the loss in conciseness, and with the addition of a new (albeit > very simple) abstraction. > > [1] - > https://docs.microsoft.com/en-us/dotnet/api/system.span-1?view=net-5.0 > [2] - > https://docs.microsoft.com/en-us/dotnet/standard/memory-and-spans/memory-t-usage-guidelines > > ? From maurizio.cimadamore at oracle.com Mon Jan 4 18:27:54 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 4 Jan 2021 18:27:54 +0000 Subject: Foreign memory access hot loop benchmark In-Reply-To: References: <0d33e2cc-1585-0fc2-8a9f-231f6c888b69@oracle.com> <3c26c12c-23e0-a99f-03cd-afd6996c6478@oracle.com> <7ca53e08-3b3d-0db3-0493-1ecb0e44b79d@oracle.com> <0c431324-68b5-c0b0-3ced-5119ab51def9@oracle.com> <72ab9217-c638-88b9-b8fc-9ec91fab4cf6@oracle.com> Message-ID: What happens with longs? Do you still see the slowdown? Maurizio On 04/01/2021 17:31, Antoine Chambille wrote: > /(using fixed width font ;)/ > > > Thank you Maurizio, for looking into this. > > This is a good find, I've just updated and rebuilt the Panama JDK, I > confirm that the big slowdown with manually unrolled loop and memory > handles has disappeared for the AddBenchmark.unrolledMHI_v2 benchmark. > But it is apparently still present in one last case: > AddBenchmark.unrolledMHI > > Maybe another missing annotation? > > Benchmark ?Mode ?Cnt ? ? ? ?Score ? ? ? ?Error ?Units > AddBenchmark.scalarArray ? ? ? ? ? ?thrpt ? ?5 ?5270072.806 ? > ?43618.821 ?ops/s > AddBenchmark.scalarArrayHandle ? ? ?thrpt ? ?5 ?5155791.142 ? > 122147.967 ?ops/s > AddBenchmark.scalarMHI ? ? ? ? ? ? ?thrpt ? ?5 ?2215595.625 ? > ?27044.786 ?ops/s > AddBenchmark.scalarMHI_v2 ? ? ? ? ? thrpt ? ?5 ?2165838.557 ? > ?48477.364 ?ops/s > AddBenchmark.scalarUnsafe ? ? ? ? ? thrpt ? ?5 ?2057853.572 ? > ?21064.385 ?ops/s > AddBenchmark.unrolledArray ? ? ? ? ?thrpt ? ?5 ?6346056.064 ? > 304425.251 ?ops/s > AddBenchmark.unrolledArrayHandle ? ?thrpt ? ?5 ?1991324.025 ? > ?39434.066 ?ops/s > AddBenchmark.unrolledMHI ? ? ? ? ? ?thrpt ? ?5 ? 206541.946 ? ? > 4031.057 ?ops/s > AddBenchmark.unrolledMHI_v2 ? ? ? ? thrpt ? ?5 ?2240957.905 ? > ?24239.357 ?ops/s > AddBenchmark.unrolledUnsafe ? ? ? ? thrpt ? ?5 ?2185038.207 ? > ?27611.150 ?ops/s > > > benchmark source code: > https://github.com/chamb/panama-benchmarks/blob/master/memory/src/main/java/com/activeviam/test/AddBenchmark.java > > > > // CODE OF THE REMAINING SLOW BENCHMARK > static final VarHandle MHI = MemoryLayout.ofSequence(SIZE, > MemoryLayouts.JAVA_DOUBLE) > ? ? ? ? ? ? .varHandle(double.class, > MemoryLayout.PathElement.sequenceElement()); > > @Benchmark > public void unrolledMHI(Data state) { > ? ? final MemorySegment is = state.inputSegment; > ? ? final MemorySegment os = state.outputSegment; > > ? ? for(int i = 0; i < SIZE; i+=4) { > ? ? ? ? MHI.set(os, (long) (i), ? (double) MHI.get(is, (long) (i)) ? + > (double) MHI.get(os, (long) (i))); > ? ? ? ? MHI.set(os, (long) (i+1), (double) MHI.get(is, (long) (i+1)) + > (double) MHI.get(os, (long) (i+1))); > ? ? ? ? MHI.set(os, (long) (i+2), (double) MHI.get(is, (long) (i+2)) + > (double) MHI.get(os, (long) (i+2))); > ? ? ? ? MHI.set(os, (long) (i+3), (double) MHI.get(is, (long) (i+3)) + > (double) MHI.get(os, (long) (i+3))); > ? ? } > } > > > > Best, > -Antoine > > > > > > > > On Mon, Jan 4, 2021 at 6:29 PM Antoine Chambille > wrote: > > Thank you Maurizio, for looking into this. > > This is a good find, I've just updated and rebuilt the panama JDK, > I confirm that the big slowdown with manually unrolled loop and > memory handles has disappeared for the AddBenchmark.unrolledMHI_v2 > benchmark. But it is apparently still present in one last case: > AddBenchmark.unrolledMHI > > Maybe another missing annotation? > > Benchmark ? ? ? ? ? ? ? ? ? ? ? ? ? ?Mode ?Cnt ?Score ? ? ? ?Error > ?Units > AddBenchmark.scalarArray ? ? ? ? ? ?thrpt ? ?5 ?5270072.806 ? > ?43618.821 ?ops/s > AddBenchmark.scalarArrayHandle ? ? ?thrpt ? ?5 ?5155791.142 ? > 122147.967 ?ops/s > AddBenchmark.scalarMHI ? ? ? ? ? ? ?thrpt ? ?5 ?2215595.625 ? > ?27044.786 ?ops/s > AddBenchmark.scalarMHI_v2 ? ? ? ? ? thrpt ? ?5 ?2165838.557 ? > ?48477.364 ?ops/s > AddBenchmark.scalarUnsafe ? ? ? ? ? thrpt ? ?5 ?2057853.572 ? > ?21064.385 ?ops/s > AddBenchmark.unrolledArray ? ? ? ? ?thrpt ? ?5 ?6346056.064 ? > 304425.251 ?ops/s > AddBenchmark.unrolledArrayHandle ? ?thrpt ? ?5 ?1991324.025 ? > ?39434.066 ?ops/s > AddBenchmark.unrolledMHI ? ? ? ? ? ?thrpt ? ?5 206541.946 ? ? > 4031.057 ?ops/s > AddBenchmark.unrolledMHI_v2 ? ? ? ? thrpt ? ?5 ?2240957.905 ? > ?24239.357 ?ops/s > AddBenchmark.unrolledUnsafe ? ? ? ? thrpt ? ?5 ?2185038.207 ? > ?27611.150 ?ops/s > > > benchmark source code: > https://github.com/chamb/panama-benchmarks/blob/master/memory/src/main/java/com/activeviam/test/AddBenchmark.java > > > > // CODE OF THE REMAINING SLOW BENCHMARK > static final VarHandle MHI = MemoryLayout.ofSequence(SIZE, > MemoryLayouts.JAVA_DOUBLE) > ? ? ? ? ? ? .varHandle(double.class, > MemoryLayout.PathElement.sequenceElement()); > > ? ? @Benchmark > ? ? public void unrolledMHI(Data state) { > ? ? ? ? final MemorySegment is = state.inputSegment; > ? ? ? ? final MemorySegment os = state.outputSegment; > > ? ? ? ? for(int i = 0; i < SIZE; i+=4) { > ? ? ? ? ? ? MHI.set(os, (long) (i), ? (double) MHI.get(is, (long) > (i)) ? + (double) MHI.get(os, (long) (i))); > ? ? ? ? ? ? MHI.set(os, (long) (i+1), (double) MHI.get(is, (long) > (i+1)) + (double) MHI.get(os, (long) (i+1))); > ? ? ? ? ? ? MHI.set(os, (long) (i+2), (double) MHI.get(is, (long) > (i+2)) + (double) MHI.get(os, (long) (i+2))); > ? ? ? ? ? ? MHI.set(os, (long) (i+3), (double) MHI.get(is, (long) > (i+3)) + (double) MHI.get(os, (long) (i+3))); > ? ? ? ? } > ? ? } > > > > Best, > -Antoine > > > > > > > > On Wed, Nov 25, 2020 at 1:42 PM Maurizio Cimadamore > > wrote: > > I did some investigation, and, during the problematic > benchmark we were > hitting some inline thresholds, as evidenced by > `-XX:PrintInlining`: > > @ 92 jdk.incubator.foreign.MemoryAccess::getLongAtIndex (12 > bytes) > NodeCountInliningCutoff > @ 96 jdk.incubator.foreign.MemoryAccess::setLongAtIndex (13 > bytes) > NodeCountInliningCutoff > @ 111 jdk.incubator.foreign.MemoryAccess::getLongAtIndex (12 > bytes) > NodeCountInliningCutoff > @ 120 jdk.incubator.foreign.MemoryAccess::getLongAtIndex (12 > bytes) > NodeCountInliningCutoff > @ 124 jdk.incubator.foreign.MemoryAccess::setLongAtIndex (13 > bytes) > NodeCountInliningCutoff > > The problem is that the static accessors in MemoryAccess are > lacking a > @ForceInline annotation. This is being addressed here: > > https://github.com/openjdk/panama-foreign/pull/401 > > > Thanks > Maurizio > > > On 25/11/2020 11:51, Maurizio Cimadamore wrote: > > > > On 24/11/2020 11:19, Antoine Chambille wrote: > >> If I look at the slow benchmark in detail, I observe that > the first > >> two warmups run at the expected speed, but then it slows > down 20x. > >> Very strange, it's almost as if some JIT optimization is > suddenly > >> turned off: > > > > This is something I've observed in the past as well, in some > cases, > > when playing with VH. > > > > We'll take a look. > > > > Thanks > > Maurizio > > > > > From uschindler at apache.org Mon Jan 4 18:40:34 2021 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 4 Jan 2021 19:40:34 +0100 Subject: [foreign-memaccess] musing on the memory access API In-Reply-To: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> References: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> Message-ID: <083001d6e2c9$1aae9040$500bb0c0$@apache.org> Hi Maurizio, here my thoughts after spending last week with making a preview of Apache Lucene and its MMapDirectory implementation to use MemorySegment API, for more details and a bit of history and our problems see here: https://github.com/apache/lucene-solr/pull/2176 A few of them between the lines below: > Hi, > now that the foreign memory access API has been around for an year, I > think it?s time we start asking ourselves if this is the API we want, > and how comfortable we are in finalizing it. Overall, I think that there > are some aspects of the memory access API which are definitively a success: > > * > > memory layouts, and the way they connect with dereference var > handles is definitively a success story, and now that we have added > even more var handle combinators, it is really possible to get crazy > with expressing exotic memory access At Lucene we have no looked at memory layouts, because we have our own API to acess memory. All we need is sequential or random access to our index files for reading posting lists containing of sometimes byte, short, int/floats or longs but in most cases vInt or zigzag encoded values. So memory layouts are not so important for us. I will more closely look into it, but our interest is low at the moment. To me the biggest success for the third incubator is: - shared memory segments, so Lucene searches/merges can from multiple threads at same time access the same huge gigabyte slices off-heap as if they were in memory. The whole design of Lucene relies on this ability (and other databases do the same, I think). - and finally being able to unmap those memory segments without relying on garbage collector. We did this before, too, but always with the risk of crushing the JVM. The Java 8 and later the Java 9+ based sun.misc.Unsafe unmapper is used in many open source projects (you remember, I was the one who asked back in Jigsaw development times to add this API). So many thanks for all those fruitful discussions! My thanks also go to Andrew Haley who had the idea how to do scoped memory access. I am glad that we had the discussion last year after FOSDEM in the commiter's meetup at Oracle Belgium! If you are interested, here is the preview of our code: https://github.com/apache/lucene-solr/pull/2176 Warning: Don't be afraid about MemorySegmentIndexInput, the code there is written like that to prevent all unnecessary duplicate bounds and "ist-still-opem" checks: MemorySegment does all of that for us, so we catch IndexOutOfBoundsException to detect if somebody is seeking to incorrect file locations or if we need to change the file mapping on reads across file/mapping boundaries (we map in junks of 16 Gigabytes to prevent address space fragmentation; with bytebuffers the junks were 1 GiB due to the 32 bits limit); and catch IllegalStateException with getMessage() contains "closed" to throw AlreadyClosedException on our side. Maybe we would love better exceptions, especially for the closed or access from other thread if confined! I opened a few bug reports (currently 4) where the MemorySegment.mapFile misbehaves: https://bugs.openjdk.java.net/browse/JDK-8259027 https://bugs.openjdk.java.net/browse/JDK-8259028 (complemented by https://bugs.openjdk.java.net/browse/JDK-8259034) https://bugs.openjdk.java.net/browse/JDK-8259032 <--- this one is a real desaster and should be fixed as soon as possible!!! > * > > the new shape of memory access var handle as (MemorySegment, > long)->X makes a lot of sense, and it allowed us to greatly simplify > and unify the implementation (as well as to give users a cheap way > to do unsafe dereference of random addresses, which they sometimes want) Yes, this is super cool. Previously the code was partly very slow as optimizations of Hotspot were hard to predict and also the many MemoryAdress objects created for nonsense just to do pointer arithmetric. The new VarHandles with "long" coordinates are exactly how you would expect it to work. It now looks like an array access. > * > > the distinction between MemorySegment and MemoryAddress is largely > beneficial - and, when explained, it?s pretty obvious where the > difference come from: to do dereference we need to attach bounds (of > various kinds) to a raw pointer - after we do that, dereference > operations are safe. I think this model makes it very natural to > think about which places in your program might introduce invalid > assumptions, especially when dealing with native code > > I also think that there are aspects of the API where it?s less clear we > made the right call: > > * > > slicing behavior: closing the slice closes everything. This was > mostly a forced move: there are basically two use cases for slices: > sometimes you slice soon after creation (e.g. to align), in which > case you want the new slice to have same properties as the old one > (e.g. deallocate on close). There are other cases where you are just > creating a dumb sub-view, and you don?t really want to expose > close() on those. This led to the creation of the ?access modes? > mechanism: each segment has some access modes - if the client wants > to prevent calls to MemorySegment::close it can do so by > /restricting/ the segment, and removing the corresponding CLOSE > access mode (e.g. before the segment is shared with other clients). > While this allows us to express all the use cases we care about, it > seems also a tad convoluted. Moreover, the client wrapping a > MemorySegment inside a TWR is always unsure as to whether the > segment will support close() or not. Thant's fine to me and easy to understand! > * > > not all segments are created equal: some memory segments are just > dumb views over memory that has been allocated somewhere else - e.g. > a Java heap array or a byte buffer. In such cases, it seems odd to > feature a close() operation (and I might add even having > thread-confinement, given the original API did not feature that to > begin with). > Sidebar: on numerous occasions it has been suggested to solve issues > such as the one above by allowing close() to be a no-op in certain > cases. While that is doable, I?ve never been too conviced about it, > mainly because of this: > > |MemorySegment s = ... s.close(); assertFalse(s.isAlive()); // I expect > this to never fail!!!! | > > In other words, a world where some segments are stateful and respond > accordingly to close() requests and some are not seems very confusing to me. > > * the various operations for managing confinement of segments is > rapidly turning into an distraction. For instance, recently, the > Netty guys have created a port on top of the memory access API, > since we have added support for shared segment. Their use of shared > segment was a bit strange, in the sense that, while they allocated a > segment in shared mode, they wanted to be able to confine the > segment near where the segment is used, to catch potential mistakes. > To do so, they resorted to calling handoff on a shared segment > repeatedly, which performance-wise doesn?t work. Closing a shared > segment (even if just for handing it off to some other thread) is a > very expensive operation which needs to be used carefully - but the > Netty developers were not aware of the trade-off (despite it being > described in the javadoc - but that?s understandable, as it?s pretty > subtle). Of course, if they just worked with a shared segment, and > avoided handoff, things would have worked just fine (closing shared > segments is perfectly fine for long lived segments). In other words, > this is a case where, by featuring many different modes of > interacting with segments (confined, shared) as well as ways to go > back and forth between these states, we create extra complexity, > both for ourselves and for the user. This is perfectly fine to me, I see no problem with that. At the moment we have shared memory buffers, why won't you not remove all the other ones. From my understanding "access" speed should be indentical, only the "unmapping" is more expensive. For Lucene this is no issue (we only unmap when we close a file and that happens seldom). IMHO: Quickly allocated memory segments that are freed after usage (like those commonly used in try with resources, like file buffers or memory layouts for foreign API calls) should be thread confined by default. But IMHO, a mmap file mapping should be shared from the beginning. It makes no sense to mmap a file, use it in one thread and close it afterwards. Most users of mmapped files we keep those segments open for long times and because of this will most likely access them from multiple threads as those are huge (like Lucene users, e.g. Elasticsearch often have indexes up to a terabyte mmapped to 64 bit address space open for longer time and accessed by hundreds of threads sometimes). An additional cost for closing them is not a big issue. It would be a much higher cost to recreate the mappings all the time, which uses disk IO and syscalls! > I?ve been thinking quite a bit about these issues, trying to find a more > stable position in the design space. While I can?t claim to have found a > 100% solution, I think I might be onto something worth exploring. On a > recent re-read of the C# Span API doc [1], it dawned on me that there is > a sibling abstraction to the Span abstraction in C#, namely Memory [2]. > While some of the reasons behind the Span vs. Memory split have to do > with stack vs. heap allocation (e.g. Span can only be used for local > vars, not fields), and so not directly related to our design choices, I > think some of the concepts of the C# solution hinted at a possibly > better way to stack the problem of memory access. > > We have known at least for the last 6 months that a MemorySegment is > playing multiple roles at once: a MS is both a memory allocation (e.g. > result of a malloc, or mmap), and a /view/ over said memory. This > duplicity creates most of the problem listed above, as it?s clear that, > while close() is a method that should belong to an allocation > abstraction, it is less clear that close() should also belong to a > view-like abstraction. We have tried, in the past, to come up with a > 3-pronged design, where we had not only MemorySegment and > MemoryAddress, > but also a MemoryResource abstraction from which /all/ segments were > derived. These experiments have failed, pretty much all for the same > reason: the return on complexity seemed thin. > > Recently, I found myself going back slightly to that approach, although > in a quite different way. Here?s the basic idea I?m playing with: > > * introduce a new abstraction: AllocationHandle (name TBD) - this > wraps an allocation, whether generated by malloc, mmap, or some > future allocator TBD (Jim?s QBA?) > * We provide many AllocationHandle factories: { confined, shared } x { > cleaner, no cleaner } > * AllocationHandle is thin: just has a way to get size, alignment and > a method to release memory - e.g. close(); in other words, > AllocationHandle <: AutoCloseable > * crucially, an AllocationHandle has a way to obtain a segment /view/ > out of it (MemorySegment) > * a MemorySegment is the same thing it used to be, /minus/ the > terminal operations (|close|, |handoff|, ? methods) > * we still keep all the factories for constructing MemorySegments out > of heap arrays and byte buffer > * there?s no way to go from a MemorySegment back to an AllocationHandle I am open to do this. Adding try-with-resources blocks around simple MemorySegments created around heap arrays makes no sense to me. So indeed splitting the "resource consuming ones" from the "free ones that don't need close" may be a good idea. > This approach solves quite few issues: > > * Since MemorySegment does not have a close() method, we don?t have to > worry about specifying what close() does in problematic cases > (slices, on-heap, etc.) > * There is an asymmetry between the actor which does an allocation > (the holder of the AllocationHandle) and the rest of the world, > which just deals with (non-closeable) MemorySegment - this seems to > reflect how memory is allocated in the real world (one actor > allocates, then shares a pointer to allocated memory to some other > actors) > * AllocationHandles come in many shapes and form, but instead of > having dynamic state transitions, users will have to choose the > flavor they like ahead of time, knowing pros and cons of each > * This approach removes the need for access modes and restricted views > - we probably still need a readOnly property in segments to support > mapped memory, but that?s pretty much it > > Of course there are also things that can be perceived as disadvantages: > > * Conciseness. Code dealing in native memory segments will have to > first obtain an allocation handle, then obtaining a segment. For > instance, code like this: > > |try (MemorySegment s = MemorySegment.allocateNative(layout)) { ... > MemoryAccess.getIntAtOffset(s, 42); ... } | > > Will become: > > |try (AllocationHandle ah = > AllocationHandle.allocateNativeConfined(layout)) { MemorySegment s = > ah.asSegment(); ... MemoryAccess.getIntAtOffset(s, 42); ... } | > > * > > It would be no longer possible for the linker API to just allocate > memory and return a segment based on that memory - since now the > user cannot free that memory anymore (no close method in segments). > We could solve this either by having the linker API return > allocation handle or, better, by having the linker API accepting a > NativeScope where allocation should occur (since that?s how clients > are likely to interact with the API point anyway). In fact, we have > already considered doing something similar in the past (doing a > malloc for each struct returned by value is a performance killer in > certain contexts). > > * > > At least in this form, we give up state transitions between confined > and shared. Users will have to pick in which side of the world they > want to play with and stick with it. For simple lexically scoped use > cases, confined is fine and efficient - in more complex cases, > shared might be unavoidable. While handing off an entire > AllocationHandle is totally doable, doing so (e.g. killing an > existing AH instance to return a new AH instance confined on a > different thread) will also kill all segments derived from the > original AH. So it?s not clear such an API would be very useful: to > be able to do an handoff, clients will need to pass around an > AllocationHandle, not a MemorySegment (like now). Note that adding > handoff operation directly on MemorySegment, under this design, is > not feasible: handoff is a terminal operation, so we would allow > clients to do nonsensical things like: > > 1. obtain a segment > 2. create two identical segments via slicing > 3. set the owner of the two segments to two different threads > > For this reason, it makes sense to think about ownership as a property > on the /allocation/, not on the /view/. > > * While the impact of these changes on client using memory access API > directly is somewhat biggie (no TWR on heap/buffer segments, need to > go through an AllocationHandle for native stuff), clients of > extracted API are largely unchanged, thanks to the fact that most of > such clients use NativeScope anyway to abstract over how segments > are allocated. > > Any thoughts? I think the first question is as to whether we?re ok with > the loss in conciseness, and with the addition of a new (albeit very > simple) abstraction. > > [1] - https://docs.microsoft.com/en-us/dotnet/api/system.span-1?view=net-5.0 > [2] - > https://docs.microsoft.com/en-us/dotnet/standard/memory-and- > spans/memory-t-usage-guidelines > > ? From maurizio.cimadamore at oracle.com Mon Jan 4 18:56:54 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 4 Jan 2021 18:56:54 +0000 Subject: Panama source code fails to compile In-Reply-To: References: <5ea52f78-f853-57df-7c7f-fa299b091c55@gmail.com> <409652537.261382.1609190287324.JavaMail.zimbra@u-pem.fr> <9a74ba5e-523a-e96d-4e60-8d66b6e0516f@gmail.com> <9045aa0c-5454-3b18-13a1-b39252a29622@gmail.com> <30df2329-2332-1b6f-bc5f-6fb40974ca60@oracle.com> Message-ID: <11035576-2e05-4b30-0135-2cdd611bd3b9@oracle.com> On 04/01/2021 16:58, Ty Young wrote: > > On 1/4/21 5:23 AM, Maurizio Cimadamore wrote: >> As usual, I find the tone of some of these emails way over the top. >> >> We do have CI, both internally and externally. I don't think the >> GitHub test was triggered during the merge, so the external CI did >> not run in this case. Our internal CI ran as usual and did not report >> any error - likely, as Remi said, because of a difference in the >> compiler being used. > > > FWIW the changes were never merged into foreign-jextract(master) as > far as I can tell, only foreign-memaccess+abi. > > > The point I was making about the CLI is so people outside of Oracle > know what's working or isn't. This time around it was a bad merge that > introduced a duplicate function, which is the most trivial of trivial > fixes, but I've in the past seen wrong/non-existant constructors > called in Java code before too, in which case waiting and letting JDK > developers fix it is best I think. In general, Skara allows for some CI results to be published alongside PRs - see for instance: https://github.com/openjdk/jdk/pull/1611 You can see at the bottom that GiitHub reports that some build/test have failed. On top of my head I don't know if (a) this is enabled for the Panama repo and (b) if it is enabled for merge changes. > > Those builds are generally too old and the changes from one to the > next can be massive. For the longest time it pointed to the old > Pointer API despite it being long abandoned. Things only happen to be > better now because Panama hasn't received major changes in months. The latest build was released just weeks ago (12/10). We plan to release more frequently now that we finished hammering the implementation and that all jextract samples have been ported. In other words, there was a reason as to why no new build has been published in such a long time. But we'll do better. > > > There are more IDEs out there than Intellij. I use Netbeans which, > while increasingly buggy as time goes on, does mostly work and was not > affected by the changes you mention. It handles JDK builds > built-fron-source surprisingly well actually, so long as you use those > builds as your boot JDK and Dr. Deprecator decided to take a vacation > for the JDK development cycle. Sure, I'm aware of Netbeans :-) That said, IJ support is so broken right now that I don't think it would be a great idea releasing a binary now when we can release a new one in 2-3 weeks and make sure it works properly with IJ too. > > >> >> As for the state of the API, as the API is incubating we consider it >> to be our best shot _so far_, but things might still change given >> targeted feedback. Of course, the more we are iterating, the less >> substantial API changes you are seeing. > > > I did a casual look over some of the code and there are a number of > mostly minor cleanups and API modifications that could be made IMO, > although only one so far that I've seen could probably be called major: > > > - AbstractLayout could be modified to use generics so that all layout > types no longer need to override standard MemoryLayout withers. The > Javadoc bug that prevented this from being done has long since been > fixed(JDK-8224052) in JDK 14. I've made the changes already here: > > Thanks for pointing that out - I think I tried that at some point but it was still not working as I expected, but worth giving another try. > > > - Padding layout should probably be a subclass of ValueLayout and just > override methods as needed. Having every memory layout have a > isPadding() method doesn't make much sense. The PaddingLayout class > can then be moved to an internal package as there is no way to create > an instance outside of ofPaddingBits as an API user. The same could be > done for AbstractLayout. Are you talking about API or impl? Impl-wise, we could resort to overriding for isPadding, but if PaddingLayout is to be impl-private, then user has no way to do instanceof PaddingLayout, so you need a predicate? > > > - GroupLayout should probably be split into StructLayout and > UnionLayout. This is the biggest change, but it simplifies the code, > provides better clarity on what's actually being represented, and > allows for future struct/union specific operations to be added without > adding a bunch of if(!isUnion) throw new > UnsupportedOperationException(); type code. Less sure about this. I think pattern matching will also help a great deal with this, at some point. > > > This is just from me skimming the surface API code after submitting > the OCA, there are probably more changes although I doubt there is > anything major. Thanks for the comment Maurizio > > >> >> Cheers >> Maurizio >> >> >> On 29/12/2020 21:12, Ty Young wrote: >>> Yes, mostly. Things happen, especially on holidays when everyone has >>> things to do and places to be. I was going to wait until after the >>> new year to bring it up, but I had seen JDK developers replying to >>> things so I figured they were back. >>> >>> >>> A proper CI could have at least warned that there is an issue, just >>> like other previous issues. Having newer JDK builds would be a >>> benefit to projects like Panama as it reduces the hurdle to try out >>> recent versions, especially those on Windows. Again, probably >>> screaming into the void on the CI thing. >>> >>> >>> On 12/29/20 5:21 AM, Samuel Audet wrote: >>>> Hi, >>>> >>>> I think the point is that this could have been prevented with >>>> proper CI. Since the repos are now on GitHub, OpenJDK could easily >>>> benefit >>>> from GitHub Actions... >>>> >>>> Samuel >>>> >>>> On Tue, Dec 29, 2020, 16:39 David Holmes >>> > wrote: >>>> >>>> ??? On 29/12/2020 1:06 pm, Ty Young wrote: >>>> ??? > >>>> ??? > On 12/28/20 3:18 PM, Remi Forax wrote: >>>> ??? >> ----- Mail original ----- >>>> ??? >>> De: "Ty Young" >>> ??? > >>>> ??? >>> ?: "panama-dev at openjdk.java.net >>>> ??? '" >>>> ??? > >>>> ??? >>> Envoy?: Lundi 28 D?cembre 2020 22:06:58 >>>> ??? >>> Objet: Panama source code fails to compile >>>> ??? >>> Just an FYI, the Panama source code have been broken since >>>> before >>>> ??? >>> Christmas with this error: >>>> ??? >>> >>>> ??? >>> >>>> ??? >>> panama-foreign/src/hotspot/share/oops/methodData.cpp:1616:6: >>>> ??? error: >>>> ??? >>> redefinition of 'static bool >>>> ??? MethodData::profile_memory_access(const >>>> ??? >>> methodHandle&, int)' >>>> ??? >>> ??1616 | bool MethodData::profile_memory_access(const >>>> ??? methodHandle& m, >>>> ??? >>> int bci) { >>>> ??? >>> ?????? |????? ^~~~~~~~~~ >>>> ??? >>> >>>> /run/media/ty/Windows_Linux_Shared/OpenJDK/panama-foreign/src/hotspot/share/oops/methodData.cpp:1604:6: >>>> >>>> >>>> ??? >>> >>>> ??? >>> note: 'static bool MethodData::profile_memory_access(const >>>> ??? >>> methodHandle&, int)' previously defined here >>>> ??? >>> ??1604 | bool MethodData::profile_memory_access(const >>>> ??? methodHandle& m, >>>> ??? >>> int bci) { >>>> ??? >>> ?????? | >>>> ??? >>> >>>> ??? >>> >>>> ??? >>> I tried building using the usual `bash configure >>>> ??? >>> --disable-warnings-as-errors` and `make images` on (Arch) >>>> ??? Linux. I am >>>> ??? >>> able to compile the standard JDK from source just fine. >>>> ??? >>> >>>> ??? >>> >>>> ??? >>> I know I'm probably (metaphorically) screaming into the void >>>> ??? here but... >>>> ??? >>> people often have data caps and JDK source code is *A LOT*. >>>> Not to >>>> ??? >>> mention the CPU and memory requirements needed to compile >>>> it in a >>>> ??? >>> reasonable amount of time, which are massive. I suggested >>>> ??? months ago on >>>> ??? >>> the skara-dev list on having build succeeded/failed badges >>>> and/or >>>> ??? >>> automatic JDK builds but apparently no one is interested >>>> ??? because it >>>> ??? >>> hasn't been added. Is making sure your code compiles & runs >>>> ??? before you >>>> ??? >>> push it not a requirement for JDK developers or something? I >>>> ??? understand >>>> ??? >>> it was Christmas but this has happened a few times now. >>>> ??? >> Usually for this kind of error, it's because you are compiling >>>> ??? with a >>>> ??? >> c++ compiler more recent than the one used by the CI, >>>> ??? >> so the bug flies under the radar. >>>> ??? > >>>> ??? > >>>> ??? > There is clearly a duplicate declaration: >>>> ??? > >>>> ??? > >>>> ??? > >>>> https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign/blob/5a8d47fd226708e46f56ec82294e9c786f6850c1/src/hotspot/share/oops/methodData.cpp*L1604__;Iw!!GqivPVa7Brio!ILC6p5xgmmz-ejxPQX_xGplLVDDWejZBFdTxXI-t04hinw_VlVp01-MoqnQmCM8LnniiGbY$ >>>> >>>> >>> > >>>> >>>> ??? > >>>> ??? > >>>> ??? > >>>> ??? > and >>>> ??? > >>>> ??? > >>>> ??? > >>>> https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign/blob/5a8d47fd226708e46f56ec82294e9c786f6850c1/src/hotspot/share/oops/methodData.cpp*L1616__;Iw!!GqivPVa7Brio!ILC6p5xgmmz-ejxPQX_xGplLVDDWejZBFdTxXI-t04hinw_VlVp01-MoqnQmCM8Ldyj5wAg$ >>>> >>>> >>> > >>>> >>>> ??? > >>>> ??? > >>>> ??? > >>>> ??? > are the same. Git blame shows that the duplicate was added 17 >>>> ??? days ago: >>>> ??? > >>>> ??? > >>>> ??? > >>>> https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign/blame/5a8d47fd226708e46f56ec82294e9c786f6850c1/src/hotspot/share/oops/methodData.cpp*L1616__;Iw!!GqivPVa7Brio!ILC6p5xgmmz-ejxPQX_xGplLVDDWejZBFdTxXI-t04hinw_VlVp01-MoqnQmCM8L7aTmLhQ$ >>>> >>>> >>> > >>>> >>>> >>>> ??? I think I see what happened. >>>> >>>> ??? JDK-8257692 was fixed in the panama-foreign repo in >>>> foreign-jextract >>>> ??? branch. >>>> >>>> ??? JDK-8258242 was fixed in the mainline JDK and contained some of >>>> ??? the same >>>> ??? code changes. >>>> >>>> ??? A few days before Christmas there was an auto-merge between >>>> ??? panama-foreign and mainline JDK, and that is when the duplicate >>>> code >>>> ??? chunk has arisen. >>>> >>>> ??? David >>>> ??? ----- >>>> >>>> ??? > >>>> ??? > >>>> ??? > and removing the duplicate allows the JDK to build correctly. >>>> ??? > >>>> ??? > >>>> ??? > So, no, this has nothing to do with the distro or the compiler I >>>> ??? use. >>>> ??? > I've already been through this blame game nonsense on swing-dev >>>> ??? with JDK >>>> ??? > developers when they broke literally every Swing application >>>> ??? that used >>>> ??? > GTK L&F on Arch Linux, lets not do it again, please. >>>> ??? > >>>> ??? > >>>> ??? >> >>>> ??? >>> >>>> ??? >>> Just a little annoyed, sorry. I try to always use the latest >>>> ??? builds so I >>>> ??? >>> don't have to constantly make large code changes, although >>>> ??? there hasn't >>>> ??? >>> been many changes lately, which is odd. Is Panama's API nearly >>>> ??? complete? >>>> ??? >>> What's the state of Panama at this point? >>>> ??? >> R?mi >>>> From maurizio.cimadamore at oracle.com Mon Jan 4 19:28:02 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 4 Jan 2021 19:28:02 +0000 Subject: [foreign-memaccess] musing on the memory access API In-Reply-To: <083001d6e2c9$1aae9040$500bb0c0$@apache.org> References: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> <083001d6e2c9$1aae9040$500bb0c0$@apache.org> Message-ID: <1a830d5e-233c-e54e-6b3c-d679c7297410@oracle.com> Thanks for the feedback Uwe, and for the bug reports. We'll do our best to address some of them quickly (the NPE and the error in Unmapper::address). As for adding an overload for mapping a segment from a FileChannel I'm totally open to it, but I think it's late-ish now to add API changes, since we are in stabilization. Also, thanks for the thoughts on the API in general - I kind of expected (given our discussions) that shared segments were 90% of what you needed - and that you are not much interested in using confinement. I agree that, when working from that angle, the API looks mostly ok. But not all clients have same requirements and some would like to take advantage of confinement more - also, note that if we just drop support for confined segments (which is something we also thought about) and just offered shared access, _all_ clients will be stuck with a very slow close() operation. There are very different ways to use a memory segment; sometimes (as in your case) a memory segment is long-lived, and you don't care if closing it takes 1 us. But there are other cases where segments are created (and disposed) more frequently. To me, the interesting fact that emerged from the Netty experiment (thanks guys!) was that using handoff AND shared segment, while nice on paper it's not going to work performance-wise, because you need to do an expensive close at each hand-off. This might be rectified, for instance by making the API more complex, and have a state where a segment has no owner (e.g. so that instead of confined(A) -> shared -> confined(B) you do confined(A) -> detached -> confined(B) ), but the risk is that to add a lot of API complexity ("detached" is a brand new segment state in which the segment is not accessible, but where memory is not yet deallocated) for what might be perceived as a corner case. So, the big question here is - given that there are defo different modes to interact with this API (short lived vs. long lived segment), what API allows us to capture the use cases we want in the simplest way possible? While dynamic ownership changes look like a cool idea on paper, it also add complexity - so I think now it's the right time to ask ourself if we should scale back on that a bit and have a more "static" set of flavors to pick from (e.g. { confined, shared } x { explicit, cleaner } Cheers Maurizio On 04/01/2021 18:40, Uwe Schindler wrote: > Hi Maurizio, > > here my thoughts after spending last week with making a preview of Apache Lucene and its MMapDirectory implementation to use MemorySegment API, for more details and a bit of history and our problems see here: https://urldefense.com/v3/__https://github.com/apache/lucene-solr/pull/2176__;!!GqivPVa7Brio!IZmGN9PWGLSQKhqp23RBDFrdoLmZ9UlDZ8sYKMGFRwTICsGaFmGiAUKKJJD_4wfatia-Dks$ > > A few of them between the lines below: > >> Hi, >> now that the foreign memory access API has been around for an year, I >> think it?s time we start asking ourselves if this is the API we want, >> and how comfortable we are in finalizing it. Overall, I think that there >> are some aspects of the memory access API which are definitively a success: >> >> * >> >> memory layouts, and the way they connect with dereference var >> handles is definitively a success story, and now that we have added >> even more var handle combinators, it is really possible to get crazy >> with expressing exotic memory access > At Lucene we have no looked at memory layouts, because we have our own API to acess memory. All we need is sequential or random access to our index files for reading posting lists containing of sometimes byte, short, int/floats or longs but in most cases vInt or zigzag encoded values. So memory layouts are not so important for us. I will more closely look into it, but our interest is low at the moment. > > To me the biggest success for the third incubator is: > - shared memory segments, so Lucene searches/merges can from multiple threads at same time access the same huge gigabyte slices off-heap as if they were in memory. The whole design of Lucene relies on this ability (and other databases do the same, I think). > - and finally being able to unmap those memory segments without relying on garbage collector. We did this before, too, but always with the risk of crushing the JVM. The Java 8 and later the Java 9+ based sun.misc.Unsafe unmapper is used in many open source projects (you remember, I was the one who asked back in Jigsaw development times to add this API). > > So many thanks for all those fruitful discussions! My thanks also go to Andrew Haley who had the idea how to do scoped memory access. I am glad that we had the discussion last year after FOSDEM in the commiter's meetup at Oracle Belgium! > > If you are interested, here is the preview of our code: https://urldefense.com/v3/__https://github.com/apache/lucene-solr/pull/2176__;!!GqivPVa7Brio!IZmGN9PWGLSQKhqp23RBDFrdoLmZ9UlDZ8sYKMGFRwTICsGaFmGiAUKKJJD_4wfatia-Dks$ > > Warning: Don't be afraid about MemorySegmentIndexInput, the code there is written like that to prevent all unnecessary duplicate bounds and "ist-still-opem" checks: MemorySegment does all of that for us, so we catch IndexOutOfBoundsException to detect if somebody is seeking to incorrect file locations or if we need to change the file mapping on reads across file/mapping boundaries (we map in junks of 16 Gigabytes to prevent address space fragmentation; with bytebuffers the junks were 1 GiB due to the 32 bits limit); and catch IllegalStateException with getMessage() contains "closed" to throw AlreadyClosedException on our side. Maybe we would love better exceptions, especially for the closed or access from other thread if confined! > > I opened a few bug reports (currently 4) where the MemorySegment.mapFile misbehaves: > https://bugs.openjdk.java.net/browse/JDK-8259027 > https://bugs.openjdk.java.net/browse/JDK-8259028 (complemented by https://bugs.openjdk.java.net/browse/JDK-8259034) > https://bugs.openjdk.java.net/browse/JDK-8259032 <--- this one is a real desaster and should be fixed as soon as possible!!! > >> * >> >> the new shape of memory access var handle as (MemorySegment, >> long)->X makes a lot of sense, and it allowed us to greatly simplify >> and unify the implementation (as well as to give users a cheap way >> to do unsafe dereference of random addresses, which they sometimes want) > Yes, this is super cool. Previously the code was partly very slow as optimizations of Hotspot were hard to predict and also the many MemoryAdress objects created for nonsense just to do pointer arithmetric. The new VarHandles with "long" coordinates are exactly how you would expect it to work. It now looks like an array access. > >> * >> >> the distinction between MemorySegment and MemoryAddress is largely >> beneficial - and, when explained, it?s pretty obvious where the >> difference come from: to do dereference we need to attach bounds (of >> various kinds) to a raw pointer - after we do that, dereference >> operations are safe. I think this model makes it very natural to >> think about which places in your program might introduce invalid >> assumptions, especially when dealing with native code >> >> I also think that there are aspects of the API where it?s less clear we >> made the right call: >> >> * >> >> slicing behavior: closing the slice closes everything. This was >> mostly a forced move: there are basically two use cases for slices: >> sometimes you slice soon after creation (e.g. to align), in which >> case you want the new slice to have same properties as the old one >> (e.g. deallocate on close). There are other cases where you are just >> creating a dumb sub-view, and you don?t really want to expose >> close() on those. This led to the creation of the ?access modes? >> mechanism: each segment has some access modes - if the client wants >> to prevent calls to MemorySegment::close it can do so by >> /restricting/ the segment, and removing the corresponding CLOSE >> access mode (e.g. before the segment is shared with other clients). >> While this allows us to express all the use cases we care about, it >> seems also a tad convoluted. Moreover, the client wrapping a >> MemorySegment inside a TWR is always unsure as to whether the >> segment will support close() or not. > Thant's fine to me and easy to understand! > >> * >> >> not all segments are created equal: some memory segments are just >> dumb views over memory that has been allocated somewhere else - e.g. >> a Java heap array or a byte buffer. In such cases, it seems odd to >> feature a close() operation (and I might add even having >> thread-confinement, given the original API did not feature that to >> begin with). >> Sidebar: on numerous occasions it has been suggested to solve issues >> such as the one above by allowing close() to be a no-op in certain >> cases. While that is doable, I?ve never been too conviced about it, >> mainly because of this: >> >> |MemorySegment s = ... s.close(); assertFalse(s.isAlive()); // I expect >> this to never fail!!!! | >> >> In other words, a world where some segments are stateful and respond >> accordingly to close() requests and some are not seems very confusing to me. >> >> * the various operations for managing confinement of segments is >> rapidly turning into an distraction. For instance, recently, the >> Netty guys have created a port on top of the memory access API, >> since we have added support for shared segment. Their use of shared >> segment was a bit strange, in the sense that, while they allocated a >> segment in shared mode, they wanted to be able to confine the >> segment near where the segment is used, to catch potential mistakes. >> To do so, they resorted to calling handoff on a shared segment >> repeatedly, which performance-wise doesn?t work. Closing a shared >> segment (even if just for handing it off to some other thread) is a >> very expensive operation which needs to be used carefully - but the >> Netty developers were not aware of the trade-off (despite it being >> described in the javadoc - but that?s understandable, as it?s pretty >> subtle). Of course, if they just worked with a shared segment, and >> avoided handoff, things would have worked just fine (closing shared >> segments is perfectly fine for long lived segments). In other words, >> this is a case where, by featuring many different modes of >> interacting with segments (confined, shared) as well as ways to go >> back and forth between these states, we create extra complexity, >> both for ourselves and for the user. > This is perfectly fine to me, I see no problem with that. At the moment we have shared memory buffers, why won't you not remove all the other ones. From my understanding "access" speed should be indentical, only the "unmapping" is more expensive. For Lucene this is no issue (we only unmap when we close a file and that happens seldom). > > IMHO: Quickly allocated memory segments that are freed after usage (like those commonly used in try with resources, like file buffers or memory layouts for foreign API calls) should be thread confined by default. But IMHO, a mmap file mapping should be shared from the beginning. It makes no sense to mmap a file, use it in one thread and close it afterwards. Most users of mmapped files we keep those segments open for long times and because of this will most likely access them from multiple threads as those are huge (like Lucene users, e.g. Elasticsearch often have indexes up to a terabyte mmapped to 64 bit address space open for longer time and accessed by hundreds of threads sometimes). An additional cost for closing them is not a big issue. It would be a much higher cost to recreate the mappings all the time, which uses disk IO and syscalls! > >> I?ve been thinking quite a bit about these issues, trying to find a more >> stable position in the design space. While I can?t claim to have found a >> 100% solution, I think I might be onto something worth exploring. On a >> recent re-read of the C# Span API doc [1], it dawned on me that there is >> a sibling abstraction to the Span abstraction in C#, namely Memory [2]. >> While some of the reasons behind the Span vs. Memory split have to do >> with stack vs. heap allocation (e.g. Span can only be used for local >> vars, not fields), and so not directly related to our design choices, I >> think some of the concepts of the C# solution hinted at a possibly >> better way to stack the problem of memory access. >> >> We have known at least for the last 6 months that a MemorySegment is >> playing multiple roles at once: a MS is both a memory allocation (e.g. >> result of a malloc, or mmap), and a /view/ over said memory. This >> duplicity creates most of the problem listed above, as it?s clear that, >> while close() is a method that should belong to an allocation >> abstraction, it is less clear that close() should also belong to a >> view-like abstraction. We have tried, in the past, to come up with a >> 3-pronged design, where we had not only MemorySegment and >> MemoryAddress, >> but also a MemoryResource abstraction from which /all/ segments were >> derived. These experiments have failed, pretty much all for the same >> reason: the return on complexity seemed thin. >> >> Recently, I found myself going back slightly to that approach, although >> in a quite different way. Here?s the basic idea I?m playing with: >> >> * introduce a new abstraction: AllocationHandle (name TBD) - this >> wraps an allocation, whether generated by malloc, mmap, or some >> future allocator TBD (Jim?s QBA?) >> * We provide many AllocationHandle factories: { confined, shared } x { >> cleaner, no cleaner } >> * AllocationHandle is thin: just has a way to get size, alignment and >> a method to release memory - e.g. close(); in other words, >> AllocationHandle <: AutoCloseable >> * crucially, an AllocationHandle has a way to obtain a segment /view/ >> out of it (MemorySegment) >> * a MemorySegment is the same thing it used to be, /minus/ the >> terminal operations (|close|, |handoff|, ? methods) >> * we still keep all the factories for constructing MemorySegments out >> of heap arrays and byte buffer >> * there?s no way to go from a MemorySegment back to an AllocationHandle > I am open to do this. Adding try-with-resources blocks around simple MemorySegments created around heap arrays makes no sense to me. So indeed splitting the "resource consuming ones" from the "free ones that don't need close" may be a good idea. > >> This approach solves quite few issues: >> >> * Since MemorySegment does not have a close() method, we don?t have to >> worry about specifying what close() does in problematic cases >> (slices, on-heap, etc.) >> * There is an asymmetry between the actor which does an allocation >> (the holder of the AllocationHandle) and the rest of the world, >> which just deals with (non-closeable) MemorySegment - this seems to >> reflect how memory is allocated in the real world (one actor >> allocates, then shares a pointer to allocated memory to some other >> actors) >> * AllocationHandles come in many shapes and form, but instead of >> having dynamic state transitions, users will have to choose the >> flavor they like ahead of time, knowing pros and cons of each >> * This approach removes the need for access modes and restricted views >> - we probably still need a readOnly property in segments to support >> mapped memory, but that?s pretty much it >> >> Of course there are also things that can be perceived as disadvantages: >> >> * Conciseness. Code dealing in native memory segments will have to >> first obtain an allocation handle, then obtaining a segment. For >> instance, code like this: >> >> |try (MemorySegment s = MemorySegment.allocateNative(layout)) { ... >> MemoryAccess.getIntAtOffset(s, 42); ... } | >> >> Will become: >> >> |try (AllocationHandle ah = >> AllocationHandle.allocateNativeConfined(layout)) { MemorySegment s = >> ah.asSegment(); ... MemoryAccess.getIntAtOffset(s, 42); ... } | >> >> * >> >> It would be no longer possible for the linker API to just allocate >> memory and return a segment based on that memory - since now the >> user cannot free that memory anymore (no close method in segments). >> We could solve this either by having the linker API return >> allocation handle or, better, by having the linker API accepting a >> NativeScope where allocation should occur (since that?s how clients >> are likely to interact with the API point anyway). In fact, we have >> already considered doing something similar in the past (doing a >> malloc for each struct returned by value is a performance killer in >> certain contexts). >> >> * >> >> At least in this form, we give up state transitions between confined >> and shared. Users will have to pick in which side of the world they >> want to play with and stick with it. For simple lexically scoped use >> cases, confined is fine and efficient - in more complex cases, >> shared might be unavoidable. While handing off an entire >> AllocationHandle is totally doable, doing so (e.g. killing an >> existing AH instance to return a new AH instance confined on a >> different thread) will also kill all segments derived from the >> original AH. So it?s not clear such an API would be very useful: to >> be able to do an handoff, clients will need to pass around an >> AllocationHandle, not a MemorySegment (like now). Note that adding >> handoff operation directly on MemorySegment, under this design, is >> not feasible: handoff is a terminal operation, so we would allow >> clients to do nonsensical things like: >> >> 1. obtain a segment >> 2. create two identical segments via slicing >> 3. set the owner of the two segments to two different threads >> >> For this reason, it makes sense to think about ownership as a property >> on the /allocation/, not on the /view/. >> >> * While the impact of these changes on client using memory access API >> directly is somewhat biggie (no TWR on heap/buffer segments, need to >> go through an AllocationHandle for native stuff), clients of >> extracted API are largely unchanged, thanks to the fact that most of >> such clients use NativeScope anyway to abstract over how segments >> are allocated. >> >> Any thoughts? I think the first question is as to whether we?re ok with >> the loss in conciseness, and with the addition of a new (albeit very >> simple) abstraction. >> >> [1] - https://urldefense.com/v3/__https://docs.microsoft.com/en-us/dotnet/api/system.span-1?view=net-5.0__;!!GqivPVa7Brio!IZmGN9PWGLSQKhqp23RBDFrdoLmZ9UlDZ8sYKMGFRwTICsGaFmGiAUKKJJD_4wfac0_Rt2Y$ >> [2] - >> https://urldefense.com/v3/__https://docs.microsoft.com/en-us/dotnet/standard/memory-and-__;!!GqivPVa7Brio!IZmGN9PWGLSQKhqp23RBDFrdoLmZ9UlDZ8sYKMGFRwTICsGaFmGiAUKKJJD_4wfaVci9Qgo$ >> spans/memory-t-usage-guidelines >> >> ? From youngty1997 at gmail.com Mon Jan 4 19:38:57 2021 From: youngty1997 at gmail.com (Ty Young) Date: Mon, 4 Jan 2021 13:38:57 -0600 Subject: Panama source code fails to compile In-Reply-To: <11035576-2e05-4b30-0135-2cdd611bd3b9@oracle.com> References: <5ea52f78-f853-57df-7c7f-fa299b091c55@gmail.com> <409652537.261382.1609190287324.JavaMail.zimbra@u-pem.fr> <9a74ba5e-523a-e96d-4e60-8d66b6e0516f@gmail.com> <9045aa0c-5454-3b18-13a1-b39252a29622@gmail.com> <30df2329-2332-1b6f-bc5f-6fb40974ca60@oracle.com> <11035576-2e05-4b30-0135-2cdd611bd3b9@oracle.com> Message-ID: <28b7134b-4006-ea85-eb16-49571a1f1c20@gmail.com> On 1/4/21 12:56 PM, Maurizio Cimadamore wrote: > > On 04/01/2021 16:58, Ty Young wrote: >> >> On 1/4/21 5:23 AM, Maurizio Cimadamore wrote: >>> As usual, I find the tone of some of these emails way over the top. >>> >>> We do have CI, both internally and externally. I don't think the >>> GitHub test was triggered during the merge, so the external CI did >>> not run in this case. Our internal CI ran as usual and did not >>> report any error - likely, as Remi said, because of a difference in >>> the compiler being used. >> >> >> FWIW the changes were never merged into foreign-jextract(master) as >> far as I can tell, only foreign-memaccess+abi. >> >> >> The point I was making about the CLI is so people outside of Oracle >> know what's working or isn't. This time around it was a bad merge >> that introduced a duplicate function, which is the most trivial of >> trivial fixes, but I've in the past seen wrong/non-existant >> constructors called in Java code before too, in which case waiting >> and letting JDK developers fix it is best I think. > > In general, Skara allows for some CI results to be published alongside > PRs - see for instance: > > https://github.com/openjdk/jdk/pull/1611 > > You can see at the bottom that GiitHub reports that some build/test > have failed. > > On top of my head I don't know if (a) this is enabled for the Panama > repo and (b) if it is enabled for merge changes. I noticed that too when I was messing around with Github actions on my fork and realized that it existed. Bit strange it isn't enabled. > > >> >> Those builds are generally too old and the changes from one to the >> next can be massive. For the longest time it pointed to the old >> Pointer API despite it being long abandoned. Things only happen to be >> better now because Panama hasn't received major changes in months. > > The latest build was released just weeks ago (12/10). > > We plan to release more frequently now that we finished hammering the > implementation and that all jextract samples have been ported. In > other words, there was a reason as to why no new build has been > published in such a long time. But we'll do better. Right, I've always assumed those were more "milestone" releases. Thanks. > >> >> >> There are more IDEs out there than Intellij. I use Netbeans which, >> while increasingly buggy as time goes on, does mostly work and was >> not affected by the changes you mention. It handles JDK builds >> built-fron-source surprisingly well actually, so long as you use >> those builds as your boot JDK and Dr. Deprecator decided to take a >> vacation for the JDK development cycle. > > Sure, I'm aware of Netbeans :-) > > That said, IJ support is so broken right now that I don't think it > would be a great idea releasing a binary now when we can release a new > one in 2-3 weeks and make sure it works properly with IJ too. > >> >> >>> >>> As for the state of the API, as the API is incubating we consider it >>> to be our best shot _so far_, but things might still change given >>> targeted feedback. Of course, the more we are iterating, the less >>> substantial API changes you are seeing. >> >> >> I did a casual look over some of the code and there are a number of >> mostly minor cleanups and API modifications that could be made IMO, >> although only one so far that I've seen could probably be called major: >> >> >> - AbstractLayout could be modified to use generics so that all layout >> types no longer need to override standard MemoryLayout withers. The >> Javadoc bug that prevented this from being done has long since been >> fixed(JDK-8224052) in JDK 14. I've made the changes already here: >> >> > Thanks for pointing that out - I think I tried that at some point but > it was still not working as I expected, but worth giving another try. It displays the "inherited from MemoryLayout" message and copies over the javadoc fine as far as I can tell. I wasn't sure specifically what the issue was. Netbeans doesn't like the Javadoc of the with* methods, but Netbeans is also buggy in general and no Javadoc is set either for the JDK. >> >> >> - Padding layout should probably be a subclass of ValueLayout and >> just override methods as needed. Having every memory layout have a >> isPadding() method doesn't make much sense. The PaddingLayout class >> can then be moved to an internal package as there is no way to create >> an instance outside of ofPaddingBits as an API user. The same could >> be done for AbstractLayout. > Are you talking about API or impl? Impl-wise, we could resort to > overriding for isPadding, but if PaddingLayout is to be impl-private, > then user has no way to do instanceof PaddingLayout, so you need a > predicate? Bit of both. ofValueBits can be modified to return a ValueLayout since, under this change, PaddingLayout extends ValueLayout and "is-a" ValueLayout. isPadding() will then be made exclusive to ValueLayout and would be how you determine if a ValueLayout is padding. If that method exists, I don't see a reason why exposing PaddingLayout as part of public API and letting a user do instanceof is needed as isPadding() exists. isPadding() should maybe use getClass() instead of instanceof, don't think it's a big deal but it's slightly faster IIRC. There isn't any reason to expose PaddingLayout or AbstractLayout in public API AFAIK. >> >> >> - GroupLayout should probably be split into StructLayout and >> UnionLayout. This is the biggest change, but it simplifies the code, >> provides better clarity on what's actually being represented, and >> allows for future struct/union specific operations to be added >> without adding a bunch of if(!isUnion) throw new >> UnsupportedOperationException(); type code. > > Less sure about this. > > I think pattern matching will also help a great deal with this, at > some point. My understanding is that you need a type to do pattern matching? The Kind enum used internally for isStruct() and isUnion() is private. If the issue is unifying the types then GroupLayout could maybe be repurposed so that it simply exposes memberLayouts() and other shared code? > >> >> >> This is just from me skimming the surface API code after submitting >> the OCA, there are probably more changes although I doubt there is >> anything major. > Thanks for the comment > > Maurizio >> >> >>> >>> Cheers >>> Maurizio >>> >>> >>> On 29/12/2020 21:12, Ty Young wrote: >>>> Yes, mostly. Things happen, especially on holidays when everyone >>>> has things to do and places to be. I was going to wait until after >>>> the new year to bring it up, but I had seen JDK developers replying >>>> to things so I figured they were back. >>>> >>>> >>>> A proper CI could have at least warned that there is an issue, just >>>> like other previous issues. Having newer JDK builds would be a >>>> benefit to projects like Panama as it reduces the hurdle to try out >>>> recent versions, especially those on Windows. Again, probably >>>> screaming into the void on the CI thing. >>>> >>>> >>>> On 12/29/20 5:21 AM, Samuel Audet wrote: >>>>> Hi, >>>>> >>>>> I think the point is that this could have been prevented with >>>>> proper CI. Since the repos are now on GitHub, OpenJDK could easily >>>>> benefit >>>>> from GitHub Actions... >>>>> >>>>> Samuel >>>>> >>>>> On Tue, Dec 29, 2020, 16:39 David Holmes >>>> > wrote: >>>>> >>>>> ??? On 29/12/2020 1:06 pm, Ty Young wrote: >>>>> ??? > >>>>> ??? > On 12/28/20 3:18 PM, Remi Forax wrote: >>>>> ??? >> ----- Mail original ----- >>>>> ??? >>> De: "Ty Young" >>>> ??? > >>>>> ??? >>> ?: "panama-dev at openjdk.java.net >>>>> ??? '" >>>>> ??? >>>> > >>>>> ??? >>> Envoy?: Lundi 28 D?cembre 2020 22:06:58 >>>>> ??? >>> Objet: Panama source code fails to compile >>>>> ??? >>> Just an FYI, the Panama source code have been broken since >>>>> before >>>>> ??? >>> Christmas with this error: >>>>> ??? >>> >>>>> ??? >>> >>>>> ??? >>> panama-foreign/src/hotspot/share/oops/methodData.cpp:1616:6: >>>>> ??? error: >>>>> ??? >>> redefinition of 'static bool >>>>> ??? MethodData::profile_memory_access(const >>>>> ??? >>> methodHandle&, int)' >>>>> ??? >>> ??1616 | bool MethodData::profile_memory_access(const >>>>> ??? methodHandle& m, >>>>> ??? >>> int bci) { >>>>> ??? >>> ?????? |????? ^~~~~~~~~~ >>>>> ??? >>> >>>>> /run/media/ty/Windows_Linux_Shared/OpenJDK/panama-foreign/src/hotspot/share/oops/methodData.cpp:1604:6: >>>>> >>>>> >>>>> ??? >>> >>>>> ??? >>> note: 'static bool MethodData::profile_memory_access(const >>>>> ??? >>> methodHandle&, int)' previously defined here >>>>> ??? >>> ??1604 | bool MethodData::profile_memory_access(const >>>>> ??? methodHandle& m, >>>>> ??? >>> int bci) { >>>>> ??? >>> ?????? | >>>>> ??? >>> >>>>> ??? >>> >>>>> ??? >>> I tried building using the usual `bash configure >>>>> ??? >>> --disable-warnings-as-errors` and `make images` on (Arch) >>>>> ??? Linux. I am >>>>> ??? >>> able to compile the standard JDK from source just fine. >>>>> ??? >>> >>>>> ??? >>> >>>>> ??? >>> I know I'm probably (metaphorically) screaming into the void >>>>> ??? here but... >>>>> ??? >>> people often have data caps and JDK source code is *A >>>>> LOT*. Not to >>>>> ??? >>> mention the CPU and memory requirements needed to compile >>>>> it in a >>>>> ??? >>> reasonable amount of time, which are massive. I suggested >>>>> ??? months ago on >>>>> ??? >>> the skara-dev list on having build succeeded/failed badges >>>>> and/or >>>>> ??? >>> automatic JDK builds but apparently no one is interested >>>>> ??? because it >>>>> ??? >>> hasn't been added. Is making sure your code compiles & runs >>>>> ??? before you >>>>> ??? >>> push it not a requirement for JDK developers or something? I >>>>> ??? understand >>>>> ??? >>> it was Christmas but this has happened a few times now. >>>>> ??? >> Usually for this kind of error, it's because you are compiling >>>>> ??? with a >>>>> ??? >> c++ compiler more recent than the one used by the CI, >>>>> ??? >> so the bug flies under the radar. >>>>> ??? > >>>>> ??? > >>>>> ??? > There is clearly a duplicate declaration: >>>>> ??? > >>>>> ??? > >>>>> ??? > >>>>> https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign/blob/5a8d47fd226708e46f56ec82294e9c786f6850c1/src/hotspot/share/oops/methodData.cpp*L1604__;Iw!!GqivPVa7Brio!ILC6p5xgmmz-ejxPQX_xGplLVDDWejZBFdTxXI-t04hinw_VlVp01-MoqnQmCM8LnniiGbY$ >>>>> >>>>> >>>> > >>>>> >>>>> ??? > >>>>> ??? > >>>>> ??? > >>>>> ??? > and >>>>> ??? > >>>>> ??? > >>>>> ??? > >>>>> https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign/blob/5a8d47fd226708e46f56ec82294e9c786f6850c1/src/hotspot/share/oops/methodData.cpp*L1616__;Iw!!GqivPVa7Brio!ILC6p5xgmmz-ejxPQX_xGplLVDDWejZBFdTxXI-t04hinw_VlVp01-MoqnQmCM8Ldyj5wAg$ >>>>> >>>>> >>>> > >>>>> >>>>> ??? > >>>>> ??? > >>>>> ??? > >>>>> ??? > are the same. Git blame shows that the duplicate was added 17 >>>>> ??? days ago: >>>>> ??? > >>>>> ??? > >>>>> ??? > >>>>> https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign/blame/5a8d47fd226708e46f56ec82294e9c786f6850c1/src/hotspot/share/oops/methodData.cpp*L1616__;Iw!!GqivPVa7Brio!ILC6p5xgmmz-ejxPQX_xGplLVDDWejZBFdTxXI-t04hinw_VlVp01-MoqnQmCM8L7aTmLhQ$ >>>>> >>>>> >>>> > >>>>> >>>>> >>>>> ??? I think I see what happened. >>>>> >>>>> ??? JDK-8257692 was fixed in the panama-foreign repo in >>>>> foreign-jextract >>>>> ??? branch. >>>>> >>>>> ??? JDK-8258242 was fixed in the mainline JDK and contained some of >>>>> ??? the same >>>>> ??? code changes. >>>>> >>>>> ??? A few days before Christmas there was an auto-merge between >>>>> ??? panama-foreign and mainline JDK, and that is when the >>>>> duplicate code >>>>> ??? chunk has arisen. >>>>> >>>>> ??? David >>>>> ??? ----- >>>>> >>>>> ??? > >>>>> ??? > >>>>> ??? > and removing the duplicate allows the JDK to build correctly. >>>>> ??? > >>>>> ??? > >>>>> ??? > So, no, this has nothing to do with the distro or the >>>>> compiler I >>>>> ??? use. >>>>> ??? > I've already been through this blame game nonsense on swing-dev >>>>> ??? with JDK >>>>> ??? > developers when they broke literally every Swing application >>>>> ??? that used >>>>> ??? > GTK L&F on Arch Linux, lets not do it again, please. >>>>> ??? > >>>>> ??? > >>>>> ??? >> >>>>> ??? >>> >>>>> ??? >>> Just a little annoyed, sorry. I try to always use the latest >>>>> ??? builds so I >>>>> ??? >>> don't have to constantly make large code changes, although >>>>> ??? there hasn't >>>>> ??? >>> been many changes lately, which is odd. Is Panama's API >>>>> nearly >>>>> ??? complete? >>>>> ??? >>> What's the state of Panama at this point? >>>>> ??? >> R?mi >>>>> From sebastian.stenzel at gmail.com Mon Jan 4 21:12:25 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Mon, 4 Jan 2021 22:12:25 +0100 Subject: Obtain MemorySegment from MemoryAddress for a given MemoryLayout In-Reply-To: References: <923683D7-2617-4053-923D-A3A687F58146@gmail.com> Message-ID: <7E789315-CC5C-46FF-8628-041E3F79B106@gmail.com> > On 4. Jan 2021, at 11:46, Jorn Vernee wrote: > > Hi, > > On 28/12/2020 19:15, Sebastian Stenzel wrote: >> During my latest experiments with Panama, I have to deal a lot with MemoryAddresses pointing to structs, that I need to access from Java: >> >> Let's say I have demo.h declaring my_struct: >> >> ``` >> struct my_struct { >> int foo; >> }; >> >> ``` >> >> If I run jextract on demo.h, it'll generate code that allows me to get "foo" from a segment, but not from an address: >> >> ``` >> int getFooFromMyStruct(MemoryAddress addr) { >> var segment = demo_h.my_struct.ofAddressRestricted(addr); // is there a better way, if I know the layout for sure? >> return demo_h.my_struct.foo$get(segment); // segment required here >> } >> ``` >> >> Now I'm wondering, if there is any safe (read: not restricted) way to obtain a MemorySegment for a given layout and address? > > No, there is no non-restricted variant for turning a MemoryAddress into a MemorySegment. The latter is directly dereferencable from Java (hence that being the required type for the getter), while the former is not. The conversion from a MemoryAddress to a MemorySegment needs to essentially attach a size to a pointer to define a region of dereferencable memory, but there is no way to mechanically check that the size being attached is actually correct. So, dereferencing the resulting MemorySegment can still result in crashes and/or silent memory corruption, and hence it is restricted functionality. > > Jorn > I understand that it is impossible to cast a "point" to a "region" without any additional information, thus considering this a "dangerous" operation seems reasonable. However, in case of jextract'ed code _any_ non-primitve parameter will essentially become a MemoryAddress, despite jextract knowing the exact type in many cases. Of course it is still black magic to create a segment from a `void *pointer`, but jextract knows the exact MemoryLayout of a `my_struct *pointer`. (Technically it might be possible for the native library to ignore type information and pass any address at runtime, but I'd consider this an upstream bug and nothing an API consumer in a strongly-typed environment should carry the can for. In other words: In this case, a crash seems legitimate, as it would have happened in any other language as well.) Long story short: Since jextract will give us MemoryAddresses (despite knowing the memory layout) almost all of the times (except for primitives), but at the same time generates code requires a segment (as you explained above), basically all projects that make use of this generated code will require `-Dforeign.restricted=permit`. Therefore I'm asking if jextract could give us some "safe" way to deal with addresses with a known layout. Maybe there could be some internal API only accessible from extracted code that doesn't require restricted operations? I understand that this might not be that easy and might even affect the design of JEP 370/383 significantly. From maurizio.cimadamore at oracle.com Mon Jan 4 21:21:04 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 4 Jan 2021 21:21:04 +0000 Subject: Panama source code fails to compile In-Reply-To: <28b7134b-4006-ea85-eb16-49571a1f1c20@gmail.com> References: <5ea52f78-f853-57df-7c7f-fa299b091c55@gmail.com> <409652537.261382.1609190287324.JavaMail.zimbra@u-pem.fr> <9a74ba5e-523a-e96d-4e60-8d66b6e0516f@gmail.com> <9045aa0c-5454-3b18-13a1-b39252a29622@gmail.com> <30df2329-2332-1b6f-bc5f-6fb40974ca60@oracle.com> <11035576-2e05-4b30-0135-2cdd611bd3b9@oracle.com> <28b7134b-4006-ea85-eb16-49571a1f1c20@gmail.com> Message-ID: On 04/01/2021 19:38, Ty Young wrote: >>> >>> >>> - Padding layout should probably be a subclass of ValueLayout and >>> just override methods as needed. Having every memory layout have a >>> isPadding() method doesn't make much sense. The PaddingLayout class >>> can then be moved to an internal package as there is no way to >>> create an instance outside of ofPaddingBits as an API user. The same >>> could be done for AbstractLayout. >> Are you talking about API or impl? Impl-wise, we could resort to >> overriding for isPadding, but if PaddingLayout is to be impl-private, >> then user has no way to do instanceof PaddingLayout, so you need a >> predicate? > > > Bit of both. ofValueBits can be modified to return a ValueLayout > since, under this change, PaddingLayout extends ValueLayout and "is-a" > ValueLayout. isPadding() will then be made exclusive to ValueLayout > and would be how you determine if a ValueLayout is padding. If that > method exists, I don't see a reason why exposing PaddingLayout as part > of public API and letting a user do instanceof is needed as > isPadding() exists. isPadding() should maybe use getClass() instead of > instanceof, don't think it's a big deal but it's slightly faster IIRC. > There isn't any reason to expose PaddingLayout or AbstractLayout in > public API AFAIK. Gotcha. Yes, in principle padding can be a special case of value - except then you have endianness thrown in as well which isn't horrible, but doesn't make a lot of sense either. My mental model is more: LeafLayout ValueLayout <: LeafLayout PaddingLayout <: LeafLayout which then led to the current compressed hierarchy. > > >>> >>> >>> - GroupLayout should probably be split into StructLayout and >>> UnionLayout. This is the biggest change, but it simplifies the code, >>> provides better clarity on what's actually being represented, and >>> allows for future struct/union specific operations to be added >>> without adding a bunch of if(!isUnion) throw new >>> UnsupportedOperationException(); type code. >> >> Less sure about this. >> >> I think pattern matching will also help a great deal with this, at >> some point. > > > My understanding is that you need a type to do pattern matching? The > Kind enum used internally for isStruct() and isUnion() is private. For now you need a type, yes. In the future, when pattern declaration will be available, we can add an extractor for each static factory there is in the API. if (layout instanceof GroupLayout.ofStruct(layoutA, layoutB)) { ? ... } Something like that. Maurizio > > > If the issue is unifying the types then GroupLayout could maybe be > repurposed so that it simply exposes memberLayouts() and other shared > code? > From maurizio.cimadamore at oracle.com Mon Jan 4 21:40:19 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 4 Jan 2021 21:40:19 +0000 Subject: Obtain MemorySegment from MemoryAddress for a given MemoryLayout In-Reply-To: <7E789315-CC5C-46FF-8628-041E3F79B106@gmail.com> References: <923683D7-2617-4053-923D-A3A687F58146@gmail.com> <7E789315-CC5C-46FF-8628-041E3F79B106@gmail.com> Message-ID: On 04/01/2021 21:12, Sebastian Stenzel wrote: >> On 4. Jan 2021, at 11:46, Jorn Vernee wrote: >> >> Hi, >> >> On 28/12/2020 19:15, Sebastian Stenzel wrote: >>> During my latest experiments with Panama, I have to deal a lot with MemoryAddresses pointing to structs, that I need to access from Java: >>> >>> Let's say I have demo.h declaring my_struct: >>> >>> ``` >>> struct my_struct { >>> int foo; >>> }; >>> >>> ``` >>> >>> If I run jextract on demo.h, it'll generate code that allows me to get "foo" from a segment, but not from an address: >>> >>> ``` >>> int getFooFromMyStruct(MemoryAddress addr) { >>> var segment = demo_h.my_struct.ofAddressRestricted(addr); // is there a better way, if I know the layout for sure? >>> return demo_h.my_struct.foo$get(segment); // segment required here >>> } >>> ``` >>> >>> Now I'm wondering, if there is any safe (read: not restricted) way to obtain a MemorySegment for a given layout and address? >> No, there is no non-restricted variant for turning a MemoryAddress into a MemorySegment. The latter is directly dereferencable from Java (hence that being the required type for the getter), while the former is not. The conversion from a MemoryAddress to a MemorySegment needs to essentially attach a size to a pointer to define a region of dereferencable memory, but there is no way to mechanically check that the size being attached is actually correct. So, dereferencing the resulting MemorySegment can still result in crashes and/or silent memory corruption, and hence it is restricted functionality. >> >> Jorn >> > I understand that it is impossible to cast a "point" to a "region" without any additional information, thus considering this a "dangerous" operation seems reasonable. > > However, in case of jextract'ed code _any_ non-primitve parameter will essentially become a MemoryAddress, despite jextract knowing the exact type in many cases. Of course it is still black magic to create a segment from a `void *pointer`, but jextract knows the exact MemoryLayout of a `my_struct *pointer`. > > (Technically it might be possible for the native library to ignore type information and pass any address at runtime, but I'd consider this an upstream bug and nothing an API consumer in a strongly-typed environment should carry the can for. In other words: In this case, a crash seems legitimate, as it would have happened in any other language as well.) > > Long story short: Since jextract will give us MemoryAddresses (despite knowing the memory layout) almost all of the times (except for primitives), but at the same time generates code requires a segment (as you explained above), basically all projects that make use of this generated code will require `-Dforeign.restricted=permit`. Therefore I'm asking if jextract could give us some "safe" way to deal with addresses with a known layout. Maybe there could be some internal API only accessible from extracted code that doesn't require restricted operations? > > I understand that this might not be that easy and might even affect the design of JEP 370/383 significantly. The problem with what you suggest is that the C type system is not expressive enough to capture what you really want to say. If you say that a function returns some type T*, you really don't know if it's one, two, or N Ts. So, while you know that the pointer points to a memory region whose size is likely to be some _multiple_ of sizeof(T), you still don't know what that size is. I understand that there might be some libraries in which T* always means "pointer to one T" but, in the general case, jextract cannot make that assumption. The idea we've been playing with is to add an extraction API, which can be used to inform jextract about constraints and idioms of a specific library - so that you could - e.g. turn all T* into a memory segment of the right layout, if you happen to know that this holds true for some functions in your library. But so far we've been focusing more on getting the basic jextract tool working on most library and we haven't spent too many cycles to make sure that the extraction API is usable enough. So, while there's a reasonable API modelling the AST that jextract works with, we don't have (yet) a very straightforward way for users to define their own transforms on said AST, in order to steer jextract generation in different ways. Cheers Maurizio From mcimadamore at openjdk.java.net Mon Jan 4 22:38:30 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 4 Jan 2021 22:38:30 GMT Subject: [foreign-memaccess+abi] RFR: Fix duplicate declaration in methodData.cpp Message-ID: <3rEaVYEzw0DdcRlqxJ-odxhz78l7KPSqCTDd1bLpKvw=.7fa31e56-574a-420d-afed-dce8acfe8f20@github.com> A recent automatic merge ended up creating a duplicate declaration of a function in methodData.cpp. This patch fixes that. Thanks to Ty for the fix. ------------- Commit messages: - Fix build issue Changes: https://git.openjdk.java.net/panama-foreign/pull/428/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=428&range=00 Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/428.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/428/head:pull/428 PR: https://git.openjdk.java.net/panama-foreign/pull/428 From paul.sandoz at oracle.com Mon Jan 4 23:11:43 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 4 Jan 2021 15:11:43 -0800 Subject: Comments / metadata in assembly listings don't make sense for code vectorized using Vector API In-Reply-To: References: Message-ID: Hi Piotr, Thanks for experimenting. The Intel folks have also experimented with Mandelbrot generation and might be able to comment with their experience in comparison. I would be interested to know what your expectations were with regards to speedup. It?s hard to evaluate without a JMH benchmark which can more easily present the code hotspots and isolate from the other areas, such as for thread parallelism. My recommendation would be to extract out the computeChunksVector kernel and embed within such a benchmark. Switching off tired compilation should help (-XX:-TiredCompilation) i.e. only C2, not C1, in getting to the C2 generated code faster. To your question about the assembly listing I believe as HotSpot goes through various compiler passes it tries to preserve the byte code index associated with generated instructions, but naturally as code is lowered this becomes an approximation, and especially so with the Vector API. In the case of "*synchronization entry?, this is stating the pseudo byte code index just before a method is entered. However, I think there is tech debt here, see https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/debugInfoRec.hpp#L67 And the usages of SynchronizationEntryBCI in hotspot code. Running in fast debug mode will present a slightly higher-level view of generated code. Here?s a snippet: 26e vmulpd XMM12,XMM7,XMM7 ! mul packedD 272 vaddpd XMM8,XMM0,XMM11 ! add packedD 277 vmulpd XMM9,XMM8,XMM8 ! mul packedD 27c vaddpd XMM0,XMM12,XMM9 ! add packedD 281 vector_compare XMM10,XMM5,XMM0,#3 ! 286 # TLS is in R15 286 cmpq RCX, [R15 + #344 (32-bit)] # raw ptr 28d jnb,u B47 P=0.000100 C=-1.000000 ? 2cf vmovdqu [rsp + 64],XMM1 # spill 2d5 B25: # out( B44 B26 ) <- in( B48 B24 ) Freq: 9114.56 2d5 2d5 # checkcastPP of RAX 2d5 vector_store_mask XMM1,XMM10 ! using XMM13 as TEMP 2f4 vector_loadmask_byte XMM15,XMM1 302 vmovdqu XMM1,[rsp + 448] # spill 30b vpor XMM1,XMM1,XMM15 ! or vectors 310 vector_store_mask XMM0,XMM1 ! using XMM14 as TEMP 32e store_vector [RAX + #16 (8-bit)],XMM0 333 vector_test RCX,XMM1, XMM2 ! using RFLAGS as TEMP nop # 2 bytes pad for loops and calls 340 testl RCX, RCX 342 je B44 P=0.108889 C=184362.000000 The mask instructions, such as vector_store_mask, are substituted for a more complex sequence of x86 instructions on AVX 2. I do notice that the inner loop (upper bound of 5) does unroll (FWIW, making the inner bound a power of 2 is more friendly for unrolling). There also appears to be many register spills, suggesting non-optimal vector register allocation/usage by C2. ? I noticed this in the code: // in Rust version this works fine, so where's the bug then? // cmpMask = vFours.lt(vZiN.add(vZrN)); What problem did you encounter? It works for me on the tip of https://github.com/openjdk/jdk. Paul. > On Dec 30, 2020, at 6:17 AM, Piotr Tarsa wrote: > > Hi all, > > Thanks for creating Project Panama! It looks promising. However, I've > made a try to vectorize some code and got somewhat disappointing > results. Therefore I wanted to look at the generated machine code to > see it it looks optimal. I've attached hsdis to JVM and enabled > assembly printing but the output doesn't make sense to me, i.e. the > instructions and comments / metadata don't seem to match. I may be > wrong as I've very rarely looked at assembly listing produced by JVM. > > Performance: > As a baseline I took > https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/mandelbrot-java-2.html > which takes about 3.05s to finish on my system. After vectorization > I've managed to achieve timings like 1.80s. That's quite disappointing > to me as I have a Haswell machine which has AVX2, high speed L1 > caches, etc I've tested on recent JDK 16 EA build from > http://jdk.java.net/16/ > > Link to the code and assembly listing: > https://gist.github.com/tarsa/7a9c80bb84c2dcd807be9cd16a655ee0 I'll > copy the source code again in this mail at the end. > > What I see in the assembly listings is e.g. > > 0x00007f0e208b8ab9: cmp r13d,0x7fffffc0 > 0x00007f0e208b8ac0: jg 0x00007f0e208b932c > 0x00007f0e208b8ac6: vmulpd ymm0,ymm6,ymm4 > 0x00007f0e208b8aca: vsubpd ymm1,ymm4,ymm4 > 0x00007f0e208b8ace: vmovdqu YMMWORD PTR [rsp+0xc0],ymm1 > 0x00007f0e208b8ad7: vmulpd ymm0,ymm0,ymm4 > ;*synchronization entry > ; - > jdk.internal.vm.vector.VectorSupport$VectorPayload::getPayload at -1 > (line 101) > ; - > jdk.incubator.vector.Double256Vector$Double256Mask::getBits at 1 (line > 557) > ; - > jdk.incubator.vector.AbstractMask::toLong at 24 (line 77) > ; - > mandelbrot_simd_1::computeChunksVector at 228 (line 187) > 0x00007f0e208b8adb: vaddpd ymm0,ymm0,ymm2 ;*checkcast > {reexecute=0 rethrow=0 return_oop=0} > ; - > jdk.incubator.vector.DoubleVector::fromArray0Template at 34 (line 3119) > ; - > jdk.incubator.vector.Double256Vector::fromArray0 at 3 (line 777) > ; - > jdk.incubator.vector.DoubleVector::fromArray at 24 (line 2564) > ; - > mandelbrot_simd_1::computeChunksVector at 95 (line 169) > 0x00007f0e208b8adf: vmovdqu YMMWORD PTR [rsp+0xe0],ymm0 > 0x00007f0e208b8ae8: vmulpd ymm0,ymm0,ymm0 > 0x00007f0e208b8aec: vmovdqu YMMWORD PTR [rsp+0x100],ymm0 > > How does vmulpd relate to a synchronization entry and > AbstrackMask::toLong? It seems way off to me. However, there maybe > some trick to understand it. Could you give me some guidelines on how > to intepret that? Are the comments describing lines below or above > them? > > Regards, > Piotr > > mandelbrot_simd_1.java source code: > import jdk.incubator.vector.DoubleVector; > import jdk.incubator.vector.VectorMask; > import jdk.incubator.vector.VectorSpecies; > > import java.io.BufferedOutputStream; > import java.io.IOException; > import java.io.OutputStream; > import java.nio.file.Files; > import java.nio.file.Path; > import java.util.concurrent.CountDownLatch; > import java.util.concurrent.ExecutorService; > import java.util.concurrent.Executors; > import java.util.concurrent.TimeUnit; > import java.util.stream.IntStream; > > public class mandelbrot_simd_1 { > private static final VectorSpecies SPECIES = > DoubleVector.SPECIES_PREFERRED.length() <= 8 ? > DoubleVector.SPECIES_PREFERRED : DoubleVector.SPECIES_512; > > private static final int LANES = SPECIES.length(); > > private static final int LANES_LOG = Integer.numberOfTrailingZeros(LANES); > > public static void main(String[] args) throws IOException { > if ((LANES > 8) || (LANES != (1 << LANES_LOG))) { > var errorMsg = "LANES must be a power of two and at most 8. " + > "Change SPECIES in the source code."; > throw new RuntimeException(errorMsg); > } > var sideLen = Integer.parseInt(args[0]); > try (var out = new BufferedOutputStream(makeOut1())) { > out.write(String.format("P4\n%d %d\n", sideLen, > sideLen).getBytes()); > computeAndOutputRows(out, sideLen); > } > } > > @SuppressWarnings("unused") > // the version that avoids mixing up output with JVM diagnostic messages > private static OutputStream makeOut1() throws IOException { > return Files.newOutputStream(Path.of("mandelbrot_simd_1.pbm")); > } > > // the version that is compatible with benchmark requirements > private static OutputStream makeOut2() { > return System.out; > } > > private static void computeAndOutputRows(OutputStream out, int sideLen) { > var poolFactor = 1000000 / sideLen; > if (poolFactor < 10) { > throw new RuntimeException("Too small poolFactor"); > } > var numCpus = Runtime.getRuntime().availableProcessors(); > var rowsPerBatch = numCpus * poolFactor; > var fac = 2.0 / sideLen; > var aCr = IntStream.range(0, sideLen).parallel() > .mapToDouble(x -> x * fac - 1.5).toArray(); > var bitsReversalMapping = computeBitsReversalMapping(); > var rowsPools = new byte[2][rowsPerBatch][(sideLen + 7) / 8]; > var rowsChunksPools = new long[2][rowsPerBatch][sideLen / 64]; > var batchSizes = new int[2]; > var batchCountDowns = new CountDownLatch[2]; > var computeEc = Executors.newWorkStealingPool(numCpus); > var masterThread = new Thread(() -> { > var rowsToProcess = sideLen; > var nextBatchStart = 0; > batchSizes[0] = 0; > batchCountDowns[0] = new CountDownLatch(0); > for (var poolId = 0; rowsToProcess > 0; poolId ^= 1) { > while (batchCountDowns[poolId].getCount() != 0) { > try { > batchCountDowns[poolId].await(); > } catch (InterruptedException ignored) { > } > } > batchCountDowns[poolId] = null; > > var nextBatchSize = > Math.min(sideLen - nextBatchStart, rowsPerBatch); > var nextPoolId = poolId ^ 1; > batchSizes[nextPoolId] = nextBatchSize; > batchCountDowns[nextPoolId] = new CountDownLatch(nextBatchSize); > sendTasks(fac, aCr, bitsReversalMapping, > rowsPools[nextPoolId], rowsChunksPools[nextPoolId], > nextBatchStart, nextBatchSize, > batchCountDowns[nextPoolId], computeEc); > nextBatchStart += nextBatchSize; > > var batchSize = batchSizes[poolId]; > try { > for (var rowIdx = 0; rowIdx < batchSize; rowIdx++) { > out.write(rowsPools[poolId][rowIdx]); > } > out.flush(); > } catch (IOException e) { > e.printStackTrace(); > System.exit(-1); > } > rowsToProcess -= batchSize; > } > > computeEc.shutdown(); > }); > masterThread.start(); > while (masterThread.isAlive() || !computeEc.isTerminated()) { > try { > @SuppressWarnings("unused") > var ignored = computeEc.awaitTermination(1, TimeUnit.DAYS); > masterThread.join(); > } catch (InterruptedException ignored) { > } > } > } > > private static void sendTasks(double fac, double[] aCr, > byte[] bitsReversalMapping, > byte[][] rows, long[][] rowsChunks, > int batchStart, int batchSize, > CountDownLatch poolsActiveWorkersCount, > ExecutorService computeEc) { > for (var i = 0; i < batchSize; i++) { > var indexInBatch = i; > var y = batchStart + i; > var Ci = y * fac - 1.0; > computeEc.submit(() -> { > try { > computeRow(Ci, aCr, bitsReversalMapping, > rows[indexInBatch], rowsChunks[indexInBatch]); > poolsActiveWorkersCount.countDown(); > } catch (Exception e) { > e.printStackTrace(); > System.exit(-1); > } > }); > } > } > > private static byte[] computeBitsReversalMapping() { > var bitsReversalMapping = new byte[256]; > for (var i = 0; i < 256; i++) { > bitsReversalMapping[i] = (byte) (Integer.reverse(i) >>> 24); > } > return bitsReversalMapping; > } > > private static void computeRow(double Ci, double[] aCr, > byte[] bitsReversalMapping, > byte[] row, long[] rowChunks) { > computeChunksVector(Ci, aCr, rowChunks); > transferRowFlags(rowChunks, row, bitsReversalMapping); > computeRemainderScalar(aCr, row, Ci); > } > > private static void computeChunksVector(double Ci, double[] aCr, > long[] rowChunks) { > var sideLen = aCr.length; > var vCi = DoubleVector.broadcast(SPECIES, Ci); > var vZeroes = DoubleVector.zero(SPECIES); > var vTwos = DoubleVector.broadcast(SPECIES, 2.0); > var vFours = DoubleVector.broadcast(SPECIES, 4.0); > var zeroMask = VectorMask.fromLong(SPECIES, 0); > // (1 << 6) = 64 = length of long in bits > for (var xBase = 0; xBase < (sideLen & ~(1 << 6)); xBase += (1 << 6)) { > var cmpFlags = 0L; > for (var xInc = 0; xInc < (1 << 6); xInc += LANES) { > var vZr = vZeroes; > var vZi = vZeroes; > var vCr = DoubleVector.fromArray(SPECIES, aCr, xBase + xInc); > var vZrN = vZeroes; > var vZiN = vZeroes; > var cmpMask = zeroMask; > for (var outer = 0; outer < 10; outer++) { > for (var inner = 0; inner < 5; inner++) { > vZi = vTwos.mul(vZr).mul(vZi).add(vCi); > vZr = vZrN.sub(vZiN).add(vCr); > vZiN = vZi.mul(vZi); > vZrN = vZr.mul(vZr); > } > cmpMask = cmpMask.or(vFours.lt(vZiN.add(vZrN))); > // in Rust version this works fine, so where's the bug then? > // cmpMask = vFours.lt(vZiN.add(vZrN)); > if (cmpMask.allTrue()) { > break; > } > } > cmpFlags |= cmpMask.toLong() << xInc; > } > rowChunks[xBase >> 6] = cmpFlags; > } > } > > private static void transferRowFlags(long[] rowChunks, byte[] row, > byte[] bitsReversalMapping) { > for (var i = 0; i < rowChunks.length; i++) { > var group = ~rowChunks[i]; > row[i * 8 + 7] = bitsReversalMapping[0xff & (byte) (group >>> 56)]; > row[i * 8 + 6] = bitsReversalMapping[0xff & (byte) (group >>> 48)]; > row[i * 8 + 5] = bitsReversalMapping[0xff & (byte) (group >>> 40)]; > row[i * 8 + 4] = bitsReversalMapping[0xff & (byte) (group >>> 32)]; > row[i * 8 + 3] = bitsReversalMapping[0xff & (byte) (group >>> 24)]; > row[i * 8 + 2] = bitsReversalMapping[0xff & (byte) (group >>> 16)]; > row[i * 8 + 1] = bitsReversalMapping[0xff & (byte) (group >>> 8)]; > row[i * 8] = bitsReversalMapping[0xff & (byte) group]; > } > } > > private static void computeRemainderScalar(double[] aCr, byte[] > row, double Ci) { > var sideLen = aCr.length; > var bits = 0; > for (var x = sideLen & ~(1 << 6); x < sideLen; x++) { > var Zr = 0.0; > var Zi = 0.0; > var Cr = aCr[x]; > var i = 50; > var ZrN = 0.0; > var ZiN = 0.0; > do { > Zi = 2.0 * Zr * Zi + Ci; > Zr = ZrN - ZiN + Cr; > ZiN = Zi * Zi; > ZrN = Zr * Zr; > } while (ZiN + ZrN <= 4.0 && --i > 0); > bits <<= 1; > bits += i == 0 ? 1 : 0; > if (x % 8 == 7) { > row[x / 8] = (byte) bits; > bits = 0; > } > } > if (sideLen % 8 != 0) { > row[sideLen / 8] = (byte) bits; > } > } > } From psandoz at openjdk.java.net Mon Jan 4 23:16:06 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 4 Jan 2021 23:16:06 GMT Subject: [foreign-memaccess+abi] RFR: Fix duplicate declaration in methodData.cpp In-Reply-To: <3rEaVYEzw0DdcRlqxJ-odxhz78l7KPSqCTDd1bLpKvw=.7fa31e56-574a-420d-afed-dce8acfe8f20@github.com> References: <3rEaVYEzw0DdcRlqxJ-odxhz78l7KPSqCTDd1bLpKvw=.7fa31e56-574a-420d-afed-dce8acfe8f20@github.com> Message-ID: On Mon, 4 Jan 2021 22:23:34 GMT, Maurizio Cimadamore wrote: > A recent automatic merge ended up creating a duplicate declaration of a function in methodData.cpp. This patch fixes that. Thanks to Ty for the fix. Marked as reviewed by psandoz (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/428 From paul.sandoz at oracle.com Mon Jan 4 23:23:48 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 4 Jan 2021 15:23:48 -0800 Subject: BLAS and Vector API In-Reply-To: <5B7E46D7-50CB-4AD6-8C43-12C93144B355@oracle.com> References: <5B7E46D7-50CB-4AD6-8C43-12C93144B355@oracle.com> Message-ID: Looks like the attachment was removed by the mailing list bot, adding inline for the benefit of those not explicitly in the To/CC list. Paul. import jdk.incubator.vector.FloatVector; import jdk.incubator.vector.VectorSpecies; import org.openjdk.jmh.annotations.Benchmark; import org.openjdk.jmh.annotations.BenchmarkMode; import org.openjdk.jmh.annotations.CompilerControl; import org.openjdk.jmh.annotations.Fork; import org.openjdk.jmh.annotations.Measurement; import org.openjdk.jmh.annotations.Mode; import org.openjdk.jmh.annotations.OutputTimeUnit; import org.openjdk.jmh.annotations.Scope; import org.openjdk.jmh.annotations.Setup; import org.openjdk.jmh.annotations.State; import org.openjdk.jmh.annotations.Warmup; import java.util.concurrent.ThreadLocalRandom; import java.util.concurrent.TimeUnit; @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @State(Scope.Thread) // Startup / Teardown / time done with single thread @Warmup(iterations = 10, time = 1) @Measurement(iterations = 10, time = 1) @Fork(value = 1, jvmArgsPrepend = {"--add-modules=jdk.incubator.vector", "--enable-preview"}) public class TestKernel { int k_iter; float[] a, b, c; @Setup public void setup() { k_iter = 100; a = new float[k_iter * 6]; fill(a); b = new float[k_iter * 16]; fill(b); c = new float[2048 * 6]; } @Benchmark @CompilerControl(value = CompilerControl.Mode.DONT_INLINE) public float[] vector() { kernel_6x16(k_iter, a, 0, b, 0, c, 0, 2048, 1); return c; } static final VectorSpecies SPECIES_256 = FloatVector.SPECIES_256; static void kernel_6x16( int k_iter, float[] a, int a_offset, float[] b, int b_offset, float[] c, int c_offset, int rs_c, int cs_c) { // For now, we ONLY accept row-major layout: if (cs_c != 1) { throw new IllegalArgumentException("Row major storage only"); } FloatVector AxB_0L, AxB_0R; AxB_0L = FloatVector.zero(SPECIES_256); AxB_0R = FloatVector.zero(SPECIES_256); FloatVector AxB_1L, AxB_1R; AxB_1L = FloatVector.zero(SPECIES_256); AxB_1R = FloatVector.zero(SPECIES_256); FloatVector AxB_2L, AxB_2R; AxB_2L = FloatVector.zero(SPECIES_256); AxB_2R = FloatVector.zero(SPECIES_256); FloatVector AxB_3L, AxB_3R; AxB_3L = FloatVector.zero(SPECIES_256); AxB_3R = FloatVector.zero(SPECIES_256); FloatVector AxB_4L, AxB_4R; AxB_4L = FloatVector.zero(SPECIES_256); AxB_4R = FloatVector.zero(SPECIES_256); FloatVector AxB_5L, AxB_5R; AxB_5L = FloatVector.zero(SPECIES_256); AxB_5R = FloatVector.zero(SPECIES_256); // Cycle through two rows of B, then repeat: int b_upper = b_offset + k_iter * 16; for (int b_iter = b_offset, a_iter = a_offset; b_iter < b_upper; b_iter += 16, a_iter += 6) { // for (int k = 0; k < k_iter; k++) { // int b_iter = b_offset + k * 16; // int a_iter = a_offset + k * 6; FloatVector B_0L = FloatVector.fromArray(SPECIES_256, b, b_iter); FloatVector B_0R = FloatVector.fromArray(SPECIES_256, b, b_iter + 8); FloatVector vbr_a0 = FloatVector.broadcast(SPECIES_256, a[a_iter + 0]); FloatVector vbr_a1 = FloatVector.broadcast(SPECIES_256, a[a_iter + 1]); // Row 0: AxB_0L = B_0L.fma(vbr_a0, AxB_0L); AxB_0R = B_0R.fma(vbr_a0, AxB_0R); // Row 1: AxB_1L = B_0L.fma(vbr_a1, AxB_1L); AxB_1R = B_0R.fma(vbr_a1, AxB_1R); vbr_a0 = FloatVector.broadcast(SPECIES_256, a[a_iter + 2]); vbr_a1 = FloatVector.broadcast(SPECIES_256, a[a_iter + 3]); // Row 2: AxB_2L = B_0L.fma(vbr_a0, AxB_2L); AxB_2R = B_0R.fma(vbr_a0, AxB_2R); // Row 3: AxB_3L = B_0L.fma(vbr_a1, AxB_3L); AxB_3R = B_0R.fma(vbr_a1, AxB_3R); vbr_a0 = FloatVector.broadcast(SPECIES_256, a[a_iter + 4]); vbr_a1 = FloatVector.broadcast(SPECIES_256, a[a_iter + 5]); // Row 4: AxB_4L = B_0L.fma(vbr_a0, AxB_4L); AxB_4R = B_0R.fma(vbr_a0, AxB_4R); // Row 5: AxB_5L = B_0L.fma(vbr_a1, AxB_5L); AxB_5R = B_0R.fma(vbr_a1, AxB_5R); } int c_row_iter = c_offset; AxB_0L.intoArray(c, c_row_iter); AxB_0R.intoArray(c, c_row_iter + 8); c_row_iter += rs_c; AxB_1L.intoArray(c, c_row_iter); AxB_1R.intoArray(c, c_row_iter + 8); c_row_iter += rs_c; AxB_2L.intoArray(c, c_row_iter); AxB_2R.intoArray(c, c_row_iter + 8); c_row_iter += rs_c; AxB_3L.intoArray(c, c_row_iter); AxB_3R.intoArray(c, c_row_iter + 8); c_row_iter += rs_c; AxB_4L.intoArray(c, c_row_iter); AxB_4R.intoArray(c, c_row_iter + 8); c_row_iter += rs_c; AxB_5L.intoArray(c, c_row_iter); AxB_5R.intoArray(c, c_row_iter + 8); } static void fill(float[] a) { for (int i = 0; i < a.length; i++) { a[i] = ThreadLocalRandom.current().nextFloat(); } } } > On Dec 23, 2020, at 9:33 AM, Paul Sandoz wrote: > > Hi Ludovic, > > Thanks for sharing, I shall look at this in more detail. > > In the interim, you may be interested in the following paper > > https://arxiv.org/pdf/1904.05717v1.pdf > > Attaining peak performance is as much about data movement as it is about the kernel. > > From this paper and BLIS Flame I wrote a kernel using the Vector API with some help from a colleague, supporting C += A * B, where C is updated in place (counter intuitively, to me at least initially, the columns of A are multiple by the rows of B). > > Attached is a kernel optimized for AVX2. The code gen is not bad. Register allocation is good. Bounds checking could be improved. Feel free to use it as you see fit. > > A useful experiment would be to wrap this kernel around the higher loops (with data movement) and see how the whole implementation behaves. > > ? > > On alignment. The problem is higher alignment of Java arrays is not stable. The array could be moved by GC. Further, it gets more difficult when there are two or more arrays at different alignments. The best way to fix this IMHO is to support the Panama Memory API using native memory that is explicitly aligned. > > Paul. From uschindler at apache.org Mon Jan 4 23:53:29 2021 From: uschindler at apache.org (Uwe Schindler) Date: Tue, 5 Jan 2021 00:53:29 +0100 Subject: [foreign-memaccess] musing on the memory access API In-Reply-To: <1a830d5e-233c-e54e-6b3c-d679c7297410@oracle.com> References: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> <083001d6e2c9$1aae9040$500bb0c0$@apache.org> <1a830d5e-233c-e54e-6b3c-d679c7297410@oracle.com> Message-ID: <08af01d6e2f4$cdae0600$690a1200$@apache.org> Hi Maurizio, > Thanks for the feedback Uwe, and for the bug reports. We'll do our best > to address some of them quickly (the NPE and the error in > Unmapper::address). As for adding an overload for mapping a segment from > a FileChannel I'm totally open to it, but I think it's late-ish now to > add API changes, since we are in stabilization. Hi, this was only a suggestion to improve the whole thing. My idea is more to wait for this until a more close integration into the FileSystem API is done. The main issue we had was that we can only pass a path from the default file system provider (I have a workaround for that, so during our testsuite we "unwrap" all the layers on top). But correctly, the FileSystem implementation should provide the way how to get a MemorySegment from the FileChannel, the current cast to the internal class is ... hacky! I know why it is like that (preview and it's not part of java base, so the FileSystem interface in java.base can't return a MemorySegment). But when Panama graduates, the filesystem integration is a must!: FileChannel should be extended by one "default" method throwing UOE, only implemented by default provider: "MemorySegment FileChannel.mapSegment(long offset, long size, MapMode mode)" > Also, thanks for the thoughts on the API in general - I kind of expected > (given our discussions) that shared segments were 90% of what you needed > - and that you are not much interested in using confinement. I agree > that, when working from that angle, the API looks mostly ok. But not all > clients have same requirements and some would like to take advantage of > confinement more - also, note that if we just drop support for confined > segments (which is something we also thought about) and just offered > shared access, _all_ clients will be stuck with a very slow close() > operation. Hi, yes, I agree. I just said: Switching between those modes is unlikely, but yet a confined default for long living segments is correct, shared for long living ones (this is also the usage pattern: something that ?lives very long is very likely often also used by many threads, like a database file or some database off-heap cache). Allocated memory used in netty is of course often short-lived, but it is in most cases not really concurrently used (or you can avoid it). I'd give the user the option on constructing, but don't allow to change it later. > There are very different ways to use a memory segment; sometimes (as in > your case) a memory segment is long-lived, and you don't care if closing > it takes 1 us. But there are other cases where segments are created (and > disposed) more frequently. To me, the interesting fact that emerged from > the Netty experiment (thanks guys!) was that using handoff AND shared > segment, while nice on paper it's not going to work performance-wise, > because you need to do an expensive close at each hand-off. This might > be rectified, for instance by making the API more complex, and have a > state where a segment has no owner (e.g. so that instead of confined(A) > -> shared -> confined(B) you do confined(A) -> detached -> confined(B) > ), but the risk is that to add a lot of API complexity ("detached" is a > brand new segment state in which the segment is not accessible, but > where memory is not yet deallocated) for what might be perceived as a > corner case. > So, the big question here is - given that there are defo different modes > to interact with this API (short lived vs. long lived segment), what API > allows us to capture the use cases we want in the simplest way possible? > While dynamic ownership changes look like a cool idea on paper, it also > add complexity - so I think now it's the right time to ask ourself if we > should scale back on that a bit and have a more "static" set of flavors > to pick from (e.g. { confined, shared } x { explicit, cleaner } I think, when "allocating" a segment (by reserving memory, mapping a file, supplying some external MemoryAddress and length), you should set confined or shared from the beginning, without a possibility to change it. This would indeed simplify many things. I got new benchmarks a minute ago from my Lucene colleagues: the current MemorySegmentAPI seems 40% slower than ByteBuffer for some use cases, but equal of speed/faster for other use cases (I assume it is still long vs. int index/looping problems; a for loop using LONG is not as good optimized as a for loop with INT -- correct?). But without diving too deep, it might also come from the fact that the memory segments *may* change their state, so hotspot is not able to do all optimizations. > Cheers > Maurizio P.S.: From my first analysis: access using the long index seems slower than MappedByteBuffer with the int position/index. Memory copy of byte blocks between memory segment and heap array seem fast, although I would have expected an overhead by constructing the views/slices on the byte[] and long[] on heap just to call copyFrom(): ; I will keep you informed what I find out and why (and when) it is slower than MappedByteBuffer. From github.com+10172435+bluegoliath at openjdk.java.net Tue Jan 5 00:41:12 2021 From: github.com+10172435+bluegoliath at openjdk.java.net (Ty Young) Date: Tue, 5 Jan 2021 00:41:12 GMT Subject: [foreign-memaccess+abi] RFR: Removed duplicate profile_memory_access function from methodData.cpp Message-ID: Removes the duplicate profile_memory_access function from methodData.cpp, which causes a build fail. This duplicate function does not exist in the foreign-jextract branch as there hasn't been a merge yet from foreign-memaccess+abi. Note: OCA filled out and sent but needs to be processed and my Github account needs to be registered. If it takes too long due to the holidays then I'll rescind the pull request. Note: 2 this is a resubmit to fix same-branch pull request issue the OpenJDK bot brought up. ------------- Commit messages: - Removed duplicate profile_memory_access function from methodData.cpp Changes: https://git.openjdk.java.net/panama-foreign/pull/427/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=427&range=00 Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/427.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/427/head:pull/427 PR: https://git.openjdk.java.net/panama-foreign/pull/427 From robilad at openjdk.java.net Tue Jan 5 00:49:06 2021 From: robilad at openjdk.java.net (Dalibor Topic) Date: Tue, 5 Jan 2021 00:49:06 GMT Subject: [foreign-memaccess+abi] RFR: Removed duplicate profile_memory_access function from methodData.cpp In-Reply-To: References: Message-ID: On Sat, 2 Jan 2021 21:13:01 GMT, Ty Young wrote: > Removes the duplicate profile_memory_access function from methodData.cpp, which causes a build fail. This duplicate function does not exist in the foreign-jextract branch as there hasn't been a merge yet from foreign-memaccess+abi. > > Note: OCA filled out and sent but needs to be processed and my Github account needs to be registered. If it takes too long due to the holidays then I'll rescind the pull request. > > Note: 2 this is a resubmit to fix same-branch pull request issue the OpenJDK bot brought up. Thank you for sending in an OCA for processing. I have marked your account as verified. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/427 From samuel.audet at gmail.com Tue Jan 5 00:56:54 2021 From: samuel.audet at gmail.com (Samuel Audet) Date: Tue, 5 Jan 2021 09:56:54 +0900 Subject: BLAS and Vector API In-Reply-To: <73bdce09-f9ca-896a-c68e-d39705cf846c@oracle.com> References: <7264552B-57D9-40CD-92CA-7BBFA7FD7324@ORACLE.COM> <73bdce09-f9ca-896a-c68e-d39705cf846c@oracle.com> Message-ID: <5fa57578-61c4-9def-e6a0-0ebed6b86732@gmail.com> Hi, Maurizio, On 1/5/21 1:22 AM, Maurizio Cimadamore wrote: > > On 04/01/2021 14:52, Samuel Audet wrote: >> Hi, Ludovic, >> >> On 1/4/21 10:48 PM, Ludovic Henry wrote: >>> I?ll also explore using the Foreign Linker API to wrap the OpenBLAS >>> library without going through JNI. I?m curious whether it?s going to >>> lead to performance improvements. >> >> No, not yet, it won't, since that still uses JNI: >> https://github.com/microsoft/onnxruntime/pull/4329#issuecomment-673848183 > > Where did you get this information from? The comment you quote shows my > reply and then you somehow (erroneously) inferring that the linker API > is based on JNI. > > The Foreign Linker API support has very little to do with JNI support. > Of course, since some of the stuff the VM has to do to go from Java to > native are the same, performances might not be too different (unless > state transitions are removed, which is possible with the linker API). OpenJDK hasn't been providing a lot of updates about the status of the various Panama APIs for a year or so now, so I can only assume that things had not changed. Also, since you're not replying to messages containing information about what you said of the state of things in the past (that the foreign API was using JNI, I can dig up the specific message if you want), I simply assumed that things had not changed! Sorry about that I'll say it again: Keeping all this information "internal" isn't helping the community. I understand that you probably don't have any say in this, that it's all about policies at Oracle, so please don't take it personally. As usual, thanks for updating us with the information you can provide. Samuel From stefan.reich.maker.of.eye at googlemail.com Tue Jan 5 01:31:28 2021 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Tue, 5 Jan 2021 02:31:28 +0100 Subject: Calculating integral images / cumulative add Message-ID: Hi, I am trying to vectorize my routine that constructs an integral image / "summed-area table" . int i = 0; for (int y = 0; y < h; y++) { int sum = 0; for (int x = 0; x < w; x++) { sum += image[i]; data[i] = y > 0 ? sum + data[i-w] : sum; i++; } } In order to use the Vector API, I'd need an operation that does a cumulative summing over the lanes, e.g. for a 4-component vector: b[0] = a[0] b[1] = a[0]+a[1] b[2] = a[0]+a[1]+a[2] b[3] = a[0]+a[1]+a[2]+a[3] I don't think this is available in the current Vector API, is it? Thanks, Stefan -- Stefan Reich BotCompany.de // Java-based operating systems From stefan.reich.maker.of.eye at googlemail.com Tue Jan 5 01:51:59 2021 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Tue, 5 Jan 2021 02:51:59 +0100 Subject: Calculating integral images / cumulative add In-Reply-To: References: Message-ID: Oh I just saw this in the presentation : ? Segmented scan (reduce with partials and mask-driven reset) That's probably what I want... so it's not there yet? On Tue, 5 Jan 2021 at 02:31, Stefan Reich < stefan.reich.maker.of.eye at googlemail.com> wrote: > Hi, > > I am trying to vectorize my routine that constructs an integral image / "summed-area > table" . > > int i = 0; > for (int y = 0; y < h; y++) { > int sum = 0; > for (int x = 0; x < w; x++) { > sum += image[i]; > data[i] = y > 0 ? sum + data[i-w] : sum; > i++; > } > } > > In order to use the Vector API, I'd need an operation that does a > cumulative summing over the lanes, e.g. for a 4-component vector: > > b[0] = a[0] > b[1] = a[0]+a[1] > b[2] = a[0]+a[1]+a[2] > b[3] = a[0]+a[1]+a[2]+a[3] > > I don't think this is available in the current Vector API, is it? > > Thanks, > Stefan > > -- > Stefan Reich > BotCompany.de // Java-based operating systems > -- Stefan Reich BotCompany.de // Java-based operating systems From whuang at openjdk.java.net Tue Jan 5 08:22:23 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 5 Jan 2021 08:22:23 GMT Subject: [vectorIntrinsics] RFR: 8258072: Add Reinterpret nodes implementation for Arm SVE [v4] In-Reply-To: References: Message-ID: > Add reinterpret nodes implementation for Arm SVE. We also adjust the implementation of Matcher::min_vector_size in the same patch. Wang Huang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8258072: Add Reinterpret nodes implementation for Arm SVE ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/29/files - new: https://git.openjdk.java.net/panama-vector/pull/29/files/125a7e14..d4213e84 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=29&range=03 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=29&range=02-03 Stats: 117 lines in 3 files changed: 90 ins; 3 del; 24 mod Patch: https://git.openjdk.java.net/panama-vector/pull/29.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/29/head:pull/29 PR: https://git.openjdk.java.net/panama-vector/pull/29 From jorn.vernee at oracle.com Tue Jan 5 08:30:20 2021 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Tue, 5 Jan 2021 09:30:20 +0100 Subject: Obtain MemorySegment from MemoryAddress for a given MemoryLayout In-Reply-To: <7E789315-CC5C-46FF-8628-041E3F79B106@gmail.com> References: <923683D7-2617-4053-923D-A3A687F58146@gmail.com> <7E789315-CC5C-46FF-8628-041E3F79B106@gmail.com> Message-ID: On 04/01/2021 22:12, Sebastian Stenzel wrote: >> On 4. Jan 2021, at 11:46, Jorn Vernee wrote: >> >> Hi, >> >> On 28/12/2020 19:15, Sebastian Stenzel wrote: >>> During my latest experiments with Panama, I have to deal a lot with MemoryAddresses pointing to structs, that I need to access from Java: >>> >>> Let's say I have demo.h declaring my_struct: >>> >>> ``` >>> struct my_struct { >>> int foo; >>> }; >>> >>> ``` >>> >>> If I run jextract on demo.h, it'll generate code that allows me to get "foo" from a segment, but not from an address: >>> >>> ``` >>> int getFooFromMyStruct(MemoryAddress addr) { >>> var segment = demo_h.my_struct.ofAddressRestricted(addr); // is there a better way, if I know the layout for sure? >>> return demo_h.my_struct.foo$get(segment); // segment required here >>> } >>> ``` >>> >>> Now I'm wondering, if there is any safe (read: not restricted) way to obtain a MemorySegment for a given layout and address? >> No, there is no non-restricted variant for turning a MemoryAddress into a MemorySegment. The latter is directly dereferencable from Java (hence that being the required type for the getter), while the former is not. The conversion from a MemoryAddress to a MemorySegment needs to essentially attach a size to a pointer to define a region of dereferencable memory, but there is no way to mechanically check that the size being attached is actually correct. So, dereferencing the resulting MemorySegment can still result in crashes and/or silent memory corruption, and hence it is restricted functionality. >> >> Jorn >> > I understand that it is impossible to cast a "point" to a "region" without any additional information, thus considering this a "dangerous" operation seems reasonable. > > However, in case of jextract'ed code _any_ non-primitve parameter will essentially become a MemoryAddress, despite jextract knowing the exact type in many cases. Of course it is still black magic to create a segment from a `void *pointer`, but jextract knows the exact MemoryLayout of a `my_struct *pointer`. > > (Technically it might be possible for the native library to ignore type information and pass any address at runtime, but I'd consider this an upstream bug and nothing an API consumer in a strongly-typed environment should carry the can for. In other words: In this case, a crash seems legitimate, as it would have happened in any other language as well.) > > Long story short: Since jextract will give us MemoryAddresses (despite knowing the memory layout) almost all of the times (except for primitives), but at the same time generates code requires a segment (as you explained above), basically all projects that make use of this generated code will require `-Dforeign.restricted=permit`. Therefore I'm asking if jextract could give us some "safe" way to deal with addresses with a known layout. Maybe there could be some internal API only accessible from extracted code that doesn't require restricted operations? > > I understand that this might not be that easy and might even affect the design of JEP 370/383 significantly. Note that `-Dforeign.restricted=permit` is required any ways when using jextract bindings because using CLinker requires it (unless you never plan to call any functions from the generated bindings). The safe way to deal with MemoryAddresses is to not dereference them at all, which doesn't require them to be converted? to MemorySegments. I.e. no restricted operation is needed in that case. Addresses with a known layout should already be MemorySegments (e.g. a MS returned by allocateNative), and can already be dereferenced without using restricted operations. "Technically it might be possible for the native library to ignore type information and pass any address at runtime, but I'd consider this an upstream bug and nothing an API consumer in a strongly-typed environment should carry the can for. In other words: In this case, a crash seems legitimate, as it would have happened in any other language as well." Note that foreign.restricted does not draw a line between legitimate and illegitimate crashes. It draws a line between crashes and no crashes (or silent memory corruption). The goal of this API is to allow interop with native libraries, not to allow writing native code in Java. However, some operations are required that do not conform to Java's safety standards (those that can cause VM crashes), and these are marked as restricted for that reason. Jorn From sebastian.stenzel at gmail.com Tue Jan 5 08:44:37 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Tue, 5 Jan 2021 09:44:37 +0100 Subject: Obtain MemorySegment from MemoryAddress for a given MemoryLayout In-Reply-To: References: <923683D7-2617-4053-923D-A3A687F58146@gmail.com> <7E789315-CC5C-46FF-8628-041E3F79B106@gmail.com> Message-ID: <94615FF0-B2B7-4FCE-B58B-0840DC75953D@gmail.com> > On 5. Jan 2021, at 09:30, Jorn Vernee wrote: > > > On 04/01/2021 22:12, Sebastian Stenzel wrote: >>> On 4. Jan 2021, at 11:46, Jorn Vernee wrote: >>> >>> Hi, >>> >>> On 28/12/2020 19:15, Sebastian Stenzel wrote: >>>> During my latest experiments with Panama, I have to deal a lot with MemoryAddresses pointing to structs, that I need to access from Java: >>>> >>>> Let's say I have demo.h declaring my_struct: >>>> >>>> ``` >>>> struct my_struct { >>>> int foo; >>>> }; >>>> >>>> ``` >>>> >>>> If I run jextract on demo.h, it'll generate code that allows me to get "foo" from a segment, but not from an address: >>>> >>>> ``` >>>> int getFooFromMyStruct(MemoryAddress addr) { >>>> var segment = demo_h.my_struct.ofAddressRestricted(addr); // is there a better way, if I know the layout for sure? >>>> return demo_h.my_struct.foo$get(segment); // segment required here >>>> } >>>> ``` >>>> >>>> Now I'm wondering, if there is any safe (read: not restricted) way to obtain a MemorySegment for a given layout and address? >>> No, there is no non-restricted variant for turning a MemoryAddress into a MemorySegment. The latter is directly dereferencable from Java (hence that being the required type for the getter), while the former is not. The conversion from a MemoryAddress to a MemorySegment needs to essentially attach a size to a pointer to define a region of dereferencable memory, but there is no way to mechanically check that the size being attached is actually correct. So, dereferencing the resulting MemorySegment can still result in crashes and/or silent memory corruption, and hence it is restricted functionality. >>> >>> Jorn >>> >> I understand that it is impossible to cast a "point" to a "region" without any additional information, thus considering this a "dangerous" operation seems reasonable. >> >> However, in case of jextract'ed code _any_ non-primitve parameter will essentially become a MemoryAddress, despite jextract knowing the exact type in many cases. Of course it is still black magic to create a segment from a `void *pointer`, but jextract knows the exact MemoryLayout of a `my_struct *pointer`. >> >> (Technically it might be possible for the native library to ignore type information and pass any address at runtime, but I'd consider this an upstream bug and nothing an API consumer in a strongly-typed environment should carry the can for. In other words: In this case, a crash seems legitimate, as it would have happened in any other language as well.) >> >> Long story short: Since jextract will give us MemoryAddresses (despite knowing the memory layout) almost all of the times (except for primitives), but at the same time generates code requires a segment (as you explained above), basically all projects that make use of this generated code will require `-Dforeign.restricted=permit`. Therefore I'm asking if jextract could give us some "safe" way to deal with addresses with a known layout. Maybe there could be some internal API only accessible from extracted code that doesn't require restricted operations? >> >> I understand that this might not be that easy and might even affect the design of JEP 370/383 significantly. > > Note that `-Dforeign.restricted=permit` is required any ways when using jextract bindings because using CLinker requires it (unless you never plan to call any functions from the generated bindings). I see, I wasn't aware of this. I had the impression that there was a way to link against shared libraries in a non-restricted way and applications, as I'm used to using such flags from other scenarios (such as in JPMS) only if I'm "misbehaving" somehow. Since this assumption was false, I think my original question became obsolete. Thanks for the explanation! > > The safe way to deal with MemoryAddresses is to not dereference them at all, which doesn't require them to be converted to MemorySegments. I.e. no restricted operation is needed in that case. Addresses with a known layout should already be MemorySegments (e.g. a MS returned by allocateNative), and can already be dereferenced without using restricted operations. I know, I just can't think of many use cases where the allocation takes place _only_ in Java. > > "Technically it might be possible for the native library to ignore type information and pass any address at runtime, but I'd consider this an upstream bug and nothing an API consumer in a strongly-typed environment should carry the can for. In other words: In this case, a crash seems legitimate, as it would have happened in any other language as well." > > Note that foreign.restricted does not draw a line between legitimate and illegitimate crashes. It draws a line between crashes and no crashes (or silent memory corruption). The goal of this API is to allow interop with native libraries, not to allow writing native code in Java. However, some operations are required that do not conform to Java's safety standards (those that can cause VM crashes), and these are marked as restricted for that reason. > > Jorn > From forax at univ-mlv.fr Tue Jan 5 09:23:33 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 5 Jan 2021 10:23:33 +0100 (CET) Subject: Comments / metadata in assembly listings don't make sense for code vectorized using Vector API In-Reply-To: References: Message-ID: <1984686533.1064182.1609838613784.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Sandoz" > ?: "Piotr Tarsa" > Cc: "panama-dev at openjdk.java.net'" > Envoy?: Mardi 5 Janvier 2021 00:11:43 > Objet: Re: Comments / metadata in assembly listings don't make sense for code vectorized using Vector API > Hi Piotr, > > Thanks for experimenting. The Intel folks have also experimented with Mandelbrot > generation and might be able to comment with their experience in comparison. > > I would be interested to know what your expectations were with regards to > speedup. > > It?s hard to evaluate without a JMH benchmark which can more easily present the > code hotspots and isolate from the other areas, such as for thread parallelism. > My recommendation would be to extract out the computeChunksVector kernel and > embed within such a benchmark. > > Switching off tired compilation should help (-XX:-TiredCompilation) i.e. only > C2, not C1, in getting to the C2 generated code faster. tiered compilation / -XX:-TieredCompilation :) > > To your question about the assembly listing I believe as HotSpot goes through > various compiler passes it tries to preserve the byte code index associated > with generated instructions, but naturally as code is lowered this becomes an > approximation, and especially so with the Vector API. > > In the case of "*synchronization entry?, this is stating the pseudo byte code > index just before a method is entered. However, I think there is tech debt > here, see > > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/debugInfoRec.hpp#L67 > > > And the usages of SynchronizationEntryBCI in hotspot code. > > Running in fast debug mode will present a slightly higher-level view of > generated code. Here?s a snippet: > > 26e vmulpd XMM12,XMM7,XMM7 ! mul packedD > 272 vaddpd XMM8,XMM0,XMM11 ! add packedD > 277 vmulpd XMM9,XMM8,XMM8 ! mul packedD > 27c vaddpd XMM0,XMM12,XMM9 ! add packedD > 281 vector_compare XMM10,XMM5,XMM0,#3 ! > 286 # TLS is in R15 > 286 cmpq RCX, [R15 + #344 (32-bit)] # raw ptr > 28d jnb,u B47 P=0.000100 C=-1.000000 > > ? > > 2cf vmovdqu [rsp + 64],XMM1 # spill > > 2d5 B25: # out( B44 B26 ) <- in( B48 B24 ) Freq: 9114.56 > 2d5 > 2d5 # checkcastPP of RAX > 2d5 vector_store_mask XMM1,XMM10 ! using XMM13 as TEMP > 2f4 vector_loadmask_byte XMM15,XMM1 > > 302 vmovdqu XMM1,[rsp + 448] # spill > 30b vpor XMM1,XMM1,XMM15 ! or vectors > 310 vector_store_mask XMM0,XMM1 ! using XMM14 as TEMP > 32e store_vector [RAX + #16 (8-bit)],XMM0 > > 333 vector_test RCX,XMM1, XMM2 ! using RFLAGS as TEMP > nop # 2 bytes pad for loops and calls > 340 testl RCX, RCX > 342 je B44 P=0.108889 C=184362.000000 > > > The mask instructions, such as vector_store_mask, are substituted for a more > complex sequence of x86 instructions on AVX 2. > > I do notice that the inner loop (upper bound of 5) does unroll (FWIW, making the > inner bound a power of 2 is more friendly for unrolling). There also appears to > be many register spills, suggesting non-optimal vector register > allocation/usage by C2. > > ? > > I noticed this in the code: > > // in Rust version this works fine, so where's the bug then? > // cmpMask = vFours.lt(vZiN.add(vZrN)); > > What problem did you encounter? It works for me on the tip of > https://github.com/openjdk/jdk. > > Paul. R?mi > >> On Dec 30, 2020, at 6:17 AM, Piotr Tarsa wrote: >> >> Hi all, >> >> Thanks for creating Project Panama! It looks promising. However, I've >> made a try to vectorize some code and got somewhat disappointing >> results. Therefore I wanted to look at the generated machine code to >> see it it looks optimal. I've attached hsdis to JVM and enabled >> assembly printing but the output doesn't make sense to me, i.e. the >> instructions and comments / metadata don't seem to match. I may be >> wrong as I've very rarely looked at assembly listing produced by JVM. >> >> Performance: >> As a baseline I took >> https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/mandelbrot-java-2.html >> which takes about 3.05s to finish on my system. After vectorization >> I've managed to achieve timings like 1.80s. That's quite disappointing >> to me as I have a Haswell machine which has AVX2, high speed L1 >> caches, etc I've tested on recent JDK 16 EA build from >> http://jdk.java.net/16/ >> >> Link to the code and assembly listing: >> https://gist.github.com/tarsa/7a9c80bb84c2dcd807be9cd16a655ee0 I'll >> copy the source code again in this mail at the end. >> >> What I see in the assembly listings is e.g. >> >> 0x00007f0e208b8ab9: cmp r13d,0x7fffffc0 >> 0x00007f0e208b8ac0: jg 0x00007f0e208b932c >> 0x00007f0e208b8ac6: vmulpd ymm0,ymm6,ymm4 >> 0x00007f0e208b8aca: vsubpd ymm1,ymm4,ymm4 >> 0x00007f0e208b8ace: vmovdqu YMMWORD PTR [rsp+0xc0],ymm1 >> 0x00007f0e208b8ad7: vmulpd ymm0,ymm0,ymm4 >> ;*synchronization entry >> ; - >> jdk.internal.vm.vector.VectorSupport$VectorPayload::getPayload at -1 >> (line 101) >> ; - >> jdk.incubator.vector.Double256Vector$Double256Mask::getBits at 1 (line >> 557) >> ; - >> jdk.incubator.vector.AbstractMask::toLong at 24 (line 77) >> ; - >> mandelbrot_simd_1::computeChunksVector at 228 (line 187) >> 0x00007f0e208b8adb: vaddpd ymm0,ymm0,ymm2 ;*checkcast >> {reexecute=0 rethrow=0 return_oop=0} >> ; - >> jdk.incubator.vector.DoubleVector::fromArray0Template at 34 (line 3119) >> ; - >> jdk.incubator.vector.Double256Vector::fromArray0 at 3 (line 777) >> ; - >> jdk.incubator.vector.DoubleVector::fromArray at 24 (line 2564) >> ; - >> mandelbrot_simd_1::computeChunksVector at 95 (line 169) >> 0x00007f0e208b8adf: vmovdqu YMMWORD PTR [rsp+0xe0],ymm0 >> 0x00007f0e208b8ae8: vmulpd ymm0,ymm0,ymm0 >> 0x00007f0e208b8aec: vmovdqu YMMWORD PTR [rsp+0x100],ymm0 >> >> How does vmulpd relate to a synchronization entry and >> AbstrackMask::toLong? It seems way off to me. However, there maybe >> some trick to understand it. Could you give me some guidelines on how >> to intepret that? Are the comments describing lines below or above >> them? >> >> Regards, >> Piotr >> >> mandelbrot_simd_1.java source code: >> import jdk.incubator.vector.DoubleVector; >> import jdk.incubator.vector.VectorMask; >> import jdk.incubator.vector.VectorSpecies; >> >> import java.io.BufferedOutputStream; >> import java.io.IOException; >> import java.io.OutputStream; >> import java.nio.file.Files; >> import java.nio.file.Path; >> import java.util.concurrent.CountDownLatch; >> import java.util.concurrent.ExecutorService; >> import java.util.concurrent.Executors; >> import java.util.concurrent.TimeUnit; >> import java.util.stream.IntStream; >> >> public class mandelbrot_simd_1 { >> private static final VectorSpecies SPECIES = >> DoubleVector.SPECIES_PREFERRED.length() <= 8 ? >> DoubleVector.SPECIES_PREFERRED : DoubleVector.SPECIES_512; >> >> private static final int LANES = SPECIES.length(); >> >> private static final int LANES_LOG = Integer.numberOfTrailingZeros(LANES); >> >> public static void main(String[] args) throws IOException { >> if ((LANES > 8) || (LANES != (1 << LANES_LOG))) { >> var errorMsg = "LANES must be a power of two and at most 8. " + >> "Change SPECIES in the source code."; >> throw new RuntimeException(errorMsg); >> } >> var sideLen = Integer.parseInt(args[0]); >> try (var out = new BufferedOutputStream(makeOut1())) { >> out.write(String.format("P4\n%d %d\n", sideLen, >> sideLen).getBytes()); >> computeAndOutputRows(out, sideLen); >> } >> } >> >> @SuppressWarnings("unused") >> // the version that avoids mixing up output with JVM diagnostic messages >> private static OutputStream makeOut1() throws IOException { >> return Files.newOutputStream(Path.of("mandelbrot_simd_1.pbm")); >> } >> >> // the version that is compatible with benchmark requirements >> private static OutputStream makeOut2() { >> return System.out; >> } >> >> private static void computeAndOutputRows(OutputStream out, int sideLen) { >> var poolFactor = 1000000 / sideLen; >> if (poolFactor < 10) { >> throw new RuntimeException("Too small poolFactor"); >> } >> var numCpus = Runtime.getRuntime().availableProcessors(); >> var rowsPerBatch = numCpus * poolFactor; >> var fac = 2.0 / sideLen; >> var aCr = IntStream.range(0, sideLen).parallel() >> .mapToDouble(x -> x * fac - 1.5).toArray(); >> var bitsReversalMapping = computeBitsReversalMapping(); >> var rowsPools = new byte[2][rowsPerBatch][(sideLen + 7) / 8]; >> var rowsChunksPools = new long[2][rowsPerBatch][sideLen / 64]; >> var batchSizes = new int[2]; >> var batchCountDowns = new CountDownLatch[2]; >> var computeEc = Executors.newWorkStealingPool(numCpus); >> var masterThread = new Thread(() -> { >> var rowsToProcess = sideLen; >> var nextBatchStart = 0; >> batchSizes[0] = 0; >> batchCountDowns[0] = new CountDownLatch(0); >> for (var poolId = 0; rowsToProcess > 0; poolId ^= 1) { >> while (batchCountDowns[poolId].getCount() != 0) { >> try { >> batchCountDowns[poolId].await(); >> } catch (InterruptedException ignored) { >> } >> } >> batchCountDowns[poolId] = null; >> >> var nextBatchSize = >> Math.min(sideLen - nextBatchStart, rowsPerBatch); >> var nextPoolId = poolId ^ 1; >> batchSizes[nextPoolId] = nextBatchSize; >> batchCountDowns[nextPoolId] = new CountDownLatch(nextBatchSize); >> sendTasks(fac, aCr, bitsReversalMapping, >> rowsPools[nextPoolId], rowsChunksPools[nextPoolId], >> nextBatchStart, nextBatchSize, >> batchCountDowns[nextPoolId], computeEc); >> nextBatchStart += nextBatchSize; >> >> var batchSize = batchSizes[poolId]; >> try { >> for (var rowIdx = 0; rowIdx < batchSize; rowIdx++) { >> out.write(rowsPools[poolId][rowIdx]); >> } >> out.flush(); >> } catch (IOException e) { >> e.printStackTrace(); >> System.exit(-1); >> } >> rowsToProcess -= batchSize; >> } >> >> computeEc.shutdown(); >> }); >> masterThread.start(); >> while (masterThread.isAlive() || !computeEc.isTerminated()) { >> try { >> @SuppressWarnings("unused") >> var ignored = computeEc.awaitTermination(1, TimeUnit.DAYS); >> masterThread.join(); >> } catch (InterruptedException ignored) { >> } >> } >> } >> >> private static void sendTasks(double fac, double[] aCr, >> byte[] bitsReversalMapping, >> byte[][] rows, long[][] rowsChunks, >> int batchStart, int batchSize, >> CountDownLatch poolsActiveWorkersCount, >> ExecutorService computeEc) { >> for (var i = 0; i < batchSize; i++) { >> var indexInBatch = i; >> var y = batchStart + i; >> var Ci = y * fac - 1.0; >> computeEc.submit(() -> { >> try { >> computeRow(Ci, aCr, bitsReversalMapping, >> rows[indexInBatch], rowsChunks[indexInBatch]); >> poolsActiveWorkersCount.countDown(); >> } catch (Exception e) { >> e.printStackTrace(); >> System.exit(-1); >> } >> }); >> } >> } >> >> private static byte[] computeBitsReversalMapping() { >> var bitsReversalMapping = new byte[256]; >> for (var i = 0; i < 256; i++) { >> bitsReversalMapping[i] = (byte) (Integer.reverse(i) >>> 24); >> } >> return bitsReversalMapping; >> } >> >> private static void computeRow(double Ci, double[] aCr, >> byte[] bitsReversalMapping, >> byte[] row, long[] rowChunks) { >> computeChunksVector(Ci, aCr, rowChunks); >> transferRowFlags(rowChunks, row, bitsReversalMapping); >> computeRemainderScalar(aCr, row, Ci); >> } >> >> private static void computeChunksVector(double Ci, double[] aCr, >> long[] rowChunks) { >> var sideLen = aCr.length; >> var vCi = DoubleVector.broadcast(SPECIES, Ci); >> var vZeroes = DoubleVector.zero(SPECIES); >> var vTwos = DoubleVector.broadcast(SPECIES, 2.0); >> var vFours = DoubleVector.broadcast(SPECIES, 4.0); >> var zeroMask = VectorMask.fromLong(SPECIES, 0); >> // (1 << 6) = 64 = length of long in bits >> for (var xBase = 0; xBase < (sideLen & ~(1 << 6)); xBase += (1 << 6)) { >> var cmpFlags = 0L; >> for (var xInc = 0; xInc < (1 << 6); xInc += LANES) { >> var vZr = vZeroes; >> var vZi = vZeroes; >> var vCr = DoubleVector.fromArray(SPECIES, aCr, xBase + xInc); >> var vZrN = vZeroes; >> var vZiN = vZeroes; >> var cmpMask = zeroMask; >> for (var outer = 0; outer < 10; outer++) { >> for (var inner = 0; inner < 5; inner++) { >> vZi = vTwos.mul(vZr).mul(vZi).add(vCi); >> vZr = vZrN.sub(vZiN).add(vCr); >> vZiN = vZi.mul(vZi); >> vZrN = vZr.mul(vZr); >> } >> cmpMask = cmpMask.or(vFours.lt(vZiN.add(vZrN))); >> // in Rust version this works fine, so where's the bug then? >> // cmpMask = vFours.lt(vZiN.add(vZrN)); >> if (cmpMask.allTrue()) { >> break; >> } >> } >> cmpFlags |= cmpMask.toLong() << xInc; >> } >> rowChunks[xBase >> 6] = cmpFlags; >> } >> } >> >> private static void transferRowFlags(long[] rowChunks, byte[] row, >> byte[] bitsReversalMapping) { >> for (var i = 0; i < rowChunks.length; i++) { >> var group = ~rowChunks[i]; >> row[i * 8 + 7] = bitsReversalMapping[0xff & (byte) (group >>> 56)]; >> row[i * 8 + 6] = bitsReversalMapping[0xff & (byte) (group >>> 48)]; >> row[i * 8 + 5] = bitsReversalMapping[0xff & (byte) (group >>> 40)]; >> row[i * 8 + 4] = bitsReversalMapping[0xff & (byte) (group >>> 32)]; >> row[i * 8 + 3] = bitsReversalMapping[0xff & (byte) (group >>> 24)]; >> row[i * 8 + 2] = bitsReversalMapping[0xff & (byte) (group >>> 16)]; >> row[i * 8 + 1] = bitsReversalMapping[0xff & (byte) (group >>> 8)]; >> row[i * 8] = bitsReversalMapping[0xff & (byte) group]; >> } >> } >> >> private static void computeRemainderScalar(double[] aCr, byte[] >> row, double Ci) { >> var sideLen = aCr.length; >> var bits = 0; >> for (var x = sideLen & ~(1 << 6); x < sideLen; x++) { >> var Zr = 0.0; >> var Zi = 0.0; >> var Cr = aCr[x]; >> var i = 50; >> var ZrN = 0.0; >> var ZiN = 0.0; >> do { >> Zi = 2.0 * Zr * Zi + Ci; >> Zr = ZrN - ZiN + Cr; >> ZiN = Zi * Zi; >> ZrN = Zr * Zr; >> } while (ZiN + ZrN <= 4.0 && --i > 0); >> bits <<= 1; >> bits += i == 0 ? 1 : 0; >> if (x % 8 == 7) { >> row[x / 8] = (byte) bits; >> bits = 0; >> } >> } >> if (sideLen % 8 != 0) { >> row[sideLen / 8] = (byte) bits; >> } >> } > > } From sundar at openjdk.java.net Tue Jan 5 10:48:30 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 5 Jan 2021 10:48:30 GMT Subject: [foreign-jextract] RFR: 8259226: jextract should differentiate between clang errors vs other runtime issues Message-ID: CLANG_ERROR error code added. Also OUTPUT_ERROR exit code is used as expected. ------------- Commit messages: - 8259226: jextract should differentiate between clang errors vs other runtime issues Changes: https://git.openjdk.java.net/panama-foreign/pull/429/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=429&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259226 Stats: 176 lines in 22 files changed: 140 ins; 2 del; 34 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/429.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/429/head:pull/429 PR: https://git.openjdk.java.net/panama-foreign/pull/429 From maurizio.cimadamore at oracle.com Tue Jan 5 11:14:12 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 5 Jan 2021 11:14:12 +0000 Subject: BLAS and Vector API In-Reply-To: <5fa57578-61c4-9def-e6a0-0ebed6b86732@gmail.com> References: <7264552B-57D9-40CD-92CA-7BBFA7FD7324@ORACLE.COM> <73bdce09-f9ca-896a-c68e-d39705cf846c@oracle.com> <5fa57578-61c4-9def-e6a0-0ebed6b86732@gmail.com> Message-ID: <3fbebeb2-81f1-fa59-19ba-8b0c500fed74@oracle.com> On 05/01/2021 00:56, Samuel Audet wrote: > Hi, Maurizio, > > On 1/5/21 1:22 AM, Maurizio Cimadamore wrote: >> >> On 04/01/2021 14:52, Samuel Audet wrote: >>> Hi, Ludovic, >>> >>> On 1/4/21 10:48 PM, Ludovic Henry wrote: >>>> I?ll also explore using the Foreign Linker API to wrap the OpenBLAS >>>> library without going through JNI. I?m curious whether it?s going >>>> to lead to performance improvements. >>> >>> No, not yet, it won't, since that still uses JNI: >>> https://urldefense.com/v3/__https://github.com/microsoft/onnxruntime/pull/4329*issuecomment-673848183__;Iw!!GqivPVa7Brio!JCrsAOkabZFThFCF13q2PkJSZmSiDf-RjGxfF0lDhGtmau_Zvo_cujZeQ6nqjchAEcVh-1c$ >> >> >> Where did you get this information from? The comment you quote shows >> my reply and then you somehow (erroneously) inferring that the linker >> API is based on JNI. >> >> The Foreign Linker API support has very little to do with JNI >> support. Of course, since some of the stuff the VM has to do to go >> from Java to native are the same, performances might not be too >> different (unless state transitions are removed, which is possible >> with the linker API). > > OpenJDK hasn't been providing a lot of updates about the status of the > various Panama APIs for a year or so now, so I can only assume that > things had not changed. Also, since you're not replying to messages > containing information about what you said of the state of things in > the past (that the foreign API was using JNI, I can dig up the > specific message if you want), I simply assumed that things had not > changed! Sorry about that > > I'll say it again: Keeping all this information "internal" isn't > helping the community. I understand that you probably don't have any > say in this, that it's all about policies at Oracle, so please don't > take it personally. As usual, thanks for updating us with the > information you can provide. I think there has been plenty of information available during 2020: https://inside.java/tag/panama There are public talks linked in the page above - unfortunately, they only cover the memory access part - since that's where we were back in February (when we still could do conferences - or attend them :-) ). Jorn and I recorded a podcast (also linked above) last December, also covering both APIs (it's in two parts). Several writeups on the current status of the APIs (both memory access AND linker) have been live on github for the past few months. Jorn also wrote a more technical writeup on the status of the VM intrinsics for downcall support, which helped the review process quite a bit. Speaking of reviews, both PRs for memory access and linker API are public and contain tons of info as well: https://github.com/openjdk/jdk/pull/548 https://git.openjdk.java.net/jdk/pull/634 If you follow the links, you will find comprehensive JEP documents, CSRs - all info has been available to see (as for any other changes to the Java platform). Should be enough at least to understand where we are at and where we're going? Cheers Maurizio > > Samuel From mcimadamore at openjdk.java.net Tue Jan 5 11:21:05 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 5 Jan 2021 11:21:05 GMT Subject: [foreign-memaccess+abi] RFR: Fix duplicate declaration in methodData.cpp In-Reply-To: References: <3rEaVYEzw0DdcRlqxJ-odxhz78l7KPSqCTDd1bLpKvw=.7fa31e56-574a-420d-afed-dce8acfe8f20@github.com> Message-ID: On Mon, 4 Jan 2021 23:13:25 GMT, Paul Sandoz wrote: >> A recent automatic merge ended up creating a duplicate declaration of a function in methodData.cpp. This patch fixes that. Thanks to Ty for the fix. > > Marked as reviewed by psandoz (Committer). I've closed this pull request - please refer to: https://github.com/openjdk/panama-foreign/pull/427 ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/428 From mcimadamore at openjdk.java.net Tue Jan 5 11:21:06 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 5 Jan 2021 11:21:06 GMT Subject: [foreign-memaccess+abi] Withdrawn: Fix duplicate declaration in methodData.cpp In-Reply-To: <3rEaVYEzw0DdcRlqxJ-odxhz78l7KPSqCTDd1bLpKvw=.7fa31e56-574a-420d-afed-dce8acfe8f20@github.com> References: <3rEaVYEzw0DdcRlqxJ-odxhz78l7KPSqCTDd1bLpKvw=.7fa31e56-574a-420d-afed-dce8acfe8f20@github.com> Message-ID: <3bqn8MXNbdUaDDbAYQHZzrA7JUq1y5ZHfaj4qtLYdYM=.77db74f2-3c43-42f9-b194-b16116350f5c@github.com> On Mon, 4 Jan 2021 22:23:34 GMT, Maurizio Cimadamore wrote: > A recent automatic merge ended up creating a duplicate declaration of a function in methodData.cpp. This patch fixes that. Thanks to Ty for the fix. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/428 From mcimadamore at openjdk.java.net Tue Jan 5 11:21:01 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 5 Jan 2021 11:21:01 GMT Subject: [foreign-memaccess+abi] RFR: Removed duplicate profile_memory_access function from methodData.cpp In-Reply-To: References: Message-ID: On Sat, 2 Jan 2021 21:13:01 GMT, Ty Young wrote: > Removes the duplicate profile_memory_access function from methodData.cpp, which causes a build fail. This duplicate function does not exist in the foreign-jextract branch as there hasn't been a merge yet from foreign-memaccess+abi. > > Note: OCA filled out and sent but needs to be processed and my Github account needs to be registered. If it takes too long due to the holidays then I'll rescind the pull request. > > Note: 2 this is a resubmit to fix same-branch pull request issue the OpenJDK bot brought up. Looks good! ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/427 From mcimadamore at openjdk.java.net Tue Jan 5 11:48:03 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 5 Jan 2021 11:48:03 GMT Subject: [foreign-jextract] RFR: 8259226: jextract should differentiate between clang errors vs other runtime issues In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 10:43:29 GMT, Athijegannathan Sundararajan wrote: > CLANG_ERROR error code added. Also OUTPUT_ERROR exit code is used as expected. While the changes look good, I think that the category CLANG_ERROR seems too broad. I think it would be useful to distinguish between genuine errors (e.g. syntax error in header) and an error that occurs because of some issues in the internal parsing machinery. The latter to me seems more a case of RUNTIME_ERROR than CLANG_ERROR. I have pointed out some examples in the code. src/jdk.incubator.jextract/share/classes/jdk/internal/clang/AccessSpecifier.java line 64: > 62: AccessSpecifier x = lookup.get(value); > 63: if (null == x) { > 64: throw new ClangException("Invalid AccessSpecifier kind value: " + value); Should this be a CLANG_ERROR? src/jdk.incubator.jextract/share/classes/jdk/internal/clang/CallingConvention.java line 71: > 69: CallingConvention x = lookup.get(value); > 70: if (null == x) { > 71: throw new ClangException("Invalid calling convention: " + value); Should this be a CLANG_ERROR? src/jdk.incubator.jextract/share/classes/jdk/internal/clang/CursorKind.java line 296: > 294: CursorKind x = lookup.get(value); > 295: if (null == x) { > 296: throw new ClangException("Invalid Cursor kind value: " + value); Should this be a CLANG_ERROR? src/jdk.incubator.jextract/share/classes/jdk/internal/clang/EvalResult.java line 74: > 72: return getAsInt0(); > 73: default: > 74: throw new ClangException("Unexpected kind: " + kind); Should this be a CLANG_ERROR? Same for others in this file ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/429 From maurizio.cimadamore at oracle.com Tue Jan 5 11:59:33 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 5 Jan 2021 11:59:33 +0000 Subject: [foreign-memaccess] musing on the memory access API In-Reply-To: <08af01d6e2f4$cdae0600$690a1200$@apache.org> References: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> <083001d6e2c9$1aae9040$500bb0c0$@apache.org> <1a830d5e-233c-e54e-6b3c-d679c7297410@oracle.com> <08af01d6e2f4$cdae0600$690a1200$@apache.org> Message-ID: <3b0c2cd5-e49b-24fe-2fe6-fc57c5dd3693@oracle.com> On 04/01/2021 23:53, Uwe Schindler wrote: > Hi Maurizio, > >> Thanks for the feedback Uwe, and for the bug reports. We'll do our best >> to address some of them quickly (the NPE and the error in >> Unmapper::address). As for adding an overload for mapping a segment from >> a FileChannel I'm totally open to it, but I think it's late-ish now to >> add API changes, since we are in stabilization. > Hi, this was only a suggestion to improve the whole thing. My idea is more to wait for this until a more close integration into the FileSystem API is done. The main issue we had was that we can only pass a path from the default file system provider (I have a workaround for that, so during our testsuite we "unwrap" all the layers on top). But correctly, the FileSystem implementation should provide the way how to get a MemorySegment from the FileChannel, the current cast to the internal class is ... hacky! I know why it is like that (preview and it's not part of java base, so the FileSystem interface in java.base can't return a MemorySegment). But when Panama graduates, the filesystem integration is a must!: FileChannel should be extended by one "default" method throwing UOE, only implemented by default provider: "MemorySegment FileChannel.mapSegment(long offset, long size, MapMode mode)" +1 - this has been raised in the past as well, and I agree that the issue is more at the FileSystem interface level - we can't really do much at the level of the segment API as things stand. I'm less convinced that this is a "must" - while it's a nice to have, and something we should defo get working in the future, I don't think that by blocking integration of Panama APIs because mapped segments do not work with custom file system will be the right choice. > >> Also, thanks for the thoughts on the API in general - I kind of expected >> (given our discussions) that shared segments were 90% of what you needed >> - and that you are not much interested in using confinement. I agree >> that, when working from that angle, the API looks mostly ok. But not all >> clients have same requirements and some would like to take advantage of >> confinement more - also, note that if we just drop support for confined >> segments (which is something we also thought about) and just offered >> shared access, _all_ clients will be stuck with a very slow close() >> operation. > Hi, yes, I agree. I just said: Switching between those modes is unlikely, but yet a confined default for long living segments is correct, shared for long living ones (this is also the usage pattern: something that ?lives very long is very likely often also used by many threads, like a database file or some database off-heap cache). Allocated memory used in netty is of course often short-lived, but it is in most cases not really concurrently used (or you can avoid it). > > I'd give the user the option on constructing, but don't allow to change it later. > >> There are very different ways to use a memory segment; sometimes (as in >> your case) a memory segment is long-lived, and you don't care if closing >> it takes 1 us. But there are other cases where segments are created (and >> disposed) more frequently. To me, the interesting fact that emerged from >> the Netty experiment (thanks guys!) was that using handoff AND shared >> segment, while nice on paper it's not going to work performance-wise, >> because you need to do an expensive close at each hand-off. This might >> be rectified, for instance by making the API more complex, and have a >> state where a segment has no owner (e.g. so that instead of confined(A) >> -> shared -> confined(B) you do confined(A) -> detached -> confined(B) >> ), but the risk is that to add a lot of API complexity ("detached" is a >> brand new segment state in which the segment is not accessible, but >> where memory is not yet deallocated) for what might be perceived as a >> corner case. >> So, the big question here is - given that there are defo different modes >> to interact with this API (short lived vs. long lived segment), what API >> allows us to capture the use cases we want in the simplest way possible? >> While dynamic ownership changes look like a cool idea on paper, it also >> add complexity - so I think now it's the right time to ask ourself if we >> should scale back on that a bit and have a more "static" set of flavors >> to pick from (e.g. { confined, shared } x { explicit, cleaner } > I think, when "allocating" a segment (by reserving memory, mapping a file, supplying some external MemoryAddress and length), you should set confined or shared from the beginning, without a possibility to change it. This would indeed simplify many things. I got new benchmarks a minute ago from my Lucene colleagues: the current MemorySegmentAPI seems 40% slower than ByteBuffer for some use cases, but equal of speed/faster for other use cases (I assume it is still long vs. int index/looping problems; a for loop using LONG is not as good optimized as a for loop with INT -- correct?). But without diving too deep, it might also come from the fact that the memory segments *may* change their state, so hotspot is not able to do all optimizations. If you have for loops with long indices, then yes, this is not optimized, and unfortunately expected to be slow. Also, to counteract that, the impl has many optimization so that, if a segment size can be represented as an int, many of the long operations are eliminated and replaced with int operations (e.g. bound checks). But if you work with true big segments (which I suspect is the case for Lucene), most of these optimization would not kick in. Luckily a lot of progress has been made on the long vs. int problem, but the work is not finished - I hope it will by the time 17 ships, so that we can remove all the hacks we have from the impl. That said, if you have specific benchmarks to throw our way we'd be happy to look at them! In our benchmark we have not observed slowdown caused to memory segment changing their state (note that they don't really change their state - a new instance with new properties is returned). Thanks Maurizio From samuel.audet at gmail.com Tue Jan 5 12:32:47 2021 From: samuel.audet at gmail.com (Samuel Audet) Date: Tue, 5 Jan 2021 21:32:47 +0900 Subject: BLAS and Vector API In-Reply-To: <3fbebeb2-81f1-fa59-19ba-8b0c500fed74@oracle.com> References: <7264552B-57D9-40CD-92CA-7BBFA7FD7324@ORACLE.COM> <73bdce09-f9ca-896a-c68e-d39705cf846c@oracle.com> <5fa57578-61c4-9def-e6a0-0ebed6b86732@gmail.com> <3fbebeb2-81f1-fa59-19ba-8b0c500fed74@oracle.com> Message-ID: <01039806-7c89-90a6-bd5a-b7be0c4f2b79@gmail.com> Wow, that's a lot of documents, thanks! I wasn't aware of half of these new links. I'm a bit disappointed though that I'm still not finding much of anything concerning performance, but that's nothing new. I understand there are other priorities. I'm still not convinced that all this work is going to provide something sufficiently more usable than JNI and sun.misc.Unsafe for people to "migrate". Yes, I know, we'll see when it's done. BTW, one new thought I had recently. One measure of success could be seeing Google going through all the legal and technical hoops to have this ported to Android. If they stick with JNI, then I suppose that means most developers may very well stick with JNI, at least until something else sufficiently "better" comes around, which might end up not being related to Panama at all. Samuel On 1/5/21 8:14 PM, Maurizio Cimadamore wrote: > > On 05/01/2021 00:56, Samuel Audet wrote: >> Hi, Maurizio, >> >> On 1/5/21 1:22 AM, Maurizio Cimadamore wrote: >>> >>> On 04/01/2021 14:52, Samuel Audet wrote: >>>> Hi, Ludovic, >>>> >>>> On 1/4/21 10:48 PM, Ludovic Henry wrote: >>>>> I?ll also explore using the Foreign Linker API to wrap the OpenBLAS >>>>> library without going through JNI. I?m curious whether it?s going >>>>> to lead to performance improvements. >>>> >>>> No, not yet, it won't, since that still uses JNI: >>>> https://github.com/microsoft/onnxruntime/pull/4329#issuecomment-673848183 >>> >>> >>> >>> Where did you get this information from? The comment you quote shows >>> my reply and then you somehow (erroneously) inferring that the linker >>> API is based on JNI. >>> >>> The Foreign Linker API support has very little to do with JNI >>> support. Of course, since some of the stuff the VM has to do to go >>> from Java to native are the same, performances might not be too >>> different (unless state transitions are removed, which is possible >>> with the linker API). >> >> OpenJDK hasn't been providing a lot of updates about the status of the >> various Panama APIs for a year or so now, so I can only assume that >> things had not changed. Also, since you're not replying to messages >> containing information about what you said of the state of things in >> the past (that the foreign API was using JNI, I can dig up the >> specific message if you want), I simply assumed that things had not >> changed! Sorry about that >> >> I'll say it again: Keeping all this information "internal" isn't >> helping the community. I understand that you probably don't have any >> say in this, that it's all about policies at Oracle, so please don't >> take it personally. As usual, thanks for updating us with the >> information you can provide. > > I think there has been plenty of information available during 2020: > > https://inside.java/tag/panama > > There are public talks linked in the page above - unfortunately, they > only cover the memory access part - since that's where we were back in > February (when we still could do conferences - or attend them :-) ). > > Jorn and I recorded a podcast (also linked above) last December, also > covering both APIs (it's in two parts). > > Several writeups on the current status of the APIs (both memory access > AND linker) have been live on github for the past few months. Jorn also > wrote a more technical writeup on the status of the VM intrinsics for > downcall support, which helped the review process quite a bit. > > Speaking of reviews, both PRs for memory access and linker API are > public and contain tons of info as well: > > https://github.com/openjdk/jdk/pull/548 > > https://git.openjdk.java.net/jdk/pull/634 > > If you follow the links, you will find comprehensive JEP documents, CSRs > - all info has been available to see (as for any other changes to the > Java platform). > > > Should be enough at least to understand where we are at and where we're > going? > > Cheers > Maurizio > > > >> >> Samuel From sundar at openjdk.java.net Tue Jan 5 13:09:07 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 5 Jan 2021 13:09:07 GMT Subject: [foreign-jextract] RFR: 8259226: jextract should differentiate between clang errors vs other runtime issues In-Reply-To: References: Message-ID: <5qJrgIv3bGqiNcQKqYmJKdzDoOl0jeFZ2L7NhgR9kUI=.cb27076b-3049-4934-b1c9-aba064795963@github.com> On Tue, 5 Jan 2021 11:44:05 GMT, Maurizio Cimadamore wrote: >> CLANG_ERROR error code added. Also OUTPUT_ERROR exit code is used as expected. > > While the changes look good, I think that the category CLANG_ERROR seems too broad. I think it would be useful to distinguish between genuine errors (e.g. syntax error in header) and an error that occurs because of some issues in the internal parsing machinery. The latter to me seems more a case of RUNTIME_ERROR than CLANG_ERROR. I have pointed out some examples in the code. Closing this PR. Will recreate new one. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/429 From sundar at openjdk.java.net Tue Jan 5 13:09:07 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 5 Jan 2021 13:09:07 GMT Subject: [foreign-jextract] Withdrawn: 8259226: jextract should differentiate between clang errors vs other runtime issues In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 10:43:29 GMT, Athijegannathan Sundararajan wrote: > CLANG_ERROR error code added. Also OUTPUT_ERROR exit code is used as expected. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/429 From sundar at openjdk.java.net Tue Jan 5 13:43:23 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 5 Jan 2021 13:43:23 GMT Subject: [foreign-jextract] RFR: 8259226: jextract should differentiate between clang errors vs other runtime issues Message-ID: Introducing ClangException for clang diagnostic errors and returning CLANG_ERROR for diagnostic errors. Also using OUTPUT_ERROR as intended. ------------- Commit messages: - 8259226: jextract should differentiate between clang errors vs other runtime issues Changes: https://git.openjdk.java.net/panama-foreign/pull/430/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=430&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259226 Stats: 150 lines in 7 files changed: 138 ins; 2 del; 10 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/430.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/430/head:pull/430 PR: https://git.openjdk.java.net/panama-foreign/pull/430 From sundar at openjdk.java.net Tue Jan 5 14:08:34 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 5 Jan 2021 14:08:34 GMT Subject: [foreign-jextract] RFR: 8259226: jextract should differentiate between clang errors vs other runtime issues [v2] In-Reply-To: References: Message-ID: > Introducing ClangException for clang diagnostic errors and returning CLANG_ERROR for diagnostic errors. Also using OUTPUT_ERROR as intended. Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: Copyright year for new file should be 2021 ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/430/files - new: https://git.openjdk.java.net/panama-foreign/pull/430/files/8b765588..21f16307 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=430&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=430&range=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/430.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/430/head:pull/430 PR: https://git.openjdk.java.net/panama-foreign/pull/430 From mcimadamore at openjdk.java.net Tue Jan 5 15:04:02 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 5 Jan 2021 15:04:02 GMT Subject: [foreign-jextract] RFR: 8259226: jextract should differentiate between clang errors vs other runtime issues [v2] In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 14:08:34 GMT, Athijegannathan Sundararajan wrote: >> Introducing ClangException for clang diagnostic errors and returning CLANG_ERROR for diagnostic errors. Also using OUTPUT_ERROR as intended. > > Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: > > Copyright year for new file should be 2021 Looks good! ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/430 From sundar at openjdk.java.net Tue Jan 5 15:04:11 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 5 Jan 2021 15:04:11 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 8259226: jextract should differentiate between clang errors vs other runtime issues Message-ID: <23eb235d-d16c-4b81-8949-b89f53052160@openjdk.org> Changeset: 796eca49 Author: Athijegannathan Sundararajan Date: 2021-01-05 15:03:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/796eca49 8259226: jextract should differentiate between clang errors vs other runtime issues Reviewed-by: mcimadamore ! src/jdk.incubator.jextract/share/classes/jdk/incubator/jextract/JextractTool.java + src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/ClangException.java ! src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/Parser.java ! test/jdk/tools/jextract/JextractToolProviderTest.java ! test/jdk/tools/jextract/JextractToolRunner.java + test/jdk/tools/jextract/illegal_decls.h + test/jdk/tools/jextract/non_existent_includer.h From sundar at openjdk.java.net Tue Jan 5 15:09:05 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 5 Jan 2021 15:09:05 GMT Subject: [foreign-jextract] Integrated: 8259226: jextract should differentiate between clang errors vs other runtime issues In-Reply-To: References: Message-ID: On Tue, 5 Jan 2021 13:38:44 GMT, Athijegannathan Sundararajan wrote: > Introducing ClangException for clang diagnostic errors and returning CLANG_ERROR for diagnostic errors. Also using OUTPUT_ERROR as intended. This pull request has now been integrated. Changeset: 796eca49 Author: Athijegannathan Sundararajan URL: https://git.openjdk.java.net/panama-foreign/commit/796eca49 Stats: 150 lines in 7 files changed: 138 ins; 2 del; 10 mod 8259226: jextract should differentiate between clang errors vs other runtime issues Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/430 From ach at activeviam.com Tue Jan 5 16:45:06 2021 From: ach at activeviam.com (Antoine Chambille) Date: Tue, 5 Jan 2021 17:45:06 +0100 Subject: Foreign memory access hot loop benchmark In-Reply-To: References: <0d33e2cc-1585-0fc2-8a9f-231f6c888b69@oracle.com> <3c26c12c-23e0-a99f-03cd-afd6996c6478@oracle.com> <7ca53e08-3b3d-0db3-0493-1ecb0e44b79d@oracle.com> <0c431324-68b5-c0b0-3ced-5119ab51def9@oracle.com> <72ab9217-c638-88b9-b8fc-9ec91fab4cf6@oracle.com> Message-ID: Yes I see the same slowdown with longs than with doubles. -Antoine On Mon, Jan 4, 2021 at 7:33 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > What happens with longs? Do you still see the slowdown? > > Maurizio > On 04/01/2021 17:31, Antoine Chambille wrote: > > *(using fixed width font ;)* > > > Thank you Maurizio, for looking into this. > > This is a good find, I've just updated and rebuilt the Panama JDK, I > confirm that the big slowdown with manually unrolled loop and memory > handles has disappeared for the AddBenchmark.unrolledMHI_v2 benchmark. But > it is apparently still present in one last case: AddBenchmark.unrolledMHI > > Maybe another missing annotation? > > Benchmark Mode Cnt Score Error > Units > AddBenchmark.scalarArray thrpt 5 5270072.806 ? 43618.821 > ops/s > AddBenchmark.scalarArrayHandle thrpt 5 5155791.142 ? 122147.967 > ops/s > AddBenchmark.scalarMHI thrpt 5 2215595.625 ? 27044.786 > ops/s > AddBenchmark.scalarMHI_v2 thrpt 5 2165838.557 ? 48477.364 > ops/s > AddBenchmark.scalarUnsafe thrpt 5 2057853.572 ? 21064.385 > ops/s > AddBenchmark.unrolledArray thrpt 5 6346056.064 ? 304425.251 > ops/s > AddBenchmark.unrolledArrayHandle thrpt 5 1991324.025 ? 39434.066 > ops/s > AddBenchmark.unrolledMHI thrpt 5 206541.946 ? 4031.057 > ops/s > AddBenchmark.unrolledMHI_v2 thrpt 5 2240957.905 ? 24239.357 > ops/s > AddBenchmark.unrolledUnsafe thrpt 5 2185038.207 ? 27611.150 > ops/s > > > benchmark source code: > > https://github.com/chamb/panama-benchmarks/blob/master/memory/src/main/java/com/activeviam/test/AddBenchmark.java > > > > // CODE OF THE REMAINING SLOW BENCHMARK > static final VarHandle MHI = MemoryLayout.ofSequence(SIZE, > MemoryLayouts.JAVA_DOUBLE) > .varHandle(double.class, > MemoryLayout.PathElement.sequenceElement()); > > @Benchmark > public void unrolledMHI(Data state) { > final MemorySegment is = state.inputSegment; > final MemorySegment os = state.outputSegment; > > for(int i = 0; i < SIZE; i+=4) { > MHI.set(os, (long) (i), (double) MHI.get(is, (long) (i)) + > (double) MHI.get(os, (long) (i))); > MHI.set(os, (long) (i+1), (double) MHI.get(is, (long) (i+1)) + > (double) MHI.get(os, (long) (i+1))); > MHI.set(os, (long) (i+2), (double) MHI.get(is, (long) (i+2)) + > (double) MHI.get(os, (long) (i+2))); > MHI.set(os, (long) (i+3), (double) MHI.get(is, (long) (i+3)) + > (double) MHI.get(os, (long) (i+3))); > } > } > > > > Best, > -Antoine > > > > > > >> >> >> On Wed, Nov 25, 2020 at 1:42 PM Maurizio Cimadamore < >> maurizio.cimadamore at oracle.com> wrote: >> >>> I did some investigation, and, during the problematic benchmark we were >>> hitting some inline thresholds, as evidenced by `-XX:PrintInlining`: >>> >>> @ 92 jdk.incubator.foreign.MemoryAccess::getLongAtIndex (12 bytes) >>> NodeCountInliningCutoff >>> @ 96 jdk.incubator.foreign.MemoryAccess::setLongAtIndex (13 bytes) >>> NodeCountInliningCutoff >>> @ 111 jdk.incubator.foreign.MemoryAccess::getLongAtIndex (12 bytes) >>> NodeCountInliningCutoff >>> @ 120 jdk.incubator.foreign.MemoryAccess::getLongAtIndex (12 bytes) >>> NodeCountInliningCutoff >>> @ 124 jdk.incubator.foreign.MemoryAccess::setLongAtIndex (13 bytes) >>> NodeCountInliningCutoff >>> >>> The problem is that the static accessors in MemoryAccess are lacking a >>> @ForceInline annotation. This is being addressed here: >>> >>> https://github.com/openjdk/panama-foreign/pull/401 >>> >>> >>> Thanks >>> Maurizio >>> >>> >>> On 25/11/2020 11:51, Maurizio Cimadamore wrote: >>> > >>> > On 24/11/2020 11:19, Antoine Chambille wrote: >>> >> If I look at the slow benchmark in detail, I observe that the first >>> >> two warmups run at the expected speed, but then it slows down 20x. >>> >> Very strange, it's almost as if some JIT optimization is suddenly >>> >> turned off: >>> > >>> > This is something I've observed in the past as well, in some cases, >>> > when playing with VH. >>> > >>> > We'll take a look. >>> > >>> > Thanks >>> > Maurizio >>> > >>> >> >> > From maurizio.cimadamore at oracle.com Tue Jan 5 16:50:50 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 5 Jan 2021 16:50:50 +0000 Subject: Foreign memory access hot loop benchmark In-Reply-To: References: <3c26c12c-23e0-a99f-03cd-afd6996c6478@oracle.com> <7ca53e08-3b3d-0db3-0493-1ecb0e44b79d@oracle.com> <0c431324-68b5-c0b0-3ced-5119ab51def9@oracle.com> <72ab9217-c638-88b9-b8fc-9ec91fab4cf6@oracle.com> Message-ID: Thanks, I'll take a look - my guts tell me that the method is just too big when using VH directly (something I've seen in other cases). Note that the fact that we have @ForceInline on the MemoryAccess accessors helps, since that will tell hotspot to always inline those access, no matter the size of the enclosing method. I'm afraid here we're in a situation where the benchmark method gets too big and no further inlining happens (even though, if we progressed with inlining we'd end up with a _smaller_ compiled method overall). I'll try to test this hypothesis. Stay tuned. Cheers Maurizio On 05/01/2021 16:45, Antoine Chambille wrote: > Yes I see the same slowdown with longs than with doubles. > > -Antoine > > > > On Mon, Jan 4, 2021 at 7:33 PM Maurizio Cimadamore > > wrote: > > What happens with longs? Do you still see the slowdown? > > Maurizio > > On 04/01/2021 17:31, Antoine Chambille wrote: >> /(using fixed width font ;)/ >> >> >> Thank you Maurizio, for looking into this. >> >> This is a good find, I've just updated and rebuilt the Panama >> JDK, I confirm that the big slowdown with manually unrolled loop >> and memory handles has disappeared for the >> AddBenchmark.unrolledMHI_v2 benchmark. But it is apparently still >> present in one last case: AddBenchmark.unrolledMHI >> >> Maybe another missing annotation? >> >> Benchmark ? ? ? ?Mode ?Cnt ? ? ? ?Score ? ? ? ?Error ?Units >> AddBenchmark.scalarArray ? ? ? ? ? ?thrpt ? ?5 ?5270072.806 ? >> ?43618.821 ?ops/s >> AddBenchmark.scalarArrayHandle ? ? ?thrpt ? ?5 ?5155791.142 ? >> 122147.967 ?ops/s >> AddBenchmark.scalarMHI ? ? ? ? ? ? ?thrpt ? ?5 ?2215595.625 ? >> ?27044.786 ?ops/s >> AddBenchmark.scalarMHI_v2 ? ? ? ? ? thrpt ? ?5 ?2165838.557 ? >> ?48477.364 ?ops/s >> AddBenchmark.scalarUnsafe ? ? ? ? ? thrpt ? ?5 ?2057853.572 ? >> ?21064.385 ?ops/s >> AddBenchmark.unrolledArray ? ? ? ? ?thrpt ? ?5 ?6346056.064 ? >> 304425.251 ?ops/s >> AddBenchmark.unrolledArrayHandle ? ?thrpt ? ?5 ?1991324.025 ? >> ?39434.066 ?ops/s >> AddBenchmark.unrolledMHI ? ? ? ? ? ?thrpt ? ?5 206541.946 ? ? >> 4031.057 ?ops/s >> AddBenchmark.unrolledMHI_v2 ? ? ? ? thrpt ? ?5 ?2240957.905 ? >> ?24239.357 ?ops/s >> AddBenchmark.unrolledUnsafe ? ? ? ? thrpt ? ?5 ?2185038.207 ? >> ?27611.150 ?ops/s >> >> >> benchmark source code: >> https://github.com/chamb/panama-benchmarks/blob/master/memory/src/main/java/com/activeviam/test/AddBenchmark.java >> >> >> >> // CODE OF THE REMAINING SLOW BENCHMARK >> static final VarHandle MHI = MemoryLayout.ofSequence(SIZE, >> MemoryLayouts.JAVA_DOUBLE) >> ? ? ? ? ? ? .varHandle(double.class, >> MemoryLayout.PathElement.sequenceElement()); >> >> @Benchmark >> public void unrolledMHI(Data state) { >> ? ? final MemorySegment is = state.inputSegment; >> ? ? final MemorySegment os = state.outputSegment; >> >> ? ? for(int i = 0; i < SIZE; i+=4) { >> ? ? ? ? MHI.set(os, (long) (i), ? (double) MHI.get(is, (long) >> (i)) ? + (double) MHI.get(os, (long) (i))); >> ? ? ? ? MHI.set(os, (long) (i+1), (double) MHI.get(is, (long) >> (i+1)) + (double) MHI.get(os, (long) (i+1))); >> ? ? ? ? MHI.set(os, (long) (i+2), (double) MHI.get(is, (long) >> (i+2)) + (double) MHI.get(os, (long) (i+2))); >> ? ? ? ? MHI.set(os, (long) (i+3), (double) MHI.get(is, (long) >> (i+3)) + (double) MHI.get(os, (long) (i+3))); >> ? ? } >> } >> >> >> >> Best, >> -Antoine >> >> >> >> >> >> >> >> >> On Wed, Nov 25, 2020 at 1:42 PM Maurizio Cimadamore >> > > wrote: >> >> I did some investigation, and, during the problematic >> benchmark we were >> hitting some inline thresholds, as evidenced by >> `-XX:PrintInlining`: >> >> @ 92 jdk.incubator.foreign.MemoryAccess::getLongAtIndex >> (12 bytes) >> NodeCountInliningCutoff >> @ 96 jdk.incubator.foreign.MemoryAccess::setLongAtIndex >> (13 bytes) >> NodeCountInliningCutoff >> @ 111 jdk.incubator.foreign.MemoryAccess::getLongAtIndex >> (12 bytes) >> NodeCountInliningCutoff >> @ 120 jdk.incubator.foreign.MemoryAccess::getLongAtIndex >> (12 bytes) >> NodeCountInliningCutoff >> @ 124 jdk.incubator.foreign.MemoryAccess::setLongAtIndex >> (13 bytes) >> NodeCountInliningCutoff >> >> The problem is that the static accessors in MemoryAccess >> are lacking a >> @ForceInline annotation. This is being addressed here: >> >> https://github.com/openjdk/panama-foreign/pull/401 >> >> >> Thanks >> Maurizio >> >> >> On 25/11/2020 11:51, Maurizio Cimadamore wrote: >> > >> > On 24/11/2020 11:19, Antoine Chambille wrote: >> >> If I look at the slow benchmark in detail, I observe >> that the first >> >> two warmups run at the expected speed, but then it >> slows down 20x. >> >> Very strange, it's almost as if some JIT optimization >> is suddenly >> >> turned off: >> > >> > This is something I've observed in the past as well, in >> some cases, >> > when playing with VH. >> > >> > We'll take a look. >> > >> > Thanks >> > Maurizio >> > >> >> >> > From maurizio.cimadamore at oracle.com Tue Jan 5 18:52:41 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 5 Jan 2021 18:52:41 +0000 Subject: Foreign memory access hot loop benchmark In-Reply-To: References: <3c26c12c-23e0-a99f-03cd-afd6996c6478@oracle.com> <7ca53e08-3b3d-0db3-0493-1ecb0e44b79d@oracle.com> <0c431324-68b5-c0b0-3ced-5119ab51def9@oracle.com> <72ab9217-c638-88b9-b8fc-9ec91fab4cf6@oracle.com> Message-ID: <9c68d444-5b6e-3784-f058-460a4ba0d914@oracle.com> Good news, it wasn't as nasty as anticipated. It seems like your benchmark was accidentally comparing pears with apples - in the sense that the VarHandle created in your benchmark was checking alignment, while the ones we have in MemoryAccess do not. This is what I get with your code: Benchmark???????????????????????? Mode? Cnt? Score?? Error? Units AddBenchmark.unrolledMHI_long???? avgt?? 30? 2.947 ? 0.029? us/op AddBenchmark.unrolledMHI_v2_long? avgt?? 30? 0.341 ? 0.004? us/op AddBenchmark.unrolledUnsafe?????? avgt?? 30? 0.251 ? 0.002? us/op But the var handle is created as follows: static final VarHandle MHI_L = MemoryLayout.ofSequence(SIZE, MemoryLayouts.JAVA_LONG.withBitAlignment(8)) ??????????? .varHandle(long.class, MemoryLayout.PathElement.sequenceElement()); Then the numbers I get are much better: Benchmark???????????????????????? Mode? Cnt? Score?? Error? Units AddBenchmark.unrolledMHI_long???? avgt?? 30? 0.339 ? 0.005? us/op AddBenchmark.unrolledMHI_v2_long? avgt?? 30? 0.341 ? 0.004? us/op AddBenchmark.unrolledUnsafe?????? avgt?? 30? 0.256 ? 0.002? us/op We know we have issues when it comes to hoisting the alignment check out of loops (Vlad, do you happen to have a JBS issue for this?) - we have some workarounds in place which work for simple loops, but fail to work in more complex code like yours. Eventually, the upcoming improvements for long loop optimizations will hopefully render much of these edge cases obsolete. On 05/01/2021 16:50, Maurizio Cimadamore wrote: > Thanks, > I'll take a look - my guts tell me that the method is just too big > when using VH directly (something I've seen in other cases). Note that > the fact that we have @ForceInline on the MemoryAccess accessors > helps, since that will tell hotspot to always inline those access, no > matter the size of the enclosing method. I'm afraid here we're in a > situation where the benchmark method gets too big and no further > inlining happens (even though, if we progressed with inlining we'd end > up with a _smaller_ compiled method overall). > > I'll try to test this hypothesis. Stay tuned. > > Cheers > Maurizio > > > On 05/01/2021 16:45, Antoine Chambille wrote: >> Yes I see the same slowdown with longs than with doubles. >> >> -Antoine >> >> >> >> On Mon, Jan 4, 2021 at 7:33 PM Maurizio Cimadamore >> > > wrote: >> >> ??? What happens with longs? Do you still see the slowdown? >> >> ??? Maurizio >> >> ??? On 04/01/2021 17:31, Antoine Chambille wrote: >>> ??? /(using fixed width font ;)/ >>> >>> >>> ??? Thank you Maurizio, for looking into this. >>> >>> ??? This is a good find, I've just updated and rebuilt the Panama >>> ??? JDK, I confirm that the big slowdown with manually unrolled loop >>> ??? and memory handles has disappeared for the >>> ??? AddBenchmark.unrolledMHI_v2 benchmark. But it is apparently still >>> ??? present in one last case: AddBenchmark.unrolledMHI >>> >>> ??? Maybe another missing annotation? >>> >>> ??? Benchmark ? ? ? ?Mode ?Cnt ? ? ? ?Score ? ? ? ?Error ?Units >>> ??? AddBenchmark.scalarArray ? ? ? ? ? ?thrpt ? ?5 ?5270072.806 ? >>> ??? ?43618.821 ?ops/s >>> ??? AddBenchmark.scalarArrayHandle ? ? ?thrpt ? ?5 ?5155791.142 ? >>> ??? 122147.967 ?ops/s >>> ??? AddBenchmark.scalarMHI ? ? ? ? ? ? ?thrpt ? ?5 ?2215595.625 ? >>> ??? ?27044.786 ?ops/s >>> ??? AddBenchmark.scalarMHI_v2 ? ? ? ? ? thrpt ? ?5 ?2165838.557 ? >>> ??? ?48477.364 ?ops/s >>> ??? AddBenchmark.scalarUnsafe ? ? ? ? ? thrpt ? ?5 ?2057853.572 ? >>> ??? ?21064.385 ?ops/s >>> ??? AddBenchmark.unrolledArray ? ? ? ? ?thrpt ? ?5 ?6346056.064 ? >>> ??? 304425.251 ?ops/s >>> ??? AddBenchmark.unrolledArrayHandle ? ?thrpt ? ?5 ?1991324.025 ? >>> ??? ?39434.066 ?ops/s >>> ??? AddBenchmark.unrolledMHI ? ? ? ? ? ?thrpt ? ?5 206541.946 ? >>> ??? 4031.057 ?ops/s >>> ??? AddBenchmark.unrolledMHI_v2 ? ? ? ? thrpt ? ?5 ?2240957.905 ? >>> ??? ?24239.357 ?ops/s >>> ??? AddBenchmark.unrolledUnsafe ? ? ? ? thrpt ? ?5 ?2185038.207 ? >>> ??? ?27611.150 ?ops/s >>> >>> >>> ??? benchmark source code: >>> https://github.com/chamb/panama-benchmarks/blob/master/memory/src/main/java/com/activeviam/test/AddBenchmark.java >>> >>> >>> >>> ??? // CODE OF THE REMAINING SLOW BENCHMARK >>> ??? static final VarHandle MHI = MemoryLayout.ofSequence(SIZE, >>> ??? MemoryLayouts.JAVA_DOUBLE) >>> ??? ? ? ? ? ? ? .varHandle(double.class, >>> ??? MemoryLayout.PathElement.sequenceElement()); >>> >>> ??? @Benchmark >>> ??? public void unrolledMHI(Data state) { >>> ??? ? ? final MemorySegment is = state.inputSegment; >>> ??? ? ? final MemorySegment os = state.outputSegment; >>> >>> ??? ? ? for(int i = 0; i < SIZE; i+=4) { >>> ??? ? ? ? ? MHI.set(os, (long) (i), ? (double) MHI.get(is, (long) >>> ??? (i)) ? + (double) MHI.get(os, (long) (i))); >>> ??? ? ? ? ? MHI.set(os, (long) (i+1), (double) MHI.get(is, (long) >>> ??? (i+1)) + (double) MHI.get(os, (long) (i+1))); >>> ??? ? ? ? ? MHI.set(os, (long) (i+2), (double) MHI.get(is, (long) >>> ??? (i+2)) + (double) MHI.get(os, (long) (i+2))); >>> ??? ? ? ? ? MHI.set(os, (long) (i+3), (double) MHI.get(is, (long) >>> ??? (i+3)) + (double) MHI.get(os, (long) (i+3))); >>> ??? ? ? } >>> ??? } >>> >>> >>> >>> ??? Best, >>> ??? -Antoine >>> >>> >>> >>> >>> >>> >>> >>> >>> ??????? On Wed, Nov 25, 2020 at 1:42 PM Maurizio Cimadamore >>> ??????? >> ??????? > wrote: >>> >>> ??????????? I did some investigation, and, during the problematic >>> ??????????? benchmark we were >>> ??????????? hitting some inline thresholds, as evidenced by >>> ??????????? `-XX:PrintInlining`: >>> >>> ??????????? @ 92 jdk.incubator.foreign.MemoryAccess::getLongAtIndex >>> ??????????? (12 bytes) >>> ??????????? NodeCountInliningCutoff >>> ??????????? @ 96 jdk.incubator.foreign.MemoryAccess::setLongAtIndex >>> ??????????? (13 bytes) >>> ??????????? NodeCountInliningCutoff >>> ??????????? @ 111 jdk.incubator.foreign.MemoryAccess::getLongAtIndex >>> ??????????? (12 bytes) >>> ??????????? NodeCountInliningCutoff >>> ??????????? @ 120 jdk.incubator.foreign.MemoryAccess::getLongAtIndex >>> ??????????? (12 bytes) >>> ??????????? NodeCountInliningCutoff >>> ??????????? @ 124 jdk.incubator.foreign.MemoryAccess::setLongAtIndex >>> ??????????? (13 bytes) >>> ??????????? NodeCountInliningCutoff >>> >>> ??????????? The problem is that the static accessors in MemoryAccess >>> ??????????? are lacking a >>> ??????????? @ForceInline annotation. This is being addressed here: >>> >>> ??????????? https://github.com/openjdk/panama-foreign/pull/401 >>> >>> >>> ??????????? Thanks >>> ??????????? Maurizio >>> >>> >>> ??????????? On 25/11/2020 11:51, Maurizio Cimadamore wrote: >>> ??????????? > >>> ??????????? > On 24/11/2020 11:19, Antoine Chambille wrote: >>> ??????????? >> If I look at the slow benchmark in detail, I observe >>> ??????????? that the first >>> ??????????? >> two warmups run at the expected speed, but then it >>> ??????????? slows down 20x. >>> ??????????? >> Very strange, it's almost as if some JIT optimization >>> ??????????? is suddenly >>> ??????????? >> turned off: >>> ??????????? > >>> ??????????? > This is something I've observed in the past as well, in >>> ??????????? some cases, >>> ??????????? > when playing with VH. >>> ??????????? > >>> ??????????? > We'll take a look. >>> ??????????? > >>> ??????????? > Thanks >>> ??????????? > Maurizio >>> ??????????? > >>> >>> >>> >> From youngty1997 at gmail.com Tue Jan 5 21:02:02 2021 From: youngty1997 at gmail.com (Ty Young) Date: Tue, 5 Jan 2021 15:02:02 -0600 Subject: Panama source code fails to compile In-Reply-To: References: <5ea52f78-f853-57df-7c7f-fa299b091c55@gmail.com> <409652537.261382.1609190287324.JavaMail.zimbra@u-pem.fr> <9a74ba5e-523a-e96d-4e60-8d66b6e0516f@gmail.com> <9045aa0c-5454-3b18-13a1-b39252a29622@gmail.com> <30df2329-2332-1b6f-bc5f-6fb40974ca60@oracle.com> <11035576-2e05-4b30-0135-2cdd611bd3b9@oracle.com> <28b7134b-4006-ea85-eb16-49571a1f1c20@gmail.com> Message-ID: <9d2998ad-8af5-b9d8-4648-5bbd971e2152@gmail.com> On 1/4/21 3:21 PM, Maurizio Cimadamore wrote: > > > On 04/01/2021 19:38, Ty Young wrote: >>>> >>>> >>>> - Padding layout should probably be a subclass of ValueLayout and >>>> just override methods as needed. Having every memory layout have a >>>> isPadding() method doesn't make much sense. The PaddingLayout class >>>> can then be moved to an internal package as there is no way to >>>> create an instance outside of ofPaddingBits as an API user. The >>>> same could be done for AbstractLayout. >>> Are you talking about API or impl? Impl-wise, we could resort to >>> overriding for isPadding, but if PaddingLayout is to be >>> impl-private, then user has no way to do instanceof PaddingLayout, >>> so you need a predicate? >> >> >> Bit of both. ofValueBits can be modified to return a ValueLayout >> since, under this change, PaddingLayout extends ValueLayout and >> "is-a" ValueLayout. isPadding() will then be made exclusive to >> ValueLayout and would be how you determine if a ValueLayout is >> padding. If that method exists, I don't see a reason why exposing >> PaddingLayout as part of public API and letting a user do instanceof >> is needed as isPadding() exists. isPadding() should maybe use >> getClass() instead of instanceof, don't think it's a big deal but >> it's slightly faster IIRC. There isn't any reason to expose >> PaddingLayout or AbstractLayout in public API AFAIK. > > Gotcha. > > Yes, in principle padding can be a special case of value - except then > you have endianness thrown in as well which isn't horrible, but > doesn't make a lot of sense either. > > My mental model is more: > > LeafLayout > ValueLayout <: LeafLayout > PaddingLayout <: LeafLayout > > which then led to the current compressed hierarchy. > The current API doesn't do that anyway, ofPaddingBits() returns a MemoryLayout which is ambiguous in terms of implementation. Sure, in most cases people just make as many ofPaddingBits() calls as needed directly in a struct's layout so it doesn't matter, but if someone were to hypothetically store the returned MemoryLayout in a variable there would be no type information to indicate it was padding(this is already true for MemoryLayouts padding constants, actually). Someone could use a ValueLayout to pad the struct all the same. How about keeping PaddingLayout where it is, having ofPaddingLayout() return PaddingLayout, and remove isPadding() for every layout type? This way the type is clear and people can do instanceof and/or getClass() themselves ? Would you accept a pull request for that? >> >> >>>> >>>> >>>> - GroupLayout should probably be split into StructLayout and >>>> UnionLayout. This is the biggest change, but it simplifies the >>>> code, provides better clarity on what's actually being represented, >>>> and allows for future struct/union specific operations to be added >>>> without adding a bunch of if(!isUnion) throw new >>>> UnsupportedOperationException(); type code. >>> >>> Less sure about this. >>> >>> I think pattern matching will also help a great deal with this, at >>> some point. >> >> >> My understanding is that you need a type to do pattern matching? The >> Kind enum used internally for isStruct() and isUnion() is private. > > For now you need a type, yes. > > In the future, when pattern declaration will be available, we can add > an extractor for each static factory there is in the API. > > if (layout instanceof GroupLayout.ofStruct(layoutA, layoutB)) { > ? ... > } > > Something like that. > So abandoning long standing and existing good coding/API design practice(SOLID 1: Single Responsibility) in the now because someday in the future(probably 2+ years from now, I'm guessing?) we'll have a shiny new language feature that will let you do what you can do now if the API was improved? Not only are you potentially backing yourselves into a corner API design wise, you're forcing people to use language features they might not want to use. Is any of this pattern matching stuff going to be performant anyway? Like, an if statement comparing class pointers is faster than doing the code above, right? > Maurizio > >> >> >> If the issue is unifying the types then GroupLayout could maybe be >> repurposed so that it simply exposes memberLayouts() and other shared >> code? >> From mail at smogura.eu Tue Jan 5 22:32:06 2021 From: mail at smogura.eu (=?windows-1250?Q?Rados=B3aw_Smogura?=) Date: Tue, 5 Jan 2021 22:32:06 +0000 Subject: Performance improvement to unchecked segment ofNativeRestricted Message-ID: Hi all, I hope you have a good day. Here I would like to present some changes to increase performance of ofNativeRestricted - my benchmarks - where I tried to simulate access from code - outpaced the access to Java array (as intended). As it looks like that pull request flow has changed, I have to sign-up OCA (and if this change is fine I would be happy to do this). Below please find benchmark results and link to "pending PR" / branch The results outpaced the Java array access. Benchmark Mode Cnt Score Error Units AccessBenchmark.foreignAddress thrpt 4 86860188.499 ? 13454393.406 ops/s AccessBenchmark.foreignAddressRaw thrpt 4 96150181.668 ? 7025145.700 ops/s AccessBenchmark.target thrpt 4 93673099.539 ? 23272596.145 ops/s``` versus tests on original repo Benchmark Mode Cnt Score Error Units AccessBenchmark.foreignAddress thrpt 4 81907199.092 ? 2663269.652 ops/s AccessBenchmark.foreignAddressRaw thrpt 4 83629168.611 ? 1025857.535 ops/s AccessBenchmark.target thrpt 4 94023553.582 ? 6128411.421 ops/s https://github.com/openjdk/panama-foreign/pull/431 [https://avatars2.githubusercontent.com/u/41768318?s=400&v=4] [WIP] Performance improvement to unchecked segment ofNativeRestricted by rsmogura ? Pull Request #431 ? openjdk/panama-foreign Here's a proposition to tune the access to global scope. This changes, could help to outpace the access to Java arrays using [] operator. The results outpaced the Java array access. Benchmark ... github.com Kind regards, Rado From youngty1997 at gmail.com Wed Jan 6 01:59:41 2021 From: youngty1997 at gmail.com (Ty Young) Date: Tue, 5 Jan 2021 19:59:41 -0600 Subject: Performance improvement to unchecked segment ofNativeRestricted In-Reply-To: References: Message-ID: <751c4d06-02b3-7883-1c04-e152a43a0c52@gmail.com> You may also need to override checkValidState from AbstractMemorySegmentImpl in EverythingSegment. checkValidState calls the scope's checkValidState and since scope is null, you'll get a NPE. The list of methods that call checkValidState include: splitterator mismatch address handoff share registerCleaner close In short, if you do basically anything but simply read/write via VarHandle, including native library usage which uses address(), you're going to get a NPE. On 1/5/21 4:32 PM, Rados?aw Smogura wrote: > Hi all, > > I hope you have a good day. > > Here I would like to present some changes to increase performance of ofNativeRestricted - my benchmarks - where I tried to simulate access from code - outpaced the access to Java array (as intended). As it looks like that pull request flow has changed, I have to sign-up OCA (and if this change is fine I would be happy to do this). > > Below please find benchmark results and link to "pending PR" / branch > > The results outpaced the Java array access. > > Benchmark Mode Cnt Score Error Units > AccessBenchmark.foreignAddress thrpt 4 86860188.499 ? 13454393.406 ops/s > AccessBenchmark.foreignAddressRaw thrpt 4 96150181.668 ? 7025145.700 ops/s > AccessBenchmark.target thrpt 4 93673099.539 ? 23272596.145 ops/s``` > > versus tests on original repo > > Benchmark Mode Cnt Score Error Units > AccessBenchmark.foreignAddress thrpt 4 81907199.092 ? 2663269.652 ops/s > AccessBenchmark.foreignAddressRaw thrpt 4 83629168.611 ? 1025857.535 ops/s > AccessBenchmark.target thrpt 4 94023553.582 ? 6128411.421 ops/s > > https://github.com/openjdk/panama-foreign/pull/431 > [https://avatars2.githubusercontent.com/u/41768318?s=400&v=4] > [WIP] Performance improvement to unchecked segment ofNativeRestricted by rsmogura ? Pull Request #431 ? openjdk/panama-foreign > Here's a proposition to tune the access to global scope. This changes, could help to outpace the access to Java arrays using [] operator. The results outpaced the Java array access. Benchmark ... > github.com > > Kind regards, > Rado From whuang at openjdk.java.net Wed Jan 6 02:56:21 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Wed, 6 Jan 2021 02:56:21 GMT Subject: [vectorIntrinsics] RFR: 8258072: Add Reinterpret nodes implementation for Arm SVE [v5] In-Reply-To: References: Message-ID: <8dkDEPz0tu8PRvg83TcBlwvPTxUt93KrPMx8vZA7L3g=.019e2284-5969-4f72-a639-4c72592defdd@github.com> > Add reinterpret nodes implementation for Arm SVE. We also adjust the implementation of Matcher::min_vector_size in the same patch. Wang Huang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/29/files - new: https://git.openjdk.java.net/panama-vector/pull/29/files/d4213e84..31344a9f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=29&range=04 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=29&range=03-04 Stats: 171 lines in 4 files changed: 2 ins; 168 del; 1 mod Patch: https://git.openjdk.java.net/panama-vector/pull/29.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/29/head:pull/29 PR: https://git.openjdk.java.net/panama-vector/pull/29 From whuang at openjdk.java.net Wed Jan 6 02:56:23 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Wed, 6 Jan 2021 02:56:23 GMT Subject: [vectorIntrinsics] Integrated: 8258072: Add Reinterpret nodes implementation for Arm SVE In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 07:18:15 GMT, Wang Huang wrote: > Add reinterpret nodes implementation for Arm SVE. We also adjust the implementation of Matcher::min_vector_size in the same patch. This pull request has now been integrated. Changeset: 31344a9f Author: Paul Sandoz URL: https://git.openjdk.java.net/panama-vector/commit/31344a9f Stats: 153244 lines in 1123 files changed: 123871 ins; 10844 del; 18529 mod Merge panama-vector:master Reviewed-by: sviswanathan ------------- PR: https://git.openjdk.java.net/panama-vector/pull/29 From whuang at openjdk.java.net Wed Jan 6 03:05:08 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Wed, 6 Jan 2021 03:05:08 GMT Subject: [vectorIntrinsics] RFR: 8258072: Add Reinterpret nodes implementation for Arm SVE Message-ID: <0tvI-tWJBswl5w_-X0BMcPcreNiTuLWZDUSuFBrgGsA=.d22886ca-5a14-46f2-b84f-a1693ae565ad@github.com> Add reduction nodes support for Arm SVE. Add the backend codegen for node like "VectorReinterpret" . In this patch, We implement these instructs: * reinterpret (src == dst) * reinterpretExpand (src < dst) * reinterpretShrink (src > dst) At the same time, we fix a bug (JDK-8258989) because it is not merged in panama-vector/vectorIntrinsics. ------------- Commit messages: - 8258072: Add Reinterpret nodes implementation for Arm SVE Changes: https://git.openjdk.java.net/panama-vector/pull/30/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=30&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258072 Stats: 150 lines in 3 files changed: 147 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/panama-vector/pull/30.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/30/head:pull/30 PR: https://git.openjdk.java.net/panama-vector/pull/30 From xgong at openjdk.java.net Wed Jan 6 03:42:14 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 6 Jan 2021 03:42:14 GMT Subject: [vectorIntrinsics] RFR: 8258072: Add Reinterpret nodes implementation for Arm SVE In-Reply-To: <0tvI-tWJBswl5w_-X0BMcPcreNiTuLWZDUSuFBrgGsA=.d22886ca-5a14-46f2-b84f-a1693ae565ad@github.com> References: <0tvI-tWJBswl5w_-X0BMcPcreNiTuLWZDUSuFBrgGsA=.d22886ca-5a14-46f2-b84f-a1693ae565ad@github.com> Message-ID: <4tMcS8sGV0itq9PpeZTgl02cT45AGugFQzSnY6in4Uo=.fa108a19-5476-4ad8-a2e9-ce66a8b143b8@github.com> On Wed, 6 Jan 2021 03:00:08 GMT, Wang Huang wrote: > Add reduction nodes support for Arm SVE. Add the backend codegen for node like "VectorReinterpret" . > In this patch, We implement these instructs: > * reinterpret (src == dst) > * reinterpretExpand (src < dst) > * reinterpretShrink (src > dst) > At the same time, we fix a bug (JDK-8258989) because it is not merged in panama-vector/vectorIntrinsics. src/hotspot/cpu/aarch64/aarch64_sve.ad line 384: > 382: zr, as_Register($tmp$$reg)); > 383: __ sve_cpy(as_FloatRegister($dst$$reg), __ B, > 384: as_PRegister($pTmp$$reg), as_FloatRegister($src$$reg)); It seems using `cpy` is not right here, which usually accept a `imm, scalar or SIMD&FP scalar register`. This instruction is expected to copy the scalar value to each active element. So use `"mov"` instead ? BTW, the normal `MOV ., /M, .` instruction uses the `merging` feature of predicate while not `zeroing`. To make sure the non active elements are zero, do you think it's better to use `MOVS .B, /Z, .B` here? src/hotspot/cpu/aarch64/aarch64_sve.ad line 369: > 367: %} > 368: > 369: instruct reinterpretExpand(vReg dst, vReg src, iRegINoSp tmp, pRegGov pTmp, rFlagsReg cr) %{ Could you please add some comments for this rule? Thanks so much! src/hotspot/cpu/aarch64/aarch64_sve.ad line 390: > 388: %} > 389: > 390: instruct reinterpretShrink(vReg dst, vReg src, iRegINoSp tmp, pRegGov pTmp, rFlagsReg cr) %{ Could you please add some comments for this rule to describe why `predicate` is needed here? Thanks so much! src/hotspot/cpu/aarch64/aarch64_sve.ad line 116: > 114: } > 115: > 116: static inline uint vector_length_in_bytes(const Node* n) { Is it possible that we reuse the existed functions `vector_length` ? Besides, the argument type is `Node*` which is not the same with other functions that use `MachNode*` . Use the same type? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/30 From xgong at openjdk.java.net Wed Jan 6 07:11:04 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 6 Jan 2021 07:11:04 GMT Subject: [vectorIntrinsics] RFR: 8258072: Add Reinterpret nodes implementation for Arm SVE In-Reply-To: <4tMcS8sGV0itq9PpeZTgl02cT45AGugFQzSnY6in4Uo=.fa108a19-5476-4ad8-a2e9-ce66a8b143b8@github.com> References: <0tvI-tWJBswl5w_-X0BMcPcreNiTuLWZDUSuFBrgGsA=.d22886ca-5a14-46f2-b84f-a1693ae565ad@github.com> <4tMcS8sGV0itq9PpeZTgl02cT45AGugFQzSnY6in4Uo=.fa108a19-5476-4ad8-a2e9-ce66a8b143b8@github.com> Message-ID: On Wed, 6 Jan 2021 03:32:45 GMT, Xiaohong Gong wrote: >> Add reduction nodes support for Arm SVE. Add the backend codegen for node like "VectorReinterpret" . >> In this patch, We implement these instructs: >> * reinterpret (src == dst) >> * reinterpretExpand (src < dst) >> * reinterpretShrink (src > dst) >> At the same time, we fix a bug (JDK-8258989) because it is not merged in panama-vector/vectorIntrinsics. > > src/hotspot/cpu/aarch64/aarch64_sve.ad line 384: > >> 382: zr, as_Register($tmp$$reg)); >> 383: __ sve_cpy(as_FloatRegister($dst$$reg), __ B, >> 384: as_PRegister($pTmp$$reg), as_FloatRegister($src$$reg)); > > It seems using `cpy` is not right here, which usually accept a `imm, scalar or SIMD&FP scalar register`. This instruction is expected to copy the scalar value to each active element. So use `"mov"` instead ? BTW, the normal `MOV ., /M, .` instruction uses the `merging` feature of predicate while not `zeroing`. To make sure the non active elements are zero, do you think it's better to use `MOVS .B, /Z, .B` here? I'm sorry that I didn't notice this is an instruction for predicate `MOVS .B, /Z, .B`. So please ignore this suggestion. Thanks? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/30 From duke at openjdk.java.net Wed Jan 6 11:38:42 2021 From: duke at openjdk.java.net (duke) Date: Wed, 6 Jan 2021 11:38:42 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets Message-ID: Changeset: cfdacf13 Author: Ty Committer: Maurizio Cimadamore Date: 2021-01-06 11:36:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cfdacf13 Removed duplicate profile_memory_access function from methodData.cpp Reviewed-by: mcimadamore ! src/hotspot/share/oops/methodData.cpp Changeset: 1f0700c2 Author: duke Date: 2021-01-06 11:37:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1f0700c2 Automatic merge of foreign-memaccess+abi into foreign-jextract From github.com+10172435+bluegoliath at openjdk.java.net Wed Jan 6 11:40:05 2021 From: github.com+10172435+bluegoliath at openjdk.java.net (Ty Young) Date: Wed, 6 Jan 2021 11:40:05 GMT Subject: [foreign-memaccess+abi] Integrated: Removed duplicate profile_memory_access function from methodData.cpp In-Reply-To: References: Message-ID: On Sat, 2 Jan 2021 21:13:01 GMT, Ty Young wrote: > Removes the duplicate profile_memory_access function from methodData.cpp, which causes a build fail. This duplicate function does not exist in the foreign-jextract branch as there hasn't been a merge yet from foreign-memaccess+abi. > > Note: OCA filled out and sent but needs to be processed and my Github account needs to be registered. If it takes too long due to the holidays then I'll rescind the pull request. > > Note: 2 this is a resubmit to fix same-branch pull request issue the OpenJDK bot brought up. This pull request has now been integrated. Changeset: cfdacf13 Author: Ty Committer: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/cfdacf13 Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod Removed duplicate profile_memory_access function from methodData.cpp Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/427 From maurizio.cimadamore at oracle.com Wed Jan 6 11:43:20 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 6 Jan 2021 11:43:20 +0000 Subject: Performance improvement to unchecked segment ofNativeRestricted In-Reply-To: <751c4d06-02b3-7883-1c04-e152a43a0c52@gmail.com> References: <751c4d06-02b3-7883-1c04-e152a43a0c52@gmail.com> Message-ID: <5fc6d41c-3fd2-f14b-f72b-61104cc1d501@oracle.com> I think the fundamental idea is solid, and I agree there's room to improve performance here, but as Ty notes, having a NULL scope might be problematic. I think it would perhaps be better to have a constant/stateless, always open scope, whose checkValidState method does nothing? If that scope is stored in a final static constant, I believe C2 will not have many problems in eliminating the overhead of the scope check. Maurizio On 06/01/2021 01:59, Ty Young wrote: > > You may also need to override checkValidState from > AbstractMemorySegmentImpl in EverythingSegment. checkValidState calls > the scope's checkValidState and since scope is null, you'll get a NPE. > The list of methods that call checkValidState include: > > > splitterator > > mismatch > > address > > handoff > > share > > registerCleaner > > close > > > In short, if you do basically anything but simply read/write via > VarHandle, including native library usage which uses address(), you're > going to get a NPE. > > > > On 1/5/21 4:32 PM, Rados?aw Smogura wrote: >> Hi all, >> >> I hope you have a good day. >> >> Here I would like to present some changes to increase performance of >> ofNativeRestricted - my benchmarks - where I tried to simulate access >> from code - outpaced the access to Java array (as intended). As it >> looks like that pull request flow has changed, I have to sign-up OCA >> (and if this change is fine I would be happy to do this). >> >> Below please find benchmark results and link to "pending PR" / branch >> >> The results outpaced the Java array access. >> >> Benchmark?????????????????????????? Mode? Cnt Score????????? Error? >> Units >> AccessBenchmark.foreignAddress???? thrpt??? 4? 86860188.499 ? >> 13454393.406? ops/s >> AccessBenchmark.foreignAddressRaw? thrpt??? 4? 96150181.668 ? >> 7025145.700? ops/s >> AccessBenchmark.target???????????? thrpt??? 4? 93673099.539 ? >> 23272596.145? ops/s``` >> >> versus tests on original repo >> >> Benchmark?????????????????????????? Mode? Cnt Score???????? Error? Units >> AccessBenchmark.foreignAddress???? thrpt??? 4? 81907199.092 ? >> 2663269.652? ops/s >> AccessBenchmark.foreignAddressRaw? thrpt??? 4? 83629168.611 ? >> 1025857.535? ops/s >> AccessBenchmark.target???????????? thrpt??? 4? 94023553.582 ? >> 6128411.421? ops/s >> >> https://github.com/openjdk/panama-foreign/pull/431 >> [https://avatars2.githubusercontent.com/u/41768318?s=400&v=4] >> >> [WIP] Performance improvement to unchecked segment ofNativeRestricted >> by rsmogura ? Pull Request #431 ? >> openjdk/panama-foreign >> Here's a proposition to tune the access to global scope. This >> changes, could help to outpace the access to Java arrays using [] >> operator. The results outpaced the Java array access. Benchmark ... >> github.com >> >> Kind regards, >> Rado From maurizio.cimadamore at oracle.com Wed Jan 6 11:57:05 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 6 Jan 2021 11:57:05 +0000 Subject: Panama source code fails to compile In-Reply-To: <9d2998ad-8af5-b9d8-4648-5bbd971e2152@gmail.com> References: <5ea52f78-f853-57df-7c7f-fa299b091c55@gmail.com> <409652537.261382.1609190287324.JavaMail.zimbra@u-pem.fr> <9a74ba5e-523a-e96d-4e60-8d66b6e0516f@gmail.com> <9045aa0c-5454-3b18-13a1-b39252a29622@gmail.com> <30df2329-2332-1b6f-bc5f-6fb40974ca60@oracle.com> <11035576-2e05-4b30-0135-2cdd611bd3b9@oracle.com> <28b7134b-4006-ea85-eb16-49571a1f1c20@gmail.com> <9d2998ad-8af5-b9d8-4648-5bbd971e2152@gmail.com> Message-ID: On 05/01/2021 21:02, Ty Young wrote: > > The current API doesn't do that anyway, ofPaddingBits() returns a > MemoryLayout which is ambiguous in terms of implementation. Sure, in > most cases people just make as many ofPaddingBits() calls as needed > directly in a struct's layout so it doesn't matter, but if someone > were to hypothetically store the returned MemoryLayout in a variable > there would be no type information to indicate it was padding(this is > already true for MemoryLayouts padding constants, actually). Someone > could use a ValueLayout to pad the struct all the same. > > > How about keeping PaddingLayout where it is, having ofPaddingLayout() > return PaddingLayout, and remove isPadding() for every layout type? > This way the type is clear and people can do instanceof and/or > getClass() themselves ? Would you accept a pull request for that? > This is what the code _used_ to do. After having a fruitful chat with Brian about an year ago, we ended up compressing the hierarchy, precisely to make it more friendly with pattern matching. I think that we will regret adding an extra subclass (which we'll be stuck with forever) when clients will have a much better way to test if a layout is padding or not. Of course the world right now is suboptimal, and methods like isStruct/isUnion/isPadding kind of make up for that. But the vision is clear: these methods are placeholder for better pattern match predicates, and will likely be deprecated at some point in the future (and I think you can agree that deprecating a predicate method is much less intrusive than deprecating PaddingLayout/StructLayout/UnionLayout). For the records, this is also why the layout API does not have a visitor-like mechanism. As for the digression on whether we're breaking API principles and all that, I think pattern matching is a fact of life in Java (the first batch of work has been finalized in 16), and I'd rather design an API taking into account where the language might land, rather than design it in a silo. Of course you are right in that there's no guarantee on if and when later pattern matching features will show up - but if they do show up at some point (and I don't see why they shouldn't), I think we'd be sorry for having missed that train. And, if these feature do not make it, we're left with a bunch of predicates which, honestly, look pretty harmless to me. Anyway, point noted. Maurizio From paul.sandoz at oracle.com Wed Jan 6 17:52:35 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 6 Jan 2021 09:52:35 -0800 Subject: Calculating integral images / cumulative add In-Reply-To: References: Message-ID: <0EC71ABE-7E22-4958-81F1-B4801E8F4C77@oracle.com> Hi Stefan, No current plans for a scan (or prefix sum). You would have to roll your own, composed from other methods [1], which I think would be a good experiment and help inform what we could add to the API/implementation (Note: support for masks are not yet optimal, esp. on AVX512). FWIW the closest I have come to loops with some form of loop-based data dependency is vectorizing Java?s array hash code implementation. I?ll share that [2] just in case you are interested (I plan to update the relevant code in the repository to that of below.) Paul. [1] See Lemire?s work https://lemire.me/blog/2017/09/27/stream-vbyte-breaking-new-speed-records-for-integer-compression/ [2] package jmh; import jdk.incubator.vector.ByteVector; import jdk.incubator.vector.IntVector; import jdk.incubator.vector.VectorOperators; import jdk.incubator.vector.VectorSpecies; import org.openjdk.jmh.annotations.Benchmark; import org.openjdk.jmh.annotations.BenchmarkMode; import org.openjdk.jmh.annotations.Fork; import org.openjdk.jmh.annotations.Measurement; import org.openjdk.jmh.annotations.Mode; import org.openjdk.jmh.annotations.OutputTimeUnit; import org.openjdk.jmh.annotations.Param; import org.openjdk.jmh.annotations.Scope; import org.openjdk.jmh.annotations.Setup; import org.openjdk.jmh.annotations.State; import org.openjdk.jmh.annotations.Warmup; import java.util.Arrays; import java.util.concurrent.ThreadLocalRandom; import java.util.concurrent.TimeUnit; @BenchmarkMode(Mode.Throughput) @OutputTimeUnit(TimeUnit.MILLISECONDS) @State(Scope.Benchmark) @Warmup(iterations = 3, time = 1) @Measurement(iterations = 5, time = 1) @Fork(value = 1, jvmArgsPrepend = {"--add-modules=jdk.incubator.vector", "-Djdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK=2"}) public class TestHashcode { static final VectorSpecies INT_256_SPECIES = IntVector.SPECIES_256; static final VectorSpecies BYTE_64_SPECIES = ByteVector.SPECIES_64; static final VectorSpecies BYTE_128_SPECIES = ByteVector.SPECIES_128; static final VectorSpecies BYTE_256_SPECIES = ByteVector.SPECIES_256; static final int COEFF_31_TO_8; static final int COEFF_31_TO_16; static final int COEFF_31_TO_24; static final int COEFF_31_TO_32; static final IntVector H_COEFF_31_TO_8; static final IntVector H_COEFF_31_TO_16; static final IntVector H_COEFF_31_TO_24; static final IntVector H_COEFF_31_TO_32; static final IntVector H_COEFF_8; static final IntVector H_COEFF_16; static final IntVector H_COEFF_24; static final IntVector H_COEFF_32; static { int[] a = new int[INT_256_SPECIES.length() * 4]; a[a.length - 1] = 1; for (int i = 1; i < a.length; i++) { a[a.length - 1 - i] = a[a.length - 1 - i + 1] * 31; } COEFF_31_TO_8 = a[24] * 31; COEFF_31_TO_16 = a[16] * 31; COEFF_31_TO_24 = a[8] * 31; COEFF_31_TO_32 = a[0] * 31; H_COEFF_31_TO_8 = IntVector.broadcast(INT_256_SPECIES, COEFF_31_TO_8); H_COEFF_31_TO_16 = IntVector.broadcast(INT_256_SPECIES, COEFF_31_TO_16); H_COEFF_31_TO_24 = IntVector.broadcast(INT_256_SPECIES, COEFF_31_TO_24); H_COEFF_31_TO_32 = IntVector.broadcast(INT_256_SPECIES, COEFF_31_TO_32); H_COEFF_8 = IntVector.fromArray(INT_256_SPECIES, a, 24); H_COEFF_16 = IntVector.fromArray(INT_256_SPECIES, a, 16); H_COEFF_24 = IntVector.fromArray(INT_256_SPECIES, a, 8); H_COEFF_32 = IntVector.fromArray(INT_256_SPECIES, a, 0); } @Param("1024") int size; byte[] a; @Setup public void init() { a = new byte[size]; ThreadLocalRandom.current().nextBytes(a); } @Benchmark public int vector64ReduceInLoop() { int h = 1; int i = 0; // Force into registers IntVector c_H_COEFF_8 = H_COEFF_8.add(0); for (; i < BYTE_64_SPECIES.loopBound(a.length); i += BYTE_64_SPECIES.length()) { ByteVector b = ByteVector.fromArray(BYTE_64_SPECIES, a, i); IntVector x = (IntVector) b.castShape(INT_256_SPECIES, 0); h = h * COEFF_31_TO_8 + x.mul(c_H_COEFF_8).reduceLanes(VectorOperators.ADD); } for (; i < a.length; i++) { h = 31 * h + a[i]; } return h; } @Benchmark public int vector64() { IntVector h = IntVector.fromArray(INT_256_SPECIES, new int[]{1, 0, 0, 0, 0, 0, 0, 0}, 0); int i = 0; // Force into registers IntVector c_H_COEFF_8 = H_COEFF_8.add(0); IntVector c_H_COEFF_31_TO_8 = H_COEFF_31_TO_8.add(0); for (; i < BYTE_64_SPECIES.loopBound(a.length); i += BYTE_64_SPECIES.length()) { ByteVector b = ByteVector.fromArray(BYTE_64_SPECIES, a, i); IntVector x = (IntVector) b.castShape(INT_256_SPECIES, 0); h = h.mul(c_H_COEFF_31_TO_8).add(x.mul(c_H_COEFF_8)); } int sh = h.reduceLanes(VectorOperators.ADD); for (; i < a.length; i++) { sh = 31 * sh + a[i]; } return sh; } @Benchmark public int vector64Unrolledx2() { IntVector h1 = IntVector.fromArray(INT_256_SPECIES, new int[]{1, 0, 0, 0, 0, 0, 0, 0}, 0); IntVector h2 = IntVector.zero(INT_256_SPECIES); int i = 0; // Force into registers IntVector c_H_COEFF_16 = H_COEFF_16.add(0); IntVector c_H_COEFF_8 = H_COEFF_8.add(0); IntVector c_H_COEFF_31_TO_16 = H_COEFF_31_TO_16.add(0); for (; i < (a.length & ~(BYTE_128_SPECIES.length() - 1)); i += BYTE_128_SPECIES.length()) { ByteVector b = ByteVector.fromArray(BYTE_64_SPECIES, a, i); IntVector x = (IntVector) b.castShape(INT_256_SPECIES, 0); h1 = h1.mul(c_H_COEFF_31_TO_16).add(x.mul(c_H_COEFF_16)); b = ByteVector.fromArray(BYTE_64_SPECIES, a, i + BYTE_64_SPECIES.length()); x = (IntVector) b.castShape(INT_256_SPECIES, 0); h2 = h2.mul(c_H_COEFF_31_TO_16).add(x.mul(c_H_COEFF_8)); } int sh = h1.reduceLanes(VectorOperators.ADD) + h2.reduceLanes(VectorOperators.ADD); for (; i < a.length; i++) { sh = 31 * sh + a[i]; } return sh; } @Benchmark public int vector64Unrolledx4() { IntVector h1 = IntVector.fromArray(INT_256_SPECIES, new int[]{1, 0, 0, 0, 0, 0, 0, 0}, 0); IntVector h2 = IntVector.zero(INT_256_SPECIES); IntVector h3 = IntVector.zero(INT_256_SPECIES); IntVector h4 = IntVector.zero(INT_256_SPECIES); int i = 0; // Force into registers IntVector c_H_COEFF_8 = H_COEFF_8.add(0); IntVector c_H_COEFF_16 = H_COEFF_16.add(0); IntVector c_H_COEFF_24 = H_COEFF_24.add(0); IntVector c_H_COEFF_32 = H_COEFF_32.add(0); IntVector c_H_COEFF_31_TO_32 = H_COEFF_31_TO_32.add(0); for (; i < (a.length & ~(BYTE_256_SPECIES.length() - 1)); i += BYTE_256_SPECIES.length()) { ByteVector b = ByteVector.fromArray(BYTE_64_SPECIES, a, i); IntVector x = (IntVector) b.castShape(INT_256_SPECIES, 0); h1 = h1.mul(c_H_COEFF_31_TO_32).add(x.mul(c_H_COEFF_32)); b = ByteVector.fromArray(BYTE_64_SPECIES, a, i + BYTE_64_SPECIES.length()); x = (IntVector) b.castShape(INT_256_SPECIES, 0); h2 = h2.mul(c_H_COEFF_31_TO_32).add(x.mul(c_H_COEFF_24)); b = ByteVector.fromArray(BYTE_64_SPECIES, a, i + BYTE_64_SPECIES.length() * 2); x = (IntVector) b.castShape(INT_256_SPECIES, 0); h3 = h3.mul(c_H_COEFF_31_TO_32).add(x.mul(c_H_COEFF_16)); b = ByteVector.fromArray(BYTE_64_SPECIES, a, i + BYTE_64_SPECIES.length() * 3); x = (IntVector) b.castShape(INT_256_SPECIES, 0); h4 = h4.mul(c_H_COEFF_31_TO_32).add(x.mul(c_H_COEFF_8)); } int sh = h1.reduceLanes(VectorOperators.ADD) + h2.reduceLanes(VectorOperators.ADD) + h3.reduceLanes(VectorOperators.ADD) + h4.reduceLanes(VectorOperators.ADD); for (; i < a.length; i++) { sh = 31 * sh + a[i]; } return sh; } @Benchmark public int vector128Unrolledx2() { IntVector h1 = IntVector.fromArray(INT_256_SPECIES, new int[]{1, 0, 0, 0, 0, 0, 0, 0}, 0); IntVector h2 = IntVector.fromArray(INT_256_SPECIES, new int[]{0, 0, 0, 0, 0, 0, 0, 0}, 0); int i = 0; // Force into registers IntVector c_H_COEFF_16_P0 = H_COEFF_16.add(0); IntVector c_H_COEFF_16_P1 = H_COEFF_8.add(0); IntVector c_H_COEFF_31_TO_16 = H_COEFF_31_TO_16.add(0); for (; i < (a.length & ~(BYTE_128_SPECIES.length() - 1)); i += BYTE_128_SPECIES.length()) { ByteVector b = ByteVector.fromArray(BYTE_128_SPECIES, a, i); IntVector x = (IntVector) b.castShape(INT_256_SPECIES, 0); h1 = h1.mul(c_H_COEFF_31_TO_16).add(x.mul(c_H_COEFF_16_P0)); x = (IntVector) b.castShape(INT_256_SPECIES, 1); h2 = h2.mul(c_H_COEFF_31_TO_16).add(x.mul(c_H_COEFF_16_P1)); } int sh = h1.reduceLanes(VectorOperators.ADD) + h2.reduceLanes(VectorOperators.ADD); for (; i < a.length; i++) { sh = 31 * sh + a[i]; } return sh; } @Benchmark public int vector256Unrolledx4() { IntVector h1 = IntVector.fromArray(INT_256_SPECIES, new int[]{1, 0, 0, 0, 0, 0, 0, 0}, 0); IntVector h2 = IntVector.zero(INT_256_SPECIES); IntVector h3 = IntVector.zero(INT_256_SPECIES); IntVector h4 = IntVector.zero(INT_256_SPECIES); int i = 0; // Force into registers IntVector c_H_COEFF_8 = H_COEFF_8.add(0); IntVector c_H_COEFF_16 = H_COEFF_16.add(0); IntVector c_H_COEFF_24 = H_COEFF_24.add(0); IntVector c_H_COEFF_32 = H_COEFF_32.add(0); IntVector c_H_COEFF_31_TO_32 = H_COEFF_31_TO_32.add(0); for (; i < (a.length & ~(BYTE_256_SPECIES.length() - 1)); i += BYTE_256_SPECIES.length()) { ByteVector b = ByteVector.fromArray(BYTE_256_SPECIES, a, i); IntVector x = (IntVector) b.castShape(INT_256_SPECIES, 0); h1 = h1.mul(c_H_COEFF_31_TO_32).add(x.mul(c_H_COEFF_32)); x = (IntVector) b.castShape(INT_256_SPECIES, 1); h2 = h2.mul(c_H_COEFF_31_TO_32).add(x.mul(c_H_COEFF_24)); x = (IntVector) b.castShape(INT_256_SPECIES, 2); h3 = h3.mul(c_H_COEFF_31_TO_32).add(x.mul(c_H_COEFF_16)); x = (IntVector) b.castShape(INT_256_SPECIES, 3); h4 = h4.mul(c_H_COEFF_31_TO_32).add(x.mul(c_H_COEFF_8)); } int sh = h1.reduceLanes(VectorOperators.ADD) + h2.reduceLanes(VectorOperators.ADD) + h3.reduceLanes(VectorOperators.ADD) + h4.reduceLanes(VectorOperators.ADD); for (; i < a.length; i++) { sh = 31 * sh + a[i]; } return sh; } @Benchmark public int scalar() { return Arrays.hashCode(a); } @Benchmark public int scalarUnrolled() { if (a == null) return 0; int h = 1; int i = 0; for (; i < (a.length & ~(8 - 1)); i += 8) { h = h * 31 * 31 * 31 * 31 * 31 * 31 * 31 * 31 + a[i + 0] * 31 * 31 * 31 * 31 * 31 * 31 * 31 + a[i + 1] * 31 * 31 * 31 * 31 * 31 * 31 + a[i + 2] * 31 * 31 * 31 * 31 * 31 + a[i + 3] * 31 * 31 * 31 * 31 + a[i + 4] * 31 * 31 * 31 + a[i + 5] * 31 * 31 + a[i + 6] * 31 + a[i + 7]; } for (; i < a.length; i++) { h = 31 * h + a[i]; } return h; } } > On Jan 4, 2021, at 5:51 PM, Stefan Reich wrote: > > Oh I just saw this in the presentation > : > > ? Segmented scan (reduce with partials and mask-driven reset) > > That's probably what I want... so it's not there yet? > > On Tue, 5 Jan 2021 at 02:31, Stefan Reich < > stefan.reich.maker.of.eye at googlemail.com> wrote: > >> Hi, >> >> I am trying to vectorize my routine that constructs an integral image / "summed-area >> table" . >> >> int i = 0; >> for (int y = 0; y < h; y++) { >> int sum = 0; >> for (int x = 0; x < w; x++) { >> sum += image[i]; >> data[i] = y > 0 ? sum + data[i-w] : sum; >> i++; >> } >> } >> >> In order to use the Vector API, I'd need an operation that does a >> cumulative summing over the lanes, e.g. for a 4-component vector: >> >> b[0] = a[0] >> b[1] = a[0]+a[1] >> b[2] = a[0]+a[1]+a[2] >> b[3] = a[0]+a[1]+a[2]+a[3] >> >> I don't think this is available in the current Vector API, is it? >> >> Thanks, >> Stefan >> >> -- >> Stefan Reich >> BotCompany.de // Java-based operating systems >> > > > -- > Stefan Reich > BotCompany.de // Java-based operating systems From leerho at gmail.com Wed Jan 6 20:34:27 2021 From: leerho at gmail.com (leerho) Date: Wed, 6 Jan 2021 12:34:27 -0800 Subject: [foreign-memaccess] musing on the memory access API In-Reply-To: <3b0c2cd5-e49b-24fe-2fe6-fc57c5dd3693@oracle.com> References: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> <083001d6e2c9$1aae9040$500bb0c0$@apache.org> <1a830d5e-233c-e54e-6b3c-d679c7297410@oracle.com> <08af01d6e2f4$cdae0600$690a1200$@apache.org> <3b0c2cd5-e49b-24fe-2fe6-fc57c5dd3693@oracle.com> Message-ID: Maurizio, Re: AllocationHandles, MemorySegments, MemoryAddress ideas I want to share with you our Memory Package (Writeup , GitHub ) we started in May, 2017 (JDK8) where we developed a capability very similar to what you are advocating. This Memory project is very analogous to your MemorySegment and our Handles implement something very similar to your AllocationHandles idea but with some other capabilities. This Memory Project was developed to support high-performance off-heap capabilities to support our Apache DataSketches project. Because we were limited to JDK8, we had to jump through a bunch of hoops to accomplish what we did using Unsafe, and gaining access to other hidden classes. Hopefully, what Panama is doing will eliminate the need to do this. Rather than repeating everything here, it is best if you could read the writeup and let me know what you think. I don't think the code is much use to you, but perhaps some of the ideas might be. Cheers, Lee. On Tue, Jan 5, 2021 at 3:59 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > On 04/01/2021 23:53, Uwe Schindler wrote: > > Hi Maurizio, > > > >> Thanks for the feedback Uwe, and for the bug reports. We'll do our best > >> to address some of them quickly (the NPE and the error in > >> Unmapper::address). As for adding an overload for mapping a segment from > >> a FileChannel I'm totally open to it, but I think it's late-ish now to > >> add API changes, since we are in stabilization. > > Hi, this was only a suggestion to improve the whole thing. My idea is > more to wait for this until a more close integration into the FileSystem > API is done. The main issue we had was that we can only pass a path from > the default file system provider (I have a workaround for that, so during > our testsuite we "unwrap" all the layers on top). But correctly, the > FileSystem implementation should provide the way how to get a MemorySegment > from the FileChannel, the current cast to the internal class is ... hacky! > I know why it is like that (preview and it's not part of java base, so the > FileSystem interface in java.base can't return a MemorySegment). But when > Panama graduates, the filesystem integration is a must!: FileChannel should > be extended by one "default" method throwing UOE, only implemented by > default provider: "MemorySegment FileChannel.mapSegment(long offset, long > size, MapMode mode)" > +1 - this has been raised in the past as well, and I agree that the > issue is more at the FileSystem interface level - we can't really do > much at the level of the segment API as things stand. I'm less convinced > that this is a "must" - while it's a nice to have, and something we > should defo get working in the future, I don't think that by blocking > integration of Panama APIs because mapped segments do not work with > custom file system will be the right choice. > > > >> Also, thanks for the thoughts on the API in general - I kind of expected > >> (given our discussions) that shared segments were 90% of what you needed > >> - and that you are not much interested in using confinement. I agree > >> that, when working from that angle, the API looks mostly ok. But not all > >> clients have same requirements and some would like to take advantage of > >> confinement more - also, note that if we just drop support for confined > >> segments (which is something we also thought about) and just offered > >> shared access, _all_ clients will be stuck with a very slow close() > >> operation. > > Hi, yes, I agree. I just said: Switching between those modes is > unlikely, but yet a confined default for long living segments is correct, > shared for long living ones (this is also the usage pattern: something that > ?lives very long is very likely often also used by many threads, like a > database file or some database off-heap cache). Allocated memory used in > netty is of course often short-lived, but it is in most cases not really > concurrently used (or you can avoid it). > > > > I'd give the user the option on constructing, but don't allow to change > it later. > > > >> There are very different ways to use a memory segment; sometimes (as in > >> your case) a memory segment is long-lived, and you don't care if closing > >> it takes 1 us. But there are other cases where segments are created (and > >> disposed) more frequently. To me, the interesting fact that emerged from > >> the Netty experiment (thanks guys!) was that using handoff AND shared > >> segment, while nice on paper it's not going to work performance-wise, > >> because you need to do an expensive close at each hand-off. This might > >> be rectified, for instance by making the API more complex, and have a > >> state where a segment has no owner (e.g. so that instead of confined(A) > >> -> shared -> confined(B) you do confined(A) -> detached -> confined(B) > >> ), but the risk is that to add a lot of API complexity ("detached" is a > >> brand new segment state in which the segment is not accessible, but > >> where memory is not yet deallocated) for what might be perceived as a > >> corner case. > >> So, the big question here is - given that there are defo different modes > >> to interact with this API (short lived vs. long lived segment), what API > >> allows us to capture the use cases we want in the simplest way possible? > >> While dynamic ownership changes look like a cool idea on paper, it also > >> add complexity - so I think now it's the right time to ask ourself if we > >> should scale back on that a bit and have a more "static" set of flavors > >> to pick from (e.g. { confined, shared } x { explicit, cleaner } > > I think, when "allocating" a segment (by reserving memory, mapping a > file, supplying some external MemoryAddress and length), you should set > confined or shared from the beginning, without a possibility to change it. > This would indeed simplify many things. I got new benchmarks a minute ago > from my Lucene colleagues: the current MemorySegmentAPI seems 40% slower > than ByteBuffer for some use cases, but equal of speed/faster for other > use cases (I assume it is still long vs. int index/looping problems; a for > loop using LONG is not as good optimized as a for loop with INT -- > correct?). But without diving too deep, it might also come from the fact > that the memory segments *may* change their state, so hotspot is not able > to do all optimizations. > > If you have for loops with long indices, then yes, this is not > optimized, and unfortunately expected to be slow. Also, to counteract > that, the impl has many optimization so that, if a segment size can be > represented as an int, many of the long operations are eliminated and > replaced with int operations (e.g. bound checks). But if you work with > true big segments (which I suspect is the case for Lucene), most of > these optimization would not kick in. Luckily a lot of progress has been > made on the long vs. int problem, but the work is not finished - I hope > it will by the time 17 ships, so that we can remove all the hacks we > have from the impl. That said, if you have specific benchmarks to throw > our way we'd be happy to look at them! > > In our benchmark we have not observed slowdown caused to memory segment > changing their state (note that they don't really change their state - a > new instance with new properties is returned). > > Thanks > Maurizio > > > From maurizio.cimadamore at oracle.com Wed Jan 6 21:53:50 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 6 Jan 2021 21:53:50 +0000 Subject: [foreign-memaccess] musing on the memory access API In-Reply-To: References: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> <083001d6e2c9$1aae9040$500bb0c0$@apache.org> <1a830d5e-233c-e54e-6b3c-d679c7297410@oracle.com> <08af01d6e2f4$cdae0600$690a1200$@apache.org> <3b0c2cd5-e49b-24fe-2fe6-fc57c5dd3693@oracle.com> Message-ID: Thanks Lee, I'll defo look that up. Cheers Maurizio On 06/01/2021 20:34, leerho wrote: > Maurizio, > > Re: AllocationHandles, MemorySegments, MemoryAddress ideas > > I want to share with you our Memory Package (Writeup > , > GitHub > ) > we started in May, 2017 (JDK8) where we developed a capability very > similar to what you are advocating.? This Memory project is very > analogous to your MemorySegment and our Handles implement something > very similar to your AllocationHandles idea but with some other > capabilities. > > This Memory Project was developed to support high-performance off-heap > capabilities to support ourApache DataSketches > > project. > > Because we were limited to JDK8, we had to jump through a bunch of > hoops to accomplish what we did using Unsafe, and gaining access to > other hidden classes. Hopefully, what Panama is doing will eliminate > the need to do this. > > Rather than repeating everything here, it is best if you could read > the writeup and let me know what you think. I don't think the code is > much use to you, but perhaps some of the ideas might be. > > Cheers, > > Lee. > > On Tue, Jan 5, 2021 at 3:59 AM Maurizio Cimadamore > > wrote: > > > On 04/01/2021 23:53, Uwe Schindler wrote: > > Hi Maurizio, > > > >> Thanks for the feedback Uwe, and for the bug reports. We'll do > our best > >> to address some of them quickly (the NPE and the error in > >> Unmapper::address). As for adding an overload for mapping a > segment from > >> a FileChannel I'm totally open to it, but I think it's late-ish > now to > >> add API changes, since we are in stabilization. > > Hi, this was only a suggestion to improve the whole thing. My > idea is more to wait for this until a more close integration into > the FileSystem API is done. The main issue we had was that we can > only pass a path from the default file system provider (I have a > workaround for that, so during our testsuite we "unwrap" all the > layers on top). But correctly, the FileSystem implementation > should provide the way how to get a MemorySegment from the > FileChannel, the current cast to the internal class is ... hacky! > I know why it is like that (preview and it's not part of java > base, so the FileSystem interface in java.base can't return a > MemorySegment). But when Panama graduates, the filesystem > integration is a must!: FileChannel should be extended by one > "default" method throwing UOE, only implemented by default > provider: "MemorySegment FileChannel.mapSegment(long offset, long > size, MapMode mode)" > +1 - this has been raised in the past as well, and I agree that the > issue is more at the FileSystem interface level - we can't really do > much at the level of the segment API as things stand. I'm less > convinced > that this is a "must" - while it's a nice to have, and something we > should defo get working in the future, I don't think that by blocking > integration of Panama APIs because mapped segments do not work with > custom file system will be the right choice. > > > >> Also, thanks for the thoughts on the API in general - I kind of > expected > >> (given our discussions) that shared segments were 90% of what > you needed > >> - and that you are not much interested in using confinement. I > agree > >> that, when working from that angle, the API looks mostly ok. > But not all > >> clients have same requirements and some would like to take > advantage of > >> confinement more - also, note that if we just drop support for > confined > >> segments (which is something we also thought about) and just > offered > >> shared access, _all_ clients will be stuck with a very slow close() > >> operation. > > Hi, yes, I agree. I just said: Switching between those modes is > unlikely, but yet a confined default for long living segments is > correct, shared for long living ones (this is also the usage > pattern: something that ?lives very long is very likely often also > used by many threads, like a database file or some database > off-heap cache). Allocated memory used in netty is of course often > short-lived, but it is in most cases not really concurrently used > (or you can avoid it). > > > > I'd give the user the option on constructing, but don't allow to > change it later. > > > >> There are very different ways to use a memory segment; > sometimes (as in > >> your case) a memory segment is long-lived, and you don't care > if closing > >> it takes 1 us. But there are other cases where segments are > created (and > >> disposed) more frequently. To me, the interesting fact that > emerged from > >> the Netty experiment (thanks guys!) was that using handoff AND > shared > >> segment, while nice on paper it's not going to work > performance-wise, > >> because you need to do an expensive close at each hand-off. > This might > >> be rectified, for instance by making the API more complex, and > have a > >> state where a segment has no owner (e.g. so that instead of > confined(A) > >> -> shared -> confined(B) you do confined(A) -> detached -> > confined(B) > >> ), but the risk is that to add a lot of API complexity > ("detached" is a > >> brand new segment state in which the segment is not accessible, but > >> where memory is not yet deallocated) for what might be > perceived as a > >> corner case. > >> So, the big question here is - given that there are defo > different modes > >> to interact with this API (short lived vs. long lived segment), > what API > >> allows us to capture the use cases we want in the simplest way > possible? > >> While dynamic ownership changes look like a cool idea on paper, > it also > >> add complexity - so I think now it's the right time to ask > ourself if we > >> should scale back on that a bit and have a more "static" set of > flavors > >> to pick from (e.g. { confined, shared } x { explicit, cleaner } > > I think, when "allocating" a segment (by reserving memory, > mapping a file, supplying some external MemoryAddress and length), > you should set confined or shared from the beginning, without a > possibility to change it. This would indeed simplify many things. > I got new benchmarks a minute ago from my Lucene colleagues: the > current MemorySegmentAPI seems 40% slower than ByteBuffer? for > some use cases, but equal of speed/faster for other use cases (I > assume it is still long vs. int index/looping problems; a for loop > using LONG is not as good optimized as a for loop with INT -- > correct?). But without diving too deep, it might also come from > the fact that the memory segments *may* change their state, so > hotspot is not able to do all optimizations. > > If you have for loops with long indices, then yes, this is not > optimized, and unfortunately expected to be slow. Also, to counteract > that, the impl has many optimization so that, if a segment size > can be > represented as an int, many of the long operations are eliminated and > replaced with int operations (e.g. bound checks). But if you work > with > true big segments (which I suspect is the case for Lucene), most of > these optimization would not kick in. Luckily a lot of progress > has been > made on the long vs. int problem, but the work is not finished - I > hope > it will by the time 17 ships, so that we can remove all the hacks we > have from the impl. That said, if you have specific benchmarks to > throw > our way we'd be happy to look at them! > > In our benchmark we have not observed slowdown caused to memory > segment > changing their state (note that they don't really change their > state - a > new instance with new properties is returned). > > Thanks > Maurizio > > From john.r.rose at oracle.com Wed Jan 6 22:09:58 2021 From: john.r.rose at oracle.com (John Rose) Date: Wed, 6 Jan 2021 14:09:58 -0800 Subject: Calculating integral images / cumulative add In-Reply-To: References: Message-ID: <2EE3AD91-C965-4F86-809E-1FD865747109@oracle.com> On Jan 4, 2021, at 5:51 PM, Stefan Reich wrote: > > Oh I just saw this in the presentation > >: > > ? Segmented scan (reduce with partials and mask-driven reset) > > That's probably what I want... so it's not there yet? You can do a lot of really nice algorithms, including parsing and nested parallelism, with good segmented scan primitives. (I learned this from Guy Steele in the Connection Machine days.) I hope the V-API will support this some day, but IMO we need some good use cases (like yours) to motivate the work, plus some pathfinding. Also, to be honest, the SIMD hardware today is not yet up to the standards of the Connection Machine of the ?80s, with respect to those use cases. (The other thing today?s HW is missing, compared to the CM, is reverse permutations, AKA sorting networks, AKA parallel deposit. Scatter is the current approximation, but it doesn?t handle collisions well.) One step at a time? For pathfinding, I suggest building the primitives you need (using binary tree decomposition) on top of the existing stuff. It won?t be as fast w/o JIT support, and your patience will be tried sorely by the lack of support for OO abstraction over vector computations. (Function abstraction is likely to work better.) I think that?s a direct route to exploring the opportunities here. ? John From stefan.reich.maker.of.eye at googlemail.com Wed Jan 6 22:20:16 2021 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Wed, 6 Jan 2021 23:20:16 +0100 Subject: Calculating integral images / cumulative add In-Reply-To: <2EE3AD91-C965-4F86-809E-1FD865747109@oracle.com> References: <2EE3AD91-C965-4F86-809E-1FD865747109@oracle.com> Message-ID: Hi Paul and John, thank you for your replies! I think I may have found a workable compromise. I will process 8x8 blocks of the image at a time, calculating only the integral image values at grid points (x & 7 == 0 || y & 7 == 0) and filling in the blocks only when requested by the image recognition algorithm looking at the integral image. So basically the conversion of a block is just this: VectorSpecies species = IntVector.SPECIES_256; int[] rowSums = new int[8]; int[] colSums = new int[8]; IntVector vColSums = IntVector.zero(species); for (int y = 0; y < 8; y++) { IntVector v = IntVector.fromArray(species, image, y*8); rowSums[y] = v.reduceLanes(VectorOperators.ADD); vColSums = vColSums.add(v); } vColSums.intoArray(colSums, 0); For turning a whole 1080p screenshot into an integral image (in B/W), I am already below 10 ms using two cores. Still I'd love to bring this down even more, just for the sake of it. Video about my nascent image recognition if anyone is interested Thanks On Wed, 6 Jan 2021 at 23:10, John Rose wrote: > On Jan 4, 2021, at 5:51 PM, Stefan Reich < > stefan.reich.maker.of.eye at googlemail.com> wrote: > > > Oh I just saw this in the presentation > : > > ? Segmented scan (reduce with partials and mask-driven reset) > > That's probably what I want... so it's not there yet? > > > You can do a lot of really nice algorithms, including parsing > and nested parallelism, with good segmented scan primitives. > (I learned this from Guy Steele in the Connection Machine days.) > > I hope the V-API will support this some day, but IMO we need > some good use cases (like yours) to motivate the work, plus some > pathfinding. Also, to be honest, the SIMD hardware today is > not yet up to the standards of the Connection Machine of the > ?80s, with respect to those use cases. (The other thing today?s > HW is missing, compared to the CM, is reverse permutations, > AKA sorting networks, AKA parallel deposit. Scatter is the > current approximation, but it doesn?t handle collisions well.) > > One step at a time? For pathfinding, I suggest building the > primitives you need (using binary tree decomposition) on top > of the existing stuff. It won?t be as fast w/o JIT support, and > your patience will be tried sorely by the lack of support for > OO abstraction over vector computations. (Function > abstraction is likely to work better.) I think that?s a direct > route to exploring the opportunities here. > > ? John > > > > -- Stefan Reich BotCompany.de // Java-based operating systems From stefan.reich.maker.of.eye at googlemail.com Wed Jan 6 22:36:46 2021 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Wed, 6 Jan 2021 23:36:46 +0100 Subject: General comment about Panama Message-ID: It's fantastic! Such a smart approach, it's actually decent to read and it really is able to speed things up. Gives you that tingly feeling of controlling the CPU very directly, while still staying on the convenient Java level. Only thing that I find unfortunate is naming the package jdk.incubator.vector. So when JDK 16 ships, I'll be forced to change my imports? Well, not that big of a deal I guess, just a temporary inconvenience. BTW I actually do make "operating systems" in Java - well, it's an integrated persistence framework + module loader + GUI + Java evaluator + networking toolkit... so it's like the upper part of an OS if you will. Screenshot Greetings -- Stefan Reich BotCompany.de // Java-based operating systems From whuang at openjdk.java.net Thu Jan 7 02:26:20 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 7 Jan 2021 02:26:20 GMT Subject: [vectorIntrinsics] RFR: 8258072: Add Reinterpret nodes implementation for Arm SVE [v2] In-Reply-To: <0tvI-tWJBswl5w_-X0BMcPcreNiTuLWZDUSuFBrgGsA=.d22886ca-5a14-46f2-b84f-a1693ae565ad@github.com> References: <0tvI-tWJBswl5w_-X0BMcPcreNiTuLWZDUSuFBrgGsA=.d22886ca-5a14-46f2-b84f-a1693ae565ad@github.com> Message-ID: > Add reduction nodes support for Arm SVE. Add the backend codegen for node like "VectorReinterpret" . > In this patch, We implement these instructs: > * reinterpret (src == dst) > * reinterpretExpand (src < dst) > * reinterpretShrink (src > dst) > At the same time, we fix a bug (JDK-8258989) because it is not merged in panama-vector/vectorIntrinsics. Wang Huang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8258072: Add Reinterpret nodes implementation for Arm SVE ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/30/files - new: https://git.openjdk.java.net/panama-vector/pull/30/files/64f7e7f9..f1de6a0b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=30&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=30&range=00-01 Stats: 77 lines in 2 files changed: 5 ins; 39 del; 33 mod Patch: https://git.openjdk.java.net/panama-vector/pull/30.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/30/head:pull/30 PR: https://git.openjdk.java.net/panama-vector/pull/30 From njian at openjdk.java.net Thu Jan 7 03:17:03 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Thu, 7 Jan 2021 03:17:03 GMT Subject: [vectorIntrinsics] RFR: 8258072: Add Reinterpret nodes implementation for Arm SVE [v2] In-Reply-To: References: <0tvI-tWJBswl5w_-X0BMcPcreNiTuLWZDUSuFBrgGsA=.d22886ca-5a14-46f2-b84f-a1693ae565ad@github.com> Message-ID: <5Uxb4UqKQDNQic9lpuXLTv8XqqwCcHD3DITDlRQx8N8=.818303ce-ecf4-4b9c-b837-d48d4ac16865@github.com> On Thu, 7 Jan 2021 02:26:20 GMT, Wang Huang wrote: >> Add reduction nodes support for Arm SVE. Add the backend codegen for node like "VectorReinterpret" . >> In this patch, We implement these instructs: >> * reinterpret (src == dst) >> * reinterpretResize, including, >> 1? reinterpret?Expand? (src < dst) >> 2? reinterpret?Shrink? (src > dst) >> >> At the same time, we fix a bug (JDK-8258989) because it is not merged in panama-vector/vectorIntrinsics. > > Wang Huang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. @Wanghuang-Huawei Please do not have a force-push as it breaks review history. src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 line 35: > 33: define(`TYPE2DATATYPE', > 34: `ifelse($1, `B', `BYTE', > 35: $1, `S', `SHORT', Not used in this patch? src/hotspot/cpu/aarch64/aarch64_sve.ad line 387: > 385: __ sve_whilelo(as_PRegister($pTmp$$reg), __ B, > 386: zr, as_Register($tmp$$reg)); > 387: __ sve_cpy(as_FloatRegister($dst$$reg), __ B, ptrue, 0, false); Is this sve_dup()? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/30 From xgong at openjdk.java.net Thu Jan 7 03:17:04 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 7 Jan 2021 03:17:04 GMT Subject: [vectorIntrinsics] RFR: 8258072: Add Reinterpret nodes implementation for Arm SVE [v2] In-Reply-To: References: <0tvI-tWJBswl5w_-X0BMcPcreNiTuLWZDUSuFBrgGsA=.d22886ca-5a14-46f2-b84f-a1693ae565ad@github.com> Message-ID: On Thu, 7 Jan 2021 02:26:20 GMT, Wang Huang wrote: >> Add reduction nodes support for Arm SVE. Add the backend codegen for node like "VectorReinterpret" . >> In this patch, We implement these instructs: >> * reinterpret (src == dst) >> * reinterpretResize, including, >> 1? reinterpret?Expand? (src < dst) >> 2? reinterpret?Shrink? (src > dst) >> >> At the same time, we fix a bug (JDK-8258989) because it is not merged in panama-vector/vectorIntrinsics. > > Wang Huang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 line 374: > 372: ins_pipe(pipe_class_empty); > 373: %}')dnl > 374: REINTERPRET(16) Can it directly use the instruct itself instead of the macro here? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/30 From whuang at openjdk.java.net Thu Jan 7 07:25:06 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 7 Jan 2021 07:25:06 GMT Subject: [vectorIntrinsics] RFR: 8258072: Add Reinterpret nodes implementation for Arm SVE [v2] In-Reply-To: <5Uxb4UqKQDNQic9lpuXLTv8XqqwCcHD3DITDlRQx8N8=.818303ce-ecf4-4b9c-b837-d48d4ac16865@github.com> References: <0tvI-tWJBswl5w_-X0BMcPcreNiTuLWZDUSuFBrgGsA=.d22886ca-5a14-46f2-b84f-a1693ae565ad@github.com> <5Uxb4UqKQDNQic9lpuXLTv8XqqwCcHD3DITDlRQx8N8=.818303ce-ecf4-4b9c-b837-d48d4ac16865@github.com> Message-ID: On Thu, 7 Jan 2021 02:32:18 GMT, Ningsheng Jian wrote: >> Wang Huang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8258072: Add Reinterpret nodes implementation for Arm SVE > > src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 line 35: > >> 33: define(`TYPE2DATATYPE', >> 34: `ifelse($1, `B', `BYTE', >> 35: $1, `S', `SHORT', > > Not used in this patch? Thank you. It is used for our next patch. I will delete these. > src/hotspot/cpu/aarch64/aarch64_sve.ad line 387: > >> 385: __ sve_whilelo(as_PRegister($pTmp$$reg), __ B, >> 386: zr, as_Register($tmp$$reg)); >> 387: __ sve_cpy(as_FloatRegister($dst$$reg), __ B, ptrue, 0, false); > > Is this sve_dup()? OK? we will use this instruction. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/30 From whuang at openjdk.java.net Thu Jan 7 07:25:07 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 7 Jan 2021 07:25:07 GMT Subject: [vectorIntrinsics] RFR: 8258072: Add Reinterpret nodes implementation for Arm SVE [v2] In-Reply-To: References: <0tvI-tWJBswl5w_-X0BMcPcreNiTuLWZDUSuFBrgGsA=.d22886ca-5a14-46f2-b84f-a1693ae565ad@github.com> Message-ID: <46nh5g1RoA8IXkgPiF714zGmV2GeMZpaUfdEgE6MTaQ=.0dee89ac-d212-47b3-84ac-4a41dff892b9@github.com> On Thu, 7 Jan 2021 03:14:00 GMT, Xiaohong Gong wrote: >> Wang Huang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8258072: Add Reinterpret nodes implementation for Arm SVE > > src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 line 374: > >> 372: ins_pipe(pipe_class_empty); >> 373: %}')dnl >> 374: REINTERPRET(16) > > Can it directly use the instruct itself instead of the macro here? OK. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/30 From whuang at openjdk.java.net Thu Jan 7 07:29:19 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 7 Jan 2021 07:29:19 GMT Subject: [vectorIntrinsics] RFR: 8258072: Add Reinterpret nodes implementation for Arm SVE [v3] In-Reply-To: <0tvI-tWJBswl5w_-X0BMcPcreNiTuLWZDUSuFBrgGsA=.d22886ca-5a14-46f2-b84f-a1693ae565ad@github.com> References: <0tvI-tWJBswl5w_-X0BMcPcreNiTuLWZDUSuFBrgGsA=.d22886ca-5a14-46f2-b84f-a1693ae565ad@github.com> Message-ID: <4vCnF9BLd8j7qJ3bo8Tale-v7_LY9RMQD1M2IWjwSKI=.4e96b8ee-355e-4551-8bee-e08b891c8674@github.com> > Add reduction nodes support for Arm SVE. Add the backend codegen for node like "VectorReinterpret" . > In this patch, We implement these instructs: > * reinterpret (src == dst) > * reinterpretResize, including, > 1? reinterpret?Expand? (src < dst) > 2? reinterpret?Shrink? (src > dst) > > At the same time, we fix a bug (JDK-8258989) because it is not merged in panama-vector/vectorIntrinsics. Wang Huang has updated the pull request incrementally with one additional commit since the last revision: fix reinterpretNode implementation ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/30/files - new: https://git.openjdk.java.net/panama-vector/pull/30/files/f1de6a0b..73e7c2cb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=30&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=30&range=01-02 Stats: 17 lines in 2 files changed: 0 ins; 11 del; 6 mod Patch: https://git.openjdk.java.net/panama-vector/pull/30.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/30/head:pull/30 PR: https://git.openjdk.java.net/panama-vector/pull/30 From whuang at openjdk.java.net Thu Jan 7 07:37:00 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 7 Jan 2021 07:37:00 GMT Subject: [vectorIntrinsics] RFR: 8258072: Add Reinterpret nodes implementation for Arm SVE [v3] In-Reply-To: <4tMcS8sGV0itq9PpeZTgl02cT45AGugFQzSnY6in4Uo=.fa108a19-5476-4ad8-a2e9-ce66a8b143b8@github.com> References: <0tvI-tWJBswl5w_-X0BMcPcreNiTuLWZDUSuFBrgGsA=.d22886ca-5a14-46f2-b84f-a1693ae565ad@github.com> <4tMcS8sGV0itq9PpeZTgl02cT45AGugFQzSnY6in4Uo=.fa108a19-5476-4ad8-a2e9-ce66a8b143b8@github.com> Message-ID: <5BWsEinnp1OZDjPYcW7d6CNGi26dyV7TsnwhQ3bCFy4=.697988cb-8436-486d-a366-35b81c5f5141@github.com> On Wed, 6 Jan 2021 03:38:19 GMT, Xiaohong Gong wrote: >> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> fix reinterpretNode implementation > > src/hotspot/cpu/aarch64/aarch64_sve.ad line 116: > >> 114: } >> 115: >> 116: static inline uint vector_length_in_bytes(const Node* n) { > > Is it possible that we reuse the existed functions `vector_length` ? Besides, the argument type is `Node*` which is not the same with other functions that use `MachNode*` . Use the same type? We port these functions from x86.ad. We will change the type to `MachNode *` in next commit. Thank you. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/30 From whuang at openjdk.java.net Thu Jan 7 07:41:04 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 7 Jan 2021 07:41:04 GMT Subject: [vectorIntrinsics] RFR: 8258072: Add Reinterpret nodes implementation for Arm SVE [v3] In-Reply-To: References: <0tvI-tWJBswl5w_-X0BMcPcreNiTuLWZDUSuFBrgGsA=.d22886ca-5a14-46f2-b84f-a1693ae565ad@github.com> <4tMcS8sGV0itq9PpeZTgl02cT45AGugFQzSnY6in4Uo=.fa108a19-5476-4ad8-a2e9-ce66a8b143b8@github.com> Message-ID: On Wed, 6 Jan 2021 07:08:12 GMT, Xiaohong Gong wrote: >> src/hotspot/cpu/aarch64/aarch64_sve.ad line 384: >> >>> 382: zr, as_Register($tmp$$reg)); >>> 383: __ sve_cpy(as_FloatRegister($dst$$reg), __ B, >>> 384: as_PRegister($pTmp$$reg), as_FloatRegister($src$$reg)); >> >> It seems using `cpy` is not right here, which usually accept a `imm, scalar or SIMD&FP scalar register`. This instruction is expected to copy the scalar value to each active element. So use `"mov"` instead ? BTW, the normal `MOV ., /M, .` instruction uses the `merging` feature of predicate while not `zeroing`. To make sure the non active elements are zero, do you think it's better to use `MOVS .B, /Z, .B` here? > > I'm sorry that I didn't notice this is an instruction for predicate `MOVS .B, /Z, .B`. So please ignore this suggestion. Thanks? OK. We change our algorithm and use other instructions instead of these. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/30 From xgong at openjdk.java.net Thu Jan 7 07:49:12 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 7 Jan 2021 07:49:12 GMT Subject: [vectorIntrinsics] RFR: 8258072: Add Reinterpret nodes implementation for Arm SVE [v2] In-Reply-To: <5Uxb4UqKQDNQic9lpuXLTv8XqqwCcHD3DITDlRQx8N8=.818303ce-ecf4-4b9c-b837-d48d4ac16865@github.com> References: <0tvI-tWJBswl5w_-X0BMcPcreNiTuLWZDUSuFBrgGsA=.d22886ca-5a14-46f2-b84f-a1693ae565ad@github.com> <5Uxb4UqKQDNQic9lpuXLTv8XqqwCcHD3DITDlRQx8N8=.818303ce-ecf4-4b9c-b837-d48d4ac16865@github.com> Message-ID: On Thu, 7 Jan 2021 03:12:00 GMT, Ningsheng Jian wrote: >> Wang Huang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8258072: Add Reinterpret nodes implementation for Arm SVE > > @Wanghuang-Huawei Please do not have a force-push as it breaks review history. LGTM, thanks! ------------- PR: https://git.openjdk.java.net/panama-vector/pull/30 From maurizio.cimadamore at oracle.com Thu Jan 7 11:07:43 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 7 Jan 2021 11:07:43 +0000 Subject: [foreign-memaccess] musing on the memory access API In-Reply-To: References: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> <083001d6e2c9$1aae9040$500bb0c0$@apache.org> <1a830d5e-233c-e54e-6b3c-d679c7297410@oracle.com> <08af01d6e2f4$cdae0600$690a1200$@apache.org> <3b0c2cd5-e49b-24fe-2fe6-fc57c5dd3693@oracle.com> Message-ID: <1dbc05b4-87e9-8626-5619-df93f49a6999@oracle.com> Overall very nice read - as you noted there are indeed many overlaps between your memory package and the memory access API. Few notes: * Your use of handles is indeed identical to what I proposed in my email, thanks for pointing that out * You attach operations such as force/load/isLoaded in the handle for mapped memory, which is something that occurred to me as well (in our API, these operations are currently statics on a separate class) * At the beginning, the doc claims protection from use after free even in concurrent use - looking at the code that doesn't seem to be the case though? E.g. it's true that updates to the "valid" bit of the memory state are atomic, but that doesn't rule out the possibility of multiple threads seeing a "true" value, then being interleaved with a memory released, which would ultimately result in access free? I the Java 16 iteration of the API we address this problem too, but at a much lower level (we needed some VM/GC black magic to pull this off). * The main differences between the memory access API and your API seem to be in how dereference is done - you opted for virtual methods, while we go all in on var handles (and then we provide a bunch of static accessors on the side). I think the two are similar, although I think I'm happy where we landed with our API, since using the pre-baked statics is not any harder than using an instance method, but in exchange we get a lot of capabilities of out the var handle API (such as atomic access and adaptation). This decision has repercussions on the API, of course: the fact that we use MemorySegment as a VarHandle coordinate means we cannot get too crazy with hierarchies on the MemorySegment front - in fact, when we tried to do that (at some point we had MappedMemorySegment <: MemorySegment) we ran into performance issues, as memory access var handle need exact type information to be fast. * I believe/hope that the main gripes you had with the byte buffer API (which seem to be endianness related) are gone with the memory access API. There we made the decision of leaving endianness outside of the MemorySegment - e.g. endianness is a property of the VarHandle doing the access, not a property of the segment per se. I believe this decision paid off (e.g. our segments are completely orthogonal w.r.t. layout decisions), and avoids a lot of confusion as to "what's the default" etc. * Because of the above (segments and layouts are orthogonal) it also means that you can view the same segments in different ways, by overlaying different layouts on top. This is especially evident in the spliterator method: https://download.java.net/java/early_access/jdk16/docs/api/jdk.incubator.foreign/jdk/incubator/foreign/MemorySegment.html#spliterator(jdk.incubator.foreign.SequenceLayout) This takes an arbitrary sequence layout and then splits the segment according to the provided layout boundaries. Overall, it seems to me that the memory access API should (hopefully) a good fit for your use case - we'd be interested to know any benchmark comparison you might have, in case you decide to try our API out. Thanks again for the pointers, very interesting stuff! Cheers Maurizio On 06/01/2021 21:53, Maurizio Cimadamore wrote: > Thanks Lee, > I'll defo look that up. > > Cheers > Maurizio > > On 06/01/2021 20:34, leerho wrote: >> Maurizio, >> >> Re: AllocationHandles, MemorySegments, MemoryAddress ideas >> >> I want to share with you our Memory Package (Writeup >> , >> GitHub >> ) >> we started in May, 2017 (JDK8) where we developed a capability very >> similar to what you are advocating.? This Memory project is very >> analogous to your MemorySegment and our Handles implement something >> very similar to your AllocationHandles idea but with some other >> capabilities. >> >> This Memory Project was developed to support high-performance >> off-heap capabilities to support ourApache DataSketches >> >> project. >> >> Because we were limited to JDK8, we had to jump through a bunch of >> hoops to accomplish what we did using Unsafe, and gaining access to >> other hidden classes. Hopefully, what Panama is doing will eliminate >> the need to do this. >> >> Rather than repeating everything here, it is best if you could read >> the writeup and let me know what you think. I don't think the code is >> much use to you, but perhaps some of the ideas might be. >> >> Cheers, >> >> Lee. >> >> On Tue, Jan 5, 2021 at 3:59 AM Maurizio Cimadamore >> > > wrote: >> >> >> ??? On 04/01/2021 23:53, Uwe Schindler wrote: >> ??? > Hi Maurizio, >> ??? > >> ??? >> Thanks for the feedback Uwe, and for the bug reports. We'll do >> ??? our best >> ??? >> to address some of them quickly (the NPE and the error in >> ??? >> Unmapper::address). As for adding an overload for mapping a >> ??? segment from >> ??? >> a FileChannel I'm totally open to it, but I think it's late-ish >> ??? now to >> ??? >> add API changes, since we are in stabilization. >> ??? > Hi, this was only a suggestion to improve the whole thing. My >> ??? idea is more to wait for this until a more close integration into >> ??? the FileSystem API is done. The main issue we had was that we can >> ??? only pass a path from the default file system provider (I have a >> ??? workaround for that, so during our testsuite we "unwrap" all the >> ??? layers on top). But correctly, the FileSystem implementation >> ??? should provide the way how to get a MemorySegment from the >> ??? FileChannel, the current cast to the internal class is ... hacky! >> ??? I know why it is like that (preview and it's not part of java >> ??? base, so the FileSystem interface in java.base can't return a >> ??? MemorySegment). But when Panama graduates, the filesystem >> ??? integration is a must!: FileChannel should be extended by one >> ??? "default" method throwing UOE, only implemented by default >> ??? provider: "MemorySegment FileChannel.mapSegment(long offset, long >> ??? size, MapMode mode)" >> ??? +1 - this has been raised in the past as well, and I agree that the >> ??? issue is more at the FileSystem interface level - we can't really do >> ??? much at the level of the segment API as things stand. I'm less >> ??? convinced >> ??? that this is a "must" - while it's a nice to have, and something we >> ??? should defo get working in the future, I don't think that by >> blocking >> ??? integration of Panama APIs because mapped segments do not work with >> ??? custom file system will be the right choice. >> ??? > >> ??? >> Also, thanks for the thoughts on the API in general - I kind of >> ??? expected >> ??? >> (given our discussions) that shared segments were 90% of what >> ??? you needed >> ??? >> - and that you are not much interested in using confinement. I >> ??? agree >> ??? >> that, when working from that angle, the API looks mostly ok. >> ??? But not all >> ??? >> clients have same requirements and some would like to take >> ??? advantage of >> ??? >> confinement more - also, note that if we just drop support for >> ??? confined >> ??? >> segments (which is something we also thought about) and just >> ??? offered >> ??? >> shared access, _all_ clients will be stuck with a very slow >> close() >> ??? >> operation. >> ??? > Hi, yes, I agree. I just said: Switching between those modes is >> ??? unlikely, but yet a confined default for long living segments is >> ??? correct, shared for long living ones (this is also the usage >> ??? pattern: something that ?lives very long is very likely often also >> ??? used by many threads, like a database file or some database >> ??? off-heap cache). Allocated memory used in netty is of course often >> ??? short-lived, but it is in most cases not really concurrently used >> ??? (or you can avoid it). >> ??? > >> ??? > I'd give the user the option on constructing, but don't allow to >> ??? change it later. >> ??? > >> ??? >> There are very different ways to use a memory segment; >> ??? sometimes (as in >> ??? >> your case) a memory segment is long-lived, and you don't care >> ??? if closing >> ??? >> it takes 1 us. But there are other cases where segments are >> ??? created (and >> ??? >> disposed) more frequently. To me, the interesting fact that >> ??? emerged from >> ??? >> the Netty experiment (thanks guys!) was that using handoff AND >> ??? shared >> ??? >> segment, while nice on paper it's not going to work >> ??? performance-wise, >> ??? >> because you need to do an expensive close at each hand-off. >> ??? This might >> ??? >> be rectified, for instance by making the API more complex, and >> ??? have a >> ??? >> state where a segment has no owner (e.g. so that instead of >> ??? confined(A) >> ??? >> -> shared -> confined(B) you do confined(A) -> detached -> >> ??? confined(B) >> ??? >> ), but the risk is that to add a lot of API complexity >> ??? ("detached" is a >> ??? >> brand new segment state in which the segment is not >> accessible, but >> ??? >> where memory is not yet deallocated) for what might be >> ??? perceived as a >> ??? >> corner case. >> ??? >> So, the big question here is - given that there are defo >> ??? different modes >> ??? >> to interact with this API (short lived vs. long lived segment), >> ??? what API >> ??? >> allows us to capture the use cases we want in the simplest way >> ??? possible? >> ??? >> While dynamic ownership changes look like a cool idea on paper, >> ??? it also >> ??? >> add complexity - so I think now it's the right time to ask >> ??? ourself if we >> ??? >> should scale back on that a bit and have a more "static" set of >> ??? flavors >> ??? >> to pick from (e.g. { confined, shared } x { explicit, cleaner } >> ??? > I think, when "allocating" a segment (by reserving memory, >> ??? mapping a file, supplying some external MemoryAddress and length), >> ??? you should set confined or shared from the beginning, without a >> ??? possibility to change it. This would indeed simplify many things. >> ??? I got new benchmarks a minute ago from my Lucene colleagues: the >> ??? current MemorySegmentAPI seems 40% slower than ByteBuffer for >> ??? some use cases, but equal of speed/faster for other use cases (I >> ??? assume it is still long vs. int index/looping problems; a for loop >> ??? using LONG is not as good optimized as a for loop with INT -- >> ??? correct?). But without diving too deep, it might also come from >> ??? the fact that the memory segments *may* change their state, so >> ??? hotspot is not able to do all optimizations. >> >> ??? If you have for loops with long indices, then yes, this is not >> ??? optimized, and unfortunately expected to be slow. Also, to >> counteract >> ??? that, the impl has many optimization so that, if a segment size >> ??? can be >> ??? represented as an int, many of the long operations are eliminated >> and >> ??? replaced with int operations (e.g. bound checks). But if you work >> ??? with >> ??? true big segments (which I suspect is the case for Lucene), most of >> ??? these optimization would not kick in. Luckily a lot of progress >> ??? has been >> ??? made on the long vs. int problem, but the work is not finished - I >> ??? hope >> ??? it will by the time 17 ships, so that we can remove all the hacks we >> ??? have from the impl. That said, if you have specific benchmarks to >> ??? throw >> ??? our way we'd be happy to look at them! >> >> ??? In our benchmark we have not observed slowdown caused to memory >> ??? segment >> ??? changing their state (note that they don't really change their >> ??? state - a >> ??? new instance with new properties is returned). >> >> ??? Thanks >> ??? Maurizio >> >> From jorn.vernee at oracle.com Thu Jan 7 12:27:55 2021 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Thu, 7 Jan 2021 13:27:55 +0100 Subject: [foreign-memaccess] musing on the memory access API In-Reply-To: References: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> <083001d6e2c9$1aae9040$500bb0c0$@apache.org> <1a830d5e-233c-e54e-6b3c-d679c7297410@oracle.com> <08af01d6e2f4$cdae0600$690a1200$@apache.org> <3b0c2cd5-e49b-24fe-2fe6-fc57c5dd3693@oracle.com> Message-ID: Hi Lee, I've read the writeup as well, and it's nice to see some of our own design decisions being reflected :) In the writeup you say in the introduction: "... the ByteBuffer API is extremely limited and contains serious defects in its design and traps that many users of the ByteBuffer class unwittingly fall into, which results in corrupted data", which is echoed several times later. I'm wondering which defects and traps you are talking about specifically here? (maybe there are some we hadn't considered) Thanks, Jorn On 06/01/2021 21:34, leerho wrote: > Maurizio, > > Re: AllocationHandles, MemorySegments, MemoryAddress ideas > > I want to share with you our Memory Package (Writeup > , GitHub > ) we started in May, 2017 > (JDK8) where we developed a capability very similar to what you are > advocating. This Memory project is very analogous to your MemorySegment > and our Handles implement something very similar to your AllocationHandles > idea but with some other capabilities. > > This Memory Project was developed to support high-performance off-heap > capabilities to support our Apache DataSketches > project. > > Because we were limited to JDK8, we had to jump through a bunch of hoops to > accomplish what we did using Unsafe, and gaining access to other hidden > classes. Hopefully, what Panama is doing will eliminate the need to do this. > > Rather than repeating everything here, it is best if you could read the > writeup and let me know what you think. I don't think the code is much use > to you, but perhaps some of the ideas might be. > > Cheers, > > Lee. > > On Tue, Jan 5, 2021 at 3:59 AM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> On 04/01/2021 23:53, Uwe Schindler wrote: >>> Hi Maurizio, >>> >>>> Thanks for the feedback Uwe, and for the bug reports. We'll do our best >>>> to address some of them quickly (the NPE and the error in >>>> Unmapper::address). As for adding an overload for mapping a segment from >>>> a FileChannel I'm totally open to it, but I think it's late-ish now to >>>> add API changes, since we are in stabilization. >>> Hi, this was only a suggestion to improve the whole thing. My idea is >> more to wait for this until a more close integration into the FileSystem >> API is done. The main issue we had was that we can only pass a path from >> the default file system provider (I have a workaround for that, so during >> our testsuite we "unwrap" all the layers on top). But correctly, the >> FileSystem implementation should provide the way how to get a MemorySegment >> from the FileChannel, the current cast to the internal class is ... hacky! >> I know why it is like that (preview and it's not part of java base, so the >> FileSystem interface in java.base can't return a MemorySegment). But when >> Panama graduates, the filesystem integration is a must!: FileChannel should >> be extended by one "default" method throwing UOE, only implemented by >> default provider: "MemorySegment FileChannel.mapSegment(long offset, long >> size, MapMode mode)" >> +1 - this has been raised in the past as well, and I agree that the >> issue is more at the FileSystem interface level - we can't really do >> much at the level of the segment API as things stand. I'm less convinced >> that this is a "must" - while it's a nice to have, and something we >> should defo get working in the future, I don't think that by blocking >> integration of Panama APIs because mapped segments do not work with >> custom file system will be the right choice. >>>> Also, thanks for the thoughts on the API in general - I kind of expected >>>> (given our discussions) that shared segments were 90% of what you needed >>>> - and that you are not much interested in using confinement. I agree >>>> that, when working from that angle, the API looks mostly ok. But not all >>>> clients have same requirements and some would like to take advantage of >>>> confinement more - also, note that if we just drop support for confined >>>> segments (which is something we also thought about) and just offered >>>> shared access, _all_ clients will be stuck with a very slow close() >>>> operation. >>> Hi, yes, I agree. I just said: Switching between those modes is >> unlikely, but yet a confined default for long living segments is correct, >> shared for long living ones (this is also the usage pattern: something that >> ?lives very long is very likely often also used by many threads, like a >> database file or some database off-heap cache). Allocated memory used in >> netty is of course often short-lived, but it is in most cases not really >> concurrently used (or you can avoid it). >>> I'd give the user the option on constructing, but don't allow to change >> it later. >>>> There are very different ways to use a memory segment; sometimes (as in >>>> your case) a memory segment is long-lived, and you don't care if closing >>>> it takes 1 us. But there are other cases where segments are created (and >>>> disposed) more frequently. To me, the interesting fact that emerged from >>>> the Netty experiment (thanks guys!) was that using handoff AND shared >>>> segment, while nice on paper it's not going to work performance-wise, >>>> because you need to do an expensive close at each hand-off. This might >>>> be rectified, for instance by making the API more complex, and have a >>>> state where a segment has no owner (e.g. so that instead of confined(A) >>>> -> shared -> confined(B) you do confined(A) -> detached -> confined(B) >>>> ), but the risk is that to add a lot of API complexity ("detached" is a >>>> brand new segment state in which the segment is not accessible, but >>>> where memory is not yet deallocated) for what might be perceived as a >>>> corner case. >>>> So, the big question here is - given that there are defo different modes >>>> to interact with this API (short lived vs. long lived segment), what API >>>> allows us to capture the use cases we want in the simplest way possible? >>>> While dynamic ownership changes look like a cool idea on paper, it also >>>> add complexity - so I think now it's the right time to ask ourself if we >>>> should scale back on that a bit and have a more "static" set of flavors >>>> to pick from (e.g. { confined, shared } x { explicit, cleaner } >>> I think, when "allocating" a segment (by reserving memory, mapping a >> file, supplying some external MemoryAddress and length), you should set >> confined or shared from the beginning, without a possibility to change it. >> This would indeed simplify many things. I got new benchmarks a minute ago >> from my Lucene colleagues: the current MemorySegmentAPI seems 40% slower >> than ByteBuffer for some use cases, but equal of speed/faster for other >> use cases (I assume it is still long vs. int index/looping problems; a for >> loop using LONG is not as good optimized as a for loop with INT -- >> correct?). But without diving too deep, it might also come from the fact >> that the memory segments *may* change their state, so hotspot is not able >> to do all optimizations. >> >> If you have for loops with long indices, then yes, this is not >> optimized, and unfortunately expected to be slow. Also, to counteract >> that, the impl has many optimization so that, if a segment size can be >> represented as an int, many of the long operations are eliminated and >> replaced with int operations (e.g. bound checks). But if you work with >> true big segments (which I suspect is the case for Lucene), most of >> these optimization would not kick in. Luckily a lot of progress has been >> made on the long vs. int problem, but the work is not finished - I hope >> it will by the time 17 ships, so that we can remove all the hacks we >> have from the impl. That said, if you have specific benchmarks to throw >> our way we'd be happy to look at them! >> >> In our benchmark we have not observed slowdown caused to memory segment >> changing their state (note that they don't really change their state - a >> new instance with new properties is returned). >> >> Thanks >> Maurizio >> >> >> From paul.sandoz at oracle.com Thu Jan 7 19:03:52 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 7 Jan 2021 11:03:52 -0800 Subject: General comment about Panama In-Reply-To: References: Message-ID: <6EC54566-3E49-4E21-9FA0-EA65C8F27483@oracle.com> Hi Stefan, The package naming is deliberate as per the requirement for incubator modules. While incubating over releases the API is likely to change, as we receive feedback and gain more experience, in addition to applying new language and library features to the API (features of Project Valhalla should have a positive impact). Once the API exits incubation name will change to a stable name, and the API will likely become part of Java SE and merged into java.base. Paul. > On Jan 6, 2021, at 2:36 PM, Stefan Reich wrote: > > It's fantastic! Such a smart approach, it's actually decent to read and it > really is able to speed things up. Gives you that tingly feeling of > controlling the CPU very directly, while still staying on the convenient > Java level. > > Only thing that I find unfortunate is naming the package > jdk.incubator.vector. So when JDK 16 ships, I'll be forced to change my > imports? Well, not that big of a deal I guess, just a temporary > inconvenience. > > BTW I actually do make "operating systems" in Java - well, it's an > integrated persistence framework + module loader + GUI + Java evaluator + > networking toolkit... so it's like the upper part of an OS if you will. > Screenshot > > Greetings > > -- > Stefan Reich > BotCompany.de // Java-based operating systems From mail at smogura.eu Thu Jan 7 22:09:21 2021 From: mail at smogura.eu (=?windows-1250?Q?Rados=B3aw_Smogura?=) Date: Thu, 7 Jan 2021 22:09:21 +0000 Subject: Performance improvement to unchecked segment ofNativeRestricted Message-ID: Hi all, Thanks for feedback, and good to hear it's a good direction. In fact my first change included a global scope, as Maurizio suggested. I added this null scope, as I have impression I constantly hit this check private int getIntUnalignedInternal(Scope scope, Object base, long offset, boolean be) { /* ...*/ if (scope != null) { scope.checkValidState(); } /* ... */ } And I could not understand why hotspot leaves scope != null, and inlines empty method ('else' part looked more like jump to a trap). Now, I tired to use IGV to understand why, rebased one commit back, and it's ok... I'll update branch, back-up original one, take closer look again, clean it, and come back later. Thanks again for checks, and sorry for not needed bother. Kind regards, Rado > I think the fundamental idea is solid, and I agree there's room to > improve performance here, but as Ty notes, having a NULL scope might be > problematic. I think it would perhaps be better to have a > constant/stateless, always open scope, whose checkValidState method does > nothing? If that scope is stored in a final static constant, I believe > C2 will not have many problems in eliminating the overhead of the scope > check. > > Maurizio > > On 06/01/2021 01:59, Ty Young wrote: >> >> You may also need to override checkValidState from >> AbstractMemorySegmentImpl in EverythingSegment. checkValidState calls >> the scope's checkValidState and since scope is null, you'll get a NPE. >> The list of methods that call checkValidState include: >> >> >> splitterator >> >> mismatch >> >> address >> >> handoff >> >> share >> >> registerCleaner >> >> close >> >> >> In short, if you do basically anything but simply read/write via >> VarHandle, including native library usage which uses address(), you're >> going to get a NPE. >> >> >> >> On 1/5/21 4:32 PM, Rados?aw Smogura wrote: >>> Hi all, >>> >>> I hope you have a good day. >>> >>> Here I would like to present some changes to increase performance of >>> ofNativeRestricted - my benchmarks - where I tried to simulate access >>> from code - outpaced the access to Java array (as intended). As it >>> looks like that pull request flow has changed, I have to sign-up OCA >>> (and if this change is fine I would be happy to do this). >>> >>> Below please find benchmark results and link to "pending PR" / branch >>> >>> The results outpaced the Java array access. >>> >>> Benchmark Mode Cnt Score Error >>> Units >>> AccessBenchmark.foreignAddress thrpt 4 86860188.499 ? >>> 13454393.406 ops/s >>> AccessBenchmark.foreignAddressRaw thrpt 4 96150181.668 ? >>> 7025145.700 ops/s >>> AccessBenchmark.target thrpt 4 93673099.539 ? >>> 23272596.145 ops/s``` >>> >>> versus tests on original repo >>> >>> Benchmark Mode Cnt Score Error Units >>> AccessBenchmark.foreignAddress thrpt 4 81907199.092 ? >>> 2663269.652 ops/s >>> AccessBenchmark.foreignAddressRaw thrpt 4 83629168.611 ? >>> 1025857.535 ops/s >>> AccessBenchmark.target thrpt 4 94023553.582 ? >>> 6128411.421 ops/s >>> >>> https://github.com/openjdk/panama-foreign/pull/431 >>> [https://avatars2.githubusercontent.com/u/41768318?s=400&v=4] >>> >>> [WIP] Performance improvement to unchecked segment ofNativeRestricted >>> by rsmogura ? Pull Request #431 ? >>> openjdk/panama-foreign >>> Here's a proposition to tune the access to global scope. This >>> changes, could help to outpace the access to Java arrays using [] >>> operator. The results outpaced the Java array access. Benchmark ... >>> github.com >>> >>> Kind regards, >>> Rado From maurizio.cimadamore at oracle.com Thu Jan 7 22:25:29 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 7 Jan 2021 22:25:29 +0000 Subject: Performance improvement to unchecked segment ofNativeRestricted In-Reply-To: References: Message-ID: <896bfd5c-83de-ba6c-cb72-e5fc051a0e3a@oracle.com> On 07/01/2021 22:09, Rados?aw Smogura wrote: > Hi all, > > Thanks for feedback, and good to hear it's a good direction. > > In fact my first change included a global scope, as Maurizio suggested. I added this null scope, as I have impression I constantly hit this check > private int getIntUnalignedInternal(Scope scope, Object base, long offset, boolean be) { > /* ...*/ > if (scope != null) { > scope.checkValidState(); > } > /* ... */ > } > And I could not understand why hotspot leaves scope != null, and inlines empty method ('else' part looked more like jump to a trap). Now, I tired to use IGV to understand why, rebased one commit back, and it's ok... Could it be that maybe you hit this compiled method from two places - one where scope == null and one where scope != null, but then the scope check is trivial (because of your NullScope). This could happen e.g. if your code is also using other APIs such as ByteBuffer heavily enough to trigger compilation of this method. That said, to overcome these issues, we turned on sharp profiling and inlining on all these ScopedMemoryAccess methods, so pollution shouldn't be a problem, especially cross API. Let us know if you find anything interesting! Thanks Maurizio > > I'll update branch, back-up original one, take closer look again, clean it, and come back later. > > Thanks again for checks, and sorry for not needed bother. > > Kind regards, > Rado > >> I think the fundamental idea is solid, and I agree there's room to >> improve performance here, but as Ty notes, having a NULL scope might be >> problematic. I think it would perhaps be better to have a >> constant/stateless, always open scope, whose checkValidState method does >> nothing? If that scope is stored in a final static constant, I believe >> C2 will not have many problems in eliminating the overhead of the scope >> check. >> >> Maurizio >> >> On 06/01/2021 01:59, Ty Young wrote: >>> You may also need to override checkValidState from >>> AbstractMemorySegmentImpl in EverythingSegment. checkValidState calls >>> the scope's checkValidState and since scope is null, you'll get a NPE. >>> The list of methods that call checkValidState include: >>> >>> >>> splitterator >>> >>> mismatch >>> >>> address >>> >>> handoff >>> >>> share >>> >>> registerCleaner >>> >>> close >>> >>> >>> In short, if you do basically anything but simply read/write via >>> VarHandle, including native library usage which uses address(), you're >>> going to get a NPE. >>> >>> >>> >>> On 1/5/21 4:32 PM, Rados?aw Smogura wrote: >>>> Hi all, >>>> >>>> I hope you have a good day. >>>> >>>> Here I would like to present some changes to increase performance of >>>> ofNativeRestricted - my benchmarks - where I tried to simulate access >>>> from code - outpaced the access to Java array (as intended). As it >>>> looks like that pull request flow has changed, I have to sign-up OCA >>>> (and if this change is fine I would be happy to do this). >>>> >>>> Below please find benchmark results and link to "pending PR" / branch >>>> >>>> The results outpaced the Java array access. >>>> >>>> Benchmark Mode Cnt Score Error >>>> Units >>>> AccessBenchmark.foreignAddress thrpt 4 86860188.499 ? >>>> 13454393.406 ops/s >>>> AccessBenchmark.foreignAddressRaw thrpt 4 96150181.668 ? >>>> 7025145.700 ops/s >>>> AccessBenchmark.target thrpt 4 93673099.539 ? >>>> 23272596.145 ops/s``` >>>> >>>> versus tests on original repo >>>> >>>> Benchmark Mode Cnt Score Error Units >>>> AccessBenchmark.foreignAddress thrpt 4 81907199.092 ? >>>> 2663269.652 ops/s >>>> AccessBenchmark.foreignAddressRaw thrpt 4 83629168.611 ? >>>> 1025857.535 ops/s >>>> AccessBenchmark.target thrpt 4 94023553.582 ? >>>> 6128411.421 ops/s >>>> >>>> https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign/pull/431__;!!GqivPVa7Brio!NjDzQjnuIfj8QDuZCy61K8fphZLKHZwMwp7YYRxaKinV1vUfDCsDzW1h_fk0t0hemqPqIyg$ >>>> [https://urldefense.com/v3/__https://avatars2.githubusercontent.com/u/41768318?s=400&v=4__;!!GqivPVa7Brio!NjDzQjnuIfj8QDuZCy61K8fphZLKHZwMwp7YYRxaKinV1vUfDCsDzW1h_fk0t0hecmGoyf0$ ] >>>> >>>> [WIP] Performance improvement to unchecked segment ofNativeRestricted >>>> by rsmogura ? Pull Request #431 ? >>>> openjdk/panama-foreign >>>> Here's a proposition to tune the access to global scope. This >>>> changes, could help to outpace the access to Java arrays using [] >>>> operator. The results outpaced the Java array access. Benchmark ... >>>> github.com >>>> >>>> Kind regards, >>>> Rado From leerho at gmail.com Thu Jan 7 22:36:30 2021 From: leerho at gmail.com (leerho) Date: Thu, 7 Jan 2021 14:36:30 -0800 Subject: [foreign-memaccess] musing on the memory access API In-Reply-To: References: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> <083001d6e2c9$1aae9040$500bb0c0$@apache.org> <1a830d5e-233c-e54e-6b3c-d679c7297410@oracle.com> <08af01d6e2f4$cdae0600$690a1200$@apache.org> <3b0c2cd5-e49b-24fe-2fe6-fc57c5dd3693@oracle.com> Message-ID: Maurizio, Jorn, Thank you very much for your thoughtful comments and observations! * At the beginning, the doc claims protection from use after free even > in concurrent use - looking at the code that doesn't seem to be the case > though? E.g. it's true that updates to the "valid" bit of the memory > state are atomic, but that doesn't rule out the possibility of multiple > threads seeing a "true" value, then being interleaved with a memory > released, which would ultimately result in access free? I the Java 16 > iteration of the API we address this problem too, but at a much lower > level (we needed some VM/GC black magic to pull this off). You are absolutely right about the multi-threading issue! I wrote this a couple years ago and on my re-read I caught that as well! Our library is strictly single-threaded, which we mention in other places in the documentation. I need to correct that statement. Nonetheless, your solving this problem at a much lower level is precisely what I would hope you would do! And at the same time you offer much stronger multithreading guarantees! * The main differences between the memory access API and your API seem > to be in how dereference is done - you opted for virtual methods, while > we go all in on var handles (and then we provide a bunch of static > accessors on the side). I think the two are similar, although I think > I'm happy where we landed with our API, since using the pre-baked > statics is not any harder than using an instance method, but in exchange > we get a lot of capabilities of out the var handle API (such as atomic > access and adaptation). This decision has repercussions on the API, of > course: the fact that we use MemorySegment as a VarHandle coordinate > means we cannot get too crazy with hierarchies on the MemorySegment > front - in fact, when we tried to do that (at some point we had > MappedMemorySegment <: MemorySegment) we ran into performance issues, as > memory access var handle need exact type information to be fast. Two comments. 1. I chose virtual methods because as of JDK8, that was the only tool in the toolbox. The main advantage of virtual methods is that I can create an API hierarchy (driven by the needs of the application) that effectively collapses down to one class at runtime (as long as it is single inheritance). I'm not yet sure how I would do it differently with the MemoryAccess API. ...we ran into performance issues, as > memory access var handles need exact type information to be fast. This relates to an issue that I'm concerned about, but perhaps because I don't fully understand why "memory access var handles *need* exact type information to be *fast*" or is this just a convention? At the CPU level, it ingests chunks of bytes and then extracts whatever type specified by the assembly instruction whether it be a 32-bit integer (signed or unsigned), short, long, float, double or whatever. I would like the ability to create a MemorySegment allocated as bytes, load it with longs (for speed) and then read it with a MemoryLayout that describes some complex multi-type data structure (because I know what the bytes represent!). In other words, MemorySegment should act like a blob of bytes and reading and writing from it should behave like a *C union* overlayed with a *C struct.* I realize this violates the Java principles of strict typing, but if we really are interested in speed, we need this ability (even if you force us to declare it as *unsafe*). I'm sure you have thought about this, but I'm not sure, yet, if this is a reality in the code. This already appears in Java in a few very limited cases. E.g., I can view a *double* as raw bits, perform operations on the raw bits as a long, and convert it back to a double. We have some math routines that take advantage of this. What is unfortunate is the lack of being able to convert a double (or long, etc) into bytes and back at an intrinsic level, which should be very fast. I looked at your spliterator and it is not clear how I would use it to view the same blob of bytes with two different layouts. I must be missing something :(. * I believe/hope that the main gripes you had with the byte buffer API > (which seem to be endianness related) are gone with the memory access > API. There we made the decision of leaving endianness outside of the > MemorySegment - e.g. endianness is a property of the VarHandle doing the > access, not a property of the segment per se. I believe this decision > paid off (e.g. our segments are completely orthogonal w.r.t. layout > decisions), and avoids a lot of confusion as to "what's the default" etc. I have a number of gripes about the ByteBuffer. 1. The most serious issue is the handling of endianness. First, the default is BigEndian, which today makes no sense as nearly all CPUs are LE. And, some byte compression algorithms only work with a given endianness. Perhaps I could live with this, but if I am interested in performance I would like to match my CPU, so I dutifully set endianness to LE. ByteBuffer bb = ByteBuffer.allocate(16); bb.order(ByteOrder.LITTLE_ENDIAN); Later, suppose I need to do any one of the following common operations: slice(), duplicate() or asReadOnlyBuffer(). * The ByteBuffer silently reverts back to BigEndian!* So the engineer must magically know to always reset the desired endianness after every one of those common operations. And, by the way, this is not documented in the Javadocs anywhere I could find. This is the cause of many difficult to find bugs! In fact we have cases where in large segments of data that have been stored into historical archives, the same segment will have different parts of it encoded with LE and other parts in BE! This is a maintenance nightmare. This bug is easy to find in the ByteBuffer source code. The calls to slice(), duplicate() and asReadOnlyBuffer() return a new ByteBuffer without copying over the current state of Endianness. This is why in our Memory Package implementation we made endianness immutable, once it is chosen, and all equivalent calls to slice(), duplicate(), etc() retain the state of endianness. 2. ByteBuffer array handling is clumsy. It was designed strictly from an IO streaming use-case with no alternative for absolute addressing like the single primitive methods. The BB API is ByteBuffer put([] src, int srcOffset, int length); Our use case has the need to put or get an array at an absolute offset from the beginning of the buffer. For example, > ByteBuffer put(long bufferOffset, [] src, int srcOffset, int length); Attempting to replicate this method with the current BB API requires: - Saving the current setting of position and limit (if used) - Setting the position, computing and perhaps checking the limit - executing the put() above, - restoring position and limit. This is a real PITA, and could be so easily solved with a few easy to add methods. 3. There is no method that allows a high-performance (system level) copy of a region of one ByteBuffer to another ByteBuffer without going through the heap. This is so easy to do with Unsafe, I hope you have the ability to do this with MemorySegments. What we need is something like static void copy(MemorySegment src, long srcOffsetBytes, MemorySegment dst, long dstOffsetBytes, long lengthBytes) Since there are no java arrays involved, the length could be a long. Under the covers, you could easily go parallel with multiple threads if the size is big. 4. The handling of the positional values is also clumsy IMHO where, for example, the Mark is silently invalidated. Agreed this is documented, but remembering the rules where the positionals are suddenly silently changed can be difficult unless you do it all the time. I designed a different positional system (see BaseBuffer) where there is no need to invalidate them. I hope you find this of interest. Cheers, Lee. From stefan.reich.maker.of.eye at googlemail.com Fri Jan 8 00:40:25 2021 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Fri, 8 Jan 2021 01:40:25 +0100 Subject: General comment about Panama In-Reply-To: <6EC54566-3E49-4E21-9FA0-EA65C8F27483@oracle.com> References: <6EC54566-3E49-4E21-9FA0-EA65C8F27483@oracle.com> Message-ID: I just don't really see the point of having to use a different import command later... but doesn't matter On Thu, 7 Jan 2021 at 20:05, Paul Sandoz wrote: > Hi Stefan, > > The package naming is deliberate as per the requirement for incubator > modules. > > While incubating over releases the API is likely to change, as we receive > feedback and gain more experience, in addition to applying new language and > library features to the API (features of Project Valhalla should have a > positive impact). > > Once the API exits incubation name will change to a stable name, and the > API will likely become part of Java SE and merged into java.base. > > Paul. > > > On Jan 6, 2021, at 2:36 PM, Stefan Reich < > stefan.reich.maker.of.eye at googlemail.com> wrote: > > > > It's fantastic! Such a smart approach, it's actually decent to read and > it > > really is able to speed things up. Gives you that tingly feeling of > > controlling the CPU very directly, while still staying on the convenient > > Java level. > > > > Only thing that I find unfortunate is naming the package > > jdk.incubator.vector. So when JDK 16 ships, I'll be forced to change my > > imports? Well, not that big of a deal I guess, just a temporary > > inconvenience. > > > > BTW I actually do make "operating systems" in Java - well, it's an > > integrated persistence framework + module loader + GUI + Java evaluator + > > networking toolkit... so it's like the upper part of an OS if you will. > > Screenshot > > > > Greetings > > > > -- > > Stefan Reich > > BotCompany.de // Java-based operating systems > > -- Stefan Reich BotCompany.de // Java-based operating systems From leerho at gmail.com Fri Jan 8 00:56:00 2021 From: leerho at gmail.com (leerho) Date: Thu, 7 Jan 2021 16:56:00 -0800 Subject: [foreign-memaccess] musing on the memory access API In-Reply-To: References: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> <083001d6e2c9$1aae9040$500bb0c0$@apache.org> <1a830d5e-233c-e54e-6b3c-d679c7297410@oracle.com> <08af01d6e2f4$cdae0600$690a1200$@apache.org> <3b0c2cd5-e49b-24fe-2fe6-fc57c5dd3693@oracle.com> Message-ID: Maurizio, Is the strategy for Panama to completely eliminate the need for ByteBuffer (except for backward integration)? If so, this would be great! This means all of the problems I mention above could be easily solved! Nonetheless, I thought I read (or heard) in one of your tutorials that you felt that the APIs for reading and writing primitives into some backing blob of bytes (MemorySegment) was a solved problem, thus the user would still be using BB for that purpose. Cheers, Lee. On Thu, Jan 7, 2021 at 2:36 PM leerho wrote: > Maurizio, Jorn, > > Thank you very much for your thoughtful comments and observations! > > * At the beginning, the doc claims protection from use after free even >> in concurrent use - looking at the code that doesn't seem to be the case >> though? E.g. it's true that updates to the "valid" bit of the memory >> state are atomic, but that doesn't rule out the possibility of multiple >> threads seeing a "true" value, then being interleaved with a memory >> released, which would ultimately result in access free? I the Java 16 >> iteration of the API we address this problem too, but at a much lower >> level (we needed some VM/GC black magic to pull this off). > > > You are absolutely right about the multi-threading issue! I wrote this a > couple > years ago and on my re-read I caught that as well! Our library is > strictly > single-threaded, which we mention in other places in the documentation. > I need to correct that statement. Nonetheless, your solving this problem > at a much lower level is precisely what I would hope you would do! And > at the same time you offer much stronger multithreading guarantees! > > * The main differences between the memory access API and your API seem >> to be in how dereference is done - you opted for virtual methods, while >> we go all in on var handles (and then we provide a bunch of static >> accessors on the side). I think the two are similar, although I think >> I'm happy where we landed with our API, since using the pre-baked >> statics is not any harder than using an instance method, but in exchange >> we get a lot of capabilities of out the var handle API (such as atomic >> access and adaptation). This decision has repercussions on the API, of >> course: the fact that we use MemorySegment as a VarHandle coordinate >> means we cannot get too crazy with hierarchies on the MemorySegment >> front - in fact, when we tried to do that (at some point we had >> MappedMemorySegment <: MemorySegment) we ran into performance issues, as >> memory access var handle need exact type information to be fast. > > > Two comments. > 1. I chose virtual methods because as of JDK8, that was the only tool in > the toolbox. > The main advantage of virtual methods is that I can create an API > hierarchy > (driven by the needs of the application) that effectively collapses down > to one > class at runtime (as long as it is single inheritance). > I'm not yet sure how I would do it differently with the MemoryAccess API. > > ...we ran into performance issues, as >> memory access var handles need exact type information to be fast. > > > This relates to an issue that I'm concerned about, but perhaps because > I don't fully understand why "memory access var handles *need* exact > type > information to be *fast*" or is this just a convention? At the CPU > level, it > ingests chunks of bytes and then extracts whatever type specified by the > assembly instruction whether it be a 32-bit integer (signed or unsigned), > short, long, float, double or whatever. I would like the ability to > create a > MemorySegment allocated as bytes, load it with longs (for speed) and > then read it with a MemoryLayout that describes some complex multi-type > data structure (because I know what the bytes represent!). In other > words, > MemorySegment should act like a blob of bytes and reading and writing > from it should behave like a *C union* overlayed with a *C struct.* > I realize this violates the Java principles of strict typing, but if we > really > are interested in speed, we need this ability (even if you force us to > declare it as *unsafe*). I'm sure you have thought > about this, but I'm not sure, yet, if this is a reality in the code. > > This already appears in Java in a few very limited cases. E.g., I can > view a > *double* as raw bits, perform operations on the raw bits as a long, and > convert it back to a double. We have some math routines that take > advantage of this. What is unfortunate is the lack of being able to > convert a double (or long, etc) into bytes and back at an intrinsic level, > which should be very fast. > > I looked at your spliterator and it is not clear how I would use it to view > the same blob of bytes with two different layouts. I must be missing > something :(. > > * I believe/hope that the main gripes you had with the byte buffer API >> (which seem to be endianness related) are gone with the memory access >> API. There we made the decision of leaving endianness outside of the >> MemorySegment - e.g. endianness is a property of the VarHandle doing the >> access, not a property of the segment per se. I believe this decision >> paid off (e.g. our segments are completely orthogonal w.r.t. layout >> decisions), and avoids a lot of confusion as to "what's the default" etc. > > > I have a number of gripes about the ByteBuffer. > > 1. The most serious issue is the handling of endianness. > First, the default is BigEndian, which today makes no sense as nearly all > CPUs are LE. And, some byte compression algorithms only work with a given > endianness. Perhaps I could live with this, but if I am interested in > performance > I would like to match my CPU, so I dutifully set endianness to LE. > > ByteBuffer bb = ByteBuffer.allocate(16); > > bb.order(ByteOrder.LITTLE_ENDIAN); > > > Later, suppose I need to do any one of the following common operations: > slice(), duplicate() or asReadOnlyBuffer(). > > * The ByteBuffer silently reverts back to BigEndian!* > > So the engineer must magically know to always reset the desired endianness > after > every one of those common operations. And, by the way, this is not > documented > in the Javadocs anywhere I could find. > > This is the cause of many difficult to find bugs! In fact we have cases > where > in large segments of data that have been stored into historical archives, > the > same segment will have different parts of it encoded with LE and other > parts > in BE! This is a maintenance nightmare. > > This bug is easy to find in the ByteBuffer source code. The calls to > slice(), > duplicate() and asReadOnlyBuffer() return a new ByteBuffer without copying > over the current state of Endianness. > > This is why in our Memory Package implementation we made endianness > immutable, once it is chosen, and all equivalent calls to slice(), > duplicate(), > etc() retain the state of endianness. > > 2. ByteBuffer array handling is clumsy. It was designed strictly from an > IO > streaming use-case with no alternative for absolute addressing like the > single primitive methods. The BB API is > > ByteBuffer put([] src, int srcOffset, int length); > > > Our use case has the need to put or get an array at an absolute offset > from the beginning of the buffer. For example, > > >> ByteBuffer put(long bufferOffset, [] src, int srcOffset, int >> length); > > > Attempting to replicate this method with the current BB API requires: > > - Saving the current setting of position and limit (if used) > - Setting the position, computing and perhaps checking the limit > - executing the put() above, > - restoring position and limit. > > This is a real PITA, and could be so easily solved with a few easy to add > methods. > > 3. There is no method that allows a high-performance (system level) > copy of a region of one ByteBuffer to another ByteBuffer without going > through the heap. This is so easy to do with Unsafe, I hope you have > the ability to do this with MemorySegments. What we need is something like > > static void copy(MemorySegment src, long srcOffsetBytes, > > MemorySegment dst, long dstOffsetBytes, long lengthBytes) > > > Since there are no java arrays involved, the length could be a long. > Under the covers, you could easily go parallel with multiple threads if > the size is big. > > 4. The handling of the positional values is also clumsy IMHO where, for > example, > the Mark is silently invalidated. Agreed this is documented, but > remembering > the rules where the positionals are suddenly silently changed can be > difficult > unless you do it all the time. I designed a different positional system > (see > BaseBuffer) where there is no need to invalidate them. > > I hope you find this of interest. > > Cheers, > > Lee. > > > From njian at openjdk.java.net Fri Jan 8 02:47:26 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Fri, 8 Jan 2021 02:47:26 GMT Subject: [vectorIntrinsics] RFR: 8258072: Add Reinterpret nodes implementation for Arm SVE [v3] In-Reply-To: <4vCnF9BLd8j7qJ3bo8Tale-v7_LY9RMQD1M2IWjwSKI=.4e96b8ee-355e-4551-8bee-e08b891c8674@github.com> References: <0tvI-tWJBswl5w_-X0BMcPcreNiTuLWZDUSuFBrgGsA=.d22886ca-5a14-46f2-b84f-a1693ae565ad@github.com> <4vCnF9BLd8j7qJ3bo8Tale-v7_LY9RMQD1M2IWjwSKI=.4e96b8ee-355e-4551-8bee-e08b891c8674@github.com> Message-ID: On Thu, 7 Jan 2021 07:29:19 GMT, Wang Huang wrote: >> Add reduction nodes support for Arm SVE. Add the backend codegen for node like "VectorReinterpret" . >> In this patch, We implement these instructs: >> * reinterpret (src == dst) >> * reinterpretResize, including, >> 1? reinterpret?Expand? (src < dst) >> 2? reinterpret?Shrink? (src > dst) >> >> At the same time, we fix a bug (JDK-8258989) because it is not merged in panama-vector/vectorIntrinsics. > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix reinterpretNode implementation Thanks for the work! ------------- Marked as reviewed by njian (Committer). PR: https://git.openjdk.java.net/panama-vector/pull/30 From xgong at openjdk.java.net Fri Jan 8 02:47:27 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Fri, 8 Jan 2021 02:47:27 GMT Subject: [vectorIntrinsics] RFR: 8258072: Add Reinterpret nodes implementation for Arm SVE [v3] In-Reply-To: <4vCnF9BLd8j7qJ3bo8Tale-v7_LY9RMQD1M2IWjwSKI=.4e96b8ee-355e-4551-8bee-e08b891c8674@github.com> References: <0tvI-tWJBswl5w_-X0BMcPcreNiTuLWZDUSuFBrgGsA=.d22886ca-5a14-46f2-b84f-a1693ae565ad@github.com> <4vCnF9BLd8j7qJ3bo8Tale-v7_LY9RMQD1M2IWjwSKI=.4e96b8ee-355e-4551-8bee-e08b891c8674@github.com> Message-ID: On Thu, 7 Jan 2021 07:29:19 GMT, Wang Huang wrote: >> Add reduction nodes support for Arm SVE. Add the backend codegen for node like "VectorReinterpret" . >> In this patch, We implement these instructs: >> * reinterpret (src == dst) >> * reinterpretResize, including, >> 1? reinterpret?Expand? (src < dst) >> 2? reinterpret?Shrink? (src > dst) >> >> At the same time, we fix a bug (JDK-8258989) because it is not merged in panama-vector/vectorIntrinsics. > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix reinterpretNode implementation Marked as reviewed by xgong (no project role). ------------- PR: https://git.openjdk.java.net/panama-vector/pull/30 From duke at openjdk.java.net Fri Jan 8 11:06:32 2021 From: duke at openjdk.java.net (duke) Date: Fri, 8 Jan 2021 11:06:32 GMT Subject: git: openjdk/panama-foreign: foreign-memaccess+abi: 87 new changesets Message-ID: <62abd4ef-1827-45bf-b045-d7020242f2df@openjdk.org> Changeset: 497efefa Author: Sergey Bylokhov Date: 2021-01-03 05:08:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/497efefa 8225116: Test OwnedWindowsLeak.java intermittently fails Reviewed-by: pbansal ! test/jdk/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java Changeset: 526c0005 Author: Guoxiong Li Committer: Jonathan Gibbons Date: 2021-01-03 17:32:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/526c0005 8255729: com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacFiler.java Changeset: f351e155 Author: Hao Sun Committer: Ningsheng Jian Date: 2021-01-04 02:21:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f351e155 8258382: Fix optimization-unstable code involving pointer overflow Reviewed-by: kbarrett ! src/hotspot/share/gc/parallel/psPromotionLAB.hpp ! src/hotspot/share/gc/parallel/psPromotionLAB.inline.hpp Changeset: a2a3f4a3 Author: Prasanta Sadhukhan Date: 2021-01-04 04:33:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a2a3f4a3 8258924: javax/swing/JSplitPane/4201995/bug4201995.java fails in GTk L&F Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JSplitPane/4201995/bug4201995.java Changeset: d679caa2 Author: Prasanta Sadhukhan Date: 2021-01-04 06:35:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d679caa2 8196466: javax/swing/JFileChooser/8062561/bug8062561.java fails Reviewed-by: serb ! test/jdk/ProblemList.txt Changeset: 7f04d23b Author: Coleen Phillimore Date: 2021-01-04 16:44:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7f04d23b 8258800: Deprecate -XX:+AlwaysLockClassLoader Reviewed-by: hseigel ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: f80c63b3 Author: Zhengyu Gu Date: 2021-01-04 18:10:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f80c63b3 8258490: Shenandoah: Full GC does not need to remark threads and drain SATB buffers Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp Changeset: 9d160aa1 Author: Claes Redestad Date: 2021-01-04 21:01:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9d160aa1 8257815: Replace global log2 functions with efficient implementations Reviewed-by: kbarrett, stefank ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/z/zGlobals_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/ppc/assembler_ppc.cpp ! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp ! src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/cpu/x86/gc/z/zGlobals_x86.cpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/compiler/compilerDefinitions.cpp ! src/hotspot/share/compiler/tieredThresholdPolicy.cpp ! src/hotspot/share/gc/g1/g1BiasedArray.hpp ! src/hotspot/share/gc/g1/g1FreeIdSet.cpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/shared/partialArrayTaskStepper.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNumberSeq.cpp ! src/hotspot/share/gc/z/zHeuristics.cpp ! src/hotspot/share/opto/divnode.cpp ! src/hotspot/share/opto/mulnode.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! src/hotspot/share/utilities/hashtable.cpp ! src/hotspot/share/utilities/powerOfTwo.hpp ! test/hotspot/gtest/utilities/test_globalDefinitions.cpp ! test/hotspot/gtest/utilities/test_powerOfTwo.cpp Changeset: e6f99260 Author: Phil Race Date: 2021-01-04 21:09:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e6f99260 8257809: JNI warnings from Toolkit JPEG image decoding Reviewed-by: serb ! src/java.desktop/share/native/libjavajpeg/jpegdecoder.c + test/jdk/java/awt/image/GetImageJNICheck/GetImageJNICheck.java + test/jdk/java/awt/image/GetImageJNICheck/GetImageJNICheck.sh = test/jdk/java/awt/image/GetImageJNICheck/duke.jpg Changeset: f0aae81e Author: Xin Liu Committer: Paul Hohensee Date: 2021-01-04 23:58:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f0aae81e 8259020: null-check of g1 write_ref_field_pre_entry is not necessary Reviewed-by: kbarrett, ayang, phh ! src/hotspot/share/gc/g1/g1BarrierSetRuntime.cpp Changeset: 2499ac3d Author: Xue-Lei Andrew Fan Date: 2021-01-05 00:11:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2499ac3d 8259069: Fields could be final Reviewed-by: wetmore ! src/java.base/share/classes/sun/security/ssl/DHClientKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/EphemeralKeyManager.java ! src/java.base/share/classes/sun/security/ssl/HelloCookieManager.java ! src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/java.base/share/classes/sun/security/ssl/SSLCipher.java ! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java ! src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLExtensions.java ! src/java.base/share/classes/sun/security/ssl/SSLKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/java.base/share/classes/sun/security/ssl/SunJSSE.java ! src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java Changeset: 5ea96072 Author: Ioi Lam Date: 2021-01-05 05:57:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ea96072 8258459: Decouple gc_globals.hpp from globals.hpp Reviewed-by: lfoltan, coleenp ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/z/zGlobals_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp ! src/hotspot/cpu/arm/c1_Runtime1_arm.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/c1/shenandoahBarrierSetC1_x86.cpp ! src/hotspot/cpu/x86/gc/z/zGlobals_x86.cpp ! src/hotspot/cpu/x86/gc/z/z_x86_64.ad ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/aot/aotCodeHeap.cpp ! src/hotspot/share/gc/epsilon/epsilonArguments.cpp ! src/hotspot/share/gc/epsilon/epsilonInitLogger.cpp ! src/hotspot/share/gc/epsilon/epsilonThreadLocalData.hpp ! src/hotspot/share/gc/g1/g1AllocRegion.cpp ! src/hotspot/share/gc/g1/g1Allocator.cpp ! src/hotspot/share/gc/g1/g1Analytics.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1EvacStats.cpp ! src/hotspot/share/gc/g1/g1FromCardCache.cpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1InitLogger.cpp ! src/hotspot/share/gc/g1/g1ThreadLocalData.hpp ! src/hotspot/share/gc/parallel/jvmFlagConstraintsParallel.cpp ! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/markSweep.cpp ! src/hotspot/share/gc/shared/ageTable.cpp ! src/hotspot/share/gc/shared/blockOffsetTable.hpp ! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp ! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp ! src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/gcConfiguration.cpp ! src/hotspot/share/gc/shared/gcInitLogger.cpp ! src/hotspot/share/gc/shared/gcOverheadChecker.hpp ! src/hotspot/share/gc/shared/gcPolicyCounters.cpp ! src/hotspot/share/gc/shared/gcStats.cpp ! src/hotspot/share/gc/shared/gcVMOperations.cpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/gc/shared/plab.cpp ! src/hotspot/share/gc/shared/pretouchTask.cpp ! src/hotspot/share/gc/shared/referencePolicy.cpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp ! src/hotspot/share/gc/shared/suspendibleThreadSet.cpp ! src/hotspot/share/gc/shared/taskTerminator.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.inline.hpp + src/hotspot/share/gc/shared/tlab_globals.hpp ! src/hotspot/share/gc/shared/weakProcessor.cpp ! src/hotspot/share/gc/shared/workerManager.hpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp ! src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp ! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp ! src/hotspot/share/gc/shenandoah/shenandoahWorkerPolicy.cpp ! src/hotspot/share/gc/z/zAddressSpaceLimit.cpp ! src/hotspot/share/gc/z/zDirector.cpp ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zHeapIterator.cpp ! src/hotspot/share/gc/z/zHeuristics.cpp ! src/hotspot/share/gc/z/zMarkStackAllocator.cpp ! src/hotspot/share/gc/z/zRelocate.cpp ! src/hotspot/share/gc/z/zRelocationSetSelector.cpp ! src/hotspot/share/gc/z/zRuntimeWorkers.cpp ! src/hotspot/share/gc/z/zStat.cpp ! src/hotspot/share/gc/z/zThreadLocalAllocBuffer.cpp ! src/hotspot/share/gc/z/zUncommitter.cpp ! src/hotspot/share/gc/z/zUnmapper.cpp ! src/hotspot/share/gc/z/zValue.inline.hpp ! src/hotspot/share/gc/z/zVerify.cpp ! src/hotspot/share/gc/z/zWorkers.inline.hpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/jfr/leakprofiler/chains/pathToGcRootsOperation.cpp ! src/hotspot/share/jfr/support/jfrObjectAllocationSample.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp ! src/hotspot/share/memory/dynamicArchive.cpp ! src/hotspot/share/memory/heapShared.hpp ! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/oops/oop.cpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/oop.inline.hpp ! src/hotspot/share/opto/arraycopynode.cpp ! src/hotspot/share/opto/lcm.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/macroArrayCopy.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/flags/allFlags.hpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/thread.inline.hpp ! src/hotspot/share/runtime/threadSMR.inline.hpp ! test/hotspot/gtest/runtime/test_globals.cpp Changeset: dd8996c5 Author: Hao Sun Committer: Ningsheng Jian Date: 2021-01-05 07:31:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dd8996c5 8258946: Fix optimization-unstable code involving signed integer overflow Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/parse2.cpp Changeset: 17d1645e Author: Hao Sun Committer: Ningsheng Jian Date: 2021-01-05 08:29:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/17d1645e 8258751: Improve ExceptionHandlerTable dump Reviewed-by: thartmann, chagedorn, njian ! src/hotspot/share/code/exceptionHandlerTable.cpp ! src/hotspot/share/code/exceptionHandlerTable.hpp ! src/hotspot/share/code/nmethod.cpp Changeset: 3817c32f Author: Lehua Ding Committer: Jie Fu Date: 2021-01-05 08:34:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3817c32f 8258534: Epsilon: clean up unused includes Reviewed-by: shade, jiefu ! src/hotspot/share/gc/epsilon/epsilonArguments.cpp ! src/hotspot/share/gc/epsilon/epsilonBarrierSet.cpp Changeset: db6f3930 Author: Aleksey Shipilev Date: 2021-01-05 08:37:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/db6f3930 8251944: Add Shenandoah test config to compiler/gcbarriers/UnsafeIntrinsicsTest.java Reviewed-by: rkennke, adityam ! test/hotspot/jtreg/compiler/gcbarriers/UnsafeIntrinsicsTest.java Changeset: 9f151649 Author: Christian Hagedorn Date: 2021-01-05 09:54:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f151649 8259049: Uninitialized variable after JDK-8257513 Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/constantTable.cpp Changeset: a6c08813 Author: Sergey Bylokhov Date: 2021-01-05 12:47:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a6c08813 8256321: Some "inactive" color profiles use the wrong profile class Reviewed-by: prr ! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java + test/jdk/java/awt/color/CheckDefaultProperties.java Changeset: fc3b45c0 Author: Alexander Zuev Date: 2021-01-05 14:46:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc3b45c0 8258643: javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button" Reviewed-by: psadhukhan ! test/jdk/javax/swing/JComponent/7154030/bug7154030.java Changeset: f4122d6a Author: Harold Seigel Date: 2021-01-05 16:14:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f4122d6a 8258896: Remove the JVM ForceFloatExceptions option Reviewed-by: lfoltan, iklam, coleenp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: 82bdbfd7 Author: Hao Sun Committer: Aleksey Shipilev Date: 2021-01-05 16:28:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/82bdbfd7 8258857: Zero: non-PCH release build fails after JDK-8258074 Reviewed-by: jiefu, shade, iklam ! src/hotspot/share/compiler/compiler_globals.hpp Changeset: d5aa49d1 Author: Claes Redestad Date: 2021-01-05 16:41:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d5aa49d1 8259236: C2 compilation fails with assert(is_power_of_2(value)) failed: value must be a power of 2: 8000000000000000 Reviewed-by: thartmann ! src/hotspot/cpu/x86/x86_64.ad Changeset: 85bac8c4 Author: Peter Levart Date: 2021-01-05 17:41:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/85bac8c4 8259021: SharedSecrets should avoid double racy reads from non-volatile fields Reviewed-by: shade, redestad, rriggs, mchung, rrich, alanb ! src/java.base/share/classes/jdk/internal/access/SharedSecrets.java Changeset: 7ddc2b56 Author: Xue-Lei Andrew Fan Date: 2021-01-05 18:29:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7ddc2b56 8258852: Arrays.asList() for single item could be replaced with List.of() Reviewed-by: mullan ! src/java.base/share/classes/sun/security/ssl/ClientHello.java ! src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java ! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java Changeset: 1b60acd8 Author: Zhengyu Gu Date: 2021-01-05 18:33:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1b60acd8 8259252: Shenandoah: Shenandoah build failed on AArch64 after JDK-8258459 Reviewed-by: rkennke, shade ! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp Changeset: 4d3d5991 Author: Xue-Lei Andrew Fan Date: 2021-01-05 19:32:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d3d5991 8259223: Simplify boolean expression in the SunJSSE provider Reviewed-by: mullan ! src/java.base/share/classes/sun/security/ssl/CipherSuite.java ! src/java.base/share/classes/sun/security/ssl/EphemeralKeyManager.java ! src/java.base/share/classes/sun/security/ssl/Finished.java ! src/java.base/share/classes/sun/security/ssl/HandshakeContext.java ! src/java.base/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java ! src/java.base/share/classes/sun/security/ssl/ProtocolVersion.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/java.base/share/classes/sun/security/ssl/SignatureScheme.java ! src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/java.base/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java Changeset: cf9908b4 Author: Harold Seigel Date: 2021-01-05 21:15:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cf9908b4 8258937: Remove JVM IgnoreRewrites flag Reviewed-by: coleenp ! src/hotspot/share/oops/generateOopMap.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: 7d769663 Author: Guoxiong Li Committer: Vicente Romero Date: 2021-01-05 22:21:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7d769663 8255757: Javac emits duplicate pool entries on array::clone Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java + test/langtools/tools/javac/classfiles/T8255757/T8255757.java Changeset: 8b454977 Author: Yasumasa Suenaga Date: 2021-01-05 22:36:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8b454977 8259037: livenmethods cannot find hsdis library Reviewed-by: cjplummer, sspitsyn ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/asm/Disassembler.java ! src/jdk.hotspot.agent/share/native/libsaproc/sadis.c Changeset: 52d3feec Author: Xiaohong Gong Committer: Ningsheng Jian Date: 2021-01-06 01:40:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/52d3feec 8258813: [TESTBUG] Fix incorrect Vector API test output message Reviewed-by: psandoz, njian ! test/jdk/jdk/incubator/vector/AbstractVectorTest.java ! test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte128VectorTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Double128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double128VectorTests.java ! test/jdk/jdk/incubator/vector/Double256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double256VectorTests.java ! test/jdk/jdk/incubator/vector/Double512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double512VectorTests.java ! test/jdk/jdk/incubator/vector/Double64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double64VectorTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Float128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float128VectorTests.java ! test/jdk/jdk/incubator/vector/Float256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float256VectorTests.java ! test/jdk/jdk/incubator/vector/Float512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float512VectorTests.java ! test/jdk/jdk/incubator/vector/Float64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float64VectorTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Int128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int128VectorTests.java ! test/jdk/jdk/incubator/vector/Int256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int256VectorTests.java ! test/jdk/jdk/incubator/vector/Int512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int512VectorTests.java ! test/jdk/jdk/incubator/vector/Int64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int64VectorTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Long128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long128VectorTests.java ! test/jdk/jdk/incubator/vector/Long256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long256VectorTests.java ! test/jdk/jdk/incubator/vector/Long512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long512VectorTests.java ! test/jdk/jdk/incubator/vector/Long64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long64VectorTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Short128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short128VectorTests.java ! test/jdk/jdk/incubator/vector/Short256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short256VectorTests.java ! test/jdk/jdk/incubator/vector/Short512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short512VectorTests.java ! test/jdk/jdk/incubator/vector/Short64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short64VectorTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java ! test/jdk/jdk/incubator/vector/VectorReshapeTests.java ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-Long-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-Masked-Long-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-op-math.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-op-math.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Blend-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-BoolReduction-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Broadcast.template ! test/jdk/jdk/incubator/vector/templates/Unit-Gather-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Gather-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Get-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Miscellaneous.template ! test/jdk/jdk/incubator/vector/templates/Unit-Rearrange.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-Max-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-Min-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Max-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Min-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Scatter-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Scatter-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Shift-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Shift-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Single-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Slice-Masked-bop.template ! test/jdk/jdk/incubator/vector/templates/Unit-Slice-bop.template ! test/jdk/jdk/incubator/vector/templates/Unit-Slice-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Broadcast-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Broadcast-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Double-Broadcast-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Double-Broadcast-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unary-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unary-op-math.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unary-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unslice-Masked-bop.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unslice-bop.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unslice-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-With-Op.template ! test/jdk/jdk/incubator/vector/templates/Unit-header.template ! test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template Changeset: 32538b5b Author: Prasanta Sadhukhan Date: 2021-01-06 06:45:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/32538b5b 8193942: Regression automated test '/open/test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java' fails Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java Changeset: e3b9da14 Author: Xin Liu Committer: Aleksey Shipilev Date: 2021-01-06 09:51:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3b9da14 8259287: AbstractCompiler marks const in wrong position for is_c1/is_c2/is_jvmci Reviewed-by: thartmann, chagedorn, shade ! src/hotspot/share/compiler/abstractCompiler.hpp Changeset: 8a05d605 Author: Sergey Bylokhov Date: 2021-01-06 10:07:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8a05d605 8259042: Inconsistent use of general primitives loops Reviewed-by: prr ! src/java.desktop/share/classes/sun/java2d/loops/Blit.java ! src/java.desktop/share/classes/sun/java2d/loops/BlitBg.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphList.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListAA.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListLCD.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawLine.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawParallelogram.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawPath.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawPolygons.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawRect.java ! src/java.desktop/share/classes/sun/java2d/loops/FillParallelogram.java ! src/java.desktop/share/classes/sun/java2d/loops/FillPath.java ! src/java.desktop/share/classes/sun/java2d/loops/FillRect.java ! src/java.desktop/share/classes/sun/java2d/loops/FillSpans.java ! src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitive.java ! src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitiveMgr.java ! src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitiveProxy.java ! src/java.desktop/share/classes/sun/java2d/loops/MaskBlit.java ! src/java.desktop/share/classes/sun/java2d/loops/MaskFill.java ! src/java.desktop/share/classes/sun/java2d/loops/ScaledBlit.java ! src/java.desktop/share/classes/sun/java2d/loops/TransformBlit.java ! src/java.desktop/share/classes/sun/java2d/loops/TransformHelper.java Changeset: 7e01bc96 Author: Mat Carter Committer: Alan Bateman Date: 2021-01-06 10:39:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e01bc96 8255264: Support for identifying the full range of IPv4 localhost addresses on Windows Reviewed-by: alanb ! src/java.base/windows/native/libnet/net_util_md.h Changeset: c0540ffd Author: Daniel D. Daugherty Date: 2021-01-06 14:34:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c0540ffd 8231627: ThreadsListHandleInErrorHandlingTest.java fails in printing all threads Reviewed-by: eosterlund, coleenp, pchilanomate, sspitsyn ! src/hotspot/share/runtime/threadSMR.cpp ! test/hotspot/jtreg/runtime/ErrorHandling/NestedThreadsListHandleInErrorHandlingTest.java ! test/hotspot/jtreg/runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java Changeset: f6cb8c55 Author: Harold Seigel Date: 2021-01-06 15:11:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f6cb8c55 8258908: Remove JVM option CleanChunkPoolAsync Reviewed-by: coleenp ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/memory/arena.cpp ! src/hotspot/share/memory/arena.hpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/thread.cpp Changeset: 722f2361 Author: Lehua Ding Committer: Aleksey Shipilev Date: 2021-01-06 15:36:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/722f2361 8259231: Epsilon: improve performance under contention during virtual space expansion Reviewed-by: shade ! src/hotspot/share/gc/epsilon/epsilonHeap.cpp Changeset: 3be6e069 Author: Rajan Halade Date: 2021-01-06 16:20:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3be6e069 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days Reviewed-by: mullan ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: d20d2fa9 Author: Joe Darcy Date: 2021-01-06 16:26:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d20d2fa9 8258143: Update --release 16 symbol information for JDK 16 build 30 or later Reviewed-by: iris, erikj ! make/data/symbols/java.desktop-G.sym.txt Changeset: df721f0c Author: Xue-Lei Andrew Fan Date: 2021-01-06 16:57:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/df721f0c 8259291: Cleanup unnecessary local variables Reviewed-by: mullan ! src/java.base/share/classes/sun/security/ssl/Finished.java ! src/java.base/share/classes/sun/security/ssl/OutputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLExtension.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketOutputRecord.java ! src/java.base/share/classes/sun/security/ssl/ServerNameExtension.java ! src/java.base/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java Changeset: 940b0530 Author: Phil Race Date: 2021-01-06 17:34:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/940b0530 8259232: Bad JNI lookup during printing Reviewed-by: psadhukhan ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m ! test/jdk/java/awt/print/bug8023392/bug8023392.java Changeset: 80544e4d Author: Joe Darcy Date: 2021-01-06 18:05:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/80544e4d 8250564: Remove terminally deprecated constructor in GSSUtil 8250565: Remove terminally deprecated constructor in java.net.URLDecoder Reviewed-by: bpb, smarks, alanb, mullan ! src/java.base/share/classes/java/net/URLDecoder.java ! src/jdk.security.jgss/share/classes/com/sun/security/jgss/GSSUtil.java ! test/jdk/java/net/URLDecoder/B6463990.java Changeset: 28e1f4d9 Author: Yoshiki Sato Committer: Jonathan Gibbons Date: 2021-01-06 22:48:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/28e1f4d9 8247957: remove doclint support for HTML 4 8257204: Remove usage of -Xhtmlversion option from javac 8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option 8258460: Remove --doclint-format option from javac 8256312: Valid anchor 'id' value not allowed Reviewed-by: jjg, ihse ! make/common/JavaCompilation.gmk ! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlVersion.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties ! test/langtools/jdk/javadoc/doclet/testHtmlTableStyles/TestHtmlTableStyles.java ! test/langtools/tools/doclint/AccessibilityTest.java ! test/langtools/tools/doclint/AccessibilityTest.out - test/langtools/tools/doclint/AccessibilityTest5.java - test/langtools/tools/doclint/AccessibilityTest5.out ! test/langtools/tools/doclint/AnchorTest.java ! test/langtools/tools/doclint/AnchorTest.out ! test/langtools/tools/doclint/AnchorTest2.java ! test/langtools/tools/doclint/AnchorTest2.out ! test/langtools/tools/doclint/AnchorTest2a.java ! test/langtools/tools/doclint/EndTagsTest.java ! test/langtools/tools/doclint/HtmlAttrsTest.java ! test/langtools/tools/doclint/HtmlAttrsTest.out ! test/langtools/tools/doclint/HtmlTagsTest.java ! test/langtools/tools/doclint/HtmlTagsTest.out - test/langtools/tools/doclint/HtmlVersionTest.java ! test/langtools/tools/doclint/anchorTests/p/Test.java ! test/langtools/tools/doclint/anchorTests/p/Test.out ! test/langtools/tools/doclint/anchorTests/p/package-info.java ! test/langtools/tools/doclint/anchorTests/p/package-info.javac.out ! test/langtools/tools/doclint/anchorTests/p/package-info.out ! test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.java + test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.out - test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTestHtml4.out - test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTestHtml5.out + test/langtools/tools/doclint/html/InlineTagTest.out ! test/langtools/tools/doclint/html/InlineTagsTest.java ! test/langtools/tools/doclint/html/OtherTagsTest.java ! test/langtools/tools/doclint/html/OtherTagsTest.out + test/langtools/tools/doclint/html/TableTagTest.out ! test/langtools/tools/doclint/html/TableTagsTest.java ! test/langtools/tools/doclint/html/TagNotAllowed.java ! test/langtools/tools/doclint/html/TagNotAllowed.out ! test/langtools/tools/doclint/html/TextNotAllowed.java ! test/langtools/tools/doclint/html/TextNotAllowed.out ! test/langtools/tools/doclint/tidy/AnchorAlreadyDefined.java ! test/langtools/tools/doclint/tidy/AnchorAlreadyDefined.out ! test/langtools/tools/doclint/tidy/BadEnd.java ! test/langtools/tools/doclint/tidy/BadEnd.out ! test/langtools/tools/doclint/tidy/InvalidName.java ! test/langtools/tools/doclint/tidy/InvalidName.out ! test/langtools/tools/doclint/tidy/TextNotAllowed.java ! test/langtools/tools/doclint/tidy/TextNotAllowed.out ! test/langtools/tools/doclint/tidy/TrimmingEmptyTag.java ! test/langtools/tools/doclint/tidy/TrimmingEmptyTag.out ! test/langtools/tools/javac/doclint/DocLintFormatTest.java Changeset: 67c22114 Author: Yasumasa Suenaga Date: 2021-01-06 23:59:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/67c22114 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale Reviewed-by: erikj, cjplummer, iklam ! make/modules/jdk.hotspot.agent/Lib.gmk ! src/jdk.hotspot.agent/share/native/libsaproc/sadis.c Changeset: 227f99d3 Author: Prasanta Sadhukhan Date: 2021-01-07 03:57:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/227f99d3 8233555: [TESTBUG] JRadioButton tests failing on MacoS Reviewed-by: serb ! test/jdk/ProblemList.txt Changeset: 81c06242 Author: Carter Kozak Committer: Erik Gahlin Date: 2021-01-07 06:11:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81c06242 8259354: Fix race condition in AbstractEventStream.nextThreadName Reviewed-by: egahlin ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java Changeset: 0e6de4eb Author: Tobias Hartmann Date: 2021-01-07 12:15:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0e6de4eb 8259339: AllocateUninitializedArray C2 intrinsic fails with void.class input Reviewed-by: kvn, chagedorn ! src/hotspot/share/opto/library_call.cpp ! test/hotspot/jtreg/compiler/intrinsics/unsafe/AllocateUninitializedArray.java Changeset: 1c33847b Author: Coleen Phillimore Date: 2021-01-07 12:35:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1c33847b 8259067: bootclasspath append takes out object lock Reviewed-by: lfoltan, sspitsyn, iklam, dholmes ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/classfile/classLoader.inline.hpp ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: 3f9f86f0 Author: Matthias Baesken Date: 2021-01-07 12:39:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3f9f86f0 8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006 Reviewed-by: clanger, mdoerr ! make/modules/java.desktop/lib/Awt2dLibraries.gmk Changeset: f91f92dc Author: Harold Seigel Date: 2021-01-07 13:18:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f91f92dc 8259317: Remove JVM option BreakAtWarning Reviewed-by: lfoltan, coleenp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/utilities/debug.cpp Changeset: 8530ef0e Author: Coleen Phillimore Date: 2021-01-07 17:13:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8530ef0e 8259375: JvmtiExport::jni_Get/SetField_probe calls do not need ResetNoHandleMark Reviewed-by: lfoltan, dcubed ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvmtiExport.cpp Changeset: 2e99e28f Author: Sergey Bylokhov Date: 2021-01-07 17:49:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2e99e28f 8213126: java/awt/Window/MainKeyWindow/TestMainKeyWindow.java time-out on mac10.13 Reviewed-by: psadhukhan ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java Changeset: 4ce83f2a Author: Rajan Halade Date: 2021-01-07 18:47:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ce83f2a 8039278: console.sh failed Automatically with exit code 1 Reviewed-by: xuelei, weijun ! test/jdk/TEST.groups - test/jdk/sun/security/tools/keytool/console.sh Changeset: d8ad6301 Author: Roberto Casta?eda Lozano Committer: Vladimir Kozlov Date: 2021-01-07 18:57:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d8ad6301 8258772: Some runtime/cds tests fail with +LogCompilation or +StressX Emit warning about TraceDependencies results in ClassHierarchyWalker::count_find_witness_calls() only if TraceDependencies is actually enabled. Use standard warning() function instead of ad hoc printing. Remove warning about using Stress(LCM|GCM|IGVN) without LogCompilation in Compile::Compile(), and add the information to the description of the StressSeed option instead. These changes prevent false test failures when using LogCompilation or Stress(LCM|GCM|IGVN). Reviewed-by: chagedorn, kvn, thartmann ! src/hotspot/share/code/dependencies.cpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/compile.cpp Changeset: bc565414 Author: Roberto Casta?eda Lozano Committer: Vladimir Kozlov Date: 2021-01-07 20:43:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bc565414 8256535: C2: randomize CCP processing order for stress testing Add 'StressCCP' option to randomize the selection of the node to be examined in each CCP iteration. Reviewed-by: chagedorn, kvn, thartmann ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/phaseX.cpp - test/hotspot/jtreg/compiler/arguments/TestStressIGVNOptions.java + test/hotspot/jtreg/compiler/arguments/TestStressOptions.java ! test/hotspot/jtreg/compiler/debug/TestGenerateStressSeed.java - test/hotspot/jtreg/compiler/debug/TestStressIGVN.java + test/hotspot/jtreg/compiler/debug/TestStressIGVNAndCCP.java Changeset: 2659bc44 Author: Brian Burkhalter Date: 2021-01-07 20:57:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2659bc44 8259274: Increase timeout duration in sun/nio/ch/TestMaxCachedBufferSize.java Reviewed-by: lancea ! test/jdk/sun/nio/ch/TestMaxCachedBufferSize.java Changeset: 73f54153 Author: Chris Hegarty Date: 2021-01-02 19:29:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/73f54153 8258955: (bf) slice(int, int) on view buffers fails to adjust index according to primitive size Reviewed-by: alanb ! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template ! test/jdk/java/nio/Buffer/ByteBufferViews.java Changeset: 216c2ec0 Author: Jie Fu Date: 2021-01-04 23:41:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/216c2ec0 8258703: Incorrect 512-bit vector registers restore on x86_32 Reviewed-by: kvn, sviswanathan ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp Changeset: 4ffbe841 Author: Jan Lahoda Date: 2021-01-05 11:40:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ffbe841 8256266: Binding variables don't correctly support declaration annotations and the final modifier Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/langtools/tools/javac/patterns/Annotations.java ! test/langtools/tools/javac/patterns/BindingsTest1.java ! test/langtools/tools/javac/patterns/BindingsTest2.java ! test/langtools/tools/javac/patterns/BindingsTest2.out + test/langtools/tools/javac/patterns/NoModifiersOnBinding.java + test/langtools/tools/javac/patterns/NoModifiersOnBinding.out Changeset: 6775113c Author: Roland Westrelin Date: 2021-01-05 13:06:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6775113c 8258393: Shenandoah: "graph should be schedulable" assert failure Reviewed-by: rkennke, thartmann ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/opto/loopnode.cpp + test/hotspot/jtreg/gc/shenandoah/compiler/TestBadRawMemoryAfterCall.java Changeset: bbc2e951 Author: Erik Gahlin Date: 2021-01-05 13:39:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bbc2e951 8257906: JFR: RecordingStream leaks memory Reviewed-by: mgronlun Backport-of: 3c6648501589bf36945340cb1e82c833ebd7485d ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ChunkParser.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventDirectoryStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventFileStream.java Changeset: b7940aa1 Author: Maurizio Cimadamore Date: 2021-01-05 16:15:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b7940aa1 8259027: NullPointerException in makeMappedSegment due to NULL Unmapper when length of segment is 0 Reviewed-by: chegar, uschindler ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MappedMemorySegmentImpl.java ! test/jdk/java/foreign/TestByteBuffer.java Changeset: 50bf4330 Author: Sandhya Viswanathan Date: 2021-01-05 17:42:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/50bf4330 8259213: Vector conversion with part > 0 is not getting intrinsic implementation Reviewed-by: psandoz ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractShuffle.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java Changeset: d5293067 Author: Vicente Romero Date: 2021-01-05 21:35:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d5293067 8213032: program fails with LambdaConversionException at execution time Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/langtools/tools/javac/lambda/methodReferenceExecution/MethodReferenceIntersection4.java Changeset: 554e60c4 Author: Wang Huang Committer: Fei Yang Date: 2021-01-06 01:49:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/554e60c4 8258989: JVM is failed to inline in jdk.internal.vm.vector.VectorSupport::convert Co-authored-by: He Xuejin Reviewed-by: vlivanov, thartmann ! src/hotspot/share/opto/vectorIntrinsics.cpp Changeset: 80110dac Author: Prasanta Sadhukhan Date: 2021-01-06 06:36:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/80110dac 8259007: This test printed a blank page Reviewed-by: prr, serb ! src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java ! src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp - test/jdk/java/awt/print/PathPrecisionScaleFactor/PathPrecisionScaleFactorTest.java Changeset: e66187d8 Author: Maurizio Cimadamore Date: 2021-01-06 12:18:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e66187d8 8259032: MappedMemorySegmentImpl#makeMappedSegment() ignores Unmapper#pagePosition Co-authored-by: Uwe Schindler Reviewed-by: alanb ! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java ! test/jdk/java/foreign/TestByteBuffer.java Changeset: ad456787 Author: Aleksey Shipilev Date: 2021-01-06 13:27:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ad456787 8258558: Revert changes for JDK-8252505 and related issues Reviewed-by: kvn ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/compiler/compilerOracle.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/memnode.hpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/regmask.cpp ! src/hotspot/share/opto/regmask.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/TEST.groups - test/hotspot/jtreg/compiler/blackhole/BlackholeDiagnosticUnlockTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeInstanceReturnTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeInstanceTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeNonVoidWarningTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeNullCheckTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeStaticReturnTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeStaticTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeTarget.java Changeset: d25a1bed Author: Rafael Winterhalter Committer: Joel Borggr?n-Franck Date: 2021-01-06 15:46:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d25a1bed 8259224: (ann) getAnnotatedReceiverType should not parameterize owner(s) of statically nested classes Reviewed-by: jfranck ! src/java.base/share/classes/java/lang/reflect/Executable.java + test/jdk/java/lang/annotation/typeAnnotations/TestReceiverTypeOwnerType.java Changeset: 4a5786b5 Author: Naoto Sato Date: 2021-01-06 16:30:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4a5786b5 8259075: Update the copyright notice in the files generated by CLDR Converter tool Reviewed-by: joehw ! make/jdk/src/classes/build/tools/cldrconverter/CopyrightHeaders.java Changeset: f1bc4e05 Author: Rajan Halade Date: 2021-01-06 16:39:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f1bc4e05 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days Backport-of: 3be6e06958c4304cafee707a29d06d6b2cc5b76b ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: eef43be7 Author: Jonathan Gibbons Date: 2021-01-06 18:52:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eef43be7 8251200: False positive messages about missing comments for serialization Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/SerializedFormBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java + test/langtools/jdk/javadoc/doclet/testSerialMissing/TestSerialMissing.java Changeset: 4f914e21 Author: Jonathan Gibbons Date: 2021-01-06 19:26:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4f914e21 8249633: doclint reports missing javadoc for JavaFX property methods that have a property description Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MemberSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java Changeset: 555641ed Author: Jesper Wilhelmsson Date: 2021-01-07 21:17:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/555641ed Merge ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/hotspot/jtreg/TEST.groups ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/hotspot/jtreg/TEST.groups Changeset: b996cccf Author: Coleen Phillimore Date: 2021-01-07 23:04:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b996cccf 8259373: c1 and jvmci runtime code use ResetNoHandleMark incorrectly Reviewed-by: kvn ! src/hotspot/share/c1/c1_Runtime1.cpp ! src/hotspot/share/code/compiledMethod.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp Changeset: 4a478b8a Author: Erik Gahlin Date: 2021-01-07 12:21:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4a478b8a 8250903: jdk/jfr/javaagent/TestLoadedAgent.java fails with Mismatch in TestEvent count Reviewed-by: mgronlun ! test/jdk/jdk/jfr/javaagent/EventEmitterAgent.java Changeset: 484e23b9 Author: Erik Joelsson Date: 2021-01-07 14:57:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/484e23b9 8258657: Doc build is broken by use of new language features Reviewed-by: tbell, iris ! make/Docs.gmk ! make/autoconf/boot-jdk.m4 ! make/autoconf/configure.ac ! make/autoconf/spec.gmk.in ! make/conf/jib-profiles.js Changeset: c1fb5216 Author: Christian Hagedorn Date: 2021-01-07 15:02:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c1fb5216 8259227: C2 crashes with SIGFPE due to a division that floats above its zero check Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/phaseX.hpp + test/hotspot/jtreg/compiler/loopopts/TestDivZeroDominatedBy.java ! test/hotspot/jtreg/compiler/loopopts/TestDivZeroWithSplitIf.java Changeset: acdd90b6 Author: Vicente Romero Date: 2021-01-07 16:38:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/acdd90b6 8258972: unexpected compilation error with generic sealed interface Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java Changeset: 1973fbee Author: Rajan Halade Date: 2021-01-07 19:21:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1973fbee 8039278: console.sh failed Automatically with exit code 1 Backport-of: 4ce83f2a3a6c5fe11c298bed557c341e286e068a ! test/jdk/TEST.groups - test/jdk/sun/security/tools/keytool/console.sh Changeset: 677802d2 Author: Christoph Langer Date: 2021-01-07 22:51:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/677802d2 8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006 Backport-of: 3f9f86f0d3f918b9955ba6ba73c9c58ae8fcf7cb ! make/modules/java.desktop/lib/Awt2dLibraries.gmk Changeset: 56a354eb Author: Jesper Wilhelmsson Date: 2021-01-07 23:51:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/56a354eb Merge ! make/Docs.gmk ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/phaseX.cpp ! make/Docs.gmk ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/phaseX.cpp Changeset: 712014c5 Author: David Holmes Date: 2021-01-08 04:11:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/712014c5 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 Reviewed-by: dcubed, hseigel ! src/hotspot/share/prims/jniCheck.cpp + test/hotspot/jtreg/runtime/jni/checked/TestCheckedReleaseArrayElements.java + test/hotspot/jtreg/runtime/jni/checked/TestCheckedReleaseCriticalArray.java + test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseArrayElements.c + test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c Changeset: fc1d2a1e Author: Claes Redestad Date: 2021-01-08 09:20:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc1d2a1e 8259065: Optimize MessageDigest.getInstance Reviewed-by: valeriep ! src/java.base/share/classes/java/security/MessageDigest.java ! src/java.base/share/classes/java/security/Provider.java ! src/java.base/share/classes/sun/security/jca/ProviderConfig.java + test/micro/org/openjdk/bench/java/security/GetMessageDigest.java Changeset: b549cbd3 Author: Thomas Schatzl Date: 2021-01-08 10:52:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b549cbd3 8258481: gc.g1.plab.TestPLABPromotion fails on Linux x86 Reviewed-by: sjohanss, kbarrett ! test/hotspot/jtreg/gc/g1/plab/TestPLABPromotion.java Changeset: 04b8ca02 Author: duke Date: 2021-01-08 11:00:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/04b8ca02 Automatic merge of jdk:master into master Changeset: 017bf202 Author: duke Date: 2021-01-08 11:00:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/017bf202 Automatic merge of master into foreign-memaccess+abi From duke at openjdk.java.net Fri Jan 8 11:11:40 2021 From: duke at openjdk.java.net (duke) Date: Fri, 8 Jan 2021 11:11:40 GMT Subject: git: openjdk/panama-foreign: master: 86 new changesets Message-ID: Changeset: 497efefa Author: Sergey Bylokhov Date: 2021-01-03 05:08:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/497efefa 8225116: Test OwnedWindowsLeak.java intermittently fails Reviewed-by: pbansal ! test/jdk/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java Changeset: 526c0005 Author: Guoxiong Li Committer: Jonathan Gibbons Date: 2021-01-03 17:32:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/526c0005 8255729: com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacFiler.java Changeset: f351e155 Author: Hao Sun Committer: Ningsheng Jian Date: 2021-01-04 02:21:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f351e155 8258382: Fix optimization-unstable code involving pointer overflow Reviewed-by: kbarrett ! src/hotspot/share/gc/parallel/psPromotionLAB.hpp ! src/hotspot/share/gc/parallel/psPromotionLAB.inline.hpp Changeset: a2a3f4a3 Author: Prasanta Sadhukhan Date: 2021-01-04 04:33:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a2a3f4a3 8258924: javax/swing/JSplitPane/4201995/bug4201995.java fails in GTk L&F Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JSplitPane/4201995/bug4201995.java Changeset: d679caa2 Author: Prasanta Sadhukhan Date: 2021-01-04 06:35:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d679caa2 8196466: javax/swing/JFileChooser/8062561/bug8062561.java fails Reviewed-by: serb ! test/jdk/ProblemList.txt Changeset: 7f04d23b Author: Coleen Phillimore Date: 2021-01-04 16:44:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7f04d23b 8258800: Deprecate -XX:+AlwaysLockClassLoader Reviewed-by: hseigel ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: f80c63b3 Author: Zhengyu Gu Date: 2021-01-04 18:10:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f80c63b3 8258490: Shenandoah: Full GC does not need to remark threads and drain SATB buffers Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp Changeset: 9d160aa1 Author: Claes Redestad Date: 2021-01-04 21:01:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9d160aa1 8257815: Replace global log2 functions with efficient implementations Reviewed-by: kbarrett, stefank ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/z/zGlobals_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/ppc/assembler_ppc.cpp ! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp ! src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/cpu/x86/gc/z/zGlobals_x86.cpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/compiler/compilerDefinitions.cpp ! src/hotspot/share/compiler/tieredThresholdPolicy.cpp ! src/hotspot/share/gc/g1/g1BiasedArray.hpp ! src/hotspot/share/gc/g1/g1FreeIdSet.cpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/shared/partialArrayTaskStepper.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNumberSeq.cpp ! src/hotspot/share/gc/z/zHeuristics.cpp ! src/hotspot/share/opto/divnode.cpp ! src/hotspot/share/opto/mulnode.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! src/hotspot/share/utilities/hashtable.cpp ! src/hotspot/share/utilities/powerOfTwo.hpp ! test/hotspot/gtest/utilities/test_globalDefinitions.cpp ! test/hotspot/gtest/utilities/test_powerOfTwo.cpp Changeset: e6f99260 Author: Phil Race Date: 2021-01-04 21:09:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e6f99260 8257809: JNI warnings from Toolkit JPEG image decoding Reviewed-by: serb ! src/java.desktop/share/native/libjavajpeg/jpegdecoder.c + test/jdk/java/awt/image/GetImageJNICheck/GetImageJNICheck.java + test/jdk/java/awt/image/GetImageJNICheck/GetImageJNICheck.sh = test/jdk/java/awt/image/GetImageJNICheck/duke.jpg Changeset: f0aae81e Author: Xin Liu Committer: Paul Hohensee Date: 2021-01-04 23:58:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f0aae81e 8259020: null-check of g1 write_ref_field_pre_entry is not necessary Reviewed-by: kbarrett, ayang, phh ! src/hotspot/share/gc/g1/g1BarrierSetRuntime.cpp Changeset: 2499ac3d Author: Xue-Lei Andrew Fan Date: 2021-01-05 00:11:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2499ac3d 8259069: Fields could be final Reviewed-by: wetmore ! src/java.base/share/classes/sun/security/ssl/DHClientKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/EphemeralKeyManager.java ! src/java.base/share/classes/sun/security/ssl/HelloCookieManager.java ! src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/java.base/share/classes/sun/security/ssl/SSLCipher.java ! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java ! src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLExtensions.java ! src/java.base/share/classes/sun/security/ssl/SSLKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/java.base/share/classes/sun/security/ssl/SunJSSE.java ! src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java Changeset: 5ea96072 Author: Ioi Lam Date: 2021-01-05 05:57:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ea96072 8258459: Decouple gc_globals.hpp from globals.hpp Reviewed-by: lfoltan, coleenp ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/z/zGlobals_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp ! src/hotspot/cpu/arm/c1_Runtime1_arm.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/c1/shenandoahBarrierSetC1_x86.cpp ! src/hotspot/cpu/x86/gc/z/zGlobals_x86.cpp ! src/hotspot/cpu/x86/gc/z/z_x86_64.ad ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/aot/aotCodeHeap.cpp ! src/hotspot/share/gc/epsilon/epsilonArguments.cpp ! src/hotspot/share/gc/epsilon/epsilonInitLogger.cpp ! src/hotspot/share/gc/epsilon/epsilonThreadLocalData.hpp ! src/hotspot/share/gc/g1/g1AllocRegion.cpp ! src/hotspot/share/gc/g1/g1Allocator.cpp ! src/hotspot/share/gc/g1/g1Analytics.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1EvacStats.cpp ! src/hotspot/share/gc/g1/g1FromCardCache.cpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1InitLogger.cpp ! src/hotspot/share/gc/g1/g1ThreadLocalData.hpp ! src/hotspot/share/gc/parallel/jvmFlagConstraintsParallel.cpp ! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/markSweep.cpp ! src/hotspot/share/gc/shared/ageTable.cpp ! src/hotspot/share/gc/shared/blockOffsetTable.hpp ! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp ! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp ! src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/gcConfiguration.cpp ! src/hotspot/share/gc/shared/gcInitLogger.cpp ! src/hotspot/share/gc/shared/gcOverheadChecker.hpp ! src/hotspot/share/gc/shared/gcPolicyCounters.cpp ! src/hotspot/share/gc/shared/gcStats.cpp ! src/hotspot/share/gc/shared/gcVMOperations.cpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/gc/shared/plab.cpp ! src/hotspot/share/gc/shared/pretouchTask.cpp ! src/hotspot/share/gc/shared/referencePolicy.cpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp ! src/hotspot/share/gc/shared/suspendibleThreadSet.cpp ! src/hotspot/share/gc/shared/taskTerminator.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.inline.hpp + src/hotspot/share/gc/shared/tlab_globals.hpp ! src/hotspot/share/gc/shared/weakProcessor.cpp ! src/hotspot/share/gc/shared/workerManager.hpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp ! src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp ! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp ! src/hotspot/share/gc/shenandoah/shenandoahWorkerPolicy.cpp ! src/hotspot/share/gc/z/zAddressSpaceLimit.cpp ! src/hotspot/share/gc/z/zDirector.cpp ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zHeapIterator.cpp ! src/hotspot/share/gc/z/zHeuristics.cpp ! src/hotspot/share/gc/z/zMarkStackAllocator.cpp ! src/hotspot/share/gc/z/zRelocate.cpp ! src/hotspot/share/gc/z/zRelocationSetSelector.cpp ! src/hotspot/share/gc/z/zRuntimeWorkers.cpp ! src/hotspot/share/gc/z/zStat.cpp ! src/hotspot/share/gc/z/zThreadLocalAllocBuffer.cpp ! src/hotspot/share/gc/z/zUncommitter.cpp ! src/hotspot/share/gc/z/zUnmapper.cpp ! src/hotspot/share/gc/z/zValue.inline.hpp ! src/hotspot/share/gc/z/zVerify.cpp ! src/hotspot/share/gc/z/zWorkers.inline.hpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/jfr/leakprofiler/chains/pathToGcRootsOperation.cpp ! src/hotspot/share/jfr/support/jfrObjectAllocationSample.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp ! src/hotspot/share/memory/dynamicArchive.cpp ! src/hotspot/share/memory/heapShared.hpp ! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/oops/oop.cpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/oop.inline.hpp ! src/hotspot/share/opto/arraycopynode.cpp ! src/hotspot/share/opto/lcm.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/macroArrayCopy.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/flags/allFlags.hpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/thread.inline.hpp ! src/hotspot/share/runtime/threadSMR.inline.hpp ! test/hotspot/gtest/runtime/test_globals.cpp Changeset: dd8996c5 Author: Hao Sun Committer: Ningsheng Jian Date: 2021-01-05 07:31:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dd8996c5 8258946: Fix optimization-unstable code involving signed integer overflow Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/parse2.cpp Changeset: 17d1645e Author: Hao Sun Committer: Ningsheng Jian Date: 2021-01-05 08:29:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/17d1645e 8258751: Improve ExceptionHandlerTable dump Reviewed-by: thartmann, chagedorn, njian ! src/hotspot/share/code/exceptionHandlerTable.cpp ! src/hotspot/share/code/exceptionHandlerTable.hpp ! src/hotspot/share/code/nmethod.cpp Changeset: 3817c32f Author: Lehua Ding Committer: Jie Fu Date: 2021-01-05 08:34:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3817c32f 8258534: Epsilon: clean up unused includes Reviewed-by: shade, jiefu ! src/hotspot/share/gc/epsilon/epsilonArguments.cpp ! src/hotspot/share/gc/epsilon/epsilonBarrierSet.cpp Changeset: db6f3930 Author: Aleksey Shipilev Date: 2021-01-05 08:37:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/db6f3930 8251944: Add Shenandoah test config to compiler/gcbarriers/UnsafeIntrinsicsTest.java Reviewed-by: rkennke, adityam ! test/hotspot/jtreg/compiler/gcbarriers/UnsafeIntrinsicsTest.java Changeset: 9f151649 Author: Christian Hagedorn Date: 2021-01-05 09:54:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f151649 8259049: Uninitialized variable after JDK-8257513 Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/constantTable.cpp Changeset: a6c08813 Author: Sergey Bylokhov Date: 2021-01-05 12:47:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a6c08813 8256321: Some "inactive" color profiles use the wrong profile class Reviewed-by: prr ! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java + test/jdk/java/awt/color/CheckDefaultProperties.java Changeset: fc3b45c0 Author: Alexander Zuev Date: 2021-01-05 14:46:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc3b45c0 8258643: javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button" Reviewed-by: psadhukhan ! test/jdk/javax/swing/JComponent/7154030/bug7154030.java Changeset: f4122d6a Author: Harold Seigel Date: 2021-01-05 16:14:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f4122d6a 8258896: Remove the JVM ForceFloatExceptions option Reviewed-by: lfoltan, iklam, coleenp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: 82bdbfd7 Author: Hao Sun Committer: Aleksey Shipilev Date: 2021-01-05 16:28:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/82bdbfd7 8258857: Zero: non-PCH release build fails after JDK-8258074 Reviewed-by: jiefu, shade, iklam ! src/hotspot/share/compiler/compiler_globals.hpp Changeset: d5aa49d1 Author: Claes Redestad Date: 2021-01-05 16:41:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d5aa49d1 8259236: C2 compilation fails with assert(is_power_of_2(value)) failed: value must be a power of 2: 8000000000000000 Reviewed-by: thartmann ! src/hotspot/cpu/x86/x86_64.ad Changeset: 85bac8c4 Author: Peter Levart Date: 2021-01-05 17:41:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/85bac8c4 8259021: SharedSecrets should avoid double racy reads from non-volatile fields Reviewed-by: shade, redestad, rriggs, mchung, rrich, alanb ! src/java.base/share/classes/jdk/internal/access/SharedSecrets.java Changeset: 7ddc2b56 Author: Xue-Lei Andrew Fan Date: 2021-01-05 18:29:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7ddc2b56 8258852: Arrays.asList() for single item could be replaced with List.of() Reviewed-by: mullan ! src/java.base/share/classes/sun/security/ssl/ClientHello.java ! src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java ! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java Changeset: 1b60acd8 Author: Zhengyu Gu Date: 2021-01-05 18:33:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1b60acd8 8259252: Shenandoah: Shenandoah build failed on AArch64 after JDK-8258459 Reviewed-by: rkennke, shade ! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp Changeset: 4d3d5991 Author: Xue-Lei Andrew Fan Date: 2021-01-05 19:32:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d3d5991 8259223: Simplify boolean expression in the SunJSSE provider Reviewed-by: mullan ! src/java.base/share/classes/sun/security/ssl/CipherSuite.java ! src/java.base/share/classes/sun/security/ssl/EphemeralKeyManager.java ! src/java.base/share/classes/sun/security/ssl/Finished.java ! src/java.base/share/classes/sun/security/ssl/HandshakeContext.java ! src/java.base/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java ! src/java.base/share/classes/sun/security/ssl/ProtocolVersion.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/java.base/share/classes/sun/security/ssl/SignatureScheme.java ! src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/java.base/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java Changeset: cf9908b4 Author: Harold Seigel Date: 2021-01-05 21:15:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cf9908b4 8258937: Remove JVM IgnoreRewrites flag Reviewed-by: coleenp ! src/hotspot/share/oops/generateOopMap.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: 7d769663 Author: Guoxiong Li Committer: Vicente Romero Date: 2021-01-05 22:21:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7d769663 8255757: Javac emits duplicate pool entries on array::clone Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java + test/langtools/tools/javac/classfiles/T8255757/T8255757.java Changeset: 8b454977 Author: Yasumasa Suenaga Date: 2021-01-05 22:36:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8b454977 8259037: livenmethods cannot find hsdis library Reviewed-by: cjplummer, sspitsyn ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/asm/Disassembler.java ! src/jdk.hotspot.agent/share/native/libsaproc/sadis.c Changeset: 52d3feec Author: Xiaohong Gong Committer: Ningsheng Jian Date: 2021-01-06 01:40:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/52d3feec 8258813: [TESTBUG] Fix incorrect Vector API test output message Reviewed-by: psandoz, njian ! test/jdk/jdk/incubator/vector/AbstractVectorTest.java ! test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte128VectorTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Double128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double128VectorTests.java ! test/jdk/jdk/incubator/vector/Double256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double256VectorTests.java ! test/jdk/jdk/incubator/vector/Double512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double512VectorTests.java ! test/jdk/jdk/incubator/vector/Double64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double64VectorTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Float128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float128VectorTests.java ! test/jdk/jdk/incubator/vector/Float256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float256VectorTests.java ! test/jdk/jdk/incubator/vector/Float512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float512VectorTests.java ! test/jdk/jdk/incubator/vector/Float64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float64VectorTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Int128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int128VectorTests.java ! test/jdk/jdk/incubator/vector/Int256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int256VectorTests.java ! test/jdk/jdk/incubator/vector/Int512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int512VectorTests.java ! test/jdk/jdk/incubator/vector/Int64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int64VectorTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Long128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long128VectorTests.java ! test/jdk/jdk/incubator/vector/Long256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long256VectorTests.java ! test/jdk/jdk/incubator/vector/Long512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long512VectorTests.java ! test/jdk/jdk/incubator/vector/Long64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long64VectorTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Short128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short128VectorTests.java ! test/jdk/jdk/incubator/vector/Short256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short256VectorTests.java ! test/jdk/jdk/incubator/vector/Short512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short512VectorTests.java ! test/jdk/jdk/incubator/vector/Short64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short64VectorTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java ! test/jdk/jdk/incubator/vector/VectorReshapeTests.java ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-Long-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-Masked-Long-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-op-math.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-op-math.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Blend-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-BoolReduction-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Broadcast.template ! test/jdk/jdk/incubator/vector/templates/Unit-Gather-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Gather-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Get-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Miscellaneous.template ! test/jdk/jdk/incubator/vector/templates/Unit-Rearrange.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-Max-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-Min-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Max-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Min-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Scatter-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Scatter-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Shift-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Shift-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Single-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Slice-Masked-bop.template ! test/jdk/jdk/incubator/vector/templates/Unit-Slice-bop.template ! test/jdk/jdk/incubator/vector/templates/Unit-Slice-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Broadcast-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Broadcast-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Double-Broadcast-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Double-Broadcast-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unary-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unary-op-math.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unary-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unslice-Masked-bop.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unslice-bop.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unslice-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-With-Op.template ! test/jdk/jdk/incubator/vector/templates/Unit-header.template ! test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template Changeset: 32538b5b Author: Prasanta Sadhukhan Date: 2021-01-06 06:45:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/32538b5b 8193942: Regression automated test '/open/test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java' fails Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java Changeset: e3b9da14 Author: Xin Liu Committer: Aleksey Shipilev Date: 2021-01-06 09:51:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3b9da14 8259287: AbstractCompiler marks const in wrong position for is_c1/is_c2/is_jvmci Reviewed-by: thartmann, chagedorn, shade ! src/hotspot/share/compiler/abstractCompiler.hpp Changeset: 8a05d605 Author: Sergey Bylokhov Date: 2021-01-06 10:07:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8a05d605 8259042: Inconsistent use of general primitives loops Reviewed-by: prr ! src/java.desktop/share/classes/sun/java2d/loops/Blit.java ! src/java.desktop/share/classes/sun/java2d/loops/BlitBg.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphList.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListAA.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListLCD.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawLine.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawParallelogram.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawPath.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawPolygons.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawRect.java ! src/java.desktop/share/classes/sun/java2d/loops/FillParallelogram.java ! src/java.desktop/share/classes/sun/java2d/loops/FillPath.java ! src/java.desktop/share/classes/sun/java2d/loops/FillRect.java ! src/java.desktop/share/classes/sun/java2d/loops/FillSpans.java ! src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitive.java ! src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitiveMgr.java ! src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitiveProxy.java ! src/java.desktop/share/classes/sun/java2d/loops/MaskBlit.java ! src/java.desktop/share/classes/sun/java2d/loops/MaskFill.java ! src/java.desktop/share/classes/sun/java2d/loops/ScaledBlit.java ! src/java.desktop/share/classes/sun/java2d/loops/TransformBlit.java ! src/java.desktop/share/classes/sun/java2d/loops/TransformHelper.java Changeset: 7e01bc96 Author: Mat Carter Committer: Alan Bateman Date: 2021-01-06 10:39:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e01bc96 8255264: Support for identifying the full range of IPv4 localhost addresses on Windows Reviewed-by: alanb ! src/java.base/windows/native/libnet/net_util_md.h Changeset: c0540ffd Author: Daniel D. Daugherty Date: 2021-01-06 14:34:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c0540ffd 8231627: ThreadsListHandleInErrorHandlingTest.java fails in printing all threads Reviewed-by: eosterlund, coleenp, pchilanomate, sspitsyn ! src/hotspot/share/runtime/threadSMR.cpp ! test/hotspot/jtreg/runtime/ErrorHandling/NestedThreadsListHandleInErrorHandlingTest.java ! test/hotspot/jtreg/runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java Changeset: f6cb8c55 Author: Harold Seigel Date: 2021-01-06 15:11:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f6cb8c55 8258908: Remove JVM option CleanChunkPoolAsync Reviewed-by: coleenp ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/memory/arena.cpp ! src/hotspot/share/memory/arena.hpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/thread.cpp Changeset: 722f2361 Author: Lehua Ding Committer: Aleksey Shipilev Date: 2021-01-06 15:36:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/722f2361 8259231: Epsilon: improve performance under contention during virtual space expansion Reviewed-by: shade ! src/hotspot/share/gc/epsilon/epsilonHeap.cpp Changeset: 3be6e069 Author: Rajan Halade Date: 2021-01-06 16:20:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3be6e069 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days Reviewed-by: mullan ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: d20d2fa9 Author: Joe Darcy Date: 2021-01-06 16:26:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d20d2fa9 8258143: Update --release 16 symbol information for JDK 16 build 30 or later Reviewed-by: iris, erikj ! make/data/symbols/java.desktop-G.sym.txt Changeset: df721f0c Author: Xue-Lei Andrew Fan Date: 2021-01-06 16:57:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/df721f0c 8259291: Cleanup unnecessary local variables Reviewed-by: mullan ! src/java.base/share/classes/sun/security/ssl/Finished.java ! src/java.base/share/classes/sun/security/ssl/OutputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLExtension.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketOutputRecord.java ! src/java.base/share/classes/sun/security/ssl/ServerNameExtension.java ! src/java.base/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java Changeset: 940b0530 Author: Phil Race Date: 2021-01-06 17:34:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/940b0530 8259232: Bad JNI lookup during printing Reviewed-by: psadhukhan ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m ! test/jdk/java/awt/print/bug8023392/bug8023392.java Changeset: 80544e4d Author: Joe Darcy Date: 2021-01-06 18:05:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/80544e4d 8250564: Remove terminally deprecated constructor in GSSUtil 8250565: Remove terminally deprecated constructor in java.net.URLDecoder Reviewed-by: bpb, smarks, alanb, mullan ! src/java.base/share/classes/java/net/URLDecoder.java ! src/jdk.security.jgss/share/classes/com/sun/security/jgss/GSSUtil.java ! test/jdk/java/net/URLDecoder/B6463990.java Changeset: 28e1f4d9 Author: Yoshiki Sato Committer: Jonathan Gibbons Date: 2021-01-06 22:48:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/28e1f4d9 8247957: remove doclint support for HTML 4 8257204: Remove usage of -Xhtmlversion option from javac 8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option 8258460: Remove --doclint-format option from javac 8256312: Valid anchor 'id' value not allowed Reviewed-by: jjg, ihse ! make/common/JavaCompilation.gmk ! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlVersion.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties ! test/langtools/jdk/javadoc/doclet/testHtmlTableStyles/TestHtmlTableStyles.java ! test/langtools/tools/doclint/AccessibilityTest.java ! test/langtools/tools/doclint/AccessibilityTest.out - test/langtools/tools/doclint/AccessibilityTest5.java - test/langtools/tools/doclint/AccessibilityTest5.out ! test/langtools/tools/doclint/AnchorTest.java ! test/langtools/tools/doclint/AnchorTest.out ! test/langtools/tools/doclint/AnchorTest2.java ! test/langtools/tools/doclint/AnchorTest2.out ! test/langtools/tools/doclint/AnchorTest2a.java ! test/langtools/tools/doclint/EndTagsTest.java ! test/langtools/tools/doclint/HtmlAttrsTest.java ! test/langtools/tools/doclint/HtmlAttrsTest.out ! test/langtools/tools/doclint/HtmlTagsTest.java ! test/langtools/tools/doclint/HtmlTagsTest.out - test/langtools/tools/doclint/HtmlVersionTest.java ! test/langtools/tools/doclint/anchorTests/p/Test.java ! test/langtools/tools/doclint/anchorTests/p/Test.out ! test/langtools/tools/doclint/anchorTests/p/package-info.java ! test/langtools/tools/doclint/anchorTests/p/package-info.javac.out ! test/langtools/tools/doclint/anchorTests/p/package-info.out ! test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.java + test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.out - test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTestHtml4.out - test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTestHtml5.out + test/langtools/tools/doclint/html/InlineTagTest.out ! test/langtools/tools/doclint/html/InlineTagsTest.java ! test/langtools/tools/doclint/html/OtherTagsTest.java ! test/langtools/tools/doclint/html/OtherTagsTest.out + test/langtools/tools/doclint/html/TableTagTest.out ! test/langtools/tools/doclint/html/TableTagsTest.java ! test/langtools/tools/doclint/html/TagNotAllowed.java ! test/langtools/tools/doclint/html/TagNotAllowed.out ! test/langtools/tools/doclint/html/TextNotAllowed.java ! test/langtools/tools/doclint/html/TextNotAllowed.out ! test/langtools/tools/doclint/tidy/AnchorAlreadyDefined.java ! test/langtools/tools/doclint/tidy/AnchorAlreadyDefined.out ! test/langtools/tools/doclint/tidy/BadEnd.java ! test/langtools/tools/doclint/tidy/BadEnd.out ! test/langtools/tools/doclint/tidy/InvalidName.java ! test/langtools/tools/doclint/tidy/InvalidName.out ! test/langtools/tools/doclint/tidy/TextNotAllowed.java ! test/langtools/tools/doclint/tidy/TextNotAllowed.out ! test/langtools/tools/doclint/tidy/TrimmingEmptyTag.java ! test/langtools/tools/doclint/tidy/TrimmingEmptyTag.out ! test/langtools/tools/javac/doclint/DocLintFormatTest.java Changeset: 67c22114 Author: Yasumasa Suenaga Date: 2021-01-06 23:59:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/67c22114 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale Reviewed-by: erikj, cjplummer, iklam ! make/modules/jdk.hotspot.agent/Lib.gmk ! src/jdk.hotspot.agent/share/native/libsaproc/sadis.c Changeset: 227f99d3 Author: Prasanta Sadhukhan Date: 2021-01-07 03:57:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/227f99d3 8233555: [TESTBUG] JRadioButton tests failing on MacoS Reviewed-by: serb ! test/jdk/ProblemList.txt Changeset: 81c06242 Author: Carter Kozak Committer: Erik Gahlin Date: 2021-01-07 06:11:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81c06242 8259354: Fix race condition in AbstractEventStream.nextThreadName Reviewed-by: egahlin ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java Changeset: 0e6de4eb Author: Tobias Hartmann Date: 2021-01-07 12:15:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0e6de4eb 8259339: AllocateUninitializedArray C2 intrinsic fails with void.class input Reviewed-by: kvn, chagedorn ! src/hotspot/share/opto/library_call.cpp ! test/hotspot/jtreg/compiler/intrinsics/unsafe/AllocateUninitializedArray.java Changeset: 1c33847b Author: Coleen Phillimore Date: 2021-01-07 12:35:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1c33847b 8259067: bootclasspath append takes out object lock Reviewed-by: lfoltan, sspitsyn, iklam, dholmes ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/classfile/classLoader.inline.hpp ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: 3f9f86f0 Author: Matthias Baesken Date: 2021-01-07 12:39:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3f9f86f0 8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006 Reviewed-by: clanger, mdoerr ! make/modules/java.desktop/lib/Awt2dLibraries.gmk Changeset: f91f92dc Author: Harold Seigel Date: 2021-01-07 13:18:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f91f92dc 8259317: Remove JVM option BreakAtWarning Reviewed-by: lfoltan, coleenp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/utilities/debug.cpp Changeset: 8530ef0e Author: Coleen Phillimore Date: 2021-01-07 17:13:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8530ef0e 8259375: JvmtiExport::jni_Get/SetField_probe calls do not need ResetNoHandleMark Reviewed-by: lfoltan, dcubed ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvmtiExport.cpp Changeset: 2e99e28f Author: Sergey Bylokhov Date: 2021-01-07 17:49:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2e99e28f 8213126: java/awt/Window/MainKeyWindow/TestMainKeyWindow.java time-out on mac10.13 Reviewed-by: psadhukhan ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java Changeset: 4ce83f2a Author: Rajan Halade Date: 2021-01-07 18:47:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ce83f2a 8039278: console.sh failed Automatically with exit code 1 Reviewed-by: xuelei, weijun ! test/jdk/TEST.groups - test/jdk/sun/security/tools/keytool/console.sh Changeset: d8ad6301 Author: Roberto Casta?eda Lozano Committer: Vladimir Kozlov Date: 2021-01-07 18:57:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d8ad6301 8258772: Some runtime/cds tests fail with +LogCompilation or +StressX Emit warning about TraceDependencies results in ClassHierarchyWalker::count_find_witness_calls() only if TraceDependencies is actually enabled. Use standard warning() function instead of ad hoc printing. Remove warning about using Stress(LCM|GCM|IGVN) without LogCompilation in Compile::Compile(), and add the information to the description of the StressSeed option instead. These changes prevent false test failures when using LogCompilation or Stress(LCM|GCM|IGVN). Reviewed-by: chagedorn, kvn, thartmann ! src/hotspot/share/code/dependencies.cpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/compile.cpp Changeset: bc565414 Author: Roberto Casta?eda Lozano Committer: Vladimir Kozlov Date: 2021-01-07 20:43:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bc565414 8256535: C2: randomize CCP processing order for stress testing Add 'StressCCP' option to randomize the selection of the node to be examined in each CCP iteration. Reviewed-by: chagedorn, kvn, thartmann ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/phaseX.cpp - test/hotspot/jtreg/compiler/arguments/TestStressIGVNOptions.java + test/hotspot/jtreg/compiler/arguments/TestStressOptions.java ! test/hotspot/jtreg/compiler/debug/TestGenerateStressSeed.java - test/hotspot/jtreg/compiler/debug/TestStressIGVN.java + test/hotspot/jtreg/compiler/debug/TestStressIGVNAndCCP.java Changeset: 2659bc44 Author: Brian Burkhalter Date: 2021-01-07 20:57:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2659bc44 8259274: Increase timeout duration in sun/nio/ch/TestMaxCachedBufferSize.java Reviewed-by: lancea ! test/jdk/sun/nio/ch/TestMaxCachedBufferSize.java Changeset: 73f54153 Author: Chris Hegarty Date: 2021-01-02 19:29:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/73f54153 8258955: (bf) slice(int, int) on view buffers fails to adjust index according to primitive size Reviewed-by: alanb ! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template ! test/jdk/java/nio/Buffer/ByteBufferViews.java Changeset: 216c2ec0 Author: Jie Fu Date: 2021-01-04 23:41:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/216c2ec0 8258703: Incorrect 512-bit vector registers restore on x86_32 Reviewed-by: kvn, sviswanathan ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp Changeset: 4ffbe841 Author: Jan Lahoda Date: 2021-01-05 11:40:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ffbe841 8256266: Binding variables don't correctly support declaration annotations and the final modifier Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/langtools/tools/javac/patterns/Annotations.java ! test/langtools/tools/javac/patterns/BindingsTest1.java ! test/langtools/tools/javac/patterns/BindingsTest2.java ! test/langtools/tools/javac/patterns/BindingsTest2.out + test/langtools/tools/javac/patterns/NoModifiersOnBinding.java + test/langtools/tools/javac/patterns/NoModifiersOnBinding.out Changeset: 6775113c Author: Roland Westrelin Date: 2021-01-05 13:06:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6775113c 8258393: Shenandoah: "graph should be schedulable" assert failure Reviewed-by: rkennke, thartmann ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/opto/loopnode.cpp + test/hotspot/jtreg/gc/shenandoah/compiler/TestBadRawMemoryAfterCall.java Changeset: bbc2e951 Author: Erik Gahlin Date: 2021-01-05 13:39:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bbc2e951 8257906: JFR: RecordingStream leaks memory Reviewed-by: mgronlun Backport-of: 3c6648501589bf36945340cb1e82c833ebd7485d ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ChunkParser.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventDirectoryStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventFileStream.java Changeset: b7940aa1 Author: Maurizio Cimadamore Date: 2021-01-05 16:15:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b7940aa1 8259027: NullPointerException in makeMappedSegment due to NULL Unmapper when length of segment is 0 Reviewed-by: chegar, uschindler ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MappedMemorySegmentImpl.java ! test/jdk/java/foreign/TestByteBuffer.java Changeset: 50bf4330 Author: Sandhya Viswanathan Date: 2021-01-05 17:42:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/50bf4330 8259213: Vector conversion with part > 0 is not getting intrinsic implementation Reviewed-by: psandoz ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractShuffle.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java Changeset: d5293067 Author: Vicente Romero Date: 2021-01-05 21:35:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d5293067 8213032: program fails with LambdaConversionException at execution time Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/langtools/tools/javac/lambda/methodReferenceExecution/MethodReferenceIntersection4.java Changeset: 554e60c4 Author: Wang Huang Committer: Fei Yang Date: 2021-01-06 01:49:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/554e60c4 8258989: JVM is failed to inline in jdk.internal.vm.vector.VectorSupport::convert Co-authored-by: He Xuejin Reviewed-by: vlivanov, thartmann ! src/hotspot/share/opto/vectorIntrinsics.cpp Changeset: 80110dac Author: Prasanta Sadhukhan Date: 2021-01-06 06:36:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/80110dac 8259007: This test printed a blank page Reviewed-by: prr, serb ! src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java ! src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp - test/jdk/java/awt/print/PathPrecisionScaleFactor/PathPrecisionScaleFactorTest.java Changeset: e66187d8 Author: Maurizio Cimadamore Date: 2021-01-06 12:18:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e66187d8 8259032: MappedMemorySegmentImpl#makeMappedSegment() ignores Unmapper#pagePosition Co-authored-by: Uwe Schindler Reviewed-by: alanb ! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java ! test/jdk/java/foreign/TestByteBuffer.java Changeset: ad456787 Author: Aleksey Shipilev Date: 2021-01-06 13:27:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ad456787 8258558: Revert changes for JDK-8252505 and related issues Reviewed-by: kvn ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/compiler/compilerOracle.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/memnode.hpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/regmask.cpp ! src/hotspot/share/opto/regmask.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/TEST.groups - test/hotspot/jtreg/compiler/blackhole/BlackholeDiagnosticUnlockTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeInstanceReturnTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeInstanceTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeNonVoidWarningTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeNullCheckTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeStaticReturnTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeStaticTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeTarget.java Changeset: d25a1bed Author: Rafael Winterhalter Committer: Joel Borggr?n-Franck Date: 2021-01-06 15:46:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d25a1bed 8259224: (ann) getAnnotatedReceiverType should not parameterize owner(s) of statically nested classes Reviewed-by: jfranck ! src/java.base/share/classes/java/lang/reflect/Executable.java + test/jdk/java/lang/annotation/typeAnnotations/TestReceiverTypeOwnerType.java Changeset: 4a5786b5 Author: Naoto Sato Date: 2021-01-06 16:30:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4a5786b5 8259075: Update the copyright notice in the files generated by CLDR Converter tool Reviewed-by: joehw ! make/jdk/src/classes/build/tools/cldrconverter/CopyrightHeaders.java Changeset: f1bc4e05 Author: Rajan Halade Date: 2021-01-06 16:39:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f1bc4e05 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days Backport-of: 3be6e06958c4304cafee707a29d06d6b2cc5b76b ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: eef43be7 Author: Jonathan Gibbons Date: 2021-01-06 18:52:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eef43be7 8251200: False positive messages about missing comments for serialization Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/SerializedFormBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java + test/langtools/jdk/javadoc/doclet/testSerialMissing/TestSerialMissing.java Changeset: 4f914e21 Author: Jonathan Gibbons Date: 2021-01-06 19:26:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4f914e21 8249633: doclint reports missing javadoc for JavaFX property methods that have a property description Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MemberSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java Changeset: 555641ed Author: Jesper Wilhelmsson Date: 2021-01-07 21:17:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/555641ed Merge ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/hotspot/jtreg/TEST.groups ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/hotspot/jtreg/TEST.groups Changeset: b996cccf Author: Coleen Phillimore Date: 2021-01-07 23:04:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b996cccf 8259373: c1 and jvmci runtime code use ResetNoHandleMark incorrectly Reviewed-by: kvn ! src/hotspot/share/c1/c1_Runtime1.cpp ! src/hotspot/share/code/compiledMethod.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp Changeset: 4a478b8a Author: Erik Gahlin Date: 2021-01-07 12:21:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4a478b8a 8250903: jdk/jfr/javaagent/TestLoadedAgent.java fails with Mismatch in TestEvent count Reviewed-by: mgronlun ! test/jdk/jdk/jfr/javaagent/EventEmitterAgent.java Changeset: 484e23b9 Author: Erik Joelsson Date: 2021-01-07 14:57:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/484e23b9 8258657: Doc build is broken by use of new language features Reviewed-by: tbell, iris ! make/Docs.gmk ! make/autoconf/boot-jdk.m4 ! make/autoconf/configure.ac ! make/autoconf/spec.gmk.in ! make/conf/jib-profiles.js Changeset: c1fb5216 Author: Christian Hagedorn Date: 2021-01-07 15:02:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c1fb5216 8259227: C2 crashes with SIGFPE due to a division that floats above its zero check Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/phaseX.hpp + test/hotspot/jtreg/compiler/loopopts/TestDivZeroDominatedBy.java ! test/hotspot/jtreg/compiler/loopopts/TestDivZeroWithSplitIf.java Changeset: acdd90b6 Author: Vicente Romero Date: 2021-01-07 16:38:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/acdd90b6 8258972: unexpected compilation error with generic sealed interface Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java Changeset: 1973fbee Author: Rajan Halade Date: 2021-01-07 19:21:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1973fbee 8039278: console.sh failed Automatically with exit code 1 Backport-of: 4ce83f2a3a6c5fe11c298bed557c341e286e068a ! test/jdk/TEST.groups - test/jdk/sun/security/tools/keytool/console.sh Changeset: 677802d2 Author: Christoph Langer Date: 2021-01-07 22:51:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/677802d2 8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006 Backport-of: 3f9f86f0d3f918b9955ba6ba73c9c58ae8fcf7cb ! make/modules/java.desktop/lib/Awt2dLibraries.gmk Changeset: 56a354eb Author: Jesper Wilhelmsson Date: 2021-01-07 23:51:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/56a354eb Merge ! make/Docs.gmk ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/phaseX.cpp ! make/Docs.gmk ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/phaseX.cpp Changeset: 712014c5 Author: David Holmes Date: 2021-01-08 04:11:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/712014c5 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 Reviewed-by: dcubed, hseigel ! src/hotspot/share/prims/jniCheck.cpp + test/hotspot/jtreg/runtime/jni/checked/TestCheckedReleaseArrayElements.java + test/hotspot/jtreg/runtime/jni/checked/TestCheckedReleaseCriticalArray.java + test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseArrayElements.c + test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c Changeset: fc1d2a1e Author: Claes Redestad Date: 2021-01-08 09:20:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc1d2a1e 8259065: Optimize MessageDigest.getInstance Reviewed-by: valeriep ! src/java.base/share/classes/java/security/MessageDigest.java ! src/java.base/share/classes/java/security/Provider.java ! src/java.base/share/classes/sun/security/jca/ProviderConfig.java + test/micro/org/openjdk/bench/java/security/GetMessageDigest.java Changeset: b549cbd3 Author: Thomas Schatzl Date: 2021-01-08 10:52:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b549cbd3 8258481: gc.g1.plab.TestPLABPromotion fails on Linux x86 Reviewed-by: sjohanss, kbarrett ! test/hotspot/jtreg/gc/g1/plab/TestPLABPromotion.java Changeset: 04b8ca02 Author: duke Date: 2021-01-08 11:00:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/04b8ca02 Automatic merge of jdk:master into master From duke at openjdk.java.net Fri Jan 8 11:17:08 2021 From: duke at openjdk.java.net (duke) Date: Fri, 8 Jan 2021 11:17:08 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 88 new changesets Message-ID: <2a0ff517-ba4d-49af-9026-00f9f81d99a2@openjdk.org> Changeset: 497efefa Author: Sergey Bylokhov Date: 2021-01-03 05:08:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/497efefa 8225116: Test OwnedWindowsLeak.java intermittently fails Reviewed-by: pbansal ! test/jdk/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java Changeset: 526c0005 Author: Guoxiong Li Committer: Jonathan Gibbons Date: 2021-01-03 17:32:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/526c0005 8255729: com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacFiler.java Changeset: f351e155 Author: Hao Sun Committer: Ningsheng Jian Date: 2021-01-04 02:21:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f351e155 8258382: Fix optimization-unstable code involving pointer overflow Reviewed-by: kbarrett ! src/hotspot/share/gc/parallel/psPromotionLAB.hpp ! src/hotspot/share/gc/parallel/psPromotionLAB.inline.hpp Changeset: a2a3f4a3 Author: Prasanta Sadhukhan Date: 2021-01-04 04:33:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a2a3f4a3 8258924: javax/swing/JSplitPane/4201995/bug4201995.java fails in GTk L&F Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JSplitPane/4201995/bug4201995.java Changeset: d679caa2 Author: Prasanta Sadhukhan Date: 2021-01-04 06:35:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d679caa2 8196466: javax/swing/JFileChooser/8062561/bug8062561.java fails Reviewed-by: serb ! test/jdk/ProblemList.txt Changeset: 7f04d23b Author: Coleen Phillimore Date: 2021-01-04 16:44:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7f04d23b 8258800: Deprecate -XX:+AlwaysLockClassLoader Reviewed-by: hseigel ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: f80c63b3 Author: Zhengyu Gu Date: 2021-01-04 18:10:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f80c63b3 8258490: Shenandoah: Full GC does not need to remark threads and drain SATB buffers Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp Changeset: 9d160aa1 Author: Claes Redestad Date: 2021-01-04 21:01:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9d160aa1 8257815: Replace global log2 functions with efficient implementations Reviewed-by: kbarrett, stefank ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/z/zGlobals_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/ppc/assembler_ppc.cpp ! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp ! src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/cpu/x86/gc/z/zGlobals_x86.cpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/compiler/compilerDefinitions.cpp ! src/hotspot/share/compiler/tieredThresholdPolicy.cpp ! src/hotspot/share/gc/g1/g1BiasedArray.hpp ! src/hotspot/share/gc/g1/g1FreeIdSet.cpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/shared/partialArrayTaskStepper.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNumberSeq.cpp ! src/hotspot/share/gc/z/zHeuristics.cpp ! src/hotspot/share/opto/divnode.cpp ! src/hotspot/share/opto/mulnode.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! src/hotspot/share/utilities/hashtable.cpp ! src/hotspot/share/utilities/powerOfTwo.hpp ! test/hotspot/gtest/utilities/test_globalDefinitions.cpp ! test/hotspot/gtest/utilities/test_powerOfTwo.cpp Changeset: e6f99260 Author: Phil Race Date: 2021-01-04 21:09:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e6f99260 8257809: JNI warnings from Toolkit JPEG image decoding Reviewed-by: serb ! src/java.desktop/share/native/libjavajpeg/jpegdecoder.c + test/jdk/java/awt/image/GetImageJNICheck/GetImageJNICheck.java + test/jdk/java/awt/image/GetImageJNICheck/GetImageJNICheck.sh = test/jdk/java/awt/image/GetImageJNICheck/duke.jpg Changeset: f0aae81e Author: Xin Liu Committer: Paul Hohensee Date: 2021-01-04 23:58:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f0aae81e 8259020: null-check of g1 write_ref_field_pre_entry is not necessary Reviewed-by: kbarrett, ayang, phh ! src/hotspot/share/gc/g1/g1BarrierSetRuntime.cpp Changeset: 2499ac3d Author: Xue-Lei Andrew Fan Date: 2021-01-05 00:11:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2499ac3d 8259069: Fields could be final Reviewed-by: wetmore ! src/java.base/share/classes/sun/security/ssl/DHClientKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/EphemeralKeyManager.java ! src/java.base/share/classes/sun/security/ssl/HelloCookieManager.java ! src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/java.base/share/classes/sun/security/ssl/SSLCipher.java ! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java ! src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLExtensions.java ! src/java.base/share/classes/sun/security/ssl/SSLKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/java.base/share/classes/sun/security/ssl/SunJSSE.java ! src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java Changeset: 5ea96072 Author: Ioi Lam Date: 2021-01-05 05:57:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5ea96072 8258459: Decouple gc_globals.hpp from globals.hpp Reviewed-by: lfoltan, coleenp ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/z/zGlobals_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp ! src/hotspot/cpu/arm/c1_Runtime1_arm.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/c1/shenandoahBarrierSetC1_x86.cpp ! src/hotspot/cpu/x86/gc/z/zGlobals_x86.cpp ! src/hotspot/cpu/x86/gc/z/z_x86_64.ad ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/aot/aotCodeHeap.cpp ! src/hotspot/share/gc/epsilon/epsilonArguments.cpp ! src/hotspot/share/gc/epsilon/epsilonInitLogger.cpp ! src/hotspot/share/gc/epsilon/epsilonThreadLocalData.hpp ! src/hotspot/share/gc/g1/g1AllocRegion.cpp ! src/hotspot/share/gc/g1/g1Allocator.cpp ! src/hotspot/share/gc/g1/g1Analytics.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1EvacStats.cpp ! src/hotspot/share/gc/g1/g1FromCardCache.cpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1InitLogger.cpp ! src/hotspot/share/gc/g1/g1ThreadLocalData.hpp ! src/hotspot/share/gc/parallel/jvmFlagConstraintsParallel.cpp ! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/markSweep.cpp ! src/hotspot/share/gc/shared/ageTable.cpp ! src/hotspot/share/gc/shared/blockOffsetTable.hpp ! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp ! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp ! src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/gcConfiguration.cpp ! src/hotspot/share/gc/shared/gcInitLogger.cpp ! src/hotspot/share/gc/shared/gcOverheadChecker.hpp ! src/hotspot/share/gc/shared/gcPolicyCounters.cpp ! src/hotspot/share/gc/shared/gcStats.cpp ! src/hotspot/share/gc/shared/gcVMOperations.cpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/gc/shared/plab.cpp ! src/hotspot/share/gc/shared/pretouchTask.cpp ! src/hotspot/share/gc/shared/referencePolicy.cpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp ! src/hotspot/share/gc/shared/suspendibleThreadSet.cpp ! src/hotspot/share/gc/shared/taskTerminator.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.inline.hpp + src/hotspot/share/gc/shared/tlab_globals.hpp ! src/hotspot/share/gc/shared/weakProcessor.cpp ! src/hotspot/share/gc/shared/workerManager.hpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp ! src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp ! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp ! src/hotspot/share/gc/shenandoah/shenandoahWorkerPolicy.cpp ! src/hotspot/share/gc/z/zAddressSpaceLimit.cpp ! src/hotspot/share/gc/z/zDirector.cpp ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zHeapIterator.cpp ! src/hotspot/share/gc/z/zHeuristics.cpp ! src/hotspot/share/gc/z/zMarkStackAllocator.cpp ! src/hotspot/share/gc/z/zRelocate.cpp ! src/hotspot/share/gc/z/zRelocationSetSelector.cpp ! src/hotspot/share/gc/z/zRuntimeWorkers.cpp ! src/hotspot/share/gc/z/zStat.cpp ! src/hotspot/share/gc/z/zThreadLocalAllocBuffer.cpp ! src/hotspot/share/gc/z/zUncommitter.cpp ! src/hotspot/share/gc/z/zUnmapper.cpp ! src/hotspot/share/gc/z/zValue.inline.hpp ! src/hotspot/share/gc/z/zVerify.cpp ! src/hotspot/share/gc/z/zWorkers.inline.hpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/jfr/leakprofiler/chains/pathToGcRootsOperation.cpp ! src/hotspot/share/jfr/support/jfrObjectAllocationSample.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp ! src/hotspot/share/memory/dynamicArchive.cpp ! src/hotspot/share/memory/heapShared.hpp ! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/oops/oop.cpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/oop.inline.hpp ! src/hotspot/share/opto/arraycopynode.cpp ! src/hotspot/share/opto/lcm.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/macroArrayCopy.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/flags/allFlags.hpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/thread.inline.hpp ! src/hotspot/share/runtime/threadSMR.inline.hpp ! test/hotspot/gtest/runtime/test_globals.cpp Changeset: dd8996c5 Author: Hao Sun Committer: Ningsheng Jian Date: 2021-01-05 07:31:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dd8996c5 8258946: Fix optimization-unstable code involving signed integer overflow Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/parse2.cpp Changeset: 17d1645e Author: Hao Sun Committer: Ningsheng Jian Date: 2021-01-05 08:29:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/17d1645e 8258751: Improve ExceptionHandlerTable dump Reviewed-by: thartmann, chagedorn, njian ! src/hotspot/share/code/exceptionHandlerTable.cpp ! src/hotspot/share/code/exceptionHandlerTable.hpp ! src/hotspot/share/code/nmethod.cpp Changeset: 3817c32f Author: Lehua Ding Committer: Jie Fu Date: 2021-01-05 08:34:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3817c32f 8258534: Epsilon: clean up unused includes Reviewed-by: shade, jiefu ! src/hotspot/share/gc/epsilon/epsilonArguments.cpp ! src/hotspot/share/gc/epsilon/epsilonBarrierSet.cpp Changeset: db6f3930 Author: Aleksey Shipilev Date: 2021-01-05 08:37:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/db6f3930 8251944: Add Shenandoah test config to compiler/gcbarriers/UnsafeIntrinsicsTest.java Reviewed-by: rkennke, adityam ! test/hotspot/jtreg/compiler/gcbarriers/UnsafeIntrinsicsTest.java Changeset: 9f151649 Author: Christian Hagedorn Date: 2021-01-05 09:54:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f151649 8259049: Uninitialized variable after JDK-8257513 Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/constantTable.cpp Changeset: a6c08813 Author: Sergey Bylokhov Date: 2021-01-05 12:47:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a6c08813 8256321: Some "inactive" color profiles use the wrong profile class Reviewed-by: prr ! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java + test/jdk/java/awt/color/CheckDefaultProperties.java Changeset: fc3b45c0 Author: Alexander Zuev Date: 2021-01-05 14:46:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc3b45c0 8258643: javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button" Reviewed-by: psadhukhan ! test/jdk/javax/swing/JComponent/7154030/bug7154030.java Changeset: f4122d6a Author: Harold Seigel Date: 2021-01-05 16:14:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f4122d6a 8258896: Remove the JVM ForceFloatExceptions option Reviewed-by: lfoltan, iklam, coleenp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: 82bdbfd7 Author: Hao Sun Committer: Aleksey Shipilev Date: 2021-01-05 16:28:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/82bdbfd7 8258857: Zero: non-PCH release build fails after JDK-8258074 Reviewed-by: jiefu, shade, iklam ! src/hotspot/share/compiler/compiler_globals.hpp Changeset: d5aa49d1 Author: Claes Redestad Date: 2021-01-05 16:41:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d5aa49d1 8259236: C2 compilation fails with assert(is_power_of_2(value)) failed: value must be a power of 2: 8000000000000000 Reviewed-by: thartmann ! src/hotspot/cpu/x86/x86_64.ad Changeset: 85bac8c4 Author: Peter Levart Date: 2021-01-05 17:41:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/85bac8c4 8259021: SharedSecrets should avoid double racy reads from non-volatile fields Reviewed-by: shade, redestad, rriggs, mchung, rrich, alanb ! src/java.base/share/classes/jdk/internal/access/SharedSecrets.java Changeset: 7ddc2b56 Author: Xue-Lei Andrew Fan Date: 2021-01-05 18:29:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7ddc2b56 8258852: Arrays.asList() for single item could be replaced with List.of() Reviewed-by: mullan ! src/java.base/share/classes/sun/security/ssl/ClientHello.java ! src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java ! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java Changeset: 1b60acd8 Author: Zhengyu Gu Date: 2021-01-05 18:33:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1b60acd8 8259252: Shenandoah: Shenandoah build failed on AArch64 after JDK-8258459 Reviewed-by: rkennke, shade ! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp Changeset: 4d3d5991 Author: Xue-Lei Andrew Fan Date: 2021-01-05 19:32:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d3d5991 8259223: Simplify boolean expression in the SunJSSE provider Reviewed-by: mullan ! src/java.base/share/classes/sun/security/ssl/CipherSuite.java ! src/java.base/share/classes/sun/security/ssl/EphemeralKeyManager.java ! src/java.base/share/classes/sun/security/ssl/Finished.java ! src/java.base/share/classes/sun/security/ssl/HandshakeContext.java ! src/java.base/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java ! src/java.base/share/classes/sun/security/ssl/ProtocolVersion.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/java.base/share/classes/sun/security/ssl/SignatureScheme.java ! src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/java.base/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java Changeset: cf9908b4 Author: Harold Seigel Date: 2021-01-05 21:15:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cf9908b4 8258937: Remove JVM IgnoreRewrites flag Reviewed-by: coleenp ! src/hotspot/share/oops/generateOopMap.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: 7d769663 Author: Guoxiong Li Committer: Vicente Romero Date: 2021-01-05 22:21:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7d769663 8255757: Javac emits duplicate pool entries on array::clone Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java + test/langtools/tools/javac/classfiles/T8255757/T8255757.java Changeset: 8b454977 Author: Yasumasa Suenaga Date: 2021-01-05 22:36:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8b454977 8259037: livenmethods cannot find hsdis library Reviewed-by: cjplummer, sspitsyn ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/asm/Disassembler.java ! src/jdk.hotspot.agent/share/native/libsaproc/sadis.c Changeset: 52d3feec Author: Xiaohong Gong Committer: Ningsheng Jian Date: 2021-01-06 01:40:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/52d3feec 8258813: [TESTBUG] Fix incorrect Vector API test output message Reviewed-by: psandoz, njian ! test/jdk/jdk/incubator/vector/AbstractVectorTest.java ! test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte128VectorTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte256VectorTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte512VectorTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Byte64VectorTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Double128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double128VectorTests.java ! test/jdk/jdk/incubator/vector/Double256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double256VectorTests.java ! test/jdk/jdk/incubator/vector/Double512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double512VectorTests.java ! test/jdk/jdk/incubator/vector/Double64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Double64VectorTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Float128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float128VectorTests.java ! test/jdk/jdk/incubator/vector/Float256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float256VectorTests.java ! test/jdk/jdk/incubator/vector/Float512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float512VectorTests.java ! test/jdk/jdk/incubator/vector/Float64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Float64VectorTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Int128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int128VectorTests.java ! test/jdk/jdk/incubator/vector/Int256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int256VectorTests.java ! test/jdk/jdk/incubator/vector/Int512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int512VectorTests.java ! test/jdk/jdk/incubator/vector/Int64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Int64VectorTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Long128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long128VectorTests.java ! test/jdk/jdk/incubator/vector/Long256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long256VectorTests.java ! test/jdk/jdk/incubator/vector/Long512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long512VectorTests.java ! test/jdk/jdk/incubator/vector/Long64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Long64VectorTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java ! test/jdk/jdk/incubator/vector/Short128VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short128VectorTests.java ! test/jdk/jdk/incubator/vector/Short256VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short256VectorTests.java ! test/jdk/jdk/incubator/vector/Short512VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short512VectorTests.java ! test/jdk/jdk/incubator/vector/Short64VectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/Short64VectorTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorLoadStoreTests.java ! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java ! test/jdk/jdk/incubator/vector/VectorReshapeTests.java ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-Long-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-Masked-Long-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-op-math.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-op-math.template ! test/jdk/jdk/incubator/vector/templates/Unit-Binary-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Blend-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-BoolReduction-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Broadcast.template ! test/jdk/jdk/incubator/vector/templates/Unit-Gather-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Gather-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Get-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Miscellaneous.template ! test/jdk/jdk/incubator/vector/templates/Unit-Rearrange.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-Max-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-Min-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Max-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Min-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Scatter-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Scatter-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Shift-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Shift-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Single-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Slice-Masked-bop.template ! test/jdk/jdk/incubator/vector/templates/Unit-Slice-bop.template ! test/jdk/jdk/incubator/vector/templates/Unit-Slice-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Broadcast-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Broadcast-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Double-Broadcast-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Double-Broadcast-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unary-Masked-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unary-op-math.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unary-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unslice-Masked-bop.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unslice-bop.template ! test/jdk/jdk/incubator/vector/templates/Unit-Unslice-op.template ! test/jdk/jdk/incubator/vector/templates/Unit-With-Op.template ! test/jdk/jdk/incubator/vector/templates/Unit-header.template ! test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template Changeset: 32538b5b Author: Prasanta Sadhukhan Date: 2021-01-06 06:45:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/32538b5b 8193942: Regression automated test '/open/test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java' fails Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java Changeset: e3b9da14 Author: Xin Liu Committer: Aleksey Shipilev Date: 2021-01-06 09:51:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3b9da14 8259287: AbstractCompiler marks const in wrong position for is_c1/is_c2/is_jvmci Reviewed-by: thartmann, chagedorn, shade ! src/hotspot/share/compiler/abstractCompiler.hpp Changeset: 8a05d605 Author: Sergey Bylokhov Date: 2021-01-06 10:07:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8a05d605 8259042: Inconsistent use of general primitives loops Reviewed-by: prr ! src/java.desktop/share/classes/sun/java2d/loops/Blit.java ! src/java.desktop/share/classes/sun/java2d/loops/BlitBg.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphList.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListAA.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListLCD.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawLine.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawParallelogram.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawPath.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawPolygons.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawRect.java ! src/java.desktop/share/classes/sun/java2d/loops/FillParallelogram.java ! src/java.desktop/share/classes/sun/java2d/loops/FillPath.java ! src/java.desktop/share/classes/sun/java2d/loops/FillRect.java ! src/java.desktop/share/classes/sun/java2d/loops/FillSpans.java ! src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitive.java ! src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitiveMgr.java ! src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitiveProxy.java ! src/java.desktop/share/classes/sun/java2d/loops/MaskBlit.java ! src/java.desktop/share/classes/sun/java2d/loops/MaskFill.java ! src/java.desktop/share/classes/sun/java2d/loops/ScaledBlit.java ! src/java.desktop/share/classes/sun/java2d/loops/TransformBlit.java ! src/java.desktop/share/classes/sun/java2d/loops/TransformHelper.java Changeset: 7e01bc96 Author: Mat Carter Committer: Alan Bateman Date: 2021-01-06 10:39:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e01bc96 8255264: Support for identifying the full range of IPv4 localhost addresses on Windows Reviewed-by: alanb ! src/java.base/windows/native/libnet/net_util_md.h Changeset: c0540ffd Author: Daniel D. Daugherty Date: 2021-01-06 14:34:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c0540ffd 8231627: ThreadsListHandleInErrorHandlingTest.java fails in printing all threads Reviewed-by: eosterlund, coleenp, pchilanomate, sspitsyn ! src/hotspot/share/runtime/threadSMR.cpp ! test/hotspot/jtreg/runtime/ErrorHandling/NestedThreadsListHandleInErrorHandlingTest.java ! test/hotspot/jtreg/runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java Changeset: f6cb8c55 Author: Harold Seigel Date: 2021-01-06 15:11:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f6cb8c55 8258908: Remove JVM option CleanChunkPoolAsync Reviewed-by: coleenp ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/memory/arena.cpp ! src/hotspot/share/memory/arena.hpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/thread.cpp Changeset: 722f2361 Author: Lehua Ding Committer: Aleksey Shipilev Date: 2021-01-06 15:36:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/722f2361 8259231: Epsilon: improve performance under contention during virtual space expansion Reviewed-by: shade ! src/hotspot/share/gc/epsilon/epsilonHeap.cpp Changeset: 3be6e069 Author: Rajan Halade Date: 2021-01-06 16:20:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3be6e069 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days Reviewed-by: mullan ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: d20d2fa9 Author: Joe Darcy Date: 2021-01-06 16:26:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d20d2fa9 8258143: Update --release 16 symbol information for JDK 16 build 30 or later Reviewed-by: iris, erikj ! make/data/symbols/java.desktop-G.sym.txt Changeset: df721f0c Author: Xue-Lei Andrew Fan Date: 2021-01-06 16:57:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/df721f0c 8259291: Cleanup unnecessary local variables Reviewed-by: mullan ! src/java.base/share/classes/sun/security/ssl/Finished.java ! src/java.base/share/classes/sun/security/ssl/OutputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLExtension.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketOutputRecord.java ! src/java.base/share/classes/sun/security/ssl/ServerNameExtension.java ! src/java.base/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java Changeset: 940b0530 Author: Phil Race Date: 2021-01-06 17:34:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/940b0530 8259232: Bad JNI lookup during printing Reviewed-by: psadhukhan ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m ! test/jdk/java/awt/print/bug8023392/bug8023392.java Changeset: 80544e4d Author: Joe Darcy Date: 2021-01-06 18:05:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/80544e4d 8250564: Remove terminally deprecated constructor in GSSUtil 8250565: Remove terminally deprecated constructor in java.net.URLDecoder Reviewed-by: bpb, smarks, alanb, mullan ! src/java.base/share/classes/java/net/URLDecoder.java ! src/jdk.security.jgss/share/classes/com/sun/security/jgss/GSSUtil.java ! test/jdk/java/net/URLDecoder/B6463990.java Changeset: 28e1f4d9 Author: Yoshiki Sato Committer: Jonathan Gibbons Date: 2021-01-06 22:48:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/28e1f4d9 8247957: remove doclint support for HTML 4 8257204: Remove usage of -Xhtmlversion option from javac 8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option 8258460: Remove --doclint-format option from javac 8256312: Valid anchor 'id' value not allowed Reviewed-by: jjg, ihse ! make/common/JavaCompilation.gmk ! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlVersion.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties ! test/langtools/jdk/javadoc/doclet/testHtmlTableStyles/TestHtmlTableStyles.java ! test/langtools/tools/doclint/AccessibilityTest.java ! test/langtools/tools/doclint/AccessibilityTest.out - test/langtools/tools/doclint/AccessibilityTest5.java - test/langtools/tools/doclint/AccessibilityTest5.out ! test/langtools/tools/doclint/AnchorTest.java ! test/langtools/tools/doclint/AnchorTest.out ! test/langtools/tools/doclint/AnchorTest2.java ! test/langtools/tools/doclint/AnchorTest2.out ! test/langtools/tools/doclint/AnchorTest2a.java ! test/langtools/tools/doclint/EndTagsTest.java ! test/langtools/tools/doclint/HtmlAttrsTest.java ! test/langtools/tools/doclint/HtmlAttrsTest.out ! test/langtools/tools/doclint/HtmlTagsTest.java ! test/langtools/tools/doclint/HtmlTagsTest.out - test/langtools/tools/doclint/HtmlVersionTest.java ! test/langtools/tools/doclint/anchorTests/p/Test.java ! test/langtools/tools/doclint/anchorTests/p/Test.out ! test/langtools/tools/doclint/anchorTests/p/package-info.java ! test/langtools/tools/doclint/anchorTests/p/package-info.javac.out ! test/langtools/tools/doclint/anchorTests/p/package-info.out ! test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.java + test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.out - test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTestHtml4.out - test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTestHtml5.out + test/langtools/tools/doclint/html/InlineTagTest.out ! test/langtools/tools/doclint/html/InlineTagsTest.java ! test/langtools/tools/doclint/html/OtherTagsTest.java ! test/langtools/tools/doclint/html/OtherTagsTest.out + test/langtools/tools/doclint/html/TableTagTest.out ! test/langtools/tools/doclint/html/TableTagsTest.java ! test/langtools/tools/doclint/html/TagNotAllowed.java ! test/langtools/tools/doclint/html/TagNotAllowed.out ! test/langtools/tools/doclint/html/TextNotAllowed.java ! test/langtools/tools/doclint/html/TextNotAllowed.out ! test/langtools/tools/doclint/tidy/AnchorAlreadyDefined.java ! test/langtools/tools/doclint/tidy/AnchorAlreadyDefined.out ! test/langtools/tools/doclint/tidy/BadEnd.java ! test/langtools/tools/doclint/tidy/BadEnd.out ! test/langtools/tools/doclint/tidy/InvalidName.java ! test/langtools/tools/doclint/tidy/InvalidName.out ! test/langtools/tools/doclint/tidy/TextNotAllowed.java ! test/langtools/tools/doclint/tidy/TextNotAllowed.out ! test/langtools/tools/doclint/tidy/TrimmingEmptyTag.java ! test/langtools/tools/doclint/tidy/TrimmingEmptyTag.out ! test/langtools/tools/javac/doclint/DocLintFormatTest.java Changeset: 67c22114 Author: Yasumasa Suenaga Date: 2021-01-06 23:59:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/67c22114 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale Reviewed-by: erikj, cjplummer, iklam ! make/modules/jdk.hotspot.agent/Lib.gmk ! src/jdk.hotspot.agent/share/native/libsaproc/sadis.c Changeset: 227f99d3 Author: Prasanta Sadhukhan Date: 2021-01-07 03:57:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/227f99d3 8233555: [TESTBUG] JRadioButton tests failing on MacoS Reviewed-by: serb ! test/jdk/ProblemList.txt Changeset: 81c06242 Author: Carter Kozak Committer: Erik Gahlin Date: 2021-01-07 06:11:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81c06242 8259354: Fix race condition in AbstractEventStream.nextThreadName Reviewed-by: egahlin ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java Changeset: 0e6de4eb Author: Tobias Hartmann Date: 2021-01-07 12:15:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0e6de4eb 8259339: AllocateUninitializedArray C2 intrinsic fails with void.class input Reviewed-by: kvn, chagedorn ! src/hotspot/share/opto/library_call.cpp ! test/hotspot/jtreg/compiler/intrinsics/unsafe/AllocateUninitializedArray.java Changeset: 1c33847b Author: Coleen Phillimore Date: 2021-01-07 12:35:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1c33847b 8259067: bootclasspath append takes out object lock Reviewed-by: lfoltan, sspitsyn, iklam, dholmes ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/classfile/classLoader.inline.hpp ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: 3f9f86f0 Author: Matthias Baesken Date: 2021-01-07 12:39:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3f9f86f0 8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006 Reviewed-by: clanger, mdoerr ! make/modules/java.desktop/lib/Awt2dLibraries.gmk Changeset: f91f92dc Author: Harold Seigel Date: 2021-01-07 13:18:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f91f92dc 8259317: Remove JVM option BreakAtWarning Reviewed-by: lfoltan, coleenp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/utilities/debug.cpp Changeset: 8530ef0e Author: Coleen Phillimore Date: 2021-01-07 17:13:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8530ef0e 8259375: JvmtiExport::jni_Get/SetField_probe calls do not need ResetNoHandleMark Reviewed-by: lfoltan, dcubed ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvmtiExport.cpp Changeset: 2e99e28f Author: Sergey Bylokhov Date: 2021-01-07 17:49:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2e99e28f 8213126: java/awt/Window/MainKeyWindow/TestMainKeyWindow.java time-out on mac10.13 Reviewed-by: psadhukhan ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java Changeset: 4ce83f2a Author: Rajan Halade Date: 2021-01-07 18:47:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ce83f2a 8039278: console.sh failed Automatically with exit code 1 Reviewed-by: xuelei, weijun ! test/jdk/TEST.groups - test/jdk/sun/security/tools/keytool/console.sh Changeset: d8ad6301 Author: Roberto Casta?eda Lozano Committer: Vladimir Kozlov Date: 2021-01-07 18:57:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d8ad6301 8258772: Some runtime/cds tests fail with +LogCompilation or +StressX Emit warning about TraceDependencies results in ClassHierarchyWalker::count_find_witness_calls() only if TraceDependencies is actually enabled. Use standard warning() function instead of ad hoc printing. Remove warning about using Stress(LCM|GCM|IGVN) without LogCompilation in Compile::Compile(), and add the information to the description of the StressSeed option instead. These changes prevent false test failures when using LogCompilation or Stress(LCM|GCM|IGVN). Reviewed-by: chagedorn, kvn, thartmann ! src/hotspot/share/code/dependencies.cpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/compile.cpp Changeset: bc565414 Author: Roberto Casta?eda Lozano Committer: Vladimir Kozlov Date: 2021-01-07 20:43:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bc565414 8256535: C2: randomize CCP processing order for stress testing Add 'StressCCP' option to randomize the selection of the node to be examined in each CCP iteration. Reviewed-by: chagedorn, kvn, thartmann ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/phaseX.cpp - test/hotspot/jtreg/compiler/arguments/TestStressIGVNOptions.java + test/hotspot/jtreg/compiler/arguments/TestStressOptions.java ! test/hotspot/jtreg/compiler/debug/TestGenerateStressSeed.java - test/hotspot/jtreg/compiler/debug/TestStressIGVN.java + test/hotspot/jtreg/compiler/debug/TestStressIGVNAndCCP.java Changeset: 2659bc44 Author: Brian Burkhalter Date: 2021-01-07 20:57:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2659bc44 8259274: Increase timeout duration in sun/nio/ch/TestMaxCachedBufferSize.java Reviewed-by: lancea ! test/jdk/sun/nio/ch/TestMaxCachedBufferSize.java Changeset: 73f54153 Author: Chris Hegarty Date: 2021-01-02 19:29:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/73f54153 8258955: (bf) slice(int, int) on view buffers fails to adjust index according to primitive size Reviewed-by: alanb ! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template ! test/jdk/java/nio/Buffer/ByteBufferViews.java Changeset: 216c2ec0 Author: Jie Fu Date: 2021-01-04 23:41:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/216c2ec0 8258703: Incorrect 512-bit vector registers restore on x86_32 Reviewed-by: kvn, sviswanathan ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp Changeset: 4ffbe841 Author: Jan Lahoda Date: 2021-01-05 11:40:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ffbe841 8256266: Binding variables don't correctly support declaration annotations and the final modifier Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/langtools/tools/javac/patterns/Annotations.java ! test/langtools/tools/javac/patterns/BindingsTest1.java ! test/langtools/tools/javac/patterns/BindingsTest2.java ! test/langtools/tools/javac/patterns/BindingsTest2.out + test/langtools/tools/javac/patterns/NoModifiersOnBinding.java + test/langtools/tools/javac/patterns/NoModifiersOnBinding.out Changeset: 6775113c Author: Roland Westrelin Date: 2021-01-05 13:06:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6775113c 8258393: Shenandoah: "graph should be schedulable" assert failure Reviewed-by: rkennke, thartmann ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/opto/loopnode.cpp + test/hotspot/jtreg/gc/shenandoah/compiler/TestBadRawMemoryAfterCall.java Changeset: bbc2e951 Author: Erik Gahlin Date: 2021-01-05 13:39:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bbc2e951 8257906: JFR: RecordingStream leaks memory Reviewed-by: mgronlun Backport-of: 3c6648501589bf36945340cb1e82c833ebd7485d ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ChunkParser.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventDirectoryStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventFileStream.java Changeset: b7940aa1 Author: Maurizio Cimadamore Date: 2021-01-05 16:15:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b7940aa1 8259027: NullPointerException in makeMappedSegment due to NULL Unmapper when length of segment is 0 Reviewed-by: chegar, uschindler ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MappedMemorySegmentImpl.java ! test/jdk/java/foreign/TestByteBuffer.java Changeset: 50bf4330 Author: Sandhya Viswanathan Date: 2021-01-05 17:42:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/50bf4330 8259213: Vector conversion with part > 0 is not getting intrinsic implementation Reviewed-by: psandoz ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractShuffle.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java Changeset: d5293067 Author: Vicente Romero Date: 2021-01-05 21:35:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d5293067 8213032: program fails with LambdaConversionException at execution time Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/langtools/tools/javac/lambda/methodReferenceExecution/MethodReferenceIntersection4.java Changeset: 554e60c4 Author: Wang Huang Committer: Fei Yang Date: 2021-01-06 01:49:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/554e60c4 8258989: JVM is failed to inline in jdk.internal.vm.vector.VectorSupport::convert Co-authored-by: He Xuejin Reviewed-by: vlivanov, thartmann ! src/hotspot/share/opto/vectorIntrinsics.cpp Changeset: 80110dac Author: Prasanta Sadhukhan Date: 2021-01-06 06:36:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/80110dac 8259007: This test printed a blank page Reviewed-by: prr, serb ! src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java ! src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp - test/jdk/java/awt/print/PathPrecisionScaleFactor/PathPrecisionScaleFactorTest.java Changeset: e66187d8 Author: Maurizio Cimadamore Date: 2021-01-06 12:18:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e66187d8 8259032: MappedMemorySegmentImpl#makeMappedSegment() ignores Unmapper#pagePosition Co-authored-by: Uwe Schindler Reviewed-by: alanb ! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java ! test/jdk/java/foreign/TestByteBuffer.java Changeset: ad456787 Author: Aleksey Shipilev Date: 2021-01-06 13:27:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ad456787 8258558: Revert changes for JDK-8252505 and related issues Reviewed-by: kvn ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/compiler/compilerOracle.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/memnode.hpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/regmask.cpp ! src/hotspot/share/opto/regmask.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/TEST.groups - test/hotspot/jtreg/compiler/blackhole/BlackholeDiagnosticUnlockTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeInstanceReturnTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeInstanceTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeNonVoidWarningTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeNullCheckTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeStaticReturnTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeStaticTest.java - test/hotspot/jtreg/compiler/blackhole/BlackholeTarget.java Changeset: d25a1bed Author: Rafael Winterhalter Committer: Joel Borggr?n-Franck Date: 2021-01-06 15:46:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d25a1bed 8259224: (ann) getAnnotatedReceiverType should not parameterize owner(s) of statically nested classes Reviewed-by: jfranck ! src/java.base/share/classes/java/lang/reflect/Executable.java + test/jdk/java/lang/annotation/typeAnnotations/TestReceiverTypeOwnerType.java Changeset: 4a5786b5 Author: Naoto Sato Date: 2021-01-06 16:30:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4a5786b5 8259075: Update the copyright notice in the files generated by CLDR Converter tool Reviewed-by: joehw ! make/jdk/src/classes/build/tools/cldrconverter/CopyrightHeaders.java Changeset: f1bc4e05 Author: Rajan Halade Date: 2021-01-06 16:39:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f1bc4e05 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days Backport-of: 3be6e06958c4304cafee707a29d06d6b2cc5b76b ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: eef43be7 Author: Jonathan Gibbons Date: 2021-01-06 18:52:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eef43be7 8251200: False positive messages about missing comments for serialization Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/SerializedFormBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java + test/langtools/jdk/javadoc/doclet/testSerialMissing/TestSerialMissing.java Changeset: 4f914e21 Author: Jonathan Gibbons Date: 2021-01-06 19:26:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4f914e21 8249633: doclint reports missing javadoc for JavaFX property methods that have a property description Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MemberSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java Changeset: 555641ed Author: Jesper Wilhelmsson Date: 2021-01-07 21:17:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/555641ed Merge ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/hotspot/jtreg/TEST.groups ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/hotspot/jtreg/TEST.groups Changeset: b996cccf Author: Coleen Phillimore Date: 2021-01-07 23:04:11 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b996cccf 8259373: c1 and jvmci runtime code use ResetNoHandleMark incorrectly Reviewed-by: kvn ! src/hotspot/share/c1/c1_Runtime1.cpp ! src/hotspot/share/code/compiledMethod.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp Changeset: 4a478b8a Author: Erik Gahlin Date: 2021-01-07 12:21:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4a478b8a 8250903: jdk/jfr/javaagent/TestLoadedAgent.java fails with Mismatch in TestEvent count Reviewed-by: mgronlun ! test/jdk/jdk/jfr/javaagent/EventEmitterAgent.java Changeset: 484e23b9 Author: Erik Joelsson Date: 2021-01-07 14:57:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/484e23b9 8258657: Doc build is broken by use of new language features Reviewed-by: tbell, iris ! make/Docs.gmk ! make/autoconf/boot-jdk.m4 ! make/autoconf/configure.ac ! make/autoconf/spec.gmk.in ! make/conf/jib-profiles.js Changeset: c1fb5216 Author: Christian Hagedorn Date: 2021-01-07 15:02:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c1fb5216 8259227: C2 crashes with SIGFPE due to a division that floats above its zero check Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/phaseX.hpp + test/hotspot/jtreg/compiler/loopopts/TestDivZeroDominatedBy.java ! test/hotspot/jtreg/compiler/loopopts/TestDivZeroWithSplitIf.java Changeset: acdd90b6 Author: Vicente Romero Date: 2021-01-07 16:38:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/acdd90b6 8258972: unexpected compilation error with generic sealed interface Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! test/langtools/tools/javac/sealed/SealedCompilationTests.java Changeset: 1973fbee Author: Rajan Halade Date: 2021-01-07 19:21:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1973fbee 8039278: console.sh failed Automatically with exit code 1 Backport-of: 4ce83f2a3a6c5fe11c298bed557c341e286e068a ! test/jdk/TEST.groups - test/jdk/sun/security/tools/keytool/console.sh Changeset: 677802d2 Author: Christoph Langer Date: 2021-01-07 22:51:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/677802d2 8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006 Backport-of: 3f9f86f0d3f918b9955ba6ba73c9c58ae8fcf7cb ! make/modules/java.desktop/lib/Awt2dLibraries.gmk Changeset: 56a354eb Author: Jesper Wilhelmsson Date: 2021-01-07 23:51:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/56a354eb Merge ! make/Docs.gmk ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/phaseX.cpp ! make/Docs.gmk ! src/hotspot/share/opto/ifnode.cpp ! src/hotspot/share/opto/phaseX.cpp Changeset: 712014c5 Author: David Holmes Date: 2021-01-08 04:11:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/712014c5 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 Reviewed-by: dcubed, hseigel ! src/hotspot/share/prims/jniCheck.cpp + test/hotspot/jtreg/runtime/jni/checked/TestCheckedReleaseArrayElements.java + test/hotspot/jtreg/runtime/jni/checked/TestCheckedReleaseCriticalArray.java + test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseArrayElements.c + test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c Changeset: fc1d2a1e Author: Claes Redestad Date: 2021-01-08 09:20:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fc1d2a1e 8259065: Optimize MessageDigest.getInstance Reviewed-by: valeriep ! src/java.base/share/classes/java/security/MessageDigest.java ! src/java.base/share/classes/java/security/Provider.java ! src/java.base/share/classes/sun/security/jca/ProviderConfig.java + test/micro/org/openjdk/bench/java/security/GetMessageDigest.java Changeset: b549cbd3 Author: Thomas Schatzl Date: 2021-01-08 10:52:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b549cbd3 8258481: gc.g1.plab.TestPLABPromotion fails on Linux x86 Reviewed-by: sjohanss, kbarrett ! test/hotspot/jtreg/gc/g1/plab/TestPLABPromotion.java Changeset: 04b8ca02 Author: duke Date: 2021-01-08 11:00:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/04b8ca02 Automatic merge of jdk:master into master Changeset: 017bf202 Author: duke Date: 2021-01-08 11:00:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/017bf202 Automatic merge of master into foreign-memaccess+abi Changeset: 88c025a4 Author: duke Date: 2021-01-08 11:01:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/88c025a4 Automatic merge of foreign-memaccess+abi into foreign-jextract ! make/autoconf/spec.gmk.in ! make/conf/jib-profiles.js ! test/jdk/TEST.groups ! make/autoconf/spec.gmk.in ! make/conf/jib-profiles.js ! test/jdk/TEST.groups From maurizio.cimadamore at oracle.com Fri Jan 8 11:18:01 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 8 Jan 2021 11:18:01 +0000 Subject: [foreign-memaccess] musing on the memory access API In-Reply-To: References: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> <083001d6e2c9$1aae9040$500bb0c0$@apache.org> <1a830d5e-233c-e54e-6b3c-d679c7297410@oracle.com> <08af01d6e2f4$cdae0600$690a1200$@apache.org> <3b0c2cd5-e49b-24fe-2fe6-fc57c5dd3693@oracle.com> Message-ID: Hi Lee > This relates to an issue that I'm concerned about, but perhaps because > I don't fully understand why? "memory access var handles *need* exact > type > information to be *fast*" or is this just a convention? With VarHandle, there are a number of things you have to do for them to be fast (by fast I mean for them to "inline" like other methods do): 1) the VarHandle should be stored in a final static variable (e.g. a VM constant) 2) the VarHandle invocation should respect the types with which the VH was created In practical terms, when you do a VH::get, it's like if the VM spinned a new method just for that on the fly (of course it's more complex that that); the spinned method has a signature. If the VM has guarantees that the parameters you are calling this method with are the same as those of the spinned method, then a bunch of checks are removed (the dreaded asType() adaptations), and you are in performance nirvana :-) > ? At the CPU level, it > ingests chunks of bytes and then extracts whatever type specified by the > assembly instruction whether it be a 32-bit integer (signed or unsigned), > short, long, float, double or whatever.? I would like the ability to > create a > MemorySegment allocated as bytes, load it with longs (for speed) and > then read it with a MemoryLayout that describes some complex multi-type > data structure (because I know what the bytes represent!).? In other > words, > MemorySegment should act like a blob of bytes and reading and writing > from it should behave like a /C union/?overlayed with a /C struct./ > I realize this violates the Java principles of strict typing, but if > we really > are interested in speed, we need this ability (even if you force us to > declare it as /unsafe/).? I'm sure you have thought > about this, but I'm not sure, yet, if this is a reality in the code. > > This already appears in Java in a few very limited cases. E.g., I can > view a > /double/ as raw bits, perform operations on the raw bits as a long, and > convert it back to a double.? We have some math routines that take > advantage of this.? What is unfortunate is the lack of being able to > convert a double (or long, etc) into bytes and back at an intrinsic level, > which should be very fast. > > I looked at your spliterator and it is not clear how I would use it to > view > the same blob of bytes with two different layouts.? I must be missing > something :(. What you describe already flows naturally from the design of the API - since a memory segment has no concept of type/endianness, it is up to the client doing the dereference to use the right type primitives/endianness primitives. Consider this: MemorySegment ms = MemorySegment.allocateNative(8); byte b = MemoryAccess.getByteAtOffset(ms, 0); short s = MemoryAccess.getShortAtOffset(ms, 0); float f = MemoryAccess.getFloatAtOffset(ms, 0, ByteOrder.BIG_ENDIAN); ... In other words, when you dereference a segment, the type of var handle being used determines (a) which carrier you should use for dereferencing and (b) which endianness you want. To simplify things (and avoid mistakes), the API comes with the concept of "memory layout" - that is, you can define, programmatically, the layout of the memory you want to dereference - e.g. var layout = MemoryLayout.ofStruct( ???? MemoryLayouts.JAVA_INT.withName("a"), ???? MemoryLayout.ofPaddingBits(16), ???? MemoryLayouts.JAVA_SHORT.withName("b")); And then get a VarHandle pointing at "b": VarHandle bHandle = layout.varHandle(short.class, PathElement.groupElement("b")); This will create a var handle with right offset (and dynamic stride, if the access element is inside an array) and correct endianness/type. This avoids the need for typical offset computation and/or remembering which endianness should be used to access a given field. In other words, access is made more declarative - you just create a bunch of VarHandles, one for each layout element you wanna access. > > * I believe/hope that the main gripes you had with the byte buffer API > (which seem to be endianness related) are gone with the memory access > API. There we made the decision of leaving endianness outside of the > MemorySegment - e.g. endianness is a property of the VarHandle > doing the > access, not a property of the segment per se. I believe this decision > paid off (e.g. our segments are completely orthogonal w.r.t. layout > decisions), and avoids a lot of confusion as to "what's the > default" etc. > > > I have a number of gripes about the ByteBuffer. > > 1. The most serious issue is the handling of endianness. > First, the default is BigEndian, which today makes no sense as nearly all > CPUs are LE.? And, some byte compression algorithms only work with a given > endianness.? Perhaps I could live with this, but if I am interested in > performance > I would like to match my CPU, so I dutifully set endianness to LE. > > ByteBuffer bb = ByteBuffer.allocate(16); > > bb.order(ByteOrder.LITTLE_ENDIAN); > > Later, suppose I need to do any one of the following common operations: > slice(), duplicate() or?asReadOnlyBuffer(). > > *? ? The ByteBuffer silently reverts back to BigEndian!* > > So the engineer must magically know to always reset the desired > endianness after > every one of those common operations.? And, by the way, this is not > documented > in the Javadocs anywhere I could find. > > This is the cause of many difficult to find bugs!? In fact we have > cases where > in large segments of data that have been stored into historical > archives, the > same segment will have different parts of it encoded with LE and other > parts > in BE!? This is a maintenance nightmare. > > This bug is easy to find in the ByteBuffer source code. The calls to > slice(), > duplicate() and asReadOnlyBuffer() return a new ByteBuffer without > copying > over the current state of Endianness. I found this issue annoying too - and encountered many times when writing tests against the memory access API and comparing results with ByteBuffer. As for the BIG_ENDIAN default, I guess any default is gonna be doomed one way or another here (although, yes, LITTLE_ENDIAN is way more common) - but I think having endianness explicit in the dereference is even better :-) (our static accessor assumes native endianness if no endianness argument is specified - which can be a source of subtle issues, but we tried to strike a balance between generality and usability). > > This is why in our Memory Package implementation we made endianness > immutable, once it is chosen, and all equivalent calls to slice(), > duplicate(), > etc() retain the state of endianness. > > 2. ByteBuffer array handling is clumsy.? It was designed strictly from > an IO > streaming use-case with no alternative for absolute addressing like the > single primitive methods.? The BB API is > > ByteBuffer put([] src, int srcOffset, int length); > > > Our use case has the need to put or get an array at an absolute offset > from the beginning of the buffer. For example, > > ByteBuffer put(long bufferOffset, [] src, int srcOffset, int > length); > > > Attempting to replicate this method with the current BB API requires: > > * Saving the current setting of position and limit (if used) > * Setting the position, computing and perhaps checking the limit > * executing the put() above, > * restoring position and limit. > > This is a real PITA, and could be so easily solved with a few easy to add > methods. I think new absolute bulk methods are now part of the BB API - I can defo see a put method which takes an initial offset: https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/nio/ByteBuffer.html#put(int,byte%5B%5D,int,int) > 3.? There is no method that allows a high-performance (system level) > copy of a region of one ByteBuffer to another ByteBuffer without going > through the heap.? This is so easy to do with Unsafe, I hope you have > the ability to do this with MemorySegments.? What we need is something > like > > static void copy(MemorySegment src, long srcOffsetBytes, > > MemorySegment dst, long dstOffsetBytes, long lengthBytes) > We have something like that in the MemorySegment API - namely MemorySegment::copyFrom. You take two segments, slice them as required, then call copyFrom to (bulk) copy contents of one slice into the other slice. No intermediate copy required. That said, I believe here the BB API also caught up recently: https://github.com/openjdk/jdk/commit/a50fdd54 You can see a new method to copy a bytebuffer into another with certain region boundaries. > > Since there are no java arrays involved, the length could be a long. > Under the covers, you could easily go parallel with multiple threads if > the size is big. Long vs. int is the real problem here which cannot be addressed by the BB API. I believe the other issues you list under (3) have more to do with the Java 8 version of the BB API. > > 4. The handling of the positional values is also clumsy IMHO > where,?for example, > the Mark is silently invalidated.? ?Agreed this is documented, but > remembering > the rules where the?positionals are suddenly silently changed can be > difficult > unless you do it all the time.? I designed a different positional > system > ?(see > BaseBuffer) where there is no need to invalidate them. My personal feeling on this is that the machinery behind ByteBuffer position/limit/mark is specifically designed for simplifying IO operations, encoders and such. Carrying them around for pure off-heap usage is always going to be problematic, as the users will have to remember which API to use (otherwise a client might affect remaining clients) - it also makes the implementation more stateful, and less likely to optimize well (on paper, because from what we've seen, in reality performance of BB often matches that of unsafe access - especially after Java 14). The MemorySegment API here adopts a "less is better" approach, as there's no relative positioning in that API - the only "mutable" bit of state in a memory segment is the bit that tells you whether the segment is alive or not - everything else is a constant. Maurizio > > I hope you find this of interest. > > Cheers, > > Lee. > > From maurizio.cimadamore at oracle.com Fri Jan 8 11:22:53 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 8 Jan 2021 11:22:53 +0000 Subject: [foreign-memaccess] musing on the memory access API In-Reply-To: References: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> <083001d6e2c9$1aae9040$500bb0c0$@apache.org> <1a830d5e-233c-e54e-6b3c-d679c7297410@oracle.com> <08af01d6e2f4$cdae0600$690a1200$@apache.org> <3b0c2cd5-e49b-24fe-2fe6-fc57c5dd3693@oracle.com> Message-ID: On 08/01/2021 00:56, leerho wrote: > Maurizio, > Is the strategy for Panama to completely eliminate the need for > ByteBuffer (except for backward integration)? > If so, this would be great! This means all of the problems I mention > above could be easily solved! > > Nonetheless,?I thought I read (or heard) in one of your tutorials that > you felt that the APIs for reading and writing primitives into some > backing blob of bytes (MemorySegment) was a solved problem, thus > the?user would still be using BB for that purpose. I don't think Panama wants to "eliminate" ByteBuffer - there are things that ByteBuffer do well, and we're not going to replace BB in those areas (e.g. charset encoder/decoders, to name one example). The MemorySegment API is a more focused API, which aims at catering the "pure" offheap usages - with a hint to native interop (in fact, MemorySegment is also the API used by the ForeignLinker to model foreign structs). If you fall in this latter categories, then you will be at home with MemorySegment (we hope!) - if, on the other hand, you are more in a IO-driven, producer/consumer use case, I don't think MemorySegment is a great fit - and it might be better to stick with ByteBuffer - and perhaps turn them into segments (which is possible with MemorySegment::ofBuffer(ByteBuffer)) if you need the more powerful dereference mechanism. Hope this helps. Maurizio > > Cheers, > > Lee. > > On Thu, Jan 7, 2021 at 2:36 PM leerho > wrote: > > Maurizio, Jorn, > > Thank you very much for your thoughtful comments and observations! > > * At the beginning, the doc claims protection from use after > free even > in concurrent use - looking at the code that doesn't seem to > be the case > though? E.g. it's true that updates to the "valid" bit of the > memory > state are atomic, but that doesn't rule out the possibility of > multiple > threads seeing a "true" value, then being interleaved with a > memory > released, which would ultimately result in access free? I the > Java 16 > iteration of the API we address this problem too, but at a > much lower > level (we needed some VM/GC black magic to pull this off). > > > You are absolutely right about the multi-threading issue!? I wrote > this a couple > years ago and on my re-read I caught that as well! Our library is > strictly > single-threaded, which we mention in other places in the > documentation. > I need to correct that statement.? Nonetheless, your solving this > problem > at a much lower level is precisely what I would hope you would do! And > at the same time you offer much stronger multithreading guarantees! > > * The main differences between the memory access API and your > API seem > to be in how dereference is done - you opted for virtual > methods, while > we go all in on var handles (and then we provide a bunch of static > accessors on the side). I think the two are similar, although > I think > I'm happy where we landed with our API, since using the pre-baked > statics is not any harder than using an instance method, but > in exchange > we get a lot of capabilities of out the var handle API (such > as atomic > access and adaptation). This decision has repercussions on the > API, of > course: the fact that we use MemorySegment as a VarHandle > coordinate > means we cannot get too crazy with hierarchies on the > MemorySegment > front - in fact, when we tried to do that (at some point we had > MappedMemorySegment <: MemorySegment) we ran into performance > issues, as > memory access var handle need exact type information to be fast. > > > Two comments. > 1. I chose virtual methods because as of JDK8, that was the only > tool in the toolbox. > The main advantage of virtual methods is that I can create an API > hierarchy > (driven by the needs of the application) that effectively > collapses down to one > class at runtime (as long as it is single inheritance). > I'm not yet sure how I would do it differently with the > MemoryAccess API. > > ...we ran into performance issues, as > memory access var handles need exact type information to be fast. > > > This relates to an issue that I'm concerned about, but perhaps because > I don't fully understand why? "memory access var handles *need* > exact type > information to be *fast*" or is this just a convention?? At the > CPU level, it > ingests chunks of bytes and then extracts whatever type specified > by the > assembly instruction whether it be a 32-bit integer (signed or > unsigned), > short, long, float, double or whatever.? I would like the ability > to create a > MemorySegment allocated as bytes, load it with longs (for speed) and > then read it with a MemoryLayout that describes some complex > multi-type > data structure (because I know what the bytes represent!).? In > other words, > MemorySegment should act like a blob of bytes and reading and writing > from it should behave like a /C union/?overlayed with a /C struct./ > I realize this violates the Java principles of strict typing, but > if we really > are interested in speed, we need this ability (even if you force us to > declare it as /unsafe/).? I'm sure you have thought > about this, but I'm not sure, yet, if this is a reality in the code. > > This already appears in Java in a few very limited cases.? E.g., I > can view a > /double/ as raw bits, perform operations on the raw bits as a > long, and > convert it back to a double.? We have some math routines that take > advantage of this.? What is unfortunate is the lack of being able to > convert a double (or long, etc) into bytes and back at an > intrinsic level, > which should be very fast. > > I looked at your spliterator and it is not clear how I would use > it to view > the same blob of bytes with two different layouts. I must be missing > something :(. > > * I believe/hope that the main gripes you had with the byte > buffer API > (which seem to be endianness related) are gone with the memory > access > API. There we made the decision of leaving endianness outside > of the > MemorySegment - e.g. endianness is a property of the VarHandle > doing the > access, not a property of the segment per se. I believe this > decision > paid off (e.g. our segments are completely orthogonal w.r.t. > layout > decisions), and avoids a lot of confusion as to "what's the > default" etc. > > > I have a number of gripes about the ByteBuffer. > > 1. The most serious issue is the handling of endianness. > First, the default is BigEndian, which today makes no sense as > nearly all > CPUs are LE.? And, some byte compression algorithms only work with > a given > endianness.? Perhaps I could live with this, but if I am > interested in performance > I would like to match my CPU, so I dutifully set endianness to LE. > > ByteBuffer bb = ByteBuffer.allocate(16); > > bb.order(ByteOrder.LITTLE_ENDIAN); > > Later, suppose I need to do any one of the following common > operations: > slice(), duplicate() or?asReadOnlyBuffer(). > > *? ? The ByteBuffer silently reverts back to BigEndian!* > > So the engineer must magically know to always reset the desired > endianness after > every one of those common operations.? And, by the way, this is > not documented > in the Javadocs anywhere I could find. > > This is the cause of many difficult to find bugs!? In fact we have > cases where > in large segments of data that have been stored into historical > archives, the > same segment will have different parts of it encoded with LE and > other parts > in BE!? This is a maintenance nightmare. > > This bug is easy to find in the ByteBuffer source code.? The calls > to slice(), > duplicate() and asReadOnlyBuffer() return a new ByteBuffer without > copying > over the current state of Endianness. > > This is why in our Memory Package implementation we made endianness > immutable, once it is chosen, and all equivalent calls to slice(), > duplicate(), > etc() retain the state of endianness. > > 2. ByteBuffer array handling is clumsy.? It was designed strictly > from an IO > streaming use-case with no alternative for absolute addressing > like the > single primitive methods.? The BB API is > > ByteBuffer put([] src, int srcOffset, int length); > > > Our use case has the need to put or get an array at an absolute > offset > from the beginning of the buffer. For example, > > ByteBuffer put(long bufferOffset, [] src, int srcOffset, > int length); > > > Attempting to replicate this method with the current BB API requires: > > * Saving the current setting of position and limit (if used) > * Setting the position, computing and perhaps checking the limit > * executing the put() above, > * restoring position and limit. > > This is a real PITA, and could be so easily solved with a few easy > to add > methods. > > 3.? There is no method that allows a high-performance (system level) > copy of a region of one ByteBuffer to another ByteBuffer without going > through the heap.? This is so easy to do with Unsafe, I hope you have > the ability to do this with MemorySegments.? What we need is > something like > > static void copy(MemorySegment src, long srcOffsetBytes, > > MemorySegment dst, long dstOffsetBytes, long lengthBytes) > > > Since there are no java arrays involved, the length could be a long. > Under the covers, you could easily go parallel with multiple > threads if > the size is big. > > 4. The handling of the positional values is also clumsy IMHO > where,?for example, > the Mark is silently invalidated.? ?Agreed this is documented, but > remembering > the rules where the?positionals are suddenly silently changed can > be difficult > unless you do it all the time.? I designed a different positional > system > ?(see > BaseBuffer) where there is no need to invalidate them. > > I hope you find this of interest. > > Cheers, > > Lee. > > From sundar at openjdk.java.net Fri Jan 8 11:26:30 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Fri, 8 Jan 2021 11:26:30 GMT Subject: [foreign-jextract] RFR: 8259473: jextract generated code should throw exception for unfound native symbols from calls, variable access, set immediately Message-ID: NPE with proper error message is thrown immediately (on call, variable access/set) ------------- Commit messages: - 8259473: jextract generated code should throw exception for unfound native symbols from calls, variable access, set immediately Changes: https://git.openjdk.java.net/panama-foreign/pull/432/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=432&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259473 Stats: 189 lines in 4 files changed: 181 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/432.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/432/head:pull/432 PR: https://git.openjdk.java.net/panama-foreign/pull/432 From mcimadamore at openjdk.java.net Fri Jan 8 11:37:10 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 8 Jan 2021 11:37:10 GMT Subject: [foreign-jextract] RFR: 8259473: jextract generated code should throw exception for unfound native symbols from calls, variable access, set immediately In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 11:21:12 GMT, Athijegannathan Sundararajan wrote: > NPE with proper error message is thrown immediately (on call, variable access/set) src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/HeaderFileBuilder.java line 110: > 108: builder.append("Objects.requireNonNull("); > 109: builder.append(methodHandleGetCallString(javaName, nativeName, mtype, desc, varargs)); > 110: builder.append(", \"no such native function: "); Nice! I wonder if here we should use "no such" vs. some other form, e.g. "unresolved". I also wonder if NPE is the right exception here - maybe a NoSuchMethodException, or LinkageError might be better? ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/432 From sundar at openjdk.java.net Fri Jan 8 12:27:30 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Fri, 8 Jan 2021 12:27:30 GMT Subject: [foreign-jextract] RFR: 8259473: jextract generated code should throw exception for unfound native symbols from calls, variable access, set immediately [v2] In-Reply-To: References: Message-ID: > NPE with proper error message is thrown immediately (on call, variable access/set) Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: Using UnsatisfiedLinkError and "unresolved symbol: " as error message. Refactored static methods in header file class to check linkage outside try block around invokeExact - so that UnsatisfiedLinkError, if needed, is thrown. ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/432/files - new: https://git.openjdk.java.net/panama-foreign/pull/432/files/bc8b043a..c9f5c213 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=432&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=432&range=00-01 Stats: 41 lines in 4 files changed: 13 ins; 4 del; 24 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/432.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/432/head:pull/432 PR: https://git.openjdk.java.net/panama-foreign/pull/432 From mcimadamore at openjdk.java.net Fri Jan 8 12:39:08 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 8 Jan 2021 12:39:08 GMT Subject: [foreign-jextract] RFR: 8259473: jextract generated code should throw exception for unfound native symbols from calls, variable access, set immediately [v2] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 12:27:30 GMT, Athijegannathan Sundararajan wrote: >> NPE with proper error message is thrown immediately (on call, variable access/set) > > Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: > > Using UnsatisfiedLinkError and "unresolved symbol: " as error message. > Refactored static methods in header file class to check linkage outside try > block around invokeExact - so that UnsatisfiedLinkError, if needed, is thrown. Looks good ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/432 From jvernee at openjdk.java.net Fri Jan 8 12:51:00 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 8 Jan 2021 12:51:00 GMT Subject: [foreign-jextract] RFR: 8259473: jextract generated code should throw exception for unfound native symbols from calls, variable access, set immediately [v2] In-Reply-To: References: Message-ID: On Fri, 8 Jan 2021 12:27:30 GMT, Athijegannathan Sundararajan wrote: >> NPE with proper error message is thrown immediately (on call, variable access/set) > > Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision: > > Using UnsatisfiedLinkError and "unresolved symbol: " as error message. > Refactored static methods in header file class to check linkage outside try > block around invokeExact - so that UnsatisfiedLinkError, if needed, is thrown. Marked as reviewed by jvernee (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/432 From sundar at openjdk.java.net Fri Jan 8 13:00:14 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Fri, 8 Jan 2021 13:00:14 GMT Subject: [foreign-jextract] Integrated: 8259473: jextract generated code should throw exception for unfound native symbols from calls, variable access, set immediately In-Reply-To: References: Message-ID: <9V0HK8i3gkID6elahJqk80qOazNGQjZruYaqre58xx0=.f1cc9877-febc-4090-9c96-4f77500decbb@github.com> On Fri, 8 Jan 2021 11:21:12 GMT, Athijegannathan Sundararajan wrote: > NPE with proper error message is thrown immediately (on call, variable access/set) This pull request has now been integrated. Changeset: 55f2e757 Author: Athijegannathan Sundararajan URL: https://git.openjdk.java.net/panama-foreign/commit/55f2e757 Stats: 199 lines in 5 files changed: 190 ins; 0 del; 9 mod 8259473: jextract generated code should throw exception for unfound native symbols from calls, variable access, set immediately Reviewed-by: mcimadamore, jvernee ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/432 From ach at activeviam.com Fri Jan 8 13:28:01 2021 From: ach at activeviam.com (Antoine Chambille) Date: Fri, 8 Jan 2021 14:28:01 +0100 Subject: Foreign memory access hot loop benchmark In-Reply-To: <9c68d444-5b6e-3784-f058-460a4ba0d914@oracle.com> References: <3c26c12c-23e0-a99f-03cd-afd6996c6478@oracle.com> <7ca53e08-3b3d-0db3-0493-1ecb0e44b79d@oracle.com> <0c431324-68b5-c0b0-3ced-5119ab51def9@oracle.com> <72ab9217-c638-88b9-b8fc-9ec91fab4cf6@oracle.com> <9c68d444-5b6e-3784-f058-460a4ba0d914@oracle.com> Message-ID: Hi Maurizio, thanks for investigating and taking the time to explain. Using the 8-bits alignment "trick" I reproduce what you described and all benchmarks are now in the same ballpark. And performance with memory handles is similar to Unsafe. Very nice. Benchmark Mode Cnt Score Error Units AddBenchmark.scalarArray thrpt 5 3670444.769 ? 2530.711 ops/s AddBenchmark.scalarArrayHandle thrpt 5 3646632.374 ? 5986.572 ops/s AddBenchmark.scalarUnsafe thrpt 5 1478253.636 ? 7656.381 ops/s AddBenchmark.scalarMHI thrpt 5 1598951.179 ? 29155.440 ops/s AddBenchmark.scalarMHI_v2 thrpt 5 1601492.148 ? 9539.575 ops/s AddBenchmark.unrolledArray thrpt 5 5388372.121 ? 12996.095 ops/s AddBenchmark.unrolledArrayHandle thrpt 5 1387713.576 ? 2794.709 ops/s AddBenchmark.unrolledUnsafe thrpt 5 1527765.861 ? 3157.150 ops/s AddBenchmark.unrolledMHI thrpt 5 1586333.615 ? 5012.909 ops/s AddBenchmark.unrolledMHI_long thrpt 5 1373930.743 ? 3170.683 ops/s AddBenchmark.unrolledMHI_v2 thrpt 5 1588131.924 ? 6045.960 ops/s AddBenchmark.unrolledMHI_v2_long thrpt 5 1373246.663 ? 18637.544 ops/s The next significant improvements will probably come from vectorization, automatic vectorization (that apparently only works with arrays for now) and the Vector API when it supports segments. Can't wait! -Antoine On Tue, Jan 5, 2021 at 7:52 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Good news, it wasn't as nasty as anticipated. > > It seems like your benchmark was accidentally comparing pears with > apples - in the sense that the VarHandle created in your benchmark was > checking alignment, while the ones we have in MemoryAccess do not. > > This is what I get with your code: > > Benchmark Mode Cnt Score Error Units > AddBenchmark.unrolledMHI_long avgt 30 2.947 ? 0.029 us/op > AddBenchmark.unrolledMHI_v2_long avgt 30 0.341 ? 0.004 us/op > AddBenchmark.unrolledUnsafe avgt 30 0.251 ? 0.002 us/op > > But the var handle is created as follows: > > static final VarHandle MHI_L = MemoryLayout.ofSequence(SIZE, > MemoryLayouts.JAVA_LONG.withBitAlignment(8)) > .varHandle(long.class, > MemoryLayout.PathElement.sequenceElement()); > > Then the numbers I get are much better: > > Benchmark Mode Cnt Score Error Units > AddBenchmark.unrolledMHI_long avgt 30 0.339 ? 0.005 us/op > AddBenchmark.unrolledMHI_v2_long avgt 30 0.341 ? 0.004 us/op > AddBenchmark.unrolledUnsafe avgt 30 0.256 ? 0.002 us/op > > We know we have issues when it comes to hoisting the alignment check out > of loops (Vlad, do you happen to have a JBS issue for this?) - we have > some workarounds in place which work for simple loops, but fail to work > in more complex code like yours. > > Eventually, the upcoming improvements for long loop optimizations will > hopefully render much of these edge cases obsolete. > > On 05/01/2021 16:50, Maurizio Cimadamore wrote: > > Thanks, > > I'll take a look - my guts tell me that the method is just too big > > when using VH directly (something I've seen in other cases). Note that > > the fact that we have @ForceInline on the MemoryAccess accessors > > helps, since that will tell hotspot to always inline those access, no > > matter the size of the enclosing method. I'm afraid here we're in a > > situation where the benchmark method gets too big and no further > > inlining happens (even though, if we progressed with inlining we'd end > > up with a _smaller_ compiled method overall). > > > > I'll try to test this hypothesis. Stay tuned. > > > > Cheers > > Maurizio > > > > > > On 05/01/2021 16:45, Antoine Chambille wrote: > >> Yes I see the same slowdown with longs than with doubles. > >> > >> -Antoine > >> > >> > >> > >> On Mon, Jan 4, 2021 at 7:33 PM Maurizio Cimadamore > >> >> > wrote: > >> > >> What happens with longs? Do you still see the slowdown? > >> > >> Maurizio > >> > From leerho at gmail.com Fri Jan 8 19:10:02 2021 From: leerho at gmail.com (leerho) Date: Fri, 8 Jan 2021 11:10:02 -0800 Subject: [foreign-memaccess] musing on the memory access API In-Reply-To: References: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> <083001d6e2c9$1aae9040$500bb0c0$@apache.org> <1a830d5e-233c-e54e-6b3c-d679c7297410@oracle.com> <08af01d6e2f4$cdae0600$690a1200$@apache.org> <3b0c2cd5-e49b-24fe-2fe6-fc57c5dd3693@oracle.com> Message-ID: Maurizio, This is all music to my ears! Originally, our Memory Package did not have any positional logic, but we had some important users that really wanted to use it as a replacement for BB and so I had to add it in. Our predominant use-case is management of foreign structs, so everything that you are telling me makes sense and sounds really good! If we were to migrate to any JDK version without Panama/FMA, we would incur a huge hit in performance. And primarily for this reason we are stuck at 8 until 16 (with FMA) becomes available. Forgive me for not tracking all the improvements in versions 9 - 15. Since we can't migrate to them efficiently, I have pretty much ignored all the other improvements. Nonetheless, it is nice to hear that someone is paying attention to the BB after all these years! I hope to be doing some characterization tests soon, which I will definitely share with you. Thanks for your comprehensive replies! Lee. On Fri, Jan 8, 2021 at 3:24 AM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > On 08/01/2021 00:56, leerho wrote: > > Maurizio, > Is the strategy for Panama to completely eliminate the need for ByteBuffer > (except for backward integration)? > If so, this would be great! This means all of the problems I mention above > could be easily solved! > > Nonetheless, I thought I read (or heard) in one of your tutorials that you > felt that the APIs for reading and writing primitives into some backing > blob of bytes (MemorySegment) was a solved problem, thus the user would > still be using BB for that purpose. > > I don't think Panama wants to "eliminate" ByteBuffer - there are things > that ByteBuffer do well, and we're not going to replace BB in those areas > (e.g. charset encoder/decoders, to name one example). > > The MemorySegment API is a more focused API, which aims at catering the > "pure" offheap usages - with a hint to native interop (in fact, > MemorySegment is also the API used by the ForeignLinker to model foreign > structs). If you fall in this latter categories, then you will be at home > with MemorySegment (we hope!) - if, on the other hand, you are more in a > IO-driven, producer/consumer use case, I don't think MemorySegment is a > great fit - and it might be better to stick with ByteBuffer - and perhaps > turn them into segments (which is possible with > MemorySegment::ofBuffer(ByteBuffer)) if you need the more powerful > dereference mechanism. > > Hope this helps. > > Maurizio > > > Cheers, > > Lee. > > On Thu, Jan 7, 2021 at 2:36 PM leerho wrote: > >> Maurizio, Jorn, >> >> Thank you very much for your thoughtful comments and observations! >> >> * At the beginning, the doc claims protection from use after free even >>> in concurrent use - looking at the code that doesn't seem to be the case >>> though? E.g. it's true that updates to the "valid" bit of the memory >>> state are atomic, but that doesn't rule out the possibility of multiple >>> threads seeing a "true" value, then being interleaved with a memory >>> released, which would ultimately result in access free? I the Java 16 >>> iteration of the API we address this problem too, but at a much lower >>> level (we needed some VM/GC black magic to pull this off). >> >> >> You are absolutely right about the multi-threading issue! I wrote this a >> couple >> years ago and on my re-read I caught that as well! Our library is >> strictly >> single-threaded, which we mention in other places in the documentation. >> I need to correct that statement. Nonetheless, your solving this problem >> at a much lower level is precisely what I would hope you would do! And >> at the same time you offer much stronger multithreading guarantees! >> >> * The main differences between the memory access API and your API seem >>> to be in how dereference is done - you opted for virtual methods, while >>> we go all in on var handles (and then we provide a bunch of static >>> accessors on the side). I think the two are similar, although I think >>> I'm happy where we landed with our API, since using the pre-baked >>> statics is not any harder than using an instance method, but in exchange >>> we get a lot of capabilities of out the var handle API (such as atomic >>> access and adaptation). This decision has repercussions on the API, of >>> course: the fact that we use MemorySegment as a VarHandle coordinate >>> means we cannot get too crazy with hierarchies on the MemorySegment >>> front - in fact, when we tried to do that (at some point we had >>> MappedMemorySegment <: MemorySegment) we ran into performance issues, as >>> memory access var handle need exact type information to be fast. >> >> >> Two comments. >> 1. I chose virtual methods because as of JDK8, that was the only tool in >> the toolbox. >> The main advantage of virtual methods is that I can create an API >> hierarchy >> (driven by the needs of the application) that effectively collapses down >> to one >> class at runtime (as long as it is single inheritance). >> I'm not yet sure how I would do it differently with the MemoryAccess API. >> >> ...we ran into performance issues, as >>> memory access var handles need exact type information to be fast. >> >> >> This relates to an issue that I'm concerned about, but perhaps because >> I don't fully understand why "memory access var handles *need* exact >> type >> information to be *fast*" or is this just a convention? At the CPU >> level, it >> ingests chunks of bytes and then extracts whatever type specified by the >> assembly instruction whether it be a 32-bit integer (signed or unsigned), >> short, long, float, double or whatever. I would like the ability to >> create a >> MemorySegment allocated as bytes, load it with longs (for speed) and >> then read it with a MemoryLayout that describes some complex multi-type >> data structure (because I know what the bytes represent!). In other >> words, >> MemorySegment should act like a blob of bytes and reading and writing >> from it should behave like a *C union* overlayed with a *C struct.* >> I realize this violates the Java principles of strict typing, but if we >> really >> are interested in speed, we need this ability (even if you force us to >> declare it as *unsafe*). I'm sure you have thought >> about this, but I'm not sure, yet, if this is a reality in the code. >> >> This already appears in Java in a few very limited cases. E.g., I can >> view a >> *double* as raw bits, perform operations on the raw bits as a long, and >> convert it back to a double. We have some math routines that take >> advantage of this. What is unfortunate is the lack of being able to >> convert a double (or long, etc) into bytes and back at an intrinsic level, >> which should be very fast. >> >> I looked at your spliterator and it is not clear how I would use it to >> view >> the same blob of bytes with two different layouts. I must be missing >> something :(. >> >> * I believe/hope that the main gripes you had with the byte buffer API >>> (which seem to be endianness related) are gone with the memory access >>> API. There we made the decision of leaving endianness outside of the >>> MemorySegment - e.g. endianness is a property of the VarHandle doing the >>> access, not a property of the segment per se. I believe this decision >>> paid off (e.g. our segments are completely orthogonal w.r.t. layout >>> decisions), and avoids a lot of confusion as to "what's the default" etc. >> >> >> I have a number of gripes about the ByteBuffer. >> >> 1. The most serious issue is the handling of endianness. >> First, the default is BigEndian, which today makes no sense as nearly all >> CPUs are LE. And, some byte compression algorithms only work with a given >> endianness. Perhaps I could live with this, but if I am interested in >> performance >> I would like to match my CPU, so I dutifully set endianness to LE. >> >> ByteBuffer bb = ByteBuffer.allocate(16); >> >> bb.order(ByteOrder.LITTLE_ENDIAN); >> >> >> Later, suppose I need to do any one of the following common operations: >> slice(), duplicate() or asReadOnlyBuffer(). >> >> * The ByteBuffer silently reverts back to BigEndian!* >> >> So the engineer must magically know to always reset the desired >> endianness after >> every one of those common operations. And, by the way, this is not >> documented >> in the Javadocs anywhere I could find. >> >> This is the cause of many difficult to find bugs! In fact we have cases >> where >> in large segments of data that have been stored into historical archives, >> the >> same segment will have different parts of it encoded with LE and other >> parts >> in BE! This is a maintenance nightmare. >> >> This bug is easy to find in the ByteBuffer source code. The calls to >> slice(), >> duplicate() and asReadOnlyBuffer() return a new ByteBuffer without >> copying >> over the current state of Endianness. >> >> This is why in our Memory Package implementation we made endianness >> immutable, once it is chosen, and all equivalent calls to slice(), >> duplicate(), >> etc() retain the state of endianness. >> >> 2. ByteBuffer array handling is clumsy. It was designed strictly from an >> IO >> streaming use-case with no alternative for absolute addressing like the >> single primitive methods. The BB API is >> >> ByteBuffer put([] src, int srcOffset, int length); >> >> >> Our use case has the need to put or get an array at an absolute offset >> from the beginning of the buffer. For example, >> >> >>> ByteBuffer put(long bufferOffset, [] src, int srcOffset, int >>> length); >> >> >> Attempting to replicate this method with the current BB API requires: >> >> - Saving the current setting of position and limit (if used) >> - Setting the position, computing and perhaps checking the limit >> - executing the put() above, >> - restoring position and limit. >> >> This is a real PITA, and could be so easily solved with a few easy to add >> methods. >> >> 3. There is no method that allows a high-performance (system level) >> copy of a region of one ByteBuffer to another ByteBuffer without going >> through the heap. This is so easy to do with Unsafe, I hope you have >> the ability to do this with MemorySegments. What we need is something >> like >> >> static void copy(MemorySegment src, long srcOffsetBytes, >> >> MemorySegment dst, long dstOffsetBytes, long lengthBytes) >> >> >> Since there are no java arrays involved, the length could be a long. >> Under the covers, you could easily go parallel with multiple threads if >> the size is big. >> >> 4. The handling of the positional values is also clumsy IMHO where, for >> example, >> the Mark is silently invalidated. Agreed this is documented, but >> remembering >> the rules where the positionals are suddenly silently changed can be >> difficult >> unless you do it all the time. I designed a different positional system >> (see >> BaseBuffer) where there is no need to invalidate them. >> >> I hope you find this of interest. >> >> Cheers, >> >> Lee. >> >> >> From jorn.vernee at oracle.com Fri Jan 8 19:56:06 2021 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Fri, 8 Jan 2021 20:56:06 +0100 Subject: [foreign-memaccess] musing on the memory access API In-Reply-To: References: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> <083001d6e2c9$1aae9040$500bb0c0$@apache.org> <1a830d5e-233c-e54e-6b3c-d679c7297410@oracle.com> <08af01d6e2f4$cdae0600$690a1200$@apache.org> <3b0c2cd5-e49b-24fe-2fe6-fc57c5dd3693@oracle.com> Message-ID: Why would you incur a huge hit in performance if you migrated? Unsafe is still openly available in 9+ (with the reflection hack). There were some memory barriers inserted around Unsafe accesses before, but that has been addressed in 14 as well. Is there something I'm missing? Is there a specific performance problem you're talking about? Jorn On 08/01/2021 20:10, leerho wrote: > Maurizio, > This is all music to my ears! > > Originally, our Memory Package did not have any positional logic, but > we had some important users that really wanted to use it as a > replacement for BB and so I had to add it in.? Our predominant > use-case is management of foreign structs, so everything that you are > telling me makes sense and sounds really good! > > If we were to migrate to any JDK version without Panama/FMA, we would > incur a huge hit in performance.? And primarily for this reason we are > stuck at 8 until 16 (with FMA)?becomes available.??Forgive me for not > tracking all the improvements in versions 9 - 15.? Since we can't > migrate to them efficiently, I have pretty much ignored all the other > improvements.? Nonetheless, it is nice to hear that someone is paying > attention to the BB after all these years! > > I hope to be doing some characterization tests soon, which I will > definitely share with you. > > Thanks for your comprehensive replies! > > Lee. > > > > > > > > > > On Fri, Jan 8, 2021 at 3:24 AM Maurizio Cimadamore > > wrote: > > > On 08/01/2021 00:56, leerho wrote: >> Maurizio, >> Is the strategy for Panama to completely eliminate the need for >> ByteBuffer (except for backward integration)? >> If so, this would be great! This means all of the problems I >> mention above could be easily solved! >> >> Nonetheless,?I thought I read (or heard) in one of your tutorials >> that you felt that the APIs for reading and writing primitives >> into some backing blob of bytes (MemorySegment) was a solved >> problem, thus the?user would still be using BB for that purpose. > > I don't think Panama wants to "eliminate" ByteBuffer - there are > things that ByteBuffer do well, and we're not going to replace BB > in those areas (e.g. charset encoder/decoders, to name one example). > > The MemorySegment API is a more focused API, which aims at > catering the "pure" offheap usages - with a hint to native interop > (in fact, MemorySegment is also the API used by the ForeignLinker > to model foreign structs). If you fall in this latter categories, > then you will be at home with MemorySegment (we hope!) - if, on > the other hand, you are more in a IO-driven, producer/consumer use > case, I don't think MemorySegment is a great fit - and it might be > better to stick with ByteBuffer - and perhaps turn them into > segments (which is possible with > MemorySegment::ofBuffer(ByteBuffer)) if you need the more powerful > dereference mechanism. > > Hope this helps. > > Maurizio > >> >> Cheers, >> >> Lee. >> >> On Thu, Jan 7, 2021 at 2:36 PM leerho > > wrote: >> >> Maurizio, Jorn, >> >> Thank you very much for your thoughtful comments and >> observations! >> >> * At the beginning, the doc claims protection from use >> after free even >> in concurrent use - looking at the code that doesn't seem >> to be the case >> though? E.g. it's true that updates to the "valid" bit of >> the memory >> state are atomic, but that doesn't rule out the >> possibility of multiple >> threads seeing a "true" value, then being interleaved >> with a memory >> released, which would ultimately result in access free? I >> the Java 16 >> iteration of the API we address this problem too, but at >> a much lower >> level (we needed some VM/GC black magic to pull this off). >> >> >> You are absolutely right about the multi-threading issue!? I >> wrote this a couple >> years ago and on my re-read I caught that as well!? Our >> library is strictly >> single-threaded, which we mention in other places in the >> documentation. >> I need to correct that statement. Nonetheless, your solving >> this problem >> at a much lower level is precisely what I would hope you >> would do! And >> at the same time you offer much stronger multithreading >> guarantees! >> >> * The main differences between the memory access API and >> your API seem >> to be in how dereference is done - you opted for virtual >> methods, while >> we go all in on var handles (and then we provide a bunch >> of static >> accessors on the side). I think the two are similar, >> although I think >> I'm happy where we landed with our API, since using the >> pre-baked >> statics is not any harder than using an instance method, >> but in exchange >> we get a lot of capabilities of out the var handle API >> (such as atomic >> access and adaptation). This decision has repercussions >> on the API, of >> course: the fact that we use MemorySegment as a VarHandle >> coordinate >> means we cannot get too crazy with hierarchies on the >> MemorySegment >> front - in fact, when we tried to do that (at some point >> we had >> MappedMemorySegment <: MemorySegment) we ran into >> performance issues, as >> memory access var handle need exact type information to >> be fast. >> >> >> Two comments. >> 1. I chose virtual methods because as of JDK8, that was the >> only tool in the toolbox. >> The main advantage of virtual methods is that I can create an >> API hierarchy >> (driven by the needs of the application) that effectively >> collapses down to one >> class at runtime (as long as it is single inheritance). >> I'm not yet sure how I would do it differently with the >> MemoryAccess API. >> >> ...we ran into performance issues, as >> memory access var handles need exact type information to >> be fast. >> >> >> This relates to an issue that I'm concerned about, but >> perhaps because >> I don't fully understand why? "memory access var handles >> *need* exact type >> information to be *fast*" or is this just a convention?? At >> the CPU level, it >> ingests chunks of bytes and then extracts whatever type >> specified by the >> assembly instruction whether it be a 32-bit integer (signed >> or unsigned), >> short, long, float, double or whatever.? I would like the >> ability to create a >> MemorySegment allocated as bytes, load it with longs (for >> speed) and >> then read it with a MemoryLayout that describes some complex >> multi-type >> data structure (because I know what the bytes represent!).? >> In other words, >> MemorySegment should act like a blob of bytes and reading and >> writing >> from it should behave like a /C union/?overlayed with a /C >> struct./ >> I realize this violates the Java principles of strict typing, >> but if we really >> are interested in speed, we need this ability (even if you >> force us to >> declare it as /unsafe/).? I'm sure you have thought >> about this, but I'm not sure, yet, if this is a reality in >> the code. >> >> This already appears in Java in a few very limited cases.? >> E.g., I can view a >> /double/ as raw bits, perform operations on the raw bits as a >> long, and >> convert it back to a double.? We have some math routines that >> take >> advantage of this.? What is unfortunate is the lack of being >> able to >> convert a double (or long, etc) into bytes and back at an >> intrinsic level, >> which should be very fast. >> >> I looked at your spliterator and it is not clear how I would >> use it to view >> the same blob of bytes with two different layouts.? I must be >> missing >> something :(. >> >> * I believe/hope that the main gripes you had with the >> byte buffer API >> (which seem to be endianness related) are gone with the >> memory access >> API. There we made the decision of leaving endianness >> outside of the >> MemorySegment - e.g. endianness is a property of the >> VarHandle doing the >> access, not a property of the segment per se. I believe >> this decision >> paid off (e.g. our segments are completely orthogonal >> w.r.t. layout >> decisions), and avoids a lot of confusion as to "what's >> the default" etc. >> >> >> I have a number of gripes about the ByteBuffer. >> >> 1. The most serious issue is the handling of endianness. >> First, the default is BigEndian, which today makes no sense >> as nearly all >> CPUs are LE.? And, some byte compression algorithms only work >> with a given >> endianness.? Perhaps I could live with this, but if I am >> interested in performance >> I would like to match my CPU, so I dutifully set endianness >> to LE. >> >> ByteBuffer bb = ByteBuffer.allocate(16); >> >> bb.order(ByteOrder.LITTLE_ENDIAN); >> >> Later, suppose I need to do any one of the following common >> operations: >> slice(), duplicate() or?asReadOnlyBuffer(). >> >> *? ? The ByteBuffer silently reverts back to BigEndian!* >> >> So the engineer must magically know to always reset the >> desired endianness after >> every one of those common operations. And, by the way, this >> is not documented >> in the Javadocs anywhere I could find. >> >> This is the cause of many difficult to find bugs!? In fact we >> have cases where >> in large segments of data that have been stored into >> historical archives, the >> same segment will have different parts of it encoded with LE >> and other parts >> in BE!? This is a maintenance nightmare. >> >> This bug is easy to find in the ByteBuffer source code.? The >> calls to slice(), >> duplicate() and asReadOnlyBuffer() return a new ByteBuffer >> without copying >> over the current state of Endianness. >> >> This is why in our Memory Package implementation we made >> endianness >> immutable, once it is chosen, and all equivalent calls to >> slice(), duplicate(), >> etc() retain the state of endianness. >> >> 2. ByteBuffer array handling is clumsy. It was designed >> strictly from an IO >> streaming use-case with no alternative for absolute >> addressing like the >> single primitive methods.? The BB API is >> >> ByteBuffer put([] src, int srcOffset, int length); >> >> >> Our use case has the need to put or get an array at an >> absolute offset >> from the beginning of the buffer. For example, >> >> ByteBuffer put(long bufferOffset, [] src, int >> srcOffset, int length); >> >> >> Attempting to replicate this method with the current BB API >> requires: >> >> * Saving the current setting of position and limit (if used) >> * Setting the position, computing and perhaps checking the >> limit >> * executing the put() above, >> * restoring position and limit. >> >> This is a real PITA, and could be so easily solved with a few >> easy to add >> methods. >> >> 3.? There is no method that allows a high-performance (system >> level) >> copy of a region of one ByteBuffer to another ByteBuffer >> without going >> through the heap.? This is so easy to do with Unsafe, I hope >> you have >> the ability to do this with MemorySegments.? What we need is >> something like >> >> static void copy(MemorySegment src, long srcOffsetBytes, >> >> MemorySegment dst, long dstOffsetBytes, long lengthBytes) >> >> >> Since there are no java arrays involved, the length could be >> a long. >> Under the covers, you could easily go parallel with multiple >> threads if >> the size is big. >> >> 4. The handling of the positional values is also clumsy IMHO >> where,?for example, >> the Mark is silently invalidated. ?Agreed this is documented, >> but remembering >> the rules where the?positionals are suddenly silently changed >> can be difficult >> unless you do it all the time.? I designed a different >> positional system >> ?(see >> BaseBuffer) where there is no need to invalidate them. >> >> I hope you find this of interest. >> >> Cheers, >> >> Lee. >> >> From leerho at gmail.com Fri Jan 8 21:42:51 2021 From: leerho at gmail.com (leerho) Date: Fri, 8 Jan 2021 13:42:51 -0800 Subject: [foreign-memaccess] musing on the memory access API In-Reply-To: References: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> <083001d6e2c9$1aae9040$500bb0c0$@apache.org> <1a830d5e-233c-e54e-6b3c-d679c7297410@oracle.com> <08af01d6e2f4$cdae0600$690a1200$@apache.org> <3b0c2cd5-e49b-24fe-2fe6-fc57c5dd3693@oracle.com> Message-ID: Hi Jorn, Unfortunately, it is more than just Unsafe. Our Memory Package was using reflection hacks to access hidden classes, fields and methods of: - *ByteBuffer* such as "address" and "offset" so we could directly read and write to it using *unsafe* totally bypassing the BB API. This allowed us to "wrap" a BB and use our more powerful API. See AccessByteBuffer . - *FileChannelImpl* and *MappedByteBuffer* which allowed us to create and/or wrap a memory mapped file and access the memory using our unsafe API, again bypassing the BB API, which the MBB extends. See AllocateDirectMap and AllocateDirectWritableMap . - sun.misc.Unsafe which allowed us to allocate and deallocate off-heap memory and read and write to it using our API. See AllocateDirect . And, of course, use all the primitive put / get methods, and a few others used in the above cases. - *sun.misc.VM*, and *java.nio.Bits* which allowed us to participate (as good citizens :) ) in the internal tracking of allocated and deallocated off-heap memory. See NioBits . Of these our users heavily leverage the first two, BB and MM files, since they already had extensive use of BB, DirectBB and MBB, they were able to just plug in our Memory package and leverage our faster and more flexible API. JDK9 basically locks out our access to the internals of BB, FileChannelImpl, internals of MappedByteBuffer, sun.misc.VM and java.nio.Bits. The value proposition of our Memory project has been gutted. With just unsafe, I don't see any way to replicate the above. Until Panama/FMA appears (hopefully in 16), the capability to do the above in Java doesn't exist. I don't know if there is a VM argument that would allow me to access all of these in the meantime, if so that would be a possible solution. Even if and when I make the migration to 16 w/FMA I will still have a major quandary. Many of the large systems that use our library are just now migrating from JDK8 to JDK11. It will be several years until they have migrated to JDK17 (the next LTS?). Any suggestions would be welcome! Cheers, Lee. On Fri, Jan 8, 2021 at 11:56 AM Jorn Vernee wrote: > Why would you incur a huge hit in performance if you migrated? Unsafe is > still openly available in 9+ (with the reflection hack). There were some > memory barriers inserted around Unsafe accesses before, but that has been > addressed in 14 as well. > > Is there something I'm missing? Is there a specific performance problem > you're talking about? > > Jorn > On 08/01/2021 20:10, leerho wrote: > > Maurizio, > This is all music to my ears! > > Originally, our Memory Package did not have any positional logic, but we > had some important users that really wanted to use it as a replacement for > BB and so I had to add it in. Our predominant use-case is management of > foreign structs, so everything that you are telling me makes sense and > sounds really good! > > If we were to migrate to any JDK version without Panama/FMA, we would > incur a huge hit in performance. And primarily for this reason we are > stuck at 8 until 16 (with FMA) becomes available. Forgive me for not > tracking all the improvements in versions 9 - 15. Since we can't migrate > to them efficiently, I have pretty much ignored all the other > improvements. Nonetheless, it is nice to hear that someone is paying > attention to the BB after all these years! > > I hope to be doing some characterization tests soon, which I will > definitely share with you. > > Thanks for your comprehensive replies! > > Lee. > > > > > > > > > > > > On Fri, Jan 8, 2021 at 3:24 AM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> >> On 08/01/2021 00:56, leerho wrote: >> >> Maurizio, >> Is the strategy for Panama to completely eliminate the need for >> ByteBuffer (except for backward integration)? >> If so, this would be great! This means all of the problems I mention >> above could be easily solved! >> >> Nonetheless, I thought I read (or heard) in one of your tutorials that >> you felt that the APIs for reading and writing primitives into some backing >> blob of bytes (MemorySegment) was a solved problem, thus the user would >> still be using BB for that purpose. >> >> I don't think Panama wants to "eliminate" ByteBuffer - there are things >> that ByteBuffer do well, and we're not going to replace BB in those areas >> (e.g. charset encoder/decoders, to name one example). >> >> The MemorySegment API is a more focused API, which aims at catering the >> "pure" offheap usages - with a hint to native interop (in fact, >> MemorySegment is also the API used by the ForeignLinker to model foreign >> structs). If you fall in this latter categories, then you will be at home >> with MemorySegment (we hope!) - if, on the other hand, you are more in a >> IO-driven, producer/consumer use case, I don't think MemorySegment is a >> great fit - and it might be better to stick with ByteBuffer - and perhaps >> turn them into segments (which is possible with >> MemorySegment::ofBuffer(ByteBuffer)) if you need the more powerful >> dereference mechanism. >> >> Hope this helps. >> >> Maurizio >> >> >> Cheers, >> >> Lee. >> >> On Thu, Jan 7, 2021 at 2:36 PM leerho wrote: >> >>> Maurizio, Jorn, >>> >>> Thank you very much for your thoughtful comments and observations! >>> >>> * At the beginning, the doc claims protection from use after free even >>>> in concurrent use - looking at the code that doesn't seem to be the case >>>> though? E.g. it's true that updates to the "valid" bit of the memory >>>> state are atomic, but that doesn't rule out the possibility of multiple >>>> threads seeing a "true" value, then being interleaved with a memory >>>> released, which would ultimately result in access free? I the Java 16 >>>> iteration of the API we address this problem too, but at a much lower >>>> level (we needed some VM/GC black magic to pull this off). >>> >>> >>> You are absolutely right about the multi-threading issue! I wrote this >>> a couple >>> years ago and on my re-read I caught that as well! Our library is >>> strictly >>> single-threaded, which we mention in other places in the documentation. >>> I need to correct that statement. Nonetheless, your solving this problem >>> at a much lower level is precisely what I would hope you would do! And >>> at the same time you offer much stronger multithreading guarantees! >>> >>> * The main differences between the memory access API and your API seem >>>> to be in how dereference is done - you opted for virtual methods, while >>>> we go all in on var handles (and then we provide a bunch of static >>>> accessors on the side). I think the two are similar, although I think >>>> I'm happy where we landed with our API, since using the pre-baked >>>> statics is not any harder than using an instance method, but in exchange >>>> we get a lot of capabilities of out the var handle API (such as atomic >>>> access and adaptation). This decision has repercussions on the API, of >>>> course: the fact that we use MemorySegment as a VarHandle coordinate >>>> means we cannot get too crazy with hierarchies on the MemorySegment >>>> front - in fact, when we tried to do that (at some point we had >>>> MappedMemorySegment <: MemorySegment) we ran into performance issues, as >>>> memory access var handle need exact type information to be fast. >>> >>> >>> Two comments. >>> 1. I chose virtual methods because as of JDK8, that was the only tool in >>> the toolbox. >>> The main advantage of virtual methods is that I can create an API >>> hierarchy >>> (driven by the needs of the application) that effectively collapses down >>> to one >>> class at runtime (as long as it is single inheritance). >>> I'm not yet sure how I would do it differently with the MemoryAccess API. >>> >>> ...we ran into performance issues, as >>>> memory access var handles need exact type information to be fast. >>> >>> >>> This relates to an issue that I'm concerned about, but perhaps because >>> I don't fully understand why "memory access var handles *need* exact >>> type >>> information to be *fast*" or is this just a convention? At the CPU >>> level, it >>> ingests chunks of bytes and then extracts whatever type specified by the >>> assembly instruction whether it be a 32-bit integer (signed or unsigned), >>> short, long, float, double or whatever. I would like the ability to >>> create a >>> MemorySegment allocated as bytes, load it with longs (for speed) and >>> then read it with a MemoryLayout that describes some complex multi-type >>> data structure (because I know what the bytes represent!). In other >>> words, >>> MemorySegment should act like a blob of bytes and reading and writing >>> from it should behave like a *C union* overlayed with a *C struct.* >>> I realize this violates the Java principles of strict typing, but if we >>> really >>> are interested in speed, we need this ability (even if you force us to >>> declare it as *unsafe*). I'm sure you have thought >>> about this, but I'm not sure, yet, if this is a reality in the code. >>> >>> This already appears in Java in a few very limited cases. E.g., I can >>> view a >>> *double* as raw bits, perform operations on the raw bits as a long, and >>> convert it back to a double. We have some math routines that take >>> advantage of this. What is unfortunate is the lack of being able to >>> convert a double (or long, etc) into bytes and back at an intrinsic >>> level, >>> which should be very fast. >>> >>> I looked at your spliterator and it is not clear how I would use it to >>> view >>> the same blob of bytes with two different layouts. I must be missing >>> something :(. >>> >>> * I believe/hope that the main gripes you had with the byte buffer API >>>> (which seem to be endianness related) are gone with the memory access >>>> API. There we made the decision of leaving endianness outside of the >>>> MemorySegment - e.g. endianness is a property of the VarHandle doing the >>>> access, not a property of the segment per se. I believe this decision >>>> paid off (e.g. our segments are completely orthogonal w.r.t. layout >>>> decisions), and avoids a lot of confusion as to "what's the default" >>>> etc. >>> >>> >>> I have a number of gripes about the ByteBuffer. >>> >>> 1. The most serious issue is the handling of endianness. >>> First, the default is BigEndian, which today makes no sense as nearly >>> all >>> CPUs are LE. And, some byte compression algorithms only work with a >>> given >>> endianness. Perhaps I could live with this, but if I am interested in >>> performance >>> I would like to match my CPU, so I dutifully set endianness to LE. >>> >>> ByteBuffer bb = ByteBuffer.allocate(16); >>> >>> bb.order(ByteOrder.LITTLE_ENDIAN); >>> >>> >>> Later, suppose I need to do any one of the following common operations: >>> slice(), duplicate() or asReadOnlyBuffer(). >>> >>> * The ByteBuffer silently reverts back to BigEndian!* >>> >>> So the engineer must magically know to always reset the desired >>> endianness after >>> every one of those common operations. And, by the way, this is not >>> documented >>> in the Javadocs anywhere I could find. >>> >>> This is the cause of many difficult to find bugs! In fact we have cases >>> where >>> in large segments of data that have been stored into historical >>> archives, the >>> same segment will have different parts of it encoded with LE and other >>> parts >>> in BE! This is a maintenance nightmare. >>> >>> This bug is easy to find in the ByteBuffer source code. The calls to >>> slice(), >>> duplicate() and asReadOnlyBuffer() return a new ByteBuffer without >>> copying >>> over the current state of Endianness. >>> >>> This is why in our Memory Package implementation we made endianness >>> immutable, once it is chosen, and all equivalent calls to slice(), >>> duplicate(), >>> etc() retain the state of endianness. >>> >>> 2. ByteBuffer array handling is clumsy. It was designed strictly from >>> an IO >>> streaming use-case with no alternative for absolute addressing like the >>> single primitive methods. The BB API is >>> >>> ByteBuffer put([] src, int srcOffset, int length); >>> >>> >>> Our use case has the need to put or get an array at an absolute offset >>> from the beginning of the buffer. For example, >>> >>> >>>> ByteBuffer put(long bufferOffset, [] src, int srcOffset, int >>>> length); >>> >>> >>> Attempting to replicate this method with the current BB API requires: >>> >>> - Saving the current setting of position and limit (if used) >>> - Setting the position, computing and perhaps checking the limit >>> - executing the put() above, >>> - restoring position and limit. >>> >>> This is a real PITA, and could be so easily solved with a few easy to >>> add >>> methods. >>> >>> 3. There is no method that allows a high-performance (system level) >>> copy of a region of one ByteBuffer to another ByteBuffer without going >>> through the heap. This is so easy to do with Unsafe, I hope you have >>> the ability to do this with MemorySegments. What we need is something >>> like >>> >>> static void copy(MemorySegment src, long srcOffsetBytes, >>> >>> MemorySegment dst, long dstOffsetBytes, long lengthBytes) >>> >>> >>> Since there are no java arrays involved, the length could be a long. >>> Under the covers, you could easily go parallel with multiple threads if >>> the size is big. >>> >>> 4. The handling of the positional values is also clumsy IMHO where, for >>> example, >>> the Mark is silently invalidated. Agreed this is documented, but >>> remembering >>> the rules where the positionals are suddenly silently changed can be >>> difficult >>> unless you do it all the time. I designed a different positional system >>> (see >>> BaseBuffer) where there is no need to invalidate them. >>> >>> I hope you find this of interest. >>> >>> Cheers, >>> >>> Lee. >>> >>> >>> From stefan.reich.maker.of.eye at googlemail.com Sat Jan 9 18:07:24 2021 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Sat, 9 Jan 2021 19:07:24 +0100 Subject: Good idea to use SPECIES_512? Message-ID: Just a quick question. Do you recommend using SPECIES_512 even on non AVX-512 CPUs? It will make some algorithms a lot simpler, but is it the fastest way? Greetings, Stefan -- Stefan Reich BotCompany.de // Java-based operating systems From whuang at openjdk.java.net Mon Jan 11 02:38:08 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Mon, 11 Jan 2021 02:38:08 GMT Subject: [vectorIntrinsics] Integrated: 8258072: Add Reinterpret nodes implementation for Arm SVE In-Reply-To: <0tvI-tWJBswl5w_-X0BMcPcreNiTuLWZDUSuFBrgGsA=.d22886ca-5a14-46f2-b84f-a1693ae565ad@github.com> References: <0tvI-tWJBswl5w_-X0BMcPcreNiTuLWZDUSuFBrgGsA=.d22886ca-5a14-46f2-b84f-a1693ae565ad@github.com> Message-ID: On Wed, 6 Jan 2021 03:00:08 GMT, Wang Huang wrote: > Add reduction nodes support for Arm SVE. Add the backend codegen for node like "VectorReinterpret" . > In this patch, We implement these instructs: > * reinterpret (src == dst) > * reinterpretResize, including, > 1? reinterpret?Expand? (src < dst) > 2? reinterpret?Shrink? (src > dst) > > At the same time, we fix a bug (JDK-8258989) because it is not merged in panama-vector/vectorIntrinsics. This pull request has now been integrated. Changeset: 2db19a41 Author: Wang Huang Committer: Ningsheng Jian URL: https://git.openjdk.java.net/panama-vector/commit/2db19a41 Stats: 105 lines in 3 files changed: 102 ins; 2 del; 1 mod 8258072: Add Reinterpret nodes implementation for Arm SVE Co-authored-by: He Xuejin Reviewed-by: njian, xgong ------------- PR: https://git.openjdk.java.net/panama-vector/pull/30 From jorn.vernee at oracle.com Mon Jan 11 12:37:21 2021 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Mon, 11 Jan 2021 13:37:21 +0100 Subject: [foreign-memaccess] musing on the memory access API In-Reply-To: References: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> <083001d6e2c9$1aae9040$500bb0c0$@apache.org> <1a830d5e-233c-e54e-6b3c-d679c7297410@oracle.com> <08af01d6e2f4$cdae0600$690a1200$@apache.org> <3b0c2cd5-e49b-24fe-2fe6-fc57c5dd3693@oracle.com> Message-ID: <6c716120-07ef-8d5b-d125-e3c1aa290a66@oracle.com> Hi Lee, Thanks for the detailed reply! FMA has been in the JDK from java 14 as an incubating feature, and is still incubating in JDK 16. In general, it is possible to expose module internals with --add-opens flags, but it looks like some of the things you're accessing have changed after 8, so your code wouldn't work on newer versions as is. For supporting multiple versions of Java you might want to investigate using multi-release jars, which allow overriding individual class files in a jar with different versions, depending on the version of VM they are loaded into. If some of your clients have already moved to Java 11, they might have already solved some of these problems on their own, so it could be worth inquiring about it. Jorn On 08/01/2021 22:42, leerho wrote: > Hi Jorn, > Unfortunately, it is more than just Unsafe.? Our Memory Package was > using reflection hacks to access hidden classes, fields and methods of: > > * /ByteBuffer/ such as "address" and "offset" so we could directly > read and write to it using /unsafe/ totally bypassing the BB API.? > This allowed us to "wrap" a BB and use our more powerful API.? See > AccessByteBuffer > . > > * /FileChannelImpl/ and /MappedByteBuffer/?which allowed us to > create and/or wrap a memory mapped file and access the memory > using our unsafe API, again bypassing the BB API, which the MBB > extends. See AllocateDirectMap > ?and > AllocateDirectWritableMap > . > * sun.misc.Unsafe which allowed us to allocate and deallocate > off-heap memory and read and write to it using our API. See > AllocateDirect > .? > And, of course, use all the primitive put / get methods, and a few > others used in the above cases. > * /sun.misc.VM/, and /java.nio.Bits/ which allowed us to participate > (as good citizens :) ) in the internal tracking of allocated and > deallocated off-heap memory. See NioBits > ?. > > > Of these our users heavily leverage the first two, BB and MM files, > since they already had extensive use of BB, DirectBB and MBB, they > were able to just plug in our Memory package and leverage our faster > and more flexible API. > > JDK9 basically locks out our access to the internals of BB, > FileChannelImpl, internals of MappedByteBuffer, sun.misc.VM and > java.nio.Bits.? The value proposition of our Memory project has been > gutted.? With just unsafe, I don't see any way to replicate the > above.? Until Panama/FMA appears (hopefully in 16), the capability to > do the above in Java doesn't exist.? I don't know if there is a VM > argument that would allow me to access all of these in the meantime, > if so that would be a possible solution. > > Even if and when I make the migration to 16 w/FMA I will still have a > major quandary. Many of the large systems that use our library are > just now migrating from JDK8 to JDK11. It will be several years until > they have migrated to JDK17 (the next LTS?). > > Any suggestions would be welcome! > > Cheers, > > Lee. > > > > > > > > > > On Fri, Jan 8, 2021 at 11:56 AM Jorn Vernee > wrote: > > Why would you incur a huge hit in performance if you migrated? > Unsafe is still openly available in 9+ (with the reflection hack). > There were some memory barriers inserted around Unsafe accesses > before, but that has been addressed in 14 as well. > > Is there something I'm missing? Is there a specific performance > problem you're talking about? > > Jorn > > On 08/01/2021 20:10, leerho wrote: >> Maurizio, >> This is all music to my ears! >> >> Originally, our Memory Package did not have any positional logic, >> but we had some important users that really wanted to use it as a >> replacement for BB and so I had to add it in.? Our predominant >> use-case is management of foreign structs, so everything that you >> are telling me makes sense and sounds really good! >> >> If we were to migrate to any JDK version without Panama/FMA, we >> would incur a huge hit in performance.? And primarily for this >> reason we are stuck at 8 until 16 (with FMA)?becomes >> available.??Forgive me for not tracking all the improvements in >> versions 9 - 15.? Since we can't migrate to them efficiently, I >> have pretty much ignored all the other improvements.? >> Nonetheless, it is nice to hear that someone is paying attention >> to the BB after all these years! >> >> I hope to be doing some characterization tests soon, which I will >> definitely share with you. >> >> Thanks for your comprehensive replies! >> >> Lee. >> >> >> >> >> >> >> >> >> >> On Fri, Jan 8, 2021 at 3:24 AM Maurizio Cimadamore >> > > wrote: >> >> >> On 08/01/2021 00:56, leerho wrote: >>> Maurizio, >>> Is the strategy for Panama to completely eliminate the need >>> for ByteBuffer (except for backward integration)? >>> If so, this would be great! This means all of the problems I >>> mention above could be easily solved! >>> >>> Nonetheless,?I thought I read (or heard) in one of your >>> tutorials that you felt that the APIs for reading and >>> writing primitives into some backing blob of bytes >>> (MemorySegment) was a solved problem, thus the?user would >>> still be using BB for that purpose. >> >> I don't think Panama wants to "eliminate" ByteBuffer - there >> are things that ByteBuffer do well, and we're not going to >> replace BB in those areas (e.g. charset encoder/decoders, to >> name one example). >> >> The MemorySegment API is a more focused API, which aims at >> catering the "pure" offheap usages - with a hint to native >> interop (in fact, MemorySegment is also the API used by the >> ForeignLinker to model foreign structs). If you fall in this >> latter categories, then you will be at home with >> MemorySegment (we hope!) - if, on the other hand, you are >> more in a IO-driven, producer/consumer use case, I don't >> think MemorySegment is a great fit - and it might be better >> to stick with ByteBuffer - and perhaps turn them into >> segments (which is possible with >> MemorySegment::ofBuffer(ByteBuffer)) if you need the more >> powerful dereference mechanism. >> >> Hope this helps. >> >> Maurizio >> >>> >>> Cheers, >>> >>> Lee. >>> >>> On Thu, Jan 7, 2021 at 2:36 PM leerho >> > wrote: >>> >>> Maurizio, Jorn, >>> >>> Thank you very much for your thoughtful comments and >>> observations! >>> >>> * At the beginning, the doc claims protection from >>> use after free even >>> in concurrent use - looking at the code that doesn't >>> seem to be the case >>> though? E.g. it's true that updates to the "valid" >>> bit of the memory >>> state are atomic, but that doesn't rule out the >>> possibility of multiple >>> threads seeing a "true" value, then being >>> interleaved with a memory >>> released, which would ultimately result in access >>> free? I the Java 16 >>> iteration of the API we address this problem too, >>> but at a much lower >>> level (we needed some VM/GC black magic to pull this >>> off). >>> >>> >>> You are absolutely right about the multi-threading >>> issue!? I wrote this a couple >>> years ago and on my re-read I caught that as well!? Our >>> library is strictly >>> single-threaded, which we mention in other places in the >>> documentation. >>> I need to correct that statement. Nonetheless, your >>> solving this problem >>> at a much lower level is precisely what I would hope you >>> would do! And >>> at the same time you offer much stronger multithreading >>> guarantees! >>> >>> * The main differences between the memory access API >>> and your API seem >>> to be in how dereference is done - you opted for >>> virtual methods, while >>> we go all in on var handles (and then we provide a >>> bunch of static >>> accessors on the side). I think the two are similar, >>> although I think >>> I'm happy where we landed with our API, since using >>> the pre-baked >>> statics is not any harder than using an instance >>> method, but in exchange >>> we get a lot of capabilities of out the var handle >>> API (such as atomic >>> access and adaptation). This decision has >>> repercussions on the API, of >>> course: the fact that we use MemorySegment as a >>> VarHandle coordinate >>> means we cannot get too crazy with hierarchies on >>> the MemorySegment >>> front - in fact, when we tried to do that (at some >>> point we had >>> MappedMemorySegment <: MemorySegment) we ran into >>> performance issues, as >>> memory access var handle need exact type information >>> to be fast. >>> >>> >>> Two comments. >>> 1. I chose virtual methods because as of JDK8, that was >>> the only tool in the toolbox. >>> The main advantage of virtual methods is that I can >>> create an API hierarchy >>> (driven by the needs of the application) that >>> effectively collapses down to one >>> class at runtime (as long as it is single inheritance). >>> I'm not yet sure how I would do it differently with the >>> MemoryAccess API. >>> >>> ...we ran into performance issues, as >>> memory access var handles need exact type >>> information to be fast. >>> >>> >>> This relates to an issue that I'm concerned about, but >>> perhaps because >>> I don't fully understand why "memory access var handles >>> *need* exact type >>> information to be *fast*" or is this just a convention?? >>> At the CPU level, it >>> ingests chunks of bytes and then extracts whatever type >>> specified by the >>> assembly instruction whether it be a 32-bit integer >>> (signed or unsigned), >>> short, long, float, double or whatever.? I would like >>> the ability to create a >>> MemorySegment allocated as bytes, load it with longs >>> (for speed) and >>> then read it with a MemoryLayout that describes some >>> complex multi-type >>> data structure (because I know what the bytes >>> represent!).? In other words, >>> MemorySegment should act like a blob of bytes and >>> reading and writing >>> from it should behave like a /C union/?overlayed with a >>> /C struct./ >>> I realize this violates the Java principles of strict >>> typing, but if we really >>> are interested in speed, we need this ability (even if >>> you force us to >>> declare it as /unsafe/).? I'm sure you have thought >>> about this, but I'm not sure, yet, if this is a reality >>> in the code. >>> >>> This already appears in Java in a few very limited >>> cases.? E.g., I can view a >>> /double/ as raw bits, perform operations on the raw bits >>> as a long, and >>> convert it back to a double.? We have some math routines >>> that take >>> advantage of this.? What is unfortunate is the lack of >>> being able to >>> convert a double (or long, etc) into bytes and back at >>> an intrinsic level, >>> which should be very fast. >>> >>> I looked at your spliterator and it is not clear how I >>> would use it to view >>> the same blob of bytes with two different layouts.? I >>> must be missing >>> something :(. >>> >>> * I believe/hope that the main gripes you had with >>> the byte buffer API >>> (which seem to be endianness related) are gone with >>> the memory access >>> API. There we made the decision of leaving >>> endianness outside of the >>> MemorySegment - e.g. endianness is a property of the >>> VarHandle doing the >>> access, not a property of the segment per se. I >>> believe this decision >>> paid off (e.g. our segments are completely >>> orthogonal w.r.t. layout >>> decisions), and avoids a lot of confusion as to >>> "what's the default" etc. >>> >>> >>> I have a number of gripes about the ByteBuffer. >>> >>> 1. The most serious issue is the handling of endianness. >>> First, the default is BigEndian, which today makes no >>> sense as nearly all >>> CPUs are LE.? And, some byte compression algorithms only >>> work with a given >>> endianness.? Perhaps I could live with this, but if I am >>> interested in performance >>> I would like to match my CPU, so I dutifully set >>> endianness to LE. >>> >>> ByteBuffer bb = ByteBuffer.allocate(16); >>> >>> bb.order(ByteOrder.LITTLE_ENDIAN); >>> >>> Later, suppose I need to do any one of the following >>> common operations: >>> slice(), duplicate() or?asReadOnlyBuffer(). >>> >>> *? ? The ByteBuffer silently reverts back to BigEndian!* >>> >>> So the engineer must magically know to always reset the >>> desired endianness after >>> every one of those common operations.? And, by the way, >>> this is not documented >>> in the Javadocs anywhere I could find. >>> >>> This is the cause of many difficult to find bugs!? In >>> fact we have cases where >>> in large segments of data that have been stored into >>> historical archives, the >>> same segment will have different parts of it encoded >>> with LE and other parts >>> in BE!? This is a maintenance nightmare. >>> >>> This bug is easy to find in the ByteBuffer source code.? >>> The calls to slice(), >>> duplicate() and asReadOnlyBuffer() return a new >>> ByteBuffer without copying >>> over the current state of Endianness. >>> >>> This is why in our Memory Package implementation we made >>> endianness >>> immutable, once it is chosen, and all equivalent calls >>> to slice(), duplicate(), >>> etc() retain the state of endianness. >>> >>> 2. ByteBuffer array handling is clumsy.? It was designed >>> strictly from an IO >>> streaming use-case with no alternative for absolute >>> addressing like the >>> single primitive methods.? The BB API is >>> >>> ByteBuffer put([] src, int srcOffset, int length); >>> >>> >>> Our use case has the need to put or get an array at an >>> absolute offset >>> from the beginning of the buffer. For example, >>> >>> ByteBuffer put(long bufferOffset, [] src, int >>> srcOffset, int length); >>> >>> >>> Attempting to replicate this method with the current BB >>> API requires: >>> >>> * Saving the current setting of position and limit (if >>> used) >>> * Setting the position, computing and perhaps checking >>> the limit >>> * executing the put() above, >>> * restoring position and limit. >>> >>> This is a real PITA, and could be so easily solved with >>> a few easy to add >>> methods. >>> >>> 3.? There is no method that allows a high-performance >>> (system level) >>> copy of a region of one ByteBuffer to another ByteBuffer >>> without going >>> through the heap.? This is so easy to do with Unsafe, I >>> hope you have >>> the ability to do this with MemorySegments.? What we >>> need is something like >>> >>> static void copy(MemorySegment src, long >>> srcOffsetBytes, >>> >>> MemorySegment dst, long dstOffsetBytes, long >>> lengthBytes) >>> >>> >>> Since there are no java arrays involved, the length >>> could be a long. >>> Under the covers, you could easily go parallel with >>> multiple threads if >>> the size is big. >>> >>> 4. The handling of the positional values is also clumsy >>> IMHO where,?for example, >>> the Mark is silently invalidated.? ?Agreed this is >>> documented, but remembering >>> the rules where the?positionals are suddenly silently >>> changed can be difficult >>> unless you do it all the time.? I designed a different >>> positional system >>> ?(see >>> BaseBuffer) where there is no need to invalidate them. >>> >>> I hope you find this of interest. >>> >>> Cheers, >>> >>> Lee. >>> >>> From jvernee at openjdk.java.net Mon Jan 11 20:39:42 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 11 Jan 2021 20:39:42 GMT Subject: [foreign-memaccess+abi] RFR: 8258516: Allow passing a target address as an argument to a native MethodHandle Message-ID: Hi, This patch adds the ability to CLinker to link a method handle that takes the address to the target function separately as a leading argument, instead of having to supply it during linking. This will avoid the need to re-link method handles for 'virtual' call sites, where the type of the call is always the same, but the address of the target function can differ. I've updated the C2 code to intrinsify the current case when the address argument is a constant, but there is still more work to be done to add intrinsification of virtual calls. Though, not having to re-link a method handle on every call should already speed things up significantly. There are other possible enhancements imaginable as well, such as caching linked method handles inside the linker, and re-using them with different addresses (but that is for a later patch). I added a benchmark similar to CallOverhead that measures the virtual variants. Some refactoring has been done there to put shared code in a helper class, and the old benchmark has been renamed to CallOverheadConstant so it's possible to select either class to run independently of the other with JMH. I've also added several more variants that test different numbers of arguments. I added a TestVirtualCalls test as a smoke test for simple virtual calls, and updated (as well as simplified a little) TestIntrinsics to make sure nothing crashes in the C2 code when encountering a virtual call. Thanks, Jorn ------------- Commit messages: - Remove unneeded imports - Update copyright header part 2 - Fix assert crash - Add tests - Fix copyrights - Cleanups + javadoc - Add virtual call benchmarks - Allow passing address of target separately to downcall handles Changes: https://git.openjdk.java.net/panama-foreign/pull/433/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=433&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258516 Stats: 960 lines in 29 files changed: 623 ins; 234 del; 103 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/433.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/433/head:pull/433 PR: https://git.openjdk.java.net/panama-foreign/pull/433 From sandhya.viswanathan at intel.com Mon Jan 11 21:56:19 2021 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Mon, 11 Jan 2021 21:56:19 +0000 Subject: Good idea to use SPECIES_512? In-Reply-To: References: Message-ID: Hi Stefan, We don?t recommend using SPECIES_512 on non-avx 512 platforms. If the vector length exceeds the vector size supported by the platform, we don't generate the underlying SIMD instructions. Best Regards, Sandhya -----Original Message----- From: panama-dev On Behalf Of Stefan Reich Sent: Saturday, January 09, 2021 10:07 AM To: panama-dev at openjdk.java.net' Subject: Good idea to use SPECIES_512? Just a quick question. Do you recommend using SPECIES_512 even on non AVX-512 CPUs? It will make some algorithms a lot simpler, but is it the fastest way? Greetings, Stefan -- Stefan Reich BotCompany.de // Java-based operating systems From stefan.reich.maker.of.eye at googlemail.com Mon Jan 11 21:58:38 2021 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Mon, 11 Jan 2021 22:58:38 +0100 Subject: Good idea to use SPECIES_512? In-Reply-To: References: Message-ID: Hi Sandhya, thanks. I was assuming you might emulate the 512 bit instructions using multiple 256 bit registers, but I understand I was wrong and that is probably too complicated. Greetings On Mon, 11 Jan 2021 at 22:56, Viswanathan, Sandhya < sandhya.viswanathan at intel.com> wrote: > Hi Stefan, > > We don?t recommend using SPECIES_512 on non-avx 512 platforms. > If the vector length exceeds the vector size supported by the platform, we > don't generate the underlying SIMD instructions. > > Best Regards, > Sandhya > > -----Original Message----- > From: panama-dev On Behalf Of Stefan > Reich > Sent: Saturday, January 09, 2021 10:07 AM > To: panama-dev at openjdk.java.net' > Subject: Good idea to use SPECIES_512? > > Just a quick question. Do you recommend using SPECIES_512 even on non > AVX-512 CPUs? It will make some algorithms a lot simpler, but is it the > fastest way? > > Greetings, > Stefan > > -- > Stefan Reich > BotCompany.de // Java-based operating systems > -- Stefan Reich BotCompany.de // Java-based operating systems From leerho at gmail.com Tue Jan 12 00:24:22 2021 From: leerho at gmail.com (leerho) Date: Mon, 11 Jan 2021 16:24:22 -0800 Subject: [foreign-memaccess] musing on the memory access API In-Reply-To: <6c716120-07ef-8d5b-d125-e3c1aa290a66@oracle.com> References: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> <083001d6e2c9$1aae9040$500bb0c0$@apache.org> <1a830d5e-233c-e54e-6b3c-d679c7297410@oracle.com> <08af01d6e2f4$cdae0600$690a1200$@apache.org> <3b0c2cd5-e49b-24fe-2fe6-fc57c5dd3693@oracle.com> <6c716120-07ef-8d5b-d125-e3c1aa290a66@oracle.com> Message-ID: Jorn, Are all the capabilities that you folks have been putting into FMA available in 14? In other words, are you continuing to upgrade FMA in 14 with the latest FMA capabilities? If this is true, this is big news. This means I could start moving to 14. What do I need 16 for?? Lee. On Mon, Jan 11, 2021 at 4:37 AM Jorn Vernee wrote: > Hi Lee, > > Thanks for the detailed reply! > > FMA has been in the JDK from java 14 as an incubating feature, and is > still incubating in JDK 16. > > In general, it is possible to expose module internals with --add-opens > flags, but it looks like some of the things you're accessing have changed > after 8, so your code wouldn't work on newer versions as is. > > For supporting multiple versions of Java you might want to investigate > using multi-release jars, which allow overriding individual class files in > a jar with different versions, depending on the version of VM they are > loaded into. > > If some of your clients have already moved to Java 11, they might have > already solved some of these problems on their own, so it could be worth > inquiring about it. > > Jorn > On 08/01/2021 22:42, leerho wrote: > > Hi Jorn, > Unfortunately, it is more than just Unsafe. Our Memory Package was using > reflection hacks to access hidden classes, fields and methods of: > > - *ByteBuffer* such as "address" and "offset" so we could directly > read and write to it using *unsafe* totally bypassing the BB API. > This allowed us to "wrap" a BB and use our more powerful API. See > AccessByteBuffer > > . > - *FileChannelImpl* and *MappedByteBuffer* which allowed us to create > and/or wrap a memory mapped file and access the memory using our unsafe > API, again bypassing the BB API, which the MBB extends. See > AllocateDirectMap > and > AllocateDirectWritableMap > > . > - sun.misc.Unsafe which allowed us to allocate and deallocate off-heap > memory and read and write to it using our API. See AllocateDirect > . > And, of course, use all the primitive put / get methods, and a few others > used in the above cases. > - *sun.misc.VM*, and *java.nio.Bits* which allowed us to participate > (as good citizens :) ) in the internal tracking of allocated and > deallocated off-heap memory. See NioBits > > . > > Of these our users heavily leverage the first two, BB and MM files, since > they already had extensive use of BB, DirectBB and MBB, they were able to > just plug in our Memory package and leverage our faster and more flexible > API. > > JDK9 basically locks out our access to the internals of BB, > FileChannelImpl, internals of MappedByteBuffer, sun.misc.VM and > java.nio.Bits. The value proposition of our Memory project has been > gutted. With just unsafe, I don't see any way to replicate the above. > Until Panama/FMA appears (hopefully in 16), the capability to do the above > in Java doesn't exist. I don't know if there is a VM argument that would > allow me to access all of these in the meantime, if so that would be a > possible solution. > > Even if and when I make the migration to 16 w/FMA I will still have a > major quandary. Many of the large systems that use our library are just now > migrating from JDK8 to JDK11. It will be several years until they have > migrated to JDK17 (the next LTS?). > > Any suggestions would be welcome! > > Cheers, > > Lee. > > > > > > > > > > On Fri, Jan 8, 2021 at 11:56 AM Jorn Vernee > wrote: > >> Why would you incur a huge hit in performance if you migrated? Unsafe is >> still openly available in 9+ (with the reflection hack). There were some >> memory barriers inserted around Unsafe accesses before, but that has been >> addressed in 14 as well. >> >> Is there something I'm missing? Is there a specific performance problem >> you're talking about? >> >> Jorn >> On 08/01/2021 20:10, leerho wrote: >> >> Maurizio, >> This is all music to my ears! >> >> Originally, our Memory Package did not have any positional logic, but we >> had some important users that really wanted to use it as a replacement for >> BB and so I had to add it in. Our predominant use-case is management of >> foreign structs, so everything that you are telling me makes sense and >> sounds really good! >> >> If we were to migrate to any JDK version without Panama/FMA, we would >> incur a huge hit in performance. And primarily for this reason we are >> stuck at 8 until 16 (with FMA) becomes available. Forgive me for not >> tracking all the improvements in versions 9 - 15. Since we can't migrate >> to them efficiently, I have pretty much ignored all the other >> improvements. Nonetheless, it is nice to hear that someone is paying >> attention to the BB after all these years! >> >> I hope to be doing some characterization tests soon, which I will >> definitely share with you. >> >> Thanks for your comprehensive replies! >> >> Lee. >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Jan 8, 2021 at 3:24 AM Maurizio Cimadamore < >> maurizio.cimadamore at oracle.com> wrote: >> >>> >>> On 08/01/2021 00:56, leerho wrote: >>> >>> Maurizio, >>> Is the strategy for Panama to completely eliminate the need for >>> ByteBuffer (except for backward integration)? >>> If so, this would be great! This means all of the problems I mention >>> above could be easily solved! >>> >>> Nonetheless, I thought I read (or heard) in one of your tutorials that >>> you felt that the APIs for reading and writing primitives into some backing >>> blob of bytes (MemorySegment) was a solved problem, thus the user would >>> still be using BB for that purpose. >>> >>> I don't think Panama wants to "eliminate" ByteBuffer - there are things >>> that ByteBuffer do well, and we're not going to replace BB in those areas >>> (e.g. charset encoder/decoders, to name one example). >>> >>> The MemorySegment API is a more focused API, which aims at catering the >>> "pure" offheap usages - with a hint to native interop (in fact, >>> MemorySegment is also the API used by the ForeignLinker to model foreign >>> structs). If you fall in this latter categories, then you will be at home >>> with MemorySegment (we hope!) - if, on the other hand, you are more in a >>> IO-driven, producer/consumer use case, I don't think MemorySegment is a >>> great fit - and it might be better to stick with ByteBuffer - and perhaps >>> turn them into segments (which is possible with >>> MemorySegment::ofBuffer(ByteBuffer)) if you need the more powerful >>> dereference mechanism. >>> >>> Hope this helps. >>> >>> Maurizio >>> >>> >>> Cheers, >>> >>> Lee. >>> >>> On Thu, Jan 7, 2021 at 2:36 PM leerho wrote: >>> >>>> Maurizio, Jorn, >>>> >>>> Thank you very much for your thoughtful comments and observations! >>>> >>>> * At the beginning, the doc claims protection from use after free even >>>>> in concurrent use - looking at the code that doesn't seem to be the >>>>> case >>>>> though? E.g. it's true that updates to the "valid" bit of the memory >>>>> state are atomic, but that doesn't rule out the possibility of multiple >>>>> threads seeing a "true" value, then being interleaved with a memory >>>>> released, which would ultimately result in access free? I the Java 16 >>>>> iteration of the API we address this problem too, but at a much lower >>>>> level (we needed some VM/GC black magic to pull this off). >>>> >>>> >>>> You are absolutely right about the multi-threading issue! I wrote this >>>> a couple >>>> years ago and on my re-read I caught that as well! Our library is >>>> strictly >>>> single-threaded, which we mention in other places in the >>>> documentation. >>>> I need to correct that statement. Nonetheless, your solving this >>>> problem >>>> at a much lower level is precisely what I would hope you would do! And >>>> at the same time you offer much stronger multithreading guarantees! >>>> >>>> * The main differences between the memory access API and your API seem >>>>> to be in how dereference is done - you opted for virtual methods, while >>>>> we go all in on var handles (and then we provide a bunch of static >>>>> accessors on the side). I think the two are similar, although I think >>>>> I'm happy where we landed with our API, since using the pre-baked >>>>> statics is not any harder than using an instance method, but in >>>>> exchange >>>>> we get a lot of capabilities of out the var handle API (such as atomic >>>>> access and adaptation). This decision has repercussions on the API, of >>>>> course: the fact that we use MemorySegment as a VarHandle coordinate >>>>> means we cannot get too crazy with hierarchies on the MemorySegment >>>>> front - in fact, when we tried to do that (at some point we had >>>>> MappedMemorySegment <: MemorySegment) we ran into performance issues, >>>>> as >>>>> memory access var handle need exact type information to be fast. >>>> >>>> >>>> Two comments. >>>> 1. I chose virtual methods because as of JDK8, that was the only tool >>>> in the toolbox. >>>> The main advantage of virtual methods is that I can create an API >>>> hierarchy >>>> (driven by the needs of the application) that effectively collapses >>>> down to one >>>> class at runtime (as long as it is single inheritance). >>>> I'm not yet sure how I would do it differently with the MemoryAccess >>>> API. >>>> >>>> ...we ran into performance issues, as >>>>> memory access var handles need exact type information to be fast. >>>> >>>> >>>> This relates to an issue that I'm concerned about, but perhaps because >>>> I don't fully understand why "memory access var handles *need* exact >>>> type >>>> information to be *fast*" or is this just a convention? At the CPU >>>> level, it >>>> ingests chunks of bytes and then extracts whatever type specified by the >>>> assembly instruction whether it be a 32-bit integer (signed or >>>> unsigned), >>>> short, long, float, double or whatever. I would like the ability to >>>> create a >>>> MemorySegment allocated as bytes, load it with longs (for speed) and >>>> then read it with a MemoryLayout that describes some complex multi-type >>>> data structure (because I know what the bytes represent!). In other >>>> words, >>>> MemorySegment should act like a blob of bytes and reading and writing >>>> from it should behave like a *C union* overlayed with a *C struct.* >>>> I realize this violates the Java principles of strict typing, but if we >>>> really >>>> are interested in speed, we need this ability (even if you force us to >>>> declare it as *unsafe*). I'm sure you have thought >>>> about this, but I'm not sure, yet, if this is a reality in the code. >>>> >>>> This already appears in Java in a few very limited cases. E.g., I can >>>> view a >>>> *double* as raw bits, perform operations on the raw bits as a long, >>>> and >>>> convert it back to a double. We have some math routines that take >>>> advantage of this. What is unfortunate is the lack of being able to >>>> convert a double (or long, etc) into bytes and back at an intrinsic >>>> level, >>>> which should be very fast. >>>> >>>> I looked at your spliterator and it is not clear how I would use it to >>>> view >>>> the same blob of bytes with two different layouts. I must be missing >>>> something :(. >>>> >>>> * I believe/hope that the main gripes you had with the byte buffer API >>>>> (which seem to be endianness related) are gone with the memory access >>>>> API. There we made the decision of leaving endianness outside of the >>>>> MemorySegment - e.g. endianness is a property of the VarHandle doing >>>>> the >>>>> access, not a property of the segment per se. I believe this decision >>>>> paid off (e.g. our segments are completely orthogonal w.r.t. layout >>>>> decisions), and avoids a lot of confusion as to "what's the default" >>>>> etc. >>>> >>>> >>>> I have a number of gripes about the ByteBuffer. >>>> >>>> 1. The most serious issue is the handling of endianness. >>>> First, the default is BigEndian, which today makes no sense as nearly >>>> all >>>> CPUs are LE. And, some byte compression algorithms only work with a >>>> given >>>> endianness. Perhaps I could live with this, but if I am interested in >>>> performance >>>> I would like to match my CPU, so I dutifully set endianness to LE. >>>> >>>> ByteBuffer bb = ByteBuffer.allocate(16); >>>> >>>> bb.order(ByteOrder.LITTLE_ENDIAN); >>>> >>>> >>>> Later, suppose I need to do any one of the following common operations: >>>> slice(), duplicate() or asReadOnlyBuffer(). >>>> >>>> * The ByteBuffer silently reverts back to BigEndian!* >>>> >>>> So the engineer must magically know to always reset the desired >>>> endianness after >>>> every one of those common operations. And, by the way, this is not >>>> documented >>>> in the Javadocs anywhere I could find. >>>> >>>> This is the cause of many difficult to find bugs! In fact we have >>>> cases where >>>> in large segments of data that have been stored into historical >>>> archives, the >>>> same segment will have different parts of it encoded with LE and other >>>> parts >>>> in BE! This is a maintenance nightmare. >>>> >>>> This bug is easy to find in the ByteBuffer source code. The calls to >>>> slice(), >>>> duplicate() and asReadOnlyBuffer() return a new ByteBuffer without >>>> copying >>>> over the current state of Endianness. >>>> >>>> This is why in our Memory Package implementation we made endianness >>>> immutable, once it is chosen, and all equivalent calls to slice(), >>>> duplicate(), >>>> etc() retain the state of endianness. >>>> >>>> 2. ByteBuffer array handling is clumsy. It was designed strictly from >>>> an IO >>>> streaming use-case with no alternative for absolute addressing like the >>>> single primitive methods. The BB API is >>>> >>>> ByteBuffer put([] src, int srcOffset, int length); >>>> >>>> >>>> Our use case has the need to put or get an array at an absolute offset >>>> from the beginning of the buffer. For example, >>>> >>>> >>>>> ByteBuffer put(long bufferOffset, [] src, int srcOffset, int >>>>> length); >>>> >>>> >>>> Attempting to replicate this method with the current BB API requires: >>>> >>>> - Saving the current setting of position and limit (if used) >>>> - Setting the position, computing and perhaps checking the limit >>>> - executing the put() above, >>>> - restoring position and limit. >>>> >>>> This is a real PITA, and could be so easily solved with a few easy to >>>> add >>>> methods. >>>> >>>> 3. There is no method that allows a high-performance (system level) >>>> copy of a region of one ByteBuffer to another ByteBuffer without going >>>> through the heap. This is so easy to do with Unsafe, I hope you have >>>> the ability to do this with MemorySegments. What we need is something >>>> like >>>> >>>> static void copy(MemorySegment src, long srcOffsetBytes, >>>> >>>> MemorySegment dst, long dstOffsetBytes, long lengthBytes) >>>> >>>> >>>> Since there are no java arrays involved, the length could be a long. >>>> Under the covers, you could easily go parallel with multiple threads if >>>> the size is big. >>>> >>>> 4. The handling of the positional values is also clumsy IMHO where, for >>>> example, >>>> the Mark is silently invalidated. Agreed this is documented, but >>>> remembering >>>> the rules where the positionals are suddenly silently changed can be >>>> difficult >>>> unless you do it all the time. I designed a different positional >>>> system >>>> (see >>>> BaseBuffer) where there is no need to invalidate them. >>>> >>>> I hope you find this of interest. >>>> >>>> Cheers, >>>> >>>> Lee. >>>> >>>> >>>> From whuang at openjdk.java.net Tue Jan 12 03:17:15 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 12 Jan 2021 03:17:15 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE Message-ID: This patch add cast nodes between interger types implementation for Arm SVE like "VectorCastB2X" "VectorCastI2X " "VectorCastS2X" "VectorCastL2X". ------------- Commit messages: - 8259536: Add cast nodes between interger types implementation for Arm SVE Changes: https://git.openjdk.java.net/panama-vector/pull/31/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=31&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259536 Stats: 243 lines in 3 files changed: 233 ins; 10 del; 0 mod Patch: https://git.openjdk.java.net/panama-vector/pull/31.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/31/head:pull/31 PR: https://git.openjdk.java.net/panama-vector/pull/31 From njian at openjdk.java.net Tue Jan 12 07:56:08 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Tue, 12 Jan 2021 07:56:08 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 03:13:31 GMT, Wang Huang wrote: > This patch add cast nodes between interger types implementation for Arm SVE like "VectorCastB2X" "VectorCastI2X " "VectorCastS2X" "VectorCastL2X". Changes requested by njian (Committer). src/hotspot/share/opto/vectorIntrinsics.cpp line 335: > 333: bool LibraryCallKit::inline_vector_shuffle_iota() { > 334: // TODO shuffle is not supported on SVE > 335: if (UseSVE > 0) { This is AArch64 only option, and should not be used in shared code. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/31 From whuang at openjdk.java.net Tue Jan 12 08:00:08 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 12 Jan 2021 08:00:08 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 03:58:43 GMT, Ningsheng Jian wrote: >> This patch add cast nodes between interger types implementation for Arm SVE like "VectorCastB2X" "VectorCastI2X " "VectorCastS2X" "VectorCastL2X". > > src/hotspot/share/opto/vectorIntrinsics.cpp line 335: > >> 333: bool LibraryCallKit::inline_vector_shuffle_iota() { >> 334: // TODO shuffle is not supported on SVE >> 335: if (UseSVE > 0) { > > This is AArch64 only option, and should not be used in shared code. Thank you. I will wrap these codes with aarch64 macro in revised patch. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/31 From maurizio.cimadamore at oracle.com Tue Jan 12 10:18:42 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 12 Jan 2021 10:18:42 +0000 Subject: [foreign-memaccess] musing on the memory access API In-Reply-To: References: <8ec939c7-43e8-668b-1766-7377e44de5c0@oracle.com> <083001d6e2c9$1aae9040$500bb0c0$@apache.org> <1a830d5e-233c-e54e-6b3c-d679c7297410@oracle.com> <08af01d6e2f4$cdae0600$690a1200$@apache.org> <3b0c2cd5-e49b-24fe-2fe6-fc57c5dd3693@oracle.com> <6c716120-07ef-8d5b-d125-e3c1aa290a66@oracle.com> Message-ID: On 12/01/2021 00:24, leerho wrote: > Jorn, > > Are all the capabilities that you folks have been putting into FMA > available in 14?? In other words, are you continuing to upgrade FMA in > 14 with the latest FMA capabilities?? If this is true, this is big > news.? This means I could start moving to 14. > > What do I need 16 for?? The foreign memory access API (and, now the foreign linker API) are in the so called "incubation" stage. This means that these API are part of the Java SE API (since 14, in the case of the memory API, and since 16 in the case of the linker API). The definition of an incubating API is more fluid than what you'll find in a regular Java SE API, and there are different that apply to these, which you can find described here: https://openjdk.java.net/jeps/11 Incubating APIs need to be defined in their own module, and said module is _disabled_ by default. This means that, in order to even be able to compile/run against said API you need to add some command line flags - e.g. "--add-modules jdk.incubator.foreign" - otherwise the API will not be resolved by the static compiler/runtime. Another big thing regarding incubating APIs is that they have a license to make breaking changes - e.g. they are not subject to the same compatibility guarantees as ordinary APIs. This is especially useful in order to make an API available, w/o committing too much on the final shape of the API, which (i) enables people to do real work experiments with it (as happened with Netty, Lucene and others) while still allowing us to change the API as we see fit, based on feedback (for instance, support for shared segment was added in the third incubation round - in Java 16 - , after a great discussion we had at the latest OpenJDK committer workshop in Brussels). I suspect, having looked at your library, that w/o shared segment support, you won't really be able to replace all the use cases for your memory API - which kinda ties you onto 16. But that's a choice only you can make - are you ok with the API changing under you (in possible incompatible ways) from version to version? Are you deploying in an environment where it's easy to add extra command line flags? Etc. But it's important to understand that the "readiness" barrier for those APIs is somewhat lower than for a full Java SE API. Cheers Maurizio > > Lee. > > > > > On Mon, Jan 11, 2021 at 4:37 AM Jorn Vernee > wrote: > > Hi Lee, > > Thanks for the detailed reply! > > FMA has been in the JDK from java 14 as an incubating feature, and > is still incubating in JDK 16. > > In general, it is possible to expose module internals with > --add-opens flags, but it looks like some of the things you're > accessing have changed after 8, so your code wouldn't work on > newer versions as is. > > For supporting multiple versions of Java you might want to > investigate using multi-release jars, which allow overriding > individual class files in a jar with different versions, depending > on the version of VM they are loaded into. > > If some of your clients have already moved to Java 11, they might > have already solved some of these problems on their own, so it > could be worth inquiring about it. > > Jorn > > On 08/01/2021 22:42, leerho wrote: >> Hi Jorn, >> Unfortunately, it is more than just Unsafe.? Our Memory Package >> was using reflection hacks to access hidden classes, fields and >> methods of: >> >> * /ByteBuffer/ such as "address" and "offset" so we could >> directly read and write to it using /unsafe/ totally >> bypassing the BB API.? This allowed us to "wrap" a BB and use >> our more powerful API.? See AccessByteBuffer >> . >> >> * /FileChannelImpl/ and /MappedByteBuffer/?which allowed us to >> create and/or wrap a memory mapped file and access the memory >> using our unsafe API, again bypassing the BB API, which the >> MBB extends. See AllocateDirectMap >> ?and >> AllocateDirectWritableMap >> . >> * sun.misc.Unsafe which allowed us to allocate and deallocate >> off-heap memory and read and write to it using our API. See >> AllocateDirect >> . >> And, of course, use all the primitive put / get methods, and >> a few others used in the above cases. >> * /sun.misc.VM/, and /java.nio.Bits/ which allowed us to >> participate (as good citizens :) ) in the internal tracking >> of allocated and deallocated off-heap memory. See NioBits >> ?. >> >> >> Of these our users heavily leverage the first two, BB and MM >> files, since they already had extensive use of BB, DirectBB and >> MBB, they were able to just plug in our Memory package and >> leverage our faster and more flexible API. >> >> JDK9 basically locks out our access to the internals of BB, >> FileChannelImpl, internals of MappedByteBuffer, sun.misc.VM and >> java.nio.Bits. The value proposition of our Memory project has >> been gutted.? With just unsafe, I don't see any way to replicate >> the above.? Until Panama/FMA appears (hopefully in 16), the >> capability to do the above in Java doesn't exist.? I don't know >> if there is a VM argument that would allow me to access all of >> these in the meantime, if so that would be a possible solution. >> >> Even if and when I make the migration to 16 w/FMA I will still >> have a major quandary. Many of the large systems that use our >> library are just now migrating from JDK8 to JDK11.? It will be >> several years until they have migrated to JDK17 (the next LTS?). >> >> Any suggestions would be welcome! >> >> Cheers, >> >> Lee. >> >> >> >> >> >> >> >> >> >> On Fri, Jan 8, 2021 at 11:56 AM Jorn Vernee >> > wrote: >> >> Why would you incur a huge hit in performance if you >> migrated? Unsafe is still openly available in 9+ (with the >> reflection hack). There were some memory barriers inserted >> around Unsafe accesses before, but that has been addressed in >> 14 as well. >> >> Is there something I'm missing? Is there a specific >> performance problem you're talking about? >> >> Jorn >> >> On 08/01/2021 20:10, leerho wrote: >>> Maurizio, >>> This is all music to my ears! >>> >>> Originally, our Memory Package did not have any positional >>> logic, but we had some important users that really wanted to >>> use it as a replacement for BB and so I had to add it in.? >>> Our predominant use-case is management of foreign structs, >>> so everything that you are telling me makes sense and sounds >>> really good! >>> >>> If we were to migrate to any JDK version without Panama/FMA, >>> we would incur a huge hit in performance.? And primarily for >>> this reason we are stuck at 8 until 16 (with FMA)?becomes >>> available.??Forgive me for not tracking all the improvements >>> in versions 9 - 15.? Since we can't migrate to them >>> efficiently, I have pretty much ignored all the other >>> improvements.? Nonetheless, it is nice to hear that someone >>> is paying attention to the BB after all these years! >>> >>> I hope to be doing some characterization tests soon, which I >>> will definitely share with you. >>> >>> Thanks for your comprehensive replies! >>> >>> Lee. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Jan 8, 2021 at 3:24 AM Maurizio Cimadamore >>> >> > wrote: >>> >>> >>> On 08/01/2021 00:56, leerho wrote: >>>> Maurizio, >>>> Is the strategy for Panama to completely eliminate the >>>> need for ByteBuffer (except for backward integration)? >>>> If so, this would be great! This means all of the >>>> problems I mention above could be easily solved! >>>> >>>> Nonetheless,?I thought I read (or heard) in one of your >>>> tutorials that you felt that the APIs for reading and >>>> writing primitives into some backing blob of bytes >>>> (MemorySegment) was a solved problem, thus the?user >>>> would still be using BB for that purpose. >>> >>> I don't think Panama wants to "eliminate" ByteBuffer - >>> there are things that ByteBuffer do well, and we're not >>> going to replace BB in those areas (e.g. charset >>> encoder/decoders, to name one example). >>> >>> The MemorySegment API is a more focused API, which aims >>> at catering the "pure" offheap usages - with a hint to >>> native interop (in fact, MemorySegment is also the API >>> used by the ForeignLinker to model foreign structs). If >>> you fall in this latter categories, then you will be at >>> home with MemorySegment (we hope!) - if, on the other >>> hand, you are more in a IO-driven, producer/consumer use >>> case, I don't think MemorySegment is a great fit - and >>> it might be better to stick with ByteBuffer - and >>> perhaps turn them into segments (which is possible with >>> MemorySegment::ofBuffer(ByteBuffer)) if you need the >>> more powerful dereference mechanism. >>> >>> Hope this helps. >>> >>> Maurizio >>> >>>> >>>> Cheers, >>>> >>>> Lee. >>>> >>>> On Thu, Jan 7, 2021 at 2:36 PM leerho >>> > wrote: >>>> >>>> Maurizio, Jorn, >>>> >>>> Thank you very much for your thoughtful comments >>>> and observations! >>>> >>>> * At the beginning, the doc claims protection >>>> from use after free even >>>> in concurrent use - looking at the code that >>>> doesn't seem to be the case >>>> though? E.g. it's true that updates to the >>>> "valid" bit of the memory >>>> state are atomic, but that doesn't rule out the >>>> possibility of multiple >>>> threads seeing a "true" value, then being >>>> interleaved with a memory >>>> released, which would ultimately result in >>>> access free? I the Java 16 >>>> iteration of the API we address this problem >>>> too, but at a much lower >>>> level (we needed some VM/GC black magic to pull >>>> this off). >>>> >>>> >>>> You are absolutely right about the multi-threading >>>> issue!? I wrote this a couple >>>> years ago and on my re-read I caught that as well!? >>>> Our library is strictly >>>> single-threaded, which we mention in other places >>>> in the documentation. >>>> I need to correct that statement.? Nonetheless, >>>> your solving this problem >>>> at a much lower level is precisely what I would >>>> hope you would do! And >>>> at the same time you offer much stronger >>>> multithreading guarantees! >>>> >>>> * The main differences between the memory >>>> access API and your API seem >>>> to be in how dereference is done - you opted >>>> for virtual methods, while >>>> we go all in on var handles (and then we >>>> provide a bunch of static >>>> accessors on the side). I think the two are >>>> similar, although I think >>>> I'm happy where we landed with our API, since >>>> using the pre-baked >>>> statics is not any harder than using an >>>> instance method, but in exchange >>>> we get a lot of capabilities of out the var >>>> handle API (such as atomic >>>> access and adaptation). This decision has >>>> repercussions on the API, of >>>> course: the fact that we use MemorySegment as a >>>> VarHandle coordinate >>>> means we cannot get too crazy with hierarchies >>>> on the MemorySegment >>>> front - in fact, when we tried to do that (at >>>> some point we had >>>> MappedMemorySegment <: MemorySegment) we ran >>>> into performance issues, as >>>> memory access var handle need exact type >>>> information to be fast. >>>> >>>> >>>> Two comments. >>>> 1. I chose virtual methods because as of JDK8, that >>>> was the only tool in the toolbox. >>>> The main advantage of virtual methods is that I can >>>> create an API hierarchy >>>> (driven by the needs of the application) that >>>> effectively collapses down to one >>>> class at runtime (as long as it is single inheritance). >>>> I'm not yet sure how I would do it differently with >>>> the MemoryAccess API. >>>> >>>> ...we ran into performance issues, as >>>> memory access var handles need exact type >>>> information to be fast. >>>> >>>> >>>> This relates to an issue that I'm concerned about, >>>> but perhaps because >>>> I don't fully understand why? "memory access var >>>> handles *need* exact type >>>> information to be *fast*" or is this just a >>>> convention?? At the CPU level, it >>>> ingests chunks of bytes and then extracts whatever >>>> type specified by the >>>> assembly instruction whether it be a 32-bit integer >>>> (signed or unsigned), >>>> short, long, float, double or whatever.? I would >>>> like the ability to create a >>>> MemorySegment allocated as bytes, load it with >>>> longs (for speed) and >>>> then read it with a MemoryLayout that describes >>>> some complex multi-type >>>> data structure (because I know what the bytes >>>> represent!).? In other words, >>>> MemorySegment should act like a blob of bytes and >>>> reading and writing >>>> from it should behave like a /C union/?overlayed >>>> with a /C struct./ >>>> I realize this violates the Java principles of >>>> strict typing, but if we really >>>> are interested in speed, we need this ability (even >>>> if you force us to >>>> declare it as /unsafe/). I'm sure you have thought >>>> about this, but I'm not sure, yet, if this is a >>>> reality in the code. >>>> >>>> This already appears in Java in a few very limited >>>> cases. E.g., I can view a >>>> /double/ as raw bits, perform operations on the raw >>>> bits as a long, and >>>> convert it back to a double.? We have some math >>>> routines that take >>>> advantage of this.? What is unfortunate is the lack >>>> of being able to >>>> convert a double (or long, etc) into bytes and back >>>> at an intrinsic level, >>>> which should be very fast. >>>> >>>> I looked at your spliterator and it is not clear >>>> how I would use it to view >>>> the same blob of bytes with two different layouts.? >>>> I must be missing >>>> something :(. >>>> >>>> * I believe/hope that the main gripes you had >>>> with the byte buffer API >>>> (which seem to be endianness related) are gone >>>> with the memory access >>>> API. There we made the decision of leaving >>>> endianness outside of the >>>> MemorySegment - e.g. endianness is a property >>>> of the VarHandle doing the >>>> access, not a property of the segment per se. I >>>> believe this decision >>>> paid off (e.g. our segments are completely >>>> orthogonal w.r.t. layout >>>> decisions), and avoids a lot of confusion as to >>>> "what's the default" etc. >>>> >>>> >>>> I have a number of gripes about the ByteBuffer. >>>> >>>> 1. The most serious issue is the handling of >>>> endianness. >>>> First, the default is BigEndian, which today makes >>>> no sense as nearly all >>>> CPUs are LE.? And, some byte compression algorithms >>>> only work with a given >>>> endianness.? Perhaps I could live with this, but if >>>> I am interested in performance >>>> I would like to match my CPU, so I dutifully set >>>> endianness to LE. >>>> >>>> ByteBuffer bb = ByteBuffer.allocate(16); >>>> >>>> bb.order(ByteOrder.LITTLE_ENDIAN); >>>> >>>> Later, suppose I need to do any one of the >>>> following common operations: >>>> slice(), duplicate() or?asReadOnlyBuffer(). >>>> >>>> *? ? The ByteBuffer silently reverts back to >>>> BigEndian!* >>>> >>>> So the engineer must magically know to always reset >>>> the desired endianness after >>>> every one of those common operations.? And, by the >>>> way, this is not documented >>>> in the Javadocs anywhere I could find. >>>> >>>> This is the cause of many difficult to find bugs!? >>>> In fact we have cases where >>>> in large segments of data that have been stored >>>> into historical archives, the >>>> same segment will have different parts of it >>>> encoded with LE and other parts >>>> in BE!? This is a maintenance nightmare. >>>> >>>> This bug is easy to find in the ByteBuffer source >>>> code. The calls to slice(), >>>> duplicate() and asReadOnlyBuffer() return a new >>>> ByteBuffer without copying >>>> over the current state of Endianness. >>>> >>>> This is why in our Memory Package implementation we >>>> made endianness >>>> immutable, once it is chosen, and all equivalent >>>> calls to slice(), duplicate(), >>>> etc() retain the state of endianness. >>>> >>>> 2. ByteBuffer array handling is clumsy.? It was >>>> designed strictly from an IO >>>> streaming use-case with no alternative for absolute >>>> addressing like the >>>> single primitive methods.? The BB API is >>>> >>>> ByteBuffer put([] src, int srcOffset, int >>>> length); >>>> >>>> >>>> Our use case has the need to put or get an array at >>>> an absolute offset >>>> from the beginning of the buffer. For example, >>>> >>>> ByteBuffer put(long bufferOffset, [] src, >>>> int srcOffset, int length); >>>> >>>> >>>> Attempting to replicate this method with the >>>> current BB API requires: >>>> >>>> * Saving the current setting of position and >>>> limit (if used) >>>> * Setting the position, computing and perhaps >>>> checking the limit >>>> * executing the put() above, >>>> * restoring position and limit. >>>> >>>> This is a real PITA, and could be so easily solved >>>> with a few easy to add >>>> methods. >>>> >>>> 3.? There is no method that allows a >>>> high-performance (system level) >>>> copy of a region of one ByteBuffer to another >>>> ByteBuffer without going >>>> through the heap.? This is so easy to do with >>>> Unsafe, I hope you have >>>> the ability to do this with MemorySegments.? What >>>> we need is something like >>>> >>>> static void copy(MemorySegment src, long >>>> srcOffsetBytes, >>>> >>>> MemorySegment dst, long dstOffsetBytes, long >>>> lengthBytes) >>>> >>>> >>>> Since there are no java arrays involved, the length >>>> could be a long. >>>> Under the covers, you could easily go parallel with >>>> multiple threads if >>>> the size is big. >>>> >>>> 4. The handling of the positional values is also >>>> clumsy IMHO where,?for example, >>>> the Mark is silently invalidated.? ?Agreed this is >>>> documented, but remembering >>>> the rules where the?positionals are suddenly >>>> silently changed can be difficult >>>> unless you do it all the time.? I designed a >>>> different positional system >>>> ?(see >>>> BaseBuffer) where there is no need to invalidate them. >>>> >>>> I hope you find this of interest. >>>> >>>> Cheers, >>>> >>>> Lee. >>>> >>>> From mcimadamore at openjdk.java.net Tue Jan 12 11:04:05 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 12 Jan 2021 11:04:05 GMT Subject: [foreign-memaccess+abi] RFR: 8258516: Allow passing a target address as an argument to a native MethodHandle In-Reply-To: References: Message-ID: <008fXsaCmVPCsyyuTXny2DL3Ehokr457CAr4Qd6tvxY=.83868680-93a3-4ff6-aad8-3507336998ac@github.com> On Mon, 11 Jan 2021 20:35:09 GMT, Jorn Vernee wrote: > Hi, > > This patch adds the ability to CLinker to link a method handle that takes the address to the target function separately as a leading argument, instead of having to supply it during linking. > > This will avoid the need to re-link method handles for 'virtual' call sites, where the type of the call is always the same, but the address of the target function can differ. > > I've updated the C2 code to intrinsify the current case when the address argument is a constant, but there is still more work to be done to add intrinsification of virtual calls. Though, not having to re-link a method handle on every call should already speed things up significantly. > > There are other possible enhancements imaginable as well, such as caching linked method handles inside the linker, and re-using them with different addresses (but that is for a later patch). > > I added a benchmark similar to CallOverhead that measures the virtual variants. Some refactoring has been done there to put shared code in a helper class, and the old benchmark has been renamed to CallOverheadConstant so it's possible to select either class to run independently of the other with JMH. I've also added several more variants that test different numbers of arguments. > > I added a TestVirtualCalls test as a smoke test for simple virtual calls, and updated (as well as simplified a little) TestIntrinsics to make sure nothing crashes in the C2 code when encountering a virtual call. > > Thanks, > Jorn Very solid piece of work. The adapter changes seem good, and I see some nice consolidation of some of the helper routines - but it made my head hurt to follow through some of the adaptations :-) (I did not review the HS part) ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/433 From mr.chrisvest at gmail.com Tue Jan 12 14:07:22 2021 From: mr.chrisvest at gmail.com (Chris Vest) Date: Tue, 12 Jan 2021 15:07:22 +0100 Subject: Interactions between memory segments and byte buffers Message-ID: Hi, In our (Netty) experimentation with foreign-memaccess, we have looked into how memory segments and byte buffers interact, because byte buffers are still the currency for doing IO, and we have found some bugs, and also some restrictions that we would prefer to have lifted. There are two issues we've identified. The less controversial one is that when you create a ByteBuffer from a slice of a heap MemorySegments, the buffer will get the base and capacity of the root (non-sliced) memory segment. The created buffer is effectively not sliced. This test fails for heap memory segments, but passes for native memory segments: @Test public void buffersAndArraysFromSlices() { try (MemorySegment segment = MemorySegment.ofArray(new byte[16])) { int newSize = 8; var slice = segment.asSlice(4, newSize); var bytes = slice.toByteArray(); assertEquals(newSize, bytes.length); var buffer = slice.asByteBuffer(); // Fails for heap segments, but passes for native segments: assertEquals(newSize, buffer.capacity()); } } The second issue is probably more controversial because it relates to this passage in the MemorySegment.asByteBuffer javadoc: *If this segment is shared, calling certain I/O operations on the resulting buffer might result in an unspecified exception being thrown. Examples of such problematic operations are FileChannel.read(ByteBuffer), FileChannel.write(ByteBuffer), java.nio.channels.SocketChannel.read(ByteBuffer) and java.nio.channels.SocketChannel.write(ByteBuffer).* This is problematic for us because, considering our usage patterns we have decided to use shared segments by default, and we need to create ByteBuffers for doing IO via the safe JDK APIs. There is also some additional fall-out from how this restriction is implemented. For instance, if you get a ByteBuffer from a shared, native memory segment, you cannot call asReadOnlyBuffer on that buffer. You also cannot create slices of it. Perhaps there are other things as well. This test demonstrates the problem: @Test public void readOnlyByteBufferFromSharedNativeSegment() { try (MemorySegment segment = MemorySegment.allocateNative(8).share()) { var byteBuffer = segment.asByteBuffer(); // This fails for native segments, but passes for heap segments. // Throws UOE: ByteBuffer derived from shared segments not supported byteBuffer.asReadOnlyBuffer(); } } I think this is an aspect of shared segments that is easy to miss. It would be desirable if shared and confined segments behaved the same in this regard; both for what ByteBuffer methods are available, and for the ability to use buffers from shared native segments for IO. Thanks, Chris From maurizio.cimadamore at oracle.com Tue Jan 12 14:40:33 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 12 Jan 2021 14:40:33 +0000 Subject: Interactions between memory segments and byte buffers In-Reply-To: References: Message-ID: <95f4413a-287a-7e8d-5f6f-e77ff1078c2a@oracle.com> On 12/01/2021 14:07, Chris Vest wrote: > Hi, > > In our (Netty) experimentation with foreign-memaccess, we have looked into > how memory segments and byte buffers interact, because byte buffers are > still the currency for doing IO, and we have found some bugs, and also some > restrictions that we would prefer to have lifted. > > There are two issues we've identified. The less controversial one is that > when you create a ByteBuffer from a slice of a heap MemorySegments, the > buffer will get the base and capacity of the root (non-sliced) memory > segment. The created buffer is effectively not sliced. I see - that seems a bug, and also doesn't seem to honor the javadoc description of what the method does. > > This test fails for heap memory segments, but passes for native memory > segments: > > @Test > public void buffersAndArraysFromSlices() { > try (MemorySegment segment = MemorySegment.ofArray(new byte[16])) { > int newSize = 8; > var slice = segment.asSlice(4, newSize); > > var bytes = slice.toByteArray(); > assertEquals(newSize, bytes.length); > > var buffer = slice.asByteBuffer(); > // Fails for heap segments, but passes for native segments: > assertEquals(newSize, buffer.capacity()); > } > } > > The second issue is probably more controversial because it relates to this > passage in the MemorySegment.asByteBuffer javadoc: > > > > *If this segment is shared, calling certain I/O operations on the resulting > buffer might result in an unspecified exception being thrown. Examples of > such problematic operations > are FileChannel.read(ByteBuffer), FileChannel.write(ByteBuffer), > java.nio.channels.SocketChannel.read(ByteBuffer) and > java.nio.channels.SocketChannel.write(ByteBuffer).* > This is problematic for us because, considering our usage patterns we have > decided to use shared segments by default, and we need to create > ByteBuffers for doing IO via the safe JDK APIs. Yeah - this was a restriction that was added at the last minute; the plan is to have a way to re-enable these use cases, of course - but we need more time to think about consequences. The underlying issue here is that when you do async IO, the buffer is stored in a queue which is later consumed by other threads (in native code). Shared segments cannot guarantee that e.g. the segment won't be closed _in the middle_ of a native call - unless of course the native call occurs inside the TWR block of a given segment. If everything is confined of course there's no issue, since you can't close and execute native code at the same time. In other words, the only safe way by which a shared segment can be consumed by native code is if the shared segment does _not_ feature deterministic deallocation but is, instead, attached to a Cleaner (similar to what happens with byte buffer). For NIO we might be able to solve the issue by introducing an internal pinning API, to make sure the segment isn't closed in the middle of an IO operation. Maurizio > > There is also some additional fall-out from how this restriction is > implemented. For instance, if you get a ByteBuffer from a shared, native > memory segment, you cannot call asReadOnlyBuffer on that buffer. You also > cannot create slices of it. Perhaps there are other things as well. This > test demonstrates the problem: > > @Test > public void readOnlyByteBufferFromSharedNativeSegment() { > try (MemorySegment segment = MemorySegment.allocateNative(8).share()) { > var byteBuffer = segment.asByteBuffer(); > // This fails for native segments, but passes for heap segments. > // Throws UOE: ByteBuffer derived from shared segments not supported > byteBuffer.asReadOnlyBuffer(); > } > } > > I think this is an aspect of shared segments that is easy to miss. It would > be desirable if shared and confined segments behaved the same in this > regard; both for what ByteBuffer methods are available, and for the ability > to use buffers from shared native segments for IO. > > Thanks, > Chris From paul.sandoz at oracle.com Tue Jan 12 17:07:49 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 12 Jan 2021 09:07:49 -0800 Subject: VectorAPI and C2 compiler In-Reply-To: <20210111210700.GA3750256@pacoca> References: <20210111210700.GA3750256@pacoca> Message-ID: Hi Jose, Shifting over to panama-dev (bcc?ing discuss at openjdk.java.net ). Can you share a complete example on x86 that is not producing what you expect? I suspect in the PPC case some wiring up to the vector intrinsics are missing. Paul. > On Jan 11, 2021, at 1:07 PM, joserz at linux.ibm.com wrote: > > Hello team, > > I'm currently working on the VectorAPI support to PowerPC64 but none of my instructions, defined in ppc64.ad, gets executed. I decided to take a look at x86, but again no Vector instructions printed. > > Basically, I have a test case like this: > for (int j = 0; j < 1_000_000; j++) { > int[] iin128 = {25, -398, 415, Short.MAX_VALUE + 2}; > short[] sout64 = new short[ShortVector.SPECIES_64.length()]; > > vectorCastIntToShort(IntVector.SPECIES_128, > ShortVector.SPECIES_64, > iin128, sout64); > } > > That I execute like: > java -Xcomp -XX:-TieredCompilation -XX:CompileThreshold=1 \ > -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly \ > -XX:+PrintOptoAssembly -XX:+UnlockExperimentalVMOptions \ > -XX:+EnableVectorSupport -XX:+EnableVectorReboxing \ > -XX:+EnableVectorAggressiveReboxing -XX:UseAVX=2 Cast > > And expected to see any of `format %{ "vector_* ... %}` instructions, defined in x86.ad, being printed. > > Am I missing anything? > > Thank you, > > Jose R Ziviani From vladimir.x.ivanov at oracle.com Tue Jan 12 19:19:02 2021 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 12 Jan 2021 22:19:02 +0300 Subject: VectorAPI and C2 compiler In-Reply-To: <20210112191131.GA10518@pacoca> References: <20210111210700.GA3750256@pacoca> <20210112191131.GA10518@pacoca> Message-ID: Thanks for the test case, Jose. I see the following intrinsification failure when running it: 572 69 b Cast::vectorCastIntToShort (28 bytes) ** missing constant: opr=ConI vclass_from=ConP etype_from=ConP vlen_from=ConI vclass_to=ConP etype_to=ConP vlen_to=LoadI ... 128 jdk.internal.vm.vector.VectorSupport::convert (39 bytes) failed to inline (intrinsic) I'll take a look why it happens. Best regards, Vladimir Ivanov [1] java --add-modules jdk.incubator.vector -Xbatch -XX:+PrintCompilation -XX:-TieredCompilation -XX:CICompilerCount=1 -XX:+PrintInlining -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,*::vectorCastIntToShort -XX:+PrintIntrinsics Cast On 12.01.2021 22:11, joserz at linux.ibm.com wrote: > Hi Paul, > > Thank you for your response!! :-) > > This is my test case for x86 (basically got from VectorReshapeTests.java). > ``` > import java.io.IOException; > import java.util.Arrays; > import jdk.incubator.vector.IntVector; > import jdk.incubator.vector.ShortVector; > import jdk.incubator.vector.DoubleVector; > import jdk.incubator.vector.VectorSpecies; > import jdk.incubator.vector.LongVector; > > class Cast > { > static void vectorCastIntToShort(VectorSpecies i, > VectorSpecies s, > int[] input, > short[] output) > { > IntVector iv = IntVector.fromArray(i, input, 0); > ShortVector sv = (ShortVector) iv.castShape(s, 0); > sv.intoArray(output, 0); > } > > public static void main(String[] args) throws IOException > { > for (int j = 0; j < 1_000_000; j++) { > int[] iin128 = {25, -398, 415, Short.MAX_VALUE + 2}; > short[] sout64 = new short[ShortVector.SPECIES_64.length()]; > > vectorCastIntToShort(IntVector.SPECIES_128, > ShortVector.SPECIES_64, > iin128, sout64); > } > > //System.out.println(Arrays.toString(iin128)); > //System.out.println(Arrays.toString(sout64)); > } > } > ``` > > Then, after compiling and running like: > $ javac Cast.java > $ java -Xcomp -XX:-TieredCompilation -XX:CompileThreshold=1 -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:+PrintOptoAssembly -XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:+EnableVectorReboxing -XX:+EnableVectorAggressiveReboxing -XX:UseAVX=2 Cast > > I was expecting to see instructions from x86.ad, like "vector_cast_i2x" being printed but it seems that VectorCastI2X pattern isn't be generated because I see compiler C2 kicking in during the program execution. > > Thank you very much! > > Jose > > > On Tue, Jan 12, 2021 at 09:07:49AM -0800, Paul Sandoz wrote: >> Hi Jose, >> >> Shifting over to panama-dev (bcc?ing discuss at openjdk.java.net ). >> >> Can you share a complete example on x86 that is not producing what you expect? >> >> I suspect in the PPC case some wiring up to the vector intrinsics are missing. >> >> Paul. >> >>> On Jan 11, 2021, at 1:07 PM, joserz at linux.ibm.com wrote: >>> >>> Hello team, >>> >>> I'm currently working on the VectorAPI support to PowerPC64 but none of my instructions, defined in ppc64.ad, gets executed. I decided to take a look at x86, but again no Vector instructions printed. >>> >>> Basically, I have a test case like this: >>> for (int j = 0; j < 1_000_000; j++) { >>> int[] iin128 = {25, -398, 415, Short.MAX_VALUE + 2}; >>> short[] sout64 = new short[ShortVector.SPECIES_64.length()]; >>> >>> vectorCastIntToShort(IntVector.SPECIES_128, >>> ShortVector.SPECIES_64, >>> iin128, sout64); >>> } >>> >>> That I execute like: >>> java -Xcomp -XX:-TieredCompilation -XX:CompileThreshold=1 \ >>> -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly \ >>> -XX:+PrintOptoAssembly -XX:+UnlockExperimentalVMOptions \ >>> -XX:+EnableVectorSupport -XX:+EnableVectorReboxing \ >>> -XX:+EnableVectorAggressiveReboxing -XX:UseAVX=2 Cast >>> >>> And expected to see any of `format %{ "vector_* ... %}` instructions, defined in x86.ad, being printed. >>> >>> Am I missing anything? >>> >>> Thank you, >>> >>> Jose R Ziviani >> From vladimir.x.ivanov at oracle.com Tue Jan 12 19:24:26 2021 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 12 Jan 2021 22:24:26 +0300 Subject: VectorAPI and C2 compiler In-Reply-To: References: <20210111210700.GA3750256@pacoca> <20210112191131.GA10518@pacoca> Message-ID: <56d505b7-7cdd-f36b-91c4-728fbc058f2c@oracle.com> False alarm. With small adjustments [1], all vector operations are intrinsified: static void test(int[] src, short[] dst) { vectorCastIntToShort(IntVector.SPECIES_128, ShortVector.SPECIES_64, src, dst); } $ jdk16/bin/java --add-modules jdk.incubator.vector -Xbatch -XX:+PrintCompilation -XX:-TieredCompilation -XX:CICompilerCount=1 -XX:+PrintInlining -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,*::test -XX:+PrintIntrinsics Cast ... 575 69 b Cast::test (12 bytes) @ 8 Cast::vectorCastIntToShort (28 bytes) inline (hot) ... @ 31 jdk.internal.vm.vector.VectorSupport::load (38 bytes) (intrinsic) ... @ 128 jdk.internal.vm.vector.VectorSupport::convert (39 bytes) (intrinsic) ... @ 42 jdk.internal.vm.vector.VectorSupport::store (38 bytes) (intrinsic) Best regards, Vladimir Ivanov [1] $ cat Cast.java import java.io.IOException; import java.util.Arrays; import jdk.incubator.vector.IntVector; import jdk.incubator.vector.ShortVector; import jdk.incubator.vector.DoubleVector; import jdk.incubator.vector.VectorSpecies; import jdk.incubator.vector.LongVector; class Cast { static void vectorCastIntToShort(VectorSpecies i, VectorSpecies s, int[] input, short[] output) { IntVector iv = IntVector.fromArray(i, input, 0); ShortVector sv = (ShortVector) iv.castShape(s, 0); sv.intoArray(output, 0); } static void test(int[] src, short[] dst) { vectorCastIntToShort(IntVector.SPECIES_128, ShortVector.SPECIES_64, src, dst); } public static void main(String[] args) throws IOException { int[] iin128 = {25, -398, 415, Short.MAX_VALUE + 2}; short[] sout64 = new short[ShortVector.SPECIES_64.length()]; for (int j = 0; j < 1_000_000; j++) { test(iin128, sout64); } } } On 12.01.2021 22:19, Vladimir Ivanov wrote: > Thanks for the test case, Jose. > > I see the following intrinsification failure when running it: > > ??? 572?? 69??? b??????? Cast::vectorCastIntToShort (28 bytes) > ? ** missing constant: opr=ConI vclass_from=ConP etype_from=ConP > vlen_from=ConI vclass_to=ConP etype_to=ConP vlen_to=LoadI > > ... > > 128?? jdk.internal.vm.vector.VectorSupport::convert (39 bytes)?? failed > to inline (intrinsic) > > I'll take a look why it happens. > > Best regards, > Vladimir Ivanov > > [1] java --add-modules jdk.incubator.vector -Xbatch > -XX:+PrintCompilation -XX:-TieredCompilation -XX:CICompilerCount=1 > -XX:+PrintInlining -XX:CompileCommand=quiet > -XX:CompileCommand=compileonly,*::vectorCastIntToShort > -XX:+PrintIntrinsics Cast > > On 12.01.2021 22:11, joserz at linux.ibm.com wrote: >> Hi Paul, >> >> Thank you for your response!! :-) >> >> This is my test case for x86 (basically got from >> VectorReshapeTests.java). >> ``` >> import java.io.IOException; >> import java.util.Arrays; >> import jdk.incubator.vector.IntVector; >> import jdk.incubator.vector.ShortVector; >> import jdk.incubator.vector.DoubleVector; >> import jdk.incubator.vector.VectorSpecies; >> import jdk.incubator.vector.LongVector; >> >> class Cast >> { >> ???? static void vectorCastIntToShort(VectorSpecies i, >> ????????????????????????????????????? VectorSpecies s, >> ????????????????????????????????????? int[] input, >> ????????????????????????????????????? short[] output) >> ???? { >> ???????? IntVector iv = IntVector.fromArray(i, input, 0); >> ???????? ShortVector sv = (ShortVector) iv.castShape(s, 0); >> ???????? sv.intoArray(output, 0); >> ???? } >> >> ???? public static void main(String[] args) throws IOException >> ???? { >> ???????? for (int j = 0; j < 1_000_000; j++) { >> ???????????? int[] iin128 = {25, -398, 415, Short.MAX_VALUE + 2}; >> ???????????? short[] sout64 = new short[ShortVector.SPECIES_64.length()]; >> >> ???????????? vectorCastIntToShort(IntVector.SPECIES_128, >> ????????????????????????????????? ShortVector.SPECIES_64, >> ????????????????????????????????? iin128, sout64); >> ???????? } >> >> ???????? //System.out.println(Arrays.toString(iin128)); >> ???????? //System.out.println(Arrays.toString(sout64)); >> ???? } >> } >> ``` >> >> Then, after compiling and running like: >> $ javac Cast.java >> $ java -Xcomp -XX:-TieredCompilation -XX:CompileThreshold=1 >> -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly >> -XX:+PrintOptoAssembly -XX:+UnlockExperimentalVMOptions >> -XX:+EnableVectorSupport -XX:+EnableVectorReboxing >> -XX:+EnableVectorAggressiveReboxing -XX:UseAVX=2 Cast >> >> I was expecting to see instructions from x86.ad, like >> "vector_cast_i2x" being printed but it seems that VectorCastI2X >> pattern isn't be generated because I see compiler C2 kicking in during >> the program execution. >> >> Thank you very much! >> >> Jose >> >> >> On Tue, Jan 12, 2021 at 09:07:49AM -0800, Paul Sandoz wrote: >>> Hi Jose, >>> >>> Shifting over to panama-dev (bcc?ing discuss at openjdk.java.net >>> ). >>> >>> Can you share a complete example on x86 that is not producing what >>> you expect? >>> >>> I suspect in the PPC case some wiring up to the vector intrinsics are >>> missing. >>> >>> Paul. >>> >>>> On Jan 11, 2021, at 1:07 PM, joserz at linux.ibm.com wrote: >>>> >>>> Hello team, >>>> >>>> I'm currently working on the VectorAPI support to PowerPC64 but none >>>> of my instructions, defined in ppc64.ad, gets executed. I decided to >>>> take a look at x86, but again no Vector instructions printed. >>>> >>>> Basically, I have a test case like this: >>>> ??????? for (int j = 0; j < 1_000_000; j++) { >>>> ??????????? int[] iin128 = {25, -398, 415, Short.MAX_VALUE + 2}; >>>> ??????????? short[] sout64 = new >>>> short[ShortVector.SPECIES_64.length()]; >>>> >>>> ??????????? vectorCastIntToShort(IntVector.SPECIES_128, >>>> ???????????????????????????????? ShortVector.SPECIES_64, >>>> ???????????????????????????????? iin128, sout64); >>>> ??????? } >>>> >>>> That I execute like: >>>> ??????? java -Xcomp -XX:-TieredCompilation -XX:CompileThreshold=1 \ >>>> ???????????? -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly \ >>>> ???????????? -XX:+PrintOptoAssembly -XX:+UnlockExperimentalVMOptions \ >>>> ???????????? -XX:+EnableVectorSupport -XX:+EnableVectorReboxing \ >>>> ???????????? -XX:+EnableVectorAggressiveReboxing -XX:UseAVX=2 Cast >>>> >>>> And expected to see any of `format %{ "vector_* ... %}` >>>> instructions, defined in x86.ad, being printed. >>>> >>>> Am I missing anything? >>>> >>>> Thank you, >>>> >>>> Jose R Ziviani >>> From joserz at linux.ibm.com Wed Jan 13 00:58:22 2021 From: joserz at linux.ibm.com (joserz at linux.ibm.com) Date: Tue, 12 Jan 2021 21:58:22 -0300 Subject: VectorAPI and C2 compiler In-Reply-To: <56d505b7-7cdd-f36b-91c4-728fbc058f2c@oracle.com> References: <20210111210700.GA3750256@pacoca> <20210112191131.GA10518@pacoca> <56d505b7-7cdd-f36b-91c4-728fbc058f2c@oracle.com> Message-ID: <20210113005822.GA50108@pacoca> Fantastic! Many thanks Vladimir and Paul!! Best regards, Jose R Ziviani On Tue, Jan 12, 2021 at 10:24:26PM +0300, Vladimir Ivanov wrote: > False alarm. > > With small adjustments [1], all vector operations are intrinsified: > > static void test(int[] src, short[] dst) { > vectorCastIntToShort(IntVector.SPECIES_128, > ShortVector.SPECIES_64, > src, dst); > > } > > $ jdk16/bin/java --add-modules jdk.incubator.vector -Xbatch > -XX:+PrintCompilation -XX:-TieredCompilation -XX:CICompilerCount=1 > -XX:+PrintInlining -XX:CompileCommand=quiet > -XX:CompileCommand=compileonly,*::test -XX:+PrintIntrinsics Cast > ... > > 575 69 b Cast::test (12 bytes) > @ 8 Cast::vectorCastIntToShort (28 bytes) inline (hot) > ... > @ 31 jdk.internal.vm.vector.VectorSupport::load (38 bytes) > (intrinsic) > ... > @ 128 jdk.internal.vm.vector.VectorSupport::convert (39 bytes) > (intrinsic) > ... > @ 42 jdk.internal.vm.vector.VectorSupport::store (38 bytes) > (intrinsic) > > > Best regards, > Vladimir Ivanov > > [1] $ cat Cast.java > import java.io.IOException; > import java.util.Arrays; > import jdk.incubator.vector.IntVector; > import jdk.incubator.vector.ShortVector; > import jdk.incubator.vector.DoubleVector; > import jdk.incubator.vector.VectorSpecies; > import jdk.incubator.vector.LongVector; > > class Cast > { > static void vectorCastIntToShort(VectorSpecies i, > VectorSpecies s, > int[] input, > short[] output) > { > IntVector iv = IntVector.fromArray(i, input, 0); > ShortVector sv = (ShortVector) iv.castShape(s, 0); > sv.intoArray(output, 0); > } > > static void test(int[] src, short[] dst) { > vectorCastIntToShort(IntVector.SPECIES_128, > ShortVector.SPECIES_64, > src, dst); > > } > > public static void main(String[] args) throws IOException { > int[] iin128 = {25, -398, 415, Short.MAX_VALUE + 2}; > short[] sout64 = new short[ShortVector.SPECIES_64.length()]; > > for (int j = 0; j < 1_000_000; j++) { > test(iin128, sout64); > } > } > } > > > > On 12.01.2021 22:19, Vladimir Ivanov wrote: > > Thanks for the test case, Jose. > > > > I see the following intrinsification failure when running it: > > > > ??? 572?? 69??? b??????? Cast::vectorCastIntToShort (28 bytes) > > ? ** missing constant: opr=ConI vclass_from=ConP etype_from=ConP > > vlen_from=ConI vclass_to=ConP etype_to=ConP vlen_to=LoadI > > > > ... > > > > 128?? jdk.internal.vm.vector.VectorSupport::convert (39 bytes)?? failed > > to inline (intrinsic) > > > > I'll take a look why it happens. > > > > Best regards, > > Vladimir Ivanov > > > > [1] java --add-modules jdk.incubator.vector -Xbatch > > -XX:+PrintCompilation -XX:-TieredCompilation -XX:CICompilerCount=1 > > -XX:+PrintInlining -XX:CompileCommand=quiet > > -XX:CompileCommand=compileonly,*::vectorCastIntToShort > > -XX:+PrintIntrinsics Cast > > > > On 12.01.2021 22:11, joserz at linux.ibm.com wrote: > > > Hi Paul, > > > > > > Thank you for your response!! :-) > > > > > > This is my test case for x86 (basically got from > > > VectorReshapeTests.java). > > > ``` > > > import java.io.IOException; > > > import java.util.Arrays; > > > import jdk.incubator.vector.IntVector; > > > import jdk.incubator.vector.ShortVector; > > > import jdk.incubator.vector.DoubleVector; > > > import jdk.incubator.vector.VectorSpecies; > > > import jdk.incubator.vector.LongVector; > > > > > > class Cast > > > { > > > ???? static void vectorCastIntToShort(VectorSpecies i, > > > ????????????????????????????????????? VectorSpecies s, > > > ????????????????????????????????????? int[] input, > > > ????????????????????????????????????? short[] output) > > > ???? { > > > ???????? IntVector iv = IntVector.fromArray(i, input, 0); > > > ???????? ShortVector sv = (ShortVector) iv.castShape(s, 0); > > > ???????? sv.intoArray(output, 0); > > > ???? } > > > > > > ???? public static void main(String[] args) throws IOException > > > ???? { > > > ???????? for (int j = 0; j < 1_000_000; j++) { > > > ???????????? int[] iin128 = {25, -398, 415, Short.MAX_VALUE + 2}; > > > ???????????? short[] sout64 = new short[ShortVector.SPECIES_64.length()]; > > > > > > ???????????? vectorCastIntToShort(IntVector.SPECIES_128, > > > ????????????????????????????????? ShortVector.SPECIES_64, > > > ????????????????????????????????? iin128, sout64); > > > ???????? } > > > > > > ???????? //System.out.println(Arrays.toString(iin128)); > > > ???????? //System.out.println(Arrays.toString(sout64)); > > > ???? } > > > } > > > ``` > > > > > > Then, after compiling and running like: > > > $ javac Cast.java > > > $ java -Xcomp -XX:-TieredCompilation -XX:CompileThreshold=1 > > > -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly > > > -XX:+PrintOptoAssembly -XX:+UnlockExperimentalVMOptions > > > -XX:+EnableVectorSupport -XX:+EnableVectorReboxing > > > -XX:+EnableVectorAggressiveReboxing -XX:UseAVX=2 Cast > > > > > > I was expecting to see instructions from x86.ad, like > > > "vector_cast_i2x" being printed but it seems that VectorCastI2X > > > pattern isn't be generated because I see compiler C2 kicking in > > > during the program execution. > > > > > > Thank you very much! > > > > > > Jose > > > > > > > > > On Tue, Jan 12, 2021 at 09:07:49AM -0800, Paul Sandoz wrote: > > > > Hi Jose, > > > > > > > > Shifting over to panama-dev (bcc?ing discuss at openjdk.java.net > > > > ). > > > > > > > > Can you share a complete example on x86 that is not producing > > > > what you expect? > > > > > > > > I suspect in the PPC case some wiring up to the vector > > > > intrinsics are missing. > > > > > > > > Paul. > > > > > > > > > On Jan 11, 2021, at 1:07 PM, joserz at linux.ibm.com wrote: > > > > > > > > > > Hello team, > > > > > > > > > > I'm currently working on the VectorAPI support to PowerPC64 > > > > > but none of my instructions, defined in ppc64.ad, gets > > > > > executed. I decided to take a look at x86, but again no > > > > > Vector instructions printed. > > > > > > > > > > Basically, I have a test case like this: > > > > > ??????? for (int j = 0; j < 1_000_000; j++) { > > > > > ??????????? int[] iin128 = {25, -398, 415, Short.MAX_VALUE + 2}; > > > > > ??????????? short[] sout64 = new > > > > > short[ShortVector.SPECIES_64.length()]; > > > > > > > > > > ??????????? vectorCastIntToShort(IntVector.SPECIES_128, > > > > > ???????????????????????????????? ShortVector.SPECIES_64, > > > > > ???????????????????????????????? iin128, sout64); > > > > > ??????? } > > > > > > > > > > That I execute like: > > > > > ??????? java -Xcomp -XX:-TieredCompilation -XX:CompileThreshold=1 \ > > > > > ???????????? -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly \ > > > > > ???????????? -XX:+PrintOptoAssembly -XX:+UnlockExperimentalVMOptions \ > > > > > ???????????? -XX:+EnableVectorSupport -XX:+EnableVectorReboxing \ > > > > > ???????????? -XX:+EnableVectorAggressiveReboxing -XX:UseAVX=2 Cast > > > > > > > > > > And expected to see any of `format %{ "vector_* ... %}` > > > > > instructions, defined in x86.ad, being printed. > > > > > > > > > > Am I missing anything? > > > > > > > > > > Thank you, > > > > > > > > > > Jose R Ziviani > > > > From maurizio.cimadamore at oracle.com Wed Jan 13 12:32:08 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 13 Jan 2021 12:32:08 +0000 Subject: Interactions between memory segments and byte buffers In-Reply-To: <95f4413a-287a-7e8d-5f6f-e77ff1078c2a@oracle.com> References: <95f4413a-287a-7e8d-5f6f-e77ff1078c2a@oracle.com> Message-ID: For the records, the two issues you reported (asByteBuffer not slicing, and asReadOnlyBuffer not working on buffers derived from shared segments) have been fixed in 16. Cheers Maurizio On 12/01/2021 14:40, Maurizio Cimadamore wrote: > > On 12/01/2021 14:07, Chris Vest wrote: >> Hi, >> >> In our (Netty) experimentation with foreign-memaccess, we have looked >> into >> how memory segments and byte buffers interact, because byte buffers are >> still the currency for doing IO, and we have found some bugs, and >> also some >> restrictions that we would prefer to have lifted. >> >> There are two issues we've identified. The less controversial one is >> that >> when you create a ByteBuffer from a slice of a heap MemorySegments, the >> buffer will get the base and capacity of the root (non-sliced) memory >> segment. The created buffer is effectively not sliced. > I see - that seems a bug, and also doesn't seem to honor the javadoc > description of what the method does. >> >> This test fails for heap memory segments, but passes for native memory >> segments: >> >> @Test >> public void buffersAndArraysFromSlices() { >> ?? try (MemorySegment segment = MemorySegment.ofArray(new byte[16])) { >> ???? int newSize = 8; >> ???? var slice = segment.asSlice(4, newSize); >> >> ???? var bytes = slice.toByteArray(); >> ???? assertEquals(newSize, bytes.length); >> >> ???? var buffer = slice.asByteBuffer(); >> ???? // Fails for heap segments, but passes for native segments: >> ???? assertEquals(newSize, buffer.capacity()); >> ?? } >> } >> >> The second issue is probably more controversial because it relates to >> this >> passage in the MemorySegment.asByteBuffer javadoc: >> >> >> >> *If this segment is shared, calling certain I/O operations on the >> resulting >> buffer might result in an unspecified exception being thrown. >> Examples of >> such problematic operations >> are FileChannel.read(ByteBuffer), FileChannel.write(ByteBuffer), >> java.nio.channels.SocketChannel.read(ByteBuffer) and >> java.nio.channels.SocketChannel.write(ByteBuffer).* >> This is problematic for us because, considering our usage patterns we >> have >> decided to use shared segments by default, and we need to create >> ByteBuffers for doing IO via the safe JDK APIs. > > Yeah - this was a restriction that was added at the last minute; the > plan is to have a way to re-enable these use cases, of course - but we > need more time to think about consequences. > > The underlying issue here is that when you do async IO, the buffer is > stored in a queue which is later consumed by other threads (in native > code). Shared segments cannot guarantee that e.g. the segment won't be > closed _in the middle_ of a native call - unless of course the native > call occurs inside the TWR block of a given segment. If everything is > confined of course there's no issue, since you can't close and execute > native code at the same time. > > In other words, the only safe way by which a shared segment can be > consumed by native code is if the shared segment does _not_ feature > deterministic deallocation but is, instead, attached to a Cleaner > (similar to what happens with byte buffer). For NIO we might be able > to solve the issue by introducing an internal pinning API, to make > sure the segment isn't closed in the middle of an IO operation. > > Maurizio > >> >> There is also some additional fall-out from how this restriction is >> implemented. For instance, if you get a ByteBuffer from a shared, native >> memory segment, you cannot call asReadOnlyBuffer on that buffer. You >> also >> cannot create slices of it. Perhaps there are other things as well. This >> test demonstrates the problem: >> >> @Test >> public void readOnlyByteBufferFromSharedNativeSegment() { >> ?? try (MemorySegment segment = >> MemorySegment.allocateNative(8).share()) { >> ???? var byteBuffer = segment.asByteBuffer(); >> ???? // This fails for native segments, but passes for heap segments. >> ???? // Throws UOE: ByteBuffer derived from shared segments not >> supported >> ???? byteBuffer.asReadOnlyBuffer(); >> ?? } >> } >> >> I think this is an aspect of shared segments that is easy to miss. It >> would >> be desirable if shared and confined segments behaved the same in this >> regard; both for what ByteBuffer methods are available, and for the >> ability >> to use buffers from shared native segments for IO. > >> >> Thanks, >> Chris From leerho at gmail.com Wed Jan 13 22:04:07 2021 From: leerho at gmail.com (leerho) Date: Wed, 13 Jan 2021 14:04:07 -0800 Subject: which download? Message-ID: Which Download should I use for the latest Panama code? 1. https://jdk.java.net/16/ Build 31, Dated 2021/1/6 2. https://jdk.java.net/panama/ Build 16-panama+3-385 (2020/12/10) If I should use #2, where do I find the corresponding source and Javadoc? Lee. From maurizio.cimadamore at oracle.com Thu Jan 14 10:39:50 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 14 Jan 2021 10:39:50 +0000 Subject: which download? In-Reply-To: References: Message-ID: <5c3a5dff-4806-b1e3-d619-f04ebfa3c7ba@oracle.com> The two builds are very similar API-wise. The main difference is that #2 has jextract while #1 has not. If you just want to play with the memory access API/linker, using 16 would be fine. I will get the javadoc link for #2 fixed - we do have them internally, but they were not included in the download page - our bad. Thanks Maurizio On 13/01/2021 22:04, leerho wrote: > Which Download should I use for the latest Panama code? > > 1. https://jdk.java.net/16/ Build 31, > Dated 2021/1/6 > 2. https://jdk.java.net/panama/ Build 16-panama+3-385 (2020/12/10) > > If I should use #2, where do I find the corresponding source and Javadoc? > > Lee. From jvernee at openjdk.java.net Thu Jan 14 19:03:31 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 14 Jan 2021 19:03:31 GMT Subject: [foreign-jextract] RFR: 8252759: Jextract flattens nested anonymous structs and unions when computing layouts Message-ID: Hi, This patch changes the way jextract handles nested structs and unions. Currently, when encountering an anonymous struct or union, jextract folds it's fields into the parent layout. But, this can lead to incorrect layouts, especially for unions. e.g. see the following example: struct Foo { int x; union { int y; int z; }; }; becomes: static final MemoryLayout Foo$struct$LAYOUT_ = MemoryLayout.ofStruct( C_INT.withName("x"), C_INT.withName("y"), C_INT.withName("z") ).withName("Foo"); In this case, the offset of the `z` field will not be correct. This patch changes the jextract behaviour to preserve the nested layouts of anonymous unions and structs, so the example becomes: static final MemoryLayout Foo$struct$LAYOUT_ = MemoryLayout.ofStruct( C_INT.withName("x"), MemoryLayout.ofUnion( C_INT.withName("y"), C_INT.withName("z") ).withName("$anon$0") ).withName("Foo"); Here, the anonymous layout gets a generated name which is needed so that the `y` and `z` fields can still be reached from the root layout with layout paths to create var handles for instance. Just the layout is changed, the Foo java class that we generate still has getters and setters for `y` and `z`. In the patch this behaviour is implemented by temporarily adding a 'prefix' (`"$anon$0"` in this case) to the `StructBuilder`, which is used in the generated layout paths to reach the nested fields. Thanks, Jorn ------------- Commit messages: - Tabs to spaces - Add test for nested anonymous unions - Don't fold anonymous struct/union layouts into the parent layout Changes: https://git.openjdk.java.net/panama-foreign/pull/434/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=434&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252759 Stats: 229 lines in 10 files changed: 169 ins; 2 del; 58 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/434.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/434/head:pull/434 PR: https://git.openjdk.java.net/panama-foreign/pull/434 From sebastian.stenzel at gmail.com Thu Jan 14 21:34:27 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Thu, 14 Jan 2021 22:34:27 +0100 Subject: jextract: offset not multiple of alignment, causing ExceptionInInitializerError Message-ID: <8F1A859E-A71F-4C0F-ABC6-ADB51CAD037A@gmail.com> Hey, Today I noticed a strange problem related to the MemoryLayout generated by jextract for the following struct: ``` struct log2phys { u_int32_t l2p_flags; off_t l2p_contigbytes; off_t l2p_devoffset; }; ``` The generated layout looks like this: ``` static final MemoryLayout log2phys$struct$LAYOUT_ = MemoryLayout.ofStruct( C_INT.withName("l2p_flags"), C_LONG_LONG.withName("l2p_contigbytes"), C_LONG_LONG.withName("l2p_devoffset") ).withName("log2phys"); ``` During runtime, when the class was loaded and the VarHandle for "l2p_contigbytes" was created, I got the following exception: Exception in thread "main" java.lang.ExceptionInInitializerError at com.example.fuse_h$fuse_operations.$LAYOUT(fuse_h.java:14808) at com.example.fuse_h$fuse_operations.allocate(fuse_h.java:16294) ... Caused by: java.lang.UnsupportedOperationException: Invalid alignment requirements for layout b64(l2p_contigbytes)[abi/kind=LONG_LONG,layout/name=l2p_contigbytes] at jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.checkAlignment(LayoutPath.java:273) at jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.dereferenceHandle(LayoutPath.java:159) at jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.lambda$varHandle$2(MemoryLayout.java:488) at jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.computePathOp(MemoryLayout.java:538) at jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.varHandle(MemoryLayout.java:488) at com.example.fuse_h_constants_1.(fuse_h_constants_1.java:1921) ... 5 more I set a breakpoint at LayoutPath.checkAlignment and can tell that "l2p_contigbytes" has an offset of 32 bit (sounds reasonable) but an alignment of 64 bit. I have no idea, what all this means, but apparently it is invalid. I were able to avoid this error in my test project, but I thought I'd better report this in case there is something wrong, as I can see nothing special about aforementioned struct. Let me know if I can provide any further information! Sebastian From maurizio.cimadamore at oracle.com Thu Jan 14 22:01:44 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 14 Jan 2021 22:01:44 +0000 Subject: jextract: offset not multiple of alignment, causing ExceptionInInitializerError In-Reply-To: <8F1A859E-A71F-4C0F-ABC6-ADB51CAD037A@gmail.com> References: <8F1A859E-A71F-4C0F-ABC6-ADB51CAD037A@gmail.com> Message-ID: <11b37ba8-9312-e255-bd56-d5b794c86bf5@oracle.com> That layout looks odd/wrong. It seems like there might be some padding missing. Note that you have a 64 bit field that is not 64 bit aligned - so accessing it might be slower. I believe in most compilers 32 bit of padding would be inserted. Or, if this is really the way the struct is laid out, jextract should have relaxed the alignment requirements for "l2p_contigbytes". As it stands, the jextract layout seems bogus. If you have access to the code, I'd suggest adding: C_LONG_LONG.withName("l2p_contigbytes").withAlignmentBits(32) This should allow you to initialize correctly. Maurizio On 14/01/2021 21:34, Sebastian Stenzel wrote: > Hey, > > Today I noticed a strange problem related to the MemoryLayout generated by jextract for the following struct: > > ``` > struct log2phys { > u_int32_t l2p_flags; > off_t l2p_contigbytes; > off_t l2p_devoffset; > }; > ``` > > The generated layout looks like this: > > ``` > static final MemoryLayout log2phys$struct$LAYOUT_ = MemoryLayout.ofStruct( > C_INT.withName("l2p_flags"), > C_LONG_LONG.withName("l2p_contigbytes"), > C_LONG_LONG.withName("l2p_devoffset") > ).withName("log2phys"); > ``` > > During runtime, when the class was loaded and the VarHandle for "l2p_contigbytes" was created, I got the following exception: > > Exception in thread "main" java.lang.ExceptionInInitializerError > at com.example.fuse_h$fuse_operations.$LAYOUT(fuse_h.java:14808) > at com.example.fuse_h$fuse_operations.allocate(fuse_h.java:16294) > ... > Caused by: java.lang.UnsupportedOperationException: Invalid alignment requirements for layout b64(l2p_contigbytes)[abi/kind=LONG_LONG,layout/name=l2p_contigbytes] > at jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.checkAlignment(LayoutPath.java:273) > at jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.dereferenceHandle(LayoutPath.java:159) > at jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.lambda$varHandle$2(MemoryLayout.java:488) > at jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.computePathOp(MemoryLayout.java:538) > at jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.varHandle(MemoryLayout.java:488) > at com.example.fuse_h_constants_1.(fuse_h_constants_1.java:1921) > ... 5 more > > I set a breakpoint at LayoutPath.checkAlignment and can tell that "l2p_contigbytes" has an offset of 32 bit (sounds reasonable) but an alignment of 64 bit. I have no idea, what all this means, but apparently it is invalid. > > I were able to avoid this error in my test project, but I thought I'd better report this in case there is something wrong, as I can see nothing special about aforementioned struct. > > Let me know if I can provide any further information! > > Sebastian From github.com+7535718+rsmogura at openjdk.java.net Thu Jan 14 22:40:25 2021 From: github.com+7535718+rsmogura at openjdk.java.net (Radoslaw Smogura) Date: Thu, 14 Jan 2021 22:40:25 GMT Subject: [foreign-memaccess+abi] RFR: Make `UNSAFE` variable static final Message-ID: Make `UNSAFE` static final, to avoid null checks and traps. ------------- Commit messages: - Make `UNSAFE` variable static final Changes: https://git.openjdk.java.net/panama-foreign/pull/436/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=436&range=00 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/436.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/436/head:pull/436 PR: https://git.openjdk.java.net/panama-foreign/pull/436 From github.com+7535718+rsmogura at openjdk.java.net Thu Jan 14 23:15:22 2021 From: github.com+7535718+rsmogura at openjdk.java.net (Radoslaw Smogura) Date: Thu, 14 Jan 2021 23:15:22 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted Message-ID: This changes removes (by making no-ops) range and temporal checks for `ofNativeRestricted` segment. As this segment is global, above checks are not needed. Generated native code is smaller, and execution outperforms Java native arrays (depending on CPU) Changed Benchmark Mode Cnt Score Error Units AccessBenchmark.foreignAddress thrpt 5 128946129.691 ? 317433.113 ops/s AccessBenchmark.foreignAddressRaw thrpt 5 136883439.221 ? 749390.255 ops/s AccessBenchmark.target thrpt 5 125325586.957 ? 32129.931 ops/s Base Benchmark Mode Cnt Score Error Units AccessBenchmark.foreignAddress thrpt 5 125257424.876 ? 230508.169 ops/s AccessBenchmark.foreignAddressRaw thrpt 5 128818591.434 ? 241806.765 ops/s AccessBenchmark.target thrpt 5 125083379.819 ? 184070.467 ops/s --- This PR is replacement for https://github.com/openjdk/panama-foreign/pull/431 (OCA) and was partially discussed (before changes) in https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011747.htm --- Benchmark @State(Scope.Thread) public class AccessBenchmark { static final MemorySegment ms = MemorySegment.ofNativeRestricted(); static final VarHandle intHandle = MemoryHandles.varHandle(int.class, ByteOrder.nativeOrder()); int[] intData = new int[12]; volatile int intDataOffset = 0; volatile MemoryAddress address; volatile long addressRaw; @Setup public void setup() { var ms = MemorySegment.allocateNative(256); address = ms.address(); addressRaw = address.toRawLongValue(); } @Benchmark public void target(Blackhole bh) { int[] local = intData; int localOffset = intDataOffset; bh.consume(local[localOffset]); bh.consume(local[localOffset + 1]); } @Benchmark public void foreignAddress(Blackhole bh) { var a = address; bh.consume((int) intHandle.get(ms, a.addOffset(0).toRawLongValue())); bh.consume((int) intHandle.get(ms, a.addOffset(4).toRawLongValue())); } @Benchmark public void foreignAddressRaw(Blackhole bh) { var a = addressRaw; bh.consume((int) intHandle.get(ms, a)); bh.consume((int) intHandle.get(ms, a + 4)); } } ------------- Commit messages: - Naming & comments redaction - Revert "Next iteration of tuning" - Next iteration of tuning - Performance improvement to unchecked segment ofNativeRestricted Changes: https://git.openjdk.java.net/panama-foreign/pull/437/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=437&range=00 Stats: 52 lines in 1 file changed: 49 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/437.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/437/head:pull/437 PR: https://git.openjdk.java.net/panama-foreign/pull/437 From github.com+7535718+rsmogura at openjdk.java.net Thu Jan 14 23:24:23 2021 From: github.com+7535718+rsmogura at openjdk.java.net (Radoslaw Smogura) Date: Thu, 14 Jan 2021 23:24:23 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v2] In-Reply-To: References: Message-ID: > This changes removes (by making no-ops) range and temporal checks for `ofNativeRestricted` segment. As this segment is global, above checks are not needed. > > Generated native code is smaller, and execution outperforms Java native arrays (depending on CPU) > Changed > Benchmark Mode Cnt Score Error Units > AccessBenchmark.foreignAddress thrpt 5 128946129.691 ? 317433.113 ops/s > AccessBenchmark.foreignAddressRaw thrpt 5 136883439.221 ? 749390.255 ops/s > AccessBenchmark.target thrpt 5 125325586.957 ? 32129.931 ops/s > Base > Benchmark Mode Cnt Score Error Units > AccessBenchmark.foreignAddress thrpt 5 125257424.876 ? 230508.169 ops/s > AccessBenchmark.foreignAddressRaw thrpt 5 128818591.434 ? 241806.765 ops/s > AccessBenchmark.target thrpt 5 125083379.819 ? 184070.467 ops/s > --- > This PR is replacement for https://github.com/openjdk/panama-foreign/pull/431 (OCA) > and was partially discussed (before changes) in https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011747.htm > > --- > Benchmark > @State(Scope.Thread) > public class AccessBenchmark { > static final MemorySegment ms = MemorySegment.ofNativeRestricted(); > static final VarHandle intHandle = MemoryHandles.varHandle(int.class, ByteOrder.nativeOrder()); > > int[] intData = new int[12]; > volatile int intDataOffset = 0; > > volatile MemoryAddress address; > volatile long addressRaw; > > @Setup > public void setup() { > var ms = MemorySegment.allocateNative(256); > address = ms.address(); > addressRaw = address.toRawLongValue(); > } > > @Benchmark > public void target(Blackhole bh) { > int[] local = intData; > int localOffset = intDataOffset; > bh.consume(local[localOffset]); > bh.consume(local[localOffset + 1]); > } > > @Benchmark > public void foreignAddress(Blackhole bh) { > var a = address; > bh.consume((int) intHandle.get(ms, a.addOffset(0).toRawLongValue())); > bh.consume((int) intHandle.get(ms, a.addOffset(4).toRawLongValue())); > } > > @Benchmark > public void foreignAddressRaw(Blackhole bh) { > var a = addressRaw; > bh.consume((int) intHandle.get(ms, a)); > bh.consume((int) intHandle.get(ms, a + 4)); > } > } Radoslaw Smogura has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains four new commits since the last revision: - Small naming & comments improvements. - Revert "Next iteration of tuning" This change was introduced as it was found that JVM makes null check and inlines empty method. However right now this phenomen can't be see, so reverting this as it can generate number of NPE. This reverts commit 9e29818b8a2f4ba3a3bec8a1edace072c993ccd4. - Next iteration of tuning After checking source code it looks like that better is to set scope to `null`. The results outpaced the Java array access. ``` Benchmark Mode Cnt Score Error Units AccessBenchmark.foreignAddress thrpt 4 86860188.499 ? 13454393.406 ops/s AccessBenchmark.foreignAddressRaw thrpt 4 96150181.668 ? 7025145.700 ops/s AccessBenchmark.target thrpt 4 93673099.539 ? 23272596.145 ops/s``` versus tests on original repo ``` Benchmark Mode Cnt Score Error Units AccessBenchmark.foreignAddress thrpt 4 81907199.092 ? 2663269.652 ops/s AccessBenchmark.foreignAddressRaw thrpt 4 83629168.611 ? 1025857.535 ops/s AccessBenchmark.target thrpt 4 94023553.582 ? 6128411.421 ops/s ``` # Benchmark code ``` State(Scope.Thread) public class AccessBenchmark { static final MemorySegment ms = MemorySegment.ofNativeRestricted(); static final VarHandle intHandle = MemoryHandles.varHandle(int.class, ByteOrder.nativeOrder()); int[] intData = new int[12]; volatile int intDataOffset = 0; volatile MemoryAddress address; volatile long addressRaw; @Setup public void setup() { var ms = MemorySegment.allocateNative(256); address = ms.address(); addressRaw = address.toRawLongValue(); } @Benchmark public void target(Blackhole bh) { int[] local = intData; int localOffset = intDataOffset; bh.consume(local[localOffset]); bh.consume(local[localOffset + 1]); } @Benchmark public void foreignAddress(Blackhole bh) { var a = address; bh.consume((int) intHandle.get(ms, a.addOffset(0).toRawLongValue())); bh.consume((int) intHandle.get(ms, a.addOffset(4).toRawLongValue())); } @Benchmark public void foreignAddressRaw(Blackhole bh) { var a = addressRaw; bh.consume((int) intHandle.get(ms, a)); bh.consume((int) intHandle.get(ms, a + 4)); } } ``` - [WIP] Performance improvement to unchecked segment ofNativeRestricted Accessing native memory using ofNativeRestricted could generate range and temporal checkes. As this scope can't be closed and represents whole memory, above checks are not needed, and are |leftoevers| from NativeMemorySegmentImpl. Thus to overcome this, I adding special segment & scope to allow hotspot better optimize code would be a good solution. The JMH benchmarks baselined to peformance of plain array access, shown improvement from 89% of array access to 94% of it (% = foreignAddress / target) Improved version ``` Benchmark Mode Cnt Score Error Units AccessBenchmark.foreignAddress thrpt 4 87981021.113 ? 4496953.479 ops/s AccessBenchmark.target thrpt 4 92840761.490 ? 15994108.441 ops/s ``` Original version ``` Benchmark Mode Cnt Score Error Units AccessBenchmark.foreignAddress thrpt 4 82076915.820 ? 3076568.791 ops/s AccessBenchmark.target thrpt 4 91962637.002 ? 5104697.571 ops/s ``` ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/437/files - new: https://git.openjdk.java.net/panama-foreign/pull/437/files/98ad3a9c..c7d4fdf1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=437&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=437&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/437.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/437/head:pull/437 PR: https://git.openjdk.java.net/panama-foreign/pull/437 From mail at smogura.eu Thu Jan 14 23:31:19 2021 From: mail at smogura.eu (=?windows-1250?Q?Rados=B3aw_Smogura?=) Date: Thu, 14 Jan 2021 23:31:19 +0000 Subject: ODP: Performance improvement to unchecked segment ofNativeRestricted In-Reply-To: <896bfd5c-83de-ba6c-cb72-e5fc051a0e3a@oracle.com> References: , <896bfd5c-83de-ba6c-cb72-e5fc051a0e3a@oracle.com> Message-ID: Hi all, This check (if / trap from JVM) is quite interesting, as I can understand logic behind it, and I can't recreate it. However meantime, I pushed this change officially, and as well found some other minor thing. Thanks for feedback and have a good day. Kind regards, Rado Od: Maurizio Cimadamore Wys?ane: czwartek, 7 stycznia 2021 23:25 Do: Rados?aw Smogura ; panama-dev at openjdk.java.net DW: Ty Young Temat: Re: Performance improvement to unchecked segment ofNativeRestricted ? On 07/01/2021 22:09, Rados?aw Smogura wrote: > Hi all, > > Thanks for feedback, and good to hear it's a good direction. > > In fact my first change included a global scope, as Maurizio suggested. I added this null scope, as I have impression I constantly hit this check >????? private int getIntUnalignedInternal(Scope scope, Object base, long offset, boolean be) { >????????? /* ...*/ >????????????? if (scope != null) { >????????????????? scope.checkValidState(); >????????????? } >??????? /* ... */ >????? } > And I could not understand why hotspot leaves scope != null, and inlines empty method ('else' part looked more like jump to a trap). Now, I tired to use IGV to understand why, rebased one commit back, and it's ok... Could it be that maybe you hit this compiled method from two places - one where scope == null and one where scope != null, but then the scope check is trivial (because of your NullScope). This could happen e.g. if your code is also using other APIs such as ByteBuffer heavily enough to trigger compilation of this method. That said, to overcome these issues, we turned on sharp profiling and inlining on all these ScopedMemoryAccess methods, so pollution shouldn't be a problem, especially cross API. Let us know if you find anything interesting! Thanks Maurizio > > I'll update? branch, back-up original one, take closer look again, clean it, and come back later. > > Thanks again for checks, and sorry for not needed bother. > > Kind regards, > Rado > >> I think the fundamental idea is solid, and I agree there's room to >> improve performance here, but as Ty notes, having a NULL scope might be >> problematic. I think it would perhaps be better to have a >> constant/stateless, always open scope, whose checkValidState method does >> nothing? If that scope is stored in a final static constant, I believe >> C2 will not have many problems in eliminating the overhead of the scope >> check. >> >> Maurizio >> >> On 06/01/2021 01:59, Ty Young wrote: >>> You may also need to override checkValidState from >>> AbstractMemorySegmentImpl in EverythingSegment. checkValidState calls >>> the scope's checkValidState and since scope is null, you'll get a NPE. >>> The list of methods that call checkValidState include: >>> >>> >>> splitterator >>> >>> mismatch >>> >>> address >>> >>> handoff >>> >>> share >>> >>> registerCleaner >>> >>> close >>> >>> >>> In short, if you do basically anything but simply read/write via >>> VarHandle, including native library usage which uses address(), you're >>> going to get a NPE. >>> >>> >>> >>> On 1/5/21 4:32 PM, Rados?aw Smogura wrote: >>>> Hi all, >>>> >>>> I hope you have a good day. >>>> >>>> Here I would like to present some changes to increase performance of >>>> ofNativeRestricted - my benchmarks - where I tried to simulate access >>>> from code - outpaced the access to Java array (as intended). As it >>>> looks like that pull request flow has changed, I have to sign-up OCA >>>> (and if this change is fine I would be happy to do this). >>>> >>>> Below please find benchmark results and link to "pending PR" / branch >>>> >>>> The results outpaced the Java array access. >>>> >>>> Benchmark?????????????????????????? Mode? Cnt Score????????? Error >>>> Units >>>> AccessBenchmark.foreignAddress???? thrpt??? 4? 86860188.499 ? >>>> 13454393.406? ops/s >>>> AccessBenchmark.foreignAddressRaw? thrpt??? 4? 96150181.668 ? >>>> 7025145.700? ops/s >>>> AccessBenchmark.target???????????? thrpt??? 4? 93673099.539 ? >>>> 23272596.145? ops/s``` >>>> >>>> versus tests on original repo >>>> >>>> Benchmark?????????????????????????? Mode? Cnt Score???????? Error? Units >>>> AccessBenchmark.foreignAddress???? thrpt??? 4? 81907199.092 ? >>>> 2663269.652? ops/s >>>> AccessBenchmark.foreignAddressRaw? thrpt??? 4? 83629168.611 ? >>>> 1025857.535? ops/s >>>> AccessBenchmark.target???????????? thrpt??? 4? 94023553.582 ? >>>> 6128411.421? ops/s >>>> >>>> https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign/pull/431__;!!GqivPVa7Brio!NjDzQjnuIfj8QDuZCy61K8fphZLKHZwMwp7YYRxaKinV1vUfDCsDzW1h_fk0t0hemqPqIyg$ >>>> [https://urldefense.com/v3/__https://avatars2.githubusercontent.com/u/41768318?s=400&v=4__;!!GqivPVa7Brio!NjDzQjnuIfj8QDuZCy61K8fphZLKHZwMwp7YYRxaKinV1vUfDCsDzW1h_fk0t0hecmGoyf0$ ] >>>> >>>> [WIP] Performance improvement to unchecked segment ofNativeRestricted >>>> by rsmogura ? Pull Request #431 ? >>>> openjdk/panama-foreign >>>> Here's a proposition to tune the access to global scope. This >>>> changes, could help to outpace the access to Java arrays using [] >>>> operator. The results outpaced the Java array access. Benchmark ... >>>> github.com >>>> >>>> Kind regards, >>>> Rado From sebastian.stenzel at gmail.com Fri Jan 15 08:31:17 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Fri, 15 Jan 2021 09:31:17 +0100 Subject: jextract: offset not multiple of alignment, causing ExceptionInInitializerError In-Reply-To: <11b37ba8-9312-e255-bd56-d5b794c86bf5@oracle.com> References: <8F1A859E-A71F-4C0F-ABC6-ADB51CAD037A@gmail.com> <11b37ba8-9312-e255-bd56-d5b794c86bf5@oracle.com> Message-ID: I had another look at the original header file (macOS: usr/include/sys/fcntl.h). Turns out, this struct is surrounded by a pack(4), which should explain this behaviour: #pragma pack(4) struct log2phys { unsigned int l2p_flags; /* unused so far */ off_t l2p_contigbytes; /* F_LOG2PHYS: unused so far */ /* F_LOG2PHYS_EXT: IN: number of bytes to be queried */ /* OUT: number of contiguous bytes at this position */ off_t l2p_devoffset; /* F_LOG2PHYS: OUT: bytes into device */ /* F_LOG2PHYS_EXT: IN: bytes into file */ /* OUT: bytes into device */ }; #pragma pack() Question is: Is jextract _expected_ to be aware of this? > On 14. Jan 2021, at 23:01, Maurizio Cimadamore wrote: > > That layout looks odd/wrong. > > It seems like there might be some padding missing. Note that you have a 64 bit field that is not 64 bit aligned - so accessing it might be slower. I believe in most compilers 32 bit of padding would be inserted. > > Or, if this is really the way the struct is laid out, jextract should have relaxed the alignment requirements for "l2p_contigbytes". As it stands, the jextract layout seems bogus. If you have access to the code, I'd suggest adding: > > C_LONG_LONG.withName("l2p_contigbytes").withAlignmentBits(32) > > This should allow you to initialize correctly. > > Maurizio > > On 14/01/2021 21:34, Sebastian Stenzel wrote: >> Hey, >> >> Today I noticed a strange problem related to the MemoryLayout generated by jextract for the following struct: >> >> ``` >> struct log2phys { >> u_int32_t l2p_flags; >> off_t l2p_contigbytes; >> off_t l2p_devoffset; >> }; >> ``` >> >> The generated layout looks like this: >> >> ``` >> static final MemoryLayout log2phys$struct$LAYOUT_ = MemoryLayout.ofStruct( >> C_INT.withName("l2p_flags"), >> C_LONG_LONG.withName("l2p_contigbytes"), >> C_LONG_LONG.withName("l2p_devoffset") >> ).withName("log2phys"); >> ``` >> >> During runtime, when the class was loaded and the VarHandle for "l2p_contigbytes" was created, I got the following exception: >> >> Exception in thread "main" java.lang.ExceptionInInitializerError >> at com.example.fuse_h$fuse_operations.$LAYOUT(fuse_h.java:14808) >> at com.example.fuse_h$fuse_operations.allocate(fuse_h.java:16294) >> ... >> Caused by: java.lang.UnsupportedOperationException: Invalid alignment requirements for layout b64(l2p_contigbytes)[abi/kind=LONG_LONG,layout/name=l2p_contigbytes] >> at jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.checkAlignment(LayoutPath.java:273) >> at jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.dereferenceHandle(LayoutPath.java:159) >> at jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.lambda$varHandle$2(MemoryLayout.java:488) >> at jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.computePathOp(MemoryLayout.java:538) >> at jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.varHandle(MemoryLayout.java:488) >> at com.example.fuse_h_constants_1.(fuse_h_constants_1.java:1921) >> ... 5 more >> >> I set a breakpoint at LayoutPath.checkAlignment and can tell that "l2p_contigbytes" has an offset of 32 bit (sounds reasonable) but an alignment of 64 bit. I have no idea, what all this means, but apparently it is invalid. >> >> I were able to avoid this error in my test project, but I thought I'd better report this in case there is something wrong, as I can see nothing special about aforementioned struct. >> >> Let me know if I can provide any further information! >> >> Sebastian From duke at openjdk.java.net Fri Jan 15 11:06:21 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 15 Jan 2021 11:06:21 GMT Subject: [foreign-jextract] RFR: Merge foreign-memaccess+abi Message-ID: <5D0uWYC_mTQ379o8XsfRRkhoKhvflMxRx7AkHAv3Sgk=.143ae13d-e3ce-4425-b1bd-ccea834997c2@github.com> Hi all, this is an _automatically_ generated pull request to notify you that there are 135 commits from the branch `foreign-memaccess+abi`that can **not** be merged into the branch `foreign-jextract`: The following file contains merge conflicts: - make/CompileJavaModules.gmk All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. # Ensure target branch is up to date $ git checkout foreign-jextract $ git pull https://github.com/openjdk/panama-foreign.git foreign-jextract # Fetch and checkout the branch for this pull request $ git fetch https://github.com/openjdk-bot/panama-foreign.git +89:openjdk-bot-89 $ git checkout openjdk-bot-89 # Merge the target branch $ git merge foreign-jextract When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: $ git add paths/to/files/with/conflicts $ git commit -m 'Merge foreign-memaccess+abi' When you have created the merge commit, run the following command to push the merge commit to this pull request: $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-89:89 _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. Thanks, J. Duke ------------- Commit messages: - Automatic merge of master into foreign-memaccess+abi - Automatic merge of jdk:master into master - 8258884: [TEST_BUG] Convert applet-based test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a regular java test - 8259627: Potential memory leaks in JVMTI after JDK-8227745 - 8259622: TreeMap.computeIfAbsent deviates from spec - Merge - 8253505: JFR: onFlush invoked out of order with a sorted event stream - 8255120: C2: assert(outer->outcnt() >= phis + 2 && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis - 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed - 8257736: InputStream from BodyPublishers.ofInputStream() leaks when IOE happens - ... and 125 more: https://git.openjdk.java.net/panama-foreign/compare/017bf202...e69b59e5 The webrev contains the conflicts with foreign-jextract: - merge conflicts: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=438&range=00.conflicts Changes: https://git.openjdk.java.net/panama-foreign/pull/438/files Stats: 28297 lines in 1075 files changed: 15713 ins; 7635 del; 4949 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/438.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/438/head:pull/438 PR: https://git.openjdk.java.net/panama-foreign/pull/438 From duke at openjdk.java.net Fri Jan 15 11:10:09 2021 From: duke at openjdk.java.net (duke) Date: Fri, 15 Jan 2021 11:10:09 GMT Subject: git: openjdk/panama-foreign: foreign-memaccess+abi: 135 new changesets Message-ID: <0af5ca59-8a1f-4d79-ab9f-9dbe66abea00@openjdk.org> Changeset: 697bf7ab Author: Guoxiong Li Committer: Vicente Romero Date: 2021-01-08 13:56:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/697bf7ab 8257740: Compiler crash when compiling type annotation on multicatch inside lambda Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/langtools/tools/javac/T8257740/T8257740_1.java + test/langtools/tools/javac/T8257740/T8257740_2.java Changeset: 6f7723b4 Author: Eric Caspole Date: 2021-01-08 14:18:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6f7723b4 8258792: LogCompilation: remove redundant check fixed by 8257518 Reviewed-by: kvn, redestad ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/LogCompilation.java Changeset: 10a6b0d9 Author: Kim Barrett Date: 2021-01-08 14:25:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/10a6b0d9 8234773: Fix ThreadsSMRSupport::_bootstrap_list Make ThreadsList noncopyable, direct initializing _bootstrap_list. Avoid C-heap allocation for _bootstrap_list. Reviewed-by: dholmes, dcubed ! src/hotspot/share/runtime/threadSMR.cpp ! src/hotspot/share/runtime/threadSMR.hpp Changeset: 090bd3af Author: Daniel D. Daugherty Date: 2021-01-08 15:30:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/090bd3af 8259397: ThreadsSMRSupport::print_info_on() should use try_lock_without_rank_check() Reviewed-by: coleenp, dholmes ! src/hotspot/share/runtime/threadSMR.cpp Changeset: 876c7fb5 Author: Roger Riggs Date: 2021-01-08 21:31:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/876c7fb5 8259493: [test] Use HexFormat instead of adhoc hex utilities in network code and locale SoftKeys Reviewed-by: lancea, naoto ! test/jdk/java/net/Authenticator/B6870935.java ! test/jdk/java/net/HttpURLConnection/SetAuthenticator/HTTPTestServer.java ! test/jdk/java/net/httpclient/DigestEchoServer.java ! test/jdk/java/util/Locale/SoftKeys.java ! test/jdk/sun/net/www/protocol/http/DigestTest.java Changeset: 628c546b Author: Roger Riggs Date: 2021-01-08 21:32:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/628c546b 8258796: [test] Apply HexFormat to tests for java.security Reviewed-by: xuelei ! test/jdk/com/sun/crypto/provider/Cipher/AEAD/SameBuffer.java ! test/jdk/com/sun/crypto/provider/Cipher/Blowfish/BlowfishTestVector.java ! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20KAT.java ! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20KeyGeneratorTest.java ! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20NoReuse.java ! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20Poly1305ParamTest.java ! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/ChaCha20CipherUnitTest.java ! test/jdk/com/sun/crypto/provider/KeyAgreement/DHKeyAgreement2.java ! test/jdk/com/sun/crypto/provider/KeyAgreement/DHKeyAgreement3.java ! test/jdk/com/sun/crypto/provider/KeyFactory/PBKDF2HmacSHA1FactoryTest.java ! test/jdk/com/sun/crypto/provider/TLS/TestLeadingZeroes.java ! test/jdk/java/security/KeyAgreement/KeySizeTest.java ! test/jdk/java/security/KeyAgreement/NegativeTest.java ! test/jdk/javax/crypto/SecretKeyFactory/SecKeyFacSunJCEPrf.java ! test/jdk/sun/security/ec/SignatureDigestTruncate.java ! test/jdk/sun/security/ec/SignatureKAT.java ! test/jdk/sun/security/ec/ed/EdDSAKeySize.java ! test/jdk/sun/security/ec/ed/EdDSANegativeTest.java ! test/jdk/sun/security/ec/ed/EdDSAParamSpec.java ! test/jdk/sun/security/ec/ed/EdDSATest.java ! test/jdk/sun/security/ec/ed/EdECKeyFormat.java ! test/jdk/sun/security/ec/ed/TestEdDSA.java ! test/jdk/sun/security/ec/ed/TestEdOps.java ! test/jdk/sun/security/ec/xec/TestXDH.java ! test/jdk/sun/security/ec/xec/TestXECOps.java ! test/jdk/sun/security/ec/xec/XECIterative.java ! test/jdk/sun/security/ec/xec/XECKeyFormat.java ! test/jdk/sun/security/krb5/RFC396xTest.java ! test/jdk/sun/security/krb5/auto/ReplayCacheTestProc.java ! test/jdk/sun/security/krb5/etype/KerberosAesSha2.java ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java ! test/jdk/sun/security/pkcs/pkcs8/PKCS8Test.java ! test/jdk/sun/security/pkcs11/tls/TestLeadingZeroesP11.java ! test/jdk/sun/security/provider/DSA/TestDSA.java ! test/jdk/sun/security/provider/MessageDigest/DigestKAT.java ! test/jdk/sun/security/rsa/SigRecord.java ! test/jdk/sun/security/rsa/TestSigGen15.java ! test/jdk/sun/security/rsa/pss/SigRecord.java ! test/jdk/sun/security/rsa/pss/TestSigGenPSS.java ! test/jdk/sun/security/util/math/TestIntegerModuloP.java ! test/jdk/sun/security/x509/X500Name/DerValueConstructor.java ! test/lib/jdk/test/lib/Convert.java ! test/lib/jdk/test/lib/Utils.java Changeset: 7e6677b5 Author: David Holmes Date: 2021-01-08 22:25:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e6677b5 8259446: runtime/jni/checked/TestCheckedReleaseArrayElements.java fails with stderr not empty Reviewed-by: dcubed ! test/hotspot/jtreg/runtime/jni/checked/TestCheckedReleaseArrayElements.java Changeset: a6539282 Author: Joe Darcy Date: 2021-01-09 00:03:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a6539282 8259512: Update --release 16 symbol information for JDK 16 build 31 Reviewed-by: jjg ! make/data/symbols/jdk.incubator.vector-G.sym.txt Changeset: 6472104e Author: Sergey Bylokhov Date: 2021-01-09 07:22:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6472104e 6278172: TextComponent.getSelectedText() throws StringIndexOutOfBoundsException Reviewed-by: aivanov ! src/java.desktop/share/classes/java/awt/TextComponent.java + test/jdk/java/awt/TextComponent/SetTextSelection.java Changeset: 5cfa8c94 Author: Martin Buchholz Date: 2021-01-09 20:57:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5cfa8c94 8246585: ForkJoin updates 8229253: forkjoin/FJExceptionTableLeak.java fails "AssertionError: failed to satisfy condition" Reviewed-by: dl ! src/java.base/share/classes/java/util/concurrent/CountedCompleter.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java + test/jdk/java/util/concurrent/forkjoin/AsyncShutdownNow.java + test/jdk/java/util/concurrent/forkjoin/AsyncShutdownNowInvokeAny.java + test/jdk/java/util/concurrent/forkjoin/AsyncShutdownNowInvokeAnyRace.java - test/jdk/java/util/concurrent/forkjoin/FJExceptionTableLeak.java ! test/jdk/java/util/concurrent/tck/ForkJoinTaskTest.java Changeset: 63e3bd76 Author: Martin Buchholz Date: 2021-01-09 21:08:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/63e3bd76 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates Reviewed-by: alanb, dl ! src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java ! test/jdk/java/util/concurrent/LinkedTransferQueue/WhiteBox.java Changeset: 270014ab Author: Martin Buchholz Date: 2021-01-09 21:59:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/270014ab 8234131: Miscellaneous changes imported from jsr166 CVS 2021-01 8257671: ThreadPoolExecutor.Discard*Policy: rejected tasks are not cancelled Reviewed-by: alanb, prappo, dl ! src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java ! src/java.base/share/classes/java/util/concurrent/CopyOnWriteArraySet.java ! src/java.base/share/classes/java/util/concurrent/CountDownLatch.java ! src/java.base/share/classes/java/util/concurrent/CyclicBarrier.java ! src/java.base/share/classes/java/util/concurrent/Exchanger.java ! src/java.base/share/classes/java/util/concurrent/ExecutorService.java ! src/java.base/share/classes/java/util/concurrent/Future.java ! src/java.base/share/classes/java/util/concurrent/Phaser.java ! src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/java.base/share/classes/java/util/concurrent/Semaphore.java ! src/java.base/share/classes/java/util/concurrent/SubmissionPublisher.java ! src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicBoolean.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/java.base/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java ! src/java.base/share/classes/java/util/concurrent/atomic/DoubleAdder.java ! src/java.base/share/classes/java/util/concurrent/atomic/LongAccumulator.java ! src/java.base/share/classes/java/util/concurrent/atomic/LongAdder.java ! src/java.base/share/classes/java/util/concurrent/atomic/Striped64.java ! src/java.base/share/classes/java/util/concurrent/atomic/package-info.java ! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java ! src/java.base/share/classes/java/util/concurrent/locks/ReentrantLock.java ! src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java ! src/java.base/share/classes/java/util/concurrent/locks/StampedLock.java ! test/jdk/java/util/Collection/IteratorMicroBenchmark.java ! test/jdk/java/util/concurrent/ExecutorService/Invoke.java ! test/jdk/java/util/concurrent/tck/ArrayBlockingQueueTest.java ! test/jdk/java/util/concurrent/tck/ArrayDequeTest.java ! test/jdk/java/util/concurrent/tck/ArrayListTest.java ! test/jdk/java/util/concurrent/tck/Collection8Test.java ! test/jdk/java/util/concurrent/tck/CompletableFutureTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentLinkedDequeTest.java ! test/jdk/java/util/concurrent/tck/ExecutorsTest.java ! test/jdk/java/util/concurrent/tck/ForkJoinPoolTest.java ! test/jdk/java/util/concurrent/tck/JSR166TestCase.java ! test/jdk/java/util/concurrent/tck/RecursiveTaskTest.java ! test/jdk/java/util/concurrent/tck/SplittableRandomTest.java ! test/jdk/java/util/concurrent/tck/StampedLockTest.java ! test/jdk/java/util/concurrent/tck/SubmissionPublisherTest.java ! test/jdk/java/util/concurrent/tck/SynchronousQueueTest.java ! test/jdk/java/util/concurrent/tck/ThreadLocalRandomTest.java Changeset: 81db63e8 Author: Xue-Lei Andrew Fan Date: 2021-01-10 04:36:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81db63e8 8259517: Incorrect test path in test cases Reviewed-by: weijun ! test/jdk/javax/net/ssl/SSLEngine/ArgCheck.java ! test/jdk/javax/net/ssl/SSLEngine/Basics.java ! test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java Changeset: 65ca5c66 Author: Tejpal Rebari Date: 2021-01-10 12:38:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/65ca5c66 8048109: JToggleButton does not fire actionPerformed under certain conditions Reviewed-by: serb, psadhukhan, vdyakov ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java + test/jdk/javax/swing/JPopupMenu/SetInvokerJPopupMenuTest.java Changeset: 11d5b047 Author: Martin Buchholz Date: 2021-01-10 18:20:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/11d5b047 8258217: PriorityBlockingQueue constructor spec and behavior mismatch Reviewed-by: dl ! src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java Changeset: e7c17408 Author: Martin Buchholz Date: 2021-01-10 18:38:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e7c17408 8258187: IllegalMonitorStateException in ArrayBlockingQueue Reviewed-by: dl ! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java Changeset: 9154f643 Author: Martin Buchholz Date: 2021-01-10 23:47:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9154f643 8254973: CompletableFuture.ThreadPerTaskExecutor does not throw NPE in #execute Reviewed-by: dl ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java Changeset: b72de3c5 Author: Xue-Lei Andrew Fan Date: 2021-01-11 00:33:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b72de3c5 8259385: Cleanup unused assignment Reviewed-by: attila ! src/java.base/share/classes/sun/security/ssl/CertStatusExtension.java ! src/java.base/share/classes/sun/security/ssl/CertificateStatus.java ! src/java.base/share/classes/sun/security/ssl/CertificateVerify.java ! src/java.base/share/classes/sun/security/ssl/DHServerKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java ! src/java.base/share/classes/sun/security/ssl/ECDHClientKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/Finished.java ! src/java.base/share/classes/sun/security/ssl/OutputRecord.java ! src/java.base/share/classes/sun/security/ssl/RSAKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/RSAServerKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/SSLCipher.java ! src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLEngineInputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLTransport.java ! src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java Changeset: 2806bf2e Author: Aleksey Shipilev Date: 2021-01-11 07:32:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2806bf2e 8259475: Fix bad merge in compilerOracle Reviewed-by: redestad, thartmann ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/compiler/compilerOracle.hpp Changeset: bb247b02 Author: Aleksey Shipilev Date: 2021-01-11 07:32:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb247b02 8259392: Zero error reporting is broken after JDK-8255711 Reviewed-by: dholmes ! src/hotspot/os/posix/signals_posix.cpp Changeset: 3974fd4f Author: Aleksey Shipilev Date: 2021-01-11 07:33:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3974fd4f 8259451: Zero: skip serviceability/sa tests, set vm.hasSA to false Reviewed-by: sgehwolf, cjplummer ! test/lib/jdk/test/lib/Platform.java Changeset: d21a0ea1 Author: Magnus Ihse Bursie Date: 2021-01-11 07:37:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d21a0ea1 8258449: Move make/hotspot/symbols to make/data Reviewed-by: erikj = make/data/hotspot-symbols/symbols-aix = make/data/hotspot-symbols/symbols-aix-debug = make/data/hotspot-symbols/symbols-linux = make/data/hotspot-symbols/symbols-macosx = make/data/hotspot-symbols/symbols-shared = make/data/hotspot-symbols/symbols-unix ! make/hotspot/lib/JvmMapfile.gmk Changeset: bd344184 Author: Magnus Ihse Bursie Date: 2021-01-11 07:42:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bd344184 8258445: Move make/templates to make/data Reviewed-by: erikj = make/data/license-templates/bsd-header = make/data/license-templates/gpl-cp-header = make/data/license-templates/gpl-header ! make/scripts/lic_check.sh Changeset: e0d748d5 Author: Thomas Stuefe Date: 2021-01-11 09:06:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e0d748d5 8258606: os::print_signal_handlers() should resolve the function name of the handlers Reviewed-by: dholmes, coleenp, gziemski ! src/hotspot/os/posix/signals_posix.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp ! test/hotspot/gtest/runtime/test_os.cpp Changeset: a03e22bb Author: Aleksey Shipilev Date: 2021-01-11 09:42:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a03e22bb 8253910: UseCompressedClassPointers depends on UseCompressedOops in vmError.cpp Reviewed-by: rrich, dholmes ! src/hotspot/share/utilities/vmError.cpp Changeset: 18a37f94 Author: Aleksey Shipilev Date: 2021-01-11 09:43:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/18a37f94 8259368: Zero: UseCompressedClassPointers does not depend on UseCompressedOops Reviewed-by: aph, zgu ! src/hotspot/cpu/zero/globalDefinitions_zero.hpp Changeset: 23548821 Author: Jan Lahoda Date: 2021-01-11 10:10:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/23548821 8250768: javac should be adapted to changes in JEP 12 Reviewed-by: mcimadamore, erikj, jjg, ihse ! make/CompileInterimLangtools.gmk ! make/Docs.gmk ! make/autoconf/spec.gmk.in - make/jdk/src/classes/build/tools/taglet/Preview.java ! make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java ! make/modules/jdk.compiler/Gendata.gmk ! make/modules/jdk.javadoc/Gendata.gmk ! src/java.base/share/classes/java/lang/Class.java = src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java ! src/java.base/share/classes/module-info.java ! src/java.compiler/share/classes/javax/lang/model/element/Modifier.java ! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java ! src/jdk.compiler/share/classes/com/sun/source/tree/ClassTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskPool.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkFactoryImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkInfoImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PreviewListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SubWriterHolderWriter.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/TagName.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ConstructorWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/EnumConstantWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/FieldWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/MethodWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/PropertyWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstructorBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/EnumConstantBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/FieldBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MethodBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/PropertyBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Comparators.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DeprecatedAPIListBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocLink.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/SummaryAPIListBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/links/LinkFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/links/LinkInfo.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java ! src/jdk.jshell/share/classes/jdk/jshell/Snippet.java ! test/jdk/java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java ! test/jdk/java/lang/ref/CleanerTest.java ! test/jdk/java/util/Arrays/TimSortStackSize2.java ! test/jdk/jdk/modules/etc/JdkQualifiedExportTest.java ! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java ! test/langtools/jdk/javadoc/doclet/testHtmlTableTags/TestHtmlTableTags.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java + test/langtools/jdk/javadoc/doclet/testPreview/TestPreview.java + test/langtools/jdk/javadoc/doclet/testPreview/api/preview/Core.java + test/langtools/jdk/javadoc/doclet/testPreview/api/preview/CoreRecord.java + test/langtools/jdk/javadoc/doclet/testPreview/api/preview/CoreRecordComponent.java + test/langtools/jdk/javadoc/doclet/testPreview/api/preview/Reflective.java + test/langtools/jdk/javadoc/doclet/testPreview/doc/element-list = test/langtools/jdk/javadoc/doclet/testPreview/doc/java.base/preview/Core.html = test/langtools/jdk/javadoc/doclet/testPreview/doc/java.base/preview/Reflective.html + test/langtools/jdk/javadoc/doclet/testPreview/m/module-info.java + test/langtools/jdk/javadoc/doclet/testPreview/m/pkg/DocAnnotation.java + test/langtools/jdk/javadoc/doclet/testPreview/m/pkg/DocAnnotationUse1.java + test/langtools/jdk/javadoc/doclet/testPreview/m/pkg/DocAnnotationUse2.java + test/langtools/jdk/javadoc/doclet/testPreview/m/pkg/TestPreviewAPIUse.java + test/langtools/jdk/javadoc/doclet/testPreview/m/pkg/TestPreviewDeclaration.java + test/langtools/jdk/javadoc/doclet/testPreview/m/pkg/TestPreviewDeclarationUse.java ! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java ! test/langtools/jdk/javadoc/doclet/testSealedTypes/TestSealedTypes.java ! test/langtools/jdk/javadoc/doclet/testStylesheet/TestStylesheet.java ! test/langtools/jdk/javadoc/tool/CheckResourceKeys.java ! test/langtools/tools/javac/diags/examples.not-yet.txt ! test/langtools/tools/javac/diags/examples/CantExtendSealedInAnotherModule/CantExtendSealedInAnotherModule.java ! test/langtools/tools/javac/diags/examples/CantExtendSealedInAnotherPkg/CantExtendSealedInAnotherPkg.java ! test/langtools/tools/javac/diags/examples/SealedTypes.java + test/langtools/tools/javac/enum/FauxEnum3-preview.out ! test/langtools/tools/javac/lib/combo/ComboTask.java ! test/langtools/tools/javac/options/BCPOrSystemNotSpecified.java ! test/langtools/tools/javac/patterns/BreakAndLoops.java ! test/langtools/tools/javac/patterns/ConditionalTest.java ! test/langtools/tools/javac/patterns/PatternMatchPosTest.out ! test/langtools/tools/javac/platform/PreviewAPIsWithRelease.out + test/langtools/tools/javac/preview/DeclaredUsingPreview-class.out + test/langtools/tools/javac/preview/DeclaredUsingPreview-source.out + test/langtools/tools/javac/preview/DeclaredUsingPreview.java + test/langtools/tools/javac/preview/DeclaredUsingPreviewDeclarations.java + test/langtools/tools/javac/preview/PreviewAutoSuppress.java ! test/langtools/tools/javac/preview/PreviewErrors.java ! test/langtools/tools/javac/processing/model/element/TestSealed.java ! test/langtools/tools/javac/sealed/SealedDiffConfigurationsTest.java ! test/langtools/tools/jdeps/listdeps/ListModuleDeps.java Changeset: 1bd015fb Author: Magnus Ihse Bursie Date: 2021-01-11 11:28:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1bd015fb 8258407: Split up CompileJavaModules.gmk into make/modules/$M/Java.gmk Reviewed-by: erikj ! make/CompileJavaModules.gmk + make/modules/java.base/Java.gmk + make/modules/java.compiler/Java.gmk + make/modules/java.datatransfer/Java.gmk + make/modules/java.desktop/Java.gmk + make/modules/java.instrument/Java.gmk + make/modules/java.logging/Java.gmk + make/modules/java.management.rmi/Java.gmk + make/modules/java.management/Java.gmk + make/modules/java.naming/Java.gmk + make/modules/java.prefs/Java.gmk + make/modules/java.rmi/Java.gmk + make/modules/java.scripting/Java.gmk + make/modules/java.security.jgss/Java.gmk + make/modules/java.smartcardio/Java.gmk + make/modules/java.sql.rowset/Java.gmk + make/modules/java.sql/Java.gmk + make/modules/java.transaction.xa/Java.gmk + make/modules/java.xml.crypto/Java.gmk + make/modules/java.xml/Java.gmk + make/modules/jdk.aot/Java.gmk + make/modules/jdk.charsets/Java.gmk + make/modules/jdk.compiler/Java.gmk + make/modules/jdk.dev/Java.gmk + make/modules/jdk.dynalink/Java.gmk + make/modules/jdk.editpad/Java.gmk + make/modules/jdk.hotspot.agent/Java.gmk + make/modules/jdk.httpserver/Java.gmk + make/modules/jdk.incubator.vector/Java.gmk + make/modules/jdk.internal.jvmstat/Java.gmk + make/modules/jdk.internal.le/Java.gmk + make/modules/jdk.internal.opt/Java.gmk + make/modules/jdk.internal.vm.ci/Java.gmk + make/modules/jdk.internal.vm.compiler/Java.gmk + make/modules/jdk.jartool/Java.gmk + make/modules/jdk.javadoc/Java.gmk + make/modules/jdk.jcmd/Java.gmk + make/modules/jdk.jconsole/Java.gmk + make/modules/jdk.jdeps/Java.gmk + make/modules/jdk.jdi/Java.gmk + make/modules/jdk.jfr/Java.gmk + make/modules/jdk.jpackage/Java.gmk + make/modules/jdk.jshell/Java.gmk + make/modules/jdk.localedata/Java.gmk + make/modules/jdk.sctp/Java.gmk + make/modules/jdk.unsupported.desktop/Java.gmk + make/modules/sun.charsets/Java.gmk Changeset: 01b2804e Author: Clive Verghese Committer: Volker Simonis Date: 2021-01-11 12:02:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/01b2804e 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed Reviewed-by: xuelei, simonis ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLTransport.java ! test/jdk/sun/security/ssl/SSLContextImpl/TrustTrustedCert.java + test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketShouldThrowSocketException.java = test/jdk/sun/security/ssl/SSLSocketImpl/SocketExceptionForSocketIssues.java Changeset: 23801da9 Author: Coleen Phillimore Date: 2021-01-11 12:27:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/23801da9 8259482: jni_Set/GetField_probe are the same as their _nh versions Reviewed-by: hseigel, sspitsyn, dholmes ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/jvmtiExport.hpp Changeset: 33fbc10c Author: Guoxiong Li Committer: Attila Szegedi Date: 2021-01-11 13:50:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/33fbc10c 8259025: Record compact constructor using Objects.requireNonNull Reviewed-by: attila ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/langtools/tools/javac/records/RecordCompilationTests.java Changeset: cf3e4bfd Author: Harold Seigel Date: 2021-01-11 18:18:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cf3e4bfd 8258838: Remove JVM option UseStackBanging Reviewed-by: dholmes, coleenp, kvn ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/arm/macroAssembler_arm.cpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/s390/templateInterpreterGenerator_s390.cpp ! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/share/asm/assembler.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/runtime/globals.hpp ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java Changeset: dab17875 Author: Magnus Ihse Bursie Date: 2021-01-11 18:18:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dab17875 8259559: COMPARE_BUILD can't compare patch files Reviewed-by: erikj ! make/Init.gmk Changeset: 38619602 Author: Magnus Ihse Bursie Date: 2021-01-11 18:22:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/38619602 8258426: Split up autoconf/version-numbers and move it to conf dir Reviewed-by: erikj ! .github/workflows/submit.yml ! make/autoconf/jdk-options.m4 ! make/autoconf/jdk-version.m4 ! make/autoconf/spec.gmk.in - make/autoconf/version-numbers + make/conf/branding.conf ! make/conf/jib-profiles.js + make/conf/version-numbers.conf Changeset: c956e7a6 Author: Jonathan Gibbons Date: 2021-01-11 18:46:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c956e7a6 8258659: Eliminate whitespace comments from generated pages Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java ! test/langtools/jdk/javadoc/doclet/AccessSkipNav/AccessSkipNav.java ! test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java ! test/langtools/jdk/javadoc/doclet/testNavigation/TestNavigation.java Changeset: d9f21346 Author: Jonathan Gibbons Date: 2021-01-11 18:49:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d9f21346 8258655: remove <-- NewPage --> comment from generated pages Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexRedirectWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlDocument.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties Changeset: 8dfc77bf Author: Daniel D. Daugherty Date: 2021-01-11 19:44:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8dfc77bf 8259586: ProblemList dll_address_to_function_and_library_name Reviewed-by: hseigel ! test/hotspot/gtest/runtime/test_os.cpp Changeset: e9929e2b Author: Volker Simonis Date: 2021-01-11 21:36:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e9929e2b 8259582: Backout JDK-8237578 until all affected tests have been fixed Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLTransport.java ! test/jdk/sun/security/ssl/SSLContextImpl/TrustTrustedCert.java = test/jdk/sun/security/ssl/SSLSocketImpl/SSLExceptionForIOIssue.java - test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketShouldThrowSocketException.java Changeset: cd73939b Author: Naoto Sato Date: 2021-01-11 22:02:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd73939b 8259528: Broken Link for [java.text.Normalizer.Form] Reviewed-by: lancea, joehw, iris ! src/java.base/share/classes/java/text/Normalizer.java Changeset: 712ea250 Author: Yasumasa Suenaga Date: 2021-01-11 23:13:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/712ea250 8258925: configure script failed on WSL Reviewed-by: dholmes, erikj ! make/scripts/fixpath.sh Changeset: ff54b77b Author: Sergey Bylokhov Date: 2021-01-11 23:14:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ff54b77b 8259439: Apply java.io.Serial annotations in java.datatransfer Reviewed-by: aivanov, pbansal, trebari, darcy ! src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/FlavorEvent.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/MimeType.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/MimeTypeParseException.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/UnsupportedFlavorException.java Changeset: 022bc9f0 Author: Andrey Turbanov Committer: Aleksei Efimov Date: 2021-01-11 23:30:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/022bc9f0 8258422: Cleanup unnecessary null comparison before instanceof check in java.base Reviewed-by: chegar, aefimov ! src/java.base/share/classes/java/io/File.java ! src/java.base/share/classes/java/lang/reflect/Constructor.java ! src/java.base/share/classes/java/lang/reflect/Field.java ! src/java.base/share/classes/java/lang/reflect/Method.java ! src/java.base/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/java.base/share/classes/java/net/AbstractPlainSocketImpl.java ! src/java.base/share/classes/java/net/DatagramPacket.java ! src/java.base/share/classes/java/net/HttpConnectSocketImpl.java ! src/java.base/share/classes/java/net/Inet4Address.java ! src/java.base/share/classes/java/net/Inet6Address.java ! src/java.base/share/classes/java/net/InetSocketAddress.java ! src/java.base/share/classes/java/net/NetMulticastSocket.java ! src/java.base/share/classes/java/net/Proxy.java ! src/java.base/share/classes/java/net/SocksSocketImpl.java ! src/java.base/share/classes/java/nio/file/attribute/AclEntry.java ! src/java.base/share/classes/jdk/internal/misc/Signal.java ! src/java.base/share/classes/sun/net/www/protocol/http/Negotiator.java ! src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/java.base/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/java.base/share/classes/sun/nio/fs/PollingWatchService.java ! src/java.base/unix/classes/sun/nio/fs/UnixPath.java ! src/java.base/windows/classes/sun/nio/fs/WindowsPath.java Changeset: b6d51e15 Author: Alexander Zuev Date: 2021-01-12 00:28:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b6d51e15 8259585: Accessible actions do not work on mac os x Reviewed-by: serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityAction.m Changeset: fb68395d Author: Michael McMahon Date: 2021-01-08 15:59:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fb68395d 8259014: (so) ServerSocketChannel.bind(UnixDomainSocketAddress)/SocketChannel.bind(UnixDomainSocketAddress) will have unknown user and group owner (win) Reviewed-by: alanb ! src/java.base/windows/native/libnio/ch/UnixDomainSockets.c Changeset: 020ec848 Author: Erik Joelsson Date: 2021-01-08 18:30:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/020ec848 8259429: Update reference to README.md Reviewed-by: iris ! make/conf/jib-profiles.js Changeset: e05f36f4 Author: Aleksey Shipilev Date: 2021-01-11 13:45:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e05f36f4 8259043: More Zero architectures need linkage with libatomic Co-authored-by: Matthias Klose Reviewed-by: erikj ! make/autoconf/libraries.m4 Changeset: d60a937e Author: Maurizio Cimadamore Date: 2021-01-11 16:14:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d60a937e 8259028: ClassCastException when using custom filesystem with wrapper FileChannel impl Reviewed-by: chegar, alanb, uschindler ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MappedMemorySegmentImpl.java ! test/jdk/java/foreign/TestByteBuffer.java Changeset: 2cb271e6 Author: Jonathan Gibbons Date: 2021-01-11 17:35:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2cb271e6 8253996: Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing Reviewed-by: hannesw ! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlOptions.java ! test/langtools/tools/javac/diags/examples.not-yet.txt + test/langtools/tools/javac/doclint/LimitedImage.java Changeset: b378f54d Author: Jesper Wilhelmsson Date: 2021-01-12 01:08:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b378f54d Merge ! make/conf/jib-profiles.js ! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/tools/javac/diags/examples.not-yet.txt ! make/conf/jib-profiles.js ! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/tools/javac/diags/examples.not-yet.txt Changeset: ae0532ed Author: Wang Huang Committer: Fei Yang Date: 2021-01-12 01:40:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ae0532ed 8259044: JVM lacks data type qualifier when using -XX:+PrintAssembly with AArch64-Neon backend Co-authored-by: He Xuejin Reviewed-by: njian, aph ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 Changeset: 2255ab76 Author: Kim Barrett Date: 2021-01-12 03:38:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2255ab76 8258810: Improve enum traits Reviewed-by: ayang, iklam, lfoltan ! src/hotspot/share/utilities/enumIterator.hpp ! test/hotspot/gtest/utilities/test_enumIterator.cpp Changeset: 77f62909 Author: Kim Barrett Date: 2021-01-12 04:12:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/77f62909 8258254: Move PtrQueue flush to PtrQueueSet subclasses Reviewed-by: tschatzl, shade ! src/hotspot/share/gc/g1/g1BarrierSet.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/g1RedirtyCardsQueue.cpp ! src/hotspot/share/gc/g1/g1RedirtyCardsQueue.hpp ! src/hotspot/share/gc/shared/ptrQueue.cpp ! src/hotspot/share/gc/shared/ptrQueue.hpp ! src/hotspot/share/gc/shared/satbMarkQueue.cpp ! src/hotspot/share/gc/shared/satbMarkQueue.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp Changeset: 61c5b95b Author: Sergey Bylokhov Date: 2021-01-12 06:53:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/61c5b95b 7194219: java/awt/Component/UpdatingBootTime/UpdatingBootTime.html fails on Linux Reviewed-by: aivanov ! src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java ! src/java.desktop/unix/classes/sun/awt/X11/XWindow.java ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Component/UpdatingBootTime/UpdatingBootTime.html ! test/jdk/java/awt/Component/UpdatingBootTime/UpdatingBootTime.java Changeset: 98ccfbf4 Author: Sergey Bylokhov Date: 2021-01-12 06:56:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/98ccfbf4 8255710: Opensource unit/regression tests for CMM Reviewed-by: pbansal, prr + test/jdk/java/awt/color/GetInstanceNullData.java + test/jdk/java/awt/color/GetNameExceptionTest.java + test/jdk/java/awt/color/GetNameTest.java + test/jdk/java/awt/color/ICC_ProfileSetNullDataTest.java + test/jdk/java/awt/color/MultiThreadCMMTest.java + test/jdk/java/awt/color/StandardProfileTest.java + test/jdk/java/awt/color/StandardProfileTest.policy + test/jdk/java/awt/color/XYZTest.java Changeset: 9d4e84fd Author: Aleksey Shipilev Date: 2021-01-12 07:49:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9d4e84fd 8259565: Zero: compiler/runtime/criticalnatives fails because CriticalJNINatives is not supported Reviewed-by: coleenp, zgu ! src/hotspot/cpu/zero/vm_version_zero.cpp ! test/hotspot/jtreg/compiler/runtime/criticalnatives/argumentcorruption/CheckLongArgs.java ! test/hotspot/jtreg/compiler/runtime/criticalnatives/lookup/LookUp.java Changeset: 46637047 Author: Aleksey Shipilev Date: 2021-01-12 07:58:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/46637047 8259583: Remove unused decode_env::_codeBuffer Reviewed-by: thartmann ! src/hotspot/share/compiler/disassembler.cpp Changeset: a3561ae8 Author: Christian Hagedorn Date: 2021-01-12 08:18:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a3561ae8 8258243: C2: assert failed ("Bad derived pointer") with -XX:+VerifyRegisterAllocator Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/chaitin.cpp + test/hotspot/jtreg/compiler/regalloc/TestVerifyRegisterAllocator.java Changeset: a6ab9e47 Author: Richard Reingruber Date: 2021-01-12 08:35:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a6ab9e47 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled Reviewed-by: mdoerr, stuefe ! src/hotspot/share/memory/metaspace.cpp ! test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointers.java Changeset: 4697cfa4 Author: Aleksey Shipilev Date: 2021-01-12 10:52:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4697cfa4 8259576: Misplaced curly brace in Matcher::find_shared_post_visit Reviewed-by: lucy, thartmann ! src/hotspot/share/opto/matcher.cpp Changeset: ac2dee56 Author: Thomas Stuefe Date: 2021-01-12 11:41:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ac2dee56 8259539: JDK-8255711 broke trap messages Reviewed-by: lfoltan, dholmes ! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp ! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp Changeset: 400dc76f Author: Peter Zhelezniakov Committer: Alexander Scherbatiy Date: 2021-01-12 11:50:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/400dc76f 8252015: [macos11] java.awt.TrayIcon requires updates for template images Co-authored-by: Tres Finocchiaro Co-authored-by: Peter Zhelezniakov Reviewed-by: serb ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CTrayIcon.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/CTrayIcon.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/CTrayIcon.m ! src/java.desktop/share/classes/java/awt/TrayIcon.java Changeset: 563b268c Author: Sergey Platonov Committer: Aleksey Shipilev Date: 2021-01-12 11:57:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/563b268c 8257709: C1: Double assignment in InstructionPrinter::print_stack Reviewed-by: shade, chagedorn ! src/hotspot/share/c1/c1_InstructionPrinter.cpp Changeset: 4c75d14a Author: Coleen Phillimore Date: 2021-01-12 13:07:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4c75d14a 8259374: Make ThreadInVMfromNative have ResetNoHandleMark Reviewed-by: dcubed, pchilanomate ! src/hotspot/share/ci/ciUtilities.inline.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp ! src/hotspot/share/jfr/recorder/repository/jfrChunkRotation.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/runtime/handles.hpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp Changeset: ccac7aae Author: Dong Bo Committer: Fei Yang Date: 2021-01-12 13:27:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ccac7aae 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp Reviewed-by: aph ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h + test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java Changeset: c338f116 Author: Daniel D. Daugherty Date: 2021-01-12 14:39:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c338f116 8259349: -XX:AvgMonitorsPerThreadEstimate=1 does not work right Reviewed-by: coleenp, dholmes ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp Changeset: d6a2105b Author: Phil Race Date: 2021-01-12 20:19:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d6a2105b 8259343: [macOS] Update JNI error handling in Cocoa code. Reviewed-by: erikj, serb ! make/modules/java.desktop/Lib.gmk ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/GeomUtilities.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaTextAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m ! src/java.desktop/macosx/native/libosxapp/JNIUtilities.h Changeset: 5f7ccce0 Author: Evan Whelan Committer: Alan Bateman Date: 2021-01-12 20:41:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5f7ccce0 8226810: Failed to launch JVM because of NullPointerException occured on System.props Reviewed-by: alanb, naoto ! make/data/charsetmapping/stdcs-windows Changeset: e4df2098 Author: Laurent Bourg?s Date: 2021-01-12 20:51:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e4df2098 7018932: Drawing very large coordinates with a dashed Stroke can cause Java to hang Reviewed-by: serb, prr ! src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinRenderingEngine.java ! src/java.desktop/share/classes/sun/java2d/marlin/TransformingPathConsumer2D.java ! src/java.desktop/share/classes/sun/java2d/pipe/LoopPipe.java ! src/java.desktop/share/classes/sun/java2d/pipe/RenderingEngine.java ! src/java.desktop/share/classes/sun/java2d/pipe/SpanShapeRenderer.java + test/jdk/sun/java2d/marlin/StrokedLinePerf.java Changeset: 4be21734 Author: Martin Balao Date: 2021-01-12 23:44:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4be21734 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes Reviewed-by: valeriep, mullan ! src/java.base/share/classes/module-info.java ! src/java.base/share/lib/security/default.policy ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java + test/jdk/sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java Changeset: c6d798c2 Author: Dong Bo Committer: Vladimir Kozlov Date: 2021-01-13 00:30:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c6d798c2 8259629: aarch64 builds fail after JDK-8258932 Reviewed-by: kvn ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h Changeset: 65bed647 Author: Xue-Lei Andrew Fan Date: 2021-01-13 01:10:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/65bed647 8253635: Implement toString() for SSLEngineImpl Reviewed-by: coffeys, wetmore ! src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 0957d9eb Author: Sergey Bylokhov Date: 2021-01-13 02:30:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0957d9eb 8259519: The java.awt.datatransfer.DataFlavor#ioInputStreamClass field is redundant Reviewed-by: aivanov ! src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java + test/jdk/java/awt/datatransfer/DataFlavor/DefaultRepresentation.java Changeset: 44c83794 Author: Prasanta Sadhukhan Date: 2021-01-13 06:57:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/44c83794 8256019: JLabel HTML text does not support translucent text colors Reviewed-by: serb ! src/java.desktop/share/classes/javax/swing/text/html/CSS.java + test/jdk/javax/swing/JLabel/TestTranslucentLabelText.java Changeset: a483869a Author: Prasanta Sadhukhan Date: 2021-01-13 07:00:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a483869a 8225045: javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails on linux-x64 Reviewed-by: serb, pbansal, trebari ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java Changeset: 139b6dae Author: Matthias Baesken Date: 2021-01-13 07:53:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/139b6dae 8259372: remove AIX related USE_LIBRARY_BASED_TLS_ONLY and THREAD_LOCAL special handling Reviewed-by: dholmes, stuefe ! src/hotspot/share/utilities/globalDefinitions_xlc.hpp Changeset: 2243a170 Author: liach Committer: Aleksey Shipilev Date: 2021-01-13 08:02:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2243a170 8259485: Document need for short paths when building on Windows Reviewed-by: erikj, shade ! doc/building.html ! doc/building.md Changeset: 77ca1031 Author: Jan Lahoda Date: 2021-01-13 11:27:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/77ca1031 8257236: can't use var with a class named Z Reviewed-by: sundar ! src/jdk.jshell/share/classes/jdk/jshell/Wrap.java ! test/langtools/jdk/jshell/VariablesTest.java Changeset: 2e124544 Author: Aleksey Shipilev Date: 2021-01-13 11:55:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2e124544 8259580: Shenandoah: uninitialized label in VerifyThreadGCState Reviewed-by: zgu, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp Changeset: ce945120 Author: Aleksey Shipilev Date: 2021-01-13 12:30:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ce945120 8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect Reviewed-by: chagedorn, kvn ! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp Changeset: 535f2da5 Author: Coleen Phillimore Date: 2021-01-13 14:32:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/535f2da5 8259486: Replace PreserveExceptionMark with implementation for CautiouslyPreserveExceptionMark Reviewed-by: dholmes, sspitsyn ! src/hotspot/cpu/arm/methodHandles_arm.cpp ! src/hotspot/cpu/ppc/methodHandles_ppc.cpp ! src/hotspot/cpu/s390/methodHandles_s390.cpp ! src/hotspot/cpu/x86/methodHandles_x86.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/jfr/recorder/service/jfrRecorderThread.cpp ! src/hotspot/share/prims/jvmtiEnter.xsl ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/utilities/exceptions.cpp ! src/hotspot/share/utilities/exceptions.hpp ! src/hotspot/share/utilities/preserveException.cpp ! src/hotspot/share/utilities/preserveException.hpp Changeset: 5df2a949 Author: Mahendra Chhipa Committer: Daniel Fuchs Date: 2021-01-13 15:53:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5df2a949 8212035: merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer Reviewed-by: dfuchs - test/jaxp/javax/xml/jaxp/libs/jaxp/library/SimpleHttpServer.java ! test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java ! test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java ! test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarHttpProperties.java ! test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarProperties.java ! test/jdk/java/util/jar/JarFile/mrjar/TestVersionedStream.java ! test/jdk/lib/testlibrary/java/util/jar/CreateMultiReleaseTestJars.java - test/jdk/lib/testlibrary/java/util/jar/SimpleHttpServer.java ! test/jdk/sun/net/www/protocol/jar/B4756443.java ! test/jdk/sun/net/www/protocol/jar/B5105410.java ! test/jdk/sun/net/www/protocol/jar/JarURLConnectionUseCaches.java ! test/jdk/sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java ! test/jdk/sun/net/www/protocol/jar/jarbug/TestDriver.java ! test/jdk/sun/net/www/protocol/jar/jarbug/src/jar1/GetResource.java ! test/jdk/sun/net/www/protocol/jar/jarbug/src/jar1/LoadResourceBundle.java ! test/jdk/sun/net/www/protocol/jar/jarbug/src/test/JarTest.java + test/lib/jdk/test/lib/net/SimpleHttpServer.java Changeset: 916ab4e7 Author: Jonathan Gibbons Date: 2021-01-13 17:01:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/916ab4e7 8259283: use new HtmlId and HtmlIds classes Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIndexBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkFactoryImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SectionName.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SubWriterHolderWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlId.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Links.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Table.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/SummaryAPIListBuilder.java Changeset: ccdf171d Author: Zhengyu Gu Date: 2021-01-13 19:01:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ccdf171d 8259377: Shenandoah: Enhance weak reference processing time tracking Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp Changeset: c7e2174b Author: Hai-May Chao Committer: Weijun Wang Date: 2021-01-13 22:32:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c7e2174b 8259401: Add checking to jarsigner to warn weak algorithms used in signer?s cert chain Reviewed-by: mullan, weijun, rhalade ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java + test/jdk/sun/security/tools/jarsigner/CheckSignerCertChain.java Changeset: a7e5da22 Author: Ningsheng Jian Date: 2021-01-12 01:31:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a7e5da22 8258384: AArch64: SVE verify_ptrue fails on some tests Reviewed-by: adinn, ngasson ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Changeset: 28ff2de1 Author: Pankaj Bansal Date: 2021-01-12 09:46:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/28ff2de1 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. Reviewed-by: psadhukhan, kizune, serb ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicButtonUI.java ! test/jdk/javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java Changeset: 67e1b639 Author: Patrick Zhang Committer: Thomas Schatzl Date: 2021-01-12 10:10:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/67e1b639 8259380: Correct pretouch chunk size to cap with actual page size Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/shared/pretouchTask.cpp Changeset: 8a81cf15 Author: Stuart Marks Date: 2021-01-12 17:04:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8a81cf15 8259298: broken link in Stream::toList spec Reviewed-by: bchristi, iris, lancea, naoto ! src/java.base/share/classes/java/util/stream/Stream.java Changeset: b03880e3 Author: Maurizio Cimadamore Date: 2021-01-12 17:09:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b03880e3 8259634: MemorySegment::asByteBuffer does not respect spatial bounds Reviewed-by: alanb, chegar ! src/java.base/share/classes/java/nio/Buffer.java ! test/jdk/java/foreign/TestByteBuffer.java Changeset: 5f9cd72c Author: Jonathan Gibbons Date: 2021-01-12 19:57:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5f9cd72c 8259645: Revert JDK-8245956 JavaCompiler still uses File API instead of Path API in a specific case Reviewed-by: chegar ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java - test/langtools/tools/javac/T8245956/T8245956.java Changeset: 17b4db31 Author: Maurizio Cimadamore Date: 2021-01-12 21:06:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/17b4db31 8259636: Check for buffer backed by shared segment kicks in in unexpected places Reviewed-by: sundar, alanb, chegar ! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template ! test/jdk/java/foreign/TestByteBuffer.java Changeset: 1cf2378b Author: Xiaohong Gong Committer: Ningsheng Jian Date: 2021-01-13 05:48:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1cf2378b 8259353: VectorReinterpretNode is incorrectly optimized out Reviewed-by: vlivanov, njian ! src/hotspot/share/opto/vectornode.cpp Changeset: 15dd8f3a Author: Calvin Cheung Date: 2021-01-13 05:51:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/15dd8f3a 8259275: JRuby crashes while resolving invokedynamic instruction Reviewed-by: iklam, minqi, lfoltan ! src/hotspot/share/classfile/classListParser.cpp ! src/hotspot/share/classfile/classListParser.hpp ! src/hotspot/share/oops/constantPool.cpp ! test/hotspot/jtreg/TEST.groups ! test/hotspot/jtreg/runtime/cds/appcds/BadBSM.java + test/hotspot/jtreg/runtime/cds/appcds/LambdaWithOldClass.java + test/hotspot/jtreg/runtime/cds/appcds/test-classes/LambdaWithOldClassApp.java + test/hotspot/jtreg/runtime/cds/appcds/test-classes/OldClass.jasm Changeset: 793017d2 Author: Xiaohong Gong Committer: Ningsheng Jian Date: 2021-01-13 05:52:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/793017d2 8259601: AArch64: Fix reinterpretX2D match rule issue Reviewed-by: adinn, njian ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 Changeset: 417e1d1a Author: Roberto Casta?eda Lozano Committer: Tobias Hartmann Date: 2021-01-13 07:22:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/417e1d1a 8259061: C2: assert(found) failed: memory-writing node is not placed in its original loop or an ancestor of it Remove assertion that is too general, that is, it can fail on compilations where C2 generates correct code otherwise. Reviewed-by: chagedorn, thartmann, kvn ! src/hotspot/share/opto/block.cpp Changeset: efc36be5 Author: Kim Barrett Date: 2021-01-13 08:22:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/efc36be5 8258985: Parallel WeakProcessor may use too few threads Use total workers rather than active. Reviewed-by: tschatzl, ayang, sjohanss ! src/hotspot/share/gc/shared/weakProcessor.hpp ! src/hotspot/share/gc/shared/weakProcessor.inline.hpp Changeset: a99df45b Author: Aleksey Shipilev Date: 2021-01-13 08:49:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a99df45b 8259560: Zero m68k: "static assertion failed: align" after JDK-8252049 Reviewed-by: dholmes ! src/hotspot/share/ci/ciMethodData.cpp ! src/hotspot/share/oops/methodData.hpp Changeset: 55675309 Author: Nils Eliasson Date: 2021-01-13 09:16:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/55675309 8258272: LoadVectorMaskedNode can't be replaced by zero con Reviewed-by: chagedorn, vlivanov ! src/hotspot/share/opto/memnode.cpp + test/hotspot/jtreg/compiler/arraycopy/TestArrayCopyMaskedWithZeroSrc.java Changeset: 6bb6093f Author: Jonathan Gibbons Date: 2021-01-13 12:40:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6bb6093f 8259657: typo in generated HELP page prevents localization Reviewed-by: vromero ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties Changeset: 42d2d6dc Author: Erik ?sterlund Date: 2021-01-13 16:48:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/42d2d6dc 8259063: Possible deadlock with vtable/itable creation vs concurrent class unloading Reviewed-by: pliden, neliasso ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp Changeset: ac4cd2e3 Author: Vicente Romero Date: 2021-01-13 17:27:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ac4cd2e3 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/lib/combo/tools/javac/combo/CompilationTestCase.java ! test/langtools/lib/combo/tools/javac/combo/Diagnostics.java ! test/langtools/lib/combo/tools/javac/combo/JavacTemplateTestBase.java + test/langtools/tools/javac/diags/examples/BoundUnboundMethRefSearch.java + test/langtools/tools/javac/diags/examples/BoundUnboundMethRefSearch2.java + test/langtools/tools/javac/lambda/methodReference/BoundUnboundSearchTest.java Changeset: fb8ac247 Author: Daniel D. Daugherty Date: 2021-01-13 18:23:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fb8ac247 8259722: ProblemList two jdk/jfr/startupargs tests on Windows Reviewed-by: mgronlun ! test/jdk/ProblemList.txt Changeset: 8abefdec Author: Daniel D. Daugherty Date: 2021-01-13 18:23:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8abefdec 8259720: ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java on Windows Reviewed-by: kizune, pbansal ! test/jdk/ProblemList.txt Changeset: 5926d75f Author: Daniel D. Daugherty Date: 2021-01-13 19:52:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5926d75f 8259719: ProblemList runtime/cds/appcds/jigsaw/modulepath/ModulePathAndCP_JFR.java on Windows Reviewed-by: pliden ! test/hotspot/jtreg/ProblemList.txt Changeset: 51e14f2e Author: Jesper Wilhelmsson Date: 2021-01-14 01:29:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/51e14f2e Merge ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/share/ci/ciMethodData.cpp ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/gc/shared/pretouchTask.cpp ! src/hotspot/share/gc/shared/weakProcessor.inline.hpp ! src/hotspot/share/opto/memnode.cpp ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.groups ! test/jdk/ProblemList.txt ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/share/ci/ciMethodData.cpp ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/gc/shared/pretouchTask.cpp ! src/hotspot/share/gc/shared/weakProcessor.inline.hpp ! src/hotspot/share/opto/memnode.cpp ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.groups ! test/jdk/ProblemList.txt Changeset: 5513f989 Author: Hao Sun Committer: Ningsheng Jian Date: 2021-01-14 04:11:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5513f989 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy Reviewed-by: xliu, kvn, kbarrett ! src/hotspot/share/opto/node.hpp Changeset: ae9187d7 Author: Alexander Zuev Date: 2021-01-14 05:07:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ae9187d7 8256109: Create implementation for NSAccessibilityButton protocol Reviewed-by: prr, serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ButtonAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ButtonAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m Changeset: 8b8b1f9a Author: Tobias Hartmann Date: 2021-01-14 07:23:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8b8b1f9a 8259706: C2 compilation fails with assert(vtable_index == Method::invalid_vtable_index) failed: correct sentinel value Reviewed-by: lucy, chagedorn ! src/hotspot/share/opto/library_call.cpp Changeset: 3462f7a9 Author: Stefan Karlsson Date: 2021-01-14 11:34:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3462f7a9 8256955: Move includes of events.hpp out of header files Reviewed-by: kbarrett, coleenp ! src/hotspot/share/classfile/classLoaderDataGraph.cpp ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/jvmci/jvmci.cpp ! src/hotspot/share/jvmci/jvmci.hpp ! src/hotspot/share/runtime/vmStructs.cpp Changeset: b040a3d7 Author: Aleksei Efimov Date: 2021-01-14 11:57:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b040a3d7 8259631: Reapply pattern match instanceof use in HttpClientImpl Reviewed-by: dfuchs, chegar ! src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java Changeset: b8ef2bad Author: Wang Xue Committer: David Holmes Date: 2021-01-14 12:56:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b8ef2bad 8259563: The CPU model name is printed multiple times when using -Xlog:os+cpu Reviewed-by: dholmes ! src/hotspot/os/linux/os_linux.cpp Changeset: ff3e6e46 Author: Jatin Bhateja Date: 2021-01-14 13:20:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ff3e6e46 8259773: Incorrect encoding of AVX-512 kmovq instruction Reviewed-by: vlivanov ! src/hotspot/cpu/x86/assembler_x86.cpp Changeset: c822eda1 Author: Sergey Tsypanov Committer: Claes Redestad Date: 2021-01-14 14:18:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c822eda1 8259699: Reduce char[] copying in URLEncoder.encode(String, Charset) Reviewed-by: attila, redestad, chegar ! src/java.base/share/classes/java/net/URLEncoder.java Changeset: be57cf14 Author: Daniel D. Daugherty Date: 2021-01-14 14:23:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/be57cf14 8226416: MonitorUsedDeflationThreshold can cause repeated async deflation requests Reviewed-by: dholmes, coleenp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/synchronizer.cpp + test/hotspot/jtreg/runtime/Monitor/MonitorUsedDeflationThresholdTest.java Changeset: 38a12017 Author: Harold Seigel Date: 2021-01-14 15:04:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/38a12017 8258912: Remove JVM options CountJNICalls and CountJVMCalls Reviewed-by: coleenp, lfoltan, shade ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/interfaceSupport.cpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp - src/hotspot/share/utilities/histogram.cpp - src/hotspot/share/utilities/histogram.hpp Changeset: 1620664e Author: Jonathan Gibbons Date: 2021-01-14 16:18:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1620664e 8259723: Move Table class to formats.html package Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllPackagesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SystemPropertiesWriter.java = src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Table.java = src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TableHeader.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/package-info.java Changeset: c2a3c7ef Author: Jonathan Gibbons Date: 2021-01-14 16:20:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c2a3c7ef 8259727: Remove redundant "target" arguments to methods in Links Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkFactoryImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkInfoImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Links.java Changeset: 8554fe6e Author: Jamil Nimeh Date: 2021-01-14 16:36:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8554fe6e 8253866: Security Libs Terminology Refresh Reviewed-by: erikj, weijun, mullan ! make/ToolsJdk.gmk = make/data/blockedcertsconverter/blocked.certs.pem = make/jdk/src/classes/build/tools/blockedcertsconverter/BlockedCertsConverter.java ! make/modules/java.base/Gendata.gmk - make/modules/java.base/gendata/GendataBlacklistedCerts.gmk + make/modules/java.base/gendata/GendataBlockedCerts.gmk ! make/scripts/compare.sh ! src/java.base/share/classes/com/sun/crypto/provider/JceKeyStore.java ! src/java.base/share/classes/java/util/jar/JarVerifier.java ! src/java.base/share/classes/sun/security/provider/JavaKeyStore.java ! src/java.base/share/classes/sun/security/util/UntrustedCertificates.java ! src/java.base/share/conf/security/java.security ! src/java.security.jgss/share/classes/sun/security/krb5/Config.java ! src/java.security.jgss/share/classes/sun/security/krb5/KdcComm.java ! test/jdk/sun/security/krb5/auto/BogusKDC.java - test/jdk/sun/security/lib/CheckBlacklistedCerts.java + test/jdk/sun/security/lib/CheckBlockedCerts.java Changeset: aba3431c Author: Naoto Sato Date: 2021-01-14 16:58:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aba3431c 8258956: Memory Leak in StringCoding on ThreadLocal resultCached StringCoding.Result Reviewed-by: rriggs, alanb ! src/java.base/share/classes/java/lang/StringCoding.java Changeset: da6bcf96 Author: Zhengyu Gu Date: 2021-01-14 17:42:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/da6bcf96 8255019: Shenandoah: Split STW and concurrent mark into separate classes Reviewed-by: rkennke, shade ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp - src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp + src/hotspot/share/gc/shenandoah/shenandoahMark.cpp + src/hotspot/share/gc/shenandoah/shenandoahMark.hpp + src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.hpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp + src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp + src/hotspot/share/gc/shenandoah/shenandoahSTWMark.hpp Changeset: a6b2162f Author: Sandhya Viswanathan Date: 2021-01-14 17:48:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a6b2162f 8259278: Optimize Vector API slice and unslice operations Reviewed-by: psandoz, vlivanov ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template Changeset: d18d26e8 Author: Chris Plummer Date: 2021-01-14 21:01:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d18d26e8 8259350: Add some internal debugging APIs to the debug agent Reviewed-by: sspitsyn, amenkov ! src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c ! src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.h ! src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c ! src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.h ! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c ! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.h ! src/jdk.jdwp.agent/share/native/libjdwp/util.c ! src/jdk.jdwp.agent/share/native/libjdwp/util.h Changeset: 4f881ba5 Author: Chris Plummer Date: 2021-01-14 23:04:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4f881ba5 8258652: Assert in JvmtiThreadState::cur_stack_depth() can noticeably slow down debugging single stepping Reviewed-by: sspitsyn, dholmes, amenkov ! src/hotspot/share/prims/jvmtiThreadState.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: bf28f925 Author: Coleen Phillimore Date: 2021-01-14 23:25:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bf28f925 8259713: Fix comments about ResetNoHandleMark in deoptimization Reviewed-by: lfoltan, dcubed, dholmes ! src/hotspot/share/runtime/deoptimization.cpp Changeset: 978bed6c Author: Sergey Bylokhov Date: 2021-01-15 00:28:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/978bed6c 8259522: Apply java.io.Serial annotations in java.desktop Reviewed-by: aivanov, psadhukhan ! src/java.desktop/share/classes/com/sun/beans/editors/ColorEditor.java ! src/java.desktop/share/classes/com/sun/beans/editors/FontEditor.java ! src/java.desktop/share/classes/com/sun/beans/finder/SignatureException.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleCMYKColorSpace.java ! src/java.desktop/share/classes/com/sun/media/sound/InvalidDataException.java ! src/java.desktop/share/classes/com/sun/media/sound/InvalidFormatException.java ! src/java.desktop/share/classes/com/sun/media/sound/RIFFInvalidDataException.java ! src/java.desktop/share/classes/com/sun/media/sound/RIFFInvalidFormatException.java ! src/java.desktop/share/classes/java/applet/Applet.java ! src/java.desktop/share/classes/java/awt/AWTError.java ! src/java.desktop/share/classes/java/awt/AWTEvent.java ! src/java.desktop/share/classes/java/awt/AWTException.java ! src/java.desktop/share/classes/java/awt/AWTKeyStroke.java ! src/java.desktop/share/classes/java/awt/AWTPermission.java ! src/java.desktop/share/classes/java/awt/BorderLayout.java ! src/java.desktop/share/classes/java/awt/Button.java ! src/java.desktop/share/classes/java/awt/Canvas.java ! src/java.desktop/share/classes/java/awt/CardLayout.java ! src/java.desktop/share/classes/java/awt/Checkbox.java ! src/java.desktop/share/classes/java/awt/CheckboxGroup.java ! src/java.desktop/share/classes/java/awt/CheckboxMenuItem.java ! src/java.desktop/share/classes/java/awt/Choice.java ! src/java.desktop/share/classes/java/awt/Color.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/ComponentOrientation.java ! src/java.desktop/share/classes/java/awt/Container.java ! src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java ! src/java.desktop/share/classes/java/awt/Cursor.java ! src/java.desktop/share/classes/java/awt/DefaultFocusTraversalPolicy.java ! src/java.desktop/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/java.desktop/share/classes/java/awt/Dialog.java ! src/java.desktop/share/classes/java/awt/Dimension.java ! src/java.desktop/share/classes/java/awt/Event.java ! src/java.desktop/share/classes/java/awt/FileDialog.java ! src/java.desktop/share/classes/java/awt/FlowLayout.java ! src/java.desktop/share/classes/java/awt/Font.java ! src/java.desktop/share/classes/java/awt/FontFormatException.java ! src/java.desktop/share/classes/java/awt/FontMetrics.java ! src/java.desktop/share/classes/java/awt/Frame.java ! src/java.desktop/share/classes/java/awt/GraphicsConfigTemplate.java ! src/java.desktop/share/classes/java/awt/GridBagConstraints.java ! src/java.desktop/share/classes/java/awt/GridBagLayout.java ! src/java.desktop/share/classes/java/awt/GridBagLayoutInfo.java ! src/java.desktop/share/classes/java/awt/GridLayout.java ! src/java.desktop/share/classes/java/awt/HeadlessException.java ! src/java.desktop/share/classes/java/awt/IllegalComponentStateException.java ! src/java.desktop/share/classes/java/awt/Insets.java ! src/java.desktop/share/classes/java/awt/Label.java ! src/java.desktop/share/classes/java/awt/List.java ! src/java.desktop/share/classes/java/awt/MediaTracker.java ! src/java.desktop/share/classes/java/awt/Menu.java ! src/java.desktop/share/classes/java/awt/MenuBar.java ! src/java.desktop/share/classes/java/awt/MenuComponent.java ! src/java.desktop/share/classes/java/awt/MenuItem.java ! src/java.desktop/share/classes/java/awt/MenuShortcut.java ! src/java.desktop/share/classes/java/awt/Panel.java ! src/java.desktop/share/classes/java/awt/Point.java ! src/java.desktop/share/classes/java/awt/Polygon.java ! src/java.desktop/share/classes/java/awt/PopupMenu.java ! src/java.desktop/share/classes/java/awt/Rectangle.java ! src/java.desktop/share/classes/java/awt/ScrollPane.java ! src/java.desktop/share/classes/java/awt/ScrollPaneAdjustable.java ! src/java.desktop/share/classes/java/awt/Scrollbar.java ! src/java.desktop/share/classes/java/awt/SentEvent.java ! src/java.desktop/share/classes/java/awt/SequencedEvent.java ! src/java.desktop/share/classes/java/awt/SystemColor.java ! src/java.desktop/share/classes/java/awt/TextArea.java ! src/java.desktop/share/classes/java/awt/TextComponent.java ! src/java.desktop/share/classes/java/awt/TextField.java ! src/java.desktop/share/classes/java/awt/Window.java ! src/java.desktop/share/classes/java/awt/color/CMMException.java ! src/java.desktop/share/classes/java/awt/color/ColorSpace.java ! src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java ! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java ! src/java.desktop/share/classes/java/awt/color/ICC_ProfileGray.java ! src/java.desktop/share/classes/java/awt/color/ICC_ProfileRGB.java ! src/java.desktop/share/classes/java/awt/color/ProfileDataException.java ! src/java.desktop/share/classes/java/awt/desktop/AboutEvent.java ! src/java.desktop/share/classes/java/awt/desktop/AppEvent.java ! src/java.desktop/share/classes/java/awt/desktop/AppForegroundEvent.java ! src/java.desktop/share/classes/java/awt/desktop/AppHiddenEvent.java ! src/java.desktop/share/classes/java/awt/desktop/AppReopenedEvent.java ! src/java.desktop/share/classes/java/awt/desktop/FilesEvent.java ! src/java.desktop/share/classes/java/awt/desktop/OpenFilesEvent.java ! src/java.desktop/share/classes/java/awt/desktop/OpenURIEvent.java ! src/java.desktop/share/classes/java/awt/desktop/PreferencesEvent.java ! src/java.desktop/share/classes/java/awt/desktop/PrintFilesEvent.java ! src/java.desktop/share/classes/java/awt/desktop/QuitEvent.java ! src/java.desktop/share/classes/java/awt/desktop/ScreenSleepEvent.java ! src/java.desktop/share/classes/java/awt/desktop/SystemSleepEvent.java ! src/java.desktop/share/classes/java/awt/desktop/UserSessionEvent.java ! src/java.desktop/share/classes/java/awt/dnd/DragGestureEvent.java ! src/java.desktop/share/classes/java/awt/dnd/DragGestureRecognizer.java ! src/java.desktop/share/classes/java/awt/dnd/DragSource.java ! src/java.desktop/share/classes/java/awt/dnd/DragSourceContext.java ! src/java.desktop/share/classes/java/awt/dnd/DragSourceDragEvent.java ! src/java.desktop/share/classes/java/awt/dnd/DragSourceDropEvent.java ! src/java.desktop/share/classes/java/awt/dnd/DragSourceEvent.java ! src/java.desktop/share/classes/java/awt/dnd/DropTarget.java ! src/java.desktop/share/classes/java/awt/dnd/DropTargetContext.java ! src/java.desktop/share/classes/java/awt/dnd/DropTargetDragEvent.java ! src/java.desktop/share/classes/java/awt/dnd/DropTargetDropEvent.java ! src/java.desktop/share/classes/java/awt/dnd/DropTargetEvent.java ! src/java.desktop/share/classes/java/awt/dnd/InvalidDnDOperationException.java ! src/java.desktop/share/classes/java/awt/dnd/MouseDragGestureRecognizer.java ! src/java.desktop/share/classes/java/awt/event/ActionEvent.java ! src/java.desktop/share/classes/java/awt/event/AdjustmentEvent.java ! src/java.desktop/share/classes/java/awt/event/ComponentEvent.java ! src/java.desktop/share/classes/java/awt/event/ContainerEvent.java ! src/java.desktop/share/classes/java/awt/event/FocusEvent.java ! src/java.desktop/share/classes/java/awt/event/HierarchyEvent.java ! src/java.desktop/share/classes/java/awt/event/InputEvent.java ! src/java.desktop/share/classes/java/awt/event/InputMethodEvent.java ! src/java.desktop/share/classes/java/awt/event/InvocationEvent.java ! src/java.desktop/share/classes/java/awt/event/ItemEvent.java ! src/java.desktop/share/classes/java/awt/event/KeyEvent.java ! src/java.desktop/share/classes/java/awt/event/MouseEvent.java ! src/java.desktop/share/classes/java/awt/event/MouseWheelEvent.java ! src/java.desktop/share/classes/java/awt/event/PaintEvent.java ! src/java.desktop/share/classes/java/awt/event/TextEvent.java ! src/java.desktop/share/classes/java/awt/event/WindowEvent.java ! src/java.desktop/share/classes/java/awt/font/NumericShaper.java ! src/java.desktop/share/classes/java/awt/font/TextAttribute.java ! src/java.desktop/share/classes/java/awt/font/TransformAttribute.java ! src/java.desktop/share/classes/java/awt/geom/AffineTransform.java ! src/java.desktop/share/classes/java/awt/geom/Arc2D.java ! src/java.desktop/share/classes/java/awt/geom/CubicCurve2D.java ! src/java.desktop/share/classes/java/awt/geom/Ellipse2D.java ! src/java.desktop/share/classes/java/awt/geom/GeneralPath.java ! src/java.desktop/share/classes/java/awt/geom/IllegalPathStateException.java ! src/java.desktop/share/classes/java/awt/geom/Line2D.java ! src/java.desktop/share/classes/java/awt/geom/NoninvertibleTransformException.java ! src/java.desktop/share/classes/java/awt/geom/Path2D.java ! src/java.desktop/share/classes/java/awt/geom/Point2D.java ! src/java.desktop/share/classes/java/awt/geom/QuadCurve2D.java ! src/java.desktop/share/classes/java/awt/geom/Rectangle2D.java ! src/java.desktop/share/classes/java/awt/geom/RoundRectangle2D.java ! src/java.desktop/share/classes/java/awt/image/ImagingOpException.java ! src/java.desktop/share/classes/java/awt/image/RasterFormatException.java ! src/java.desktop/share/classes/java/awt/image/renderable/ParameterBlock.java ! src/java.desktop/share/classes/java/awt/print/PrinterAbortException.java ! src/java.desktop/share/classes/java/awt/print/PrinterException.java ! src/java.desktop/share/classes/java/awt/print/PrinterIOException.java ! src/java.desktop/share/classes/java/beans/IndexedPropertyChangeEvent.java ! src/java.desktop/share/classes/java/beans/IntrospectionException.java ! src/java.desktop/share/classes/java/beans/PropertyChangeEvent.java ! src/java.desktop/share/classes/java/beans/PropertyChangeSupport.java ! src/java.desktop/share/classes/java/beans/PropertyVetoException.java ! src/java.desktop/share/classes/java/beans/VetoableChangeSupport.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextChildSupport.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextEvent.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextMembershipEvent.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextServiceAvailableEvent.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextServiceRevokedEvent.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextServicesSupport.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextSupport.java ! src/java.desktop/share/classes/javax/imageio/IIOException.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOInvalidTreeException.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataNode.java ! src/java.desktop/share/classes/javax/imageio/spi/DigraphNode.java ! src/java.desktop/share/classes/javax/print/DocFlavor.java ! src/java.desktop/share/classes/javax/print/MimeType.java ! src/java.desktop/share/classes/javax/print/PrintException.java ! src/java.desktop/share/classes/javax/print/attribute/AttributeSetUtilities.java ! src/java.desktop/share/classes/javax/print/attribute/DateTimeSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/EnumSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/HashAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/HashDocAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/HashPrintJobAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/HashPrintRequestAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/HashPrintServiceAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/IntegerSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/ResolutionSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/SetOfIntegerSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/Size2DSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/TextSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/URISyntax.java ! src/java.desktop/share/classes/javax/print/attribute/UnmodifiableSetException.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Chromaticity.java ! src/java.desktop/share/classes/javax/print/attribute/standard/ColorSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Compression.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Copies.java ! src/java.desktop/share/classes/javax/print/attribute/standard/CopiesSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DateTimeAtCompleted.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DateTimeAtCreation.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DateTimeAtProcessing.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Destination.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DialogOwner.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DialogTypeSelection.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DocumentName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Fidelity.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Finishings.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobHoldUntil.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobImpressions.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobImpressionsCompleted.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobImpressionsSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobKOctets.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobKOctetsProcessed.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobKOctetsSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobMediaSheets.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobMediaSheetsCompleted.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobMediaSheetsSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobMessageFromOperator.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobOriginatingUserName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobPriority.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobPrioritySupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobSheets.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobState.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobStateReason.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobStateReasons.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Media.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MediaName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MediaPrintableArea.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MediaSize.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MediaSizeName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MediaTray.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MultipleDocumentHandling.java ! src/java.desktop/share/classes/javax/print/attribute/standard/NumberOfDocuments.java ! src/java.desktop/share/classes/javax/print/attribute/standard/NumberOfInterveningJobs.java ! src/java.desktop/share/classes/javax/print/attribute/standard/NumberUp.java ! src/java.desktop/share/classes/javax/print/attribute/standard/NumberUpSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/OrientationRequested.java ! src/java.desktop/share/classes/javax/print/attribute/standard/OutputDeviceAssigned.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PDLOverrideSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PageRanges.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PagesPerMinute.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PagesPerMinuteColor.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PresentationDirection.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrintQuality.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterInfo.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterIsAcceptingJobs.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterLocation.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMakeAndModel.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMessageFromOperator.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMoreInfo.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMoreInfoManufacturer.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterResolution.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterState.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterStateReason.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterURI.java ! src/java.desktop/share/classes/javax/print/attribute/standard/QueuedJobCount.java ! src/java.desktop/share/classes/javax/print/attribute/standard/ReferenceUriSchemesSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/RequestingUserName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Severity.java ! src/java.desktop/share/classes/javax/print/attribute/standard/SheetCollate.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Sides.java ! src/java.desktop/share/classes/javax/print/event/PrintEvent.java ! src/java.desktop/share/classes/javax/print/event/PrintJobAttributeEvent.java ! src/java.desktop/share/classes/javax/print/event/PrintJobEvent.java ! src/java.desktop/share/classes/javax/print/event/PrintServiceAttributeEvent.java ! src/java.desktop/share/classes/javax/sound/midi/InvalidMidiDataException.java ! src/java.desktop/share/classes/javax/sound/midi/MidiUnavailableException.java ! src/java.desktop/share/classes/javax/sound/sampled/AudioPermission.java ! src/java.desktop/share/classes/javax/sound/sampled/LineEvent.java ! src/java.desktop/share/classes/javax/sound/sampled/LineUnavailableException.java ! src/java.desktop/share/classes/javax/sound/sampled/UnsupportedAudioFileException.java ! src/java.desktop/share/classes/javax/swing/AbstractAction.java ! src/java.desktop/share/classes/javax/swing/ActionMap.java ! src/java.desktop/share/classes/javax/swing/ActionPropertyChangeListener.java ! src/java.desktop/share/classes/javax/swing/CellRendererPane.java ! src/java.desktop/share/classes/javax/swing/ImageIcon.java ! src/java.desktop/share/classes/javax/swing/InputMap.java ! src/java.desktop/share/classes/javax/swing/JButton.java ! src/java.desktop/share/classes/javax/swing/JCheckBox.java ! src/java.desktop/share/classes/javax/swing/JCheckBoxMenuItem.java ! src/java.desktop/share/classes/javax/swing/JColorChooser.java ! src/java.desktop/share/classes/javax/swing/JComboBox.java ! src/java.desktop/share/classes/javax/swing/JComponent.java ! src/java.desktop/share/classes/javax/swing/JDesktopPane.java ! src/java.desktop/share/classes/javax/swing/JEditorPane.java ! src/java.desktop/share/classes/javax/swing/JFileChooser.java ! src/java.desktop/share/classes/javax/swing/JFormattedTextField.java ! src/java.desktop/share/classes/javax/swing/JInternalFrame.java ! src/java.desktop/share/classes/javax/swing/JLabel.java ! src/java.desktop/share/classes/javax/swing/JLayer.java ! src/java.desktop/share/classes/javax/swing/JList.java ! src/java.desktop/share/classes/javax/swing/JMenu.java ! src/java.desktop/share/classes/javax/swing/JMenuBar.java ! src/java.desktop/share/classes/javax/swing/JMenuItem.java ! src/java.desktop/share/classes/javax/swing/JOptionPane.java ! src/java.desktop/share/classes/javax/swing/JPanel.java ! src/java.desktop/share/classes/javax/swing/JPasswordField.java ! src/java.desktop/share/classes/javax/swing/JPopupMenu.java ! src/java.desktop/share/classes/javax/swing/JProgressBar.java ! src/java.desktop/share/classes/javax/swing/JRadioButton.java ! src/java.desktop/share/classes/javax/swing/JRadioButtonMenuItem.java ! src/java.desktop/share/classes/javax/swing/JScrollBar.java ! src/java.desktop/share/classes/javax/swing/JScrollPane.java ! src/java.desktop/share/classes/javax/swing/JSeparator.java ! src/java.desktop/share/classes/javax/swing/JSlider.java ! src/java.desktop/share/classes/javax/swing/JSpinner.java ! src/java.desktop/share/classes/javax/swing/JSplitPane.java ! src/java.desktop/share/classes/javax/swing/JTabbedPane.java ! src/java.desktop/share/classes/javax/swing/JTable.java ! src/java.desktop/share/classes/javax/swing/JTextArea.java ! src/java.desktop/share/classes/javax/swing/JTextField.java ! src/java.desktop/share/classes/javax/swing/JTextPane.java ! src/java.desktop/share/classes/javax/swing/JToggleButton.java ! src/java.desktop/share/classes/javax/swing/JToolBar.java ! src/java.desktop/share/classes/javax/swing/JToolTip.java ! src/java.desktop/share/classes/javax/swing/JTree.java ! src/java.desktop/share/classes/javax/swing/KeyStroke.java ! src/java.desktop/share/classes/javax/swing/LayoutFocusTraversalPolicy.java ! src/java.desktop/share/classes/javax/swing/LegacyGlueFocusTraversalPolicy.java ! src/java.desktop/share/classes/javax/swing/Timer.java ! src/java.desktop/share/classes/javax/swing/event/EventListenerList.java ! src/java.desktop/share/classes/javax/swing/event/SwingPropertyChangeSupport.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/table/JTableHeader.java ! src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java ! src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java ! src/java.desktop/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/java.desktop/share/classes/javax/swing/text/GapContent.java ! src/java.desktop/share/classes/javax/swing/text/InternationalFormatter.java ! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java ! src/java.desktop/share/classes/javax/swing/text/MaskFormatter.java ! src/java.desktop/share/classes/javax/swing/text/SimpleAttributeSet.java ! src/java.desktop/share/classes/javax/swing/text/StyleContext.java ! src/java.desktop/share/classes/javax/swing/text/html/CSS.java ! src/java.desktop/share/classes/javax/swing/text/html/HTML.java ! src/java.desktop/share/classes/javax/swing/text/html/parser/ParserDelegator.java ! src/java.desktop/share/classes/javax/swing/tree/DefaultMutableTreeNode.java ! src/java.desktop/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/java.desktop/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java ! src/java.desktop/share/classes/sun/awt/CausedFocusEvent.java ! src/java.desktop/share/classes/sun/awt/EmbeddedFrame.java ! src/java.desktop/share/classes/sun/awt/im/CompositionArea.java ! src/java.desktop/share/classes/sun/awt/im/InputMethodJFrame.java ! src/java.desktop/share/classes/sun/awt/im/SimpleInputMethodWindow.java ! src/java.desktop/share/classes/sun/awt/shell/DefaultShellFolder.java ! src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java ! src/java.desktop/share/classes/sun/font/FontDesignMetrics.java ! src/java.desktop/share/classes/sun/print/CustomMediaSizeName.java ! src/java.desktop/share/classes/sun/print/CustomMediaTray.java ! src/java.desktop/share/classes/sun/print/PrinterJobWrapper.java ! src/java.desktop/share/classes/sun/print/SunAlternateMedia.java ! src/java.desktop/share/classes/sun/swing/PrintColorUIResource.java ! src/java.desktop/unix/classes/sun/awt/X11/XMouseDragGestureRecognizer.java ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/java.desktop/windows/classes/sun/awt/windows/WMouseDragGestureRecognizer.java Changeset: e3b548a6 Author: Yasumasa Suenaga Date: 2021-01-15 01:58:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3b548a6 8257736: InputStream from BodyPublishers.ofInputStream() leaks when IOE happens Reviewed-by: dfuchs, chegar ! src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java + test/jdk/java/net/httpclient/StreamCloseTest.java Changeset: 90960c5f Author: Yasumasa Suenaga Date: 2021-01-15 02:47:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/90960c5f 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed Reviewed-by: dholmes, sspitsyn ! src/hotspot/share/prims/jvmti.xml ! src/hotspot/share/prims/jvmtiExport.cpp ! test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java Changeset: 0148adf2 Author: Vladimir Ivanov Date: 2021-01-14 17:18:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0148adf2 8255120: C2: assert(outer->outcnt() >= phis + 2 && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis Reviewed-by: thartmann ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/loopnode.hpp ! test/hotspot/jtreg/ProblemList.txt Changeset: 4307fa68 Author: Erik Gahlin Date: 2021-01-14 21:26:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4307fa68 8253505: JFR: onFlush invoked out of order with a sorted event stream Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingFile.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ChunkParser.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/Dispatcher.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventDirectoryStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventFileStream.java Changeset: d701babb Author: Jesper Wilhelmsson Date: 2021-01-15 03:10:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d701babb Merge ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java ! test/hotspot/jtreg/ProblemList.txt ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java ! test/hotspot/jtreg/ProblemList.txt Changeset: 2c8e337d Author: Tagir F. Valeev Date: 2021-01-15 04:11:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2c8e337d 8259622: TreeMap.computeIfAbsent deviates from spec Reviewed-by: smarks ! src/java.base/share/classes/java/util/TreeMap.java ! test/jdk/java/util/Map/InPlaceOpsCollisions.java Changeset: 6d4a593f Author: Richard Reingruber Date: 2021-01-15 07:39:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6d4a593f 8259627: Potential memory leaks in JVMTI after JDK-8227745 Reviewed-by: shade, stuefe, dholmes, sspitsyn ! src/hotspot/share/prims/jvmtiEnv.cpp Changeset: b01a15e4 Author: K Suman Rajkumaar <70650887+skodanda at users.noreply.github.com> Committer: Alexey Ivanov Date: 2021-01-15 09:40:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b01a15e4 8258884: [TEST_BUG] Convert applet-based test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a regular java test Reviewed-by: aivanov, serb - test/jdk/javax/swing/JMenuItem/8031573/bug8031573.html ! test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java Changeset: ed91e293 Author: duke Date: 2021-01-15 11:01:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ed91e293 Automatic merge of jdk:master into master Changeset: e69b59e5 Author: duke Date: 2021-01-15 11:01:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e69b59e5 Automatic merge of master into foreign-memaccess+abi From mcimadamore at openjdk.java.net Fri Jan 15 11:22:15 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 15 Jan 2021 11:22:15 GMT Subject: [foreign-memaccess+abi] RFR: Make `UNSAFE` variable static final In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 22:36:14 GMT, Radoslaw Smogura wrote: > Make `UNSAFE` static final, to avoid null checks > and traps. Whoops - well spotted! ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/436 From duke at openjdk.java.net Fri Jan 15 11:18:11 2021 From: duke at openjdk.java.net (duke) Date: Fri, 15 Jan 2021 11:18:11 GMT Subject: git: openjdk/panama-foreign: master: 134 new changesets Message-ID: <913a436d-da9b-4b85-99fe-10241304f349@openjdk.org> Changeset: 697bf7ab Author: Guoxiong Li Committer: Vicente Romero Date: 2021-01-08 13:56:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/697bf7ab 8257740: Compiler crash when compiling type annotation on multicatch inside lambda Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/langtools/tools/javac/T8257740/T8257740_1.java + test/langtools/tools/javac/T8257740/T8257740_2.java Changeset: 6f7723b4 Author: Eric Caspole Date: 2021-01-08 14:18:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6f7723b4 8258792: LogCompilation: remove redundant check fixed by 8257518 Reviewed-by: kvn, redestad ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/LogCompilation.java Changeset: 10a6b0d9 Author: Kim Barrett Date: 2021-01-08 14:25:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/10a6b0d9 8234773: Fix ThreadsSMRSupport::_bootstrap_list Make ThreadsList noncopyable, direct initializing _bootstrap_list. Avoid C-heap allocation for _bootstrap_list. Reviewed-by: dholmes, dcubed ! src/hotspot/share/runtime/threadSMR.cpp ! src/hotspot/share/runtime/threadSMR.hpp Changeset: 090bd3af Author: Daniel D. Daugherty Date: 2021-01-08 15:30:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/090bd3af 8259397: ThreadsSMRSupport::print_info_on() should use try_lock_without_rank_check() Reviewed-by: coleenp, dholmes ! src/hotspot/share/runtime/threadSMR.cpp Changeset: 876c7fb5 Author: Roger Riggs Date: 2021-01-08 21:31:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/876c7fb5 8259493: [test] Use HexFormat instead of adhoc hex utilities in network code and locale SoftKeys Reviewed-by: lancea, naoto ! test/jdk/java/net/Authenticator/B6870935.java ! test/jdk/java/net/HttpURLConnection/SetAuthenticator/HTTPTestServer.java ! test/jdk/java/net/httpclient/DigestEchoServer.java ! test/jdk/java/util/Locale/SoftKeys.java ! test/jdk/sun/net/www/protocol/http/DigestTest.java Changeset: 628c546b Author: Roger Riggs Date: 2021-01-08 21:32:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/628c546b 8258796: [test] Apply HexFormat to tests for java.security Reviewed-by: xuelei ! test/jdk/com/sun/crypto/provider/Cipher/AEAD/SameBuffer.java ! test/jdk/com/sun/crypto/provider/Cipher/Blowfish/BlowfishTestVector.java ! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20KAT.java ! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20KeyGeneratorTest.java ! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20NoReuse.java ! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20Poly1305ParamTest.java ! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/ChaCha20CipherUnitTest.java ! test/jdk/com/sun/crypto/provider/KeyAgreement/DHKeyAgreement2.java ! test/jdk/com/sun/crypto/provider/KeyAgreement/DHKeyAgreement3.java ! test/jdk/com/sun/crypto/provider/KeyFactory/PBKDF2HmacSHA1FactoryTest.java ! test/jdk/com/sun/crypto/provider/TLS/TestLeadingZeroes.java ! test/jdk/java/security/KeyAgreement/KeySizeTest.java ! test/jdk/java/security/KeyAgreement/NegativeTest.java ! test/jdk/javax/crypto/SecretKeyFactory/SecKeyFacSunJCEPrf.java ! test/jdk/sun/security/ec/SignatureDigestTruncate.java ! test/jdk/sun/security/ec/SignatureKAT.java ! test/jdk/sun/security/ec/ed/EdDSAKeySize.java ! test/jdk/sun/security/ec/ed/EdDSANegativeTest.java ! test/jdk/sun/security/ec/ed/EdDSAParamSpec.java ! test/jdk/sun/security/ec/ed/EdDSATest.java ! test/jdk/sun/security/ec/ed/EdECKeyFormat.java ! test/jdk/sun/security/ec/ed/TestEdDSA.java ! test/jdk/sun/security/ec/ed/TestEdOps.java ! test/jdk/sun/security/ec/xec/TestXDH.java ! test/jdk/sun/security/ec/xec/TestXECOps.java ! test/jdk/sun/security/ec/xec/XECIterative.java ! test/jdk/sun/security/ec/xec/XECKeyFormat.java ! test/jdk/sun/security/krb5/RFC396xTest.java ! test/jdk/sun/security/krb5/auto/ReplayCacheTestProc.java ! test/jdk/sun/security/krb5/etype/KerberosAesSha2.java ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java ! test/jdk/sun/security/pkcs/pkcs8/PKCS8Test.java ! test/jdk/sun/security/pkcs11/tls/TestLeadingZeroesP11.java ! test/jdk/sun/security/provider/DSA/TestDSA.java ! test/jdk/sun/security/provider/MessageDigest/DigestKAT.java ! test/jdk/sun/security/rsa/SigRecord.java ! test/jdk/sun/security/rsa/TestSigGen15.java ! test/jdk/sun/security/rsa/pss/SigRecord.java ! test/jdk/sun/security/rsa/pss/TestSigGenPSS.java ! test/jdk/sun/security/util/math/TestIntegerModuloP.java ! test/jdk/sun/security/x509/X500Name/DerValueConstructor.java ! test/lib/jdk/test/lib/Convert.java ! test/lib/jdk/test/lib/Utils.java Changeset: 7e6677b5 Author: David Holmes Date: 2021-01-08 22:25:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7e6677b5 8259446: runtime/jni/checked/TestCheckedReleaseArrayElements.java fails with stderr not empty Reviewed-by: dcubed ! test/hotspot/jtreg/runtime/jni/checked/TestCheckedReleaseArrayElements.java Changeset: a6539282 Author: Joe Darcy Date: 2021-01-09 00:03:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a6539282 8259512: Update --release 16 symbol information for JDK 16 build 31 Reviewed-by: jjg ! make/data/symbols/jdk.incubator.vector-G.sym.txt Changeset: 6472104e Author: Sergey Bylokhov Date: 2021-01-09 07:22:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6472104e 6278172: TextComponent.getSelectedText() throws StringIndexOutOfBoundsException Reviewed-by: aivanov ! src/java.desktop/share/classes/java/awt/TextComponent.java + test/jdk/java/awt/TextComponent/SetTextSelection.java Changeset: 5cfa8c94 Author: Martin Buchholz Date: 2021-01-09 20:57:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5cfa8c94 8246585: ForkJoin updates 8229253: forkjoin/FJExceptionTableLeak.java fails "AssertionError: failed to satisfy condition" Reviewed-by: dl ! src/java.base/share/classes/java/util/concurrent/CountedCompleter.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java + test/jdk/java/util/concurrent/forkjoin/AsyncShutdownNow.java + test/jdk/java/util/concurrent/forkjoin/AsyncShutdownNowInvokeAny.java + test/jdk/java/util/concurrent/forkjoin/AsyncShutdownNowInvokeAnyRace.java - test/jdk/java/util/concurrent/forkjoin/FJExceptionTableLeak.java ! test/jdk/java/util/concurrent/tck/ForkJoinTaskTest.java Changeset: 63e3bd76 Author: Martin Buchholz Date: 2021-01-09 21:08:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/63e3bd76 8246677: LinkedTransferQueue and SynchronousQueue synchronization updates Reviewed-by: alanb, dl ! src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java ! test/jdk/java/util/concurrent/LinkedTransferQueue/WhiteBox.java Changeset: 270014ab Author: Martin Buchholz Date: 2021-01-09 21:59:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/270014ab 8234131: Miscellaneous changes imported from jsr166 CVS 2021-01 8257671: ThreadPoolExecutor.Discard*Policy: rejected tasks are not cancelled Reviewed-by: alanb, prappo, dl ! src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java ! src/java.base/share/classes/java/util/concurrent/CopyOnWriteArraySet.java ! src/java.base/share/classes/java/util/concurrent/CountDownLatch.java ! src/java.base/share/classes/java/util/concurrent/CyclicBarrier.java ! src/java.base/share/classes/java/util/concurrent/Exchanger.java ! src/java.base/share/classes/java/util/concurrent/ExecutorService.java ! src/java.base/share/classes/java/util/concurrent/Future.java ! src/java.base/share/classes/java/util/concurrent/Phaser.java ! src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/java.base/share/classes/java/util/concurrent/Semaphore.java ! src/java.base/share/classes/java/util/concurrent/SubmissionPublisher.java ! src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicBoolean.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/java.base/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java ! src/java.base/share/classes/java/util/concurrent/atomic/DoubleAdder.java ! src/java.base/share/classes/java/util/concurrent/atomic/LongAccumulator.java ! src/java.base/share/classes/java/util/concurrent/atomic/LongAdder.java ! src/java.base/share/classes/java/util/concurrent/atomic/Striped64.java ! src/java.base/share/classes/java/util/concurrent/atomic/package-info.java ! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java ! src/java.base/share/classes/java/util/concurrent/locks/ReentrantLock.java ! src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java ! src/java.base/share/classes/java/util/concurrent/locks/StampedLock.java ! test/jdk/java/util/Collection/IteratorMicroBenchmark.java ! test/jdk/java/util/concurrent/ExecutorService/Invoke.java ! test/jdk/java/util/concurrent/tck/ArrayBlockingQueueTest.java ! test/jdk/java/util/concurrent/tck/ArrayDequeTest.java ! test/jdk/java/util/concurrent/tck/ArrayListTest.java ! test/jdk/java/util/concurrent/tck/Collection8Test.java ! test/jdk/java/util/concurrent/tck/CompletableFutureTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentLinkedDequeTest.java ! test/jdk/java/util/concurrent/tck/ExecutorsTest.java ! test/jdk/java/util/concurrent/tck/ForkJoinPoolTest.java ! test/jdk/java/util/concurrent/tck/JSR166TestCase.java ! test/jdk/java/util/concurrent/tck/RecursiveTaskTest.java ! test/jdk/java/util/concurrent/tck/SplittableRandomTest.java ! test/jdk/java/util/concurrent/tck/StampedLockTest.java ! test/jdk/java/util/concurrent/tck/SubmissionPublisherTest.java ! test/jdk/java/util/concurrent/tck/SynchronousQueueTest.java ! test/jdk/java/util/concurrent/tck/ThreadLocalRandomTest.java Changeset: 81db63e8 Author: Xue-Lei Andrew Fan Date: 2021-01-10 04:36:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81db63e8 8259517: Incorrect test path in test cases Reviewed-by: weijun ! test/jdk/javax/net/ssl/SSLEngine/ArgCheck.java ! test/jdk/javax/net/ssl/SSLEngine/Basics.java ! test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java Changeset: 65ca5c66 Author: Tejpal Rebari Date: 2021-01-10 12:38:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/65ca5c66 8048109: JToggleButton does not fire actionPerformed under certain conditions Reviewed-by: serb, psadhukhan, vdyakov ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java + test/jdk/javax/swing/JPopupMenu/SetInvokerJPopupMenuTest.java Changeset: 11d5b047 Author: Martin Buchholz Date: 2021-01-10 18:20:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/11d5b047 8258217: PriorityBlockingQueue constructor spec and behavior mismatch Reviewed-by: dl ! src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java Changeset: e7c17408 Author: Martin Buchholz Date: 2021-01-10 18:38:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e7c17408 8258187: IllegalMonitorStateException in ArrayBlockingQueue Reviewed-by: dl ! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java Changeset: 9154f643 Author: Martin Buchholz Date: 2021-01-10 23:47:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9154f643 8254973: CompletableFuture.ThreadPerTaskExecutor does not throw NPE in #execute Reviewed-by: dl ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java Changeset: b72de3c5 Author: Xue-Lei Andrew Fan Date: 2021-01-11 00:33:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b72de3c5 8259385: Cleanup unused assignment Reviewed-by: attila ! src/java.base/share/classes/sun/security/ssl/CertStatusExtension.java ! src/java.base/share/classes/sun/security/ssl/CertificateStatus.java ! src/java.base/share/classes/sun/security/ssl/CertificateVerify.java ! src/java.base/share/classes/sun/security/ssl/DHServerKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java ! src/java.base/share/classes/sun/security/ssl/ECDHClientKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/Finished.java ! src/java.base/share/classes/sun/security/ssl/OutputRecord.java ! src/java.base/share/classes/sun/security/ssl/RSAKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/RSAServerKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/SSLCipher.java ! src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLEngineInputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLTransport.java ! src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java Changeset: 2806bf2e Author: Aleksey Shipilev Date: 2021-01-11 07:32:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2806bf2e 8259475: Fix bad merge in compilerOracle Reviewed-by: redestad, thartmann ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/compiler/compilerOracle.hpp Changeset: bb247b02 Author: Aleksey Shipilev Date: 2021-01-11 07:32:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb247b02 8259392: Zero error reporting is broken after JDK-8255711 Reviewed-by: dholmes ! src/hotspot/os/posix/signals_posix.cpp Changeset: 3974fd4f Author: Aleksey Shipilev Date: 2021-01-11 07:33:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3974fd4f 8259451: Zero: skip serviceability/sa tests, set vm.hasSA to false Reviewed-by: sgehwolf, cjplummer ! test/lib/jdk/test/lib/Platform.java Changeset: d21a0ea1 Author: Magnus Ihse Bursie Date: 2021-01-11 07:37:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d21a0ea1 8258449: Move make/hotspot/symbols to make/data Reviewed-by: erikj = make/data/hotspot-symbols/symbols-aix = make/data/hotspot-symbols/symbols-aix-debug = make/data/hotspot-symbols/symbols-linux = make/data/hotspot-symbols/symbols-macosx = make/data/hotspot-symbols/symbols-shared = make/data/hotspot-symbols/symbols-unix ! make/hotspot/lib/JvmMapfile.gmk Changeset: bd344184 Author: Magnus Ihse Bursie Date: 2021-01-11 07:42:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bd344184 8258445: Move make/templates to make/data Reviewed-by: erikj = make/data/license-templates/bsd-header = make/data/license-templates/gpl-cp-header = make/data/license-templates/gpl-header ! make/scripts/lic_check.sh Changeset: e0d748d5 Author: Thomas Stuefe Date: 2021-01-11 09:06:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e0d748d5 8258606: os::print_signal_handlers() should resolve the function name of the handlers Reviewed-by: dholmes, coleenp, gziemski ! src/hotspot/os/posix/signals_posix.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp ! test/hotspot/gtest/runtime/test_os.cpp Changeset: a03e22bb Author: Aleksey Shipilev Date: 2021-01-11 09:42:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a03e22bb 8253910: UseCompressedClassPointers depends on UseCompressedOops in vmError.cpp Reviewed-by: rrich, dholmes ! src/hotspot/share/utilities/vmError.cpp Changeset: 18a37f94 Author: Aleksey Shipilev Date: 2021-01-11 09:43:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/18a37f94 8259368: Zero: UseCompressedClassPointers does not depend on UseCompressedOops Reviewed-by: aph, zgu ! src/hotspot/cpu/zero/globalDefinitions_zero.hpp Changeset: 23548821 Author: Jan Lahoda Date: 2021-01-11 10:10:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/23548821 8250768: javac should be adapted to changes in JEP 12 Reviewed-by: mcimadamore, erikj, jjg, ihse ! make/CompileInterimLangtools.gmk ! make/Docs.gmk ! make/autoconf/spec.gmk.in - make/jdk/src/classes/build/tools/taglet/Preview.java ! make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java ! make/modules/jdk.compiler/Gendata.gmk ! make/modules/jdk.javadoc/Gendata.gmk ! src/java.base/share/classes/java/lang/Class.java = src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java ! src/java.base/share/classes/module-info.java ! src/java.compiler/share/classes/javax/lang/model/element/Modifier.java ! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java ! src/jdk.compiler/share/classes/com/sun/source/tree/ClassTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskPool.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkFactoryImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkInfoImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PreviewListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SubWriterHolderWriter.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/TagName.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ConstructorWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/EnumConstantWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/FieldWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/MethodWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/PropertyWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstructorBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/EnumConstantBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/FieldBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MethodBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/PropertyBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Comparators.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DeprecatedAPIListBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocLink.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/SummaryAPIListBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/links/LinkFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/links/LinkInfo.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java ! src/jdk.jshell/share/classes/jdk/jshell/Snippet.java ! test/jdk/java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java ! test/jdk/java/lang/ref/CleanerTest.java ! test/jdk/java/util/Arrays/TimSortStackSize2.java ! test/jdk/jdk/modules/etc/JdkQualifiedExportTest.java ! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java ! test/langtools/jdk/javadoc/doclet/testHtmlTableTags/TestHtmlTableTags.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java + test/langtools/jdk/javadoc/doclet/testPreview/TestPreview.java + test/langtools/jdk/javadoc/doclet/testPreview/api/preview/Core.java + test/langtools/jdk/javadoc/doclet/testPreview/api/preview/CoreRecord.java + test/langtools/jdk/javadoc/doclet/testPreview/api/preview/CoreRecordComponent.java + test/langtools/jdk/javadoc/doclet/testPreview/api/preview/Reflective.java + test/langtools/jdk/javadoc/doclet/testPreview/doc/element-list = test/langtools/jdk/javadoc/doclet/testPreview/doc/java.base/preview/Core.html = test/langtools/jdk/javadoc/doclet/testPreview/doc/java.base/preview/Reflective.html + test/langtools/jdk/javadoc/doclet/testPreview/m/module-info.java + test/langtools/jdk/javadoc/doclet/testPreview/m/pkg/DocAnnotation.java + test/langtools/jdk/javadoc/doclet/testPreview/m/pkg/DocAnnotationUse1.java + test/langtools/jdk/javadoc/doclet/testPreview/m/pkg/DocAnnotationUse2.java + test/langtools/jdk/javadoc/doclet/testPreview/m/pkg/TestPreviewAPIUse.java + test/langtools/jdk/javadoc/doclet/testPreview/m/pkg/TestPreviewDeclaration.java + test/langtools/jdk/javadoc/doclet/testPreview/m/pkg/TestPreviewDeclarationUse.java ! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java ! test/langtools/jdk/javadoc/doclet/testSealedTypes/TestSealedTypes.java ! test/langtools/jdk/javadoc/doclet/testStylesheet/TestStylesheet.java ! test/langtools/jdk/javadoc/tool/CheckResourceKeys.java ! test/langtools/tools/javac/diags/examples.not-yet.txt ! test/langtools/tools/javac/diags/examples/CantExtendSealedInAnotherModule/CantExtendSealedInAnotherModule.java ! test/langtools/tools/javac/diags/examples/CantExtendSealedInAnotherPkg/CantExtendSealedInAnotherPkg.java ! test/langtools/tools/javac/diags/examples/SealedTypes.java + test/langtools/tools/javac/enum/FauxEnum3-preview.out ! test/langtools/tools/javac/lib/combo/ComboTask.java ! test/langtools/tools/javac/options/BCPOrSystemNotSpecified.java ! test/langtools/tools/javac/patterns/BreakAndLoops.java ! test/langtools/tools/javac/patterns/ConditionalTest.java ! test/langtools/tools/javac/patterns/PatternMatchPosTest.out ! test/langtools/tools/javac/platform/PreviewAPIsWithRelease.out + test/langtools/tools/javac/preview/DeclaredUsingPreview-class.out + test/langtools/tools/javac/preview/DeclaredUsingPreview-source.out + test/langtools/tools/javac/preview/DeclaredUsingPreview.java + test/langtools/tools/javac/preview/DeclaredUsingPreviewDeclarations.java + test/langtools/tools/javac/preview/PreviewAutoSuppress.java ! test/langtools/tools/javac/preview/PreviewErrors.java ! test/langtools/tools/javac/processing/model/element/TestSealed.java ! test/langtools/tools/javac/sealed/SealedDiffConfigurationsTest.java ! test/langtools/tools/jdeps/listdeps/ListModuleDeps.java Changeset: 1bd015fb Author: Magnus Ihse Bursie Date: 2021-01-11 11:28:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1bd015fb 8258407: Split up CompileJavaModules.gmk into make/modules/$M/Java.gmk Reviewed-by: erikj ! make/CompileJavaModules.gmk + make/modules/java.base/Java.gmk + make/modules/java.compiler/Java.gmk + make/modules/java.datatransfer/Java.gmk + make/modules/java.desktop/Java.gmk + make/modules/java.instrument/Java.gmk + make/modules/java.logging/Java.gmk + make/modules/java.management.rmi/Java.gmk + make/modules/java.management/Java.gmk + make/modules/java.naming/Java.gmk + make/modules/java.prefs/Java.gmk + make/modules/java.rmi/Java.gmk + make/modules/java.scripting/Java.gmk + make/modules/java.security.jgss/Java.gmk + make/modules/java.smartcardio/Java.gmk + make/modules/java.sql.rowset/Java.gmk + make/modules/java.sql/Java.gmk + make/modules/java.transaction.xa/Java.gmk + make/modules/java.xml.crypto/Java.gmk + make/modules/java.xml/Java.gmk + make/modules/jdk.aot/Java.gmk + make/modules/jdk.charsets/Java.gmk + make/modules/jdk.compiler/Java.gmk + make/modules/jdk.dev/Java.gmk + make/modules/jdk.dynalink/Java.gmk + make/modules/jdk.editpad/Java.gmk + make/modules/jdk.hotspot.agent/Java.gmk + make/modules/jdk.httpserver/Java.gmk + make/modules/jdk.incubator.vector/Java.gmk + make/modules/jdk.internal.jvmstat/Java.gmk + make/modules/jdk.internal.le/Java.gmk + make/modules/jdk.internal.opt/Java.gmk + make/modules/jdk.internal.vm.ci/Java.gmk + make/modules/jdk.internal.vm.compiler/Java.gmk + make/modules/jdk.jartool/Java.gmk + make/modules/jdk.javadoc/Java.gmk + make/modules/jdk.jcmd/Java.gmk + make/modules/jdk.jconsole/Java.gmk + make/modules/jdk.jdeps/Java.gmk + make/modules/jdk.jdi/Java.gmk + make/modules/jdk.jfr/Java.gmk + make/modules/jdk.jpackage/Java.gmk + make/modules/jdk.jshell/Java.gmk + make/modules/jdk.localedata/Java.gmk + make/modules/jdk.sctp/Java.gmk + make/modules/jdk.unsupported.desktop/Java.gmk + make/modules/sun.charsets/Java.gmk Changeset: 01b2804e Author: Clive Verghese Committer: Volker Simonis Date: 2021-01-11 12:02:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/01b2804e 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed Reviewed-by: xuelei, simonis ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLTransport.java ! test/jdk/sun/security/ssl/SSLContextImpl/TrustTrustedCert.java + test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketShouldThrowSocketException.java = test/jdk/sun/security/ssl/SSLSocketImpl/SocketExceptionForSocketIssues.java Changeset: 23801da9 Author: Coleen Phillimore Date: 2021-01-11 12:27:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/23801da9 8259482: jni_Set/GetField_probe are the same as their _nh versions Reviewed-by: hseigel, sspitsyn, dholmes ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/jvmtiExport.hpp Changeset: 33fbc10c Author: Guoxiong Li Committer: Attila Szegedi Date: 2021-01-11 13:50:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/33fbc10c 8259025: Record compact constructor using Objects.requireNonNull Reviewed-by: attila ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/langtools/tools/javac/records/RecordCompilationTests.java Changeset: cf3e4bfd Author: Harold Seigel Date: 2021-01-11 18:18:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cf3e4bfd 8258838: Remove JVM option UseStackBanging Reviewed-by: dholmes, coleenp, kvn ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/arm/macroAssembler_arm.cpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/s390/templateInterpreterGenerator_s390.cpp ! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/share/asm/assembler.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/runtime/globals.hpp ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java Changeset: dab17875 Author: Magnus Ihse Bursie Date: 2021-01-11 18:18:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dab17875 8259559: COMPARE_BUILD can't compare patch files Reviewed-by: erikj ! make/Init.gmk Changeset: 38619602 Author: Magnus Ihse Bursie Date: 2021-01-11 18:22:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/38619602 8258426: Split up autoconf/version-numbers and move it to conf dir Reviewed-by: erikj ! .github/workflows/submit.yml ! make/autoconf/jdk-options.m4 ! make/autoconf/jdk-version.m4 ! make/autoconf/spec.gmk.in - make/autoconf/version-numbers + make/conf/branding.conf ! make/conf/jib-profiles.js + make/conf/version-numbers.conf Changeset: c956e7a6 Author: Jonathan Gibbons Date: 2021-01-11 18:46:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c956e7a6 8258659: Eliminate whitespace comments from generated pages Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java ! test/langtools/jdk/javadoc/doclet/AccessSkipNav/AccessSkipNav.java ! test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java ! test/langtools/jdk/javadoc/doclet/testNavigation/TestNavigation.java Changeset: d9f21346 Author: Jonathan Gibbons Date: 2021-01-11 18:49:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d9f21346 8258655: remove <-- NewPage --> comment from generated pages Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexRedirectWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlDocument.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties Changeset: 8dfc77bf Author: Daniel D. Daugherty Date: 2021-01-11 19:44:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8dfc77bf 8259586: ProblemList dll_address_to_function_and_library_name Reviewed-by: hseigel ! test/hotspot/gtest/runtime/test_os.cpp Changeset: e9929e2b Author: Volker Simonis Date: 2021-01-11 21:36:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e9929e2b 8259582: Backout JDK-8237578 until all affected tests have been fixed Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLTransport.java ! test/jdk/sun/security/ssl/SSLContextImpl/TrustTrustedCert.java = test/jdk/sun/security/ssl/SSLSocketImpl/SSLExceptionForIOIssue.java - test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketShouldThrowSocketException.java Changeset: cd73939b Author: Naoto Sato Date: 2021-01-11 22:02:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd73939b 8259528: Broken Link for [java.text.Normalizer.Form] Reviewed-by: lancea, joehw, iris ! src/java.base/share/classes/java/text/Normalizer.java Changeset: 712ea250 Author: Yasumasa Suenaga Date: 2021-01-11 23:13:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/712ea250 8258925: configure script failed on WSL Reviewed-by: dholmes, erikj ! make/scripts/fixpath.sh Changeset: ff54b77b Author: Sergey Bylokhov Date: 2021-01-11 23:14:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ff54b77b 8259439: Apply java.io.Serial annotations in java.datatransfer Reviewed-by: aivanov, pbansal, trebari, darcy ! src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/FlavorEvent.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/MimeType.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/MimeTypeParseException.java ! src/java.datatransfer/share/classes/java/awt/datatransfer/UnsupportedFlavorException.java Changeset: 022bc9f0 Author: Andrey Turbanov Committer: Aleksei Efimov Date: 2021-01-11 23:30:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/022bc9f0 8258422: Cleanup unnecessary null comparison before instanceof check in java.base Reviewed-by: chegar, aefimov ! src/java.base/share/classes/java/io/File.java ! src/java.base/share/classes/java/lang/reflect/Constructor.java ! src/java.base/share/classes/java/lang/reflect/Field.java ! src/java.base/share/classes/java/lang/reflect/Method.java ! src/java.base/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/java.base/share/classes/java/net/AbstractPlainSocketImpl.java ! src/java.base/share/classes/java/net/DatagramPacket.java ! src/java.base/share/classes/java/net/HttpConnectSocketImpl.java ! src/java.base/share/classes/java/net/Inet4Address.java ! src/java.base/share/classes/java/net/Inet6Address.java ! src/java.base/share/classes/java/net/InetSocketAddress.java ! src/java.base/share/classes/java/net/NetMulticastSocket.java ! src/java.base/share/classes/java/net/Proxy.java ! src/java.base/share/classes/java/net/SocksSocketImpl.java ! src/java.base/share/classes/java/nio/file/attribute/AclEntry.java ! src/java.base/share/classes/jdk/internal/misc/Signal.java ! src/java.base/share/classes/sun/net/www/protocol/http/Negotiator.java ! src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/java.base/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/java.base/share/classes/sun/nio/fs/PollingWatchService.java ! src/java.base/unix/classes/sun/nio/fs/UnixPath.java ! src/java.base/windows/classes/sun/nio/fs/WindowsPath.java Changeset: b6d51e15 Author: Alexander Zuev Date: 2021-01-12 00:28:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b6d51e15 8259585: Accessible actions do not work on mac os x Reviewed-by: serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityAction.m Changeset: fb68395d Author: Michael McMahon Date: 2021-01-08 15:59:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fb68395d 8259014: (so) ServerSocketChannel.bind(UnixDomainSocketAddress)/SocketChannel.bind(UnixDomainSocketAddress) will have unknown user and group owner (win) Reviewed-by: alanb ! src/java.base/windows/native/libnio/ch/UnixDomainSockets.c Changeset: 020ec848 Author: Erik Joelsson Date: 2021-01-08 18:30:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/020ec848 8259429: Update reference to README.md Reviewed-by: iris ! make/conf/jib-profiles.js Changeset: e05f36f4 Author: Aleksey Shipilev Date: 2021-01-11 13:45:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e05f36f4 8259043: More Zero architectures need linkage with libatomic Co-authored-by: Matthias Klose Reviewed-by: erikj ! make/autoconf/libraries.m4 Changeset: d60a937e Author: Maurizio Cimadamore Date: 2021-01-11 16:14:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d60a937e 8259028: ClassCastException when using custom filesystem with wrapper FileChannel impl Reviewed-by: chegar, alanb, uschindler ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MappedMemorySegmentImpl.java ! test/jdk/java/foreign/TestByteBuffer.java Changeset: 2cb271e6 Author: Jonathan Gibbons Date: 2021-01-11 17:35:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2cb271e6 8253996: Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing Reviewed-by: hannesw ! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlOptions.java ! test/langtools/tools/javac/diags/examples.not-yet.txt + test/langtools/tools/javac/doclint/LimitedImage.java Changeset: b378f54d Author: Jesper Wilhelmsson Date: 2021-01-12 01:08:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b378f54d Merge ! make/conf/jib-profiles.js ! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/tools/javac/diags/examples.not-yet.txt ! make/conf/jib-profiles.js ! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/tools/javac/diags/examples.not-yet.txt Changeset: ae0532ed Author: Wang Huang Committer: Fei Yang Date: 2021-01-12 01:40:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ae0532ed 8259044: JVM lacks data type qualifier when using -XX:+PrintAssembly with AArch64-Neon backend Co-authored-by: He Xuejin Reviewed-by: njian, aph ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 Changeset: 2255ab76 Author: Kim Barrett Date: 2021-01-12 03:38:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2255ab76 8258810: Improve enum traits Reviewed-by: ayang, iklam, lfoltan ! src/hotspot/share/utilities/enumIterator.hpp ! test/hotspot/gtest/utilities/test_enumIterator.cpp Changeset: 77f62909 Author: Kim Barrett Date: 2021-01-12 04:12:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/77f62909 8258254: Move PtrQueue flush to PtrQueueSet subclasses Reviewed-by: tschatzl, shade ! src/hotspot/share/gc/g1/g1BarrierSet.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/g1RedirtyCardsQueue.cpp ! src/hotspot/share/gc/g1/g1RedirtyCardsQueue.hpp ! src/hotspot/share/gc/shared/ptrQueue.cpp ! src/hotspot/share/gc/shared/ptrQueue.hpp ! src/hotspot/share/gc/shared/satbMarkQueue.cpp ! src/hotspot/share/gc/shared/satbMarkQueue.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp Changeset: 61c5b95b Author: Sergey Bylokhov Date: 2021-01-12 06:53:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/61c5b95b 7194219: java/awt/Component/UpdatingBootTime/UpdatingBootTime.html fails on Linux Reviewed-by: aivanov ! src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java ! src/java.desktop/unix/classes/sun/awt/X11/XWindow.java ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Component/UpdatingBootTime/UpdatingBootTime.html ! test/jdk/java/awt/Component/UpdatingBootTime/UpdatingBootTime.java Changeset: 98ccfbf4 Author: Sergey Bylokhov Date: 2021-01-12 06:56:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/98ccfbf4 8255710: Opensource unit/regression tests for CMM Reviewed-by: pbansal, prr + test/jdk/java/awt/color/GetInstanceNullData.java + test/jdk/java/awt/color/GetNameExceptionTest.java + test/jdk/java/awt/color/GetNameTest.java + test/jdk/java/awt/color/ICC_ProfileSetNullDataTest.java + test/jdk/java/awt/color/MultiThreadCMMTest.java + test/jdk/java/awt/color/StandardProfileTest.java + test/jdk/java/awt/color/StandardProfileTest.policy + test/jdk/java/awt/color/XYZTest.java Changeset: 9d4e84fd Author: Aleksey Shipilev Date: 2021-01-12 07:49:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9d4e84fd 8259565: Zero: compiler/runtime/criticalnatives fails because CriticalJNINatives is not supported Reviewed-by: coleenp, zgu ! src/hotspot/cpu/zero/vm_version_zero.cpp ! test/hotspot/jtreg/compiler/runtime/criticalnatives/argumentcorruption/CheckLongArgs.java ! test/hotspot/jtreg/compiler/runtime/criticalnatives/lookup/LookUp.java Changeset: 46637047 Author: Aleksey Shipilev Date: 2021-01-12 07:58:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/46637047 8259583: Remove unused decode_env::_codeBuffer Reviewed-by: thartmann ! src/hotspot/share/compiler/disassembler.cpp Changeset: a3561ae8 Author: Christian Hagedorn Date: 2021-01-12 08:18:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a3561ae8 8258243: C2: assert failed ("Bad derived pointer") with -XX:+VerifyRegisterAllocator Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/chaitin.cpp + test/hotspot/jtreg/compiler/regalloc/TestVerifyRegisterAllocator.java Changeset: a6ab9e47 Author: Richard Reingruber Date: 2021-01-12 08:35:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a6ab9e47 8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled Reviewed-by: mdoerr, stuefe ! src/hotspot/share/memory/metaspace.cpp ! test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointers.java Changeset: 4697cfa4 Author: Aleksey Shipilev Date: 2021-01-12 10:52:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4697cfa4 8259576: Misplaced curly brace in Matcher::find_shared_post_visit Reviewed-by: lucy, thartmann ! src/hotspot/share/opto/matcher.cpp Changeset: ac2dee56 Author: Thomas Stuefe Date: 2021-01-12 11:41:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ac2dee56 8259539: JDK-8255711 broke trap messages Reviewed-by: lfoltan, dholmes ! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp ! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp Changeset: 400dc76f Author: Peter Zhelezniakov Committer: Alexander Scherbatiy Date: 2021-01-12 11:50:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/400dc76f 8252015: [macos11] java.awt.TrayIcon requires updates for template images Co-authored-by: Tres Finocchiaro Co-authored-by: Peter Zhelezniakov Reviewed-by: serb ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CTrayIcon.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/CTrayIcon.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/CTrayIcon.m ! src/java.desktop/share/classes/java/awt/TrayIcon.java Changeset: 563b268c Author: Sergey Platonov Committer: Aleksey Shipilev Date: 2021-01-12 11:57:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/563b268c 8257709: C1: Double assignment in InstructionPrinter::print_stack Reviewed-by: shade, chagedorn ! src/hotspot/share/c1/c1_InstructionPrinter.cpp Changeset: 4c75d14a Author: Coleen Phillimore Date: 2021-01-12 13:07:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4c75d14a 8259374: Make ThreadInVMfromNative have ResetNoHandleMark Reviewed-by: dcubed, pchilanomate ! src/hotspot/share/ci/ciUtilities.inline.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp ! src/hotspot/share/jfr/recorder/repository/jfrChunkRotation.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/runtime/handles.hpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp Changeset: ccac7aae Author: Dong Bo Committer: Fei Yang Date: 2021-01-12 13:27:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ccac7aae 8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp Reviewed-by: aph ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h + test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java Changeset: c338f116 Author: Daniel D. Daugherty Date: 2021-01-12 14:39:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c338f116 8259349: -XX:AvgMonitorsPerThreadEstimate=1 does not work right Reviewed-by: coleenp, dholmes ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp Changeset: d6a2105b Author: Phil Race Date: 2021-01-12 20:19:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d6a2105b 8259343: [macOS] Update JNI error handling in Cocoa code. Reviewed-by: erikj, serb ! make/modules/java.desktop/Lib.gmk ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/GeomUtilities.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaTextAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m ! src/java.desktop/macosx/native/libosxapp/JNIUtilities.h Changeset: 5f7ccce0 Author: Evan Whelan Committer: Alan Bateman Date: 2021-01-12 20:41:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5f7ccce0 8226810: Failed to launch JVM because of NullPointerException occured on System.props Reviewed-by: alanb, naoto ! make/data/charsetmapping/stdcs-windows Changeset: e4df2098 Author: Laurent Bourg?s Date: 2021-01-12 20:51:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e4df2098 7018932: Drawing very large coordinates with a dashed Stroke can cause Java to hang Reviewed-by: serb, prr ! src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinRenderingEngine.java ! src/java.desktop/share/classes/sun/java2d/marlin/TransformingPathConsumer2D.java ! src/java.desktop/share/classes/sun/java2d/pipe/LoopPipe.java ! src/java.desktop/share/classes/sun/java2d/pipe/RenderingEngine.java ! src/java.desktop/share/classes/sun/java2d/pipe/SpanShapeRenderer.java + test/jdk/sun/java2d/marlin/StrokedLinePerf.java Changeset: 4be21734 Author: Martin Balao Date: 2021-01-12 23:44:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4be21734 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes Reviewed-by: valeriep, mullan ! src/java.base/share/classes/module-info.java ! src/java.base/share/lib/security/default.policy ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java + test/jdk/sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java Changeset: c6d798c2 Author: Dong Bo Committer: Vladimir Kozlov Date: 2021-01-13 00:30:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c6d798c2 8259629: aarch64 builds fail after JDK-8258932 Reviewed-by: kvn ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h Changeset: 65bed647 Author: Xue-Lei Andrew Fan Date: 2021-01-13 01:10:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/65bed647 8253635: Implement toString() for SSLEngineImpl Reviewed-by: coffeys, wetmore ! src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 0957d9eb Author: Sergey Bylokhov Date: 2021-01-13 02:30:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0957d9eb 8259519: The java.awt.datatransfer.DataFlavor#ioInputStreamClass field is redundant Reviewed-by: aivanov ! src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java + test/jdk/java/awt/datatransfer/DataFlavor/DefaultRepresentation.java Changeset: 44c83794 Author: Prasanta Sadhukhan Date: 2021-01-13 06:57:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/44c83794 8256019: JLabel HTML text does not support translucent text colors Reviewed-by: serb ! src/java.desktop/share/classes/javax/swing/text/html/CSS.java + test/jdk/javax/swing/JLabel/TestTranslucentLabelText.java Changeset: a483869a Author: Prasanta Sadhukhan Date: 2021-01-13 07:00:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a483869a 8225045: javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails on linux-x64 Reviewed-by: serb, pbansal, trebari ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java Changeset: 139b6dae Author: Matthias Baesken Date: 2021-01-13 07:53:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/139b6dae 8259372: remove AIX related USE_LIBRARY_BASED_TLS_ONLY and THREAD_LOCAL special handling Reviewed-by: dholmes, stuefe ! src/hotspot/share/utilities/globalDefinitions_xlc.hpp Changeset: 2243a170 Author: liach Committer: Aleksey Shipilev Date: 2021-01-13 08:02:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2243a170 8259485: Document need for short paths when building on Windows Reviewed-by: erikj, shade ! doc/building.html ! doc/building.md Changeset: 77ca1031 Author: Jan Lahoda Date: 2021-01-13 11:27:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/77ca1031 8257236: can't use var with a class named Z Reviewed-by: sundar ! src/jdk.jshell/share/classes/jdk/jshell/Wrap.java ! test/langtools/jdk/jshell/VariablesTest.java Changeset: 2e124544 Author: Aleksey Shipilev Date: 2021-01-13 11:55:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2e124544 8259580: Shenandoah: uninitialized label in VerifyThreadGCState Reviewed-by: zgu, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp Changeset: ce945120 Author: Aleksey Shipilev Date: 2021-01-13 12:30:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ce945120 8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect Reviewed-by: chagedorn, kvn ! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp Changeset: 535f2da5 Author: Coleen Phillimore Date: 2021-01-13 14:32:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/535f2da5 8259486: Replace PreserveExceptionMark with implementation for CautiouslyPreserveExceptionMark Reviewed-by: dholmes, sspitsyn ! src/hotspot/cpu/arm/methodHandles_arm.cpp ! src/hotspot/cpu/ppc/methodHandles_ppc.cpp ! src/hotspot/cpu/s390/methodHandles_s390.cpp ! src/hotspot/cpu/x86/methodHandles_x86.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/jfr/recorder/service/jfrRecorderThread.cpp ! src/hotspot/share/prims/jvmtiEnter.xsl ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/utilities/exceptions.cpp ! src/hotspot/share/utilities/exceptions.hpp ! src/hotspot/share/utilities/preserveException.cpp ! src/hotspot/share/utilities/preserveException.hpp Changeset: 5df2a949 Author: Mahendra Chhipa Committer: Daniel Fuchs Date: 2021-01-13 15:53:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5df2a949 8212035: merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer Reviewed-by: dfuchs - test/jaxp/javax/xml/jaxp/libs/jaxp/library/SimpleHttpServer.java ! test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java ! test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java ! test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarHttpProperties.java ! test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarProperties.java ! test/jdk/java/util/jar/JarFile/mrjar/TestVersionedStream.java ! test/jdk/lib/testlibrary/java/util/jar/CreateMultiReleaseTestJars.java - test/jdk/lib/testlibrary/java/util/jar/SimpleHttpServer.java ! test/jdk/sun/net/www/protocol/jar/B4756443.java ! test/jdk/sun/net/www/protocol/jar/B5105410.java ! test/jdk/sun/net/www/protocol/jar/JarURLConnectionUseCaches.java ! test/jdk/sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java ! test/jdk/sun/net/www/protocol/jar/jarbug/TestDriver.java ! test/jdk/sun/net/www/protocol/jar/jarbug/src/jar1/GetResource.java ! test/jdk/sun/net/www/protocol/jar/jarbug/src/jar1/LoadResourceBundle.java ! test/jdk/sun/net/www/protocol/jar/jarbug/src/test/JarTest.java + test/lib/jdk/test/lib/net/SimpleHttpServer.java Changeset: 916ab4e7 Author: Jonathan Gibbons Date: 2021-01-13 17:01:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/916ab4e7 8259283: use new HtmlId and HtmlIds classes Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIndexBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkFactoryImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SectionName.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SubWriterHolderWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlId.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Links.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Table.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/SummaryAPIListBuilder.java Changeset: ccdf171d Author: Zhengyu Gu Date: 2021-01-13 19:01:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ccdf171d 8259377: Shenandoah: Enhance weak reference processing time tracking Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp Changeset: c7e2174b Author: Hai-May Chao Committer: Weijun Wang Date: 2021-01-13 22:32:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c7e2174b 8259401: Add checking to jarsigner to warn weak algorithms used in signer?s cert chain Reviewed-by: mullan, weijun, rhalade ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java + test/jdk/sun/security/tools/jarsigner/CheckSignerCertChain.java Changeset: a7e5da22 Author: Ningsheng Jian Date: 2021-01-12 01:31:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a7e5da22 8258384: AArch64: SVE verify_ptrue fails on some tests Reviewed-by: adinn, ngasson ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Changeset: 28ff2de1 Author: Pankaj Bansal Date: 2021-01-12 09:46:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/28ff2de1 8259237: Demo selection changes with left/right arrow key. No need to press space for selection. Reviewed-by: psadhukhan, kizune, serb ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicButtonUI.java ! test/jdk/javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java Changeset: 67e1b639 Author: Patrick Zhang Committer: Thomas Schatzl Date: 2021-01-12 10:10:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/67e1b639 8259380: Correct pretouch chunk size to cap with actual page size Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/shared/pretouchTask.cpp Changeset: 8a81cf15 Author: Stuart Marks Date: 2021-01-12 17:04:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8a81cf15 8259298: broken link in Stream::toList spec Reviewed-by: bchristi, iris, lancea, naoto ! src/java.base/share/classes/java/util/stream/Stream.java Changeset: b03880e3 Author: Maurizio Cimadamore Date: 2021-01-12 17:09:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b03880e3 8259634: MemorySegment::asByteBuffer does not respect spatial bounds Reviewed-by: alanb, chegar ! src/java.base/share/classes/java/nio/Buffer.java ! test/jdk/java/foreign/TestByteBuffer.java Changeset: 5f9cd72c Author: Jonathan Gibbons Date: 2021-01-12 19:57:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5f9cd72c 8259645: Revert JDK-8245956 JavaCompiler still uses File API instead of Path API in a specific case Reviewed-by: chegar ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java - test/langtools/tools/javac/T8245956/T8245956.java Changeset: 17b4db31 Author: Maurizio Cimadamore Date: 2021-01-12 21:06:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/17b4db31 8259636: Check for buffer backed by shared segment kicks in in unexpected places Reviewed-by: sundar, alanb, chegar ! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template ! test/jdk/java/foreign/TestByteBuffer.java Changeset: 1cf2378b Author: Xiaohong Gong Committer: Ningsheng Jian Date: 2021-01-13 05:48:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1cf2378b 8259353: VectorReinterpretNode is incorrectly optimized out Reviewed-by: vlivanov, njian ! src/hotspot/share/opto/vectornode.cpp Changeset: 15dd8f3a Author: Calvin Cheung Date: 2021-01-13 05:51:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/15dd8f3a 8259275: JRuby crashes while resolving invokedynamic instruction Reviewed-by: iklam, minqi, lfoltan ! src/hotspot/share/classfile/classListParser.cpp ! src/hotspot/share/classfile/classListParser.hpp ! src/hotspot/share/oops/constantPool.cpp ! test/hotspot/jtreg/TEST.groups ! test/hotspot/jtreg/runtime/cds/appcds/BadBSM.java + test/hotspot/jtreg/runtime/cds/appcds/LambdaWithOldClass.java + test/hotspot/jtreg/runtime/cds/appcds/test-classes/LambdaWithOldClassApp.java + test/hotspot/jtreg/runtime/cds/appcds/test-classes/OldClass.jasm Changeset: 793017d2 Author: Xiaohong Gong Committer: Ningsheng Jian Date: 2021-01-13 05:52:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/793017d2 8259601: AArch64: Fix reinterpretX2D match rule issue Reviewed-by: adinn, njian ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 Changeset: 417e1d1a Author: Roberto Casta?eda Lozano Committer: Tobias Hartmann Date: 2021-01-13 07:22:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/417e1d1a 8259061: C2: assert(found) failed: memory-writing node is not placed in its original loop or an ancestor of it Remove assertion that is too general, that is, it can fail on compilations where C2 generates correct code otherwise. Reviewed-by: chagedorn, thartmann, kvn ! src/hotspot/share/opto/block.cpp Changeset: efc36be5 Author: Kim Barrett Date: 2021-01-13 08:22:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/efc36be5 8258985: Parallel WeakProcessor may use too few threads Use total workers rather than active. Reviewed-by: tschatzl, ayang, sjohanss ! src/hotspot/share/gc/shared/weakProcessor.hpp ! src/hotspot/share/gc/shared/weakProcessor.inline.hpp Changeset: a99df45b Author: Aleksey Shipilev Date: 2021-01-13 08:49:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a99df45b 8259560: Zero m68k: "static assertion failed: align" after JDK-8252049 Reviewed-by: dholmes ! src/hotspot/share/ci/ciMethodData.cpp ! src/hotspot/share/oops/methodData.hpp Changeset: 55675309 Author: Nils Eliasson Date: 2021-01-13 09:16:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/55675309 8258272: LoadVectorMaskedNode can't be replaced by zero con Reviewed-by: chagedorn, vlivanov ! src/hotspot/share/opto/memnode.cpp + test/hotspot/jtreg/compiler/arraycopy/TestArrayCopyMaskedWithZeroSrc.java Changeset: 6bb6093f Author: Jonathan Gibbons Date: 2021-01-13 12:40:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6bb6093f 8259657: typo in generated HELP page prevents localization Reviewed-by: vromero ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties Changeset: 42d2d6dc Author: Erik ?sterlund Date: 2021-01-13 16:48:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/42d2d6dc 8259063: Possible deadlock with vtable/itable creation vs concurrent class unloading Reviewed-by: pliden, neliasso ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp Changeset: ac4cd2e3 Author: Vicente Romero Date: 2021-01-13 17:27:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ac4cd2e3 8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/lib/combo/tools/javac/combo/CompilationTestCase.java ! test/langtools/lib/combo/tools/javac/combo/Diagnostics.java ! test/langtools/lib/combo/tools/javac/combo/JavacTemplateTestBase.java + test/langtools/tools/javac/diags/examples/BoundUnboundMethRefSearch.java + test/langtools/tools/javac/diags/examples/BoundUnboundMethRefSearch2.java + test/langtools/tools/javac/lambda/methodReference/BoundUnboundSearchTest.java Changeset: fb8ac247 Author: Daniel D. Daugherty Date: 2021-01-13 18:23:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fb8ac247 8259722: ProblemList two jdk/jfr/startupargs tests on Windows Reviewed-by: mgronlun ! test/jdk/ProblemList.txt Changeset: 8abefdec Author: Daniel D. Daugherty Date: 2021-01-13 18:23:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8abefdec 8259720: ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java on Windows Reviewed-by: kizune, pbansal ! test/jdk/ProblemList.txt Changeset: 5926d75f Author: Daniel D. Daugherty Date: 2021-01-13 19:52:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5926d75f 8259719: ProblemList runtime/cds/appcds/jigsaw/modulepath/ModulePathAndCP_JFR.java on Windows Reviewed-by: pliden ! test/hotspot/jtreg/ProblemList.txt Changeset: 51e14f2e Author: Jesper Wilhelmsson Date: 2021-01-14 01:29:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/51e14f2e Merge ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/share/ci/ciMethodData.cpp ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/gc/shared/pretouchTask.cpp ! src/hotspot/share/gc/shared/weakProcessor.inline.hpp ! src/hotspot/share/opto/memnode.cpp ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.groups ! test/jdk/ProblemList.txt ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/share/ci/ciMethodData.cpp ! src/hotspot/share/code/codeBlob.cpp ! src/hotspot/share/gc/shared/pretouchTask.cpp ! src/hotspot/share/gc/shared/weakProcessor.inline.hpp ! src/hotspot/share/opto/memnode.cpp ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.groups ! test/jdk/ProblemList.txt Changeset: 5513f989 Author: Hao Sun Committer: Ningsheng Jian Date: 2021-01-14 04:11:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5513f989 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy Reviewed-by: xliu, kvn, kbarrett ! src/hotspot/share/opto/node.hpp Changeset: ae9187d7 Author: Alexander Zuev Date: 2021-01-14 05:07:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ae9187d7 8256109: Create implementation for NSAccessibilityButton protocol Reviewed-by: prr, serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ButtonAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ButtonAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m Changeset: 8b8b1f9a Author: Tobias Hartmann Date: 2021-01-14 07:23:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8b8b1f9a 8259706: C2 compilation fails with assert(vtable_index == Method::invalid_vtable_index) failed: correct sentinel value Reviewed-by: lucy, chagedorn ! src/hotspot/share/opto/library_call.cpp Changeset: 3462f7a9 Author: Stefan Karlsson Date: 2021-01-14 11:34:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3462f7a9 8256955: Move includes of events.hpp out of header files Reviewed-by: kbarrett, coleenp ! src/hotspot/share/classfile/classLoaderDataGraph.cpp ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/jvmci/jvmci.cpp ! src/hotspot/share/jvmci/jvmci.hpp ! src/hotspot/share/runtime/vmStructs.cpp Changeset: b040a3d7 Author: Aleksei Efimov Date: 2021-01-14 11:57:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b040a3d7 8259631: Reapply pattern match instanceof use in HttpClientImpl Reviewed-by: dfuchs, chegar ! src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java Changeset: b8ef2bad Author: Wang Xue Committer: David Holmes Date: 2021-01-14 12:56:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b8ef2bad 8259563: The CPU model name is printed multiple times when using -Xlog:os+cpu Reviewed-by: dholmes ! src/hotspot/os/linux/os_linux.cpp Changeset: ff3e6e46 Author: Jatin Bhateja Date: 2021-01-14 13:20:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ff3e6e46 8259773: Incorrect encoding of AVX-512 kmovq instruction Reviewed-by: vlivanov ! src/hotspot/cpu/x86/assembler_x86.cpp Changeset: c822eda1 Author: Sergey Tsypanov Committer: Claes Redestad Date: 2021-01-14 14:18:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c822eda1 8259699: Reduce char[] copying in URLEncoder.encode(String, Charset) Reviewed-by: attila, redestad, chegar ! src/java.base/share/classes/java/net/URLEncoder.java Changeset: be57cf14 Author: Daniel D. Daugherty Date: 2021-01-14 14:23:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/be57cf14 8226416: MonitorUsedDeflationThreshold can cause repeated async deflation requests Reviewed-by: dholmes, coleenp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/synchronizer.cpp + test/hotspot/jtreg/runtime/Monitor/MonitorUsedDeflationThresholdTest.java Changeset: 38a12017 Author: Harold Seigel Date: 2021-01-14 15:04:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/38a12017 8258912: Remove JVM options CountJNICalls and CountJVMCalls Reviewed-by: coleenp, lfoltan, shade ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/interfaceSupport.cpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp - src/hotspot/share/utilities/histogram.cpp - src/hotspot/share/utilities/histogram.hpp Changeset: 1620664e Author: Jonathan Gibbons Date: 2021-01-14 16:18:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1620664e 8259723: Move Table class to formats.html package Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllPackagesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SystemPropertiesWriter.java = src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Table.java = src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TableHeader.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/package-info.java Changeset: c2a3c7ef Author: Jonathan Gibbons Date: 2021-01-14 16:20:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c2a3c7ef 8259727: Remove redundant "target" arguments to methods in Links Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkFactoryImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkInfoImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Links.java Changeset: 8554fe6e Author: Jamil Nimeh Date: 2021-01-14 16:36:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8554fe6e 8253866: Security Libs Terminology Refresh Reviewed-by: erikj, weijun, mullan ! make/ToolsJdk.gmk = make/data/blockedcertsconverter/blocked.certs.pem = make/jdk/src/classes/build/tools/blockedcertsconverter/BlockedCertsConverter.java ! make/modules/java.base/Gendata.gmk - make/modules/java.base/gendata/GendataBlacklistedCerts.gmk + make/modules/java.base/gendata/GendataBlockedCerts.gmk ! make/scripts/compare.sh ! src/java.base/share/classes/com/sun/crypto/provider/JceKeyStore.java ! src/java.base/share/classes/java/util/jar/JarVerifier.java ! src/java.base/share/classes/sun/security/provider/JavaKeyStore.java ! src/java.base/share/classes/sun/security/util/UntrustedCertificates.java ! src/java.base/share/conf/security/java.security ! src/java.security.jgss/share/classes/sun/security/krb5/Config.java ! src/java.security.jgss/share/classes/sun/security/krb5/KdcComm.java ! test/jdk/sun/security/krb5/auto/BogusKDC.java - test/jdk/sun/security/lib/CheckBlacklistedCerts.java + test/jdk/sun/security/lib/CheckBlockedCerts.java Changeset: aba3431c Author: Naoto Sato Date: 2021-01-14 16:58:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aba3431c 8258956: Memory Leak in StringCoding on ThreadLocal resultCached StringCoding.Result Reviewed-by: rriggs, alanb ! src/java.base/share/classes/java/lang/StringCoding.java Changeset: da6bcf96 Author: Zhengyu Gu Date: 2021-01-14 17:42:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/da6bcf96 8255019: Shenandoah: Split STW and concurrent mark into separate classes Reviewed-by: rkennke, shade ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp - src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp + src/hotspot/share/gc/shenandoah/shenandoahMark.cpp + src/hotspot/share/gc/shenandoah/shenandoahMark.hpp + src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.hpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp + src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp + src/hotspot/share/gc/shenandoah/shenandoahSTWMark.hpp Changeset: a6b2162f Author: Sandhya Viswanathan Date: 2021-01-14 17:48:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a6b2162f 8259278: Optimize Vector API slice and unslice operations Reviewed-by: psandoz, vlivanov ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template Changeset: d18d26e8 Author: Chris Plummer Date: 2021-01-14 21:01:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d18d26e8 8259350: Add some internal debugging APIs to the debug agent Reviewed-by: sspitsyn, amenkov ! src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c ! src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.h ! src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c ! src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.h ! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c ! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.h ! src/jdk.jdwp.agent/share/native/libjdwp/util.c ! src/jdk.jdwp.agent/share/native/libjdwp/util.h Changeset: 4f881ba5 Author: Chris Plummer Date: 2021-01-14 23:04:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4f881ba5 8258652: Assert in JvmtiThreadState::cur_stack_depth() can noticeably slow down debugging single stepping Reviewed-by: sspitsyn, dholmes, amenkov ! src/hotspot/share/prims/jvmtiThreadState.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: bf28f925 Author: Coleen Phillimore Date: 2021-01-14 23:25:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bf28f925 8259713: Fix comments about ResetNoHandleMark in deoptimization Reviewed-by: lfoltan, dcubed, dholmes ! src/hotspot/share/runtime/deoptimization.cpp Changeset: 978bed6c Author: Sergey Bylokhov Date: 2021-01-15 00:28:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/978bed6c 8259522: Apply java.io.Serial annotations in java.desktop Reviewed-by: aivanov, psadhukhan ! src/java.desktop/share/classes/com/sun/beans/editors/ColorEditor.java ! src/java.desktop/share/classes/com/sun/beans/editors/FontEditor.java ! src/java.desktop/share/classes/com/sun/beans/finder/SignatureException.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleCMYKColorSpace.java ! src/java.desktop/share/classes/com/sun/media/sound/InvalidDataException.java ! src/java.desktop/share/classes/com/sun/media/sound/InvalidFormatException.java ! src/java.desktop/share/classes/com/sun/media/sound/RIFFInvalidDataException.java ! src/java.desktop/share/classes/com/sun/media/sound/RIFFInvalidFormatException.java ! src/java.desktop/share/classes/java/applet/Applet.java ! src/java.desktop/share/classes/java/awt/AWTError.java ! src/java.desktop/share/classes/java/awt/AWTEvent.java ! src/java.desktop/share/classes/java/awt/AWTException.java ! src/java.desktop/share/classes/java/awt/AWTKeyStroke.java ! src/java.desktop/share/classes/java/awt/AWTPermission.java ! src/java.desktop/share/classes/java/awt/BorderLayout.java ! src/java.desktop/share/classes/java/awt/Button.java ! src/java.desktop/share/classes/java/awt/Canvas.java ! src/java.desktop/share/classes/java/awt/CardLayout.java ! src/java.desktop/share/classes/java/awt/Checkbox.java ! src/java.desktop/share/classes/java/awt/CheckboxGroup.java ! src/java.desktop/share/classes/java/awt/CheckboxMenuItem.java ! src/java.desktop/share/classes/java/awt/Choice.java ! src/java.desktop/share/classes/java/awt/Color.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/ComponentOrientation.java ! src/java.desktop/share/classes/java/awt/Container.java ! src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java ! src/java.desktop/share/classes/java/awt/Cursor.java ! src/java.desktop/share/classes/java/awt/DefaultFocusTraversalPolicy.java ! src/java.desktop/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/java.desktop/share/classes/java/awt/Dialog.java ! src/java.desktop/share/classes/java/awt/Dimension.java ! src/java.desktop/share/classes/java/awt/Event.java ! src/java.desktop/share/classes/java/awt/FileDialog.java ! src/java.desktop/share/classes/java/awt/FlowLayout.java ! src/java.desktop/share/classes/java/awt/Font.java ! src/java.desktop/share/classes/java/awt/FontFormatException.java ! src/java.desktop/share/classes/java/awt/FontMetrics.java ! src/java.desktop/share/classes/java/awt/Frame.java ! src/java.desktop/share/classes/java/awt/GraphicsConfigTemplate.java ! src/java.desktop/share/classes/java/awt/GridBagConstraints.java ! src/java.desktop/share/classes/java/awt/GridBagLayout.java ! src/java.desktop/share/classes/java/awt/GridBagLayoutInfo.java ! src/java.desktop/share/classes/java/awt/GridLayout.java ! src/java.desktop/share/classes/java/awt/HeadlessException.java ! src/java.desktop/share/classes/java/awt/IllegalComponentStateException.java ! src/java.desktop/share/classes/java/awt/Insets.java ! src/java.desktop/share/classes/java/awt/Label.java ! src/java.desktop/share/classes/java/awt/List.java ! src/java.desktop/share/classes/java/awt/MediaTracker.java ! src/java.desktop/share/classes/java/awt/Menu.java ! src/java.desktop/share/classes/java/awt/MenuBar.java ! src/java.desktop/share/classes/java/awt/MenuComponent.java ! src/java.desktop/share/classes/java/awt/MenuItem.java ! src/java.desktop/share/classes/java/awt/MenuShortcut.java ! src/java.desktop/share/classes/java/awt/Panel.java ! src/java.desktop/share/classes/java/awt/Point.java ! src/java.desktop/share/classes/java/awt/Polygon.java ! src/java.desktop/share/classes/java/awt/PopupMenu.java ! src/java.desktop/share/classes/java/awt/Rectangle.java ! src/java.desktop/share/classes/java/awt/ScrollPane.java ! src/java.desktop/share/classes/java/awt/ScrollPaneAdjustable.java ! src/java.desktop/share/classes/java/awt/Scrollbar.java ! src/java.desktop/share/classes/java/awt/SentEvent.java ! src/java.desktop/share/classes/java/awt/SequencedEvent.java ! src/java.desktop/share/classes/java/awt/SystemColor.java ! src/java.desktop/share/classes/java/awt/TextArea.java ! src/java.desktop/share/classes/java/awt/TextComponent.java ! src/java.desktop/share/classes/java/awt/TextField.java ! src/java.desktop/share/classes/java/awt/Window.java ! src/java.desktop/share/classes/java/awt/color/CMMException.java ! src/java.desktop/share/classes/java/awt/color/ColorSpace.java ! src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java ! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java ! src/java.desktop/share/classes/java/awt/color/ICC_ProfileGray.java ! src/java.desktop/share/classes/java/awt/color/ICC_ProfileRGB.java ! src/java.desktop/share/classes/java/awt/color/ProfileDataException.java ! src/java.desktop/share/classes/java/awt/desktop/AboutEvent.java ! src/java.desktop/share/classes/java/awt/desktop/AppEvent.java ! src/java.desktop/share/classes/java/awt/desktop/AppForegroundEvent.java ! src/java.desktop/share/classes/java/awt/desktop/AppHiddenEvent.java ! src/java.desktop/share/classes/java/awt/desktop/AppReopenedEvent.java ! src/java.desktop/share/classes/java/awt/desktop/FilesEvent.java ! src/java.desktop/share/classes/java/awt/desktop/OpenFilesEvent.java ! src/java.desktop/share/classes/java/awt/desktop/OpenURIEvent.java ! src/java.desktop/share/classes/java/awt/desktop/PreferencesEvent.java ! src/java.desktop/share/classes/java/awt/desktop/PrintFilesEvent.java ! src/java.desktop/share/classes/java/awt/desktop/QuitEvent.java ! src/java.desktop/share/classes/java/awt/desktop/ScreenSleepEvent.java ! src/java.desktop/share/classes/java/awt/desktop/SystemSleepEvent.java ! src/java.desktop/share/classes/java/awt/desktop/UserSessionEvent.java ! src/java.desktop/share/classes/java/awt/dnd/DragGestureEvent.java ! src/java.desktop/share/classes/java/awt/dnd/DragGestureRecognizer.java ! src/java.desktop/share/classes/java/awt/dnd/DragSource.java ! src/java.desktop/share/classes/java/awt/dnd/DragSourceContext.java ! src/java.desktop/share/classes/java/awt/dnd/DragSourceDragEvent.java ! src/java.desktop/share/classes/java/awt/dnd/DragSourceDropEvent.java ! src/java.desktop/share/classes/java/awt/dnd/DragSourceEvent.java ! src/java.desktop/share/classes/java/awt/dnd/DropTarget.java ! src/java.desktop/share/classes/java/awt/dnd/DropTargetContext.java ! src/java.desktop/share/classes/java/awt/dnd/DropTargetDragEvent.java ! src/java.desktop/share/classes/java/awt/dnd/DropTargetDropEvent.java ! src/java.desktop/share/classes/java/awt/dnd/DropTargetEvent.java ! src/java.desktop/share/classes/java/awt/dnd/InvalidDnDOperationException.java ! src/java.desktop/share/classes/java/awt/dnd/MouseDragGestureRecognizer.java ! src/java.desktop/share/classes/java/awt/event/ActionEvent.java ! src/java.desktop/share/classes/java/awt/event/AdjustmentEvent.java ! src/java.desktop/share/classes/java/awt/event/ComponentEvent.java ! src/java.desktop/share/classes/java/awt/event/ContainerEvent.java ! src/java.desktop/share/classes/java/awt/event/FocusEvent.java ! src/java.desktop/share/classes/java/awt/event/HierarchyEvent.java ! src/java.desktop/share/classes/java/awt/event/InputEvent.java ! src/java.desktop/share/classes/java/awt/event/InputMethodEvent.java ! src/java.desktop/share/classes/java/awt/event/InvocationEvent.java ! src/java.desktop/share/classes/java/awt/event/ItemEvent.java ! src/java.desktop/share/classes/java/awt/event/KeyEvent.java ! src/java.desktop/share/classes/java/awt/event/MouseEvent.java ! src/java.desktop/share/classes/java/awt/event/MouseWheelEvent.java ! src/java.desktop/share/classes/java/awt/event/PaintEvent.java ! src/java.desktop/share/classes/java/awt/event/TextEvent.java ! src/java.desktop/share/classes/java/awt/event/WindowEvent.java ! src/java.desktop/share/classes/java/awt/font/NumericShaper.java ! src/java.desktop/share/classes/java/awt/font/TextAttribute.java ! src/java.desktop/share/classes/java/awt/font/TransformAttribute.java ! src/java.desktop/share/classes/java/awt/geom/AffineTransform.java ! src/java.desktop/share/classes/java/awt/geom/Arc2D.java ! src/java.desktop/share/classes/java/awt/geom/CubicCurve2D.java ! src/java.desktop/share/classes/java/awt/geom/Ellipse2D.java ! src/java.desktop/share/classes/java/awt/geom/GeneralPath.java ! src/java.desktop/share/classes/java/awt/geom/IllegalPathStateException.java ! src/java.desktop/share/classes/java/awt/geom/Line2D.java ! src/java.desktop/share/classes/java/awt/geom/NoninvertibleTransformException.java ! src/java.desktop/share/classes/java/awt/geom/Path2D.java ! src/java.desktop/share/classes/java/awt/geom/Point2D.java ! src/java.desktop/share/classes/java/awt/geom/QuadCurve2D.java ! src/java.desktop/share/classes/java/awt/geom/Rectangle2D.java ! src/java.desktop/share/classes/java/awt/geom/RoundRectangle2D.java ! src/java.desktop/share/classes/java/awt/image/ImagingOpException.java ! src/java.desktop/share/classes/java/awt/image/RasterFormatException.java ! src/java.desktop/share/classes/java/awt/image/renderable/ParameterBlock.java ! src/java.desktop/share/classes/java/awt/print/PrinterAbortException.java ! src/java.desktop/share/classes/java/awt/print/PrinterException.java ! src/java.desktop/share/classes/java/awt/print/PrinterIOException.java ! src/java.desktop/share/classes/java/beans/IndexedPropertyChangeEvent.java ! src/java.desktop/share/classes/java/beans/IntrospectionException.java ! src/java.desktop/share/classes/java/beans/PropertyChangeEvent.java ! src/java.desktop/share/classes/java/beans/PropertyChangeSupport.java ! src/java.desktop/share/classes/java/beans/PropertyVetoException.java ! src/java.desktop/share/classes/java/beans/VetoableChangeSupport.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextChildSupport.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextEvent.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextMembershipEvent.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextServiceAvailableEvent.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextServiceRevokedEvent.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextServicesSupport.java ! src/java.desktop/share/classes/java/beans/beancontext/BeanContextSupport.java ! src/java.desktop/share/classes/javax/imageio/IIOException.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOInvalidTreeException.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataNode.java ! src/java.desktop/share/classes/javax/imageio/spi/DigraphNode.java ! src/java.desktop/share/classes/javax/print/DocFlavor.java ! src/java.desktop/share/classes/javax/print/MimeType.java ! src/java.desktop/share/classes/javax/print/PrintException.java ! src/java.desktop/share/classes/javax/print/attribute/AttributeSetUtilities.java ! src/java.desktop/share/classes/javax/print/attribute/DateTimeSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/EnumSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/HashAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/HashDocAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/HashPrintJobAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/HashPrintRequestAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/HashPrintServiceAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/IntegerSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/ResolutionSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/SetOfIntegerSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/Size2DSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/TextSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/URISyntax.java ! src/java.desktop/share/classes/javax/print/attribute/UnmodifiableSetException.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Chromaticity.java ! src/java.desktop/share/classes/javax/print/attribute/standard/ColorSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Compression.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Copies.java ! src/java.desktop/share/classes/javax/print/attribute/standard/CopiesSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DateTimeAtCompleted.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DateTimeAtCreation.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DateTimeAtProcessing.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Destination.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DialogOwner.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DialogTypeSelection.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DocumentName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Fidelity.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Finishings.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobHoldUntil.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobImpressions.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobImpressionsCompleted.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobImpressionsSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobKOctets.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobKOctetsProcessed.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobKOctetsSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobMediaSheets.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobMediaSheetsCompleted.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobMediaSheetsSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobMessageFromOperator.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobOriginatingUserName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobPriority.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobPrioritySupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobSheets.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobState.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobStateReason.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobStateReasons.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Media.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MediaName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MediaPrintableArea.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MediaSize.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MediaSizeName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MediaTray.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MultipleDocumentHandling.java ! src/java.desktop/share/classes/javax/print/attribute/standard/NumberOfDocuments.java ! src/java.desktop/share/classes/javax/print/attribute/standard/NumberOfInterveningJobs.java ! src/java.desktop/share/classes/javax/print/attribute/standard/NumberUp.java ! src/java.desktop/share/classes/javax/print/attribute/standard/NumberUpSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/OrientationRequested.java ! src/java.desktop/share/classes/javax/print/attribute/standard/OutputDeviceAssigned.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PDLOverrideSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PageRanges.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PagesPerMinute.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PagesPerMinuteColor.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PresentationDirection.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrintQuality.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterInfo.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterIsAcceptingJobs.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterLocation.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMakeAndModel.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMessageFromOperator.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMoreInfo.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMoreInfoManufacturer.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterResolution.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterState.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterStateReason.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterURI.java ! src/java.desktop/share/classes/javax/print/attribute/standard/QueuedJobCount.java ! src/java.desktop/share/classes/javax/print/attribute/standard/ReferenceUriSchemesSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/RequestingUserName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Severity.java ! src/java.desktop/share/classes/javax/print/attribute/standard/SheetCollate.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Sides.java ! src/java.desktop/share/classes/javax/print/event/PrintEvent.java ! src/java.desktop/share/classes/javax/print/event/PrintJobAttributeEvent.java ! src/java.desktop/share/classes/javax/print/event/PrintJobEvent.java ! src/java.desktop/share/classes/javax/print/event/PrintServiceAttributeEvent.java ! src/java.desktop/share/classes/javax/sound/midi/InvalidMidiDataException.java ! src/java.desktop/share/classes/javax/sound/midi/MidiUnavailableException.java ! src/java.desktop/share/classes/javax/sound/sampled/AudioPermission.java ! src/java.desktop/share/classes/javax/sound/sampled/LineEvent.java ! src/java.desktop/share/classes/javax/sound/sampled/LineUnavailableException.java ! src/java.desktop/share/classes/javax/sound/sampled/UnsupportedAudioFileException.java ! src/java.desktop/share/classes/javax/swing/AbstractAction.java ! src/java.desktop/share/classes/javax/swing/ActionMap.java ! src/java.desktop/share/classes/javax/swing/ActionPropertyChangeListener.java ! src/java.desktop/share/classes/javax/swing/CellRendererPane.java ! src/java.desktop/share/classes/javax/swing/ImageIcon.java ! src/java.desktop/share/classes/javax/swing/InputMap.java ! src/java.desktop/share/classes/javax/swing/JButton.java ! src/java.desktop/share/classes/javax/swing/JCheckBox.java ! src/java.desktop/share/classes/javax/swing/JCheckBoxMenuItem.java ! src/java.desktop/share/classes/javax/swing/JColorChooser.java ! src/java.desktop/share/classes/javax/swing/JComboBox.java ! src/java.desktop/share/classes/javax/swing/JComponent.java ! src/java.desktop/share/classes/javax/swing/JDesktopPane.java ! src/java.desktop/share/classes/javax/swing/JEditorPane.java ! src/java.desktop/share/classes/javax/swing/JFileChooser.java ! src/java.desktop/share/classes/javax/swing/JFormattedTextField.java ! src/java.desktop/share/classes/javax/swing/JInternalFrame.java ! src/java.desktop/share/classes/javax/swing/JLabel.java ! src/java.desktop/share/classes/javax/swing/JLayer.java ! src/java.desktop/share/classes/javax/swing/JList.java ! src/java.desktop/share/classes/javax/swing/JMenu.java ! src/java.desktop/share/classes/javax/swing/JMenuBar.java ! src/java.desktop/share/classes/javax/swing/JMenuItem.java ! src/java.desktop/share/classes/javax/swing/JOptionPane.java ! src/java.desktop/share/classes/javax/swing/JPanel.java ! src/java.desktop/share/classes/javax/swing/JPasswordField.java ! src/java.desktop/share/classes/javax/swing/JPopupMenu.java ! src/java.desktop/share/classes/javax/swing/JProgressBar.java ! src/java.desktop/share/classes/javax/swing/JRadioButton.java ! src/java.desktop/share/classes/javax/swing/JRadioButtonMenuItem.java ! src/java.desktop/share/classes/javax/swing/JScrollBar.java ! src/java.desktop/share/classes/javax/swing/JScrollPane.java ! src/java.desktop/share/classes/javax/swing/JSeparator.java ! src/java.desktop/share/classes/javax/swing/JSlider.java ! src/java.desktop/share/classes/javax/swing/JSpinner.java ! src/java.desktop/share/classes/javax/swing/JSplitPane.java ! src/java.desktop/share/classes/javax/swing/JTabbedPane.java ! src/java.desktop/share/classes/javax/swing/JTable.java ! src/java.desktop/share/classes/javax/swing/JTextArea.java ! src/java.desktop/share/classes/javax/swing/JTextField.java ! src/java.desktop/share/classes/javax/swing/JTextPane.java ! src/java.desktop/share/classes/javax/swing/JToggleButton.java ! src/java.desktop/share/classes/javax/swing/JToolBar.java ! src/java.desktop/share/classes/javax/swing/JToolTip.java ! src/java.desktop/share/classes/javax/swing/JTree.java ! src/java.desktop/share/classes/javax/swing/KeyStroke.java ! src/java.desktop/share/classes/javax/swing/LayoutFocusTraversalPolicy.java ! src/java.desktop/share/classes/javax/swing/LegacyGlueFocusTraversalPolicy.java ! src/java.desktop/share/classes/javax/swing/Timer.java ! src/java.desktop/share/classes/javax/swing/event/EventListenerList.java ! src/java.desktop/share/classes/javax/swing/event/SwingPropertyChangeSupport.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/table/JTableHeader.java ! src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java ! src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java ! src/java.desktop/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/java.desktop/share/classes/javax/swing/text/GapContent.java ! src/java.desktop/share/classes/javax/swing/text/InternationalFormatter.java ! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java ! src/java.desktop/share/classes/javax/swing/text/MaskFormatter.java ! src/java.desktop/share/classes/javax/swing/text/SimpleAttributeSet.java ! src/java.desktop/share/classes/javax/swing/text/StyleContext.java ! src/java.desktop/share/classes/javax/swing/text/html/CSS.java ! src/java.desktop/share/classes/javax/swing/text/html/HTML.java ! src/java.desktop/share/classes/javax/swing/text/html/parser/ParserDelegator.java ! src/java.desktop/share/classes/javax/swing/tree/DefaultMutableTreeNode.java ! src/java.desktop/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/java.desktop/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java ! src/java.desktop/share/classes/sun/awt/CausedFocusEvent.java ! src/java.desktop/share/classes/sun/awt/EmbeddedFrame.java ! src/java.desktop/share/classes/sun/awt/im/CompositionArea.java ! src/java.desktop/share/classes/sun/awt/im/InputMethodJFrame.java ! src/java.desktop/share/classes/sun/awt/im/SimpleInputMethodWindow.java ! src/java.desktop/share/classes/sun/awt/shell/DefaultShellFolder.java ! src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java ! src/java.desktop/share/classes/sun/font/FontDesignMetrics.java ! src/java.desktop/share/classes/sun/print/CustomMediaSizeName.java ! src/java.desktop/share/classes/sun/print/CustomMediaTray.java ! src/java.desktop/share/classes/sun/print/PrinterJobWrapper.java ! src/java.desktop/share/classes/sun/print/SunAlternateMedia.java ! src/java.desktop/share/classes/sun/swing/PrintColorUIResource.java ! src/java.desktop/unix/classes/sun/awt/X11/XMouseDragGestureRecognizer.java ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/java.desktop/windows/classes/sun/awt/windows/WMouseDragGestureRecognizer.java Changeset: e3b548a6 Author: Yasumasa Suenaga Date: 2021-01-15 01:58:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e3b548a6 8257736: InputStream from BodyPublishers.ofInputStream() leaks when IOE happens Reviewed-by: dfuchs, chegar ! src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java + test/jdk/java/net/httpclient/StreamCloseTest.java Changeset: 90960c5f Author: Yasumasa Suenaga Date: 2021-01-15 02:47:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/90960c5f 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed Reviewed-by: dholmes, sspitsyn ! src/hotspot/share/prims/jvmti.xml ! src/hotspot/share/prims/jvmtiExport.cpp ! test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java Changeset: 0148adf2 Author: Vladimir Ivanov Date: 2021-01-14 17:18:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0148adf2 8255120: C2: assert(outer->outcnt() >= phis + 2 && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis Reviewed-by: thartmann ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/loopnode.hpp ! test/hotspot/jtreg/ProblemList.txt Changeset: 4307fa68 Author: Erik Gahlin Date: 2021-01-14 21:26:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4307fa68 8253505: JFR: onFlush invoked out of order with a sorted event stream Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingFile.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ChunkParser.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/Dispatcher.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventDirectoryStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventFileStream.java Changeset: d701babb Author: Jesper Wilhelmsson Date: 2021-01-15 03:10:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d701babb Merge ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java ! test/hotspot/jtreg/ProblemList.txt ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java ! test/hotspot/jtreg/ProblemList.txt Changeset: 2c8e337d Author: Tagir F. Valeev Date: 2021-01-15 04:11:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2c8e337d 8259622: TreeMap.computeIfAbsent deviates from spec Reviewed-by: smarks ! src/java.base/share/classes/java/util/TreeMap.java ! test/jdk/java/util/Map/InPlaceOpsCollisions.java Changeset: 6d4a593f Author: Richard Reingruber Date: 2021-01-15 07:39:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6d4a593f 8259627: Potential memory leaks in JVMTI after JDK-8227745 Reviewed-by: shade, stuefe, dholmes, sspitsyn ! src/hotspot/share/prims/jvmtiEnv.cpp Changeset: b01a15e4 Author: K Suman Rajkumaar <70650887+skodanda at users.noreply.github.com> Committer: Alexey Ivanov Date: 2021-01-15 09:40:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b01a15e4 8258884: [TEST_BUG] Convert applet-based test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a regular java test Reviewed-by: aivanov, serb - test/jdk/javax/swing/JMenuItem/8031573/bug8031573.html ! test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java Changeset: ed91e293 Author: duke Date: 2021-01-15 11:01:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ed91e293 Automatic merge of jdk:master into master From mcimadamore at openjdk.java.net Fri Jan 15 11:28:15 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 15 Jan 2021 11:28:15 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v2] In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 23:24:23 GMT, Radoslaw Smogura wrote: >> This changes removes (by making no-ops) range and temporal checks for `ofNativeRestricted` segment. As this segment is global, above checks are not needed. >> >> Generated native code is smaller, and execution outperforms Java native arrays (depending on CPU) >> Changed >> Benchmark Mode Cnt Score Error Units >> AccessBenchmark.foreignAddress thrpt 5 128946129.691 ? 317433.113 ops/s >> AccessBenchmark.foreignAddressRaw thrpt 5 136883439.221 ? 749390.255 ops/s >> AccessBenchmark.target thrpt 5 125325586.957 ? 32129.931 ops/s >> Base >> Benchmark Mode Cnt Score Error Units >> AccessBenchmark.foreignAddress thrpt 5 125257424.876 ? 230508.169 ops/s >> AccessBenchmark.foreignAddressRaw thrpt 5 128818591.434 ? 241806.765 ops/s >> AccessBenchmark.target thrpt 5 125083379.819 ? 184070.467 ops/s >> --- >> This PR is replacement for https://github.com/openjdk/panama-foreign/pull/431 (OCA) >> and was partially discussed (before changes) in https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011747.htm >> >> --- >> Benchmark >> @State(Scope.Thread) >> public class AccessBenchmark { >> static final MemorySegment ms = MemorySegment.ofNativeRestricted(); >> static final VarHandle intHandle = MemoryHandles.varHandle(int.class, ByteOrder.nativeOrder()); >> >> int[] intData = new int[12]; >> volatile int intDataOffset = 0; >> >> volatile MemoryAddress address; >> volatile long addressRaw; >> >> @Setup >> public void setup() { >> var ms = MemorySegment.allocateNative(256); >> address = ms.address(); >> addressRaw = address.toRawLongValue(); >> } >> >> @Benchmark >> public void target(Blackhole bh) { >> int[] local = intData; >> int localOffset = intDataOffset; >> bh.consume(local[localOffset]); >> bh.consume(local[localOffset + 1]); >> } >> >> @Benchmark >> public void foreignAddress(Blackhole bh) { >> var a = address; >> bh.consume((int) intHandle.get(ms, a.addOffset(0).toRawLongValue())); >> bh.consume((int) intHandle.get(ms, a.addOffset(4).toRawLongValue())); >> } >> >> @Benchmark >> public void foreignAddressRaw(Blackhole bh) { >> var a = addressRaw; >> bh.consume((int) intHandle.get(ms, a)); >> bh.consume((int) intHandle.get(ms, a + 4)); >> } >> } > > Radoslaw Smogura has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Looks good! Thanks for investigating the issues with lack of static on Unsafe. Could we please add the benchmark under test/micro/org/openjdk/bench/jdk/incubator/foreign ? We try to add benchmark for each case we find as we go along, to make sure we don't regress. This seems like another interesting case. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/437 From maurizio.cimadamore at oracle.com Fri Jan 15 11:30:30 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 15 Jan 2021 11:30:30 +0000 Subject: jextract: offset not multiple of alignment, causing ExceptionInInitializerError In-Reply-To: References: <8F1A859E-A71F-4C0F-ABC6-ADB51CAD037A@gmail.com> <11b37ba8-9312-e255-bd56-d5b794c86bf5@oracle.com> Message-ID: <4145f641-374b-b509-b7a4-7167590ad0c9@oracle.com> Aha! That's interesting. Pretty sure jextract is completely oblivious about that. Of course the solution would be to recover the pragma and tweak the layout alignment accordingly. I have a vague feeling that what "makes sense" is not going to be that easy using the clang API :-) We'll take? a look. Thanks for reporting this. Filed this: https://bugs.openjdk.java.net/browse/JDK-8259832 Maurizio On 15/01/2021 08:31, Sebastian Stenzel wrote: > I had another look at the original header file (macOS: usr/include/sys/fcntl.h). Turns out, this struct is surrounded by a pack(4), which should explain this behaviour: > > #pragma pack(4) > > struct log2phys { > unsigned int l2p_flags; /* unused so far */ > off_t l2p_contigbytes; /* F_LOG2PHYS: unused so far */ > /* F_LOG2PHYS_EXT: IN: number of bytes to be queried */ > /* OUT: number of contiguous bytes at this position */ > off_t l2p_devoffset; /* F_LOG2PHYS: OUT: bytes into device */ > /* F_LOG2PHYS_EXT: IN: bytes into file */ > /* OUT: bytes into device */ > }; > > #pragma pack() > > Question is: Is jextract _expected_ to be aware of this? > > >> On 14. Jan 2021, at 23:01, Maurizio Cimadamore wrote: >> >> That layout looks odd/wrong. >> >> It seems like there might be some padding missing. Note that you have a 64 bit field that is not 64 bit aligned - so accessing it might be slower. I believe in most compilers 32 bit of padding would be inserted. >> >> Or, if this is really the way the struct is laid out, jextract should have relaxed the alignment requirements for "l2p_contigbytes". As it stands, the jextract layout seems bogus. If you have access to the code, I'd suggest adding: >> >> C_LONG_LONG.withName("l2p_contigbytes").withAlignmentBits(32) >> >> This should allow you to initialize correctly. >> >> Maurizio >> >> On 14/01/2021 21:34, Sebastian Stenzel wrote: >>> Hey, >>> >>> Today I noticed a strange problem related to the MemoryLayout generated by jextract for the following struct: >>> >>> ``` >>> struct log2phys { >>> u_int32_t l2p_flags; >>> off_t l2p_contigbytes; >>> off_t l2p_devoffset; >>> }; >>> ``` >>> >>> The generated layout looks like this: >>> >>> ``` >>> static final MemoryLayout log2phys$struct$LAYOUT_ = MemoryLayout.ofStruct( >>> C_INT.withName("l2p_flags"), >>> C_LONG_LONG.withName("l2p_contigbytes"), >>> C_LONG_LONG.withName("l2p_devoffset") >>> ).withName("log2phys"); >>> ``` >>> >>> During runtime, when the class was loaded and the VarHandle for "l2p_contigbytes" was created, I got the following exception: >>> >>> Exception in thread "main" java.lang.ExceptionInInitializerError >>> at com.example.fuse_h$fuse_operations.$LAYOUT(fuse_h.java:14808) >>> at com.example.fuse_h$fuse_operations.allocate(fuse_h.java:16294) >>> ... >>> Caused by: java.lang.UnsupportedOperationException: Invalid alignment requirements for layout b64(l2p_contigbytes)[abi/kind=LONG_LONG,layout/name=l2p_contigbytes] >>> at jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.checkAlignment(LayoutPath.java:273) >>> at jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.dereferenceHandle(LayoutPath.java:159) >>> at jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.lambda$varHandle$2(MemoryLayout.java:488) >>> at jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.computePathOp(MemoryLayout.java:538) >>> at jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.varHandle(MemoryLayout.java:488) >>> at com.example.fuse_h_constants_1.(fuse_h_constants_1.java:1921) >>> ... 5 more >>> >>> I set a breakpoint at LayoutPath.checkAlignment and can tell that "l2p_contigbytes" has an offset of 32 bit (sounds reasonable) but an alignment of 64 bit. I have no idea, what all this means, but apparently it is invalid. >>> >>> I were able to avoid this error in my test project, but I thought I'd better report this in case there is something wrong, as I can see nothing special about aforementioned struct. >>> >>> Let me know if I can provide any further information! >>> >>> Sebastian From mcimadamore at openjdk.java.net Fri Jan 15 11:53:10 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 15 Jan 2021 11:53:10 GMT Subject: [foreign-jextract] RFR: 8252759: Jextract flattens nested anonymous structs and unions when computing layouts In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 18:54:43 GMT, Jorn Vernee wrote: > Hi, > > This patch changes the way jextract handles nested structs and unions. > > Currently, when encountering an anonymous struct or union, jextract folds it's fields into the parent layout. But, this can lead to incorrect layouts, especially for unions. e.g. see the following example: > > struct Foo { > int x; > union { > int y; > int z; > }; > }; > > becomes: > > static final MemoryLayout Foo$struct$LAYOUT_ = MemoryLayout.ofStruct( > C_INT.withName("x"), > C_INT.withName("y"), > C_INT.withName("z") > ).withName("Foo"); > > In this case, the offset of the `z` field will not be correct. > > This patch changes the jextract behaviour to preserve the nested layouts of anonymous unions and structs, so the example becomes: > > static final MemoryLayout Foo$struct$LAYOUT_ = MemoryLayout.ofStruct( > C_INT.withName("x"), > MemoryLayout.ofUnion( > C_INT.withName("y"), > C_INT.withName("z") > ).withName("$anon$0") > ).withName("Foo"); > > Here, the anonymous layout gets a generated name which is needed so that the `y` and `z` fields can still be reached from the root layout with layout paths to create var handles for instance. > > Just the layout is changed, the Foo java class that we generate still has getters and setters for `y` and `z`. > > In the patch this behaviour is implemented by temporarily adding a 'prefix' (`"$anon$0"` in this case) to the `StructBuilder`, which is used in the generated layout paths to reach the nested fields. > > Thanks, > Jorn I like the approach, because not only it fixes code generation, but it also makes the AST "right" by avoiding early flattening. I think the test is a bit light - we might want to add more cases of deeply nested anon structs, just in case - as this area is a bit fragile. src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/RecordLayoutComputer.java line 108: > 106: > 107: void addFieldLayout(long offset, Type parent, Cursor c) { > 108: MemoryLayout memoryLayout = c.isAnonymousStruct() So, am I right that this avoid flattening of the anon structs fields into enclosing layout - e.g. layouts coming out of the parser now are non-flattened, but we tag them with an attribute so that we can emit flattened accessors later? ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/434 From jvernee at openjdk.java.net Fri Jan 15 12:01:17 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 15 Jan 2021 12:01:17 GMT Subject: [foreign-jextract] RFR: 8252759: Jextract flattens nested anonymous structs and unions when computing layouts In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 11:48:52 GMT, Maurizio Cimadamore wrote: >> Hi, >> >> This patch changes the way jextract handles nested structs and unions. >> >> Currently, when encountering an anonymous struct or union, jextract folds it's fields into the parent layout. But, this can lead to incorrect layouts, especially for unions. e.g. see the following example: >> >> struct Foo { >> int x; >> union { >> int y; >> int z; >> }; >> }; >> >> becomes: >> >> static final MemoryLayout Foo$struct$LAYOUT_ = MemoryLayout.ofStruct( >> C_INT.withName("x"), >> C_INT.withName("y"), >> C_INT.withName("z") >> ).withName("Foo"); >> >> In this case, the offset of the `z` field will not be correct. >> >> This patch changes the jextract behaviour to preserve the nested layouts of anonymous unions and structs, so the example becomes: >> >> static final MemoryLayout Foo$struct$LAYOUT_ = MemoryLayout.ofStruct( >> C_INT.withName("x"), >> MemoryLayout.ofUnion( >> C_INT.withName("y"), >> C_INT.withName("z") >> ).withName("$anon$0") >> ).withName("Foo"); >> >> Here, the anonymous layout gets a generated name which is needed so that the `y` and `z` fields can still be reached from the root layout with layout paths to create var handles for instance. >> >> Just the layout is changed, the Foo java class that we generate still has getters and setters for `y` and `z`. >> >> In the patch this behaviour is implemented by temporarily adding a 'prefix' (`"$anon$0"` in this case) to the `StructBuilder`, which is used in the generated layout paths to reach the nested fields. >> >> Thanks, >> Jorn > > src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/RecordLayoutComputer.java line 108: > >> 106: >> 107: void addFieldLayout(long offset, Type parent, Cursor c) { >> 108: MemoryLayout memoryLayout = c.isAnonymousStruct() > > So, am I right that this avoid flattening of the anon structs fields into enclosing layout - e.g. layouts coming out of the parser now are non-flattened, but we tag them with an attribute so that we can emit flattened accessors later? Yeah. The layout is only tagged if it is nested inside a parent record layout, since we can only assign a synthetic unique name to it in the context of the parent layout. But, the layout attached to the Declaration object for the anonymous struct will not have this name, since it is created separately outside of the context of the parent struct. That means that when generating code, and when we counter an anonymous nested struct/union decl in visitScoped, we have to look up it's layout in the layout of the parent in order to find the context dependent name we attached here. The attribute is used to find anonymous layouts. Technically we could also check if the name starts with `$anon$` instead of looking for the attribute, but doing it this way seemed more robust. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/434 From jvernee at openjdk.java.net Fri Jan 15 12:04:10 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 15 Jan 2021 12:04:10 GMT Subject: [foreign-jextract] RFR: 8252759: Jextract flattens nested anonymous structs and unions when computing layouts In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 11:50:15 GMT, Maurizio Cimadamore wrote: >> Hi, >> >> This patch changes the way jextract handles nested structs and unions. >> >> Currently, when encountering an anonymous struct or union, jextract folds it's fields into the parent layout. But, this can lead to incorrect layouts, especially for unions. e.g. see the following example: >> >> struct Foo { >> int x; >> union { >> int y; >> int z; >> }; >> }; >> >> becomes: >> >> static final MemoryLayout Foo$struct$LAYOUT_ = MemoryLayout.ofStruct( >> C_INT.withName("x"), >> C_INT.withName("y"), >> C_INT.withName("z") >> ).withName("Foo"); >> >> In this case, the offset of the `z` field will not be correct. >> >> This patch changes the jextract behaviour to preserve the nested layouts of anonymous unions and structs, so the example becomes: >> >> static final MemoryLayout Foo$struct$LAYOUT_ = MemoryLayout.ofStruct( >> C_INT.withName("x"), >> MemoryLayout.ofUnion( >> C_INT.withName("y"), >> C_INT.withName("z") >> ).withName("$anon$0") >> ).withName("Foo"); >> >> Here, the anonymous layout gets a generated name which is needed so that the `y` and `z` fields can still be reached from the root layout with layout paths to create var handles for instance. >> >> Just the layout is changed, the Foo java class that we generate still has getters and setters for `y` and `z`. >> >> In the patch this behaviour is implemented by temporarily adding a 'prefix' (`"$anon$0"` in this case) to the `StructBuilder`, which is used in the generated layout paths to reach the nested fields. >> >> Thanks, >> Jorn > > I like the approach, because not only it fixes code generation, but it also makes the AST "right" by avoiding early flattening. I think the test is a bit light - we might want to add more cases of deeply nested anon structs, just in case - as this area is a bit fragile. Note that we already have a test that more broadly tests nested structs; https://github.com/openjdk/panama-foreign/blob/foreign-jextract/test/jdk/tools/jextract/nested.h It just wasn't catching this particular case, so I added something separate. I can enhance that test to also check offsets of fields. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/434 From duke at openjdk.java.net Fri Jan 15 12:07:28 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 15 Jan 2021 12:07:28 GMT Subject: [foreign-jextract] RFR: Merge foreign-memaccess+abi [v2] In-Reply-To: <5D0uWYC_mTQ379o8XsfRRkhoKhvflMxRx7AkHAv3Sgk=.143ae13d-e3ce-4425-b1bd-ccea834997c2@github.com> References: <5D0uWYC_mTQ379o8XsfRRkhoKhvflMxRx7AkHAv3Sgk=.143ae13d-e3ce-4425-b1bd-ccea834997c2@github.com> Message-ID: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 135 commits from the branch `foreign-memaccess+abi`that can **not** be merged into the branch `foreign-jextract`: > > The following file contains merge conflicts: > > - make/CompileJavaModules.gmk > > All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). > The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. > The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. > > # Ensure target branch is up to date > $ git checkout foreign-jextract > $ git pull https://github.com/openjdk/panama-foreign.git foreign-jextract > > # Fetch and checkout the branch for this pull request > $ git fetch https://github.com/openjdk-bot/panama-foreign.git +89:openjdk-bot-89 > $ git checkout openjdk-bot-89 > > # Merge the target branch > $ git merge foreign-jextract > > When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: > > $ git add paths/to/files/with/conflicts > $ git commit -m 'Merge foreign-memaccess+abi' > > > When you have created the merge commit, run the following command to push the merge commit to this pull request: > > $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-89:89 > > _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. > > Thanks, > J. Duke J. Duke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 409 additional commits since the last revision: - Merge branch 'foreign-jextract' into openjdk-bot-89 - 8259473: jextract generated code should throw exception for unfound native symbols from calls, variable access, set immediately Reviewed-by: mcimadamore, jvernee - Automatic merge of foreign-memaccess+abi into foreign-jextract - Automatic merge of foreign-memaccess+abi into foreign-jextract - 8259226: jextract should differentiate between clang errors vs other runtime issues Reviewed-by: mcimadamore - Automatic merge of foreign-memaccess+abi into foreign-jextract - Automatic merge of foreign-memaccess+abi into foreign-jextract - Merge foreign-memaccess+abi - 8258605: regression: jextract can not handle function prototypes as function arguments Reviewed-by: mcimadamore - 8258405: functional interfaces are not generated for struct fields/global variables with function pointers Reviewed-by: mcimadamore, jvernee - ... and 399 more: https://git.openjdk.java.net/panama-foreign/compare/e69b59e5...f704f19d ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/438/files - new: https://git.openjdk.java.net/panama-foreign/pull/438/files/e69b59e5..f704f19d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=438&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=438&range=00-01 Stats: 39174 lines in 226 files changed: 39167 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/438.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/438/head:pull/438 PR: https://git.openjdk.java.net/panama-foreign/pull/438 From duke at openjdk.java.net Fri Jan 15 12:07:29 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 15 Jan 2021 12:07:29 GMT Subject: [foreign-jextract] RFR: Merge foreign-memaccess+abi In-Reply-To: <5D0uWYC_mTQ379o8XsfRRkhoKhvflMxRx7AkHAv3Sgk=.143ae13d-e3ce-4425-b1bd-ccea834997c2@github.com> References: <5D0uWYC_mTQ379o8XsfRRkhoKhvflMxRx7AkHAv3Sgk=.143ae13d-e3ce-4425-b1bd-ccea834997c2@github.com> Message-ID: On Fri, 15 Jan 2021 11:01:53 GMT, J. Duke wrote: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 135 commits from the branch `foreign-memaccess+abi`that can **not** be merged into the branch `foreign-jextract`: > > The following file contains merge conflicts: > > - make/CompileJavaModules.gmk > > All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). > The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. > The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. > > # Ensure target branch is up to date > $ git checkout foreign-jextract > $ git pull https://github.com/openjdk/panama-foreign.git foreign-jextract > > # Fetch and checkout the branch for this pull request > $ git fetch https://github.com/openjdk-bot/panama-foreign.git +89:openjdk-bot-89 > $ git checkout openjdk-bot-89 > > # Merge the target branch > $ git merge foreign-jextract > > When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: > > $ git add paths/to/files/with/conflicts > $ git commit -m 'Merge foreign-memaccess+abi' > > > When you have created the merge commit, run the following command to push the merge commit to this pull request: > > $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-89:89 > > _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. > > Thanks, > J. Duke ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/438 From duke at openjdk.java.net Fri Jan 15 12:07:31 2021 From: duke at openjdk.java.net (J.Duke) Date: Fri, 15 Jan 2021 12:07:31 GMT Subject: [foreign-jextract] Integrated: Merge foreign-memaccess+abi In-Reply-To: <5D0uWYC_mTQ379o8XsfRRkhoKhvflMxRx7AkHAv3Sgk=.143ae13d-e3ce-4425-b1bd-ccea834997c2@github.com> References: <5D0uWYC_mTQ379o8XsfRRkhoKhvflMxRx7AkHAv3Sgk=.143ae13d-e3ce-4425-b1bd-ccea834997c2@github.com> Message-ID: <5TxdQDNUrNQ3XuM2maaKi4FowsHlWB33bDKW6Js0ZJM=.3a29945b-401f-4985-b200-7c0a3ee4e650@github.com> On Fri, 15 Jan 2021 11:01:53 GMT, J. Duke wrote: > Hi all, > > this is an _automatically_ generated pull request to notify you that there are 135 commits from the branch `foreign-memaccess+abi`that can **not** be merged into the branch `foreign-jextract`: > > The following file contains merge conflicts: > > - make/CompileJavaModules.gmk > > All Committers in this [project](https://openjdk.java.net/census#panama) have access to my [personal fork](https://github.com/openjdk-bot/panama-foreign) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this). > The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request. > The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/panama-foreign](https://github.com/openjdk/panama-foreign) repository. > > # Ensure target branch is up to date > $ git checkout foreign-jextract > $ git pull https://github.com/openjdk/panama-foreign.git foreign-jextract > > # Fetch and checkout the branch for this pull request > $ git fetch https://github.com/openjdk-bot/panama-foreign.git +89:openjdk-bot-89 > $ git checkout openjdk-bot-89 > > # Merge the target branch > $ git merge foreign-jextract > > When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit: > > $ git add paths/to/files/with/conflicts > $ git commit -m 'Merge foreign-memaccess+abi' > > > When you have created the merge commit, run the following command to push the merge commit to this pull request: > > $ git push https://github.com/openjdk-bot/panama-foreign.git openjdk-bot-89:89 > > _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly. > > Thanks, > J. Duke This pull request has now been integrated. Changeset: 8eede509 Author: J. Duke Committer: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/8eede509 Stats: 28327 lines in 1076 files changed: 15739 ins; 7639 del; 4949 mod Merge foreign-memaccess+abi ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/438 From jvernee at openjdk.java.net Fri Jan 15 12:13:09 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 15 Jan 2021 12:13:09 GMT Subject: [foreign-jextract] RFR: 8252759: Jextract flattens nested anonymous structs and unions when computing layouts In-Reply-To: References: Message-ID: <7M1mdOPUVIB3lMOmxmIwl8eGgyfD6x9HUX164SYdpQs=.0b9892c4-60d2-43f7-990a-6d2a71c56177@github.com> On Fri, 15 Jan 2021 11:58:31 GMT, Jorn Vernee wrote: >> src/jdk.incubator.jextract/share/classes/jdk/internal/jextract/impl/RecordLayoutComputer.java line 108: >> >>> 106: >>> 107: void addFieldLayout(long offset, Type parent, Cursor c) { >>> 108: MemoryLayout memoryLayout = c.isAnonymousStruct() >> >> So, am I right that this avoid flattening of the anon structs fields into enclosing layout - e.g. layouts coming out of the parser now are non-flattened, but we tag them with an attribute so that we can emit flattened accessors later? > > Yeah. The layout is only tagged if it is nested inside a parent record layout, since we can only assign a synthetic unique name to it in the context of the parent layout. But, the layout attached to the Declaration object for the anonymous struct will not have this name, since it is created separately outside of the context of the parent struct. > > That means that when generating code, and when we counter an anonymous nested struct/union decl in visitScoped, we have to look up it's layout in the layout of the parent in order to find the context dependent name we attached here. The attribute is used to find anonymous layouts. Technically we could also check if the name starts with `$anon$` instead of looking for the attribute, but doing it this way seemed more robust. The name on the anonymous struct itself is needed to create a layout path to the nested field. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/434 From mcimadamore at openjdk.java.net Fri Jan 15 12:26:11 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 15 Jan 2021 12:26:11 GMT Subject: [foreign-jextract] RFR: 8252759: Jextract flattens nested anonymous structs and unions when computing layouts In-Reply-To: References: Message-ID: <2lNKYAe4JDQ9ULE47X9Nba_fzmZSR_ckGL9XnjGlvQs=.dc233c11-9d37-4376-b0f4-20c6c87f8f62@github.com> On Fri, 15 Jan 2021 12:01:09 GMT, Jorn Vernee wrote: > Note that we already have a test that more broadly tests nested structs; https://github.com/openjdk/panama-foreign/blob/foreign-jextract/test/jdk/tools/jextract/nested.h > > It just wasn't catching this particular case, so I added something separate. I can enhance that test to also check offsets of fields. Yes, but that test is super simple: https://github.com/openjdk/panama-foreign/blob/foreign-jextract/test/jdk/tools/jextract/Test8244512.java (unless I'm missing something). I'd suggest to unify both test and verify the emitted layouts (and field accessors too), not just the classes that come out. I'm also ok if we do that as a separate change. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/434 From jvernee at openjdk.java.net Fri Jan 15 14:31:44 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 15 Jan 2021 14:31:44 GMT Subject: [foreign-jextract] RFR: 8252759: Jextract flattens nested anonymous structs and unions when computing layouts [v2] In-Reply-To: References: Message-ID: > Hi, > > This patch changes the way jextract handles nested structs and unions. > > Currently, when encountering an anonymous struct or union, jextract folds it's fields into the parent layout. But, this can lead to incorrect layouts, especially for unions. e.g. see the following example: > > struct Foo { > int x; > union { > int y; > int z; > }; > }; > > becomes: > > static final MemoryLayout Foo$struct$LAYOUT_ = MemoryLayout.ofStruct( > C_INT.withName("x"), > C_INT.withName("y"), > C_INT.withName("z") > ).withName("Foo"); > > In this case, the offset of the `z` field will not be correct. > > This patch changes the jextract behaviour to preserve the nested layouts of anonymous unions and structs, so the example becomes: > > static final MemoryLayout Foo$struct$LAYOUT_ = MemoryLayout.ofStruct( > C_INT.withName("x"), > MemoryLayout.ofUnion( > C_INT.withName("y"), > C_INT.withName("z") > ).withName("$anon$0") > ).withName("Foo"); > > Here, the anonymous layout gets a generated name which is needed so that the `y` and `z` fields can still be reached from the root layout with layout paths to create var handles for instance. > > Just the layout is changed, the Foo java class that we generate still has getters and setters for `y` and `z`. > > In the patch this behaviour is implemented by temporarily adding a 'prefix' (`"$anon$0"` in this case) to the `StructBuilder`, which is used in the generated layout paths to reach the nested fields. > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Rename and expand nested struct and union test ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/434/files - new: https://git.openjdk.java.net/panama-foreign/pull/434/files/26f830e2..c3e4f479 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=434&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=434&range=00-01 Stats: 246 lines in 4 files changed: 178 ins; 64 del; 4 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/434.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/434/head:pull/434 PR: https://git.openjdk.java.net/panama-foreign/pull/434 From jvernee at openjdk.java.net Fri Jan 15 14:38:36 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 15 Jan 2021 14:38:36 GMT Subject: [foreign-jextract] RFR: 8252759: Jextract flattens nested anonymous structs and unions when computing layouts [v3] In-Reply-To: References: Message-ID: > Hi, > > This patch changes the way jextract handles nested structs and unions. > > Currently, when encountering an anonymous struct or union, jextract folds it's fields into the parent layout. But, this can lead to incorrect layouts, especially for unions. e.g. see the following example: > > struct Foo { > int x; > union { > int y; > int z; > }; > }; > > becomes: > > static final MemoryLayout Foo$struct$LAYOUT_ = MemoryLayout.ofStruct( > C_INT.withName("x"), > C_INT.withName("y"), > C_INT.withName("z") > ).withName("Foo"); > > In this case, the offset of the `z` field will not be correct. > > This patch changes the jextract behaviour to preserve the nested layouts of anonymous unions and structs, so the example becomes: > > static final MemoryLayout Foo$struct$LAYOUT_ = MemoryLayout.ofStruct( > C_INT.withName("x"), > MemoryLayout.ofUnion( > C_INT.withName("y"), > C_INT.withName("z") > ).withName("$anon$0") > ).withName("Foo"); > > Here, the anonymous layout gets a generated name which is needed so that the `y` and `z` fields can still be reached from the root layout with layout paths to create var handles for instance. > > Just the layout is changed, the Foo java class that we generate still has getters and setters for `y` and `z`. > > In the patch this behaviour is implemented by temporarily adding a 'prefix' (`"$anon$0"` in this case) to the `StructBuilder`, which is used in the generated layout paths to reach the nested fields. > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Unify tests ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/434/files - new: https://git.openjdk.java.net/panama-foreign/pull/434/files/c3e4f479..4a6bb618 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=434&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=434&range=01-02 Stats: 102 lines in 4 files changed: 13 ins; 89 del; 0 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/434.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/434/head:pull/434 PR: https://git.openjdk.java.net/panama-foreign/pull/434 From jvernee at openjdk.java.net Fri Jan 15 14:38:36 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 15 Jan 2021 14:38:36 GMT Subject: [foreign-jextract] RFR: 8252759: Jextract flattens nested anonymous structs and unions when computing layouts [v3] In-Reply-To: <2lNKYAe4JDQ9ULE47X9Nba_fzmZSR_ckGL9XnjGlvQs=.dc233c11-9d37-4376-b0f4-20c6c87f8f62@github.com> References: <2lNKYAe4JDQ9ULE47X9Nba_fzmZSR_ckGL9XnjGlvQs=.dc233c11-9d37-4376-b0f4-20c6c87f8f62@github.com> Message-ID: On Fri, 15 Jan 2021 12:22:35 GMT, Maurizio Cimadamore wrote: >> Note that we already have a test that more broadly tests nested structs; https://github.com/openjdk/panama-foreign/blob/foreign-jextract/test/jdk/tools/jextract/nested.h >> >> It just wasn't catching this particular case, so I added something separate. I can enhance that test to also check offsets of fields. > >> Note that we already have a test that more broadly tests nested structs; https://github.com/openjdk/panama-foreign/blob/foreign-jextract/test/jdk/tools/jextract/nested.h >> >> It just wasn't catching this particular case, so I added something separate. I can enhance that test to also check offsets of fields. > > Yes, but that test is super simple: > https://github.com/openjdk/panama-foreign/blob/foreign-jextract/test/jdk/tools/jextract/Test8244512.java > > (unless I'm missing something). > > I'd suggest to unify both test and verify the emitted layouts (and field accessors too), not just the classes that come out. I'm also ok if we do that as a separate change. I've unified the two tests, and expanded the existing test of nested structs to also verify field offsets and accessors. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/434 From mcimadamore at openjdk.java.net Fri Jan 15 17:15:10 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 15 Jan 2021 17:15:10 GMT Subject: [foreign-jextract] RFR: 8252759: Jextract flattens nested anonymous structs and unions when computing layouts [v3] In-Reply-To: References: Message-ID: On Fri, 15 Jan 2021 14:38:36 GMT, Jorn Vernee wrote: >> Hi, >> >> This patch changes the way jextract handles nested structs and unions. >> >> Currently, when encountering an anonymous struct or union, jextract folds it's fields into the parent layout. But, this can lead to incorrect layouts, especially for unions. e.g. see the following example: >> >> struct Foo { >> int x; >> union { >> int y; >> int z; >> }; >> }; >> >> becomes: >> >> static final MemoryLayout Foo$struct$LAYOUT_ = MemoryLayout.ofStruct( >> C_INT.withName("x"), >> C_INT.withName("y"), >> C_INT.withName("z") >> ).withName("Foo"); >> >> In this case, the offset of the `z` field will not be correct. >> >> This patch changes the jextract behaviour to preserve the nested layouts of anonymous unions and structs, so the example becomes: >> >> static final MemoryLayout Foo$struct$LAYOUT_ = MemoryLayout.ofStruct( >> C_INT.withName("x"), >> MemoryLayout.ofUnion( >> C_INT.withName("y"), >> C_INT.withName("z") >> ).withName("$anon$0") >> ).withName("Foo"); >> >> Here, the anonymous layout gets a generated name which is needed so that the `y` and `z` fields can still be reached from the root layout with layout paths to create var handles for instance. >> >> Just the layout is changed, the Foo java class that we generate still has getters and setters for `y` and `z`. >> >> In the patch this behaviour is implemented by temporarily adding a 'prefix' (`"$anon$0"` in this case) to the `StructBuilder`, which is used in the generated layout paths to reach the nested fields. >> >> Thanks, >> Jorn > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Unify tests Looks great! Thanks for making the test more portable too (e.g. `long long`). ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/434 From jvernee at openjdk.java.net Fri Jan 15 18:16:13 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 15 Jan 2021 18:16:13 GMT Subject: [foreign-jextract] Integrated: 8252759: Jextract flattens nested anonymous structs and unions when computing layouts In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 18:54:43 GMT, Jorn Vernee wrote: > Hi, > > This patch changes the way jextract handles nested structs and unions. > > Currently, when encountering an anonymous struct or union, jextract folds it's fields into the parent layout. But, this can lead to incorrect layouts, especially for unions. e.g. see the following example: > > struct Foo { > int x; > union { > int y; > int z; > }; > }; > > becomes: > > static final MemoryLayout Foo$struct$LAYOUT_ = MemoryLayout.ofStruct( > C_INT.withName("x"), > C_INT.withName("y"), > C_INT.withName("z") > ).withName("Foo"); > > In this case, the offset of the `z` field will not be correct. > > This patch changes the jextract behaviour to preserve the nested layouts of anonymous unions and structs, so the example becomes: > > static final MemoryLayout Foo$struct$LAYOUT_ = MemoryLayout.ofStruct( > C_INT.withName("x"), > MemoryLayout.ofUnion( > C_INT.withName("y"), > C_INT.withName("z") > ).withName("$anon$0") > ).withName("Foo"); > > Here, the anonymous layout gets a generated name which is needed so that the `y` and `z` fields can still be reached from the root layout with layout paths to create var handles for instance. > > Just the layout is changed, the Foo java class that we generate still has getters and setters for `y` and `z`. > > In the patch this behaviour is implemented by temporarily adding a 'prefix' (`"$anon$0"` in this case) to the `StructBuilder`, which is used in the generated layout paths to reach the nested fields. > > Thanks, > Jorn This pull request has now been integrated. Changeset: 6aafbbbe Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/6aafbbbe Stats: 422 lines in 12 files changed: 295 ins; 66 del; 61 mod 8252759: Jextract flattens nested anonymous structs and unions when computing layouts Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/434 From mr.chrisvest at gmail.com Fri Jan 15 20:49:30 2021 From: mr.chrisvest at gmail.com (Chris Vest) Date: Fri, 15 Jan 2021 21:49:30 +0100 Subject: MemoryAddress.toRawLongValue Message-ID: Hi, In Netty we expect to have use for MemoryAddress.toRawLongValue, for JNI integration stuff. Calling it on a heap address will throw UOE, which is fine, but it'd be nice if we could check with some hasRawLongValue method instead and avoid making unsupported calls. Thanks, Chris From maurizio.cimadamore at oracle.com Fri Jan 15 21:30:26 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 15 Jan 2021 21:30:26 +0000 Subject: MemoryAddress.toRawLongValue In-Reply-To: References: Message-ID: Hi Chris, I hear you - another option would be an OptionalLong - but that would create some extra allocations (although maybe that's ok). I think an extra predicate is something we could do. Again, with pattern matching the pair of predicate + accessor might (one day) just be replaced by a pattern declaration: MemoryAddress addr = ... if (add instanceof MemoryAddress.of(long rawValue)) { ? // use rawValue } Cheers Maurizio On 15/01/2021 20:49, Chris Vest wrote: > Hi, > > In Netty we expect to have use for MemoryAddress.toRawLongValue, for JNI > integration stuff. > Calling it on a heap address will throw UOE, which is fine, but it'd be > nice if we could check with some hasRawLongValue method instead and avoid > making unsupported calls. > > Thanks, > Chris From luhenry at openjdk.java.net Fri Jan 15 23:49:15 2021 From: luhenry at openjdk.java.net (Ludovic Henry) Date: Fri, 15 Jan 2021 23:49:15 GMT Subject: [vectorIntrinsics] Withdrawn: Merge panama-vector:master In-Reply-To: <1YcghAZgpx7zjN6MJh5jpzDSFBBIxA4Sef0Km1mG_kw=.336f39e7-af06-42c4-a3c1-1f9c6506ad9c@github.com> References: <1YcghAZgpx7zjN6MJh5jpzDSFBBIxA4Sef0Km1mG_kw=.336f39e7-af06-42c4-a3c1-1f9c6506ad9c@github.com> Message-ID: <-kCh-D1OXkJnnZ3ctS120vvfZVjXWKMYAGDOqiwBALU=.d1e18cb7-ab9b-4726-8483-35c74440d494@github.com> On Fri, 4 Dec 2020 13:52:10 GMT, Ludovic Henry wrote: > Merge latest master changes into vectorIntrinsics branch. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/28 From github.com+7535718+rsmogura at openjdk.java.net Sat Jan 16 02:08:55 2021 From: github.com+7535718+rsmogura at openjdk.java.net (Radoslaw Smogura) Date: Sat, 16 Jan 2021 02:08:55 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v3] In-Reply-To: References: Message-ID: <9EfxwrBTtLQ49qhoPej98Ff7umUHJMgE0ljM7hSztPo=.a7678d80-a98a-4355-b085-a9f2e20ca912@github.com> > This changes removes (by making no-ops) range and temporal checks for `ofNativeRestricted` segment. As this segment is global, above checks are not needed. > > Generated native code is smaller, and execution outperforms Java native arrays (depending on CPU) > Changed > Benchmark Mode Cnt Score Error Units > AccessBenchmark.foreignAddress thrpt 5 128946129.691 ? 317433.113 ops/s > AccessBenchmark.foreignAddressRaw thrpt 5 136883439.221 ? 749390.255 ops/s > AccessBenchmark.target thrpt 5 125325586.957 ? 32129.931 ops/s > Base > Benchmark Mode Cnt Score Error Units > AccessBenchmark.foreignAddress thrpt 5 125257424.876 ? 230508.169 ops/s > AccessBenchmark.foreignAddressRaw thrpt 5 128818591.434 ? 241806.765 ops/s > AccessBenchmark.target thrpt 5 125083379.819 ? 184070.467 ops/s > --- > This PR is replacement for https://github.com/openjdk/panama-foreign/pull/431 (OCA) > and was partially discussed (before changes) in https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011747.htm > > --- > Benchmark > @State(Scope.Thread) > public class AccessBenchmark { > static final MemorySegment ms = MemorySegment.ofNativeRestricted(); > static final VarHandle intHandle = MemoryHandles.varHandle(int.class, ByteOrder.nativeOrder()); > > int[] intData = new int[12]; > volatile int intDataOffset = 0; > > volatile MemoryAddress address; > volatile long addressRaw; > > @Setup > public void setup() { > var ms = MemorySegment.allocateNative(256); > address = ms.address(); > addressRaw = address.toRawLongValue(); > } > > @Benchmark > public void target(Blackhole bh) { > int[] local = intData; > int localOffset = intDataOffset; > bh.consume(local[localOffset]); > bh.consume(local[localOffset + 1]); > } > > @Benchmark > public void foreignAddress(Blackhole bh) { > var a = address; > bh.consume((int) intHandle.get(ms, a.addOffset(0).toRawLongValue())); > bh.consume((int) intHandle.get(ms, a.addOffset(4).toRawLongValue())); > } > > @Benchmark > public void foreignAddressRaw(Blackhole bh) { > var a = addressRaw; > bh.consume((int) intHandle.get(ms, a)); > bh.consume((int) intHandle.get(ms, a + 4)); > } > } Radoslaw Smogura has updated the pull request incrementally with one additional commit since the last revision: JMH Benchmarks for evaluation of `ofNativeRestricted` Original benchmark comparing performance of accessing data using var handles vs ordinal arrays Modified existing benchmark `LoopOverNonConstant` to see differences versus range / temporal checking & and non-checking segments. ``` Benchmark Mode Cnt Score Error Units LoopOverNonConstant.BB_get avgt 30 3.885 ? 0.003 ns/op LoopOverNonConstant.BB_loop avgt 30 0.229 ? 0.001 ms/op LoopOverNonConstant.global_segment_get avgt 30 3.663 ? 0.006 ns/op LoopOverNonConstant.global_segment_loop avgt 30 0.374 ? 0.001 ms/op LoopOverNonConstant.segment_get avgt 30 5.514 ? 0.023 ns/op LoopOverNonConstant.segment_loop avgt 30 0.229 ? 0.001 ms/op ``` Not optimized `ofNativeRestricted` ``` LoopOverNonConstant.global_segment_get avgt 30 4.126 ? 0.006 ns/op LoopOverNonConstant.global_segment_loop avgt 30 0.603 ? 0.001 ms/op ``` ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/437/files - new: https://git.openjdk.java.net/panama-foreign/pull/437/files/c7d4fdf1..ee220f9d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=437&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=437&range=01-02 Stats: 127 lines in 2 files changed: 125 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/437.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/437/head:pull/437 PR: https://git.openjdk.java.net/panama-foreign/pull/437 From github.com+7535718+rsmogura at openjdk.java.net Sat Jan 16 02:08:57 2021 From: github.com+7535718+rsmogura at openjdk.java.net (Radoslaw Smogura) Date: Sat, 16 Jan 2021 02:08:57 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v2] In-Reply-To: References: Message-ID: <0rB3a3cVsVNJ-L9LhioxRjz1m-5ElRVTgdvxqNaiOPM=.e0295739-28a3-4756-836d-c48c4099e73d@github.com> On Fri, 15 Jan 2021 11:24:55 GMT, Maurizio Cimadamore wrote: >> Radoslaw Smogura has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > Looks good! Thanks for investigating the issues with lack of static on Unsafe. > > Could we please add the benchmark under test/micro/org/openjdk/bench/jdk/incubator/foreign ? We try to add benchmark for each case we find as we go along, to make sure we don't regress. This seems like another interesting case. Hi. I've added the benchmarks: * benchmarks used by me; * added a new benchmarks to `LoopOverNonConstant` to compare performance of this approach with existing methods for getting values. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/437 From piotr.tarsa at gmail.com Sat Jan 16 12:12:50 2021 From: piotr.tarsa at gmail.com (Piotr Tarsa) Date: Sat, 16 Jan 2021 13:12:50 +0100 Subject: Comments / metadata in assembly listings don't make sense for code vectorized using Vector API In-Reply-To: References: Message-ID: Hi Paul, Thanks for replying. As per your advice I've prepared JMH benchmarks. Also I've copied some optimizations from other mandelbrot benchmark implementations and achieved further speedup. New version is here: https://gist.github.com/tarsa/7a9c80bb84c2dcd807be9cd16a655ee0/4ced690e20ad561515094995a852adc95820955e It also has simplified buffer management and multithreading, so there's less boilerplate. Results from JMH are quite good (a bit reordered for clarity): # Run complete. Total time: 00:16:42 Benchmark Mode Cnt Score Error Units benchRowMT thrpt 5 17755,337 ? 279,118 ops/s benchRowST thrpt 5 4535,280 ? 7,471 ops/s benchScalarPairsMT thrpt 5 4583,354 ? 89,532 ops/s benchScalarPairsST thrpt 5 1163,925 ? 0,469 ops/s benchScalarMT thrpt 5 2666,210 ? 5,004 ops/s benchScalarST thrpt 5 673,234 ? 0,167 ops/s benchVectorMT thrpt 5 18020,397 ? 54,230 ops/s benchVectorST thrpt 5 4567,873 ? 10,339 ops/s benchVectorWithTransfer thrpt 5 4557,361 ? 9,450 ops/s benchScalarRemainderOnly thrpt 5 7105989,167 ? 4691,311 ops/s The mandelbrot Java #2 is named here benchScalarPairsMT (it's manually unrolled x2). My new vectorized version (similarly manually unrolled) is benchVectorMT and it has about 4x higher performance which is quite good. However when I run the benchmark from command line (in non-JMH mode) to replicate the benchmark rules then there is much smaller performance difference. Mandelbrot Java #2 (the unvectorized one) takes about 3s, while my one takes about 1.2s - 1.3s and sometimes fluctuated up to about 1.5s. It seems that compilation takes up a lot of benchmark time. Is it possible to reduce compilation times for code using Vector API? wt., 5 sty 2021 o 00:11 Paul Sandoz napisa?(a): > > Hi Piotr, > > Thanks for experimenting. The Intel folks have also experimented with Mandelbrot generation and might be able to comment with their experience in comparison. > > I would be interested to know what your expectations were with regards to speedup. I've expected more than 2x speedup vs the scalar version as I have 256-bit SIMD on my Haswell machine. Luckily, I've managed to achieve it as I've written at the beginning. > It?s hard to evaluate without a JMH benchmark which can more easily present the code hotspots and isolate from the other areas, such as for thread parallelism. My recommendation would be to extract out the computeChunksVector kernel and embed within such a benchmark. > > Switching off tired compilation should help (-XX:-TiredCompilation) i.e. only C2, not C1, in getting to the C2 generated code faster. Good point. I've made a JMH benchmark (that I've presented at the beginning) and saw where are inefficiences. > To your question about the assembly listing I believe as HotSpot goes through various compiler passes it tries to preserve the byte code index associated with generated instructions, but naturally as code is lowered this becomes an approximation, and especially so with the Vector API. Hmmm, it's sad that it's only approximation. > In the case of "*synchronization entry?, this is stating the pseudo byte code index just before a method is entered. However, I think there is tech debt here, see > > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/debugInfoRec.hpp#L67 > > And the usages of SynchronizationEntryBCI in hotspot code. > > Running in fast debug mode will present a slightly higher-level view of generated code. Here?s a snippet: > > 26e vmulpd XMM12,XMM7,XMM7 ! mul packedD > 272 vaddpd XMM8,XMM0,XMM11 ! add packedD > 277 vmulpd XMM9,XMM8,XMM8 ! mul packedD > 27c vaddpd XMM0,XMM12,XMM9 ! add packedD > 281 vector_compare XMM10,XMM5,XMM0,#3 ! > 286 # TLS is in R15 > 286 cmpq RCX, [R15 + #344 (32-bit)] # raw ptr > 28d jnb,u B47 P=0.000100 C=-1.000000 > > ? > > 2cf vmovdqu [rsp + 64],XMM1 # spill > > 2d5 B25: # out( B44 B26 ) <- in( B48 B24 ) Freq: 9114.56 > 2d5 > 2d5 # checkcastPP of RAX > 2d5 vector_store_mask XMM1,XMM10 ! using XMM13 as TEMP > 2f4 vector_loadmask_byte XMM15,XMM1 > > 302 vmovdqu XMM1,[rsp + 448] # spill > 30b vpor XMM1,XMM1,XMM15 ! or vectors > 310 vector_store_mask XMM0,XMM1 ! using XMM14 as TEMP > 32e store_vector [RAX + #16 (8-bit)],XMM0 > > 333 vector_test RCX,XMM1, XMM2 ! using RFLAGS as TEMP > nop # 2 bytes pad for loops and calls > 340 testl RCX, RCX > 342 je B44 P=0.108889 C=184362.000000 > > > The mask instructions, such as vector_store_mask, are substituted for a more complex sequence of x86 instructions on AVX 2. Thanks. For now the speedup in JMH is good enough for me, so I won't dig into assembly code, but I'll consider fastdebug Java build when I explore assembly next time. > I do notice that the inner loop (upper bound of 5) does unroll (FWIW, making the inner bound a power of 2 is more friendly for unrolling). There also appears to be many register spills, suggesting non-optimal vector register allocation/usage by C2. I've tried factor of 4, but that didn't improve performance. I think it even made it worse as 50 is not a multiply of 4 and benchmark rules dictates that there must be exactly 50 iterations so I needed to make additional code for 50 % 4 = 2 extra iterations. That probably made code compilation even longer and worsen benchmark execution time. Instead of unrolling the inner loops, I've duplicated all vectors (i.e. unrolled the chunk-level loop, instead of the inner iteration level loop), so I was working on 256-bit / 64-bit * 2 = 8 results at a time. That worked well, similarly to mandelbrot Java #2. > I noticed this in the code: > > // in Rust version this works fine, so where's the bug then? > // cmpMask = vFours.lt(vZiN.add(vZrN)); > > What problem did you encounter? It works for me on the tip of https://github.com/openjdk/jdk. The results were different, but benchmark dictates that the output must be bit-to-bit identical to correct output. I've nailed it down. It's because of numeric overflows causing numbers to go to Double.Infinity and then subtracting Infinity from Infinity results in Double.NaN and then comparisons are always false. Anyway, I've tried to make a version without `cmpMask = cmpMask.or(newValue)` and made a correct version, but that turned out to be slower. Perhaps some of the mask operations are not intrinsified yet or something. Rust was doing the comparisons a little bit differently, properly accounting for NaNs. All tests were done on: openjdk 16-ea 2021-03-16 OpenJDK Runtime Environment (build 16-ea+30-2130) OpenJDK 64-Bit Server VM (build 16-ea+30-2130, mixed mode, sharing) > > Paul. > > On Dec 30, 2020, at 6:17 AM, Piotr Tarsa wrote: > > Hi all, > > Thanks for creating Project Panama! It looks promising. However, I've > made a try to vectorize some code and got somewhat disappointing > results. Therefore I wanted to look at the generated machine code to > see it it looks optimal. I've attached hsdis to JVM and enabled > assembly printing but the output doesn't make sense to me, i.e. the > instructions and comments / metadata don't seem to match. I may be > wrong as I've very rarely looked at assembly listing produced by JVM. > > Performance: > As a baseline I took > https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/mandelbrot-java-2.html > which takes about 3.05s to finish on my system. After vectorization > I've managed to achieve timings like 1.80s. That's quite disappointing > to me as I have a Haswell machine which has AVX2, high speed L1 > caches, etc I've tested on recent JDK 16 EA build from > http://jdk.java.net/16/ > > Link to the code and assembly listing: > https://gist.github.com/tarsa/7a9c80bb84c2dcd807be9cd16a655ee0 I'll > copy the source code again in this mail at the end. > > What I see in the assembly listings is e.g. > > 0x00007f0e208b8ab9: cmp r13d,0x7fffffc0 > 0x00007f0e208b8ac0: jg 0x00007f0e208b932c > 0x00007f0e208b8ac6: vmulpd ymm0,ymm6,ymm4 > 0x00007f0e208b8aca: vsubpd ymm1,ymm4,ymm4 > 0x00007f0e208b8ace: vmovdqu YMMWORD PTR [rsp+0xc0],ymm1 > 0x00007f0e208b8ad7: vmulpd ymm0,ymm0,ymm4 > ;*synchronization entry > ; - > jdk.internal.vm.vector.VectorSupport$VectorPayload::getPayload at -1 > (line 101) > ; - > jdk.incubator.vector.Double256Vector$Double256Mask::getBits at 1 (line > 557) > ; - > jdk.incubator.vector.AbstractMask::toLong at 24 (line 77) > ; - > mandelbrot_simd_1::computeChunksVector at 228 (line 187) > 0x00007f0e208b8adb: vaddpd ymm0,ymm0,ymm2 ;*checkcast > {reexecute=0 rethrow=0 return_oop=0} > ; - > jdk.incubator.vector.DoubleVector::fromArray0Template at 34 (line 3119) > ; - > jdk.incubator.vector.Double256Vector::fromArray0 at 3 (line 777) > ; - > jdk.incubator.vector.DoubleVector::fromArray at 24 (line 2564) > ; - > mandelbrot_simd_1::computeChunksVector at 95 (line 169) > 0x00007f0e208b8adf: vmovdqu YMMWORD PTR [rsp+0xe0],ymm0 > 0x00007f0e208b8ae8: vmulpd ymm0,ymm0,ymm0 > 0x00007f0e208b8aec: vmovdqu YMMWORD PTR [rsp+0x100],ymm0 > > How does vmulpd relate to a synchronization entry and > AbstrackMask::toLong? It seems way off to me. However, there maybe > some trick to understand it. Could you give me some guidelines on how > to intepret that? Are the comments describing lines below or above > them? > > Regards, > Piotr > > mandelbrot_simd_1.java source code: > import jdk.incubator.vector.DoubleVector; > import jdk.incubator.vector.VectorMask; > import jdk.incubator.vector.VectorSpecies; > > import java.io.BufferedOutputStream; > import java.io.IOException; > import java.io.OutputStream; > import java.nio.file.Files; > import java.nio.file.Path; > import java.util.concurrent.CountDownLatch; > import java.util.concurrent.ExecutorService; > import java.util.concurrent.Executors; > import java.util.concurrent.TimeUnit; > import java.util.stream.IntStream; > > public class mandelbrot_simd_1 { > private static final VectorSpecies SPECIES = > DoubleVector.SPECIES_PREFERRED.length() <= 8 ? > DoubleVector.SPECIES_PREFERRED : DoubleVector.SPECIES_512; > > private static final int LANES = SPECIES.length(); > > private static final int LANES_LOG = Integer.numberOfTrailingZeros(LANES); > > public static void main(String[] args) throws IOException { > if ((LANES > 8) || (LANES != (1 << LANES_LOG))) { > var errorMsg = "LANES must be a power of two and at most 8. " + > "Change SPECIES in the source code."; > throw new RuntimeException(errorMsg); > } > var sideLen = Integer.parseInt(args[0]); > try (var out = new BufferedOutputStream(makeOut1())) { > out.write(String.format("P4\n%d %d\n", sideLen, > sideLen).getBytes()); > computeAndOutputRows(out, sideLen); > } > } > > @SuppressWarnings("unused") > // the version that avoids mixing up output with JVM diagnostic messages > private static OutputStream makeOut1() throws IOException { > return Files.newOutputStream(Path.of("mandelbrot_simd_1.pbm")); > } > > // the version that is compatible with benchmark requirements > private static OutputStream makeOut2() { > return System.out; > } > > private static void computeAndOutputRows(OutputStream out, int sideLen) { > var poolFactor = 1000000 / sideLen; > if (poolFactor < 10) { > throw new RuntimeException("Too small poolFactor"); > } > var numCpus = Runtime.getRuntime().availableProcessors(); > var rowsPerBatch = numCpus * poolFactor; > var fac = 2.0 / sideLen; > var aCr = IntStream.range(0, sideLen).parallel() > .mapToDouble(x -> x * fac - 1.5).toArray(); > var bitsReversalMapping = computeBitsReversalMapping(); > var rowsPools = new byte[2][rowsPerBatch][(sideLen + 7) / 8]; > var rowsChunksPools = new long[2][rowsPerBatch][sideLen / 64]; > var batchSizes = new int[2]; > var batchCountDowns = new CountDownLatch[2]; > var computeEc = Executors.newWorkStealingPool(numCpus); > var masterThread = new Thread(() -> { > var rowsToProcess = sideLen; > var nextBatchStart = 0; > batchSizes[0] = 0; > batchCountDowns[0] = new CountDownLatch(0); > for (var poolId = 0; rowsToProcess > 0; poolId ^= 1) { > while (batchCountDowns[poolId].getCount() != 0) { > try { > batchCountDowns[poolId].await(); > } catch (InterruptedException ignored) { > } > } > batchCountDowns[poolId] = null; > > var nextBatchSize = > Math.min(sideLen - nextBatchStart, rowsPerBatch); > var nextPoolId = poolId ^ 1; > batchSizes[nextPoolId] = nextBatchSize; > batchCountDowns[nextPoolId] = new CountDownLatch(nextBatchSize); > sendTasks(fac, aCr, bitsReversalMapping, > rowsPools[nextPoolId], rowsChunksPools[nextPoolId], > nextBatchStart, nextBatchSize, > batchCountDowns[nextPoolId], computeEc); > nextBatchStart += nextBatchSize; > > var batchSize = batchSizes[poolId]; > try { > for (var rowIdx = 0; rowIdx < batchSize; rowIdx++) { > out.write(rowsPools[poolId][rowIdx]); > } > out.flush(); > } catch (IOException e) { > e.printStackTrace(); > System.exit(-1); > } > rowsToProcess -= batchSize; > } > > computeEc.shutdown(); > }); > masterThread.start(); > while (masterThread.isAlive() || !computeEc.isTerminated()) { > try { > @SuppressWarnings("unused") > var ignored = computeEc.awaitTermination(1, TimeUnit.DAYS); > masterThread.join(); > } catch (InterruptedException ignored) { > } > } > } > > private static void sendTasks(double fac, double[] aCr, > byte[] bitsReversalMapping, > byte[][] rows, long[][] rowsChunks, > int batchStart, int batchSize, > CountDownLatch poolsActiveWorkersCount, > ExecutorService computeEc) { > for (var i = 0; i < batchSize; i++) { > var indexInBatch = i; > var y = batchStart + i; > var Ci = y * fac - 1.0; > computeEc.submit(() -> { > try { > computeRow(Ci, aCr, bitsReversalMapping, > rows[indexInBatch], rowsChunks[indexInBatch]); > poolsActiveWorkersCount.countDown(); > } catch (Exception e) { > e.printStackTrace(); > System.exit(-1); > } > }); > } > } > > private static byte[] computeBitsReversalMapping() { > var bitsReversalMapping = new byte[256]; > for (var i = 0; i < 256; i++) { > bitsReversalMapping[i] = (byte) (Integer.reverse(i) >>> 24); > } > return bitsReversalMapping; > } > > private static void computeRow(double Ci, double[] aCr, > byte[] bitsReversalMapping, > byte[] row, long[] rowChunks) { > computeChunksVector(Ci, aCr, rowChunks); > transferRowFlags(rowChunks, row, bitsReversalMapping); > computeRemainderScalar(aCr, row, Ci); > } > > private static void computeChunksVector(double Ci, double[] aCr, > long[] rowChunks) { > var sideLen = aCr.length; > var vCi = DoubleVector.broadcast(SPECIES, Ci); > var vZeroes = DoubleVector.zero(SPECIES); > var vTwos = DoubleVector.broadcast(SPECIES, 2.0); > var vFours = DoubleVector.broadcast(SPECIES, 4.0); > var zeroMask = VectorMask.fromLong(SPECIES, 0); > // (1 << 6) = 64 = length of long in bits > for (var xBase = 0; xBase < (sideLen & ~(1 << 6)); xBase += (1 << 6)) { > var cmpFlags = 0L; > for (var xInc = 0; xInc < (1 << 6); xInc += LANES) { > var vZr = vZeroes; > var vZi = vZeroes; > var vCr = DoubleVector.fromArray(SPECIES, aCr, xBase + xInc); > var vZrN = vZeroes; > var vZiN = vZeroes; > var cmpMask = zeroMask; > for (var outer = 0; outer < 10; outer++) { > for (var inner = 0; inner < 5; inner++) { > vZi = vTwos.mul(vZr).mul(vZi).add(vCi); > vZr = vZrN.sub(vZiN).add(vCr); > vZiN = vZi.mul(vZi); > vZrN = vZr.mul(vZr); > } > cmpMask = cmpMask.or(vFours.lt(vZiN.add(vZrN))); > // in Rust version this works fine, so where's the bug then? > // cmpMask = vFours.lt(vZiN.add(vZrN)); > if (cmpMask.allTrue()) { > break; > } > } > cmpFlags |= cmpMask.toLong() << xInc; > } > rowChunks[xBase >> 6] = cmpFlags; > } > } > > private static void transferRowFlags(long[] rowChunks, byte[] row, > byte[] bitsReversalMapping) { > for (var i = 0; i < rowChunks.length; i++) { > var group = ~rowChunks[i]; > row[i * 8 + 7] = bitsReversalMapping[0xff & (byte) (group >>> 56)]; > row[i * 8 + 6] = bitsReversalMapping[0xff & (byte) (group >>> 48)]; > row[i * 8 + 5] = bitsReversalMapping[0xff & (byte) (group >>> 40)]; > row[i * 8 + 4] = bitsReversalMapping[0xff & (byte) (group >>> 32)]; > row[i * 8 + 3] = bitsReversalMapping[0xff & (byte) (group >>> 24)]; > row[i * 8 + 2] = bitsReversalMapping[0xff & (byte) (group >>> 16)]; > row[i * 8 + 1] = bitsReversalMapping[0xff & (byte) (group >>> 8)]; > row[i * 8] = bitsReversalMapping[0xff & (byte) group]; > } > } > > private static void computeRemainderScalar(double[] aCr, byte[] > row, double Ci) { > var sideLen = aCr.length; > var bits = 0; > for (var x = sideLen & ~(1 << 6); x < sideLen; x++) { > var Zr = 0.0; > var Zi = 0.0; > var Cr = aCr[x]; > var i = 50; > var ZrN = 0.0; > var ZiN = 0.0; > do { > Zi = 2.0 * Zr * Zi + Ci; > Zr = ZrN - ZiN + Cr; > ZiN = Zi * Zi; > ZrN = Zr * Zr; > } while (ZiN + ZrN <= 4.0 && --i > 0); > bits <<= 1; > bits += i == 0 ? 1 : 0; > if (x % 8 == 7) { > row[x / 8] = (byte) bits; > bits = 0; > } > } > if (sideLen % 8 != 0) { > row[sideLen / 8] = (byte) bits; > } > } > } > > From mcimadamore at openjdk.java.net Sat Jan 16 15:03:26 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Sat, 16 Jan 2021 15:03:26 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v2] In-Reply-To: <0rB3a3cVsVNJ-L9LhioxRjz1m-5ElRVTgdvxqNaiOPM=.e0295739-28a3-4756-836d-c48c4099e73d@github.com> References: <0rB3a3cVsVNJ-L9LhioxRjz1m-5ElRVTgdvxqNaiOPM=.e0295739-28a3-4756-836d-c48c4099e73d@github.com> Message-ID: On Sat, 16 Jan 2021 01:56:51 GMT, Radoslaw Smogura wrote: > Hi. I've added the benchmarks: > > * benchmarks used by me; > > * added a new benchmarks to `LoopOverNonConstant` to compare performance of this approach with existing methods for getting values. It's strange to see the performances of global segment to be worse than that of a regular segment? ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/437 From github.com+7535718+rsmogura at openjdk.java.net Sat Jan 16 15:08:52 2021 From: github.com+7535718+rsmogura at openjdk.java.net (Radoslaw Smogura) Date: Sat, 16 Jan 2021 15:08:52 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v2] In-Reply-To: References: <0rB3a3cVsVNJ-L9LhioxRjz1m-5ElRVTgdvxqNaiOPM=.e0295739-28a3-4756-836d-c48c4099e73d@github.com> Message-ID: On Sat, 16 Jan 2021 14:59:41 GMT, Maurizio Cimadamore wrote: > > Hi. I've added the benchmarks: > > > > > > * benchmarks used by me; > > > > > > * added a new benchmarks to `LoopOverNonConstant` to compare performance of this approach with existing methods for getting values. > > > > It's strange to see the performances of global segment to be worse than that of a regular segment? Indeed. I can't understand this (I'll make additional research). I suspect that's because the access is indexed (so global memory is treated as big array), or it's more about test itself - there's additional additions and we use longs instead of ints. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/437 From mcimadamore at openjdk.java.net Sat Jan 16 15:11:29 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Sat, 16 Jan 2021 15:11:29 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v2] In-Reply-To: References: <0rB3a3cVsVNJ-L9LhioxRjz1m-5ElRVTgdvxqNaiOPM=.e0295739-28a3-4756-836d-c48c4099e73d@github.com> Message-ID: On Sat, 16 Jan 2021 15:06:38 GMT, Radoslaw Smogura wrote: > > Hi. I've added the benchmarks: > > ``` > > * benchmarks used by me; > > > > * added a new benchmarks to `LoopOverNonConstant` to compare performance of this approach with existing methods for getting values. > > ``` > > It's strange to see the performances of global segment to be worse than that of a regular segment? Ah! I think I know what's happening here. In principle, the original implementation should have been just as good - but there's one issue: since the everything segment has length of Long.MAX_VALUE it is, by definition, not a SMALL segment - which means the internal optimizations that are aimed at working around the hotspot limitations around int vs. long loops will not work for the everything segment. That's why it was 2x slower. Your patch removes _some_ of these factors, but not _all_ of them. And I think the updates to LoopOverNonConstants are wrong - as you are essentially trying to use a strided VarHandle in an absolute way (see code comment). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/437 From mcimadamore at openjdk.java.net Sat Jan 16 15:34:06 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Sat, 16 Jan 2021 15:34:06 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v3] In-Reply-To: <9EfxwrBTtLQ49qhoPej98Ff7umUHJMgE0ljM7hSztPo=.a7678d80-a98a-4355-b085-a9f2e20ca912@github.com> References: <9EfxwrBTtLQ49qhoPej98Ff7umUHJMgE0ljM7hSztPo=.a7678d80-a98a-4355-b085-a9f2e20ca912@github.com> Message-ID: On Sat, 16 Jan 2021 02:08:55 GMT, Radoslaw Smogura wrote: >> This changes removes (by making no-ops) range and temporal checks for `ofNativeRestricted` segment. As this segment is global, above checks are not needed. >> >> Generated native code is smaller, and execution outperforms Java native arrays (depending on CPU) >> Changed >> Benchmark Mode Cnt Score Error Units >> AccessBenchmark.foreignAddress thrpt 5 128946129.691 ? 317433.113 ops/s >> AccessBenchmark.foreignAddressRaw thrpt 5 136883439.221 ? 749390.255 ops/s >> AccessBenchmark.target thrpt 5 125325586.957 ? 32129.931 ops/s >> Base >> Benchmark Mode Cnt Score Error Units >> AccessBenchmark.foreignAddress thrpt 5 125257424.876 ? 230508.169 ops/s >> AccessBenchmark.foreignAddressRaw thrpt 5 128818591.434 ? 241806.765 ops/s >> AccessBenchmark.target thrpt 5 125083379.819 ? 184070.467 ops/s >> --- >> This PR is replacement for https://github.com/openjdk/panama-foreign/pull/431 (OCA) >> and was partially discussed (before changes) in https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011747.htm >> >> --- >> Benchmark >> @State(Scope.Thread) >> public class AccessBenchmark { >> static final MemorySegment ms = MemorySegment.ofNativeRestricted(); >> static final VarHandle intHandle = MemoryHandles.varHandle(int.class, ByteOrder.nativeOrder()); >> >> int[] intData = new int[12]; >> volatile int intDataOffset = 0; >> >> volatile MemoryAddress address; >> volatile long addressRaw; >> >> @Setup >> public void setup() { >> var ms = MemorySegment.allocateNative(256); >> address = ms.address(); >> addressRaw = address.toRawLongValue(); >> } >> >> @Benchmark >> public void target(Blackhole bh) { >> int[] local = intData; >> int localOffset = intDataOffset; >> bh.consume(local[localOffset]); >> bh.consume(local[localOffset + 1]); >> } >> >> @Benchmark >> public void foreignAddress(Blackhole bh) { >> var a = address; >> bh.consume((int) intHandle.get(ms, a.addOffset(0).toRawLongValue())); >> bh.consume((int) intHandle.get(ms, a.addOffset(4).toRawLongValue())); >> } >> >> @Benchmark >> public void foreignAddressRaw(Blackhole bh) { >> var a = addressRaw; >> bh.consume((int) intHandle.get(ms, a)); >> bh.consume((int) intHandle.get(ms, a + 4)); >> } >> } > > Radoslaw Smogura has updated the pull request incrementally with one additional commit since the last revision: > > JMH Benchmarks for evaluation of `ofNativeRestricted` > > Original benchmark comparing performance of accessing > data using var handles vs ordinal arrays > > Modified existing benchmark `LoopOverNonConstant` to > see differences versus range / temporal checking & and non-checking segments. > > ``` > Benchmark Mode Cnt Score Error Units > LoopOverNonConstant.BB_get avgt 30 3.885 ? 0.003 ns/op > LoopOverNonConstant.BB_loop avgt 30 0.229 ? 0.001 ms/op > LoopOverNonConstant.global_segment_get avgt 30 3.663 ? 0.006 ns/op > LoopOverNonConstant.global_segment_loop avgt 30 0.374 ? 0.001 ms/op > LoopOverNonConstant.segment_get avgt 30 5.514 ? 0.023 ns/op > LoopOverNonConstant.segment_loop avgt 30 0.229 ? 0.001 ms/op > ``` > Not optimized `ofNativeRestricted` > ``` > LoopOverNonConstant.global_segment_get avgt 30 4.126 ? 0.006 ns/op > LoopOverNonConstant.global_segment_loop avgt 30 0.603 ? 0.001 ms/op > ``` test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstant.java line 65: > 63: static final MemorySegment globalRestrictedSegment = MemorySegment.ofNativeRestricted(); > 64: > 65: static final VarHandle VH_int = MemoryLayout.ofSequence(JAVA_INT).varHandle(int.class, sequenceElement()); This is a strided VarHandle - e.g. it takes a logical index (the sequence element index inside the segment) and it dereferences that element. So, you use it like this: VH_int.get(segment, 0); // first int element VH_int.get(segment, 1); // second int element (segment base address + 4) VH_int.get(segment, 2); // second int element (segment base address + 8) ... test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstant.java line 140: > 138: int res = 0; > 139: for (int i = 0; i < ELEM_SIZE; i ++) { > 140: res += (int) VH_int.get(globalRestrictedSegment, segment_addr_idx + i); This looks wrong. you are passing an absolute address to a "logical index" argument. I see that you are attempting to divide the segment address by the carrier size, and that kind offset things, but still leaves you with suboptimal performances. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/437 From mcimadamore at openjdk.java.net Sat Jan 16 15:34:22 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Sat, 16 Jan 2021 15:34:22 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v3] In-Reply-To: References: <9EfxwrBTtLQ49qhoPej98Ff7umUHJMgE0ljM7hSztPo=.a7678d80-a98a-4355-b085-a9f2e20ca912@github.com> Message-ID: On Sat, 16 Jan 2021 15:11:16 GMT, Maurizio Cimadamore wrote: >> Radoslaw Smogura has updated the pull request incrementally with one additional commit since the last revision: >> >> JMH Benchmarks for evaluation of `ofNativeRestricted` >> >> Original benchmark comparing performance of accessing >> data using var handles vs ordinal arrays >> >> Modified existing benchmark `LoopOverNonConstant` to >> see differences versus range / temporal checking & and non-checking segments. >> >> ``` >> Benchmark Mode Cnt Score Error Units >> LoopOverNonConstant.BB_get avgt 30 3.885 ? 0.003 ns/op >> LoopOverNonConstant.BB_loop avgt 30 0.229 ? 0.001 ms/op >> LoopOverNonConstant.global_segment_get avgt 30 3.663 ? 0.006 ns/op >> LoopOverNonConstant.global_segment_loop avgt 30 0.374 ? 0.001 ms/op >> LoopOverNonConstant.segment_get avgt 30 5.514 ? 0.023 ns/op >> LoopOverNonConstant.segment_loop avgt 30 0.229 ? 0.001 ms/op >> ``` >> Not optimized `ofNativeRestricted` >> ``` >> LoopOverNonConstant.global_segment_get avgt 30 4.126 ? 0.006 ns/op >> LoopOverNonConstant.global_segment_loop avgt 30 0.603 ? 0.001 ms/op >> ``` > > test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstant.java line 140: > >> 138: int res = 0; >> 139: for (int i = 0; i < ELEM_SIZE; i ++) { >> 140: res += (int) VH_int.get(globalRestrictedSegment, segment_addr_idx + i); > > This looks wrong. you are passing an absolute address to a "logical index" argument. I see that you are attempting to divide the segment address by the carrier size, and that kind offset things, but still leaves you with suboptimal performances. If you want to access memory this way, you need a different VarHandle: VarHandle absolute_int_VH = MemoryHandles.varHandle(int.class, ByteOrder.nativeOrder()); Or use one of the static accessors: MemoryAccess.getIntAtOffset(globalRestrictedSegment, segment_addr_idx + i); ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/437 From github.com+7535718+rsmogura at openjdk.java.net Sat Jan 16 20:38:37 2021 From: github.com+7535718+rsmogura at openjdk.java.net (Radoslaw Smogura) Date: Sat, 16 Jan 2021 20:38:37 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v2] In-Reply-To: References: <0rB3a3cVsVNJ-L9LhioxRjz1m-5ElRVTgdvxqNaiOPM=.e0295739-28a3-4756-836d-c48c4099e73d@github.com> Message-ID: On Sat, 16 Jan 2021 15:07:29 GMT, Maurizio Cimadamore wrote: > > > Hi. I've added the benchmarks: > > > ``` > > > * benchmarks used by me; > > > > > > * added a new benchmarks to `LoopOverNonConstant` to compare performance of this approach with existing methods for getting values. > > > ``` > > > > > > It's strange to see the performances of global segment to be worse than that of a regular segment? > > Ah! I think I know what's happening here. In principle, the original implementation should have been just as good - but there's one issue: since the everything segment has length of Long.MAX_VALUE it is, by definition, not a SMALL segment - which means the internal optimizations that are aimed at working around the hotspot limitations around int vs. long loops will not work for the everything segment. That's why it was 2x slower. Your patch removes _some_ of these factors, but not _all_ of them. And I think the updates to LoopOverNonConstants are wrong - as you are essentially trying to use a strided VarHandle in an absolute way (see code comment). > > Note that an indexed VarHandle will, internally, need to perform additions and multiplications - so if your segment is "big" these will be long additions and multiplications - which you will pay for (at least for the time being). > > Overall I'm hopeful that, by the time we fix the long vs. int optimization problem in hotspot, the code we have today should just get faster, without a real need for a global segment. Hi, That's interesting how changing just one type can introduce such a big performance results. I changed the access to `globalRestrictedSegment`. I completely agree previous version was a bit wired. I analyzed both methods, it looks like that (I'm not the expert), segment / int versions do loop unrolling 0x00007fbcd80c8220: add 0x0(%r13),%eax 0x00007fbcd80c8224: add 0x4(%r13),%eax 0x00007fbcd80c8228: add 0x8(%r13),%eax // Removed similar lines 0x00007fbcd80c8254: add 0x34(%r13),%eax 0x00007fbcd80c8258: add 0x38(%r13),%eax 0x00007fbcd80c825c: add 0x3c(%r13),%eax ;*iadd {reexecute=0 rethrow=0 return_oop=0} ; - org.openjdk.bench.jdk.incubator.foreign.LoopOverNonConstant::segment_loop at 23 (line 165) 0x00007fbcd80c8260: add $0x10,%ebx ;*iinc {reexecute=0 rethrow=0 return_oop=0} ; - org.openjdk.bench.jdk.incubator.foreign.LoopOverNonConstant::segment_loop at 25 (line 164) I could not find such optimization in case of global segment and long numbers. >From the other hand I have put together this PR and previous with Unsafe access, disabled alignment checks by settings alignment to 1, and global memory segment rocks. I added benchmark method to show performance of it. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/437 From github.com+7535718+rsmogura at openjdk.java.net Sat Jan 16 21:00:04 2021 From: github.com+7535718+rsmogura at openjdk.java.net (Radoslaw Smogura) Date: Sat, 16 Jan 2021 21:00:04 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v4] In-Reply-To: References: Message-ID: > This changes removes (by making no-ops) range and temporal checks for `ofNativeRestricted` segment. As this segment is global, above checks are not needed. > > Generated native code is smaller, and execution outperforms Java native arrays (depending on CPU) > Changed > Benchmark Mode Cnt Score Error Units > AccessBenchmark.foreignAddress thrpt 5 128946129.691 ? 317433.113 ops/s > AccessBenchmark.foreignAddressRaw thrpt 5 136883439.221 ? 749390.255 ops/s > AccessBenchmark.target thrpt 5 125325586.957 ? 32129.931 ops/s > Base > Benchmark Mode Cnt Score Error Units > AccessBenchmark.foreignAddress thrpt 5 125257424.876 ? 230508.169 ops/s > AccessBenchmark.foreignAddressRaw thrpt 5 128818591.434 ? 241806.765 ops/s > AccessBenchmark.target thrpt 5 125083379.819 ? 184070.467 ops/s > --- > This PR is replacement for https://github.com/openjdk/panama-foreign/pull/431 (OCA) > and was partially discussed (before changes) in https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011747.htm > > --- > Benchmark > @State(Scope.Thread) > public class AccessBenchmark { > static final MemorySegment ms = MemorySegment.ofNativeRestricted(); > static final VarHandle intHandle = MemoryHandles.varHandle(int.class, ByteOrder.nativeOrder()); > > int[] intData = new int[12]; > volatile int intDataOffset = 0; > > volatile MemoryAddress address; > volatile long addressRaw; > > @Setup > public void setup() { > var ms = MemorySegment.allocateNative(256); > address = ms.address(); > addressRaw = address.toRawLongValue(); > } > > @Benchmark > public void target(Blackhole bh) { > int[] local = intData; > int localOffset = intDataOffset; > bh.consume(local[localOffset]); > bh.consume(local[localOffset + 1]); > } > > @Benchmark > public void foreignAddress(Blackhole bh) { > var a = address; > bh.consume((int) intHandle.get(ms, a.addOffset(0).toRawLongValue())); > bh.consume((int) intHandle.get(ms, a.addOffset(4).toRawLongValue())); > } > > @Benchmark > public void foreignAddressRaw(Blackhole bh) { > var a = addressRaw; > bh.consume((int) intHandle.get(ms, a)); > bh.consume((int) intHandle.get(ms, a + 4)); > } > } Radoslaw Smogura has updated the pull request incrementally with one additional commit since the last revision: Replaced the stride access with normal VarHandle. Added no_align benchmakr, to compare preformance with alignments checks turned off. ``` Benchmark Mode Cnt Score Error Units LoopOverNonConstant.BB_get avgt 30 3.892 ? 0.012 ns/op LoopOverNonConstant.BB_loop avgt 30 0.230 ? 0.001 ms/op LoopOverNonConstant.global_segment_get avgt 30 3.887 ? 0.008 ns/op LoopOverNonConstant.global_segment_loop avgt 30 0.396 ? 0.002 ms/op LoopOverNonConstant.global_segment_loop_no_align avgt 30 0.247 ? 0.001 ms/op LoopOverNonConstant.segment_get avgt 30 5.489 ? 0.014 ns/op LoopOverNonConstant.segment_loop avgt 30 0.229 ? 0.001 ms/op LoopOverNonConstant.segment_loop_readonly avgt 30 0.236 ? 0.001 ms/op LoopOverNonConstant.segment_loop_slice avgt 30 0.241 ? 0.001 ms/op LoopOverNonConstant.segment_loop_static avgt 30 0.230 ? 0.001 ms/op LoopOverNonConstant.unsafe_get avgt 30 3.425 ? 0.006 ns/op LoopOverNonConstant.unsafe_loop avgt 30 0.230 ? 0.001 ms/op ``` Not optimized `ofNativeRestricted` ``` LoopOverNonConstant.global_segment_get avgt 30 4.126 ? 0.006 ns/op LoopOverNonConstant.global_segment_loop avgt 30 0.603 ? 0.001 ms/op ``` ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/437/files - new: https://git.openjdk.java.net/panama-foreign/pull/437/files/ee220f9d..a262b6d6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=437&range=03 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=437&range=02-03 Stats: 23 lines in 1 file changed: 14 ins; 3 del; 6 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/437.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/437/head:pull/437 PR: https://git.openjdk.java.net/panama-foreign/pull/437 From whuang at openjdk.java.net Mon Jan 18 03:24:02 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Mon, 18 Jan 2021 03:24:02 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE [v2] In-Reply-To: References: Message-ID: > This patch add cast nodes between interger types implementation for Arm SVE like "VectorCastB2X" "VectorCastI2X " "VectorCastS2X" "VectorCastL2X". Wang Huang has updated the pull request incrementally with one additional commit since the last revision: fix build bug on other archs caused by UseSVE > 0 ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/31/files - new: https://git.openjdk.java.net/panama-vector/pull/31/files/ddcff3e0..db8e148d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=31&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=31&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/panama-vector/pull/31.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/31/head:pull/31 PR: https://git.openjdk.java.net/panama-vector/pull/31 From whuang at openjdk.java.net Mon Jan 18 03:26:49 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Mon, 18 Jan 2021 03:26:49 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE [v2] In-Reply-To: References: Message-ID: <9MLkKDq8hyrczk15NAcsDnpmSgd9yj1D-gulnP1xym4=.7d4eb3dc-7b4e-4954-9a8d-ecd0257e7194@github.com> On Tue, 12 Jan 2021 07:57:44 GMT, Wang Huang wrote: >> src/hotspot/share/opto/vectorIntrinsics.cpp line 335: >> >>> 333: bool LibraryCallKit::inline_vector_shuffle_iota() { >>> 334: // TODO shuffle is not supported on SVE >>> 335: if (UseSVE > 0) { >> >> This is AArch64 only option, and should not be used in shared code. > > Thank you. I will wrap these codes with aarch64 macro in revised patch. We change this `UseSVE > 0` into `Matcher::supports_scalable_vector` in revised patch. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/31 From whuang at openjdk.java.net Mon Jan 18 07:02:58 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Mon, 18 Jan 2021 07:02:58 GMT Subject: [vectorIntrinsics] RFR: 8259604: Change the implementation of loadV_partial and storeV_partial in Aarch64-SVE backend Message-ID: Now, the implementation of `loadV_partial` is : mov $tmp1, 0 mov $tmp2, vector_length sve_whilelo $pTmp, $tmp1, $tmp2 sve_ldr $dst, $pTmp, $mem However, we can encode register `zr` in instruction `sve_whilelo` instead of getting from the first mov instruction. The new implementation is : mov $tmp, vector_length sve_whilelo $pTmp, zr, $tmp sve_ldr $dst, $pTmp, $mem >From this changing, we reduce a mov instruction and a temporary variable($tmp2 ). ------------- Commit messages: - 8259604: Change the implementation of loadV_partial and storeV_partial in Aarch64-SVE backend Changes: https://git.openjdk.java.net/panama-vector/pull/32/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=32&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259604 Stats: 36 lines in 2 files changed: 0 ins; 12 del; 24 mod Patch: https://git.openjdk.java.net/panama-vector/pull/32.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/32/head:pull/32 PR: https://git.openjdk.java.net/panama-vector/pull/32 From xgong at openjdk.java.net Mon Jan 18 09:12:50 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Mon, 18 Jan 2021 09:12:50 GMT Subject: [vectorIntrinsics] RFR: 8259604: Change the implementation of loadV_partial and storeV_partial in Aarch64-SVE backend In-Reply-To: References: Message-ID: <9r7CHgfoqHx6iwrhaIqyjbMtf3hmjfvnYpoMuGcliEE=.c1dbda17-c2bb-440b-8a53-026e7274864e@github.com> On Mon, 18 Jan 2021 06:55:48 GMT, Wang Huang wrote: > Now, the implementation of `loadV_partial` is : > mov $tmp1, 0 > mov $tmp2, vector_length > sve_whilelo $pTmp, $tmp1, $tmp2 > sve_ldr $dst, $pTmp, $mem > However, we can encode register `zr` in instruction `sve_whilelo` instead of getting from the first mov instruction. > > The new implementation is : > mov $tmp, vector_length > sve_whilelo $pTmp, zr, $tmp > sve_ldr $dst, $pTmp, $mem > From this changing, we reduce a mov instruction and a temporary variable($tmp2 ). LGTM, thanks! ------------- PR: https://git.openjdk.java.net/panama-vector/pull/32 From xgong at openjdk.java.net Mon Jan 18 09:39:52 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Mon, 18 Jan 2021 09:39:52 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 03:13:31 GMT, Wang Huang wrote: > This patch add cast nodes between interger types implementation for Arm SVE like "VectorCastB2X" "VectorCastI2X " "VectorCastS2X" "VectorCastL2X". Hi @Wanghuang-Huawei, thanks for adding the SVE support for VectorCast. I observed that this patch misses some type casts like: `byte -> long`, `short -> long`, `long -> byte` and `long -> short`. Do you have any plan to add these missing parts in future? I'd suggest to add them all with the single patch. WDYT? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/31 From xgong at openjdk.java.net Mon Jan 18 09:42:55 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Mon, 18 Jan 2021 09:42:55 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE [v2] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 03:24:02 GMT, Wang Huang wrote: >> This patch add cast nodes between interger types implementation for Arm SVE like "VectorCastB2X" "VectorCastI2X " "VectorCastS2X" "VectorCastL2X". > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix build bug on other archs caused by UseSVE > 0 src/hotspot/share/opto/vectorIntrinsics.cpp line 338: > 336: if (C->print_intrinsics()) { > 337: tty->print_cr(" ** shuffle iota not supported on SVE"); > 338: } I guess these parts will be removed in future if shuffle is supported with SVE. Could you please add some comments for it? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/31 From mcimadamore at openjdk.java.net Mon Jan 18 10:59:50 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 18 Jan 2021 10:59:50 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v2] In-Reply-To: References: <0rB3a3cVsVNJ-L9LhioxRjz1m-5ElRVTgdvxqNaiOPM=.e0295739-28a3-4756-836d-c48c4099e73d@github.com> Message-ID: On Sat, 16 Jan 2021 20:36:05 GMT, Radoslaw Smogura wrote: > could not find such optimization in case of global segment and long numbers. The optimization happens on segment construction - if the segment size is < Integer.MAX_VALUE, the AbstractMemorySegment::defaultAccessMode method appends the SMALL flag to the set of segment flags. This flag is then consulted many times, typically before long addition/multiplications have to be performed. > > From the other hand I have put together this PR and previous with Unsafe access, disabled alignment checks by settings alignment to 1, and global memory segment rocks. I added benchmark method to show performance of it. Alignment check is an outstanding issue for the API - hotspot doesn't optimize those very well. See also: https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011794.html ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/437 From mcimadamore at openjdk.java.net Mon Jan 18 10:59:50 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 18 Jan 2021 10:59:50 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v2] In-Reply-To: References: <0rB3a3cVsVNJ-L9LhioxRjz1m-5ElRVTgdvxqNaiOPM=.e0295739-28a3-4756-836d-c48c4099e73d@github.com> Message-ID: On Mon, 18 Jan 2021 10:54:42 GMT, Maurizio Cimadamore wrote: >>> > > Hi. I've added the benchmarks: >>> > > ``` >>> > > * benchmarks used by me; >>> > > >>> > > * added a new benchmarks to `LoopOverNonConstant` to compare performance of this approach with existing methods for getting values. >>> > > ``` >>> > >>> > >>> > It's strange to see the performances of global segment to be worse than that of a regular segment? >>> >>> Ah! I think I know what's happening here. In principle, the original implementation should have been just as good - but there's one issue: since the everything segment has length of Long.MAX_VALUE it is, by definition, not a SMALL segment - which means the internal optimizations that are aimed at working around the hotspot limitations around int vs. long loops will not work for the everything segment. That's why it was 2x slower. Your patch removes _some_ of these factors, but not _all_ of them. And I think the updates to LoopOverNonConstants are wrong - as you are essentially trying to use a strided VarHandle in an absolute way (see code comment). >>> >>> Note that an indexed VarHandle will, internally, need to perform additions and multiplications - so if your segment is "big" these will be long additions and multiplications - which you will pay for (at least for the time being). >>> >>> Overall I'm hopeful that, by the time we fix the long vs. int optimization problem in hotspot, the code we have today should just get faster, without a real need for a global segment. >> >> Hi, >> >> That's interesting how changing just one type can introduce such a big performance results. >> >> I changed the access to `globalRestrictedSegment`. I completely agree previous version was a bit wired. >> >> I analyzed both methods, it looks like that (I'm not the expert), segment / int versions do loop unrolling >> 0x00007fbcd80c8220: add 0x0(%r13),%eax >> 0x00007fbcd80c8224: add 0x4(%r13),%eax >> 0x00007fbcd80c8228: add 0x8(%r13),%eax >> // Removed similar lines >> 0x00007fbcd80c8254: add 0x34(%r13),%eax >> 0x00007fbcd80c8258: add 0x38(%r13),%eax >> 0x00007fbcd80c825c: add 0x3c(%r13),%eax ;*iadd {reexecute=0 rethrow=0 return_oop=0} >> ; - org.openjdk.bench.jdk.incubator.foreign.LoopOverNonConstant::segment_loop at 23 (line 165) >> 0x00007fbcd80c8260: add $0x10,%ebx ;*iinc {reexecute=0 rethrow=0 return_oop=0} >> ; - org.openjdk.bench.jdk.incubator.foreign.LoopOverNonConstant::segment_loop at 25 (line 164) >> I could not find such optimization in case of global segment and long numbers. >> >> From the other hand I have put together this PR and previous with Unsafe access, disabled alignment checks by settings alignment to 1, and global memory segment rocks. I added benchmark method to show performance of it. > >> could not find such optimization in case of global segment and long numbers. > > The optimization happens on segment construction - if the segment size is < Integer.MAX_VALUE, the AbstractMemorySegment::defaultAccessMode method appends the SMALL flag to the set of segment flags. This flag is then consulted many times, typically before long addition/multiplications have to be performed. >> >> From the other hand I have put together this PR and previous with Unsafe access, disabled alignment checks by settings alignment to 1, and global memory segment rocks. I added benchmark method to show performance of it. > > Alignment check is an outstanding issue for the API - hotspot doesn't optimize those very well. See also: > > https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011794.html Would you mind pasting the benchmark results before/after the patch, now that the benchmark has been fixed? Thanks! ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/437 From github.com+7535718+rsmogura at openjdk.java.net Mon Jan 18 21:45:55 2021 From: github.com+7535718+rsmogura at openjdk.java.net (Radoslaw Smogura) Date: Mon, 18 Jan 2021 21:45:55 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v2] In-Reply-To: References: <0rB3a3cVsVNJ-L9LhioxRjz1m-5ElRVTgdvxqNaiOPM=.e0295739-28a3-4756-836d-c48c4099e73d@github.com> Message-ID: On Mon, 18 Jan 2021 10:57:19 GMT, Maurizio Cimadamore wrote: >>> could not find such optimization in case of global segment and long numbers. >> >> The optimization happens on segment construction - if the segment size is < Integer.MAX_VALUE, the AbstractMemorySegment::defaultAccessMode method appends the SMALL flag to the set of segment flags. This flag is then consulted many times, typically before long addition/multiplications have to be performed. >>> >>> From the other hand I have put together this PR and previous with Unsafe access, disabled alignment checks by settings alignment to 1, and global memory segment rocks. I added benchmark method to show performance of it. >> >> Alignment check is an outstanding issue for the API - hotspot doesn't optimize those very well. See also: >> >> https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011794.html > > Would you mind pasting the benchmark results before/after the patch, now that the benchmark has been fixed? Thanks! After patch Benchmark Mode Cnt Score Error Units LoopOverNonConstant.BB_get avgt 30 3.915 ? 0.012 ns/op LoopOverNonConstant.BB_loop avgt 30 0.230 ? 0.001 ms/op LoopOverNonConstant.global_segment_get avgt 30 3.878 ? 0.001 ns/op LoopOverNonConstant.global_segment_loop avgt 30 0.400 ? 0.002 ms/op LoopOverNonConstant.global_segment_loop_no_align avgt 30 0.248 ? 0.001 ms/op LoopOverNonConstant.segment_get avgt 30 5.497 ? 0.015 ns/op LoopOverNonConstant.segment_loop avgt 30 0.229 ? 0.001 ms/op LoopOverNonConstant.segment_loop_readonly avgt 30 0.239 ? 0.001 ms/op LoopOverNonConstant.segment_loop_slice avgt 30 0.241 ? 0.001 ms/op LoopOverNonConstant.segment_loop_static avgt 30 0.229 ? 0.001 ms/op LoopOverNonConstant.unsafe_get avgt 30 3.434 ? 0.006 ns/op LoopOverNonConstant.unsafe_loop avgt 30 0.229 ? 0.001 ms/op before patch Benchmark Mode Cnt Score Error Units LoopOverNonConstant.BB_get avgt 30 3.906 ? 0.012 ns/op LoopOverNonConstant.BB_loop avgt 30 0.231 ? 0.001 ms/op LoopOverNonConstant.global_segment_get avgt 30 4.125 ? 0.012 ns/op LoopOverNonConstant.global_segment_loop avgt 30 0.596 ? 0.004 ms/op LoopOverNonConstant.global_segment_loop_no_align avgt 30 0.489 ? 0.002 ms/op LoopOverNonConstant.segment_get avgt 30 5.507 ? 0.017 ns/op LoopOverNonConstant.segment_loop avgt 30 0.231 ? 0.001 ms/op LoopOverNonConstant.segment_loop_readonly avgt 30 0.238 ? 0.001 ms/op LoopOverNonConstant.segment_loop_slice avgt 30 0.242 ? 0.001 ms/op LoopOverNonConstant.segment_loop_static avgt 30 0.230 ? 0.001 ms/op LoopOverNonConstant.unsafe_get avgt 30 3.442 ? 0.008 ns/op LoopOverNonConstant.unsafe_loop avgt 30 0.230 ? 0.001 ms/op ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/437 From github.com+7535718+rsmogura at openjdk.java.net Mon Jan 18 22:33:49 2021 From: github.com+7535718+rsmogura at openjdk.java.net (Radoslaw Smogura) Date: Mon, 18 Jan 2021 22:33:49 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v2] In-Reply-To: References: <0rB3a3cVsVNJ-L9LhioxRjz1m-5ElRVTgdvxqNaiOPM=.e0295739-28a3-4756-836d-c48c4099e73d@github.com> Message-ID: On Mon, 18 Jan 2021 21:43:23 GMT, Radoslaw Smogura wrote: >> Would you mind pasting the benchmark results before/after the patch, now that the benchmark has been fixed? Thanks! > > After patch > Benchmark Mode Cnt Score Error Units > LoopOverNonConstant.BB_get avgt 30 3.915 ? 0.012 ns/op > LoopOverNonConstant.BB_loop avgt 30 0.230 ? 0.001 ms/op > LoopOverNonConstant.global_segment_get avgt 30 3.878 ? 0.001 ns/op > LoopOverNonConstant.global_segment_loop avgt 30 0.400 ? 0.002 ms/op > LoopOverNonConstant.global_segment_loop_no_align avgt 30 0.248 ? 0.001 ms/op > LoopOverNonConstant.segment_get avgt 30 5.497 ? 0.015 ns/op > LoopOverNonConstant.segment_loop avgt 30 0.229 ? 0.001 ms/op > LoopOverNonConstant.segment_loop_readonly avgt 30 0.239 ? 0.001 ms/op > LoopOverNonConstant.segment_loop_slice avgt 30 0.241 ? 0.001 ms/op > LoopOverNonConstant.segment_loop_static avgt 30 0.229 ? 0.001 ms/op > LoopOverNonConstant.unsafe_get avgt 30 3.434 ? 0.006 ns/op > LoopOverNonConstant.unsafe_loop avgt 30 0.229 ? 0.001 ms/op > before patch > Benchmark Mode Cnt Score Error Units > LoopOverNonConstant.BB_get avgt 30 3.906 ? 0.012 ns/op > LoopOverNonConstant.BB_loop avgt 30 0.231 ? 0.001 ms/op > LoopOverNonConstant.global_segment_get avgt 30 4.125 ? 0.012 ns/op > LoopOverNonConstant.global_segment_loop avgt 30 0.596 ? 0.004 ms/op > LoopOverNonConstant.global_segment_loop_no_align avgt 30 0.489 ? 0.002 ms/op > LoopOverNonConstant.segment_get avgt 30 5.507 ? 0.017 ns/op > LoopOverNonConstant.segment_loop avgt 30 0.231 ? 0.001 ms/op > LoopOverNonConstant.segment_loop_readonly avgt 30 0.238 ? 0.001 ms/op > LoopOverNonConstant.segment_loop_slice avgt 30 0.242 ? 0.001 ms/op > LoopOverNonConstant.segment_loop_static avgt 30 0.230 ? 0.001 ms/op > LoopOverNonConstant.unsafe_get avgt 30 3.442 ? 0.008 ns/op > LoopOverNonConstant.unsafe_loop avgt 30 0.230 ? 0.001 ms/op Hi Maurizio, I added benchmarks, in previous comment. If you would like more, please let me know! Have a great day, Rado ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/437 From paul.sandoz at oracle.com Tue Jan 19 20:17:09 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 19 Jan 2021 20:17:09 +0000 Subject: Comments / metadata in assembly listings don't make sense for code vectorized using Vector API In-Reply-To: References: Message-ID: Hi Piotr, Thanks for further sharing. I am glad you managed to make progress. I was not aware there were some benchmark rules you needed to adhere to. Re: masks, yes there is still work to do for some mask operations. Re: execution from the command line. You can run with -XX:-TieredCompilation (Remi, thanks for the correction in the prior email :-) ), and it's also possible reduce the compilation threshold (at the expense of potentially less accurate profiling information) using say -XX:CompileThreshold=1000 (the default is 10000). It?s always a bit tricky to compare a static (Rust) vs. dynamic system that needs to warm up. Paul. On Jan 16, 2021, at 4:12 AM, Piotr Tarsa > wrote: Hi Paul, Thanks for replying. As per your advice I've prepared JMH benchmarks. Also I've copied some optimizations from other mandelbrot benchmark implementations and achieved further speedup. New version is here: https://urldefense.com/v3/__https://gist.github.com/tarsa/7a9c80bb84c2dcd807be9cd16a655ee0/4ced690e20ad561515094995a852adc95820955e__;!!GqivPVa7Brio!PPG_y5O-1X6iaHMBpRFVBkTI7zM4hvwD-CWKID54DAHe_q47jEN4GoDyUO8MCOGPNQ$ It also has simplified buffer management and multithreading, so there's less boilerplate. Results from JMH are quite good (a bit reordered for clarity): # Run complete. Total time: 00:16:42 Benchmark Mode Cnt Score Error Units benchRowMT thrpt 5 17755,337 ? 279,118 ops/s benchRowST thrpt 5 4535,280 ? 7,471 ops/s benchScalarPairsMT thrpt 5 4583,354 ? 89,532 ops/s benchScalarPairsST thrpt 5 1163,925 ? 0,469 ops/s benchScalarMT thrpt 5 2666,210 ? 5,004 ops/s benchScalarST thrpt 5 673,234 ? 0,167 ops/s benchVectorMT thrpt 5 18020,397 ? 54,230 ops/s benchVectorST thrpt 5 4567,873 ? 10,339 ops/s benchVectorWithTransfer thrpt 5 4557,361 ? 9,450 ops/s benchScalarRemainderOnly thrpt 5 7105989,167 ? 4691,311 ops/s The mandelbrot Java #2 is named here benchScalarPairsMT (it's manually unrolled x2). My new vectorized version (similarly manually unrolled) is benchVectorMT and it has about 4x higher performance which is quite good. However when I run the benchmark from command line (in non-JMH mode) to replicate the benchmark rules then there is much smaller performance difference. Mandelbrot Java #2 (the unvectorized one) takes about 3s, while my one takes about 1.2s - 1.3s and sometimes fluctuated up to about 1.5s. It seems that compilation takes up a lot of benchmark time. Is it possible to reduce compilation times for code using Vector API? wt., 5 sty 2021 o 00:11 Paul Sandoz > napisa?(a): Hi Piotr, Thanks for experimenting. The Intel folks have also experimented with Mandelbrot generation and might be able to comment with their experience in comparison. I would be interested to know what your expectations were with regards to speedup. I've expected more than 2x speedup vs the scalar version as I have 256-bit SIMD on my Haswell machine. Luckily, I've managed to achieve it as I've written at the beginning. It?s hard to evaluate without a JMH benchmark which can more easily present the code hotspots and isolate from the other areas, such as for thread parallelism. My recommendation would be to extract out the computeChunksVector kernel and embed within such a benchmark. Switching off tired compilation should help (-XX:-TiredCompilation) i.e. only C2, not C1, in getting to the C2 generated code faster. Good point. I've made a JMH benchmark (that I've presented at the beginning) and saw where are inefficiences. To your question about the assembly listing I believe as HotSpot goes through various compiler passes it tries to preserve the byte code index associated with generated instructions, but naturally as code is lowered this becomes an approximation, and especially so with the Vector API. Hmmm, it's sad that it's only approximation. In the case of "*synchronization entry?, this is stating the pseudo byte code index just before a method is entered. However, I think there is tech debt here, see https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/debugInfoRec.hpp*L67__;Iw!!GqivPVa7Brio!PPG_y5O-1X6iaHMBpRFVBkTI7zM4hvwD-CWKID54DAHe_q47jEN4GoDyUO-g6St52w$ And the usages of SynchronizationEntryBCI in hotspot code. Running in fast debug mode will present a slightly higher-level view of generated code. Here?s a snippet: 26e vmulpd XMM12,XMM7,XMM7 ! mul packedD 272 vaddpd XMM8,XMM0,XMM11 ! add packedD 277 vmulpd XMM9,XMM8,XMM8 ! mul packedD 27c vaddpd XMM0,XMM12,XMM9 ! add packedD 281 vector_compare XMM10,XMM5,XMM0,#3 ! 286 # TLS is in R15 286 cmpq RCX, [R15 + #344 (32-bit)] # raw ptr 28d jnb,u B47 P=0.000100 C=-1.000000 ? 2cf vmovdqu [rsp + 64],XMM1 # spill 2d5 B25: # out( B44 B26 ) <- in( B48 B24 ) Freq: 9114.56 2d5 2d5 # checkcastPP of RAX 2d5 vector_store_mask XMM1,XMM10 ! using XMM13 as TEMP 2f4 vector_loadmask_byte XMM15,XMM1 302 vmovdqu XMM1,[rsp + 448] # spill 30b vpor XMM1,XMM1,XMM15 ! or vectors 310 vector_store_mask XMM0,XMM1 ! using XMM14 as TEMP 32e store_vector [RAX + #16 (8-bit)],XMM0 333 vector_test RCX,XMM1, XMM2 ! using RFLAGS as TEMP nop # 2 bytes pad for loops and calls 340 testl RCX, RCX 342 je B44 P=0.108889 C=184362.000000 The mask instructions, such as vector_store_mask, are substituted for a more complex sequence of x86 instructions on AVX 2. Thanks. For now the speedup in JMH is good enough for me, so I won't dig into assembly code, but I'll consider fastdebug Java build when I explore assembly next time. I do notice that the inner loop (upper bound of 5) does unroll (FWIW, making the inner bound a power of 2 is more friendly for unrolling). There also appears to be many register spills, suggesting non-optimal vector register allocation/usage by C2. I've tried factor of 4, but that didn't improve performance. I think it even made it worse as 50 is not a multiply of 4 and benchmark rules dictates that there must be exactly 50 iterations so I needed to make additional code for 50 % 4 = 2 extra iterations. That probably made code compilation even longer and worsen benchmark execution time. Instead of unrolling the inner loops, I've duplicated all vectors (i.e. unrolled the chunk-level loop, instead of the inner iteration level loop), so I was working on 256-bit / 64-bit * 2 = 8 results at a time. That worked well, similarly to mandelbrot Java #2. I noticed this in the code: // in Rust version this works fine, so where's the bug then? // cmpMask = vFours.lt(vZiN.add(vZrN)); What problem did you encounter? It works for me on the tip of https://urldefense.com/v3/__https://github.com/openjdk/jdk__;!!GqivPVa7Brio!PPG_y5O-1X6iaHMBpRFVBkTI7zM4hvwD-CWKID54DAHe_q47jEN4GoDyUO80IYo13A$ . The results were different, but benchmark dictates that the output must be bit-to-bit identical to correct output. I've nailed it down. It's because of numeric overflows causing numbers to go to Double.Infinity and then subtracting Infinity from Infinity results in Double.NaN and then comparisons are always false. Anyway, I've tried to make a version without `cmpMask = cmpMask.or(newValue)` and made a correct version, but that turned out to be slower. Perhaps some of the mask operations are not intrinsified yet or something. Rust was doing the comparisons a little bit differently, properly accounting for NaNs. All tests were done on: openjdk 16-ea 2021-03-16 OpenJDK Runtime Environment (build 16-ea+30-2130) OpenJDK 64-Bit Server VM (build 16-ea+30-2130, mixed mode, sharing) Paul. On Dec 30, 2020, at 6:17 AM, Piotr Tarsa > wrote: Hi all, Thanks for creating Project Panama! It looks promising. However, I've made a try to vectorize some code and got somewhat disappointing results. Therefore I wanted to look at the generated machine code to see it it looks optimal. I've attached hsdis to JVM and enabled assembly printing but the output doesn't make sense to me, i.e. the instructions and comments / metadata don't seem to match. I may be wrong as I've very rarely looked at assembly listing produced by JVM. Performance: As a baseline I took https://urldefense.com/v3/__https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/mandelbrot-java-2.html__;!!GqivPVa7Brio!PPG_y5O-1X6iaHMBpRFVBkTI7zM4hvwD-CWKID54DAHe_q47jEN4GoDyUO9Hidpnxg$ which takes about 3.05s to finish on my system. After vectorization I've managed to achieve timings like 1.80s. That's quite disappointing to me as I have a Haswell machine which has AVX2, high speed L1 caches, etc I've tested on recent JDK 16 EA build from https://urldefense.com/v3/__http://jdk.java.net/16/__;!!GqivPVa7Brio!PPG_y5O-1X6iaHMBpRFVBkTI7zM4hvwD-CWKID54DAHe_q47jEN4GoDyUO8eAZxJgQ$ Link to the code and assembly listing: https://urldefense.com/v3/__https://gist.github.com/tarsa/7a9c80bb84c2dcd807be9cd16a655ee0__;!!GqivPVa7Brio!PPG_y5O-1X6iaHMBpRFVBkTI7zM4hvwD-CWKID54DAHe_q47jEN4GoDyUO9lqtRFkA$ I'll copy the source code again in this mail at the end. What I see in the assembly listings is e.g. 0x00007f0e208b8ab9: cmp r13d,0x7fffffc0 0x00007f0e208b8ac0: jg 0x00007f0e208b932c 0x00007f0e208b8ac6: vmulpd ymm0,ymm6,ymm4 0x00007f0e208b8aca: vsubpd ymm1,ymm4,ymm4 0x00007f0e208b8ace: vmovdqu YMMWORD PTR [rsp+0xc0],ymm1 0x00007f0e208b8ad7: vmulpd ymm0,ymm0,ymm4 ;*synchronization entry ; - jdk.internal.vm.vector.VectorSupport$VectorPayload::getPayload at -1 (line 101) ; - jdk.incubator.vector.Double256Vector$Double256Mask::getBits at 1 (line 557) ; - jdk.incubator.vector.AbstractMask::toLong at 24 (line 77) ; - mandelbrot_simd_1::computeChunksVector at 228 (line 187) 0x00007f0e208b8adb: vaddpd ymm0,ymm0,ymm2 ;*checkcast {reexecute=0 rethrow=0 return_oop=0} ; - jdk.incubator.vector.DoubleVector::fromArray0Template at 34 (line 3119) ; - jdk.incubator.vector.Double256Vector::fromArray0 at 3 (line 777) ; - jdk.incubator.vector.DoubleVector::fromArray at 24 (line 2564) ; - mandelbrot_simd_1::computeChunksVector at 95 (line 169) 0x00007f0e208b8adf: vmovdqu YMMWORD PTR [rsp+0xe0],ymm0 0x00007f0e208b8ae8: vmulpd ymm0,ymm0,ymm0 0x00007f0e208b8aec: vmovdqu YMMWORD PTR [rsp+0x100],ymm0 How does vmulpd relate to a synchronization entry and AbstrackMask::toLong? It seems way off to me. However, there maybe some trick to understand it. Could you give me some guidelines on how to intepret that? Are the comments describing lines below or above them? Regards, Piotr mandelbrot_simd_1.java source code: import jdk.incubator.vector.DoubleVector; import jdk.incubator.vector.VectorMask; import jdk.incubator.vector.VectorSpecies; import java.io.BufferedOutputStream; import java.io.IOException; import java.io.OutputStream; import java.nio.file.Files; import java.nio.file.Path; import java.util.concurrent.CountDownLatch; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.TimeUnit; import java.util.stream.IntStream; public class mandelbrot_simd_1 { private static final VectorSpecies SPECIES = DoubleVector.SPECIES_PREFERRED.length() <= 8 ? DoubleVector.SPECIES_PREFERRED : DoubleVector.SPECIES_512; private static final int LANES = SPECIES.length(); private static final int LANES_LOG = Integer.numberOfTrailingZeros(LANES); public static void main(String[] args) throws IOException { if ((LANES > 8) || (LANES != (1 << LANES_LOG))) { var errorMsg = "LANES must be a power of two and at most 8. " + "Change SPECIES in the source code."; throw new RuntimeException(errorMsg); } var sideLen = Integer.parseInt(args[0]); try (var out = new BufferedOutputStream(makeOut1())) { out.write(String.format("P4\n%d %d\n", sideLen, sideLen).getBytes()); computeAndOutputRows(out, sideLen); } } @SuppressWarnings("unused") // the version that avoids mixing up output with JVM diagnostic messages private static OutputStream makeOut1() throws IOException { return Files.newOutputStream(Path.of("mandelbrot_simd_1.pbm")); } // the version that is compatible with benchmark requirements private static OutputStream makeOut2() { return System.out; } private static void computeAndOutputRows(OutputStream out, int sideLen) { var poolFactor = 1000000 / sideLen; if (poolFactor < 10) { throw new RuntimeException("Too small poolFactor"); } var numCpus = Runtime.getRuntime().availableProcessors(); var rowsPerBatch = numCpus * poolFactor; var fac = 2.0 / sideLen; var aCr = IntStream.range(0, sideLen).parallel() .mapToDouble(x -> x * fac - 1.5).toArray(); var bitsReversalMapping = computeBitsReversalMapping(); var rowsPools = new byte[2][rowsPerBatch][(sideLen + 7) / 8]; var rowsChunksPools = new long[2][rowsPerBatch][sideLen / 64]; var batchSizes = new int[2]; var batchCountDowns = new CountDownLatch[2]; var computeEc = Executors.newWorkStealingPool(numCpus); var masterThread = new Thread(() -> { var rowsToProcess = sideLen; var nextBatchStart = 0; batchSizes[0] = 0; batchCountDowns[0] = new CountDownLatch(0); for (var poolId = 0; rowsToProcess > 0; poolId ^= 1) { while (batchCountDowns[poolId].getCount() != 0) { try { batchCountDowns[poolId].await(); } catch (InterruptedException ignored) { } } batchCountDowns[poolId] = null; var nextBatchSize = Math.min(sideLen - nextBatchStart, rowsPerBatch); var nextPoolId = poolId ^ 1; batchSizes[nextPoolId] = nextBatchSize; batchCountDowns[nextPoolId] = new CountDownLatch(nextBatchSize); sendTasks(fac, aCr, bitsReversalMapping, rowsPools[nextPoolId], rowsChunksPools[nextPoolId], nextBatchStart, nextBatchSize, batchCountDowns[nextPoolId], computeEc); nextBatchStart += nextBatchSize; var batchSize = batchSizes[poolId]; try { for (var rowIdx = 0; rowIdx < batchSize; rowIdx++) { out.write(rowsPools[poolId][rowIdx]); } out.flush(); } catch (IOException e) { e.printStackTrace(); System.exit(-1); } rowsToProcess -= batchSize; } computeEc.shutdown(); }); masterThread.start(); while (masterThread.isAlive() || !computeEc.isTerminated()) { try { @SuppressWarnings("unused") var ignored = computeEc.awaitTermination(1, TimeUnit.DAYS); masterThread.join(); } catch (InterruptedException ignored) { } } } private static void sendTasks(double fac, double[] aCr, byte[] bitsReversalMapping, byte[][] rows, long[][] rowsChunks, int batchStart, int batchSize, CountDownLatch poolsActiveWorkersCount, ExecutorService computeEc) { for (var i = 0; i < batchSize; i++) { var indexInBatch = i; var y = batchStart + i; var Ci = y * fac - 1.0; computeEc.submit(() -> { try { computeRow(Ci, aCr, bitsReversalMapping, rows[indexInBatch], rowsChunks[indexInBatch]); poolsActiveWorkersCount.countDown(); } catch (Exception e) { e.printStackTrace(); System.exit(-1); } }); } } private static byte[] computeBitsReversalMapping() { var bitsReversalMapping = new byte[256]; for (var i = 0; i < 256; i++) { bitsReversalMapping[i] = (byte) (Integer.reverse(i) >>> 24); } return bitsReversalMapping; } private static void computeRow(double Ci, double[] aCr, byte[] bitsReversalMapping, byte[] row, long[] rowChunks) { computeChunksVector(Ci, aCr, rowChunks); transferRowFlags(rowChunks, row, bitsReversalMapping); computeRemainderScalar(aCr, row, Ci); } private static void computeChunksVector(double Ci, double[] aCr, long[] rowChunks) { var sideLen = aCr.length; var vCi = DoubleVector.broadcast(SPECIES, Ci); var vZeroes = DoubleVector.zero(SPECIES); var vTwos = DoubleVector.broadcast(SPECIES, 2.0); var vFours = DoubleVector.broadcast(SPECIES, 4.0); var zeroMask = VectorMask.fromLong(SPECIES, 0); // (1 << 6) = 64 = length of long in bits for (var xBase = 0; xBase < (sideLen & ~(1 << 6)); xBase += (1 << 6)) { var cmpFlags = 0L; for (var xInc = 0; xInc < (1 << 6); xInc += LANES) { var vZr = vZeroes; var vZi = vZeroes; var vCr = DoubleVector.fromArray(SPECIES, aCr, xBase + xInc); var vZrN = vZeroes; var vZiN = vZeroes; var cmpMask = zeroMask; for (var outer = 0; outer < 10; outer++) { for (var inner = 0; inner < 5; inner++) { vZi = vTwos.mul(vZr).mul(vZi).add(vCi); vZr = vZrN.sub(vZiN).add(vCr); vZiN = vZi.mul(vZi); vZrN = vZr.mul(vZr); } cmpMask = cmpMask.or(vFours.lt(vZiN.add(vZrN))); // in Rust version this works fine, so where's the bug then? // cmpMask = vFours.lt(vZiN.add(vZrN)); if (cmpMask.allTrue()) { break; } } cmpFlags |= cmpMask.toLong() << xInc; } rowChunks[xBase >> 6] = cmpFlags; } } private static void transferRowFlags(long[] rowChunks, byte[] row, byte[] bitsReversalMapping) { for (var i = 0; i < rowChunks.length; i++) { var group = ~rowChunks[i]; row[i * 8 + 7] = bitsReversalMapping[0xff & (byte) (group >>> 56)]; row[i * 8 + 6] = bitsReversalMapping[0xff & (byte) (group >>> 48)]; row[i * 8 + 5] = bitsReversalMapping[0xff & (byte) (group >>> 40)]; row[i * 8 + 4] = bitsReversalMapping[0xff & (byte) (group >>> 32)]; row[i * 8 + 3] = bitsReversalMapping[0xff & (byte) (group >>> 24)]; row[i * 8 + 2] = bitsReversalMapping[0xff & (byte) (group >>> 16)]; row[i * 8 + 1] = bitsReversalMapping[0xff & (byte) (group >>> 8)]; row[i * 8] = bitsReversalMapping[0xff & (byte) group]; } } private static void computeRemainderScalar(double[] aCr, byte[] row, double Ci) { var sideLen = aCr.length; var bits = 0; for (var x = sideLen & ~(1 << 6); x < sideLen; x++) { var Zr = 0.0; var Zi = 0.0; var Cr = aCr[x]; var i = 50; var ZrN = 0.0; var ZiN = 0.0; do { Zi = 2.0 * Zr * Zi + Ci; Zr = ZrN - ZiN + Cr; ZiN = Zi * Zi; ZrN = Zr * Zr; } while (ZiN + ZrN <= 4.0 && --i > 0); bits <<= 1; bits += i == 0 ? 1 : 0; if (x % 8 == 7) { row[x / 8] = (byte) bits; bits = 0; } } if (sideLen % 8 != 0) { row[sideLen / 8] = (byte) bits; } } } From duke at openjdk.java.net Wed Jan 20 13:03:07 2021 From: duke at openjdk.java.net (duke) Date: Wed, 20 Jan 2021 13:03:07 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets Message-ID: <51870423-75a8-42a3-8ac7-d248c24aeec7@openjdk.org> Changeset: 962361e0 Author: Rado Smogura Committer: Maurizio Cimadamore Date: 2021-01-20 13:01:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/962361e0 Make `UNSAFE` variable static final Reviewed-by: mcimadamore ! src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template Changeset: e8342603 Author: duke Date: 2021-01-20 13:02:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e8342603 Automatic merge of foreign-memaccess+abi into foreign-jextract From github.com+7535718+rsmogura at openjdk.java.net Wed Jan 20 13:04:53 2021 From: github.com+7535718+rsmogura at openjdk.java.net (Radoslaw Smogura) Date: Wed, 20 Jan 2021 13:04:53 GMT Subject: [foreign-memaccess+abi] Integrated: Make `UNSAFE` variable static final In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 22:36:14 GMT, Radoslaw Smogura wrote: > Make `UNSAFE` static final, to avoid null checks > and traps. This pull request has now been integrated. Changeset: 962361e0 Author: Rado Smogura Committer: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/962361e0 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Make `UNSAFE` variable static final Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/436 From mcimadamore at openjdk.java.net Wed Jan 20 14:23:52 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 20 Jan 2021 14:23:52 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v4] In-Reply-To: References: Message-ID: On Sat, 16 Jan 2021 21:00:04 GMT, Radoslaw Smogura wrote: >> This changes removes (by making no-ops) range and temporal checks for `ofNativeRestricted` segment. As this segment is global, above checks are not needed. >> >> Generated native code is smaller, and execution outperforms Java native arrays (depending on CPU) >> Changed >> Benchmark Mode Cnt Score Error Units >> AccessBenchmark.foreignAddress thrpt 5 128946129.691 ? 317433.113 ops/s >> AccessBenchmark.foreignAddressRaw thrpt 5 136883439.221 ? 749390.255 ops/s >> AccessBenchmark.target thrpt 5 125325586.957 ? 32129.931 ops/s >> Base >> Benchmark Mode Cnt Score Error Units >> AccessBenchmark.foreignAddress thrpt 5 125257424.876 ? 230508.169 ops/s >> AccessBenchmark.foreignAddressRaw thrpt 5 128818591.434 ? 241806.765 ops/s >> AccessBenchmark.target thrpt 5 125083379.819 ? 184070.467 ops/s >> --- >> This PR is replacement for https://github.com/openjdk/panama-foreign/pull/431 (OCA) >> and was partially discussed (before changes) in https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011747.htm >> >> --- >> Benchmark >> @State(Scope.Thread) >> public class AccessBenchmark { >> static final MemorySegment ms = MemorySegment.ofNativeRestricted(); >> static final VarHandle intHandle = MemoryHandles.varHandle(int.class, ByteOrder.nativeOrder()); >> >> int[] intData = new int[12]; >> volatile int intDataOffset = 0; >> >> volatile MemoryAddress address; >> volatile long addressRaw; >> >> @Setup >> public void setup() { >> var ms = MemorySegment.allocateNative(256); >> address = ms.address(); >> addressRaw = address.toRawLongValue(); >> } >> >> @Benchmark >> public void target(Blackhole bh) { >> int[] local = intData; >> int localOffset = intDataOffset; >> bh.consume(local[localOffset]); >> bh.consume(local[localOffset + 1]); >> } >> >> @Benchmark >> public void foreignAddress(Blackhole bh) { >> var a = address; >> bh.consume((int) intHandle.get(ms, a.addOffset(0).toRawLongValue())); >> bh.consume((int) intHandle.get(ms, a.addOffset(4).toRawLongValue())); >> } >> >> @Benchmark >> public void foreignAddressRaw(Blackhole bh) { >> var a = addressRaw; >> bh.consume((int) intHandle.get(ms, a)); >> bh.consume((int) intHandle.get(ms, a + 4)); >> } >> } > > Radoslaw Smogura has updated the pull request incrementally with one additional commit since the last revision: > > Replaced the stride access with normal VarHandle. > > Added no_align benchmakr, to compare preformance with alignments checks turned off. > ``` > Benchmark Mode Cnt Score Error Units > LoopOverNonConstant.BB_get avgt 30 3.892 ? 0.012 ns/op > LoopOverNonConstant.BB_loop avgt 30 0.230 ? 0.001 ms/op > LoopOverNonConstant.global_segment_get avgt 30 3.887 ? 0.008 ns/op > LoopOverNonConstant.global_segment_loop avgt 30 0.396 ? 0.002 ms/op > LoopOverNonConstant.global_segment_loop_no_align avgt 30 0.247 ? 0.001 ms/op > LoopOverNonConstant.segment_get avgt 30 5.489 ? 0.014 ns/op > LoopOverNonConstant.segment_loop avgt 30 0.229 ? 0.001 ms/op > LoopOverNonConstant.segment_loop_readonly avgt 30 0.236 ? 0.001 ms/op > LoopOverNonConstant.segment_loop_slice avgt 30 0.241 ? 0.001 ms/op > LoopOverNonConstant.segment_loop_static avgt 30 0.230 ? 0.001 ms/op > LoopOverNonConstant.unsafe_get avgt 30 3.425 ? 0.006 ns/op > LoopOverNonConstant.unsafe_loop avgt 30 0.230 ? 0.001 ms/op > ``` > Not optimized `ofNativeRestricted` > ``` > LoopOverNonConstant.global_segment_get avgt 30 4.126 ? 0.006 ns/op > LoopOverNonConstant.global_segment_loop avgt 30 0.603 ? 0.001 ms/op > ``` Looks good for now - we can reassess after the hotspot improvements for long in loops start to have visible effects. Thanks! ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/437 From njian at openjdk.java.net Thu Jan 21 02:39:53 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Thu, 21 Jan 2021 02:39:53 GMT Subject: [vectorIntrinsics] RFR: 8259604: Change the implementation of loadV_partial and storeV_partial in Aarch64-SVE backend In-Reply-To: References: Message-ID: <4onyd8SAMNrupYPWKdVwsdOdHK_nFn9tbvF4y4dQ2Lk=.14c39b62-f6e0-4088-b818-b899a4665b9e@github.com> On Mon, 18 Jan 2021 06:55:48 GMT, Wang Huang wrote: > Now, the implementation of `loadV_partial` is : > mov $tmp1, 0 > mov $tmp2, vector_length > sve_whilelo $pTmp, $tmp1, $tmp2 > sve_ldr $dst, $pTmp, $mem > However, we can encode register `zr` in instruction `sve_whilelo` instead of getting from the first mov instruction. > > The new implementation is : > mov $tmp, vector_length > sve_whilelo $pTmp, zr, $tmp > sve_ldr $dst, $pTmp, $mem > From this changing, we reduce a mov instruction and a temporary variable($tmp2 ). Marked as reviewed by njian (Committer). ------------- PR: https://git.openjdk.java.net/panama-vector/pull/32 From whuang at openjdk.java.net Thu Jan 21 03:16:50 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 21 Jan 2021 03:16:50 GMT Subject: [vectorIntrinsics] RFR: 8259604: Change the implementation of loadV_partial and storeV_partial in Aarch64-SVE backend In-Reply-To: <4onyd8SAMNrupYPWKdVwsdOdHK_nFn9tbvF4y4dQ2Lk=.14c39b62-f6e0-4088-b818-b899a4665b9e@github.com> References: <4onyd8SAMNrupYPWKdVwsdOdHK_nFn9tbvF4y4dQ2Lk=.14c39b62-f6e0-4088-b818-b899a4665b9e@github.com> Message-ID: On Thu, 21 Jan 2021 02:37:05 GMT, Ningsheng Jian wrote: >> Now, the implementation of `loadV_partial` is : >> mov $tmp1, 0 >> mov $tmp2, vector_length >> sve_whilelo $pTmp, $tmp1, $tmp2 >> sve_ldr $dst, $pTmp, $mem >> However, we can encode register `zr` in instruction `sve_whilelo` instead of getting from the first mov instruction. >> >> The new implementation is : >> mov $tmp, vector_length >> sve_whilelo $pTmp, zr, $tmp >> sve_ldr $dst, $pTmp, $mem >> From this changing, we reduce a mov instruction and a temporary variable($tmp2 ). > > Marked as reviewed by njian (Committer). > LGTM, thanks! Thank you for your review. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/32 From sviswanathan at openjdk.java.net Thu Jan 21 21:57:23 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 21 Jan 2021 21:57:23 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master Message-ID: This pull request merges master changes into vectorIntrinsics. Please review. Best Regards, Sandhya ------------- Commit messages: - Merge - 8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags - 8259947: (fs) Optimize UnixPath.encode implementation - 8259843: initialize dli_fname array before calling dll_address_to_library_name - 8259786: initialize last parameter of getpwuid_r - 8257664: HTMLEditorKit: Wrong CSS relative font sizes - 8260005: Shenandoah: Remove unused AlwaysTrueClosure in ShenandoahConcurrentRootScanner::roots_do() - 8259867: Move encoding checks into ZipCoder - 8258383: vmTestbase/gc/g1/unloading/tests/unloading_compilation_level[1,2,3] time out without TieredCompilation - 8259983: do not use uninitialized expand_ms value in G1CollectedHeap::expand_heap_after_young_collection - ... and 672 more: https://git.openjdk.java.net/panama-vector/compare/2db19a41...e6c1778f The webrevs contain the adjustments done while merging with regards to each parent branch: - vectorIntrinsics: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=33&range=00.0 - panama-vector:master: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=33&range=00.1 Changes: https://git.openjdk.java.net/panama-vector/pull/33/files Stats: 131967 lines in 3307 files changed: 71226 ins; 37684 del; 23057 mod Patch: https://git.openjdk.java.net/panama-vector/pull/33.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/33/head:pull/33 PR: https://git.openjdk.java.net/panama-vector/pull/33 From whuang at openjdk.java.net Fri Jan 22 01:57:03 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Fri, 22 Jan 2021 01:57:03 GMT Subject: [vectorIntrinsics] Integrated: 8259604: Change the implementation of loadV_partial and storeV_partial in Aarch64-SVE backend In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 06:55:48 GMT, Wang Huang wrote: > Now, the implementation of `loadV_partial` is : > mov $tmp1, 0 > mov $tmp2, vector_length > sve_whilelo $pTmp, $tmp1, $tmp2 > sve_ldr $dst, $pTmp, $mem > However, we can encode register `zr` in instruction `sve_whilelo` instead of getting from the first mov instruction. > > The new implementation is : > mov $tmp, vector_length > sve_whilelo $pTmp, zr, $tmp > sve_ldr $dst, $pTmp, $mem > From this changing, we reduce a mov instruction and a temporary variable($tmp2 ). This pull request has now been integrated. Changeset: ca9fad51 Author: Wang Huang Committer: Ningsheng Jian URL: https://git.openjdk.java.net/panama-vector/commit/ca9fad51 Stats: 36 lines in 2 files changed: 0 ins; 12 del; 24 mod 8259604: Change the implementation of loadV_partial and storeV_partial in Aarch64-SVE backend Co-authored-by: He Xuejin Reviewed-by: njian ------------- PR: https://git.openjdk.java.net/panama-vector/pull/32 From njian at openjdk.java.net Fri Jan 22 06:27:45 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Fri, 22 Jan 2021 06:27:45 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 21:38:12 GMT, Sandhya Viswanathan wrote: > This pull request merges master changes into vectorIntrinsics. > Please review. > > Best Regards, > Sandhya Please help to update aarch64 asmtest.out.h, otherwise looks good to me. My local tests for this merge passed, except for AArch64 GTestWrapper.java case, which was caused by the merge of asmtest.out.h. test/hotspot/gtest/aarch64/asmtest.out.h line 540: > 538: __ sminv(v23, __ T16B, v24); // sminv b23, v24.16B > 539: __ sminv(v4, __ T4H, v5); // sminv h4, v5.4H > 540: __ sminv(v19, __ T8H, v20); // sminv h19, v20.8H A manual merge seems not working fine for this file to resolve conflicts. I will sent you the regenerated file. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/33 From duke at openjdk.java.net Fri Jan 22 11:07:11 2021 From: duke at openjdk.java.net (duke) Date: Fri, 22 Jan 2021 11:07:11 GMT Subject: git: openjdk/panama-foreign: foreign-memaccess+abi: 91 new changesets Message-ID: <7cd68b78-bd19-4ad9-b71a-ec9983ab93e3@openjdk.org> Changeset: 0ec2c969 Author: Jan Lahoda Date: 2021-01-15 12:45:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0ec2c969 8259820: JShell does not handle -source 8 properly Reviewed-by: sundar ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java + test/langtools/jdk/jshell/SourceLevelTest.java Changeset: 707bce08 Author: Conor Cleary Committer: Chris Hegarty Date: 2021-01-15 14:06:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/707bce08 8257212: (bf spec) Clarify byte order of the buffer returned by CharBuffer.subsequence(int,int) Reviewed-by: chegar, bpb, alanb ! src/java.base/share/classes/java/nio/X-Buffer.java.template ! test/jdk/java/nio/Buffer/Order-X.java.template ! test/jdk/java/nio/Buffer/OrderChar.java ! test/jdk/java/nio/Buffer/OrderDouble.java ! test/jdk/java/nio/Buffer/OrderFloat.java ! test/jdk/java/nio/Buffer/OrderInt.java ! test/jdk/java/nio/Buffer/OrderLong.java ! test/jdk/java/nio/Buffer/OrderShort.java Changeset: bbac91a4 Author: Thomas Stuefe Date: 2021-01-15 14:51:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bbac91a4 8257959: Add gtest run with -XX:+UseLargePages Reviewed-by: lfoltan, tschatzl ! test/hotspot/jtreg/TEST.groups + test/hotspot/jtreg/gtest/LargePageGtests.java Changeset: bcf20a0d Author: Jatin Bhateja Date: 2021-01-15 15:03:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bcf20a0d 8259777: Incorrect predication condition generated by ADLC Reviewed-by: vlivanov ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/adlc/formssel.hpp Changeset: eb7fa006 Author: liach Committer: Hannes Walln?fer Date: 2021-01-15 15:12:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eb7fa006 8259216: javadoc omits method receiver for any nested type annotation Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/langtools/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java Changeset: b78cd633 Author: Daniel D. Daugherty Date: 2021-01-15 16:53:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b78cd633 8259846: [BACKOUT] JDK-8259278 Optimize Vector API slice and unslice operations Reviewed-by: vlivanov, psandoz ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template Changeset: 360c7226 Author: Phil Race Date: 2021-01-15 17:02:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/360c7226 8259729: Missed JNFInstanceOf -> IsInstanceOf conversion Reviewed-by: serb, psadhukhan, kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m Changeset: 5855d52a Author: Phil Race Date: 2021-01-15 17:04:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5855d52a 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros Reviewed-by: serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTSurfaceLayers.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CCursorManager.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDataTransferer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDesktopPeer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDragSource.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDragSourceContextPeer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDropTarget.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDropTargetContextPeer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CFRetainedResource.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CFileDialog.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsEnv.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CImage.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CInputMethod.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CMenu.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CMenuBar.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CMenuItem.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPopupMenu.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CTrayIcon.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CWrapper.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/ImageSurfaceData.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/PrintModel.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterSurfaceData.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzRenderer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.m ! src/java.desktop/macosx/native/libawt_lwawt/font/AWTFont.m ! src/java.desktop/macosx/native/libawt_lwawt/font/AWTStrike.m ! src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLGraphicsConfig.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLLayer.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLSurfaceData.m ! src/java.desktop/macosx/native/libosx/CFileManager.m ! src/java.desktop/macosx/native/libosxapp/JNIUtilities.h ! src/java.desktop/macosx/native/libosxui/AquaFileView.m ! src/java.desktop/macosx/native/libosxui/AquaNativeResources.m ! src/java.desktop/macosx/native/libosxui/ScreenMenu.m Changeset: 27a39c8d Author: Sergey Tsypanov Committer: Peter Levart Date: 2021-01-15 17:38:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/27a39c8d 8193031: Collections.addAll is likely to perform worse than Collection.addAll Reviewed-by: plevart ! src/java.base/share/classes/java/util/Collections.java Changeset: 9aa5672a Author: Coleen Phillimore Date: 2021-01-15 17:47:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9aa5672a 8259068: Streamline class loader locking Reviewed-by: dcubed, iklam ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp Changeset: fe84ecd5 Author: Kiran Sidhartha Ravikumar Date: 2021-01-15 19:14:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe84ecd5 8259048: (tz) Upgrade time-zone data to tzdata2020f Reviewed-by: naoto, erikj ! make/data/tzdata/VERSION ! make/data/tzdata/africa ! make/data/tzdata/asia ! make/data/tzdata/australasia ! make/data/tzdata/backward ! make/data/tzdata/etcetera ! make/data/tzdata/europe ! make/data/tzdata/leapseconds ! make/data/tzdata/northamerica ! make/data/tzdata/zone.tab Changeset: d7d34dd9 Author: Leonid Mesnik Date: 2021-01-15 19:33:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d7d34dd9 8259799: vmTestbase/nsk/jvmti/Breakpoint/breakpoint001 is incorrect Reviewed-by: iignatyev, sspitsyn, cjplummer ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/Breakpoint/breakpoint001/breakpoint001.cpp Changeset: d63388c0 Author: Alex Menkov Date: 2021-01-15 22:40:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d63388c0 8259266: com/sun/jdi/JdbOptions.java failed with "RuntimeException: 'prop[boo] = >foo 2<' missing from stdout/stderr" Reviewed-by: cjplummer, sspitsyn ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/VMConnection.java Changeset: e85892bf Author: Jaroslav Bachorik Date: 2021-01-15 15:12:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e85892bf 8258396: SIGILL in jdk.jfr.internal.PlatformRecorder.rotateDisk() Reviewed-by: egahlin Backport-of: a06cea50a5ea04fb0399d7ea3f6a2a20d9b4d254 ! src/hotspot/share/jfr/recorder/storage/jfrStorage.cpp Changeset: 536082db Author: Jesper Wilhelmsson Date: 2021-01-16 02:46:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/536082db Merge Changeset: 90c73d05 Author: Thomas Stuefe Date: 2021-01-16 05:17:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/90c73d05 8259569: gtest os.dll_address_to_function_and_library_name_vm fails Reviewed-by: dcubed ! test/hotspot/gtest/runtime/test_os.cpp Changeset: bbb93ca3 Author: Pankaj Bansal Date: 2021-01-16 07:52:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bbb93ca3 8256126: Create implementation for NSAccessibilityImage protocol peer Reviewed-by: kizune, serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m = src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ImageAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ImageAccessibility.m Changeset: afd3f78a Author: Sebastian Stenzel Committer: Alan Bateman Date: 2021-01-16 08:36:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/afd3f78a 8030048: (fs) Support UserDefinedFileAttributeView/extended attributes on OS X / HFS+ Reviewed-by: alanb ! src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java ! src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java ! src/java.base/macosx/classes/sun/nio/fs/BsdFileSystemProvider.java ! src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java = src/java.base/macosx/classes/sun/nio/fs/BsdUserDefinedFileAttributeView.java ! src/java.base/macosx/native/libnio/fs/BsdNativeDispatcher.c ! src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template Changeset: 6d6a23e3 Author: Andy Herrick Date: 2021-01-16 14:37:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6d6a23e3 8259062: Remove MacAppStoreBundler Reviewed-by: asemenyuk, almatvee, kizune - src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppStoreBundler.java ! src/jdk.jpackage/macosx/classes/module-info.java.extra Changeset: c3bdbf9d Author: Andy Herrick Date: 2021-01-16 14:38:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c3bdbf9d 8259238: Clean up Log.java and remove usage of non-final static variables. Reviewed-by: asemenyuk, almatvee, kizune ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Log.java ! src/jdk.jpackage/share/classes/jdk/jpackage/main/Main.java Changeset: da4cf05d Author: Andy Herrick Date: 2021-01-16 14:38:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/da4cf05d 8258755: jpackage: Invalid 32-bit exe when building app-image Reviewed-by: asemenyuk, almatvee, kizune ! src/jdk.jpackage/share/native/applauncher/JvmLauncher.cpp ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixPipeline.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixSourcesBuilder.java Changeset: 5f2e280c Author: Alan Bateman Date: 2021-01-17 18:13:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5f2e280c 8259865: (fs) test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java failing on macOS 10.13 Reviewed-by: dcubed ! src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java Changeset: 5dc5d940 Author: Alexander Zuev Date: 2021-01-17 20:39:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5dc5d940 8256110: Create implementation for NSAccessibilityStepper protocol Reviewed-by: pbansal, serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ButtonAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.m Changeset: 68cf65d2 Author: Valerie Peng Date: 2021-01-18 02:26:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/68cf65d2 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 Reviewed-by: weijun ! src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java ! src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java ! src/java.base/share/classes/sun/security/rsa/RSAPublicKeyImpl.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java ! test/jdk/sun/security/pkcs11/rsa/TestKeyFactory.java ! test/jdk/sun/security/rsa/TestKeyFactory.java Changeset: 3f19ef63 Author: Prasanta Sadhukhan Date: 2021-01-18 07:20:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3f19ef63 8202880: Test javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java fails Reviewed-by: aivanov ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java Changeset: 917f7e9a Author: Alexander Zuev Date: 2021-01-18 08:23:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/917f7e9a 8259650: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button" Reviewed-by: jdv ! test/jdk/javax/swing/JComponent/7154030/bug7154030.java Changeset: e93f08e2 Author: Albert Mingkun Yang Committer: Thomas Schatzl Date: 2021-01-18 08:33:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e93f08e2 8074101: Add verification that all tasks are actually claimed during roots processing Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/g1/g1RootProcessor.cpp ! src/hotspot/share/gc/g1/g1RootProcessor.hpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.hpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp ! src/hotspot/share/runtime/safepoint.cpp Changeset: ff275b37 Author: Aleksey Shipilev Date: 2021-01-18 10:28:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ff275b37 8259403: Zero: crash with NULL MethodHandle receiver Reviewed-by: coleenp ! src/hotspot/cpu/zero/methodHandles_zero.cpp ! src/hotspot/cpu/zero/methodHandles_zero.hpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/interpreterRuntime.hpp Changeset: 61292be7 Author: Laurent Bourg?s Date: 2021-01-18 11:34:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/61292be7 8259681: Remove the Marlin rendering engine (single-precision) Reviewed-by: serb ! src/java.desktop/share/classes/sun/java2d/marlin/CollinearSimplifier.java ! src/java.desktop/share/classes/sun/java2d/marlin/Curve.java - src/java.desktop/share/classes/sun/java2d/marlin/DCollinearSimplifier.java - src/java.desktop/share/classes/sun/java2d/marlin/DCurve.java - src/java.desktop/share/classes/sun/java2d/marlin/DDasher.java - src/java.desktop/share/classes/sun/java2d/marlin/DHelpers.java ! src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java - src/java.desktop/share/classes/sun/java2d/marlin/DPathSimplifier.java - src/java.desktop/share/classes/sun/java2d/marlin/DRenderer.java - src/java.desktop/share/classes/sun/java2d/marlin/DRendererContext.java - src/java.desktop/share/classes/sun/java2d/marlin/DStroker.java - src/java.desktop/share/classes/sun/java2d/marlin/DTransformingPathConsumer2D.java ! src/java.desktop/share/classes/sun/java2d/marlin/Dasher.java - src/java.desktop/share/classes/sun/java2d/marlin/FloatArrayCache.java ! src/java.desktop/share/classes/sun/java2d/marlin/Helpers.java - src/java.desktop/share/classes/sun/java2d/marlin/IRendererContext.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinCache.java - src/java.desktop/share/classes/sun/java2d/marlin/MarlinRenderer.java - src/java.desktop/share/classes/sun/java2d/marlin/MarlinRenderingEngine.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinTileGenerator.java ! src/java.desktop/share/classes/sun/java2d/marlin/PathSimplifier.java ! src/java.desktop/share/classes/sun/java2d/marlin/Renderer.java ! src/java.desktop/share/classes/sun/java2d/marlin/RendererContext.java ! src/java.desktop/share/classes/sun/java2d/marlin/Stroker.java ! src/java.desktop/share/classes/sun/java2d/marlin/TransformingPathConsumer2D.java ! src/java.desktop/share/classes/sun/java2d/marlin/Version.java ! test/jdk/sun/java2d/marlin/ClipShapeTest.java ! test/jdk/sun/java2d/marlin/StrokedLinePerf.java Changeset: db9c114d Author: Jaikiran Pai Date: 2021-01-18 11:53:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/db9c114d 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection Reviewed-by: alanb, chegar ! src/java.base/share/classes/java/net/URL.java ! src/java.base/share/classes/java/net/URLStreamHandler.java Changeset: e60c9926 Author: Roman Kennke Date: 2021-01-18 15:29:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e60c9926 8259849: Shenandoah: Rename store-val to IU-barrier Reviewed-by: zgu, shade ! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/x86/gc/shenandoah/c1/shenandoahBarrierSetC1_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.hpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp ! src/hotspot/share/gc/shenandoah/mode/shenandoahIUMode.cpp ! src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp ! src/hotspot/share/gc/shenandoah/mode/shenandoahSATBMode.cpp ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp ! src/hotspot/share/opto/classes.hpp ! test/hotspot/jtreg/gc/shenandoah/options/TestSelectiveBarrierFlags.java ! test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierDisable.java ! test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierEnable.java Changeset: 061ffc47 Author: Markus Gr?nlund Date: 2021-01-18 16:14:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/061ffc47 8249245: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant Reviewed-by: egahlin ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp Changeset: 6b4732fe Author: Aleksey Shipilev Date: 2021-01-18 18:42:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6b4732fe 8259679: GitHub actions should use MSVC 14.28 Reviewed-by: ihse, redestad ! .github/workflows/submit.yml Changeset: 533a2d39 Author: Xin Liu Committer: Vladimir Kozlov Date: 2021-01-18 22:34:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/533a2d39 8258961: move some fields of SafePointNode from public to protected Reviewed-by: thartmann, kvn ! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/generateOptoStub.cpp ! src/hotspot/share/opto/parse1.cpp Changeset: 492bebc7 Author: Ioi Lam Date: 2021-01-19 04:32:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/492bebc7 8258004: Remove unnecessary inclusion of vm_version.hpp Reviewed-by: dholmes, stefank ! src/hotspot/cpu/ppc/assembler_ppc.inline.hpp ! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/c2_init_ppc.cpp ! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp ! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c2_init_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp ! src/hotspot/share/asm/assembler.hpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIRAssembler.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp ! src/hotspot/share/jfr/periodic/jfrOSInterface.cpp ! src/hotspot/share/jfr/periodic/jfrPeriodic.cpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/services/diagnosticCommand.cpp Changeset: d5ca3b3f Author: Roland Westrelin Date: 2021-01-18 07:54:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d5ca3b3f 8259641: C2: assert(early->dominates(LCA)) failed: early is high enough Reviewed-by: chagedorn, thartmann ! src/hotspot/share/opto/loopnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestBrokenAntiDependenceWithPhi.java Changeset: cd25bf2e Author: Markus Gr?nlund Date: 2021-01-18 10:22:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd25bf2e 8259574: SIGSEGV in BFSClosure::closure_impl Reviewed-by: stefank, egahlin ! src/hotspot/share/jfr/leakprofiler/chains/bfsClosure.cpp ! src/hotspot/share/jfr/leakprofiler/chains/rootSetClosure.cpp ! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp Changeset: bb0821eb Author: Alexander Zuev Date: 2021-01-18 22:12:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb0821eb 8258643: [TESTBUG] javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button" Reviewed-by: trebari, psadhukhan ! test/jdk/javax/swing/JComponent/7154030/bug7154030.java Changeset: a1a851b6 Author: Jesper Wilhelmsson Date: 2021-01-19 05:43:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a1a851b6 Merge ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.cpp Changeset: 14ce8f1a Author: Ioi Lam Date: 2021-01-19 06:44:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/14ce8f1a 8259870: zBarrier.inline.hpp should not include javaClasses.hpp Reviewed-by: stefank, tschatzl ! src/hotspot/share/gc/z/zBarrier.cpp ! src/hotspot/share/gc/z/zBarrier.hpp ! src/hotspot/share/gc/z/zBarrier.inline.hpp Changeset: dfee7b8a Author: Sergey Bylokhov Date: 2021-01-19 07:16:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dfee7b8a 8259511: java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java failed with "RuntimeException: Test failed: 20 failure(s)" Reviewed-by: jdv ! test/jdk/java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java ! test/jdk/java/awt/Window/MainKeyWindowTest/libTestMainKeyWindow.c Changeset: bd81ccfd Author: Jie Fu Date: 2021-01-19 07:43:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bd81ccfd 8259957: Build failure without C1 Compiler after JDK-8258004 Reviewed-by: dholmes, shade ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp Changeset: 139f5d33 Author: Yasumasa Suenaga Date: 2021-01-19 08:57:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/139f5d33 8259035: Comments for load order of hsdis should be updated Reviewed-by: thartmann ! src/hotspot/share/compiler/disassembler.cpp Changeset: a9519c83 Author: Aleksey Shipilev Date: 2021-01-19 09:38:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a9519c83 8259924: GitHub actions fail on Linux x86_32 with "Could not configure libc6:i386" Reviewed-by: dholmes ! .github/workflows/submit.yml Changeset: 82adfb32 Author: Harold Seigel Date: 2021-01-19 13:44:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/82adfb32 8134540: Much nearly duplicated code for PerfMemory support Reviewed-by: coleenp, dholmes ! src/hotspot/os/aix/os_aix.inline.hpp - src/hotspot/os/aix/perfMemory_aix.cpp ! src/hotspot/os/bsd/os_bsd.inline.hpp - src/hotspot/os/bsd/perfMemory_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/linux/os_linux.hpp ! src/hotspot/os/linux/os_linux.inline.hpp ! src/hotspot/os/posix/os_posix.inline.hpp = src/hotspot/os/posix/perfMemory_posix.cpp Changeset: c0e9c446 Author: Aleksey Shipilev Date: 2021-01-19 14:39:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c0e9c446 8259962: Shenandoah: task queue statistics is inconsistent after JDK-8255019 Reviewed-by: zgu ! src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp Changeset: 5cfb36e7 Author: Markus Gr?nlund Date: 2021-01-19 15:27:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5cfb36e7 8259036: Failed JfrVersionSystem invariant when VM built with -fno-elide-constructors Reviewed-by: egahlin ! src/hotspot/share/jfr/utilities/jfrConcurrentLinkedListHost.inline.hpp ! src/hotspot/share/jfr/utilities/jfrConcurrentQueue.inline.hpp ! src/hotspot/share/jfr/utilities/jfrRefCountPointer.hpp ! src/hotspot/share/jfr/utilities/jfrVersionSystem.hpp ! src/hotspot/share/jfr/utilities/jfrVersionSystem.inline.hpp Changeset: 5d8861b0 Author: Markus Gr?nlund Date: 2021-01-19 16:56:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5d8861b0 8259995: Missing comma to separate years in copyright header Reviewed-by: egahlin ! src/hotspot/share/jfr/utilities/jfrConcurrentLinkedListHost.inline.hpp ! src/hotspot/share/jfr/utilities/jfrVersionSystem.hpp ! src/hotspot/share/jfr/utilities/jfrVersionSystem.inline.hpp Changeset: 3edf393d Author: Aleksey Shipilev Date: 2021-01-19 18:33:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3edf393d 8259978: PPC64 builds broken after JDK-8258004 Reviewed-by: lucy, iklam ! src/hotspot/cpu/ppc/nativeInst_ppc.hpp ! src/hotspot/share/oops/method.cpp Changeset: 33dcc00c Author: Kim Barrett Date: 2021-01-19 19:14:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/33dcc00c 8132984: incorrect type for Reference.discovered Use unbounded wildcard placeholders, plus a new helper to get back to the Reference domain. Reviewed-by: rkennke, plevart, rriggs, mchung ! src/java.base/share/classes/java/lang/ref/Reference.java Changeset: a37cd5a3 Author: Zhengyu Gu Date: 2021-01-19 20:01:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a37cd5a3 8259859: Missing metaspace NMT memory tag Reviewed-by: iklam ! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp Changeset: f7b96d34 Author: Martin Buchholz Date: 2021-01-19 18:41:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f7b96d34 8259796: timed CompletableFuture.get may swallow InterruptedException Reviewed-by: dl, alanb ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! test/jdk/java/util/concurrent/CompletableFuture/SwallowedInterruptedException.java Changeset: cf25383d Author: Jesper Wilhelmsson Date: 2021-01-19 22:49:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cf25383d Merge ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java Changeset: 9f21bb6a Author: Matthias Baesken Date: 2021-01-20 07:49:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f21bb6a 8259983: do not use uninitialized expand_ms value in G1CollectedHeap::expand_heap_after_young_collection Reviewed-by: kbarrett, lucy ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp Changeset: 7c32ffea Author: Tobias Hartmann Date: 2021-01-20 11:48:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7c32ffea 8258383: vmTestbase/gc/g1/unloading/tests/unloading_compilation_level[1,2,3] time out without TieredCompilation Reviewed-by: kvn ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/loading/ClassLoadingHelper.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_inMemoryCompilation_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_inMemoryCompilation_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_inMemoryCompilation_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_inMemoryCompilation_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_inMemoryCompilation_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_inMemoryCompilation_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_inMemoryCompilation_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_inMemoryCompilation_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_inMemoryCompilation_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_inMemoryCompilation_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_inMemoryCompilation_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_inMemoryCompilation_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_keep_obj/TestDescription.java Changeset: 05294802 Author: Eirik Bjorsnos Committer: Claes Redestad Date: 2021-01-20 12:02:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/05294802 8259867: Move encoding checks into ZipCoder Reviewed-by: redestad, lancea ! src/java.base/share/classes/java/util/zip/ZipCoder.java ! src/java.base/share/classes/java/util/zip/ZipFile.java Changeset: 0b01d692 Author: Zhengyu Gu Date: 2021-01-20 13:11:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0b01d692 8260005: Shenandoah: Remove unused AlwaysTrueClosure in ShenandoahConcurrentRootScanner::roots_do() Reviewed-by: shade, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp Changeset: 70b5b311 Author: Stanimir Stamenkov Committer: Alexey Ivanov Date: 2021-01-20 13:34:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/70b5b311 8257664: HTMLEditorKit: Wrong CSS relative font sizes Reviewed-by: aivanov, psadhukhan ! src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java + test/jdk/javax/swing/text/html/StyleSheet/TestWrongCSSFontSize.java Changeset: 52ed2aab Author: Matthias Baesken Date: 2021-01-20 15:04:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/52ed2aab 8259786: initialize last parameter of getpwuid_r Reviewed-by: mdoerr, hseigel ! src/hotspot/os/posix/perfMemory_posix.cpp ! src/jdk.security.auth/unix/native/libjaas/Unix.c Changeset: 69f90b5f Author: Matthias Baesken Date: 2021-01-20 15:08:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/69f90b5f 8259843: initialize dli_fname array before calling dll_address_to_library_name Reviewed-by: lucy, dholmes ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/share/prims/nativeLookup.cpp ! src/hotspot/share/runtime/frame.cpp Changeset: 5891509d Author: Claes Redestad Date: 2021-01-20 15:14:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5891509d 8259947: (fs) Optimize UnixPath.encode implementation Reviewed-by: chegar, shade, alanb ! src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java ! src/java.base/macosx/classes/sun/nio/fs/MacOSXFileSystem.java ! src/java.base/macosx/classes/sun/nio/fs/MacOSXNativeDispatcher.java ! src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java ! src/java.base/unix/classes/sun/nio/fs/UnixPath.java ! test/micro/org/openjdk/bench/java/io/FileOpen.java Changeset: 07851474 Author: Andrew John Hughes Date: 2021-01-20 16:13:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/07851474 8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags Use -march=i686 instead of -march=i586 if -fcf-protection is passed to the build as CMOV is required Reviewed-by: erikj ! make/autoconf/flags-cflags.m4 Changeset: 4f11ff32 Author: Zhengyu Gu Date: 2021-01-20 21:41:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4f11ff32 8259488: Shenandoah: Missing timing tracking for STW CLD root processing Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp Changeset: 8b95d954 Author: Hai-May Chao Committer: Sean Mullan Date: 2021-01-20 22:23:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8b95d954 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension Reviewed-by: jnimeh, mullan ! src/java.base/share/classes/sun/security/provider/certpath/OCSPNonceExtension.java ! src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/SSLCA.java ! test/jdk/sun/security/provider/certpath/Extensions/OCSPNonceExtensionTests.java Changeset: 1f47de5f Author: Claes Redestad Date: 2021-01-20 23:42:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1f47de5f 8260010: UTF8ZipCoder not thread-safe since JDK-8243469 Reviewed-by: lancea ! src/java.base/share/classes/java/util/zip/ZipCoder.java Changeset: 27cc62a5 Author: Claes Redestad Date: 2021-01-20 23:42:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/27cc62a5 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException Reviewed-by: jvernee, mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template ! test/jdk/java/lang/invoke/VarHandles/VarHandleBaseTest.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessByte.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessChar.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessDouble.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessFloat.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessShort.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessString.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessBoolean.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessChar.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessDouble.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessFloat.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessInt.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessLong.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessShort.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessString.java ! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template ! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template ! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template Changeset: 35c9da70 Author: Claes Redestad Date: 2021-01-20 23:45:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/35c9da70 8259498: Reduce overhead of MD5 and SHA digests Reviewed-by: valeriep ! src/java.base/share/classes/sun/security/provider/ByteArrayAccess.java ! src/java.base/share/classes/sun/security/provider/MD4.java ! src/java.base/share/classes/sun/security/provider/MD5.java ! src/java.base/share/classes/sun/security/provider/SHA.java ! src/java.base/share/classes/sun/security/provider/SHA2.java ! src/java.base/share/classes/sun/security/provider/SHA5.java ! test/micro/org/openjdk/bench/java/security/MessageDigests.java ! test/micro/org/openjdk/bench/java/util/UUIDBench.java Changeset: 77a43023 Author: David Holmes Date: 2021-01-21 02:41:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/77a43023 8223056: Remove Type-Stable-Memory support for Parkers Reviewed-by: coleenp, rehn ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/posix/os_posix.hpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os/windows/os_windows.hpp ! src/hotspot/share/prims/unsafe.cpp ! src/hotspot/share/runtime/park.cpp ! src/hotspot/share/runtime/park.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: 044bae0e Author: Ioi Lam Date: 2021-01-21 03:54:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/044bae0e 8260191: Do not include access.hpp in oop.hpp Reviewed-by: kbarrett ! src/hotspot/share/gc/z/zBarrierSetRuntime.cpp ! src/hotspot/share/oops/oop.hpp Changeset: 01205109 Author: Leo Jiang Date: 2021-01-20 13:58:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/01205109 8259732: JDK 16 L10n resource file update - msg drop 10 Reviewed-by: naoto ! src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_ja.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_ja.properties ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_ja.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_zh_CN.properties ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/LinuxResources_ja.properties ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/LinuxResources_zh_CN.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_ja.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_zh_CN.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_ja.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_zh_CN.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_ja.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_zh_CN.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties ! src/jdk.jshell/share/classes/jdk/jshell/resources/l10n_ja.properties ! src/jdk.jshell/share/classes/jdk/jshell/resources/l10n_zh_CN.properties Changeset: 0408b23b Author: Igor Ignatyev Date: 2021-01-20 18:48:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0408b23b 8259757: add a regression test for 8259353 and 8259601 Co-authored-by: Xiaohong Gong Co-authored-by: Igor Ignatyev Reviewed-by: kvn, jiefu + test/hotspot/jtreg/compiler/vectorapi/Test8259353.java Changeset: 133bcb09 Author: Jesper Wilhelmsson Date: 2021-01-21 05:23:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/133bcb09 Merge ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties Changeset: f8a9602a Author: Yasumasa Suenaga Date: 2021-01-21 06:08:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f8a9602a 8260025: Missing comma in VM_Version_Ext::_family_id_amd Reviewed-by: dholmes, stuefe ! src/hotspot/cpu/x86/vm_version_ext_x86.cpp Changeset: 5940287b Author: Aleksey Shipilev Date: 2021-01-21 07:21:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5940287b 8260048: Shenandoah: ShenandoahMarkingContext asserts are unnecessary Reviewed-by: zgu, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.inline.hpp Changeset: 7f7166db Author: Prasanta Sadhukhan Date: 2021-01-21 08:27:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7f7166db 8260035: Deproblemlist few problemlisted test Reviewed-by: jdv ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JMenuItem/6249972/bug6249972.java ! test/jdk/javax/swing/JTree/6263446/bug6263446.java ! test/jdk/javax/swing/plaf/basic/Test6984643.java Changeset: 4dfd8cc4 Author: Thomas Stuefe Date: 2021-01-21 10:30:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4dfd8cc4 8259897: gtest os.dll_address_to_function_and_library_name_vm fails on AIX Reviewed-by: mdoerr ! test/hotspot/gtest/runtime/test_os.cpp Changeset: e1de0bf8 Author: Eirik Bjorsnos Committer: Claes Redestad Date: 2021-01-21 10:37:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e1de0bf8 8260043: Reduce allocation in sun.net.www.protocol.jar.Handler.parseURL Reviewed-by: redestad, chegar ! src/java.base/share/classes/sun/net/www/ParseUtil.java ! src/java.base/share/classes/sun/net/www/protocol/jar/Handler.java Changeset: 4bcffeb9 Author: Fei Yang Date: 2021-01-21 11:58:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4bcffeb9 8260029: aarch64: fix typo in verify_oop_array Co-authored-by: Zhuxuan Ni Reviewed-by: shade, aph ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Changeset: 6ce0799b Author: Albert Mingkun Yang Committer: Thomas Schatzl Date: 2021-01-21 12:10:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6ce0799b 8259851: Use boolean type for tasks in SubTasksDone Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp Changeset: c3c66625 Author: Aleksey Shipilev Date: 2021-01-21 13:32:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c3c66625 8259954: gc/shenandoah/mxbeans tests fail with -Xcomp Reviewed-by: rkennke, zgu ! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java ! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestPauseNotifications.java Changeset: 34eb8b34 Author: Zhengyu Gu Date: 2021-01-21 16:55:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/34eb8b34 8255765: Shenandoah: Isolate concurrent, degenerated and full GC Reviewed-by: rkennke, shade ! src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.hpp + src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp + src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp + src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp + src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.hpp + src/hotspot/share/gc/shenandoah/shenandoahGC.cpp + src/hotspot/share/gc/shenandoah/shenandoahGC.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.hpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp Changeset: a8073efe Author: Brian Burkhalter Date: 2021-01-21 21:36:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a8073efe 8253478: (se) epoll Selector should use eventfd for wakeup instead of pipe Reviewed-by: alanb ! src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java + src/java.base/linux/classes/sun/nio/ch/EventFD.java + src/java.base/linux/native/libnio/ch/EventFD.c + test/micro/org/openjdk/bench/java/nio/SelectorWakeup.java Changeset: 2f47c39a Author: Brian Burkhalter Date: 2021-01-21 21:54:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f47c39a 8259943: FileDescriptor.close0 does not handle EINTR Reviewed-by: naoto, alanb ! src/java.base/unix/native/libjava/io_util_md.c Changeset: a7c2ebc7 Author: Sergey Bylokhov Date: 2021-01-22 00:21:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a7c2ebc7 8239894: Xserver crashes when the wrong high refresh rate is used Reviewed-by: kizune ! src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java ! src/java.desktop/unix/native/common/awt/systemscale/systemScale.c ! src/java.desktop/unix/native/common/awt/systemscale/systemScale.h ! src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c ! src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c Changeset: 92c2f084 Author: Phil Race Date: 2021-01-22 01:50:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92c2f084 8259869: [macOS] Remove desktop module dependencies on JNF Reference APIs Reviewed-by: serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDragSource.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDragSourceContextPeer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDropTarget.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDropTargetContextPeer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CFileDialog.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsEnv.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CInputMethod.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CMenuComponent.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPopupMenu.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CTrayIcon.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/ImageSurfaceData.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityAction.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLLayer.h ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLLayer.m ! src/java.desktop/macosx/native/libosxui/ScreenMenu.m Changeset: ba386615 Author: Ioi Lam Date: 2021-01-22 04:20:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ba386615 8259882: Reduce the inclusion of perfData.hpp Reviewed-by: redestad, coleenp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileBroker.hpp ! src/hotspot/share/gc/epsilon/epsilonMonitoringSupport.cpp ! src/hotspot/share/gc/shared/ageTable.cpp ! src/hotspot/share/gc/shared/ageTable.hpp ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shared/generationCounters.cpp ! src/hotspot/share/gc/shared/generationCounters.hpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp ! src/hotspot/share/runtime/arguments.hpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp ! src/hotspot/share/runtime/perfData.hpp + src/hotspot/share/runtime/perfDataTypes.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/runtime/vmThread.hpp ! src/hotspot/share/services/management.hpp Changeset: a70acf2c Author: Aleksey Shipilev Date: 2021-01-22 07:05:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a70acf2c 8259928: compiler/jvmci tests fail with -Xint Reviewed-by: kvn, iignatyev ! test/jtreg-ext/requires/VMProps.java Changeset: 14522800 Author: Prasanta Sadhukhan Date: 2021-01-22 08:02:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/14522800 8164484: Unity, JTable cell editor, javax/swing/JComboBox/6559152/bug6559152.java Reviewed-by: serb, jdv ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JComboBox/6559152/bug6559152.java Changeset: d066f2b0 Author: Thomas Stuefe Date: 2021-01-22 09:00:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d066f2b0 8260030: Improve stringStream buffer handling Reviewed-by: iklam, kbarrett ! src/hotspot/share/utilities/ostream.cpp ! src/hotspot/share/utilities/ostream.hpp ! test/hotspot/gtest/utilities/test_ostream.cpp Changeset: 5f05e377 Author: duke Date: 2021-01-22 11:01:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5f05e377 Automatic merge of jdk:master into master Changeset: aea0196d Author: duke Date: 2021-01-22 11:01:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aea0196d Automatic merge of master into foreign-memaccess+abi From duke at openjdk.java.net Fri Jan 22 11:12:30 2021 From: duke at openjdk.java.net (duke) Date: Fri, 22 Jan 2021 11:12:30 GMT Subject: git: openjdk/panama-foreign: master: 90 new changesets Message-ID: Changeset: 0ec2c969 Author: Jan Lahoda Date: 2021-01-15 12:45:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0ec2c969 8259820: JShell does not handle -source 8 properly Reviewed-by: sundar ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java + test/langtools/jdk/jshell/SourceLevelTest.java Changeset: 707bce08 Author: Conor Cleary Committer: Chris Hegarty Date: 2021-01-15 14:06:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/707bce08 8257212: (bf spec) Clarify byte order of the buffer returned by CharBuffer.subsequence(int,int) Reviewed-by: chegar, bpb, alanb ! src/java.base/share/classes/java/nio/X-Buffer.java.template ! test/jdk/java/nio/Buffer/Order-X.java.template ! test/jdk/java/nio/Buffer/OrderChar.java ! test/jdk/java/nio/Buffer/OrderDouble.java ! test/jdk/java/nio/Buffer/OrderFloat.java ! test/jdk/java/nio/Buffer/OrderInt.java ! test/jdk/java/nio/Buffer/OrderLong.java ! test/jdk/java/nio/Buffer/OrderShort.java Changeset: bbac91a4 Author: Thomas Stuefe Date: 2021-01-15 14:51:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bbac91a4 8257959: Add gtest run with -XX:+UseLargePages Reviewed-by: lfoltan, tschatzl ! test/hotspot/jtreg/TEST.groups + test/hotspot/jtreg/gtest/LargePageGtests.java Changeset: bcf20a0d Author: Jatin Bhateja Date: 2021-01-15 15:03:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bcf20a0d 8259777: Incorrect predication condition generated by ADLC Reviewed-by: vlivanov ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/adlc/formssel.hpp Changeset: eb7fa006 Author: liach Committer: Hannes Walln?fer Date: 2021-01-15 15:12:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eb7fa006 8259216: javadoc omits method receiver for any nested type annotation Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/langtools/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java Changeset: b78cd633 Author: Daniel D. Daugherty Date: 2021-01-15 16:53:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b78cd633 8259846: [BACKOUT] JDK-8259278 Optimize Vector API slice and unslice operations Reviewed-by: vlivanov, psandoz ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template Changeset: 360c7226 Author: Phil Race Date: 2021-01-15 17:02:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/360c7226 8259729: Missed JNFInstanceOf -> IsInstanceOf conversion Reviewed-by: serb, psadhukhan, kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m Changeset: 5855d52a Author: Phil Race Date: 2021-01-15 17:04:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5855d52a 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros Reviewed-by: serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTSurfaceLayers.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CCursorManager.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDataTransferer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDesktopPeer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDragSource.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDragSourceContextPeer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDropTarget.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDropTargetContextPeer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CFRetainedResource.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CFileDialog.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsEnv.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CImage.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CInputMethod.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CMenu.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CMenuBar.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CMenuItem.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPopupMenu.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CTrayIcon.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CWrapper.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/ImageSurfaceData.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/PrintModel.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterSurfaceData.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzRenderer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.m ! src/java.desktop/macosx/native/libawt_lwawt/font/AWTFont.m ! src/java.desktop/macosx/native/libawt_lwawt/font/AWTStrike.m ! src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLGraphicsConfig.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLLayer.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLSurfaceData.m ! src/java.desktop/macosx/native/libosx/CFileManager.m ! src/java.desktop/macosx/native/libosxapp/JNIUtilities.h ! src/java.desktop/macosx/native/libosxui/AquaFileView.m ! src/java.desktop/macosx/native/libosxui/AquaNativeResources.m ! src/java.desktop/macosx/native/libosxui/ScreenMenu.m Changeset: 27a39c8d Author: Sergey Tsypanov Committer: Peter Levart Date: 2021-01-15 17:38:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/27a39c8d 8193031: Collections.addAll is likely to perform worse than Collection.addAll Reviewed-by: plevart ! src/java.base/share/classes/java/util/Collections.java Changeset: 9aa5672a Author: Coleen Phillimore Date: 2021-01-15 17:47:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9aa5672a 8259068: Streamline class loader locking Reviewed-by: dcubed, iklam ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp Changeset: fe84ecd5 Author: Kiran Sidhartha Ravikumar Date: 2021-01-15 19:14:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe84ecd5 8259048: (tz) Upgrade time-zone data to tzdata2020f Reviewed-by: naoto, erikj ! make/data/tzdata/VERSION ! make/data/tzdata/africa ! make/data/tzdata/asia ! make/data/tzdata/australasia ! make/data/tzdata/backward ! make/data/tzdata/etcetera ! make/data/tzdata/europe ! make/data/tzdata/leapseconds ! make/data/tzdata/northamerica ! make/data/tzdata/zone.tab Changeset: d7d34dd9 Author: Leonid Mesnik Date: 2021-01-15 19:33:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d7d34dd9 8259799: vmTestbase/nsk/jvmti/Breakpoint/breakpoint001 is incorrect Reviewed-by: iignatyev, sspitsyn, cjplummer ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/Breakpoint/breakpoint001/breakpoint001.cpp Changeset: d63388c0 Author: Alex Menkov Date: 2021-01-15 22:40:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d63388c0 8259266: com/sun/jdi/JdbOptions.java failed with "RuntimeException: 'prop[boo] = >foo 2<' missing from stdout/stderr" Reviewed-by: cjplummer, sspitsyn ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/VMConnection.java Changeset: e85892bf Author: Jaroslav Bachorik Date: 2021-01-15 15:12:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e85892bf 8258396: SIGILL in jdk.jfr.internal.PlatformRecorder.rotateDisk() Reviewed-by: egahlin Backport-of: a06cea50a5ea04fb0399d7ea3f6a2a20d9b4d254 ! src/hotspot/share/jfr/recorder/storage/jfrStorage.cpp Changeset: 536082db Author: Jesper Wilhelmsson Date: 2021-01-16 02:46:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/536082db Merge Changeset: 90c73d05 Author: Thomas Stuefe Date: 2021-01-16 05:17:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/90c73d05 8259569: gtest os.dll_address_to_function_and_library_name_vm fails Reviewed-by: dcubed ! test/hotspot/gtest/runtime/test_os.cpp Changeset: bbb93ca3 Author: Pankaj Bansal Date: 2021-01-16 07:52:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bbb93ca3 8256126: Create implementation for NSAccessibilityImage protocol peer Reviewed-by: kizune, serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m = src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ImageAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ImageAccessibility.m Changeset: afd3f78a Author: Sebastian Stenzel Committer: Alan Bateman Date: 2021-01-16 08:36:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/afd3f78a 8030048: (fs) Support UserDefinedFileAttributeView/extended attributes on OS X / HFS+ Reviewed-by: alanb ! src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java ! src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java ! src/java.base/macosx/classes/sun/nio/fs/BsdFileSystemProvider.java ! src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java = src/java.base/macosx/classes/sun/nio/fs/BsdUserDefinedFileAttributeView.java ! src/java.base/macosx/native/libnio/fs/BsdNativeDispatcher.c ! src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template Changeset: 6d6a23e3 Author: Andy Herrick Date: 2021-01-16 14:37:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6d6a23e3 8259062: Remove MacAppStoreBundler Reviewed-by: asemenyuk, almatvee, kizune - src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppStoreBundler.java ! src/jdk.jpackage/macosx/classes/module-info.java.extra Changeset: c3bdbf9d Author: Andy Herrick Date: 2021-01-16 14:38:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c3bdbf9d 8259238: Clean up Log.java and remove usage of non-final static variables. Reviewed-by: asemenyuk, almatvee, kizune ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Log.java ! src/jdk.jpackage/share/classes/jdk/jpackage/main/Main.java Changeset: da4cf05d Author: Andy Herrick Date: 2021-01-16 14:38:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/da4cf05d 8258755: jpackage: Invalid 32-bit exe when building app-image Reviewed-by: asemenyuk, almatvee, kizune ! src/jdk.jpackage/share/native/applauncher/JvmLauncher.cpp ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixPipeline.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixSourcesBuilder.java Changeset: 5f2e280c Author: Alan Bateman Date: 2021-01-17 18:13:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5f2e280c 8259865: (fs) test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java failing on macOS 10.13 Reviewed-by: dcubed ! src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java Changeset: 5dc5d940 Author: Alexander Zuev Date: 2021-01-17 20:39:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5dc5d940 8256110: Create implementation for NSAccessibilityStepper protocol Reviewed-by: pbansal, serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ButtonAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.m Changeset: 68cf65d2 Author: Valerie Peng Date: 2021-01-18 02:26:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/68cf65d2 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 Reviewed-by: weijun ! src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java ! src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java ! src/java.base/share/classes/sun/security/rsa/RSAPublicKeyImpl.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java ! test/jdk/sun/security/pkcs11/rsa/TestKeyFactory.java ! test/jdk/sun/security/rsa/TestKeyFactory.java Changeset: 3f19ef63 Author: Prasanta Sadhukhan Date: 2021-01-18 07:20:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3f19ef63 8202880: Test javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java fails Reviewed-by: aivanov ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java Changeset: 917f7e9a Author: Alexander Zuev Date: 2021-01-18 08:23:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/917f7e9a 8259650: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button" Reviewed-by: jdv ! test/jdk/javax/swing/JComponent/7154030/bug7154030.java Changeset: e93f08e2 Author: Albert Mingkun Yang Committer: Thomas Schatzl Date: 2021-01-18 08:33:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e93f08e2 8074101: Add verification that all tasks are actually claimed during roots processing Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/g1/g1RootProcessor.cpp ! src/hotspot/share/gc/g1/g1RootProcessor.hpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.hpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp ! src/hotspot/share/runtime/safepoint.cpp Changeset: ff275b37 Author: Aleksey Shipilev Date: 2021-01-18 10:28:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ff275b37 8259403: Zero: crash with NULL MethodHandle receiver Reviewed-by: coleenp ! src/hotspot/cpu/zero/methodHandles_zero.cpp ! src/hotspot/cpu/zero/methodHandles_zero.hpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/interpreterRuntime.hpp Changeset: 61292be7 Author: Laurent Bourg?s Date: 2021-01-18 11:34:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/61292be7 8259681: Remove the Marlin rendering engine (single-precision) Reviewed-by: serb ! src/java.desktop/share/classes/sun/java2d/marlin/CollinearSimplifier.java ! src/java.desktop/share/classes/sun/java2d/marlin/Curve.java - src/java.desktop/share/classes/sun/java2d/marlin/DCollinearSimplifier.java - src/java.desktop/share/classes/sun/java2d/marlin/DCurve.java - src/java.desktop/share/classes/sun/java2d/marlin/DDasher.java - src/java.desktop/share/classes/sun/java2d/marlin/DHelpers.java ! src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java - src/java.desktop/share/classes/sun/java2d/marlin/DPathSimplifier.java - src/java.desktop/share/classes/sun/java2d/marlin/DRenderer.java - src/java.desktop/share/classes/sun/java2d/marlin/DRendererContext.java - src/java.desktop/share/classes/sun/java2d/marlin/DStroker.java - src/java.desktop/share/classes/sun/java2d/marlin/DTransformingPathConsumer2D.java ! src/java.desktop/share/classes/sun/java2d/marlin/Dasher.java - src/java.desktop/share/classes/sun/java2d/marlin/FloatArrayCache.java ! src/java.desktop/share/classes/sun/java2d/marlin/Helpers.java - src/java.desktop/share/classes/sun/java2d/marlin/IRendererContext.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinCache.java - src/java.desktop/share/classes/sun/java2d/marlin/MarlinRenderer.java - src/java.desktop/share/classes/sun/java2d/marlin/MarlinRenderingEngine.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinTileGenerator.java ! src/java.desktop/share/classes/sun/java2d/marlin/PathSimplifier.java ! src/java.desktop/share/classes/sun/java2d/marlin/Renderer.java ! src/java.desktop/share/classes/sun/java2d/marlin/RendererContext.java ! src/java.desktop/share/classes/sun/java2d/marlin/Stroker.java ! src/java.desktop/share/classes/sun/java2d/marlin/TransformingPathConsumer2D.java ! src/java.desktop/share/classes/sun/java2d/marlin/Version.java ! test/jdk/sun/java2d/marlin/ClipShapeTest.java ! test/jdk/sun/java2d/marlin/StrokedLinePerf.java Changeset: db9c114d Author: Jaikiran Pai Date: 2021-01-18 11:53:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/db9c114d 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection Reviewed-by: alanb, chegar ! src/java.base/share/classes/java/net/URL.java ! src/java.base/share/classes/java/net/URLStreamHandler.java Changeset: e60c9926 Author: Roman Kennke Date: 2021-01-18 15:29:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e60c9926 8259849: Shenandoah: Rename store-val to IU-barrier Reviewed-by: zgu, shade ! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/x86/gc/shenandoah/c1/shenandoahBarrierSetC1_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.hpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp ! src/hotspot/share/gc/shenandoah/mode/shenandoahIUMode.cpp ! src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp ! src/hotspot/share/gc/shenandoah/mode/shenandoahSATBMode.cpp ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp ! src/hotspot/share/opto/classes.hpp ! test/hotspot/jtreg/gc/shenandoah/options/TestSelectiveBarrierFlags.java ! test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierDisable.java ! test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierEnable.java Changeset: 061ffc47 Author: Markus Gr?nlund Date: 2021-01-18 16:14:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/061ffc47 8249245: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant Reviewed-by: egahlin ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp Changeset: 6b4732fe Author: Aleksey Shipilev Date: 2021-01-18 18:42:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6b4732fe 8259679: GitHub actions should use MSVC 14.28 Reviewed-by: ihse, redestad ! .github/workflows/submit.yml Changeset: 533a2d39 Author: Xin Liu Committer: Vladimir Kozlov Date: 2021-01-18 22:34:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/533a2d39 8258961: move some fields of SafePointNode from public to protected Reviewed-by: thartmann, kvn ! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/generateOptoStub.cpp ! src/hotspot/share/opto/parse1.cpp Changeset: 492bebc7 Author: Ioi Lam Date: 2021-01-19 04:32:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/492bebc7 8258004: Remove unnecessary inclusion of vm_version.hpp Reviewed-by: dholmes, stefank ! src/hotspot/cpu/ppc/assembler_ppc.inline.hpp ! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/c2_init_ppc.cpp ! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp ! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c2_init_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp ! src/hotspot/share/asm/assembler.hpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIRAssembler.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp ! src/hotspot/share/jfr/periodic/jfrOSInterface.cpp ! src/hotspot/share/jfr/periodic/jfrPeriodic.cpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/services/diagnosticCommand.cpp Changeset: d5ca3b3f Author: Roland Westrelin Date: 2021-01-18 07:54:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d5ca3b3f 8259641: C2: assert(early->dominates(LCA)) failed: early is high enough Reviewed-by: chagedorn, thartmann ! src/hotspot/share/opto/loopnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestBrokenAntiDependenceWithPhi.java Changeset: cd25bf2e Author: Markus Gr?nlund Date: 2021-01-18 10:22:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd25bf2e 8259574: SIGSEGV in BFSClosure::closure_impl Reviewed-by: stefank, egahlin ! src/hotspot/share/jfr/leakprofiler/chains/bfsClosure.cpp ! src/hotspot/share/jfr/leakprofiler/chains/rootSetClosure.cpp ! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp Changeset: bb0821eb Author: Alexander Zuev Date: 2021-01-18 22:12:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb0821eb 8258643: [TESTBUG] javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button" Reviewed-by: trebari, psadhukhan ! test/jdk/javax/swing/JComponent/7154030/bug7154030.java Changeset: a1a851b6 Author: Jesper Wilhelmsson Date: 2021-01-19 05:43:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a1a851b6 Merge ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.cpp Changeset: 14ce8f1a Author: Ioi Lam Date: 2021-01-19 06:44:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/14ce8f1a 8259870: zBarrier.inline.hpp should not include javaClasses.hpp Reviewed-by: stefank, tschatzl ! src/hotspot/share/gc/z/zBarrier.cpp ! src/hotspot/share/gc/z/zBarrier.hpp ! src/hotspot/share/gc/z/zBarrier.inline.hpp Changeset: dfee7b8a Author: Sergey Bylokhov Date: 2021-01-19 07:16:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dfee7b8a 8259511: java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java failed with "RuntimeException: Test failed: 20 failure(s)" Reviewed-by: jdv ! test/jdk/java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java ! test/jdk/java/awt/Window/MainKeyWindowTest/libTestMainKeyWindow.c Changeset: bd81ccfd Author: Jie Fu Date: 2021-01-19 07:43:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bd81ccfd 8259957: Build failure without C1 Compiler after JDK-8258004 Reviewed-by: dholmes, shade ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp Changeset: 139f5d33 Author: Yasumasa Suenaga Date: 2021-01-19 08:57:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/139f5d33 8259035: Comments for load order of hsdis should be updated Reviewed-by: thartmann ! src/hotspot/share/compiler/disassembler.cpp Changeset: a9519c83 Author: Aleksey Shipilev Date: 2021-01-19 09:38:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a9519c83 8259924: GitHub actions fail on Linux x86_32 with "Could not configure libc6:i386" Reviewed-by: dholmes ! .github/workflows/submit.yml Changeset: 82adfb32 Author: Harold Seigel Date: 2021-01-19 13:44:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/82adfb32 8134540: Much nearly duplicated code for PerfMemory support Reviewed-by: coleenp, dholmes ! src/hotspot/os/aix/os_aix.inline.hpp - src/hotspot/os/aix/perfMemory_aix.cpp ! src/hotspot/os/bsd/os_bsd.inline.hpp - src/hotspot/os/bsd/perfMemory_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/linux/os_linux.hpp ! src/hotspot/os/linux/os_linux.inline.hpp ! src/hotspot/os/posix/os_posix.inline.hpp = src/hotspot/os/posix/perfMemory_posix.cpp Changeset: c0e9c446 Author: Aleksey Shipilev Date: 2021-01-19 14:39:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c0e9c446 8259962: Shenandoah: task queue statistics is inconsistent after JDK-8255019 Reviewed-by: zgu ! src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp Changeset: 5cfb36e7 Author: Markus Gr?nlund Date: 2021-01-19 15:27:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5cfb36e7 8259036: Failed JfrVersionSystem invariant when VM built with -fno-elide-constructors Reviewed-by: egahlin ! src/hotspot/share/jfr/utilities/jfrConcurrentLinkedListHost.inline.hpp ! src/hotspot/share/jfr/utilities/jfrConcurrentQueue.inline.hpp ! src/hotspot/share/jfr/utilities/jfrRefCountPointer.hpp ! src/hotspot/share/jfr/utilities/jfrVersionSystem.hpp ! src/hotspot/share/jfr/utilities/jfrVersionSystem.inline.hpp Changeset: 5d8861b0 Author: Markus Gr?nlund Date: 2021-01-19 16:56:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5d8861b0 8259995: Missing comma to separate years in copyright header Reviewed-by: egahlin ! src/hotspot/share/jfr/utilities/jfrConcurrentLinkedListHost.inline.hpp ! src/hotspot/share/jfr/utilities/jfrVersionSystem.hpp ! src/hotspot/share/jfr/utilities/jfrVersionSystem.inline.hpp Changeset: 3edf393d Author: Aleksey Shipilev Date: 2021-01-19 18:33:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3edf393d 8259978: PPC64 builds broken after JDK-8258004 Reviewed-by: lucy, iklam ! src/hotspot/cpu/ppc/nativeInst_ppc.hpp ! src/hotspot/share/oops/method.cpp Changeset: 33dcc00c Author: Kim Barrett Date: 2021-01-19 19:14:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/33dcc00c 8132984: incorrect type for Reference.discovered Use unbounded wildcard placeholders, plus a new helper to get back to the Reference domain. Reviewed-by: rkennke, plevart, rriggs, mchung ! src/java.base/share/classes/java/lang/ref/Reference.java Changeset: a37cd5a3 Author: Zhengyu Gu Date: 2021-01-19 20:01:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a37cd5a3 8259859: Missing metaspace NMT memory tag Reviewed-by: iklam ! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp Changeset: f7b96d34 Author: Martin Buchholz Date: 2021-01-19 18:41:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f7b96d34 8259796: timed CompletableFuture.get may swallow InterruptedException Reviewed-by: dl, alanb ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! test/jdk/java/util/concurrent/CompletableFuture/SwallowedInterruptedException.java Changeset: cf25383d Author: Jesper Wilhelmsson Date: 2021-01-19 22:49:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cf25383d Merge ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java Changeset: 9f21bb6a Author: Matthias Baesken Date: 2021-01-20 07:49:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f21bb6a 8259983: do not use uninitialized expand_ms value in G1CollectedHeap::expand_heap_after_young_collection Reviewed-by: kbarrett, lucy ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp Changeset: 7c32ffea Author: Tobias Hartmann Date: 2021-01-20 11:48:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7c32ffea 8258383: vmTestbase/gc/g1/unloading/tests/unloading_compilation_level[1,2,3] time out without TieredCompilation Reviewed-by: kvn ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/loading/ClassLoadingHelper.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_inMemoryCompilation_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_inMemoryCompilation_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_inMemoryCompilation_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_inMemoryCompilation_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_inMemoryCompilation_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_inMemoryCompilation_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_inMemoryCompilation_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_inMemoryCompilation_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_inMemoryCompilation_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_inMemoryCompilation_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_inMemoryCompilation_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_inMemoryCompilation_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_keep_obj/TestDescription.java Changeset: 05294802 Author: Eirik Bjorsnos Committer: Claes Redestad Date: 2021-01-20 12:02:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/05294802 8259867: Move encoding checks into ZipCoder Reviewed-by: redestad, lancea ! src/java.base/share/classes/java/util/zip/ZipCoder.java ! src/java.base/share/classes/java/util/zip/ZipFile.java Changeset: 0b01d692 Author: Zhengyu Gu Date: 2021-01-20 13:11:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0b01d692 8260005: Shenandoah: Remove unused AlwaysTrueClosure in ShenandoahConcurrentRootScanner::roots_do() Reviewed-by: shade, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp Changeset: 70b5b311 Author: Stanimir Stamenkov Committer: Alexey Ivanov Date: 2021-01-20 13:34:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/70b5b311 8257664: HTMLEditorKit: Wrong CSS relative font sizes Reviewed-by: aivanov, psadhukhan ! src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java + test/jdk/javax/swing/text/html/StyleSheet/TestWrongCSSFontSize.java Changeset: 52ed2aab Author: Matthias Baesken Date: 2021-01-20 15:04:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/52ed2aab 8259786: initialize last parameter of getpwuid_r Reviewed-by: mdoerr, hseigel ! src/hotspot/os/posix/perfMemory_posix.cpp ! src/jdk.security.auth/unix/native/libjaas/Unix.c Changeset: 69f90b5f Author: Matthias Baesken Date: 2021-01-20 15:08:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/69f90b5f 8259843: initialize dli_fname array before calling dll_address_to_library_name Reviewed-by: lucy, dholmes ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/share/prims/nativeLookup.cpp ! src/hotspot/share/runtime/frame.cpp Changeset: 5891509d Author: Claes Redestad Date: 2021-01-20 15:14:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5891509d 8259947: (fs) Optimize UnixPath.encode implementation Reviewed-by: chegar, shade, alanb ! src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java ! src/java.base/macosx/classes/sun/nio/fs/MacOSXFileSystem.java ! src/java.base/macosx/classes/sun/nio/fs/MacOSXNativeDispatcher.java ! src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java ! src/java.base/unix/classes/sun/nio/fs/UnixPath.java ! test/micro/org/openjdk/bench/java/io/FileOpen.java Changeset: 07851474 Author: Andrew John Hughes Date: 2021-01-20 16:13:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/07851474 8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags Use -march=i686 instead of -march=i586 if -fcf-protection is passed to the build as CMOV is required Reviewed-by: erikj ! make/autoconf/flags-cflags.m4 Changeset: 4f11ff32 Author: Zhengyu Gu Date: 2021-01-20 21:41:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4f11ff32 8259488: Shenandoah: Missing timing tracking for STW CLD root processing Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp Changeset: 8b95d954 Author: Hai-May Chao Committer: Sean Mullan Date: 2021-01-20 22:23:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8b95d954 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension Reviewed-by: jnimeh, mullan ! src/java.base/share/classes/sun/security/provider/certpath/OCSPNonceExtension.java ! src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/SSLCA.java ! test/jdk/sun/security/provider/certpath/Extensions/OCSPNonceExtensionTests.java Changeset: 1f47de5f Author: Claes Redestad Date: 2021-01-20 23:42:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1f47de5f 8260010: UTF8ZipCoder not thread-safe since JDK-8243469 Reviewed-by: lancea ! src/java.base/share/classes/java/util/zip/ZipCoder.java Changeset: 27cc62a5 Author: Claes Redestad Date: 2021-01-20 23:42:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/27cc62a5 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException Reviewed-by: jvernee, mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template ! test/jdk/java/lang/invoke/VarHandles/VarHandleBaseTest.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessByte.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessChar.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessDouble.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessFloat.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessShort.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessString.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessBoolean.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessChar.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessDouble.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessFloat.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessInt.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessLong.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessShort.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessString.java ! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template ! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template ! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template Changeset: 35c9da70 Author: Claes Redestad Date: 2021-01-20 23:45:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/35c9da70 8259498: Reduce overhead of MD5 and SHA digests Reviewed-by: valeriep ! src/java.base/share/classes/sun/security/provider/ByteArrayAccess.java ! src/java.base/share/classes/sun/security/provider/MD4.java ! src/java.base/share/classes/sun/security/provider/MD5.java ! src/java.base/share/classes/sun/security/provider/SHA.java ! src/java.base/share/classes/sun/security/provider/SHA2.java ! src/java.base/share/classes/sun/security/provider/SHA5.java ! test/micro/org/openjdk/bench/java/security/MessageDigests.java ! test/micro/org/openjdk/bench/java/util/UUIDBench.java Changeset: 77a43023 Author: David Holmes Date: 2021-01-21 02:41:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/77a43023 8223056: Remove Type-Stable-Memory support for Parkers Reviewed-by: coleenp, rehn ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/posix/os_posix.hpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os/windows/os_windows.hpp ! src/hotspot/share/prims/unsafe.cpp ! src/hotspot/share/runtime/park.cpp ! src/hotspot/share/runtime/park.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: 044bae0e Author: Ioi Lam Date: 2021-01-21 03:54:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/044bae0e 8260191: Do not include access.hpp in oop.hpp Reviewed-by: kbarrett ! src/hotspot/share/gc/z/zBarrierSetRuntime.cpp ! src/hotspot/share/oops/oop.hpp Changeset: 01205109 Author: Leo Jiang Date: 2021-01-20 13:58:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/01205109 8259732: JDK 16 L10n resource file update - msg drop 10 Reviewed-by: naoto ! src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_ja.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_ja.properties ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_ja.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_zh_CN.properties ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/LinuxResources_ja.properties ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/LinuxResources_zh_CN.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_ja.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_zh_CN.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_ja.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_zh_CN.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_ja.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_zh_CN.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties ! src/jdk.jshell/share/classes/jdk/jshell/resources/l10n_ja.properties ! src/jdk.jshell/share/classes/jdk/jshell/resources/l10n_zh_CN.properties Changeset: 0408b23b Author: Igor Ignatyev Date: 2021-01-20 18:48:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0408b23b 8259757: add a regression test for 8259353 and 8259601 Co-authored-by: Xiaohong Gong Co-authored-by: Igor Ignatyev Reviewed-by: kvn, jiefu + test/hotspot/jtreg/compiler/vectorapi/Test8259353.java Changeset: 133bcb09 Author: Jesper Wilhelmsson Date: 2021-01-21 05:23:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/133bcb09 Merge ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties Changeset: f8a9602a Author: Yasumasa Suenaga Date: 2021-01-21 06:08:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f8a9602a 8260025: Missing comma in VM_Version_Ext::_family_id_amd Reviewed-by: dholmes, stuefe ! src/hotspot/cpu/x86/vm_version_ext_x86.cpp Changeset: 5940287b Author: Aleksey Shipilev Date: 2021-01-21 07:21:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5940287b 8260048: Shenandoah: ShenandoahMarkingContext asserts are unnecessary Reviewed-by: zgu, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.inline.hpp Changeset: 7f7166db Author: Prasanta Sadhukhan Date: 2021-01-21 08:27:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7f7166db 8260035: Deproblemlist few problemlisted test Reviewed-by: jdv ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JMenuItem/6249972/bug6249972.java ! test/jdk/javax/swing/JTree/6263446/bug6263446.java ! test/jdk/javax/swing/plaf/basic/Test6984643.java Changeset: 4dfd8cc4 Author: Thomas Stuefe Date: 2021-01-21 10:30:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4dfd8cc4 8259897: gtest os.dll_address_to_function_and_library_name_vm fails on AIX Reviewed-by: mdoerr ! test/hotspot/gtest/runtime/test_os.cpp Changeset: e1de0bf8 Author: Eirik Bjorsnos Committer: Claes Redestad Date: 2021-01-21 10:37:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e1de0bf8 8260043: Reduce allocation in sun.net.www.protocol.jar.Handler.parseURL Reviewed-by: redestad, chegar ! src/java.base/share/classes/sun/net/www/ParseUtil.java ! src/java.base/share/classes/sun/net/www/protocol/jar/Handler.java Changeset: 4bcffeb9 Author: Fei Yang Date: 2021-01-21 11:58:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4bcffeb9 8260029: aarch64: fix typo in verify_oop_array Co-authored-by: Zhuxuan Ni Reviewed-by: shade, aph ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Changeset: 6ce0799b Author: Albert Mingkun Yang Committer: Thomas Schatzl Date: 2021-01-21 12:10:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6ce0799b 8259851: Use boolean type for tasks in SubTasksDone Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp Changeset: c3c66625 Author: Aleksey Shipilev Date: 2021-01-21 13:32:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c3c66625 8259954: gc/shenandoah/mxbeans tests fail with -Xcomp Reviewed-by: rkennke, zgu ! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java ! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestPauseNotifications.java Changeset: 34eb8b34 Author: Zhengyu Gu Date: 2021-01-21 16:55:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/34eb8b34 8255765: Shenandoah: Isolate concurrent, degenerated and full GC Reviewed-by: rkennke, shade ! src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.hpp + src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp + src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp + src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp + src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.hpp + src/hotspot/share/gc/shenandoah/shenandoahGC.cpp + src/hotspot/share/gc/shenandoah/shenandoahGC.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.hpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp Changeset: a8073efe Author: Brian Burkhalter Date: 2021-01-21 21:36:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a8073efe 8253478: (se) epoll Selector should use eventfd for wakeup instead of pipe Reviewed-by: alanb ! src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java + src/java.base/linux/classes/sun/nio/ch/EventFD.java + src/java.base/linux/native/libnio/ch/EventFD.c + test/micro/org/openjdk/bench/java/nio/SelectorWakeup.java Changeset: 2f47c39a Author: Brian Burkhalter Date: 2021-01-21 21:54:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f47c39a 8259943: FileDescriptor.close0 does not handle EINTR Reviewed-by: naoto, alanb ! src/java.base/unix/native/libjava/io_util_md.c Changeset: a7c2ebc7 Author: Sergey Bylokhov Date: 2021-01-22 00:21:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a7c2ebc7 8239894: Xserver crashes when the wrong high refresh rate is used Reviewed-by: kizune ! src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java ! src/java.desktop/unix/native/common/awt/systemscale/systemScale.c ! src/java.desktop/unix/native/common/awt/systemscale/systemScale.h ! src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c ! src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c Changeset: 92c2f084 Author: Phil Race Date: 2021-01-22 01:50:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92c2f084 8259869: [macOS] Remove desktop module dependencies on JNF Reference APIs Reviewed-by: serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDragSource.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDragSourceContextPeer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDropTarget.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDropTargetContextPeer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CFileDialog.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsEnv.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CInputMethod.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CMenuComponent.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPopupMenu.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CTrayIcon.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/ImageSurfaceData.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityAction.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLLayer.h ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLLayer.m ! src/java.desktop/macosx/native/libosxui/ScreenMenu.m Changeset: ba386615 Author: Ioi Lam Date: 2021-01-22 04:20:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ba386615 8259882: Reduce the inclusion of perfData.hpp Reviewed-by: redestad, coleenp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileBroker.hpp ! src/hotspot/share/gc/epsilon/epsilonMonitoringSupport.cpp ! src/hotspot/share/gc/shared/ageTable.cpp ! src/hotspot/share/gc/shared/ageTable.hpp ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shared/generationCounters.cpp ! src/hotspot/share/gc/shared/generationCounters.hpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp ! src/hotspot/share/runtime/arguments.hpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp ! src/hotspot/share/runtime/perfData.hpp + src/hotspot/share/runtime/perfDataTypes.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/runtime/vmThread.hpp ! src/hotspot/share/services/management.hpp Changeset: a70acf2c Author: Aleksey Shipilev Date: 2021-01-22 07:05:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a70acf2c 8259928: compiler/jvmci tests fail with -Xint Reviewed-by: kvn, iignatyev ! test/jtreg-ext/requires/VMProps.java Changeset: 14522800 Author: Prasanta Sadhukhan Date: 2021-01-22 08:02:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/14522800 8164484: Unity, JTable cell editor, javax/swing/JComboBox/6559152/bug6559152.java Reviewed-by: serb, jdv ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JComboBox/6559152/bug6559152.java Changeset: d066f2b0 Author: Thomas Stuefe Date: 2021-01-22 09:00:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d066f2b0 8260030: Improve stringStream buffer handling Reviewed-by: iklam, kbarrett ! src/hotspot/share/utilities/ostream.cpp ! src/hotspot/share/utilities/ostream.hpp ! test/hotspot/gtest/utilities/test_ostream.cpp Changeset: 5f05e377 Author: duke Date: 2021-01-22 11:01:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5f05e377 Automatic merge of jdk:master into master From duke at openjdk.java.net Fri Jan 22 11:18:10 2021 From: duke at openjdk.java.net (duke) Date: Fri, 22 Jan 2021 11:18:10 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 92 new changesets Message-ID: Changeset: 0ec2c969 Author: Jan Lahoda Date: 2021-01-15 12:45:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0ec2c969 8259820: JShell does not handle -source 8 properly Reviewed-by: sundar ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java + test/langtools/jdk/jshell/SourceLevelTest.java Changeset: 707bce08 Author: Conor Cleary Committer: Chris Hegarty Date: 2021-01-15 14:06:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/707bce08 8257212: (bf spec) Clarify byte order of the buffer returned by CharBuffer.subsequence(int,int) Reviewed-by: chegar, bpb, alanb ! src/java.base/share/classes/java/nio/X-Buffer.java.template ! test/jdk/java/nio/Buffer/Order-X.java.template ! test/jdk/java/nio/Buffer/OrderChar.java ! test/jdk/java/nio/Buffer/OrderDouble.java ! test/jdk/java/nio/Buffer/OrderFloat.java ! test/jdk/java/nio/Buffer/OrderInt.java ! test/jdk/java/nio/Buffer/OrderLong.java ! test/jdk/java/nio/Buffer/OrderShort.java Changeset: bbac91a4 Author: Thomas Stuefe Date: 2021-01-15 14:51:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bbac91a4 8257959: Add gtest run with -XX:+UseLargePages Reviewed-by: lfoltan, tschatzl ! test/hotspot/jtreg/TEST.groups + test/hotspot/jtreg/gtest/LargePageGtests.java Changeset: bcf20a0d Author: Jatin Bhateja Date: 2021-01-15 15:03:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bcf20a0d 8259777: Incorrect predication condition generated by ADLC Reviewed-by: vlivanov ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/adlc/formssel.hpp Changeset: eb7fa006 Author: liach Committer: Hannes Walln?fer Date: 2021-01-15 15:12:34 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eb7fa006 8259216: javadoc omits method receiver for any nested type annotation Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/langtools/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java Changeset: b78cd633 Author: Daniel D. Daugherty Date: 2021-01-15 16:53:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b78cd633 8259846: [BACKOUT] JDK-8259278 Optimize Vector API slice and unslice operations Reviewed-by: vlivanov, psandoz ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template Changeset: 360c7226 Author: Phil Race Date: 2021-01-15 17:02:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/360c7226 8259729: Missed JNFInstanceOf -> IsInstanceOf conversion Reviewed-by: serb, psadhukhan, kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m Changeset: 5855d52a Author: Phil Race Date: 2021-01-15 17:04:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5855d52a 8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros Reviewed-by: serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTSurfaceLayers.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CCursorManager.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDataTransferer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDesktopPeer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDragSource.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDragSourceContextPeer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDropTarget.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDropTargetContextPeer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CFRetainedResource.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CFileDialog.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsEnv.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CImage.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CInputMethod.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CMenu.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CMenuBar.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CMenuItem.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPopupMenu.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CTrayIcon.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CWrapper.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/ImageSurfaceData.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/PrintModel.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterSurfaceData.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzRenderer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.m ! src/java.desktop/macosx/native/libawt_lwawt/font/AWTFont.m ! src/java.desktop/macosx/native/libawt_lwawt/font/AWTStrike.m ! src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLGraphicsConfig.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLLayer.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLSurfaceData.m ! src/java.desktop/macosx/native/libosx/CFileManager.m ! src/java.desktop/macosx/native/libosxapp/JNIUtilities.h ! src/java.desktop/macosx/native/libosxui/AquaFileView.m ! src/java.desktop/macosx/native/libosxui/AquaNativeResources.m ! src/java.desktop/macosx/native/libosxui/ScreenMenu.m Changeset: 27a39c8d Author: Sergey Tsypanov Committer: Peter Levart Date: 2021-01-15 17:38:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/27a39c8d 8193031: Collections.addAll is likely to perform worse than Collection.addAll Reviewed-by: plevart ! src/java.base/share/classes/java/util/Collections.java Changeset: 9aa5672a Author: Coleen Phillimore Date: 2021-01-15 17:47:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9aa5672a 8259068: Streamline class loader locking Reviewed-by: dcubed, iklam ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp Changeset: fe84ecd5 Author: Kiran Sidhartha Ravikumar Date: 2021-01-15 19:14:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fe84ecd5 8259048: (tz) Upgrade time-zone data to tzdata2020f Reviewed-by: naoto, erikj ! make/data/tzdata/VERSION ! make/data/tzdata/africa ! make/data/tzdata/asia ! make/data/tzdata/australasia ! make/data/tzdata/backward ! make/data/tzdata/etcetera ! make/data/tzdata/europe ! make/data/tzdata/leapseconds ! make/data/tzdata/northamerica ! make/data/tzdata/zone.tab Changeset: d7d34dd9 Author: Leonid Mesnik Date: 2021-01-15 19:33:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d7d34dd9 8259799: vmTestbase/nsk/jvmti/Breakpoint/breakpoint001 is incorrect Reviewed-by: iignatyev, sspitsyn, cjplummer ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/Breakpoint/breakpoint001/breakpoint001.cpp Changeset: d63388c0 Author: Alex Menkov Date: 2021-01-15 22:40:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d63388c0 8259266: com/sun/jdi/JdbOptions.java failed with "RuntimeException: 'prop[boo] = >foo 2<' missing from stdout/stderr" Reviewed-by: cjplummer, sspitsyn ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/VMConnection.java Changeset: e85892bf Author: Jaroslav Bachorik Date: 2021-01-15 15:12:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e85892bf 8258396: SIGILL in jdk.jfr.internal.PlatformRecorder.rotateDisk() Reviewed-by: egahlin Backport-of: a06cea50a5ea04fb0399d7ea3f6a2a20d9b4d254 ! src/hotspot/share/jfr/recorder/storage/jfrStorage.cpp Changeset: 536082db Author: Jesper Wilhelmsson Date: 2021-01-16 02:46:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/536082db Merge Changeset: 90c73d05 Author: Thomas Stuefe Date: 2021-01-16 05:17:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/90c73d05 8259569: gtest os.dll_address_to_function_and_library_name_vm fails Reviewed-by: dcubed ! test/hotspot/gtest/runtime/test_os.cpp Changeset: bbb93ca3 Author: Pankaj Bansal Date: 2021-01-16 07:52:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bbb93ca3 8256126: Create implementation for NSAccessibilityImage protocol peer Reviewed-by: kizune, serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m = src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ImageAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ImageAccessibility.m Changeset: afd3f78a Author: Sebastian Stenzel Committer: Alan Bateman Date: 2021-01-16 08:36:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/afd3f78a 8030048: (fs) Support UserDefinedFileAttributeView/extended attributes on OS X / HFS+ Reviewed-by: alanb ! src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java ! src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java ! src/java.base/macosx/classes/sun/nio/fs/BsdFileSystemProvider.java ! src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java = src/java.base/macosx/classes/sun/nio/fs/BsdUserDefinedFileAttributeView.java ! src/java.base/macosx/native/libnio/fs/BsdNativeDispatcher.c ! src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template Changeset: 6d6a23e3 Author: Andy Herrick Date: 2021-01-16 14:37:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6d6a23e3 8259062: Remove MacAppStoreBundler Reviewed-by: asemenyuk, almatvee, kizune - src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppStoreBundler.java ! src/jdk.jpackage/macosx/classes/module-info.java.extra Changeset: c3bdbf9d Author: Andy Herrick Date: 2021-01-16 14:38:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c3bdbf9d 8259238: Clean up Log.java and remove usage of non-final static variables. Reviewed-by: asemenyuk, almatvee, kizune ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Log.java ! src/jdk.jpackage/share/classes/jdk/jpackage/main/Main.java Changeset: da4cf05d Author: Andy Herrick Date: 2021-01-16 14:38:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/da4cf05d 8258755: jpackage: Invalid 32-bit exe when building app-image Reviewed-by: asemenyuk, almatvee, kizune ! src/jdk.jpackage/share/native/applauncher/JvmLauncher.cpp ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixPipeline.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixSourcesBuilder.java Changeset: 5f2e280c Author: Alan Bateman Date: 2021-01-17 18:13:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5f2e280c 8259865: (fs) test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java failing on macOS 10.13 Reviewed-by: dcubed ! src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java Changeset: 5dc5d940 Author: Alexander Zuev Date: 2021-01-17 20:39:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5dc5d940 8256110: Create implementation for NSAccessibilityStepper protocol Reviewed-by: pbansal, serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ButtonAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.m Changeset: 68cf65d2 Author: Valerie Peng Date: 2021-01-18 02:26:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/68cf65d2 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 Reviewed-by: weijun ! src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java ! src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java ! src/java.base/share/classes/sun/security/rsa/RSAPublicKeyImpl.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java ! test/jdk/sun/security/pkcs11/rsa/TestKeyFactory.java ! test/jdk/sun/security/rsa/TestKeyFactory.java Changeset: 3f19ef63 Author: Prasanta Sadhukhan Date: 2021-01-18 07:20:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3f19ef63 8202880: Test javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java fails Reviewed-by: aivanov ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java Changeset: 917f7e9a Author: Alexander Zuev Date: 2021-01-18 08:23:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/917f7e9a 8259650: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button" Reviewed-by: jdv ! test/jdk/javax/swing/JComponent/7154030/bug7154030.java Changeset: e93f08e2 Author: Albert Mingkun Yang Committer: Thomas Schatzl Date: 2021-01-18 08:33:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e93f08e2 8074101: Add verification that all tasks are actually claimed during roots processing Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/g1/g1RootProcessor.cpp ! src/hotspot/share/gc/g1/g1RootProcessor.hpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.hpp ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp ! src/hotspot/share/runtime/safepoint.cpp Changeset: ff275b37 Author: Aleksey Shipilev Date: 2021-01-18 10:28:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ff275b37 8259403: Zero: crash with NULL MethodHandle receiver Reviewed-by: coleenp ! src/hotspot/cpu/zero/methodHandles_zero.cpp ! src/hotspot/cpu/zero/methodHandles_zero.hpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/interpreterRuntime.hpp Changeset: 61292be7 Author: Laurent Bourg?s Date: 2021-01-18 11:34:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/61292be7 8259681: Remove the Marlin rendering engine (single-precision) Reviewed-by: serb ! src/java.desktop/share/classes/sun/java2d/marlin/CollinearSimplifier.java ! src/java.desktop/share/classes/sun/java2d/marlin/Curve.java - src/java.desktop/share/classes/sun/java2d/marlin/DCollinearSimplifier.java - src/java.desktop/share/classes/sun/java2d/marlin/DCurve.java - src/java.desktop/share/classes/sun/java2d/marlin/DDasher.java - src/java.desktop/share/classes/sun/java2d/marlin/DHelpers.java ! src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java - src/java.desktop/share/classes/sun/java2d/marlin/DPathSimplifier.java - src/java.desktop/share/classes/sun/java2d/marlin/DRenderer.java - src/java.desktop/share/classes/sun/java2d/marlin/DRendererContext.java - src/java.desktop/share/classes/sun/java2d/marlin/DStroker.java - src/java.desktop/share/classes/sun/java2d/marlin/DTransformingPathConsumer2D.java ! src/java.desktop/share/classes/sun/java2d/marlin/Dasher.java - src/java.desktop/share/classes/sun/java2d/marlin/FloatArrayCache.java ! src/java.desktop/share/classes/sun/java2d/marlin/Helpers.java - src/java.desktop/share/classes/sun/java2d/marlin/IRendererContext.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinCache.java - src/java.desktop/share/classes/sun/java2d/marlin/MarlinRenderer.java - src/java.desktop/share/classes/sun/java2d/marlin/MarlinRenderingEngine.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinTileGenerator.java ! src/java.desktop/share/classes/sun/java2d/marlin/PathSimplifier.java ! src/java.desktop/share/classes/sun/java2d/marlin/Renderer.java ! src/java.desktop/share/classes/sun/java2d/marlin/RendererContext.java ! src/java.desktop/share/classes/sun/java2d/marlin/Stroker.java ! src/java.desktop/share/classes/sun/java2d/marlin/TransformingPathConsumer2D.java ! src/java.desktop/share/classes/sun/java2d/marlin/Version.java ! test/jdk/sun/java2d/marlin/ClipShapeTest.java ! test/jdk/sun/java2d/marlin/StrokedLinePerf.java Changeset: db9c114d Author: Jaikiran Pai Date: 2021-01-18 11:53:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/db9c114d 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection Reviewed-by: alanb, chegar ! src/java.base/share/classes/java/net/URL.java ! src/java.base/share/classes/java/net/URLStreamHandler.java Changeset: e60c9926 Author: Roman Kennke Date: 2021-01-18 15:29:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e60c9926 8259849: Shenandoah: Rename store-val to IU-barrier Reviewed-by: zgu, shade ! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/x86/gc/shenandoah/c1/shenandoahBarrierSetC1_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.hpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp ! src/hotspot/share/gc/shenandoah/mode/shenandoahIUMode.cpp ! src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp ! src/hotspot/share/gc/shenandoah/mode/shenandoahSATBMode.cpp ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp ! src/hotspot/share/opto/classes.hpp ! test/hotspot/jtreg/gc/shenandoah/options/TestSelectiveBarrierFlags.java ! test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierDisable.java ! test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierEnable.java Changeset: 061ffc47 Author: Markus Gr?nlund Date: 2021-01-18 16:14:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/061ffc47 8249245: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant Reviewed-by: egahlin ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp Changeset: 6b4732fe Author: Aleksey Shipilev Date: 2021-01-18 18:42:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6b4732fe 8259679: GitHub actions should use MSVC 14.28 Reviewed-by: ihse, redestad ! .github/workflows/submit.yml Changeset: 533a2d39 Author: Xin Liu Committer: Vladimir Kozlov Date: 2021-01-18 22:34:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/533a2d39 8258961: move some fields of SafePointNode from public to protected Reviewed-by: thartmann, kvn ! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/generateOptoStub.cpp ! src/hotspot/share/opto/parse1.cpp Changeset: 492bebc7 Author: Ioi Lam Date: 2021-01-19 04:32:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/492bebc7 8258004: Remove unnecessary inclusion of vm_version.hpp Reviewed-by: dholmes, stefank ! src/hotspot/cpu/ppc/assembler_ppc.inline.hpp ! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/c2_init_ppc.cpp ! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp ! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c2_init_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp ! src/hotspot/share/asm/assembler.hpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIRAssembler.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp ! src/hotspot/share/jfr/periodic/jfrOSInterface.cpp ! src/hotspot/share/jfr/periodic/jfrPeriodic.cpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/services/diagnosticCommand.cpp Changeset: d5ca3b3f Author: Roland Westrelin Date: 2021-01-18 07:54:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d5ca3b3f 8259641: C2: assert(early->dominates(LCA)) failed: early is high enough Reviewed-by: chagedorn, thartmann ! src/hotspot/share/opto/loopnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestBrokenAntiDependenceWithPhi.java Changeset: cd25bf2e Author: Markus Gr?nlund Date: 2021-01-18 10:22:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cd25bf2e 8259574: SIGSEGV in BFSClosure::closure_impl Reviewed-by: stefank, egahlin ! src/hotspot/share/jfr/leakprofiler/chains/bfsClosure.cpp ! src/hotspot/share/jfr/leakprofiler/chains/rootSetClosure.cpp ! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp Changeset: bb0821eb Author: Alexander Zuev Date: 2021-01-18 22:12:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bb0821eb 8258643: [TESTBUG] javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button" Reviewed-by: trebari, psadhukhan ! test/jdk/javax/swing/JComponent/7154030/bug7154030.java Changeset: a1a851b6 Author: Jesper Wilhelmsson Date: 2021-01-19 05:43:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a1a851b6 Merge ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.cpp Changeset: 14ce8f1a Author: Ioi Lam Date: 2021-01-19 06:44:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/14ce8f1a 8259870: zBarrier.inline.hpp should not include javaClasses.hpp Reviewed-by: stefank, tschatzl ! src/hotspot/share/gc/z/zBarrier.cpp ! src/hotspot/share/gc/z/zBarrier.hpp ! src/hotspot/share/gc/z/zBarrier.inline.hpp Changeset: dfee7b8a Author: Sergey Bylokhov Date: 2021-01-19 07:16:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/dfee7b8a 8259511: java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java failed with "RuntimeException: Test failed: 20 failure(s)" Reviewed-by: jdv ! test/jdk/java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java ! test/jdk/java/awt/Window/MainKeyWindowTest/libTestMainKeyWindow.c Changeset: bd81ccfd Author: Jie Fu Date: 2021-01-19 07:43:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bd81ccfd 8259957: Build failure without C1 Compiler after JDK-8258004 Reviewed-by: dholmes, shade ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp Changeset: 139f5d33 Author: Yasumasa Suenaga Date: 2021-01-19 08:57:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/139f5d33 8259035: Comments for load order of hsdis should be updated Reviewed-by: thartmann ! src/hotspot/share/compiler/disassembler.cpp Changeset: a9519c83 Author: Aleksey Shipilev Date: 2021-01-19 09:38:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a9519c83 8259924: GitHub actions fail on Linux x86_32 with "Could not configure libc6:i386" Reviewed-by: dholmes ! .github/workflows/submit.yml Changeset: 82adfb32 Author: Harold Seigel Date: 2021-01-19 13:44:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/82adfb32 8134540: Much nearly duplicated code for PerfMemory support Reviewed-by: coleenp, dholmes ! src/hotspot/os/aix/os_aix.inline.hpp - src/hotspot/os/aix/perfMemory_aix.cpp ! src/hotspot/os/bsd/os_bsd.inline.hpp - src/hotspot/os/bsd/perfMemory_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/linux/os_linux.hpp ! src/hotspot/os/linux/os_linux.inline.hpp ! src/hotspot/os/posix/os_posix.inline.hpp = src/hotspot/os/posix/perfMemory_posix.cpp Changeset: c0e9c446 Author: Aleksey Shipilev Date: 2021-01-19 14:39:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c0e9c446 8259962: Shenandoah: task queue statistics is inconsistent after JDK-8255019 Reviewed-by: zgu ! src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp Changeset: 5cfb36e7 Author: Markus Gr?nlund Date: 2021-01-19 15:27:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5cfb36e7 8259036: Failed JfrVersionSystem invariant when VM built with -fno-elide-constructors Reviewed-by: egahlin ! src/hotspot/share/jfr/utilities/jfrConcurrentLinkedListHost.inline.hpp ! src/hotspot/share/jfr/utilities/jfrConcurrentQueue.inline.hpp ! src/hotspot/share/jfr/utilities/jfrRefCountPointer.hpp ! src/hotspot/share/jfr/utilities/jfrVersionSystem.hpp ! src/hotspot/share/jfr/utilities/jfrVersionSystem.inline.hpp Changeset: 5d8861b0 Author: Markus Gr?nlund Date: 2021-01-19 16:56:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5d8861b0 8259995: Missing comma to separate years in copyright header Reviewed-by: egahlin ! src/hotspot/share/jfr/utilities/jfrConcurrentLinkedListHost.inline.hpp ! src/hotspot/share/jfr/utilities/jfrVersionSystem.hpp ! src/hotspot/share/jfr/utilities/jfrVersionSystem.inline.hpp Changeset: 3edf393d Author: Aleksey Shipilev Date: 2021-01-19 18:33:18 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3edf393d 8259978: PPC64 builds broken after JDK-8258004 Reviewed-by: lucy, iklam ! src/hotspot/cpu/ppc/nativeInst_ppc.hpp ! src/hotspot/share/oops/method.cpp Changeset: 33dcc00c Author: Kim Barrett Date: 2021-01-19 19:14:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/33dcc00c 8132984: incorrect type for Reference.discovered Use unbounded wildcard placeholders, plus a new helper to get back to the Reference domain. Reviewed-by: rkennke, plevart, rriggs, mchung ! src/java.base/share/classes/java/lang/ref/Reference.java Changeset: a37cd5a3 Author: Zhengyu Gu Date: 2021-01-19 20:01:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a37cd5a3 8259859: Missing metaspace NMT memory tag Reviewed-by: iklam ! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp Changeset: f7b96d34 Author: Martin Buchholz Date: 2021-01-19 18:41:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f7b96d34 8259796: timed CompletableFuture.get may swallow InterruptedException Reviewed-by: dl, alanb ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! test/jdk/java/util/concurrent/CompletableFuture/SwallowedInterruptedException.java Changeset: cf25383d Author: Jesper Wilhelmsson Date: 2021-01-19 22:49:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/cf25383d Merge ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java Changeset: 9f21bb6a Author: Matthias Baesken Date: 2021-01-20 07:49:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f21bb6a 8259983: do not use uninitialized expand_ms value in G1CollectedHeap::expand_heap_after_young_collection Reviewed-by: kbarrett, lucy ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp Changeset: 7c32ffea Author: Tobias Hartmann Date: 2021-01-20 11:48:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7c32ffea 8258383: vmTestbase/gc/g1/unloading/tests/unloading_compilation_level[1,2,3] time out without TieredCompilation Reviewed-by: kvn ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/loading/ClassLoadingHelper.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_inMemoryCompilation_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_inMemoryCompilation_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_inMemoryCompilation_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_inMemoryCompilation_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_inMemoryCompilation_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_inMemoryCompilation_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_inMemoryCompilation_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_inMemoryCompilation_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_inMemoryCompilation_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_inMemoryCompilation_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_inMemoryCompilation_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_inMemoryCompilation_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_keep_obj/TestDescription.java Changeset: 05294802 Author: Eirik Bjorsnos Committer: Claes Redestad Date: 2021-01-20 12:02:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/05294802 8259867: Move encoding checks into ZipCoder Reviewed-by: redestad, lancea ! src/java.base/share/classes/java/util/zip/ZipCoder.java ! src/java.base/share/classes/java/util/zip/ZipFile.java Changeset: 0b01d692 Author: Zhengyu Gu Date: 2021-01-20 13:11:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0b01d692 8260005: Shenandoah: Remove unused AlwaysTrueClosure in ShenandoahConcurrentRootScanner::roots_do() Reviewed-by: shade, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp Changeset: 70b5b311 Author: Stanimir Stamenkov Committer: Alexey Ivanov Date: 2021-01-20 13:34:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/70b5b311 8257664: HTMLEditorKit: Wrong CSS relative font sizes Reviewed-by: aivanov, psadhukhan ! src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java + test/jdk/javax/swing/text/html/StyleSheet/TestWrongCSSFontSize.java Changeset: 52ed2aab Author: Matthias Baesken Date: 2021-01-20 15:04:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/52ed2aab 8259786: initialize last parameter of getpwuid_r Reviewed-by: mdoerr, hseigel ! src/hotspot/os/posix/perfMemory_posix.cpp ! src/jdk.security.auth/unix/native/libjaas/Unix.c Changeset: 69f90b5f Author: Matthias Baesken Date: 2021-01-20 15:08:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/69f90b5f 8259843: initialize dli_fname array before calling dll_address_to_library_name Reviewed-by: lucy, dholmes ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/share/prims/nativeLookup.cpp ! src/hotspot/share/runtime/frame.cpp Changeset: 5891509d Author: Claes Redestad Date: 2021-01-20 15:14:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5891509d 8259947: (fs) Optimize UnixPath.encode implementation Reviewed-by: chegar, shade, alanb ! src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java ! src/java.base/macosx/classes/sun/nio/fs/MacOSXFileSystem.java ! src/java.base/macosx/classes/sun/nio/fs/MacOSXNativeDispatcher.java ! src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java ! src/java.base/unix/classes/sun/nio/fs/UnixPath.java ! test/micro/org/openjdk/bench/java/io/FileOpen.java Changeset: 07851474 Author: Andrew John Hughes Date: 2021-01-20 16:13:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/07851474 8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags Use -march=i686 instead of -march=i586 if -fcf-protection is passed to the build as CMOV is required Reviewed-by: erikj ! make/autoconf/flags-cflags.m4 Changeset: 4f11ff32 Author: Zhengyu Gu Date: 2021-01-20 21:41:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4f11ff32 8259488: Shenandoah: Missing timing tracking for STW CLD root processing Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp Changeset: 8b95d954 Author: Hai-May Chao Committer: Sean Mullan Date: 2021-01-20 22:23:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8b95d954 8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension Reviewed-by: jnimeh, mullan ! src/java.base/share/classes/sun/security/provider/certpath/OCSPNonceExtension.java ! src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/SSLCA.java ! test/jdk/sun/security/provider/certpath/Extensions/OCSPNonceExtensionTests.java Changeset: 1f47de5f Author: Claes Redestad Date: 2021-01-20 23:42:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1f47de5f 8260010: UTF8ZipCoder not thread-safe since JDK-8243469 Reviewed-by: lancea ! src/java.base/share/classes/java/util/zip/ZipCoder.java Changeset: 27cc62a5 Author: Claes Redestad Date: 2021-01-20 23:42:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/27cc62a5 8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException Reviewed-by: jvernee, mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template ! test/jdk/java/lang/invoke/VarHandles/VarHandleBaseTest.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessByte.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessChar.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessDouble.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessFloat.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessShort.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessString.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessBoolean.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessChar.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessDouble.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessFloat.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessInt.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessLong.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessShort.java ! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessString.java ! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template ! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template ! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template Changeset: 35c9da70 Author: Claes Redestad Date: 2021-01-20 23:45:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/35c9da70 8259498: Reduce overhead of MD5 and SHA digests Reviewed-by: valeriep ! src/java.base/share/classes/sun/security/provider/ByteArrayAccess.java ! src/java.base/share/classes/sun/security/provider/MD4.java ! src/java.base/share/classes/sun/security/provider/MD5.java ! src/java.base/share/classes/sun/security/provider/SHA.java ! src/java.base/share/classes/sun/security/provider/SHA2.java ! src/java.base/share/classes/sun/security/provider/SHA5.java ! test/micro/org/openjdk/bench/java/security/MessageDigests.java ! test/micro/org/openjdk/bench/java/util/UUIDBench.java Changeset: 77a43023 Author: David Holmes Date: 2021-01-21 02:41:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/77a43023 8223056: Remove Type-Stable-Memory support for Parkers Reviewed-by: coleenp, rehn ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/posix/os_posix.hpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os/windows/os_windows.hpp ! src/hotspot/share/prims/unsafe.cpp ! src/hotspot/share/runtime/park.cpp ! src/hotspot/share/runtime/park.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: 044bae0e Author: Ioi Lam Date: 2021-01-21 03:54:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/044bae0e 8260191: Do not include access.hpp in oop.hpp Reviewed-by: kbarrett ! src/hotspot/share/gc/z/zBarrierSetRuntime.cpp ! src/hotspot/share/oops/oop.hpp Changeset: 01205109 Author: Leo Jiang Date: 2021-01-20 13:58:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/01205109 8259732: JDK 16 L10n resource file update - msg drop 10 Reviewed-by: naoto ! src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_ja.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_ja.properties ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_ja.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_zh_CN.properties ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/LinuxResources_ja.properties ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/LinuxResources_zh_CN.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_ja.properties ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_zh_CN.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_ja.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_zh_CN.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_ja.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_zh_CN.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties ! src/jdk.jshell/share/classes/jdk/jshell/resources/l10n_ja.properties ! src/jdk.jshell/share/classes/jdk/jshell/resources/l10n_zh_CN.properties Changeset: 0408b23b Author: Igor Ignatyev Date: 2021-01-20 18:48:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0408b23b 8259757: add a regression test for 8259353 and 8259601 Co-authored-by: Xiaohong Gong Co-authored-by: Igor Ignatyev Reviewed-by: kvn, jiefu + test/hotspot/jtreg/compiler/vectorapi/Test8259353.java Changeset: 133bcb09 Author: Jesper Wilhelmsson Date: 2021-01-21 05:23:42 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/133bcb09 Merge ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties Changeset: f8a9602a Author: Yasumasa Suenaga Date: 2021-01-21 06:08:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f8a9602a 8260025: Missing comma in VM_Version_Ext::_family_id_amd Reviewed-by: dholmes, stuefe ! src/hotspot/cpu/x86/vm_version_ext_x86.cpp Changeset: 5940287b Author: Aleksey Shipilev Date: 2021-01-21 07:21:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5940287b 8260048: Shenandoah: ShenandoahMarkingContext asserts are unnecessary Reviewed-by: zgu, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.inline.hpp Changeset: 7f7166db Author: Prasanta Sadhukhan Date: 2021-01-21 08:27:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7f7166db 8260035: Deproblemlist few problemlisted test Reviewed-by: jdv ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JMenuItem/6249972/bug6249972.java ! test/jdk/javax/swing/JTree/6263446/bug6263446.java ! test/jdk/javax/swing/plaf/basic/Test6984643.java Changeset: 4dfd8cc4 Author: Thomas Stuefe Date: 2021-01-21 10:30:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4dfd8cc4 8259897: gtest os.dll_address_to_function_and_library_name_vm fails on AIX Reviewed-by: mdoerr ! test/hotspot/gtest/runtime/test_os.cpp Changeset: e1de0bf8 Author: Eirik Bjorsnos Committer: Claes Redestad Date: 2021-01-21 10:37:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e1de0bf8 8260043: Reduce allocation in sun.net.www.protocol.jar.Handler.parseURL Reviewed-by: redestad, chegar ! src/java.base/share/classes/sun/net/www/ParseUtil.java ! src/java.base/share/classes/sun/net/www/protocol/jar/Handler.java Changeset: 4bcffeb9 Author: Fei Yang Date: 2021-01-21 11:58:23 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4bcffeb9 8260029: aarch64: fix typo in verify_oop_array Co-authored-by: Zhuxuan Ni Reviewed-by: shade, aph ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Changeset: 6ce0799b Author: Albert Mingkun Yang Committer: Thomas Schatzl Date: 2021-01-21 12:10:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6ce0799b 8259851: Use boolean type for tasks in SubTasksDone Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/shared/workgroup.cpp ! src/hotspot/share/gc/shared/workgroup.hpp Changeset: c3c66625 Author: Aleksey Shipilev Date: 2021-01-21 13:32:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c3c66625 8259954: gc/shenandoah/mxbeans tests fail with -Xcomp Reviewed-by: rkennke, zgu ! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java ! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestPauseNotifications.java Changeset: 34eb8b34 Author: Zhengyu Gu Date: 2021-01-21 16:55:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/34eb8b34 8255765: Shenandoah: Isolate concurrent, degenerated and full GC Reviewed-by: rkennke, shade ! src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.hpp + src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp + src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp + src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp + src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.hpp + src/hotspot/share/gc/shenandoah/shenandoahGC.cpp + src/hotspot/share/gc/shenandoah/shenandoahGC.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.hpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp Changeset: a8073efe Author: Brian Burkhalter Date: 2021-01-21 21:36:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a8073efe 8253478: (se) epoll Selector should use eventfd for wakeup instead of pipe Reviewed-by: alanb ! src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java + src/java.base/linux/classes/sun/nio/ch/EventFD.java + src/java.base/linux/native/libnio/ch/EventFD.c + test/micro/org/openjdk/bench/java/nio/SelectorWakeup.java Changeset: 2f47c39a Author: Brian Burkhalter Date: 2021-01-21 21:54:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2f47c39a 8259943: FileDescriptor.close0 does not handle EINTR Reviewed-by: naoto, alanb ! src/java.base/unix/native/libjava/io_util_md.c Changeset: a7c2ebc7 Author: Sergey Bylokhov Date: 2021-01-22 00:21:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a7c2ebc7 8239894: Xserver crashes when the wrong high refresh rate is used Reviewed-by: kizune ! src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java ! src/java.desktop/unix/native/common/awt/systemscale/systemScale.c ! src/java.desktop/unix/native/common/awt/systemscale/systemScale.h ! src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c ! src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c Changeset: 92c2f084 Author: Phil Race Date: 2021-01-22 01:50:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/92c2f084 8259869: [macOS] Remove desktop module dependencies on JNF Reference APIs Reviewed-by: serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDragSource.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDragSourceContextPeer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDropTarget.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDropTargetContextPeer.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CFileDialog.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsEnv.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CInputMethod.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CMenuComponent.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPopupMenu.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/CTrayIcon.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/ImageSurfaceData.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityAction.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLLayer.h ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLLayer.m ! src/java.desktop/macosx/native/libosxui/ScreenMenu.m Changeset: ba386615 Author: Ioi Lam Date: 2021-01-22 04:20:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ba386615 8259882: Reduce the inclusion of perfData.hpp Reviewed-by: redestad, coleenp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileBroker.hpp ! src/hotspot/share/gc/epsilon/epsilonMonitoringSupport.cpp ! src/hotspot/share/gc/shared/ageTable.cpp ! src/hotspot/share/gc/shared/ageTable.hpp ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shared/generationCounters.cpp ! src/hotspot/share/gc/shared/generationCounters.hpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp ! src/hotspot/share/runtime/arguments.hpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp ! src/hotspot/share/runtime/perfData.hpp + src/hotspot/share/runtime/perfDataTypes.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/runtime/vmThread.hpp ! src/hotspot/share/services/management.hpp Changeset: a70acf2c Author: Aleksey Shipilev Date: 2021-01-22 07:05:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a70acf2c 8259928: compiler/jvmci tests fail with -Xint Reviewed-by: kvn, iignatyev ! test/jtreg-ext/requires/VMProps.java Changeset: 14522800 Author: Prasanta Sadhukhan Date: 2021-01-22 08:02:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/14522800 8164484: Unity, JTable cell editor, javax/swing/JComboBox/6559152/bug6559152.java Reviewed-by: serb, jdv ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JComboBox/6559152/bug6559152.java Changeset: d066f2b0 Author: Thomas Stuefe Date: 2021-01-22 09:00:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d066f2b0 8260030: Improve stringStream buffer handling Reviewed-by: iklam, kbarrett ! src/hotspot/share/utilities/ostream.cpp ! src/hotspot/share/utilities/ostream.hpp ! test/hotspot/gtest/utilities/test_ostream.cpp Changeset: 5f05e377 Author: duke Date: 2021-01-22 11:01:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5f05e377 Automatic merge of jdk:master into master Changeset: aea0196d Author: duke Date: 2021-01-22 11:01:25 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aea0196d Automatic merge of master into foreign-memaccess+abi Changeset: 7df3a0e5 Author: duke Date: 2021-01-22 11:01:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7df3a0e5 Automatic merge of foreign-memaccess+abi into foreign-jextract From sviswanathan at openjdk.java.net Fri Jan 22 18:57:29 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 22 Jan 2021 18:57:29 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master [v2] In-Reply-To: References: Message-ID: <6xmXOsH9FxGmQrRwVY_N_riK1wHjmkgHSPjNdcicQPc=.4439da7a-1b79-45f4-838e-547aa5cde93a@github.com> > This pull request merges master changes into vectorIntrinsics. > Please review. > > Best Regards, > Sandhya Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision: update asmtest.out.h ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/33/files - new: https://git.openjdk.java.net/panama-vector/pull/33/files/e6c1778f..6b3f851d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=33&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=33&range=00-01 Stats: 1168 lines in 1 file changed: 0 ins; 0 del; 1168 mod Patch: https://git.openjdk.java.net/panama-vector/pull/33.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/33/head:pull/33 PR: https://git.openjdk.java.net/panama-vector/pull/33 From sviswanathan at openjdk.java.net Fri Jan 22 20:05:45 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 22 Jan 2021 20:05:45 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master [v3] In-Reply-To: References: Message-ID: > This pull request merges master changes into vectorIntrinsics. > Please review. > > Best Regards, > Sandhya Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 687 commits: - corrected permissions - jcheck fix - update asmtest.out.h - Merge - 8258072: Add Reinterpret nodes implementation for Arm SVE Co-authored-by: He Xuejin Reviewed-by: njian, xgong - Merge panama-vector:master Reviewed-by: sviswanathan - Add utf8 decoding benchmarks Reviewed-by: sviswanathan - Merge panama-vector:master Reviewed-by: sviswanathan - Load/store short vectors from/to char[] Reviewed-by: sviswanathan - Conversion test refactor Reviewed-by: sviswanathan - ... and 677 more: https://git.openjdk.java.net/panama-vector/compare/07851474...4189ef9c ------------- Changes: https://git.openjdk.java.net/panama-vector/pull/33/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=33&range=02 Stats: 485844 lines in 309 files changed: 485429 ins; 167 del; 248 mod Patch: https://git.openjdk.java.net/panama-vector/pull/33.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/33/head:pull/33 PR: https://git.openjdk.java.net/panama-vector/pull/33 From sviswanathan at openjdk.java.net Fri Jan 22 20:05:52 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 22 Jan 2021 20:05:52 GMT Subject: [vectorIntrinsics] Integrated: Merge panama-vector:master In-Reply-To: References: Message-ID: On Thu, 21 Jan 2021 21:38:12 GMT, Sandhya Viswanathan wrote: > This pull request merges master changes into vectorIntrinsics. > Please review. > > Best Regards, > Sandhya This pull request has now been integrated. Changeset: fcc36ceb Author: Sandhya Viswanathan URL: https://git.openjdk.java.net/panama-vector/commit/fcc36ceb Stats: 132070 lines in 3307 files changed: 71226 ins; 37684 del; 23160 mod Merge panama-vector:master ------------- PR: https://git.openjdk.java.net/panama-vector/pull/33 From sviswanathan at openjdk.java.net Fri Jan 22 20:05:49 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 22 Jan 2021 20:05:49 GMT Subject: [vectorIntrinsics] RFR: Merge panama-vector:master [v3] In-Reply-To: References: Message-ID: <_GkZ7RKta8Yo1kIN0lSQcVagfV1uMuKey4uHi8ttQSk=.58f6d489-8bea-4741-b1ca-b1c48133d255@github.com> On Fri, 22 Jan 2021 06:07:18 GMT, Ningsheng Jian wrote: >> Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 687 commits: >> >> - corrected permissions >> - jcheck fix >> - update asmtest.out.h >> - Merge >> - 8258072: Add Reinterpret nodes implementation for Arm SVE >> >> Co-authored-by: He Xuejin >> Reviewed-by: njian, xgong >> - Merge panama-vector:master >> >> Reviewed-by: sviswanathan >> - Add utf8 decoding benchmarks >> >> Reviewed-by: sviswanathan >> - Merge panama-vector:master >> >> Reviewed-by: sviswanathan >> - Load/store short vectors from/to char[] >> >> Reviewed-by: sviswanathan >> - Conversion test refactor >> >> Reviewed-by: sviswanathan >> - ... and 677 more: https://git.openjdk.java.net/panama-vector/compare/07851474...4189ef9c > > test/hotspot/gtest/aarch64/asmtest.out.h line 540: > >> 538: __ sminv(v23, __ T16B, v24); // sminv b23, v24.16B >> 539: __ sminv(v4, __ T4H, v5); // sminv h4, v5.4H >> 540: __ sminv(v19, __ T8H, v20); // sminv h19, v20.8H > > A manual merge seems not working fine for this file to resolve conflicts. I will sent you the regenerated file. @nsjian Thanks a lot. I pushed the regenerated asmtest.out.h. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/33 From github.com+7535718+rsmogura at openjdk.java.net Fri Jan 22 20:58:55 2021 From: github.com+7535718+rsmogura at openjdk.java.net (Radoslaw Smogura) Date: Fri, 22 Jan 2021 20:58:55 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v4] In-Reply-To: References: Message-ID: On Wed, 20 Jan 2021 14:20:39 GMT, Maurizio Cimadamore wrote: >> Radoslaw Smogura has updated the pull request incrementally with one additional commit since the last revision: >> >> Replaced the stride access with normal VarHandle. >> >> Added no_align benchmakr, to compare preformance with alignments checks turned off. >> ``` >> Benchmark Mode Cnt Score Error Units >> LoopOverNonConstant.BB_get avgt 30 3.892 ? 0.012 ns/op >> LoopOverNonConstant.BB_loop avgt 30 0.230 ? 0.001 ms/op >> LoopOverNonConstant.global_segment_get avgt 30 3.887 ? 0.008 ns/op >> LoopOverNonConstant.global_segment_loop avgt 30 0.396 ? 0.002 ms/op >> LoopOverNonConstant.global_segment_loop_no_align avgt 30 0.247 ? 0.001 ms/op >> LoopOverNonConstant.segment_get avgt 30 5.489 ? 0.014 ns/op >> LoopOverNonConstant.segment_loop avgt 30 0.229 ? 0.001 ms/op >> LoopOverNonConstant.segment_loop_readonly avgt 30 0.236 ? 0.001 ms/op >> LoopOverNonConstant.segment_loop_slice avgt 30 0.241 ? 0.001 ms/op >> LoopOverNonConstant.segment_loop_static avgt 30 0.230 ? 0.001 ms/op >> LoopOverNonConstant.unsafe_get avgt 30 3.425 ? 0.006 ns/op >> LoopOverNonConstant.unsafe_loop avgt 30 0.230 ? 0.001 ms/op >> ``` >> Not optimized `ofNativeRestricted` >> ``` >> LoopOverNonConstant.global_segment_get avgt 30 4.126 ? 0.006 ns/op >> LoopOverNonConstant.global_segment_loop avgt 30 0.603 ? 0.001 ms/op >> ``` > > Looks good for now - we can reassess after the hotspot improvements for long in loops start to have visible effects. Thanks! Hi all, I realized that my benchmarks contains small issue. I think @mcimadamore mentioned it, but I did not understood. The loops are counted using long instead of int. With int I've seen the loop get unrolled and the aligned to 1 loop is as fast as other tests. I'm not sure if at this stage I c an add modified benchmarks or should I opens new PR? ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/437 From mcimadamore at openjdk.java.net Fri Jan 22 22:18:51 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 22 Jan 2021 22:18:51 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 20:55:41 GMT, Radoslaw Smogura wrote: > Hi all, > > I realized that my benchmarks contains small issue. I think @mcimadamore mentioned it, but I did not understood. > > The loops are counted using long instead of int. With int I've seen the loop get unrolled and the aligned to 1 loop is as fast as other tests. > > I'm not sure if at this stage I c an add modified benchmarks or should I opens new PR? Hi, this PR is still open, since I forgot to integrate it (sorry). But this means that we can decide what to do. I see the issue with the benchmark - well spotted. At this point, to be honest, I'm unsure about the value of the proposed patch. It helps a bit for long loops, yes, but in the idiomatic use (e.g. with int) performances are the same. Given that better VM support for long loops is on the way, I'm not sure we should add more workarounds for longs (as it's proving already difficult to keep an inventory of all the hacks we have in the implementation in order to eliminate this hotspot issue). Would you be ok with just closing the PR, or, maybe just add the (revised) benchmark for the everything segment (which we don't currently have) ? Thanks! ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/437 From duncan.gittins at gmail.com Sat Jan 23 18:34:25 2021 From: duncan.gittins at gmail.com (Duncan Gittins) Date: Sat, 23 Jan 2021 18:34:25 +0000 Subject: Feedback / query on jextract for Windows 10 Message-ID: <0e35502c-3656-9c23-eca8-4ca8a4377d15@gmail.com> I've been using Panama on Windows 10 to eliminate my C# apps which I would normally call via ProcessBuilder. I'm very impressed so far and looking forward to newer versions: everything I have written in Windows C# is now replaced with foreign memory / linker calls to native code using the latest Java 16 EA.? I have examples for various Win32 API and COM objects, HWND objects and screensaver. However I'm struggling to get the code running with output from jextract build. Perhaps I overlooked something very obvious in how to setup? One example app is attached - this calls SystemParametersInfoA to set the Windows desktop background. There are two implementations of setImage: one with hardwired MethodHandle works fine, but the jextract version gives UnsupportedOperationException for layout unrelated to SystemParametersInfoA. If I edit the generated code to comment out all lines unrelated to SystemParametersInfoA then both versions of setImage work. The jextract command on Windows 10 (with fresh Vis Studio installation) expands shlobj_core.h because I my app also uses IShellLink. ???? set "WINKIT=c:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0" ???? jextract --source -t duncan.win32.shobjidl_core -d shlobj_core.h/java ??? "%WINKIT%/um/shlobj_core.h" Another issue is that this single windows header file gives rise to 11MB jar and is unusable inside Eclipse (on my slow PC), and is slow startup at runtime. Have you considered changing the generated code to use lazy Supplier instead of MethodHandle to ensure only required handles are created on-demand? Kind regards Duncan -------------- next part -------------- package duncan.sample; import java.nio.file.Path; import java.util.concurrent.TimeUnit; import java.util.function.Supplier; import duncan.win32.shobjidl_core.shlobj_core_h; //import duncan.win32.shobjidl_core.shlobj_core_h$19; import jdk.incubator.foreign.*; import java.lang.invoke.MethodHandle; import java.lang.invoke.MethodType; /** %JAVAHOME%\bin\java -Dforeign.restricted=permit --add-modules jdk.incubator.foreign -Dfile.encoding=UTF-8 -cp C:\dev\jars\samplepanama.jar;C:\dev\jars\jextract-shlobj_core.h.jar duncan.sample.Screen "C:\Temp\sm all\1.jpg" All Windows native calls fail with same error, when initialising the same layout (not related to the actual calls being made) shlobj_core_h$constants$16.java:1844 is: static final VarHandle _NT_TIB$ArbitraryUserPointer$VH_ = MemoryHandles.asAddressVarHandle(_NT_TIB$struct$LAYOUT_.varHandle(long.class, MemoryLayout.PathElement.groupElement("ArbitraryUserPointer"))); Note - no runtime issues if commenting out all lines unrelated to SystemParametersInfoA Exception in thread "main" java.lang.AssertionError: java.lang.ExceptionInInitializerError at duncan.win32.shobjidl_core.shlobj_core_h$19.SystemParametersInfoA(shlobj_core_h$19.java:552) at duncan.sample.Screen.setImage(Screen.java:49) at duncan.sample.Screen.main(Screen.java:64) Caused by: java.lang.ExceptionInInitializerError at duncan.win32.shobjidl_core.shlobj_core_h$19.SystemParametersInfoA(shlobj_core_h$19.java:550) ... 2 more Caused by: java.lang.UnsupportedOperationException: Invalid alignment requirements for layout b64(ArbitraryUserPointer)[abi/kind=POINTER,layout/name=ArbitraryUserPointer] at jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.checkAlignment(LayoutPath.java:273) at jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.dereferenceHandle(LayoutPath.java:159) at jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.lambda$varHandle$2(MemoryLayout.java:488) at jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.computePathOp(MemoryLayout.java:534) at jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.varHandle(MemoryLayout.java:488) at duncan.win32.shobjidl_core.shlobj_core_h$constants$16.(shlobj_core_h$constants$16.java:1844) */ public class Screen { private static void Win32_checkThat(boolean condition, Supplier error) { if (!condition) { String message = error.get(); System.err.println(message); throw new RuntimeException(message); } } private static final int SPI_SETDESKWALLPAPER = 0x0014; //shlobj_core_h.SPI_SETDESKWALLPAPER(); private static final int SPIF_UPDATEINIFILE = 0x01; // shlobj_core_h.SPIF_UPDATEINIFILE(); private static final int SPIF_SENDCHANGE = 0x02; // shlobj_core_h.SPIF_SENDCHANGE(); private static void setImage(String path) throws Throwable { final long t0 = System.nanoTime(); try (NativeScope scope = NativeScope.unboundedScope()) { MemorySegment img = CLinker.toCString(path, /*StandardCharsets.UTF_16LE,*/ scope); // int status = shlobj_core_h$19.SystemParametersInfoA(SPI_SETDESKWALLPAPER, 0, img.address(), SPIF_UPDATEINIFILE | SPIF_SENDCHANGE); int status = shlobj_core_h.SystemParametersInfoA(SPI_SETDESKWALLPAPER, 0, img.address(), SPIF_UPDATEINIFILE | SPIF_SENDCHANGE); Win32_checkThat(status != 0, () -> "setImage status="+status+" path="+path); } final long now = System.nanoTime(); System.out.println("setImage ms="+TimeUnit.NANOSECONDS.toMillis(now - t0)+" "+path); } private static void setImageWORKS(String path) throws Throwable { final long t0 = System.nanoTime(); LibraryLookup user32 = LibraryLookup.ofLibrary("user32"); MethodHandle spi = CLinker.getInstance().downcallHandle(user32.lookup("SystemParametersInfoA").get() // BOOL SystemParametersInfoA (UINT uiAction, UINT uiParam, PVOID pvParam, UINT fWinIni); , MethodType.methodType(int.class, int.class, int.class, MemoryAddress.class, int.class) , FunctionDescriptor.of(CLinker.C_LONG,CLinker.C_LONG, CLinker.C_LONG, CLinker.C_POINTER, CLinker.C_LONG)); try (NativeScope scope = NativeScope.unboundedScope()) { MemorySegment img = CLinker.toCString(path, scope); int status = (int)spi.invokeExact(SPI_SETDESKWALLPAPER, 0, img.address(), SPIF_UPDATEINIFILE | SPIF_SENDCHANGE); Win32_checkThat(status != 0, () -> "setImageWORKS status="+status+" path="+path); } final long now = System.nanoTime(); System.out.println("setImageWORKS ms="+TimeUnit.NANOSECONDS.toMillis(now - t0)+" "+path); } public static void main(String[] args) throws Throwable { if (args.length == 0) throw new IllegalArgumentException("Usage: "+Screen.class.getClass().getName()+" {image}"); for(String arg : args) { String p = Path.of(arg).toAbsolutePath().toString(); setImageWORKS(p); setImage(p); } } } From maurizio.cimadamore at oracle.com Mon Jan 25 10:20:50 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 25 Jan 2021 10:20:50 +0000 Subject: Feedback / query on jextract for Windows 10 In-Reply-To: <0e35502c-3656-9c23-eca8-4ca8a4377d15@gmail.com> References: <0e35502c-3656-9c23-eca8-4ca8a4377d15@gmail.com> Message-ID: On 23/01/2021 18:34, Duncan Gittins wrote: > I've been using Panama on Windows 10 to eliminate my C# apps which I > would normally call via ProcessBuilder. I'm very impressed so far and > looking forward to newer versions: everything I have written in > Windows C# is now replaced with foreign memory / linker calls to > native code using the latest Java 16 EA.? I have examples for various > Win32 API and COM objects, HWND objects and screensaver. However I'm > struggling to get the code running with output from jextract build. > Perhaps I overlooked something very obvious in how to setup? > > One example app is attached - this calls SystemParametersInfoA to set > the Windows desktop background. There are two implementations of > setImage: one with hardwired MethodHandle works fine, but the jextract > version gives UnsupportedOperationException for layout unrelated to > SystemParametersInfoA. If I edit the generated code to comment out all > lines unrelated to SystemParametersInfoA then both versions of > setImage work. I think the culprit is this: ``` Caused by: java.lang.UnsupportedOperationException: Invalid alignment requirements for layout b64(ArbitraryUserPointer)[abi/kind=POINTER,layout/name=ArbitraryUserPointer] ??????? at jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.checkAlignment(LayoutPath.java:273) ??????? at jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.dereferenceHandle(LayoutPath.java:159) ??????? at jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.lambda$varHandle$2(MemoryLayout.java:488) ??????? at jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.computePathOp(MemoryLayout.java:534) ??????? at jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.varHandle(MemoryLayout.java:488) ??????? at duncan.win32.shobjidl_core.shlobj_core_h$constants$16.(shlobj_core_h$constants$16.java:1844) ``` This seems a duplicate of another issue that has been reported last week: https://bugs.openjdk.java.net/browse/JDK-8259832 E.g. jextract ignoring alignment requirements. Note that jextract generates lots of constants, and it takes only one bad one to make initialization fail. > > The jextract command on Windows 10 (with fresh Vis Studio > installation) expands shlobj_core.h because I my app also uses > IShellLink. > > ???? set "WINKIT=c:\Program Files (x86)\Windows > Kits\10\Include\10.0.18362.0" > ???? jextract --source -t duncan.win32.shobjidl_core -d > shlobj_core.h/java ??? "%WINKIT%/um/shlobj_core.h" > > Another issue is that this single windows header file gives rise to > 11MB jar and is unusable inside Eclipse (on my slow PC), and is slow > startup at runtime. Have you considered changing the generated code to > use lazy Supplier instead of MethodHandle to ensure only > required handles are created on-demand? Uhm... we are already using dynamic constants, so you should only pay for the MHs and VHs you use - e.g. in fact I'm even surprised you get the failure inside the above - since that constant should not be initialized unless it's used. I wonder if there's a regression here... are you using the `--source` flag? With that flag we revert back to a monolithic header, so that will explain both failures. If so, try removing that flag - and see what happens (if everything is working as it should I don't think you should even see the error above, assuming you never use that layout). Maurizio > > Kind regards > > Duncan > > From sundar at openjdk.java.net Mon Jan 25 15:16:21 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Mon, 25 Jan 2021 15:16:21 GMT Subject: [foreign-jextract] RFR: 8260344: jextract crashes with exception for log.h from libdebian-installer4-dev Message-ID: Fixed type handling in createFunction when typedef on function pointer is used. ------------- Commit messages: - 8260344: jextract crashes with exception for log.h from libdebian-installer4-dev Changes: https://git.openjdk.java.net/panama-foreign/pull/439/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=439&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260344 Stats: 94 lines in 3 files changed: 93 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/439.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/439/head:pull/439 PR: https://git.openjdk.java.net/panama-foreign/pull/439 From mcimadamore at openjdk.java.net Mon Jan 25 16:10:54 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 25 Jan 2021 16:10:54 GMT Subject: [foreign-jextract] RFR: 8260344: jextract crashes with exception for log.h from libdebian-installer4-dev In-Reply-To: References: Message-ID: On Mon, 25 Jan 2021 15:10:37 GMT, Athijegannathan Sundararajan wrote: > Fixed type handling in createFunction when typedef on function pointer is used. Looks good ------------- Marked as reviewed by mcimadamore (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/439 From duncan.gittins at gmail.com Mon Jan 25 16:13:30 2021 From: duncan.gittins at gmail.com (Duncan Gittins) Date: Mon, 25 Jan 2021 16:13:30 +0000 Subject: Feedback / query on jextract for Windows 10 In-Reply-To: References: <0e35502c-3656-9c23-eca8-4ca8a4377d15@gmail.com> Message-ID: <52aa2217-0795-a27b-8173-78b06be3f25b@gmail.com> Thanks for the information.? As you suspected that bug must be related and there is a minor difference in the --source output because the problem does go away when removing the jextract "--source" flag and making jar directly from generated classes rather than just compiling from the generated source code. My code samples using jextract bindings are ~300ms slower at startup time (but same speed runtime). I'm not certain if this overhead is down to initialisation of static constants or simply to be expected when adding 11MB jar footprint (compared to 56k jar for my handwritten MH bindings). I will follow-up if I find out more. Looking at the generated code for "xxx$constants$nn.java" there seems to be a degree of unnecessary initialisation per xxx$constants$nn class as it contains static variables for FunctionDescriptor / MemoryLayout which would be initialised every time that particular class was loaded and not used in my code. I felt that my own jar was slow starting so switched foreign linker references to a lazy load Supplier for every library / symbol / mh / vh so that only the referenced types get created. I will have a look at future builds - this project is extremely useful so I hope it gets into a full JDK release soon. Unfortunately my issue with a huge jar in Eclipse means I can't easily develop using the generated code variant right now, but in the meantime the jextract code is still very helpful to work out how to call Windows APIs correctly. Duncan On 25/01/2021 10:20, Maurizio Cimadamore wrote: > > On 23/01/2021 18:34, Duncan Gittins wrote: >> I've been using Panama on Windows 10 to eliminate my C# apps which I >> would normally call via ProcessBuilder. I'm very impressed so far and >> looking forward to newer versions: everything I have written in >> Windows C# is now replaced with foreign memory / linker calls to >> native code using the latest Java 16 EA.? I have examples for various >> Win32 API and COM objects, HWND objects and screensaver. However I'm >> struggling to get the code running with output from jextract build. >> Perhaps I overlooked something very obvious in how to setup? >> >> One example app is attached - this calls SystemParametersInfoA to set >> the Windows desktop background. There are two implementations of >> setImage: one with hardwired MethodHandle works fine, but the >> jextract version gives UnsupportedOperationException for layout >> unrelated to SystemParametersInfoA. If I edit the generated code to >> comment out all lines unrelated to SystemParametersInfoA then both >> versions of setImage work. > > I think the culprit is this: > > ``` > Caused by: java.lang.UnsupportedOperationException: Invalid alignment > requirements for layout > b64(ArbitraryUserPointer)[abi/kind=POINTER,layout/name=ArbitraryUserPointer] > ??????? at > jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.checkAlignment(LayoutPath.java:273) > ??????? at > jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.dereferenceHandle(LayoutPath.java:159) > ??????? at > jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.lambda$varHandle$2(MemoryLayout.java:488) > ??????? at > jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.computePathOp(MemoryLayout.java:534) > ??????? at > jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.varHandle(MemoryLayout.java:488) > ??????? at > duncan.win32.shobjidl_core.shlobj_core_h$constants$16.(shlobj_core_h$constants$16.java:1844) > ``` > > This seems a duplicate of another issue that has been reported last week: > > https://bugs.openjdk.java.net/browse/JDK-8259832 > > E.g. jextract ignoring alignment requirements. Note that jextract > generates lots of constants, and it takes only one bad one to make > initialization fail. > >> >> The jextract command on Windows 10 (with fresh Vis Studio >> installation) expands shlobj_core.h because I my app also uses >> IShellLink. >> >> ???? set "WINKIT=c:\Program Files (x86)\Windows >> Kits\10\Include\10.0.18362.0" >> ???? jextract --source -t duncan.win32.shobjidl_core -d >> shlobj_core.h/java ??? "%WINKIT%/um/shlobj_core.h" >> >> Another issue is that this single windows header file gives rise to >> 11MB jar and is unusable inside Eclipse (on my slow PC), and is slow >> startup at runtime. Have you considered changing the generated code >> to use lazy Supplier instead of MethodHandle to ensure >> only required handles are created on-demand? > > Uhm... we are already using dynamic constants, so you should only pay > for the MHs and VHs you use - e.g. in fact I'm even surprised you get > the failure inside the above - since that constant should not > be initialized unless it's used. I wonder if there's a regression > here... are you using the `--source` flag? With that flag we revert > back to a monolithic header, so that will explain both failures. If > so, try removing that flag - and see what happens (if everything is > working as it should I don't think you should even see the error > above, assuming you never use that layout). > > Maurizio > >> >> Kind regards >> >> Duncan >> >> From maurizio.cimadamore at oracle.com Mon Jan 25 16:18:58 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 25 Jan 2021 16:18:58 +0000 Subject: [External] : Re: Feedback / query on jextract for Windows 10 In-Reply-To: <52aa2217-0795-a27b-8173-78b06be3f25b@gmail.com> References: <0e35502c-3656-9c23-eca8-4ca8a4377d15@gmail.com> <52aa2217-0795-a27b-8173-78b06be3f25b@gmail.com> Message-ID: <145ff947-5de4-3d7e-17b9-074842b0f2ce@oracle.com> On 25/01/2021 16:13, Duncan Gittins wrote: > Thanks for the information.? As you suspected that bug must be related > and there is a minor difference in the --source output because the > problem does go away when removing the jextract "--source" flag and > making jar directly from generated classes rather than just compiling > from the generated source code. > > My code samples using jextract bindings are ~300ms slower at startup > time (but same speed runtime). I'm not certain if this overhead is > down to initialisation of static constants or simply to be expected > when adding 11MB jar footprint (compared to 56k jar for my handwritten > MH bindings). I will follow-up if I find out more. If you see the startup slowdown even when omitting --source, then the issue is with loading the jar, rather than initializing - as explaining no initializing should happen outside for stuff that is actually used by your code - so I'd expect that initialization overhead for jextract code and your manually written versions should be roughly the same. > > Looking at the generated code for "xxx$constants$nn.java" there seems > to be a degree of unnecessary initialisation per xxx$constants$nn > class as it contains static variables for FunctionDescriptor / > MemoryLayout which would be initialised every time that particular > class was loaded and not used in my code. I felt that my own jar was > slow starting so switched foreign linker references to a lazy load > Supplier for every library / symbol / mh / vh so that only the > referenced types get created. Sure - but that's only when --source is used - when you generated classes directly, everything is lazy (and in a more general way than using Suppliers). So, can you please confirm, to be clear, that you still see startup regression even when NOT using "--source" ? Thanks! Maurizio > > I will have a look at future builds - this project is extremely useful > so I hope it gets into a full JDK release soon. Unfortunately my issue > with a huge jar in Eclipse means I can't easily develop using the > generated code variant right now, but in the meantime the jextract > code is still very helpful to work out how to call Windows APIs > correctly. > > Duncan > > On 25/01/2021 10:20, Maurizio Cimadamore wrote: >> >> On 23/01/2021 18:34, Duncan Gittins wrote: >>> I've been using Panama on Windows 10 to eliminate my C# apps which I >>> would normally call via ProcessBuilder. I'm very impressed so far >>> and looking forward to newer versions: everything I have written in >>> Windows C# is now replaced with foreign memory / linker calls to >>> native code using the latest Java 16 EA.? I have examples for >>> various Win32 API and COM objects, HWND objects and screensaver. >>> However I'm struggling to get the code running with output from >>> jextract build. Perhaps I overlooked something very obvious in how >>> to setup? >>> >>> One example app is attached - this calls SystemParametersInfoA to >>> set the Windows desktop background. There are two implementations of >>> setImage: one with hardwired MethodHandle works fine, but the >>> jextract version gives UnsupportedOperationException for layout >>> unrelated to SystemParametersInfoA. If I edit the generated code to >>> comment out all lines unrelated to SystemParametersInfoA then both >>> versions of setImage work. >> >> I think the culprit is this: >> >> ``` >> Caused by: java.lang.UnsupportedOperationException: Invalid alignment >> requirements for layout >> b64(ArbitraryUserPointer)[abi/kind=POINTER,layout/name=ArbitraryUserPointer] >> ??????? at >> jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.checkAlignment(LayoutPath.java:273) >> ??????? at >> jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.dereferenceHandle(LayoutPath.java:159) >> ??????? at >> jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.lambda$varHandle$2(MemoryLayout.java:488) >> ??????? at >> jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.computePathOp(MemoryLayout.java:534) >> ??????? at >> jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.varHandle(MemoryLayout.java:488) >> ??????? at >> duncan.win32.shobjidl_core.shlobj_core_h$constants$16.(shlobj_core_h$constants$16.java:1844) >> ``` >> >> This seems a duplicate of another issue that has been reported last >> week: >> >> https://bugs.openjdk.java.net/browse/JDK-8259832 >> >> E.g. jextract ignoring alignment requirements. Note that jextract >> generates lots of constants, and it takes only one bad one to make >> initialization fail. >> >>> >>> The jextract command on Windows 10 (with fresh Vis Studio >>> installation) expands shlobj_core.h because I my app also uses >>> IShellLink. >>> >>> ???? set "WINKIT=c:\Program Files (x86)\Windows >>> Kits\10\Include\10.0.18362.0" >>> ???? jextract --source -t duncan.win32.shobjidl_core -d >>> shlobj_core.h/java ??? "%WINKIT%/um/shlobj_core.h" >>> >>> Another issue is that this single windows header file gives rise to >>> 11MB jar and is unusable inside Eclipse (on my slow PC), and is slow >>> startup at runtime. Have you considered changing the generated code >>> to use lazy Supplier instead of MethodHandle to ensure >>> only required handles are created on-demand? >> >> Uhm... we are already using dynamic constants, so you should only pay >> for the MHs and VHs you use - e.g. in fact I'm even surprised you get >> the failure inside the above - since that constant should >> not be initialized unless it's used. I wonder if there's a regression >> here... are you using the `--source` flag? With that flag we revert >> back to a monolithic header, so that will explain both failures. If >> so, try removing that flag - and see what happens (if everything is >> working as it should I don't think you should even see the error >> above, assuming you never use that layout). >> >> Maurizio >> >>> >>> Kind regards >>> >>> Duncan >>> >>> > From sundar at openjdk.java.net Mon Jan 25 16:27:56 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Mon, 25 Jan 2021 16:27:56 GMT Subject: [foreign-jextract] Integrated: 8260344: jextract crashes with exception for log.h from libdebian-installer4-dev In-Reply-To: References: Message-ID: <1QweIrB7nekXWKWaJHrvSs8MAL8KNANUz4SWjEX8ReA=.3730d5c6-6a16-45f8-a541-361c4559a923@github.com> On Mon, 25 Jan 2021 15:10:37 GMT, Athijegannathan Sundararajan wrote: > Fixed type handling in createFunction when typedef on function pointer is used. This pull request has now been integrated. Changeset: 43f6a1c3 Author: Athijegannathan Sundararajan URL: https://git.openjdk.java.net/panama-foreign/commit/43f6a1c3 Stats: 94 lines in 3 files changed: 93 ins; 0 del; 1 mod 8260344: jextract crashes with exception for log.h from libdebian-installer4-dev Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/439 From maurizio.cimadamore at oracle.com Mon Jan 25 17:52:10 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 25 Jan 2021 17:52:10 +0000 Subject: memory access - pulling all the threads Message-ID: Hi, as you know, I've been looking at both internal and external feedback on usage of the memory access API, in an attempt to understand what the problem with the API are, and how to move forward. As discussed here [1], there are some things which work well, such as structured access, or recent addition to shared segment support (the latter seem to have enabled a wide variety of experiments which allowed us to gather more feedback - thanks!). But there are still some issues to be resolved - which could be summarized as "the MemorySegment abstraction is trying to do too many things at once" (again, please refer to [1] for a more detailed description of the problem involved). In [1] I described a possible approach where every allocation method (MemorySegment::allocateNative and MemorySegment::mapFile) return a "allocation handle", not a segment directly. The handle is the closeable entity, while the segment is just a view. While this approach is workable (and something very similar has indeed been explored here [2]), after implementing some parts of it, I was left not satisfied with how this approach integrates with respect to the foreign linker support. For instance, defining the behavior of methods such as CLinker::toCString becomes quite convoluted: where does the allocation handle associated with the returned string comes from? If the segment has no pointer to the handle, how can the memory associated to the string be closed? What is the relationship between an allocation handle and a NativeScope? All these questions led me to conclude that the proposed approach was not enough, and that we needed to try harder. The above approach does one thing right: it splits memory segments from the entity managing allocation/closure of memory resources, thus turning memory segments into dumb views. But it doesn't go far enough in this direction; as it turns out, what we really want here is a way to capture the concept of the lifecycle that is associated to one or more (logically related) resources - which, unsurprisingly, is part of what NativeScope does too. So, let's try to model this abstraction: ``` interface ResourceScope extends AutoCloseable { ?? void addOnClose(Runnable) // adds a new cleanup action to this scope ?? void close() // closes the scope ?? static ResourceScope ofConfined() // creates a confined resource scope ?? static ResourceScope ofShared() // creates a shared resource scope ?? static ResourceScope ofConfined(Cleaner) // creates a confined resource scope - managed by cleaner ?? static ResourceScope ofShared(Cleaner) // creates a shared resource scope - managed by cleaner } ``` It's a very simple interface - you can basically add new cleanup actions to it, which will be called when the scope is closed; note that ResourceScope supports implicit close (via a Cleaner), or explicit close (via the close method) - it can even support both (not shown here). Armed with this new abstraction, let's try to see if we can shine new light onto some of the existing API methods and abstractions. Let's start with heap segments - these are allocated using one of the MemorySegment::ofArray() factories; one of the issues with heap segments is that it doesn't make much sense to close them. In the proposed approach, this can be handled nicely: heap segments are associated with a _global_ scope that cannot be closed - a scope that is _always alive_. This clarifies the role of heap segments (and also of buffer segments) nicely. Let's proceed to MemorySegment::allocateNative/mapFile - what should these factories do? Under the new proposal, these method should accept a ResourceScope parameter, which defines the lifecycle to which the newly created segment should be attached to. If we want to still provide ResourceScope-less overloads (as the API does now) we can pick a useful default: a shared, non-closeable, cleaner-backed scope. This choice gives us essentially the same semantics as a byte buffer, so it would be an ideal starting point for developers coming from the ByteBuffer API trying to familiarize with the new memory access API. Note that, when using these more compact factories, scopes are almost entirely hidden from the client - so no extra complexity is added (compared e.g. to the ByteBuffer API). As it turns out, ResourceScope is not only useful for segments, but it is also useful for a number of entities which need to be attached to some lifecycle, such as: * upcall stubs * va lists * loaded libraries The upcall stub case is particularly telling: in that case, we have decided to model an upcall stub as a MemorySegment not because it makes sense to dereference an upcall stub - but simply because we need to have a way to _release_ the upcall stub once we're done using it. Under the new proposal, we have a new, powerful option: the upcall stub API point can accept an user-provided ResourceScope which will be responsible for managing the lifecycle of the upcall stub entity. That is, we are now? free to turn the result of a call to upcallStub to something other than a MemorySegment (e.g. a FunctionPointer?) w/o loss of functionality. Resource scopes are very useful to manage _group_ of resources - there are in fact cases where one or more segments share the same lifecycle - that is, they need to be all alive at the same time; to handle some of these use cases, the status quo adds the NativeScope abstraction, which can accept registration of external memory segment (via the MemorySegment::handoff) API. This use case is naturally handled by the ResourceScope API: ``` try (ResourceScope scope : ResourceScope.ofConfined()) { ?? MemorySegment.allocateNative(layout, scope): ?? MemorySegment.mapFile(... , scope); ?? CLinker.upcallStub(..., scope); } // release all resources ``` Does this remove the need for NativeScope ? Not so fast: NativeScope is used to group logically related resources, yes, but is also used as a faster, arena-based allocator - which attempts to minimize the number of system calls (e.g. to malloc) by allocating bigger memory blocks and then handing over slices to clients. Let's try to model the allocation-nature of a NativeScope with a separate interface, as follows: ``` @FunctionalInterface interface NativeAllocator { ?? MemorySegment allocate(long size, long align); ?? default allocateInt(MemoryLayout intLayout, int value) { ... } ?? default allocateLong(MemoryLayout intLayout, long value) { ... } ?? ... // all allocation helpers in NativeScope } ``` At first, it seems this interface doesn't add much. But it is quite powerful - for instance, a client can create a simple, malloc-like allocator, as follows: ``` NativeAllocator malloc = (size, align) -> MemorySegment.allocateNative(size, align, ResourceScope.ofConfined()); ``` This is an allocator which allocates a new region of memory on each allocation request, backed by a fresh confined scope (which can be closed independently). This idiom is in fact so common that the API allows client to create these allocators in a more compact fashion: ``` NativeAllocator confinedMalloc = NativeAllocator.ofMalloc(ResourceScope::ofConfined); NativeAllocator sharedMalloc = NativeAllocator.ofMalloc(ResourceScope::ofConfined); ``` But other strategies are also possible: * arena allocation (e.g. the allocation strategy currently used by NativeScope) * recycling allocation (a single segment, with given layout, is allocated, and allocation requests are served by repeatedly slicing that very segment) - this is a critical optimization in e.g. loops * interop with custom allocators So, where would we accept a NativeAllocator in our API? Turns out that accepting an allocator is handy whenever an API point needs to allocate some native memory - so, instead of ``` MemorySegment toCString(String) ``` This is better: ``` MemorySegment toCString(String, NativeAllocator) ``` Of course, we need to tweak the foreign linker, so that in all foreign calls returning a struct by value (which require some allocation), a NativeAllocator prefix argument is added to the method handle, so that the user can specify which allocator should be used by the call; this is a straightforward change which greatly enhances the expressive power of the linker API. So, we are in a place where some methods (e.g. factories which create some resource) takes an additional ResourceScope argument - and some other methods (e.g. methods that need to allocate native segments) which take an additional NativeAllocator argument. Now, it would be inconvenient for the user to have to create both, at least in simple use cases - but, since these are interfaces, nothing prevents us from creating a new abstraction which implements _both_ ResourceScope _and_ NativeAllocator - in fact this is exactly what the role of the already existing NativeScope is! ``` interface NativeScope extends NativeAllocator, ResourceScope { ... } ``` In other words, we have retconned the existing NativeScope abstraction, by explaining its behavior in terms of more primitive abstractions (scopes and allocators). This means that clients can, for the most part, just create a NativeScope and then pass it whenever a ResourceScope or a NativeAllocator is required (which is what is already happening in all of our jextract examples). There are some additional bonus points of this approach. First, ResourceScope features some locking capabilities - e.g. you can do things like: ``` try (ResourceScope.Lock lock = segment.scope().lock()) { ?? } ``` Which allows clients to perform segment critical operations w/o worrying that a segment memory will be reclaimed while in the middle of the operation. This solves the problem with async operation on byte buffers derived from shared segments (see [3]). Another bonus point is that the ResourceScope interface is completely segment-agnostic - in fact, we have now a way to describe APIs which return resources which must be cleaned by the user (or, implicitly, by the GC). For instance, it would be entirely reasonable to imagine, one day, the ByteBuffer API to provide an additional factory - e.g. allocateDirect(int size, ResourceScope scope) - which gives you a direct buffer attached to a given (closeable) scope. The same trick can probably be used in other APIs as well where implicit cleanup has been preferred for performance and/or safety reasons. tl;dr; This restacking described in this email enhances the Foreign Memory Access API in many different ways, and allows clients to approach the API in increasing degrees of complexity (depending on needs): * for smoother transition, coming from the ByteBuffer API, users can only have swap ByteBuffer::allocateDirect with MemorySegment::allocateNative - not much else changes, no need to think about lifecycles (and ResourceScope); GC is still in charge of deallocation * users that want tighter control over resources, can dive deeper and learn how segments (and other resources) are attached to a resource scope (which can be closed safely, if needed) * for the native interop case, the NativeScope abstraction is retconned to be both a ResourceScope *and* a NativeAllocator - so it can be used whenever an API needs to know how to _allocate_ or which _lifecycle_ should be used for a newly created resource * scopes can be locked, which allows clients to write critical sections in which a segment has to be operated upon w/o fear of it being closed * the idiom described here can be used to e.g. enhance the ByteBuffer API and to add close capabilities there All the above require very little changes to the clients of the memory access API. The biggest change is that a MemorySegment no longer supports the AutoCloseable interface, which is instead moved to ResourceScope. While this can get a little more verbose in case you need a single segment, the code scales _a lot_ better in case you need multiple segments/resources. Existing clients using jextract-generated APIs, on the other hand, are not affected much, since they are mostly dependent on the NativeScope API, which this proposal does not alter (although the role of a NativeScope is now retconned to be allocator + scope). You can find a branch which implements some of the changes described above (except the changes to the foreign linker API) here: https://github.com/mcimadamore/panama-foreign/tree/resourceScope While an initial javadoc of the API described in this email can be found here: http://cr.openjdk.java.net/~mcimadamore/panama/resourceScope-javadoc_v2/javadoc/jdk/incubator/foreign/package-summary.html Cheers Maurizio [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011700.html [2] - https://datasketches.apache.org/docs/Memory/MemoryPackage.html [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011810.html From paul.sandoz at oracle.com Mon Jan 25 22:02:01 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 25 Jan 2021 22:02:01 +0000 Subject: memory access - pulling all the threads In-Reply-To: References: Message-ID: <71E11042-CBA6-46C3-8DE7-B3BDEE600E8B@oracle.com> Nicely done. I think this greatly simplifies the API via composition of two concepts that were hiding behind NativeScope. Further, it mostly expands the functionality. The ability to lock a ResourceScope and attach close actions to an existing scope are two pieces of functionality that enable an existing resource scope to keep alive segments from another scope e.g. a structure is allocated to manage matrix metadata, accepting a pointer allocated from somewhere else for the matrix elements (the former might have a confined scope, where as the latter might have a shared scope and be retained for much longer). Paul. > On Jan 25, 2021, at 9:52 AM, Maurizio Cimadamore wrote: ... > This restacking described in this email enhances the Foreign Memory Access API in many different ways, and allows clients to approach the API in increasing degrees of complexity (depending on needs): > > * for smoother transition, coming from the ByteBuffer API, users can only have swap ByteBuffer::allocateDirect with MemorySegment::allocateNative - not much else changes, no need to think about lifecycles (and ResourceScope); GC is still in charge of deallocation > * users that want tighter control over resources, can dive deeper and learn how segments (and other resources) are attached to a resource scope (which can be closed safely, if needed) > * for the native interop case, the NativeScope abstraction is retconned to be both a ResourceScope *and* a NativeAllocator - so it can be used whenever an API needs to know how to _allocate_ or which _lifecycle_ should be used for a newly created resource > * scopes can be locked, which allows clients to write critical sections in which a segment has to be operated upon w/o fear of it being closed > * the idiom described here can be used to e.g. enhance the ByteBuffer API and to add close capabilities there > > All the above require very little changes to the clients of the memory access API. The biggest change is that a MemorySegment no longer supports the AutoCloseable interface, which is instead moved to ResourceScope. While this can get a little more verbose in case you need a single segment, the code scales _a lot_ better in case you need multiple segments/resources. Existing clients using jextract-generated APIs, on the other hand, are not affected much, since they are mostly dependent on the NativeScope API, which this proposal does not alter (although the role of a NativeScope is now retconned to be allocator + scope). > > You can find a branch which implements some of the changes described above (except the changes to the foreign linker API) here: > > https://github.com/mcimadamore/panama-foreign/tree/resourceScope > > While an initial javadoc of the API described in this email can be found here: > > http://cr.openjdk.java.net/~mcimadamore/panama/resourceScope-javadoc_v2/javadoc/jdk/incubator/foreign/package-summary.html > > > Cheers > Maurizio > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011700.html > [2] - https://datasketches.apache.org/docs/Memory/MemoryPackage.html > [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011810.html > > From samuel.audet at gmail.com Tue Jan 26 00:42:11 2021 From: samuel.audet at gmail.com (Samuel Audet) Date: Tue, 26 Jan 2021 09:42:11 +0900 Subject: memory access - pulling all the threads In-Reply-To: References: Message-ID: <008565df-4001-d931-3e9e-2d173b7ff999@gmail.com> That looks awesome! Thank you for considering this design. Samuel On 1/26/21 2:52 AM, Maurizio Cimadamore wrote: > > You can find a branch which implements some of the changes described > above (except the changes to the foreign linker API) here: > > https://github.com/mcimadamore/panama-foreign/tree/resourceScope > > While an initial javadoc of the API described in this email can be found here: > > http://cr.openjdk.java.net/~mcimadamore/panama/resourceScope-javadoc_v2/javadoc/jdk/incubator/foreign/package-summary.html > > > Cheers > Maurizio > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011700.html > [2] - https://datasketches.apache.org/docs/Memory/MemoryPackage.html > [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011810.html > > From youngty1997 at gmail.com Tue Jan 26 07:36:34 2021 From: youngty1997 at gmail.com (Ty Young) Date: Tue, 26 Jan 2021 01:36:34 -0600 Subject: memory access - pulling all the threads In-Reply-To: References: Message-ID: <4e6b74ac-13cf-cbce-6e2c-7d4dd61eb2d5@gmail.com> The basic idea behind a NativeAllocator makes sense but Is keeping the current MemorySegment.close() and access modes out of the question? Would it not be possible to introduce a free(MemorySegment)? method to this NativeAllocator interface, which MemorySegment.close() calls, so that the MemorySegment abstraction may be marked as **not** alive but the underlying memory may still be alive? On 1/25/21 11:52 AM, Maurizio Cimadamore wrote: > Hi, > as you know, I've been looking at both internal and external feedback > on usage of the memory access API, in an attempt to understand what > the problem with the API are, and how to move forward. As discussed > here [1], there are some things which work well, such as structured > access, or recent addition to shared segment support (the latter seem > to have enabled a wide variety of experiments which allowed us to > gather more feedback - thanks!). But there are still some issues to be > resolved - which could be summarized as "the MemorySegment abstraction > is trying to do too many things at once" (again, please refer to [1] > for a more detailed description of the problem involved). > > In [1] I described a possible approach where every allocation method > (MemorySegment::allocateNative and MemorySegment::mapFile) return a > "allocation handle", not a segment directly. The handle is the > closeable entity, while the segment is just a view. While this > approach is workable (and something very similar has indeed been > explored here [2]), after implementing some parts of it, I was left > not satisfied with how this approach integrates with respect to the > foreign linker support. For instance, defining the behavior of methods > such as CLinker::toCString becomes quite convoluted: where does the > allocation handle associated with the returned string comes from? If > the segment has no pointer to the handle, how can the memory > associated to the string be closed? What is the relationship between > an allocation handle and a NativeScope? All these questions led me to > conclude that the proposed approach was not enough, and that we needed > to try harder. > > The above approach does one thing right: it splits memory segments > from the entity managing allocation/closure of memory resources, thus > turning memory segments into dumb views. But it doesn't go far enough > in this direction; as it turns out, what we really want here is a way > to capture the concept of the lifecycle that is associated to one or > more (logically related) resources - which, unsurprisingly, is part of > what NativeScope does too. So, let's try to model this abstraction: > > ``` > interface ResourceScope extends AutoCloseable { > ?? void addOnClose(Runnable) // adds a new cleanup action to this scope > ?? void close() // closes the scope > > ?? static ResourceScope ofConfined() // creates a confined resource scope > ?? static ResourceScope ofShared() // creates a shared resource scope > ?? static ResourceScope ofConfined(Cleaner) // creates a confined > resource scope - managed by cleaner > ?? static ResourceScope ofShared(Cleaner) // creates a shared resource > scope - managed by cleaner > } > ``` > > It's a very simple interface - you can basically add new cleanup > actions to it, which will be called when the scope is closed; note > that ResourceScope supports implicit close (via a Cleaner), or > explicit close (via the close method) - it can even support both (not > shown here). > > Armed with this new abstraction, let's try to see if we can shine new > light onto some of the existing API methods and abstractions. > > Let's start with heap segments - these are allocated using one of the > MemorySegment::ofArray() factories; one of the issues with heap > segments is that it doesn't make much sense to close them. In the > proposed approach, this can be handled nicely: heap segments are > associated with a _global_ scope that cannot be closed - a scope that > is _always alive_. This clarifies the role of heap segments (and also > of buffer segments) nicely. > > Let's proceed to MemorySegment::allocateNative/mapFile - what should > these factories do? Under the new proposal, these method should accept > a ResourceScope parameter, which defines the lifecycle to which the > newly created segment should be attached to. If we want to still > provide ResourceScope-less overloads (as the API does now) we can pick > a useful default: a shared, non-closeable, cleaner-backed scope. This > choice gives us essentially the same semantics as a byte buffer, so it > would be an ideal starting point for developers coming from the > ByteBuffer API trying to familiarize with the new memory access API. > Note that, when using these more compact factories, scopes are almost > entirely hidden from the client - so no extra complexity is added > (compared e.g. to the ByteBuffer API). > > As it turns out, ResourceScope is not only useful for segments, but it > is also useful for a number of entities which need to be attached to > some lifecycle, such as: > > * upcall stubs > * va lists > * loaded libraries > > The upcall stub case is particularly telling: in that case, we have > decided to model an upcall stub as a MemorySegment not because it > makes sense to dereference an upcall stub - but simply because we need > to have a way to _release_ the upcall stub once we're done using it. > Under the new proposal, we have a new, powerful option: the upcall > stub API point can accept an user-provided ResourceScope which will be > responsible for managing the lifecycle of the upcall stub entity. That > is, we are now? free to turn the result of a call to upcallStub to > something other than a MemorySegment (e.g. a FunctionPointer?) w/o > loss of functionality. > > Resource scopes are very useful to manage _group_ of resources - there > are in fact cases where one or more segments share the same lifecycle > - that is, they need to be all alive at the same time; to handle some > of these use cases, the status quo adds the NativeScope abstraction, > which can accept registration of external memory segment (via the > MemorySegment::handoff) API. This use case is naturally handled by the > ResourceScope API: > > ``` > try (ResourceScope scope : ResourceScope.ofConfined()) { > ?? MemorySegment.allocateNative(layout, scope): > ?? MemorySegment.mapFile(... , scope); > ?? CLinker.upcallStub(..., scope); > } // release all resources > ``` > > Does this remove the need for NativeScope ? Not so fast: NativeScope > is used to group logically related resources, yes, but is also used as > a faster, arena-based allocator - which attempts to minimize the > number of system calls (e.g. to malloc) by allocating bigger memory > blocks and then handing over slices to clients. Let's try to model the > allocation-nature of a NativeScope with a separate interface, as follows: > > ``` > @FunctionalInterface > interface NativeAllocator { > ?? MemorySegment allocate(long size, long align); > ?? default allocateInt(MemoryLayout intLayout, int value) { ... } > ?? default allocateLong(MemoryLayout intLayout, long value) { ... } > ?? ... // all allocation helpers in NativeScope > } > ``` > > At first, it seems this interface doesn't add much. But it is quite > powerful - for instance, a client can create a simple, malloc-like > allocator, as follows: > > ``` > NativeAllocator malloc = (size, align) -> > MemorySegment.allocateNative(size, align, ResourceScope.ofConfined()); > > ``` > > This is an allocator which allocates a new region of memory on each > allocation request, backed by a fresh confined scope (which can be > closed independently). This idiom is in fact so common that the API > allows client to create these allocators in a more compact fashion: > > ``` > NativeAllocator confinedMalloc = > NativeAllocator.ofMalloc(ResourceScope::ofConfined); > NativeAllocator sharedMalloc = > NativeAllocator.ofMalloc(ResourceScope::ofConfined); > ``` > > But other strategies are also possible: > > * arena allocation (e.g. the allocation strategy currently used by > NativeScope) > * recycling allocation (a single segment, with given layout, is > allocated, and allocation requests are served by repeatedly slicing > that very segment) - this is a critical optimization in e.g. loops > * interop with custom allocators > > So, where would we accept a NativeAllocator in our API? Turns out that > accepting an allocator is handy whenever an API point needs to > allocate some native memory - so, instead of > > ``` > MemorySegment toCString(String) > ``` > > This is better: > > ``` > MemorySegment toCString(String, NativeAllocator) > ``` > > Of course, we need to tweak the foreign linker, so that in all foreign > calls returning a struct by value (which require some allocation), a > NativeAllocator prefix argument is added to the method handle, so that > the user can specify which allocator should be used by the call; this > is a straightforward change which greatly enhances the expressive > power of the linker API. > > So, we are in a place where some methods (e.g. factories which create > some resource) takes an additional ResourceScope argument - and some > other methods (e.g. methods that need to allocate native segments) > which take an additional NativeAllocator argument. Now, it would be > inconvenient for the user to have to create both, at least in simple > use cases - but, since these are interfaces, nothing prevents us from > creating a new abstraction which implements _both_ ResourceScope _and_ > NativeAllocator - in fact this is exactly what the role of the already > existing NativeScope is! > > ``` > interface NativeScope extends NativeAllocator, ResourceScope { ... } > ``` > > In other words, we have retconned the existing NativeScope > abstraction, by explaining its behavior in terms of more primitive > abstractions (scopes and allocators). This means that clients can, for > the most part, just create a NativeScope and then pass it whenever a > ResourceScope or a NativeAllocator is required (which is what is > already happening in all of our jextract examples). > > There are some additional bonus points of this approach. > > First, ResourceScope features some locking capabilities - e.g. you can > do things like: > > ``` > try (ResourceScope.Lock lock = segment.scope().lock()) { > ?? > } > ``` > > Which allows clients to perform segment critical operations w/o > worrying that a segment memory will be reclaimed while in the middle > of the operation. This solves the problem with async operation on byte > buffers derived from shared segments (see [3]). > > Another bonus point is that the ResourceScope interface is completely > segment-agnostic - in fact, we have now a way to describe APIs which > return resources which must be cleaned by the user (or, implicitly, by > the GC). For instance, it would be entirely reasonable to imagine, one > day, the ByteBuffer API to provide an additional factory - e.g. > allocateDirect(int size, ResourceScope scope) - which gives you a > direct buffer attached to a given (closeable) scope. The same trick > can probably be used in other APIs as well where implicit cleanup has > been preferred for performance and/or safety reasons. > > tl;dr; > > This restacking described in this email enhances the Foreign Memory > Access API in many different ways, and allows clients to approach the > API in increasing degrees of complexity (depending on needs): > > * for smoother transition, coming from the ByteBuffer API, users can > only have swap ByteBuffer::allocateDirect with > MemorySegment::allocateNative - not much else changes, no need to > think about lifecycles (and ResourceScope); GC is still in charge of > deallocation > * users that want tighter control over resources, can dive deeper and > learn how segments (and other resources) are attached to a resource > scope (which can be closed safely, if needed) > * for the native interop case, the NativeScope abstraction is > retconned to be both a ResourceScope *and* a NativeAllocator - so it > can be used whenever an API needs to know how to _allocate_ or which > _lifecycle_ should be used for a newly created resource > * scopes can be locked, which allows clients to write critical > sections in which a segment has to be operated upon w/o fear of it > being closed > * the idiom described here can be used to e.g. enhance the ByteBuffer > API and to add close capabilities there > > All the above require very little changes to the clients of the memory > access API. The biggest change is that a MemorySegment no longer > supports the AutoCloseable interface, which is instead moved to > ResourceScope. While this can get a little more verbose in case you > need a single segment, the code scales _a lot_ better in case you need > multiple segments/resources. Existing clients using jextract-generated > APIs, on the other hand, are not affected much, since they are mostly > dependent on the NativeScope API, which this proposal does not alter > (although the role of a NativeScope is now retconned to be allocator + > scope). > > You can find a branch which implements some of the changes described > above (except the changes to the foreign linker API) here: > > https://github.com/mcimadamore/panama-foreign/tree/resourceScope > > While an initial javadoc of the API described in this email can be > found here: > > http://cr.openjdk.java.net/~mcimadamore/panama/resourceScope-javadoc_v2/javadoc/jdk/incubator/foreign/package-summary.html > > > > Cheers > Maurizio > > [1] - > https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011700.html > [2] - https://datasketches.apache.org/docs/Memory/MemoryPackage.html > [3] - > https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011810.html > > From whuang at openjdk.java.net Tue Jan 26 08:56:07 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 26 Jan 2021 08:56:07 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE [v3] In-Reply-To: References: Message-ID: > This patch add cast nodes between interger types implementation for Arm SVE like "VectorCastB2X" "VectorCastI2X " "VectorCastS2X" "VectorCastL2X". Wang Huang has updated the pull request incrementally with one additional commit since the last revision: add other I2I cast nodes ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/31/files - new: https://git.openjdk.java.net/panama-vector/pull/31/files/db8e148d..2a6df4e1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=31&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=31&range=01-02 Stats: 130 lines in 3 files changed: 126 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/panama-vector/pull/31.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/31/head:pull/31 PR: https://git.openjdk.java.net/panama-vector/pull/31 From whuang at openjdk.java.net Tue Jan 26 08:56:08 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 26 Jan 2021 08:56:08 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE In-Reply-To: References: Message-ID: On Tue, 12 Jan 2021 03:13:31 GMT, Wang Huang wrote: > This patch add cast nodes between interger types implementation for Arm SVE like "VectorCastB2X" "VectorCastI2X " "VectorCastS2X" "VectorCastL2X". > Hi @Wanghuang-Huawei, thanks for adding the SVE support for VectorCast. I observed that this patch misses some type casts like: `byte -> long`, `short -> long`, `long -> byte` and `long -> short`. Do you have any plan to add these missing parts in future? I'd suggest to add them all with the single patch. WDYT? OK. I will add them in next commit. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/31 From whuang at openjdk.java.net Tue Jan 26 08:56:09 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 26 Jan 2021 08:56:09 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE [v2] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 09:39:24 GMT, Xiaohong Gong wrote: >> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> fix build bug on other archs caused by UseSVE > 0 > > src/hotspot/share/opto/vectorIntrinsics.cpp line 338: > >> 336: if (C->print_intrinsics()) { >> 337: tty->print_cr(" ** shuffle iota not supported on SVE"); >> 338: } > > I guess these parts will be removed in future if shuffle is supported with SVE. Could you please add some comments for it? OK. Thank you for your review. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/31 From maurizio.cimadamore at oracle.com Tue Jan 26 11:03:32 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 26 Jan 2021 11:03:32 +0000 Subject: memory access - pulling all the threads In-Reply-To: <4e6b74ac-13cf-cbce-6e2c-7d4dd61eb2d5@gmail.com> References: <4e6b74ac-13cf-cbce-6e2c-7d4dd61eb2d5@gmail.com> Message-ID: <4eaf68e6-9405-e105-a633-20ece46f61ec@oracle.com> On 26/01/2021 07:36, Ty Young wrote: > The basic idea behind a NativeAllocator makes sense but Is keeping the > current MemorySegment.close() and access modes out of the question? > Would it not be possible to introduce a free(MemorySegment)? method to > this NativeAllocator interface, which MemorySegment.close() calls, so > that the MemorySegment abstraction may be marked as **not** alive but > the underlying memory may still be alive? In the proposed design, single segments do not have a liveness bit to themselves. Of course you can use an allocator which creates a new scope for each new segment and land exactly where you were before. As for free, it doesn't make sense on "all" allocators. I think whether segments are independently freeable and how, is a detail of the allocator implementation. As for adding close() to MemorySegment, I believe having MemorySegment (as well as other resource-like abstraction like VaList) being AutoCloseable looks like a win in short examples where you have only a single segment - but it fails to scale to more complex examples where you have multiple segments (and other resources) whose life-cycle is shared. And when you get to the latter case, having a close() becomes problematic, because you are never quite sure of what will the side-effects of calling close() be: will you close only the segment you are operating on? Or, is that segment a slice from a bigger chunk, so that you will also end up killing other 50 segments? The proposed API, by making the transition from segment to scope (many to one) explicit, makes it clearer that segment is just a view that is attached to some other abstraction which will "release" the resources attached to the segment; this makes the segment API roughly half the size of what it was, and allows us to capture common traits of all managed resources in a single abstraction. Now, MemorySegment has a scope, VaList has a scope, LibraryLookup has a scope (although that is not exposed - yet), and if we tweak CLinker::upcallStub to return something other than a segment (e.g. a FunctionPointer), that will have a scope too. Of course, clients can implement closeable segments using the abstractions provided, e.g. ``` class CloseableSegment implements AutoCloseable { ?? private final MemorySegment segment; ?? public static CloseableSegment make(long size) { ?????? segment = MemorySegment.allocateNative(size, ResourceScope.ofConfined()); ?? } ?? // maybe sprinkle some accessors based on MemoryAcccess ? ?? public void close() { ????? return segment.scope.close(); ?? } ?? public MemorySegment toSegment() { ?????? return segment; // interop with linker API ??? } } ``` You can even implement handoff primitives like the ones we had using the proposed API (e.g. on handoff from A to B close the scope and return a new CloseableSegment that has a scope confined on B). So, the segment abstraction included in the proposal is more primitive, which is, I think, a good sign. P.S. Now that segments are simpler and do not have any real lifecycle logic, one might wonder why not allowing users to define custom implementation of the MemorySegment interface. While that's possible in practice, I think most of the times that will run into troubles when integrating with var handles and method handles, which prefer exact type matches. That's the main reason why we have not relied on subtyping much for linker-related abstractions: it's easy to run into performance pitfalls, and there doesn't seem enough to gain in exchange. Maurizio > > > On 1/25/21 11:52 AM, Maurizio Cimadamore wrote: >> Hi, >> as you know, I've been looking at both internal and external feedback >> on usage of the memory access API, in an attempt to understand what >> the problem with the API are, and how to move forward. As discussed >> here [1], there are some things which work well, such as structured >> access, or recent addition to shared segment support (the latter seem >> to have enabled a wide variety of experiments which allowed us to >> gather more feedback - thanks!). But there are still some issues to >> be resolved - which could be summarized as "the MemorySegment >> abstraction is trying to do too many things at once" (again, please >> refer to [1] for a more detailed description of the problem involved). >> >> In [1] I described a possible approach where every allocation method >> (MemorySegment::allocateNative and MemorySegment::mapFile) return a >> "allocation handle", not a segment directly. The handle is the >> closeable entity, while the segment is just a view. While this >> approach is workable (and something very similar has indeed been >> explored here [2]), after implementing some parts of it, I was left >> not satisfied with how this approach integrates with respect to the >> foreign linker support. For instance, defining the behavior of >> methods such as CLinker::toCString becomes quite convoluted: where >> does the allocation handle associated with the returned string comes >> from? If the segment has no pointer to the handle, how can the memory >> associated to the string be closed? What is the relationship between >> an allocation handle and a NativeScope? All these questions led me to >> conclude that the proposed approach was not enough, and that we >> needed to try harder. >> >> The above approach does one thing right: it splits memory segments >> from the entity managing allocation/closure of memory resources, thus >> turning memory segments into dumb views. But it doesn't go far enough >> in this direction; as it turns out, what we really want here is a way >> to capture the concept of the lifecycle that is associated to one or >> more (logically related) resources - which, unsurprisingly, is part >> of what NativeScope does too. So, let's try to model this abstraction: >> >> ``` >> interface ResourceScope extends AutoCloseable { >> ?? void addOnClose(Runnable) // adds a new cleanup action to this scope >> ?? void close() // closes the scope >> >> ?? static ResourceScope ofConfined() // creates a confined resource >> scope >> ?? static ResourceScope ofShared() // creates a shared resource scope >> ?? static ResourceScope ofConfined(Cleaner) // creates a confined >> resource scope - managed by cleaner >> ?? static ResourceScope ofShared(Cleaner) // creates a shared >> resource scope - managed by cleaner >> } >> ``` >> >> It's a very simple interface - you can basically add new cleanup >> actions to it, which will be called when the scope is closed; note >> that ResourceScope supports implicit close (via a Cleaner), or >> explicit close (via the close method) - it can even support both (not >> shown here). >> >> Armed with this new abstraction, let's try to see if we can shine new >> light onto some of the existing API methods and abstractions. >> >> Let's start with heap segments - these are allocated using one of the >> MemorySegment::ofArray() factories; one of the issues with heap >> segments is that it doesn't make much sense to close them. In the >> proposed approach, this can be handled nicely: heap segments are >> associated with a _global_ scope that cannot be closed - a scope that >> is _always alive_. This clarifies the role of heap segments (and also >> of buffer segments) nicely. >> >> Let's proceed to MemorySegment::allocateNative/mapFile - what should >> these factories do? Under the new proposal, these method should >> accept a ResourceScope parameter, which defines the lifecycle to >> which the newly created segment should be attached to. If we want to >> still provide ResourceScope-less overloads (as the API does now) we >> can pick a useful default: a shared, non-closeable, cleaner-backed >> scope. This choice gives us essentially the same semantics as a byte >> buffer, so it would be an ideal starting point for developers coming >> from the ByteBuffer API trying to familiarize with the new memory >> access API. Note that, when using these more compact factories, >> scopes are almost entirely hidden from the client - so no extra >> complexity is added (compared e.g. to the ByteBuffer API). >> >> As it turns out, ResourceScope is not only useful for segments, but >> it is also useful for a number of entities which need to be attached >> to some lifecycle, such as: >> >> * upcall stubs >> * va lists >> * loaded libraries >> >> The upcall stub case is particularly telling: in that case, we have >> decided to model an upcall stub as a MemorySegment not because it >> makes sense to dereference an upcall stub - but simply because we >> need to have a way to _release_ the upcall stub once we're done using >> it. Under the new proposal, we have a new, powerful option: the >> upcall stub API point can accept an user-provided ResourceScope which >> will be responsible for managing the lifecycle of the upcall stub >> entity. That is, we are now? free to turn the result of a call to >> upcallStub to something other than a MemorySegment (e.g. a >> FunctionPointer?) w/o loss of functionality. >> >> Resource scopes are very useful to manage _group_ of resources - >> there are in fact cases where one or more segments share the same >> lifecycle - that is, they need to be all alive at the same time; to >> handle some of these use cases, the status quo adds the NativeScope >> abstraction, which can accept registration of external memory segment >> (via the MemorySegment::handoff) API. This use case is naturally >> handled by the ResourceScope API: >> >> ``` >> try (ResourceScope scope : ResourceScope.ofConfined()) { >> ?? MemorySegment.allocateNative(layout, scope): >> ?? MemorySegment.mapFile(... , scope); >> ?? CLinker.upcallStub(..., scope); >> } // release all resources >> ``` >> >> Does this remove the need for NativeScope ? Not so fast: NativeScope >> is used to group logically related resources, yes, but is also used >> as a faster, arena-based allocator - which attempts to minimize the >> number of system calls (e.g. to malloc) by allocating bigger memory >> blocks and then handing over slices to clients. Let's try to model >> the allocation-nature of a NativeScope with a separate interface, as >> follows: >> >> ``` >> @FunctionalInterface >> interface NativeAllocator { >> ?? MemorySegment allocate(long size, long align); >> ?? default allocateInt(MemoryLayout intLayout, int value) { ... } >> ?? default allocateLong(MemoryLayout intLayout, long value) { ... } >> ?? ... // all allocation helpers in NativeScope >> } >> ``` >> >> At first, it seems this interface doesn't add much. But it is quite >> powerful - for instance, a client can create a simple, malloc-like >> allocator, as follows: >> >> ``` >> NativeAllocator malloc = (size, align) -> >> MemorySegment.allocateNative(size, align, ResourceScope.ofConfined()); >> >> ``` >> >> This is an allocator which allocates a new region of memory on each >> allocation request, backed by a fresh confined scope (which can be >> closed independently). This idiom is in fact so common that the API >> allows client to create these allocators in a more compact fashion: >> >> ``` >> NativeAllocator confinedMalloc = >> NativeAllocator.ofMalloc(ResourceScope::ofConfined); >> NativeAllocator sharedMalloc = >> NativeAllocator.ofMalloc(ResourceScope::ofConfined); >> ``` >> >> But other strategies are also possible: >> >> * arena allocation (e.g. the allocation strategy currently used by >> NativeScope) >> * recycling allocation (a single segment, with given layout, is >> allocated, and allocation requests are served by repeatedly slicing >> that very segment) - this is a critical optimization in e.g. loops >> * interop with custom allocators >> >> So, where would we accept a NativeAllocator in our API? Turns out >> that accepting an allocator is handy whenever an API point needs to >> allocate some native memory - so, instead of >> >> ``` >> MemorySegment toCString(String) >> ``` >> >> This is better: >> >> ``` >> MemorySegment toCString(String, NativeAllocator) >> ``` >> >> Of course, we need to tweak the foreign linker, so that in all >> foreign calls returning a struct by value (which require some >> allocation), a NativeAllocator prefix argument is added to the method >> handle, so that the user can specify which allocator should be used >> by the call; this is a straightforward change which greatly enhances >> the expressive power of the linker API. >> >> So, we are in a place where some methods (e.g. factories which create >> some resource) takes an additional ResourceScope argument - and some >> other methods (e.g. methods that need to allocate native segments) >> which take an additional NativeAllocator argument. Now, it would be >> inconvenient for the user to have to create both, at least in simple >> use cases - but, since these are interfaces, nothing prevents us from >> creating a new abstraction which implements _both_ ResourceScope >> _and_ NativeAllocator - in fact this is exactly what the role of the >> already existing NativeScope is! >> >> ``` >> interface NativeScope extends NativeAllocator, ResourceScope { ... } >> ``` >> >> In other words, we have retconned the existing NativeScope >> abstraction, by explaining its behavior in terms of more primitive >> abstractions (scopes and allocators). This means that clients can, >> for the most part, just create a NativeScope and then pass it >> whenever a ResourceScope or a NativeAllocator is required (which is >> what is already happening in all of our jextract examples). >> >> There are some additional bonus points of this approach. >> >> First, ResourceScope features some locking capabilities - e.g. you >> can do things like: >> >> ``` >> try (ResourceScope.Lock lock = segment.scope().lock()) { >> ?? >> } >> ``` >> >> Which allows clients to perform segment critical operations w/o >> worrying that a segment memory will be reclaimed while in the middle >> of the operation. This solves the problem with async operation on >> byte buffers derived from shared segments (see [3]). >> >> Another bonus point is that the ResourceScope interface is completely >> segment-agnostic - in fact, we have now a way to describe APIs which >> return resources which must be cleaned by the user (or, implicitly, >> by the GC). For instance, it would be entirely reasonable to imagine, >> one day, the ByteBuffer API to provide an additional factory - e.g. >> allocateDirect(int size, ResourceScope scope) - which gives you a >> direct buffer attached to a given (closeable) scope. The same trick >> can probably be used in other APIs as well where implicit cleanup has >> been preferred for performance and/or safety reasons. >> >> tl;dr; >> >> This restacking described in this email enhances the Foreign Memory >> Access API in many different ways, and allows clients to approach the >> API in increasing degrees of complexity (depending on needs): >> >> * for smoother transition, coming from the ByteBuffer API, users can >> only have swap ByteBuffer::allocateDirect with >> MemorySegment::allocateNative - not much else changes, no need to >> think about lifecycles (and ResourceScope); GC is still in charge of >> deallocation >> * users that want tighter control over resources, can dive deeper and >> learn how segments (and other resources) are attached to a resource >> scope (which can be closed safely, if needed) >> * for the native interop case, the NativeScope abstraction is >> retconned to be both a ResourceScope *and* a NativeAllocator - so it >> can be used whenever an API needs to know how to _allocate_ or which >> _lifecycle_ should be used for a newly created resource >> * scopes can be locked, which allows clients to write critical >> sections in which a segment has to be operated upon w/o fear of it >> being closed >> * the idiom described here can be used to e.g. enhance the ByteBuffer >> API and to add close capabilities there >> >> All the above require very little changes to the clients of the >> memory access API. The biggest change is that a MemorySegment no >> longer supports the AutoCloseable interface, which is instead moved >> to ResourceScope. While this can get a little more verbose in case >> you need a single segment, the code scales _a lot_ better in case you >> need multiple segments/resources. Existing clients using >> jextract-generated APIs, on the other hand, are not affected much, >> since they are mostly dependent on the NativeScope API, which this >> proposal does not alter (although the role of a NativeScope is now >> retconned to be allocator + scope). >> >> You can find a branch which implements some of the changes described >> above (except the changes to the foreign linker API) here: >> >> https://github.com/mcimadamore/panama-foreign/tree/resourceScope >> >> While an initial javadoc of the API described in this email can be >> found here: >> >> http://cr.openjdk.java.net/~mcimadamore/panama/resourceScope-javadoc_v2/javadoc/jdk/incubator/foreign/package-summary.html >> >> >> >> Cheers >> Maurizio >> >> [1] - >> https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011700.html >> [2] - https://datasketches.apache.org/docs/Memory/MemoryPackage.html >> [3] - >> https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011810.html >> >> From duncan.gittins at gmail.com Tue Jan 26 15:43:18 2021 From: duncan.gittins at gmail.com (Duncan Gittins) Date: Tue, 26 Jan 2021 15:43:18 +0000 Subject: [External] : Re: Feedback / query on jextract for Windows 10 In-Reply-To: <145ff947-5de4-3d7e-17b9-074842b0f2ce@oracle.com> References: <0e35502c-3656-9c23-eca8-4ca8a4377d15@gmail.com> <52aa2217-0795-a27b-8173-78b06be3f25b@gmail.com> <145ff947-5de4-3d7e-17b9-074842b0f2ce@oracle.com> Message-ID: <9071e122-8bb3-2688-f9f3-ba63f15e127f@gmail.com> I don't know what causes the speed difference, which may be down to the jar size as you suggest. I'll re-test after the time that "--source" generates same code as seen in the .class files when it may be easier to understand why there is a difference. I am using 16-panama+3-385. This isn't a very robust test, but I also tried deleted all the un-necessary .class files from the 11MB jextract generated classes (not produced using --source) down to 2MB jar, then I moved my handcoded method into a separate class and added a dependency on a different 2MB jar. Neither of those changes affected the typical speeds of first call times - I still consistently see that the hand coded method handle version of my app is ~300-500ms faster on first call, and no difference for 2nd+ calls. Duncan On 25/01/2021 16:18, Maurizio Cimadamore wrote: > > On 25/01/2021 16:13, Duncan Gittins wrote: >> Thanks for the information.? As you suspected that bug must be >> related and there is a minor difference in the --source output >> because the problem does go away when removing the jextract >> "--source" flag and making jar directly from generated classes rather >> than just compiling from the generated source code. >> >> My code samples using jextract bindings are ~300ms slower at startup >> time (but same speed runtime). I'm not certain if this overhead is >> down to initialisation of static constants or simply to be expected >> when adding 11MB jar footprint (compared to 56k jar for my >> handwritten MH bindings). I will follow-up if I find out more. > If you see the startup slowdown even when omitting --source, then the > issue is with loading the jar, rather than initializing - as > explaining no initializing should happen outside for stuff that is > actually used by your code - so I'd expect that initialization > overhead for jextract code and your manually written versions should > be roughly the same. >> >> Looking at the generated code for "xxx$constants$nn.java" there seems >> to be a degree of unnecessary initialisation per xxx$constants$nn >> class as it contains static variables for FunctionDescriptor / >> MemoryLayout which would be initialised every time that particular >> class was loaded and not used in my code. I felt that my own jar was >> slow starting so switched foreign linker references to a lazy load >> Supplier for every library / symbol / mh / vh so that only the >> referenced types get created. > > Sure - but that's only when --source is used - when you generated > classes directly, everything is lazy (and in a more general way than > using Suppliers). > > So, can you please confirm, to be clear, that you still see startup > regression even when NOT using "--source" ? > > Thanks! > Maurizio > >> >> I will have a look at future builds - this project is extremely >> useful so I hope it gets into a full JDK release soon. Unfortunately >> my issue with a huge jar in Eclipse means I can't easily develop >> using the generated code variant right now, but in the meantime the >> jextract code is still very helpful to work out how to call Windows >> APIs correctly. >> >> Duncan >> >> On 25/01/2021 10:20, Maurizio Cimadamore wrote: >>> >>> On 23/01/2021 18:34, Duncan Gittins wrote: >>>> I've been using Panama on Windows 10 to eliminate my C# apps which >>>> I would normally call via ProcessBuilder. I'm very impressed so far >>>> and looking forward to newer versions: everything I have written in >>>> Windows C# is now replaced with foreign memory / linker calls to >>>> native code using the latest Java 16 EA.? I have examples for >>>> various Win32 API and COM objects, HWND objects and screensaver. >>>> However I'm struggling to get the code running with output from >>>> jextract build. Perhaps I overlooked something very obvious in how >>>> to setup? >>>> >>>> One example app is attached - this calls SystemParametersInfoA to >>>> set the Windows desktop background. There are two implementations >>>> of setImage: one with hardwired MethodHandle works fine, but the >>>> jextract version gives UnsupportedOperationException for layout >>>> unrelated to SystemParametersInfoA. If I edit the generated code to >>>> comment out all lines unrelated to SystemParametersInfoA then both >>>> versions of setImage work. >>> >>> I think the culprit is this: >>> >>> ``` >>> Caused by: java.lang.UnsupportedOperationException: Invalid >>> alignment requirements for layout >>> b64(ArbitraryUserPointer)[abi/kind=POINTER,layout/name=ArbitraryUserPointer] >>> ??????? at >>> jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.checkAlignment(LayoutPath.java:273) >>> ??????? at >>> jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.dereferenceHandle(LayoutPath.java:159) >>> ??????? at >>> jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.lambda$varHandle$2(MemoryLayout.java:488) >>> ??????? at >>> jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.computePathOp(MemoryLayout.java:534) >>> ??????? at >>> jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.varHandle(MemoryLayout.java:488) >>> ??????? at >>> duncan.win32.shobjidl_core.shlobj_core_h$constants$16.(shlobj_core_h$constants$16.java:1844) >>> ``` >>> >>> This seems a duplicate of another issue that has been reported last >>> week: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8259832 >>> >>> E.g. jextract ignoring alignment requirements. Note that jextract >>> generates lots of constants, and it takes only one bad one to make >>> initialization fail. >>> >>>> >>>> The jextract command on Windows 10 (with fresh Vis Studio >>>> installation) expands shlobj_core.h because I my app also uses >>>> IShellLink. >>>> >>>> ???? set "WINKIT=c:\Program Files (x86)\Windows >>>> Kits\10\Include\10.0.18362.0" >>>> ???? jextract --source -t duncan.win32.shobjidl_core -d >>>> shlobj_core.h/java ??? "%WINKIT%/um/shlobj_core.h" >>>> >>>> Another issue is that this single windows header file gives rise to >>>> 11MB jar and is unusable inside Eclipse (on my slow PC), and is >>>> slow startup at runtime. Have you considered changing the generated >>>> code to use lazy Supplier instead of MethodHandle to >>>> ensure only required handles are created on-demand? >>> >>> Uhm... we are already using dynamic constants, so you should only >>> pay for the MHs and VHs you use - e.g. in fact I'm even surprised >>> you get the failure inside the above - since that constant >>> should not be initialized unless it's used. I wonder if there's a >>> regression here... are you using the `--source` flag? With that flag >>> we revert back to a monolithic header, so that will explain both >>> failures. If so, try removing that flag - and see what happens (if >>> everything is working as it should I don't think you should even see >>> the error above, assuming you never use that layout). >>> >>> Maurizio >>> >>>> >>>> Kind regards >>>> >>>> Duncan >>>> >>>> >> From maurizio.cimadamore at oracle.com Tue Jan 26 16:54:30 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 26 Jan 2021 16:54:30 +0000 Subject: [External] : Re: Feedback / query on jextract for Windows 10 In-Reply-To: <9071e122-8bb3-2688-f9f3-ba63f15e127f@gmail.com> References: <0e35502c-3656-9c23-eca8-4ca8a4377d15@gmail.com> <52aa2217-0795-a27b-8173-78b06be3f25b@gmail.com> <145ff947-5de4-3d7e-17b9-074842b0f2ce@oracle.com> <9071e122-8bb3-2688-f9f3-ba63f15e127f@gmail.com> Message-ID: <03b8a550-b3a3-acd1-a1ba-752454b01a01@oracle.com> I'll take a look with the latest version - it might be that something is interacting with the lazy constant loading process. Thanks for reporting this - minimizing startup of jextracted libraries is a pretty important use case for us. Cheers Maurizio On 26/01/2021 15:43, Duncan Gittins wrote: > I don't know what causes the speed difference, which may be down to > the jar size as you suggest. I'll re-test after the time that > "--source" generates same code as seen in the .class files when it may > be easier to understand why there is a difference. I am using > 16-panama+3-385. > > This isn't a very robust test, but I also tried deleted all the > un-necessary .class files from the 11MB jextract generated classes > (not produced using --source) down to 2MB jar, then I moved my > handcoded method into a separate class and added a dependency on a > different 2MB jar. Neither of those changes affected the typical > speeds of first call times - I still consistently see that the hand > coded method handle version of my app is ~300-500ms faster on first > call, and no difference for 2nd+ calls. > > Duncan > > On 25/01/2021 16:18, Maurizio Cimadamore wrote: >> >> On 25/01/2021 16:13, Duncan Gittins wrote: >>> Thanks for the information.? As you suspected that bug must be >>> related and there is a minor difference in the --source output >>> because the problem does go away when removing the jextract >>> "--source" flag and making jar directly from generated classes >>> rather than just compiling from the generated source code. >>> >>> My code samples using jextract bindings are ~300ms slower at startup >>> time (but same speed runtime). I'm not certain if this overhead is >>> down to initialisation of static constants or simply to be expected >>> when adding 11MB jar footprint (compared to 56k jar for my >>> handwritten MH bindings). I will follow-up if I find out more. >> If you see the startup slowdown even when omitting --source, then the >> issue is with loading the jar, rather than initializing - as >> explaining no initializing should happen outside for stuff that is >> actually used by your code - so I'd expect that initialization >> overhead for jextract code and your manually written versions should >> be roughly the same. >>> >>> Looking at the generated code for "xxx$constants$nn.java" there >>> seems to be a degree of unnecessary initialisation per >>> xxx$constants$nn class as it contains static variables for >>> FunctionDescriptor / MemoryLayout which would be initialised every >>> time that particular class was loaded and not used in my code. I >>> felt that my own jar was slow starting so switched foreign linker >>> references to a lazy load Supplier for every library / symbol / mh / >>> vh so that only the referenced types get created. >> >> Sure - but that's only when --source is used - when you generated >> classes directly, everything is lazy (and in a more general way than >> using Suppliers). >> >> So, can you please confirm, to be clear, that you still see startup >> regression even when NOT using "--source" ? >> >> Thanks! >> Maurizio >> >>> >>> I will have a look at future builds - this project is extremely >>> useful so I hope it gets into a full JDK release soon. Unfortunately >>> my issue with a huge jar in Eclipse means I can't easily develop >>> using the generated code variant right now, but in the meantime the >>> jextract code is still very helpful to work out how to call Windows >>> APIs correctly. >>> >>> Duncan >>> >>> On 25/01/2021 10:20, Maurizio Cimadamore wrote: >>>> >>>> On 23/01/2021 18:34, Duncan Gittins wrote: >>>>> I've been using Panama on Windows 10 to eliminate my C# apps which >>>>> I would normally call via ProcessBuilder. I'm very impressed so >>>>> far and looking forward to newer versions: everything I have >>>>> written in Windows C# is now replaced with foreign memory / linker >>>>> calls to native code using the latest Java 16 EA.? I have examples >>>>> for various Win32 API and COM objects, HWND objects and >>>>> screensaver. However I'm struggling to get the code running with >>>>> output from jextract build. Perhaps I overlooked something very >>>>> obvious in how to setup? >>>>> >>>>> One example app is attached - this calls SystemParametersInfoA to >>>>> set the Windows desktop background. There are two implementations >>>>> of setImage: one with hardwired MethodHandle works fine, but the >>>>> jextract version gives UnsupportedOperationException for layout >>>>> unrelated to SystemParametersInfoA. If I edit the generated code >>>>> to comment out all lines unrelated to SystemParametersInfoA then >>>>> both versions of setImage work. >>>> >>>> I think the culprit is this: >>>> >>>> ``` >>>> Caused by: java.lang.UnsupportedOperationException: Invalid >>>> alignment requirements for layout >>>> b64(ArbitraryUserPointer)[abi/kind=POINTER,layout/name=ArbitraryUserPointer] >>>> ??????? at >>>> jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.checkAlignment(LayoutPath.java:273) >>>> ??????? at >>>> jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.dereferenceHandle(LayoutPath.java:159) >>>> ??????? at >>>> jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.lambda$varHandle$2(MemoryLayout.java:488) >>>> ??????? at >>>> jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.computePathOp(MemoryLayout.java:534) >>>> ??????? at >>>> jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.varHandle(MemoryLayout.java:488) >>>> ??????? at >>>> duncan.win32.shobjidl_core.shlobj_core_h$constants$16.(shlobj_core_h$constants$16.java:1844) >>>> ``` >>>> >>>> This seems a duplicate of another issue that has been reported last >>>> week: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8259832 >>>> >>>> E.g. jextract ignoring alignment requirements. Note that jextract >>>> generates lots of constants, and it takes only one bad one to make >>>> initialization fail. >>>> >>>>> >>>>> The jextract command on Windows 10 (with fresh Vis Studio >>>>> installation) expands shlobj_core.h because I my app also uses >>>>> IShellLink. >>>>> >>>>> ???? set "WINKIT=c:\Program Files (x86)\Windows >>>>> Kits\10\Include\10.0.18362.0" >>>>> ???? jextract --source -t duncan.win32.shobjidl_core -d >>>>> shlobj_core.h/java ??? "%WINKIT%/um/shlobj_core.h" >>>>> >>>>> Another issue is that this single windows header file gives rise >>>>> to 11MB jar and is unusable inside Eclipse (on my slow PC), and is >>>>> slow startup at runtime. Have you considered changing the >>>>> generated code to use lazy Supplier instead of >>>>> MethodHandle to ensure only required handles are created on-demand? >>>> >>>> Uhm... we are already using dynamic constants, so you should only >>>> pay for the MHs and VHs you use - e.g. in fact I'm even surprised >>>> you get the failure inside the above - since that constant >>>> should not be initialized unless it's used. I wonder if there's a >>>> regression here... are you using the `--source` flag? With that >>>> flag we revert back to a monolithic header, so that will explain >>>> both failures. If so, try removing that flag - and see what happens >>>> (if everything is working as it should I don't think you should >>>> even see the error above, assuming you never use that layout). >>>> >>>> Maurizio >>>> >>>>> >>>>> Kind regards >>>>> >>>>> Duncan >>>>> >>>>> >>> > From maurizio.cimadamore at oracle.com Tue Jan 26 17:25:53 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 26 Jan 2021 17:25:53 +0000 Subject: [External] : Re: Feedback / query on jextract for Windows 10 In-Reply-To: <9071e122-8bb3-2688-f9f3-ba63f15e127f@gmail.com> References: <0e35502c-3656-9c23-eca8-4ca8a4377d15@gmail.com> <52aa2217-0795-a27b-8173-78b06be3f25b@gmail.com> <145ff947-5de4-3d7e-17b9-074842b0f2ce@oracle.com> <9071e122-8bb3-2688-f9f3-ba63f15e127f@gmail.com> Message-ID: Another fly by comment - have you tried using the --filter option so that jextract will just extract the header you want? e.g. you might try adding `--filter shlobj_core` and see what happens (but it might be too narrow of a filter). Maurizio On 26/01/2021 15:43, Duncan Gittins wrote: > I don't know what causes the speed difference, which may be down to > the jar size as you suggest. I'll re-test after the time that > "--source" generates same code as seen in the .class files when it may > be easier to understand why there is a difference. I am using > 16-panama+3-385. > > This isn't a very robust test, but I also tried deleted all the > un-necessary .class files from the 11MB jextract generated classes > (not produced using --source) down to 2MB jar, then I moved my > handcoded method into a separate class and added a dependency on a > different 2MB jar. Neither of those changes affected the typical > speeds of first call times - I still consistently see that the hand > coded method handle version of my app is ~300-500ms faster on first > call, and no difference for 2nd+ calls. > > Duncan > > On 25/01/2021 16:18, Maurizio Cimadamore wrote: >> >> On 25/01/2021 16:13, Duncan Gittins wrote: >>> Thanks for the information.? As you suspected that bug must be >>> related and there is a minor difference in the --source output >>> because the problem does go away when removing the jextract >>> "--source" flag and making jar directly from generated classes >>> rather than just compiling from the generated source code. >>> >>> My code samples using jextract bindings are ~300ms slower at startup >>> time (but same speed runtime). I'm not certain if this overhead is >>> down to initialisation of static constants or simply to be expected >>> when adding 11MB jar footprint (compared to 56k jar for my >>> handwritten MH bindings). I will follow-up if I find out more. >> If you see the startup slowdown even when omitting --source, then the >> issue is with loading the jar, rather than initializing - as >> explaining no initializing should happen outside for stuff that is >> actually used by your code - so I'd expect that initialization >> overhead for jextract code and your manually written versions should >> be roughly the same. >>> >>> Looking at the generated code for "xxx$constants$nn.java" there >>> seems to be a degree of unnecessary initialisation per >>> xxx$constants$nn class as it contains static variables for >>> FunctionDescriptor / MemoryLayout which would be initialised every >>> time that particular class was loaded and not used in my code. I >>> felt that my own jar was slow starting so switched foreign linker >>> references to a lazy load Supplier for every library / symbol / mh / >>> vh so that only the referenced types get created. >> >> Sure - but that's only when --source is used - when you generated >> classes directly, everything is lazy (and in a more general way than >> using Suppliers). >> >> So, can you please confirm, to be clear, that you still see startup >> regression even when NOT using "--source" ? >> >> Thanks! >> Maurizio >> >>> >>> I will have a look at future builds - this project is extremely >>> useful so I hope it gets into a full JDK release soon. Unfortunately >>> my issue with a huge jar in Eclipse means I can't easily develop >>> using the generated code variant right now, but in the meantime the >>> jextract code is still very helpful to work out how to call Windows >>> APIs correctly. >>> >>> Duncan >>> >>> On 25/01/2021 10:20, Maurizio Cimadamore wrote: >>>> >>>> On 23/01/2021 18:34, Duncan Gittins wrote: >>>>> I've been using Panama on Windows 10 to eliminate my C# apps which >>>>> I would normally call via ProcessBuilder. I'm very impressed so >>>>> far and looking forward to newer versions: everything I have >>>>> written in Windows C# is now replaced with foreign memory / linker >>>>> calls to native code using the latest Java 16 EA.? I have examples >>>>> for various Win32 API and COM objects, HWND objects and >>>>> screensaver. However I'm struggling to get the code running with >>>>> output from jextract build. Perhaps I overlooked something very >>>>> obvious in how to setup? >>>>> >>>>> One example app is attached - this calls SystemParametersInfoA to >>>>> set the Windows desktop background. There are two implementations >>>>> of setImage: one with hardwired MethodHandle works fine, but the >>>>> jextract version gives UnsupportedOperationException for layout >>>>> unrelated to SystemParametersInfoA. If I edit the generated code >>>>> to comment out all lines unrelated to SystemParametersInfoA then >>>>> both versions of setImage work. >>>> >>>> I think the culprit is this: >>>> >>>> ``` >>>> Caused by: java.lang.UnsupportedOperationException: Invalid >>>> alignment requirements for layout >>>> b64(ArbitraryUserPointer)[abi/kind=POINTER,layout/name=ArbitraryUserPointer] >>>> ??????? at >>>> jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.checkAlignment(LayoutPath.java:273) >>>> ??????? at >>>> jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.dereferenceHandle(LayoutPath.java:159) >>>> ??????? at >>>> jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.lambda$varHandle$2(MemoryLayout.java:488) >>>> ??????? at >>>> jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.computePathOp(MemoryLayout.java:534) >>>> ??????? at >>>> jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.varHandle(MemoryLayout.java:488) >>>> ??????? at >>>> duncan.win32.shobjidl_core.shlobj_core_h$constants$16.(shlobj_core_h$constants$16.java:1844) >>>> ``` >>>> >>>> This seems a duplicate of another issue that has been reported last >>>> week: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8259832 >>>> >>>> E.g. jextract ignoring alignment requirements. Note that jextract >>>> generates lots of constants, and it takes only one bad one to make >>>> initialization fail. >>>> >>>>> >>>>> The jextract command on Windows 10 (with fresh Vis Studio >>>>> installation) expands shlobj_core.h because I my app also uses >>>>> IShellLink. >>>>> >>>>> ???? set "WINKIT=c:\Program Files (x86)\Windows >>>>> Kits\10\Include\10.0.18362.0" >>>>> ???? jextract --source -t duncan.win32.shobjidl_core -d >>>>> shlobj_core.h/java ??? "%WINKIT%/um/shlobj_core.h" >>>>> >>>>> Another issue is that this single windows header file gives rise >>>>> to 11MB jar and is unusable inside Eclipse (on my slow PC), and is >>>>> slow startup at runtime. Have you considered changing the >>>>> generated code to use lazy Supplier instead of >>>>> MethodHandle to ensure only required handles are created on-demand? >>>> >>>> Uhm... we are already using dynamic constants, so you should only >>>> pay for the MHs and VHs you use - e.g. in fact I'm even surprised >>>> you get the failure inside the above - since that constant >>>> should not be initialized unless it's used. I wonder if there's a >>>> regression here... are you using the `--source` flag? With that >>>> flag we revert back to a monolithic header, so that will explain >>>> both failures. If so, try removing that flag - and see what happens >>>> (if everything is working as it should I don't think you should >>>> even see the error above, assuming you never use that layout). >>>> >>>> Maurizio >>>> >>>>> >>>>> Kind regards >>>>> >>>>> Duncan >>>>> >>>>> >>> > From github.com+7535718+rsmogura at openjdk.java.net Tue Jan 26 17:53:51 2021 From: github.com+7535718+rsmogura at openjdk.java.net (Radoslaw Smogura) Date: Tue, 26 Jan 2021 17:53:51 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v4] In-Reply-To: References: Message-ID: On Fri, 22 Jan 2021 22:15:27 GMT, Maurizio Cimadamore wrote: >> Hi all, >> >> I realized that my benchmarks contains small issue. I think @mcimadamore mentioned it, but I did not understood. >> >> The loops are counted using long instead of int. With int I've seen the loop get unrolled and the aligned to 1 loop is as fast as other tests. >> >> I'm not sure if at this stage I c an add modified benchmarks or should I opens new PR? > >> Hi all, >> >> I realized that my benchmarks contains small issue. I think @mcimadamore mentioned it, but I did not understood. >> >> The loops are counted using long instead of int. With int I've seen the loop get unrolled and the aligned to 1 loop is as fast as other tests. >> >> I'm not sure if at this stage I c an add modified benchmarks or should I opens new PR? > > Hi, > this PR is still open, since I forgot to integrate it (sorry). But this means that we can decide what to do. I see the issue with the benchmark - well spotted. At this point, to be honest, I'm unsure about the value of the proposed patch. It helps a bit for long loops, yes, but in the idiomatic use (e.g. with int) performances are the same. Given that better VM support for long loops is on the way, I'm not sure we should add more workarounds for longs (as it's proving already difficult to keep an inventory of all the hacks we have in the implementation in order to eliminate this hotspot issue). > > Would you be ok with just closing the PR, or, maybe just add the (revised) benchmark for the everything segment (which we don't currently have) ? > > Thanks! Hi Maurizio, I hope this message finds you well. Maybe let me add a benchmark first. In fact I never targeted this for loops, but for use cases where the access will be random, so when the chance to put checks outside loop are minimal. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/437 From mcimadamore at openjdk.java.net Tue Jan 26 22:47:59 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 26 Jan 2021 22:47:59 GMT Subject: [foreign-memaccess+abi] RFR: Performance improvement to unchecked segment ofNativeRestricted [v4] In-Reply-To: References: Message-ID: <6-2scSc-4V4Bhu-7re3nSRWgFhMVwncB8anNZs-hJGU=.60e486ff-9aab-4762-b611-9d0adbed36c3@github.com> On Tue, 26 Jan 2021 17:50:38 GMT, Radoslaw Smogura wrote: > Hi Maurizio, > > I hope this message finds you well. > > Maybe let me add a benchmark first. In fact I never targeted this for loops, but for use cases where the access will be random, so when the chance to put checks outside loop are minimal. Sure - let me know how that goes! Cheers. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/437 From augustnagro at gmail.com Wed Jan 27 01:22:48 2021 From: augustnagro at gmail.com (August Nagro) Date: Tue, 26 Jan 2021 17:22:48 -0800 Subject: Testing Vector API; which branch to build? Message-ID: Hello, I was testing the Vector API last month and I've noticed that Vlad's patch for branch prediction, as well as an improvement to slice() have been merged. I'm thinking of re-running some of my tests; which repo / branch do you suggest I build? Regards, August From jiefu at tencent.com Wed Jan 27 01:38:32 2021 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Wed, 27 Jan 2021 01:38:32 +0000 Subject: Testing Vector API; which branch to build?(Internet mail) In-Reply-To: References: Message-ID: <57548DC0-D057-43A0-9EB8-6859E435AD16@tencent.com> https://github.com/openjdk/panama-vector/tree/vectorIntrinsics , or https://github.com/openjdk/jdk Both of them will be updated from time to time. Since https://github.com/openjdk/panama-vector/tree/vectorIntrinsics had merged the master several days ago, I think it is fine to you. Thanks. ?On 2021/1/27, 9:26 AM, "panama-dev on behalf of August Nagro" wrote: Hello, I was testing the Vector API last month and I've noticed that Vlad's patch for branch prediction, as well as an improvement to slice() have been merged. I'm thinking of re-running some of my tests; which repo / branch do you suggest I build? Regards, August From augustnagro at gmail.com Wed Jan 27 02:34:42 2021 From: augustnagro at gmail.com (August Nagro) Date: Tue, 26 Jan 2021 18:34:42 -0800 Subject: Testing Vector API; which branch to build?(Internet mail) In-Reply-To: <57548DC0-D057-43A0-9EB8-6859E435AD16@tencent.com> References: <57548DC0-D057-43A0-9EB8-6859E435AD16@tencent.com> Message-ID: Thanks JieFu. On Tue, Jan 26, 2021 at 5:38 PM jiefu(??) wrote: > > https://github.com/openjdk/panama-vector/tree/vectorIntrinsics , or > https://github.com/openjdk/jdk > > Both of them will be updated from time to time. > > Since https://github.com/openjdk/panama-vector/tree/vectorIntrinsics had merged the master several days ago, I think it is fine to you. > > Thanks. > > ?On 2021/1/27, 9:26 AM, "panama-dev on behalf of August Nagro" wrote: > > Hello, > > I was testing the Vector API last month and I've noticed that Vlad's > patch for branch prediction, as well as an improvement to slice() have > been merged. > > I'm thinking of re-running some of my tests; which repo / branch do > you suggest I build? > > Regards, > > August > > > From njian at openjdk.java.net Wed Jan 27 09:24:09 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Wed, 27 Jan 2021 09:24:09 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE [v3] In-Reply-To: References: Message-ID: On Tue, 26 Jan 2021 08:56:07 GMT, Wang Huang wrote: >> This patch add cast nodes between interger types implementation for Arm SVE like "VectorCastB2X" "VectorCastI2X " "VectorCastS2X" "VectorCastL2X". > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > add other I2I cast nodes @Wanghuang-Huawei Thanks a lot for the work! Could you please do a merge and resolve the merge conflicts? src/hotspot/cpu/aarch64/aarch64_sve.ad line 2499: > 2497: predicate(UseSVE > 0 && n->bottom_type()->is_vect()->length_in_bytes() >= 16 && > 2498: n->bottom_type()->is_vect()->element_basic_type() == T_SHORT); > 2499: match(Set dst (VectorCastB2X src)); Is it possible to sort these newly added rules by Node name? So that it's easier to know whether there are still some rules missing. src/hotspot/share/opto/vectorIntrinsics.cpp line 441: > 439: if (Matcher::supports_scalable_vector()) { > 440: if (C->print_intrinsics()) { > 441: tty->print_cr(" ** shuffle to vector not supported on SVE"); I think it's a bit intrusive to do a workaround here, which will be removed soon, for SVE implementation in shared code. src/hotspot/share/opto/vectorIntrinsics.cpp line 334: > 332: // int start, int step, int wrap, ShuffleIotaOperation defaultImpl) > 333: bool LibraryCallKit::inline_vector_shuffle_iota() { > 334: // TODO shuffle is not supported on SVE This check is no necessary? Since SVE does not have Op_VectorLoadConst yet, arch_supports_vector() check below should return false. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/31 From whuang at openjdk.java.net Wed Jan 27 09:55:06 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Wed, 27 Jan 2021 09:55:06 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE [v4] In-Reply-To: References: Message-ID: > This patch add cast nodes between interger types implementation for Arm SVE like "VectorCastB2X" "VectorCastI2X " "VectorCastS2X" "VectorCastL2X". Wang Huang has updated the pull request incrementally with two additional commits since the last revision: - remove useless codes - remove walkaround codes ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/31/files - new: https://git.openjdk.java.net/panama-vector/pull/31/files/2a6df4e1..95fbbb7e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=31&range=03 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=31&range=02-03 Stats: 15 lines in 1 file changed: 0 ins; 15 del; 0 mod Patch: https://git.openjdk.java.net/panama-vector/pull/31.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/31/head:pull/31 PR: https://git.openjdk.java.net/panama-vector/pull/31 From lev at serebryakov.spb.ru Wed Jan 27 10:56:53 2021 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Wed, 27 Jan 2021 13:56:53 +0300 Subject: Can not built latest vectorIntrinsic on Windows (Was: Testing Vector API; which branch to build?) In-Reply-To: <57548DC0-D057-43A0-9EB8-6859E435AD16@tencent.com> References: <57548DC0-D057-43A0-9EB8-6859E435AD16@tencent.com> Message-ID: <61bad66a-c12c-2f49-351f-3dc6d6bc9746@serebryakov.spb.ru> On 27.01.2021 4:38, jiefu(??) wrote: I can not build https://github.com/openjdk/panama-vector/tree/vectorIntrinsics fcc36ceb040 on Windows 10 with MSVS 2019 Community There is problems with assembler source files: Microsoft (R) Macro Assembler Version 14.28.29336.0 Copyright (C) Microsoft Corporation. All rights reserved. Microsoft (R) Incremental Linker Version 14.28.29336.0 Copyright (C) Microsoft Corporation. All rights reserved. /OUT:svml_d_acos_windows_x86.exe c:\home\ref\panama-vector\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\svml_d_acos_windows_x86.obj LINK : fatal error LNK1561: entry point must be defined Assembling: c:\home\ref\panama-vector\src\hotspot\os_cpu\windows_x86\svml_d_acos_windows_x86.s make[3]: *** [lib/CompileJvm.gmk:143: /cygdrive/c/home/ref/panama-vector/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/svml_d_acos_windows_x86.obj] Error 25 make[3]: *** Deleting file '/cygdrive/c/home/ref/panama-vector/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/svml_d_acos_windows_x86.obj' > https://github.com/openjdk/panama-vector/tree/vectorIntrinsics , or > https://github.com/openjdk/jdk > > Both of them will be updated from time to time. > > Since https://github.com/openjdk/panama-vector/tree/vectorIntrinsics had merged the master several days ago, I think it is fine to you. -- // Black Lion AKA Lev Serebryakov From jiefu at tencent.com Wed Jan 27 13:25:08 2021 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Wed, 27 Jan 2021 13:25:08 +0000 Subject: Can not built latest vectorIntrinsic on Windows (Was: Testing Vector API; which branch to build?)(Internet mail) In-Reply-To: <61bad66a-c12c-2f49-351f-3dc6d6bc9746@serebryakov.spb.ru> References: <57548DC0-D057-43A0-9EB8-6859E435AD16@tencent.com> <61bad66a-c12c-2f49-351f-3dc6d6bc9746@serebryakov.spb.ru> Message-ID: <1C16FB85-B51C-4727-8FE8-5FE402C26AED@tencent.com> It works fine on my mac. So seems like a bug on Windows. Maybe, you have to try https://github.com/openjdk/jdk on Windows right now. ?On 2021/1/27, 7:01 PM, "panama-dev on behalf of Lev Serebryakov" wrote: On 27.01.2021 4:38, jiefu(??) wrote: I can not build https://github.com/openjdk/panama-vector/tree/vectorIntrinsics fcc36ceb040 on Windows 10 with MSVS 2019 Community There is problems with assembler source files: Microsoft (R) Macro Assembler Version 14.28.29336.0 Copyright (C) Microsoft Corporation. All rights reserved. Microsoft (R) Incremental Linker Version 14.28.29336.0 Copyright (C) Microsoft Corporation. All rights reserved. /OUT:svml_d_acos_windows_x86.exe c:\home\ref\panama-vector\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\svml_d_acos_windows_x86.obj LINK : fatal error LNK1561: entry point must be defined Assembling: c:\home\ref\panama-vector\src\hotspot\os_cpu\windows_x86\svml_d_acos_windows_x86.s make[3]: *** [lib/CompileJvm.gmk:143: /cygdrive/c/home/ref/panama-vector/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/svml_d_acos_windows_x86.obj] Error 25 make[3]: *** Deleting file '/cygdrive/c/home/ref/panama-vector/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/svml_d_acos_windows_x86.obj' > https://github.com/openjdk/panama-vector/tree/vectorIntrinsics , or > https://github.com/openjdk/jdk > > Both of them will be updated from time to time. > > Since https://github.com/openjdk/panama-vector/tree/vectorIntrinsics had merged the master several days ago, I think it is fine to you. -- // Black Lion AKA Lev Serebryakov From lev at serebryakov.spb.ru Wed Jan 27 14:27:05 2021 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Wed, 27 Jan 2021 17:27:05 +0300 Subject: Can not built latest vectorIntrinsic on Windows (Was: Testing Vector API; which branch to build?)(Internet mail) In-Reply-To: <1C16FB85-B51C-4727-8FE8-5FE402C26AED@tencent.com> References: <57548DC0-D057-43A0-9EB8-6859E435AD16@tencent.com> <61bad66a-c12c-2f49-351f-3dc6d6bc9746@serebryakov.spb.ru> <1C16FB85-B51C-4727-8FE8-5FE402C26AED@tencent.com> Message-ID: On 27.01.2021 16:25, jiefu(??) wrote: > It works fine on my mac. > So seems like a bug on Windows. > > Maybe, you have to try https://github.com/openjdk/jdk on Windows right now. It works as of master at 7ed591cc9a1c46f7c0b10a4c4ad3c181333bf5b6 So, there are problems only with assembler files added by panama/vectorIntrinsic... -- // Black Lion AKA Lev Serebryakov From duncan.gittins at gmail.com Wed Jan 27 14:36:09 2021 From: duncan.gittins at gmail.com (Duncan Gittins) Date: Wed, 27 Jan 2021 14:36:09 +0000 Subject: [External] : Re: Feedback / query on jextract for Windows 10 In-Reply-To: References: <0e35502c-3656-9c23-eca8-4ca8a4377d15@gmail.com> <52aa2217-0795-a27b-8173-78b06be3f25b@gmail.com> <145ff947-5de4-3d7e-17b9-074842b0f2ce@oracle.com> <9071e122-8bb3-2688-f9f3-ba63f15e127f@gmail.com> Message-ID: <54212946-48c0-2c17-541b-ea9442096304@gmail.com> Thanks, that's very helpful. Use of repeated --filter option solves my problem with huge jars - now down to 800k and cuts the first-time startup delay vs handcoded to around 50-150ms depending on the calls made. It might be helpful if there was a command line option to set the output class name so the top level classname isn't derived from the header file name. I avoid static imports, and would prefer to call say "Ole32.CoInitializeEx()" than "shlobj_core.CoInitializeEx()" for code derived from shlobj_core.h. This would also help for projects that had one master header file which set up #define for other includes. eg. Consider winuser.h: ?? set "WINKIT=c:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0" ?? jextract -luser32 -t duncan.win.user32 -d winuser.classes --filter winuser.h "%WINKIT%/um/winuser.h" ?? => Fails error: "No Target Architecture" ?? jextract -luser32 -t duncan.win.user32 -d winuser.classes --filter winuser.h "%WINKIT%/um/shlobj_core.h" ?? => Works fine, but the top level class name is shlobj_core_h which would same class name as for this jextract: ?? jextract -lshell32 -t duncan.win.shell32 -d shlobj_core.classes --filter shlobj_core.h "%WINKIT%/um/shlobj_core.h" However there is a very simple workaround: I can create a User32.h file which contains "#include " ??? jextract -luser32 -t duncan.win.user32 -d winuser.classes --filter winuser.h? -I "%WINKIT%/um" User32.h Duncan On 26/01/2021 17:25, Maurizio Cimadamore wrote: > Another fly by comment - have you tried using the --filter option so > that jextract will just extract the header you want? > > e.g. you might try adding `--filter shlobj_core` and see what happens > (but it might be too narrow of a filter). > > Maurizio > > > On 26/01/2021 15:43, Duncan Gittins wrote: >> I don't know what causes the speed difference, which may be down to >> the jar size as you suggest. I'll re-test after the time that >> "--source" generates same code as seen in the .class files when it >> may be easier to understand why there is a difference. I am using >> 16-panama+3-385. >> >> This isn't a very robust test, but I also tried deleted all the >> un-necessary .class files from the 11MB jextract generated classes >> (not produced using --source) down to 2MB jar, then I moved my >> handcoded method into a separate class and added a dependency on a >> different 2MB jar. Neither of those changes affected the typical >> speeds of first call times - I still consistently see that the hand >> coded method handle version of my app is ~300-500ms faster on first >> call, and no difference for 2nd+ calls. >> >> Duncan >> >> On 25/01/2021 16:18, Maurizio Cimadamore wrote: >>> >>> On 25/01/2021 16:13, Duncan Gittins wrote: >>>> Thanks for the information.? As you suspected that bug must be >>>> related and there is a minor difference in the --source output >>>> because the problem does go away when removing the jextract >>>> "--source" flag and making jar directly from generated classes >>>> rather than just compiling from the generated source code. >>>> >>>> My code samples using jextract bindings are ~300ms slower at >>>> startup time (but same speed runtime). I'm not certain if this >>>> overhead is down to initialisation of static constants or simply to >>>> be expected when adding 11MB jar footprint (compared to 56k jar for >>>> my handwritten MH bindings). I will follow-up if I find out more. >>> If you see the startup slowdown even when omitting --source, then >>> the issue is with loading the jar, rather than initializing - as >>> explaining no initializing should happen outside for stuff that is >>> actually used by your code - so I'd expect that initialization >>> overhead for jextract code and your manually written versions should >>> be roughly the same. >>>> >>>> Looking at the generated code for "xxx$constants$nn.java" there >>>> seems to be a degree of unnecessary initialisation per >>>> xxx$constants$nn class as it contains static variables for >>>> FunctionDescriptor / MemoryLayout which would be initialised every >>>> time that particular class was loaded and not used in my code. I >>>> felt that my own jar was slow starting so switched foreign linker >>>> references to a lazy load Supplier for every library / symbol / mh >>>> / vh so that only the referenced types get created. >>> >>> Sure - but that's only when --source is used - when you generated >>> classes directly, everything is lazy (and in a more general way than >>> using Suppliers). >>> >>> So, can you please confirm, to be clear, that you still see startup >>> regression even when NOT using "--source" ? >>> >>> Thanks! >>> Maurizio >>> >>>> >>>> I will have a look at future builds - this project is extremely >>>> useful so I hope it gets into a full JDK release soon. >>>> Unfortunately my issue with a huge jar in Eclipse means I can't >>>> easily develop using the generated code variant right now, but in >>>> the meantime the jextract code is still very helpful to work out >>>> how to call Windows APIs correctly. >>>> >>>> Duncan >>>> >>>> On 25/01/2021 10:20, Maurizio Cimadamore wrote: >>>>> >>>>> On 23/01/2021 18:34, Duncan Gittins wrote: >>>>>> I've been using Panama on Windows 10 to eliminate my C# apps >>>>>> which I would normally call via ProcessBuilder. I'm very >>>>>> impressed so far and looking forward to newer versions: >>>>>> everything I have written in Windows C# is now replaced with >>>>>> foreign memory / linker calls to native code using the latest >>>>>> Java 16 EA.? I have examples for various Win32 API and COM >>>>>> objects, HWND objects and screensaver. However I'm struggling to >>>>>> get the code running with output from jextract build. Perhaps I >>>>>> overlooked something very obvious in how to setup? >>>>>> >>>>>> One example app is attached - this calls SystemParametersInfoA to >>>>>> set the Windows desktop background. There are two implementations >>>>>> of setImage: one with hardwired MethodHandle works fine, but the >>>>>> jextract version gives UnsupportedOperationException for layout >>>>>> unrelated to SystemParametersInfoA. If I edit the generated code >>>>>> to comment out all lines unrelated to SystemParametersInfoA then >>>>>> both versions of setImage work. >>>>> >>>>> I think the culprit is this: >>>>> >>>>> ``` >>>>> Caused by: java.lang.UnsupportedOperationException: Invalid >>>>> alignment requirements for layout >>>>> b64(ArbitraryUserPointer)[abi/kind=POINTER,layout/name=ArbitraryUserPointer] >>>>> ??????? at >>>>> jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.checkAlignment(LayoutPath.java:273) >>>>> ??????? at >>>>> jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.dereferenceHandle(LayoutPath.java:159) >>>>> ??????? at >>>>> jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.lambda$varHandle$2(MemoryLayout.java:488) >>>>> ??????? at >>>>> jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.computePathOp(MemoryLayout.java:534) >>>>> ??????? at >>>>> jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.varHandle(MemoryLayout.java:488) >>>>> ??????? at >>>>> duncan.win32.shobjidl_core.shlobj_core_h$constants$16.(shlobj_core_h$constants$16.java:1844) >>>>> ``` >>>>> >>>>> This seems a duplicate of another issue that has been reported >>>>> last week: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8259832 >>>>> >>>>> E.g. jextract ignoring alignment requirements. Note that jextract >>>>> generates lots of constants, and it takes only one bad one to make >>>>> initialization fail. >>>>> >>>>>> >>>>>> The jextract command on Windows 10 (with fresh Vis Studio >>>>>> installation) expands shlobj_core.h because I my app also uses >>>>>> IShellLink. >>>>>> >>>>>> ???? set "WINKIT=c:\Program Files (x86)\Windows >>>>>> Kits\10\Include\10.0.18362.0" >>>>>> ???? jextract --source -t duncan.win32.shobjidl_core -d >>>>>> shlobj_core.h/java ??? "%WINKIT%/um/shlobj_core.h" >>>>>> >>>>>> Another issue is that this single windows header file gives rise >>>>>> to 11MB jar and is unusable inside Eclipse (on my slow PC), and >>>>>> is slow startup at runtime. Have you considered changing the >>>>>> generated code to use lazy Supplier instead of >>>>>> MethodHandle to ensure only required handles are created on-demand? >>>>> >>>>> Uhm... we are already using dynamic constants, so you should only >>>>> pay for the MHs and VHs you use - e.g. in fact I'm even surprised >>>>> you get the failure inside the above - since that >>>>> constant should not be initialized unless it's used. I wonder if >>>>> there's a regression here... are you using the `--source` flag? >>>>> With that flag we revert back to a monolithic header, so that will >>>>> explain both failures. If so, try removing that flag - and see >>>>> what happens (if everything is working as it should I don't think >>>>> you should even see the error above, assuming you never use that >>>>> layout). >>>>> >>>>> Maurizio >>>>> >>>>>> >>>>>> Kind regards >>>>>> >>>>>> Duncan >>>>>> >>>>>> >>>> >> From maurizio.cimadamore at oracle.com Wed Jan 27 14:45:35 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 27 Jan 2021 14:45:35 +0000 Subject: [External] : Re: Feedback / query on jextract for Windows 10 In-Reply-To: <54212946-48c0-2c17-541b-ea9442096304@gmail.com> References: <0e35502c-3656-9c23-eca8-4ca8a4377d15@gmail.com> <52aa2217-0795-a27b-8173-78b06be3f25b@gmail.com> <145ff947-5de4-3d7e-17b9-074842b0f2ce@oracle.com> <9071e122-8bb3-2688-f9f3-ba63f15e127f@gmail.com> <54212946-48c0-2c17-541b-ea9442096304@gmail.com> Message-ID: <85c45929d16d027c90f43259b6dcdd4e5104369e.camel@oracle.com> Hi Duncan, On Wed, 2021-01-27 at 14:36 +0000, Duncan Gittins wrote: > Thanks, that's very helpful. Use of repeated --filter option solves > my > problem with huge jars - now down to 800k and cuts the first-time > startup delay vs handcoded to around 50-150ms depending on the calls > made. I'm happy that the filter option worked for you! I still have to investigate on the startup issue. > > It might be helpful if there was a command line option to set the > output > class name so the top level classname isn't derived from the header > file > name. I avoid static imports, and would prefer to call say > "Ole32.CoInitializeEx()" than "shlobj_core.CoInitializeEx()" for > code > derived from shlobj_core.h. I think this is a good suggestion. While inferring from header file is a good "default" I agree that it should be possible to override this, especially now that a single header file is generated (the reason we don't have this is that it was harder to to in the previous design). > > This would also help for projects that had one master header file > which > set up #define for other includes. eg. Consider winuser.h: > > set "WINKIT=c:\Program Files (x86)\Windows > Kits\10\Include\10.0.18362.0" > jextract -luser32 -t duncan.win.user32 -d winuser.classes -- > filter > winuser.h "%WINKIT%/um/winuser.h" > => Fails error: "No Target Architecture" > > jextract -luser32 -t duncan.win.user32 -d winuser.classes -- > filter > winuser.h "%WINKIT%/um/shlobj_core.h" > => Works fine, but the top level class name is shlobj_core_h > which > would same class name as for this jextract: > > jextract -lshell32 -t duncan.win.shell32 -d shlobj_core.classes > --filter shlobj_core.h "%WINKIT%/um/shlobj_core.h" > > However there is a very simple workaround: I can create a User32.h > file > which contains "#include " Yes! I expect this kind of workaround to be unavoidable in the general cases - especially when dealing with very large monolithic headers such as Windows.h. Ideally, one day, IDEs might provide some integration for this, so that maybe when you extract you get a nice dialog with all the "discovered symbols" and you can manually click on the ones you want to import. This is why our aim is to provide not just a tool, but also some kind of API, so that this kind of IDE plugin will, one day, be possible. CheersMaurizio > > jextract -luser32 -t duncan.win.user32 -d winuser.classes -- > filter > winuser.h -I "%WINKIT%/um" User32.h > > Duncan > > On 26/01/2021 17:25, Maurizio Cimadamore wrote: > > Another fly by comment - have you tried using the --filter option > > so > > that jextract will just extract the header you want? > > > > e.g. you might try adding `--filter shlobj_core` and see what > > happens > > (but it might be too narrow of a filter). > > > > Maurizio > > > > > > On 26/01/2021 15:43, Duncan Gittins wrote: > > > I don't know what causes the speed difference, which may be down > > > to > > > the jar size as you suggest. I'll re-test after the time that > > > "--source" generates same code as seen in the .class files when > > > it > > > may be easier to understand why there is a difference. I am > > > using > > > 16-panama+3-385. > > > > > > This isn't a very robust test, but I also tried deleted all the > > > un-necessary .class files from the 11MB jextract generated > > > classes > > > (not produced using --source) down to 2MB jar, then I moved my > > > handcoded method into a separate class and added a dependency on > > > a > > > different 2MB jar. Neither of those changes affected the typical > > > speeds of first call times - I still consistently see that the > > > hand > > > coded method handle version of my app is ~300-500ms faster on > > > first > > > call, and no difference for 2nd+ calls. > > > > > > Duncan > > > > > > On 25/01/2021 16:18, Maurizio Cimadamore wrote: > > > > On 25/01/2021 16:13, Duncan Gittins wrote: > > > > > Thanks for the information. As you suspected that bug must > > > > > be > > > > > related and there is a minor difference in the --source > > > > > output > > > > > because the problem does go away when removing the jextract > > > > > "--source" flag and making jar directly from generated > > > > > classes > > > > > rather than just compiling from the generated source code. > > > > > > > > > > My code samples using jextract bindings are ~300ms slower at > > > > > startup time (but same speed runtime). I'm not certain if > > > > > this > > > > > overhead is down to initialisation of static constants or > > > > > simply to > > > > > be expected when adding 11MB jar footprint (compared to 56k > > > > > jar for > > > > > my handwritten MH bindings). I will follow-up if I find out > > > > > more. > > > > If you see the startup slowdown even when omitting --source, > > > > then > > > > the issue is with loading the jar, rather than initializing - > > > > as > > > > explaining no initializing should happen outside for stuff that > > > > is > > > > actually used by your code - so I'd expect that initialization > > > > overhead for jextract code and your manually written versions > > > > should > > > > be roughly the same. > > > > > Looking at the generated code for "xxx$constants$nn.java" > > > > > there > > > > > seems to be a degree of unnecessary initialisation per > > > > > xxx$constants$nn class as it contains static variables for > > > > > FunctionDescriptor / MemoryLayout which would be initialised > > > > > every > > > > > time that particular class was loaded and not used in my > > > > > code. I > > > > > felt that my own jar was slow starting so switched foreign > > > > > linker > > > > > references to a lazy load Supplier for every library / symbol > > > > > / mh > > > > > / vh so that only the referenced types get created. > > > > > > > > Sure - but that's only when --source is used - when you > > > > generated > > > > classes directly, everything is lazy (and in a more general way > > > > than > > > > using Suppliers). > > > > > > > > So, can you please confirm, to be clear, that you still see > > > > startup > > > > regression even when NOT using "--source" ? > > > > > > > > Thanks! > > > > Maurizio > > > > > > > > > I will have a look at future builds - this project is > > > > > extremely > > > > > useful so I hope it gets into a full JDK release soon. > > > > > Unfortunately my issue with a huge jar in Eclipse means I > > > > > can't > > > > > easily develop using the generated code variant right now, > > > > > but in > > > > > the meantime the jextract code is still very helpful to work > > > > > out > > > > > how to call Windows APIs correctly. > > > > > > > > > > Duncan > > > > > > > > > > On 25/01/2021 10:20, Maurizio Cimadamore wrote: > > > > > > On 23/01/2021 18:34, Duncan Gittins wrote: > > > > > > > I've been using Panama on Windows 10 to eliminate my C# > > > > > > > apps > > > > > > > which I would normally call via ProcessBuilder. I'm very > > > > > > > impressed so far and looking forward to newer versions: > > > > > > > everything I have written in Windows C# is now replaced > > > > > > > with > > > > > > > foreign memory / linker calls to native code using the > > > > > > > latest > > > > > > > Java 16 EA. I have examples for various Win32 API and > > > > > > > COM > > > > > > > objects, HWND objects and screensaver. However I'm > > > > > > > struggling to > > > > > > > get the code running with output from jextract build. > > > > > > > Perhaps I > > > > > > > overlooked something very obvious in how to setup? > > > > > > > > > > > > > > One example app is attached - this calls > > > > > > > SystemParametersInfoA to > > > > > > > set the Windows desktop background. There are two > > > > > > > implementations > > > > > > > of setImage: one with hardwired MethodHandle works fine, > > > > > > > but the > > > > > > > jextract version gives UnsupportedOperationException for > > > > > > > layout > > > > > > > unrelated to SystemParametersInfoA. If I edit the > > > > > > > generated code > > > > > > > to comment out all lines unrelated to > > > > > > > SystemParametersInfoA then > > > > > > > both versions of setImage work. > > > > > > > > > > > > I think the culprit is this: > > > > > > > > > > > > ``` > > > > > > Caused by: java.lang.UnsupportedOperationException: > > > > > > Invalid > > > > > > alignment requirements for layout > > > > > > b64(ArbitraryUserPointer)[abi/kind=POINTER,layout/name=Arbi > > > > > > traryUserPointer] > > > > > > at > > > > > > jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.check > > > > > > Alignment(LayoutPath.java:273) > > > > > > at > > > > > > jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.deref > > > > > > erenceHandle(LayoutPath.java:159) > > > > > > at > > > > > > jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.la > > > > > > mbda$varHandle$2(MemoryLayout.java:488) > > > > > > at > > > > > > jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.co > > > > > > mputePathOp(MemoryLayout.java:534) > > > > > > at > > > > > > jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.va > > > > > > rHandle(MemoryLayout.java:488) > > > > > > at > > > > > > duncan.win32.shobjidl_core.shlobj_core_h$constants$16. > > > > > it>(shlobj_core_h$constants$16.java:1844) > > > > > > ``` > > > > > > > > > > > > This seems a duplicate of another issue that has been > > > > > > reported > > > > > > last week: > > > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8259832 > > > > > > > > > > > > E.g. jextract ignoring alignment requirements. Note that > > > > > > jextract > > > > > > generates lots of constants, and it takes only one bad one > > > > > > to make > > > > > > initialization fail. > > > > > > > > > > > > > The jextract command on Windows 10 (with fresh Vis > > > > > > > Studio > > > > > > > installation) expands shlobj_core.h because I my app also > > > > > > > uses > > > > > > > IShellLink. > > > > > > > > > > > > > > set "WINKIT=c:\Program Files (x86)\Windows > > > > > > > Kits\10\Include\10.0.18362.0" > > > > > > > jextract --source -t duncan.win32.shobjidl_core -d > > > > > > > shlobj_core.h/java "%WINKIT%/um/shlobj_core.h" > > > > > > > > > > > > > > Another issue is that this single windows header file > > > > > > > gives rise > > > > > > > to 11MB jar and is unusable inside Eclipse (on my slow > > > > > > > PC), and > > > > > > > is slow startup at runtime. Have you considered changing > > > > > > > the > > > > > > > generated code to use lazy Supplier instead > > > > > > > of > > > > > > > MethodHandle to ensure only required handles are created > > > > > > > on-demand? > > > > > > > > > > > > Uhm... we are already using dynamic constants, so you > > > > > > should only > > > > > > pay for the MHs and VHs you use - e.g. in fact I'm even > > > > > > surprised > > > > > > you get the failure inside the above - since that > > > > > > constant should not be initialized unless it's used. I > > > > > > wonder if > > > > > > there's a regression here... are you using the `--source` > > > > > > flag? > > > > > > With that flag we revert back to a monolithic header, so > > > > > > that will > > > > > > explain both failures. If so, try removing that flag - and > > > > > > see > > > > > > what happens (if everything is working as it should I don't > > > > > > think > > > > > > you should even see the error above, assuming you never use > > > > > > that > > > > > > layout). > > > > > > > > > > > > Maurizio > > > > > > > > > > > > > Kind regards > > > > > > > > > > > > > > Duncan > > > > > > > > > > > > > > From mr.chrisvest at gmail.com Wed Jan 27 15:28:58 2021 From: mr.chrisvest at gmail.com (Chris Vest) Date: Wed, 27 Jan 2021 16:28:58 +0100 Subject: memory access - pulling all the threads In-Reply-To: References: Message-ID: This API looks pretty good, I agree. Would the resource scope locking for memory segment based byte buffers happen inside the relevant channel IO methods, say? I didn't see such changes in the code yet. Chris On Mon, 25 Jan 2021 at 18:52, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Hi, > as you know, I've been looking at both internal and external feedback on > usage of the memory access API, in an attempt to understand what the > problem with the API are, and how to move forward. As discussed here > [1], there are some things which work well, such as structured access, > or recent addition to shared segment support (the latter seem to have > enabled a wide variety of experiments which allowed us to gather more > feedback - thanks!). But there are still some issues to be resolved - > which could be summarized as "the MemorySegment abstraction is trying to > do too many things at once" (again, please refer to [1] for a more > detailed description of the problem involved). > > In [1] I described a possible approach where every allocation method > (MemorySegment::allocateNative and MemorySegment::mapFile) return a > "allocation handle", not a segment directly. The handle is the closeable > entity, while the segment is just a view. While this approach is > workable (and something very similar has indeed been explored here [2]), > after implementing some parts of it, I was left not satisfied with how > this approach integrates with respect to the foreign linker support. For > instance, defining the behavior of methods such as CLinker::toCString > becomes quite convoluted: where does the allocation handle associated > with the returned string comes from? If the segment has no pointer to > the handle, how can the memory associated to the string be closed? What > is the relationship between an allocation handle and a NativeScope? All > these questions led me to conclude that the proposed approach was not > enough, and that we needed to try harder. > > The above approach does one thing right: it splits memory segments from > the entity managing allocation/closure of memory resources, thus turning > memory segments into dumb views. But it doesn't go far enough in this > direction; as it turns out, what we really want here is a way to capture > the concept of the lifecycle that is associated to one or more > (logically related) resources - which, unsurprisingly, is part of what > NativeScope does too. So, let's try to model this abstraction: > > ``` > interface ResourceScope extends AutoCloseable { > void addOnClose(Runnable) // adds a new cleanup action to this scope > void close() // closes the scope > > static ResourceScope ofConfined() // creates a confined resource scope > static ResourceScope ofShared() // creates a shared resource scope > static ResourceScope ofConfined(Cleaner) // creates a confined > resource scope - managed by cleaner > static ResourceScope ofShared(Cleaner) // creates a shared resource > scope - managed by cleaner > } > ``` > > It's a very simple interface - you can basically add new cleanup actions > to it, which will be called when the scope is closed; note that > ResourceScope supports implicit close (via a Cleaner), or explicit close > (via the close method) - it can even support both (not shown here). > > Armed with this new abstraction, let's try to see if we can shine new > light onto some of the existing API methods and abstractions. > > Let's start with heap segments - these are allocated using one of the > MemorySegment::ofArray() factories; one of the issues with heap segments > is that it doesn't make much sense to close them. In the proposed > approach, this can be handled nicely: heap segments are associated with > a _global_ scope that cannot be closed - a scope that is _always alive_. > This clarifies the role of heap segments (and also of buffer segments) > nicely. > > Let's proceed to MemorySegment::allocateNative/mapFile - what should > these factories do? Under the new proposal, these method should accept a > ResourceScope parameter, which defines the lifecycle to which the newly > created segment should be attached to. If we want to still provide > ResourceScope-less overloads (as the API does now) we can pick a useful > default: a shared, non-closeable, cleaner-backed scope. This choice > gives us essentially the same semantics as a byte buffer, so it would be > an ideal starting point for developers coming from the ByteBuffer API > trying to familiarize with the new memory access API. Note that, when > using these more compact factories, scopes are almost entirely hidden > from the client - so no extra complexity is added (compared e.g. to the > ByteBuffer API). > > As it turns out, ResourceScope is not only useful for segments, but it > is also useful for a number of entities which need to be attached to > some lifecycle, such as: > > * upcall stubs > * va lists > * loaded libraries > > The upcall stub case is particularly telling: in that case, we have > decided to model an upcall stub as a MemorySegment not because it makes > sense to dereference an upcall stub - but simply because we need to have > a way to _release_ the upcall stub once we're done using it. Under the > new proposal, we have a new, powerful option: the upcall stub API point > can accept an user-provided ResourceScope which will be responsible for > managing the lifecycle of the upcall stub entity. That is, we are now > free to turn the result of a call to upcallStub to something other than > a MemorySegment (e.g. a FunctionPointer?) w/o loss of functionality. > > Resource scopes are very useful to manage _group_ of resources - there > are in fact cases where one or more segments share the same lifecycle - > that is, they need to be all alive at the same time; to handle some of > these use cases, the status quo adds the NativeScope abstraction, which > can accept registration of external memory segment (via the > MemorySegment::handoff) API. This use case is naturally handled by the > ResourceScope API: > > ``` > try (ResourceScope scope : ResourceScope.ofConfined()) { > MemorySegment.allocateNative(layout, scope): > MemorySegment.mapFile(... , scope); > CLinker.upcallStub(..., scope); > } // release all resources > ``` > > Does this remove the need for NativeScope ? Not so fast: NativeScope is > used to group logically related resources, yes, but is also used as a > faster, arena-based allocator - which attempts to minimize the number of > system calls (e.g. to malloc) by allocating bigger memory blocks and > then handing over slices to clients. Let's try to model the > allocation-nature of a NativeScope with a separate interface, as follows: > > ``` > @FunctionalInterface > interface NativeAllocator { > MemorySegment allocate(long size, long align); > default allocateInt(MemoryLayout intLayout, int value) { ... } > default allocateLong(MemoryLayout intLayout, long value) { ... } > ... // all allocation helpers in NativeScope > } > ``` > > At first, it seems this interface doesn't add much. But it is quite > powerful - for instance, a client can create a simple, malloc-like > allocator, as follows: > > ``` > NativeAllocator malloc = (size, align) -> > MemorySegment.allocateNative(size, align, ResourceScope.ofConfined()); > > ``` > > This is an allocator which allocates a new region of memory on each > allocation request, backed by a fresh confined scope (which can be > closed independently). This idiom is in fact so common that the API > allows client to create these allocators in a more compact fashion: > > ``` > NativeAllocator confinedMalloc = > NativeAllocator.ofMalloc(ResourceScope::ofConfined); > NativeAllocator sharedMalloc = > NativeAllocator.ofMalloc(ResourceScope::ofConfined); > ``` > > But other strategies are also possible: > > * arena allocation (e.g. the allocation strategy currently used by > NativeScope) > * recycling allocation (a single segment, with given layout, is > allocated, and allocation requests are served by repeatedly slicing that > very segment) - this is a critical optimization in e.g. loops > * interop with custom allocators > > So, where would we accept a NativeAllocator in our API? Turns out that > accepting an allocator is handy whenever an API point needs to allocate > some native memory - so, instead of > > ``` > MemorySegment toCString(String) > ``` > > This is better: > > ``` > MemorySegment toCString(String, NativeAllocator) > ``` > > Of course, we need to tweak the foreign linker, so that in all foreign > calls returning a struct by value (which require some allocation), a > NativeAllocator prefix argument is added to the method handle, so that > the user can specify which allocator should be used by the call; this is > a straightforward change which greatly enhances the expressive power of > the linker API. > > So, we are in a place where some methods (e.g. factories which create > some resource) takes an additional ResourceScope argument - and some > other methods (e.g. methods that need to allocate native segments) which > take an additional NativeAllocator argument. Now, it would be > inconvenient for the user to have to create both, at least in simple use > cases - but, since these are interfaces, nothing prevents us from > creating a new abstraction which implements _both_ ResourceScope _and_ > NativeAllocator - in fact this is exactly what the role of the already > existing NativeScope is! > > ``` > interface NativeScope extends NativeAllocator, ResourceScope { ... } > ``` > > In other words, we have retconned the existing NativeScope abstraction, > by explaining its behavior in terms of more primitive abstractions > (scopes and allocators). This means that clients can, for the most part, > just create a NativeScope and then pass it whenever a ResourceScope or a > NativeAllocator is required (which is what is already happening in all > of our jextract examples). > > There are some additional bonus points of this approach. > > First, ResourceScope features some locking capabilities - e.g. you can > do things like: > > ``` > try (ResourceScope.Lock lock = segment.scope().lock()) { > > } > ``` > > Which allows clients to perform segment critical operations w/o worrying > that a segment memory will be reclaimed while in the middle of the > operation. This solves the problem with async operation on byte buffers > derived from shared segments (see [3]). > > Another bonus point is that the ResourceScope interface is completely > segment-agnostic - in fact, we have now a way to describe APIs which > return resources which must be cleaned by the user (or, implicitly, by > the GC). For instance, it would be entirely reasonable to imagine, one > day, the ByteBuffer API to provide an additional factory - e.g. > allocateDirect(int size, ResourceScope scope) - which gives you a direct > buffer attached to a given (closeable) scope. The same trick can > probably be used in other APIs as well where implicit cleanup has been > preferred for performance and/or safety reasons. > > tl;dr; > > This restacking described in this email enhances the Foreign Memory > Access API in many different ways, and allows clients to approach the > API in increasing degrees of complexity (depending on needs): > > * for smoother transition, coming from the ByteBuffer API, users can > only have swap ByteBuffer::allocateDirect with > MemorySegment::allocateNative - not much else changes, no need to think > about lifecycles (and ResourceScope); GC is still in charge of deallocation > * users that want tighter control over resources, can dive deeper and > learn how segments (and other resources) are attached to a resource > scope (which can be closed safely, if needed) > * for the native interop case, the NativeScope abstraction is retconned > to be both a ResourceScope *and* a NativeAllocator - so it can be used > whenever an API needs to know how to _allocate_ or which _lifecycle_ > should be used for a newly created resource > * scopes can be locked, which allows clients to write critical sections > in which a segment has to be operated upon w/o fear of it being closed > * the idiom described here can be used to e.g. enhance the ByteBuffer > API and to add close capabilities there > > All the above require very little changes to the clients of the memory > access API. The biggest change is that a MemorySegment no longer > supports the AutoCloseable interface, which is instead moved to > ResourceScope. While this can get a little more verbose in case you need > a single segment, the code scales _a lot_ better in case you need > multiple segments/resources. Existing clients using jextract-generated > APIs, on the other hand, are not affected much, since they are mostly > dependent on the NativeScope API, which this proposal does not alter > (although the role of a NativeScope is now retconned to be allocator + > scope). > > You can find a branch which implements some of the changes described > above (except the changes to the foreign linker API) here: > > https://github.com/mcimadamore/panama-foreign/tree/resourceScope > > While an initial javadoc of the API described in this email can be found > here: > > > http://cr.openjdk.java.net/~mcimadamore/panama/resourceScope-javadoc_v2/javadoc/jdk/incubator/foreign/package-summary.html > > > Cheers > Maurizio > > [1] - > https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011700.html > [2] - https://datasketches.apache.org/docs/Memory/MemoryPackage.html > [3] - > https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011810.html > > > From maurizio.cimadamore at oracle.com Wed Jan 27 15:40:32 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 27 Jan 2021 15:40:32 +0000 Subject: [External] : Re: memory access - pulling all the threads In-Reply-To: References: Message-ID: <86b94dd24cfe898014206b8d6afcbe52dea71888.camel@oracle.com> On Wed, 2021-01-27 at 16:28 +0100, Chris Vest wrote: > This API looks pretty good, I agree. > > Would the resource scope locking for memory segment based byte > buffers happen inside the relevant channel IO methods, say? I didn't > see such changes in the code yet. Yes, basically, in all places where we are using DirectBuffer::address, we would need to add a lock try-with-resources, to make sure the address remains valid for the entire duration of the call. This work has not started yet (I wanted to gather some feedback on the general direction first ;-)). ThanksMaurizio > > Chris > > On Mon, 25 Jan 2021 at 18:52, Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > > Hi, > > as you know, I've been looking at both internal and external > > feedback on > > usage of the memory access API, in an attempt to understand what > > the > > problem with the API are, and how to move forward. As discussed > > here > > [1], there are some things which work well, such as structured > > access, > > or recent addition to shared segment support (the latter seem to > > have > > enabled a wide variety of experiments which allowed us to gather > > more > > feedback - thanks!). But there are still some issues to be resolved > > - > > which could be summarized as "the MemorySegment abstraction is > > trying to > > do too many things at once" (again, please refer to [1] for a more > > detailed description of the problem involved). > > > > In [1] I described a possible approach where every allocation > > method > > (MemorySegment::allocateNative and MemorySegment::mapFile) return > > a > > "allocation handle", not a segment directly. The handle is the > > closeable > > entity, while the segment is just a view. While this approach is > > workable (and something very similar has indeed been explored here > > [2]), > > after implementing some parts of it, I was left not satisfied with > > how > > this approach integrates with respect to the foreign linker > > support. For > > instance, defining the behavior of methods such as > > CLinker::toCString > > becomes quite convoluted: where does the allocation handle > > associated > > with the returned string comes from? If the segment has no pointer > > to > > the handle, how can the memory associated to the string be closed? > > What > > is the relationship between an allocation handle and a NativeScope? > > All > > these questions led me to conclude that the proposed approach was > > not > > enough, and that we needed to try harder. > > > > The above approach does one thing right: it splits memory segments > > from > > the entity managing allocation/closure of memory resources, thus > > turning > > memory segments into dumb views. But it doesn't go far enough in > > this > > direction; as it turns out, what we really want here is a way to > > capture > > the concept of the lifecycle that is associated to one or more > > (logically related) resources - which, unsurprisingly, is part of > > what > > NativeScope does too. So, let's try to model this abstraction: > > > > ``` > > interface ResourceScope extends AutoCloseable { > > void addOnClose(Runnable) // adds a new cleanup action to this > > scope > > void close() // closes the scope > > > > static ResourceScope ofConfined() // creates a confined > > resource scope > > static ResourceScope ofShared() // creates a shared resource > > scope > > static ResourceScope ofConfined(Cleaner) // creates a confined > > resource scope - managed by cleaner > > static ResourceScope ofShared(Cleaner) // creates a shared > > resource > > scope - managed by cleaner > > } > > ``` > > > > It's a very simple interface - you can basically add new cleanup > > actions > > to it, which will be called when the scope is closed; note that > > ResourceScope supports implicit close (via a Cleaner), or explicit > > close > > (via the close method) - it can even support both (not shown here). > > > > Armed with this new abstraction, let's try to see if we can shine > > new > > light onto some of the existing API methods and abstractions. > > > > Let's start with heap segments - these are allocated using one of > > the > > MemorySegment::ofArray() factories; one of the issues with heap > > segments > > is that it doesn't make much sense to close them. In the proposed > > approach, this can be handled nicely: heap segments are associated > > with > > a _global_ scope that cannot be closed - a scope that is _always > > alive_. > > This clarifies the role of heap segments (and also of buffer > > segments) > > nicely. > > > > Let's proceed to MemorySegment::allocateNative/mapFile - what > > should > > these factories do? Under the new proposal, these method should > > accept a > > ResourceScope parameter, which defines the lifecycle to which the > > newly > > created segment should be attached to. If we want to still provide > > ResourceScope-less overloads (as the API does now) we can pick a > > useful > > default: a shared, non-closeable, cleaner-backed scope. This > > choice > > gives us essentially the same semantics as a byte buffer, so it > > would be > > an ideal starting point for developers coming from the ByteBuffer > > API > > trying to familiarize with the new memory access API. Note that, > > when > > using these more compact factories, scopes are almost entirely > > hidden > > from the client - so no extra complexity is added (compared e.g. to > > the > > ByteBuffer API). > > > > As it turns out, ResourceScope is not only useful for segments, but > > it > > is also useful for a number of entities which need to be attached > > to > > some lifecycle, such as: > > > > * upcall stubs > > * va lists > > * loaded libraries > > > > The upcall stub case is particularly telling: in that case, we > > have > > decided to model an upcall stub as a MemorySegment not because it > > makes > > sense to dereference an upcall stub - but simply because we need to > > have > > a way to _release_ the upcall stub once we're done using it. Under > > the > > new proposal, we have a new, powerful option: the upcall stub API > > point > > can accept an user-provided ResourceScope which will be responsible > > for > > managing the lifecycle of the upcall stub entity. That is, we are > > now > > free to turn the result of a call to upcallStub to something other > > than > > a MemorySegment (e.g. a FunctionPointer?) w/o loss of > > functionality. > > > > Resource scopes are very useful to manage _group_ of resources - > > there > > are in fact cases where one or more segments share the same > > lifecycle - > > that is, they need to be all alive at the same time; to handle some > > of > > these use cases, the status quo adds the NativeScope abstraction, > > which > > can accept registration of external memory segment (via the > > MemorySegment::handoff) API. This use case is naturally handled by > > the > > ResourceScope API: > > > > ``` > > try (ResourceScope scope : ResourceScope.ofConfined()) { > > MemorySegment.allocateNative(layout, scope): > > MemorySegment.mapFile(... , scope); > > CLinker.upcallStub(..., scope); > > } // release all resources > > ``` > > > > Does this remove the need for NativeScope ? Not so fast: > > NativeScope is > > used to group logically related resources, yes, but is also used as > > a > > faster, arena-based allocator - which attempts to minimize the > > number of > > system calls (e.g. to malloc) by allocating bigger memory blocks > > and > > then handing over slices to clients. Let's try to model the > > allocation-nature of a NativeScope with a separate interface, as > > follows: > > > > ``` > > @FunctionalInterface > > interface NativeAllocator { > > MemorySegment allocate(long size, long align); > > default allocateInt(MemoryLayout intLayout, int value) { ... } > > default allocateLong(MemoryLayout intLayout, long value) { ... > > } > > ... // all allocation helpers in NativeScope > > } > > ``` > > > > At first, it seems this interface doesn't add much. But it is > > quite > > powerful - for instance, a client can create a simple, malloc-like > > allocator, as follows: > > > > ``` > > NativeAllocator malloc = (size, align) -> > > MemorySegment.allocateNative(size, align, > > ResourceScope.ofConfined()); > > > > ``` > > > > This is an allocator which allocates a new region of memory on > > each > > allocation request, backed by a fresh confined scope (which can be > > closed independently). This idiom is in fact so common that the > > API > > allows client to create these allocators in a more compact fashion: > > > > ``` > > NativeAllocator confinedMalloc = > > NativeAllocator.ofMalloc(ResourceScope::ofConfined); > > NativeAllocator sharedMalloc = > > NativeAllocator.ofMalloc(ResourceScope::ofConfined); > > ``` > > > > But other strategies are also possible: > > > > * arena allocation (e.g. the allocation strategy currently used by > > NativeScope) > > * recycling allocation (a single segment, with given layout, is > > allocated, and allocation requests are served by repeatedly slicing > > that > > very segment) - this is a critical optimization in e.g. loops > > * interop with custom allocators > > > > So, where would we accept a NativeAllocator in our API? Turns out > > that > > accepting an allocator is handy whenever an API point needs to > > allocate > > some native memory - so, instead of > > > > ``` > > MemorySegment toCString(String) > > ``` > > > > This is better: > > > > ``` > > MemorySegment toCString(String, NativeAllocator) > > ``` > > > > Of course, we need to tweak the foreign linker, so that in all > > foreign > > calls returning a struct by value (which require some allocation), > > a > > NativeAllocator prefix argument is added to the method handle, so > > that > > the user can specify which allocator should be used by the call; > > this is > > a straightforward change which greatly enhances the expressive > > power of > > the linker API. > > > > So, we are in a place where some methods (e.g. factories which > > create > > some resource) takes an additional ResourceScope argument - and > > some > > other methods (e.g. methods that need to allocate native segments) > > which > > take an additional NativeAllocator argument. Now, it would be > > inconvenient for the user to have to create both, at least in > > simple use > > cases - but, since these are interfaces, nothing prevents us from > > creating a new abstraction which implements _both_ ResourceScope > > _and_ > > NativeAllocator - in fact this is exactly what the role of the > > already > > existing NativeScope is! > > > > ``` > > interface NativeScope extends NativeAllocator, ResourceScope { ... > > } > > ``` > > > > In other words, we have retconned the existing NativeScope > > abstraction, > > by explaining its behavior in terms of more primitive abstractions > > (scopes and allocators). This means that clients can, for the most > > part, > > just create a NativeScope and then pass it whenever a ResourceScope > > or a > > NativeAllocator is required (which is what is already happening in > > all > > of our jextract examples). > > > > There are some additional bonus points of this approach. > > > > First, ResourceScope features some locking capabilities - e.g. you > > can > > do things like: > > > > ``` > > try (ResourceScope.Lock lock = segment.scope().lock()) { > > > > } > > ``` > > > > Which allows clients to perform segment critical operations w/o > > worrying > > that a segment memory will be reclaimed while in the middle of the > > operation. This solves the problem with async operation on byte > > buffers > > derived from shared segments (see [3]). > > > > Another bonus point is that the ResourceScope interface is > > completely > > segment-agnostic - in fact, we have now a way to describe APIs > > which > > return resources which must be cleaned by the user (or, implicitly, > > by > > the GC). For instance, it would be entirely reasonable to imagine, > > one > > day, the ByteBuffer API to provide an additional factory - e.g. > > allocateDirect(int size, ResourceScope scope) - which gives you a > > direct > > buffer attached to a given (closeable) scope. The same trick can > > probably be used in other APIs as well where implicit cleanup has > > been > > preferred for performance and/or safety reasons. > > > > tl;dr; > > > > This restacking described in this email enhances the Foreign > > Memory > > Access API in many different ways, and allows clients to approach > > the > > API in increasing degrees of complexity (depending on needs): > > > > * for smoother transition, coming from the ByteBuffer API, users > > can > > only have swap ByteBuffer::allocateDirect with > > MemorySegment::allocateNative - not much else changes, no need to > > think > > about lifecycles (and ResourceScope); GC is still in charge of > > deallocation > > * users that want tighter control over resources, can dive deeper > > and > > learn how segments (and other resources) are attached to a > > resource > > scope (which can be closed safely, if needed) > > * for the native interop case, the NativeScope abstraction is > > retconned > > to be both a ResourceScope *and* a NativeAllocator - so it can be > > used > > whenever an API needs to know how to _allocate_ or which > > _lifecycle_ > > should be used for a newly created resource > > * scopes can be locked, which allows clients to write critical > > sections > > in which a segment has to be operated upon w/o fear of it being > > closed > > * the idiom described here can be used to e.g. enhance the > > ByteBuffer > > API and to add close capabilities there > > > > All the above require very little changes to the clients of the > > memory > > access API. The biggest change is that a MemorySegment no longer > > supports the AutoCloseable interface, which is instead moved to > > ResourceScope. While this can get a little more verbose in case you > > need > > a single segment, the code scales _a lot_ better in case you need > > multiple segments/resources. Existing clients using jextract- > > generated > > APIs, on the other hand, are not affected much, since they are > > mostly > > dependent on the NativeScope API, which this proposal does not > > alter > > (although the role of a NativeScope is now retconned to be > > allocator + > > scope). > > > > You can find a branch which implements some of the changes > > described > > above (except the changes to the foreign linker API) here: > > > > https://github.com/mcimadamore/panama-foreign/tree/resourceScope > > > > While an initial javadoc of the API described in this email can be > > found > > here: > > > > http://cr.openjdk.java.net/~mcimadamore/panama/resourceScope-javadoc_v2/javadoc/jdk/incubator/foreign/package-summary.html > > > > > > Cheers > > Maurizio > > > > [1] - > > https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011700.html > > [2] - > > https://datasketches.apache.org/docs/Memory/MemoryPackage.html > > [3] - > > https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011810.html > > > > From paul.sandoz at oracle.com Wed Jan 27 16:34:22 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 27 Jan 2021 16:34:22 +0000 Subject: Can not built latest vectorIntrinsic on Windows (Was: Testing Vector API; which branch to build?) In-Reply-To: <61bad66a-c12c-2f49-351f-3dc6d6bc9746@serebryakov.spb.ru> References: <57548DC0-D057-43A0-9EB8-6859E435AD16@tencent.com> <61bad66a-c12c-2f49-351f-3dc6d6bc9746@serebryakov.spb.ru> Message-ID: Hi, Unfortunately there are some build issues on windows for the vectorIntrinsics related to SVML files (e.g. for the vectorized transcendental functions). Sandhya may have more details as to what is going on. Paul. > On Jan 27, 2021, at 2:56 AM, Lev Serebryakov wrote: > > On 27.01.2021 4:38, jiefu(??) wrote: > > I can not build https://github.com/openjdk/panama-vector/tree/vectorIntrinsics fcc36ceb040 on Windows 10 with MSVS 2019 Community > > There is problems with assembler source files: > > Microsoft (R) Macro Assembler Version 14.28.29336.0 > Copyright (C) Microsoft Corporation. All rights reserved. > > Microsoft (R) Incremental Linker Version 14.28.29336.0 > Copyright (C) Microsoft Corporation. All rights reserved. > > /OUT:svml_d_acos_windows_x86.exe > c:\home\ref\panama-vector\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\svml_d_acos_windows_x86.obj > LINK : fatal error LNK1561: entry point must be defined > Assembling: c:\home\ref\panama-vector\src\hotspot\os_cpu\windows_x86\svml_d_acos_windows_x86.s > make[3]: *** [lib/CompileJvm.gmk:143: /cygdrive/c/home/ref/panama-vector/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/svml_d_acos_windows_x86.obj] Error 25 > make[3]: *** Deleting file '/cygdrive/c/home/ref/panama-vector/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/svml_d_acos_windows_x86.obj' > > >> https://github.com/openjdk/panama-vector/tree/vectorIntrinsics , or >> https://github.com/openjdk/jdk >> Both of them will be updated from time to time. >> Since https://github.com/openjdk/panama-vector/tree/vectorIntrinsics had merged the master several days ago, I think it is fine to you. > > > -- > // Black Lion AKA Lev Serebryakov From maurizio.cimadamore at oracle.com Wed Jan 27 17:57:02 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 27 Jan 2021 17:57:02 +0000 Subject: [External] : Re: Feedback / query on jextract for Windows 10 In-Reply-To: <03b8a550-b3a3-acd1-a1ba-752454b01a01@oracle.com> References: <0e35502c-3656-9c23-eca8-4ca8a4377d15@gmail.com> <52aa2217-0795-a27b-8173-78b06be3f25b@gmail.com> <145ff947-5de4-3d7e-17b9-074842b0f2ce@oracle.com> <9071e122-8bb3-2688-f9f3-ba63f15e127f@gmail.com> <03b8a550-b3a3-acd1-a1ba-752454b01a01@oracle.com> Message-ID: <1cd0b90eafd10db474e75874895fe307e18b3d57.camel@oracle.com> On Tue, 2021-01-26 at 16:54 +0000, Maurizio Cimadamore wrote: > I'll take a look with the latest version - it might be that something > is > interacting with the lazy constant loading process. I think I have been able to reproduce what you are seeing. I generated an absurd header containing 50K constants and 50K functions. The header is called foo.h and it generated several foo_h$n and foo_h$constants$m classes. I then put together a very simple program, as follows: ``` import static pkg.foo_h.*; public class Main { public static void main(String[] args) throws Throwable { long prev = System.currentTimeMillis(); int i = C_i121(); long after = System.currentTimeMillis(); System.out.println("time = " + (after - prev)); } } ``` And I observe some 250-300ms of startup cost. After a bit of troubleshooting, I noted that if I add this line at the beginning of the main() method: Class c1 = Class.forName("pkg.foo_h"); The overhead is essentially eliminated (goes from 300ms down to 5-6ms). So, I suspect that what we're seeing is just the VM coping with this huge amount of classes (which are fairly stuffed with several members). In order to present all members under the same umbrella, generated classes inherit each other - and I believe that is what is pulling in the whole tree. I'll keep investigating to see if this is expected behavior, or if there's something that can be improved, either in how we generated code, or in the constant dynamic support. Cheers Maurizio > > Thanks for reporting this - minimizing startup of jextracted > libraries > is a pretty important use case for us. > > Cheers > Maurizio > > On 26/01/2021 15:43, Duncan Gittins wrote: > > I don't know what causes the speed difference, which may be down > > to > > the jar size as you suggest. I'll re-test after the time that > > "--source" generates same code as seen in the .class files when it > > may > > be easier to understand why there is a difference. I am using > > 16-panama+3-385. > > > > This isn't a very robust test, but I also tried deleted all the > > un-necessary .class files from the 11MB jextract generated classes > > (not produced using --source) down to 2MB jar, then I moved my > > handcoded method into a separate class and added a dependency on a > > different 2MB jar. Neither of those changes affected the typical > > speeds of first call times - I still consistently see that the > > hand > > coded method handle version of my app is ~300-500ms faster on > > first > > call, and no difference for 2nd+ calls. > > > > Duncan > > > > On 25/01/2021 16:18, Maurizio Cimadamore wrote: > > > On 25/01/2021 16:13, Duncan Gittins wrote: > > > > Thanks for the information. As you suspected that bug must be > > > > related and there is a minor difference in the --source output > > > > because the problem does go away when removing the jextract > > > > "--source" flag and making jar directly from generated classes > > > > rather than just compiling from the generated source code. > > > > > > > > My code samples using jextract bindings are ~300ms slower at > > > > startup > > > > time (but same speed runtime). I'm not certain if this overhead > > > > is > > > > down to initialisation of static constants or simply to be > > > > expected > > > > when adding 11MB jar footprint (compared to 56k jar for my > > > > handwritten MH bindings). I will follow-up if I find out more. > > > If you see the startup slowdown even when omitting --source, then > > > the > > > issue is with loading the jar, rather than initializing - as > > > explaining no initializing should happen outside for stuff that > > > is > > > actually used by your code - so I'd expect that initialization > > > overhead for jextract code and your manually written versions > > > should > > > be roughly the same. > > > > Looking at the generated code for "xxx$constants$nn.java" > > > > there > > > > seems to be a degree of unnecessary initialisation per > > > > xxx$constants$nn class as it contains static variables for > > > > FunctionDescriptor / MemoryLayout which would be initialised > > > > every > > > > time that particular class was loaded and not used in my code. > > > > I > > > > felt that my own jar was slow starting so switched foreign > > > > linker > > > > references to a lazy load Supplier for every library / symbol / > > > > mh / > > > > vh so that only the referenced types get created. > > > > > > Sure - but that's only when --source is used - when you > > > generated > > > classes directly, everything is lazy (and in a more general way > > > than > > > using Suppliers). > > > > > > So, can you please confirm, to be clear, that you still see > > > startup > > > regression even when NOT using "--source" ? > > > > > > Thanks! > > > Maurizio > > > > > > > I will have a look at future builds - this project is > > > > extremely > > > > useful so I hope it gets into a full JDK release soon. > > > > Unfortunately > > > > my issue with a huge jar in Eclipse means I can't easily > > > > develop > > > > using the generated code variant right now, but in the meantime > > > > the > > > > jextract code is still very helpful to work out how to call > > > > Windows > > > > APIs correctly. > > > > > > > > Duncan > > > > > > > > On 25/01/2021 10:20, Maurizio Cimadamore wrote: > > > > > On 23/01/2021 18:34, Duncan Gittins wrote: > > > > > > I've been using Panama on Windows 10 to eliminate my C# > > > > > > apps which > > > > > > I would normally call via ProcessBuilder. I'm very > > > > > > impressed so > > > > > > far and looking forward to newer versions: everything I > > > > > > have > > > > > > written in Windows C# is now replaced with foreign memory / > > > > > > linker > > > > > > calls to native code using the latest Java 16 EA. I have > > > > > > examples > > > > > > for various Win32 API and COM objects, HWND objects and > > > > > > screensaver. However I'm struggling to get the code running > > > > > > with > > > > > > output from jextract build. Perhaps I overlooked something > > > > > > very > > > > > > obvious in how to setup? > > > > > > > > > > > > One example app is attached - this calls > > > > > > SystemParametersInfoA to > > > > > > set the Windows desktop background. There are two > > > > > > implementations > > > > > > of setImage: one with hardwired MethodHandle works fine, > > > > > > but the > > > > > > jextract version gives UnsupportedOperationException for > > > > > > layout > > > > > > unrelated to SystemParametersInfoA. If I edit the generated > > > > > > code > > > > > > to comment out all lines unrelated to SystemParametersInfoA > > > > > > then > > > > > > both versions of setImage work. > > > > > > > > > > I think the culprit is this: > > > > > > > > > > ``` > > > > > Caused by: java.lang.UnsupportedOperationException: Invalid > > > > > alignment requirements for layout > > > > > b64(ArbitraryUserPointer)[abi/kind=POINTER,layout/name=Arbitr > > > > > aryUserPointer] > > > > > at > > > > > jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.checkAl > > > > > ignment(LayoutPath.java:273) > > > > > at > > > > > jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.derefer > > > > > enceHandle(LayoutPath.java:159) > > > > > at > > > > > jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.lamb > > > > > da$varHandle$2(MemoryLayout.java:488) > > > > > at > > > > > jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.comp > > > > > utePathOp(MemoryLayout.java:534) > > > > > at > > > > > jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.varH > > > > > andle(MemoryLayout.java:488) > > > > > at > > > > > duncan.win32.shobjidl_core.shlobj_core_h$constants$16. > > > > >(shlobj_core_h$constants$16.java:1844) > > > > > ``` > > > > > > > > > > This seems a duplicate of another issue that has been > > > > > reported last > > > > > week: > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8259832 > > > > > > > > > > E.g. jextract ignoring alignment requirements. Note that > > > > > jextract > > > > > generates lots of constants, and it takes only one bad one to > > > > > make > > > > > initialization fail. > > > > > > > > > > > The jextract command on Windows 10 (with fresh Vis Studio > > > > > > installation) expands shlobj_core.h because I my app also > > > > > > uses > > > > > > IShellLink. > > > > > > > > > > > > set "WINKIT=c:\Program Files (x86)\Windows > > > > > > Kits\10\Include\10.0.18362.0" > > > > > > jextract --source -t duncan.win32.shobjidl_core -d > > > > > > shlobj_core.h/java "%WINKIT%/um/shlobj_core.h" > > > > > > > > > > > > Another issue is that this single windows header file gives > > > > > > rise > > > > > > to 11MB jar and is unusable inside Eclipse (on my slow PC), > > > > > > and is > > > > > > slow startup at runtime. Have you considered changing the > > > > > > generated code to use lazy Supplier instead > > > > > > of > > > > > > MethodHandle to ensure only required handles are created > > > > > > on-demand? > > > > > > > > > > Uhm... we are already using dynamic constants, so you should > > > > > only > > > > > pay for the MHs and VHs you use - e.g. in fact I'm even > > > > > surprised > > > > > you get the failure inside the above - since that > > > > > constant > > > > > should not be initialized unless it's used. I wonder if > > > > > there's a > > > > > regression here... are you using the `--source` flag? With > > > > > that > > > > > flag we revert back to a monolithic header, so that will > > > > > explain > > > > > both failures. If so, try removing that flag - and see what > > > > > happens > > > > > (if everything is working as it should I don't think you > > > > > should > > > > > even see the error above, assuming you never use that > > > > > layout). > > > > > > > > > > Maurizio > > > > > > > > > > > Kind regards > > > > > > > > > > > > Duncan > > > > > > > > > > > > From maurizio.cimadamore at oracle.com Wed Jan 27 22:13:16 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 27 Jan 2021 22:13:16 +0000 Subject: [External] : Re: Feedback / query on jextract for Windows 10 In-Reply-To: <1cd0b90eafd10db474e75874895fe307e18b3d57.camel@oracle.com> References: <0e35502c-3656-9c23-eca8-4ca8a4377d15@gmail.com> <52aa2217-0795-a27b-8173-78b06be3f25b@gmail.com> <145ff947-5de4-3d7e-17b9-074842b0f2ce@oracle.com> <9071e122-8bb3-2688-f9f3-ba63f15e127f@gmail.com> <03b8a550-b3a3-acd1-a1ba-752454b01a01@oracle.com> <1cd0b90eafd10db474e75874895fe307e18b3d57.camel@oracle.com> Message-ID: <8526bb67168cedd3d3c7ffa0100d3dcbf24199d1.camel@oracle.com> On Wed, 2021-01-27 at 17:56 +0000, Maurizio Cimadamore wrote: > I'll keep investigating to see if this is expected behavior, or if > > there's something that can be improved, either in how we generated > > code, or in the constant dynamic support. As it turns out, there's not much we can do in this kind of situation. Basically, we're in a case where we have a deep hierarchy like this: A1 extends A2 extends A3 ... extends An (we need to do this so that all symbols will be seen as "members" of A1, while at the same time not blowing up the classfile limits). Now, if you call a static method, like A1::m, the VM has still to load the entire hierarchy A1 ... An. This seems counter-intuitive at first, after all, we want to call a static method, not an instance one, so there's no vtable needed. But - VM method resolution is designed to look into superclasses not just for instance methods, but also for static ones! There's also the detail that the VM must know the superclasses in order to correctly layout _static_ fields in the hierarchy (again, there are no fields in jextract generated hierarchy - but to discover that you have to walk the hierarchy anyway, so that info cannot be exploited at load time). So, when dealing with enormous headers (like Windows.h), filtering is the way to go. Our approach is already trying its best at being as lazy as possible (and I've verified that it only creates the layouts and method handles that are used by the client - so that aspect works) - but we cannot take away the cost of class loading. Of course, if jextract bucketed the various symbols in separate files which you had to manually include, we could reduce the cost associated to loading - but at a big cost in terms of usability: as a user of a big library L, how are you expected to know in which header is a given symbol defined? We have tried breaking up by headers in the past, and it just doesn't work. The scheme we have now works very well for all "normal" libraries - it adds zero-to-very-minimal overhead, and it makes things easy for clients which do not have to guess where symbols are (just import the main `foo_h` header file, and everything works). Unfortunately this means that clients that want to interact with huge, monolithic libraries, will have to resort to filtering, or maybe define some headers manually (as you have done) to keep footprint down. I don't think there's a silver bullet here (*): we can only hope to come up with something that works well in the 90% of cases, and then offer workarounds for the remaining 10%. Cheers Maurizio (*) It occurs to me that most of the symbols required by a client interacting with a jextracted API are scrutable and foldable symbols: method handles, var handles, layouts, ... This could mean that, at least in principle, in the future it would be possible for javac to remove calls and dependencies on the jextract generated binding, and "inline" the var/method handle creation (as it does for other kind of "constants"). This generalization of constant folding has been discussed in this JEP: https://openjdk.java.net/jeps/303 So, there might be, one day, a solution which will allow javac to "embed" only the contents from a jextract bindings that are required in order to execute your application. But it might take a while to get there. From lev at serebryakov.spb.ru Wed Jan 27 22:25:22 2021 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Thu, 28 Jan 2021 01:25:22 +0300 Subject: Can not built latest vectorIntrinsic on Windows (Was: Testing Vector API; which branch to build?) In-Reply-To: References: <57548DC0-D057-43A0-9EB8-6859E435AD16@tencent.com> <61bad66a-c12c-2f49-351f-3dc6d6bc9746@serebryakov.spb.ru> Message-ID: On 27.01.2021 19:34, Paul Sandoz wrote: Looks like command line for ml.exe (MS' assembler) is wrong: /cygdrive/c/home/ref/panama-vector/build/windows-x86_64-server-release/fixpath exec \ /cygdrive/c/progra~2/micros~2/2019/commun~1/vc/tools/msvc/1428~1.293/bin/hostx86/x86/ml.exe \ -Fo/cygdrive/c/home/ref/panama-vector/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/svml_d_acos_windows_x86.obj \ /Ta /cygdrive/c/home/ref/panama-vector/src/hotspot/os_cpu/windows_x86/svml_d_acos_windows_x86.s /Ta is "trust this source, even if extension is not asm" -Fo is "output object file", but it should be "/Fo", really and there should be /c after it ("assemble only, don't link")... Also, "ml.exe" is 32-bit assembelr with 32-bit output. ml64.exe is needed here (as Win32 32 bit is not supported by JDK anymore). Ok, I found solution (by searching for "/Ta"). Patch attached. This is not full solution, it doesn't hide ML's output (banner & all this), but it allows to compile panama/vectorIntrinsic on Windows. > Hi, > > Unfortunately there are some build issues on windows for the vectorIntrinsics related to SVML files (e.g. for the vectorized transcendental functions). Sandhya may have more details as to what is going on. > > Paul. > >> On Jan 27, 2021, at 2:56 AM, Lev Serebryakov wrote: >> >> On 27.01.2021 4:38, jiefu(??) wrote: >> >> I can not build https://github.com/openjdk/panama-vector/tree/vectorIntrinsics fcc36ceb040 on Windows 10 with MSVS 2019 Community >> >> There is problems with assembler source files: >> >> Microsoft (R) Macro Assembler Version 14.28.29336.0 >> Copyright (C) Microsoft Corporation. All rights reserved. >> >> Microsoft (R) Incremental Linker Version 14.28.29336.0 >> Copyright (C) Microsoft Corporation. All rights reserved. >> >> /OUT:svml_d_acos_windows_x86.exe >> c:\home\ref\panama-vector\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\svml_d_acos_windows_x86.obj >> LINK : fatal error LNK1561: entry point must be defined >> Assembling: c:\home\ref\panama-vector\src\hotspot\os_cpu\windows_x86\svml_d_acos_windows_x86.s >> make[3]: *** [lib/CompileJvm.gmk:143: /cygdrive/c/home/ref/panama-vector/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/svml_d_acos_windows_x86.obj] Error 25 >> make[3]: *** Deleting file '/cygdrive/c/home/ref/panama-vector/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/svml_d_acos_windows_x86.obj' >> >> >>> https://github.com/openjdk/panama-vector/tree/vectorIntrinsics , or >>> https://github.com/openjdk/jdk >>> Both of them will be updated from time to time. >>> Since https://github.com/openjdk/panama-vector/tree/vectorIntrinsics had merged the master several days ago, I think it is fine to you. >> >> >> -- >> // Black Lion AKA Lev Serebryakov > -- // Black Lion AKA Lev Serebryakov -------------- next part -------------- diff --git a/make/autoconf/toolchain.m4 b/make/autoconf/toolchain.m4 index 09a79636593..b76a55388ba 100644 --- a/make/autoconf/toolchain.m4 +++ b/make/autoconf/toolchain.m4 @@ -697,7 +697,7 @@ AC_DEFUN_ONCE([TOOLCHAIN_DETECT_TOOLCHAIN_CORE], AS="$CC -c" else # On windows, the assember is "ml.exe" - UTIL_LOOKUP_TOOLCHAIN_PROGS(AS, ml) + UTIL_LOOKUP_TOOLCHAIN_PROGS(AS, ml64) fi AC_SUBST(AS) @@ -853,7 +853,7 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS], # On windows, the assember is "ml.exe". We currently don't need this so # do not require. - UTIL_LOOKUP_PROGS(BUILD_AS, ml, [$VS_PATH]) + UTIL_LOOKUP_PROGS(BUILD_AS, ml64, [$VS_PATH]) # On windows, the ar tool is lib.exe (used to create static libraries). # We currently don't need this so do not require. diff --git a/make/common/NativeCompilation.gmk b/make/common/NativeCompilation.gmk index 18edb5a46f1..37bf6e94c57 100644 --- a/make/common/NativeCompilation.gmk +++ b/make/common/NativeCompilation.gmk @@ -438,7 +438,7 @@ define SetupCompileNativeFileBody # For assembler calls, no need to build dependency list. $$(call ExecuteWithLog, $$@, $$(call MakeCommandRelative, \ $$($1_COMPILER) $$($1_FLAGS) \ - $(CC_OUT_OPTION)$$($1_OBJ) /Ta $$($1_SRC_FILE))) + $(CC_OUT_OPTION)$$($1_OBJ) /c /Ta $$($1_SRC_FILE))) endif endif endif From whuang at openjdk.java.net Thu Jan 28 01:52:09 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 28 Jan 2021 01:52:09 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE [v5] In-Reply-To: References: Message-ID: > This patch add cast nodes between interger types implementation for Arm SVE like "VectorCastB2X" "VectorCastI2X " "VectorCastS2X" "VectorCastL2X". Wang Huang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge vectorIntrinsics - remove useless codes - remove walkaround codes - add other I2I cast nodes - fix build bug on other archs caused by UseSVE > 0 - 8259536: Add cast nodes between interger types implementation for Arm SVE ------------- Changes: https://git.openjdk.java.net/panama-vector/pull/31/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=31&range=04 Stats: 352 lines in 3 files changed: 342 ins; 10 del; 0 mod Patch: https://git.openjdk.java.net/panama-vector/pull/31.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/31/head:pull/31 PR: https://git.openjdk.java.net/panama-vector/pull/31 From whuang at openjdk.java.net Thu Jan 28 01:57:01 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 28 Jan 2021 01:57:01 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE [v5] In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 01:52:09 GMT, Wang Huang wrote: >> This patch add cast nodes between interger types implementation for Arm SVE like "VectorCastB2X" "VectorCastI2X " "VectorCastS2X" "VectorCastL2X". > > Wang Huang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge vectorIntrinsics > - remove useless codes > - remove walkaround codes > - add other I2I cast nodes > - fix build bug on other archs caused by UseSVE > 0 > - 8259536: Add cast nodes between interger types implementation for Arm SVE > @Wanghuang-Huawei Thanks a lot for the work! Could you please do a merge and resolve the merge conflicts? OK. I have resolved that. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/31 From whuang at openjdk.java.net Thu Jan 28 01:57:02 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 28 Jan 2021 01:57:02 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE [v3] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 09:15:18 GMT, Ningsheng Jian wrote: >> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> add other I2I cast nodes > > src/hotspot/share/opto/vectorIntrinsics.cpp line 334: > >> 332: // int start, int step, int wrap, ShuffleIotaOperation defaultImpl) >> 333: bool LibraryCallKit::inline_vector_shuffle_iota() { >> 334: // TODO shuffle is not supported on SVE > > This check is no necessary? Since SVE does not have Op_VectorLoadConst yet, arch_supports_vector() check below should return false. Ok. I will remove them. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/31 From xgong at openjdk.java.net Thu Jan 28 02:09:59 2021 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 28 Jan 2021 02:09:59 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE [v5] In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 01:52:09 GMT, Wang Huang wrote: >> This patch add cast nodes between interger types implementation for Arm SVE like "VectorCastB2X" "VectorCastI2X " "VectorCastS2X" "VectorCastL2X". > > Wang Huang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge vectorIntrinsics > - remove useless codes > - remove walkaround codes > - add other I2I cast nodes > - fix build bug on other archs caused by UseSVE > 0 > - 8259536: Add cast nodes between interger types implementation for Arm SVE src/hotspot/share/opto/vectorIntrinsics.cpp line 440: > 438: // ShuffleToVectorOperation defaultImpl) > 439: bool LibraryCallKit::inline_vector_shuffle_to_vector() { > 440: // TODO shuffle is not supported on SVE The whole patch looks good to me, except for this comment. Could you please remove it as well? Thanks! ------------- PR: https://git.openjdk.java.net/panama-vector/pull/31 From sandhya.viswanathan at intel.com Thu Jan 28 02:25:48 2021 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Thu, 28 Jan 2021 02:25:48 +0000 Subject: Can not built latest vectorIntrinsic on Windows (Was: Testing Vector API; which branch to build?) In-Reply-To: References: <57548DC0-D057-43A0-9EB8-6859E435AD16@tencent.com> <61bad66a-c12c-2f49-351f-3dc6d6bc9746@serebryakov.spb.ru> Message-ID: Hi Lev, Thanks for looking into it. Adding /nologo to ml64 command and filtering the output helps remove the verbosity: --- a/make/common/NativeCompilation.gmk +++ b/make/common/NativeCompilation.gmk @@ -438,7 +438,8 @@ define SetupCompileNativeFileBody # For assembler calls, no need to build dependency list. $$(call ExecuteWithLog, $$@, $$(call MakeCommandRelative, \ $$($1_COMPILER) $$($1_FLAGS) \ - $(CC_OUT_OPTION)$$($1_OBJ) /Ta $$($1_SRC_FILE))) + $(CC_OUT_OPTION)$$($1_OBJ) /nologo /c /Ta $$($1_SRC_FILE) 2>&1 \ + | $(TR) -d '\r' | $(GREP) -v -e "Assembling:" || test "$$$$?" = "1" ;)) endif endif endif Also, the ml64 vs ml selection could be done based on 32 bit or 64 bit platform, e.g. something like below: --- a/make/autoconf/toolchain.m4 +++ b/make/autoconf/toolchain.m4 @@ -696,8 +696,13 @@ AC_DEFUN_ONCE([TOOLCHAIN_DETECT_TOOLCHAIN_CORE], if test "x$TOOLCHAIN_TYPE" != xmicrosoft; then AS="$CC -c" else - # On windows, the assember is "ml.exe" - UTIL_LOOKUP_TOOLCHAIN_PROGS(AS, ml) + if test "x$OPENJDK_TARGET_CPU" = "xx86_64"; then + # On 64 bit windows, the assember is "ml64.exe" + UTIL_LOOKUP_TOOLCHAIN_PROGS(AS, ml64) + else + # otherwise, the assember is "ml.exe" + UTIL_LOOKUP_TOOLCHAIN_PROGS(AS, ml) + fi fi AC_SUBST(AS) @@ -853,7 +858,13 @@ AC_DEFUN_ONCE([TOOLCHAIN_SETUP_BUILD_COMPILERS], # On windows, the assember is "ml.exe". We currently don't need this so # do not require. - UTIL_LOOKUP_PROGS(BUILD_AS, ml, [$VS_PATH]) + if test "x$OPENJDK_TARGET_CPU" = "xx86_64"; then + # On 64 bit windows, the assember is "ml64.exe" + UTIL_LOOKUP_PROGS(BUILD_AS, ml64, [$VS_PATH]) + else + # otherwise the assember is "ml.exe" + UTIL_LOOKUP_PROGS(BUILD_AS, ml, [$VS_PATH]) + fi # On windows, the ar tool is lib.exe (used to create static libraries). # We currently don't need this so do not require. Do you plan to submit the fix to panama-dev? Best Regards, Sandhya -----Original Message----- From: Lev Serebryakov Sent: Wednesday, January 27, 2021 2:25 PM To: Paul Sandoz ; Viswanathan, Sandhya Cc: panama-dev at openjdk.java.net' Subject: Re: Can not built latest vectorIntrinsic on Windows (Was: Testing Vector API; which branch to build?) On 27.01.2021 19:34, Paul Sandoz wrote: Looks like command line for ml.exe (MS' assembler) is wrong: /cygdrive/c/home/ref/panama-vector/build/windows-x86_64-server-release/fixpath exec \ /cygdrive/c/progra~2/micros~2/2019/commun~1/vc/tools/msvc/1428~1.293/bin/hostx86/x86/ml.exe \ -Fo/cygdrive/c/home/ref/panama-vector/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/svml_d_acos_windows_x86.obj \ /Ta /cygdrive/c/home/ref/panama-vector/src/hotspot/os_cpu/windows_x86/svml_d_acos_windows_x86.s /Ta is "trust this source, even if extension is not asm" -Fo is "output object file", but it should be "/Fo", really and there should be /c after it ("assemble only, don't link")... Also, "ml.exe" is 32-bit assembelr with 32-bit output. ml64.exe is needed here (as Win32 32 bit is not supported by JDK anymore). Ok, I found solution (by searching for "/Ta"). Patch attached. This is not full solution, it doesn't hide ML's output (banner & all this), but it allows to compile panama/vectorIntrinsic on Windows. > Hi, > > Unfortunately there are some build issues on windows for the vectorIntrinsics related to SVML files (e.g. for the vectorized transcendental functions). Sandhya may have more details as to what is going on. > > Paul. > >> On Jan 27, 2021, at 2:56 AM, Lev Serebryakov wrote: >> >> On 27.01.2021 4:38, jiefu(??) wrote: >> >> I can not build >> https://github.com/openjdk/panama-vector/tree/vectorIntrinsics >> fcc36ceb040 on Windows 10 with MSVS 2019 Community >> >> There is problems with assembler source files: >> >> Microsoft (R) Macro Assembler Version 14.28.29336.0 Copyright (C) >> Microsoft Corporation. All rights reserved. >> >> Microsoft (R) Incremental Linker Version 14.28.29336.0 Copyright (C) >> Microsoft Corporation. All rights reserved. >> >> /OUT:svml_d_acos_windows_x86.exe >> c:\home\ref\panama-vector\build\windows-x86_64-server-release\hotspot >> \variant-server\libjvm\objs\svml_d_acos_windows_x86.obj >> LINK : fatal error LNK1561: entry point must be defined >> Assembling: >> c:\home\ref\panama-vector\src\hotspot\os_cpu\windows_x86\svml_d_acos_ >> windows_x86.s >> make[3]: *** [lib/CompileJvm.gmk:143: >> /cygdrive/c/home/ref/panama-vector/build/windows-x86_64-server-releas >> e/hotspot/variant-server/libjvm/objs/svml_d_acos_windows_x86.obj] >> Error 25 >> make[3]: *** Deleting file '/cygdrive/c/home/ref/panama-vector/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/svml_d_acos_windows_x86.obj' >> >> >>> https://github.com/openjdk/panama-vector/tree/vectorIntrinsics , or >>> https://github.com/openjdk/jdk Both of them will be updated from >>> time to time. >>> Since https://github.com/openjdk/panama-vector/tree/vectorIntrinsics had merged the master several days ago, I think it is fine to you. >> >> >> -- >> // Black Lion AKA Lev Serebryakov > -- // Black Lion AKA Lev Serebryakov From whuang at openjdk.java.net Thu Jan 28 02:37:54 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 28 Jan 2021 02:37:54 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE [v5] In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 02:07:15 GMT, Xiaohong Gong wrote: >> Wang Huang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge vectorIntrinsics >> - remove useless codes >> - remove walkaround codes >> - add other I2I cast nodes >> - fix build bug on other archs caused by UseSVE > 0 >> - 8259536: Add cast nodes between interger types implementation for Arm SVE > > src/hotspot/share/opto/vectorIntrinsics.cpp line 440: > >> 438: // ShuffleToVectorOperation defaultImpl) >> 439: bool LibraryCallKit::inline_vector_shuffle_to_vector() { >> 440: // TODO shuffle is not supported on SVE > > The whole patch looks good to me, except for this comment. Could you please remove it as well? Thanks! OK. I will remove it. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/31 From whuang at openjdk.java.net Thu Jan 28 02:51:05 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Thu, 28 Jan 2021 02:51:05 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE [v3] In-Reply-To: References: Message-ID: On Wed, 27 Jan 2021 09:00:50 GMT, Ningsheng Jian wrote: >> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> add other I2I cast nodes > > src/hotspot/cpu/aarch64/aarch64_sve.ad line 2499: > >> 2497: predicate(UseSVE > 0 && n->bottom_type()->is_vect()->length_in_bytes() >= 16 && >> 2498: n->bottom_type()->is_vect()->element_basic_type() == T_SHORT); >> 2499: match(Set dst (VectorCastB2X src)); > > Is it possible to sort these newly added rules by Node name? So that it's easier to know whether there are still some rules missing. * These nodes are generated by m4. In m4 file, I put nodes which call the same macro together. For instance, the macro `VECTOR_CAST_I2I` generate `B2S` `S2I` `I2L` , so I put the `B2S` `S2I` `I2L` together to clarify codes of m4. If we want to sort the generated nodes by name, we may change the position of the callsite of these macros. * All I2I nodes is included in this patch. ------------- PR: https://git.openjdk.java.net/panama-vector/pull/31 From luhenry at microsoft.com Thu Jan 28 06:12:36 2021 From: luhenry at microsoft.com (Ludovic Henry) Date: Thu, 28 Jan 2021 06:12:36 +0000 Subject: Learnings with the Vector API Message-ID: Hello, As part of my exploration of the Vector API, I?ve run into the following issues. I?m then turning to you to figure out what eventual limitation I?m hitting in Hotspot and that can be trivially alleviated, and whether it is worth in your opinion to implement missing APIs and optimizations. For context, I?ve been using two BLAS (Basic Linear Algebra Subprograms) implementations: one using the Vector API [1], and one using plain Java 8/11 APIs and code [2]. You?ll note that the code is laid out very similarly, both to make it easier to transpose the algorithm from the Java 8/11 implementation to the Vector API one by hand, but also in the hope to present enough information to the JIT that it can easily autovectorize the Java 8/11 implementation. You can also find the appropriate JMH benchmarks at [3]. # `a * b + c` isn?t optimized to `fma(a, b, c)` on supported hardware Even though major platforms support FMA instructions (x86 and ARM at least), there is currently no optimization in Hotspot to automatically transform `a * b + c` into `fma(a, b, c)`. Hotspot _is_ aware of FMA as there is the UseFMA global check, and `Math.fma` is intrinsified in the correct instruction. But there seems to be no ?auto-fmaization?. This code pattern is particularely common in Linear Algebra workloads (as you can attest by the number of `Math.fma` calls in [2] even though there is still room for more). And using a single FMA instruction over the two MUL+ADD instructions brings a 15-20% speedup on the specific workloads I?ve been looking at. The only significant behaviour change I can observe is the increase in precision since you don?t compound floating precision losses on two instructions (MUL+ADD) because you only do one instruction (FMA). # No `Math.dot` operation The dot product is an extremely common operation in Linear Algebra. It is, for example, the most time consuming operations in matrix-matrix multiplications which are at the core of current ML and AI workloads. In both the Vector API and the Java 8/11 implementations, I?ve laid out near optimal unrolling of the different loops for the matrix-matrix multiply case, but I?ve been hitting limitations in Hotspot register allocator leading to uncessecary spilling. Having a dedicated `Math.dot` method (or equivalent like a LinearAlgebra.dot) taking two ?matrices of arbitrary sizes? would allow to intrinsify this very specific operation. (By matrices of arbitrary sizes, the intrinsic should be optimized for matrices of size 3xk for A, and kx4 for B, with C += A * B.) The maximum speed I?m observing on my machine with the Vector API implementation is in the order of 15 Gflops/seconds, while the OpenBLAS implementation (which uses handwritten assembly) runs in the order of 25 Gflops/seconds. The main difference between the code generated by Hotspot in both cases is the size of the inner-loop submatrix (3x3 for the Vector API implementation, 3x4 for OpenBLAS), and the unrolling of the inner-loop (none for the Vector API implementation, and more than 4 for OpenBLAS). Both the augmentation of size in the inner-loop submatrix and the unrolling alleviates the current bottleneck at the microarchitecture level which is the high ratio of scalar instructions over vector instructions. An intrinsic would allow to handroll a hardware-optimized dot-product, leading to performance equivalent to native libraries, and allowing any Java application doing ML and AI to accelerate some of their core operations in pure Java. # Uncessary spilling in register allocator As alluded to in the previous point, I?m unable to reach peak performance when doing matrices dot-product because Hotspot generates uncessary register spilling. Let?s look at the specific piece of code: ``` DoubleVector vsum00 = DoubleVector.zero(DMAX); DoubleVector vsum01 = DoubleVector.zero(DMAX); DoubleVector vsum02 = DoubleVector.zero(DMAX); DoubleVector vsum03 = DoubleVector.zero(DMAX); DoubleVector vsum10 = DoubleVector.zero(DMAX); DoubleVector vsum11 = DoubleVector.zero(DMAX); DoubleVector vsum12 = DoubleVector.zero(DMAX); DoubleVector vsum13 = DoubleVector.zero(DMAX); DoubleVector vsum20 = DoubleVector.zero(DMAX); DoubleVector vsum21 = DoubleVector.zero(DMAX); DoubleVector vsum22 = DoubleVector.zero(DMAX); DoubleVector vsum23 = DoubleVector.zero(DMAX); for (; i < loopBound(ie, Ti * DMAX.length()); i += Ti * DMAX.length()) { DoubleVector va00 = DoubleVector.fromArray(DMAX, a, offseta + (i + 0 * DMAX.length()) + (row + 0) * lda); DoubleVector va01 = DoubleVector.fromArray(DMAX, a, offseta + (i + 0 * DMAX.length()) + (row + 1) * lda); DoubleVector va02 = DoubleVector.fromArray(DMAX, a, offseta + (i + 0 * DMAX.length()) + (row + 2) * lda); DoubleVector vb00 = DoubleVector.fromArray(DMAX, b, offsetb + (i + 0 * DMAX.length()) + (col + 0) * ldb); vsum00 = va00.fma(vb00, vsum00); vsum10 = va01.fma(vb00, vsum10); vsum20 = va02.fma(vb00, vsum20); DoubleVector vb01 = DoubleVector.fromArray(DMAX, b, offsetb + (i + 0 * DMAX.length()) + (col + 1) * ldb); vsum01 = va00.fma(vb01, vsum01); vsum11 = va01.fma(vb01, vsum11); vsum21 = va02.fma(vb01, vsum21); DoubleVector vb02 = DoubleVector.fromArray(DMAX, b, offsetb + (i + 0 * DMAX.length()) + (col + 2) * ldb); vsum02 = va00.fma(vb02, vsum02); vsum12 = va01.fma(vb02, vsum12); vsum22 = va02.fma(vb02, vsum22); DoubleVector vb03 = DoubleVector.fromArray(DMAX, b, offsetb + (i + 0 * DMAX.length()) + (col + 3) * ldb); vsum03 = va00.fma(vb03, vsum03); vsum13 = va01.fma(vb03, vsum13); vsum23 = va02.fma(vb03, vsum23); } ``` There is theoretically no need to spill any of the loaded vectors since the number of live register at any of the vector operations is at a maximum of 16 (12 for vsum, 3 for va, and 1 for vb). However, Hotspot does generate spilling for some vector registers, leading to suboptimal performance (even though it?s in L1, it?s still slowing down computation due to the larger number of instructions and the latency cost of L1). To ensure optimal performance, I?ve fallen back to a 3x3 inner submatrix (vsum[0-2][0-2]) instead of the above 3x4 inner submatrix (vsum[0-2][0-3]). Having a more conservative spilling would allow to both use the higher-performance 3x4 submatrix in this case, but also to unroll the loop more aggressively, reducing the overhead of ?loop management? (incrementing and checking the indexes). # Auto-vectorization not kicking in on trivial cases Even though the algorithms laid out in the Java 8/11 implementation are trivially reused and manually-vectorized in the Vector API implementation, Hotspot isn?t able to auto-vectorize the Java 8/11 implementation. I haven?t figure out the underlying reason why Hotspot isn?t able to (lack of information? Corner case?) but I thought useful to raise it here to get your take on the matter. # No `Math.fms` operation Similarly to `Math.dot`, FMS (Fused Multiply-Substract, `a * b ? c`) isn?t trivially available from Java. It isn?t as commonly used as FMA but still has use-cases in some Linear Algebra operations. There is also a corresponding instruction on major architectures (I?ve checked x86 and ARM). It would be technically trivial to add support for it, but would require an API change to add `Math.fms`. Thank you and I?m very happy to answer any further question, Ludovic [1] https://github.com/luhenry/netlib/blob/master/blas/src/main/java/dev/ludovic/netlib/blas/VectorizedBLAS.java [2] https://github.com/luhenry/netlib/blob/master/blas/src/main/java/dev/ludovic/netlib/blas/JavaBLAS.java [3] https://github.com/luhenry/netlib/tree/master/benchmarks From mcimadamore at openjdk.java.net Thu Jan 28 12:15:11 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 28 Jan 2021 12:15:11 GMT Subject: [foreign-jextract] RFR: 8260583: jextract generates redundant constant files Message-ID: When testing performances of jextract generated code with big headers, I noticed that jextract was emitting empty constant files. After some debugging, I realized that the issues lies in the fact that `ConstantHelper::build` is called both by `ToplevelBuilder::build` and by `HeaderFileBuilder::build` - so, for every new header file split that is generated, we trigger a new constant file, even though that is not needed. The solution is to remove the call from `HeaderFileBuilder` and just keep the one inside `TopLevelBuilder`. ------------- Commit messages: - Fix issue in constant file generation Changes: https://git.openjdk.java.net/panama-foreign/pull/440/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=440&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260583 Stats: 78 lines in 3 files changed: 75 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/440.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/440/head:pull/440 PR: https://git.openjdk.java.net/panama-foreign/pull/440 From duncan.gittins at gmail.com Thu Jan 28 12:21:54 2021 From: duncan.gittins at gmail.com (Duncan Gittins) Date: Thu, 28 Jan 2021 12:21:54 +0000 Subject: [External] : Re: Feedback / query on jextract for Windows 10 In-Reply-To: <8526bb67168cedd3d3c7ffa0100d3dcbf24199d1.camel@oracle.com> References: <0e35502c-3656-9c23-eca8-4ca8a4377d15@gmail.com> <52aa2217-0795-a27b-8173-78b06be3f25b@gmail.com> <145ff947-5de4-3d7e-17b9-074842b0f2ce@oracle.com> <9071e122-8bb3-2688-f9f3-ba63f15e127f@gmail.com> <03b8a550-b3a3-acd1-a1ba-752454b01a01@oracle.com> <1cd0b90eafd10db474e75874895fe307e18b3d57.camel@oracle.com> <8526bb67168cedd3d3c7ffa0100d3dcbf24199d1.camel@oracle.com> Message-ID: <684bf255-2aec-c78b-712d-b0c9e80f6666@gmail.com> Understood.? The behaviour of "--source" is different to the class generation in this respect too, as the "--source" compile version creates all method handles at once. [I confirmed this by adding System.out.println("downcallHandle "+name); into the RuntimeHelper.downcallHandle method and then merged the modified+compiled --source class with the generated classes to verify on-demand creates there] It would be nice to view the generated source to study the issue - will the --source option be maintained in future releases? Perhaps it's time that I downloaded the JDK source repository and find out myself. Duncan On 27/01/2021 22:13, Maurizio Cimadamore wrote: > On Wed, 2021-01-27 at 17:56 +0000, Maurizio Cimadamore wrote: >> I'll keep investigating to see if this is expected behavior, or if >> >> there's something that can be improved, either in how we generated >> >> code, or in the constant dynamic support. > As it turns out, there's not much we can do in this kind of situation. > Basically, we're in a case where we have a deep hierarchy like this: > > A1 extends A2 extends A3 ... extends An > > (we need to do this so that all symbols will be seen as "members" of > A1, while at the same time not blowing up the classfile limits). > > Now, if you call a static method, like A1::m, the VM has still to load > the entire hierarchy A1 ... An. This seems counter-intuitive at first, > after all, we want to call a static method, not an instance one, so > there's no vtable needed. But - VM method resolution is designed to > look into superclasses not just for instance methods, but also for > static ones! There's also the detail that the VM must know the > superclasses in order to correctly layout _static_ fields in the > hierarchy (again, there are no fields in jextract generated hierarchy - > but to discover that you have to walk the hierarchy anyway, so that > info cannot be exploited at load time). > > So, when dealing with enormous headers (like Windows.h), filtering is > the way to go. Our approach is already trying its best at being as lazy > as possible (and I've verified that it only creates the layouts and > method handles that are used by the client - so that aspect works) - > but we cannot take away the cost of class loading. > > Of course, if jextract bucketed the various symbols in separate files > which you had to manually include, we could reduce the cost associated > to loading - but at a big cost in terms of usability: as a user of a > big library L, how are you expected to know in which header is a given > symbol defined? We have tried breaking up by headers in the past, and > it just doesn't work. > > The scheme we have now works very well for all "normal" libraries - it > adds zero-to-very-minimal overhead, and it makes things easy for > clients which do not have to guess where symbols are (just import the > main `foo_h` header file, and everything works). Unfortunately this > means that clients that want to interact with huge, monolithic > libraries, will have to resort to filtering, or maybe define some > headers manually (as you have done) to keep footprint down. I don't > think there's a silver bullet here (*): we can only hope to come up > with something that works well in the 90% of cases, and then offer > workarounds for the remaining 10%. > > Cheers > Maurizio > > (*) It occurs to me that most of the symbols required by a client > interacting with a jextracted API are scrutable and foldable symbols: > method handles, var handles, layouts, ... > This could mean that, at least in principle, in the future it would be > possible for javac to remove calls and dependencies on the jextract > generated binding, and "inline" the var/method handle creation (as it > does for other kind of "constants"). This generalization of constant > folding has been discussed in this JEP: > > https://openjdk.java.net/jeps/303 > > So, there might be, one day, a solution which will allow javac to > "embed" only the contents from a jextract bindings that are required in > order to execute your application. But it might take a while to get > there. > > From sundar at openjdk.java.net Thu Jan 28 12:22:53 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Thu, 28 Jan 2021 12:22:53 GMT Subject: [foreign-jextract] RFR: 8260583: jextract generates redundant constant files In-Reply-To: References: Message-ID: <9iHIjFs6CC-SmpkgNtqz2xLoDiCNG7kpU28YSUvuLhU=.7320ed78-630c-4443-b997-d9d60356eae4@github.com> On Thu, 28 Jan 2021 12:10:21 GMT, Maurizio Cimadamore wrote: > When testing performances of jextract generated code with big headers, I noticed that jextract was emitting empty constant files. After some debugging, I realized that the issues lies in the fact that `ConstantHelper::build` is called both by `ToplevelBuilder::build` and by `HeaderFileBuilder::build` - so, for every new header file split that is generated, we trigger a new constant file, even though that is not needed. > > The solution is to remove the call from `HeaderFileBuilder` and just keep the one inside `TopLevelBuilder`. Marked as reviewed by sundar (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/440 From maurizio.cimadamore at oracle.com Thu Jan 28 12:25:31 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Jan 2021 12:25:31 +0000 Subject: [External] : Re: Feedback / query on jextract for Windows 10 In-Reply-To: <684bf255-2aec-c78b-712d-b0c9e80f6666@gmail.com> References: <0e35502c-3656-9c23-eca8-4ca8a4377d15@gmail.com> <52aa2217-0795-a27b-8173-78b06be3f25b@gmail.com> <145ff947-5de4-3d7e-17b9-074842b0f2ce@oracle.com> <9071e122-8bb3-2688-f9f3-ba63f15e127f@gmail.com> <03b8a550-b3a3-acd1-a1ba-752454b01a01@oracle.com> <1cd0b90eafd10db474e75874895fe307e18b3d57.camel@oracle.com> <8526bb67168cedd3d3c7ffa0100d3dcbf24199d1.camel@oracle.com> <684bf255-2aec-c78b-712d-b0c9e80f6666@gmail.com> Message-ID: <8f6773a33fd3ffdc7204d43be115b25cac1721a3.camel@oracle.com> On Thu, 2021-01-28 at 12:21 +0000, Duncan Gittins wrote: > Understood. The behaviour of "--source" is different to the class > generation in this respect too, as the "--source" compile version > creates all method handles at once. [I confirmed this by adding > System.out.println("downcallHandle "+name); into the > RuntimeHelper.downcallHandle method and then merged the > modified+compiled --source class with the generated classes to > verify > on-demand creates there] Yes, the source generation is eager, while the class generation is as lazy as possible, using every inch of VM features we have available there. We could do more on the source side, to make things lazier there, but we're at the fence - kind of hoping for this: https://openjdk.java.net/jeps/8209964 If we had this, then we could just use same strategy for both class AND source and they would be both "naturally" lazy. We do not have plans to remove the --source flag. Cheers Maurizio > > It would be nice to view the generated source to study the issue - > will > the --source option be maintained in future releases? Perhaps it's > time > that I downloaded the JDK source repository and find out myself. > > Duncan > > On 27/01/2021 22:13, Maurizio Cimadamore wrote: > > On Wed, 2021-01-27 at 17:56 +0000, Maurizio Cimadamore wrote: > > > I'll keep investigating to see if this is expected behavior, or > > > if > > > > > > there's something that can be improved, either in how we > > > generated > > > > > > code, or in the constant dynamic support. > > As it turns out, there's not much we can do in this kind of > > situation. > > Basically, we're in a case where we have a deep hierarchy like > > this: > > > > A1 extends A2 extends A3 ... extends An > > > > (we need to do this so that all symbols will be seen as "members" > > of > > A1, while at the same time not blowing up the classfile limits). > > > > Now, if you call a static method, like A1::m, the VM has still to > > load > > the entire hierarchy A1 ... An. This seems counter-intuitive at > > first, > > after all, we want to call a static method, not an instance one, so > > there's no vtable needed. But - VM method resolution is designed to > > look into superclasses not just for instance methods, but also for > > static ones! There's also the detail that the VM must know the > > superclasses in order to correctly layout _static_ fields in the > > hierarchy (again, there are no fields in jextract generated > > hierarchy - > > but to discover that you have to walk the hierarchy anyway, so that > > info cannot be exploited at load time). > > > > So, when dealing with enormous headers (like Windows.h), filtering > > is > > the way to go. Our approach is already trying its best at being as > > lazy > > as possible (and I've verified that it only creates the layouts and > > method handles that are used by the client - so that aspect works) > > - > > but we cannot take away the cost of class loading. > > > > Of course, if jextract bucketed the various symbols in separate > > files > > which you had to manually include, we could reduce the cost > > associated > > to loading - but at a big cost in terms of usability: as a user of > > a > > big library L, how are you expected to know in which header is a > > given > > symbol defined? We have tried breaking up by headers in the past, > > and > > it just doesn't work. > > > > The scheme we have now works very well for all "normal" libraries - > > it > > adds zero-to-very-minimal overhead, and it makes things easy for > > clients which do not have to guess where symbols are (just import > > the > > main `foo_h` header file, and everything works). Unfortunately this > > means that clients that want to interact with huge, monolithic > > libraries, will have to resort to filtering, or maybe define some > > headers manually (as you have done) to keep footprint down. I don't > > think there's a silver bullet here (*): we can only hope to come up > > with something that works well in the 90% of cases, and then offer > > workarounds for the remaining 10%. > > > > Cheers > > Maurizio > > > > (*) It occurs to me that most of the symbols required by a client > > interacting with a jextracted API are scrutable and foldable > > symbols: > > method handles, var handles, layouts, ... > > This could mean that, at least in principle, in the future it would > > be > > possible for javac to remove calls and dependencies on the jextract > > generated binding, and "inline" the var/method handle creation (as > > it > > does for other kind of "constants"). This generalization of > > constant > > folding has been discussed in this JEP: > > > > https://openjdk.java.net/jeps/303 > > > > So, there might be, one day, a solution which will allow javac to > > "embed" only the contents from a jextract bindings that are > > required in > > order to execute your application. But it might take a while to get > > there. > > > > From mcimadamore at openjdk.java.net Thu Jan 28 12:32:09 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 28 Jan 2021 12:32:09 GMT Subject: [foreign-jextract] Integrated: 8260583: jextract generates redundant constant files In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 12:10:21 GMT, Maurizio Cimadamore wrote: > When testing performances of jextract generated code with big headers, I noticed that jextract was emitting empty constant files. After some debugging, I realized that the issues lies in the fact that `ConstantHelper::build` is called both by `ToplevelBuilder::build` and by `HeaderFileBuilder::build` - so, for every new header file split that is generated, we trigger a new constant file, even though that is not needed. > > The solution is to remove the call from `HeaderFileBuilder` and just keep the one inside `TopLevelBuilder`. This pull request has now been integrated. Changeset: 1233eafd Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/1233eafd Stats: 78 lines in 3 files changed: 75 ins; 2 del; 1 mod 8260583: jextract generates redundant constant files Reviewed-by: sundar ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/440 From magnus.ihse.bursie at oracle.com Thu Jan 28 12:56:45 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 28 Jan 2021 13:56:45 +0100 Subject: Can not built latest vectorIntrinsic on Windows (Was: Testing Vector API; which branch to build?) In-Reply-To: References: <57548DC0-D057-43A0-9EB8-6859E435AD16@tencent.com> <61bad66a-c12c-2f49-351f-3dc6d6bc9746@serebryakov.spb.ru> Message-ID: <4e4fe585-646b-1154-cf12-c0da5fcd38dd@oracle.com> On 2021-01-27 23:25, Lev Serebryakov wrote: > On 27.01.2021 19:34, Paul Sandoz wrote: > > ?Looks like command line for ml.exe (MS' assembler) is wrong: > > /cygdrive/c/home/ref/panama-vector/build/windows-x86_64-server-release/fixpath > exec \ > /cygdrive/c/progra~2/micros~2/2019/commun~1/vc/tools/msvc/1428~1.293/bin/hostx86/x86/ml.exe > \ > -Fo/cygdrive/c/home/ref/panama-vector/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/svml_d_acos_windows_x86.obj > \ > ? /Ta > /cygdrive/c/home/ref/panama-vector/src/hotspot/os_cpu/windows_x86/svml_d_acos_windows_x86.s > > /Ta is "trust this source, even if extension is not asm" > > -Fo is "output object file", but it should be "/Fo", really and there > should be /c after it ("assemble only, don't link")... Actually, the microsoft tools will accept - as well as / as prefix. We have consistently used - instead of /, since it lowers the risk of parsing conflicts between options and paths written in unix style. So -Fo is not incorrect, and it is in fact preferred. Correspondingly, the other flags should be "-c" and "-Ta". > Also, "ml.exe" is 32-bit assembelr with 32-bit output. ml64.exe is > needed here (as Win32 32 bit is not supported by JDK anymore). Actually, some folks still build this, and while it is not regularly tested, we always get patches when things break, so I'd hate to break it knowingly. So ml64.exe cannot generate code for 32-bit output, and ml64.exe cannot generate code for 64-bit output? But both commands will be present on a 64-bit system? > > ?Ok, I found solution (by searching for "/Ta"). Patch attached. > > ?This is not full solution, it doesn't hide ML's output (banner & all > this), I think the proper solution is to add "-nologo" to ASFLAGS in configure. Assembly on Windows has gotten very little attention, due to the simple fact that we have not had any assembly code needed on Windows before. :-) (Or if we had, it was long time ago, and has bit-rotted heavily.) I look at the code and realize it might need some cleanup. I assume I can open a PR on the panama-vector repo? /Magnus From sebastian.stenzel at gmail.com Thu Jan 28 13:06:47 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Thu, 28 Jan 2021 14:06:47 +0100 Subject: Is a jextracted jar supposed to be published? Message-ID: <4AD06951-2B2F-4428-9E07-4AF079E5EB49@gmail.com> > On 28. Jan 2021, at 13:25, Maurizio Cimadamore wrote: > > Yes, the source generation is eager, while the class generation is as > lazy as possible, using every inch of VM features we have available > there. We could do more on the source side, to make things lazier > there, but we're at the fence - kind of hoping for this: > > https://openjdk.java.net/jeps/8209964 > > If we had this, then we could just use same strategy for both class AND > source and they would be both "naturally" lazy. > > We do not have plans to remove the --source flag. Above is a quote from the "Feedback / query on jextract for Windows 10" thread, which I didn't want to hijack. So I thought to create a new one instead. So far I have always been working with `--source`, however after reading the aforementioned, I'm reconsidering. However, I really don't understand how jextracted .jar files are intended to be used. Without further artifacts such as a source jar, we can not just straightaway publish them to public repos like Maven Central, which effectively disqualifies them to be used as a dependency as is. This brings me to the question: Is the jextracted jar file even intended to be "released" or should I consider it just an intermediate build artifact that _requires_ post-processing such as re-packaging (i.e. using maven-shade-plugin)? I know that this question may be a bit off-topic, but since there seem to be significant differences between generated sources and classes, I thought I should bring up these "downstream problems" before it is too late. From lev at serebryakov.spb.ru Thu Jan 28 13:08:57 2021 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Thu, 28 Jan 2021 16:08:57 +0300 Subject: Can not built latest vectorIntrinsic on Windows (Was: Testing Vector API; which branch to build?) In-Reply-To: References: <57548DC0-D057-43A0-9EB8-6859E435AD16@tencent.com> <61bad66a-c12c-2f49-351f-3dc6d6bc9746@serebryakov.spb.ru> Message-ID: <82d2cc94-3e18-61bc-9327-22837376e08c@serebryakov.spb.ru> On 28.01.2021 5:25, Viswanathan, Sandhya wrote: > Thanks for looking into it. My patch was dirty hack to make branch build on my system (!), not a complete solution. Thank you for improvements! > Do you plan to submit the fix to panama-dev? This message is on panama-dev@ so, I think, it is effectively submitted? :) -- // Black Lion AKA Lev Serebryakov From lev at serebryakov.spb.ru Thu Jan 28 13:13:00 2021 From: lev at serebryakov.spb.ru (Lev Serebryakov) Date: Thu, 28 Jan 2021 16:13:00 +0300 Subject: Can not built latest vectorIntrinsic on Windows (Was: Testing Vector API; which branch to build?) In-Reply-To: <4e4fe585-646b-1154-cf12-c0da5fcd38dd@oracle.com> References: <57548DC0-D057-43A0-9EB8-6859E435AD16@tencent.com> <61bad66a-c12c-2f49-351f-3dc6d6bc9746@serebryakov.spb.ru> <4e4fe585-646b-1154-cf12-c0da5fcd38dd@oracle.com> Message-ID: <86e67d35-77ff-dc64-0f67-9dfffa5f3980@serebryakov.spb.ru> On 28.01.2021 15:56, Magnus Ihse Bursie wrote: >> Also, "ml.exe" is 32-bit assembelr with 32-bit output. ml64.exe is needed here (as Win32 32 bit is not supported by JDK anymore). > > Actually, some folks still build this, and while it is not regularly tested, we always get patches when things break, so I'd hate to break it knowingly. Sandhya Viswanathan provided right way to select assembler binary. > So ml64.exe cannot generate code for 32-bit output, and ml64.exe cannot generate code for 64-bit output? But both commands will be present on a 64-bit system? I'm not a expert in MS build toolchain by any means, but short googling and reading ML documentation on MS site doesn't reveal any switch/option to change "bitness" of Assembler. Looks like ML.exe is for 32 bit output and ML64 is for 64 bit one. Default toolchion installation on 64 bit system has both of them. > I look at the code and realize it might need some cleanup. I assume I can open a PR on the panama-vector repo? Looks like patches from Sandhya could be a good start. -- // Black Lion AKA Lev Serebryakov From forax at univ-mlv.fr Thu Jan 28 14:06:11 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 28 Jan 2021 15:06:11 +0100 (CET) Subject: Is a jextracted jar supposed to be published? In-Reply-To: <4AD06951-2B2F-4428-9E07-4AF079E5EB49@gmail.com> References: <4AD06951-2B2F-4428-9E07-4AF079E5EB49@gmail.com> Message-ID: <1714047310.426766.1611842771257.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Sebastian Stenzel" > ?: "Maurizio Cimadamore" > Cc: "panama-dev at openjdk.java.net'" > Envoy?: Jeudi 28 Janvier 2021 14:06:47 > Objet: Is a jextracted jar supposed to be published? >> On 28. Jan 2021, at 13:25, Maurizio Cimadamore >> wrote: >> >> Yes, the source generation is eager, while the class generation is as >> lazy as possible, using every inch of VM features we have available >> there. We could do more on the source side, to make things lazier >> there, but we're at the fence - kind of hoping for this: >> >> https://openjdk.java.net/jeps/8209964 >> >> If we had this, then we could just use same strategy for both class AND >> source and they would be both "naturally" lazy. >> >> We do not have plans to remove the --source flag. > > Above is a quote from the "Feedback / query on jextract for Windows 10" thread, > which I didn't want to hijack. So I thought to create a new one instead. So far > I have always been working with `--source`, however after reading the > aforementioned, I'm reconsidering. > > However, I really don't understand how jextracted .jar files are intended to be > used. Without further artifacts such as a source jar, we can not just > straightaway publish them to public repos like Maven Central, which effectively > disqualifies them to be used as a dependency as is. I have not all the answer :) Technically the .h file is the source, a generated .java source file is not better than a .class file. I can see IDEs in the fture being able to link the elements of a .h file with the corresponding class file representation. > > This brings me to the question: Is the jextracted jar file even intended to be > "released" or should I consider it just an intermediate build artifact that > _requires_ post-processing such as re-packaging (i.e. using > maven-shade-plugin)? Great question, it can also be like Ruby gems, the jar file is generated at the first installation. I think it depends on from whom the .h file comes from and on which OS your program run, on Windows the libraries tends to be backward compatible while on Linux, only the kernel OS calls are backward compatible so you may want to support several incompatible versions of the same library. I hope jextract will have enough option to avoid shading because you loose the connection between the source code and class files with shading. Shading is fine for an application, far less for a library. > > I know that this question may be a bit off-topic, but since there seem to be > significant differences between generated sources and classes, I thought I > should bring up these "downstream problems" before it is too late. R?mi From maurizio.cimadamore at oracle.com Thu Jan 28 14:08:52 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Jan 2021 14:08:52 +0000 Subject: [External] : Is a jextracted jar supposed to be published? In-Reply-To: <4AD06951-2B2F-4428-9E07-4AF079E5EB49@gmail.com> References: <4AD06951-2B2F-4428-9E07-4AF079E5EB49@gmail.com> Message-ID: <9d0840119e7d2b0006b43ce8b14ed495a6ace531.camel@oracle.com> > > This brings me to the question: Is the jextracted jar file even > intended to be "released" or should I consider it just an > intermediate build artifact that _requires_ post-processing such as > re-packaging (i.e. using maven-shade-plugin)? > > I know that this question may be a bit off-topic, but since there > seem to be significant differences between generated sources and > classes, I thought I should bring up these "downstream problems" > before it is too late. I believe that, eventually, both formats will do the same thing - it's just hard (if not impossible w/o extra overhead) at the moment to have a truly lazy source-based strategy, but as mentioned, help is on the way (by means of other JEPs). The jar option is mostly meant for quick consumption of the jextract- generated artifact - it was never our goal to generate a distribution- ready artifact. So I would file it in the "intermediate build artifact" category. Perhaps I wonder if, by generating classes instead of a jar, we might make this clearer than it is currently. Maurizio From jvernee at openjdk.java.net Thu Jan 28 15:13:59 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 28 Jan 2021 15:13:59 GMT Subject: [foreign-memaccess+abi] RFR: 8258238: Some jextract samples crash with: "updating map that does not need updating" Message-ID: Hi, This PR applies the same fix we did for x86 in [1] to frame_aarch64, which sees the same issue. The test for this issue is found at [2], which is still under review as well. Thanks, Jorn [1] : https://github.com/openjdk/panama-foreign/pull/417 [2] : https://github.com/openjdk/panama-foreign/pull/423 ------------- Commit messages: - Apply same update_map() check in frame_aarch64.cpp Changes: https://git.openjdk.java.net/panama-foreign/pull/441/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=441&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258238 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/441.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/441/head:pull/441 PR: https://git.openjdk.java.net/panama-foreign/pull/441 From maurizio.cimadamore at oracle.com Thu Jan 28 15:51:47 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Jan 2021 15:51:47 +0000 Subject: [External] : Is a jextracted jar supposed to be published? In-Reply-To: <9d0840119e7d2b0006b43ce8b14ed495a6ace531.camel@oracle.com> References: <4AD06951-2B2F-4428-9E07-4AF079E5EB49@gmail.com> <9d0840119e7d2b0006b43ce8b14ed495a6ace531.camel@oracle.com> Message-ID: On Thu, 2021-01-28 at 14:08 +0000, Maurizio Cimadamore wrote: > Perhaps I wonder if, by generating classes instead of a jar, > > we might make this clearer than it is currently. Minor correction - I got confused :-) The current jextract does NOT have a jar output - precisely not to make any claim re. distribute-ability. I acknowledge that there's a wider problem regarding distributing jextract artifacts - my sense is that most of the issues we have now could be eventually side-stepped once we can roll-in a 100% "lazy" source generation strategy (at which point libraries producers can take the sources and package them in any way they like). As I said before in this thread, there's unfortunately an asymmetry between what can be expressed in the source code (in terms of laziness) and what can be expressed in terms of bytecode - which is why we provide two options. But I do hope this is a transient state, not the final one. CheersMaurizio From paul.sandoz at oracle.com Thu Jan 28 16:12:44 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 28 Jan 2021 16:12:44 +0000 Subject: Can not built latest vectorIntrinsic on Windows (Was: Testing Vector API; which branch to build?) In-Reply-To: <4e4fe585-646b-1154-cf12-c0da5fcd38dd@oracle.com> References: <57548DC0-D057-43A0-9EB8-6859E435AD16@tencent.com> <61bad66a-c12c-2f49-351f-3dc6d6bc9746@serebryakov.spb.ru> <4e4fe585-646b-1154-cf12-c0da5fcd38dd@oracle.com> Message-ID: <6994D450-C6F5-4A64-8DEA-4AA05DED3FAE@oracle.com> > On Jan 28, 2021, at 4:56 AM, Magnus Ihse Bursie wrote: > > I look at the code and realize it might need some cleanup. I assume I can open a PR on the panama-vector repo? > Yes, it should be possible, unsure if it will need a sponsor. Thanks for the help. Paul. From sebastian.stenzel at gmail.com Thu Jan 28 17:33:58 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Thu, 28 Jan 2021 18:33:58 +0100 Subject: [External] : Is a jextracted jar supposed to be published? In-Reply-To: References: Message-ID: > Am 28.01.2021 um 16:53 schrieb Maurizio Cimadamore : > > The current jextract does NOT have a jar output - precisely not to make > any claim re. distribute-ability. Oh I didn't know that. Last time I tried, it produced a jar, since then I always created sources. In that case I will experiment with creating class files directly. Thanks for the clarification! From krakowski at hhu.de Thu Jan 28 17:48:15 2021 From: krakowski at hhu.de (Filip Krakowski) Date: Thu, 28 Jan 2021 18:48:15 +0100 Subject: [foreign-jextract] Duplicated interface declarations when using typedefs for function pointers Message-ID: <5c613b22-d0dc-56e5-875e-6153178d6b41@hhu.de> Hi, I just noticed that jextract generates duplicate code (interfaces) for function pointers within each struct instead at the top-level. Each interface's name seems to have a suffix based on the occurrence of the declaration in the source file. typedef void (*callback_t)(void *arg); typedef struct first_handler { ??? callback_t cb; } first_handler_t; typedef struct second_handler { ??? callback_t cb; } second_handler_t; This code generates the following java source code. @C("struct first_handler")public static class first_handler { ... ??? public static interface cb { ??????????? void apply(jdk.incubator.foreign.MemoryAddress x0); ??????????? public static? @C("callback_t") MemorySegment allocate(cb fi) { ??????????????? return RuntimeHelper.upcallStub(cb.class, fi, ucx_h_constants_0.cb$FUNC(), "(Ljdk/incubator/foreign/MemoryAddress;)V"); ??????????? } ??????????? public static? @C("callback_t") MemorySegment allocate(cb fi, NativeScope scope) { ??????????????? return allocate(fi).handoff(scope); ??????????? } ??????? } ... } @C("struct second_handler")public static class second_handler { ... ??? public static interface cb$0 { ??????????? void apply(jdk.incubator.foreign.MemoryAddress x0); ??????????? public static? @C("callback_t") MemorySegment allocate(cb$0 fi) { ??????????????? return RuntimeHelper.upcallStub(cb$0.class, fi, ucx_h_constants_0.cb$0$FUNC(), "(Ljdk/incubator/foreign/MemoryAddress;)V"); ??????????? } ??????????? public static? @C("callback_t") MemorySegment allocate(cb$0 fi, NativeScope scope) { ??????????????? return allocate(fi).handoff(scope); ??????????? } ??????? } ... } From my point of view both interfaces are identical. Is there a reason for placing them inside the struct class? Best regards Filip From maurizio.cimadamore at oracle.com Thu Jan 28 17:49:08 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Jan 2021 17:49:08 +0000 Subject: [External] : Is a jextracted jar supposed to be published? In-Reply-To: References: Message-ID: <28328792515666b2e7ef63d546183459823ec36a.camel@oracle.com> On Thu, 2021-01-28 at 18:33 +0100, Sebastian Stenzel wrote: > > Am 28.01.2021 um 16:53 schrieb Maurizio Cimadamore < > > maurizio.cimadamore at oracle.com>: > > > > The current jextract does NOT have a jar output - precisely not to > > make > > any claim re. distribute-ability. > > Oh I didn't know that. Last time I tried, it produced a jar, since > then I always created sources. In that case I will experiment with > creating class files directly. Thanks for the clarification! > I believe that was what jextract generated in the EA we shipped before last September, yes. The "new" jextract we started to ship in recent EA builds is simpler, and more direct - but the API it generates is quite different from what it used to be - e.g. more low level (jextract now is a thin wrapper around the VarHandle/MethodHandle layer - see [1]). [1] http://cr.openjdk.java.net/~mcimadamore/panama/jextract_distilled.html > From maurizio.cimadamore at oracle.com Thu Jan 28 17:57:42 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Jan 2021 17:57:42 +0000 Subject: [foreign-jextract] Duplicated interface declarations when using typedefs for function pointers In-Reply-To: <5c613b22-d0dc-56e5-875e-6153178d6b41@hhu.de> References: <5c613b22-d0dc-56e5-875e-6153178d6b41@hhu.de> Message-ID: <1614976372c35ba935f8ee8457bd4af8795837e1.camel@oracle.com> This seems odd. But I guess I can see why jextract ends up doing that. I think what jextract *should* do is to reuse the interface for `callback_t` whenever possible (which should be declared at the toplevel). In other words, it seems like jextract is re-generating a new interface every time it encounters a reference to a function pointer typedef, which seems a bug. Maurizio On Thu, 2021-01-28 at 18:48 +0100, Filip Krakowski wrote: > Hi, > > I just noticed that jextract generates duplicate code (interfaces) > for > function pointers within each struct instead at the top-level. > Each interface's name seems to have a suffix based on the occurrence > of > the declaration in the source file. > > typedef void (*callback_t)(void *arg); > > typedef struct first_handler { > callback_t cb; > } first_handler_t; > > typedef struct second_handler { > callback_t cb; > } second_handler_t; > > This code generates the following java source code. > > @C("struct first_handler")public static class first_handler { > ... > public static interface cb { > > void apply(jdk.incubator.foreign.MemoryAddress x0); > > public static @C("callback_t") MemorySegment > allocate(cb fi) { > return RuntimeHelper.upcallStub(cb.class, fi, > ucx_h_constants_0.cb$FUNC(), > "(Ljdk/incubator/foreign/MemoryAddress;)V"); > } > > public static @C("callback_t") MemorySegment > allocate(cb fi, NativeScope scope) { > return allocate(fi).handoff(scope); > } > } > ... > } > > @C("struct second_handler")public static class second_handler { > ... > public static interface cb$0 { > > void apply(jdk.incubator.foreign.MemoryAddress x0); > > public static @C("callback_t") MemorySegment > allocate(cb$0 fi) { > return RuntimeHelper.upcallStub(cb$0.class, fi, > ucx_h_constants_0.cb$0$FUNC(), > "(Ljdk/incubator/foreign/MemoryAddress;)V"); > } > > public static @C("callback_t") MemorySegment > allocate(cb$0 fi, NativeScope scope) { > return allocate(fi).handoff(scope); > } > } > ... > } > > From my point of view both interfaces are identical. Is there a > reason > for placing them inside the struct class? > > > Best regards > Filip > > From sebastian.stenzel at gmail.com Thu Jan 28 18:24:58 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Thu, 28 Jan 2021 19:24:58 +0100 Subject: [External] : Is a jextracted jar supposed to be published? In-Reply-To: <28328792515666b2e7ef63d546183459823ec36a.camel@oracle.com> References: <28328792515666b2e7ef63d546183459823ec36a.camel@oracle.com> Message-ID: <693D37FC-2764-480E-8439-B7CA697384DD@gmail.com> > Am 28.01.2021 um 18:49 schrieb Maurizio Cimadamore : > > ?On Thu, 2021-01-28 at 18:33 +0100, Sebastian Stenzel wrote: >>> Am 28.01.2021 um 16:53 schrieb Maurizio Cimadamore < >>> maurizio.cimadamore at oracle.com>: >>> >>> The current jextract does NOT have a jar output - precisely not to >>> make >>> any claim re. distribute-ability. >> >> Oh I didn't know that. Last time I tried, it produced a jar, since >> then I always created sources. In that case I will experiment with >> creating class files directly. Thanks for the clarification! >> > I believe that was what jextract generated in the EA we shipped before > last September, yes. The "new" jextract we started to ship in recent EA > builds is simpler, and more direct - but the API it generates is quite > different from what it used to be - e.g. more low level (jextract now > is a thin wrapper around the VarHandle/MethodHandle layer - see [1]). > > [1] > http://cr.openjdk.java.net/~mcimadamore/panama/jextract_distilled.html Yes, I noticed the API change! :D I just wasn't aware that it stopped producing jars, since I never tried it. From vlivanov at openjdk.java.net Thu Jan 28 18:52:56 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 28 Jan 2021 18:52:56 GMT Subject: [foreign-memaccess+abi] RFR: Add stack walk test case that doesn't verify oops In-Reply-To: <2dC5iNW2JzprohQhvxGLIBOyPU-dKkXNppcVCrYpCis=.cd68e19a-e7d0-41ed-8fb6-f4548a9042ef@github.com> References: <2dC5iNW2JzprohQhvxGLIBOyPU-dKkXNppcVCrYpCis=.cd68e19a-e7d0-41ed-8fb6-f4548a9042ef@github.com> Message-ID: On Wed, 16 Dec 2020 14:25:45 GMT, Jorn Vernee wrote: > This is a followup for the earlier quickfix of: https://github.com/openjdk/panama-foreign/pull/417 > > This adds another test case to TestStackWalk that catches the failing code path. > > This re-uses the previously added `WhiteBox::verifyFrames`, and adds a flag to turn off the verification, which triggers the problematic code path. (I've also renamed this to just `walkFrames`, since now we don't always do verification anymore. src/hotspot/share/prims/whitebox.cpp line 2293: > 2291: tty->print_cr("[WhiteBox::WalkFrames] Walking Frames"); > 2292: } > 2293: for (StackFrameStream fst(JavaThread::current(), verify_oops, true); !fst.is_done(); fst.next()) { Can you elaborate, please, why `verify_oops` is equivalent to `RegisterMap::_update_map`? ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/423 From maurizio.cimadamore at oracle.com Thu Jan 28 18:57:32 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Jan 2021 18:57:32 +0000 Subject: [foreign-jextract] Duplicated interface declarations when using typedefs for function pointers In-Reply-To: <1614976372c35ba935f8ee8457bd4af8795837e1.camel@oracle.com> References: <5c613b22-d0dc-56e5-875e-6153178d6b41@hhu.de> <1614976372c35ba935f8ee8457bd4af8795837e1.camel@oracle.com> Message-ID: <70c6242355f75f242c3c9a611a04e7e2414f6734.camel@oracle.com> Filed this: https://bugs.openjdk.java.net/browse/JDK-8260602 Thanks for the report! Maurizio On Thu, 2021-01-28 at 17:57 +0000, Maurizio Cimadamore wrote: > This seems odd. But I guess I can see why jextract ends up doing > that. > > I think what jextract *should* do is to reuse the interface for > `callback_t` whenever possible (which should be declared at the > toplevel). > > In other words, it seems like jextract is re-generating a new > interface > every time it encounters a reference to a function pointer typedef, > which seems a bug. > > Maurizio > > > > On Thu, 2021-01-28 at 18:48 +0100, Filip Krakowski wrote: > > Hi, > > > > I just noticed that jextract generates duplicate code (interfaces) > > for > > function pointers within each struct instead at the top-level. > > Each interface's name seems to have a suffix based on the > > occurrence > > of > > the declaration in the source file. > > > > typedef void (*callback_t)(void *arg); > > > > typedef struct first_handler { > > callback_t cb; > > } first_handler_t; > > > > typedef struct second_handler { > > callback_t cb; > > } second_handler_t; > > > > This code generates the following java source code. > > > > @C("struct first_handler")public static class first_handler { > > ... > > public static interface cb { > > > > void apply(jdk.incubator.foreign.MemoryAddress > > x0); > > > > public static @C("callback_t") MemorySegment > > allocate(cb fi) { > > return RuntimeHelper.upcallStub(cb.class, fi, > > ucx_h_constants_0.cb$FUNC(), > > "(Ljdk/incubator/foreign/MemoryAddress;)V"); > > } > > > > public static @C("callback_t") MemorySegment > > allocate(cb fi, NativeScope scope) { > > return allocate(fi).handoff(scope); > > } > > } > > ... > > } > > > > @C("struct second_handler")public static class second_handler { > > ... > > public static interface cb$0 { > > > > void apply(jdk.incubator.foreign.MemoryAddress > > x0); > > > > public static @C("callback_t") MemorySegment > > allocate(cb$0 fi) { > > return RuntimeHelper.upcallStub(cb$0.class, > > fi, > > ucx_h_constants_0.cb$0$FUNC(), > > "(Ljdk/incubator/foreign/MemoryAddress;)V"); > > } > > > > public static @C("callback_t") MemorySegment > > allocate(cb$0 fi, NativeScope scope) { > > return allocate(fi).handoff(scope); > > } > > } > > ... > > } > > > > From my point of view both interfaces are identical. Is there a > > reason > > for placing them inside the struct class? > > > > > > Best regards > > Filip > > > > From mcimadamore at openjdk.java.net Thu Jan 28 19:01:01 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 28 Jan 2021 19:01:01 GMT Subject: [foreign-jextract] RFR: 8260602: jextract generates redundant functional interafces Message-ID: <1knXBUwBzGGK7IxosTzXmcxCd82WUe6lXZbykE0Q38g=.a5549fc7-5f95-473f-9852-0ee0d05f730d@github.com> There seems to be an issue in how jextract handles function pointer typedef. Currently, these typedefs are handled in two places: * OutputFactory::visitVar * OutputFactory::visitFunction That is, if a variable (struct field or global), or a function parameter is seen to have a typedef of a function pointer, jextract will generate a functional interface _exactly at that point_ where the variable is found. This might be inside a struct. Now, what we really want is slightly different: the functional interface for a function pointer typedef should really be generated in the toplevel interface hierarchy; any other reference to it (from struct fields, or function parameters, or globals) should _not_ result in additional functional interface declaration. In other words, in this example [1]: typedef void (*callback_t)(void *arg); typedef struct first_handler { callback_t cb; } first_handler_t; typedef struct second_handler { callback_t cb; } second_handler_t; There should be (in the user perspective) only _one_ functional interface, and its name should just be `callback_t`. The fix is to make OutputFactory::getAsFunctionPointer non-transparent w.r.t. typedefs - that is, if a typedef is found, that method should just return null (so that the enclosing code will skip functional interface generation). To counter balance that, we need to add logic for functional interface declaration inside OutputFactory::visitTypedef. I did not add any new test, since it turns out we already had a test for this (LibTest8258605Test) whose code was referring to the same typedef-ed function pointer using two names - this fix rectifies that behavior, and the test is now updated. [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011948.html ------------- Commit messages: - Fix redundant functional interfaces Changes: https://git.openjdk.java.net/panama-foreign/pull/442/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=442&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260602 Stats: 13 lines in 3 files changed: 9 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/442.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/442/head:pull/442 PR: https://git.openjdk.java.net/panama-foreign/pull/442 From maurizio.cimadamore at oracle.com Thu Jan 28 22:05:37 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Jan 2021 22:05:37 +0000 Subject: Feedback / query on jextract for Windows 10 In-Reply-To: <0e35502c-3656-9c23-eca8-4ca8a4377d15@gmail.com> References: <0e35502c-3656-9c23-eca8-4ca8a4377d15@gmail.com> Message-ID: <6aeec51e5921ed084808ec984b5194678f1ab736.camel@oracle.com> On Sat, 2021-01-23 at 18:34 +0000, Duncan Gittins wrote: > Have you considered changing the generated code to use lazy > Supplier instead of MethodHandle to ensure only > required > handles are created on-demand? I realize that I have not answered to this question in full, as we were attempting to diagnose if there was an issue. Why not using Supplier<...> in the source generation scheme? The issue has to do with constant-ness. For Hotspot to be able to optimize VarHandle and MethodHandle access, said VarHandles and MethodHandles have to be declared in _final_ _static_ variables. This doesn't leave a lot of room in terms of laziness. If we switched to some more dynamic approach (e.g. use a supplier, or dynamically assign elements into a static Object array) we would lose the constant-ness property, and var/method handle access would become slow. The only idiom which allows for lazy constant initialization in Java, w/o changes to the language, is something like this: ``` static class ValueHolder { final static MethodHandle x = ... } MethodHandle get_x() { return ValueHolder.x; } ``` This approach is fully lazy: the `x` constant is only initialized when the `get_x` method is called, because the constant is defined in its own holder class, and that holder class is only referenced by the getter method. So this is both lazy, and constant-friendly. But there is, as I'm sure you have noted, a big drawback of this approach: it basically requires one class holder per constant value (ok, in the jextract case we could probably optimize a little by putting - with some redundancy - all constants related to e.g. the same native function in the same class, but still). So, unless we want to generate an enormous number of classes, this approach to achieve true laziness is not really feasible, as it comes with a static footprint tag which is simply prohibitive in most cases. That's why, to preserve constant-ness, we have sacrificed laziness when jextract runs in `source` mode (but not when running in `class` mode, since in that case we can take advantage of extra VM features that are only available at the bytecode level). I hope this helps. CheersMaurizio From njian at openjdk.java.net Fri Jan 29 03:03:50 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Fri, 29 Jan 2021 03:03:50 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE [v5] In-Reply-To: References: Message-ID: On Thu, 28 Jan 2021 01:52:09 GMT, Wang Huang wrote: >> This patch add cast nodes between interger types implementation for Arm SVE like "VectorCastB2X" "VectorCastI2X " "VectorCastS2X" "VectorCastL2X". > > Wang Huang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge vectorIntrinsics > - remove useless codes > - remove walkaround codes > - add other I2I cast nodes > - fix build bug on other archs caused by UseSVE > 0 > - 8259536: Add cast nodes between interger types implementation for Arm SVE src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 line 1483: > 1481: %{ > 1482: predicate(UseSVE > 0 && n->bottom_type()->is_vect()->length_in_bytes() >= 16 && > 1483: n->bottom_type()->is_vect()->element_basic_type() == T_`'TYPE2DATATYPE($2)); Please replace leading tab with space. src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 line 1504: > 1502: %{ > 1503: predicate(UseSVE > 0 && n->bottom_type()->is_vect()->length_in_bytes() >= 16 && > 1504: n->bottom_type()->is_vect()->element_basic_type() == T_`'TYPE2DATATYPE($2)); And here is another tab. src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 line 1460: > 1458: // ------------------------------ Vector cast ------------------------------- > 1459: dnl > 1460: define(`VECTOR_CAST_I2I', ` I think the I2I name is a bit confusing, as it is also used by S2I, I2L (though NEON has the same naming...). Maybe VECTOR_CAST_EXTEND? src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 line 1479: > 1477: > 1478: dnl > 1479: define(`VECTOR_CAST_B2I', ` VECTOR_CAST_EXTEND2? src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 line 1567: > 1565: > 1566: dnl > 1567: define(`VECTOR_CAST_L2B', ` E.g. VECTOR_CAST_NARROW3? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/31 From sundar at openjdk.java.net Fri Jan 29 07:52:48 2021 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Fri, 29 Jan 2021 07:52:48 GMT Subject: [foreign-jextract] RFR: 8260602: jextract generates redundant functional interafces In-Reply-To: <1knXBUwBzGGK7IxosTzXmcxCd82WUe6lXZbykE0Q38g=.a5549fc7-5f95-473f-9852-0ee0d05f730d@github.com> References: <1knXBUwBzGGK7IxosTzXmcxCd82WUe6lXZbykE0Q38g=.a5549fc7-5f95-473f-9852-0ee0d05f730d@github.com> Message-ID: <_J_tiedWwPS7JE3Sv992BDP6XakxvFGdcrqENICwKmk=.03ce8cd3-c1d2-45f5-8fc3-cf08b8e2936d@github.com> On Thu, 28 Jan 2021 18:56:29 GMT, Maurizio Cimadamore wrote: > There seems to be an issue in how jextract handles function pointer typedef. > > Currently, these typedefs are handled in two places: > > * OutputFactory::visitVar > * OutputFactory::visitFunction > > That is, if a variable (struct field or global), or a function parameter is seen to have a typedef of a function pointer, jextract will generate a functional interface _exactly at that point_ where the variable is found. This might be inside a struct. > > Now, what we really want is slightly different: the functional interface for a function pointer typedef should really be generated in the toplevel interface hierarchy; any other reference to it (from struct fields, or function parameters, or globals) should _not_ result in additional functional interface declaration. > > In other words, in this example [1]: > > typedef void (*callback_t)(void *arg); > > typedef struct first_handler { > callback_t cb; > } first_handler_t; > > typedef struct second_handler { > callback_t cb; > } second_handler_t; > > There should be (in the user perspective) only _one_ functional interface, and its name should just be `callback_t`. > > The fix is to make OutputFactory::getAsFunctionPointer non-transparent w.r.t. typedefs - that is, if a typedef is found, that method should just return null (so that the enclosing code will skip functional interface generation). To counter balance that, we need to add logic for functional interface declaration inside OutputFactory::visitTypedef. > > I did not add any new test, since it turns out we already had a test for this (LibTest8258605Test) whose code was referring to the same typedef-ed function pointer using two names - this fix rectifies that behavior, and the test is now updated. > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011948.html Marked as reviewed by sundar (Committer). ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/442 From duncan.gittins at gmail.com Fri Jan 29 10:53:49 2021 From: duncan.gittins at gmail.com (Duncan Gittins) Date: Fri, 29 Jan 2021 10:53:49 +0000 Subject: Feedback / query on jextract for Windows 10 In-Reply-To: <6aeec51e5921ed084808ec984b5194678f1ab736.camel@oracle.com> References: <0e35502c-3656-9c23-eca8-4ca8a4377d15@gmail.com> <6aeec51e5921ed084808ec984b5194678f1ab736.camel@oracle.com> Message-ID: <5fa7c946-4f1d-b487-be3b-d087b80cf24d@gmail.com> Thanks for the explanation, I had not appreciated the requirement that MH/VH must be final/static which rules out the type of lazy initialise I expected to find in the --source output, and similar to how I've set up the downcallHandle requests in my own code. I don't call into native code often enough to notice that my calls may be slower later on, and I don't plan to explore too many more of the monster Windows headers files that raise this issue. Previously I asked: "will the --source option be maintained in future releases?". I should have clarified my intention by adding "to be 100% same as the .class generation?". Based on your comments it sounds that 100% compatibility is unlikely for some time - without VM improvements your suggested - but it helpful to know the option will be kept and they may? converge at some point. Duncan On 28/01/2021 22:05, Maurizio Cimadamore wrote: > On Sat, 2021-01-23 at 18:34 +0000, Duncan Gittins wrote: >> Have you considered changing the generated code to use lazy >> Supplier instead of MethodHandle to ensure only >> required >> handles are created on-demand? > I realize that I have not answered to this question in full, as we were > attempting to diagnose if there was an issue. > > Why not using Supplier<...> in the source generation scheme? The issue > has to do with constant-ness. For Hotspot to be able to optimize > VarHandle and MethodHandle access, said VarHandles and MethodHandles > have to be declared in _final_ _static_ variables. This doesn't leave a > lot of room in terms of laziness. If we switched to some more dynamic > approach (e.g. use a supplier, or dynamically assign elements into a > static Object array) we would lose the constant-ness property, and > var/method handle access would become slow. > > The only idiom which allows for lazy constant initialization in Java, > w/o changes to the language, is something like this: > > ``` > static class ValueHolder { > final static MethodHandle x = ... > } > > MethodHandle get_x() { > return ValueHolder.x; > } > ``` > > This approach is fully lazy: the `x` constant is only initialized when > the `get_x` method is called, because the constant is defined in its > own holder class, and that holder class is only referenced by the > getter method. So this is both lazy, and constant-friendly. > > But there is, as I'm sure you have noted, a big drawback of this > approach: it basically requires one class holder per constant value > (ok, in the jextract case we could probably optimize a little by > putting - with some redundancy - all constants related to e.g. the same > native function in the same class, but still). > > So, unless we want to generate an enormous number of classes, this > approach to achieve true laziness is not really feasible, as it comes > with a static footprint tag which is simply prohibitive in most cases. > That's why, to preserve constant-ness, we have sacrificed laziness when > jextract runs in `source` mode (but not when running in `class` mode, > since in that case we can take advantage of extra VM features that are > only available at the bytecode level). > > I hope this helps. > > CheersMaurizio > > From maurizio.cimadamore at oracle.com Fri Jan 29 11:02:07 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 29 Jan 2021 11:02:07 +0000 Subject: Feedback / query on jextract for Windows 10 In-Reply-To: <5fa7c946-4f1d-b487-be3b-d087b80cf24d@gmail.com> References: <0e35502c-3656-9c23-eca8-4ca8a4377d15@gmail.com> <6aeec51e5921ed084808ec984b5194678f1ab736.camel@oracle.com> <5fa7c946-4f1d-b487-be3b-d087b80cf24d@gmail.com> Message-ID: <88af312a9bf7b6d2e373c42407d4b6e6a9b40e57.camel@oracle.com> On Fri, 2021-01-29 at 10:53 +0000, Duncan Gittins wrote: > Based on your comments it sounds that > > 100% compatibility is unlikely for some time - without VM > improvements > > your suggested - but it helpful to know the option will be kept and > they > > may converge at some point. Yes, that's the plan - in fact, I think that when we'll be able to express in source code what we can at the bytecode level, the "class" mode will, perhaps be the redundant one (I expect developers to prefer working with sources, rather than with classfiles). Cheers Maurizio From duke at openjdk.java.net Fri Jan 29 11:09:09 2021 From: duke at openjdk.java.net (duke) Date: Fri, 29 Jan 2021 11:09:09 GMT Subject: git: openjdk/panama-foreign: foreign-memaccess+abi: 118 new changesets Message-ID: Changeset: 58ceb254 Author: Claes Redestad Date: 2021-01-22 11:27:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/58ceb254 8259842: Remove Result cache from StringCoding Reviewed-by: naoto, plevart, rriggs ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/StringCoding.java ! src/java.base/share/classes/java/lang/System.java + test/micro/org/openjdk/bench/java/lang/StringDecode.java + test/micro/org/openjdk/bench/java/lang/StringEncode.java Changeset: bfac3fb5 Author: Aleksey Shipilev Date: 2021-01-22 11:39:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bfac3fb5 8260212: Shenandoah: resolve-only UpdateRefsMode is not used Reviewed-by: rkennke, zgu ! src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.hpp Changeset: 7ed8ba1c Author: Kim Barrett Date: 2021-01-22 13:12:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7ed8ba1c 8256814: WeakProcessorPhases may be redundant Remove WeakProcessorPhase, adding scoped enum categories to OopStorageSet. Reviewed-by: stefank, tschatzl, rkennke ! src/hotspot/share/gc/g1/g1FullGCAdjustTask.hpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp ! src/hotspot/share/gc/g1/g1RootProcessor.cpp ! src/hotspot/share/gc/shared/oopStorageSet.cpp ! src/hotspot/share/gc/shared/oopStorageSet.hpp ! src/hotspot/share/gc/shared/oopStorageSet.inline.hpp ! src/hotspot/share/gc/shared/oopStorageSetParState.hpp ! src/hotspot/share/gc/shared/oopStorageSetParState.inline.hpp ! src/hotspot/share/gc/shared/weakProcessor.cpp ! src/hotspot/share/gc/shared/weakProcessor.hpp ! src/hotspot/share/gc/shared/weakProcessor.inline.hpp - src/hotspot/share/gc/shared/weakProcessorPhase.hpp - src/hotspot/share/gc/shared/weakProcessorPhaseTimes.cpp - src/hotspot/share/gc/shared/weakProcessorPhaseTimes.hpp + src/hotspot/share/gc/shared/weakProcessorTimes.cpp + src/hotspot/share/gc/shared/weakProcessorTimes.hpp ! src/hotspot/share/gc/shenandoah/shenandoahParallelCleaning.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootVerifier.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/rootResolver.cpp ! src/hotspot/share/jfr/leakprofiler/utilities/rootType.cpp ! src/hotspot/share/jfr/leakprofiler/utilities/rootType.hpp ! src/hotspot/share/runtime/serviceThread.cpp ! test/hotspot/gtest/gc/shared/test_oopStorageSet.cpp Changeset: f928265e Author: Harold Seigel Date: 2021-01-22 13:52:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f928265e 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined Reviewed-by: lfoltan, sspitsyn, dholmes ! src/hotspot/share/oops/instanceKlass.cpp + test/hotspot/jtreg/runtime/sealedClasses/RedefinePermittedSubclass.java Changeset: acbcde8c Author: Pankaj Bansal Date: 2021-01-22 13:53:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/acbcde8c 8256111: Create implementation for NSAccessibilityStaticText protocol Reviewed-by: serb, kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonTextAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonTextAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/StaticTextAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/StaticTextAccessibility.m Changeset: 154e1d63 Author: Yasumasa Suenaga Date: 2021-01-22 14:16:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/154e1d63 8259009: G1 heap summary should be shown in "Heap Parameters" window on HSDB Reviewed-by: cjplummer, tschatzl ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1CollectedHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java Changeset: a97f3c18 Author: Kim Barrett Date: 2021-01-22 14:44:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a97f3c18 8258853: Support separate function declaration and definition with ENABLE_IF-based SFINAE Add ENABLE_IF_SDEFN, unit tests Reviewed-by: jrose, eosterlund ! src/hotspot/share/metaprogramming/enableIf.hpp ! test/hotspot/gtest/metaprogramming/test_enableIf.cpp Changeset: 18eb6d9e Author: Sean Coffey Date: 2021-01-22 15:31:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/18eb6d9e 8255348: NPE in PKIXCertPathValidator event logging code Reviewed-by: mullan ! src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! test/jdk/jdk/jfr/event/security/TestX509CertificateEvent.java ! test/jdk/jdk/jfr/event/security/TestX509ValidationEvent.java ! test/jdk/jdk/security/logging/TestX509CertificateLog.java ! test/jdk/jdk/security/logging/TestX509ValidationLog.java ! test/lib/jdk/test/lib/security/TestCertificate.java Changeset: 0ea58626 Author: Guoxiong Li Committer: Maurizio Cimadamore Date: 2021-01-22 15:47:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0ea58626 8260053: Optimize Tokens' use of Names Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java Changeset: bf5e8015 Author: Johannes Kuhn Committer: Mandy Chung Date: 2021-01-22 17:18:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bf5e8015 8259922: MethodHandles.collectArguments does not throw IAE if pos is outside the arity range Reviewed-by: mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java + test/jdk/java/lang/invoke/MethodHandlesCollectArgsTest.java Changeset: c5ad713e Author: Aleksey Shipilev Date: 2021-01-22 17:19:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c5ad713e 8260250: Duplicate check in DebugInformationRecorder::recorders_frozen Reviewed-by: iveresov, thartmann ! src/hotspot/share/code/debugInfoRec.cpp Changeset: 874aef4a Author: Alexey Bakhtin Committer: Daniel Fuchs Date: 2021-01-22 18:21:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/874aef4a 8259707: LDAP channel binding does not work with StartTLS extension Reviewed-by: mullan, dfuchs, aefimov ! src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java ! src/java.naming/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java Changeset: a8871776 Author: Stuart Marks Date: 2021-01-22 18:51:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a8871776 8246788: ZoneRules invariants can be broken Reviewed-by: rriggs, naoto ! src/java.base/share/classes/java/time/zone/ZoneRules.java + test/jdk/java/time/test/java/time/zone/TestMutableZoneRules.java Changeset: 53fecba7 Author: Dmitry Markov Date: 2021-01-22 19:21:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/53fecba7 8258805: Japanese characters not entered by mouse click on Windows 10 Reviewed-by: aivanov ! src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java Changeset: 5aca934c Author: Aleksey Shipilev Date: 2021-01-22 19:21:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5aca934c 8260304: (se) EPollSelectorImpl wakeup mechanism broken on Linux 32-bit Reviewed-by: bpb, alanb ! src/java.base/linux/native/libnio/ch/EventFD.c Changeset: 7be9113b Author: Dan Lemmond Committer: Paul Hohensee Date: 2021-01-22 20:33:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7be9113b 8255216: Change _directive->BreakAtCompileOption to env()->break_at_compile() Reviewed-by: kvn, phh ! src/hotspot/share/c1/c1_Compilation.cpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/opto/compile.cpp Changeset: bdc305e1 Author: Alex Menkov Date: 2021-01-22 21:33:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bdc305e1 8258917: NativeMemoryTracking is handled by launcher inconsistenly Reviewed-by: zgu ! src/java.base/share/native/libjli/java.c ! test/jdk/tools/launcher/TestSpecialArgs.java Changeset: aa57d07c Author: Ioi Lam Date: 2021-01-22 22:47:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aa57d07c 8259214: MetaspaceClosure support for Arrays of MetaspaceObj Reviewed-by: fparain, ccheung ! src/hotspot/share/memory/metaspaceClosure.hpp + test/hotspot/gtest/utilities/test_metaspaceClosure.cpp Changeset: a5367cbb Author: Brian Burkhalter Committer: Henry Jen Date: 2020-07-29 09:52:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a5367cbb 8247619: Improve Direct Buffering of Characters Reviewed-by: alanb, ahgross, rhalade, psandoz ! src/java.base/share/classes/java/nio/Buffer.java ! src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template ! src/java.base/share/classes/java/nio/X-Buffer.java.template Changeset: 62eab505 Author: Weijun Wang Committer: Henry Jen Date: 2020-10-23 13:00:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/62eab505 8255199: Catching a few NumberFormatExceptions in xmldsig Reviewed-by: rhalade ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java ! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java Changeset: ede1beae Author: Thomas Schatzl Date: 2021-01-21 18:21:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ede1beae 8227695: assert(pss->trim_ticks().seconds() == 0.0) failed: Unexpected partial trimming during evacuation Change FP comparison to integer comparison. Reviewed-by: kbarrett, iwalulya, eosterlund ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp Changeset: d90e06af Author: Jie Fu Date: 2021-01-22 00:13:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d90e06af 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation Reviewed-by: rbackman, neliasso, kvn ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86.ad + test/hotspot/jtreg/compiler/vectorapi/VectorReinterpretTest.java Changeset: 685c03dc Author: Kim Barrett Date: 2021-01-22 11:20:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/685c03dc 8259271: gc/parallel/TestDynShrinkHeap.java still fails "assert(covered_region.contains(new_memregion)) failed: new region is not in covered_region" Use load_acquire to order reads of top and end. Reviewed-by: tschatzl, iwalulya, eosterlund ! src/hotspot/share/gc/parallel/mutableSpace.cpp Changeset: 6f2a3943 Author: Jesper Wilhelmsson Date: 2021-01-23 03:15:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6f2a3943 Merge ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/java.base/share/classes/java/nio/X-Buffer.java.template ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/java.base/share/classes/java/nio/X-Buffer.java.template Changeset: 5cdcce1c Author: Ioi Lam Date: 2021-01-23 06:24:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5cdcce1c 8260307: Do not include method.hpp in frame.hpp Reviewed-by: lfoltan, coleenp ! src/hotspot/cpu/arm/interp_masm_arm.hpp ! src/hotspot/cpu/x86/interp_masm_x86.hpp ! src/hotspot/share/ci/ciInstanceKlass.hpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/classfile/resolutionErrors.cpp ! src/hotspot/share/code/compiledMethod.hpp ! src/hotspot/share/compiler/methodMatcher.cpp ! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp ! src/hotspot/share/interpreter/abstractInterpreter.hpp ! src/hotspot/share/jvmci/jvmci_globals.cpp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/memory/metaspace/printMetaspaceInfoKlassClosure.cpp ! src/hotspot/share/memory/metaspaceCounters.cpp ! src/hotspot/share/oops/methodCounters.cpp ! src/hotspot/share/prims/jvmtiExport.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/deoptimization.hpp ! src/hotspot/share/runtime/frame.hpp ! src/hotspot/share/runtime/handles.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: f624dba6 Author: Alexey Ivanov Date: 2021-01-23 11:38:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f624dba6 8240247: No longer need to wrap files with contentContainer Reviewed-by: serb ! src/java.desktop/share/classes/java/awt/doc-files/AWTThreadIssues.html ! src/java.desktop/share/classes/java/awt/doc-files/DesktopProperties.html ! src/java.desktop/share/classes/java/awt/doc-files/FocusSpec.html ! src/java.desktop/share/classes/java/awt/doc-files/Modality.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/bmp_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/jpeg_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/png_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/standard_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/wbmp_metadata.html ! src/java.desktop/share/classes/javax/swing/plaf/multi/doc-files/multi_tsc.html ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html ! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html ! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html Changeset: b53d5cac Author: Alexey Ivanov Date: 2021-01-23 17:03:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b53d5cac 8260315: Typo "focul" instead of "focus" in FocusSpec.html Reviewed-by: kizune, pbansal ! src/java.desktop/share/classes/java/awt/doc-files/FocusSpec.html Changeset: 6c4c96fa Author: Kim Barrett Date: 2021-01-23 19:47:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6c4c96fa 8258742: Move PtrQueue reset to PtrQueueSet subclasses Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/g1/g1BarrierSet.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/shared/ptrQueue.cpp ! src/hotspot/share/gc/shared/ptrQueue.hpp ! src/hotspot/share/gc/shared/satbMarkQueue.cpp ! src/hotspot/share/gc/shared/satbMarkQueue.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp Changeset: 06348dfc Author: Kim Barrett Date: 2021-01-23 22:47:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/06348dfc 8259776: Remove ParallelGC non-CAS oldgen allocation Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp ! src/hotspot/share/gc/parallel/mutableNUMASpace.hpp ! src/hotspot/share/gc/parallel/mutableSpace.cpp ! src/hotspot/share/gc/parallel/mutableSpace.hpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/parallel/psOldGen.cpp ! src/hotspot/share/gc/parallel/psOldGen.hpp ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp ! src/hotspot/share/gc/parallel/psYoungGen.hpp Changeset: 535c2927 Author: Ioi Lam Date: 2021-01-24 02:40:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/535c2927 8260306: Do not include osThread.hpp in thread.hpp Reviewed-by: coleenp, lfoltan ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.inline.hpp ! src/hotspot/share/interpreter/bytecodeTracer.cpp ! src/hotspot/share/jfr/support/jfrThreadId.hpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/objectMonitor.inline.hpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/osThread.hpp ! src/hotspot/share/runtime/safepointMechanism.cpp ! src/hotspot/share/runtime/semaphore.inline.hpp ! src/hotspot/share/runtime/stackWatermark.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/vframe.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/vmError.cpp Changeset: c52c6c66 Author: Hamlin Li Date: 2021-01-25 01:05:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c52c6c66 8260273: DataOutputStream writeChars optimization Reviewed-by: rriggs, bpb, alanb ! src/java.base/share/classes/java/io/DataOutputStream.java ! test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java Changeset: 4ae39b14 Author: Hamlin Li Date: 2021-01-25 01:06:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ae39b14 8260208: Improve dummy object filling condition in G1CollectedHeap::fill_archive_regions in cds Reviewed-by: tschatzl, iklam ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp Changeset: 764111ff Author: Dongbo He Committer: Fei Yang Date: 2021-01-25 01:08:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/764111ff 8260272: bash configure --prefix does not work after JDK-8257679 Reviewed-by: erikj, ihse ! make/autoconf/util_paths.m4 Changeset: 5898ab65 Author: Ioi Lam Date: 2021-01-25 08:00:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5898ab65 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h Reviewed-by: dholmes, coleenp ! src/hotspot/os/windows/os_perf_windows.cpp ! src/hotspot/share/ci/ciFlags.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/include/jvm.h + src/hotspot/share/include/jvm_constants.h + src/hotspot/share/include/jvm_io.h ! src/hotspot/share/logging/logSelection.cpp ! src/hotspot/share/prims/stackwalk.hpp ! src/hotspot/share/runtime/abstract_vm_version.cpp ! src/hotspot/share/runtime/flags/jvmFlag.cpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/utilities/accessFlags.hpp ! src/hotspot/share/utilities/constantTag.hpp ! src/hotspot/share/utilities/formatBuffer.hpp ! test/hotspot/gtest/logging/test_gcTraceTime.cpp ! test/hotspot/gtest/logging/test_logStream.cpp Changeset: d825339d Author: Thomas Schatzl Date: 2021-01-25 08:38:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d825339d 8260263: Remove PtrQueue::_qset Remove dead code related to PtrQueue::_qset and itself. Reviewed-by: kbarrett, sjohanss ! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp ! src/hotspot/share/gc/shared/ptrQueue.cpp ! src/hotspot/share/gc/shared/ptrQueue.hpp ! src/hotspot/share/gc/shared/satbMarkQueue.hpp Changeset: af155fc0 Author: Severin Gehwolf Date: 2021-01-25 08:57:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/af155fc0 8258836: JNI local refs exceed capacity getDiagnosticCommandInfo Reviewed-by: cjplummer, shade ! src/jdk.management/share/native/libmanagement_ext/DiagnosticCommandImpl.c + test/jdk/com/sun/management/DiagnosticCommandMBean/DcmdMBeanTestCheckJni.java Changeset: 09489e28 Author: Yasumasa Suenaga Date: 2021-01-25 09:12:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/09489e28 8260338: Some fields in HaltNode is not cloned Reviewed-by: xliu, neliasso, thartmann ! src/hotspot/share/opto/rootnode.cpp ! src/hotspot/share/opto/rootnode.hpp Changeset: ca20c63c Author: Thomas Stuefe Date: 2021-01-25 10:50:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ca20c63c 8259710: Inlining trace leaks memory Reviewed-by: thartmann, neliasso ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp Changeset: 6e037354 Author: Coleen Phillimore Date: 2021-01-25 13:40:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6e037354 8259845: Move placeholder implementation details to cpp file and add logging Reviewed-by: iklam, lfoltan, dholmes ! src/hotspot/share/classfile/placeholders.cpp ! src/hotspot/share/classfile/placeholders.hpp ! src/hotspot/share/logging/logTag.hpp Changeset: d076977d Author: Eric Caspole Date: 2021-01-25 14:11:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d076977d 8260169: LogCompilation: Unexpected method mismatch Reviewed-by: kvn, vlivanov ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/LogParser.java ! src/utils/LogCompilation/src/test/java/com/sun/hotspot/tools/compiler/TestLogCompilation.java Changeset: ef247ab2 Author: Dan Lutker Committer: Igor Ignatyev Date: 2021-01-25 17:16:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ef247ab2 8260308: Update LogCompilation junit to 4.13.1 Reviewed-by: ecaspole, iignatyev ! src/utils/LogCompilation/pom.xml Changeset: 47c7dc77 Author: Martin Balao Date: 2021-01-25 18:01:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/47c7dc77 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures Reviewed-by: valeriep ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PSSSignature.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Signature.java + test/jdk/sun/security/pkcs11/Cipher/CancelMultipart.java Changeset: 5b0b24b5 Author: Daniel D. Daugherty Date: 2021-01-25 18:20:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5b0b24b5 8260381: ProblemList com/sun/management/DiagnosticCommandMBean/DcmdMBeanTestCheckJni.java on Win with ZGC Reviewed-by: sspitsyn, sgehwolf ! test/jdk/ProblemList-zgc.txt Changeset: 73c78c8a Author: Joe Darcy Date: 2021-01-25 19:06:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/73c78c8a 8260329: Update references to TAOCP to latest edition Reviewed-by: alanb, bpb ! src/java.base/share/classes/java/math/MutableBigInteger.java ! src/java.base/share/classes/java/util/Random.java Changeset: 12ccd211 Author: Andrew Leonard Date: 2021-01-25 19:26:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/12ccd211 8260289: Unable to customize module lists after change JDK-8258411 Reviewed-by: ihse, alanb ! make/common/Modules.gmk Changeset: d6fb9d72 Author: Jonathan Gibbons Date: 2021-01-25 21:44:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d6fb9d72 8255464: Cannot access ModuleTree in a CompilationUnitTree Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/source/tree/CompilationUnitTree.java ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java + test/langtools/tools/javac/tree/CompilationUnitTreeTest.java Changeset: 982e42b8 Author: Jonathan Gibbons Date: 2021-01-25 21:45:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/982e42b8 8259726: Use of HashSet leads to undefined order in test output Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Table.java ! test/langtools/jdk/javadoc/doclet/testAbstractMethod/TestAbstractMethod.java ! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java ! test/langtools/jdk/javadoc/doclet/testHtmlTableTags/TestHtmlTableTags.java ! test/langtools/jdk/javadoc/doclet/testInterface/TestInterface.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java ! test/langtools/jdk/javadoc/doclet/testLambdaFeature/TestLambdaFeature.java ! test/langtools/jdk/javadoc/doclet/testMemberInheritance/TestMemberInheritance.java ! test/langtools/jdk/javadoc/doclet/testMemberSummary/TestMemberSummary.java ! test/langtools/jdk/javadoc/doclet/testMethodTypes/TestMethodTypes.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModulePackages.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java ! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverrideMethods.java ! test/langtools/jdk/javadoc/doclet/testProperty/TestProperty.java ! test/langtools/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java ! test/langtools/jdk/javadoc/doclet/testTypeParams/TestTypeParameters.java ! test/langtools/jdk/javadoc/doclet/testUnnamedPackage/TestUnnamedPackage.java Changeset: 9ea93238 Author: Coleen Phillimore Date: 2021-01-25 23:58:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ea93238 8254246: SymbolHashMapEntry wastes space Reviewed-by: redestad ! src/hotspot/share/oops/constantPool.hpp Changeset: c538cd8b Author: Serguei Spitsyn Date: 2021-01-26 07:15:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c538cd8b 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs Reviewed-by: mchung, dholmes, alanb ! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java + test/jdk/java/lang/instrument/NegativeAgentRunner.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0001.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0010.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0011.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0100.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0101.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0110.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0111.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1000.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1001.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1010.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1011.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1100.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1101.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1110.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1111.java ! test/jdk/java/lang/instrument/PremainClass/NoPremainAgent.java - test/jdk/java/lang/instrument/PremainClass/NoPremainAgentTest.java + test/jdk/java/lang/instrument/PremainClass/NonPublicAgent.java + test/jdk/java/lang/instrument/PremainClass/NonPublicPremainAgent.java ! test/jdk/java/lang/instrument/PremainClass/ZeroArgPremainAgent.java - test/jdk/java/lang/instrument/PremainClass/ZeroArgPremainAgentTest.java Changeset: abd9310b Author: Matthias Baesken Date: 2021-01-26 07:42:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/abd9310b 8260222: remove unused _thread member SymbolTableLookup Reviewed-by: coleenp, dholmes, shade ! src/hotspot/share/classfile/symbolTable.cpp Changeset: 23edb6f6 Author: Guoxiong Li Committer: Joel Borggr?n-Franck Date: 2021-01-26 08:57:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/23edb6f6 8236490: Compiler bug relating to @NonNull annotation Reviewed-by: vromero, jfranck ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java + test/langtools/tools/javac/annotations/typeAnnotations/8236490/T8236490.java Changeset: b4ace3e9 Author: Thomas Schatzl Date: 2021-01-26 10:14:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b4ace3e9 8260042: G1 Post-cleanup liveness printing occurs too early Reviewed-by: sjohanss, iwalulya ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1Policy.cpp Changeset: 81a66dfa Author: Coleen Phillimore Date: 2021-01-26 11:50:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81a66dfa 8259809: Remove PerfEvent class loading locking counters Reviewed-by: redestad, iklam ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp Changeset: edd27074 Author: Aleksey Shipilev Date: 2021-01-26 13:04:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/edd27074 8260408: Shenandoah: adjust inline hints after JDK-8255019 Reviewed-by: rkennke, ihse ! make/hotspot/lib/JvmOverrideFiles.gmk Changeset: e080ce92 Author: Harold Seigel Date: 2021-01-26 13:17:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e080ce92 8252545: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java timed out Reviewed-by: stuefe, coleenp ! test/hotspot/jtreg/TEST.groups ! test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java - test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java Changeset: 5e8e0ada Author: Jan Lahoda Date: 2021-01-26 13:42:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5e8e0ada 8242456: PreviewFeature.Feature enum removal of TEXT_BLOCKS Reviewed-by: jlaskey ! src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java Changeset: 8d2f77fd Author: Magnus Ihse Bursie Date: 2021-01-26 14:08:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8d2f77fd 8260406: Do not copy pure java source code to gensrc Reviewed-by: alanb, erikj ! make/modules/java.base/gensrc/GensrcCharacterData.gmk = src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java = src/java.base/share/classes/java/lang/CharacterDataUndefined.java Changeset: af8a08f5 Author: Severin Gehwolf Date: 2021-01-26 15:18:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/af8a08f5 8260378: [TESTBUG] DcmdMBeanTestCheckJni.java reports false positive Reviewed-by: dcubed ! test/jdk/ProblemList-zgc.txt ! test/jdk/com/sun/management/DiagnosticCommandMBean/DcmdMBeanTestCheckJni.java Changeset: b07797c2 Author: Claes Redestad Date: 2021-01-26 15:25:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b07797c2 8260391: Remove StringCoding::err Reviewed-by: shade, rriggs ! src/java.base/share/classes/java/lang/StringCoding.java - src/java.base/share/native/libjava/StringCoding.c Changeset: fd00ed74 Author: Zhengyu Gu Date: 2021-01-26 16:46:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fd00ed74 8256298: Shenandoah: Enable concurrent stack processing Reviewed-by: rkennke, shade ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp ! src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp ! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp + src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.cpp + src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.hpp ! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp Changeset: 9f0a0436 Author: Fernando Guallini Committer: Rajan Halade Date: 2021-01-26 18:15:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f0a0436 8260286: Manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails Reviewed-by: rhalade ! test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java ! test/jdk/sun/security/tools/jarsigner/warnings/Test.java Changeset: 42cef27f Author: Sergey Bylokhov Date: 2021-01-26 18:31:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/42cef27f 8260343: Delete obsolete classes in the Windows L&F Reviewed-by: aivanov, pbansal - src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsButtonListener.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java Changeset: 1bebd418 Author: Zhengyu Gu Date: 2021-01-26 20:25:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1bebd418 8260421: Shenandoah: Fix conc_mark_roots timing name and indentations Reviewed-by: rkennke, shade ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Changeset: 19b6f61b Author: Xin Liu Committer: Paul Hohensee Date: 2021-01-26 20:52:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/19b6f61b 8260334: Remove deprecated sv_for_node_id() from Compile Reviewed-by: neliasso, chagedorn, thartmann, phh ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/output.hpp Changeset: 6f2be9c6 Author: David Holmes Date: 2021-01-27 01:18:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6f2be9c6 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC Reviewed-by: ihse, erikj, gziemski, hseigel ! make/autoconf/flags-cflags.m4 ! make/autoconf/flags-ldflags.m4 ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/aix/os_aix.inline.hpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/bsd/os_bsd.hpp ! src/hotspot/os/bsd/os_bsd.inline.hpp ! src/hotspot/os/bsd/os_perf_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/linux/os_linux.inline.hpp ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/posix/os_posix.hpp ! src/hotspot/os/posix/os_posix.inline.hpp ! src/hotspot/os/windows/os_windows.inline.hpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/runtime/thread.cpp Changeset: e1411fd4 Author: Sergey Bylokhov Date: 2021-01-27 02:52:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e1411fd4 6606673: Path2D.Double, Path2D.Float and GeneralPath ctors throw exception when initialCapacity is negative Reviewed-by: psadhukhan, kizune ! src/java.desktop/share/classes/java/awt/geom/GeneralPath.java ! src/java.desktop/share/classes/java/awt/geom/Path2D.java + test/jdk/java/awt/geom/GeneralPath/GeneralPathExceptions.java + test/jdk/java/awt/geom/Path2D/Path2DExceptions.java Changeset: c836da38 Author: Martin Buchholz Date: 2021-01-27 04:31:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c836da38 8252412: [macos11] system dynamic libraries removed from filesystem Co-authored-by: Dominik R?ttsches Reviewed-by: jiangli, valeriep ! src/java.smartcardio/unix/classes/sun/security/smartcardio/PlatformPCSC.java Changeset: bd2744dd Author: Aleksey Shipilev Date: 2021-01-27 07:17:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bd2744dd 8260106: Shenandoah: refactor reference updating closures and related code Reviewed-by: zgu, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMark.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.hpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp Changeset: 1c770468 Author: Thomas Stuefe Date: 2021-01-27 07:34:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1c770468 8260404: jvm_io.h include missing in a number of files Reviewed-by: shade, iklam, dholmes ! src/hotspot/os/posix/perfMemory_posix.cpp ! src/hotspot/share/aot/aotCodeHeap.cpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/jfr/jni/jfrUpcalls.cpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleDescription.cpp ! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/hotspot/share/jvmci/jvmciRuntime.hpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/runtime/handshake.cpp Changeset: fd2641ed Author: Matthias Baesken Date: 2021-01-27 07:57:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fd2641ed 8260236: better init AnnotationCollector _contended_group Reviewed-by: coleenp, shade ! src/hotspot/share/classfile/classFileParser.cpp Changeset: 4d004c94 Author: Roman Kennke Date: 2021-01-27 09:32:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d004c94 8260449: Remove stale declaration of SATBMarkQueue::apply_closure_and_empty() Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/satbMarkQueue.hpp Changeset: fa40a966 Author: Albert Mingkun Yang Committer: Stefan Johansson Date: 2021-01-27 09:57:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fa40a966 8253420: Refactor HeapRegionManager::find_highest_free Reviewed-by: sjohanss, kbarrett ! src/hotspot/share/gc/g1/heapRegionManager.cpp Changeset: 3e4194c4 Author: Thomas Stuefe Date: 2021-01-27 10:43:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3e4194c4 8260022: [ppc] os::print_function_and_library_name shall resolve function descriptors transparently Reviewed-by: mdoerr, lucy ! src/hotspot/cpu/ppc/assembler_ppc.hpp ! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp ! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.hpp ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.hpp ! src/hotspot/share/runtime/os.cpp Changeset: bf15c709 Author: Aleksey Shipilev Date: 2021-01-27 10:48:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bf15c709 8260460: GitHub actions still fail on Linux x86_32 with "Could not configure libc6:i386" Reviewed-by: ihse ! .github/workflows/submit.yml Changeset: b3c8a528 Author: Jan Lahoda Date: 2021-01-27 11:00:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b3c8a528 8259050: Error recovery in lexer could be improved Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java ! test/langtools/tools/javac/lexer/JavaLexerTest.java ! test/langtools/tools/javac/parser/JavacParserTest.java Changeset: e696baab Author: Claes Redestad Date: 2021-01-27 11:30:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e696baab 8260448: Simplify ManagementFactory$PlatformMBeanFinder Reviewed-by: mchung, dfuchs ! src/java.management/share/classes/java/lang/management/ManagementFactory.java Changeset: 7ed591cc Author: Alexey Ivanov Date: 2021-01-27 12:09:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7ed591cc 8260314: Replace border="1" on tables with CSS Reviewed-by: serb ! src/java.desktop/share/classes/java/awt/doc-files/DesktopProperties.html ! src/java.desktop/share/classes/java/awt/doc-files/Modality.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html ! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html ! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html Changeset: ac276bb3 Author: Chris Hegarty Date: 2021-01-27 14:09:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ac276bb3 8257074: Update the ByteBuffers micro benchmark Reviewed-by: redestad, dfuchs, jvernee, bpb ! test/micro/org/openjdk/bench/java/nio/ByteBuffers.java ! test/micro/org/openjdk/bench/java/nio/CharBuffers.java + test/micro/org/openjdk/bench/java/nio/DoubleBuffers.java + test/micro/org/openjdk/bench/java/nio/FloatBuffers.java + test/micro/org/openjdk/bench/java/nio/IntBuffers.java + test/micro/org/openjdk/bench/java/nio/LongBuffers.java + test/micro/org/openjdk/bench/java/nio/ShortBuffers.java + test/micro/org/openjdk/bench/java/nio/X-Buffers-bin.java.template + test/micro/org/openjdk/bench/java/nio/X-Buffers.java.template + test/micro/org/openjdk/bench/java/nio/X-ByteBuffers-bin.java.template + test/micro/org/openjdk/bench/java/nio/genBuffers.sh Changeset: f353fcf2 Author: Roberto Casta?eda Lozano Committer: Tobias Hartmann Date: 2021-01-27 15:08:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f353fcf2 8258894: C2: Forbid GCM to move stores into loops Prevent GCM from placing memory-writing nodes (such as stores) into loops deeper than their home loop (determined by their control input). Such placements are invalid, as they cause memory definitions to interfere, and risk causing miscompilations. This change complements JDK-8255763, which only addresses invalid placements in irreducible CFGs. Add control input to stores in generated stubs to ensure that all memory-writing nodes have control inputs from which their home block can be derived. Add a battery of simplified fuzzer test cases where, before this change, GCM moves stores into deeper loops. Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/block.cpp ! src/hotspot/share/opto/block.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/gcm.cpp ! src/hotspot/share/opto/generateOptoStub.cpp ! src/hotspot/share/opto/node.hpp ! test/hotspot/jtreg/compiler/codegen/TestGCMStorePlacement.java Changeset: 311a0a91 Author: Denghui Dong Committer: Thomas Schatzl Date: 2021-01-27 15:28:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/311a0a91 8259808: Add JFR event to detect GC locker stall Reviewed-by: sjohanss, tschatzl, egahlin ! src/hotspot/share/gc/shared/gcLocker.cpp ! src/hotspot/share/gc/shared/gcTrace.hpp ! src/hotspot/share/gc/shared/gcTraceSend.cpp ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/prims/whitebox.cpp ! src/jdk.jfr/share/conf/jfr/default.jfc ! src/jdk.jfr/share/conf/jfr/profile.jfc + test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java ! test/lib/jdk/test/lib/jfr/EventNames.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: 684c8558 Author: Daniel D. Daugherty Date: 2021-01-27 17:26:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/684c8558 8260524: validate-source fails on test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java Reviewed-by: bpb, iignatyev ! src/hotspot/share/gc/shared/gcLocker.cpp ! src/hotspot/share/gc/shared/gcTrace.hpp ! src/hotspot/share/gc/shared/gcTraceSend.cpp ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/prims/whitebox.cpp ! test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java ! test/lib/jdk/test/lib/jfr/EventNames.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: 0eed2c33 Author: Guoxiong Li Committer: Vicente Romero Date: 2021-01-27 18:12:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0eed2c33 8259359: javac does not attribute unexpected super constructor invocation qualifier, and may crash Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java + test/langtools/tools/javac/recovery/T8259359.java Changeset: eb923685 Author: Stuart Marks Date: 2021-01-27 19:02:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eb923685 8259816: Typo in java.util.stream package description Reviewed-by: iris, lancea, naoto ! src/java.base/share/classes/java/util/stream/package-info.java Changeset: c5ab7c32 Author: Christian Hagedorn Date: 2021-01-25 17:09:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c5ab7c32 8260284: C2: assert(_base == Int) failed: Not an Int Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/phaseX.cpp + test/hotspot/jtreg/compiler/loopopts/TestDivWithTopDivisor.java Changeset: 81e730e5 Author: Vladimir Ivanov Date: 2021-01-25 20:02:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81e730e5 8259276: C2: Empty expression stack when reexecuting tableswitch/lookupswitch instructions after deoptimization Reviewed-by: dlong, kvn, thartmann ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/parse2.cpp Changeset: 408772c9 Author: Vicente Romero Date: 2021-01-26 16:00:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/408772c9 8259025: Record compact constructor using Objects.requireNonNull Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/langtools/tools/javac/records/RecordCompilationTests.java Changeset: c52212b1 Author: Jesper Wilhelmsson Date: 2021-01-27 20:56:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c52212b1 Merge ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/phaseX.cpp Changeset: c7661aed Author: Roger Riggs Date: 2021-01-27 22:37:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c7661aed 8260561: [doc] HexFormat has incorrect @since tag Reviewed-by: darcy, naoto, bpb, lancea ! src/java.base/share/classes/java/util/HexFormat.java Changeset: 7030d2e0 Author: Hamlin Li Date: 2021-01-28 00:45:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7030d2e0 8260200: G1: Remove unnecessary update in FreeRegionList::remove_starting_at Reviewed-by: ayang, sjohanss, tschatzl ! src/hotspot/share/gc/g1/heapRegionSet.cpp ! src/hotspot/share/gc/g1/heapRegionSet.hpp Changeset: e28e1111 Author: Vladimir Ivanov Date: 2021-01-27 10:29:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e28e1111 8260370: C2: LoopLimit node is not eliminated Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/loopnode.cpp Changeset: 62ffe75b Author: Jesper Wilhelmsson Date: 2021-01-28 03:38:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/62ffe75b Merge ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/loopnode.cpp Changeset: 396a496f Author: Ioi Lam Date: 2021-01-28 04:24:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/396a496f 8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp Reviewed-by: dholmes, coleenp ! src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp ! src/hotspot/cpu/aarch64/methodHandles_aarch64.hpp ! src/hotspot/cpu/arm/methodHandles_arm.cpp ! src/hotspot/cpu/arm/methodHandles_arm.hpp ! src/hotspot/cpu/ppc/methodHandles_ppc.cpp ! src/hotspot/cpu/ppc/methodHandles_ppc.hpp ! src/hotspot/cpu/s390/methodHandles_s390.cpp ! src/hotspot/cpu/s390/methodHandles_s390.hpp ! src/hotspot/cpu/x86/methodHandles_x86.cpp ! src/hotspot/cpu/x86/methodHandles_x86.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciObjArrayKlass.cpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp + src/hotspot/share/classfile/vmClassID.hpp + src/hotspot/share/classfile/vmClassMacros.hpp + src/hotspot/share/classfile/vmClasses.cpp + src/hotspot/share/classfile/vmClasses.hpp ! src/hotspot/share/memory/archiveBuilder.cpp ! src/hotspot/share/memory/archiveBuilder.hpp ! src/hotspot/share/memory/filemap.cpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/vmEnums.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbPrintStatics.java Changeset: 11a70d11 Author: Matthias Baesken Date: 2021-01-28 07:35:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/11a70d11 8260426: awt debug_mem.c DMem_AllocateBlock might leak memory Reviewed-by: psadhukhan, aivanov ! src/java.desktop/share/native/common/awt/debug/debug_mem.c Changeset: 316d52c1 Author: Roman Kennke Date: 2021-01-28 09:50:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/316d52c1 8260497: Shenandoah: Improve SATB flushing Reviewed-by: shade, zgu ! src/hotspot/share/gc/shared/satbMarkQueue.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Changeset: a97aedff Author: Aleksey Shipilev Date: 2021-01-28 10:24:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a97aedff 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code Reviewed-by: rkennke, zgu ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp Changeset: ecde52ec Author: Claes Redestad Date: 2021-01-28 11:13:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ecde52ec 8260506: VersionHelper cleanup Reviewed-by: alanb, dfuchs, aefimov ! src/java.naming/share/classes/com/sun/naming/internal/VersionHelper.java Changeset: 8fe1323d Author: Claes Redestad Date: 2021-01-28 11:14:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8fe1323d 8260520: Avoid getting permissions in JarFileFactory when no SecurityManager installed Reviewed-by: alanb, dfuchs, michaelm, mullan ! src/java.base/unix/classes/sun/net/www/protocol/jar/JarFileFactory.java ! src/java.base/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java Changeset: 87522573 Author: Martin Doerr Date: 2021-01-28 11:39:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/87522573 8260502: [s390] NativeMovRegMem::verify() fails because it's too strict Reviewed-by: lucy, rrich ! src/hotspot/cpu/s390/nativeInst_s390.cpp ! src/hotspot/cpu/s390/nativeInst_s390.hpp Changeset: a68c6c2a Author: Aleksey Shipilev Date: 2021-01-28 12:00:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a68c6c2a 8260579: PPC64 and S390 builds failures after JDK-8260467 Reviewed-by: mdoerr ! src/hotspot/cpu/ppc/methodHandles_ppc.cpp ! src/hotspot/cpu/s390/methodHandles_s390.cpp Changeset: d07af2b8 Author: Jorn Vernee Date: 2021-01-28 12:26:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d07af2b8 8255531: MethodHandles::permuteArguments throws NPE when duplicating dropped arguments Reviewed-by: redestad ! src/java.base/share/classes/java/lang/invoke/LambdaFormBuffer.java ! test/jdk/java/lang/invoke/MethodHandlesPermuteArgumentsTest.java Changeset: 11d6467c Author: Roland Westrelin Date: 2021-01-28 12:27:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/11d6467c 8260407: cmp != __null && cmp->Opcode() == Op_CmpL failure with -XX:StressLongCountedLoop=200000000 in lucene Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/loopopts.cpp + test/hotspot/jtreg/compiler/longcountedloops/TestLongCountedLoopSplitIf.java Changeset: 20e7df50 Author: Harold Seigel Date: 2021-01-28 13:17:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/20e7df50 8260466: Test TestHeapDumpOnOutOfMemoryError.java needs multiple @test sections Reviewed-by: shade, lmesnik ! test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java Changeset: baf46bac Author: Sean Mullan Date: 2021-01-28 14:28:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/baf46bac 8259801: Enable XML Signature secure validation mode by default Reviewed-by: weijun, rhalade ! src/java.base/share/conf/security/java.security ! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/dom/DOMValidateContext.java ! test/jdk/javax/xml/crypto/dsig/GenerationTests.java Changeset: 13ca433f Author: Patrick Concannon Date: 2021-01-28 15:01:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/13ca433f 8259628: jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java fails intermittently Reviewed-by: dfuchs ! test/jdk/jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java Changeset: abc4300d Author: Poonam Bajaj Date: 2021-01-28 15:07:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/abc4300d 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines Reviewed-by: hseigel ! src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java Changeset: 3aabbd72 Author: Matthias Baesken Date: 2021-01-28 15:20:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3aabbd72 8260432: allocateSpaceForGP in freetypeScaler.c might leak memory Reviewed-by: shade, stuefe ! src/java.desktop/share/native/libfontmanager/freetypeScaler.c Changeset: bbbfaa58 Author: Calvin Cheung Date: 2021-01-28 16:17:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bbbfaa58 8249262: Initialize InstanceKlass::_package_entry during CDS dump time Reviewed-by: iklam, minqi ! src/hotspot/share/classfile/classLoaderDataShared.cpp ! src/hotspot/share/classfile/classLoaderDataShared.hpp ! src/hotspot/share/classfile/packageEntry.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/oops/instanceKlass.cpp Changeset: 1de3c554 Author: Aleksey Shipilev Date: 2021-01-28 16:31:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1de3c554 8260584: Shenandoah: simplify "Concurrent Thread Roots" logging Reviewed-by: rkennke, zgu ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Changeset: 2b166d81 Author: Weijun Wang Date: 2021-01-28 17:54:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2b166d81 8260596: Comment cleanup in BigInteger Reviewed-by: bpb ! src/java.base/share/classes/java/math/BigInteger.java Changeset: 81e9e6a7 Author: Martin Buchholz Date: 2021-01-28 18:06:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81e9e6a7 8260461: Modernize jsr166 tck tests Reviewed-by: dl ! test/jdk/java/util/concurrent/tck/AbstractExecutorServiceTest.java ! test/jdk/java/util/concurrent/tck/AbstractQueueTest.java ! test/jdk/java/util/concurrent/tck/ArrayBlockingQueueTest.java ! test/jdk/java/util/concurrent/tck/ArrayDeque8Test.java ! test/jdk/java/util/concurrent/tck/ArrayDequeTest.java ! test/jdk/java/util/concurrent/tck/ArrayListTest.java ! test/jdk/java/util/concurrent/tck/Atomic8Test.java ! test/jdk/java/util/concurrent/tck/AtomicBooleanTest.java ! test/jdk/java/util/concurrent/tck/AtomicIntegerArrayTest.java ! test/jdk/java/util/concurrent/tck/AtomicIntegerTest.java ! test/jdk/java/util/concurrent/tck/AtomicLongArrayTest.java ! test/jdk/java/util/concurrent/tck/AtomicLongTest.java ! test/jdk/java/util/concurrent/tck/AtomicMarkableReferenceTest.java ! test/jdk/java/util/concurrent/tck/AtomicReference9Test.java ! test/jdk/java/util/concurrent/tck/AtomicReferenceArray9Test.java ! test/jdk/java/util/concurrent/tck/AtomicReferenceArrayTest.java ! test/jdk/java/util/concurrent/tck/AtomicReferenceFieldUpdaterTest.java ! test/jdk/java/util/concurrent/tck/AtomicReferenceTest.java ! test/jdk/java/util/concurrent/tck/AtomicStampedReferenceTest.java ! test/jdk/java/util/concurrent/tck/BlockingQueueTest.java ! test/jdk/java/util/concurrent/tck/Collection8Test.java ! test/jdk/java/util/concurrent/tck/CompletableFutureTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentHashMap8Test.java ! test/jdk/java/util/concurrent/tck/ConcurrentHashMapTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentLinkedDequeTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentLinkedQueueTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentSkipListMapTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentSkipListSetTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentSkipListSubMapTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentSkipListSubSetTest.java ! test/jdk/java/util/concurrent/tck/CopyOnWriteArrayListTest.java ! test/jdk/java/util/concurrent/tck/CopyOnWriteArraySetTest.java ! test/jdk/java/util/concurrent/tck/CountedCompleterTest.java ! test/jdk/java/util/concurrent/tck/DelayQueueTest.java ! test/jdk/java/util/concurrent/tck/ExchangerTest.java ! test/jdk/java/util/concurrent/tck/ExecutorCompletionService9Test.java ! test/jdk/java/util/concurrent/tck/ExecutorCompletionServiceTest.java ! test/jdk/java/util/concurrent/tck/ExecutorsTest.java ! test/jdk/java/util/concurrent/tck/ForkJoinPool8Test.java ! test/jdk/java/util/concurrent/tck/ForkJoinPoolTest.java ! test/jdk/java/util/concurrent/tck/ForkJoinTask8Test.java ! test/jdk/java/util/concurrent/tck/ForkJoinTaskTest.java ! test/jdk/java/util/concurrent/tck/FutureTaskTest.java + test/jdk/java/util/concurrent/tck/Item.java ! test/jdk/java/util/concurrent/tck/JSR166TestCase.java ! test/jdk/java/util/concurrent/tck/LinkedBlockingDeque8Test.java ! test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java ! test/jdk/java/util/concurrent/tck/LinkedBlockingQueue8Test.java ! test/jdk/java/util/concurrent/tck/LinkedBlockingQueueTest.java ! test/jdk/java/util/concurrent/tck/LinkedListTest.java ! test/jdk/java/util/concurrent/tck/LinkedTransferQueueTest.java ! test/jdk/java/util/concurrent/tck/MapTest.java ! test/jdk/java/util/concurrent/tck/NonNestmates.java ! test/jdk/java/util/concurrent/tck/PhaserTest.java ! test/jdk/java/util/concurrent/tck/PriorityBlockingQueueTest.java ! test/jdk/java/util/concurrent/tck/PriorityQueueTest.java ! test/jdk/java/util/concurrent/tck/RecursiveActionTest.java ! test/jdk/java/util/concurrent/tck/RecursiveTaskTest.java ! test/jdk/java/util/concurrent/tck/ScheduledExecutorSubclassTest.java ! test/jdk/java/util/concurrent/tck/ScheduledExecutorTest.java ! test/jdk/java/util/concurrent/tck/StampedLockTest.java ! test/jdk/java/util/concurrent/tck/SubmissionPublisherTest.java ! test/jdk/java/util/concurrent/tck/SynchronousQueueTest.java ! test/jdk/java/util/concurrent/tck/ThreadLocalTest.java ! test/jdk/java/util/concurrent/tck/ThreadPoolExecutorSubclassTest.java ! test/jdk/java/util/concurrent/tck/ThreadPoolExecutorTest.java ! test/jdk/java/util/concurrent/tck/TreeMapTest.java ! test/jdk/java/util/concurrent/tck/TreeSetTest.java ! test/jdk/java/util/concurrent/tck/TreeSubMapTest.java ! test/jdk/java/util/concurrent/tck/TreeSubSetTest.java ! test/jdk/java/util/concurrent/tck/VectorTest.java Changeset: 71128cf4 Author: Aleksey Shipilev Date: 2021-01-28 19:04:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/71128cf4 8260586: Shenandoah: simplify "Concurrent Weak References" logging Reviewed-by: rkennke, zgu ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Changeset: 15196325 Author: Igor Veresov Date: 2021-01-28 20:51:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/15196325 8251462: Simplify compilation policy Reviewed-by: cjplummer, kvn ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_globals_aarch64.hpp ! src/hotspot/cpu/aarch64/c2_globals_aarch64.hpp ! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp ! src/hotspot/cpu/aarch64/globals_aarch64.hpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/arm/globals_arm.hpp ! src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/ppc/c1_globals_ppc.hpp ! src/hotspot/cpu/ppc/c2_globals_ppc.hpp ! src/hotspot/cpu/ppc/interp_masm_ppc.hpp ! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/s390/c1_globals_s390.hpp ! src/hotspot/cpu/s390/c2_globals_s390.hpp ! src/hotspot/cpu/s390/templateInterpreterGenerator_s390.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp ! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/c1_globals_x86.hpp ! src/hotspot/cpu/x86/c2_globals_x86.hpp ! src/hotspot/cpu/x86/globalDefinitions_x86.hpp ! src/hotspot/cpu/x86/globals_x86.hpp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/zero/globals_zero.hpp ! src/hotspot/share/aot/aotCodeHeap.cpp ! src/hotspot/share/aot/aotCompiledMethod.cpp ! src/hotspot/share/aot/aotCompiledMethod.hpp ! src/hotspot/share/c1/c1_Compilation.cpp ! src/hotspot/share/c1/c1_Compilation.hpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_LIRAssembler.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_Runtime1.cpp ! src/hotspot/share/c1/c1_globals.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/compiler/compilationPolicy.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileTask.cpp ! src/hotspot/share/compiler/compilerDefinitions.cpp ! src/hotspot/share/compiler/compilerDefinitions.hpp ! src/hotspot/share/compiler/compilerDirectives.cpp ! src/hotspot/share/compiler/compiler_globals.hpp ! src/hotspot/share/compiler/oopMap.cpp - src/hotspot/share/compiler/tieredThresholdPolicy.cpp - src/hotspot/share/compiler/tieredThresholdPolicy.hpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/interpreterRuntime.hpp ! src/hotspot/share/interpreter/invocationCounter.cpp ! src/hotspot/share/interpreter/invocationCounter.hpp ! src/hotspot/share/interpreter/templateInterpreterGenerator.hpp ! src/hotspot/share/jvmci/compilerRuntime.cpp ! src/hotspot/share/jvmci/jvmciCompiler.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/oops/methodCounters.cpp ! src/hotspot/share/oops/methodCounters.hpp ! src/hotspot/share/oops/methodData.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/abstract_vm_version.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp ! src/hotspot/share/runtime/globals_shared.hpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/macros.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Method.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodCounters.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodData.java ! test/hotspot/jtreg/TEST.quick-groups ! test/hotspot/jtreg/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java ! test/hotspot/jtreg/compiler/whitebox/ClearMethodStateTest.java ! test/hotspot/jtreg/compiler/whitebox/CompilerWhiteBoxTest.java - test/hotspot/jtreg/vmTestbase/jit/tiered/Test.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/MyThread.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.java Changeset: 251c6419 Author: Kim Barrett Date: 2021-01-29 03:34:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/251c6419 8259487: Remove unused StarTask Reviewed-by: iklam, tschatzl ! src/hotspot/share/gc/shared/taskqueue.hpp Changeset: ea2c4474 Author: Kim Barrett Date: 2021-01-29 03:49:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ea2c4474 8259778: Merge MutableSpace and ImmutableSpace Reviewed-by: sspitsyn, dholmes, tschatzl - src/hotspot/share/gc/parallel/immutableSpace.cpp - src/hotspot/share/gc/parallel/immutableSpace.hpp ! src/hotspot/share/gc/parallel/mutableSpace.cpp ! src/hotspot/share/gc/parallel/mutableSpace.hpp ! src/hotspot/share/gc/parallel/spaceCounters.hpp ! src/hotspot/share/gc/parallel/vmStructs_parallelgc.hpp - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/ImmutableSpace.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/MutableSpace.java Changeset: 64a150c5 Author: Sergey Bylokhov Date: 2021-01-29 06:18:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/64a150c5 6986863: ProfileDeferralMgr throwing ConcurrentModificationException Reviewed-by: kizune ! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java ! src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java - src/java.desktop/share/classes/sun/java2d/cmm/ProfileActivator.java ! src/java.desktop/share/classes/sun/java2d/cmm/ProfileDeferralInfo.java - src/java.desktop/share/classes/sun/java2d/cmm/ProfileDeferralMgr.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/java.desktop/share/native/liblcms/LCMS.c + test/jdk/java/awt/color/ICC_ProfileRGB/MTMatrixAccess.java + test/jdk/java/awt/color/ProfileActivationDuringPropertyAccess.java Changeset: 06754734 Author: Jan Lahoda Date: 2021-01-29 09:19:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/06754734 8252409: JShell: Intersection types cause NoSuchFieldError Reviewed-by: vromero ! src/jdk.jshell/share/classes/jdk/jshell/ExpressionToTypeInfo.java ! src/jdk.jshell/share/classes/jdk/jshell/TreeDissector.java ! src/jdk.jshell/share/classes/jdk/jshell/TypePrinter.java ! test/langtools/jdk/jshell/TypeNameTest.java ! test/langtools/jdk/jshell/VariablesTest.java Changeset: a81656b7 Author: duke Date: 2021-01-29 11:01:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a81656b7 Automatic merge of jdk:master into master Changeset: 95b9ef9d Author: duke Date: 2021-01-29 11:01:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/95b9ef9d Automatic merge of master into foreign-memaccess+abi From duke at openjdk.java.net Fri Jan 29 11:16:13 2021 From: duke at openjdk.java.net (duke) Date: Fri, 29 Jan 2021 11:16:13 GMT Subject: git: openjdk/panama-foreign: master: 117 new changesets Message-ID: <9c33fe37-b229-4661-a4a2-511319b6286c@openjdk.org> Changeset: 58ceb254 Author: Claes Redestad Date: 2021-01-22 11:27:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/58ceb254 8259842: Remove Result cache from StringCoding Reviewed-by: naoto, plevart, rriggs ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/StringCoding.java ! src/java.base/share/classes/java/lang/System.java + test/micro/org/openjdk/bench/java/lang/StringDecode.java + test/micro/org/openjdk/bench/java/lang/StringEncode.java Changeset: bfac3fb5 Author: Aleksey Shipilev Date: 2021-01-22 11:39:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bfac3fb5 8260212: Shenandoah: resolve-only UpdateRefsMode is not used Reviewed-by: rkennke, zgu ! src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.hpp Changeset: 7ed8ba1c Author: Kim Barrett Date: 2021-01-22 13:12:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7ed8ba1c 8256814: WeakProcessorPhases may be redundant Remove WeakProcessorPhase, adding scoped enum categories to OopStorageSet. Reviewed-by: stefank, tschatzl, rkennke ! src/hotspot/share/gc/g1/g1FullGCAdjustTask.hpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp ! src/hotspot/share/gc/g1/g1RootProcessor.cpp ! src/hotspot/share/gc/shared/oopStorageSet.cpp ! src/hotspot/share/gc/shared/oopStorageSet.hpp ! src/hotspot/share/gc/shared/oopStorageSet.inline.hpp ! src/hotspot/share/gc/shared/oopStorageSetParState.hpp ! src/hotspot/share/gc/shared/oopStorageSetParState.inline.hpp ! src/hotspot/share/gc/shared/weakProcessor.cpp ! src/hotspot/share/gc/shared/weakProcessor.hpp ! src/hotspot/share/gc/shared/weakProcessor.inline.hpp - src/hotspot/share/gc/shared/weakProcessorPhase.hpp - src/hotspot/share/gc/shared/weakProcessorPhaseTimes.cpp - src/hotspot/share/gc/shared/weakProcessorPhaseTimes.hpp + src/hotspot/share/gc/shared/weakProcessorTimes.cpp + src/hotspot/share/gc/shared/weakProcessorTimes.hpp ! src/hotspot/share/gc/shenandoah/shenandoahParallelCleaning.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootVerifier.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/rootResolver.cpp ! src/hotspot/share/jfr/leakprofiler/utilities/rootType.cpp ! src/hotspot/share/jfr/leakprofiler/utilities/rootType.hpp ! src/hotspot/share/runtime/serviceThread.cpp ! test/hotspot/gtest/gc/shared/test_oopStorageSet.cpp Changeset: f928265e Author: Harold Seigel Date: 2021-01-22 13:52:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f928265e 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined Reviewed-by: lfoltan, sspitsyn, dholmes ! src/hotspot/share/oops/instanceKlass.cpp + test/hotspot/jtreg/runtime/sealedClasses/RedefinePermittedSubclass.java Changeset: acbcde8c Author: Pankaj Bansal Date: 2021-01-22 13:53:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/acbcde8c 8256111: Create implementation for NSAccessibilityStaticText protocol Reviewed-by: serb, kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonTextAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonTextAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/StaticTextAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/StaticTextAccessibility.m Changeset: 154e1d63 Author: Yasumasa Suenaga Date: 2021-01-22 14:16:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/154e1d63 8259009: G1 heap summary should be shown in "Heap Parameters" window on HSDB Reviewed-by: cjplummer, tschatzl ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1CollectedHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java Changeset: a97f3c18 Author: Kim Barrett Date: 2021-01-22 14:44:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a97f3c18 8258853: Support separate function declaration and definition with ENABLE_IF-based SFINAE Add ENABLE_IF_SDEFN, unit tests Reviewed-by: jrose, eosterlund ! src/hotspot/share/metaprogramming/enableIf.hpp ! test/hotspot/gtest/metaprogramming/test_enableIf.cpp Changeset: 18eb6d9e Author: Sean Coffey Date: 2021-01-22 15:31:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/18eb6d9e 8255348: NPE in PKIXCertPathValidator event logging code Reviewed-by: mullan ! src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! test/jdk/jdk/jfr/event/security/TestX509CertificateEvent.java ! test/jdk/jdk/jfr/event/security/TestX509ValidationEvent.java ! test/jdk/jdk/security/logging/TestX509CertificateLog.java ! test/jdk/jdk/security/logging/TestX509ValidationLog.java ! test/lib/jdk/test/lib/security/TestCertificate.java Changeset: 0ea58626 Author: Guoxiong Li Committer: Maurizio Cimadamore Date: 2021-01-22 15:47:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0ea58626 8260053: Optimize Tokens' use of Names Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java Changeset: bf5e8015 Author: Johannes Kuhn Committer: Mandy Chung Date: 2021-01-22 17:18:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bf5e8015 8259922: MethodHandles.collectArguments does not throw IAE if pos is outside the arity range Reviewed-by: mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java + test/jdk/java/lang/invoke/MethodHandlesCollectArgsTest.java Changeset: c5ad713e Author: Aleksey Shipilev Date: 2021-01-22 17:19:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c5ad713e 8260250: Duplicate check in DebugInformationRecorder::recorders_frozen Reviewed-by: iveresov, thartmann ! src/hotspot/share/code/debugInfoRec.cpp Changeset: 874aef4a Author: Alexey Bakhtin Committer: Daniel Fuchs Date: 2021-01-22 18:21:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/874aef4a 8259707: LDAP channel binding does not work with StartTLS extension Reviewed-by: mullan, dfuchs, aefimov ! src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java ! src/java.naming/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java Changeset: a8871776 Author: Stuart Marks Date: 2021-01-22 18:51:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a8871776 8246788: ZoneRules invariants can be broken Reviewed-by: rriggs, naoto ! src/java.base/share/classes/java/time/zone/ZoneRules.java + test/jdk/java/time/test/java/time/zone/TestMutableZoneRules.java Changeset: 53fecba7 Author: Dmitry Markov Date: 2021-01-22 19:21:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/53fecba7 8258805: Japanese characters not entered by mouse click on Windows 10 Reviewed-by: aivanov ! src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java Changeset: 5aca934c Author: Aleksey Shipilev Date: 2021-01-22 19:21:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5aca934c 8260304: (se) EPollSelectorImpl wakeup mechanism broken on Linux 32-bit Reviewed-by: bpb, alanb ! src/java.base/linux/native/libnio/ch/EventFD.c Changeset: 7be9113b Author: Dan Lemmond Committer: Paul Hohensee Date: 2021-01-22 20:33:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7be9113b 8255216: Change _directive->BreakAtCompileOption to env()->break_at_compile() Reviewed-by: kvn, phh ! src/hotspot/share/c1/c1_Compilation.cpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/opto/compile.cpp Changeset: bdc305e1 Author: Alex Menkov Date: 2021-01-22 21:33:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bdc305e1 8258917: NativeMemoryTracking is handled by launcher inconsistenly Reviewed-by: zgu ! src/java.base/share/native/libjli/java.c ! test/jdk/tools/launcher/TestSpecialArgs.java Changeset: aa57d07c Author: Ioi Lam Date: 2021-01-22 22:47:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aa57d07c 8259214: MetaspaceClosure support for Arrays of MetaspaceObj Reviewed-by: fparain, ccheung ! src/hotspot/share/memory/metaspaceClosure.hpp + test/hotspot/gtest/utilities/test_metaspaceClosure.cpp Changeset: a5367cbb Author: Brian Burkhalter Committer: Henry Jen Date: 2020-07-29 09:52:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a5367cbb 8247619: Improve Direct Buffering of Characters Reviewed-by: alanb, ahgross, rhalade, psandoz ! src/java.base/share/classes/java/nio/Buffer.java ! src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template ! src/java.base/share/classes/java/nio/X-Buffer.java.template Changeset: 62eab505 Author: Weijun Wang Committer: Henry Jen Date: 2020-10-23 13:00:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/62eab505 8255199: Catching a few NumberFormatExceptions in xmldsig Reviewed-by: rhalade ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java ! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java Changeset: ede1beae Author: Thomas Schatzl Date: 2021-01-21 18:21:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ede1beae 8227695: assert(pss->trim_ticks().seconds() == 0.0) failed: Unexpected partial trimming during evacuation Change FP comparison to integer comparison. Reviewed-by: kbarrett, iwalulya, eosterlund ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp Changeset: d90e06af Author: Jie Fu Date: 2021-01-22 00:13:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d90e06af 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation Reviewed-by: rbackman, neliasso, kvn ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86.ad + test/hotspot/jtreg/compiler/vectorapi/VectorReinterpretTest.java Changeset: 685c03dc Author: Kim Barrett Date: 2021-01-22 11:20:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/685c03dc 8259271: gc/parallel/TestDynShrinkHeap.java still fails "assert(covered_region.contains(new_memregion)) failed: new region is not in covered_region" Use load_acquire to order reads of top and end. Reviewed-by: tschatzl, iwalulya, eosterlund ! src/hotspot/share/gc/parallel/mutableSpace.cpp Changeset: 6f2a3943 Author: Jesper Wilhelmsson Date: 2021-01-23 03:15:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6f2a3943 Merge ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/java.base/share/classes/java/nio/X-Buffer.java.template ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/java.base/share/classes/java/nio/X-Buffer.java.template Changeset: 5cdcce1c Author: Ioi Lam Date: 2021-01-23 06:24:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5cdcce1c 8260307: Do not include method.hpp in frame.hpp Reviewed-by: lfoltan, coleenp ! src/hotspot/cpu/arm/interp_masm_arm.hpp ! src/hotspot/cpu/x86/interp_masm_x86.hpp ! src/hotspot/share/ci/ciInstanceKlass.hpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/classfile/resolutionErrors.cpp ! src/hotspot/share/code/compiledMethod.hpp ! src/hotspot/share/compiler/methodMatcher.cpp ! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp ! src/hotspot/share/interpreter/abstractInterpreter.hpp ! src/hotspot/share/jvmci/jvmci_globals.cpp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/memory/metaspace/printMetaspaceInfoKlassClosure.cpp ! src/hotspot/share/memory/metaspaceCounters.cpp ! src/hotspot/share/oops/methodCounters.cpp ! src/hotspot/share/prims/jvmtiExport.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/deoptimization.hpp ! src/hotspot/share/runtime/frame.hpp ! src/hotspot/share/runtime/handles.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: f624dba6 Author: Alexey Ivanov Date: 2021-01-23 11:38:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f624dba6 8240247: No longer need to wrap files with contentContainer Reviewed-by: serb ! src/java.desktop/share/classes/java/awt/doc-files/AWTThreadIssues.html ! src/java.desktop/share/classes/java/awt/doc-files/DesktopProperties.html ! src/java.desktop/share/classes/java/awt/doc-files/FocusSpec.html ! src/java.desktop/share/classes/java/awt/doc-files/Modality.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/bmp_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/jpeg_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/png_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/standard_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/wbmp_metadata.html ! src/java.desktop/share/classes/javax/swing/plaf/multi/doc-files/multi_tsc.html ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html ! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html ! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html Changeset: b53d5cac Author: Alexey Ivanov Date: 2021-01-23 17:03:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b53d5cac 8260315: Typo "focul" instead of "focus" in FocusSpec.html Reviewed-by: kizune, pbansal ! src/java.desktop/share/classes/java/awt/doc-files/FocusSpec.html Changeset: 6c4c96fa Author: Kim Barrett Date: 2021-01-23 19:47:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6c4c96fa 8258742: Move PtrQueue reset to PtrQueueSet subclasses Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/g1/g1BarrierSet.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/shared/ptrQueue.cpp ! src/hotspot/share/gc/shared/ptrQueue.hpp ! src/hotspot/share/gc/shared/satbMarkQueue.cpp ! src/hotspot/share/gc/shared/satbMarkQueue.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp Changeset: 06348dfc Author: Kim Barrett Date: 2021-01-23 22:47:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/06348dfc 8259776: Remove ParallelGC non-CAS oldgen allocation Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp ! src/hotspot/share/gc/parallel/mutableNUMASpace.hpp ! src/hotspot/share/gc/parallel/mutableSpace.cpp ! src/hotspot/share/gc/parallel/mutableSpace.hpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/parallel/psOldGen.cpp ! src/hotspot/share/gc/parallel/psOldGen.hpp ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp ! src/hotspot/share/gc/parallel/psYoungGen.hpp Changeset: 535c2927 Author: Ioi Lam Date: 2021-01-24 02:40:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/535c2927 8260306: Do not include osThread.hpp in thread.hpp Reviewed-by: coleenp, lfoltan ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.inline.hpp ! src/hotspot/share/interpreter/bytecodeTracer.cpp ! src/hotspot/share/jfr/support/jfrThreadId.hpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/objectMonitor.inline.hpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/osThread.hpp ! src/hotspot/share/runtime/safepointMechanism.cpp ! src/hotspot/share/runtime/semaphore.inline.hpp ! src/hotspot/share/runtime/stackWatermark.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/vframe.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/vmError.cpp Changeset: c52c6c66 Author: Hamlin Li Date: 2021-01-25 01:05:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c52c6c66 8260273: DataOutputStream writeChars optimization Reviewed-by: rriggs, bpb, alanb ! src/java.base/share/classes/java/io/DataOutputStream.java ! test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java Changeset: 4ae39b14 Author: Hamlin Li Date: 2021-01-25 01:06:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ae39b14 8260208: Improve dummy object filling condition in G1CollectedHeap::fill_archive_regions in cds Reviewed-by: tschatzl, iklam ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp Changeset: 764111ff Author: Dongbo He Committer: Fei Yang Date: 2021-01-25 01:08:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/764111ff 8260272: bash configure --prefix does not work after JDK-8257679 Reviewed-by: erikj, ihse ! make/autoconf/util_paths.m4 Changeset: 5898ab65 Author: Ioi Lam Date: 2021-01-25 08:00:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5898ab65 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h Reviewed-by: dholmes, coleenp ! src/hotspot/os/windows/os_perf_windows.cpp ! src/hotspot/share/ci/ciFlags.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/include/jvm.h + src/hotspot/share/include/jvm_constants.h + src/hotspot/share/include/jvm_io.h ! src/hotspot/share/logging/logSelection.cpp ! src/hotspot/share/prims/stackwalk.hpp ! src/hotspot/share/runtime/abstract_vm_version.cpp ! src/hotspot/share/runtime/flags/jvmFlag.cpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/utilities/accessFlags.hpp ! src/hotspot/share/utilities/constantTag.hpp ! src/hotspot/share/utilities/formatBuffer.hpp ! test/hotspot/gtest/logging/test_gcTraceTime.cpp ! test/hotspot/gtest/logging/test_logStream.cpp Changeset: d825339d Author: Thomas Schatzl Date: 2021-01-25 08:38:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d825339d 8260263: Remove PtrQueue::_qset Remove dead code related to PtrQueue::_qset and itself. Reviewed-by: kbarrett, sjohanss ! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp ! src/hotspot/share/gc/shared/ptrQueue.cpp ! src/hotspot/share/gc/shared/ptrQueue.hpp ! src/hotspot/share/gc/shared/satbMarkQueue.hpp Changeset: af155fc0 Author: Severin Gehwolf Date: 2021-01-25 08:57:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/af155fc0 8258836: JNI local refs exceed capacity getDiagnosticCommandInfo Reviewed-by: cjplummer, shade ! src/jdk.management/share/native/libmanagement_ext/DiagnosticCommandImpl.c + test/jdk/com/sun/management/DiagnosticCommandMBean/DcmdMBeanTestCheckJni.java Changeset: 09489e28 Author: Yasumasa Suenaga Date: 2021-01-25 09:12:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/09489e28 8260338: Some fields in HaltNode is not cloned Reviewed-by: xliu, neliasso, thartmann ! src/hotspot/share/opto/rootnode.cpp ! src/hotspot/share/opto/rootnode.hpp Changeset: ca20c63c Author: Thomas Stuefe Date: 2021-01-25 10:50:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ca20c63c 8259710: Inlining trace leaks memory Reviewed-by: thartmann, neliasso ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp Changeset: 6e037354 Author: Coleen Phillimore Date: 2021-01-25 13:40:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6e037354 8259845: Move placeholder implementation details to cpp file and add logging Reviewed-by: iklam, lfoltan, dholmes ! src/hotspot/share/classfile/placeholders.cpp ! src/hotspot/share/classfile/placeholders.hpp ! src/hotspot/share/logging/logTag.hpp Changeset: d076977d Author: Eric Caspole Date: 2021-01-25 14:11:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d076977d 8260169: LogCompilation: Unexpected method mismatch Reviewed-by: kvn, vlivanov ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/LogParser.java ! src/utils/LogCompilation/src/test/java/com/sun/hotspot/tools/compiler/TestLogCompilation.java Changeset: ef247ab2 Author: Dan Lutker Committer: Igor Ignatyev Date: 2021-01-25 17:16:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ef247ab2 8260308: Update LogCompilation junit to 4.13.1 Reviewed-by: ecaspole, iignatyev ! src/utils/LogCompilation/pom.xml Changeset: 47c7dc77 Author: Martin Balao Date: 2021-01-25 18:01:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/47c7dc77 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures Reviewed-by: valeriep ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PSSSignature.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Signature.java + test/jdk/sun/security/pkcs11/Cipher/CancelMultipart.java Changeset: 5b0b24b5 Author: Daniel D. Daugherty Date: 2021-01-25 18:20:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5b0b24b5 8260381: ProblemList com/sun/management/DiagnosticCommandMBean/DcmdMBeanTestCheckJni.java on Win with ZGC Reviewed-by: sspitsyn, sgehwolf ! test/jdk/ProblemList-zgc.txt Changeset: 73c78c8a Author: Joe Darcy Date: 2021-01-25 19:06:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/73c78c8a 8260329: Update references to TAOCP to latest edition Reviewed-by: alanb, bpb ! src/java.base/share/classes/java/math/MutableBigInteger.java ! src/java.base/share/classes/java/util/Random.java Changeset: 12ccd211 Author: Andrew Leonard Date: 2021-01-25 19:26:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/12ccd211 8260289: Unable to customize module lists after change JDK-8258411 Reviewed-by: ihse, alanb ! make/common/Modules.gmk Changeset: d6fb9d72 Author: Jonathan Gibbons Date: 2021-01-25 21:44:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d6fb9d72 8255464: Cannot access ModuleTree in a CompilationUnitTree Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/source/tree/CompilationUnitTree.java ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java + test/langtools/tools/javac/tree/CompilationUnitTreeTest.java Changeset: 982e42b8 Author: Jonathan Gibbons Date: 2021-01-25 21:45:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/982e42b8 8259726: Use of HashSet leads to undefined order in test output Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Table.java ! test/langtools/jdk/javadoc/doclet/testAbstractMethod/TestAbstractMethod.java ! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java ! test/langtools/jdk/javadoc/doclet/testHtmlTableTags/TestHtmlTableTags.java ! test/langtools/jdk/javadoc/doclet/testInterface/TestInterface.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java ! test/langtools/jdk/javadoc/doclet/testLambdaFeature/TestLambdaFeature.java ! test/langtools/jdk/javadoc/doclet/testMemberInheritance/TestMemberInheritance.java ! test/langtools/jdk/javadoc/doclet/testMemberSummary/TestMemberSummary.java ! test/langtools/jdk/javadoc/doclet/testMethodTypes/TestMethodTypes.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModulePackages.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java ! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverrideMethods.java ! test/langtools/jdk/javadoc/doclet/testProperty/TestProperty.java ! test/langtools/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java ! test/langtools/jdk/javadoc/doclet/testTypeParams/TestTypeParameters.java ! test/langtools/jdk/javadoc/doclet/testUnnamedPackage/TestUnnamedPackage.java Changeset: 9ea93238 Author: Coleen Phillimore Date: 2021-01-25 23:58:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ea93238 8254246: SymbolHashMapEntry wastes space Reviewed-by: redestad ! src/hotspot/share/oops/constantPool.hpp Changeset: c538cd8b Author: Serguei Spitsyn Date: 2021-01-26 07:15:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c538cd8b 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs Reviewed-by: mchung, dholmes, alanb ! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java + test/jdk/java/lang/instrument/NegativeAgentRunner.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0001.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0010.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0011.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0100.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0101.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0110.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0111.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1000.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1001.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1010.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1011.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1100.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1101.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1110.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1111.java ! test/jdk/java/lang/instrument/PremainClass/NoPremainAgent.java - test/jdk/java/lang/instrument/PremainClass/NoPremainAgentTest.java + test/jdk/java/lang/instrument/PremainClass/NonPublicAgent.java + test/jdk/java/lang/instrument/PremainClass/NonPublicPremainAgent.java ! test/jdk/java/lang/instrument/PremainClass/ZeroArgPremainAgent.java - test/jdk/java/lang/instrument/PremainClass/ZeroArgPremainAgentTest.java Changeset: abd9310b Author: Matthias Baesken Date: 2021-01-26 07:42:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/abd9310b 8260222: remove unused _thread member SymbolTableLookup Reviewed-by: coleenp, dholmes, shade ! src/hotspot/share/classfile/symbolTable.cpp Changeset: 23edb6f6 Author: Guoxiong Li Committer: Joel Borggr?n-Franck Date: 2021-01-26 08:57:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/23edb6f6 8236490: Compiler bug relating to @NonNull annotation Reviewed-by: vromero, jfranck ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java + test/langtools/tools/javac/annotations/typeAnnotations/8236490/T8236490.java Changeset: b4ace3e9 Author: Thomas Schatzl Date: 2021-01-26 10:14:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b4ace3e9 8260042: G1 Post-cleanup liveness printing occurs too early Reviewed-by: sjohanss, iwalulya ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1Policy.cpp Changeset: 81a66dfa Author: Coleen Phillimore Date: 2021-01-26 11:50:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81a66dfa 8259809: Remove PerfEvent class loading locking counters Reviewed-by: redestad, iklam ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp Changeset: edd27074 Author: Aleksey Shipilev Date: 2021-01-26 13:04:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/edd27074 8260408: Shenandoah: adjust inline hints after JDK-8255019 Reviewed-by: rkennke, ihse ! make/hotspot/lib/JvmOverrideFiles.gmk Changeset: e080ce92 Author: Harold Seigel Date: 2021-01-26 13:17:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e080ce92 8252545: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java timed out Reviewed-by: stuefe, coleenp ! test/hotspot/jtreg/TEST.groups ! test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java - test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java Changeset: 5e8e0ada Author: Jan Lahoda Date: 2021-01-26 13:42:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5e8e0ada 8242456: PreviewFeature.Feature enum removal of TEXT_BLOCKS Reviewed-by: jlaskey ! src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java Changeset: 8d2f77fd Author: Magnus Ihse Bursie Date: 2021-01-26 14:08:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8d2f77fd 8260406: Do not copy pure java source code to gensrc Reviewed-by: alanb, erikj ! make/modules/java.base/gensrc/GensrcCharacterData.gmk = src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java = src/java.base/share/classes/java/lang/CharacterDataUndefined.java Changeset: af8a08f5 Author: Severin Gehwolf Date: 2021-01-26 15:18:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/af8a08f5 8260378: [TESTBUG] DcmdMBeanTestCheckJni.java reports false positive Reviewed-by: dcubed ! test/jdk/ProblemList-zgc.txt ! test/jdk/com/sun/management/DiagnosticCommandMBean/DcmdMBeanTestCheckJni.java Changeset: b07797c2 Author: Claes Redestad Date: 2021-01-26 15:25:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b07797c2 8260391: Remove StringCoding::err Reviewed-by: shade, rriggs ! src/java.base/share/classes/java/lang/StringCoding.java - src/java.base/share/native/libjava/StringCoding.c Changeset: fd00ed74 Author: Zhengyu Gu Date: 2021-01-26 16:46:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fd00ed74 8256298: Shenandoah: Enable concurrent stack processing Reviewed-by: rkennke, shade ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp ! src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp ! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp + src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.cpp + src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.hpp ! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp Changeset: 9f0a0436 Author: Fernando Guallini Committer: Rajan Halade Date: 2021-01-26 18:15:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f0a0436 8260286: Manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails Reviewed-by: rhalade ! test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java ! test/jdk/sun/security/tools/jarsigner/warnings/Test.java Changeset: 42cef27f Author: Sergey Bylokhov Date: 2021-01-26 18:31:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/42cef27f 8260343: Delete obsolete classes in the Windows L&F Reviewed-by: aivanov, pbansal - src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsButtonListener.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java Changeset: 1bebd418 Author: Zhengyu Gu Date: 2021-01-26 20:25:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1bebd418 8260421: Shenandoah: Fix conc_mark_roots timing name and indentations Reviewed-by: rkennke, shade ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Changeset: 19b6f61b Author: Xin Liu Committer: Paul Hohensee Date: 2021-01-26 20:52:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/19b6f61b 8260334: Remove deprecated sv_for_node_id() from Compile Reviewed-by: neliasso, chagedorn, thartmann, phh ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/output.hpp Changeset: 6f2be9c6 Author: David Holmes Date: 2021-01-27 01:18:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6f2be9c6 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC Reviewed-by: ihse, erikj, gziemski, hseigel ! make/autoconf/flags-cflags.m4 ! make/autoconf/flags-ldflags.m4 ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/aix/os_aix.inline.hpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/bsd/os_bsd.hpp ! src/hotspot/os/bsd/os_bsd.inline.hpp ! src/hotspot/os/bsd/os_perf_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/linux/os_linux.inline.hpp ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/posix/os_posix.hpp ! src/hotspot/os/posix/os_posix.inline.hpp ! src/hotspot/os/windows/os_windows.inline.hpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/runtime/thread.cpp Changeset: e1411fd4 Author: Sergey Bylokhov Date: 2021-01-27 02:52:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e1411fd4 6606673: Path2D.Double, Path2D.Float and GeneralPath ctors throw exception when initialCapacity is negative Reviewed-by: psadhukhan, kizune ! src/java.desktop/share/classes/java/awt/geom/GeneralPath.java ! src/java.desktop/share/classes/java/awt/geom/Path2D.java + test/jdk/java/awt/geom/GeneralPath/GeneralPathExceptions.java + test/jdk/java/awt/geom/Path2D/Path2DExceptions.java Changeset: c836da38 Author: Martin Buchholz Date: 2021-01-27 04:31:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c836da38 8252412: [macos11] system dynamic libraries removed from filesystem Co-authored-by: Dominik R?ttsches Reviewed-by: jiangli, valeriep ! src/java.smartcardio/unix/classes/sun/security/smartcardio/PlatformPCSC.java Changeset: bd2744dd Author: Aleksey Shipilev Date: 2021-01-27 07:17:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bd2744dd 8260106: Shenandoah: refactor reference updating closures and related code Reviewed-by: zgu, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMark.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.hpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp Changeset: 1c770468 Author: Thomas Stuefe Date: 2021-01-27 07:34:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1c770468 8260404: jvm_io.h include missing in a number of files Reviewed-by: shade, iklam, dholmes ! src/hotspot/os/posix/perfMemory_posix.cpp ! src/hotspot/share/aot/aotCodeHeap.cpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/jfr/jni/jfrUpcalls.cpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleDescription.cpp ! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/hotspot/share/jvmci/jvmciRuntime.hpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/runtime/handshake.cpp Changeset: fd2641ed Author: Matthias Baesken Date: 2021-01-27 07:57:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fd2641ed 8260236: better init AnnotationCollector _contended_group Reviewed-by: coleenp, shade ! src/hotspot/share/classfile/classFileParser.cpp Changeset: 4d004c94 Author: Roman Kennke Date: 2021-01-27 09:32:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d004c94 8260449: Remove stale declaration of SATBMarkQueue::apply_closure_and_empty() Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/satbMarkQueue.hpp Changeset: fa40a966 Author: Albert Mingkun Yang Committer: Stefan Johansson Date: 2021-01-27 09:57:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fa40a966 8253420: Refactor HeapRegionManager::find_highest_free Reviewed-by: sjohanss, kbarrett ! src/hotspot/share/gc/g1/heapRegionManager.cpp Changeset: 3e4194c4 Author: Thomas Stuefe Date: 2021-01-27 10:43:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3e4194c4 8260022: [ppc] os::print_function_and_library_name shall resolve function descriptors transparently Reviewed-by: mdoerr, lucy ! src/hotspot/cpu/ppc/assembler_ppc.hpp ! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp ! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.hpp ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.hpp ! src/hotspot/share/runtime/os.cpp Changeset: bf15c709 Author: Aleksey Shipilev Date: 2021-01-27 10:48:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bf15c709 8260460: GitHub actions still fail on Linux x86_32 with "Could not configure libc6:i386" Reviewed-by: ihse ! .github/workflows/submit.yml Changeset: b3c8a528 Author: Jan Lahoda Date: 2021-01-27 11:00:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b3c8a528 8259050: Error recovery in lexer could be improved Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java ! test/langtools/tools/javac/lexer/JavaLexerTest.java ! test/langtools/tools/javac/parser/JavacParserTest.java Changeset: e696baab Author: Claes Redestad Date: 2021-01-27 11:30:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e696baab 8260448: Simplify ManagementFactory$PlatformMBeanFinder Reviewed-by: mchung, dfuchs ! src/java.management/share/classes/java/lang/management/ManagementFactory.java Changeset: 7ed591cc Author: Alexey Ivanov Date: 2021-01-27 12:09:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7ed591cc 8260314: Replace border="1" on tables with CSS Reviewed-by: serb ! src/java.desktop/share/classes/java/awt/doc-files/DesktopProperties.html ! src/java.desktop/share/classes/java/awt/doc-files/Modality.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html ! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html ! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html Changeset: ac276bb3 Author: Chris Hegarty Date: 2021-01-27 14:09:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ac276bb3 8257074: Update the ByteBuffers micro benchmark Reviewed-by: redestad, dfuchs, jvernee, bpb ! test/micro/org/openjdk/bench/java/nio/ByteBuffers.java ! test/micro/org/openjdk/bench/java/nio/CharBuffers.java + test/micro/org/openjdk/bench/java/nio/DoubleBuffers.java + test/micro/org/openjdk/bench/java/nio/FloatBuffers.java + test/micro/org/openjdk/bench/java/nio/IntBuffers.java + test/micro/org/openjdk/bench/java/nio/LongBuffers.java + test/micro/org/openjdk/bench/java/nio/ShortBuffers.java + test/micro/org/openjdk/bench/java/nio/X-Buffers-bin.java.template + test/micro/org/openjdk/bench/java/nio/X-Buffers.java.template + test/micro/org/openjdk/bench/java/nio/X-ByteBuffers-bin.java.template + test/micro/org/openjdk/bench/java/nio/genBuffers.sh Changeset: f353fcf2 Author: Roberto Casta?eda Lozano Committer: Tobias Hartmann Date: 2021-01-27 15:08:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f353fcf2 8258894: C2: Forbid GCM to move stores into loops Prevent GCM from placing memory-writing nodes (such as stores) into loops deeper than their home loop (determined by their control input). Such placements are invalid, as they cause memory definitions to interfere, and risk causing miscompilations. This change complements JDK-8255763, which only addresses invalid placements in irreducible CFGs. Add control input to stores in generated stubs to ensure that all memory-writing nodes have control inputs from which their home block can be derived. Add a battery of simplified fuzzer test cases where, before this change, GCM moves stores into deeper loops. Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/block.cpp ! src/hotspot/share/opto/block.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/gcm.cpp ! src/hotspot/share/opto/generateOptoStub.cpp ! src/hotspot/share/opto/node.hpp ! test/hotspot/jtreg/compiler/codegen/TestGCMStorePlacement.java Changeset: 311a0a91 Author: Denghui Dong Committer: Thomas Schatzl Date: 2021-01-27 15:28:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/311a0a91 8259808: Add JFR event to detect GC locker stall Reviewed-by: sjohanss, tschatzl, egahlin ! src/hotspot/share/gc/shared/gcLocker.cpp ! src/hotspot/share/gc/shared/gcTrace.hpp ! src/hotspot/share/gc/shared/gcTraceSend.cpp ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/prims/whitebox.cpp ! src/jdk.jfr/share/conf/jfr/default.jfc ! src/jdk.jfr/share/conf/jfr/profile.jfc + test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java ! test/lib/jdk/test/lib/jfr/EventNames.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: 684c8558 Author: Daniel D. Daugherty Date: 2021-01-27 17:26:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/684c8558 8260524: validate-source fails on test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java Reviewed-by: bpb, iignatyev ! src/hotspot/share/gc/shared/gcLocker.cpp ! src/hotspot/share/gc/shared/gcTrace.hpp ! src/hotspot/share/gc/shared/gcTraceSend.cpp ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/prims/whitebox.cpp ! test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java ! test/lib/jdk/test/lib/jfr/EventNames.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: 0eed2c33 Author: Guoxiong Li Committer: Vicente Romero Date: 2021-01-27 18:12:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0eed2c33 8259359: javac does not attribute unexpected super constructor invocation qualifier, and may crash Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java + test/langtools/tools/javac/recovery/T8259359.java Changeset: eb923685 Author: Stuart Marks Date: 2021-01-27 19:02:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eb923685 8259816: Typo in java.util.stream package description Reviewed-by: iris, lancea, naoto ! src/java.base/share/classes/java/util/stream/package-info.java Changeset: c5ab7c32 Author: Christian Hagedorn Date: 2021-01-25 17:09:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c5ab7c32 8260284: C2: assert(_base == Int) failed: Not an Int Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/phaseX.cpp + test/hotspot/jtreg/compiler/loopopts/TestDivWithTopDivisor.java Changeset: 81e730e5 Author: Vladimir Ivanov Date: 2021-01-25 20:02:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81e730e5 8259276: C2: Empty expression stack when reexecuting tableswitch/lookupswitch instructions after deoptimization Reviewed-by: dlong, kvn, thartmann ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/parse2.cpp Changeset: 408772c9 Author: Vicente Romero Date: 2021-01-26 16:00:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/408772c9 8259025: Record compact constructor using Objects.requireNonNull Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/langtools/tools/javac/records/RecordCompilationTests.java Changeset: c52212b1 Author: Jesper Wilhelmsson Date: 2021-01-27 20:56:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c52212b1 Merge ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/phaseX.cpp Changeset: c7661aed Author: Roger Riggs Date: 2021-01-27 22:37:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c7661aed 8260561: [doc] HexFormat has incorrect @since tag Reviewed-by: darcy, naoto, bpb, lancea ! src/java.base/share/classes/java/util/HexFormat.java Changeset: 7030d2e0 Author: Hamlin Li Date: 2021-01-28 00:45:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7030d2e0 8260200: G1: Remove unnecessary update in FreeRegionList::remove_starting_at Reviewed-by: ayang, sjohanss, tschatzl ! src/hotspot/share/gc/g1/heapRegionSet.cpp ! src/hotspot/share/gc/g1/heapRegionSet.hpp Changeset: e28e1111 Author: Vladimir Ivanov Date: 2021-01-27 10:29:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e28e1111 8260370: C2: LoopLimit node is not eliminated Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/loopnode.cpp Changeset: 62ffe75b Author: Jesper Wilhelmsson Date: 2021-01-28 03:38:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/62ffe75b Merge ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/loopnode.cpp Changeset: 396a496f Author: Ioi Lam Date: 2021-01-28 04:24:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/396a496f 8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp Reviewed-by: dholmes, coleenp ! src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp ! src/hotspot/cpu/aarch64/methodHandles_aarch64.hpp ! src/hotspot/cpu/arm/methodHandles_arm.cpp ! src/hotspot/cpu/arm/methodHandles_arm.hpp ! src/hotspot/cpu/ppc/methodHandles_ppc.cpp ! src/hotspot/cpu/ppc/methodHandles_ppc.hpp ! src/hotspot/cpu/s390/methodHandles_s390.cpp ! src/hotspot/cpu/s390/methodHandles_s390.hpp ! src/hotspot/cpu/x86/methodHandles_x86.cpp ! src/hotspot/cpu/x86/methodHandles_x86.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciObjArrayKlass.cpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp + src/hotspot/share/classfile/vmClassID.hpp + src/hotspot/share/classfile/vmClassMacros.hpp + src/hotspot/share/classfile/vmClasses.cpp + src/hotspot/share/classfile/vmClasses.hpp ! src/hotspot/share/memory/archiveBuilder.cpp ! src/hotspot/share/memory/archiveBuilder.hpp ! src/hotspot/share/memory/filemap.cpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/vmEnums.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbPrintStatics.java Changeset: 11a70d11 Author: Matthias Baesken Date: 2021-01-28 07:35:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/11a70d11 8260426: awt debug_mem.c DMem_AllocateBlock might leak memory Reviewed-by: psadhukhan, aivanov ! src/java.desktop/share/native/common/awt/debug/debug_mem.c Changeset: 316d52c1 Author: Roman Kennke Date: 2021-01-28 09:50:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/316d52c1 8260497: Shenandoah: Improve SATB flushing Reviewed-by: shade, zgu ! src/hotspot/share/gc/shared/satbMarkQueue.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Changeset: a97aedff Author: Aleksey Shipilev Date: 2021-01-28 10:24:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a97aedff 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code Reviewed-by: rkennke, zgu ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp Changeset: ecde52ec Author: Claes Redestad Date: 2021-01-28 11:13:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ecde52ec 8260506: VersionHelper cleanup Reviewed-by: alanb, dfuchs, aefimov ! src/java.naming/share/classes/com/sun/naming/internal/VersionHelper.java Changeset: 8fe1323d Author: Claes Redestad Date: 2021-01-28 11:14:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8fe1323d 8260520: Avoid getting permissions in JarFileFactory when no SecurityManager installed Reviewed-by: alanb, dfuchs, michaelm, mullan ! src/java.base/unix/classes/sun/net/www/protocol/jar/JarFileFactory.java ! src/java.base/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java Changeset: 87522573 Author: Martin Doerr Date: 2021-01-28 11:39:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/87522573 8260502: [s390] NativeMovRegMem::verify() fails because it's too strict Reviewed-by: lucy, rrich ! src/hotspot/cpu/s390/nativeInst_s390.cpp ! src/hotspot/cpu/s390/nativeInst_s390.hpp Changeset: a68c6c2a Author: Aleksey Shipilev Date: 2021-01-28 12:00:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a68c6c2a 8260579: PPC64 and S390 builds failures after JDK-8260467 Reviewed-by: mdoerr ! src/hotspot/cpu/ppc/methodHandles_ppc.cpp ! src/hotspot/cpu/s390/methodHandles_s390.cpp Changeset: d07af2b8 Author: Jorn Vernee Date: 2021-01-28 12:26:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d07af2b8 8255531: MethodHandles::permuteArguments throws NPE when duplicating dropped arguments Reviewed-by: redestad ! src/java.base/share/classes/java/lang/invoke/LambdaFormBuffer.java ! test/jdk/java/lang/invoke/MethodHandlesPermuteArgumentsTest.java Changeset: 11d6467c Author: Roland Westrelin Date: 2021-01-28 12:27:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/11d6467c 8260407: cmp != __null && cmp->Opcode() == Op_CmpL failure with -XX:StressLongCountedLoop=200000000 in lucene Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/loopopts.cpp + test/hotspot/jtreg/compiler/longcountedloops/TestLongCountedLoopSplitIf.java Changeset: 20e7df50 Author: Harold Seigel Date: 2021-01-28 13:17:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/20e7df50 8260466: Test TestHeapDumpOnOutOfMemoryError.java needs multiple @test sections Reviewed-by: shade, lmesnik ! test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java Changeset: baf46bac Author: Sean Mullan Date: 2021-01-28 14:28:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/baf46bac 8259801: Enable XML Signature secure validation mode by default Reviewed-by: weijun, rhalade ! src/java.base/share/conf/security/java.security ! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/dom/DOMValidateContext.java ! test/jdk/javax/xml/crypto/dsig/GenerationTests.java Changeset: 13ca433f Author: Patrick Concannon Date: 2021-01-28 15:01:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/13ca433f 8259628: jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java fails intermittently Reviewed-by: dfuchs ! test/jdk/jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java Changeset: abc4300d Author: Poonam Bajaj Date: 2021-01-28 15:07:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/abc4300d 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines Reviewed-by: hseigel ! src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java Changeset: 3aabbd72 Author: Matthias Baesken Date: 2021-01-28 15:20:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3aabbd72 8260432: allocateSpaceForGP in freetypeScaler.c might leak memory Reviewed-by: shade, stuefe ! src/java.desktop/share/native/libfontmanager/freetypeScaler.c Changeset: bbbfaa58 Author: Calvin Cheung Date: 2021-01-28 16:17:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bbbfaa58 8249262: Initialize InstanceKlass::_package_entry during CDS dump time Reviewed-by: iklam, minqi ! src/hotspot/share/classfile/classLoaderDataShared.cpp ! src/hotspot/share/classfile/classLoaderDataShared.hpp ! src/hotspot/share/classfile/packageEntry.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/oops/instanceKlass.cpp Changeset: 1de3c554 Author: Aleksey Shipilev Date: 2021-01-28 16:31:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1de3c554 8260584: Shenandoah: simplify "Concurrent Thread Roots" logging Reviewed-by: rkennke, zgu ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Changeset: 2b166d81 Author: Weijun Wang Date: 2021-01-28 17:54:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2b166d81 8260596: Comment cleanup in BigInteger Reviewed-by: bpb ! src/java.base/share/classes/java/math/BigInteger.java Changeset: 81e9e6a7 Author: Martin Buchholz Date: 2021-01-28 18:06:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81e9e6a7 8260461: Modernize jsr166 tck tests Reviewed-by: dl ! test/jdk/java/util/concurrent/tck/AbstractExecutorServiceTest.java ! test/jdk/java/util/concurrent/tck/AbstractQueueTest.java ! test/jdk/java/util/concurrent/tck/ArrayBlockingQueueTest.java ! test/jdk/java/util/concurrent/tck/ArrayDeque8Test.java ! test/jdk/java/util/concurrent/tck/ArrayDequeTest.java ! test/jdk/java/util/concurrent/tck/ArrayListTest.java ! test/jdk/java/util/concurrent/tck/Atomic8Test.java ! test/jdk/java/util/concurrent/tck/AtomicBooleanTest.java ! test/jdk/java/util/concurrent/tck/AtomicIntegerArrayTest.java ! test/jdk/java/util/concurrent/tck/AtomicIntegerTest.java ! test/jdk/java/util/concurrent/tck/AtomicLongArrayTest.java ! test/jdk/java/util/concurrent/tck/AtomicLongTest.java ! test/jdk/java/util/concurrent/tck/AtomicMarkableReferenceTest.java ! test/jdk/java/util/concurrent/tck/AtomicReference9Test.java ! test/jdk/java/util/concurrent/tck/AtomicReferenceArray9Test.java ! test/jdk/java/util/concurrent/tck/AtomicReferenceArrayTest.java ! test/jdk/java/util/concurrent/tck/AtomicReferenceFieldUpdaterTest.java ! test/jdk/java/util/concurrent/tck/AtomicReferenceTest.java ! test/jdk/java/util/concurrent/tck/AtomicStampedReferenceTest.java ! test/jdk/java/util/concurrent/tck/BlockingQueueTest.java ! test/jdk/java/util/concurrent/tck/Collection8Test.java ! test/jdk/java/util/concurrent/tck/CompletableFutureTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentHashMap8Test.java ! test/jdk/java/util/concurrent/tck/ConcurrentHashMapTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentLinkedDequeTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentLinkedQueueTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentSkipListMapTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentSkipListSetTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentSkipListSubMapTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentSkipListSubSetTest.java ! test/jdk/java/util/concurrent/tck/CopyOnWriteArrayListTest.java ! test/jdk/java/util/concurrent/tck/CopyOnWriteArraySetTest.java ! test/jdk/java/util/concurrent/tck/CountedCompleterTest.java ! test/jdk/java/util/concurrent/tck/DelayQueueTest.java ! test/jdk/java/util/concurrent/tck/ExchangerTest.java ! test/jdk/java/util/concurrent/tck/ExecutorCompletionService9Test.java ! test/jdk/java/util/concurrent/tck/ExecutorCompletionServiceTest.java ! test/jdk/java/util/concurrent/tck/ExecutorsTest.java ! test/jdk/java/util/concurrent/tck/ForkJoinPool8Test.java ! test/jdk/java/util/concurrent/tck/ForkJoinPoolTest.java ! test/jdk/java/util/concurrent/tck/ForkJoinTask8Test.java ! test/jdk/java/util/concurrent/tck/ForkJoinTaskTest.java ! test/jdk/java/util/concurrent/tck/FutureTaskTest.java + test/jdk/java/util/concurrent/tck/Item.java ! test/jdk/java/util/concurrent/tck/JSR166TestCase.java ! test/jdk/java/util/concurrent/tck/LinkedBlockingDeque8Test.java ! test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java ! test/jdk/java/util/concurrent/tck/LinkedBlockingQueue8Test.java ! test/jdk/java/util/concurrent/tck/LinkedBlockingQueueTest.java ! test/jdk/java/util/concurrent/tck/LinkedListTest.java ! test/jdk/java/util/concurrent/tck/LinkedTransferQueueTest.java ! test/jdk/java/util/concurrent/tck/MapTest.java ! test/jdk/java/util/concurrent/tck/NonNestmates.java ! test/jdk/java/util/concurrent/tck/PhaserTest.java ! test/jdk/java/util/concurrent/tck/PriorityBlockingQueueTest.java ! test/jdk/java/util/concurrent/tck/PriorityQueueTest.java ! test/jdk/java/util/concurrent/tck/RecursiveActionTest.java ! test/jdk/java/util/concurrent/tck/RecursiveTaskTest.java ! test/jdk/java/util/concurrent/tck/ScheduledExecutorSubclassTest.java ! test/jdk/java/util/concurrent/tck/ScheduledExecutorTest.java ! test/jdk/java/util/concurrent/tck/StampedLockTest.java ! test/jdk/java/util/concurrent/tck/SubmissionPublisherTest.java ! test/jdk/java/util/concurrent/tck/SynchronousQueueTest.java ! test/jdk/java/util/concurrent/tck/ThreadLocalTest.java ! test/jdk/java/util/concurrent/tck/ThreadPoolExecutorSubclassTest.java ! test/jdk/java/util/concurrent/tck/ThreadPoolExecutorTest.java ! test/jdk/java/util/concurrent/tck/TreeMapTest.java ! test/jdk/java/util/concurrent/tck/TreeSetTest.java ! test/jdk/java/util/concurrent/tck/TreeSubMapTest.java ! test/jdk/java/util/concurrent/tck/TreeSubSetTest.java ! test/jdk/java/util/concurrent/tck/VectorTest.java Changeset: 71128cf4 Author: Aleksey Shipilev Date: 2021-01-28 19:04:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/71128cf4 8260586: Shenandoah: simplify "Concurrent Weak References" logging Reviewed-by: rkennke, zgu ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Changeset: 15196325 Author: Igor Veresov Date: 2021-01-28 20:51:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/15196325 8251462: Simplify compilation policy Reviewed-by: cjplummer, kvn ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_globals_aarch64.hpp ! src/hotspot/cpu/aarch64/c2_globals_aarch64.hpp ! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp ! src/hotspot/cpu/aarch64/globals_aarch64.hpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/arm/globals_arm.hpp ! src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/ppc/c1_globals_ppc.hpp ! src/hotspot/cpu/ppc/c2_globals_ppc.hpp ! src/hotspot/cpu/ppc/interp_masm_ppc.hpp ! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/s390/c1_globals_s390.hpp ! src/hotspot/cpu/s390/c2_globals_s390.hpp ! src/hotspot/cpu/s390/templateInterpreterGenerator_s390.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp ! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/c1_globals_x86.hpp ! src/hotspot/cpu/x86/c2_globals_x86.hpp ! src/hotspot/cpu/x86/globalDefinitions_x86.hpp ! src/hotspot/cpu/x86/globals_x86.hpp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/zero/globals_zero.hpp ! src/hotspot/share/aot/aotCodeHeap.cpp ! src/hotspot/share/aot/aotCompiledMethod.cpp ! src/hotspot/share/aot/aotCompiledMethod.hpp ! src/hotspot/share/c1/c1_Compilation.cpp ! src/hotspot/share/c1/c1_Compilation.hpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_LIRAssembler.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_Runtime1.cpp ! src/hotspot/share/c1/c1_globals.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/compiler/compilationPolicy.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileTask.cpp ! src/hotspot/share/compiler/compilerDefinitions.cpp ! src/hotspot/share/compiler/compilerDefinitions.hpp ! src/hotspot/share/compiler/compilerDirectives.cpp ! src/hotspot/share/compiler/compiler_globals.hpp ! src/hotspot/share/compiler/oopMap.cpp - src/hotspot/share/compiler/tieredThresholdPolicy.cpp - src/hotspot/share/compiler/tieredThresholdPolicy.hpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/interpreterRuntime.hpp ! src/hotspot/share/interpreter/invocationCounter.cpp ! src/hotspot/share/interpreter/invocationCounter.hpp ! src/hotspot/share/interpreter/templateInterpreterGenerator.hpp ! src/hotspot/share/jvmci/compilerRuntime.cpp ! src/hotspot/share/jvmci/jvmciCompiler.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/oops/methodCounters.cpp ! src/hotspot/share/oops/methodCounters.hpp ! src/hotspot/share/oops/methodData.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/abstract_vm_version.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp ! src/hotspot/share/runtime/globals_shared.hpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/macros.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Method.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodCounters.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodData.java ! test/hotspot/jtreg/TEST.quick-groups ! test/hotspot/jtreg/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java ! test/hotspot/jtreg/compiler/whitebox/ClearMethodStateTest.java ! test/hotspot/jtreg/compiler/whitebox/CompilerWhiteBoxTest.java - test/hotspot/jtreg/vmTestbase/jit/tiered/Test.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/MyThread.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.java Changeset: 251c6419 Author: Kim Barrett Date: 2021-01-29 03:34:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/251c6419 8259487: Remove unused StarTask Reviewed-by: iklam, tschatzl ! src/hotspot/share/gc/shared/taskqueue.hpp Changeset: ea2c4474 Author: Kim Barrett Date: 2021-01-29 03:49:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ea2c4474 8259778: Merge MutableSpace and ImmutableSpace Reviewed-by: sspitsyn, dholmes, tschatzl - src/hotspot/share/gc/parallel/immutableSpace.cpp - src/hotspot/share/gc/parallel/immutableSpace.hpp ! src/hotspot/share/gc/parallel/mutableSpace.cpp ! src/hotspot/share/gc/parallel/mutableSpace.hpp ! src/hotspot/share/gc/parallel/spaceCounters.hpp ! src/hotspot/share/gc/parallel/vmStructs_parallelgc.hpp - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/ImmutableSpace.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/MutableSpace.java Changeset: 64a150c5 Author: Sergey Bylokhov Date: 2021-01-29 06:18:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/64a150c5 6986863: ProfileDeferralMgr throwing ConcurrentModificationException Reviewed-by: kizune ! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java ! src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java - src/java.desktop/share/classes/sun/java2d/cmm/ProfileActivator.java ! src/java.desktop/share/classes/sun/java2d/cmm/ProfileDeferralInfo.java - src/java.desktop/share/classes/sun/java2d/cmm/ProfileDeferralMgr.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/java.desktop/share/native/liblcms/LCMS.c + test/jdk/java/awt/color/ICC_ProfileRGB/MTMatrixAccess.java + test/jdk/java/awt/color/ProfileActivationDuringPropertyAccess.java Changeset: 06754734 Author: Jan Lahoda Date: 2021-01-29 09:19:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/06754734 8252409: JShell: Intersection types cause NoSuchFieldError Reviewed-by: vromero ! src/jdk.jshell/share/classes/jdk/jshell/ExpressionToTypeInfo.java ! src/jdk.jshell/share/classes/jdk/jshell/TreeDissector.java ! src/jdk.jshell/share/classes/jdk/jshell/TypePrinter.java ! test/langtools/jdk/jshell/TypeNameTest.java ! test/langtools/jdk/jshell/VariablesTest.java Changeset: a81656b7 Author: duke Date: 2021-01-29 11:01:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a81656b7 Automatic merge of jdk:master into master From duke at openjdk.java.net Fri Jan 29 11:23:38 2021 From: duke at openjdk.java.net (duke) Date: Fri, 29 Jan 2021 11:23:38 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 119 new changesets Message-ID: Changeset: 58ceb254 Author: Claes Redestad Date: 2021-01-22 11:27:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/58ceb254 8259842: Remove Result cache from StringCoding Reviewed-by: naoto, plevart, rriggs ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/StringCoding.java ! src/java.base/share/classes/java/lang/System.java + test/micro/org/openjdk/bench/java/lang/StringDecode.java + test/micro/org/openjdk/bench/java/lang/StringEncode.java Changeset: bfac3fb5 Author: Aleksey Shipilev Date: 2021-01-22 11:39:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bfac3fb5 8260212: Shenandoah: resolve-only UpdateRefsMode is not used Reviewed-by: rkennke, zgu ! src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.hpp Changeset: 7ed8ba1c Author: Kim Barrett Date: 2021-01-22 13:12:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7ed8ba1c 8256814: WeakProcessorPhases may be redundant Remove WeakProcessorPhase, adding scoped enum categories to OopStorageSet. Reviewed-by: stefank, tschatzl, rkennke ! src/hotspot/share/gc/g1/g1FullGCAdjustTask.hpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp ! src/hotspot/share/gc/g1/g1RootProcessor.cpp ! src/hotspot/share/gc/shared/oopStorageSet.cpp ! src/hotspot/share/gc/shared/oopStorageSet.hpp ! src/hotspot/share/gc/shared/oopStorageSet.inline.hpp ! src/hotspot/share/gc/shared/oopStorageSetParState.hpp ! src/hotspot/share/gc/shared/oopStorageSetParState.inline.hpp ! src/hotspot/share/gc/shared/weakProcessor.cpp ! src/hotspot/share/gc/shared/weakProcessor.hpp ! src/hotspot/share/gc/shared/weakProcessor.inline.hpp - src/hotspot/share/gc/shared/weakProcessorPhase.hpp - src/hotspot/share/gc/shared/weakProcessorPhaseTimes.cpp - src/hotspot/share/gc/shared/weakProcessorPhaseTimes.hpp + src/hotspot/share/gc/shared/weakProcessorTimes.cpp + src/hotspot/share/gc/shared/weakProcessorTimes.hpp ! src/hotspot/share/gc/shenandoah/shenandoahParallelCleaning.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootVerifier.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/rootResolver.cpp ! src/hotspot/share/jfr/leakprofiler/utilities/rootType.cpp ! src/hotspot/share/jfr/leakprofiler/utilities/rootType.hpp ! src/hotspot/share/runtime/serviceThread.cpp ! test/hotspot/gtest/gc/shared/test_oopStorageSet.cpp Changeset: f928265e Author: Harold Seigel Date: 2021-01-22 13:52:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f928265e 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined Reviewed-by: lfoltan, sspitsyn, dholmes ! src/hotspot/share/oops/instanceKlass.cpp + test/hotspot/jtreg/runtime/sealedClasses/RedefinePermittedSubclass.java Changeset: acbcde8c Author: Pankaj Bansal Date: 2021-01-22 13:53:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/acbcde8c 8256111: Create implementation for NSAccessibilityStaticText protocol Reviewed-by: serb, kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonTextAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonTextAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/StaticTextAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/StaticTextAccessibility.m Changeset: 154e1d63 Author: Yasumasa Suenaga Date: 2021-01-22 14:16:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/154e1d63 8259009: G1 heap summary should be shown in "Heap Parameters" window on HSDB Reviewed-by: cjplummer, tschatzl ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1CollectedHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java Changeset: a97f3c18 Author: Kim Barrett Date: 2021-01-22 14:44:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a97f3c18 8258853: Support separate function declaration and definition with ENABLE_IF-based SFINAE Add ENABLE_IF_SDEFN, unit tests Reviewed-by: jrose, eosterlund ! src/hotspot/share/metaprogramming/enableIf.hpp ! test/hotspot/gtest/metaprogramming/test_enableIf.cpp Changeset: 18eb6d9e Author: Sean Coffey Date: 2021-01-22 15:31:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/18eb6d9e 8255348: NPE in PKIXCertPathValidator event logging code Reviewed-by: mullan ! src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! test/jdk/jdk/jfr/event/security/TestX509CertificateEvent.java ! test/jdk/jdk/jfr/event/security/TestX509ValidationEvent.java ! test/jdk/jdk/security/logging/TestX509CertificateLog.java ! test/jdk/jdk/security/logging/TestX509ValidationLog.java ! test/lib/jdk/test/lib/security/TestCertificate.java Changeset: 0ea58626 Author: Guoxiong Li Committer: Maurizio Cimadamore Date: 2021-01-22 15:47:05 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0ea58626 8260053: Optimize Tokens' use of Names Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java Changeset: bf5e8015 Author: Johannes Kuhn Committer: Mandy Chung Date: 2021-01-22 17:18:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bf5e8015 8259922: MethodHandles.collectArguments does not throw IAE if pos is outside the arity range Reviewed-by: mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java + test/jdk/java/lang/invoke/MethodHandlesCollectArgsTest.java Changeset: c5ad713e Author: Aleksey Shipilev Date: 2021-01-22 17:19:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c5ad713e 8260250: Duplicate check in DebugInformationRecorder::recorders_frozen Reviewed-by: iveresov, thartmann ! src/hotspot/share/code/debugInfoRec.cpp Changeset: 874aef4a Author: Alexey Bakhtin Committer: Daniel Fuchs Date: 2021-01-22 18:21:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/874aef4a 8259707: LDAP channel binding does not work with StartTLS extension Reviewed-by: mullan, dfuchs, aefimov ! src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java ! src/java.naming/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java Changeset: a8871776 Author: Stuart Marks Date: 2021-01-22 18:51:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a8871776 8246788: ZoneRules invariants can be broken Reviewed-by: rriggs, naoto ! src/java.base/share/classes/java/time/zone/ZoneRules.java + test/jdk/java/time/test/java/time/zone/TestMutableZoneRules.java Changeset: 53fecba7 Author: Dmitry Markov Date: 2021-01-22 19:21:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/53fecba7 8258805: Japanese characters not entered by mouse click on Windows 10 Reviewed-by: aivanov ! src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java Changeset: 5aca934c Author: Aleksey Shipilev Date: 2021-01-22 19:21:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5aca934c 8260304: (se) EPollSelectorImpl wakeup mechanism broken on Linux 32-bit Reviewed-by: bpb, alanb ! src/java.base/linux/native/libnio/ch/EventFD.c Changeset: 7be9113b Author: Dan Lemmond Committer: Paul Hohensee Date: 2021-01-22 20:33:44 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7be9113b 8255216: Change _directive->BreakAtCompileOption to env()->break_at_compile() Reviewed-by: kvn, phh ! src/hotspot/share/c1/c1_Compilation.cpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/opto/compile.cpp Changeset: bdc305e1 Author: Alex Menkov Date: 2021-01-22 21:33:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bdc305e1 8258917: NativeMemoryTracking is handled by launcher inconsistenly Reviewed-by: zgu ! src/java.base/share/native/libjli/java.c ! test/jdk/tools/launcher/TestSpecialArgs.java Changeset: aa57d07c Author: Ioi Lam Date: 2021-01-22 22:47:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/aa57d07c 8259214: MetaspaceClosure support for Arrays of MetaspaceObj Reviewed-by: fparain, ccheung ! src/hotspot/share/memory/metaspaceClosure.hpp + test/hotspot/gtest/utilities/test_metaspaceClosure.cpp Changeset: a5367cbb Author: Brian Burkhalter Committer: Henry Jen Date: 2020-07-29 09:52:13 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a5367cbb 8247619: Improve Direct Buffering of Characters Reviewed-by: alanb, ahgross, rhalade, psandoz ! src/java.base/share/classes/java/nio/Buffer.java ! src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template ! src/java.base/share/classes/java/nio/X-Buffer.java.template Changeset: 62eab505 Author: Weijun Wang Committer: Henry Jen Date: 2020-10-23 13:00:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/62eab505 8255199: Catching a few NumberFormatExceptions in xmldsig Reviewed-by: rhalade ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java ! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java Changeset: ede1beae Author: Thomas Schatzl Date: 2021-01-21 18:21:07 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ede1beae 8227695: assert(pss->trim_ticks().seconds() == 0.0) failed: Unexpected partial trimming during evacuation Change FP comparison to integer comparison. Reviewed-by: kbarrett, iwalulya, eosterlund ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp Changeset: d90e06af Author: Jie Fu Date: 2021-01-22 00:13:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d90e06af 8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation Reviewed-by: rbackman, neliasso, kvn ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86.ad + test/hotspot/jtreg/compiler/vectorapi/VectorReinterpretTest.java Changeset: 685c03dc Author: Kim Barrett Date: 2021-01-22 11:20:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/685c03dc 8259271: gc/parallel/TestDynShrinkHeap.java still fails "assert(covered_region.contains(new_memregion)) failed: new region is not in covered_region" Use load_acquire to order reads of top and end. Reviewed-by: tschatzl, iwalulya, eosterlund ! src/hotspot/share/gc/parallel/mutableSpace.cpp Changeset: 6f2a3943 Author: Jesper Wilhelmsson Date: 2021-01-23 03:15:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6f2a3943 Merge ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/java.base/share/classes/java/nio/X-Buffer.java.template ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/java.base/share/classes/java/nio/X-Buffer.java.template Changeset: 5cdcce1c Author: Ioi Lam Date: 2021-01-23 06:24:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5cdcce1c 8260307: Do not include method.hpp in frame.hpp Reviewed-by: lfoltan, coleenp ! src/hotspot/cpu/arm/interp_masm_arm.hpp ! src/hotspot/cpu/x86/interp_masm_x86.hpp ! src/hotspot/share/ci/ciInstanceKlass.hpp ! src/hotspot/share/ci/ciMethod.hpp ! src/hotspot/share/classfile/resolutionErrors.cpp ! src/hotspot/share/code/compiledMethod.hpp ! src/hotspot/share/compiler/methodMatcher.cpp ! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp ! src/hotspot/share/interpreter/abstractInterpreter.hpp ! src/hotspot/share/jvmci/jvmci_globals.cpp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/memory/metaspace/printMetaspaceInfoKlassClosure.cpp ! src/hotspot/share/memory/metaspaceCounters.cpp ! src/hotspot/share/oops/methodCounters.cpp ! src/hotspot/share/prims/jvmtiExport.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/deoptimization.hpp ! src/hotspot/share/runtime/frame.hpp ! src/hotspot/share/runtime/handles.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: f624dba6 Author: Alexey Ivanov Date: 2021-01-23 11:38:00 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f624dba6 8240247: No longer need to wrap files with contentContainer Reviewed-by: serb ! src/java.desktop/share/classes/java/awt/doc-files/AWTThreadIssues.html ! src/java.desktop/share/classes/java/awt/doc-files/DesktopProperties.html ! src/java.desktop/share/classes/java/awt/doc-files/FocusSpec.html ! src/java.desktop/share/classes/java/awt/doc-files/Modality.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/bmp_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/jpeg_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/png_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/standard_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/wbmp_metadata.html ! src/java.desktop/share/classes/javax/swing/plaf/multi/doc-files/multi_tsc.html ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html ! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html ! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html Changeset: b53d5cac Author: Alexey Ivanov Date: 2021-01-23 17:03:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b53d5cac 8260315: Typo "focul" instead of "focus" in FocusSpec.html Reviewed-by: kizune, pbansal ! src/java.desktop/share/classes/java/awt/doc-files/FocusSpec.html Changeset: 6c4c96fa Author: Kim Barrett Date: 2021-01-23 19:47:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6c4c96fa 8258742: Move PtrQueue reset to PtrQueueSet subclasses Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/g1/g1BarrierSet.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp ! src/hotspot/share/gc/shared/ptrQueue.cpp ! src/hotspot/share/gc/shared/ptrQueue.hpp ! src/hotspot/share/gc/shared/satbMarkQueue.cpp ! src/hotspot/share/gc/shared/satbMarkQueue.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp Changeset: 06348dfc Author: Kim Barrett Date: 2021-01-23 22:47:31 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/06348dfc 8259776: Remove ParallelGC non-CAS oldgen allocation Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp ! src/hotspot/share/gc/parallel/mutableNUMASpace.hpp ! src/hotspot/share/gc/parallel/mutableSpace.cpp ! src/hotspot/share/gc/parallel/mutableSpace.hpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/parallel/psOldGen.cpp ! src/hotspot/share/gc/parallel/psOldGen.hpp ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp ! src/hotspot/share/gc/parallel/psYoungGen.hpp Changeset: 535c2927 Author: Ioi Lam Date: 2021-01-24 02:40:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/535c2927 8260306: Do not include osThread.hpp in thread.hpp Reviewed-by: coleenp, lfoltan ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.inline.hpp ! src/hotspot/share/interpreter/bytecodeTracer.cpp ! src/hotspot/share/jfr/support/jfrThreadId.hpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/objectMonitor.inline.hpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/osThread.hpp ! src/hotspot/share/runtime/safepointMechanism.cpp ! src/hotspot/share/runtime/semaphore.inline.hpp ! src/hotspot/share/runtime/stackWatermark.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/vframe.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/vmError.cpp Changeset: c52c6c66 Author: Hamlin Li Date: 2021-01-25 01:05:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c52c6c66 8260273: DataOutputStream writeChars optimization Reviewed-by: rriggs, bpb, alanb ! src/java.base/share/classes/java/io/DataOutputStream.java ! test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java Changeset: 4ae39b14 Author: Hamlin Li Date: 2021-01-25 01:06:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ae39b14 8260208: Improve dummy object filling condition in G1CollectedHeap::fill_archive_regions in cds Reviewed-by: tschatzl, iklam ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp Changeset: 764111ff Author: Dongbo He Committer: Fei Yang Date: 2021-01-25 01:08:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/764111ff 8260272: bash configure --prefix does not work after JDK-8257679 Reviewed-by: erikj, ihse ! make/autoconf/util_paths.m4 Changeset: 5898ab65 Author: Ioi Lam Date: 2021-01-25 08:00:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5898ab65 8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h Reviewed-by: dholmes, coleenp ! src/hotspot/os/windows/os_perf_windows.cpp ! src/hotspot/share/ci/ciFlags.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/include/jvm.h + src/hotspot/share/include/jvm_constants.h + src/hotspot/share/include/jvm_io.h ! src/hotspot/share/logging/logSelection.cpp ! src/hotspot/share/prims/stackwalk.hpp ! src/hotspot/share/runtime/abstract_vm_version.cpp ! src/hotspot/share/runtime/flags/jvmFlag.cpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/utilities/accessFlags.hpp ! src/hotspot/share/utilities/constantTag.hpp ! src/hotspot/share/utilities/formatBuffer.hpp ! test/hotspot/gtest/logging/test_gcTraceTime.cpp ! test/hotspot/gtest/logging/test_logStream.cpp Changeset: d825339d Author: Thomas Schatzl Date: 2021-01-25 08:38:47 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d825339d 8260263: Remove PtrQueue::_qset Remove dead code related to PtrQueue::_qset and itself. Reviewed-by: kbarrett, sjohanss ! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp ! src/hotspot/share/gc/shared/ptrQueue.cpp ! src/hotspot/share/gc/shared/ptrQueue.hpp ! src/hotspot/share/gc/shared/satbMarkQueue.hpp Changeset: af155fc0 Author: Severin Gehwolf Date: 2021-01-25 08:57:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/af155fc0 8258836: JNI local refs exceed capacity getDiagnosticCommandInfo Reviewed-by: cjplummer, shade ! src/jdk.management/share/native/libmanagement_ext/DiagnosticCommandImpl.c + test/jdk/com/sun/management/DiagnosticCommandMBean/DcmdMBeanTestCheckJni.java Changeset: 09489e28 Author: Yasumasa Suenaga Date: 2021-01-25 09:12:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/09489e28 8260338: Some fields in HaltNode is not cloned Reviewed-by: xliu, neliasso, thartmann ! src/hotspot/share/opto/rootnode.cpp ! src/hotspot/share/opto/rootnode.hpp Changeset: ca20c63c Author: Thomas Stuefe Date: 2021-01-25 10:50:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ca20c63c 8259710: Inlining trace leaks memory Reviewed-by: thartmann, neliasso ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp Changeset: 6e037354 Author: Coleen Phillimore Date: 2021-01-25 13:40:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6e037354 8259845: Move placeholder implementation details to cpp file and add logging Reviewed-by: iklam, lfoltan, dholmes ! src/hotspot/share/classfile/placeholders.cpp ! src/hotspot/share/classfile/placeholders.hpp ! src/hotspot/share/logging/logTag.hpp Changeset: d076977d Author: Eric Caspole Date: 2021-01-25 14:11:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d076977d 8260169: LogCompilation: Unexpected method mismatch Reviewed-by: kvn, vlivanov ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/LogParser.java ! src/utils/LogCompilation/src/test/java/com/sun/hotspot/tools/compiler/TestLogCompilation.java Changeset: ef247ab2 Author: Dan Lutker Committer: Igor Ignatyev Date: 2021-01-25 17:16:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ef247ab2 8260308: Update LogCompilation junit to 4.13.1 Reviewed-by: ecaspole, iignatyev ! src/utils/LogCompilation/pom.xml Changeset: 47c7dc77 Author: Martin Balao Date: 2021-01-25 18:01:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/47c7dc77 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures Reviewed-by: valeriep ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PSSSignature.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Signature.java + test/jdk/sun/security/pkcs11/Cipher/CancelMultipart.java Changeset: 5b0b24b5 Author: Daniel D. Daugherty Date: 2021-01-25 18:20:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5b0b24b5 8260381: ProblemList com/sun/management/DiagnosticCommandMBean/DcmdMBeanTestCheckJni.java on Win with ZGC Reviewed-by: sspitsyn, sgehwolf ! test/jdk/ProblemList-zgc.txt Changeset: 73c78c8a Author: Joe Darcy Date: 2021-01-25 19:06:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/73c78c8a 8260329: Update references to TAOCP to latest edition Reviewed-by: alanb, bpb ! src/java.base/share/classes/java/math/MutableBigInteger.java ! src/java.base/share/classes/java/util/Random.java Changeset: 12ccd211 Author: Andrew Leonard Date: 2021-01-25 19:26:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/12ccd211 8260289: Unable to customize module lists after change JDK-8258411 Reviewed-by: ihse, alanb ! make/common/Modules.gmk Changeset: d6fb9d72 Author: Jonathan Gibbons Date: 2021-01-25 21:44:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d6fb9d72 8255464: Cannot access ModuleTree in a CompilationUnitTree Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/source/tree/CompilationUnitTree.java ! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java + test/langtools/tools/javac/tree/CompilationUnitTreeTest.java Changeset: 982e42b8 Author: Jonathan Gibbons Date: 2021-01-25 21:45:54 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/982e42b8 8259726: Use of HashSet leads to undefined order in test output Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Table.java ! test/langtools/jdk/javadoc/doclet/testAbstractMethod/TestAbstractMethod.java ! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java ! test/langtools/jdk/javadoc/doclet/testHtmlTableTags/TestHtmlTableTags.java ! test/langtools/jdk/javadoc/doclet/testInterface/TestInterface.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java ! test/langtools/jdk/javadoc/doclet/testLambdaFeature/TestLambdaFeature.java ! test/langtools/jdk/javadoc/doclet/testMemberInheritance/TestMemberInheritance.java ! test/langtools/jdk/javadoc/doclet/testMemberSummary/TestMemberSummary.java ! test/langtools/jdk/javadoc/doclet/testMethodTypes/TestMethodTypes.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModulePackages.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java ! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverrideMethods.java ! test/langtools/jdk/javadoc/doclet/testProperty/TestProperty.java ! test/langtools/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java ! test/langtools/jdk/javadoc/doclet/testTypeParams/TestTypeParameters.java ! test/langtools/jdk/javadoc/doclet/testUnnamedPackage/TestUnnamedPackage.java Changeset: 9ea93238 Author: Coleen Phillimore Date: 2021-01-25 23:58:33 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9ea93238 8254246: SymbolHashMapEntry wastes space Reviewed-by: redestad ! src/hotspot/share/oops/constantPool.hpp Changeset: c538cd8b Author: Serguei Spitsyn Date: 2021-01-26 07:15:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c538cd8b 8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs Reviewed-by: mchung, dholmes, alanb ! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java + test/jdk/java/lang/instrument/NegativeAgentRunner.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0001.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0010.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0011.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0100.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0101.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0110.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent0111.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1000.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1001.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1010.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1011.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1100.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1101.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1110.java ! test/jdk/java/lang/instrument/PremainClass/InheritAgent1111.java ! test/jdk/java/lang/instrument/PremainClass/NoPremainAgent.java - test/jdk/java/lang/instrument/PremainClass/NoPremainAgentTest.java + test/jdk/java/lang/instrument/PremainClass/NonPublicAgent.java + test/jdk/java/lang/instrument/PremainClass/NonPublicPremainAgent.java ! test/jdk/java/lang/instrument/PremainClass/ZeroArgPremainAgent.java - test/jdk/java/lang/instrument/PremainClass/ZeroArgPremainAgentTest.java Changeset: abd9310b Author: Matthias Baesken Date: 2021-01-26 07:42:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/abd9310b 8260222: remove unused _thread member SymbolTableLookup Reviewed-by: coleenp, dholmes, shade ! src/hotspot/share/classfile/symbolTable.cpp Changeset: 23edb6f6 Author: Guoxiong Li Committer: Joel Borggr?n-Franck Date: 2021-01-26 08:57:20 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/23edb6f6 8236490: Compiler bug relating to @NonNull annotation Reviewed-by: vromero, jfranck ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java + test/langtools/tools/javac/annotations/typeAnnotations/8236490/T8236490.java Changeset: b4ace3e9 Author: Thomas Schatzl Date: 2021-01-26 10:14:53 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b4ace3e9 8260042: G1 Post-cleanup liveness printing occurs too early Reviewed-by: sjohanss, iwalulya ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1Policy.cpp Changeset: 81a66dfa Author: Coleen Phillimore Date: 2021-01-26 11:50:10 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81a66dfa 8259809: Remove PerfEvent class loading locking counters Reviewed-by: redestad, iklam ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp Changeset: edd27074 Author: Aleksey Shipilev Date: 2021-01-26 13:04:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/edd27074 8260408: Shenandoah: adjust inline hints after JDK-8255019 Reviewed-by: rkennke, ihse ! make/hotspot/lib/JvmOverrideFiles.gmk Changeset: e080ce92 Author: Harold Seigel Date: 2021-01-26 13:17:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e080ce92 8252545: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java timed out Reviewed-by: stuefe, coleenp ! test/hotspot/jtreg/TEST.groups ! test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java - test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java Changeset: 5e8e0ada Author: Jan Lahoda Date: 2021-01-26 13:42:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/5e8e0ada 8242456: PreviewFeature.Feature enum removal of TEXT_BLOCKS Reviewed-by: jlaskey ! src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java Changeset: 8d2f77fd Author: Magnus Ihse Bursie Date: 2021-01-26 14:08:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8d2f77fd 8260406: Do not copy pure java source code to gensrc Reviewed-by: alanb, erikj ! make/modules/java.base/gensrc/GensrcCharacterData.gmk = src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java = src/java.base/share/classes/java/lang/CharacterDataUndefined.java Changeset: af8a08f5 Author: Severin Gehwolf Date: 2021-01-26 15:18:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/af8a08f5 8260378: [TESTBUG] DcmdMBeanTestCheckJni.java reports false positive Reviewed-by: dcubed ! test/jdk/ProblemList-zgc.txt ! test/jdk/com/sun/management/DiagnosticCommandMBean/DcmdMBeanTestCheckJni.java Changeset: b07797c2 Author: Claes Redestad Date: 2021-01-26 15:25:01 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b07797c2 8260391: Remove StringCoding::err Reviewed-by: shade, rriggs ! src/java.base/share/classes/java/lang/StringCoding.java - src/java.base/share/native/libjava/StringCoding.c Changeset: fd00ed74 Author: Zhengyu Gu Date: 2021-01-26 16:46:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fd00ed74 8256298: Shenandoah: Enable concurrent stack processing Reviewed-by: rkennke, shade ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp ! src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp ! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp + src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.cpp + src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.hpp ! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp Changeset: 9f0a0436 Author: Fernando Guallini Committer: Rajan Halade Date: 2021-01-26 18:15:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/9f0a0436 8260286: Manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails Reviewed-by: rhalade ! test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java ! test/jdk/sun/security/tools/jarsigner/warnings/Test.java Changeset: 42cef27f Author: Sergey Bylokhov Date: 2021-01-26 18:31:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/42cef27f 8260343: Delete obsolete classes in the Windows L&F Reviewed-by: aivanov, pbansal - src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsButtonListener.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java Changeset: 1bebd418 Author: Zhengyu Gu Date: 2021-01-26 20:25:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1bebd418 8260421: Shenandoah: Fix conc_mark_roots timing name and indentations Reviewed-by: rkennke, shade ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Changeset: 19b6f61b Author: Xin Liu Committer: Paul Hohensee Date: 2021-01-26 20:52:19 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/19b6f61b 8260334: Remove deprecated sv_for_node_id() from Compile Reviewed-by: neliasso, chagedorn, thartmann, phh ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/output.hpp Changeset: 6f2be9c6 Author: David Holmes Date: 2021-01-27 01:18:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/6f2be9c6 8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC Reviewed-by: ihse, erikj, gziemski, hseigel ! make/autoconf/flags-cflags.m4 ! make/autoconf/flags-ldflags.m4 ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/aix/os_aix.inline.hpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/bsd/os_bsd.hpp ! src/hotspot/os/bsd/os_bsd.inline.hpp ! src/hotspot/os/bsd/os_perf_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/linux/os_linux.inline.hpp ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/posix/os_posix.hpp ! src/hotspot/os/posix/os_posix.inline.hpp ! src/hotspot/os/windows/os_windows.inline.hpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/runtime/thread.cpp Changeset: e1411fd4 Author: Sergey Bylokhov Date: 2021-01-27 02:52:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e1411fd4 6606673: Path2D.Double, Path2D.Float and GeneralPath ctors throw exception when initialCapacity is negative Reviewed-by: psadhukhan, kizune ! src/java.desktop/share/classes/java/awt/geom/GeneralPath.java ! src/java.desktop/share/classes/java/awt/geom/Path2D.java + test/jdk/java/awt/geom/GeneralPath/GeneralPathExceptions.java + test/jdk/java/awt/geom/Path2D/Path2DExceptions.java Changeset: c836da38 Author: Martin Buchholz Date: 2021-01-27 04:31:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c836da38 8252412: [macos11] system dynamic libraries removed from filesystem Co-authored-by: Dominik R?ttsches Reviewed-by: jiangli, valeriep ! src/java.smartcardio/unix/classes/sun/security/smartcardio/PlatformPCSC.java Changeset: bd2744dd Author: Aleksey Shipilev Date: 2021-01-27 07:17:30 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bd2744dd 8260106: Shenandoah: refactor reference updating closures and related code Reviewed-by: zgu, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMark.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.hpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp Changeset: 1c770468 Author: Thomas Stuefe Date: 2021-01-27 07:34:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1c770468 8260404: jvm_io.h include missing in a number of files Reviewed-by: shade, iklam, dholmes ! src/hotspot/os/posix/perfMemory_posix.cpp ! src/hotspot/share/aot/aotCodeHeap.cpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/jfr/jni/jfrUpcalls.cpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleDescription.cpp ! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/hotspot/share/jvmci/jvmciRuntime.hpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/runtime/handshake.cpp Changeset: fd2641ed Author: Matthias Baesken Date: 2021-01-27 07:57:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fd2641ed 8260236: better init AnnotationCollector _contended_group Reviewed-by: coleenp, shade ! src/hotspot/share/classfile/classFileParser.cpp Changeset: 4d004c94 Author: Roman Kennke Date: 2021-01-27 09:32:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4d004c94 8260449: Remove stale declaration of SATBMarkQueue::apply_closure_and_empty() Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/satbMarkQueue.hpp Changeset: fa40a966 Author: Albert Mingkun Yang Committer: Stefan Johansson Date: 2021-01-27 09:57:24 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/fa40a966 8253420: Refactor HeapRegionManager::find_highest_free Reviewed-by: sjohanss, kbarrett ! src/hotspot/share/gc/g1/heapRegionManager.cpp Changeset: 3e4194c4 Author: Thomas Stuefe Date: 2021-01-27 10:43:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3e4194c4 8260022: [ppc] os::print_function_and_library_name shall resolve function descriptors transparently Reviewed-by: mdoerr, lucy ! src/hotspot/cpu/ppc/assembler_ppc.hpp ! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp ! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.hpp ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.hpp ! src/hotspot/share/runtime/os.cpp Changeset: bf15c709 Author: Aleksey Shipilev Date: 2021-01-27 10:48:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bf15c709 8260460: GitHub actions still fail on Linux x86_32 with "Could not configure libc6:i386" Reviewed-by: ihse ! .github/workflows/submit.yml Changeset: b3c8a528 Author: Jan Lahoda Date: 2021-01-27 11:00:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b3c8a528 8259050: Error recovery in lexer could be improved Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java ! test/langtools/tools/javac/lexer/JavaLexerTest.java ! test/langtools/tools/javac/parser/JavacParserTest.java Changeset: e696baab Author: Claes Redestad Date: 2021-01-27 11:30:28 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e696baab 8260448: Simplify ManagementFactory$PlatformMBeanFinder Reviewed-by: mchung, dfuchs ! src/java.management/share/classes/java/lang/management/ManagementFactory.java Changeset: 7ed591cc Author: Alexey Ivanov Date: 2021-01-27 12:09:48 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7ed591cc 8260314: Replace border="1" on tables with CSS Reviewed-by: serb ! src/java.desktop/share/classes/java/awt/doc-files/DesktopProperties.html ! src/java.desktop/share/classes/java/awt/doc-files/Modality.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html ! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html ! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html ! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html Changeset: ac276bb3 Author: Chris Hegarty Date: 2021-01-27 14:09:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ac276bb3 8257074: Update the ByteBuffers micro benchmark Reviewed-by: redestad, dfuchs, jvernee, bpb ! test/micro/org/openjdk/bench/java/nio/ByteBuffers.java ! test/micro/org/openjdk/bench/java/nio/CharBuffers.java + test/micro/org/openjdk/bench/java/nio/DoubleBuffers.java + test/micro/org/openjdk/bench/java/nio/FloatBuffers.java + test/micro/org/openjdk/bench/java/nio/IntBuffers.java + test/micro/org/openjdk/bench/java/nio/LongBuffers.java + test/micro/org/openjdk/bench/java/nio/ShortBuffers.java + test/micro/org/openjdk/bench/java/nio/X-Buffers-bin.java.template + test/micro/org/openjdk/bench/java/nio/X-Buffers.java.template + test/micro/org/openjdk/bench/java/nio/X-ByteBuffers-bin.java.template + test/micro/org/openjdk/bench/java/nio/genBuffers.sh Changeset: f353fcf2 Author: Roberto Casta?eda Lozano Committer: Tobias Hartmann Date: 2021-01-27 15:08:39 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/f353fcf2 8258894: C2: Forbid GCM to move stores into loops Prevent GCM from placing memory-writing nodes (such as stores) into loops deeper than their home loop (determined by their control input). Such placements are invalid, as they cause memory definitions to interfere, and risk causing miscompilations. This change complements JDK-8255763, which only addresses invalid placements in irreducible CFGs. Add control input to stores in generated stubs to ensure that all memory-writing nodes have control inputs from which their home block can be derived. Add a battery of simplified fuzzer test cases where, before this change, GCM moves stores into deeper loops. Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/block.cpp ! src/hotspot/share/opto/block.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/gcm.cpp ! src/hotspot/share/opto/generateOptoStub.cpp ! src/hotspot/share/opto/node.hpp ! test/hotspot/jtreg/compiler/codegen/TestGCMStorePlacement.java Changeset: 311a0a91 Author: Denghui Dong Committer: Thomas Schatzl Date: 2021-01-27 15:28:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/311a0a91 8259808: Add JFR event to detect GC locker stall Reviewed-by: sjohanss, tschatzl, egahlin ! src/hotspot/share/gc/shared/gcLocker.cpp ! src/hotspot/share/gc/shared/gcTrace.hpp ! src/hotspot/share/gc/shared/gcTraceSend.cpp ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/prims/whitebox.cpp ! src/jdk.jfr/share/conf/jfr/default.jfc ! src/jdk.jfr/share/conf/jfr/profile.jfc + test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java ! test/lib/jdk/test/lib/jfr/EventNames.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: 684c8558 Author: Daniel D. Daugherty Date: 2021-01-27 17:26:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/684c8558 8260524: validate-source fails on test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java Reviewed-by: bpb, iignatyev ! src/hotspot/share/gc/shared/gcLocker.cpp ! src/hotspot/share/gc/shared/gcTrace.hpp ! src/hotspot/share/gc/shared/gcTraceSend.cpp ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/prims/whitebox.cpp ! test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java ! test/lib/jdk/test/lib/jfr/EventNames.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: 0eed2c33 Author: Guoxiong Li Committer: Vicente Romero Date: 2021-01-27 18:12:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/0eed2c33 8259359: javac does not attribute unexpected super constructor invocation qualifier, and may crash Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java + test/langtools/tools/javac/recovery/T8259359.java Changeset: eb923685 Author: Stuart Marks Date: 2021-01-27 19:02:49 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/eb923685 8259816: Typo in java.util.stream package description Reviewed-by: iris, lancea, naoto ! src/java.base/share/classes/java/util/stream/package-info.java Changeset: c5ab7c32 Author: Christian Hagedorn Date: 2021-01-25 17:09:52 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c5ab7c32 8260284: C2: assert(_base == Int) failed: Not an Int Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/phaseX.cpp + test/hotspot/jtreg/compiler/loopopts/TestDivWithTopDivisor.java Changeset: 81e730e5 Author: Vladimir Ivanov Date: 2021-01-25 20:02:56 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81e730e5 8259276: C2: Empty expression stack when reexecuting tableswitch/lookupswitch instructions after deoptimization Reviewed-by: dlong, kvn, thartmann ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/parse2.cpp Changeset: 408772c9 Author: Vicente Romero Date: 2021-01-26 16:00:41 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/408772c9 8259025: Record compact constructor using Objects.requireNonNull Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/langtools/tools/javac/records/RecordCompilationTests.java Changeset: c52212b1 Author: Jesper Wilhelmsson Date: 2021-01-27 20:56:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c52212b1 Merge ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/parse2.cpp ! src/hotspot/share/opto/phaseX.cpp Changeset: c7661aed Author: Roger Riggs Date: 2021-01-27 22:37:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/c7661aed 8260561: [doc] HexFormat has incorrect @since tag Reviewed-by: darcy, naoto, bpb, lancea ! src/java.base/share/classes/java/util/HexFormat.java Changeset: 7030d2e0 Author: Hamlin Li Date: 2021-01-28 00:45:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/7030d2e0 8260200: G1: Remove unnecessary update in FreeRegionList::remove_starting_at Reviewed-by: ayang, sjohanss, tschatzl ! src/hotspot/share/gc/g1/heapRegionSet.cpp ! src/hotspot/share/gc/g1/heapRegionSet.hpp Changeset: e28e1111 Author: Vladimir Ivanov Date: 2021-01-27 10:29:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/e28e1111 8260370: C2: LoopLimit node is not eliminated Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/loopnode.cpp Changeset: 62ffe75b Author: Jesper Wilhelmsson Date: 2021-01-28 03:38:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/62ffe75b Merge ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/loopnode.cpp Changeset: 396a496f Author: Ioi Lam Date: 2021-01-28 04:24:04 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/396a496f 8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp Reviewed-by: dholmes, coleenp ! src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp ! src/hotspot/cpu/aarch64/methodHandles_aarch64.hpp ! src/hotspot/cpu/arm/methodHandles_arm.cpp ! src/hotspot/cpu/arm/methodHandles_arm.hpp ! src/hotspot/cpu/ppc/methodHandles_ppc.cpp ! src/hotspot/cpu/ppc/methodHandles_ppc.hpp ! src/hotspot/cpu/s390/methodHandles_s390.cpp ! src/hotspot/cpu/s390/methodHandles_s390.hpp ! src/hotspot/cpu/x86/methodHandles_x86.cpp ! src/hotspot/cpu/x86/methodHandles_x86.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciObjArrayKlass.cpp ! src/hotspot/share/ci/ciObjectFactory.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp + src/hotspot/share/classfile/vmClassID.hpp + src/hotspot/share/classfile/vmClassMacros.hpp + src/hotspot/share/classfile/vmClasses.cpp + src/hotspot/share/classfile/vmClasses.hpp ! src/hotspot/share/memory/archiveBuilder.cpp ! src/hotspot/share/memory/archiveBuilder.hpp ! src/hotspot/share/memory/filemap.cpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/prims/methodHandles.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/vmEnums.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbPrintStatics.java Changeset: 11a70d11 Author: Matthias Baesken Date: 2021-01-28 07:35:58 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/11a70d11 8260426: awt debug_mem.c DMem_AllocateBlock might leak memory Reviewed-by: psadhukhan, aivanov ! src/java.desktop/share/native/common/awt/debug/debug_mem.c Changeset: 316d52c1 Author: Roman Kennke Date: 2021-01-28 09:50:21 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/316d52c1 8260497: Shenandoah: Improve SATB flushing Reviewed-by: shade, zgu ! src/hotspot/share/gc/shared/satbMarkQueue.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Changeset: a97aedff Author: Aleksey Shipilev Date: 2021-01-28 10:24:37 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a97aedff 8256215: Shenandoah: re-organize saving/restoring machine state in assembler code Reviewed-by: rkennke, zgu ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp Changeset: ecde52ec Author: Claes Redestad Date: 2021-01-28 11:13:26 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ecde52ec 8260506: VersionHelper cleanup Reviewed-by: alanb, dfuchs, aefimov ! src/java.naming/share/classes/com/sun/naming/internal/VersionHelper.java Changeset: 8fe1323d Author: Claes Redestad Date: 2021-01-28 11:14:35 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/8fe1323d 8260520: Avoid getting permissions in JarFileFactory when no SecurityManager installed Reviewed-by: alanb, dfuchs, michaelm, mullan ! src/java.base/unix/classes/sun/net/www/protocol/jar/JarFileFactory.java ! src/java.base/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java Changeset: 87522573 Author: Martin Doerr Date: 2021-01-28 11:39:06 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/87522573 8260502: [s390] NativeMovRegMem::verify() fails because it's too strict Reviewed-by: lucy, rrich ! src/hotspot/cpu/s390/nativeInst_s390.cpp ! src/hotspot/cpu/s390/nativeInst_s390.hpp Changeset: a68c6c2a Author: Aleksey Shipilev Date: 2021-01-28 12:00:59 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a68c6c2a 8260579: PPC64 and S390 builds failures after JDK-8260467 Reviewed-by: mdoerr ! src/hotspot/cpu/ppc/methodHandles_ppc.cpp ! src/hotspot/cpu/s390/methodHandles_s390.cpp Changeset: d07af2b8 Author: Jorn Vernee Date: 2021-01-28 12:26:32 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d07af2b8 8255531: MethodHandles::permuteArguments throws NPE when duplicating dropped arguments Reviewed-by: redestad ! src/java.base/share/classes/java/lang/invoke/LambdaFormBuffer.java ! test/jdk/java/lang/invoke/MethodHandlesPermuteArgumentsTest.java Changeset: 11d6467c Author: Roland Westrelin Date: 2021-01-28 12:27:40 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/11d6467c 8260407: cmp != __null && cmp->Opcode() == Op_CmpL failure with -XX:StressLongCountedLoop=200000000 in lucene Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/loopopts.cpp + test/hotspot/jtreg/compiler/longcountedloops/TestLongCountedLoopSplitIf.java Changeset: 20e7df50 Author: Harold Seigel Date: 2021-01-28 13:17:22 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/20e7df50 8260466: Test TestHeapDumpOnOutOfMemoryError.java needs multiple @test sections Reviewed-by: shade, lmesnik ! test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java Changeset: baf46bac Author: Sean Mullan Date: 2021-01-28 14:28:27 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/baf46bac 8259801: Enable XML Signature secure validation mode by default Reviewed-by: weijun, rhalade ! src/java.base/share/conf/security/java.security ! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/dom/DOMValidateContext.java ! test/jdk/javax/xml/crypto/dsig/GenerationTests.java Changeset: 13ca433f Author: Patrick Concannon Date: 2021-01-28 15:01:38 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/13ca433f 8259628: jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java fails intermittently Reviewed-by: dfuchs ! test/jdk/jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java Changeset: abc4300d Author: Poonam Bajaj Date: 2021-01-28 15:07:03 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/abc4300d 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines Reviewed-by: hseigel ! src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java Changeset: 3aabbd72 Author: Matthias Baesken Date: 2021-01-28 15:20:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/3aabbd72 8260432: allocateSpaceForGP in freetypeScaler.c might leak memory Reviewed-by: shade, stuefe ! src/java.desktop/share/native/libfontmanager/freetypeScaler.c Changeset: bbbfaa58 Author: Calvin Cheung Date: 2021-01-28 16:17:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/bbbfaa58 8249262: Initialize InstanceKlass::_package_entry during CDS dump time Reviewed-by: iklam, minqi ! src/hotspot/share/classfile/classLoaderDataShared.cpp ! src/hotspot/share/classfile/classLoaderDataShared.hpp ! src/hotspot/share/classfile/packageEntry.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/oops/instanceKlass.cpp Changeset: 1de3c554 Author: Aleksey Shipilev Date: 2021-01-28 16:31:45 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/1de3c554 8260584: Shenandoah: simplify "Concurrent Thread Roots" logging Reviewed-by: rkennke, zgu ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Changeset: 2b166d81 Author: Weijun Wang Date: 2021-01-28 17:54:09 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/2b166d81 8260596: Comment cleanup in BigInteger Reviewed-by: bpb ! src/java.base/share/classes/java/math/BigInteger.java Changeset: 81e9e6a7 Author: Martin Buchholz Date: 2021-01-28 18:06:55 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/81e9e6a7 8260461: Modernize jsr166 tck tests Reviewed-by: dl ! test/jdk/java/util/concurrent/tck/AbstractExecutorServiceTest.java ! test/jdk/java/util/concurrent/tck/AbstractQueueTest.java ! test/jdk/java/util/concurrent/tck/ArrayBlockingQueueTest.java ! test/jdk/java/util/concurrent/tck/ArrayDeque8Test.java ! test/jdk/java/util/concurrent/tck/ArrayDequeTest.java ! test/jdk/java/util/concurrent/tck/ArrayListTest.java ! test/jdk/java/util/concurrent/tck/Atomic8Test.java ! test/jdk/java/util/concurrent/tck/AtomicBooleanTest.java ! test/jdk/java/util/concurrent/tck/AtomicIntegerArrayTest.java ! test/jdk/java/util/concurrent/tck/AtomicIntegerTest.java ! test/jdk/java/util/concurrent/tck/AtomicLongArrayTest.java ! test/jdk/java/util/concurrent/tck/AtomicLongTest.java ! test/jdk/java/util/concurrent/tck/AtomicMarkableReferenceTest.java ! test/jdk/java/util/concurrent/tck/AtomicReference9Test.java ! test/jdk/java/util/concurrent/tck/AtomicReferenceArray9Test.java ! test/jdk/java/util/concurrent/tck/AtomicReferenceArrayTest.java ! test/jdk/java/util/concurrent/tck/AtomicReferenceFieldUpdaterTest.java ! test/jdk/java/util/concurrent/tck/AtomicReferenceTest.java ! test/jdk/java/util/concurrent/tck/AtomicStampedReferenceTest.java ! test/jdk/java/util/concurrent/tck/BlockingQueueTest.java ! test/jdk/java/util/concurrent/tck/Collection8Test.java ! test/jdk/java/util/concurrent/tck/CompletableFutureTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentHashMap8Test.java ! test/jdk/java/util/concurrent/tck/ConcurrentHashMapTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentLinkedDequeTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentLinkedQueueTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentSkipListMapTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentSkipListSetTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentSkipListSubMapTest.java ! test/jdk/java/util/concurrent/tck/ConcurrentSkipListSubSetTest.java ! test/jdk/java/util/concurrent/tck/CopyOnWriteArrayListTest.java ! test/jdk/java/util/concurrent/tck/CopyOnWriteArraySetTest.java ! test/jdk/java/util/concurrent/tck/CountedCompleterTest.java ! test/jdk/java/util/concurrent/tck/DelayQueueTest.java ! test/jdk/java/util/concurrent/tck/ExchangerTest.java ! test/jdk/java/util/concurrent/tck/ExecutorCompletionService9Test.java ! test/jdk/java/util/concurrent/tck/ExecutorCompletionServiceTest.java ! test/jdk/java/util/concurrent/tck/ExecutorsTest.java ! test/jdk/java/util/concurrent/tck/ForkJoinPool8Test.java ! test/jdk/java/util/concurrent/tck/ForkJoinPoolTest.java ! test/jdk/java/util/concurrent/tck/ForkJoinTask8Test.java ! test/jdk/java/util/concurrent/tck/ForkJoinTaskTest.java ! test/jdk/java/util/concurrent/tck/FutureTaskTest.java + test/jdk/java/util/concurrent/tck/Item.java ! test/jdk/java/util/concurrent/tck/JSR166TestCase.java ! test/jdk/java/util/concurrent/tck/LinkedBlockingDeque8Test.java ! test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java ! test/jdk/java/util/concurrent/tck/LinkedBlockingQueue8Test.java ! test/jdk/java/util/concurrent/tck/LinkedBlockingQueueTest.java ! test/jdk/java/util/concurrent/tck/LinkedListTest.java ! test/jdk/java/util/concurrent/tck/LinkedTransferQueueTest.java ! test/jdk/java/util/concurrent/tck/MapTest.java ! test/jdk/java/util/concurrent/tck/NonNestmates.java ! test/jdk/java/util/concurrent/tck/PhaserTest.java ! test/jdk/java/util/concurrent/tck/PriorityBlockingQueueTest.java ! test/jdk/java/util/concurrent/tck/PriorityQueueTest.java ! test/jdk/java/util/concurrent/tck/RecursiveActionTest.java ! test/jdk/java/util/concurrent/tck/RecursiveTaskTest.java ! test/jdk/java/util/concurrent/tck/ScheduledExecutorSubclassTest.java ! test/jdk/java/util/concurrent/tck/ScheduledExecutorTest.java ! test/jdk/java/util/concurrent/tck/StampedLockTest.java ! test/jdk/java/util/concurrent/tck/SubmissionPublisherTest.java ! test/jdk/java/util/concurrent/tck/SynchronousQueueTest.java ! test/jdk/java/util/concurrent/tck/ThreadLocalTest.java ! test/jdk/java/util/concurrent/tck/ThreadPoolExecutorSubclassTest.java ! test/jdk/java/util/concurrent/tck/ThreadPoolExecutorTest.java ! test/jdk/java/util/concurrent/tck/TreeMapTest.java ! test/jdk/java/util/concurrent/tck/TreeSetTest.java ! test/jdk/java/util/concurrent/tck/TreeSubMapTest.java ! test/jdk/java/util/concurrent/tck/TreeSubSetTest.java ! test/jdk/java/util/concurrent/tck/VectorTest.java Changeset: 71128cf4 Author: Aleksey Shipilev Date: 2021-01-28 19:04:50 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/71128cf4 8260586: Shenandoah: simplify "Concurrent Weak References" logging Reviewed-by: rkennke, zgu ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Changeset: 15196325 Author: Igor Veresov Date: 2021-01-28 20:51:12 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/15196325 8251462: Simplify compilation policy Reviewed-by: cjplummer, kvn ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_globals_aarch64.hpp ! src/hotspot/cpu/aarch64/c2_globals_aarch64.hpp ! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp ! src/hotspot/cpu/aarch64/globals_aarch64.hpp ! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/arm/globals_arm.hpp ! src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/ppc/c1_globals_ppc.hpp ! src/hotspot/cpu/ppc/c2_globals_ppc.hpp ! src/hotspot/cpu/ppc/interp_masm_ppc.hpp ! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/s390/c1_globals_s390.hpp ! src/hotspot/cpu/s390/c2_globals_s390.hpp ! src/hotspot/cpu/s390/templateInterpreterGenerator_s390.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp ! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/c1_globals_x86.hpp ! src/hotspot/cpu/x86/c2_globals_x86.hpp ! src/hotspot/cpu/x86/globalDefinitions_x86.hpp ! src/hotspot/cpu/x86/globals_x86.hpp ! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/zero/globals_zero.hpp ! src/hotspot/share/aot/aotCodeHeap.cpp ! src/hotspot/share/aot/aotCompiledMethod.cpp ! src/hotspot/share/aot/aotCompiledMethod.hpp ! src/hotspot/share/c1/c1_Compilation.cpp ! src/hotspot/share/c1/c1_Compilation.hpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_LIRAssembler.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_Runtime1.cpp ! src/hotspot/share/c1/c1_globals.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/compiler/compilationPolicy.cpp ! src/hotspot/share/compiler/compilationPolicy.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileTask.cpp ! src/hotspot/share/compiler/compilerDefinitions.cpp ! src/hotspot/share/compiler/compilerDefinitions.hpp ! src/hotspot/share/compiler/compilerDirectives.cpp ! src/hotspot/share/compiler/compiler_globals.hpp ! src/hotspot/share/compiler/oopMap.cpp - src/hotspot/share/compiler/tieredThresholdPolicy.cpp - src/hotspot/share/compiler/tieredThresholdPolicy.hpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/interpreterRuntime.hpp ! src/hotspot/share/interpreter/invocationCounter.cpp ! src/hotspot/share/interpreter/invocationCounter.hpp ! src/hotspot/share/interpreter/templateInterpreterGenerator.hpp ! src/hotspot/share/jvmci/compilerRuntime.cpp ! src/hotspot/share/jvmci/jvmciCompiler.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/oops/methodCounters.cpp ! src/hotspot/share/oops/methodCounters.hpp ! src/hotspot/share/oops/methodData.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/abstract_vm_version.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp ! src/hotspot/share/runtime/globals_shared.hpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/macros.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Method.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodCounters.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodData.java ! test/hotspot/jtreg/TEST.quick-groups ! test/hotspot/jtreg/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java ! test/hotspot/jtreg/compiler/whitebox/ClearMethodStateTest.java ! test/hotspot/jtreg/compiler/whitebox/CompilerWhiteBoxTest.java - test/hotspot/jtreg/vmTestbase/jit/tiered/Test.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/MyThread.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.java Changeset: 251c6419 Author: Kim Barrett Date: 2021-01-29 03:34:02 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/251c6419 8259487: Remove unused StarTask Reviewed-by: iklam, tschatzl ! src/hotspot/share/gc/shared/taskqueue.hpp Changeset: ea2c4474 Author: Kim Barrett Date: 2021-01-29 03:49:57 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/ea2c4474 8259778: Merge MutableSpace and ImmutableSpace Reviewed-by: sspitsyn, dholmes, tschatzl - src/hotspot/share/gc/parallel/immutableSpace.cpp - src/hotspot/share/gc/parallel/immutableSpace.hpp ! src/hotspot/share/gc/parallel/mutableSpace.cpp ! src/hotspot/share/gc/parallel/mutableSpace.hpp ! src/hotspot/share/gc/parallel/spaceCounters.hpp ! src/hotspot/share/gc/parallel/vmStructs_parallelgc.hpp - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/ImmutableSpace.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/parallel/MutableSpace.java Changeset: 64a150c5 Author: Sergey Bylokhov Date: 2021-01-29 06:18:43 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/64a150c5 6986863: ProfileDeferralMgr throwing ConcurrentModificationException Reviewed-by: kizune ! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java ! src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java - src/java.desktop/share/classes/sun/java2d/cmm/ProfileActivator.java ! src/java.desktop/share/classes/sun/java2d/cmm/ProfileDeferralInfo.java - src/java.desktop/share/classes/sun/java2d/cmm/ProfileDeferralMgr.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/java.desktop/share/native/liblcms/LCMS.c + test/jdk/java/awt/color/ICC_ProfileRGB/MTMatrixAccess.java + test/jdk/java/awt/color/ProfileActivationDuringPropertyAccess.java Changeset: 06754734 Author: Jan Lahoda Date: 2021-01-29 09:19:14 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/06754734 8252409: JShell: Intersection types cause NoSuchFieldError Reviewed-by: vromero ! src/jdk.jshell/share/classes/jdk/jshell/ExpressionToTypeInfo.java ! src/jdk.jshell/share/classes/jdk/jshell/TreeDissector.java ! src/jdk.jshell/share/classes/jdk/jshell/TypePrinter.java ! test/langtools/jdk/jshell/TypeNameTest.java ! test/langtools/jdk/jshell/VariablesTest.java Changeset: a81656b7 Author: duke Date: 2021-01-29 11:01:08 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a81656b7 Automatic merge of jdk:master into master Changeset: 95b9ef9d Author: duke Date: 2021-01-29 11:01:29 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/95b9ef9d Automatic merge of master into foreign-memaccess+abi Changeset: 4bfb2c3f Author: duke Date: 2021-01-29 11:01:46 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4bfb2c3f Automatic merge of foreign-memaccess+abi into foreign-jextract From jvernee at openjdk.java.net Fri Jan 29 12:04:01 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 29 Jan 2021 12:04:01 GMT Subject: [foreign-memaccess+abi] RFR: Add stack walk test case that doesn't verify oops In-Reply-To: References: <2dC5iNW2JzprohQhvxGLIBOyPU-dKkXNppcVCrYpCis=.cd68e19a-e7d0-41ed-8fb6-f4548a9042ef@github.com> Message-ID: On Thu, 28 Jan 2021 18:49:44 GMT, Vladimir Ivanov wrote: >> This is a followup for the earlier quickfix of: https://github.com/openjdk/panama-foreign/pull/417 >> >> This adds another test case to TestStackWalk that catches the failing code path. >> >> This re-uses the previously added `WhiteBox::verifyFrames`, and adds a flag to turn off the verification, which triggers the problematic code path. (I've also renamed this to just `walkFrames`, since now we don't always do verification anymore. > > src/hotspot/share/prims/whitebox.cpp line 2293: > >> 2291: tty->print_cr("[WhiteBox::WalkFrames] Walking Frames"); >> 2292: } >> 2293: for (StackFrameStream fst(JavaThread::current(), verify_oops, true); !fst.is_done(); fst.next()) { > > Can you elaborate, please, why `verify_oops` is equivalent to `RegisterMap::_update_map`? If the register map is not updated, we can't do the call to `frame::verify` below that, which currently only verifies oops in the frame. I thought that the name `verify_oops` would best describe the functionality of the parameter in general, but maybe I've got that backwards... I use it specifically to turn off `RegisterMap::_update_map` after all. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/423 From jvernee at openjdk.java.net Fri Jan 29 12:15:56 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 29 Jan 2021 12:15:56 GMT Subject: [foreign-memaccess+abi] RFR: Add stack walk test case that doesn't verify oops In-Reply-To: References: <2dC5iNW2JzprohQhvxGLIBOyPU-dKkXNppcVCrYpCis=.cd68e19a-e7d0-41ed-8fb6-f4548a9042ef@github.com> Message-ID: On Fri, 29 Jan 2021 12:00:40 GMT, Jorn Vernee wrote: >> src/hotspot/share/prims/whitebox.cpp line 2293: >> >>> 2291: tty->print_cr("[WhiteBox::WalkFrames] Walking Frames"); >>> 2292: } >>> 2293: for (StackFrameStream fst(JavaThread::current(), verify_oops, true); !fst.is_done(); fst.next()) { >> >> Can you elaborate, please, why `verify_oops` is equivalent to `RegisterMap::_update_map`? > > If the register map is not updated, we can't do the call to `frame::verify` below that, which currently only verifies oops in the frame. I thought that the name `verify_oops` would best describe the functionality of the parameter in general, but maybe I've got that backwards... I use it specifically to turn off `RegisterMap::_update_map` after all. Renaming this to `update_reg_map_and_verify_oops` a bit of a mouth full maybe, but want to make clear that oop verification only happens when the flag is set. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/423 From maurizio.cimadamore at oracle.com Fri Jan 29 12:41:26 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 29 Jan 2021 12:41:26 +0000 Subject: [foreign-jextract] Duplicated interface declarations when using typedefs for function pointers In-Reply-To: <70c6242355f75f242c3c9a611a04e7e2414f6734.camel@oracle.com> References: <5c613b22-d0dc-56e5-875e-6153178d6b41@hhu.de> <1614976372c35ba935f8ee8457bd4af8795837e1.camel@oracle.com> <70c6242355f75f242c3c9a611a04e7e2414f6734.camel@oracle.com> Message-ID: <38476791ec13e7ca4add2707e82dd5c74ce0616c.camel@oracle.com> On Thu, 2021-01-28 at 18:57 +0000, Maurizio Cimadamore wrote: > Filed this: > > https://bugs.openjdk.java.net/browse/JDK-8260602 > > Thanks for the report! > > Maurizio This has been fixed now. We realized that some of the jextract samples in our document [1] were also referring to suboptimal functional interface names. We will fix the document shortly. Thanks again. Maurizio [1] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_jextract.md > > > On Thu, 2021-01-28 at 17:57 +0000, Maurizio Cimadamore wrote: > > This seems odd. But I guess I can see why jextract ends up doing > > that. > > > > I think what jextract *should* do is to reuse the interface for > > `callback_t` whenever possible (which should be declared at the > > toplevel). > > > > In other words, it seems like jextract is re-generating a new > > interface > > every time it encounters a reference to a function pointer typedef, > > which seems a bug. > > > > Maurizio > > > > > > > > On Thu, 2021-01-28 at 18:48 +0100, Filip Krakowski wrote: > > > Hi, > > > > > > I just noticed that jextract generates duplicate code > > > (interfaces) > > > for > > > function pointers within each struct instead at the top-level. > > > Each interface's name seems to have a suffix based on the > > > occurrence > > > of > > > the declaration in the source file. > > > > > > typedef void (*callback_t)(void *arg); > > > > > > typedef struct first_handler { > > > callback_t cb; > > > } first_handler_t; > > > > > > typedef struct second_handler { > > > callback_t cb; > > > } second_handler_t; > > > > > > This code generates the following java source code. > > > > > > @C("struct first_handler")public static class first_handler { > > > ... > > > public static interface cb { > > > > > > void apply(jdk.incubator.foreign.MemoryAddress > > > x0); > > > > > > public static @C("callback_t") MemorySegment > > > allocate(cb fi) { > > > return RuntimeHelper.upcallStub(cb.class, > > > fi, > > > ucx_h_constants_0.cb$FUNC(), > > > "(Ljdk/incubator/foreign/MemoryAddress;)V"); > > > } > > > > > > public static @C("callback_t") MemorySegment > > > allocate(cb fi, NativeScope scope) { > > > return allocate(fi).handoff(scope); > > > } > > > } > > > ... > > > } > > > > > > @C("struct second_handler")public static class second_handler > > > { > > > ... > > > public static interface cb$0 { > > > > > > void apply(jdk.incubator.foreign.MemoryAddress > > > x0); > > > > > > public static @C("callback_t") MemorySegment > > > allocate(cb$0 fi) { > > > return RuntimeHelper.upcallStub(cb$0.class, > > > fi, > > > ucx_h_constants_0.cb$0$FUNC(), > > > "(Ljdk/incubator/foreign/MemoryAddress;)V"); > > > } > > > > > > public static @C("callback_t") MemorySegment > > > allocate(cb$0 fi, NativeScope scope) { > > > return allocate(fi).handoff(scope); > > > } > > > } > > > ... > > > } > > > > > > From my point of view both interfaces are identical. Is there a > > > reason > > > for placing them inside the struct class? > > > > > > > > > Best regards > > > Filip > > > > > > From mcimadamore at openjdk.java.net Fri Jan 29 12:42:54 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 29 Jan 2021 12:42:54 GMT Subject: [foreign-jextract] Integrated: 8260602: jextract generates redundant functional interafces In-Reply-To: <1knXBUwBzGGK7IxosTzXmcxCd82WUe6lXZbykE0Q38g=.a5549fc7-5f95-473f-9852-0ee0d05f730d@github.com> References: <1knXBUwBzGGK7IxosTzXmcxCd82WUe6lXZbykE0Q38g=.a5549fc7-5f95-473f-9852-0ee0d05f730d@github.com> Message-ID: On Thu, 28 Jan 2021 18:56:29 GMT, Maurizio Cimadamore wrote: > There seems to be an issue in how jextract handles function pointer typedef. > > Currently, these typedefs are handled in two places: > > * OutputFactory::visitVar > * OutputFactory::visitFunction > > That is, if a variable (struct field or global), or a function parameter is seen to have a typedef of a function pointer, jextract will generate a functional interface _exactly at that point_ where the variable is found. This might be inside a struct. > > Now, what we really want is slightly different: the functional interface for a function pointer typedef should really be generated in the toplevel interface hierarchy; any other reference to it (from struct fields, or function parameters, or globals) should _not_ result in additional functional interface declaration. > > In other words, in this example [1]: > > typedef void (*callback_t)(void *arg); > > typedef struct first_handler { > callback_t cb; > } first_handler_t; > > typedef struct second_handler { > callback_t cb; > } second_handler_t; > > There should be (in the user perspective) only _one_ functional interface, and its name should just be `callback_t`. > > The fix is to make OutputFactory::getAsFunctionPointer non-transparent w.r.t. typedefs - that is, if a typedef is found, that method should just return null (so that the enclosing code will skip functional interface generation). To counter balance that, we need to add logic for functional interface declaration inside OutputFactory::visitTypedef. > > I did not add any new test, since it turns out we already had a test for this (LibTest8258605Test) whose code was referring to the same typedef-ed function pointer using two names - this fix rectifies that behavior, and the test is now updated. > > [1] - https://mail.openjdk.java.net/pipermail/panama-dev/2021-January/011948.html This pull request has now been integrated. Changeset: c26ad46b Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/panama-foreign/commit/c26ad46b Stats: 13 lines in 3 files changed: 9 ins; 0 del; 4 mod 8260602: jextract generates redundant functional interafces Reviewed-by: sundar ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/442 From jvernee at openjdk.java.net Fri Jan 29 12:45:12 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 29 Jan 2021 12:45:12 GMT Subject: [foreign-memaccess+abi] RFR: Add stack walk test case that doesn't verify oops [v2] In-Reply-To: <2dC5iNW2JzprohQhvxGLIBOyPU-dKkXNppcVCrYpCis=.cd68e19a-e7d0-41ed-8fb6-f4548a9042ef@github.com> References: <2dC5iNW2JzprohQhvxGLIBOyPU-dKkXNppcVCrYpCis=.cd68e19a-e7d0-41ed-8fb6-f4548a9042ef@github.com> Message-ID: > This is a followup for the earlier quickfix of: https://github.com/openjdk/panama-foreign/pull/417 > > This adds another test case to TestStackWalk that catches the failing code path. > > This re-uses the previously added `WhiteBox::verifyFrames`, and adds a flag to turn off the verification, which triggers the problematic code path. (I've also renamed this to just `walkFrames`, since now we don't always do verification anymore. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Rename WalkFrames parameter ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/423/files - new: https://git.openjdk.java.net/panama-foreign/pull/423/files/485040c6..ab1cac78 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=423&range=01 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=423&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/423.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/423/head:pull/423 PR: https://git.openjdk.java.net/panama-foreign/pull/423 From krakowski at hhu.de Fri Jan 29 14:44:43 2021 From: krakowski at hhu.de (Filip Krakowski) Date: Fri, 29 Jan 2021 15:44:43 +0100 Subject: [foreign-jextract] Duplicated interface declarations when using typedefs for function pointers In-Reply-To: <38476791ec13e7ca4add2707e82dd5c74ce0616c.camel@oracle.com> References: <5c613b22-d0dc-56e5-875e-6153178d6b41@hhu.de> <1614976372c35ba935f8ee8457bd4af8795837e1.camel@oracle.com> <70c6242355f75f242c3c9a611a04e7e2414f6734.camel@oracle.com> <38476791ec13e7ca4add2707e82dd5c74ce0616c.camel@oracle.com> Message-ID: <35be4ecd-f212-0f21-e2e4-936e466bea1c@hhu.de> Hi, it's really great how outstandingly fast bugs are fixed! Thank you very much for this :) Filip On 1/29/21 1:41 PM, Maurizio Cimadamore wrote: > On Thu, 2021-01-28 at 18:57 +0000, Maurizio Cimadamore wrote: >> Filed this: >> >> https://bugs.openjdk.java.net/browse/JDK-8260602 >> >> Thanks for the report! >> >> Maurizio > This has been fixed now. > > We realized that some of the jextract samples in our document [1] were > also referring to suboptimal functional interface names. We will fix > the document shortly. > > Thanks again. > > Maurizio > > [1] - > https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_jextract.md >> >> On Thu, 2021-01-28 at 17:57 +0000, Maurizio Cimadamore wrote: >>> This seems odd. But I guess I can see why jextract ends up doing >>> that. >>> >>> I think what jextract *should* do is to reuse the interface for >>> `callback_t` whenever possible (which should be declared at the >>> toplevel). >>> >>> In other words, it seems like jextract is re-generating a new >>> interface >>> every time it encounters a reference to a function pointer typedef, >>> which seems a bug. >>> >>> Maurizio >>> >>> >>> >>> On Thu, 2021-01-28 at 18:48 +0100, Filip Krakowski wrote: >>>> Hi, >>>> >>>> I just noticed that jextract generates duplicate code >>>> (interfaces) >>>> for >>>> function pointers within each struct instead at the top-level. >>>> Each interface's name seems to have a suffix based on the >>>> occurrence >>>> of >>>> the declaration in the source file. >>>> >>>> typedef void (*callback_t)(void *arg); >>>> >>>> typedef struct first_handler { >>>> callback_t cb; >>>> } first_handler_t; >>>> >>>> typedef struct second_handler { >>>> callback_t cb; >>>> } second_handler_t; >>>> >>>> This code generates the following java source code. >>>> >>>> @C("struct first_handler")public static class first_handler { >>>> ... >>>> public static interface cb { >>>> >>>> void apply(jdk.incubator.foreign.MemoryAddress >>>> x0); >>>> >>>> public static @C("callback_t") MemorySegment >>>> allocate(cb fi) { >>>> return RuntimeHelper.upcallStub(cb.class, >>>> fi, >>>> ucx_h_constants_0.cb$FUNC(), >>>> "(Ljdk/incubator/foreign/MemoryAddress;)V"); >>>> } >>>> >>>> public static @C("callback_t") MemorySegment >>>> allocate(cb fi, NativeScope scope) { >>>> return allocate(fi).handoff(scope); >>>> } >>>> } >>>> ... >>>> } >>>> >>>> @C("struct second_handler")public static class second_handler >>>> { >>>> ... >>>> public static interface cb$0 { >>>> >>>> void apply(jdk.incubator.foreign.MemoryAddress >>>> x0); >>>> >>>> public static @C("callback_t") MemorySegment >>>> allocate(cb$0 fi) { >>>> return RuntimeHelper.upcallStub(cb$0.class, >>>> fi, >>>> ucx_h_constants_0.cb$0$FUNC(), >>>> "(Ljdk/incubator/foreign/MemoryAddress;)V"); >>>> } >>>> >>>> public static @C("callback_t") MemorySegment >>>> allocate(cb$0 fi, NativeScope scope) { >>>> return allocate(fi).handoff(scope); >>>> } >>>> } >>>> ... >>>> } >>>> >>>> From my point of view both interfaces are identical. Is there a >>>> reason >>>> for placing them inside the struct class? >>>> >>>> >>>> Best regards >>>> Filip >>>> >>>> From jvernee at openjdk.java.net Fri Jan 29 15:05:10 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 29 Jan 2021 15:05:10 GMT Subject: [foreign-memaccess+abi] RFR: Add stack walk test case that doesn't verify oops [v3] In-Reply-To: <2dC5iNW2JzprohQhvxGLIBOyPU-dKkXNppcVCrYpCis=.cd68e19a-e7d0-41ed-8fb6-f4548a9042ef@github.com> References: <2dC5iNW2JzprohQhvxGLIBOyPU-dKkXNppcVCrYpCis=.cd68e19a-e7d0-41ed-8fb6-f4548a9042ef@github.com> Message-ID: > This is a followup for the earlier quickfix of: https://github.com/openjdk/panama-foreign/pull/417 > > This adds another test case to TestStackWalk that catches the failing code path. > > This re-uses the previously added `WhiteBox::verifyFrames`, and adds a flag to turn off the verification, which triggers the problematic code path. (I've also renamed this to just `walkFrames`, since now we don't always do verification anymore. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: - Renamed back to VerifyFrames - Rename update_reg_map_and_verify_oops to just update_map - Add check in frame::verify for update_map() before doing oop verification ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/423/files - new: https://git.openjdk.java.net/panama-foreign/pull/423/files/ab1cac78..35676f3c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=423&range=02 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=423&range=01-02 Stats: 14 lines in 4 files changed: 2 ins; 2 del; 10 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/423.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/423/head:pull/423 PR: https://git.openjdk.java.net/panama-foreign/pull/423 From vlivanov at openjdk.java.net Fri Jan 29 16:25:51 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 29 Jan 2021 16:25:51 GMT Subject: [foreign-memaccess+abi] RFR: 8258516: Allow passing a target address as an argument to a native MethodHandle In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 20:35:09 GMT, Jorn Vernee wrote: > Hi, > > This patch adds the ability to CLinker to link a method handle that takes the address to the target function separately as a leading argument, instead of having to supply it during linking. > > This will avoid the need to re-link method handles for 'virtual' call sites, where the type of the call is always the same, but the address of the target function can differ. > > I've updated the C2 code to intrinsify the current case when the address argument is a constant, but there is still more work to be done to add intrinsification of virtual calls. Though, not having to re-link a method handle on every call should already speed things up significantly. > > There are other possible enhancements imaginable as well, such as caching linked method handles inside the linker, and re-using them with different addresses (but that is for a later patch). > > I added a benchmark similar to CallOverhead that measures the virtual variants. Some refactoring has been done there to put shared code in a helper class, and the old benchmark has been renamed to CallOverheadConstant so it's possible to select either class to run independently of the other with JMH. I've also added several more variants that test different numbers of arguments. > > I added a TestVirtualCalls test as a smoke test for simple virtual calls, and updated (as well as simplified a little) TestIntrinsics to make sure nothing crashes in the C2 code when encountering a virtual call. > > Thanks, > Jorn Looks good. ------------- Marked as reviewed by vlivanov (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/433 From jvernee at openjdk.java.net Fri Jan 29 16:44:11 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 29 Jan 2021 16:44:11 GMT Subject: [foreign-memaccess+abi] RFR: Add stack walk test case that doesn't verify oops [v4] In-Reply-To: <2dC5iNW2JzprohQhvxGLIBOyPU-dKkXNppcVCrYpCis=.cd68e19a-e7d0-41ed-8fb6-f4548a9042ef@github.com> References: <2dC5iNW2JzprohQhvxGLIBOyPU-dKkXNppcVCrYpCis=.cd68e19a-e7d0-41ed-8fb6-f4548a9042ef@github.com> Message-ID: > This is a followup for the earlier quickfix of: https://github.com/openjdk/panama-foreign/pull/417 > > This adds another test case to TestStackWalk that catches the failing code path. > > This re-uses the previously added `WhiteBox::verifyFrames`, and adds a flag to turn off the verification, which triggers the problematic code path. (I've also renamed this to just `walkFrames`, since now we don't always do verification anymore. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: - update comment in frame::verify ------------- Changes: - all: https://git.openjdk.java.net/panama-foreign/pull/423/files - new: https://git.openjdk.java.net/panama-foreign/pull/423/files/35676f3c..1d0f85ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=423&range=03 - incr: https://webrevs.openjdk.java.net/?repo=panama-foreign&pr=423&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/panama-foreign/pull/423.diff Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/423/head:pull/423 PR: https://git.openjdk.java.net/panama-foreign/pull/423 From duke at openjdk.java.net Fri Jan 29 17:12:43 2021 From: duke at openjdk.java.net (duke) Date: Fri, 29 Jan 2021 17:12:43 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets Message-ID: <450db9b8-f7e2-4f8c-a5cd-2395dbc70854@openjdk.org> Changeset: a983f556 Author: Jorn Vernee Date: 2021-01-29 17:11:36 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/a983f556 8258516: Allow passing a target address as an argument to a native MethodHandle Reviewed-by: mcimadamore, vlivanov ! src/hotspot/share/ci/ciNativeEntryPoint.cpp ! src/hotspot/share/ci/ciNativeEntryPoint.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/graphKit.hpp ! src/java.base/share/classes/java/lang/invoke/NativeMethodHandle.java ! src/java.base/share/classes/jdk/internal/invoke/NativeEntryPoint.java ! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/Binding.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/AArch64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVx64Linker.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java ! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/x64/windows/Windowsx64Linker.java ! test/jdk/java/foreign/TestIntrinsics.java + test/jdk/java/foreign/virtual/TestVirtualCalls.java + test/jdk/java/foreign/virtual/libVirtual.c - test/micro/org/openjdk/bench/jdk/incubator/foreign/CallOverhead.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/CallOverheadConstant.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/CallOverheadHelper.java + test/micro/org/openjdk/bench/jdk/incubator/foreign/CallOverheadVirtual.java ! test/micro/org/openjdk/bench/jdk/incubator/foreign/libCallOverhead.c ! test/micro/org/openjdk/bench/jdk/incubator/foreign/libCallOverheadJNI.c Changeset: b39ce240 Author: duke Date: 2021-01-29 17:12:15 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/b39ce240 Automatic merge of foreign-memaccess+abi into foreign-jextract From jvernee at openjdk.java.net Fri Jan 29 17:14:03 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 29 Jan 2021 17:14:03 GMT Subject: [foreign-memaccess+abi] Integrated: 8258516: Allow passing a target address as an argument to a native MethodHandle In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 20:35:09 GMT, Jorn Vernee wrote: > Hi, > > This patch adds the ability to CLinker to link a method handle that takes the address to the target function separately as a leading argument, instead of having to supply it during linking. > > This will avoid the need to re-link method handles for 'virtual' call sites, where the type of the call is always the same, but the address of the target function can differ. > > I've updated the C2 code to intrinsify the current case when the address argument is a constant, but there is still more work to be done to add intrinsification of virtual calls. Though, not having to re-link a method handle on every call should already speed things up significantly. > > There are other possible enhancements imaginable as well, such as caching linked method handles inside the linker, and re-using them with different addresses (but that is for a later patch). > > I added a benchmark similar to CallOverhead that measures the virtual variants. Some refactoring has been done there to put shared code in a helper class, and the old benchmark has been renamed to CallOverheadConstant so it's possible to select either class to run independently of the other with JMH. I've also added several more variants that test different numbers of arguments. > > I added a TestVirtualCalls test as a smoke test for simple virtual calls, and updated (as well as simplified a little) TestIntrinsics to make sure nothing crashes in the C2 code when encountering a virtual call. > > Thanks, > Jorn This pull request has now been integrated. Changeset: a983f556 Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/a983f556 Stats: 957 lines in 29 files changed: 623 ins; 234 del; 100 mod 8258516: Allow passing a target address as an argument to a native MethodHandle Reviewed-by: mcimadamore, vlivanov ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/433 From duke at openjdk.java.net Fri Jan 29 17:31:56 2021 From: duke at openjdk.java.net (duke) Date: Fri, 29 Jan 2021 17:31:56 GMT Subject: git: openjdk/panama-foreign: foreign-jextract: 2 new changesets Message-ID: Changeset: d207b2cf Author: Jorn Vernee Date: 2021-01-29 17:30:17 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/d207b2cf Add stack walk test case that doesn't verify oops Reviewed-by: vlivanov ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/frame.cpp ! test/jdk/java/foreign/stackwalk/TestStackWalk.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: 4ff318cb Author: duke Date: 2021-01-29 17:31:16 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/4ff318cb Automatic merge of foreign-memaccess+abi into foreign-jextract From jvernee at openjdk.java.net Fri Jan 29 17:33:02 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 29 Jan 2021 17:33:02 GMT Subject: [foreign-memaccess+abi] RFR: Add stack walk test case that doesn't verify oops In-Reply-To: <2dC5iNW2JzprohQhvxGLIBOyPU-dKkXNppcVCrYpCis=.cd68e19a-e7d0-41ed-8fb6-f4548a9042ef@github.com> References: <2dC5iNW2JzprohQhvxGLIBOyPU-dKkXNppcVCrYpCis=.cd68e19a-e7d0-41ed-8fb6-f4548a9042ef@github.com> Message-ID: <8Dxo-OVNF96nTCHp6ehqCgyc9wktz0WXOIr7VtIqD_8=.c8f619c3-0ecf-4174-ab2c-3264b655d7b7@github.com> On Wed, 16 Dec 2020 14:25:45 GMT, Jorn Vernee wrote: > This is a followup for the earlier quickfix of: https://github.com/openjdk/panama-foreign/pull/417 > > This adds another test case to TestStackWalk that catches the failing code path. > > This re-uses the previously added `WhiteBox::verifyFrames`, and adds a flag to turn off the verification, which triggers the problematic code path. (I've also renamed this to just `walkFrames`, since now we don't always do verification anymore. I've integrated all open comments now (including offline discussion), please have another look. Thanks. ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/423 From vlivanov at openjdk.java.net Fri Jan 29 17:33:01 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 29 Jan 2021 17:33:01 GMT Subject: [foreign-memaccess+abi] RFR: Add stack walk test case that doesn't verify oops [v4] In-Reply-To: References: <2dC5iNW2JzprohQhvxGLIBOyPU-dKkXNppcVCrYpCis=.cd68e19a-e7d0-41ed-8fb6-f4548a9042ef@github.com> Message-ID: On Fri, 29 Jan 2021 16:44:11 GMT, Jorn Vernee wrote: >> This is a followup for the earlier quickfix of: https://github.com/openjdk/panama-foreign/pull/417 >> >> This adds another test case to TestStackWalk that catches the failing code path. >> >> This re-uses the previously added `WhiteBox::verifyFrames`, and adds a flag to turn off the verification, which triggers the problematic code path. (I've also renamed this to just `walkFrames`, since now we don't always do verification anymore. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > - update comment in frame::verify Looks good. ------------- Marked as reviewed by vlivanov (Committer). PR: https://git.openjdk.java.net/panama-foreign/pull/423 From jvernee at openjdk.java.net Fri Jan 29 17:33:02 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 29 Jan 2021 17:33:02 GMT Subject: [foreign-memaccess+abi] Integrated: Add stack walk test case that doesn't verify oops In-Reply-To: <2dC5iNW2JzprohQhvxGLIBOyPU-dKkXNppcVCrYpCis=.cd68e19a-e7d0-41ed-8fb6-f4548a9042ef@github.com> References: <2dC5iNW2JzprohQhvxGLIBOyPU-dKkXNppcVCrYpCis=.cd68e19a-e7d0-41ed-8fb6-f4548a9042ef@github.com> Message-ID: <0UWhySyNghuGJGL5bBZHgr2ZKw9qrMeMQl0nRz1orHE=.2af5cf05-0cb9-4e22-a1e7-8ec44ffa4d51@github.com> On Wed, 16 Dec 2020 14:25:45 GMT, Jorn Vernee wrote: > This is a followup for the earlier quickfix of: https://github.com/openjdk/panama-foreign/pull/417 > > This adds another test case to TestStackWalk that catches the failing code path. > > This re-uses the previously added `WhiteBox::verifyFrames`, and adds a flag to turn off the verification, which triggers the problematic code path. (I've also renamed this to just `walkFrames`, since now we don't always do verification anymore. This pull request has now been integrated. Changeset: d207b2cf Author: Jorn Vernee URL: https://git.openjdk.java.net/panama-foreign/commit/d207b2cf Stats: 9 lines in 4 files changed: 3 ins; 0 del; 6 mod Add stack walk test case that doesn't verify oops Reviewed-by: vlivanov ------------- PR: https://git.openjdk.java.net/panama-foreign/pull/423 From sviswanathan at openjdk.java.net Fri Jan 29 21:05:58 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 29 Jan 2021 21:05:58 GMT Subject: [vectorIntrinsics] RFR: 8260668: vectorIntrinsics windows build problem Message-ID: The panama-vector vectorIntrinsics branch fails to build on windows. This is happening because /Ta option is no more supported by the VS2019 C compiler to generate obj from assembly files. The alternative is to use the windows assembler instead for this purpose. Best Regards, Sandhya ------------- Commit messages: - 8260668: vectorIntrinsics windows build problem Changes: https://git.openjdk.java.net/panama-vector/pull/34/files Webrev: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=34&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260668 Stats: 55 lines in 3 files changed: 12 ins; 0 del; 43 mod Patch: https://git.openjdk.java.net/panama-vector/pull/34.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/34/head:pull/34 PR: https://git.openjdk.java.net/panama-vector/pull/34 From whuang at openjdk.java.net Sat Jan 30 02:08:10 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Sat, 30 Jan 2021 02:08:10 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE [v6] In-Reply-To: References: Message-ID: <8QuIjY5ijK0c4znaPJSfSEBFH6VdhMrDxSYkIo5K4g8=.d6eca6ed-b7db-47a7-93af-796922591e33@github.com> > This patch add cast nodes between interger types implementation for Arm SVE like "VectorCastB2X" "VectorCastI2X " "VectorCastS2X" "VectorCastL2X". Wang Huang has updated the pull request incrementally with one additional commit since the last revision: fix years and tab ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/31/files - new: https://git.openjdk.java.net/panama-vector/pull/31/files/a925c37e..b46f46f5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=31&range=05 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=31&range=04-05 Stats: 25 lines in 2 files changed: 0 ins; 0 del; 25 mod Patch: https://git.openjdk.java.net/panama-vector/pull/31.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/31/head:pull/31 PR: https://git.openjdk.java.net/panama-vector/pull/31 From whuang at openjdk.java.net Sat Jan 30 03:05:08 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Sat, 30 Jan 2021 03:05:08 GMT Subject: [vectorIntrinsics] RFR: 8259536: Add cast nodes between interger types implementation for Arm SVE [v7] In-Reply-To: References: Message-ID: > This patch add cast nodes between interger types implementation for Arm SVE like "VectorCastB2X" "VectorCastI2X " "VectorCastS2X" "VectorCastL2X". Wang Huang has updated the pull request incrementally with one additional commit since the last revision: fix align problem ------------- Changes: - all: https://git.openjdk.java.net/panama-vector/pull/31/files - new: https://git.openjdk.java.net/panama-vector/pull/31/files/b46f46f5..177bdab7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=31&range=06 - incr: https://webrevs.openjdk.java.net/?repo=panama-vector&pr=31&range=05-06 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/panama-vector/pull/31.diff Fetch: git fetch https://git.openjdk.java.net/panama-vector pull/31/head:pull/31 PR: https://git.openjdk.java.net/panama-vector/pull/31 From psandoz at openjdk.java.net Sat Jan 30 03:25:50 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Sat, 30 Jan 2021 03:25:50 GMT Subject: [vectorIntrinsics] RFR: 8260668: vectorIntrinsics windows build problem In-Reply-To: References: Message-ID: On Fri, 29 Jan 2021 19:25:31 GMT, Sandhya Viswanathan wrote: > The panama-vector vectorIntrinsics branch fails to build on windows. > This is happening because /Ta option is no more supported by the VS2019 C compiler to generate obj from assembly files. > The alternative is to use the windows assembler instead for this purpose. > > Best Regards, > Sandhya @magicus can you please review this? ------------- PR: https://git.openjdk.java.net/panama-vector/pull/34 From piotr.tarsa at gmail.com Sat Jan 30 13:14:06 2021 From: piotr.tarsa at gmail.com (Piotr Tarsa) Date: Sat, 30 Jan 2021 14:14:06 +0100 Subject: Comments / metadata in assembly listings don't make sense for code vectorized using Vector API In-Reply-To: References: Message-ID: Hi, I was busy with other things, so that's why I delayed the reply. wt., 19 sty 2021 o 21:17 Paul Sandoz napisa?(a): > > Hi Piotr, > > Thanks for further sharing. I am glad you managed to make progress. I was not aware there were some benchmark rules you needed to adhere to. Rules are here: https://benchmarksgame-team.pages.debian.net/benchmarksgame/description/mandelbrot.html#mandelbrot They require bit perfect output and also the same algorithm. Well, in the end it's a benchmark of programming languages, not of algorithms. > Re: masks, yes there is still work to do for some mask operations. OK, good to know. > Re: execution from the command line. You can run with -XX:-TieredCompilation (Remi, thanks for the correction in the prior email :-) ), and it's also possible reduce the compilation threshold (at the expense of potentially less accurate profiling information) using say -XX:CompileThreshold=1000 (the default is 10000). > It?s always a bit tricky to compare a static (Rust) vs. dynamic system that needs to warm up. > > Paul. I've tested the provided options, but they don't improve performance on the real benchmark: $ time for run in {1..30}; do ~/devel/jdk-16/bin/java -XX:-TieredCompilation -XX:CompileThreshold=1000 --add-modules jdk.incubator.vector -cp target/classes/:/home/piotrek/.m2/repository/org/openjdk/jmh/jmh-core/1.27/jmh-core-1.27.jar pl.tarsa.mandelbrot_simd_1 16000 > /dev/null; done WARNING: Using incubator modules: jdk.incubator.vector WARNING: Using incubator modules: jdk.incubator.vector ... (repeated for each run) WARNING: Using incubator modules: jdk.incubator.vector WARNING: Using incubator modules: jdk.incubator.vector real 0m42,213s user 2m35,740s sys 0m4,094s $ time for run in {1..30}; do ~/devel/jdk-16/bin/java -XX:-TieredCompilation --add-modules jdk.incubator.vector -cp target/classes/:/home/piotrek/.m2/repository/org/openjdk/jmh/jmh-core/1.27/jmh-core-1.27.jar pl.tarsa.mandelbrot_simd_1 16000 > /dev/null; done WARNING: Using incubator modules: jdk.incubator.vector WARNING: Using incubator modules: jdk.incubator.vector ... (repeated for each run) WARNING: Using incubator modules: jdk.incubator.vector WARNING: Using incubator modules: jdk.incubator.vector real 0m40,038s user 2m23,227s sys 0m3,515s $ time for run in {1..30}; do ~/devel/jdk-16/bin/java --add-modules jdk.incubator.vector -cp target/classes/:/home/piotrek/.m2/repository/org/openjdk/jmh/jmh-core/1.27/jmh-core-1.27.jar pl.tarsa.mandelbrot_simd_1 16000 > /dev/null; done WARNING: Using incubator modules: jdk.incubator.vector WARNING: Using incubator modules: jdk.incubator.vector ... (repeated for each run) WARNING: Using incubator modules: jdk.incubator.vector WARNING: Using incubator modules: jdk.incubator.vector real 0m37,743s user 2m16,316s sys 0m3,758s Looks like the default settings yield best performance. That's a positive thing, actually. I'll probably send my version to benchmarks game maintainer when he switches to Java 16 and then leave tuning to others. Thanks for the conversation, Piotr > > On Jan 16, 2021, at 4:12 AM, Piotr Tarsa wrote: > > Hi Paul, > > Thanks for replying. > > As per your advice I've prepared JMH benchmarks. Also I've copied some > optimizations from other mandelbrot benchmark implementations and > achieved further speedup. New version is here: > https://urldefense.com/v3/__https://gist.github.com/tarsa/7a9c80bb84c2dcd807be9cd16a655ee0/4ced690e20ad561515094995a852adc95820955e__;!!GqivPVa7Brio!PPG_y5O-1X6iaHMBpRFVBkTI7zM4hvwD-CWKID54DAHe_q47jEN4GoDyUO8MCOGPNQ$ > It also has simplified buffer management and multithreading, so > there's less boilerplate. > > Results from JMH are quite good (a bit reordered for clarity): > # Run complete. Total time: 00:16:42 > Benchmark Mode Cnt Score Error Units > benchRowMT thrpt 5 17755,337 ? 279,118 ops/s > benchRowST thrpt 5 4535,280 ? 7,471 ops/s > benchScalarPairsMT thrpt 5 4583,354 ? 89,532 ops/s > benchScalarPairsST thrpt 5 1163,925 ? 0,469 ops/s > benchScalarMT thrpt 5 2666,210 ? 5,004 ops/s > benchScalarST thrpt 5 673,234 ? 0,167 ops/s > benchVectorMT thrpt 5 18020,397 ? 54,230 ops/s > benchVectorST thrpt 5 4567,873 ? 10,339 ops/s > benchVectorWithTransfer thrpt 5 4557,361 ? 9,450 ops/s > benchScalarRemainderOnly thrpt 5 7105989,167 ? 4691,311 ops/s > > The mandelbrot Java #2 is named here benchScalarPairsMT (it's manually > unrolled x2). My new vectorized version (similarly manually unrolled) > is benchVectorMT and it has about 4x higher performance which is quite > good. > > However when I run the benchmark from command line (in non-JMH mode) > to replicate the benchmark rules then there is much smaller > performance difference. Mandelbrot Java #2 (the unvectorized one) > takes about 3s, while my one takes about 1.2s - 1.3s and sometimes > fluctuated up to about 1.5s. It seems that compilation takes up a lot > of benchmark time. Is it possible to reduce compilation times for code > using Vector API? > > wt., 5 sty 2021 o 00:11 Paul Sandoz napisa?(a): > > > Hi Piotr, > > Thanks for experimenting. The Intel folks have also experimented with Mandelbrot generation and might be able to comment with their experience in comparison. > > I would be interested to know what your expectations were with regards to speedup. > > > I've expected more than 2x speedup vs the scalar version as I have > 256-bit SIMD on my Haswell machine. Luckily, I've managed to achieve > it as I've written at the beginning. > > It?s hard to evaluate without a JMH benchmark which can more easily present the code hotspots and isolate from the other areas, such as for thread parallelism. My recommendation would be to extract out the computeChunksVector kernel and embed within such a benchmark. > > Switching off tired compilation should help (-XX:-TiredCompilation) i.e. only C2, not C1, in getting to the C2 generated code faster. > > > Good point. I've made a JMH benchmark (that I've presented at the > beginning) and saw where are inefficiences. > > To your question about the assembly listing I believe as HotSpot goes through various compiler passes it tries to preserve the byte code index associated with generated instructions, but naturally as code is lowered this becomes an approximation, and especially so with the Vector API. > > > Hmmm, it's sad that it's only approximation. > > In the case of "*synchronization entry?, this is stating the pseudo byte code index just before a method is entered. However, I think there is tech debt here, see > > https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/debugInfoRec.hpp*L67__;Iw!!GqivPVa7Brio!PPG_y5O-1X6iaHMBpRFVBkTI7zM4hvwD-CWKID54DAHe_q47jEN4GoDyUO-g6St52w$ > > And the usages of SynchronizationEntryBCI in hotspot code. > > Running in fast debug mode will present a slightly higher-level view of generated code. Here?s a snippet: > > 26e vmulpd XMM12,XMM7,XMM7 ! mul packedD > 272 vaddpd XMM8,XMM0,XMM11 ! add packedD > 277 vmulpd XMM9,XMM8,XMM8 ! mul packedD > 27c vaddpd XMM0,XMM12,XMM9 ! add packedD > 281 vector_compare XMM10,XMM5,XMM0,#3 ! > 286 # TLS is in R15 > 286 cmpq RCX, [R15 + #344 (32-bit)] # raw ptr > 28d jnb,u B47 P=0.000100 C=-1.000000 > > ? > > 2cf vmovdqu [rsp + 64],XMM1 # spill > > 2d5 B25: # out( B44 B26 ) <- in( B48 B24 ) Freq: 9114.56 > 2d5 > 2d5 # checkcastPP of RAX > 2d5 vector_store_mask XMM1,XMM10 ! using XMM13 as TEMP > 2f4 vector_loadmask_byte XMM15,XMM1 > > 302 vmovdqu XMM1,[rsp + 448] # spill > 30b vpor XMM1,XMM1,XMM15 ! or vectors > 310 vector_store_mask XMM0,XMM1 ! using XMM14 as TEMP > 32e store_vector [RAX + #16 (8-bit)],XMM0 > > 333 vector_test RCX,XMM1, XMM2 ! using RFLAGS as TEMP > nop # 2 bytes pad for loops and calls > 340 testl RCX, RCX > 342 je B44 P=0.108889 C=184362.000000 > > > The mask instructions, such as vector_store_mask, are substituted for a more complex sequence of x86 instructions on AVX 2. > > > Thanks. For now the speedup in JMH is good enough for me, so I won't > dig into assembly code, but I'll consider fastdebug Java build when I > explore assembly next time. > > I do notice that the inner loop (upper bound of 5) does unroll (FWIW, making the inner bound a power of 2 is more friendly for unrolling). There also appears to be many register spills, suggesting non-optimal vector register allocation/usage by C2. > > > I've tried factor of 4, but that didn't improve performance. I think > it even made it worse as 50 is not a multiply of 4 and benchmark rules > dictates that there must be exactly 50 iterations so I needed to make > additional code for 50 % 4 = 2 extra iterations. That probably made > code compilation even longer and worsen benchmark execution time. > > Instead of unrolling the inner loops, I've duplicated all vectors > (i.e. unrolled the chunk-level loop, instead of the inner iteration > level loop), so I was working on 256-bit / 64-bit * 2 = 8 results at a > time. That worked well, similarly to mandelbrot Java #2. > > I noticed this in the code: > > // in Rust version this works fine, so where's the bug then? > // cmpMask = vFours.lt(vZiN.add(vZrN)); > > What problem did you encounter? It works for me on the tip of https://urldefense.com/v3/__https://github.com/openjdk/jdk__;!!GqivPVa7Brio!PPG_y5O-1X6iaHMBpRFVBkTI7zM4hvwD-CWKID54DAHe_q47jEN4GoDyUO80IYo13A$ . > > > The results were different, but benchmark dictates that the output > must be bit-to-bit identical to correct output. I've nailed it down. > It's because of numeric overflows causing numbers to go to > Double.Infinity and then subtracting Infinity from Infinity results in > Double.NaN and then comparisons are always false. Anyway, I've tried > to make a version without `cmpMask = cmpMask.or(newValue)` and made a > correct version, but that turned out to be slower. Perhaps some of the > mask operations are not intrinsified yet or something. Rust was doing > the comparisons a little bit differently, properly accounting for > NaNs. > > All tests were done on: > openjdk 16-ea 2021-03-16 > OpenJDK Runtime Environment (build 16-ea+30-2130) > OpenJDK 64-Bit Server VM (build 16-ea+30-2130, mixed mode, sharing) > > > Paul. > > On Dec 30, 2020, at 6:17 AM, Piotr Tarsa wrote: > > Hi all, > > Thanks for creating Project Panama! It looks promising. However, I've > made a try to vectorize some code and got somewhat disappointing > results. Therefore I wanted to look at the generated machine code to > see it it looks optimal. I've attached hsdis to JVM and enabled > assembly printing but the output doesn't make sense to me, i.e. the > instructions and comments / metadata don't seem to match. I may be > wrong as I've very rarely looked at assembly listing produced by JVM. > > Performance: > As a baseline I took > https://urldefense.com/v3/__https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/mandelbrot-java-2.html__;!!GqivPVa7Brio!PPG_y5O-1X6iaHMBpRFVBkTI7zM4hvwD-CWKID54DAHe_q47jEN4GoDyUO9Hidpnxg$ > which takes about 3.05s to finish on my system. After vectorization > I've managed to achieve timings like 1.80s. That's quite disappointing > to me as I have a Haswell machine which has AVX2, high speed L1 > caches, etc I've tested on recent JDK 16 EA build from > https://urldefense.com/v3/__http://jdk.java.net/16/__;!!GqivPVa7Brio!PPG_y5O-1X6iaHMBpRFVBkTI7zM4hvwD-CWKID54DAHe_q47jEN4GoDyUO8eAZxJgQ$ > > Link to the code and assembly listing: > https://urldefense.com/v3/__https://gist.github.com/tarsa/7a9c80bb84c2dcd807be9cd16a655ee0__;!!GqivPVa7Brio!PPG_y5O-1X6iaHMBpRFVBkTI7zM4hvwD-CWKID54DAHe_q47jEN4GoDyUO9lqtRFkA$ I'll > copy the source code again in this mail at the end. > > What I see in the assembly listings is e.g. > > 0x00007f0e208b8ab9: cmp r13d,0x7fffffc0 > 0x00007f0e208b8ac0: jg 0x00007f0e208b932c > 0x00007f0e208b8ac6: vmulpd ymm0,ymm6,ymm4 > 0x00007f0e208b8aca: vsubpd ymm1,ymm4,ymm4 > 0x00007f0e208b8ace: vmovdqu YMMWORD PTR [rsp+0xc0],ymm1 > 0x00007f0e208b8ad7: vmulpd ymm0,ymm0,ymm4 > ;*synchronization entry > ; - > jdk.internal.vm.vector.VectorSupport$VectorPayload::getPayload at -1 > (line 101) > ; - > jdk.incubator.vector.Double256Vector$Double256Mask::getBits at 1 (line > 557) > ; - > jdk.incubator.vector.AbstractMask::toLong at 24 (line 77) > ; - > mandelbrot_simd_1::computeChunksVector at 228 (line 187) > 0x00007f0e208b8adb: vaddpd ymm0,ymm0,ymm2 ;*checkcast > {reexecute=0 rethrow=0 return_oop=0} > ; - > jdk.incubator.vector.DoubleVector::fromArray0Template at 34 (line 3119) > ; - > jdk.incubator.vector.Double256Vector::fromArray0 at 3 (line 777) > ; - > jdk.incubator.vector.DoubleVector::fromArray at 24 (line 2564) > ; - > mandelbrot_simd_1::computeChunksVector at 95 (line 169) > 0x00007f0e208b8adf: vmovdqu YMMWORD PTR [rsp+0xe0],ymm0 > 0x00007f0e208b8ae8: vmulpd ymm0,ymm0,ymm0 > 0x00007f0e208b8aec: vmovdqu YMMWORD PTR [rsp+0x100],ymm0 > > How does vmulpd relate to a synchronization entry and > AbstrackMask::toLong? It seems way off to me. However, there maybe > some trick to understand it. Could you give me some guidelines on how > to intepret that? Are the comments describing lines below or above > them? > > Regards, > Piotr > > mandelbrot_simd_1.java source code: > import jdk.incubator.vector.DoubleVector; > import jdk.incubator.vector.VectorMask; > import jdk.incubator.vector.VectorSpecies; > > import java.io.BufferedOutputStream; > import java.io.IOException; > import java.io.OutputStream; > import java.nio.file.Files; > import java.nio.file.Path; > import java.util.concurrent.CountDownLatch; > import java.util.concurrent.ExecutorService; > import java.util.concurrent.Executors; > import java.util.concurrent.TimeUnit; > import java.util.stream.IntStream; > > public class mandelbrot_simd_1 { > private static final VectorSpecies SPECIES = > DoubleVector.SPECIES_PREFERRED.length() <= 8 ? > DoubleVector.SPECIES_PREFERRED : DoubleVector.SPECIES_512; > > private static final int LANES = SPECIES.length(); > > private static final int LANES_LOG = Integer.numberOfTrailingZeros(LANES); > > public static void main(String[] args) throws IOException { > if ((LANES > 8) || (LANES != (1 << LANES_LOG))) { > var errorMsg = "LANES must be a power of two and at most 8. " + > "Change SPECIES in the source code."; > throw new RuntimeException(errorMsg); > } > var sideLen = Integer.parseInt(args[0]); > try (var out = new BufferedOutputStream(makeOut1())) { > out.write(String.format("P4\n%d %d\n", sideLen, > sideLen).getBytes()); > computeAndOutputRows(out, sideLen); > } > } > > @SuppressWarnings("unused") > // the version that avoids mixing up output with JVM diagnostic messages > private static OutputStream makeOut1() throws IOException { > return Files.newOutputStream(Path.of("mandelbrot_simd_1.pbm")); > } > > // the version that is compatible with benchmark requirements > private static OutputStream makeOut2() { > return System.out; > } > > private static void computeAndOutputRows(OutputStream out, int sideLen) { > var poolFactor = 1000000 / sideLen; > if (poolFactor < 10) { > throw new RuntimeException("Too small poolFactor"); > } > var numCpus = Runtime.getRuntime().availableProcessors(); > var rowsPerBatch = numCpus * poolFactor; > var fac = 2.0 / sideLen; > var aCr = IntStream.range(0, sideLen).parallel() > .mapToDouble(x -> x * fac - 1.5).toArray(); > var bitsReversalMapping = computeBitsReversalMapping(); > var rowsPools = new byte[2][rowsPerBatch][(sideLen + 7) / 8]; > var rowsChunksPools = new long[2][rowsPerBatch][sideLen / 64]; > var batchSizes = new int[2]; > var batchCountDowns = new CountDownLatch[2]; > var computeEc = Executors.newWorkStealingPool(numCpus); > var masterThread = new Thread(() -> { > var rowsToProcess = sideLen; > var nextBatchStart = 0; > batchSizes[0] = 0; > batchCountDowns[0] = new CountDownLatch(0); > for (var poolId = 0; rowsToProcess > 0; poolId ^= 1) { > while (batchCountDowns[poolId].getCount() != 0) { > try { > batchCountDowns[poolId].await(); > } catch (InterruptedException ignored) { > } > } > batchCountDowns[poolId] = null; > > var nextBatchSize = > Math.min(sideLen - nextBatchStart, rowsPerBatch); > var nextPoolId = poolId ^ 1; > batchSizes[nextPoolId] = nextBatchSize; > batchCountDowns[nextPoolId] = new CountDownLatch(nextBatchSize); > sendTasks(fac, aCr, bitsReversalMapping, > rowsPools[nextPoolId], rowsChunksPools[nextPoolId], > nextBatchStart, nextBatchSize, > batchCountDowns[nextPoolId], computeEc); > nextBatchStart += nextBatchSize; > > var batchSize = batchSizes[poolId]; > try { > for (var rowIdx = 0; rowIdx < batchSize; rowIdx++) { > out.write(rowsPools[poolId][rowIdx]); > } > out.flush(); > } catch (IOException e) { > e.printStackTrace(); > System.exit(-1); > } > rowsToProcess -= batchSize; > } > > computeEc.shutdown(); > }); > masterThread.start(); > while (masterThread.isAlive() || !computeEc.isTerminated()) { > try { > @SuppressWarnings("unused") > var ignored = computeEc.awaitTermination(1, TimeUnit.DAYS); > masterThread.join(); > } catch (InterruptedException ignored) { > } > } > } > > private static void sendTasks(double fac, double[] aCr, > byte[] bitsReversalMapping, > byte[][] rows, long[][] rowsChunks, > int batchStart, int batchSize, > CountDownLatch poolsActiveWorkersCount, > ExecutorService computeEc) { > for (var i = 0; i < batchSize; i++) { > var indexInBatch = i; > var y = batchStart + i; > var Ci = y * fac - 1.0; > computeEc.submit(() -> { > try { > computeRow(Ci, aCr, bitsReversalMapping, > rows[indexInBatch], rowsChunks[indexInBatch]); > poolsActiveWorkersCount.countDown(); > } catch (Exception e) { > e.printStackTrace(); > System.exit(-1); > } > }); > } > } > > private static byte[] computeBitsReversalMapping() { > var bitsReversalMapping = new byte[256]; > for (var i = 0; i < 256; i++) { > bitsReversalMapping[i] = (byte) (Integer.reverse(i) >>> 24); > } > return bitsReversalMapping; > } > > private static void computeRow(double Ci, double[] aCr, > byte[] bitsReversalMapping, > byte[] row, long[] rowChunks) { > computeChunksVector(Ci, aCr, rowChunks); > transferRowFlags(rowChunks, row, bitsReversalMapping); > computeRemainderScalar(aCr, row, Ci); > } > > private static void computeChunksVector(double Ci, double[] aCr, > long[] rowChunks) { > var sideLen = aCr.length; > var vCi = DoubleVector.broadcast(SPECIES, Ci); > var vZeroes = DoubleVector.zero(SPECIES); > var vTwos = DoubleVector.broadcast(SPECIES, 2.0); > var vFours = DoubleVector.broadcast(SPECIES, 4.0); > var zeroMask = VectorMask.fromLong(SPECIES, 0); > // (1 << 6) = 64 = length of long in bits > for (var xBase = 0; xBase < (sideLen & ~(1 << 6)); xBase += (1 << 6)) { > var cmpFlags = 0L; > for (var xInc = 0; xInc < (1 << 6); xInc += LANES) { > var vZr = vZeroes; > var vZi = vZeroes; > var vCr = DoubleVector.fromArray(SPECIES, aCr, xBase + xInc); > var vZrN = vZeroes; > var vZiN = vZeroes; > var cmpMask = zeroMask; > for (var outer = 0; outer < 10; outer++) { > for (var inner = 0; inner < 5; inner++) { > vZi = vTwos.mul(vZr).mul(vZi).add(vCi); > vZr = vZrN.sub(vZiN).add(vCr); > vZiN = vZi.mul(vZi); > vZrN = vZr.mul(vZr); > } > cmpMask = cmpMask.or(vFours.lt(vZiN.add(vZrN))); > // in Rust version this works fine, so where's the bug then? > // cmpMask = vFours.lt(vZiN.add(vZrN)); > if (cmpMask.allTrue()) { > break; > } > } > cmpFlags |= cmpMask.toLong() << xInc; > } > rowChunks[xBase >> 6] = cmpFlags; > } > } > > private static void transferRowFlags(long[] rowChunks, byte[] row, > byte[] bitsReversalMapping) { > for (var i = 0; i < rowChunks.length; i++) { > var group = ~rowChunks[i]; > row[i * 8 + 7] = bitsReversalMapping[0xff & (byte) (group >>> 56)]; > row[i * 8 + 6] = bitsReversalMapping[0xff & (byte) (group >>> 48)]; > row[i * 8 + 5] = bitsReversalMapping[0xff & (byte) (group >>> 40)]; > row[i * 8 + 4] = bitsReversalMapping[0xff & (byte) (group >>> 32)]; > row[i * 8 + 3] = bitsReversalMapping[0xff & (byte) (group >>> 24)]; > row[i * 8 + 2] = bitsReversalMapping[0xff & (byte) (group >>> 16)]; > row[i * 8 + 1] = bitsReversalMapping[0xff & (byte) (group >>> 8)]; > row[i * 8] = bitsReversalMapping[0xff & (byte) group]; > } > } > > private static void computeRemainderScalar(double[] aCr, byte[] > row, double Ci) { > var sideLen = aCr.length; > var bits = 0; > for (var x = sideLen & ~(1 << 6); x < sideLen; x++) { > var Zr = 0.0; > var Zi = 0.0; > var Cr = aCr[x]; > var i = 50; > var ZrN = 0.0; > var ZiN = 0.0; > do { > Zi = 2.0 * Zr * Zi + Ci; > Zr = ZrN - ZiN + Cr; > ZiN = Zi * Zi; > ZrN = Zr * Zr; > } while (ZiN + ZrN <= 4.0 && --i > 0); > bits <<= 1; > bits += i == 0 ? 1 : 0; > if (x % 8 == 7) { > row[x / 8] = (byte) bits; > bits = 0; > } > } > if (sideLen % 8 != 0) { > row[sideLen / 8] = (byte) bits; > } > } > } > > From duncan.gittins at gmail.com Sun Jan 31 15:54:29 2021 From: duncan.gittins at gmail.com (Duncan Gittins) Date: Sun, 31 Jan 2021 15:54:29 +0000 Subject: jextract on large Windows header files In-Reply-To: <88af312a9bf7b6d2e373c42407d4b6e6a9b40e57.camel@oracle.com> References: <0e35502c-3656-9c23-eca8-4ca8a4377d15@gmail.com> <6aeec51e5921ed084808ec984b5194678f1ab736.camel@oracle.com> <5fa7c946-4f1d-b487-be3b-d087b80cf24d@gmail.com> <88af312a9bf7b6d2e373c42407d4b6e6a9b40e57.camel@oracle.com> Message-ID: <2628b41e-3519-5e6e-c84b-73f886510699@gmail.com> I've downloaded jdk/panama-foreign and experimented with some changes to jextract in order to help with the footprint of jars generated from the large Windows header files that I mentioned in the thread: Feedback / query on jextract for Windows 10. 1) Added command line args: --symbol {symbol-to-include} and --symbols {file-of-symbols-to-include} which eliminates all top level symbols not in the parameter list or symbol file(s). This avoids the need to generate huge amounts of unnecessary methods. For example in my application, "jextract shlobj_core.h" gives ~ 11MB jar (~ 49k top level symbols), adding -filter for required small group of header files cuts this to 880k (5k symbols), and with the --symbols filter that is down to a 10K jar (9 symbols) which is much more managable size to use. Also the lack of lazy load in --source output is also no longer a problem because all static field method handles are generally used. 2) Changed "jextract --source" so that identical FunctionDescriptor declarations are re-used. This makes the compiled source jar a little bit smaller than the generated class jar. For example many of the Windows functions such as SetUserObjectInformationA / SetUserObjectInformationW have the same descriptor, so jextract can emit just one FUNC_ declaration and make MH_? / $FUNC() of the second refer to the earlier declaration like this: ??? /**? DUPLICATE => SetUserObjectInformationA$FUNC_ ??? static final FunctionDescriptor SetUserObjectInformationW$FUNC_ = FunctionDescriptor.of(C_INT,C_POINTER,C_INT,C_POINTER,C_LONG); ??? */ ??? static final jdk.incubator.foreign.FunctionDescriptor SetUserObjectInformationW$FUNC() { return SetUserObjectInformationA$FUNC_; } If you think either of these will help, I can share the small set of changes I made. Duncan From joserz at linux.ibm.com Tue Jan 12 19:11:46 2021 From: joserz at linux.ibm.com (joserz at linux.ibm.com) Date: Tue, 12 Jan 2021 19:11:46 -0000 Subject: VectorAPI and C2 compiler In-Reply-To: References: <20210111210700.GA3750256@pacoca> Message-ID: <20210112191131.GA10518@pacoca> Hi Paul, Thank you for your response!! :-) This is my test case for x86 (basically got from VectorReshapeTests.java). ``` import java.io.IOException; import java.util.Arrays; import jdk.incubator.vector.IntVector; import jdk.incubator.vector.ShortVector; import jdk.incubator.vector.DoubleVector; import jdk.incubator.vector.VectorSpecies; import jdk.incubator.vector.LongVector; class Cast { static void vectorCastIntToShort(VectorSpecies i, VectorSpecies s, int[] input, short[] output) { IntVector iv = IntVector.fromArray(i, input, 0); ShortVector sv = (ShortVector) iv.castShape(s, 0); sv.intoArray(output, 0); } public static void main(String[] args) throws IOException { for (int j = 0; j < 1_000_000; j++) { int[] iin128 = {25, -398, 415, Short.MAX_VALUE + 2}; short[] sout64 = new short[ShortVector.SPECIES_64.length()]; vectorCastIntToShort(IntVector.SPECIES_128, ShortVector.SPECIES_64, iin128, sout64); } //System.out.println(Arrays.toString(iin128)); //System.out.println(Arrays.toString(sout64)); } } ``` Then, after compiling and running like: $ javac Cast.java $ java -Xcomp -XX:-TieredCompilation -XX:CompileThreshold=1 -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:+PrintOptoAssembly -XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:+EnableVectorReboxing -XX:+EnableVectorAggressiveReboxing -XX:UseAVX=2 Cast I was expecting to see instructions from x86.ad, like "vector_cast_i2x" being printed but it seems that VectorCastI2X pattern isn't be generated because I see compiler C2 kicking in during the program execution. Thank you very much! Jose On Tue, Jan 12, 2021 at 09:07:49AM -0800, Paul Sandoz wrote: > Hi Jose, > > Shifting over to panama-dev (bcc?ing discuss at openjdk.java.net ). > > Can you share a complete example on x86 that is not producing what you expect? > > I suspect in the PPC case some wiring up to the vector intrinsics are missing. > > Paul. > > > On Jan 11, 2021, at 1:07 PM, joserz at linux.ibm.com wrote: > > > > Hello team, > > > > I'm currently working on the VectorAPI support to PowerPC64 but none of my instructions, defined in ppc64.ad, gets executed. I decided to take a look at x86, but again no Vector instructions printed. > > > > Basically, I have a test case like this: > > for (int j = 0; j < 1_000_000; j++) { > > int[] iin128 = {25, -398, 415, Short.MAX_VALUE + 2}; > > short[] sout64 = new short[ShortVector.SPECIES_64.length()]; > > > > vectorCastIntToShort(IntVector.SPECIES_128, > > ShortVector.SPECIES_64, > > iin128, sout64); > > } > > > > That I execute like: > > java -Xcomp -XX:-TieredCompilation -XX:CompileThreshold=1 \ > > -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly \ > > -XX:+PrintOptoAssembly -XX:+UnlockExperimentalVMOptions \ > > -XX:+EnableVectorSupport -XX:+EnableVectorReboxing \ > > -XX:+EnableVectorAggressiveReboxing -XX:UseAVX=2 Cast > > > > And expected to see any of `format %{ "vector_* ... %}` instructions, defined in x86.ad, being printed. > > > > Am I missing anything? > > > > Thank you, > > > > Jose R Ziviani >