Дак спрашивай)

ну короче, есть кто-нибудь кто хоть немного шарит в сборщиках мусора? я просто хочу запилить дженерик интерфейс через который можно будет через опции командной строки выбирать стратегию сборки мусора соответственно как я себе это представляю есть трейты GcRuntime<T> и GcBox<T> (первый в общем разруливает поведение gc, второй - обёртка над хранимыми данными) выглядеть они могут допустим как-то так pub trait GcRuntime<T> { type BoxType: GcBox<T>; fn alloc(&mut self, value: T) -> Self::BoxType; } pub trait GcBox<T> { // что сюда пихать я пока не придумал, но на всякий допустим пусть будет отдельный трейт } ну и допустим я для начала хочу в качестве стратегии сборки использовать обычный счётчик ссылок рантайма для него никакого не нужно, GcBox - это std::rc::Rc struct RcRuntime; impl<T> GcRuntime<T> for RcRuntime { type BoxType = Rc<T>; fn alloc(&mut self, value: T) -> Rc<T> { Rc::new(value) } } impl<T> GcBox<T> for Rc<T> {} Ну ок, допустим оно должно работать Теперь есть вот такое вот определение объекта в языке (по сути стыренное): type ObjectRef = Rc<Object>; #[derive(PartialEq, Debug, Clone)] pub struct Object { pub version: u64, pub name: Option<String>, pub content: ObjectContent, pub class: ObjectRef, pub bases: Option<Vec<ObjectRef>>, pub attributes: Option<HashMap<String, ObjectRef>>, } // тут ещё struct ObjectContent и др. Ну вот и теперь пытаюсь переписать на дженериках pub struct Object<O: GcRuntime<Object<O>>> { pub version: u64, pub name: Option<String>, pub content: ObjectContent<O>, pub class: O::BoxType, pub bases: Option<Vec<O::BoxType>>, pub attributes: Option<HashMap<String, O::BoxType>>, } pub enum ObjectContent<O: GcRuntime<Object<O>>> { None, Bool(bool), Int(i64), Float(f64), Str(String), List(Vec<Object<O>>), Tuple(Vec<Object<O>>), Code(CodeObject), Function(Function<O>), NativeFunction(fn(Vec<Object<O>>) -> Object<O>), } pub struct Function<O: GcRuntime<Object<O>>> { name: String, code: CodeObject, closure: Vec<Object<O>>, } // TODO pub struct CodeObject; Воот, оно вроде компилится, но получился какой-то дженерик-адок, и я не уверен что вообще сам подход верен. Может лучше уйти в динамику и использовать какой-нибудь Any вместо BoxType? Или может подход вообще в корне не верен? Может кто-нибудь подсказать кто шарит?

ну короче, есть кто-нибудь кто хоть немного шарит в сборщиках мусора? я просто хочу запилить дженерик интерфейс через который можно будет через опции командной строки выбирать стратегию сборки мусора соответственно как я себе это представляю есть трейты GcRuntime<T> и GcBox<T> (первый в общем разруливает поведение gc, второй - обёртка над хранимыми данными) выглядеть они могут допустим как-то так pub trait GcRuntime<T> { type BoxType: GcBox<T>; fn alloc(&mut self, value: T) -> Self::BoxType; } pub trait GcBox<T> { // что сюда пихать я пока не придумал, но на всякий допустим пусть будет отдельный трейт } ну и допустим я для начала хочу в качестве стратегии сборки использовать обычный счётчик ссылок рантайма для него никакого не нужно, GcBox - это std::rc::Rc struct RcRuntime; impl<T> GcRuntime<T> for RcRuntime { type BoxType = Rc<T>; fn alloc(&mut self, value: T) -> Rc<T> { Rc::new(value) } } impl<T> GcBox<T> for Rc<T> {} Ну ок, допустим оно должно работать Теперь есть вот такое вот определение объекта в языке (по сути стыренное): type ObjectRef = Rc<Object>; #[derive(PartialEq, Debug, Clone)] pub struct Object { pub version: u64, pub name: Option<String>, pub content: ObjectContent, pub class: ObjectRef, pub bases: Option<Vec<ObjectRef>>, pub attributes: Option<HashMap<String, ObjectRef>>, } // тут ещё struct ObjectContent и др. Ну вот и теперь пытаюсь переписать на дженериках pub struct Object<O: GcRuntime<Object<O>>> { pub version: u64, pub name: Option<String>, pub content: ObjectContent<O>, pub class: O::BoxType, pub bases: Option<Vec<O::BoxType>>, pub attributes: Option<HashMap<String, O::BoxType>>, } pub enum ObjectContent<O: GcRuntime<Object<O>>> { None, Bool(bool), Int(i64), Float(f64), Str(String), List(Vec<Object<O>>), Tuple(Vec<Object<O>>), Code(CodeObject), Function(Function<O>), NativeFunction(fn(Vec<Object<O>>) -> Object<O>), } pub struct Function<O: GcRuntime<Object<O>>> { name: String, code: CodeObject, closure: Vec<Object<O>>, } // TODO pub struct CodeObject; Воот, оно вроде компилится, но получился какой-то дженерик-адок, и я не уверен что вообще сам подход верен. Может лучше уйти в динамику и использовать какой-нибудь Any вместо BoxType? Или может подход вообще в корне не верен? Может кто-нибудь подсказать кто шарит?

и поэтому он связан с пропускной способностью

Да, в том плане что ты не обработаешь запросов больше. чем может прокачать твой канал, например. Это верхний ораничитель, пока мы в пропускную способность не уперлись, throughput растет вместе с rps

блин, полотно получилось вынести в гист?

Энивей, мы скатываемся в другой срач. Твой сервачок с архитектурой, приятно пахнущей ламповыми девяностыми, ни по throughput ни по rps даже близко не приблизится к правильно написанному асинхронному серверу. И это проблема)

а зачем тебе вообще дженерики?

Давай на плейграунд, там проще

блин, у меня просто много файлов, я тогда лучше уж сразу на гитхаб всё вместе залью

дык никто не спорит, но 50к протянуть можно

Дык это неэффективное решение как ни крути. Если у тебя железо может вытянуть лям клиентов, а ты только 50к со своим сервером хэндлишь, то чем это не проблема? Это как использовать сортировку пузырьком там, когда есть значительно более эффективные алгоритмы.

ну я же говорю, чтобы можно было в рантайме выбрать стратегию gc соответственно исходя из выбранных опций создавать объекты у которых параметр-тип-gc будет соответствовать той или иной стратегии

Ты уже дважды согласился что было

плохая идея выбирать стратегию в рантаиме

чтоб ты уже отстал

JVM так делает, не?

ага так, но только в случае с jvm gc сильно интегрирован с компилятором

JVM так делает, не?

можешь поподробнее рассказать или кинуть статейку какую-нибудь где про это прочитать можно?

можешь поподробнее рассказать или кинуть статейку какую-нибудь где про это прочитать можно?

с дженериками это вообще не сделать, имхо

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

у тебя язык интерпритируемый? или ты для раста делаешь?

интерпретируемый байт-код

для начала я хочу просто интерпретатор реализовать, а то я и так замахнулся на сложную для меня вещь, а jit - ещё одна вещь в которой надо основательно разбираться но если просто интерпретатор получится сделать, то потом jit было бы круто запилить кстати, вот ты говоришь что нужно делать интеграцию с jit - значит ли это, что какой-нибудь llvm'овский jit заюзать не получится и нужно будет писать свой, или llvm предоставляют какие-нибудь api для этого?

у Шипилева есть на твиче видео как он шенаду пилит

почитай еще http://llvm.org/docs/GarbageCollection.html