> 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

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8350/files
  - new: https://git.openjdk.java.net/jdk/pull/8350/files/8445f328..936877c6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8350&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8350&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8350.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8350/head:pull/8350

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

Reply via email to