Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 14
когда я вижу слово «андройд» (через «й»), моя рука самопроизвольно тянется к пистолету
хм… а разве JIT-компилятор Дальвика не должен бы скомпилировать рассмотренную dex-функцию в аналогичный набор arm-инстркукций?
если вы это с целью оптимизации производительности, то — замеры в студию! очень любопытно
если вы это с целью оптимизации производительности, то — замеры в студию! очень любопытно
Нет, не с целью производительности. Для производительности врятли нужно разбирать инструкции и анализировать код, так как сделано в статье. Там нужно просто сделать замеры. Сам же хотел просто разобраться где что лежит, чтобы если захочу вернусь попозже.
Про JIT компиляцию сходу и не скажу, на деле — да оно должно преобразоваться в аналогичный набор, но не проверял. По наитию кажется, что JIT должен быть пристройкой к уже существующему варианту, но на тот момент не было интересно и очень, очень не хотел запутяться еще и в JIT.
Про JIT компиляцию сходу и не скажу, на деле — да оно должно преобразоваться в аналогичный набор, но не проверял. По наитию кажется, что JIT должен быть пристройкой к уже существующему варианту, но на тот момент не было интересно и очень, очень не хотел запутяться еще и в JIT.
Из моего опыта работы над реализации Джава машины — JIT существенно отличается от интерпретатора тем, что подставляет сразу вычисленое значение адреса нативной функции в генерируемый код, если функция не виртуальная (private, static). Вся логика определения calling convention, адреса функции делается один раз и генерирутся нужный вариант. В случае не-нативной функции, без виртуальности — вызов может заменен на подстановку кода вызываемой функции, если она не большая. С виртуальной функцией всё сложнее, особенно нативной.
хабр торт!
Отличная статья, спасибо.
А не смотрели в сторону JNA — Java Native Access. Возможно ли использовать на андроиде его? И если да, до каковы потери по производительности по сравнению с обычным JNI?
Вам крайне повезло, этот вопрос есть в JNA FAQ (самый последний). :)
И при этом эта цитата не относится к андройду.
Если честно, где-то слышал, но только сейчас посмотрел информацию по JNA. По тем ссылкам, которые нашел, даже если и есть JNA для андроида, то в функциях через JNA есть какой-то довесок (overhead). Т.е. если в данный момент выбирать между JNA или JNI, то лучше работающий и прямой (понятный) JNI.
Но если вам не нужно часто вызывать функцию, то overhead не так важен.
The calling overhead for a single native call using JNA interface mapping can be an order of magnitude (~10X) greater time than equivalent custom JNI (whether it actually does in the context of your application is a different question).
И при этом эта цитата не относится к андройду.
Если честно, где-то слышал, но только сейчас посмотрел информацию по JNA. По тем ссылкам, которые нашел, даже если и есть JNA для андроида, то в функциях через JNA есть какой-то довесок (overhead). Т.е. если в данный момент выбирать между JNA или JNI, то лучше работающий и прямой (понятный) JNI.
Но если вам не нужно часто вызывать функцию, то overhead не так важен.
Очень классная статья, спасибо
'thiz' rulez!
Нет слов. Охуенная статья. Спасибо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Насколько крепка дружба между Java и С внутри Dalvik VM?