Как бы вы улучшили Dalvik? Виртуальная машина Android - PullRequest
17 голосов
/ 21 июня 2009

Я сейчас пишу статью на платформе Android. После некоторых исследований стало ясно, что у Далвика есть возможности для совершенствования. Мне было интересно, что, по вашему мнению, будет наилучшим использованием времени разработчика с этой целью?

JIT-компиляция кажется большой, но потом я также услышал, что она будет иметь ограниченное применение на таком ресурсоемком компьютере. У кого-нибудь есть ресурс или данные, подтверждающие это?

Есть ли другие варианты, которые следует рассмотреть? Помимо разработки надежного собственного комплекта разработки для обхода виртуальной машины.

Для тех, кто заинтересован, есть записанная и размещенная в Интернете лекция о Dalvik VM .

Любые мысли приветствуются, так как этот вопрос представляется субъективным Я поясню, что ответ, который я приму, должен иметь некоторое обоснование для предлагаемых изменений. Любые данные, подтверждающие это, такие как улучшение Sun JVM, когда она была представлена, были бы огромным плюсом.

Ответы [ 3 ]

18 голосов
/ 21 июня 2009
  1. Лучшая сборка мусора: минимальное сжатие (для устранения проблем с фрагментацией памяти, с которыми мы сталкиваемся сегодня), в идеале менее ресурсоемкая при выполнении самой сборки (для уменьшения количества жалоб на "частоту кадров в моей игре")
  2. JIT, как вы цитируете
  3. Достаточно документации, что в сочетании с NDK кто-то достаточно сумасшедший может скомпилировать байт-код Dalvik в собственный код для опции компиляции AOT
  4. Сделайте его отделимым от самого Android, чтобы другие проекты могли поэкспериментировать с ним, и вклады сообщества могли бы поступить в большем количестве и более быстрым клипом

Я уверен, что мог бы придумать другие идеи, если они вам понадобятся.

3 голосов
/ 24 июня 2009
  1. JIT. То, что это не помогает, - куча дерьма. Вы можете быть более разборчивы в отношении того, какой код JIT вы используете, но производительность на 1/10-й производительности собственного кода всегда будет ограничивать

  2. Достойный GC. У современных сборщиков мусора нет больших заиканий.

  3. Лучший анализ кода. Есть много случаев, когда распределение / освобождение не требуется, блокировки удерживаются и так далее. Это позволяет вам писать чистый код, а не выполнять оптимизацию, чтобы машина лучше справлялась с

Теоретически большинство языков более высокого уровня (Java, Javascript, python, ...) должны в большинстве случаев находиться в пределах 20% от производительности нативного кода. Но это требует от разработчика платформы потратить 100 с лишним человеко-лет. Sun Java становится все лучше. Они также работают над этим в течение 10 лет.

0 голосов
/ 21 июня 2009

Одна из основных проблем с Dalvik - производительность, которую я слышал ужасно, но мне больше всего хотелось бы добавить больше языков.

В JVM были проекты сообщества, позволяющие запускать Python и Ruby на платформе, и даже специальные языки, такие как Scala, Groovy и Closure, были разработаны для него. Было бы неплохо увидеть их (и / или других) на платформе Dalvik. Sun также работает над машиной Da Vinci, динамическим расширением набора текста JVM, что указывает на серьезный отход от философии «один язык подходит всем», которой придерживалась Sun в течение последних 15 лет.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...