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

Fixes #16513: JVM GC cannot clean objects in scope in a for { } yield {} even if they are not referenced anymore #2709

Conversation

ncharles
Copy link
Member

Copy link
Member

@fanf fanf left a comment

Choose a reason for hiding this comment

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

Appart for the comment on clarity of for loops scoping, that PR does nothing fancy and the goal is clear, so if a "ok" for me, appart if you find a better way to display it.

_ = PolicyLogger.debug(s"Node configuration written in ${timeWriteNodeConfig} ms, start to update expected reports.")
(updatedNodesId, updatedNodeInfo, expectedReports, allErrors, errorNodes, timeFetchAll, timeHistorize, timeRuleVal, timeBuildConfig, timeWriteNodeConfig, timeSetExpectedReport) <- for {
(updatedNodeConfigIds, allNodeConfigurations, allNodeConfigsInfos, updatedNodesId, updatedNodeInfo, allLicenses, globalPolicyMode, allNodeModes, allErrors, errorNodes, timeFetchAll, timeHistorize, timeRuleVal, timeBuildConfig) <- for {
(activeNodeIds, ruleVals, nodeContexts, allNodeModes, scriptEngineEnabled, globalPolicyMode, nodeConfigCaches, allLicenses, timeFetchAll, timeHistorize, timeRuleVal) <- for {
Copy link
Member

Choose a reason for hiding this comment

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

The scoping is quickly becoming hard to follow I believe. Wouldn't it be clearer to factor out the inner-most for in dedicated support function ? (I'm not sure, because we already have tons of them, and we will likely loose the general understanding of the policy generation workflow). What's your opinion on that?

Copy link
Member

Choose a reason for hiding this comment

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

Or perhaps build dedicated case objects that only handle the relevant part and are passed around ?
(well, I fear that it will make refactoring harder, since we will have a hard time to know when we can remove an object from such a structure, so perhaps a bad idea actually)

Copy link
Member Author

Choose a reason for hiding this comment

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

we already have a lot of back and forth with def, making it hard to follow. Plus, there are timestamp for loging within this, so adding them in a def is nightmarish

Copy link
Member Author

Choose a reason for hiding this comment

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

I wish there were a way to make it better (an annotation that the compiler could use to know to release quickly some variable)

@Normation-Quality-Assistant
Copy link
Contributor

This PR is not mergeable to upper versions.
Since it is "Ready for merge" you must merge it by yourself using the following command:
rudder-dev merge https://github.com/Normation/rudder/pull/2709
-- Your faithful QA
Kant merge: "Science is organized knowledge. Wisdom is organized life."
(https://ci.normation.com/jenkins/job/merge-accepted-pr/19222/console)

@fanf
Copy link
Member

fanf commented Jan 13, 2020

OK, merging this PR

@fanf fanf merged commit d441f48 into Normation:branches/rudder/5.0 Jan 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants