5583 2007-09-27 12:43 Upgrade Java WS core to Java 5 2008-04-10 09:38:58 1 1 1 Unclassified Java WS Core Campaign unspecified Macintosh All RESOLVED FIXED P1 blocker 4.2.0 5616 5753 1 trhowe@uchicago.edu trhowe@uchicago.edu jwscore-dev@globus.org rohder@mcs.anl.gov trhowe@uchicago.edu 2007-09-27 12:43:02 Objective: Upgrade the Java VM to Java 5 Technologies: Java WS Core Description: Several services have asked for database resource persistence to be included in the ws-core. In order to limit the responsibility of the service developer from handling the persistence mechanism, this should be implemented using some object relational mapping tool. Given our requirements, the Java Persistence API (JPA) is the best choice. However, the JPA requires the use of some of the language features of Java 5. As such we need to upgrade to Java 5. This should be a fairly seamless transition for most users who would only upgrade their Virtual Machine and likely not need to change any of their code. Users who have used "enum" as a variable name would need to change those usages as it is a reserved keyword in Java 5. There have also been some changes to the semantics of the thread scheduler, but these changes should not affect many service developers and there exists a clear upgrade path for developers who are affected by the change using javax.util.concurrent. Benefits: Resource Persistence using the JPA. Access to Annotations, Generics and runtime enhancement which can be used to make the process of developing services simpler. Implementation tasks: 1. Refactor current uses of the word "enum" in the current implementation. 2. Implement performance tests to evaluate effect of thread scheduler semantics check. Deliverables: 1. Updated code and unit tests. 2. Document detailing migration path for developers who need to update their thread handling. bacon@mcs.anl.gov 2007-09-27 12:57:08 As an aside, note that GRAM is one of the services affected by the java 5 thread processing, see bug 4452. trhowe@uchicago.edu 2007-10-05 09:37:46 Charles is currently investigating how well java 5 works on the various platforms globus supports. trhowe@uchicago.edu 2007-10-15 08:43:14 So far this bug is progressing, however, it will currently be put on hold while I work on the container reliability bug: http://bugzilla.mcs.anl.gov/globus/show_bug.cgi?id=5612 trhowe@uchicago.edu 2008-01-04 09:31:58 One of the concerns with an upgrade to Java 5 was the semantics of Thread scheduling. In java 1.4 the thread scheduling was largely left to the OS (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4985566). In java 5 the JVM defaults to an Non-fair scheduling algorithm, where a thread can jump to the front of the queue if a lock becomes available. Generally this approach with be faster on enterprise systems as it means that short running threads can grab a lock instead of waiting for long running threads to finish. In certain circumstances, it can lead to starved threads, particularly when there are long running threads all contending for the same lock. This is often a sign of poorly designed synchronization. It is important to note that the JVM spec does not promise any particular order of thread scheduling, so if we plan to support multiple JVM versions, we need to make sure not to assume a thread order with default synchronization. If starvation problems do occur (I do not anticipate this), we have two options: 1) reduce the amount of synchronization, if appropriate, or 2) replace the synchronization with the Lock constructs from java.util.concurrent and it's backport. These locks allow us to specify Fair scheduling. However, I doubt this will be an issue. if it is, though it's a bug that needs to be fixed properly, instead of assuming a version. Secondly, Java 5 presents a significant performance boost using Locks over synchronized{} blocks. This advantage is not present in Java 6. Locks are slightly more difficult to use because the developer is required to unlock in a finally block. Failing to do so can lead to myriad problems down the road. Generally the explicit locks are recommended when you need a special feature not provided by intrinsic locks (timeouts, cancellations, non-block locks). In the case of core, since we we not be upgrading to java 6 for the forseeable future, we we find the places of most contention, likely the request handling code and the ResourceHome code and replace the intrinsic locks with explicit locks. This way we can gain the performance advantages without upending the entire codebase tfreeman@mcs.anl.gov 2008-01-04 10:08:52 Speaking of util.concurrent, core includes a homegrown executor engine (see org.globus.wsrf.container package) which I think could possibly/should be replaced by util.concurrent's executors. I've been using the backport with Java 1.4 and it is great. bacon@mcs.anl.gov 2008-03-25 09:10:44 Regarding Java 6, is your plan to require people NOT to use Java 6? Because even when we required Java 1.4, people were still able to use Java 5 to run core. I like the idea of using improvements that are available in Java 5 and beyond, but it seems like a mistake to home in on improvements that only exist in one incarnation of the JVM. trhowe@uchicago.edu 2008-03-25 09:12:45 Charles, No, I should have been clear. This means java 5 +, not java 5 exactly. trhowe@uchicago.edu 2008-04-10 09:38:58 Code has been tested against Java 5. Fixed a bug that assumed that the .class macro calls the static initializers for a class. That is no longer the case, so replaced it with Class.forName().