Thumbs up!
Thanks,
David
On 25/02/2015 2:17 AM, Kumar Srinivasan wrote:
Hi David,
comments inlined.
Hi Kumar,
On 24/02/2015 8:14 AM, Kumar Srinivasan wrote:
Hello,
Please review the fix for the above issue.
Webrev:
http://cr.openjdk.java.net/~ksrini/8066185/webrev.00/
The fix is self ex
On Feb 24, 2015, at 7:49 AM, Andrew Haley wrote:
>
>>
>> There will be only one runtime Unsafe sub-type ever observed in a
>> particular VM.
>
> Oh, that's very nice.
That doesn't help with B accesses on L platforms and vice versa.
Having an optional boolean parameter (gating reverseBytes) wi
On Feb 23, 2015, at 10:13 AM, Andrew Haley wrote:
>
> I've been kicking around a few ideas for Unsafe access methods for
> unaligned access to byte arrays and buffers in order to provide
> "whatever second-best mechanism the platform offers". These would
> provide the base for fast lexicographic
I'm not sure I'm convincing anyone other than myself, but here's another
try:
"recover" means taking any action at all, the most common of which is ...
nothing!
Perhaps a product feature simply becomes "grayed out" when running a
process fails.
>From a WORA developer's point of view, it is irrelev
This fix looks fine.
--Sean
On 02/20/2015 01:54 PM, Mandy Chung wrote:
This fixes a regression due to JDK-8057645 moving JAXB to ext loader
that was tested before the fix for JDK-8054367 went in jdk9. This
was uncovered after JDK-8057645and JDK-8054367 met.
The fix is simple. Class.getDeclar
Approved!
On Tue, Feb 24, 2015 at 8:44 AM, Ivan Gerasimov
wrote:
> Hi!
>
> A typo populated over a few places.
>
> Fix: s/StackOverflowException/StackOverflowError/g
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8073779
> WEBREV: http://cr.openjdk.java.net/~igerasim/8073779/0/webrev/
>
>
Can you add 5.1 to your list ? :)
If we had AOT, small methods will be inlined and sharing their profile in that
case seems just wrong.
As you said it will also make tiered compilation smarter.
Rémi
Le 22 février 2015 01:58:02 CET, John Rose a écrit :
>All of the proposed tweaks to null check
Kumar,
This looks good to me. I didn't review all the changes in the test very
carefully, so someone else should vouch for that.
Thank you for fixing this!
Coleen
On 2/23/15, 9:09 PM, David Holmes wrote:
Hi Kumar,
On 24/02/2015 8:14 AM, Kumar Srinivasan wrote:
Hello,
Please review the
On 24/02/2015 17:08, Ivan Gerasimov wrote:
Right. I shouldn't have pushed it that quick. Sigh
Nothing important. Just thought it might be a useful step while you were
there! It's something we can keep in mind for a later fix.
regards,
Sean.
On 24.02.2015 19:53, Seán Coffey wrote:
Nice catc
Right. I shouldn't have pushed it that quick. Sigh
On 24.02.2015 19:53, Seán Coffey wrote:
Nice catch Ivan. You could also clean up the typo in various test
cases relating to it also perhaps :
langtools/test/tools/javac/generics/inference/8043725/T8043725.java
jdk/test/java/util/Hashtable/Self
Nice catch Ivan. You could also clean up the typo in various test cases
relating to it also perhaps :
langtools/test/tools/javac/generics/inference/8043725/T8043725.java
jdk/test/java/util/Hashtable/SelfRef.java
jdk/test/javax/swing/border/Test6461042.java
langtools/test/tools/javac/defaultMetho
Thanks!
pushed.
On 24.02.2015 19:46, Martin Buchholz wrote:
Approved!
On Tue, Feb 24, 2015 at 8:44 AM, Ivan Gerasimov
mailto:ivan.gerasi...@oracle.com>> wrote:
Hi!
A typo populated over a few places.
Fix: s/StackOverflowException/StackOverflowError/g
BUGURL: https://bugs.
Hi!
A typo populated over a few places.
Fix: s/StackOverflowException/StackOverflowError/g
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8073779
WEBREV: http://cr.openjdk.java.net/~igerasim/8073779/0/webrev/
Sincerely yours,
Ivan
Hi David,
comments inlined.
Hi Kumar,
On 24/02/2015 8:14 AM, Kumar Srinivasan wrote:
Hello,
Please review the fix for the above issue.
Webrev:
http://cr.openjdk.java.net/~ksrini/8066185/webrev.00/
The fix is self explanatory, as for the test I have done the following:
I found the comment
On 02/24/2015 03:40 PM, Peter Levart wrote:
> On 02/24/2015 02:48 PM, Andrew Haley wrote:
private static final boolean IS_UNALIGNED = theUnsafe.unalignedAccess();
public void putIntUnaligned(Object o, long offset, int x) { if
(IS_UNALIGNED || (offset & 3) == 0) { putInt(o, offs
On 02/24/2015 02:48 PM, Andrew Haley wrote:
>private static final boolean IS_UNALIGNED = theUnsafe.unalignedAccess();
>
>public void putIntUnaligned(Object o, long offset, int x) { if (IS_UNALIGNED ||
(offset & 3) == 0) { putInt(o, offset, x); } else if (byteOrder == BIG_ENDIAN) {
putIntB(o, of
On Feb 24, 2015, at 3:59 PM, Andrew Haley wrote:
>
If we expose the endianness query via a new method in unsafe we
should reuse that in java.nio.Bits and get rid of the associated
static code block.
>>>
>>> Sure, I already did that.
>>>
>>
>> Locally i guess? (just in case i mis
On 24 Feb 2015, at 11:45, Peter Levart wrote:
>> ...
>>> - You are tracking the requiresFreeze flag in readSerialData() method for
>>> each class slot the deserialized object is composed of. This can be
>>> optimized and the 'hasFinalField' flag pre-computed for the whole object
>>> (all slots
On 02/24/2015 02:47 PM, Paul Sandoz wrote:
> On Feb 24, 2015, at 2:48 PM, Andrew Haley wrote:
>>> With that in mind is there any need to intrinsify the new methods
>>> at all given those new Java methods can defer to the older ones
>>> based on a constant check? Also should that anyway be done fo
On Feb 24, 2015, at 2:48 PM, Andrew Haley wrote:
>>
>> I am all for keeping more code in Java if we can. I don't know enough about
>> assembler-based optimizations to determine if it might be possible to do
>> better on certain CPU architectures.
>
> Me either, but I have tested this on the ar
Hi,
On 02/24/2015 11:16 AM, Paul Sandoz wrote:
> This looks like a good start.
Good, thanks.
> On Feb 23, 2015, at 7:13 PM, Andrew Haley wrote:
>
>> I've been kicking around a few ideas for Unsafe access methods for unaligned
>> access to byte arrays and buffers in order to provide "whatever
Hello Peter
Le 24/02/15 13:49, Peter Levart a écrit :
> You could synchronize on the entire loop and just copy over the
> service objects to another collection (say ArrayList).
Right, but I would like to keep the laziness instantiation behaviour.
> If you really must combine laziness of constru
On 02/24/2015 10:32 AM, Martin Desruisseaux wrote:
Le 24/02/15 09:09, Alan Bateman a écrit :
Right, it has never supported multiple iterators but as it's an
Iterable then it should unless specified otherwise. So I think this is
a bug (although one could argue that the usage is unusual, almost a
On 02/24/2015 11:16 AM, Daniel Fuchs wrote:
Hi Peter,
On 24/02/15 10:00, Stephen Colebourne wrote:
On 23 February 2015 at 22:27, Peter Levart
wrote:
What about the following idea:
- create a (maybe still package-private) instance method
ZoneId.getSystemClock() and cache the per-ZoneId Clock
Hi Chris,
On 02/24/2015 11:53 AM, Chris Hegarty wrote:
Peter,
On 23 Feb 2015, at 21:08, Peter Levart wrote:
Hi Chris,
On 02/23/2015 12:01 PM, Chris Hegarty wrote:
Peter, David, Vitaly,
Can you please take a look at the latest version of this change:
http://cr.openjdk.java.net/~chegar/
Looks good Daniel.
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Sent from my iPad
> On Feb 24, 2015, at 5:59 AM, Daniel Fuchs wrote:
>
>> On 23/02/15 21:40, Stephen Colebourne wro
Thanks for the change. This reviewer is happy.
Stephen
On 24 February 2015 at 10:59, Daniel Fuchs wrote:
> On 23/02/15 21:40, Stephen Colebourne wrote:
>>
>> The rest of the java.time code tends to put the data provider method
>> before the test, and mostly uses a naming convention of
>> "data_sy
Hi,
Here is a fix for an issue with repeating annotations when a security manager
is set.
Fix is to use the Proxy invocation handler to unwrap the array containing the
repeating annotations. In theory it might be possible to have instances of
Annotations that are not implemented using Proxies,
I've updated summary and description.
Lev
On 02/23/2015 04:55 AM, David Holmes wrote:
On 20/02/2015 7:57 PM, Lev Priima wrote:
Functional is pretty same, but:
- make it run with a single argument '67108864' by moving @summary tag
strait down to line after the @run tag
- '-Xmx385' ->'-Xms38
David,
On 2015-02-24 05:23, David Holmes wrote:
> On 24/02/2015 12:02 AM, Dmitry Samersoff wrote:
>> Hi Everyone,
>>
>> Webrev updated in-place (press shift-reload)
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8073584/webrev.01/
>
> share/native/libunpack/jni.cpp
>
> 295 return (jobject)
Le 24/02/15 09:09, Alan Bateman a écrit :
> Right, it has never supported multiple iterators but as it's an
> Iterable then it should unless specified otherwise. So I think this is
> a bug (although one could argue that the usage is unusual, almost a
> mis-use).
One use case is that in a multi-th
On 24 Feb 2015, at 00:58, Mandy Chung wrote:
> In fact, find another redundant in jdk.httpserver. I have updated the
> synopsis of JDK-8073696 to remove redundant imports in java.corba and
> jdk.httpserver
>
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8073696/webrev.00/
Looks good to
On 23 February 2015 at 22:27, Peter Levart wrote:
> What about the following idea:
>
> - create a (maybe still package-private) instance method
> ZoneId.getSystemClock() and cache the per-ZoneId Clock instance inside the
> ZoneId.
> - Clock.system(ZoneId) static method is then just delegating to
>
On Feb 23, 2015, at 10:08 PM, Peter Levart wrote:
>
> - We have to be careful with "loosening" of volatile writes to final fields
> in custom readObject() methods (BigDecimal.intCompact for example) especialy
> if they are writes to fields that are not serial fields in ObjectStreamClass
> (eit
On 24/02/2015 00:58, Mandy Chung wrote:
In fact, find another redundant in jdk.httpserver. I have updated
the synopsis of JDK-8073696 to remove redundant imports in java.corba
and jdk.httpserver
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8073696/webrev.00/
Mandy
Looks okay to me.
-A
On 24/02/2015 01:32, David Holmes wrote:
On 24/02/2015 12:20 AM, Martin Desruisseaux wrote:
Hello all
java.util.ServiceLoader does not seem to support usage of a second
Iterator in the middle of a previous iteration.
Nope it doesn't. At a minimum this should be documented. The distinct
Itera
36 matches
Mail list logo
