Re: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] (open part)
On 22/11/2012 07:38, Alexey Utkin wrote: : I take in account the AWT problem on Mac OS: in ssh session due to compatibility reason AWT switches to X11 toolkit if DISPLAY variable is defined. But Mac OS implementation of X11 toolkit has a deadlock/linkage problems. In JDK8 the X11 toolkit support is obsolete and problem would be resolved by AWT team. Alexey - can you explain this comment a bit further? Are you saying that the X11 support has been removed or will be removed? We've had major grief get automated testing running on Mac OSX and I would prefer not to remove the tests from the ProblemList until we are confident that the AWT deadlock issue has been resolved. -Alan
Re: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] (open part)
On 22.11.2012 12:41, Alan Bateman wrote: On 22/11/2012 07:38, Alexey Utkin wrote: : I take in account the AWT problem on Mac OS: in ssh session due to compatibility reason AWT switches to X11 toolkit if DISPLAY variable is defined. But Mac OS implementation of X11 toolkit has a deadlock/linkage problems. In JDK8 the X11 toolkit support is obsolete and problem would be resolved by AWT team. Alexey - can you explain this comment a bit further? Are you saying that the X11 support has been removed or will be removed? We've had major grief get automated testing running on Mac OSX and I would prefer not to remove the tests from the ProblemList until we are confident that the AWT deadlock issue has been resolved. In accordance with the AWT plan the support for X11 toolkit on Mac OS has to be removed. As a result the issues in that part of code are frozen. In fact the most of work is already done, except the border cases similar to described in the comment. More over, seems that it is the only case with problem (falldown to X11 toolkit without switches in command line for very specific environment). The best choice would be the ban for DISPLAY variable setup on JPRT computers as temporary solution. AWT deadlock issue for X11 toolkit on Mac OS will not be resolved, instead, X11 toolkit will be forbidden for Mac OS. -Alan
Request for review: 7173494: some jdk tests are not run in test/Makefile
Hi folks, Looking to backport these changes to the test makefiles to jdk7. As per Alans original mail: This one is a small clean-up of the test targets defined in jdk/test/Makefile. The union of the tests executed by each of the make targets should be the entire test suite but this isn't so, there are small number of tests that aren't run. I've renamed jdk_misc to jdk_other (the original name is confusing because of sun.misc) and expanded it to run additional areas that have a small number of tests. If more tests are added to these areas over time then it may make sense to add new targets in the future. make jdk_jmx now runs the JMX tests as it was confusing to have those tests split between management1 and management2. I've also renamed jdk_tools1 to jdk_jdi to make it clear that this is the JDI tests rather than tools. When Kelly originally set this up he split the NIO tests into 3 batches, I don't think this is necessary any longer (the really slow tests have been long been dialed down or changed to run much faster). The tl folder refers to the forest root, the jdk folder refers to the jdk repo. http://cr.openjdk.java.net/~robm/7173494/ ( 8 changesets: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b79177ebfef http://hg.openjdk.java.net/jdk8/tl/rev/4bde5640fb36 ) -Rob
Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion
Hi folks, Looking for a review for the webrev below, which also resolves: 7175692: (process) Process.exec should use posix_spawn [macosx] For additional context and a brief description it would be well worth looking at the following thread started by Michael McMahon, who did the brunt of the work for this fix: http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-May/thread.html#1644 Basically the fix aims to swap fork for posix_spawn as the default process launch mechanism on Solaris and Mac OSX in order to avoid swap exhaustion issues encountered with fork()/exec(). It also offers a flag (java.lang.useFork) to allow a user to revert to the old behaviour. I'm having trouble seeing the wood for the trees at this point so I'm anticipating plenty of feedback. In particular I'd appreciate some discussion on: - The binary launcher name property name may need some work. A more general property (java.lang.launchMechanism) to allow a user to specify a particular call was mooted too. It may be more future proof and I'm completely open to that. (e.g. launchMechanism=spawn|fork|vfork|clone - we would obviously ignore inapplicable values on a per-platform basis) - I'd like a more robust way of checking that someone isn't trying to use jprochelper outside of the context for which it is meant. - The decision around which call to use getting moved to the java level and away from the native preprocessor. The webrev is at: http://cr.openjdk.java.net/~robm/5049299/webrev.01/ http://cr.openjdk.java.net/%7Erobm/5049299/webrev.01/ Thanks a lot, -Rob
Canonical path for /ssss/../../ ?
I've seen something weird on Linux: new File(//../).getCanonicalFile()' = / new File(//../../).getCanonicalFile()' = /.. new File(//../../../).getCanonicalFile()' = / new File(//../../../../).getCanonicalFile()' = /.. and new File(//../..).getCanonicalFile().getCanonicalFile() = / Is /.. canonical? Shouldn't getCanonicalFile() be idempotent? Thanks Max
