Win a copy of Learn Spring Security (video course) this week in the Spring forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

To the author: Memory model

 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Cay,

I just checkde that Tiger has added JSR-133 for new memory model, could you briefly discribed what memory structure Tiger is using? Any brenchmark data for comparing the old model with the new one?

Thanks.

Nick
 
Cay Horstmann
author
Ranch Hand
Posts: 172
15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The "memory model" is a rather specialized issue that is important in the following circumstances:

1) You have a computer with more than one CPU
2) Your Java program has multiple threads
3) Your threads simultaneously access the same memory values

Funny things can happen in these circumstances because each processor has its own cache. (RAM is quite slow compared to a modern CPU, so the CPU caches frequently accessed memory locations.) Each processor might use a different value for what should be the same memory location.

Also, the JIT compiler may reorder instructions in one thread, which may mess up assumptions about instruction order that another thread makes. For example, if one thread never modifies a variable, the compiler may only read it from memory once. Then the other thread's modification of the same variable becomes invisible.

The memory model gives precise rules when the JVM needs to ensure that variables are properly shared between threads (e.g. in a synchronized block or if the variables are volatile), and when the processor and the compiler are free to carry out optimizations.

It is probably the dullest JSR out there, but of course, this is important stuff, and I am glad that some people worry about it.

Application programmers probably shouldn't worry about it too much. My advice is:
1) Try to use the new threadsafe collections in JDK 5.0. The implementors
have done all the thread-safety grunt work for you.
2) If there are no collections that work for your task, use synchronization or the new JDK 5.0 locks and conditions
3) If that's too much trouble (e.g. to access a single shared int), use volatile

Cheers,

Cay
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Cay.

That is to say, in case my applications are distributed and multithreaded, the JVM will cater all memory issues for me, and what I need to do is to make sure that the Objects used in the system is thread-safe?

For non-multithreaded applications, are there any impact on them?

Recently, I havent developed any non-Web-based applications, and I guess the multithreading issues are handled by the container, in case, J2EE Tiger released, which I suppose it will use the same memory model, the container might have less effort for handling these issues?

Nick
 
Cay Horstmann
author
Ranch Hand
Posts: 172
15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Absolutely... Ideally you shouldn't have to worry much about it, particularly if you can have the container handle transactions. The people who implement the container will really appreciate the new multithreading features.
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Cay.

Did you have any reference/articles about this area?

Nick
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic