A
Сильно зависит от того что написали, вплоть до полного его отключения
в смысле отключения?
Size: a a a
2019 June 24
VM
в смысле отключения?
В прямом. Java может без gc работать, памятью только надо ручками управлять тогда
VM
при этом у них куча кода на с++.
У них на всем куча кода, каждый большой сервис это сотни микросервисов на большом множестве языков
A
В прямом. Java может без gc работать, памятью только надо ручками управлять тогда
не встречал, чтобы кто-то так реально делал. если уж это понадобилось, то кажется пора на с++
VM
не встречал, чтобы кто-то так реально делал. если уж это понадобилось, то кажется пора на с++
Перечитай что выше написано. С и его производные сильно медленнее в разработке и в поиске инженеров, соответственно пока можно этого избежать ПМ и ко пытаются обходится без этого.
A
В прямом. Java может без gc работать, памятью только надо ручками управлять тогда
это точно возможно? кажется sun jvm не может так.
там же вроде в языке деструкторов даже нет, как памятью управлять?
там же вроде в языке деструкторов даже нет, как памятью управлять?
VM
это точно возможно? кажется sun jvm не может так.
там же вроде в языке деструкторов даже нет, как памятью управлять?
там же вроде в языке деструкторов даже нет, как памятью управлять?
Первая ссылка в Гугле http://www.coralblocks.com/index.php/java-development-without-gc/
A
Первая ссылка в Гугле http://www.coralblocks.com/index.php/java-development-without-gc/
"it is impossible to turn off the GC"
МК
можно выключить GC (условно), можно выключить и реально, можно аллоцировать память вне хипа
A
можно выключить GC (условно), можно выключить и реально, можно аллоцировать память вне хипа
как создать объект в памяти стека в java?
МК
как создать объект в памяти стека в java?
так создать на стеке или вне хипа ?
F
как создать объект в памяти стека в java?
The strategy here is that instead of leaking this decision into the language, Java lets the JVM/Hotspot/JIT/runtime decide where and how it wants to allocate memory.
There is research going on to use "escape analysis" to figure out what objects don't actually need to go onto the heap and stack-allocate them instead. I am not sure if this has made it into a mainstrem JVM already. But if it does, it will be controlled by the runtime (thing -XX:something), not the developer.
The upside of this is that even old code can benefit from these future enhancements without itself being updated.
If you like to manually manage this (but still have the compiler check that it stays "safe"), take a look at Rust.
There is research going on to use "escape analysis" to figure out what objects don't actually need to go onto the heap and stack-allocate them instead. I am not sure if this has made it into a mainstrem JVM already. But if it does, it will be controlled by the runtime (thing -XX:something), not the developer.
The upside of this is that even old code can benefit from these future enhancements without itself being updated.
If you like to manually manage this (but still have the compiler check that it stays "safe"), take a look at Rust.
A
так создать на стеке или вне хипа ?
а где еще вне хипа, если не стек?
МК
The strategy here is that instead of leaking this decision into the language, Java lets the JVM/Hotspot/JIT/runtime decide where and how it wants to allocate memory.
There is research going on to use "escape analysis" to figure out what objects don't actually need to go onto the heap and stack-allocate them instead. I am not sure if this has made it into a mainstrem JVM already. But if it does, it will be controlled by the runtime (thing -XX:something), not the developer.
The upside of this is that even old code can benefit from these future enhancements without itself being updated.
If you like to manually manage this (but still have the compiler check that it stays "safe"), take a look at Rust.
There is research going on to use "escape analysis" to figure out what objects don't actually need to go onto the heap and stack-allocate them instead. I am not sure if this has made it into a mainstrem JVM already. But if it does, it will be controlled by the runtime (thing -XX:something), not the developer.
The upside of this is that even old code can benefit from these future enhancements without itself being updated.
If you like to manually manage this (but still have the compiler check that it stays "safe"), take a look at Rust.
тока термин все же Scalar Replacement
МК
а где еще вне хипа, если не стек?
в оперативе?
F
тока термин все же Scalar Replacement
Скопировал с SO :)
A
в оперативе?
м? куча там и находится
МК
malloc где память выделает?