You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Michael Osipov (JIRA)" <ji...@apache.org> on 2019/06/08 09:15:00 UTC

[jira] [Updated] (MNG-6668) Model location handling uses too much memory

     [ https://issues.apache.org/jira/browse/MNG-6668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Osipov updated MNG-6668:
--------------------------------
    Fix Version/s: 3.6.2

> Model location handling uses too much memory
> --------------------------------------------
>
>                 Key: MNG-6668
>                 URL: https://issues.apache.org/jira/browse/MNG-6668
>             Project: Maven
>          Issue Type: Bug
>          Components: core
>            Reporter: Stefan Oehme
>            Priority: Major
>             Fix For: 3.6.2
>
>
> Every model element in Maven has one or several Location objects associated with it. These locations specify where in the POM each attribute of that object was configured. This is a very useful feature for better error messages and IDE assistance, but its current implementation takes too much memory.
> Locations are currently tracked with a LinkedHashMap, with String keys and Location values. LinkedHashMap has a large overhead per entry. In a particularly large build that I was investigating, just this overhead summed up to almost 3GB of memory. However, there is actually no need for arbitrary Strings or a Map. The keys are always the name of the corresponding field in the model class. So instead we could create one Location field for every actual data field in the model and then switch over the String key to assign the Location to the correct field. This would get rid of the LinkedHashMap overhead altogether. It would add a small overhead for modello users who don't care about location handling, but I assume that Maven is the only major consumer of it.
>  
> See [https://github.com/codehaus-plexus/modello/pull/31] and [https://github.com/apache/maven/pull/252]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)