5 ms·

Java isn't as performant as C++. BTW, how do you implement a garbage collector with a garbage-collected language?

by maxloh 4y ago

chrisseaton 4y ago
> BTW, how do you implement a garbage collector with a garbage-collected language? You write it carefully so the garbage collector itself doesn't also need to allocate objects. Here's a GC for Java written in Java https://github.com/oracle/graal/tree/master/substratevm/src/com.oracle.svm.core.genscavenge/src/com/oracle/svm/core/genscavenge https://github.com/oracle/graal/tree/master/substratevm/src/....
- quelltext 4y ago
  Digging through that code might be a bit challenging. Do you happen to have a link to a paper/documentation on this? Or maybe some rough explanation how it works (that goes beyond the short summary you provided) Java doesn't provide a primitive to deallocate memory. So while I can see how for instance allocation a huge chunk / big array could be allocated and you represent objects in there don't you end up with a situation where your process will always occupy a fixed amount memory? Might not need to be fixed. You might also be able to extend more but how would you free that again?
  - chrisseaton 4y ago
    Not being facetious - but it works exactly like any other GC. There's nothing magic about writing code in Java instead of C that makes a huge difference. But you might find this interesting as a specific example - this is where it actually obtains memory from the OS. https://github.com/oracle/graal/blob/44e68777b130c8ee781c72b0e24dfec922712d85/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/PosixVirtualMemoryProvider.java#L126 https://github.com/oracle/graal/blob/44e68777b130c8ee781c72b... Note the @Uninterruptible annotation - that's saying that this code is safe to use within the GC itself. Notice how the file doesn't contain even a single 'new! (Outside of PosixVirtualMemoryProviderFeature, which is something else.)
    - throwaway894345 4y ago
      Worth noting that Go's GC is written entirely in Go. https://github.com/golang/go/blob/master/src/runtime/mgc.go https://github.com/golang/go/blob/master/src/runtime/mgc.go
    - quelltext 4y ago
      I think that's the piece that got me and grand-GP maybe confused. You are writing a GC in Java, yes but have access to low-level memory abstractions/interfaces, right? Whereas I was initially wondering how to write a GC in "pure Java" that doesn't have access to low-level memory interfaces. Does it make sense why I was asking, now? Or am I still not getting it? To be clear, Java the language is Java, I'm not going to argue that it's not Java because of special primitives / interfaces available to write the GC here, but it is not what most people would think of when considering the limitations of the runtime everyone's using.
      - grashalm 4y ago
        I think with regular old java this would be impossible to do in a reasonable way. But with AOT compiled Java and extensions like @Uninterruptible you can do it. I think I'd phrase it like this: you can write a GC mostly in Java. Other GCs than the default Java one in native image like G1 actually embed the C++ version of the implementation instead of writing it in Java.
        quelltext 4y ago
        > But with AOT compiled Java and extensions like @Uninterruptible you can do it. Yeah, but also the code shown above used native low level primitives like mmap which typically aren't available. AOT, special behavior directives (@Uninterruptible), native memory access, making sure not to use new (?), at that point you are formally using Java, the language, but it's sort of its own thing. So, that's still cool and likely no way around it but I wonder to what degree it's actually beneficial: Your program is much closer to a C++ program than a Java one except for syntax and the additional glue abstractions that typically exist in neither. In a (exaggerated) sense it's like it's written in a C++ DSL embedded in Java. If you know how to write C++ it's possibly simpler to just write it in C++ as you know how memory management there works. If you know Java you need to get familiar to the extensions used here. This is a bit different from the idea of self-hosting a compiler for instance where you can start writing your compiler now ideomatically in your own language instead of something different. For instance if your language & runtime has GC it's much simpler / safer to write a program in it, and so a compiler in it than pre-self-hosting (if the earlier compiler was written in C). So what in particular is afforded by writing the GC in "Special Java" ? Is it just about being able to say "it's all in Java" or are there language features in "Special Java" that make live easier than C++? Or other benefits? For instance, I imagine use of the wider ecosystem / libraries isn't possible whereas in C++ it is (more so at least). It would be nice if somehow you could write a GC itself in regular old Java without having to worry about aspects of how to do it in a special, restricted way. Say, the code you write and which runs the garbage collection creates objects, which subsequently get cleaned up by your very own GC program. In the end you still have to work with low level abstractions / memory though and maybe that's still different to the self-hosted compiler example in a sense: There you translate code into a language that is more low level but you don't need to have these abstractions available in your own language / on your stage of computation / while running your compiler.
jlouis 4y ago
You carefully avoid allocation.
deleted 4y ago
[deleted]
jfoutz 4y ago
This is kinda diving into the deep end, but this is a great overview - https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/full-text/book/book-Z-H-33.html#%_sec_5.3 https://mitp-content-server.mit.edu/books/content/sectbyfn/b... the gist is you treat memory as a big array, then write a program to manipulate that array. it's really just a decision about what you want to "take as primitive" in your implementation. could be brk, could be malloc and free, or something higher level.
bitcharmer 4y ago
Java often is as fast as cpp, sometimes faster. JIT gives it a huge advantage and c2 is pretty much state of the art these days.
- anthk 4y ago
  No. Compare SweetHome 3D to any similar tool written in C++.
  - bitcharmer 4y ago
    Providing a single sample of random software as the ultimate rebuttal to my claim speaks more about your understanding of how performance comparisons of compilers and runtimes are made than about Java itself. My turn: NASDAQ moved from cpp to Java quite a few years ago. Do you think you know something they don't?
  - michaelmrose 4y ago
    There are 3 separate statements you could make. SweetHome 3D IS slower than competitive projects written in C++. C++ tools tend to be faster than comparative Java tools because of fast startup time, no GC, and being the default choice for performance sensitive projects for decades. C++ is definitively faster because of inherent advantages. You appear to be jumping to the third based on the first which appears erroneous in argument even if you turned out to be correct. In actuality it appears that for most things in the same ballpark language choice isn't necessarily the only or even the most important factor. This is even more true for things where startup time is an inconsequential factor, with better GC that doesn't result in lengthy pauses, and where development time is a substantial limiting factor wherein being quicker to work with may result in more time available to improve other design choices yielding as good or better results.
- mike_hearn 4y ago
  Technically, GraalVM Enterprise Edition is state of the art. It's similar to C2 for Java code, but for compiling other languages EE smokes C2.

Java isn't as performant as C++. BTW, how do you implement a garbage collector with a garbage-collected language?

by maxloh 4y ago

Java isn't as performant as C++. BTW, how do you implement a garbage collector with a garbage-collected language?

> BTW, how do you implement a garbage collector with a garbage-collected language? You write it carefully so the garbage collector itself doesn't also need to allocate objects. Here's a GC for Java written in Java https://github.com/oracle/graal/tree/master/substratevm/src/com.oracle.svm.core.genscavenge/src/com/oracle/svm/core/genscavenge https://github.com/oracle/graal/tree/master/substratevm/src/....

quelltext 4y ago
Digging through that code might be a bit challenging. Do you happen to have a link to a paper/documentation on this? Or maybe some rough explanation how it works (that goes beyond the short summary you provided) Java doesn't provide a primitive to deallocate memory. So while I can see how for instance allocation a huge chunk / big array could be allocated and you represent objects in there don't you end up with a situation where your process will always occupy a fixed amount memory? Might not need to be fixed. You might also be able to extend more but how would you free that again?
- chrisseaton 4y ago
  Not being facetious - but it works exactly like any other GC. There's nothing magic about writing code in Java instead of C that makes a huge difference. But you might find this interesting as a specific example - this is where it actually obtains memory from the OS. https://github.com/oracle/graal/blob/44e68777b130c8ee781c72b0e24dfec922712d85/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/PosixVirtualMemoryProvider.java#L126 https://github.com/oracle/graal/blob/44e68777b130c8ee781c72b... Note the @Uninterruptible annotation - that's saying that this code is safe to use within the GC itself. Notice how the file doesn't contain even a single 'new! (Outside of PosixVirtualMemoryProviderFeature, which is something else.)
  - throwaway894345 4y ago
    Worth noting that Go's GC is written entirely in Go. https://github.com/golang/go/blob/master/src/runtime/mgc.go https://github.com/golang/go/blob/master/src/runtime/mgc.go
  - quelltext 4y ago
    I think that's the piece that got me and grand-GP maybe confused. You are writing a GC in Java, yes but have access to low-level memory abstractions/interfaces, right? Whereas I was initially wondering how to write a GC in "pure Java" that doesn't have access to low-level memory interfaces. Does it make sense why I was asking, now? Or am I still not getting it? To be clear, Java the language is Java, I'm not going to argue that it's not Java because of special primitives / interfaces available to write the GC here, but it is not what most people would think of when considering the limitations of the runtime everyone's using.
    - grashalm 4y ago
      I think with regular old java this would be impossible to do in a reasonable way. But with AOT compiled Java and extensions like @Uninterruptible you can do it. I think I'd phrase it like this: you can write a GC mostly in Java. Other GCs than the default Java one in native image like G1 actually embed the C++ version of the implementation instead of writing it in Java.
      - quelltext 4y ago
        > But with AOT compiled Java and extensions like @Uninterruptible you can do it. Yeah, but also the code shown above used native low level primitives like mmap which typically aren't available. AOT, special behavior directives (@Uninterruptible), native memory access, making sure not to use new (?), at that point you are formally using Java, the language, but it's sort of its own thing. So, that's still cool and likely no way around it but I wonder to what degree it's actually beneficial: Your program is much closer to a C++ program than a Java one except for syntax and the additional glue abstractions that typically exist in neither. In a (exaggerated) sense it's like it's written in a C++ DSL embedded in Java. If you know how to write C++ it's possibly simpler to just write it in C++ as you know how memory management there works. If you know Java you need to get familiar to the extensions used here. This is a bit different from the idea of self-hosting a compiler for instance where you can start writing your compiler now ideomatically in your own language instead of something different. For instance if your language & runtime has GC it's much simpler / safer to write a program in it, and so a compiler in it than pre-self-hosting (if the earlier compiler was written in C). So what in particular is afforded by writing the GC in "Special Java" ? Is it just about being able to say "it's all in Java" or are there language features in "Special Java" that make live easier than C++? Or other benefits? For instance, I imagine use of the wider ecosystem / libraries isn't possible whereas in C++ it is (more so at least). It would be nice if somehow you could write a GC itself in regular old Java without having to worry about aspects of how to do it in a special, restricted way. Say, the code you write and which runs the garbage collection creates objects, which subsequently get cleaned up by your very own GC program. In the end you still have to work with low level abstractions / memory though and maybe that's still different to the self-hosted compiler example in a sense: There you translate code into a language that is more low level but you don't need to have these abstractions available in your own language / on your stage of computation / while running your compiler.

jlouis 4y ago

You carefully avoid allocation.

deleted 4y ago

[deleted]

jfoutz 4y ago

This is kinda diving into the deep end, but this is a great overview - https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/full-text/book/book-Z-H-33.html#%_sec_5.3 https://mitp-content-server.mit.edu/books/content/sectbyfn/b... the gist is you treat memory as a big array, then write a program to manipulate that array. it's really just a decision about what you want to "take as primitive" in your implementation. could be brk, could be malloc and free, or something higher level.

bitcharmer 4y ago

Java often is as fast as cpp, sometimes faster. JIT gives it a huge advantage and c2 is pretty much state of the art these days.

anthk 4y ago
No. Compare SweetHome 3D to any similar tool written in C++.
- bitcharmer 4y ago
  Providing a single sample of random software as the ultimate rebuttal to my claim speaks more about your understanding of how performance comparisons of compilers and runtimes are made than about Java itself. My turn: NASDAQ moved from cpp to Java quite a few years ago. Do you think you know something they don't?
- michaelmrose 4y ago
  There are 3 separate statements you could make. SweetHome 3D IS slower than competitive projects written in C++. C++ tools tend to be faster than comparative Java tools because of fast startup time, no GC, and being the default choice for performance sensitive projects for decades. C++ is definitively faster because of inherent advantages. You appear to be jumping to the third based on the first which appears erroneous in argument even if you turned out to be correct. In actuality it appears that for most things in the same ballpark language choice isn't necessarily the only or even the most important factor. This is even more true for things where startup time is an inconsequential factor, with better GC that doesn't result in lengthy pauses, and where development time is a substantial limiting factor wherein being quicker to work with may result in more time available to improve other design choices yielding as good or better results.
mike_hearn 4y ago
Technically, GraalVM Enterprise Edition is state of the art. It's similar to C2 for Java code, but for compiling other languages EE smokes C2.