Recycled Bin

В данном случае? messages, со всеми уже выведенными хвостами, жадно пожирающими память.

Т.е. в первом примере сгенерится astore и в нужном месте (где foreach, если знаешь Scala, или где <-, если не знаешь) будет вызван aload.

Во втором примере в том месте, где в первом был aload будет сделан непосредственный вызов — создание Stream-а. И вот он уже будет собираться gc.

From:

tonsky.livejournal.com

Stream хранит ссылку на голову последовательности? Нафига?

From:

что-то как-то непонятно, можно байткод обоих случаев в студию?

вообще любоей вменяемый компилятор делает анализ живости, поэтому если локальная переменная с какого-то момента не используется, то ее GC и не должен видеть.

Edited Date: 2012-12-01 01:04 pm (UTC)

From:

thedeemon.livejournal.com

Нет же, ссылка в стеке оказывается, из-за нее голова потока не считается мусором, а за ней и другие элементы.

From:

jakobz.livejournal.com

В дотнете делает только в релизе - чтобы не печалить индусов в дебаггере.

From:

ну на jvm интерпретатор такого тоже не делает.

From:

Это старая фишка, нарывался много лет назад, поэтому помню хорошо.

Ну вот для этого:

object X {

    def main(xs: Array[String]) = {
        for (x <- Stream.continually(1)) {}  // первый случай

        val xs = Stream.continually(1)  // второй случай
        for (x <- xs) {}
    }

}

байткод будет

public final class X$ extends java.lang.Object implements scala.ScalaObject{
public static final X$ MODULE$;

public static {};
  Code:
   0:	new	#9; //class X$
   3:	invokespecial	#12; //Method "":()V
   6:	return

public void main(java.lang.String[]);
  Code:
   0:	getstatic	#19; //Field scala/package$.MODULE$:Lscala/package$;
   3:	invokevirtual	#24; //Method scala/package$.Stream:()Lscala/collection/immutable/Stream$;
   6:	new	#26; //class X$$anonfun$main$1
   9:	dup
   10:	invokespecial	#27; //Method X$$anonfun$main$1."":()V
   13:	invokevirtual	#33; //Method scala/collection/immutable/Stream$.continually:(Lscala/Function0;)Lscala/collection/immutable/Stream;
   16:	new	#35; //class X$$anonfun$main$2
   19:	dup
   20:	invokespecial	#36; //Method X$$anonfun$main$2."":()V
   23:	invokevirtual	#42; //Method scala/collection/immutable/Stream.foreach:(Lscala/Function1;)V
   26:	getstatic	#19; //Field scala/package$.MODULE$:Lscala/package$;
   29:	invokevirtual	#24; //Method scala/package$.Stream:()Lscala/collection/immutable/Stream$;
   32:	new	#44; //class X$$anonfun$1
   35:	dup
   36:	invokespecial	#45; //Method X$$anonfun$1."":()V
   39:	invokevirtual	#33; //Method scala/collection/immutable/Stream$.continually:(Lscala/Function0;)Lscala/collection/immutable/Stream;
   42:	astore_2
   43:	aload_2
   44:	new	#47; //class X$$anonfun$main$3
   47:	dup
   48:	invokespecial	#48; //Method X$$anonfun$main$3."":()V
   51:	invokevirtual	#42; //Method scala/collection/immutable/Stream.foreach:(Lscala/Function1;)V
   54:	return

}

Обрати внимание на 42-43 строчки.

From:

Ну Stream это же head и tail, только tail ленивый. Так вот даже когда нам не нужны предыдущие вычисления они будут храниться. Обязаны, пока они являются локальными переменными.

From:

tonsky.livejournal.com

Да, точно, иммутабельность же.

From:

Кстати, а как с этим в clojure?

From:

так на строчках 13 и 51 поток используется как ресивер виртуального вызова Stream.foreach

до того как этот foreach вернется поток точно не помрет в обоих случаях, а после того как вернется... ну в интерпретаторе он допустим застрянет в локале ненадолго, но я более чем уверен, что для C1/C2 локал мертв после 43й строчки.

From:

andy legkiy (from livejournal.com)

Где-то на stackoverflow alexrom советовал пробовать ephemeral stream, из scalaz. Оно память не жрет.
https://github.com/scalaz/scalaz/blob/master/core/src/main/scala/scalaz/EphemeralStream.scala

> import scalaz.EphemeralStream
> val stream = EphemeralStream.range(0, 100000000)
> stream.length
  res0: Int = 100000000

Советы использовать tailrec, чтобы head не сохранялся, мне не особо понравились.

From:

Проверь!

Закомментируй первый случай, скомпиль, запусти. Убедись, что падает.
Раскомментируй, скомпиль, запусти. Убедись, что вертится.

From:

Спасибо, глянул реализацию.

Так там weak reference! У этого-то, конечно, будут чиститься все tail (кроме самого первого Stream, разумеется).

From:

Кстати, также очень не нравится, что из-за этого нельзя описывать рекурсивные фишки, типа

val fibs: Stream[Int] = 0 #:: 1 #:: (fibs, fibs.tail).zipped.map(_ + _)

Опять локальные переменные, опять out-of-memory.

Edited Date: 2012-12-01 06:18 pm (UTC)

From:

да, действительно застревает.

чудеса! совершенно непонятно зачем и где они его удерживают. я бы не стал.

ради интереса хотел посмотреть ассемблерный код, но на маке это надо через скакалочку прыгать, оказывается...

(а Stream.foreach оказывается свой this перезаписывает. поэтому он там и не застревает как я ожидал).

Edited Date: 2012-12-01 06:39 pm (UTC)

From:

В Heskell подобное тоже случается. Правда, хвостовая рекурсия и умный оптимизатор делают это событие сравнительно редким.

From:

Угу, чудеса, причём в спеке об этом как-то мимоходом сказано (сейчас даже найти не смог). А нарвался я на это много лет назад, разбираясь почему память течёт.

foreach — тоже угу, хвостато-рекурсивный.

From:

andy legkiy (from livejournal.com)

Видимо для выбранных нужд коллекции с memoization и правда не очень подходят.
Прийдется возращаться к рекурсии ;)

From:

thesz.livejournal.com

Слабо пример случившегося привести?

From:

Там же вроде не хвостовая рекурсия, там и стека-то толком нет.

From:

Prelude> let n=[1..] ; m = n !! (2 ^ 30) ; k = m + if m == 0 then head n else 1 in k

From:

Ленивость в некотором смысле ей эквивалентна. Но по моему он хвостовой вызов умеет оптимизировать - раз до туда управление дошло, значит результат вызова понадобился и возвращать недовыполненное значение смысла не имеет.

From:

Нечестно! Читер! Читер! :-)

У тебя два использования n. Он просто обязан хранить весь список.

From:

thesz.livejournal.com

Это не совсем другое, но заметно другой пример. В вычислении k используется n, хотя человеку понятно, что происходит, а компилятору нет. Здесь нужен умный компилятор. В вычислении foreach (x : s) { } переменная s не используется, она может быть заменена прямой подстановкой, компилятор и RTS могут быть заметно тупей.

From:

Мог бы. Тем более там val, а не var. Но тягаться по интеллекту с ghc компиляторы еще долго не смогут.

From:

по поводу UPD будут какие-нибудь детали? :-)

From:

Упс. Ссылку криво вписал, поправил.

Смысл такой, что на некоторых jvm да с некоторыми ключами jit оптимизирует хранение переменной (регистр, параметр следующей функции, х.з.). И gc её всё-таки убивает.

From: