JAL-3477: Default memory selection should have a maximum value

Activity

CR-JAL-189 17

Keyboard shortcuts  
  • Summarize the review outcomes (optional)
     
    #permalink

    Details

    Warning: no files are visible, they have all been filtered.
    Participant Role Time Spent Comments Latest Comment
    Author 1h 16m 2 Changing "... 8GB ..." to "... " + (noMemMaxHeapSizeDefau...
    Reviewer - 79% reviewed 25m 15 A public class with no public members doesn't quite make ...
    Total   1h 40m 17  
    #permalink

    Objectives

    Jalview's new dynamic memory allocation defaults to 90% of physical memory, trying to obtain at least 0.5GB for Jalview, but also leaveing at least 0.5GB for the OS.

    In some environments (e.g. HPC) 90% of physical memory is inappropriately large.
    We should set a (default) limit of e.g. 32GB (maybe lower?).

    This could be done in jalview.bin.MemorySetting.java, but should be copied over to the getdown src and jar too.

    Branches in review

    #permalink

    Issues Raised From Comments

    Key Summary State Assignee
    #permalink

    General Comments

    Mungo Carstairs

    Should the getdown code be in a jar file? And include MemorySettings? cf comm...

    Should the getdown code be in a jar file? And include MemorySettings?
    cf comment https://issues.jalview.org/browse/?focusedCommentId=21949&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#JAL-3278comment-21949

    Not having getdown/data/Application on the project classpath confused me a bit (calls from Application to MemorySettings don't show up).

    Ben Soares

    I agree the getdown (adapted) source that we use is not in the right place. C...

    I agree the getdown (adapted) source that we use is not in the right place. Currently all getdown resources and built components get put under ./getdown/ to keep it a separate entity from Jalview. I've created an issue detailing where the different getdown folders should be moved to (including putting ./getdown/src under ./src), but the build process for getdown is still necessarily separate from the Jalview build process. See issue JAL-3500.

    /getdown/lib/getdown-core.jar Changed
    Open in IDE #permalink
    /getdown/lib/getdown-launcher-local.jar Changed
    Open in IDE #permalink
    /getdown/lib/getdown-launcher.jar Changed
    Open in IDE #permalink
    /getdown/src/getdown/ant/pom.xml Changed
    /getdown/src/.../getdown/data/Application.java Changed
    /getdown/src/.../getdown/util/Config.java Changed
    Open in IDE #permalink
    /getdown/src/.../bin/MemoryPercent.java Changed 2
    /getdown/src/.../bin/MemorySetting.java Changed 10
    /getdown/src/getdown/core/pom.xml Changed
    /getdown/src/getdown/launcher/pom.xml Changed
    /getdown/src/getdown/mvn_cmd Changed
    /getdown/src/getdown/pom.xml Changed
    /j11lib/getdown-core.jar Changed
    Open in IDE #permalink
    /j8lib/getdown-core.jar Changed
    Open in IDE #permalink
    /src/jalview/bin/Launcher.java Changed 3
    /src/jalview/bin/MemoryPercent.java Added
    /src/jalview/bin/MemorySetting.java Changed
    /test/jalview/bin/MemorySettingTest.java Added
    Open in IDE #permalink
    /utils/testnglibs/classgraph-4.1.6.jar Added
    Open in IDE #permalink
    /utils/classgraph-4.1.6.jar Deleted
    Open in IDE #permalink
    /gradle.properties Changed

    Review updated: Reload | Ignore | Collapse

    You cannot reload the review while writing a comment.

    Log time against