/guides/troubleshoot/memleaks002.html
>
>
Yes, all on Java 8. Thanks. I thought about using that flag, but wanted
to get to the bottom of the problem, and have now done so by turning off
locals clearing.
--
You received this message because you are subscribed to the Google
Groups "
ars0i ha scritto:
>
> In my application, I seem to get a memory leak when I use
> -Dclojure.compiler.disable-locals-clearing=true in Clojure 1.7.0 and 1.8.0,
> but not in 1.6.0. (i.e. I get "java.lang.OutOfMemoryError: GC overhead
> limit exceeded" with the more rec
On Monday, January 25, 2016 at 9:26:17 AM UTC-6, Alex Miller wrote:
>
> When you disable locals clearing, you will start holding the head of
> (potentially large) locals everywhere. This is the reason that locals are
> aggressively called in the first place. This is a typical co
On Monday, January 25, 2016 at 9:26:17 AM UTC-6, Alex Miller wrote:
>
> When you disable locals clearing, you will start holding the head of
> (potentially large) locals everywhere. This is the reason that locals are
> aggressively called in the first place. This is a typical co
when I use
> -Dclojure.compiler.disable-locals-clearing=true in Clojure 1.7.0 and 1.8.0,
> but not in 1.6.0. (i.e. I get "java.lang.OutOfMemoryError: GC overhead
> limit exceeded" with the more recent versions).
>
> Any guesses about why this might happen? Just curiou
When you disable locals clearing, you will start holding the head of
(potentially large) locals everywhere. This is the reason that locals are
aggressively called in the first place. This is a typical consequence of
disabling locals clearing and the reason why they are cleared by default.
This
In my application, I seem to get a memory leak when I use
-Dclojure.compiler.disable-locals-clearing=true in Clojure 1.7.0 and 1.8.0,
but not in 1.6.0. (i.e. I get "java.lang.OutOfMemoryError: GC overhead
limit exceeded" with the more recent versions).
Any guesses about why this mi
they are out of scope they are eligible for garbage
collection. The "locals clearing" is just an optimisation to allow
the GC before they are out of scope, but after they are no longer
needed.
> On Sunday, January 30, 2011 7:41:44 AM UTC-6, Rich Hickey wrote:
>>
>> (Note:
Am I correct in assuming that if those allocations had been smaller (i.e. if
the JVM had not run out of memory), the GC would have eventually detected
the dead references and freed them once the locals went out of scope?
Bill Smith
On Sunday, January 30, 2011 7:41:44 AM UTC-6, Rich Hickey wrote
On Jan 30, 6:08 am, Daniel Janus wrote:
> Hi,
>
> I've recently heard about the locals clearing feature of Clojure 1.2 (from a
> recent post by Ken Wesson), and decided to test-drive it. Here is a
> contrived example:
>
> (defn garbage []
> (make-array Byte/TY
Hi,
I've recently heard about the locals clearing feature of Clojure 1.2 (from a
recent post by Ken Wesson), and decided to test-drive it. Here is a
contrived example:
(defn garbage []
(make-array Byte/TYPE 10485760))
(defn -main [& args]
(let [a (garbage)
b (garbage)
It's an issue of when the object referenced by 'a' can be garbage
collected.
Rich is able to do some magic in the bytecode whereby the 'a'
reference is set to null prior to the effective call to fn2 (and still
pass the object), thus the object can be garbage collected whenever
fn2 is done with it
I do not understand the question.
On Jun 22, 5:46 am, ann wrote:
> (defn fn1 [a] (fn2 a) )
>
> When is a cleared, before call to fn2 or after?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.
Before.
On Jun 22, 3:46 am, ann wrote:
> (defn fn1 [a] (fn2 a) )
>
> When is a cleared, before call to fn2 or after?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from n
(defn fn1 [a] (fn2 a) )
When is a cleared, before call to fn2 or after?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient w
On Sat, Dec 12, 2009 at 10:57 AM, Daniel Werner
wrote:
> On Dec 10, 3:10 pm, Rich Hickey wrote:
>> I'm happy to announce I have implemented this fine-grained locals
>> clearing in the compiler, in the 'new' branch.
>
> Is there a chance for this featur
On Dec 10, 3:10 pm, Rich Hickey wrote:
> I'm happy to announce I have implemented this fine-grained locals
> clearing in the compiler, in the 'new' branch.
Is there a chance for this feature to find its way into master before
Clojure 1.1 is released?
--
You received thi
> Also, it may be very useful to try all your code on 'new' *without*
> taking
> advantage of the new features, and reporting back on any
> breakage.
That's more what I was thinking. While I find the new features
interesting, I'm less jazzed about spending the time to build on
features that
h Hickey wrote:
> I'm happy to announce I have implemented this fine-grained locals
> clearing in the compiler, in the 'new' branch. It should automatically
> cover all cases in which the code doesn't explicitly reuse the head -
> including non-tail usage, destructurin
On Thu, Dec 10, 2009 at 2:26 PM, Richard Newman wrote:
>> +1 As cool as the new branch is, this is the first compelling reason
>> I've seen to go to my boss and say we need to switch to it now.
>>
>> Thanks Rich!
>
> Speaking of which... I know the new branch is where Rich publishes his
> current
> +1 As cool as the new branch is, this is the first compelling reason
> I've seen to go to my boss and say we need to switch to it now.
>
> Thanks Rich!
Speaking of which... I know the new branch is where Rich publishes his
current work. Does anyone (Rich included!) have any opinion on whether
+1 As cool as the new branch is, this is the first compelling reason
I've seen to go to my boss and say we need to switch to it now.
Thanks Rich!
On Dec 10, 6:40 am, "Stephen C. Gilardi" wrote:
> On Dec 10, 2009, at 9:10 AM, Rich Hickey wrote:
>
> What a great change! We ran into the problem
On Dec 10, 2009, at 9:10 AM, Rich Hickey wrote:
> I'm happy to announce I have implemented this fine-grained locals
> clearing in the compiler, in the 'new' branch. It should automatically
> cover all cases in which the code doesn't explicitly reuse the head
branches of the execution path and to emit code that
> clears them at the point of last use in any particular branch.
>
> I'm happy to announce I have implemented this fine-grained locals
> clearing in the compiler, in the 'new' branch. It should automatically
> cover
emented this fine-grained locals
clearing in the compiler, in the 'new' branch. It should automatically
cover all cases in which the code doesn't explicitly reuse the head -
including non-tail usage, destructuring etc. In short, such cases
should 'just work' from now on.
N.B.
25 matches
Mail list logo
