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

8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException #1595

Closed
wants to merge 3 commits into from

Conversation

pliden
Copy link
Contributor

@pliden pliden commented Dec 3, 2020

This PR replaces the withdrawn PR #1348. This PR tries to fix the underlying problem, rather than fix the tests.

The problem is that a number of JDI tests create objects on the debugger side with calls to newInstance(). However, on the debugee side, these new instances will only be held on to by a JNIGlobalWeakRef, which means they could be collected at any time, even before newInstace() returns. A number of JDI tests get spurious ObjectCollectedException thrown at them, which results in test failures. To make these objects stick around, a call to disableCollection() is typically needed.

However, as pointer out by @plummercj in JDK-8255987:

Going back to the spec, ObjectReference.disableCollection() says:

"By default all ObjectReference values returned by JDI may be collected at any time the target VM is running"

and

"Note that while the target VM is suspended, no garbage collection will occur because all threads are suspended."

But no where does is say what is meant by the VM running or being suspended, or how to get it in that state. One might assume that this ties in with VirtualMachine.suspend(), but it says:

"Suspends the execution of the application running in this virtual machine. All threads currently running will be suspended."

No mention of suspending the VM, but that certainly seems to be what is implied by the method name and also by the loose wording in disableCollection().

Most of our spuriously failing tests do actually make a call to VirtualMachine.suspend(), presumably to prevent objects from being garbage collected. However, the current implementation of VirtualMachine.suspend() will only suspend all Java threads. That is not enough to prevent objects from being garbage collected. The GC can basically run at any time, and there is no relation to whether all Java threads are suspended or not.

However, as suggested by @plummercj, we could emulate the behaviour implied by the spec by letting a call to VirtualMachine.suspend() also convert all existing JDI objects references to be backed by a (strong) JNIGlobalRef rather than a (weak) JNIGlobalWeakRef. That will not prevent the GC from running, but it will prevent any object visible to a JDI client from being garbage collected. Of course, a call to VirtualMachine.resume() would convert all references back to being weak again.

This patch introduces the needed functions in libjdwp to "pin" and "unpin" all objects. These new functions are then used by the underpinnings of VirtualMachine.suspend() and VirtualMachine.resume() to implement the behaviour described above.

Note that there are still a few tests that needed adjustments to guard against ObjectCollectionException. These are:

  • vmTestbase/nsk/jdi/ArrayType/newInstance/newinstance004.java - This test seems to have been forgotten by JDK-8203174, which did a similar fix in the other ArrayType/newinstance tests.
  • vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001.java - We just want to allocate as much as we can, so catching an ignoring ObjectCollectedException seems reasonable here.
  • vmTestbase/nsk/share/jdi/sde/SDEDebuggee.java - We still want to prevent TestClassLoader from being unloaded to avoid invalidating code locations.
  • vmTestbase/nsk/jdi/ReferenceType/instances/instances002/instances002.java - This test keeps the VM suspended, and then expects objects to be garbage collected, which they now won't.

Testing:

  • More than 50 iterations of the vmTestbase/nsk/jdi and vmTestbase/nsk/jdwp test suites, using various GC, both in mach5 and locally.

Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException

Reviewers

Download

$ git fetch https://git.openjdk.java.net/jdk pull/1595/head:pull/1595
$ git checkout pull/1595

@bridgekeeper
Copy link

bridgekeeper bot commented Dec 3, 2020

👋 Welcome back pliden! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented Dec 3, 2020

@pliden The following label will be automatically applied to this pull request:

  • serviceability

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added the serviceability serviceability-dev@openjdk.org label Dec 3, 2020
@pliden
Copy link
Contributor Author

pliden commented Dec 3, 2020

/cc hotspot-gc

@openjdk openjdk bot added the hotspot-gc hotspot-gc-dev@openjdk.org label Dec 3, 2020
@openjdk
Copy link

openjdk bot commented Dec 3, 2020

@pliden
The hotspot-gc label was successfully added.

@pliden pliden marked this pull request as ready for review December 3, 2020 13:15
@openjdk openjdk bot added the rfr Pull request is ready for review label Dec 3, 2020
@mlbridge
Copy link

mlbridge bot commented Dec 3, 2020

Webrevs

Comment on lines +192 to +194
debuggee.resume();
checkDebugeeAnswer_instances(className, baseInstances);
debuggee.suspend();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before the changes in this PR, what was triggering the (expected) collection of the objects?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes aren't making sense to me - but then this test is not making much sense to me either. The testArrayType logic is quite different to testClassType and now seems invalid. It suspends the VM, then calls disableCollection on all the object refs of interest, then later calls enableCollection and then resumes the VM. The calls to disableCollection/enableCollection seem pointless if GC is disabled while the VM is suspended. I suspect this was added because VM suspension was not in fact stopping the GC.
The testClassType test is doing what? I can't tell what it expects to be checking with checkDebugeeAnswer_instances, but there's no VM suspension (presently) and no disableCollection calls. ???

Copy link
Contributor Author

@pliden pliden Dec 7, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@plummercj Nothing was explicitly triggering collection of these objects. However, the test is explicitly checking the number of objects "reachable for the purposes of garbage collection" in checkDebugeeAnswer_instances(). The tests sets up a breakpoint (with SUSPEND_ALL), which suspends the VM. Then it creates a number of new instances and expects these to be weakly reachable. However, with this change, suspending the VM will make all objects "reachable for the purposes of garbage collection". So, to let the test continue to work as intended we need to first resume the VM, count the instances, and then suspend it again.

@dholmes-ora I have no idea why these tests are so different. The VM suspend is implicit in the breakpoint in this test, which is set up using SUSPEND_ALL.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I understand now. ReferenceType.instances() only counts objects "reachable for the purposes of garbage collection". This change in behavior does concern me a little bit. I think the expectation is that the instances created by ClassType.newInstance() will not show up in this count unless disableCollection() is called, even when under a "suspend all". Clearly that's the expectation of this test, so the question is whether or not it is a reasonable expectation.

Note that ClassType.newInstance() says nothing about the state of the returned object w.r.t. GC. It makes no mention of the need to call disableCollection() before resuming the VM, so I guess this gives us some wiggle room. However, the argument against the object being strongly reachable is comes from user asking the question "who has the strong reference that makes it strongly reachable?". It's not obvious to the user why there is a strong reference, and why it seemingly goes a way once VM.resumeAll() is called.

I still think overall this is the right approach (baring a better approach being presented), but we may need to include some spec clarifications, and be prepared for some push back if this breaks anything.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't follow your reasoning here Chris. All ObjectReferences can be GC'd at any time unless GC has been disallowed. So a reference create via newInstance is no different to any other reference. If it is currently reachable then instances() should return it. Are you treating "reachable for the purposes of garbage collection" as-if it said "strongly reachable"? It doesn't so I think you are reading too much into this. I think there is a lot of flexibility in this API in terms of what it may return regarding weak references.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I read "reachable for the purposes of garbage collection" as not including objects reachable only via weak reference. So if the only reference to an object is a weak reference, which is normally what you have after calling ClassType.newInstance(), then the object is not considered reachable. At the very least, his is how ReferenceType.instances() is implemented, and is based on JVMTI FollowReferences().

So given that, the expectation would be that an object returned ClassType.newInstance() would not be counted by ReferenceType.instances() unless something is done to add a strong reference to the object, such as calling ObjectReference.disableCollection(). Now with Per's changes a strong reference is also created with doing a VM.suspend(). The test doesn't expect this behavior, and it's understandable why.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we're still within what the spec says, given that the wording is so loose. But it's hard to tell if this change will be problematic for some use case.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm ok with making the change and then seeing if there is any fallout from it. My guess is there won't be. I do think there is a need to cleanup the JDI and JDWP specs in a few areas w.r.t. object liveness. Another CR can be filed for that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I filed https://bugs.openjdk.java.net/browse/JDK-8257921. Feel free to extend/improve the description.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I'll add some suggestions to the CR based on some of our recent discussions.

try {
array.disableCollection();
} catch (ObjectCollectedException e) {
continue;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add a comment: "Since the VM is not suspended, the object may have been collected before disableCollection() could be called on it. Just ignore and continue doing allocations until we run out of memory."

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, will fix.

Comment on lines +630 to +632
if (weakRef == NULL) {
EXIT_ERROR(AGENT_ERROR_NULL_POINTER,"NewWeakGlobalRef");
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not so sure I agree that having a fatal error here is the right thing to do. The only other user of weakenNode() is ObjectReference.disableCollection(). It returns an error to the debugger if weakenNode() returns NULL. However, I'm not so sure that's a good thing to do here either, since it means the VM.resume() will need to fail. Possibly the error should just be ignored, and we live with the ref staying strong.

Copy link
Contributor

@plummercj plummercj Dec 4, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another options is to save away the weakref in the node when strengthening. This would benefit ObjectReference.disableCollection() also, since it would no longer need to deal with a potential OOM. However, I'm not so sure it's actually worth doing. Trying to keep the debug session alive will having allocation errors is probably a fools errand.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree a fatal error here seems excessive. Simply maintaining the strong ref seems reasonable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was trying to mimic what we already do in strengthenNode(), i.e. it's a fatal error if we can't create a JNI ref. Here:

        strongRef = JNI_FUNC_PTR(env,NewGlobalRef)(env, node->ref);
        /*
         * NewGlobalRef on a weak ref will return NULL if the weak
         * reference has been collected or if out of memory.
         * It never throws OOM.
         * We need to distinguish those two occurrences.
         */
        if ((strongRef == NULL) && !isSameObject(env, node->ref, NULL)) {
            EXIT_ERROR(AGENT_ERROR_NULL_POINTER,"NewGlobalRef");
        }

So it seems appropriate to do the same thing if we fail to create a JNI weak ref. Also, as @plummercj mentioned, if we can't create a JNI ref, continuing the debug session seems rather pointless as we're about to go down anyway (the next allocation in the JVM will be fatal).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay.

@mlbridge
Copy link

mlbridge bot commented Dec 7, 2020

Mailing list message from David Holmes on hotspot-gc-dev:

Hi Per,

On 3/12/2020 11:19 pm, Per Liden wrote:

This PR replaces the withdraw PR #1348. This PR tries to fix the underlying problem, rather than fix the tests.

The problem is that a number of JDI tests create objects on the debugger side with calls to `newInstance()`. However, on the debugee side, these new instances will only be held on to by a `JNIGlobalWeakRef`, which means they could be collected at any time, even before `newInstace()` returns. A number of JDI tests get spurious `ObjectCollectedException` thrown at them, which results in test failures. To make these objects stick around, a call to `disableCollection()` is typically needed.

However, as pointer out by @plummercj in [JDK-8255987](https://bugs.openjdk.java.net/browse/JDK-8255987):

Going back to the spec, ObjectReference.disableCollection() says:

"By default all ObjectReference values returned by JDI may be collected at any time the target VM is running"

and

"Note that while the target VM is suspended, no garbage collection will occur because all threads are suspended."

But no where does is say what is meant by the VM running or being suspended, or how to get it in that state. One might assume that this ties in with VirtualMachine.suspend(), but it says:

"Suspends the execution of the application running in this virtual machine. All threads currently running will be suspended."

No mention of suspending the VM, but that certainly seems to be what is implied by the method name and also by the loose wording in disableCollection().

I think we can quite reasonably infer that "suspending a VM" means
calling VirtualMachine.suspend to suspend all the threads of the target VM.

Most of our spuriously failing tests do actually make a call to `VirtualMachine.suspend()`, presumably to prevent objects from being garbage collected. However, the current implementation of `VirtualMachine.suspend()` will only suspend all Java threads. That is not enough to prevent objects from being garbage collected. The GC can basically run at any time, and there is no relation to whether all Java threads are suspended or not.

You can imagine though that 25 years ago it was not an unreasonable
assumption that GC only runs in response to (failed) allocation requests
from running application threads - i.e. that it is a synchronous
response to application code execution. Hence all threads suspended
implies no allocation and thus no GC. (Someone can correct me if I'm
wrong but way way back didn't running in JDI debug mode force use of
SerialGC?)

I'm somewhat surprised that it has taken this long to discover that our
GC's are no longer operating in a way that JDI requires them to.

However, as suggested by @plummercj, we could emulate the behaviour implied by the spec by letting a call to `VirtualMachine.suspend()` also convert all existing JDI objects references to be backed by a (strong) `JNIGlobalRef` rather than a (weak) `JNIGlobalWeakRef`. That will not prevent the GC from running, but it will prevent any object visible to a JDI client from being garbage collected. Of course, a call to `VirtualMachine.resume()` would convert all references back to being weak again.

I assume that the GC folk would be horrified if I were to suggest a
global flag to enable/disable GC? ;-)

Doing what is suggested sounds reasonable, from a functional
perspective, to get the desired effect of not collecting any objects of
interest. But I do have to wonder how many objects we are typically
dealing with and what the performance impact of this might be if we have
to iterate through each all the objects?

Thanks,
David
-----

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall seems okay. Some comments on tests as I think the existing test logic is quite confused in places.

Thanks,
David

Comment on lines +584 to +586
jobject strongRef;

strongRef = strengthenNode(env, node);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can just be one line.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was actually trying to carefully to follow the coding style currently used in this file/library. If you have a quick look at this file you'll see the pattern above in multiple places, where as combined declaration+assignment style isn't used. So while I personally agree about this style question, I also think following the style already present in a file has precedence over introducing a new style. Don't you agree?

Comment on lines +627 to +629
jweak weakRef;

weakRef = weakenNode(env, node);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again this can be a single line.

Comment on lines +630 to +632
if (weakRef == NULL) {
EXIT_ERROR(AGENT_ERROR_NULL_POINTER,"NewWeakGlobalRef");
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree a fatal error here seems excessive. Simply maintaining the strong ref seems reasonable.

* Pin all objects to prevent objects from being
* garbage collected while the VM is suspended.
*/
commonRef_pinAll();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we have multiple VM.suspend calls? The suspendAllCount seems to suggest that. In which case shouldn't we only pin on the 0->1 transition, and only unpin on the 1->0 transition?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was something I pointed out in the pre-review, and it has been addressed in commonRef_pinAll/unpinAll:

568 if (gdata->pinAllCount == 1) {
618 if (gdata->pinAllCount == 0) {

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay. I would not have handled it at that level, but would have had
pinAll/unpinAll operate unconditionally, but the calls to those methods
being conditional based on the suspendAllCount.

David

Well, that's assuming pinAll() will only ever be used by by suspendAll(). One could imaging a future use, such as if VirtualMachine.disableCollection() were ever to be added.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was also thinking pinAll()/unpinAll() should stand on their own, and not implicitly depend/rely on suspendAllCount. As @plummercj says, one could imagine we want to use these functions in other contexts in the future.

Comment on lines +192 to +194
debuggee.resume();
checkDebugeeAnswer_instances(className, baseInstances);
debuggee.suspend();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes aren't making sense to me - but then this test is not making much sense to me either. The testArrayType logic is quite different to testClassType and now seems invalid. It suspends the VM, then calls disableCollection on all the object refs of interest, then later calls enableCollection and then resumes the VM. The calls to disableCollection/enableCollection seem pointless if GC is disabled while the VM is suspended. I suspect this was added because VM suspension was not in fact stopping the GC.
The testClassType test is doing what? I can't tell what it expects to be checking with checkDebugeeAnswer_instances, but there's no VM suspension (presently) and no disableCollection calls. ???

@mlbridge
Copy link

mlbridge bot commented Dec 7, 2020

Mailing list message from David Holmes on hotspot-gc-dev:

On 7/12/2020 4:30 pm, Chris Plummer wrote:

On Mon, 7 Dec 2020 05:18:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

1558: * garbage collected while the VM is suspended.
1559: */
1560: commonRef_pinAll();

Can we have multiple VM.suspend calls? The suspendAllCount seems to suggest that. In which case shouldn't we only pin on the 0->1 transition, and only unpin on the 1->0 transition?

That was something I pointed out in the pre-review, and it has been addressed in `commonRef_pinAll/unpinAll`:

`568 if (gdata->pinAllCount == 1) {`
`618 if (gdata->pinAllCount == 0) {`

Okay. I would not have handled it at that level, but would have had
pinAll/unpinAll operate unconditionally, but the calls to those methods
being conditional based on the suspendAllCount.

David
-----

@mlbridge
Copy link

mlbridge bot commented Dec 7, 2020

Mailing list message from David Holmes on hotspot-gc-dev:

On 7/12/2020 5:44 pm, Chris Plummer wrote:

On Mon, 7 Dec 2020 06:27:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 1560:

1558: * garbage collected while the VM is suspended.
1559: */
1560: commonRef_pinAll();

Can we have multiple VM.suspend calls? The suspendAllCount seems to suggest that. In which case shouldn't we only pin on the 0->1 transition, and only unpin on the 1->0 transition?

That was something I pointed out in the pre-review, and it has been addressed in `commonRef_pinAll/unpinAll`:

`568 if (gdata->pinAllCount == 1) {`
`618 if (gdata->pinAllCount == 0) {`

Okay. I would not have handled it at that level, but would have had
pinAll/unpinAll operate unconditionally, but the calls to those methods
being conditional based on the suspendAllCount.

David

Well, that's assuming `pinAll()` will only ever be used by by `suspendAll()`. One could imaging a future use, such as if `VirtualMachine.disableCollection()` were ever to be added.

Not really. I consider pinAll should pin-all as the name implies. The
question of when to pin should be handled by the caller of pinAll. If
there were ever to be a second reason to pinAll then you would have to
decide what semantics that has: does it maintain a count, or is it like
thread suspension.

David

@mlbridge
Copy link

mlbridge bot commented Dec 7, 2020

Mailing list message from David Holmes on hotspot-gc-dev:

On 7/12/2020 9:12 pm, Per Liden wrote:

On Mon, 7 Dec 2020 05:10:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

584: jobject strongRef;
585:
586: strongRef = strengthenNode(env, node);

This can just be one line.

I was actually trying to carefully to follow the coding style currently used in this file/library. If you have a quick look at this file you'll see the pattern above in multiple places, where as combined declaration+assignment style isn't used. So while I personally agree about this style question, I also think following the style already present in a file has precedence over introducing a new style. Don't you agree?

This file uses an archaic C-style, so while I agree it would be
inappropriate to over modernise the new code, this particular example
stuck out because even in archaic C there is no reason to split this
onto two lines. I didn't go looking to see if this mimicked existing
code. :) Keep it or change it as you see fit.

Cheers,
David

@pliden
Copy link
Contributor Author

pliden commented Dec 7, 2020

Not really. I consider pinAll should pin-all as the name implies. The question of when to pin should be handled by the caller of pinAll. If there were ever to be a second reason to pinAll then you would have to decide what semantics that has: does it maintain a count, or is it like thread suspension.

I would say that would not be in spirit of how the rest of this library is designed, with regards to nesting of calls. For example, pin()/unpin(), suspend()/resume(), createNode()/deleteNode(), etc. All these functions supports nesting, so they might just up/down a counter, instead of doing exactly what their name implies. The new pinAll()/unpinAll() follow the same model, which, to me, feels like the natural thing to do here.

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still have some reservations about the logic in some of the tests now (ie using disableCollection whilst the VM is suspended and reenabling also whilst suspended) but the logic was unclear in the first place. If necessary follow up cleanup issues could be filed here.

Thanks,
David

@openjdk
Copy link

openjdk bot commented Dec 7, 2020

@pliden This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8255987: JDI tests fail with com.sun.jdi.ObjectCollectedException

Reviewed-by: dholmes, cjplummer

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 102 new commits pushed to the master branch:

  • ed4c4ee: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default
  • c47ab5f: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event
  • 291ba97: 8251267: CDS tests should use CDSTestUtils.getOutputDir instead of System.getProperty("user.dir")
  • f48d5d1: 8257789: Fix incremental build of test-image and bundles
  • 1a9ed92: 8200102: NativeLibraryTest.java fails intermittently, unloaded count is not same as expected
  • 264feb3: 8257905: Make fixpath.sh more liberal in accepting paths embedded in arguments
  • 044616b: 8252049: Native memory leak in ciMethodData ctor
  • fab6158: 8236413: AbstractConnectTimeout should tolerate both NoRouteToHostException and UnresolvedAddressException
  • 936a7ac: 8252797: Non-PCH build fails on Ubuntu 16.4 when building with gtests
  • d0c5265: 8256149: Weird AST structure for incomplete member select
  • ... and 92 more: https://git.openjdk.java.net/jdk/compare/4a267f1bc2b025aae2cb9df7283156aeb0282406...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Dec 7, 2020
@plummercj
Copy link
Contributor

A number of files need copyright updates.

@pliden
Copy link
Contributor Author

pliden commented Dec 8, 2020

@plummercj Copyright fixed.

@pliden
Copy link
Contributor Author

pliden commented Dec 9, 2020

Thanks for reviewing, @plummercj and @dholmes-ora!

/integrate

@openjdk openjdk bot closed this Dec 9, 2020
@openjdk openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Dec 9, 2020
@openjdk
Copy link

openjdk bot commented Dec 9, 2020

@pliden Since your change was applied there have been 107 commits pushed to the master branch:

  • 9ce3d80: 8257887: java/foreign/TestSegments.java test fails on 32-bit after JDK-8257186
  • 10da767: 8257847: Tiered should publish MDO data pointer for interpreter after profile start
  • 2a62d5d: 8256917: Use combo @returns tag in java.compiler javadoc
  • b29f9cd: 8075778: Add javadoc tag to avoid duplication of return information in simple situations.
  • 48d8650: 8257845: Integrate JEP 390
  • ed4c4ee: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default
  • c47ab5f: 8256515: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event
  • 291ba97: 8251267: CDS tests should use CDSTestUtils.getOutputDir instead of System.getProperty("user.dir")
  • f48d5d1: 8257789: Fix incremental build of test-image and bundles
  • 1a9ed92: 8200102: NativeLibraryTest.java fails intermittently, unloaded count is not same as expected
  • ... and 97 more: https://git.openjdk.java.net/jdk/compare/4a267f1bc2b025aae2cb9df7283156aeb0282406...master

Your commit was automatically rebased without conflicts.

Pushed as commit 79f1dfb.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@pliden pliden deleted the 8255987_jdi_suspend_resume branch December 9, 2020 07:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot-gc hotspot-gc-dev@openjdk.org integrated Pull request has been integrated serviceability serviceability-dev@openjdk.org
3 participants