Clojure

Locals still cleared too aggressively on delay in specific cases

Details

  • Type: Defect Defect
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Completed
  • Affects Version/s: Release 1.4
  • Fix Version/s: Release 1.6
  • Component/s: None
  • Labels:
    None

Description

This seems to be an extension of #CLJ-232. Locals are still cleared too aggressively in some specific instances: If the delay throws an exception when realized, and you dereference a local within the delay, the local may or may not be cleared depending on its need in the tail positions (without any obvious pattern). Examples of functions which works as intended and doesn't work as intended follows.

(def d (let [y (delay 0)]
         (delay (if (zero? @y) (/ 0 0) (/ @y 1))))) ; works properly

(def d (let [y (delay 0)]
         (delay (if (zero? @y) (/ 0 0) (/ 1 1))))) ; does not work properly

(def d (let [y (delay 0)]
         (delay (if (zero? @y) (/ @y 0) (/ 1 1))))) ; does not work properly

(def d (let [y (delay 0)]
         (delay (if (zero? @y) (/ @y 0) (/ @y 1))))) ; does not work properly

(def d (let [y (delay 0)]
         (delay @y (/ 0 0)))) ; does not work properly

(def d (let [y (delay 0)]
         (delay @y (/ 0 0) @y))) ; works properly

By "works", d will throw "ArithmeticException Divide by zero" every single time it is dereferenced. By "does not work", d will throw "ArithmeticException Divide by zero" on first dereferencing, but from second and onwards it will throw "NullPointerException [trace missing]".

Activity

Andy Fingerhut made changes -
Field Original Value New Value
Description This seems to be an extension of [#CLJ-232|http://dev.clojure.org/jira/browse/CLJ-232]. Locals are still cleared too aggressively in some specific instances: If the delay throws an exception when realized, and you dereference a local within the delay, the local may or may not be cleared depending on its need in the tail positions (without any obvious pattern). Examples of functions which works as intended and doesn't work as intended follows.

{noformat}
(def d (let [y (delay 0)]
         (delay (if (zero? @y) (/ 0 0) (/ @y 1))))) ; works properly

(def d (let [y (delay 0)]
         (delay (if (zero? @y) (/ 0 0) (/ 1 1))))) ; does not work properly

(def d (let [y (delay 0)]
         (delay (if (zero? @y) (/ @y 0) (/ 1 1))))) ; does not work properly

(def d (let [y (delay 0)]
         (delay (if (zero? @y) (/ @y 0) (/ @y 1))))) ; does not work properly

(def d (let [y (delay o)]
         (delay @y (/ 0 0)))) ; does not work properly

(def d (let [y (delay o)]
         (delay @y (/ 0 0) @y))) ; works properly
{noformat}
By "works", {{d}} will throw "ArithmeticException Divide by zero" every single time it is dereferenced. By "does not work", {{d}} will throw "ArithmeticException Divide by zero" on first dereferencing, but from second and onwards it will throw "NullPointerException [trace missing]".
This seems to be an extension of [#CLJ-232|http://dev.clojure.org/jira/browse/CLJ-232]. Locals are still cleared too aggressively in some specific instances: If the delay throws an exception when realized, and you dereference a local within the delay, the local may or may not be cleared depending on its need in the tail positions (without any obvious pattern). Examples of functions which works as intended and doesn't work as intended follows.

{noformat}
(def d (let [y (delay 0)]
         (delay (if (zero? @y) (/ 0 0) (/ @y 1))))) ; works properly

(def d (let [y (delay 0)]
         (delay (if (zero? @y) (/ 0 0) (/ 1 1))))) ; does not work properly

(def d (let [y (delay 0)]
         (delay (if (zero? @y) (/ @y 0) (/ 1 1))))) ; does not work properly

(def d (let [y (delay 0)]
         (delay (if (zero? @y) (/ @y 0) (/ @y 1))))) ; does not work properly

(def d (let [y (delay 0)]
         (delay @y (/ 0 0)))) ; does not work properly

(def d (let [y (delay 0)]
         (delay @y (/ 0 0) @y))) ; works properly
{noformat}
By "works", {{d}} will throw "ArithmeticException Divide by zero" every single time it is dereferenced. By "does not work", {{d}} will throw "ArithmeticException Divide by zero" on first dereferencing, but from second and onwards it will throw "NullPointerException [trace missing]".
Alex Miller made changes -
Resolution Completed [ 1 ]
Fix Version/s Release 1.6 [ 10157 ]
Status Open [ 1 ] Closed [ 6 ]

People

Vote (0)
Watch (4)

Dates

  • Created:
    Updated:
    Resolved: