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

Move "owner" field and thread-confinement checks to MemoryScope #167

Conversation

@plevart
Copy link
Contributor

@plevart plevart commented May 15, 2020

Now MemoryScope is simplified, I re-based this change and am opening this PR on top. Currently MemorySegment is encapsulating thread-confinement logic and state (owner field) while MemoryScope is encapsulating temporal-confinement logic and state. But the interplay between the two must be very carefully caried out (for example, close() or dup() on child scopes may only be called in owner thread). By moving the thread-confinement logic and state to MemoryScope, I think we get better encapsulation as all MemoryScope methods become "safe" - some can still be called in owner thread only, but failing to do so throws IllegalSateException instead of exhibiting undefined behavior.


Progress

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

Reviewers

Download

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

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented May 15, 2020

👋 Welcome back plevart! 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 15, 2020
@mlbridge
Copy link

@mlbridge mlbridge bot commented May 15, 2020

Copy link
Collaborator

@mcimadamore mcimadamore left a comment

Overall, I like this and I agree that moving ownership in scope makes the code easier to follow. I've added some specific comments.

* the returned scope is <em>not</em> thread-confined and not checked.
* @return a root MemoryScope
*/
static MemoryScope createUnchecked(Object ref, Runnable cleanupAction, Thread owner) {

This comment has been minimized.

@mcimadamore

mcimadamore May 15, 2020
Collaborator

For some (merely stylistic) reason, I'd prefer to see owner coming first in the parameter list

}

boolean closed = false;
private final Thread owner;
boolean closed; // = false

This comment has been minimized.

@mcimadamore

mcimadamore May 15, 2020
Collaborator

Is there any real advantage in not having the initialization here? I mean, I get we probably save one putfield - but I would say that if the code is hot, C2 is probably able to detect that the store is useless? I kind of prefer the code to be self-evident rather then to use comments, where possible, of course. I've seen in the past cases where seemingly innocuous redundant initializer subtly changed happens-before order; but this shouldn't be the case here?

This comment has been minimized.

@mcimadamore

mcimadamore May 15, 2020
Collaborator

So maybe just rename the parameter to newOwner ?

Yes please

* If this is a root scope, new root scope is returned, this root scope is closed but
* eventual cleanup action is not executed yet - it is inherited by duped scope.
Comment on lines 138 to 139

This comment has been minimized.

@mcimadamore

mcimadamore May 15, 2020
Collaborator

Suggested change
* If this is a root scope, new root scope is returned, this root scope is closed but
* eventual cleanup action is not executed yet - it is inherited by duped scope.
* If this is a root scope, a new root scope is returned; this root scope is closed, but
* without executing the cleanup action, which is instead transferred to the duped scope.
* If this is a child scope, new child scope is returned.
* This method may only be called in "owner" thread of this scope unless the
Comment on lines 140 to 141

This comment has been minimized.

@mcimadamore

mcimadamore May 15, 2020
Collaborator

Suggested change
* If this is a child scope, new child scope is returned.
* This method may only be called in "owner" thread of this scope unless the
* If this is a child scope, a new child scope is returned.
* This method may only be called in the "owner" thread of this scope unless the
*
* @throws IllegalStateException if this scope is already closed
*/
@ForceInline
final void checkAliveConfined() {

This comment has been minimized.

@mcimadamore

mcimadamore May 15, 2020
Collaborator

Consider making this private

MemoryScope dup() { // always called in owner thread
return closeOrDup(false);
MemoryScope dup(Thread owner) {
Objects.requireNonNull(owner, "owner");

This comment has been minimized.

@mcimadamore

mcimadamore May 15, 2020
Collaborator

Uhm - not sure about this. Let's say that you have an unchecked segment - you start off unconfined - but then, after some processing, you want to kill the segment and obtained a confined view. Seems a legitimate use case? Although I agree that, in that case, we'd need at least some sort of atomic handshake on the closed bit, to ensure the update either fails or succeeds across multiple racy threads.

}

private MemoryScope closeOrDup(boolean close) {
private MemoryScope closeOrDup(Thread newOwner) {

This comment has been minimized.

@mcimadamore

mcimadamore May 15, 2020
Collaborator

I think I don't like this way of sharing the code. Since we're in cleanup mode, I think the code would be more readable by having two separate methods close and dup which both uses the same underlying logic for flipping the liveness bit (using the lock).

@mlbridge
Copy link

@mlbridge mlbridge bot commented May 15, 2020

Mailing list message from Peter Levart on panama-dev:

Hi Maurizio, comments inline...

On 5/15/20 11:44 AM, Maurizio Cimadamore wrote:

On Fri, 15 May 2020 08:56:14 GMT, Peter Levart <plevart at openjdk.org> wrote:

Now MemoryScope is simplified, I re-based this change and am opening this PR on top. Currently MemorySegment is
encapsulating thread-confinement logic and state (owner field) while MemoryScope is encapsulating temporal-confinement
logic and state. But the interplay between the two must be very carefully caried out (for example, close() or dup() on
child scopes may only be called in owner thread). By moving the thread-confinement logic and state to MemoryScope, I
think we get better encapsulation as all MemoryScope methods become "safe" - some can still be called in owner thread
only, but failing to do so throws IllegalSateException instead of exhibiting undefined behavior.
Overall, I like this and I agree that moving ownership in scope makes the code easier to follow. I've added some
specific comments.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java line 90:

89: */
90: static MemoryScope createUnchecked(Object ref, Runnable cleanupAction, Thread owner) {
91: return new Root(owner, ref, cleanupAction);
For some (merely stylistic) reason, I'd prefer to see `owner` coming first in the parameter list

Ok, moving it as 1st parameter.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java line 95:

94: private final Thread owner;
95: boolean closed; // = false
96: private static final VarHandle CLOSED;
Is there any real advantage in not having the initialization here? I mean, I get we probably save one putfield - but I
would say that if the code is hot, C2 is probably able to detect that the store is useless? I kind of prefer the code
to be self-evident rather then to use comments, where possible, of course. I've seen in the past cases where seemingly
innocuous redundant initializer subtly changed happens-before order; but this shouldn't be the case here?

If there is a data race (publishing reference to scope), then I think
JMM may allow this write to end up in final memory location later than
for example another write that puts true to this field. So while C2 may
optimize this write into no-op, it may still theoretically cause
trouble. This is only theory of what is allowed by JMM of course. All
fields of an object already get their 1st implicit initializing write
which is different as it is guaranteed to happen before any read of that
field. An explicit write is not given such guarantee (unless the field
is final).

While publishing scope is never performed via data race in our case
(scope is assigned to final field in MemorySegment), it is a good
property of a class to allow such usage (like String for example) in
particular if such class is security or stability sensitive and/or it
may be used elsewhere hypothetically. So initializing plain fields to
their default values is never a good thing and is, IMHO just a relic
from C, where they did not get the implicit initialization. I think Java
is old enough that everybody knows this difference even without hints in
comments. So maybe just remove the comment?

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java line 139:

138: * If this is a root scope, new root scope is returned, this root scope is closed but
139: * eventual cleanup action is not executed yet - it is inherited by duped scope.
140: * If this is a child scope, new child scope is returned.
Suggestion:

  \* If this is a root scope\, a new root scope is returned\; this root scope is closed\, but
  \* without executing the cleanup action\, which is instead transferred to the duped scope\.

Better. Will change.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java line 141:

140: * If this is a child scope, new child scope is returned.
141: * This method may only be called in "owner" thread of this scope unless the
142: * scope is a root scope with no owner thread - i.e. is not checked.
Suggestion:

  \* If this is a child scope\, a new child scope is returned\.
  \* This method may only be called in the \"owner\" thread of this scope unless the

Will change.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java line 203:

202: @forceinline
203: final void checkAliveConfined() {
204: if (closed) {
Consider making this private

If I make it private, it is not accessible in subclasses although they
are nestmates unless I do something like that:

((MemoryScope)this).checkAliveConfined();

Do you prefer such call gymnastics? If this class gets used elsewhere
then maybe it will be required...

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java line 250:

249: MemoryScope dup(Thread owner) {
250: Objects.requireNonNull(owner, "owner");
251: return closeOrDup(owner);
Uhm - not sure about this. Let's say that you have an unchecked segment - you start off unconfined - but then, after
some processing, you want to kill the segment and obtained a confined view. Seems a legitimate use case? Although I
agree that, in that case, we'd need at least some sort of atomic handshake on the closed bit, to ensure the update
either fails or succeeds across multiple racy threads.

So above, the check is made against the parameter "owner" not the field
"owner". This means that we are preventing another usecase where one
would want to "transfer" ownership to nobody - when one would start with
confined segment and then wanted to obtain an unconfined segment from it.

This is already prevented in the MemorySegment too:

??? public MemorySegment withOwnerThread(Thread newOwner) {
??????? Objects.requireNonNull(newOwner);

So maybe just rename the parameter to newOwner ?

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MemoryScope.java line 259:

258:
259: private MemoryScope closeOrDup(Thread newOwner) {
260: // pre-allocate duped scope so we don't get OOME later and be left with this scope closed
I think I don't like this way of sharing the code. Since we're in cleanup mode, I think the code would be more readable
by having two separate methods `close` and `dup` which both uses the same underlying logic for flipping the liveness
bit (using the lock).

I think the sharing can be performed in a more readable way. Will show
in an update...

Regards, Peter

@mcimadamore
Copy link
Collaborator

@mcimadamore mcimadamore commented May 15, 2020

So maybe just remove the comment?

No, leave it there - I'm fine with the explanation.

@mcimadamore
Copy link
Collaborator

@mcimadamore mcimadamore commented May 15, 2020

((MemoryScope)this).checkAliveConfined();

Do you prefer such call gymnastics? If this class gets used elsewhere
then maybe it will be required...

Ugh - I missed subclass usages. Perhaps a private static routine in the toplevel class. But it's also ok if you leave it like that.

Copy link
Collaborator

@mcimadamore mcimadamore left a comment

Looks good. Thanks.

}

@Override
void close() {
closeOrDup(null);
justClose();

This comment has been minimized.

@mcimadamore

mcimadamore May 15, 2020
Collaborator

This is exactly what I had in mind - I think the code is cleaner. Perhaps rename justClose to doClose (and make doClose private) - but that's minor - I'll leave that up to you.

This comment has been minimized.

@plevart

plevart May 15, 2020
Author Contributor

I think justClose() tells more that doClose() and private it is.

@openjdk
Copy link

@openjdk openjdk bot commented May 15, 2020

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

Move "owner" field and thread-confinement checks to MemoryScope

Reviewed-by: mcimadamore
  • 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 113 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 39ab61868cc2c968033d0b3d1c1755717b833f42.

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) 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 15, 2020
@plevart
Copy link
Contributor Author

@plevart plevart commented May 15, 2020

I hid checkAliveConfined (by making it private static) and also the closed field which has the same poblem of being access from subclass if it is private. But there's no such problem if it is accessed via VarHandle. Would that be OK?

@plevart
Copy link
Contributor Author

@plevart plevart commented May 15, 2020

I ran the tests and the TestSegments.testOpOutsideConfinement(close) fails with this change. The fix follows.

@mcimadamore
Copy link
Collaborator

@mcimadamore mcimadamore commented May 15, 2020

I ran the tests and the TestSegments.testOpOutsideConfinement(close) fails with this change. The fix follows.

In the latest iteration I don't see any change that could possibly affect the test (compared to the previous iteration I mean). Are you also working on a followup fix for the test?

if (owner != null) {
if (owner != Thread.currentThread()) {
throw new IllegalStateException("Attempted access outside owning thread");
}
checkAliveConfined(this);
}
Comment on lines 187 to 192

This comment has been minimized.

@JornVernee

JornVernee May 15, 2020
Member

This changes the behavior we had before in AbstractMemorySegmentImpl::checkValidState. We should still do the liveness check even if there is no owner.

Suggested change
if (owner != null) {
if (owner != Thread.currentThread()) {
throw new IllegalStateException("Attempted access outside owning thread");
}
checkAliveConfined(this);
}
if (owner != null && owner != Thread.currentThread()) {
throw new IllegalStateException("Attempted access outside owning thread");
}
checkAliveConfined(this);

This comment has been minimized.

@mcimadamore

mcimadamore May 15, 2020
Collaborator

This changes the behavior we had before in AbstractMemorySegmentImpl::checkValidState. We should still do the liveness check even if there is no owner.

True - I suspect Peter would argue that such check doesn't make much sense in a racy context - but still, there's a change in behavior here.

This comment has been minimized.

@JornVernee

JornVernee May 15, 2020
Member

IMO It's not necessarily racy, it's just that the API doesn't guarantee that there is no race, that's up to the user to do. e.g. by making sure that the thread doing the access can see an up to date liveness flag (by using other synchronization).

This comment has been minimized.

@plevart

plevart May 15, 2020
Author Contributor

Ok, then another change follows...

Copy link
Collaborator

@mcimadamore mcimadamore left a comment

Looks good - thanks for spotting the test issue.

…be racy without outside synchronization
@plevart
Copy link
Contributor Author

@plevart plevart commented May 15, 2020

Tests still pass after this change.

Copy link
Collaborator

@mcimadamore mcimadamore left a comment

LGTM

@plevart
Copy link
Contributor Author

@plevart plevart commented May 15, 2020

/integrate

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

@openjdk openjdk bot commented May 15, 2020

@plevart
Your change (at version 66a821d) is now ready to be sponsored by a Committer.

@mcimadamore
Copy link
Collaborator

@mcimadamore mcimadamore commented May 15, 2020

/sponsor

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

@openjdk openjdk bot commented May 15, 2020

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

  • 39ab618: Automatic merge of master into foreign-memaccess
  • 37d5e5f: Automatic merge of jdk:master into master
  • 2349db7: Add MemorySegment::fill
  • 82f2a0e: 8245024: Simplify and eagerly initialize StringConcatFactory
  • b76a215: 8245046: SetupTarget incorrect for hotspot-ide-project
  • 4c54fa2: 8209774: Refactor shell test javax/xml/jaxp/common/8035437/run.sh to java
  • b883bad: 8244961: MethodHandles::privateLookupIn throws NPE when called during initPhase2
  • cab61f1: 8243012: Fix issues in j.l.i package info
  • 8da07d1: 8242524: Use different default CDS archives depending on UseCompressOops
  • 71cc95e: 8243947: [TESTBUG] hotspot/jtreg:hotspot_appcds_dynamic fails when the JDK doesn't have default CDS archive
  • 95b8e9e: 8244340: Handshake processing thread lacks yielding
  • 9a04631: 8244973: serviceability/attach/RemovingUnixDomainSocketTest.java fails "stderr was not empty"
  • 43da9ff: 8245032: Remove exceptions from compare.sh
  • 014095c: 8245041: Fix incorrect output order in configure
  • 8c54309: 8245033: Fixes for building in WSL
  • e13c481: 8218482: sun/security/krb5/auto/ReplayCachePrecise.java failed - no KrbException thrown
  • c992521: 8244951: Missing entitlements for hardened runtime
  • 0cc7f35: 8244576: [macos] Volume icon deleted by osascript for background image
  • 9768618: 8244945: Mark VS2019 as supported and default
  • 1856ff8: 8244684: G1 abuses StarTask to also include partial objarray scan tasks
  • 5b6f81d: 8244777: ClassLoaderStats VM Op uses constant hash value
  • 587505f: 8244971: Zero VM is broken after JDK-8241825 (COMPRESSED_CLASS_POINTERS_DEPENDS_ON_COMPRESSED_OOPS not defined)
  • 17dd7dc: 8240588: _threadObj cannot be used on an exiting JavaThread
  • be7771b: Added tag jdk-15+23 for changeset f143729ca00e
  • 80c75c9: 8239383: Support for Unicode 13.0
  • 073e095: 8235211: serviceability/attach/RemovingUnixDomainSocketTest.java fails with AttachNotSupportedException: Unable to open socket file
  • 659aa08: 8242901: Duplicate PSYoung/OldGen max size functions
  • 168cdcf: 8244936: Reduce JNI overhead of accessing FileDescriptor
  • ad2afe0: 8241062: Shenandoah: rich asserts trigger "empty statement" inspection
  • 92d1c4a: 8244775: Remove unnecessary dependency to jfrEvents.hpp
  • 49bfbd3: 8243417: Clean up com.sun.tools.javac.main.CommandLine
  • 3d50f24: 8244853: The static build of libextnet is missing the JNI_OnLoad_extnet function
  • 658fb7a: 8244852: GraalVM native-image fails after JDK-8238048 change
  • 398a2b3: 8231264: Implementation of JEP 374: Disable biased-locking and deprecate all flags related to biased-locking
  • ca53ee2: 8242934: test/jdk/jdk/jfr/tool/TestPrintJSON.java uses nashorn script engine
  • 707462e: 8244930: Building without test failure handler broken after JDK-8244844
  • fe46f44: 8244758: DMG bundler ignores --install-dir option
  • 382e5dc: 8241825: Make compressed oops and compressed class pointers independent (x86_64, PPC, S390)
  • 9651edd: 8244815: Always log MMU information in G1
  • 0dab181: 8244714: G1 young gen sizer allows zero young gen with huge -XX:NewRatio
  • 7345502: 8244928: Build log output too verbose after JDK-8244844
  • 820f722: 8242188: [TESTBUG] error in jtreg test jdk/jfr/api/consumer/TestRecordedFrame.java on linux-aarch64
  • e48410a: 8244634: LoadLibraryW failed from tools/jpackage tests after JDK-8242302
  • dc54da2: 8244407: JVM crashes after transformation in C2 IdealLoopTree::split_fall_in
  • cdf8cc5: 8244855: Remove unused "getParent" function from Windows jni_util_md.c
  • 06d6234: 8244767: Potential non-terminated string in getEncodingInternal() on Windows
  • be6f747: 8244844: javac command line is not re-executable
  • a726aca: 8242009: Review setting test.java/vm.opts in jcmd/jhsdb and debugger in serviceability tests
  • e686fb6: 8244757: Introduce SetupTarget in Main.gmk
  • e722efa: 8244807: Shenandoah: ditch filter in ShenandoahUnload::unload
  • ba59fe9: 8244813: [BACKOUT] 8244523: Shenandoah: Remove null-handling in LRB expansion
  • 25dcb1f: 8244821: Shenandoah: disarmed_value is initialized at wrong place
  • a6cdce1: 8244661: JFR: Remove use of thread-locals for java.base events
  • b29d982: 8244756: Build broken with some awk version after JDK-8244248
  • 52e1bec: 8022574: remove HaltNode code after uncommon trap calls
  • cc47d0a: 8244674: Third-party code version check
  • 45e0c6a: 8244759: Shenandoah: print verbose class unloading counters
  • 46d2879: 8244779: ProblemList serviceability/jvmti/HiddenClass/P/Q/HiddenClassSigTest.java pending JDK-8244571
  • babaab2: 8242429: Better implementation for sign extract
  • 9122028: 8147018: CompilerControl: Improve handling of timeouts and failures for tests
  • fc842d2: 8193066: Avoid use of capturing lambdas in JarFile
  • 3b93676: 8244676: test/jdk/jdk/jfr/startupargs/TestOptionsWithLocale.java fails
  • 9253c29: 8244620: Fix test WinUpgradeUUIDTest failures in Mach5
  • 7882592: 8244151: Update MUSCLE PC/SC-Lite headers to the latest release 1.8.26
  • aebc856: 8194874: SA: Remove scripts with sa-jdi.jar dependencies
  • d5414d7: 8244740: Shenandoah: rename ShenandoahNormalMode to ShenandoahSATBMode
  • 4016667: 8244739: Shenandoah: break superclass dependency on ShenandoahNormalMode
  • e3138f8: 8244737: Shenandoah: move mode code to gc/shenandoah/mode
  • f37b72c: 8244732: Shenandoah: move heuristics code to gc/shenandoah/heuristics
  • 68e55bd: 8244730: Shenandoah: gc/shenandoah/options/TestHeuristicsUnlock.java should only verify the heuristics
  • 39670b0: 8241934: Simplify parse_stream() and remove has_class_mirror_holder_cld()
  • 3887904: 8244207: Simplify usage of Compile::print_method() when debugging with gdb and enable its use with rr
  • ceda308: 8244624: Improve handling of JarFile META-INF resources
  • a06585a: 8244673: Add periods to SourceVersion.isName javadoc
  • d8510ea: Merge
  • 15d7ef7: 8244667: Shenandoah: SBC2Support::test_gc_state takes loop for wrong control
  • 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
  • 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
  • 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 928a8af.

@plevart plevart deleted the plevart:foreign-memaccess-thread-confined-scope branch May 15, 2020
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.