vitalyd

12 ms·

61.
by vitalyd 11y ago
What JVM stops threads for ~20 micros?
62.
by vitalyd 11y ago
Escape analysis hasn't lived up to its promises/potential, IMO. Current Hotspot uses control flow insensitive escape detection, meaning an object that escapes on any path, even if that path is never taken, is considered escaping.
63.
by vitalyd 11y ago
Any language used for producing high performance software requires more than just beginner knowledge, each one just has its own specific things along with general cross-lang concepts to keep in mind.
64.
by vitalyd 11y ago
So what's the reason for strdup'ing vs having const names that never get freed? Also, sounds like you could use ints/enum to represent the key and provide string conversion util functions. Anyway, spending 25%in malloc/
65.
by vitalyd 11y ago
While it does avoid GC, it's mostly a faster way to share data between threads than the builtin concurrent collections.
66.
by vitalyd 11y ago
It has its pros/cons but you'd be surprised (perhaps) at the throughput and latency you can get if you're mindful of things to avoid.
67.
by vitalyd 11y ago
Yes, ergonomics suck. It's particularly frustrating since a lot of things that end up pooled are confined to current thread execution (e.g. request) and could easily be stack alloc'd if that facility was there. Along the same li
68.
by vitalyd 11y ago
For the most part stack allocs would be faster unless ctor does something ridiculously expensive. Also, one typically doesn't pool objects that are confined to the current thread's execution - it's mostly for heap references
69.
by vitalyd 11y ago
It's very much alive in the java low latency space where even young GCs are a problem. Allocations of temps/short lived objects also wash your cpu caches, and generally there are other reasons to avoid any GC in this space.
70.
by vitalyd 11y ago
>The key is that most of the effort is not where most of the data is. It's the small percentage of data (say, database index) that requires the biggest development effort, and you want the best mechanism to assist not where most byt
71.
by vitalyd 11y ago
GC definitely makes some types of systems easier to develop and reason about, but it also tends to make people be a bit sloppy with respect to memory management. For systems where managing data is one of their reasons for existence, it cre
72.
by vitalyd 11y ago
>You are right, of course. You should definitely know the behavior and failure modes of every framework and library you call. And you should consult the documentation for that. But what you don't need to consult (or even necessary k
73.
by vitalyd 11y ago
>As an example, imagine you're building an application that you know uses sockets. And it's in the requirements that your application must be able recover and re-attempt set of operations. So you look into what kinds of network
74.
by vitalyd 11y ago
The ones you can handle is a subset of possibly thrown ones, which means you need to know the superset before deciding which ones to handle. You're just describing the handling strategy: pass on it or handle it. It doesn't obvia
75.
by vitalyd 11y ago
So this is more akin to panics, where you don't really care about handling the error but rather want to stop dead in the tracks. But take something like .NET's SocketException, which contains a SocketErrorCode property; you may v
76.
by vitalyd 11y ago
Oh, I agree that TryParse is much better than Parse for cases where parsing is expected to fail. But that doesn't detract from having better error handling capabilities in places where it is needed (e.g. i/o). A lot of the .NET
77.
by vitalyd 11y ago
Error handling is one of the harder aspects of software engineering, IMHO. For starters, those code paths are less tested than others. See this, for example: https://www.usenix.org/system/files/conference/os
78.
by vitalyd 11y ago
uint.Parse vs TryParse misses the point. It's very true that doing proper error handling in C# requires more diligence and attention. I know people like to harp on checked exceptions in java, but if used properly, they at least help
79.
by vitalyd 11y ago
Segmented Code Cache has nothing to do with JIT caching. Or rather, it has as much to do with it as the existing homogenous code cache.
80.
by vitalyd 11y ago
Which ones?
81.
by vitalyd 11y ago
As already mentioned, Graal is just the JIT compiler, it's not the entire VM. JikesRVM is a research VM, which has different needs/characteristics from production JVMs.
82.
by vitalyd 11y ago
I was replying to pjmlp's comment: >Maybe with Sumatra the integration would be deeper than just an API, e.g. replacing HotSpot completely and also add SubtrateVM into it.
83.
by vitalyd 11y ago
I don't think you want a production/industrial JVM written in java :).
84.
by vitalyd 11y ago
Don't think there's anything in 9 for JIT caching unless I missed it - do you have a reference? JIT caching is non trivial problem for Hotspot due to the nature of speculative optimization, so it may take quite some time for that
85.
by vitalyd 11y ago
Sumatra was about GPU offload, not so much metacircular JVM. If you look at sumatra dev mailing list archive, you'll see the last email there states it's not in active development. The project appeared to have been driven by AMD
86.
by vitalyd 11y ago
Java could use type alias/typedef, but I doubt Oracle will add it.
87.
by vitalyd 11y ago
Sumatra is dead, AFAIK. But why would graal depend on sumatra for integration? Bigger challenge is how to bootstrap graal itself such that compilation time and thus time to peak perf isn't degraded substantially.
88.
by vitalyd 11y ago
Performance has been briefly mentioned in this thread; if you google you'll also see some empirical results. But really the best you can hope for, all else equal, is same perf as for loop. The JIT compilers have been taught about loo
89.
by vitalyd 11y ago
Well, you're not really testing for loops since 5there are other artifacts here: 1) forEach driver method is receiving multiple types, it's not monomorphic 2) you may be hitting OSR compilations 3) for loop may hit range checks on
90.
by vitalyd 11y ago
Aka "flat profile". Using these things in full force requires really banking on JIT doing the right thing (if perf is a concern), which is optimistic. A simple loop is just as readable as these one liners, and carries less risk

More ›