История изменений
Исправление sanyo1234, (текущая версия) :
И чем тогда в твоей интерпретации AOT отличается от обычной компиляции той же сишки?
AOT компилятор - это некий преобразователь кода из состояния S1 в состояние S2.
S1 - состояние кода на входе AOT компилятора.
S2 - состояние кода на выходе AOT компилятора, пригодное для запуска (обычно на bare-metal).
S1 может быть кодом в сорцах, P/byte/IL, etc.
S2 должно соответствовать рантайму, т.е. обычно native. Но например, для Angulare - это JavaScript :)
AOT provides better security. It compiles HTML components and templates into JavaScript files long before they are served into the client display. So, there are no templates to read and no risky client-side HTML or JavaScript evaluation. This will reduce the chances of injections attacks.
https://www.geeksforgeeks.org/what-is-aot-and-jit-compiler-in-angular/
Важно то, что AOT компилятор обычно работает на машине разработчика или DevOps пайплайне до запуска на возможно другой целевой машине.
Об AOT компиляторах действительно заговорили, когда стали добавлять его альтернативной к JIT компиляторам, потому что раньше для старинных Сишки, etc. AOT компилируемость подразумевалась по умолчанию, на этом не делали акцента модными словечками, потому что редко для какого ЯП была возможность генерить байт код (кстати это IMHO тоже своеобразный AOT из сорцов в P/byte код). Ну для Паскаля (не Турбо) вроде было возможно такое в теории Вирта и даже для Perl.
Из дискуссии в этой ветке вижу, что народ привык понимать AOT так, как это описано в доках IBM и других Java вендоров.
Но за пределами Java мирка AOT тоже существует, а то что OpenJ9 называет у себя AOT, другие привыкли называть JIT caching.
У Oracle кстати IMHO определения AOT в контексте GraalVM ближе к тому, что мы наблюдаем в .NET и т.п.?
Исправление sanyo1234, :
И чем тогда в твоей интерпретации AOT отличается от обычной компиляции той же сишки?
AOT компилятор - это некий преобразователь кода из состояния S1 в состояние S2.
S1 - состояние кода на входе AOT компилятора.
S2 - состояние кода на выходе AOT компилятора, пригодное для запуска (обычно на bare-metal).
S1 может быть кодом в сорцах, P/byte/IL, etc.
S2 должно соответствовать рантайму, т.е. обычно native. Но например, для Angulare - это JavaScript :)
AOT provides better security. It compiles HTML components and templates into JavaScript files long before they are served into the client display. So, there are no templates to read and no risky client-side HTML or JavaScript evaluation. This will reduce the chances of injections attacks.
https://www.geeksforgeeks.org/what-is-aot-and-jit-compiler-in-angular/
Важно то, что AOT компилятор обычно работает на машине разработчика или DevOps пайплайне до запуска на возможно другой целевой машине.
Об AOT компиляторах действительно заговорили, когда стали добавлять его альтернативной к JIT компиляторам, потому что раньше для старинных Сишки, etc. AOT компилируемость подразумевалась по умолчанию, на этом не делали акцента модными словечками, потому что редко для какого ЯП была возможность генерить байт код (кстати это IMHO тоже своеобразный AOT из сорцов в P/byte код). Ну для Паскаля (не Турбо) вроде было возможно такое в теории Вирта и даже для Perl.
Из дискуссии в этой ветке вижу, что народ привык понимать AOT так, как это описано в доках OpenJ9 и других Java вендоров.
Но за пределами Java мирка AOT тоже существует, а то что OpenJ9 называет у себя AOT, другие привыкли называть JIT caching.
У Oracle кстати IMHO определения AOT в контексте GraalVM ближе к тому, что мы наблюдаем в .NET и т.п.?
Исправление sanyo1234, :
И чем тогда в твоей интерпретации AOT отличается от обычной компиляции той же сишки?
AOT компилятор - это некий преобразователь кода из состояния S1 в состояние S2.
S1 - состояние кода на входе AOT компилятора.
S2 - состояние кода на выходе AOT компилятора, пригодное для запуска (обычно на bare-metal).
S1 может быть кодом в сорцах, P/byte/IL, etc.
S2 должно соответствовать рантайму, т.е. обычно native. Но например, для Angulare - это JavaScript :)
AOT provides better security. It compiles HTML components and templates into JavaScript files long before they are served into the client display. So, there are no templates to read and no risky client-side HTML or JavaScript evaluation. This will reduce the chances of injections attacks.
https://www.geeksforgeeks.org/what-is-aot-and-jit-compiler-in-angular/
Важно то, что AOT компилятор обычно работает на машине разработчика или DevOps пайплайне до запуска на возможно другой целевой машине.
Об AOT компиляторах действительно заговорили, когда стали добавлять его альтернативной к JIT компиляторам, потому что раньше для старинных Сишки, etc. AOT компилируемость подразумевалась по умолчанию, на этом не делали акцента модными словечками, потому что редко для какого ЯП была возможность генерить байт код (кстати это IMHO тоже своеобразный AOT из сорцов в P/byte код). Ну для Паскаля (не Турбо) вроде было возможно такое в теории Вирта и даже для Perl.
Из дискуссии в этой ветке вижу, что народ привык понимать AOT так, как это описано в доках OpenJ9 и других Java вендоров.
Но за пределами Java мирка AOT тоже существует, а то что IBM называет у себя AOT, другие привыкли называть JIT caching.
У Oracle кстати IMHO определения AOT в контексте GraalVM ближе к тому, что мы наблюдаем в .NET и т.п.?
Исходная версия sanyo1234, :
И чем тогда в твоей интерпретации AOT отличается от обычной компиляции той же сишки?
AOT компилятор - это некий преобразователь кода из состояния S1 в состояние S2.
S1 - состояние кода на входе AOT компилятора.
S2 - состояние кода на выходе AOT компилятора, пригодное для запуска (обычно на bare-metal).
S1 может быть кодом в сорцах, P/byte/IL, etc.
S2 должно соответствовать рантайму, т.е. обычно native. Но например, для Angulare - это JavaScript :)
AOT provides better security. It compiles HTML components and templates into JavaScript files long before they are served into the client display. So, there are no templates to read and no risky client-side HTML or JavaScript evaluation. This will reduce the chances of injections attacks.
https://www.geeksforgeeks.org/what-is-aot-and-jit-compiler-in-angular/
Важно то, что AOT компилятор обычно работает на машине разработчика или DevOps пайплайне до запуска на возможно другой целевой машине.
Об AOT компиляторах действительно заговорили, когда стали добавлять его альтернативной к JIT компиляторам, потому что раньше для старинных Сишки, etc. AOT компилируемость подразумевалась по умолчанию, на этом не делали акцента модными словечками, потому что редко для какого ЯП была возможность генерить байт код (кстати это IMHO тоже своеобразный AOT из сорцов в P/byte код). Ну для Паскаля (не Турбо) вроде было возможно такое в теории Вирта и даже для Perl.
Из дискуссии в этой ветке вижу, что народ привык понимать AOT так, как это описано в доках IBM и других Java вендоров.
Но за пределами Java мирка AOT тоже существует, а то что IBM называет у себя AOT, другие привыкли называть JIT caching.
У Oracle кстати IMHO определения AOT в контексте GraalVM ближе к тому, что мы наблюдаем в .NET и т.п.?