I watched Phil Bagwell's talk and found it very interesting, but I as far
as I remember he doesn't discuss GC.
Anyway, let's leave this as an "open question", and I'd be interested in
hearing from people who've memory-profiled their persistent collections.
But I can understand from your answer t
On Sun, Feb 12, 2012 at 5:44 AM, pron wrote:
> So my question is, what is the
> "behavior profile" for persistent collection nodes in Clojure applications,
> and what is their measured effect on GC.
I think that's going to depend on what your code does and how it
behaves - which is the same answe
I suspect that the clojure is actually slightly better here than standard java
collections.
With standard java collections, you'll tend to associate a collection with some
attribute or property of an object and then modify it over time. The chances of
this object living to a later generation ar
Alright, let me explain. I'm not talking about memory leaks or whether or
not objects become eligible for collection when they should. The JVM
garbage collector is a generational collector, which means there's a *
humongous* difference in GC work between objects that become unreachable
(eligible
Hi Ron,
I've profiled a 20k line Clojure application and have never seen anything like
what you seem to be suggesting. It seems (though you've not been very clear)
that you suspect that persistent collections may be holding references to nodes
longer than necessary. That is, longer than a mutab
Not sure if I understand your concern since I wonder how's that
different from, say, some ephemeral Java collection that happens to be
around after a given generational threshold and then becomes
unreachable.
On Feb 10, 4:01 am, pron wrote:
> And have you profiled the objects making it to the old
And have you profiled the objects making it to the old generation
(requiring/causing the full GC)? Are persistent collection nodes a
significant part of those?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to cloj
On Thu, Feb 9, 2012 at 4:30 PM, pron wrote:
> Yes, that's what I thought. Does anyone have any experience with Clojure's
> garbage production pattern (esp. due to the persistent collection) and it's
> behavior with the older GCs as well as with G1?
These are the options we run with in production
Yes, that's what I thought. Does anyone have any experience with Clojure's
garbage production pattern (esp. due to the persistent collection) and it's
behavior with the older GCs as well as with G1?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
T
It seems to me that a generational collector would have problems
collecting Clojure's garbage production pattern. Luckily, the oracle/
hotspot jvm has a continuous collecting compacting GC called G1. That
should mitigate oldspace collection latency spikes. Enable with -XX:
+UnlockExperimentalVMOpti
Hi Ron,
I think the persistent collections are no different from any other
collections from a GC perspective in that you control which references you
keep and for how long in your code. After "modification" some nodes may no
longer be referenced and will be eligible for GC so I'm not sure what you
Hi. I have a question:
I love Clojure's persistent collections, but don't they generate many
long-lived objects (that go to the surving generations) that are hard to
garbage-collect? After all, the discarded nodes after "modification" are
not necessarily short lived. It seems like they would beh
12 matches
Mail list logo
