[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8285032: [LOOM] vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy008/ fails with
From:       Chris Plummer <cjplummer () openjdk ! java ! net>
Date:       2022-04-27 20:29:48
Message-ID: HI2Zgp6TXmJ6Ggp9Gu20WWBNYNEtbc5wd-_BBEJkvqk=.ba8acb7b-39a1-4493-9328-701d54ff4c35 () github ! com
[Download RAW message or body]

On Tue, 26 Apr 2022 19:25:44 GMT, Chris Plummer <cjplummer@openjdk.org> wrote:

> > The test is testing that EventSets for ThreadStartEvents have the proper \
> > suspendPolicy. When there is more than one ThreadStartRequest and a thread is \
> > started, each ThreadStartRequest results in a ThreadStartEvent being created, and \
> > they all are grouped into the same EventSet. The suspendPolicy on this EventSet \
> > should come from the ThreadStartRequest suspend policy that suspends the most \
> > threads. The test is testing for all possible combinations of the 3 suspend \
> > polices (NONE, THREAD, and ALL). For example, if NONE and ALL are used, the \
> > resulting suspend policy should be ALL. 
> > The following 3 issues are being addressed. These all turned up in loom as a \
> > result of carrier threads being created while the test was running, but \
> > potentially could happen with other threads that the jvm starts up. 
> > 1. When the test calls getEventSet() for the next ThreadStartEvent, it sometimes \
> > gets one that is for a carrier thread. In general this is not a problem because \
> > the test will accept any thread, but sometimes this carrier thread is generated \
> > between setting up two different `ThreadStartRequests`, and as a result has the \
> > wrong suspend policy, so the test fails with: 
> > nsk.share.TestFailure: ##> debugger: ERROR: eventSet.suspendPolicy() != \
> > policyExpected  
> > This is fixed by using getEventSetForThreadStartDeath(<threadName>) instead of \
> > getEventSet(), so carrier threads (and any other spuriously created thread) can \
> > be ignored. 
> > 2. The ThreadStartRequests used a filterCount of 1, which meant they would only \
> > produce one ThreadStartEvent. This meant that after fix (1) was in place, I \
> > started seeing issues with not even seeing the expected ThreadStartEvent, because \
> > the 1 count was used up by the carrier thread starting. I don't see any reason \
> > for this filterCount (other than the issue described in 3), so I just removed it. \
> >  3. After (1) and (2) were in place, I then noticed issues with sometimes getting \
> > a ThreadStartEvent when the BreakpointEvent was expected. This is because \
> > sometime a carrier thread was being created after receiving the expected \
> > ThreadStartEvent, but before the ThreadStartRequests could be disabled (this is \
> > the result of getting rid of the counterFiler). This was fixed by having \
> > breakpointForCommunication() filter out unexpected ThreadStartEvents by calling \
> > EventFilters.filtered(). I also had to add carrier threads that \
> > EventFilters.filtered() filters out.
> 
> Chris Plummer has updated the pull request incrementally with one additional commit \
> since the last revision: 
> Add comment

Thanks for the reviews Alex and Serguei!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8350


[prev in list] [next in list] [prev in thread] [next in thread]