Телеграмм чат группы compilerdev страница 959

Михаил Бахтерев

А сейчас как в Go?

Одним куском стек аллоцируют и переаллоцируют, если нужно. Оказалось, что так быстрее. Но всё равно в куче, конечно.

18:06пожаловаться #1

Ɖ

Ɖrēw in Compiler Development

Ребят, всем привет
Недавно начал разбираться с LLVM
До этого работал только с CLR и CIL
Кто то может подсказать как там дела обстоят с интеропом с другими языками которые таргетятся на LLVM?
Например захотелось мне какую то либу заюзать для того чтобы написать веб фреймворк на своем языке, как мне это сделать?

18:18пожаловаться #2

KR

Alexander Tchitchigin

Одним куском стек аллоцируют и переаллоцируют, если нужно. Оказалось, что так быстрее. Но всё равно в куче, конечно.

А то, что уже лежит на стеке? Это копируют?

18:22пожаловаться #3

AT

А то, что уже лежит на стеке? Это копируют?

Конечно. Работает как std::vector в C++.

18:23пожаловаться #4

KR

А указатели на данные на стеке там не протекают?

18:25пожаловаться #5

AT

А указатели на данные на стеке там не протекают?

А в Go бывают указатели на данные на стеке? 😊

18:26пожаловаться #6

KR

Alexander Tchitchigin

А в Go бывают указатели на данные на стеке? 😊

А указатели на локальные переменные же могут быть?

18:29пожаловаться #7

KR

Я что-то базовое не понимаю.

18:29пожаловаться #8

AT

А указатели на локальные переменные же могут быть?

Поскольку компилятор про них знает и перемещает в кучу, если они "убегают", то и при реаллокации стека явно может обновить.

18:30пожаловаться #9

KR

Но реаллокация стека же зависит от глубины рекурсии. Как о ней может знать компилятор?

Михаил Бахтерев in Compiler Development

18:31пожаловаться #10

МБ

Но реаллокация стека же зависит от глубины рекурсии. Как о ней может знать компилятор?

Он знает об убегающих в кучу объектах. Просто сразу их там аллоцирует. Это, вроде, и в начальной реализации так было.

18:32пожаловаться #11

Ɖ

Ɖrēw in Compiler Development

Ɖrēw

Ребят, всем привет
Недавно начал разбираться с LLVM
До этого работал только с CLR и CIL
Кто то может подсказать как там дела обстоят с интеропом с другими языками которые таргетятся на LLVM?
Например захотелось мне какую то либу заюзать для того чтобы написать веб фреймворк на своем языке, как мне это сделать?

Никто не может подсказать я так понял?)

18:33пожаловаться #12

Ɖ

Ɖrēw in Compiler Development

Возможно вопрос глупый и кто то направит в нужную сторону

18:33пожаловаться #13

KR

Михаил Бахтерев

Он знает об убегающих в кучу объектах. Просто сразу их там аллоцирует. Это, вроде, и в начальной реализации так было.

Всё равно непонятно:

func a() {
i:= 1
pi := &i

b()

*pi = 2
}

Как только взяли указатель на i, ее сразу в кучу?

Михаил Бахтерев in Compiler Development

18:35пожаловаться #14

МБ

Ɖrēw

Возможно вопрос глупый и кто то направит в нужную сторону

Это называют foreign function interface, надо смотреть в эту сторону. Вообще, зависит от того, в каком формате библиотека подготовлена. Если это llvm-биткод, то линковщик без особых проблем слинкует.

18:35пожаловаться #15

AT

Но реаллокация стека же зависит от глубины рекурсии. Как о ней может знать компилятор?

Реаллоцирует стек же не компилятор, а рантайм. А он понятно откуда будет знать. Для GC всё равно нужно знать где какой кадр лежит и к какой функции он относится. 🤷‍♀️

Михаил Бахтерев in Compiler Development

18:39пожаловаться #16

МБ

Всё равно непонятно:

func a() {
i:= 1
pi := &i

b()

*pi = 2
}

Как только взяли указатель на i, ее сразу в кучу?

Надо запустить 6g -m и посмотреть, что компилятор об этом думает. Вероятно, будет зависеть от оценок размера стека для b()

18:40пожаловаться #17

KR

Alexander Tchitchigin

Реаллоцирует стек же не компилятор, а рантайм. А он понятно откуда будет знать. Для GC всё равно нужно знать где какой кадр лежит и к какой функции он относится. 🤷‍♀️

То есть, выделяя переменную на стеке, мы всё равно уведомляем о ней gc?

18:42пожаловаться #18

AT

То есть, выделяя переменную на стеке, мы всё равно уведомляем о ней gc?

Ясен пень - как иначе GC должен догадаться это root или нет?