BEA создает Java-процессор

http://www.zdnet.ru/?ID=493841

ЗАЧЕМ?

А что, нельзя?

>ЗАЧЕМ?
Могу лишь предположить, что если на сервере компания держит только Application Server, то впринципе, от операционной системы ей нужно только управление сокетами, жеским диском(кстати может эта железка все в памяти держит), и т.д.
Нужно все это для увиличения производительности, хотя по моему опыту текущей производительности достаточно текущей jvm от SUN достаточно.

Вот примеры:
cайты монстров:
www.sony.com
www.hp.com
www.sun.com
www.adobe.com
www.oracle.com

отечесвенных сайтов с большой посещаемостью
www.job.ru
www.i2i.ru
www.ntv.ru
www.govoritmoskva.ru
и известный вам linux.org.ru

всем им хватает производительости.

> всем им хватает производительости.

возможно, это будет позиционироваться, как embedded решение.

Вообще, все новое - хорошо забытое старое. Процессор MAJIK, вроде, делала Sun. IBM ускоряла Java в AS/400 за счет найтивной трансляции байт-кода, наверняка есть еще приложения...

Чёто непонял, в каком месте ОС тормозит? ИМХО без отказа от многозадачности никакого выигрыша в производительности от такого неможет бысть.

Блин? постеднее время столько замечательных новостей!!!

Например, есть такая штука называется MHP (Multimedia Home Platform) - это когда Ява-Апплеты по DVB в ресивер передаются. А ресивер их должен исполнить, если в него нормальную JVM запихать - то дороговатый ресивер выйдет, т.к. Ява ресурсы любит.

Напомините, плиз, разве сановский процессор PicoJava не для этого делался?

А есть "открытый" процессор %) http://www.jopdesign.com

Всё таки ... JVM проигрывает DIS :)

>Напомините, плиз, разве сановский процессор PicoJava не для этого делался?

По ссылке "Подробности" в тексте новости как раз об этом и говорится. Sun не Microsoft, он не обязан хвататься за все подряд и бросать на половину недоделанное. Не получилось у Sun пропеарить PicoJava, получится у BEA. Пусть Sun лучше занимается прямыми обязанностями - увеличивает отрыв Java от .NET

Тормозящая прослойка - это прослойка между стулом и клавиатурой, которая безуспешно пытается делать бизнес на всяком бобовом фуфле. Сколько можно? Уже и не смешно обсуждать эту жабу, пора делом заниматься!

Еще один глюкавый форк джавы, для которого говорун-титиретик Луговский будет умозрительно писать "кучу" "функциональных и околофункциональных язычков" с "длинными методами" и подхвостовым "замыканием". :)

Аппаратная Жаба имеет место быть в моем мобильнике, где она действительно нужна. А так, уже проходили "шыбко швыдкую", но глюкавую бимерскую Жабу.

А при чем здесь процессор?

Я думаю, что такая железка может использоваться как некий Java-сопроцессор - добавка для центрального :)
Будет ускорять выполнение Java-кода ;)
Того, который JIT не перекодил в нативный :)

> Того, который JIT не перекодил в нативный

!!!

> Я думаю,

Для того, чтобы "думать", надо, как минимум иметь мозги. Судя по вашему познанию JIT компиляторов, к вам это не относится.

>Аппаратная Жаба имеет место быть в моем мобильнике, где она действительно нужна.

А что, она там правда аппаратная? Не банальный интерпретатор? Вроде когда-то делали Java процессор, потом это оказалось невыгодным.

>Будет ускорять выполнение Java-кода ;) >Того, который JIT не перекодил в нативный :)

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

"Java-велосипед" с пятью колёсами.

...будут кроссплатформенные дрова писать на java... красотища!

JRockit - не железка. это реализация JVM, на мой вкус довольно кривая. речь о том, что она будет исполняться на голом железе, хотя что это может ускорить - хоть убей не пойму. аналогичные замыслы когда-то были у оракла относительно своего сервера (в преддверии выхода восьмерки эллисон гордо объявлял об отказе от поддержки win nt), но вроде как не осуществились.

"Это полезный способ обеспечения портативности программ, однако ради этой пользы приходится жертвовать производительностью."

Так Жаба всё таки тормозит!!!

>...хотя что это может ускорить - хоть убей не пойму.

Ну, ну если совсем по тупому подходить, то освобождение памяти от ненужных кусков OS несомненно работу ускорить может. :) Ну или быстрые нити, одно адресное пространство на все, и.т.д.

Вы правы. Именно банальный тупой KVM интерпретатор бинарного кода для процессора ARM (SimbianOS ?) сделанного трудолюбивыми корейцами из фирмы "Сам-СоН". PicoJava - это мечты-мечты...

Твой вкус тебя подводит.

> Много стековых операций будет.

ЕМНИС, на этот счет Sun пиарил архитектурную фичу под названием "Instruction Folding", она же (ИМХО) была предложена еще в 70-е годы под названием (примерно) "процессор с изменяемой адресностью команд" Н.П. Брусенцовым (тем самым, который сделал "Сетунь").

--

SVK

Причем неизменно :) Но это сугубо личный опыт на конкретной задаче, которая была именно что спасена выбрасыванием JRockit и переходом на Sun JVM. В общем случае вкусностей у JRockit действительно много.