Am 12/12/12 08:23, schrieb Milos Kleint:
> how much memory will be freed by the soft reference? if it's not a big
> chunk, most likely not worth it, soft references are released only
> when your VM is really, really in trouble. by the time it gets
> released, you've been slowed down by repeatedly hitting the ceiling of
> your memory and CGed frequently.
Driving the VM constantly at its memory limits soft references won't
help, of course.
>
> just an illustrative story, most likely not related to this usecase
> but still interesting
> while embedding maven in netbeans, we've SoftReferenced MavenProject
> at some point in time. MavenProjects can hold a big object tree,
> mostly via the cache in ProjectBuildingRequest. So once you run out of
> memory, the SRs get dropped however sometimes the MP instances are
> again immediately required, so they are loaded again. And dropped. And
> loaded.... and the IDE grinds to a halt. In some cases, one gets OOME
> fairly fast, but in others it can take fairly long.
That's exactly what happens when memory requirements are larger than
what is available. Soft/weak references can be of great help when used
in a fine-grained manner. Using some third party library with large
memory requirements there is nearly no way to manage its memory
requirements from client code efficiently. Exposing some cache
infrastructure by providing cache interfaces with get/put methods will
not work efficiently most of the time also. Going that road, those
interfaces will evolve and at some time they will look like callback
interfaces of the garbage collector. At that point the library could as
well use soft references internally and not expose any memory management
related interfaces at all. This already matches with what Kristian is
suggesting.
[...]
B) Cache eviction mechanism in DefaultPluginRealmCache and maybe
DefaultProjectRealmCache. Maybe ditch everything
"every now and then" or half the plugins every 5 invocations or similar.
[...]
Don't re-invent the garbage collector - just use it. I know this can
lead to major refactorings internally. I still haven't looked at the code.
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
