JVM internals - what does the JVM do? — Ian Rogers

[Интеррапт]

Почему подход с GC не работает? В большинстве случаев работает. И при чем здесь дядя Бил или Sun? Не хотите работать в managed environment никто вам не мешает из этих языков native код вызывать или даже просто писать свои программы на Asm, C, C++.

Опять же, оно все хорошо только на словах, а когда дело доходит до практики, то кошмар нафиг.

Когда я писал про "Asm, C, C++.", то имел ввиду именно приложения на нем, а не в качестве вызова из Java. Ес-но если речь про Андроид, то тут совсем другое дело.

JNI например в ICS поменял правила игры. Падает с ошибками, что ошибки компиляции в STL покажутся сказкой. Хорошо, что сами ошибки уникальны и легко гуглятся. Но вобще вся эта дребедень с локальным и глобальным контекстами сделана ровно для того, чтобы убить любое желание писать нативный код.

Ну вообще-то об изменениях с JNI в ICS было написано еще в ноябре собственно и если в манифесте targetSdkVersion < ICS (или вы пишите именно для ICS?), то эти изменения вас не затронут, старый код будет отлично работать. Если targetSdkVersion == ICS, то тогда да, нужно вылавливать ошибки (посредством CheckJNI). И я отлично отловил все ошибки. Не знаю, чего там гуглить особо, все это описано в официальной документации и официальном блоге.
http://developer.android.com/guide/practices/jni.html
http://android-developers.blogspot.com/ ... ckjni.html

Хотя возможно, ваш JNI код и взаимодействие c Java намного сложнее того, что у меня, так что ес-но у вас может быть больше проблем.

Ну а так да, никто не в восторге, что Гугл любит переодически чего-то ломать.

[Montchik]

а мне нравился (нынче неосуществимый) вариант управления памятью от турбопаскаля, вернее в турбовижене они его реализовали. управление памятью по сути делалось так (уж не серчайте если по памяти что напутаю). объект при инициализации эвристически заказывал сколько ему потребуется памяти, получал его в куче, и больше о памяти не беспокоился. если не хватило—прога падала. но таких неугадываний случалось _исключительно_ мало. ценой такой роскоши был некоторый перерасход памяти. но это малая цена за отсутствие головной боли с управлением памятью

А как объект отдавал память назад в кучу?

ох ну ты как спросишь

куча работала как стек, запрашиваешь память, куча "растёт", перед созданием очередной коллекции объектов отмечаешь текущее состояние кучи, создаёшь нужное количество объектов не перепроверяя доступную память, когда нужда в объектах пропадает, релизишь кучу (=все объекты одним махом). аналог пула молодых объектов в JVM но без собссно GC.

поскрипев мозгами смутно припоминаю что кажется была зона памяти если куча до неё дорастала то возникало нефатальное исключение ООМ. но только в том случае если создаваемый объект не был больше чем эта зона. если больше то каюк.

Интересно. Надо будет memory management models погуглить на досуге.

[rzen]

а мне нравился (нынче неосуществимый) вариант управления памятью от турбопаскаля, вернее в турбовижене они его реализовали. управление памятью по сути делалось так (уж не серчайте если по памяти что напутаю). объект при инициализации эвристически заказывал сколько ему потребуется памяти, получал его в куче, и больше о памяти не беспокоился. если не хватило—прога падала. но таких неугадываний случалось _исключительно_ мало. ценой такой роскоши был некоторый перерасход памяти. но это малая цена за отсутствие головной боли с управлением памятью

А как объект отдавал память назад в кучу?

ох ну ты как спросишь

куча работала как стек, запрашиваешь память, куча "растёт", перед созданием очередной коллекции объектов отмечаешь текущее состояние кучи, создаёшь нужное количество объектов не перепроверяя доступную память, когда нужда в объектах пропадает, релизишь кучу (=все объекты одним махом). аналог пула молодых объектов в JVM но без собссно GC.

поскрипев мозгами смутно припоминаю что кажется была зона памяти если куча до неё дорастала то возникало нефатальное исключение ООМ. но только в том случае если создаваемый объект не был больше чем эта зона. если больше то каюк.

Интересно. Надо будет memory management models погуглить на досуге.

в мире многозадачности и многотредности этот способ управления памятью не пригодится

но вообще да, интересно, турбопаскаль открыл много горизонтов, дорос до сишарпа, и процветает

[dotcom]

Хотя возможно, ваш JNI код и взаимодействие c Java намного сложнее того, что у меня, так что ес-но у вас может быть больше проблем.

Да нет, ничего там фантастического нет. FindClass(), GetStaticMethodId(), callback через CallVoidMethod() и манипуляции с буферами с переводом их из Си в j-классы. Ваши ссылки я нашел быстро как раз по ошибкам и гуглу из разряда "why my JNI code crashes". Я не сказал, что я правил это долго. Из блога понятно, где собака рылась. Но ломать так, как ломает Гугл, - это действительно их подход. И сам JNI весьма далек от интуитивного понимания. Зачем делать AttachThread() и почему, если результат < 0, то это fail, но работать все равно можно, потому что так говорит гугл - я не понял, но разбираться не хочу, честно говоря.

[valchkou]

турбопаскаль открыл много горизонтов, дорос до сишарпа, и процветает

Давно не слышал слово турбопаскаль, а где он процветает ?

[Интеррапт]

турбопаскаль открыл много горизонтов, дорос до сишарпа, и процветает

Давно не слышал слово турбопаскаль, а где он процветает ?

Ну из него собственно вырос Дельфи, а оттуда (обходными путями, скрестившись с Java) вырос C#.

[Flash-04]

я бы не сказал что из Delphi вырос C#, скорее некоторые идеи были заимствованы, а так был тот же C++.
Помнится Borland писал что внутрях у них один и тот же компилятор для C++/Object Pascal.

p.s. синтаксис Pascal не любил дюже...

[rzen]

ну нетушки, на ц++ турбопаскаль не был похож ни буквой ни духом. то что внутри (взоможно, я уже не помню) был один и тот же компилятор это ничего не значит.

[Dmitry67]

турбопаскаль открыл много горизонтов, дорос до сишарпа, и процветает

Давно не слышал слово турбопаскаль, а где он процветает ?

Процветает, процветает...

[rzen]

подправьте ссылку, а то вашу остроумную картинку не видно:

[Flying Hen]

Т.е., по вашему, вот такой код должен exception выкидывать?

Code: Select all

String s1 = new String("hello world");
String s = s1;
delete s1;

Ну хорошо, не надо exception. Смысл в том, чтобы дать возможность девелоперу возвратить память сразу explicitly. Разработчики Жабы самые упертые в этом смысле, ни малейших уступок никому.

[Flash-04]

ну нетушки, на ц++ турбопаскаль не был похож ни буквой ни духом. то что внутри (взоможно, я уже не помню) был один и тот же компилятор это ничего не значит.

как это? я писал и на C++ и на Delphi/Object Pascal, не заметил какой-то жутко принципиальной разницы Даже указатели при желании были, хотя была уже видна тенденция использовать референсы. Но это и в C++ было.

[rzen]

Т.е., по вашему, вот такой код должен exception выкидывать?

Code: Select all

String s1 = new String("hello world");
String s = s1;
delete s1;

Ну хорошо, не надо exception. Смысл в том, чтобы дать возможность девелоперу возвратить память сразу explicitly. Разработчики Жабы самые упертые в этом смысле, ни малейших уступок никому.

как это сделать не создавая при этом бОльших проблем?

[rzen]

ну нетушки, на ц++ турбопаскаль не был похож ни буквой ни духом. то что внутри (взоможно, я уже не помню) был один и тот же компилятор это ничего не значит.

как это? я писал и на C++ и на Delphi/Object Pascal, не заметил какой-то жутко принципиальной разницы Даже указатели при желании были, хотя была уже видна тенденция использовать референсы. Но это и в C++ было.

в дельфи есть множественное наследование? Шаблоны?

[Flash-04]

хм... тут вы конечно правы. Он несколько Java в этом плане напоминает. Нет шаблонов, нет множественного наследования, есть интерфейсы.
Видимо я это подзабыл, т.к. активно эти фичи не использовал.

[rzen]

угу. и самое главное у турбопаскаля и си++ были совершенно разные философии. турбопаскаль бережнее относился к программисту. си++ и тогда и сейчас предполагает что программист это суровый сибиряк с небритостью и бензопилой в кармане

[dotcom]

я бы не сказал что из Delphi вырос C#, скорее некоторые идеи были заимствованы, а так был тот же C++.
Помнится Borland писал что внутрях у них один и тот же компилятор для C++/Object Pascal.

Компиляторы как раз разные были. C++ компилятор Борланд вобще купил у кого-то. А вот библиотеки действительно были одинаковые.

[Flash-04]

хм... я наверное сейчас не найду быстро, но помнится именно у Borland-а это было написано что у них единый компилятор для C++ и Delphi. Если не изменяет память C++ 5.0 и Delphi 3.0

[vaduz]

я бы не сказал что из Delphi вырос C#, скорее некоторые идеи были заимствованы...

На самом деле, Microsoft позаимствовал создателя Delphi, Anders'a Hejlsberg'a.
Он и был главным архитектором C#.

Хотя идею RAD + Visual programming AH позаимствовал у MS Visual Basic 1.0

[rzen]

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

[Flash-04]

я не про Turbo Pascal, а про Delphi/Object Pascal. Это совершенно разные вещи как и Turbo C и Borland C++.

[Flash-04]

На самом деле, Microsoft позаимствовал создателя Delphi, Anders'a Hejlsberg'a.
Он и был главным архитектором C#.

ага, они тогда многих сманили и ещё помню народ писал что в IDE Visual C++ стали быстро появляться фичи из Delphi

[rzen]

аа, про дельфи ничего не скажу, я к тому времени перешел на другие продукты и назад уже не оглядывался.

[dotcom]

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

Не знаю, где вы там разности нашли. Стандартная библиотка от C - понятно, уникальна. А борландовые либы, Turbo Vision, OWL и потом особенно VCL были унифицированы. Вплоть до того, что сишный код шел к библиотекам через PASCAL call convention.
Компиляторы разные, да и как можно унифицировать их, если Паскаль - это однопроходный транслятор с уникальным парсером, а C++ - многопроходный, в лучшем случае двухпроходный? Про историю Turbo C сказано следующее:

The software was, like many Borland products of the time, bought from another company and branded with the "Turbo" name, in this case Wizard C by Bob Jervis[1]

Возможно они что-то в компиляторах впоследствии и унифицировали - не знаю.

[dotcom]

Кстати, а Turbo Pascal'е. Среди присутствующих есть кто-нибудь, кто пытался работать с Boostrap'ом?