Migrate, Modernize and Build Java Web Apps on Azure: This live workshop will cover methods to enhance Java application development workflow.
Modern Digital Website Security: Prepare to face any form of malicious web activity and enable your sites to optimally serve your customers.
Technical Manager at SunGard Consulting Services
NYC, US
Joined Jun 2010
About
Yongjun Jiao (yongjun.jiao@sungard.com) has been a professional software developer for the past 10 years. His expertise covers Java SE, Java EE, Oracle, application tuning and high performance and low latency computing. He is a technical manager with SunGard Global Services.
Stats
Reputation: | 6 |
Pageviews: | 155.1K |
Articles: | 1 |
Comments: | 7 |
Articles
Comments
Apr 17, 2011 · Gerd Storm
Apr 17, 2011 · Yongjun Jiao
Oct 18, 2010 · Yongjun Jiao
For the last comment, the code in section 3 did annotate the following method with @transactional in a separate bean:
public void callDBStoredProcedure();
So the calling thread (in the TaskExecutor) will call the above method through an AOP CGLib proxy which was generated by the default "proxy" mode.
The code also mentioned "aspectj" as another mode. What is not obvious is that it didn't explicitly tell readers the "aspectj" mode supports self - invocation calls. Sorry for that.
Oct 15, 2010 · Yongjun Jiao
A reasonable concern. So it is recommended to use Java's Executor where you can specify the number of Core and Max threads, inactivity period etc.
Another solution for non-blocking is to use your client's side non-blocking feather if it support. In case of Swing, you can use SwingWorker to actually call the backend long-runing method. However in this case the connection between the front-end and back-end will be held for long.
Oct 15, 2010 · Yongjun Jiao
A reasonable concern. So it is recommended to use Java's Executor where you can specify the number of Core and Max threads, inactivity period etc.
Another solution for non-blocking is to use your client's side non-blocking feather if it support. In case of Swing, you can use SwingWorker to actually call the backend long-runing method. However in this case the connection between the front-end and back-end will be held for long.
Aug 24, 2010 · Yongjun Jiao
Regarding "Thread1, Return value from method, reads null (line 17)", I don't think thread1 can return NULL because if thread1 returns null in line 17, it means line 17 was reordered ahead of line 13 in my List 9. But I don't think the compiler will do such reordering for a return statement.
Regarding "If I understand correctly the crux of the claim is that a JVM is free to reorder memory writes even across block boundaries", I don't think the compiler will reorder operations across block / method boundaries. Actually inlining method to eliminate block/method boundaries is just making it possible to reorder operations that were originally in different methods (http://java.sun.com/products/hotspot/whitepaper.html).
Regarding "The de-facto standard born out of the implementations of the language says although it was possible it wasn't a good idea to do so, I would like to know if such maybe true for Java.", I totally concur. Although the current JMM has improved a lot to eliminated many counter-intuitives such as out-of-thin-air values, it still has to do something in order for most Java developers to easily understand it.
Regarding "That all static initializers are instated before any new instance of a class can be created (before the first invocation to a constructor is called, the initializers have run and committed their memory writes).", I don't think you can find such a rule in Dou Lea's JSR 133 cooking book. I know this is very counter-intuitiv. More comments please!
Regarding "There maybe some language requirement in java to have a pseudo method call to enforce flushes (write) and reloads (read) of memory.", actually Dou Lea proposed a Fence API for the upcoming Java 7 release for this purpose.
Regarding "It is my understanding there is nothing stopping a lame JVM from evaluating the load from static variable 'instance' twice (when using your example).", I am not quite clear about this. But if a thread loads a second time in the return statement in line 17 in my List 9, it must have a compelling reason to do so. But the return statement is not in any sychronized, the thread should assume it is the only one to be running at that time.
Regarding your 2nd listing, I don't think it can fix the out-of-order write problem because line 4 still incurs 2 memory writes: one is the write of tmpInstance;the other is SingletonDemo's field intialization. The 2 writes can still be reordered by either compiler or CPU. You may have known this web site for DCL discussions by thought-leaders.
Aug 09, 2010 · Yongjun Jiao
Regarding the "Causality" in Section 4.5, it turns out that there are no processors supporting it. Here is the email response from Profession Adve along with my original request:
Dear Yong,
There are no processors today that do this (otherwise, we would have trouble with the C++ and Java memory models prohibiting this). The goal here is to ensure (1) future processors never allow this outcome, and (2) to make it part of the formal semantics so programmers can rely on it. The data-race-free model clearly prohibits this outcome. Sarita
From:JIAO, YONGJUN[mailto:YONGJUN.JIAO@nexteraenergy.com]
Sent: Monday, August 02, 2010 5:06 PM
To: Adve, Sarita V
Subject:
Dear professor,
I learned a lot from your article "Memory Models: A Case for Rethinking Parallel Languages and Hardware".
However I do want to consult you for case (a) in Figure 4 on page 4:
what microprocessors support such a "causality loop"?
My understanding is when core 1 speculatively executes "Y = 1", it puts the new value in a temporary store (core 2 will not see it) until it detects the predicate in the "if" statement becomes true; I have similar argument for core 2. So neither core 1 nor core 2 will make its speculative write operation visible to the other core.
Regards,
Yong Jiao