Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>2. JVM не позволяет взять адрес локальной переменной, отсюда имеем невозможность передачи параметра по ссылке. (~ ref параметр в C#).
Да, это серьезный -.
LCR>6. Не поддерживается перегрузка по типу возвращаемого значения.
А где она поддерживается ?
LCR>8. Не поддерживается хвостовая рекурсия.
Что значит не поддерживается? Ведь компилятор-то ее может развернуть (как делает компилятор Scala, например).
LCR>9. Тяжёлые потоки.
По-моему это зависит от реализации. Раньше в JVM вроде были green threads, но потом от них отказались.
LCR>10. Некоторый байткод не может быть скомпилирован JITом. В частности если функция превышает некоторый предел, то JIT не будет её компилировать (и этот порог достаточно низок).
В смысле? Он вообще вылетит с исключением или будет интерпретировать .
LCR>11. Нет быстрых замыканий.
А что такое быстрое замыкание? Без аллокации снимка локальных переменных для делегата в куче?
LCR>12. Не умеет вышивать крестиком.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Совмещение разных объектных моделей на одном фреймвор
Андрей Хропов,
LCR>>6. Не поддерживается перегрузка по типу возвращаемого значения. АХ>А где она поддерживается ?
AndrewVK утверждает, что в CLR. Представь себе, да?
LCR>>8. Не поддерживается хвостовая рекурсия. АХ>Что значит не поддерживается? Ведь компилятор-то ее может развернуть (как делает компилятор Scala, например).
В Эрланге поддержка хвостовой рекурсии прямо в виртуальной машине. Есть специальная инструкция: enterlocal. Так несколько эффективнее, чем если это будет делать байткод.
LCR>>9. Тяжёлые потоки. АХ>По-моему это зависит от реализации. Раньше в JVM вроде были green threads, но потом от них отказались.
Подозреваю, что crossplatform issues.
LCR>>10. Некоторый байткод не может быть скомпилирован JITом. В частности если функция превышает некоторый предел, то JIT не будет её компилировать (и этот порог достаточно низок). АХ>В смысле? Он вообще вылетит с исключением или будет интерпретировать .
По умолчанию, если метод превышает что-то порядка 250 инструкций, то будет интерпретироваться. К счастью, в последних версиях hotspot настраивается:
-XX:MaxInlineSize=<size>
Integer specifying maximum number of bytecode instructions in a method which gets inlined.
-XX:FreqInlineSize=<size>
Integer specifying maximum number of bytecode instructions in a frequently executed method which gets inlined.
LCR>>11. Нет быстрых замыканий. АХ>А что такое быстрое замыкание? Без аллокации снимка локальных переменных для делегата в куче?
Да. Эмуляция замыкания в виде объекта — не очень дёшево. И если захочешь сделать ленивые вычисления — отгребёшь по полной программе.
LCR>>12. Не умеет вышивать крестиком. АХ>
Хе-хе. Это я к тому, что перечислять, чего машина не может, можно бесконечно. Даже возможности процессоров ограничены, а виртуальных машин — и подавно.
Lazy Cjow Rhrr wrote: > По умолчанию, если метод превышает что-то порядка 250 инструкций, то > будет интерпретироваться. К счастью, в последних версиях hotspot > настраивается: > -XX:MaxInlineSize=<size> Integer specifying maximum number of bytecode > instructions in a method which gets inlined. -XX:FreqInlineSize=<size> > Integer specifying maximum number of bytecode instructions in a > frequently executed method which gets inlined.
А прочитать????
Тут говорится про inlining, а не HotSpot-компиляцию!
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[4]: Совмещение разных объектных моделей на одном фреймвор
LCR>В Эрланге поддержка хвостовой рекурсии прямо в виртуальной машине. Есть специальная инструкция: enterlocal.
Поправочка. enterlocal — это вызов функции внутри того-же самого модуля (в противоположность вызову из другого модуля). Если это последняя инструкция в функции, то VM переиспользует фрейм. А компилятор Эрланга если может, оптимизирует функции к хвостовым. Вроде так.
Теперь смотрю очень внимательно. Вижу только
[code]
-XX:CompileThreshold=10000
number of method invocations/branches before
(re-)compiling [10,000 -server, 1,500 -client]
[code]
Больше ничего такого про компиляцию — параметр ненастраиваемый.
Lazy Cjow Rhrr wrote: > C>Тут говорится про inlining, а не HotSpot-компиляцию! > http://java.sun.com/docs/hotspot/VMOptions.html
Еще раз: ты путаешь inlining (непосредственное включение метода в код
вызываемой функции для избежания расходов на вызов функции) и
HotSpot-компиляцию (перевод байт-кодов в машинные по результатам
профилирования).
Проверить, что функции больше 256 байт-кодовых операций вполне нормально
JIT-компилируются, я думаю, ты сможешь и сам.
> Теперь смотрю очень внимательно. Вижу только > [code] > -XX:CompileThreshold=10000 > number of method invocations/branches before > (re-)compiling [10,000 -server, 1,500 -client] > [code] > Больше ничего такого про компиляцию — параметр ненастраиваемый.
Ну еще бы — в .NET ты JITтер тоже особо много непонастраиваешь.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[4]: Совмещение разных объектных моделей на одном фреймвор
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Андрей Хропов,
LCR>>>6. Не поддерживается перегрузка по типу возвращаемого значения. АХ>>А где она поддерживается ? LCR>AndrewVK утверждает, что в CLR. Представь себе, да?
Changing the return type of a method does not make the method unique as stated in the common language runtime specification. You cannot define overloads that vary only by return type.
LCR>>>11. Нет быстрых замыканий. АХ>>А что такое быстрое замыкание? Без аллокации снимка локальных переменных для делегата в куче? LCR>Да. Эмуляция замыкания в виде объекта — не очень дёшево. И если захочешь сделать ленивые вычисления — отгребёшь по полной программе.
Да, вроде компилятор OCaml славится тем что он как раз умеет вычислять когда не надо делать отдельную аллокацию.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Совмещение разных объектных моделей на одном фреймвор
We have noticed that the current JIT compilers use a
compilation threshold. In particular, we have experimen-
tally found out that Sun's HotSpot stops compiling func-
tions for which the body is larger than 8000 JVM bytecode
instructions.
LCR>Поправочка. enterlocal — это вызов функции внутри того-же самого модуля (в противоположность вызову из другого модуля). Если это последняя инструкция в функции, то VM переиспользует фрейм.
В MSIL похожий префикс .tail есть для call-instructions:
Tail calls are similar to method jumps (jmp) in the sense that both lead to abandoning the current method, discarding its stack frame, and passing the arguments to the tail-called (jumped-at) method. However, because the arguments of a tail call have to be loaded on the evaluation stack explicitly, a tail call—unlike a jump—does not require the entire signature of the called method to match the signature of the calling method; only the return types must be the same or compatible. In short, a jump is the equivalent of loading all the current method’s arguments on the stack and invoking a tail call.
...
tail. (0xFE 0x14) Mark the following call instruction as a tail call. This instruction has no parameters and does not work with the stack. In ILAsm, this instruction—like the other prefix instructions unaligned. and volatile., discussed earlier—must be separated from the call instruction that follows it by at least a space symbol.
The difference between a jump and a tail call is that the tail call instruction pair is verifiable in principle, subject to the verifiability of the call arguments, as long as it is immediately followed by the ret instruction. As is the case with other prefix instructions, it is illegal to bypass the prefix and branch directly to the prefixed instruction, in this case, call, callvirt, or calli.
Кстати, вообще предел JVM для метода — это 65536 инструкций.
Единственный раз мне это доставило проблем, когда скомпилированый в
Java-код XSLT-преобразователь получился слишком большим.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[8]: Совмещение разных объектных моделей на одном фреймвор
Cyberax,
>> Каменты? C>Я бы не назвал это "маленьким методом" На практике такие монстры C>будут встречаться разве что при машииной генерации.
Ага, компиляторы этим и занимаются. Если используется CPS, то такие мегаметоды будут появляться за нефиг делать...
C>Кстати, вообще предел JVM для метода — это 65536 инструкций. C>Единственный раз мне это доставило проблем, когда скомпилированый в C>Java-код XSLT-преобразователь получился слишком большим.
А что выдаёт? Ошибку при компиляции — типа "метод ххх слишком большой, разбейте на несколько"?
Lazy Cjow Rhrr wrote: >> > Каменты? > C>Я бы не назвал это "маленьким методом" На практике такие монстры > C>будут встречаться разве что при машииной генерации. > Ага, компиляторы этим и занимаются. Если используется CPS, то такие > мегаметоды будут появляться за нефиг делать...
Ну так компилятор — он железный, может и на несколько методов разбить.
> C>Кстати, вообще предел JVM для метода — это 65536 инструкций. > C>Единственный раз мне это доставило проблем, когда скомпилированый в > C>Java-код XSLT-преобразователь получился слишком большим. > А что выдаёт? Ошибку при компиляции — типа "метод ххх слишком большой, > разбейте на несколько"?
Там хуже было — сразу формировался байт-код, который при загрузке
выдавал Error. Долго тогда разбирался из-за чего — решилось апгрейдом на
более новую версию компилятора XSLT.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[9]: Совмещение разных объектных моделей на одном фреймвор
Андрей,
LCR>>AndrewVK утверждает, что в CLR. Представь себе, да?
АХ>В MSDN пишут, что нет:
АХ>
АХ>Changing the return type of a method does not make the method unique as stated in the common language runtime specification. You cannot define overloads that vary only by return type.
Возможно MSDN имело ввиду требования к языкам, чтобы быть CLR-совместимыми?
Lazy Cjow Rhrr wrote: > C>Кстати, сам Performance Study тоже весьма древний. Современные JVM > C>оптимизирую значительно лучше (switch точно стал константное время > C>работать — как-то тестировал). > Там не говорилось, что тормозит именно та, которую ты гонял (sun jvm?) > However, we found that *some JITs* are unable to produce code with a > constant complexity for the tableswitch instruction
Ну... После того, как Sun выпустил JDK под GPL, можно считать, что особо
другие JVM и не нужны (кроме встроеных устройств, разве что).
> На мой взгляд, 2002-й год, вполне современная статья. Тем более учитывая > черепашью скорость развития JVM.
5 лет и 3 версии JDK прошло, однако.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[11]: Совмещение разных объектных моделей на одном фреймво
Cyberax,
C>Ну... После того, как Sun выпустил JDK под GPL, можно считать, что особо C>другие JVM и не нужны (кроме встроеных устройств, разве что).
Да. И там будет применяться LLVM
>> На мой взгляд, 2002-й год, вполне современная статья. Тем более учитывая >> черепашью скорость развития JVM. C>5 лет и 3 версии JDK прошло, однако.
А ты считаешь с 1-го января 2002-го года, или с 31-го декабря?
Ладно, пусть будет статья старовата. Ок. Но я ничего лучше пока не видел. Есть варианты?
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Возможно MSDN имело ввиду требования к языкам, чтобы быть CLR-совместимыми?
Да, естественно. В своем языке можешь что угодно делать. Но я что-то не встречал языков где это можно. Может кто более образованный знает .
?
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
.