Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

2017-03-12 Thread Ralph Goers
Sorry for not getting back sooner but I finally found some time to follow up. I took a look at https://www.sitepoint.com/deep-dive-into-java-9s-stack-walking-api/ and modified the benchmarks that were used there to add a few

RE: RFR 9: 8165641 : Deprecate Object.finalize

2017-03-12 Thread Uwe Schindler
Hi, > >> I guess "difficulty in properly triggering GC for non-memory resource > >> exhaustion" is closest to what I just described. > > > > This has long been an issue in the Java client area where native desktop > > resources or the like need to be managed carefully, but it is not just > >

Re: Shouldn't InputStream/Files::readAllBytes throw something other than OutOfMemoryError?

2017-03-12 Thread Christoph Engelbert
Hey Anthony, Fair point though. Guess it might be just for consistency, with existing behavior. Anyhow your explanation makes sense, let’s hope it’ll be a temporary limitation as we’re seeing Arrays 2.0 on the horizon and most most most probably will offer 64bit array indexes :-) Chris > On

Re: RFR 9: 8165641 : Deprecate Object.finalize

2017-03-12 Thread Andrew Haley
On 12/03/17 16:40, Philip Race wrote: > > On 3/12/17, 3:07 AM, Andrew Haley wrote: >> I guess "difficulty in properly triggering GC for non-memory resource >> exhaustion" is closest to what I just described. > > This has long been an issue in the Java client area where native desktop > resources

Re: Shouldn't InputStream/Files::readAllBytes throw something other than OutOfMemoryError?

2017-03-12 Thread Anthony Vanelverdinghe
Hi Chris Point well taken, but being unable to create a native thread is definitely a VirtualMachineError, and personally I don't care whether the JVM throws an OOME or any other kind of VirtualMachineError in that case. My point was that I don't see how being unable to return a result

Re: RFR 9: 8165641 : Deprecate Object.finalize

2017-03-12 Thread Philip Race
On 3/12/17, 3:07 AM, Andrew Haley wrote: I guess "difficulty in properly triggering GC for non-memory resource exhaustion" is closest to what I just described. This has long been an issue in the Java client area where native desktop resources or the like need to be managed carefully, but it

Re: RFR: 8176508 Update JAX-WS RI integration to latest version

2017-03-12 Thread Alan Bateman
On 12/03/2017 14:39, Roman Grigoriadi wrote: Hi, Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. JBS: https://bugs.openjdk.java.net/browse/JDK-8176508 Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/00/ I skimmed the changes and have a few

Re: Shouldn't InputStream/Files::readAllBytes throw something other than OutOfMemoryError?

2017-03-12 Thread Christoph Engelbert
Hey Anthony, The meaning is already overloaded, as "Cannot create native thread" is also an OutOfMemoryError and in like 99% of the cases means "Linux ran out of filehandles". The chance the OS really couldn't allocate a thread for the reason of no main memory available is very narrow :) Chris

RFR: 8176508 Update JAX-WS RI integration to latest version

2017-03-12 Thread Roman Grigoriadi
Hi, Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. JBS: https://bugs.openjdk.java.net/browse/JDK-8176508 Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/00/ Summary of changes: jaxws/src/java.activation/share/classes/javax/activation/* These are

Shouldn't InputStream/Files::readAllBytes throw something other than OutOfMemoryError?

2017-03-12 Thread Anthony Vanelverdinghe
Files::readAllBytes is specified to throw an OutOfMemoryError "if an array of the required size cannot be allocated, for example the file is larger that 2G". Now in Java 9, InputStream::readAllBytes does the same. However, this overloads the meaning of OutOfMemoryError: either "the JVM is out

Re: RFR 9: 8165641 : Deprecate Object.finalize

2017-03-12 Thread Andrew Haley
On 11/03/17 18:56, Hans Boehm wrote: > > Stepping back, I'm a little surprised at the deprecation. In my opinion, > the problems with finalizers are, in rough order of significance: I would have thought the most significant problem with finalizers is that finalizers may never run unless the

Re: RFR 9: 8165641 : Deprecate Object.finalize

2017-03-12 Thread Andrew Haley
On 11/03/17 11:08, Alan Bateman wrote: > On 11/03/2017 07:59, Andrew Haley wrote: > >> : >> Wow. I totally agree with the sentiment, but it's a bit late in the >> JDK 9 timeframe to be talking about this. Has this been discussed >> internally within Oracle for some time? > For years, long