7163395: jdk8/tl no longer builds on Mac
I need a reviewer for a trivial change to get jdk8/tl building on Mac again. Jim's changes for 7130404 [1] change the os.arch variable to x86_64 to be compatible with Apple's JDK but the change-set doesn't add a jvm.cfg to the x86_64 directory. The issue is trivially fixed by moving the jvm,cfg to the right location: $ hg diff -g diff --git a/src/macosx/bin/amd64/jvm.cfg b/src/macosx/bin/x86_64/jvm.cfg rename from src/macosx/bin/amd64/jvm.cfg rename to src/macosx/bin/x86_64/jvm.cfg Note that jdk7u doesn't have this issue as the corresponding change-set added a new jvm,cfg. Thanks, Alan. [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77b35c5c4b95
RE: 7163395: jdk8/tl no longer builds on Mac
Looks fine Alan. -Chris Alan Bateman alan.bate...@oracle.com wrote: I need a reviewer for a trivial change to get jdk8/tl building on Mac again. Jim's changes for 7130404 [1] change the os.arch variable to x86_64 to be compatible with Apple's JDK but the change-set doesn't add a jvm.cfg to the x86_64 directory. The issue is trivially fixed by moving the jvm,cfg to the right location: $ hg diff -g diff --git a/src/macosx/bin/amd64/jvm.cfg b/src/macosx/bin/x86_64/jvm.cfg rename from src/macosx/bin/amd64/jvm.cfg rename to src/macosx/bin/x86_64/jvm.cfg Note that jdk7u doesn't have this issue as the corresponding change-set added a new jvm,cfg. Thanks, Alan. [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77b35c5c4b95
Re: 7163395: jdk8/tl no longer builds on Mac
Looks fine. -kto On Apr 22, 2012, at 8:51 AM, Alan Bateman wrote: I need a reviewer for a trivial change to get jdk8/tl building on Mac again. Jim's changes for 7130404 [1] change the os.arch variable to x86_64 to be compatible with Apple's JDK but the change-set doesn't add a jvm.cfg to the x86_64 directory. The issue is trivially fixed by moving the jvm,cfg to the right location: $ hg diff -g diff --git a/src/macosx/bin/amd64/jvm.cfg b/src/macosx/bin/x86_64/jvm.cfg rename from src/macosx/bin/amd64/jvm.cfg rename to src/macosx/bin/x86_64/jvm.cfg Note that jdk7u doesn't have this issue as the corresponding change-set added a new jvm,cfg. Thanks, Alan. [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77b35c5c4b95
Re: Draft j.u.c JEP
On 04/21/2012 09:50 PM, Doug Lea wrote: On 04/21/12 13:10, Brian Goetz wrote: My only concern is the mention of a fences API; I would think that this might rise to the level of wanting its own JSR, since the memory model does not necessarily provide for the all various relaxed consistency modes that such an API would seem to imply, and might involve VM support. Tying this to a JMM revision is a little scary: We know there are bugs (ranging from typos to unintended semantics to incompleteness) in the JMM. None of them are very interesting wrt 99.9% of all java programs. Still, the sense is that any revision should fix these as well. But some of these are not amenable to simple bandaids, but would require a major re-spec effort. In the mean time, we have introduced some methods (like AtomicX.lazySet) as well as those in the JDK7 Fences proposal that can ride on top of flawed underlying spec, in a way that doesn't introduce any further flaws, and so doesn't make eventual JMM re-spec any harder. When scoping out Fences for JDK7, I discussed the 3 minimal VM intrinsics methods to add with Hotspot and IBM J9 engineers. They were OK about doing it then (because it mainly entails just exposing some VM internals), so presumably still are, modulo scheduling effort to actually do it. The main questions are as always whether the potential benefits of exposing these methods to people who need them outweigh their relatively high potential for errors and uninterpretable effects. People have very strong view on both sides. (This doesn't impact us much inside java.util.concurrent because we can for the most part get the intended effects by directly using existing intrinsics.) Anyway, it's not clear we even want to have another discussion about introducing Fences. But I listed it because I think it is likely to come up again. -Doug Given that fences is really low level, I'm not sure it's a good idea to have a public API for them. I would prefer to have a class sun.misc.Fences (or in sun.misc.Unsafe) i.e. a class that is part of the VM API but not part of the JDK API. Rémi
hg: jdk8/tl/jdk: 6981776: Pack200 must support -target 7 bytecodes
Changeset: ec9876082b4e Author:ksrini Date: 2012-04-22 06:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ec9876082b4e 6981776: Pack200 must support -target 7 bytecodes Summary: pack200 implementation of JSR-200 updated for JSR-292 changes Reviewed-by: jrose, ksrini Contributed-by: john.r.r...@oracle.com, kumar.x.sriniva...@oracle.com ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/TLGlobals.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/constants.h ! src/share/native/com/sun/java/util/jar/pack/defines.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.h ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/PackageVersionTest.java ! test/tools/pack200/Utils.java - test/tools/pack200/dyn.jar ! test/tools/pack200/pack200-verifier/data/README ! test/tools/pack200/pack200-verifier/data/golden.jar ! test/tools/pack200/pack200-verifier/make/build.xml ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java
Re: Draft j.u.c JEP
I would prefer that Fences was a JDK API rather than being hidden inside a VM one. It is low level but there's nothing unsafe about it in the sense of other APIs inside the Unsafe class, and it would be undesirable if one had to jump through hoops to get access to it like we do for Unsafe today (i.e. using reflection). Sent from my phone On Apr 22, 2012 6:02 AM, Rémi Forax fo...@univ-mlv.fr wrote: On 04/21/2012 09:50 PM, Doug Lea wrote: On 04/21/12 13:10, Brian Goetz wrote: My only concern is the mention of a fences API; I would think that this might rise to the level of wanting its own JSR, since the memory model does not necessarily provide for the all various relaxed consistency modes that such an API would seem to imply, and might involve VM support. Tying this to a JMM revision is a little scary: We know there are bugs (ranging from typos to unintended semantics to incompleteness) in the JMM. None of them are very interesting wrt 99.9% of all java programs. Still, the sense is that any revision should fix these as well. But some of these are not amenable to simple bandaids, but would require a major re-spec effort. In the mean time, we have introduced some methods (like AtomicX.lazySet) as well as those in the JDK7 Fences proposal that can ride on top of flawed underlying spec, in a way that doesn't introduce any further flaws, and so doesn't make eventual JMM re-spec any harder. When scoping out Fences for JDK7, I discussed the 3 minimal VM intrinsics methods to add with Hotspot and IBM J9 engineers. They were OK about doing it then (because it mainly entails just exposing some VM internals), so presumably still are, modulo scheduling effort to actually do it. The main questions are as always whether the potential benefits of exposing these methods to people who need them outweigh their relatively high potential for errors and uninterpretable effects. People have very strong view on both sides. (This doesn't impact us much inside java.util.concurrent because we can for the most part get the intended effects by directly using existing intrinsics.) Anyway, it's not clear we even want to have another discussion about introducing Fences. But I listed it because I think it is likely to come up again. -Doug Given that fences is really low level, I'm not sure it's a good idea to have a public API for them. I would prefer to have a class sun.misc.Fences (or in sun.misc.Unsafe) i.e. a class that is part of the VM API but not part of the JDK API. Rémi
hg: jdk8/tl/jdk: 7132924: (dc) DatagramChannel.disconnect throws SocketException with IPv4 socket and IPv6 enabled [macosx]
Changeset: 1980be18d0f8 Author:alanb Date: 2012-04-22 21:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1980be18d0f8 7132924: (dc) DatagramChannel.disconnect throws SocketException with IPv4 socket and IPv6 enabled [macosx] Reviewed-by: chegar ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c + test/java/nio/channels/DatagramChannel/Disconnect.java
Re: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid)
The process reaper thread will be calling process.notifyAll() so this is
not simply a sleep. In which case the correct form would be:
public synchronized boolean waitFor(long timeout, TimeUnit unit) {
...
while (!hasExited) {
wait(timeLeft);
if (!hasExited) {
timeleft = recalcTimeLeft(...);
}
...
}
but using wait/notify the recalculation of the timeleft to wait becomes
burdensome. At this point - issues of j.u.c dependencies not
withstanding - it becomes simpler to use eg CountDownLatch for the
synchronization.
David
-
On 20/04/2012 7:27 PM, David Holmes wrote:
Correction:
On 20/04/2012 7:15 PM, David Holmes wrote:
Rob,
You can't use wait this way:
217 public synchronized boolean waitFor(long timeout, TimeUnit unit)
218 throws InterruptedException {
219 long millis = unit.toMillis(timeout);
220 long nanos = unit.toNanos(timeout) % (millis * 100);
221
222 if (hasExited) return true;
223 if (timeout = 0) return false;
224 wait(millis, (int)nanos);
225 return hasExited;
226 }
If this is just causing a delay then use Thread.sleep() (but don't have
the method synchronized of course). If something is actually calling
notifyAll (I don't see it) then the above suffers from lost wakeups.
Sorry - There's no lost wakeup.
David
-
Either way a spurious wakeup means you will return earlier than expected.
David
-
On 20/04/2012 11:33 AM, Rob McKenna wrote:
I've uploaded another webrev to:
http://cr.openjdk.java.net/~robm/4244896/webrev.02/
http://cr.openjdk.java.net/%7Erobm/4244896/webrev.02/
I plan to spend some time over the coming day or two beefing up the test
for waitFor (right now its really geared towards destroyForcibly) so I
won't guarantee its 100% quite yet. That said, I would like feedback on
a couple of points before I proceed:
1) Alan suggested the use of System.nanoTime() so I altered
waitFor(long) to allow for a TimeUnit parameter. UnixProcess objects can
use Object.wait(long, int) but unfortunately WaitForMultipleObjects (on
Windows) only works to millisecond precision.
2) As Alan noted, there is really no need for isAlive() if people are
happy with the idea of waitFor(long, TimeUnit). I'd appreciate any
feedback on this aspect of the fix.
-Rob
On 19/04/12 12:05, Alan Bateman wrote:
On 19/04/2012 01:05, David Holmes wrote:
On 18/04/2012 11:44 PM, Jason Mehrens wrote:
Rob,
It looks like waitFor is calling Object.wait(long) without owning
this objects monitor. If I pass Long.MAX_VALUE to waitFor, shouldn't
waitFor return if the early if the process ends?
Also waitFor doesn't call wait() under the guard of a looping
predicate so it will suffer from lost signals and potentially
spurious wakeups. I also don't see anything calling notify[All] to
indicate the process has now terminated. It would appear that
wait(timeout) is being used as a sleep mechanism and that is wrong on
a number of levels.
I assume waitFor(timout) will require 3 distinct implementations, one
for Solaris/Linux/Mac, another for Windows, and a default
implementations for Process implementations that exist outside of the
JDK.
It's likely the Solaris/Linux/Mac implementation will involve two
threads, one to block in waitpid and the other to interrupt it via a
signal if the timeout elapses before the child terminates. The Windows
implementation should be trivial because it can be a timed wait.
I assume the default implementation (which is what is being discussed
here) will need to loop calling exitValue until the timeout elapses or
the child terminates. Not very efficient but at least it won't be used
when when creating Processes via Runtime.exec or ProcessBuilder.
I think the question we need to consider is whether waitFor(timeout)
is really needed. If it's something that it pushed out for another day
then it brings up the question as to whether to include isAlive now or
not (as waitFor without timeout gives us an isAlive equivalent too).
-Alan.
Re: core-libs-dev sun.management.Agent: the properties.putAll API may fail with ConcurrentModifcationException on multi-thread scenario
On 04/18/2012 02:20 PM, Deven You wrote: On 04/18/2012 01:34 PM, Mandy Chung wrote: On 4/17/2012 12:33 AM, Deven You wrote: I think this could still run into CME. System Properties is not a synchronized map and the setter methods (System.setProperty or Properties.put method) doesn't synchronize on the Properties object. Hi Mandy, I didn't catch you. Do you mean there are other setter methods of System properties in the Agent.java which are not synchronized? The setter methods I'm referring to are System.setProperty and System.getProperties().put(). Mandy Hi Mandy, I have gone through the Agent.java, I think other set/put methods related to properties are protected properly. public static void agentmain using parseString(args) which return a properties which is a local var and is not possible to cause concurrent problem when call config_props.putAll(arg_props). private static synchronized void startLocalManagementAgent() is synchronized already. private static synchronized void startRemoteManagementAgent(String args) is synchronized also. Could you point where the CME may ocurr? Thanks a lot! Hi All, Is there any suggestion from the mailing list? -- Best Regards, Deven
