On Thu, Mar 29, 2012 at 5:15 AM, stirfoo <stir...@gmail.com> wrote:
>
> user=> (nth (subvec [:??? 1 2] 1) -1)
> :???
>
> This could be a bug, not sure.
>
> Only the upper bound of the internal SubVec is being checked.
Hmm. This also raises the specter of
(let [a (some-very-large-vector-with-millions-of-elements)
b (subvec a n (+ n 2))]
(swap! something assoc :somekey b))
holding onto the entirety of a via the subvec. One would hope that b
would only hold onto the minimal subtree of a needed to span b, i.e.
the tree root for b would be the deepest node of a that has all the
elements of b as children. With b only a couple of elements long that
would usually mean holding onto only 32 elements of a and occasionally
1024 elements (when b was split across two of a's 32-element leaf
nodes).
That hope would be dashed:
user=> (def a (vec (range 64)))
#'user/a
user=> (let [b (subvec a 33 35)] (nth b -17))
16
user=> (let [x (vec (range 64)) b (subvec x 33 35)] (nth b -17))
16
user=> (def b (subvec a 33 35))
#'user/b
user=> (def a nil)
#'user/a
user=> (System/gc)
nil
user=> (nth b -17)
16
The bs in this instance would not have access to the first half of a/x
with that implementation, certainly not after the a vector was
completely purged by setting a to nil and doing a full GC. And yet
they do.
Subvec should be modified to hold onto the deepest node of the parent
that holds all of the subvec's elements.
--
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 with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
