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
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
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
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
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
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
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
!
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
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
