Re: RFR 8073124: Tune test and document TimSort runs length stack size increase

On 17/02/2015 3:43 PM, Lev Priima wrote: Thanks David! Is this expected behavior of this annotation ? Yes that is the way jtreg defines tags: http://openjdk.java.net/jtreg/tag-spec.html "The argument tokens of a tag extend from the first token after the tag token to the end of the comment, t

Re: RFR 8072466: Deadlock when starting MulticastSocket and DatagramSocket

Can someone help review this fix please? Comments/suggestions are welcome! Sincerely yours, Ivan On 06.02.2015 20:48, Ivan Gerasimov wrote: Hello! There has been a deadlock in jdk-net code noticed on Windows. In the bug description there's a stack snippet showing that one of the deadlocked

Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces

On Feb 16, 2015, at 10:33 PM, Staffan Larsen wrote: > > The first shot at fixing this bug was to filter out ACC_SYNTHETIC. The > drawback was that the actual lambda method are marked ACC_SYNTHETIC, so that > filtered too much. OTOH it seems odd to filter out the actual interface method. Idea

Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces

> On 17 feb 2015, at 02:16, John Rose wrote: > > On Feb 16, 2015, at 6:25 AM, Staffan Larsen > wrote: >> >> new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.02/ >> > Looks good; ship it. Thanks.

Re: RFR 8073124: Tune test and document TimSort runs length stack size increase

Thanks David! Is this expected behavior of this annotation ? Lev On 02/17/2015 03:20 AM, David Holmes wrote: On 16/02/2015 9:20 PM, David Holmes wrote: On 16/02/2015 6:59 PM, Lev Priima wrote: Thanks, David, Could you please push it ? I will if Roger doesn't get to it first. It'll be 11 hou

Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses

On Feb 14, 2015, at 12:01 AM, Andrew Haley wrote: > > On 02/14/2015 12:09 AM, John Rose wrote: >> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever >> second-best mechanism the platform offers. > > Indeed. I'm intending to prototype a design for those next week. OK?

RE: RFR: 8072645: java.util.logging should use java.time to get more precise time stamps

Daniel, I agree with you that removing the new XMLFormatter constructor is the right thing to do in this case. Jason > Date: Sat, 14 Feb 2015 13:06:21 +0100 > From: daniel.fu...@oracle.com > To: jason_mehr...@hotmail.com; core-libs-dev@openjdk.java.net > Su

Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces

On Feb 16, 2015, at 6:25 AM, Staffan Larsen wrote: > > new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.02/ > Looks good; ship it. To me this fix raises more questions: 1. Are there other places where we generate ACC_SYNTHETIC that

Re: RFR 8073124: Tune test and document TimSort runs length stack size increase

On 16/02/2015 9:20 PM, David Holmes wrote: On 16/02/2015 6:59 PM, Lev Priima wrote: Thanks, David, Could you please push it ? I will if Roger doesn't get to it first. It'll be 11 hours before I can push it. This has been pushed but note there is a minor issue with the test. The jtreg tag sp

Re: RFR: JDK-8073152: Update Standard/ExtendedCharsets to work with module system

Am 16.02.2015 um 19:46 schrieb Xueming Shen: On 2/16/15 4:11 AM, Alan Bateman wrote: 2. Hasher.java is showing up in the webrev as a new file, was this build.tools.hasher.Hasher and so we know have two copies? "This" Hasher.java has a different use interface and works on a pair of key/value list

[9] RFR of 8073207: javadoc typos in java.nio.channels.Pipe

Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8073207 Patch: http://cr.openjdk.java.net/~bpb/8073207/webrev.00/ Simply implements what the description suggests. Thanks, Brian

Re: RFR: JDK-8073152: Update Standard/ExtendedCharsets to work with module system

On 16/02/2015 18:46, Xueming Shen wrote: : 1. Is list_old needed, I can't tell if this is checked in for use by future archaeologists. No, it's not used by any code. I just added it the last minute to be a reference for the future, as I'm deleting the original list sbcs, dbcs and extsbcs.

Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces

yes, thumb up ! Rémi Le 16 février 2015 18:50:25 CET, "Joel Borggrén-Franck" a écrit : >+1 > >cheers >/Joel > >> On 16 Feb 2015, at 15:25, Staffan Larsen >wrote: >> >> Good point! >> >> new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.02/ >> >> Thanks, >> /Staffan >> >>> On 16 f

Re: RFR: 8072645: java.util.logging should use java.time to get more precise time stamps

Hi Stephen, Thanks again for your support and suggestions! On 14/02/15 14:03, Daniel Fuchs wrote: If I'm not mistaken the previous SimpleFormatter used to use java.util.Date and printed the time in the local time zone. I have tried to keep this behavior. I'm not sure we would want to change it

Re: RFR: JDK-8073152: Update Standard/ExtendedCharsets to work with module system

On 2/16/15 4:11 AM, Alan Bateman wrote: On 14/02/2015 20:30, Xueming Shen wrote: Hi, Please help review the changes for JDK-8073152 Issue: https://bugs.openjdk.java.net/browse/JDK-8073152 Webrev: http://cr.openjdk.java.net/~sherman/8073152/webrev/ This change is to re-organize how the "stand

Re: 8068680: Move java.transaction to the ext class loader

Looks good. We will want to deprivilege a few more modules and move them to the extension loader. That'll be something for the future. Mandy On 2/16/2015 9:28 AM, Alan Bateman wrote: Now that the types in the java.corba module are moved to the extension loader, it is time to move java.tran

Re: 8068680: Move java.transaction to the ext class loader

Looks fine Alan On Feb 16, 2015, at 12:28 PM, Alan Bateman wrote: > > Now that the types in the java.corba module are moved to the extension > loader, it is time to move java.transaction and further our quest to move all > of the EE/upgradeable modules to the ext loader. This one is easy as th

Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces

+1 cheers /Joel > On 16 Feb 2015, at 15:25, Staffan Larsen wrote: > > Good point! > > new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.02/ > > Thanks, > /Staffan > >> On 16 feb 2015, at 12:40, Remi Forax wrote: >> >> Hi Staffan, >> ASM MethodVisitor API requires to call visitAnno

8068680: Move java.transaction to the ext class loader

Now that the types in the java.corba module are moved to the extension loader, it is time to move java.transaction and further our quest to move all of the EE/upgradeable modules to the ext loader. This one is easy as there isn't any permissions and other security adjustments needed. It's jus

Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces

Good point! new webrev: http://cr.openjdk.java.net/~sla/8025636/webrev.02/ Thanks, /Staffan > On 16 feb 2015, at 12:40, Remi Forax wrote: > > Hi Staffan, > ASM MethodVisitor API requires to call visitAnnotation before calling > visitCode s

Re: JEP 102 Process Updates revised API draft

On 02/13/2015 04:34 PM, Peter Levart wrote: On 02/13/2015 04:18 PM, David M. Lloyd wrote: I hesitate to mention it, but as someone who has been frustrated by this same problem on numerous occasions I feel I must suggest that maybe... having a completableFuture method should just be dropped?

Re: RFR: JDK-8073152: Update Standard/ExtendedCharsets to work with module system

On 14/02/2015 20:30, Xueming Shen wrote: Hi, Please help review the changes for JDK-8073152 Issue: https://bugs.openjdk.java.net/browse/JDK-8073152 Webrev: http://cr.openjdk.java.net/~sherman/8073152/webrev/ This change is to re-organize how the "standard" and "extended" charsets repository

Re: RFR: JDK-8025636 Hide lambda proxy frames in stacktraces

Looks good. Best regards, Vladimir Ivanov On 2/16/15 10:47 AM, Staffan Larsen wrote: Brian pointed out to me that this change missed to add the annotation to bridge methods. Here is an updated version that takes those into account. I also needed to update the test to verify that bridge method

Re: RFR 8073124: Tune test and document TimSort runs length stack size increase

On 16/02/2015 6:59 PM, Lev Priima wrote: Thanks, David, Could you please push it ? I will if Roger doesn't get to it first. It'll be 11 hours before I can push it. David Lev On 02/16/2015 08:55 AM, David Holmes wrote: On 14/02/2015 12:03 AM, Lev Priima wrote: Please review and push: htt

Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses

On 02/16/2015 11:02 AM, Alan Bateman wrote: > On 14/02/2015 22:10, Dean Long wrote: >> >> Even if linux-aarch64 always allows unaligned, checking only for >> "aarch64" is not future-proof >> because it doesn't take the OS into account. However, I really don't >> like having to enumerate >> all r

Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses

On 14/02/2015 22:10, Dean Long wrote: Even if linux-aarch64 always allows unaligned, checking only for "aarch64" is not future-proof because it doesn't take the OS into account. However, I really don't like having to enumerate all relevant platforms in multiple places in shared code, so I di

Re: RFR: JDK-8073152: Update Standard/ExtendedCharsets to work with module system

(adding build-dev) Hello Sherman, In Gensrc-jdk.charsets.gmk: * The variable CHARSET_EXTENDED is defined but never used. The value is used in several places however. I think you should either use the variable or not define it at all. * $(CHARSET_EXTENDED_DATA) is put on a prerequisite line, bu

Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses

On 14/02/15 22:10, Dean Long wrote: > On 2/14/2015 12:07 AM, Andrew Haley wrote: >> On 02/13/2015 10:52 PM, Dean Long wrote: >> >>> My understanding is that whether or not aarch64 allows unaligned >>> accesses is based on a system setting, so this change is too >>> simplistic. >> >> Disabling unali

Re: RFR 8073124: Tune test and document TimSort runs length stack size increase

Thanks, David, Could you please push it ? Lev On 02/16/2015 08:55 AM, David Holmes wrote: On 14/02/2015 12:03 AM, Lev Priima wrote: Please review and push: http://cr.openjdk.java.net/~lpriima/8073124/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8073124 I hadn't realized 8072909 h