RE: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions

+1, nice fix. > -Original Message- > From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf > Of Joe Wang > Sent: Mittwoch, 17. August 2016 18:30 > To: Aleks Efimov > Cc: core-libs-dev > Subject: Re: RFR

Fork/Join exceptional completion can return before all tasks have finished executing Re: Exceptional behavior of parallel stream

Hi Tagir, Hmm… we certainly ensure that any short-circuiting computation will wait until all the computation is complete (tasks still running whose results will be thrown away have to complete before the terminal operation returns). In that sprit we should be consistent when exceptions are

RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle

Hi, please review this change which adds pre-generation of simple DelegatingMethodHandles corresponding to the DirectMethodHandles we already pre-generate during linking. webrev: http://cr.openjdk.java.net/~redestad/8164044/webrev.02/ bug: https://bugs.openjdk.java.net/browse/JDK-8164044

Re: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are incorrect

Brent, hotspot/src/share/vm/prims/stackwalk.cpp: 230 if (!expressions && 231 values->at(i)->type() == T_INT && 232 values->int_at(i) == 0 && // empty first slot of long? 233 i+1 < values->size() && 234 values->at(i+1)->type() == T_INT) { How does this

RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are incorrect

Hi, Please review this StackWalker fix in hotspot for 8156073, "2-slot LiveStackFrame locals (long and double) are incorrect" Bug: https://bugs.openjdk.java.net/browse/JDK-8156073 Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.01/ The experimental LiveStackFrame[1] interface for

Re: Collectors.toSet() small performance improvement

> On 16 Aug 2016, at 20:08, Tagir F. Valeev wrote: > > Hello, Paul! > > Thank you. Here's issue: > https://bugs.openjdk.java.net/browse/JDK-8164189 > And webrev: > http://cr.openjdk.java.net/~tvaleev/webrev/8164189/r1/ > Thanks will push today or tomorrow, Paul. > With

Re: RFR 9 7180225 : SecurityExceptions not defined in some class loader methods

On 8/16/16 8:33 PM, Mandy Chung wrote: On Aug 16, 2016, at 1:54 PM, Brent Christian wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-7180225 Webrev: http://cr.openjdk.java.net/~bchristi/7180225/webrev.01/webrev/ Specdiff:

Re: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions

Looks good, Aleksej. Thanks for coming up with a well-thought solution to get rid of the static RE field. Best, Joe On 8/17/16, 7:04 AM, Aleks Efimov wrote: Hi Joe, Aleksey, Thank you for reviewing the initial fix. I followed the Joe's suggestion (thanks for that) and removed static 'abort'

Re: RFR 9 7180225 : SecurityExceptions not defined in some class loader methods

Looks fine to me. --Sean On 08/16/2016 02:54 PM, Brent Christian wrote: Hi, Please review this change which does some cleanup around documenting conditions for throwing SecurityExceptions. It adds a missing @throws tag to Class.forName(String, boolean, ClassLoader), and consolidates

Re: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions

Hi Joe, Aleksey, Thank you for reviewing the initial fix. I followed the Joe's suggestion (thanks for that) and removed static 'abort' field completely, the functionality was replaced by throwing the exception of newly added type - AbortException. The new webrev with removed 'abort' can be

Re: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

Hi Kim, On 08/15/2016 05:15 AM, Kim Barrett wrote: >I have a feeling that these pauses are now unnecessary. Will try to check with some experiments… I found that the DirectBufferAllocTest will sometimes fail if the pauses are taken out. I think what’s going on is that the multiple threads

Exceptional behavior of parallel stream

Hello! I found no information in Stream API documentation on how it behaves in case if exception occurs during the stream processing. While it's quite evident for sequential stream (stream processing is terminated and exception is propagated to the caller as is), the behavior for parallel streams

Re: RFR: 6543126: Level.known can leak memory

Hi Peter, On 17/08/16 12:20, Peter Levart wrote: Hi Daniel, Thinking of this patch from the compatibility standpoint, aren't you afraid that someone might be using the following idiom: public class MyLevel extends java.util.logging.Level { static { new MyLevel("LEVEL1", 1);

Re: RFE to re-purpose option --version:

On 10/08/2016 23:46, Martin Buchholz wrote: On Wed, Aug 10, 2016 at 11:52 AM, Paul Benedict wrote: Martin, what do you have in mind when saying it's "broken"? Functionally, everything is fine -- I can delete "release" locally without issue (so it appears) -- so I

Re: RFR: 6543126: Level.known can leak memory

On 08/17/2016 01:20 PM, Peter Levart wrote: You could use a ClassLoaderValue for this purpose, like in the following addition to your patch (see KnownLevel.add): http://cr.openjdk.java.net/~plevart/jdk9-dev/Level.known/webrev.01/ Note that the above also contains the functional-style

Re: RFR: 6543126: Level.known can leak memory

On 08/17/2016 01:16 PM, Daniel Fuchs wrote: Now that you have various findByXXX methods return Optional, you could make methods that use them more Optional-API-powered. For example, findLevel could be written as a single expression: Right. But do you mind if I leave that for another day?

Re: RFR: 6543126: Level.known can leak memory

Hi Daniel, Thinking of this patch from the compatibility standpoint, aren't you afraid that someone might be using the following idiom: public class MyLevel extends java.util.logging.Level { static { new MyLevel("LEVEL1", 1); new MyLevel("LEVEL2", 2); ... }

Re: RFR: 6543126: Level.known can leak memory

Hi Peter, Now that you have various findByXXX methods return Optional, you could make methods that use them more Optional-API-powered. For example, findLevel could be written as a single expression: Right. But do you mind if I leave that for another day? I'm not too keen on multi-line code

Re: RFR: 6543126: Level.known can leak memory

Hi Peter, Rereading the comment and looking at the code I see that the comment is actually right. There are two methods with similar names: Level.getLocalizedName() which can be overridden by subclasses and Level.getLocalizedLevelName() which cannot. By default Level.getLocalizedName() calls

Re: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration

On 17.08.2016 01:50, Paul Sandoz wrote: > On 8 Aug 2016, at 12:14, Patrick Reinhart wrote: >> Am 08.08.2016 um 18:55 schrieb Alan Bateman : >>> On 08/08/2016 17:29, Patrick Reinhart wrote: >>> : I tried to integrate your suggested changes

Re: RFR: 6543126: Level.known can leak memory

Hi Mandy, On 17/08/16 05:05, Mandy Chung wrote: On Aug 16, 2016, at 5:42 AM, Daniel Fuchs wrote: > > Hi Mandy, > > I added an additional selector parameter to the find methods. > This made it possible to return Optional instead of > KnownLevel - and it does simply the