m039 15 авг 2011 в 18:27

Насколько крепка дружба между Java и С внутри Dalvik VM?

20 мин

7.2K

Разработка под Android*

Из песочницы

+108

Комментарии 14

bachin 15 авг 2011 в 18:55

когда я вижу слово «андройд» (через «й»), моя рука самопроизвольно тянется к пистолету

m039 15 авг 2011 в 18:58

Спасибо, исправил. Только вы не говорите не кому, а то кто-нибудь может вас убить. ;)

m039 15 авг 2011 в 18:59

«никому», ай, самому бы не застрелиться)

asfd 18 авг 2011 в 01:43

нйкому

kosiakk 15 авг 2011 в 19:45

хм… а разве JIT-компилятор Дальвика не должен бы скомпилировать рассмотренную dex-функцию в аналогичный набор arm-инстркукций?

если вы это с целью оптимизации производительности, то — замеры в студию! очень любопытно

m039 15 авг 2011 в 20:02

Нет, не с целью производительности. Для производительности врятли нужно разбирать инструкции и анализировать код, так как сделано в статье. Там нужно просто сделать замеры. Сам же хотел просто разобраться где что лежит, чтобы если захочу вернусь попозже.

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

ivanrt 17 авг 2011 в 08:59

Из моего опыта работы над реализации Джава машины — JIT существенно отличается от интерпретатора тем, что подставляет сразу вычисленое значение адреса нативной функции в генерируемый код, если функция не виртуальная (private, static). Вся логика определения calling convention, адреса функции делается один раз и генерирутся нужный вариант. В случае не-нативной функции, без виртуальности — вызов может заменен на подстановку кода вызываемой функции, если она не большая. С виртуальной функцией всё сложнее, особенно нативной.

Lashezzz 15 авг 2011 в 20:34

хабр торт!

samlabs821 16 авг 2011 в 01:47

Отличная статья, спасибо.

alist 16 авг 2011 в 12:15

А не смотрели в сторону JNA — Java Native Access. Возможно ли использовать на андроиде его? И если да, до каковы потери по производительности по сравнению с обычным JNI?

m039 16 авг 2011 в 12:39

Вам крайне повезло, этот вопрос есть в JNA FAQ (самый последний). :)

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 не так важен.