Комментарии 14
когда я вижу слово «андройд» (через «й»), моя рука самопроизвольно тянется к пистолету
+8
хм… а разве JIT-компилятор Дальвика не должен бы скомпилировать рассмотренную dex-функцию в аналогичный набор arm-инстркукций?
если вы это с целью оптимизации производительности, то — замеры в студию! очень любопытно
если вы это с целью оптимизации производительности, то — замеры в студию! очень любопытно
+3
Нет, не с целью производительности. Для производительности врятли нужно разбирать инструкции и анализировать код, так как сделано в статье. Там нужно просто сделать замеры. Сам же хотел просто разобраться где что лежит, чтобы если захочу вернусь попозже.
Про JIT компиляцию сходу и не скажу, на деле — да оно должно преобразоваться в аналогичный набор, но не проверял. По наитию кажется, что JIT должен быть пристройкой к уже существующему варианту, но на тот момент не было интересно и очень, очень не хотел запутяться еще и в JIT.
Про JIT компиляцию сходу и не скажу, на деле — да оно должно преобразоваться в аналогичный набор, но не проверял. По наитию кажется, что JIT должен быть пристройкой к уже существующему варианту, но на тот момент не было интересно и очень, очень не хотел запутяться еще и в JIT.
+4
Из моего опыта работы над реализации Джава машины — JIT существенно отличается от интерпретатора тем, что подставляет сразу вычисленое значение адреса нативной функции в генерируемый код, если функция не виртуальная (private, static). Вся логика определения calling convention, адреса функции делается один раз и генерирутся нужный вариант. В случае не-нативной функции, без виртуальности — вызов может заменен на подстановку кода вызываемой функции, если она не большая. С виртуальной функцией всё сложнее, особенно нативной.
+1
хабр торт!
+9
Отличная статья, спасибо.
+3
А не смотрели в сторону JNA — Java Native Access. Возможно ли использовать на андроиде его? И если да, до каковы потери по производительности по сравнению с обычным JNI?
+1
Вам крайне повезло, этот вопрос есть в 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 не так важен.
+1
Очень классная статья, спасибо
0
'thiz' rulez!
0
Нет слов. Охуенная статья. Спасибо.
+2
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Насколько крепка дружба между Java и С внутри Dalvik VM?