4 ms·

Weird presentation. He has a disclaimer upfront that he doesn't really know much about the JVM. He wants a Decimal class? Fine go ahead and write one. You can e

by zohebv 15y ago

Weird presentation. He has a disclaimer upfront that he doesn't really know much about the JVM. He wants a Decimal class? Fine go ahead and write one. You can easily emulate it using an int with a globally accepted denominator value, but whatever. He wants the class file format to be changed from stack machine to register machines. And exactly why? He wants deadlock detection on every lock acquisition? So lock acquisition is now O(n) instead of O(1). Fine, go ahead and write your own expensive deadlock detecting lock class. Why does he need the "JVM" to support this? Also what does - synchronized must die because we have > 2 CPUs- mean. One would think this makes synchronization more important. He is not even proposing an actor model as an alternative. What does non threadsafe objects not being allowed to escape mean? Escape into a different thread? How does he propose to do the analysis required to identify such objects? Statically/Runtime? Is this even tractable? What level of granularity does he expect the lock on an "escaped" object to be, if the object itself is a graph of of many objects? I like how he pretends to solve all GC problems in one slide, using "escape" analysis or whatever. Everything will be concurrent and nobody will pause. And there seems to be some persistent obsession with the Date and Time classes. He has also somehow managed to combine immutability with autoboxing.

psykotic 15y ago
> So lock acquisition is now O(n) instead of O(1). You can do incremental deadlock detection in O(1) time per waiter assuming you are okay with treating hash table operations as O(1), so that successful lock acquisition takes O(w) time where w is the number of threads directly or indirectly waiting on the lock-acquiring thread. A really simple example would be Herlihy's dreadlocks: http://www.unine.ch/transact08/slides/Herlihy-Dreadlocks.pdf http://www.unine.ch/transact08/slides/Herlihy-Dreadlocks.pdf. He does lossy deadlock detection using Bloom filters and bit vectors, so it's truly constant time per waiter at the cost of false negatives. But the same idea works for exact deadlock detection if you use concurrent hash tables. The only question is whether you'd want to do that in practice. The overhead of using this as the default mode of operation would absolutely be prohibitive. But all that is just an aside for your edification, because frankly I don't see anything in the slides that requires instant deadlock detection. He's just asking for a standardized DeadlockError exception that will be thrown to waiting threads involved in a cycle so as to break the deadlock. Most practical deadlock detectors run periodically and that's consistent with what he's requesting. > And there seems to be some persistent obsession with the Date and Time classes. Why not? Java's Date/Time classes have a broken design. That's why everyone uses Joda-Time.
- zohebv 15y ago
  Thank you for the paper reference. It looks like O(1) detection is possible but is possibly expensive. With a periodic deadlock check you end up having to tune the periodicity and be able to write a very robust deadlock handler. For ex: what if one module ends up deadlocking leading to huge buffer overflows in a queuing system. What kind of periodic interval can you recommend that would be generally applicable, how should the deadlock handler react in such a situation etc. periodic detection will make the deadlock handler harder to write. > Java's Date/Time classes have a broken design They might be. But none of these are JVM issues per se. These are merely Java library issues. Add a library that fixes the issue. The slide deck is apparently about top 10 issues in the JVM. Deadlock/date are problems that can be solved by a library. Some of the issues in there are Java language issues and not strictly JVM issues. The pauseless GC slide is a ridiculous simplification. The slide deck is an obviously random hodge podge collection of disconnected scraps. It is a waste of time to go read through it. The intention of my comment was to save other people's time as the slide deck does not have anything interesting about Top 10 JVM issues or anything close. It is also somewhat disconcerting to know that the speaker is a VP at Oracle though possibly not in charge of JVM development.
  - psykotic 15y ago
    > What kind of periodic interval can you recommend that would be generally applicable, how should the deadlock handler react in such a situation etc. periodic detection will make the deadlock handler harder to write. The question of how the deadlock handler should be respond is what his slide was about. You need to have a way of returning a standardized error from lock() to signal a deadlock. That's the exception type he calls DeadlockError. You send those signals to enough waiters to break the detected cycles in the graph. As for the checking interval, there's no simple answer. Engineering is often like that. It doesn't mean you give up and abandon the idea. We can define desirable criteria and go from there: the interval needs to be adaptive, long-waiting threads might boost the priority of the deadlock detector thread, etc. For what it's worth, I agree with your overall assessment of his suggestions.

by zohebv 15y ago

psykotic 15y ago

> So lock acquisition is now O(n) instead of O(1). You can do incremental deadlock detection in O(1) time per waiter assuming you are okay with treating hash table operations as O(1), so that successful lock acquisition takes O(w) time where w is the number of threads directly or indirectly waiting on the lock-acquiring thread. A really simple example would be Herlihy's dreadlocks: http://www.unine.ch/transact08/slides/Herlihy-Dreadlocks.pdf http://www.unine.ch/transact08/slides/Herlihy-Dreadlocks.pdf. He does lossy deadlock detection using Bloom filters and bit vectors, so it's truly constant time per waiter at the cost of false negatives. But the same idea works for exact deadlock detection if you use concurrent hash tables. The only question is whether you'd want to do that in practice. The overhead of using this as the default mode of operation would absolutely be prohibitive. But all that is just an aside for your edification, because frankly I don't see anything in the slides that requires instant deadlock detection. He's just asking for a standardized DeadlockError exception that will be thrown to waiting threads involved in a cycle so as to break the deadlock. Most practical deadlock detectors run periodically and that's consistent with what he's requesting. > And there seems to be some persistent obsession with the Date and Time classes. Why not? Java's Date/Time classes have a broken design. That's why everyone uses Joda-Time.

zohebv 15y ago
Thank you for the paper reference. It looks like O(1) detection is possible but is possibly expensive. With a periodic deadlock check you end up having to tune the periodicity and be able to write a very robust deadlock handler. For ex: what if one module ends up deadlocking leading to huge buffer overflows in a queuing system. What kind of periodic interval can you recommend that would be generally applicable, how should the deadlock handler react in such a situation etc. periodic detection will make the deadlock handler harder to write. > Java's Date/Time classes have a broken design They might be. But none of these are JVM issues per se. These are merely Java library issues. Add a library that fixes the issue. The slide deck is apparently about top 10 issues in the JVM. Deadlock/date are problems that can be solved by a library. Some of the issues in there are Java language issues and not strictly JVM issues. The pauseless GC slide is a ridiculous simplification. The slide deck is an obviously random hodge podge collection of disconnected scraps. It is a waste of time to go read through it. The intention of my comment was to save other people's time as the slide deck does not have anything interesting about Top 10 JVM issues or anything close. It is also somewhat disconcerting to know that the speaker is a VP at Oracle though possibly not in charge of JVM development.
- psykotic 15y ago
  > What kind of periodic interval can you recommend that would be generally applicable, how should the deadlock handler react in such a situation etc. periodic detection will make the deadlock handler harder to write. The question of how the deadlock handler should be respond is what his slide was about. You need to have a way of returning a standardized error from lock() to signal a deadlock. That's the exception type he calls DeadlockError. You send those signals to enough waiters to break the detected cycles in the graph. As for the checking interval, there's no simple answer. Engineering is often like that. It doesn't mean you give up and abandon the idea. We can define desirable criteria and go from there: the interval needs to be adaptive, long-waiting threads might boost the priority of the deadlock detector thread, etc. For what it's worth, I agree with your overall assessment of his suggestions.