ru_java, posts by tag: jvm - LiveJournal (original) (raw)
March 17th, 2012
зимой в голову пришла идея написать транслятор из JVM байт кода в команды Z80, спайк показал что дело реальное. В свободное время довел до работающего состояния и оформил как maven plugin, выложил в общий доступ как опенсорсный проект (код сильно не вылизывался). Проект находится по ссылке http://code.google.com/p/j2z80/
это не виртуальная машина, JVM байткод просто транслируется в команды Z80, pattern compiler можно сказать. Из типов данных убраны long, float, double, а int стал 16 битным, char же перешел на 8 битную ширину. Понятно что эта вещь не позволяет юзать обычные Java программы на Z80, но в целом позволяет при каких то разработках задействовать Java toolchain
September 13th, 2010
Началось всё с того, что пред-продакшн сервер выдал нам "too many open files". Выдалось это после второй попытки пропатчить наше мега-приложение. Мега-приложение грузится своим деплойером, расширяющим SubDeployerSupport, поэтому все силы были брошены сначала на него...
Но в процессе борьбы выяснилось, что в /proc лежит множество линков вида:
server/default/tmp/deploy/tmp1536561351976467536qwe.sar (deleted)
Собсна, после нескольких редеплойментов приложения мы и получали указаную выше ошибку.
По мотивам был найден следующий пост: http://management-platform.blogspot.com/2009/01/classloaders-keeping-jar-files-open.html
Оказалось, что JarFile не закрывает открытые потоки!!! Это было откровением...
Вроде как понятен стал метод борьбы (указан в посте), но он почему-то не сработал для JBoss. Как минимум, мне нужно каким-то хитрым образом запихать свой класс-лоадер заместо URLClassLoader. Но там всё-равно ещё остаются открытые дескрипторы, которые я выловил указаной в посте хитрой утилитой http://blogs.sun.com/roller/resources/quinn/ZipFileMonitor.jar
Кто-нибудь сталкивался с такой проблемой? Как решали?
Может быть можно запатчить саму Java-машину? http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4167874 Вроде бы баг пофикшен для 7-й версии...