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

Alternative scalable MemoryScope #142

Closed
wants to merge 3 commits into from

Conversation

@plevart
Copy link
Contributor

@plevart plevart commented May 3, 2020

This is an alternative MemoryScope which is more scalable when used in a scenario where child scope is frequently acquired and closed concurrently from multiple threads (for example in parallel Stream.findAny())


Progress

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

Reviewers

Download

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

@bridgekeeper bridgekeeper bot added the oca label May 3, 2020
@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented May 3, 2020

Hi @plevart, welcome to this OpenJDK project and thanks for contributing!

We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing /signed in a comment in this pull request.

If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user plevart" as summary for the issue.

If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing /covered in a comment in this pull request.

@openjdk
Copy link

@openjdk openjdk bot commented May 3, 2020

⚠️ @plevart a branch with the same name as the source branch for this pull request (foreign-memaccess) is present in the target repository. If you eventually integrate this pull request then the branch foreign-memaccess in your personal fork will diverge once you sync your personal fork with the upstream repository.

To avoid this situation, create a new branch for your changes and reset the foreign-memaccess branch. You can do this by running the following commands in a local repository for your personal fork. Note: you do not have to name the new branch NEW-BRANCH-NAME.

$ git checkout -b NEW-BRANCH-NAME
$ git branch -f foreign-memaccess 4397c2d060856538f52cc8165dc94fd0cc9fa0fc
$ git push -f origin foreign-memaccess

Then proceed to create a new pull request with NEW-BRANCH-NAME as the source branch and close this one.

@bridgekeeper bridgekeeper bot removed the oca label May 4, 2020
@openjdk openjdk bot added the rfr label May 4, 2020
@mlbridge
Copy link

@mlbridge mlbridge bot commented May 4, 2020

Webrevs

acquires.increment();
// check state 2nd
int state = (int) STATE.getVolatile(this);
while (state > STATE_OPEN) {

This comment has been minimized.

@PaulSandoz

PaulSandoz May 4, 2020
Member

You could do the following to limit to one VH call:

int state;  // perhaps rename to not shadow the field
while ((state = (int) STATE.getVolatile(this)) > STATE_OPEN) {
   ...
}

This comment has been minimized.

@plevart

plevart May 5, 2020
Author Contributor

Sure, that's possible. Thanks.

return new MemoryScope(ref, this::release);
}
private static final class Root extends MemoryScope {
private final LongAdder acquires;

This comment has been minimized.

@PaulSandoz

PaulSandoz May 4, 2020
Member

Did you consider collapsing into just one LongAdder using increment (for acquiring), decrement (for releasing), and sum (checking a zero sum for closing)? Perhaps it was discussed already, i lost track of all the discussion.

This comment has been minimized.

@plevart

plevart May 5, 2020
Author Contributor

No, it was not discussed yet. I'm happy you brought it up. That would not work. LongAdder.sum() is not an atomic operation. Consider the following scenario:

  • precondition: adder.sum() == 0
  • thread A1 successfully acquires child segment: adder.sum() == 1
  • thread C calls close() on root segment
    • sets state = CLOSING
    • calls adder.sum() which starts summing LongAdder cells and just misses adder.increment() of thread A2...
  • thread A2 tries to acquire child segment and so it 1st does adder.increment()
  • thread A2 reads state == CLOSING and therefore undoes previous increment with adder.decrement() and fails, but...
  • thread C that just missed A2's adder.increment() does see A2's adder.decrement() because it is performed on a different LongAdder cell which C reads after it is incremented, so what C gets as a result of adder.sum() is 0, it completes closing the root segment by setting state = CLOSED and executing cleanup, but thread A1 still has access to the child segment and BOOM!!!

Having two LongAdders (acquires, releases) and doing the sum() per-partes sequentially: 1st releases.sum(), then acquires.sum() we guarantee that we never miss an acquiring thread's acquires.increment() but see the thread's releases.increment(), so above scenario is not possible.

This comment has been minimized.

@mcimadamore

mcimadamore May 5, 2020
Collaborator

I agree with Peter that using a single long would misses update and you could see 'zero' when in reality something has happened but sum didn't get the memo. The entire approach, as far as I understand, relies on subtle happens-before relationship which arise precisely because of the use of the two counters (and the fact that one counter is always updated before the other).

This comment has been minimized.

@plevart

plevart May 5, 2020
Author Contributor

...right and the fact that the sum() of both counters is performed in the opposite order as they are updated.

@PaulSandoz
Copy link
Member

@PaulSandoz PaulSandoz commented May 4, 2020

I think this should work under the well-defined Spliterator use case but might be problematic if made public sometime later on. For example:

MemorySegment s = ...
var a = s.acquire();
a.close();
var d = s.dup();
a.acquire();  // transiently affecting state of d since the adders are shared

There also might be ways to poke a Spliterator to induce such behaviour e.g. the Consumer passed to tryAdvance creating a new Spliterator from the given segment, and operating on that after the tryAdvance completes. Clearly that's not what someone should be doing but it's starting complex enough that it's hard to reason about the possible effects and whether they are harmless or not, at least for me :-)

@plevart
Copy link
Contributor Author

@plevart plevart commented May 5, 2020

So, in your scenario:

MemorySegment s = ...
var a = s.acquire();
a.close();
var d = s.dup();
a.acquire();  // transiently affecting state of d since the adders are shared

...the a.acquire() will fail, because s.state == CLOSED, but the shared acquires.sum() will briefly be greater than releases.sum() and therefore could affect d.close() in a way that it would cause spurious failure of d.close(). This is of course undesirable (like it was undesirable to have spurious failures of acquire() in previous versions of this MemoryScope until I added a two-phase close), so it would be best to not share the acquires/releases LongAdders with a duped MemoryScope. I'll fix this by creating new LongAdder instances for duped scope. Thanks.

//flush read/writes to memory before returning the new segment
VarHandle.fullFence();
}
return dup(0L, length, mask, newOwner, scope.dup());
}

This comment has been minimized.

@plevart

plevart May 5, 2020
Author Contributor

Maybe you're asking why did I remove this fullFence() call? I don't think it is needed. I checked all implementations of MemorySegment and they all contain just final fields. It is therefore safe to publish such instances via data races and no explicit fences are needed.

This comment has been minimized.

@mcimadamore

mcimadamore May 5, 2020
Collaborator

I think we had a discussion on this; we knew publishing segments was safe (all fields final), but there were some perplexities that the fences added at the end of the constructor were enough to warrant flushing of writes to the off-heap memory backing the segment (on all platforms). This effect is not covered (afaik) by the JMM.

This comment has been minimized.

@plevart

plevart May 5, 2020
Author Contributor

Ah, I see. Will revert that back then. But why is AbstractMemorySegmentImpl.withOwnerThread() doing this differently than AbstractMemorySegmentImpl.acquire() ? acquire() too is handing access to a different thread and in acquire() there is no explicit fence.

This comment has been minimized.

@mcimadamore

mcimadamore May 6, 2020
Collaborator

But why is AbstractMemorySegmentImpl.withOwnerThread() doing this differently than AbstractMemorySegmentImpl.acquire() ? acquire() too is handing access to a different thread and in acquire() there is no explicit fence.

This is a valid point. I guess from the past, acquire() meant "racy" - whereas for handoff patterns (e.g. withOwnerAccess) we wanted to be extra careful that only one thread at a time has access.

Note that, currently, while all acquired segments slices can be operated concurrently in a race-free fashion, unfortunately there is still the main segment that can be written/read concurrently by the original thread. So adding fences in this situation just kicks the can down the road.

If we had a way so that the original segment became inaccessible while splitted with a spliterator, then I'd agree with you that a fence would be ideal (since this is another case of handoff).

But it is very hard to invalidate the original segment; few options I've considered:

  • make the 'valid state' check more complex - e.g. in your implementation we could check whether the two counters yield same value before allowing access to the original thread - but I think this would be slow, and I think it could still allow races (this is a case of check & act - where we have no guarantees that, by the time memory is read/written, the condition we checked still holds true)

  • as we do in other places of the API - just kill the original segment after you split (e.g. make it not alive). This will make it inaccessible, which is consistent with what we want. But now there's a problem: how do you get back the original segment after you're done with the spliterator? Joining slices is messy. And add synchronization to allow for spliterators to be 'closed' atomically, will just add more contention.

So, it seems like the cost for fixing this particular issue is higher than the actual problem; there's an access mode called ACQUIRE - if a segment owner is not OK with having races with different threads - that mode can be disabled.

This comment has been minimized.

@plevart

plevart May 6, 2020
Author Contributor

Yeah, I was just thinking of the situation where a segment is passed to parallel stream and the threads of parallel stream operate on slices (acquired children) in read-only way, since this is the source of information and should not be mutated. Now if the segment was created and written to in one thread before handed to parallel stream then workers from the FJPool may not see the content of their slices (acquired children) fully initialized since normal synchronization like dispatch of control to other thread presumably doesn't have the same effect on the off-heap memory (on all platforms)?

This comment has been minimized.

@mcimadamore

mcimadamore May 6, 2020
Collaborator

Yeah, I was just thinking of the situation where a segment is passed to parallel stream and the threads of parallel stream operate on slices (acquired children) in read-only way, since this is the source of information and should not be mutated. Now if the segment was created and written to in one thread before handed to parallel stream then workers from the FJPool may not see the content of their slices (acquired children) fully initialized since normal synchronization like dispatch of control to other thread presumably doesn't have the same effect on the off-heap memory (on all platforms)?

I'm fine with adding the fence in principle - if it adds too much overhead (which I didn't try), I think we should leave it out though, since the benefits are limited.

Copy link
Collaborator

@mcimadamore mcimadamore left a comment

My comment here is mostly non-code-related; I've already seen the code and attempted to prove its correctness in this email:

https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066190.html

My concerns are:

  • some of the HB relationships in the code are quite non-obvious, subtle and hard to reason about (well, at least they were for me) - this means that, compared to current approach, there will be an high maintenance cost associated with this

  • In some of the benchmarks provided by Peter, the stream version of findAny is going several orders of magnitude slower than a serial for/each loop anyway. So, are we sure we're solving the right problem here? I.e. is there a use case where, by reducing contention, we get back performances that would be considered acceptable for a performance-savy user? Or is this something that just make something 100x worse as opposed to 1000x worse? Data is reported below:

w/o patch
ParallelSum.find_any_stream_parallel    avgt   10  1332.687 ± 733.535  ms/op
ParallelSum.find_any_stream_serial      avgt   10   440.260 ±   3.110  ms/op
ParallelSum.find_first_loop_serial      avgt   10     5.809 ±   0.044  ms/op 

w/ patch
ParallelSum.find_any_stream_parallel    avgt   10   80.280 ± 13.183  ms/op
ParallelSum.find_any_stream_serial      avgt   10  317.388 ±  2.787  ms/op
ParallelSum.find_first_loop_serial      avgt   10    5.790 ±  0.038  ms/op 

(full email here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/066136.html)

Few questions come up naturally here - do these number reflect some intrinsic problem with the memory segment spliterator per se, or do they reflect some more general problem with using shortcircuiting operations (such as find any) which consume almost zero CPU time in a stream (and, worse, a parallel stream) ?

With this I'm not of course saying that the patch (and associated improvement) is not important, but I'm wondering whether the added benefit would be worth the added maintenance cost given that, from the numbers above, it still doesn't look like findAny is the way to go for processing a segment efficiently anyway?

@plevart
Copy link
Contributor Author

@plevart plevart commented May 5, 2020

I agree that the main problem here is the constant acquire/close-ing of memory segment in Spliterator.tryAdvance(). It is interesting to observe a slight performance improvement even in serial stream (according to above results) while the concurrent contention in current MemoryScope is obvious in parallel stream. The above results are of course "distorted" by the fact that there are lots of small elements in the testing stream (int == 4 bytes) so performance figures are dominated by the overhead. But there may be valid compositions of .findAny() or such that use bigger elements so that the overhead plays a minor role. Still, current MemoryScope could present a problem even in such compositions where the alternative MemoryScope would be perfectly acceptable.
Anyway I was also thinking of "improving" the Spliterator API with two empty default methods that would present real improvement in such scenarios:

public interface Spliterator<T> {

    /**
     * Before a sequence of {@link #tryAdvance} calls from a thread, this method may
     * be called in the same thread to establish a context that may help in improving the
     * efficiency of subsequent {@code tryAdvance} calls. If this method is called and it returns
     * normally, then it is guaranteed that the sequence of {@code tryAdvance} calls will be
     * followed by a call to {@link #endTryAdvanceSequence} method to end such sequence.
     * The end of sequence of {@code tryAdvance} calls may be announced before all elements of
     * the Spliterator have been exhausted.
     *
     * @implNote the default implementation of this method does nothing
     * @since 15
     */
    default void beginTryAdvanceSequence() {
    }

    /**
     * If {@link #beginTryAdvanceSequence} method is called and the call returns normally before
     * a sequence of {@link #tryAdvance} calls, then this method is guaranteed to be called to end such
     * sequence and give this Spliterator a chance to clean-up what was established in
     * {@code beginTryAdvanceSequence}.
     *
     * @implNote the default implementation of this method does nothing
     * @since 15
     */
    default void endTryAdvanceSequence() {
    }

Would this be an acceptable "addtition" to Spliterator API?

@mcimadamore
Copy link
Collaborator

@mcimadamore mcimadamore commented May 5, 2020

Would this be an acceptable "addtition" to Spliterator API?

I'll leave this to Paul. IMHO doing this for an incubating API seems a bit too much (although I can buy that there can be other benefits in doing this). Another option would be in having this be a JDK-internal spliterator API, so that our own spliterators could implement that and get better stream performances (after all, I don't expect a lot of users to come up with their own spliterators). If stream sees that one of those 'special' stream is being used, it can use the more efficient implementation.

@plevart
Copy link
Contributor Author

@plevart plevart commented May 5, 2020

This would be universally useful. I once already missed such methods in a Spliterator I was trying to design, backed by database.

…n the segment backing memory which is not guaranteed by JMM otherwise
Copy link
Collaborator

@mcimadamore mcimadamore left a comment

The code looks good - leaning towards approving and see how it goes.

One thing I noted is that there are many assumptions that some methods can only be called from owner thread - but while that's true for the 'safe' API, that's not the case for the unsafe API; in that case I have a vague feeling that the old atomic would behave a bit more predictably.

//reference to keep hold onto
final Object ref;
/**
* Creates a root MemoryScope with given ref and cleanupAction.

This comment has been minimized.

@mcimadamore

mcimadamore May 6, 2020
Collaborator

While this is true, note that it is possible to unsafely create unconfined segments, in which case the ownership restriction would not apply. Perhaps the doc should be tweaked a bit to reflect this.

final static MemoryScope GLOBAL = new MemoryScope(null, null);
/**
* Closes this scope, executing any cleanup action if this is the root scope.
* This method may only be called in "owner" thread.

This comment has been minimized.

@mcimadamore

mcimadamore May 6, 2020
Collaborator

Again - for unsafe segments this is not true. Not that we need to provide guarantees in that case - but I think it's better to make things clear.

@openjdk
Copy link

@openjdk openjdk bot commented May 6, 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:

Alternative scalable MemoryScope

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 /solves command.

Since the source branch of this PR was last updated there have been 115 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 46b7d054ec1ff9cb59f50a2bd358a998ee1a398a.

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 6, 2020
@PaulSandoz
Copy link
Member

@PaulSandoz PaulSandoz commented May 6, 2020

Thanks Peter for the explanation. I now see why two monotonically increasing counters work (with careful ordering the non-atomic sums). My sense is we should let this soak in the panama repo.

With regards to the proposed changes to Spliterator, i fear this will complicate the already complicated set of interactions that are possible, and require clients to take into account what is in effect a new characteristic. Instead i am wondering if we can add a new traversal method that can short-circuit, for example:

    // traverses until no elements or the action returns false, which ever is first
    // if action returns false and if there are elements remaining then traversing may continue
    // with further calls to this method, or tryAdvance, or forEachRemaining
    default void forEachSomeRemaining(Predicate<? super T> action) {
        boolean[] _continue = new boolean[1]; // ugly side return
        boolean continue;
        do {
            boolean continue = tryAdvance(e -> { _continue[0] = action.test(e); });
        } while (continue && _continue[0]);
    }

@mcimadamore
Copy link
Collaborator

@mcimadamore mcimadamore commented May 8, 2020

/sponsor

@openjdk
Copy link

@openjdk openjdk bot commented May 8, 2020

@mcimadamore The change author (@plevart) must issue an integrate command before the integration can be sponsored.

@plevart
Copy link
Contributor Author

@plevart plevart commented May 8, 2020

/integrate

@openjdk
Copy link

@openjdk openjdk bot commented May 8, 2020

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

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

@mcimadamore mcimadamore commented May 8, 2020

/sponsor

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

@openjdk openjdk bot commented May 8, 2020

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

  • 46b7d05: Automatic merge of master into foreign-memaccess
  • b09f806: Automatic merge of jdk:master into master
  • 3f50575: 8237834: com/sun/jndi/ldap/LdapDnsProviderTest.java failing with LDAP response read timeout
  • 3beee2c: 8242919: Paste locks up jshell
  • 13d6b49: 8244625: Zero VM is broken after JDK-8244550 (java_lang_Class::as_Klass(oopDesc*) undefined)
  • 601891a: 8244618: WinUpgradeUUIDTest.java fails after JDK-8236518
  • 88722a8: 8244243: Shenandoah: Cleanup Shenandoah phase timing tracking and JFR event supporting
  • 61864c2: 8062947: Fix exception message to correctly represent LDAP connection failure
  • e05227a: 8244248: boot-jdk.m4 captures the version line using regex
  • ed4bc1b: 8244245: localizedBy() should override localized values with default values
  • 29f015c: 8236518: There is no Native Packages WinUpgradeUUIDTest-2.0.exe after creating Native packages on win
  • 1a16a4b: 8244592: Start supporting SOURCE_DATE_EPOCH
  • 74132fe: 8244615: build-performance.m4 is not always parsing /proc/cpuinfo correctly
  • 54b49db: 8244606: Non-PCH build is broken after JDK-8244550
  • f6dda95: 8243596: ModuleLayer::parents should return an unmodifiable list
  • 93b0516: 8224613: javadoc should better handle bad options
  • c2780c9: 8244550: Unsafe::allocateInstance does redundant transitions
  • 62bf2d0: 8244551: Shenandoah: Fix racy update of update_watermark
  • b231ad7: 8244510: Shenandoah: invert SHC2Support::is_in_cset condition
  • 1ac3811: 8244509: Shenandoah: refactor ShenandoahBarrierC2Support::test_* methods
  • 1c136aa: 8244595: [REDO] 8244523: Shenandoah: Remove null-handling in LRB expansion
  • 441e4cd: 8244594: [BACKOUT] 8244523: Shenandoah: Remove null-handling in LRB expansion
  • 2f9cfb1: 8244523: Shenandoah: Remove null-handling in LRB expansion
  • 76507ee: 8242060: Add revocation checking to jarsigner
  • 0ef6d1d: 8244495: Some jlink tests crash on Windows after JDK-8237750
  • 6dd8443: 8243452: JFR: Could not create chunk in repository with over 200 recordings
  • 28f6cd5: Added tag jdk-15+22 for changeset 7223c6d61034
  • b0f7ebc: 8244542: ProblemList cds/DeterministicDump.java for Windows
  • 6a9d057: 8244094: Fix Amazon copyright in various test files
  • 0cf8281: 8241086: Test runtime/NMT/HugeArenaTracking.java is failing on 32bit Windows
  • d2e6339: 6415694: Clarification in Javadoc for java.rmi.AlreadyBoundException
  • b24c0d2: 8244267: Improve serviceability task definitions in CI
  • a2c35a6: 8244205: HTTP/2 tunnel connections through proxy may be reused regardless of which proxy is selected
  • 91ed3fc: 8236177: assert(status == 0) failed: error ETIMEDOUT(60), cond_wait
  • 1f31afd: 8237777: "Dumping core ..." is shown despite claiming that "# No core dump will be written."
  • 09287ab: 8244459: Optimize the hash map size in LocaleProviderAdapters
  • ed24927: 8240666: Websocket client’s OpeningHandshake discards the HTTP response body
  • 9f86d94: 8244491: make runtime/cds/appcds/TestZGCWithCDS.java test more robust
  • 5e83cb6: 8241602: jlink does not produce reproducible jimage files
  • 72704aa: 8244413: Avoid rebinds in MethodHandle.viewAsType
  • 463e377: 8244196: adjust output in os_linux
  • ca371c9: 8244463: JFR: Clean up jdk.jfr.internal.RepositoryChunk
  • a3443d0: 8243656: Shell built-in test in configure depends on help
  • 5b06609: 8243325: Cleanup TaskQueueSuper<>::peek
  • 611fda6: 8244497: [TESTBUG] Incompatible types conversion error in vmTestbase/vm/runtime/defmeth/StressTest.java after JDK-8243432
  • 98d4101: 8244307: Improve assertions against taskqueue underflow
  • 7ae3bea: 8243961: ForceNUMA and only one available NUMA node fails assertion on Windows
  • 317bd88: 8244489: Zero and minimal VM build failure after JDK-8241071 (MetaspaceShared::symbol_space_alloc is undefined)
  • 0c0d485: 8237750: Load libzip.so only if necessary
  • bc8065f: 8244485: runtime/cds/appcds/TestZGCWithCDS.java fails after 8244385
  • eadcb08: 8241071: Generation of classes.jsa with -Xshare:dump is not deterministic
  • 957eb27: 8243388: Moving search result selection clears search input
  • 98cbf46: 8242532: convert tests to use Text Blocks
  • 5868c76: 8233166: jpackage tool skips empty directories
  • 2254cf5: 8244247: Build failures after sjavac cleanup
  • 2883bcc: 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD
  • 469c13a: 8243488: Add tests for set/get SendBufferSize and getReceiveBufferSize in DatagramSocket
  • cd9b2bb: 8244444: [TESTBUG] Test for XPathEvaluationResult.XPathResultType
  • 2163dec: 8243432: use reproducible random in :vmTestbase_vm_defmeth
  • 0b7a476: 8243431: use reproducible random in :vmTestbase_vm_metaspace
  • 80d2802: 8183266: [TESTBUG]Add test to cover XPathEvaluationResult.XPathResultType.getQNameType method
  • a899004: 8244384: @requires-related clean up in gc/metaspace/ tests
  • c976be6: 8244385: various clean-ups in runtime tests
  • 5ac7556: 8244420: Shenandoah: Ensure _disarmed_value offset < 128
  • 704749a: 8244293: Remove outdated @APinote in java.util.Objects
  • 1a07550: 8244214: Change to VS2019 for building on Windows at Oracle
  • 00e15ff: 8244326: Shenandoah: global statistics should not accept bogus samples
  • 81597d9: 8244078: ProcessTools executeTestJvm and createJavaProcessBuilder have inconsistent handling of test.*.opts
  • a8edd11: 8242335: Additional Tests for RSASSA-PSS
  • 600319b: 8244149: jdk/jfr/api/consumer/recordingstream/TestOnEvent.java times out
  • df182ea: 8244133: Refactor nsk/jdi tests to reduce code duplication in settingBreakpoint communication
  • 342edb4: 8244018: No error message for non-existent icon path
  • 14ae7cf: 8242865: Usability problems using mac signing in jpackage
  • 0efacb3: 8244292: Headful clients failing with --illegal-access=deny
  • 90e8a0a: 8243453: java --describe-module failed with non-ASCII module name under non-UTF8 environment
  • e70d76d: 8244200: Shenandoah: build breakages after JDK-8241743
  • 31041d4: 8241100: Make Boolean, Character, Byte, and Short implement Constable
  • 2d8bea8: 8244328: Shenandoah: move ShenandoahThreadLocalData::_disarmed_value initialization
  • cbfcae7: 8233439: G1 zero_filled optimization when committing CardCountsTable does not work
  • c7b1b1b: 8244284: Two tests in test/hotspot/jtreg/vmTestbase fail with --illegal-access=deny
  • e5099da: 8244283: test/jdk/sun/net/idn/TestStringPrep.java fails with --illegal-access=deny
  • 352e460: 8244281: test/jdk/com/sun/crypto/provider/KeyProtector/IterationCount.java fails with --illegal-access=deny
  • 4e55421: 8243548: Javac incorrectly collects enum fields when verifying switch expression exhaustivness
  • 1a35219: 8243557: Inconvenient span for multi-catch error diagnostics
  • 09912cc: 8244182: Use root node as default for find_node when called from debugger
  • bbcb3b6: 8230402: Allocation of compile task fails with assert: "Leaking compilation tasks?"
  • 57fbf93: 8230940: Obsolete MonitorBound
  • 765a5b8: 8244276: Zero and minimal VM build failure after JDK-8178349 (use of undeclared identifier 'SystemDictionaryShared')
  • eee3249: 8244220: Compiler error in jpackage with VS2019
  • f0f7070: 8244186: assertion failure test/jdk/javax/net/ssl/DTLS/RespondToRetransmit.java
  • bcf3ae8: 8244142: some hotspot/runtime tests don't check exit code of forked JVM
  • 47c30db: 8244141: use @requires and SkippedException in some hotspot/runtime tests
  • 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 e1ae7db.

@plevart plevart deleted the plevart:foreign-memaccess branch May 9, 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.