|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Code changed in jenkins
User: Stephen Connolly
Path:
core/src/main/java/hudson/model/Queue.java
http://jenkins-ci.org/commit/jenkins/5880ed830201f9349ae9def6653c19a186e1eb18
Log:
[FIXED JENKINS-27708][FIXED JENKINS-27871] Ensure that identification of blocked tasks is using the live state.
job execution. You probably would need 100's of jobs starting execution every iteration
of maintain() before this could even start to become an issue and likely the calculation
of isBuildBlocked(p) will become a bottleneck before updateSnapshot() will. Additionally
since the snapshot itself only ever has at most one reference originating outside of the stack
it should remain in the eden space and thus be cheap to GC.
this issue. I am favouring this approach as it is simpler and provides less scope for error as any
new helper methods can just rely on the snapshot being up to date whereas with the other
two candidates if a new helper method is introduced there is the potential to miss adding support
for the live view. The comment 225819 has the risk of introducing extra lock contention while
the comment 225906 version forces every access to the helper methods to pass a second memory
barrier