0

It explains concurrency in terms of Java concurrency primitives but in practice best-performance concurrent code uses sun.misc.Unsafe primitives which involves CAS and direct memory fence instructions.

Moreover, personally I prefer to use fences over happens-before when reasoning over concurrent code.

So, is JMM still valid for modern Java?

Or, to say it in other words, can JMM be used to reason over programs, synchronized via sun.misc.Unsafe methods?

Sergey Alaev
  • 3,851
  • 2
  • 20
  • 35
  • 2
    Yes. The vast, vast majority of the time you should not be using `Unsafe` because, well, it's unsafe. – Andy Turner Mar 09 '16 at 20:09
  • 3
    JMM is intended to be always valid, not just at vast majority of the time. – Sergey Alaev Mar 09 '16 at 20:14
  • I have been writing for Java code ... like since day 1 of Java. I have never used sun.misc.Unsafe. What makes you think that "high-quality" concurrent code needs it?! I would say, it is the other way round: high-quality code should focus on robust, high-level abstractions ... – GhostCat Mar 09 '16 at 20:23
  • 1
    @Jägermeister Many java.util.concurrent classes as well as modern frameworks use it. Look here for details for example: https://docs.google.com/document/d/1GDm_cAxYInmoHMor-AkStzWvwE9pw6tnz_CebJQxuUE/edit – Sergey Alaev Mar 09 '16 at 20:26
  • Yes, but does that matter? In the sense of: why would I care how a high-level construct is implemented; as long as I am not running into the trouble that this implementation isn't "good enough" for my use case. Besides: your question is basically asking for "opinion-based" answers. And such questions are not appreciated here. – GhostCat Mar 09 '16 at 20:29
  • No, I am asking about validity of Java Memory Model. Can it be used if it no longer describes Java concurrency? As a "practical developer" you might not care about that until you need to strive for performance. But my question is methodological. – Sergey Alaev Mar 09 '16 at 20:32
  • @SergeyAlaev "If it no longer describes Java concurrency" is false. – user207421 Mar 09 '16 at 20:35
  • Please explain. `Unsafe` methods are not mentioned in `17.4.5. Happens-before Order` of JLS while they clearly are inter-thread actions and widely used. – Sergey Alaev Mar 09 '16 at 20:38

1 Answers1

-1

So, is JMM still useful for modern Java?

Not really.

So, is JMM still valid for modern Java?

Yes, is still valid

Most of the java memory are handled behind the scene, garbage collection calls and manual memory manipulation is very rarely used and considered bad design. Most people will tell you it is still useful due to certain things can be done such as native memory allocation or create native concurrency.

While JMM is supported and is valid, no one really uses it. Why? Those type of things are not safe to be done using sun.misc.Unsafe. One reason why it is unsafe code is because the instances are never garbage collected. (unless this is what you want). Is like using volatile variable for thread; it never cached locally and it cost you performance and is difficult to write. In a non atomic operation may give you different result!

It is not wrong to use fence code but think about the trade offs. Ask yourself why do you use java and not C?

In short, it could be useful to get certain things done but it is not practical, due to there would be alternative way to do this. (native code)

For Vince's comment I will add this:

volatile int i = 0;

public void foo() { 
    if (i == 0) i = i + 1;
}

The above code is inherently unsafe, even though the variable's declaration as being volatile means that reads and writes are flushed to main memory - the only safe implementation of such a method would be something like:

int i = 0;

public synchronized void foo() {
    if (i == 0) 
    i = i + 1;
}

So which should you prefer? Well, if you have multiple threads modifying a field dependent on that field's value (i.e. compare-and set), then synchronized is the only safe solution.

logger
  • 1,983
  • 5
  • 31
  • 57
  • JMM is Java Memory Model, described in section `17.4` of JLS and used to reason over concurrent code. I do not understand your answer :-( – Sergey Alaev Mar 09 '16 at 21:04
  • Like I said, it depends on what you are using it for. If you are using it for thread, is not useful because instead of using volatile to check varaible, you can create synchronize block to prevent race conditions. but for using sun.misc.Unsafe like you describe in title. No it is not practical and it does not get garbage collected. you need to write difficult code to handle specific cases if you are manipulating the memory. – logger Mar 09 '16 at 21:20
  • Ah. But my question was about applicability of JMM for reasoning over concurrent programs synchronized via `Unsafe` methods. – Sergey Alaev Mar 09 '16 at 21:26
  • for example: synchronize block is pretty much the replacement for the volatile synchronized order. If you go look at any industry code that has multithreading 99.9% of time you will not find people use volatile on a variable to check for the thread safety. JMM has been replaced by many alternative. – logger Mar 09 '16 at 21:29
  • @user3659052 Are you suggesting that synchronized blocks are supposed to replace the use of volatile? If so, I think you should look into the differences, as they are not interchangeable. If not, what do you mean "replacement for the volatile synchronized order"? From what I've learned, `volatile` ensures data is stored in main memory, allowing all threads to view the same copy (rather than storing it locally). – Vince Mar 09 '16 at 21:33
  • @Vince Emigh please refer to this: http://stackoverflow.com/questions/106591/do-you-ever-use-the-volatile-keyword-in-java and what i mean is that they both does the same thing but rather using volatile to check for the data then modify the value you use synchronized block which will ensure 1 thread block the other. – logger Mar 09 '16 at 21:41
  • @user3659052 It seems my knowledge is flawed, they do share similar results (as of JSR 133). Sorry for the misunderstanding. – Vince Mar 09 '16 at 22:22