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

Не очень хочется об этом говорить, но один я всё же чувствую себя слабоватым для задачи. Немного вводных:

• сборка мусора иногда незаменима, поэтому если её выкинуть из языка совсем, то потом будет больно
• на подсчёте ссылок работает гуй в Apple, и работает он быстро. После Явы программы для Эпл просто поражают своей быстротой
• питон успешно использует комбинацию подсчёта ссылок и gc. Но из-за общей тормознутости сложно понять, насколько подсчёт ссылок его замедляет

В ЯОС куча уже большая и уже есть проблемы. Сборщик мусора там простой без поколений, да и мне с трудом верится, что для мутабельных объектов поколенческий сборщик хорошо работает. Я читал какую-то статью на эту тему, но не понял.

Я сначала думал, что нужно взять механизмы из Раста и добавить их к Оберону, чтобы получился гибрид между растовым механизмом и сборкой мусора. Но теперь я думаю, что нефиг тут изображать из себя гения, особенно, когда ничего не получается, и нужно взять модель из Питона. Потому что наша задача про список с помощью RC вполне себе решается. Соответственно на данный момент стратегический план хочет стать таким:

• создаём кучи, локальные для «активностей». Активность - это римерно зелёный тред. Соответственно, создаём предпосылки, чтобы активности больше пользовались локальными данными и уменьшить количество разделяемых данных

• используем подсчёт ссылок и сборку мусора совместно, как в Питоне. При этом стараемся использовать потоко-локальный подсчёт ссылок, который дешевле

• где можно, выделяем на стеке (такая возможность в Обероне уже и так есть, но немного криво нарезана, объекты выделять на стеке нельзя, только записи и фиксированные массивы).

В итоге тут возникают корреляции с Растом, но не в том. ХОрошие вещи - это контроль компилятором за передачей данных между потоками и различие между внутрипоточным и многопоточным Rc.

И вот это всё вместе у меня варится-варится - да не сваривается. Например, если мы разрешаем простые ссылки между кучами разных активностей, то у нас всё равно в итоге все кучи склеиваются в одну. Если же мы её не разрешаем, то мы теряем сборку мусора там, где она может быть нужна больше всего.

Ещё нужно RAII добавить как-то.

Не очень хочется об этом говорить, но один я всё же чувствую себя слабоватым для задачи. Немного вводных:

• сборка мусора иногда незаменима, поэтому если её выкинуть из языка совсем, то потом будет больно
• на подсчёте ссылок работает гуй в Apple, и работает он быстро. После Явы программы для Эпл просто поражают своей быстротой
• питон успешно использует комбинацию подсчёта ссылок и gc. Но из-за общей тормознутости сложно понять, насколько подсчёт ссылок его замедляет

В ЯОС куча уже большая и уже есть проблемы. Сборщик мусора там простой без поколений, да и мне с трудом верится, что для мутабельных объектов поколенческий сборщик хорошо работает. Я читал какую-то статью на эту тему, но не понял.

Я сначала думал, что нужно взять механизмы из Раста и добавить их к Оберону, чтобы получился гибрид между растовым механизмом и сборкой мусора. Но теперь я думаю, что нефиг тут изображать из себя гения, особенно, когда ничего не получается, и нужно взять модель из Питона. Потому что наша задача про список с помощью RC вполне себе решается. Соответственно на данный момент стратегический план хочет стать таким:

• создаём кучи, локальные для «активностей». Активность - это римерно зелёный тред. Соответственно, создаём предпосылки, чтобы активности больше пользовались локальными данными и уменьшить количество разделяемых данных

• используем подсчёт ссылок и сборку мусора совместно, как в Питоне. При этом стараемся использовать потоко-локальный подсчёт ссылок, который дешевле

• где можно, выделяем на стеке (такая возможность в Обероне уже и так есть, но немного криво нарезана, объекты выделять на стеке нельзя, только записи и фиксированные массивы).

В итоге тут возникают корреляции с Растом, но не в том. ХОрошие вещи - это контроль компилятором за передачей данных между потоками и различие между внутрипоточным и многопоточным Rc.

И вот это всё вместе у меня варится-варится - да не сваривается. Например, если мы разрешаем простые ссылки между кучами разных объектов, то у нас всё равно в итоге все кучи склеиваются в одну. Если же мы её не разрешаем, то мы теряем сборку мусора там, где она может быть нужна больше всего.

Ещё нужно RAII добавить как-то.

Не очень хочется об этом говорить, но один я всё же чувствую себя слабоватым для задачи. Немного вводных:

• сборка мусора иногда незаменима, поэтому если её выкинуть из языка совсем, то потом будет больно
• на подсчёте ссылок работает гуй в Apple, и работает он быстро. После Явы программы для Эпл просто поражают своей быстротой
• питон успешно использует комбинацию подсчёта ссылок и gc. Но из-за общей тормознутости сложно понять, насколько подсчёт ссылок его замедляет

В ЯОС куча уже большая и уже есть проблемы. Сборщик мусора там простой без поколений, да и мне с трудом верится, что для мутабельных объектов поколенческий сборщик хорошо работает. Я читал какую-то статью на эту тему, но не понял.

Я сначала думал, что нужно взять механизмы из Раста и добавить их к Оберону, чтобы получился гибрид между растовым механизмом и сборкой мусора. Но теперь я думаю, что нефиг тут изображать из себя гения, особенно, когда ничего не получается, и нужно взять модель из Питона. Потому что наша задача про список с помощью RC вполне себе решается. Соответственно на данный момент стратегический план хочет стать таким:

• создаём кучи, локальные для «активностей». Активность - это римерно зелёный тред. Соответственно, создаём предпосылки, чтобы активности больше пользовались локальными данными и уменьшить количество разделяемых данных

• используем подсчёт ссылок и сборку мусора совместно, как в Питоне. При этом стараемся использовать потоко-локальный подсчёт ссылок, который дешевле

• где можно, выделяем на стеке (такая возможность в Обероне уже и так есть, но немного криво нарезана, объекты выделять на стеке нельзя, только записи и фиксированные массивы).

В итоге тут возникают корреляции с Растом, но не в том. ХОрошие вещи - это контроль компилятором за передачей данных между потоками и различие между внутрипоточным и многопоточным Rc.

И вот это всё вместе у меня варится-варится - да не сваривается. Например, если мы разрешаем простые ссылки между кучами разных объектов, то у нас всё равно в итоге все кучи склеиваются в одну.

Ещё нужно RAII добавить как-то.

Не очень хочется об этом говорить, но один я всё же чувствую себя слабоватым для задачи. Немного вводных:

• сборка мусора иногда незаменима, поэтому если её выкинуть из языка совсем, то потом будет больно
• на подсчёте ссылок работает гуй в Apple, и работает он быстро. После Явы программы для Эпл просто поражают своей быстротой
• питон успешно использует комбинацию подсчёта ссылок и gc. Но из-за общей тормознутости сложно понять, насколько подсчёт ссылок его замедляет

В ЯОС куча уже большая и уже есть проблемы. Сборщик мусора там простой без поколений, да и мне с трудом верится, что для мутабельных объектов поколенческий сборщик хорошо работает. Я читал какую-то статью на эту тему, но не понял.

Я сначала думал, что нужно взять механизмы из Раста и добавить их к Оберону, чтобы получился гибрид между растовым механизмом и сборкой мусора. Но теперь я думаю, что нефиг тут изображать из себя гения, особенно, когда ничего не получается, и нужно взять модель из Питона. Потому что наша задача про список с помощью RC вполне себе решается. Соответственно на данный момент стратегический план хочет стать таким:

• создаём кучи, локальные для «активностей». Активность - это римерно зелёный тред. Соответственно, создаём предпосылки, чтобы активности больше пользовались локальными данными и уменьшить количество разделяемых данных

• используем подсчёт ссылок и сборку мусора совместно, как в Питоне. При этом стараемся использовать потоко-локальный подсчёт ссылок, который дешевле

• где можно, выделяем на стеке (такая возможность в Обероне уже и так есть, но немного криво нарезана, объекты выделять на стеке нельзя, только записи и фиксированные массивы).

В итоге тут возникают корреляции с Растом, но не в том. ХОрошие вещи - это контроль компилятором за передачей данных между потоками и различие между внутрипоточным и многопоточным Rc.

И вот это всё вместе у меня варится-варится - да не сваривается. Ещё нужно RAII добавить как-то.

Не очень хочется об этом говорить, но один я всё же чувствую себя слабоватым для задачи. Немного вводных:

• сборка мусора иногда незаменима, поэтому если её выкинуть из языка совсем, то потом будет больно
• на подсчёте ссылок работает гуй в Apple, и работает он быстро. После Явы программы для Эпл просто поражают своей быстротой
• питон успешно использует комбинацию подсчёта ссылок и gc. Но из-за общей тормознутости сложно понять, насколько подсчёт ссылок его замедляет

В ЯОС куча уже большая и уже есть проблемы. Сборщик мусора там простой без поколений, да и мне с трудом верится, что для мутабельных объектов поколенческий сборщик хорошо работает. Я читал какую-то статью на эту тему, но не понял.

Я сначала думал, что нужно взять механизмы из Раста и добавить их к Оберону, чтобы получился гибрид между растовым механизмом и сборкой мусора. Но теперь я думаю, что нефиг тут изображать из себя гения, особенно, когда ничего не получается, и нужно взять модель из Питона. Потому что наша задача про список с помощью RC вполне себе решается. Соответственно на данный момент стратегический план хочет стать таким:

• создаём кучи, локальные для «активностей». Активность - это римерно зелёный тред. Соответственно, создаём предпосылки, чтобы активности больше пользовались локальными данными и уменьшить количество разделяемых данных

• используем подсчёт ссылок и сборку мусора совместно, как в Питоне. При этом стараемся использовать потоко-локальный подсчёт ссылок, который дешевле

• где можно, выделяем на стеке (такая возможность в Обероне уже и так есть, но немного криво нарезана, объекты выделять на стеке нельзя, только записи и фиксированные массивы).

В итоге тут возникают корреляции с Растом, но не в том. ХОрошие вещи - это контроль компилятором за передачей данных между потоками и различие между Rc и многопоточным Rc.

И вот это всё вместе у меня варится-варится - да не сваривается. Ещё нужно RAII добавить как-то.

Не очень хочется об этом говорить, но один я всё же чувствую себя слабоватым для задачи. Немного вводных:

• сборка мусора иногда незаменима, поэтому если её выкинуть из языка совсем, то потом будет больно
• на подсчёте ссылок работает гуй в Apple, и работает он быстро. После Явы программы для Эпл просто поражают своей быстротой
• питон успешно использует комбинацию подсчёта ссылок и gc. Но из-за общей тормознутости сложно понять, насколько подсчёт ссылок его замедляет

В ЯОС куча уже большая и уже есть проблемы. Сборщик мусора там простой без поколений, да и мне с трудом верится, что для мутабельных объектов поколенческий сборщик хорошо работает. Я читал какую-то статью на эту тему, но не понял.

Я сначала думал, что нужно взять механизмы из Раста и добавить их к Оберону, чтобы получился гибрид между растовым механизмом и сборкой мусора. Но теперь я думаю, что нефиг тут изображать из себя гения, особенно, когда ничего не получается, и нужно взять модель из Питона. Потому что наша задача про список с помощью RC вполне себе решается.