Hi Eric and others,
I'd also like to rise an internal design concern regarding construction
of Parameter objects. Currently raw reflection data for Executable
objects is obtained from the VM atomically - the whole Method or
Constructor is fully constructed with all necessary information in
Hello,
Nice to see a good attempt at getting the new build in order. While this
looks like it works, I have a few comments:
In makefiles/CompileLaunchers.gmk
* OPENJDK_TARGET_CPU_LIBDIR is empty on macosx, so you can safely use
the same definition of BUILD_JSPAWNHELPER_DST_DIR for all
Thanks for all the inputs.
I think I need to get off to concurrency-interest to ask what the
general public expectations are, to see whether we need to spec this
more accurately. Even though spec is explicit now about using Buffers
with synchronization, there is also a reasonable behavior, that
Changeset: b600d490dc57
Author:dsamersoff
Date: 2012-12-20 16:02 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b600d490dc57
6783290: MBeanInfo/MBeanFeatureInfo has inconsistent readObject/writeObject
Summary: call readObject in all cases
Reviewed-by: emcmanus
Changeset: e43f90d5af11
Author:dsamersoff
Date: 2012-12-20 16:56 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e43f90d5af11
6937053: RMI unmarshalling errors in ClientNotifForwarder cause silent failure
Summary: the catch block in the fetchNotifs() method is extended to
Changeset: 3f014bc09297
Author:dsamersoff
Date: 2012-12-20 17:24 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f014bc09297
7009998: JMX synchronization during connection restart is faulty
Summary: add a return statement after the re-connecting has finished and the
state
Hi Peter, Eric and and others,
Thanks for your comments,
On 12/20/2012 09:09 AM, Peter Levart wrote:
Hi Eric and others,
I'd also like to rise an internal design concern regarding construction
of Parameter objects. Currently raw reflection data for Executable
objects is obtained from the VM
Changeset: d01a810798e0
Author:dl
Date: 2012-12-20 13:44 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d01a810798e0
8002356: Add ForkJoin common pool and CountedCompleter
Reviewed-by: chegar, mduigou
! make/java/java/FILES_java.gmk
+
On 18/12/2012 18:04, marti...@google.com wrote:
Changeset: 0fabdf676395
Author:martin
Date: 2012-12-17 18:39 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0fabdf676395
8004863: Infinite Loop in KeepAliveStream
Reviewed-by: chegar
!
On 20/12/2012 14:01, Alan Bateman wrote:
../../../../src/share/classes/sun/net/www/http/KeepAliveStream.java:86:
warning: [cast] redundant cast to long
do {} while ((nskip = (long) (expected - count)) 0L
I can't help but feel responsible for this, since I reviewed the
On 20/12/2012 14:15, Chris Hegarty wrote:
On 20/12/2012 14:01, Alan Bateman wrote:
../../../../src/share/classes/sun/net/www/http/KeepAliveStream.java:86:
warning: [cast] redundant cast to long
do {} while ((nskip = (long) (expected - count))
0L
I can't help but feel
On 12/20/2012 02:45 PM, Joel Borggrén-Franck wrote:
Hi Peter, Eric and and others,
Thanks for your comments,
On 12/20/2012 09:09 AM, Peter Levart wrote:
Hi Eric and others,
I'd also like to rise an internal design concern regarding construction
of Parameter objects. Currently raw reflection
Hi,
I'm looking for a code review for a corba fix for 7 and 8, which is
identical to fix went to earlier releases.
A wrong IOP00810247: (MARSHAL) Default union branch not expected
exception is thrown for discriminated unions with no matching
discriminator and no default cases, while Section
Hi Stuart,
Looks good to me.
Thanks,
Jim
On 12/19/2012 08:11 PM, Stuart Marks wrote:
Hi all,
Please review the fix [1] for bug 8005290 [2].
[1] http://cr.openjdk.java.net/~smarks/reviews/8005290/webrev.0/
[2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005290
I just filed this
From my limited knowledge of this, it look ok to me.
-Chris.
On 20/12/2012 01:11, Stuart Marks wrote:
Hi all,
Please review the fix [1] for bug 8005290 [2].
[1] http://cr.openjdk.java.net/~smarks/reviews/8005290/webrev.0/
[2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005290
I
2012/12/19 12:37 -0800, david.hol...@oracle.com:
If multiple threads have to synchronize access to the buffer then the
reads/writes do not need to be atomic. Atomicity is only needed when
data races are allowed.
Correct.
Byte buffers, especially the direct variety, are all about performance.
On 12/20/2012 09:11 PM, mark.reinh...@oracle.com wrote:
2012/12/19 12:37 -0800, david.hol...@oracle.com:
If multiple threads have to synchronize access to the buffer then the
reads/writes do not need to be atomic. Atomicity is only needed when
data races are allowed.
Correct.
Byte
This is a review request for the addition of utility methods to
java.util.Arrays that provide sorting of arrays in parallel, JEP 103 [1].
Webrev:
http://cr.openjdk.java.net/~chegar/8003981/ver.00/
Current sorting implementations provided by the Java Collections
Framework (Collections.sort
Am 20.12.2012 18:18, schrieb Aleksey Shipilev:
On 12/20/2012 09:11 PM, mark.reinh...@oracle.com wrote:
2012/12/19 12:37 -0800, david.hol...@oracle.com:
If multiple threads have to synchronize access to the buffer then the
reads/writes do not need to be atomic. Atomicity is only needed when
Aleksey,
Just curious - what's the driver for this? Suppose it did have full width
writes/reads - you still shouldn't use it in a data racey way since it's
not spec'd to be threadsafe and you can only observe torn reads/writes if
you access it without synchronization.
As others have suggested, I
But why would there be astonishment/surprise here if it says it's not
threadsafe? I guess that's the part I'm having trouble understanding.
Sent from my phone
On Dec 20, 2012 12:54 PM, Aleksey Shipilev aleksey.shipi...@oracle.com
wrote:
On 12/20/2012 09:49 PM, Vitaly Davidovich wrote:
Just
The astonishment comes from this:
a. racy Unsafe.putInt(...) to byte[] is atomic*
b. racy direct ByteBuffer.putInt(...) is atomic*
c. racy heap ByteBuffer.putInt(...) is NOT!
d. racy heap ByteBuffer.asIntBuffer().put(...) is NOT atomic again!
So then, the hacky code over the byte arrays
Hi Stuart,
the changes look fine to me. The only comments I have are to remove
the java.util.Properties import from JavaVM and possibly to use explicit
imports instead of * imports in JavaVM and StreamPipe.
Darryl
On 12/19/2012 05:11 PM, Stuart Marks wrote:
Hi all,
Please review the
Hi,
I've prepared a JDK 8 fix for 8003228 [1]. The webrev is here:
http://cr.openjdk.java.net/~bchristi/8003228/webrev.00/
JPRT passes on all platforms (with the exception of two known bugs[2]).
There was some recent discussion related to this - see [3].
Thanks,
-Brent
[1]
Hi,
Sorry for cross-list posting, but this change affects both HS and JDK.
This simple change is missing from recently committed CR 7023898. While
the VM support is there in Hotspot, no methods are exposed in Unsafe to
actually make use of those intrinsics. This is the webrev fixing that:
In the name of performance, go for it. :)
Vitaly
Sent from my phone
On Dec 20, 2012 1:22 PM, Aleksey Shipilev aleksey.shipi...@oracle.com
wrote:
The astonishment comes from this:
a. racy Unsafe.putInt(...) to byte[] is atomic*
b. racy direct ByteBuffer.putInt(...) is atomic*
c. racy
The small footprint XML parser that we pushed yesterday for use with
Properties isn't thread safe but the properties provider assumes that it
is. I should have spotted this before pushing the changes. The change to
fix it is trivial and I've added a basher test that duplicates it almost
On 12/20/12 12:01 PM, Alan Bateman wrote:
The small footprint XML parser that we pushed yesterday for use with
Properties isn't thread safe but the properties provider assumes that
it is. I should have spotted this before pushing the changes. The
change to fix it is trivial and I've added a
Changeset: edb71a37fcb7
Author:alanb
Date: 2012-12-20 20:29 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/edb71a37fcb7
8001048: JSR-160: Allow IIOP transport to be optional
Reviewed-by: dsamersoff, dfuchs, mchung
!
Changeset: eeda18683ddc
Author:alanb
Date: 2012-12-20 20:40 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eeda18683ddc
8005281: (props) loadFromXML/storeToXML with small parser is not thread safe
Reviewed-by: mchung
!
Hi Mandy,
I had much to do, guessed, all would be all-right.
I first had problems to find my proposed changes from 2012-12-15 in your code.
Now I found it. You did it even better
Just an additional nit in JDepsTask:
511 if (o.hasArg) {
512 String arg =
On 12/20/12 1:06 PM, Ulf Zibis wrote:
Hi Mandy,
I had much to do, guessed, all would be all-right.
I first had problems to find my proposed changes from 2012-12-15 in
your code.
Now I found it. You did it even better
Just an additional nit in JDepsTask:
511 if (o.hasArg) {
On 12/19/12 12:32 AM, Alan Bateman wrote:
On 17/12/2012 18:46, Rob McKenna wrote:
Hi folks,
This review contains:
8003898: X11 toolkit can be chosen as the default toolkit
7162111: TEST_BUG: change tests run in headless mode [macosx] (open)
8004928: TEST_BUG: Reduce dependence of CoreLib
Forgot a regtest - now included w/ v.01:
http://cr.openjdk.java.net/~bchristi/8003228/webrev.01/
Thanks,
-Brent
On 12/20/12 10:52 AM, Brent Christian wrote:
Hi,
I've prepared a JDK 8 fix for 8003228 [1]. The webrev is here:
http://cr.openjdk.java.net/~bchristi/8003228/webrev.00/
JPRT
On 21/12/2012 4:22 AM, Aleksey Shipilev wrote:
The astonishment comes from this:
a. racy Unsafe.putInt(...) to byte[] is atomic*
b. racy direct ByteBuffer.putInt(...) is atomic*
c. racy heap ByteBuffer.putInt(...) is NOT!
d. racy heap ByteBuffer.asIntBuffer().put(...) is NOT atomic
Hello all;
Here are some additional functional interfaces for review. The additions fill
in holes for primitive types and for two operand Bi operations.
http://cr.openjdk.java.net/~mduigou/8004561/0/webrev/
Hi Chris,
The specdiff is missing the Object variants for some reason.
Otherwise this looks pretty much as I remember it. :)
There is an open question as to whether MIN_ARRAY_SORT_GRAN should be
configurable/overridable.
Thanks,
David
On 21/12/2012 3:31 AM, Chris Hegarty wrote:
This is a
Request for review for extending the launcher support to allow the JavaFX
runtime to fully support all of it's launch features, including preloaders,
classpath, etc..
Webrev:
http://cr.openjdk.java.net/~ddehaven/8004547/webrev.1/
Corresponding JavaFX JIRA issue that these changes depend on:
FYI the Profiles forest has been updated to the jdk8-b69 level (the tags
are missing but it is b69).
This is the last sync-up of the Profiles forest with jdk8/jdk8.
We are preparing to integrate the Profiles changes with mainline using
the jdk8/build forest. Request for reviews will be issued
Changeset: 60adb69bf043
Author:smarks
Date: 2012-12-20 20:11 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60adb69bf043
8005290: remove -showversion from RMI test library subprocess mechanism
Reviewed-by: jgish, chegar, dmocek
! test/java/rmi/testlibrary/JavaVM.java
!
The Java SE 8 Compact Profiles:
http://openjdk.java.net/jeps/161
provides for subsetting of the Java SE 8 platform. While the
specification covers the platform, we are only providing a reference
implementation on Linux x86 at this time.
This work is covered by a number of CRs due to there
Hi,
This patch adds a couple APIs to java.util.logging.Logger so that
construction of log messages only occurs when it is actually to be
logged by using SupplierString instead of String.
Since the idea is to avoid unnecessary construction of log messages,
thus APIs imply formatting are not
Ah, good suggestion. I've cleaned up the imports in JavaVM.java and
StreamPipe.java.
s'marks
On 12/20/12 10:36 AM, Darryl Mocek wrote:
Hi Stuart,
the changes look fine to me. The only comments I have are to remove the
java.util.Properties import from JavaVM and possibly to use explicit
Hi David,
On 12/20/2012 7:17 PM, David DeHaven wrote:
Request for review for extending the launcher support to allow the JavaFX
runtime to fully support all of it's launch features, including preloaders,
classpath, etc..
Webrev:
http://cr.openjdk.java.net/~ddehaven/8004547/webrev.1/
44 matches
Mail list logo
