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

Fixup total memory parsing logic #46

Merged
merged 1 commit into from
Dec 11, 2020
Merged

Fixup total memory parsing logic #46

merged 1 commit into from
Dec 11, 2020

Conversation

ekcasey
Copy link
Member

@ekcasey ekcasey commented Dec 10, 2020

  • injects correct default memory info filepath
  • allows specified suffixes when parsing memory.limit_in_bytes
  • parses units from available memory instead of only matching kB
  • no longer support nonstandard b and B suffixes when parsing memory size
  • replace parsing error cases with warning and continue to next fallback
  • formatting

Signed-off-by: Emily Casey ecasey@vmware.com

Please confirm the following:

  • I have viewed, signed, and submitted the Contributor License Agreement.
  • I have added an integration test, if necessary.

@ekcasey ekcasey added type:bug A general bug semver:patch A change requiring a patch version bump labels Dec 10, 2020
@ekcasey ekcasey requested a review from a team December 10, 2020 15:41
@@ -167,3 +162,22 @@ func (m MemoryCalculator) Execute() (map[string]string, error) {

return map[string]string{"JAVA_TOOL_OPTIONS": strings.Join(values, " ")}, nil
}

func parseMemInfo(s string) (int64, error) {
pattern := `MemAvailable:\s*(\d+)(.*)`
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we always be sure that the amount is shown as kB?
My approach was that in case of a different unit it would be safer to not use it.

Copy link
Member Author

Choose a reason for hiding this comment

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

https://github.com/paketo-buildpacks/libjvm/pull/46/files#diff-0ab20a99dcc0be1692ffca784255e81c58b78b03b66a6bfc65f77b6e82e3e16aR178-R182178 is now parsing the units explicitly. In practice the unit appears to always be kB but the documentation potentially leaves open the option for other units so I decided to go with the more complete/paranoid version while I was making changes.

Copy link
Contributor

Choose a reason for hiding this comment

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

sorry totally missed the second match group.

if mem, err := parseMemInfo(string(b)); err != nil {
m.Logger.Infof(`WARNING: failed to parse available memory from path %q: %s`, m.MemoryInfoPath, err)
} else {
totalMemory = mem
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we log a short info "memory calculation is based on x amount of available memory"?
When reading the logs of a container it way be hard to understand why the jvm memory was calculated this way. Especially as it may be impossible to check what the available memory was at startup.

* injects correct default memory info filepath
* allows specified prefixes when parsing memory.limit_in_bytes
* parses units from available memory instead of only matching kB
* no longer support nonstandard b and B suffixes when parsing memory size
* replace parsing error cases with warning and continue to next fallback
* formatting

Signed-off-by: Emily Casey <ecasey@vmware.com>
@ekcasey ekcasey force-pushed the fixup-total-mem-parsing branch from 2e29946 to 36564f4 Compare December 10, 2020 23:16
@ekcasey ekcasey merged commit 9c630de into main Dec 11, 2020
@ekcasey ekcasey deleted the fixup-total-mem-parsing branch December 11, 2020 00:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
semver:patch A change requiring a patch version bump type:bug A general bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants