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

Use correct variable for nodeAfter in MemoryFlowChunk constructor #89

Merged
merged 2 commits into from
Apr 12, 2019

Conversation

dwnusbaum
Copy link
Member

Noticed while working on adding some new tests in pipeline-graph-analysis. Thankfully, it doesn't look like there are any callers currently using this overload of the constructor (here is a GitHub search for MemoryFlowChunk in the jenkinsci org).

@dwnusbaum dwnusbaum requested review from abayer and jglick April 11, 2019 19:51
Copy link
Member

@jglick jglick left a comment

Choose a reason for hiding this comment

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

Seems right by visual inspection, but I find it disturbing that there is no test coverage for this constructor.

@dwnusbaum
Copy link
Member Author

I find it disturbing that there is no test coverage for this constructor

From what I can tell, this is because the normal usage idiom is to maintain a single MemoryFlowChunk at the field level in graph analysis-related classes, and update its values over time rather than constructing new instances (presumably to reduce GC pressure?). See the note here for example. Other scanning-related methods and visitors use FlowNode directly and so don't run into the problem.

I will go ahead and add a basic unit test for the constructor.

assertThat(chunk.getNodeBefore(), equalTo(start));
assertThat(chunk.getFirstNode(), equalTo(blockStart));
assertThat(chunk.getLastNode(), equalTo(blockEnd));
assertThat(chunk.getNodeAfter(), equalTo(end));
Copy link
Member Author

Choose a reason for hiding this comment

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

Test fails here if the change in src/main is reverted.

@dwnusbaum dwnusbaum merged commit c309efc into jenkinsci:master Apr 12, 2019
@dwnusbaum dwnusbaum deleted the fix-constructor branch April 12, 2019 17:30
jglick added a commit to jglick/workflow-api-plugin that referenced this pull request May 26, 2022
…r882853693

Example from `ExecutorStepDynamicContextTest.parallelNodeDisappearance`:

```
"Computer.threadPoolForRemoting [#3]" jenkinsci#89 daemon prio=5 os_prio=0 tid=0x00007f30d0c6a800 nid=0x6d0f9 in Object.wait() [0x00007f31047fe000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:460)
	at hudson.remoting.AsyncFutureImpl.get(AsyncFutureImpl.java:97)
	- locked <0x00000000f83dd1e8> (a hudson.remoting.AsyncFutureImpl)
	at org.jenkinsci.plugins.workflow.support.steps.ExecutorStepDynamicContext.resume(ExecutorStepDynamicContext.java:108)
	at org.jenkinsci.plugins.workflow.support.steps.ExecutorStepExecution.onResume(ExecutorStepExecution.java:201)
	at org.jenkinsci.plugins.workflow.flow.FlowExecutionList$ParallelResumer.lambda$run$5(FlowExecutionList.java:369)
	at org.jenkinsci.plugins.workflow.flow.FlowExecutionList$ParallelResumer$$Lambda$350/265274739.run(Unknown Source)
	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
	at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68)
	at …
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants