Actually it seems to me that LazyList.length could be written as a tail
call. The length of a list equals the length of its tail + 1, which would
be pretty easy to turn into a tail-recursive function using an accumulator
parameter.
Also, you could make the lazily generated tail reference be a soft or a weak
reference, and just (re)generate it as required.
But I'm being nit-picky. Leaving xs uncollectable past its time makes the
GC abstraction leaky, thereby forcing clever tricks that should not be
required.
On 10/30/07, Malcolm Sharpe <[EMAIL PROTECTED]> wrote:
>
>
> Proper tail calls would help sometimes, but not always.
>
> For instance, using a fictional LazyList class,
>
> int foo() {
> LazyList xs = LazyList.replicate(10000000, new Object());
> int x = LazyList.length(xs); // this call fully evaluates the tails
> of xs
> return 2 + x;
> }
>
> In this case, LazyList.length is not a tail call, but it is the
> problematic call, since xs will be referenced throughout the call.
> Note also that the JIT will compile LazyList.length, since its loop
> will execute often enough, but it will not compile foo(), which is the
> method retaining the unneeded reference to xs.
>
> - Malcolm
>
> On Oct 30, 1:29 am, Ingo Wechsung <[EMAIL PROTECTED]> wrote:
> > On 29 Okt., 19:37, Malcolm Sharpe <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > > Hi,
> >
> > > We've encountered an interesting Java memory usage problem that occurs
> > > when using lazily-constructed data structures. The problem is that a
> > > single data structure, such as a list, may not fit into memory all at
> > > once, so it's important to not hold a reference to the parts that are
> > > no longer in use. Unfortunately, Sun's Java GC follows local variables
> > > even when they can be statically known to be no longer in use, such as
> > > after they are passed to a function call and never again referenced.
> > > This only seems to be the case with the bytecode interpreter, but an
> > > out-of-memory error can occur well before the affected code is JIT-
> > > compiled.
> >
> > > This issue is most common in lazy languages implemented on the JVM,
> > > such as our language, CAL, but it affects any JVM program using lazy
> > > data structures.
> >
> > Right.
> > This is also a problem brought about by the inability of the JVM to do
> > tail calls. Proper tail calls would null out the local variables of
> > the caller automatically, instantly and cheaply.
>
>
> >
>
--
http://erikengbrecht.blogspot.com/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
