LINUX.ORG.RU

История изменений

Исправление hateyoufeel, (текущая версия) :

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

как бы инкременто не аллокировался обьект, на N аллокаций, надо N деалокаций, что муторно в сборщиках мусора.

Нет. В случае с generational gc, в новое поколение копируются только живые объекты и те, на которые они ссылаются. Под живыми подразумеваются те, на которые есть ссылки из текущего кода/тредов.

У эрланго-хацкеллов тут есть жирный бонус ввиду иммутабельности в том, что старые объекты не могут ссылаться на более новые. То есть, если у тебя самый новый живой объект имеет адрес X, то на все объекты начиная с X+1 можно класть жирный болт, они мертвы.

Ещё жирным бонусом по части generational gc идёт то, что в них есть отдельное нулевое поколение nursery (ясли), которое обычно имеет размер кэша процессора. Профит в том, что подавляющее большинство объектов долго не живут, и 80-90% из них не покидают ясли в принципе. Соответственно, при переносе из яслей в первое поколение, нужно обработать только 10-20% объектов, а остальные просто сносятся скопом и даже в оперативную память не попадают.

GC действительно эволюционировали и весьма сильно за последние лет 50, тут лавсанчег прав. Но в чём он неправ, так это в том, что GC будет быстрее ручного управления. Как показывает практика, не будет, если не задрачивать GC до такой степени, что код выглядит хуже чем на C++.

Исправление hateyoufeel, :

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

как бы инкременто не аллокировался обьект, на N аллокаций, надо N деалокаций, что муторно в сборщиках мусора.

Нет. В случае с generational gc, в новое поколение копируются только живые объекты и те, на которые они ссылаются. Под живыми подразумеваются те, на которые есть ссылки из текущего кода/тредов.

У эрланго-хацкеллов тут есть жирный бонус ввиду иммутабельности в том, что старые объекты не могут ссылаться на более новые. То есть, если у тебя самый новый живой объект имеет адрес X, то на все объекты начиная с X+1 можно класть жирный болт, они мертвы.

Ещё жирным бонусом по части generational gc идёт то, что в них есть отдельное нулевое поколение nursery (ясли), которое обычно имеет размер кэша процессора. Профит в том, что подавляющее большинство объектов долго не живут, и 80-90% из них не покидают ясли в принципе. Соответственно, при переносе из яслей в первое поколение, нужно обработать только 10-20% объектов, а остальные просто сносятся скопом.

GC действительно эволюционировали и весьма сильно за последние лет 50, тут лавсанчег прав. Но в чём он неправ, так это в том, что GC будет быстрее ручного управления. Как показывает практика, не будет, если не задрачивать GC до такой степени, что код выглядит хуже чем на C++.

Исправление hateyoufeel, :

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

как бы инкременто не аллокировался обьект, на N аллокаций, надо N деалокаций, что муторно в сборщиках мусора.

Нет. В случае с generational gc, в новое поколение копируются только живые объекты и те, на которые они ссылаются. Под живыми подразумеваются те, на которые есть ссылки из текущего кода/тредов.

У эрланго-хацкеллов тут есть жирный бонус ввиду иммутабельности в том, что старые объекты не могут ссылаться на более новые. То есть, если у тебя самый новый живой объект имеет адрес X, то на все объекты начиная с X+1 можно класть жирный болт, они мертвы.

Ещё жирным бонусом по части generational gc идёт то, что в них есть отдельное нулевое поколение nursery (ясли), которое обычно имеет размер кэша процессора. Профит в том, что подавляющее большинство объектов долго не живут, и 80-90% из них не покидают ясли в принципе. Соответственно, при переносе из яслей в первое поколение, нужно обработать только 10-20% объектов, а остальные просто сносятся скопом.

Исходная версия hateyoufeel, :

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

как бы инкременто не аллокировался обьект, на N аллокаций, надо N деалокаций, что муторно в сборщиках мусора.

Нет. В случае с generational gc, новое поколение копируются только живые объекты и те, на которые они ссылаются. Под живыми подразумеваются те, на которые есть ссылки из текущего кода/тредов.

У эрланго-хацкеллов тут есть жирный бонус ввиду иммутабельности в том, что старые объекты не могут ссылаться на более новые. То есть, если у тебя самый новый живой объект имеет адрес X, то на все объекты начиная с X+1 можно класть жирный болт, они мертвы.