Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add MemorySegment::mismatch #180

Closed
wants to merge 5 commits into from

Conversation

@ChrisHegarty
Copy link
Member

@ChrisHegarty ChrisHegarty commented May 20, 2020

Hi,

As part of feedback on the Foreign Memory API (when experimenting with its usage internally in the JDK), a small number of potential usability enhancements could be made to the API. This is the fourth such, and last on my current todo list.

This change proposes to add a new method:
MemorySegment::mismatch

The mismatch semantic is very useful for building equality and comparison logic on top of segments. I found that I needed such when modeling and comparing native socket address in the JDK implementation. It is possible to write your own, but requires a non-trivial amount of not-trivial code - to do it right! I also think that we can provide a more efficient implementation building on top of the JDK's internal mismatch support.

I still need to do some perf testing and add a micro-benchmake ( Maurizio suggested possibly amending TestBulkOps ). There is also the question about possibly improving the JDK's internal implementation to work on long sizes (which could be done separately). For now, I just want to share the idea, along with the proposed specification and initial implementation.

Comments welcome.


Progress

  • Change must not contain extraneous whitespace
  • Change must be properly reviewed

Reviewers

Download

$ git fetch https://git.openjdk.java.net/panama-foreign pull/180/head:pull/180
$ git checkout pull/180

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented May 20, 2020

👋 Welcome back chegar! A progress list of the required criteria for merging this PR into foreign-memaccess will be added to the body of your pull request.

@openjdk openjdk bot added the rfr label May 20, 2020
@mlbridge
Copy link

@mlbridge mlbridge bot commented May 20, 2020

Copy link
Collaborator

@mcimadamore mcimadamore left a comment

Looks good - I've added some comments. Test is very comprehensive - thanks!

}

for (; off < minSize; off++) {
if (UNSAFE.getByte(this.base(), this.min() + off) != UNSAFE.getByte(that.base(), that.min() + off)) {

This comment has been minimized.

@mcimadamore

mcimadamore May 20, 2020
Collaborator

This code could be simplified/rewritten to use MemoryAddress' and VH, instead of unsafe access with object/offset addressing. E.g. you could maintain a MemoryAddresslocal variable in the loop instead of theoffsetand keep increasing that address on each iteration ofArraySupport::vectorizedMismatch`. Then, when you get out of the loop, the address already points at the base of the region to compare, and a simple for loop with an indexed VH should do the job.

@Test(dataProvider = "slices")
public void testSameValues(MemorySegment ss1, MemorySegment ss2) {
out.format("testSameValues s1:%s, s2:%s\n", ss1, ss2);
MemorySegment s1 = initializeSegment(ss1);
MemorySegment s2 = initializeSegment(ss2);

if (s1.byteSize() == s2.byteSize()) {
assertEquals(s1.mismatch(s2), -1); // identical
assertEquals(s2.mismatch(s1), -1);
} else if (s1.byteSize() > s2.byteSize()) {
assertEquals(s1.mismatch(s2), s2.byteSize()); // proper prefix
assertEquals(s2.mismatch(s1), s2.byteSize());
} else {
assert s1.byteSize() < s2.byteSize();
assertEquals(s1.mismatch(s2), s1.byteSize()); // proper prefix
assertEquals(s2.mismatch(s1), s1.byteSize());
}
}

@Test(dataProvider = "slices")
public void testDifferentValues(MemorySegment s1, MemorySegment s2) {
out.format("testDifferentValues s1:%s, s2:%s\n", s1, s2);
s1 = initializeSegment(s1);
s2 = initializeSegment(s2);

for (long i = s2.byteSize() -1 ; i >= 0; i--) {
long expectedMismatchOffset = i;
BYTE_HANDLE.set(s2.baseAddress().addOffset(i), (byte) 0xFF);

if (s1.byteSize() == s2.byteSize()) {
assertEquals(s1.mismatch(s2), expectedMismatchOffset);
assertEquals(s2.mismatch(s1), expectedMismatchOffset);
} else if (s1.byteSize() > s2.byteSize()) {
assertEquals(s1.mismatch(s2), expectedMismatchOffset);
assertEquals(s2.mismatch(s1), expectedMismatchOffset);
} else {
assert s1.byteSize() < s2.byteSize();
var off = Math.min(s1.byteSize(), expectedMismatchOffset);
assertEquals(s1.mismatch(s2), off); // proper prefix
assertEquals(s2.mismatch(s1), off);
}
}
}
Comment on lines +57 to +99

This comment has been minimized.

@mcimadamore

mcimadamore May 20, 2020
Collaborator

How important is it that these tests operate on slices? Looking at the test code, it could have worked equally well if the input parameters were just two sizes, and then you did an explicit allocation (or maybe also receive a segment factory from the provider, so that you can test different segment kinds).

This comment has been minimized.

@ChrisHegarty

ChrisHegarty May 20, 2020
Author Member

Originally I had a version of the test that did compare specific segments, but it didn't scale well to different sizes and kinds ( we need to test both above and below the 8 byte threshold ). I removed a number of slice sizes, which greatly reduces the combinations. This may be enough, or I can certainly revisit the test's structure.

Copy link
Member

@PaulSandoz PaulSandoz left a comment

Very nice.

Improving the JDK implementation is good. In fact i think you could so that now. In ArraysSupport, with strip mining:

    public static int vectorizedMismatchLarge(
                                         Object a, long aOffset,
                                         Object b, long bOffset,
                                         long length,
                                         int log2ArrayIndexScale)

Then you can specialize mismatch of memory segments for length threshold and type (the threshold only really makes sense for the first check, once you go over Integer.MAX_VALUE the cost of another round with a small length part is really low overall).

@openjdk
Copy link

@openjdk openjdk bot commented May 20, 2020

@ChrisHegarty This change now passes all automated pre-integration checks, type /integrate in a new comment to proceed. After integration, the commit message will be:

Add MemorySegment::mismatch

Reviewed-by: mcimadamore, psandoz
  • If you would like to add a summary, use the /summary command.
  • To credit additional contributors, use the /contributor command.
  • To add additional solved issues, use the /issue command.

Since the source branch of this PR was last updated there have been 143 commits pushed to the foreign-memaccess branch:

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid automatic rebasing, please merge foreign-memaccess into your branch, and then specify the current head hash when integrating, like this: /integrate f024ca7de9d28bbaa27e57e8d4f547db5ea06002.

As you do not have Committer status in this project, an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@mcimadamore, @PaulSandoz) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the ready label May 20, 2020
@mlbridge
Copy link

@mlbridge mlbridge bot commented May 20, 2020

Mailing list message from Maurizio Cimadamore on panama-dev:

On 20/05/2020 16:36, Paul Sandoz wrote:

On Wed, 20 May 2020 14:06:48 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

Hi,

As part of feedback on the Foreign Memory API (when experimenting with its usage internally in the JDK), a small number
of potential usability enhancements could be made to the API. This is the fourth such, and last on my current todo
list. This change proposes to add a new method:
MemorySegment::mismatch

The mismatch semantic is very useful for building equality and comparison logic on top of segments. I found that I
needed such when modeling and comparing native socket address in the JDK implementation. It is possible to write your
own, but requires a non-trivial amount of not-trivial code - to do it right! I also think that we can provide a more
efficient implementation building on top of the JDK's internal mismatch support. I still need to do some perf testing
and add a micro-benchmake ( Maurizio suggested possibly amending TestBulkOps ). There is also the question about
possibly improving the JDK's internal implementation to work on long sizes (which could be done separately). For now, I
just want to share the idea, along with the proposed specification and initial implementation. Comments welcome.
Very nice.

Improving the JDK implementation is good. In fact i think you could so that now. In `ArraysSupport`, with strip mining:

 public static int vectorizedMismatchLarge\(
                                      Object a\, long aOffset\,
                                      Object b\, long bOffset\,
                                      long length\,
                                      int log2ArrayIndexScale\)

Then you can specialize mismatch of memory segments for length threshold and type (the threshold only really makes
sense for the first check, once you go over `Integer.MAX_VALUE` the cost of another round with a small length part is
really low overall).

To be clear - are you suggesting to add vectorizedMismatchLarge inside
ArraySupport (but not add intrinsic support for that, for now) - and
then to have the memory segment implementation to call either that or
the standard version based on whether the segment is small or not?

Maurizio

@mlbridge
Copy link

@mlbridge mlbridge bot commented May 20, 2020

Mailing list message from Paul Sandoz on panama-dev:

Yes, add the ?large? strip mining implementation to ArraysSupport. I think it unlikely this method ever needs to be made intrinsic. For large loop bounds it's important that we don?t starve the system (allow for safe points), so it?s easier to do that from Java than in the intrinsic stub or in C2.

Then the memory segment code can use the those primitives based on thresholds. I suspect it can get away with just calling the large version, after a check for a small threshold value and a scalar loop.

Paul.

On May 20, 2020, at 8:53 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:

On 20/05/2020 16:36, Paul Sandoz wrote:

On Wed, 20 May 2020 14:06:48 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

Hi,

As part of feedback on the Foreign Memory API (when experimenting with its usage internally in the JDK), a small number
of potential usability enhancements could be made to the API. This is the fourth such, and last on my current todo
list. This change proposes to add a new method:
MemorySegment::mismatch

The mismatch semantic is very useful for building equality and comparison logic on top of segments. I found that I
needed such when modeling and comparing native socket address in the JDK implementation. It is possible to write your
own, but requires a non-trivial amount of not-trivial code - to do it right! I also think that we can provide a more
efficient implementation building on top of the JDK's internal mismatch support. I still need to do some perf testing
and add a micro-benchmake ( Maurizio suggested possibly amending TestBulkOps ). There is also the question about
possibly improving the JDK's internal implementation to work on long sizes (which could be done separately). For now, I
just want to share the idea, along with the proposed specification and initial implementation. Comments welcome.
Very nice.

Improving the JDK implementation is good. In fact i think you could so that now. In `ArraysSupport`, with strip mining:

public static int vectorizedMismatchLarge\(
                                     Object a\, long aOffset\,
                                     Object b\, long bOffset\,
                                     long length\,
                                     int log2ArrayIndexScale\)

Then you can specialize mismatch of memory segments for length threshold and type (the threshold only really makes
sense for the first check, once you go over `Integer.MAX_VALUE` the cost of another round with a small length part is
really low overall).

To be clear - are you suggesting to add vectorizedMismatchLarge inside ArraySupport (but not add intrinsic support for that, for now) - and then to have the memory segment implementation to call either that or the standard version based on whether the segment is small or not?

Maurizio

Copy link
Collaborator

@mcimadamore mcimadamore left a comment

Looks good

return i;
}
}
return thisSize != thatSize ? length : -1;

This comment has been minimized.

@mcimadamore

mcimadamore May 20, 2020
Collaborator

I guess I'm a bit confused - shouldn't this method return (as per javadoc), -1 if there's no mismatch? In this code path we found no mismatch, and yet, if sizes are different we return length, suggesting there's a mismatch. I now realize that mismatch is taken quite literally - e.g. no mismatch really means the two things are identical in contents and size --- which is, I realize, what Arrays::mismatch also does.

IMHO the javadoc of the various mismatch routines could use more clarity around what a mismatch is. But maybe that's something for another day.

@mlbridge
Copy link

@mlbridge mlbridge bot commented May 20, 2020

Mailing list message from Paul Sandoz on panama-dev:

If the two segments are are different lengths and one segment is a proper prefix of the other (all elements are equal) there is a mismatch in the length. It?s described more formally in the JavaDoc of the Arrays.mismatch methods. e.g

* <p>If the two arrays share a common prefix then the returned index is the
* length of the common prefix and it follows that there is a mismatch
* between the two elements at that index within the respective arrays.
* If one array is a proper prefix of the other then the returned index is
* the length of the smaller array and it follows that the index is only
* valid for the larger array.
* Otherwise, there is no mismatch.

Paul.

@ChrisHegarty
Copy link
Member Author

@ChrisHegarty ChrisHegarty commented May 21, 2020

The proposed MemorySegment::mismatch spec wording is aligned with similar in the buffer classes and elsewhere. If it needs clarification then we should probably do so consistently. As @mcimadamore said, "that's something for another day" ;-)

@ChrisHegarty
Copy link
Member Author

@ChrisHegarty ChrisHegarty commented May 21, 2020

/integrate

@openjdk openjdk bot added the sponsor label May 21, 2020
@openjdk
Copy link

@openjdk openjdk bot commented May 21, 2020

@ChrisHegarty
Your change (at version caf136f) is now ready to be sponsored by a Committer.

@openjdk openjdk bot removed the sponsor label May 21, 2020
Copy link
Collaborator

@mcimadamore mcimadamore left a comment

Looks good!

@mcimadamore
Copy link
Collaborator

@mcimadamore mcimadamore commented May 21, 2020

/sponsor

@openjdk
Copy link

@openjdk openjdk bot commented May 21, 2020

@mcimadamore The PR has been updated since the change author (@ChrisHegarty) issued the integrate command - the author must perform this command again.

@ChrisHegarty
Copy link
Member Author

@ChrisHegarty ChrisHegarty commented May 22, 2020

/integrate

@openjdk
Copy link

@openjdk openjdk bot commented May 22, 2020

@ChrisHegarty
Your change (at version d525e57) is now ready to be sponsored by a Committer.

@openjdk openjdk bot added the sponsor label May 22, 2020
@mcimadamore
Copy link
Collaborator

@mcimadamore mcimadamore commented May 25, 2020

/sponsor

@openjdk openjdk bot closed this May 25, 2020
@openjdk openjdk bot added integrated and removed sponsor ready rfr labels May 25, 2020
@openjdk
Copy link

@openjdk openjdk bot commented May 25, 2020

@mcimadamore @ChrisHegarty The following commits have been pushed to foreign-memaccess since your change was applied:

  • f024ca7: Automatic merge of master into foreign-memaccess
  • 046af8c: Automatic merge of jdk:master into master
  • de37507: 8245619: Remove unused methods in UnixNativeDispatcher
  • 113c48f: 8215401: Add isEmpty default method to CharSequence
  • 7d330d3: 8245335: [TESTBUG] DeterministicDump.java fails with release JVM
  • f72b574: 8245459: Add support for complex filter value var handle adaptation
  • ea38873: 8239480: Support for CLDR version 37
  • b5b6ae3: 8245241: Incorrect locale provider preference is not logged
  • e3be308: 8245260: Missing file header for test/hotspot/jtreg/containers/docker/TEST.properties
  • 270674c: Merge
  • 20dbc94: 8245518: Problem list java/net/SocketOption/AfterClose.java
  • 040d70c: 8238592: JFR: Crash when dumping paths to gc roots on deep heaps
  • 804576e: Added tag jdk-15+24 for changeset 497fd9f9129c
  • f39a0d5: Merge
  • 071bd52: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports
  • 9fe4b69: 8235921: jdk/jfr/event/oldobject/TestLargeRootSet.java times out with debug bits
  • 59dc384: Merge
  • 6651425: 8244733: Add ResourceHashtable::xxx_if_absent
  • ac93f38: 8245463: Shenandoah: refine ShenandoahPhaseTimings constructor arguments
  • 0a94d85: 8245461: Shenandoah: refine mode name()-s
  • 3f7cd1f: 8244416: Remove incorrect assert during inline cache cleaning
  • afe76a9: 8245398: Remove addition preview adornment from String::formatted
  • 600d82a: 8245281: Disabling hotspot gtest builds make it impossible to run tests
  • d191d2f: 8245445: Langtools NetBeans ant build broken after JDK-8244093
  • 47ceb80: 8245428: Remove unused oopFactory functions
  • 9ae8b32: 8233553: [TESTBUG] JSpinner test bug4973721.java fails on MacOS
  • 3d659ef: 8245000: Windows GDI functions don't support large pages
  • 6f29ba1: 8245002: Windows GDI functions don't support NUMA interleaving
  • 0d5f654: 8245042: Improve scalability of reading Windows Performance counters via PDH when using the Process object
  • 8c7fac8: 8245450: ZGC: Remove unused ZArguments::initialize_platform()
  • 6812f6f: 8218173: exception during StringConcatFactory clinit breaks string concat with no fallback
  • 6508c5a: 8243996: Remove hardcoded field offsets from HotSpot
  • 1f233c8: 6949753: [TEST BUG]: java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop
  • 9c415c4: 8243925: Toolkit#getScreenInsets() returns wrong value on HiDPI screens (Windows)
  • 08ded85: 8245165: Update bug id for javax/swing/text/StyledEditorKit/4506788/bug4506788.java in ProblemList
  • f76b6e7: 8238824: [macos] javax/swing/JSpinner/4840869/bug4840869.java fails on macos
  • 4cf3e6b: 8238085: PIT: javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java fails on Mac
  • 79905b1: 8229856: [macos] Opening a menu on a JTextField can clear the text selection
  • d8510ea: Merge
  • 15d7ef7: 8244667: Shenandoah: SBC2Support::test_gc_state takes loop for wrong control
  • bdb8ef1: 8242150: [GRAAL] Add jtreg "serviceability/sa/ClhsdbJstackXcompStress.java" to graal problem list
  • 93fcbec: 8243099: SO_INCOMING_NAPI_ID support
  • 822ec45: 8245401: AbsPathsInImage.java fails on Windows on jdwp.dll
  • 3802524: 8245288: Shenandoah: move up ShenandoahEvacOOM scope for code root processing during concurrent class unloading
  • 5b3c33a: 8245022: ParallelGC abuses StarTask to also include partial objarray scan tasks
  • 275079c: 8245240: Shenandoah: support nesting evacuation OOM scope
  • 612c38c: 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse
  • 58adc04: 8244031: HttpClient should have more tests for HEAD requests
  • 692f753: 8240910: jmod rejects duplicate entries in --class-path jars
  • f351901: 8244508: JFR: FlightRecorderOptions reset date format
  • e544a6a: Merge
  • 59eb031: 8237888: security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java fails when checking validity interval
  • d5b5059: 8244653: Suppress gcc 9.1 ABI change notes on aarch64
  • b75ea9b: Merge
  • 1f2f808: 8233643: [TESTBUG] JMenu test bug4515762.java fails on macos
  • 5f0d11e: 8233642: [TESTBUG] JMenuBar test bug 4750590.java fails on macos
  • f64bded: 8244557: test/jdk/javax/swing/JTabbedPane/TestBackgroundScrollPolicy.java failed
  • c3e3459: 8244183: linker error jpackageapplauncher on Windows 32bit
  • 58a34f7: 8244291: Test: gc/z/TestGarbageCollectorMXBean.java failed: "unexpected cycles"
  • e9b8463: 8245236: Remove MO_VOLATILE Access decorator
  • 18db3de: 8244164: AArch64: jaotc generates incorrect code for compressed OOPs with non-zero heap base
  • 6cbf57a: 8245147: Refactor and improve utility of test/langtools/tools/javac/versions/Versions.java
  • dc38439: 8229829: java/lang/management/ThreadMXBean/Locks.java fails with java.lang.RuntimeException: Thread WaitingThread is at WAITING state but is expected to be in Thread.State = WAITING
  • 939c0a4: 8245035: Clean up os::split_reserved_memory()
  • d3e0c4c: 8244966: Add .vscode to .hgignore and .gitignore
  • 104ea2d: 8244170: [aarch64] correct instruction typo for dcps1/2/3
  • 554e988: 8243396: Add a brief description of argfiles to the javadoc help output
  • 9d4872f: 8241080: Consolidate signature parsing code in serviceability tools
  • fa36d28: 8245280: Add runtime/cds/appcds/SignedJar.java to problem list
  • 1cb7df6: 8245287: Start using ModuleWrapper for gensrc as well
  • 74f1e6d: 8244093: Move all IDE support into coherent structure in make directory
  • b6fde85: 8245047: [PPC64] C2: ReverseBytes + Load always match to unordered Load (acquire semantics missing)
  • ebf928a: 8244819: hsdis does not compile with binutils 2.34+
  • 13cf783: 8209632: Develop new tests for EdDSA API
  • 77826c0: 8245168: jlink should not be treated as a "small" tool
  • 8ec7512: 8245106: ZGC: Fix incorrect setup when using -XX:+UseTransparentHugePages
  • bcf99aa: 8245098: Make SafeFetch32/N available earlier
  • ce6aadb: 8245196: ZGC: No need to disable UseBiasedLocking by default
  • cc3a859: 8245233: ZGC: Load volatile oops using Atomic::load()
  • 080b3b8: 8242151: Improve OID mapping and reuse among JDK security providers for aliases registration
  • a97932d: 8245151: jarsigner should not raise duplicate warnings on verification
  • 4159f68: 8233706: JFR emergency dump should be performed after error reporting
  • b08140d: 8245231: Javadoc for the readObject methods needs to be updated
  • 039cb65: 8239816: Make handling of module / package / types consistent
  • b265163: 8245124: Shenandoah: optimize code root evacuation/update during concurrent class unloading
  • 3eaf944: 8244342: Compilation warnings about unexpected serialization related method signatures
  • fd28aad: 8166597: Crypto support for the EdDSA Signature Algorithm
  • 02293da: 8245070: 32-bit builds are broken after JDK-8242524
  • 60728a4: 8242424: Deprecate InitialBootClassLoaderMetaspaceSize
  • b957788: 8245137: aarch64 ICache flush depends on enabling gnu extensions
  • 840c305: 8237971: Package type for runtime image on macosx
  • 6bd9391: 8244433: Remove saving of RSP in Assembler::pusha_uncached()
  • eb91535: 8172269: When checking the default behaviour for a scroll tab layout and checking the 'opaque' checkbox, the area behind tabs is not red
  • ddb1d7a: 8232243: Wrong caret position in JTextPane on Windows with a screen resolution > 100%
  • a040c56: 8221305: java/awt/FontMetrics/MaxAdvanceIsMax.java fails on MacOS + Solaris
  • 823d1d2: 8233638: [TESTBUG] Swing test ScreenMenuBarInputTwice.java fails on macos
  • 4071546: 8221902: PIT: javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java fails on ubuntu
  • 2731d62: Merge
  • eb6ef3c: 8243436: use reproducible random in :vmTestbase_nsk_monitoring
  • d29e5b7: 8243435: use reproducible random in :vmTestbase_nsk_jvmti
  • 56fcd54: 8243437: use reproducible random in :vmTestbase_nsk_jdi
  • b938a4c: 8244113: [TESTBUG] java/awt/font/Rotate/RotatedSyntheticBoldTest.java test comments interpreted as args
  • a777dcf: 8225069: Remove Comodo root certificate that is expiring in May 2020
  • 832272d: 8178349: Cache builtin class loader constraints to avoid re-initializing itable/vtable for shared classes
  • eaf3306: 8243433: use reproducible random in :vmTestbase_nsk_sysdict
  • 0264b05: 8243429: use reproducible random in :vmTestbase_nsk_stress
  • da064f8: 8244226: Shenandoah: per-cycle statistics contain worker data from previous cycles
  • 318fab9: 8242541: Small charset issues (ISO8859-16, x-eucJP-Open, x-IBM834 and x-IBM949C)
  • 26e37d1: 8232744: j.awt.Window::setShape(Shape) paints visible artifacts outside of the given shape
  • b3e1ea0: Merge
  • 188106b: 8242557: Add length limit for strings in PNGImageWriter
  • 7dad5d2: 8226464: TitledBorder label appears cut off on hidpi devices
  • e9cc3da: 8208566: [TEST_BUG] javax\swing\text\GlyphPainter2\6427244\bug6427244.java: Test failed
  • ed9cbe2: 8241616: Timestamps on ct.sym entries lead to non-reproducible builds
  • 31479a0: 8244752: Enable Linux support for multiple huge page sizes -XX:LargePageSizeInBytes
  • dde3b90: 8244981: jpackage error due to missing final newline in Debian control file
  • 76b7665: 8235673: [C1, C2] Split inlining control flags
  • d5bd523: 8244536: cds/DeterministicDump.java failed: File content different
  • 0f7aeed: 8241305: Add protocol specific factory creation methods to SocketChannel and ServerSocketChannel
  • 42bad03: 8245146: Update description of SourceVersion.RELEASE_15 with text blocks
  • 9efdaac: 8242478: compiler implementation for records (Second Preview)
  • a2057ad: 8240228: "make hotspot-ide-project" on Windows creates a Visual Studio project with empty preprocessor defines
  • a09720f: 8232213: runtime/MemberName/MemberNameLeak.java fails intermittently
  • 46cf294: 8245005: javax/net/ssl/compatibility/BasicConnectTest.java failed with No enum constant
  • 1e251e9: 8241070: Shenandoah: remove unused local variables in C2 support
  • 6d98502: 8244663: Shenandoah: C2 assertion fails in Matcher::collect_null_checks
  • 36fb21d: 8245111: Update doc comments for improved processing by the Standard Doclet
  • 35a7eff: 8244721: CTW: C2 (Shenandoah) compilation fails with "unexpected infinite loop graph shape"
  • b61c88c: 8245083: [REDO] Shenandoah: Remove null-handling in LRB expansion
  • fb6e7b0: 8245119: Fix include path for hotspot-ide-project
  • 150d6cf: 8245094: Reduce overhead of initializing the default StringConcatFactory strategy
  • e839687: 8245096: Better windows environment output in configure
  • adf1d47: 8245093: WSL support broke cygwin toolchain detection
  • fad2cf5: 8241072: Reimplement the Legacy DatagramSocket API
  • 3930460: 8244953: Shenandoah: gc/shenandoah/TestStringInternCleanup fails with broken string table root
  • 178e69a: 8244652: Add test for non utf-8 response handling by websocket
  • 0d2cc3b: 8169953: JComboBox/8057893: ComboBoxEdited event is not fired! on Windows
  • 943f8df: 8230672: Specification for java.awt.FontMetrics.getMaxAdvance() is too prescriptive
  • 70165f5: 8197797: Test java/awt/Graphics2D/DrawString/RotTransText.java fails
  • 14b7dd4: 7185258: [macosx] Deadlock in SunToolKit.realSync()
  • b36738a: 8238575: DragSourceEvent.getLocation() returns wrong value on HiDPI screens (Windows)
  • a0a9595: 8236980: Cleanup of toString methods in JavaSound
  • c18080f: 8213123: javax/swing/JButton/4368790/bug4368790.java fails on mac

Your commit was automatically rebased without conflicts.

Pushed as commit cd39750.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.