Re: RFR (s): 4354680: Runtime.runFinalization() silently clears interrupted flag in the calling thread

> Aside, I noticed in this code: > > 146 forkSecondaryFinalizer(new Runnable() { > 147 private volatile boolean running; > 148 public void run() { > 149 if (running) > 150 return; > 151 final JavaLangAccess jl

Re: RFR (s): 4354680: Runtime.runFinalization() silently clears interrupted flag in the calling thread

On 10/29/14 7:22 PM, David Holmes wrote: Hi Stuart, You're a brave man! :) :-) Right - there is no change in behaviour with your change other than fixing the problem with the cleared interrupt bit. That's the best you can do in my opinion. OK, after thinking about it, I was starting to le

Re: RFR (M) 8061651 - Interface to the Lookup Index Cache to improve URLClassPath search time (round 3)

OK, here's the latest version. I removed the synchronization but kept the resolveClass just for completeness, even if it currently does nothing. class Launcher$AppClassLoader { public Class loadClass(String name, boolean resolve) throws ClassNotFoundException

Re: RFR 9 8062513: doclint warnings in HijrahChronology

Looks good; thanks Roger, -Joe On 10/29/2014 7:28 PM, roger riggs wrote: Please review a correction to address a doclint warning in HijrahChronology. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-doclint-8062513/ Issue: 8062513: doclint warnings in HijrahChronology Thanks, Roger

RFR 9 8062513: doclint warnings in HijrahChronology

Please review a correction to address a doclint warning in HijrahChronology. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-doclint-8062513/ Issue: 8062513: doclint warnings in HijrahChronology Thanks, Roger

Re: RFR (s): 4354680: Runtime.runFinalization() silently clears interrupted flag in the calling thread

Hi Stuart, You're a brave man! :) On 30/10/2014 11:04 AM, Stuart Marks wrote: Hi all, Please review this small change that fixes this bug in System.runFinalization() and Runtime.runFinalization(). Bug: https://bugs.openjdk.java.net/browse/JDK-4354680 Webrev: http://cr.openjdk.java.net/~

RFR (s): 4354680: Runtime.runFinalization() silently clears interrupted flag in the calling thread

Hi all, Please review this small change that fixes this bug in System.runFinalization() and Runtime.runFinalization(). Bug: https://bugs.openjdk.java.net/browse/JDK-4354680 Webrev: http://cr.openjdk.java.net/~smarks/reviews/4354680/webrev.0/ This is probably the simplest approach, which

Re: Losing features of JVM_Open, e.g. CLOEXEC

On 30/10/2014 7:15 AM, Mario Torre wrote: +1 We should have spotted it in the review though. My thoughts exactly! Further only 2 calls were changed both in the zip code, while raw open is used in quite a number of other places in the JDK code. So while I can understand there may be a desire

Re: RFR 7156085: ArrayIndexOutOfBoundsException throws in UTF8Reader of SAXParser

On 10/29/2014 3:59 PM, Martin Buchholz wrote: On Wed, Oct 29, 2014 at 2:37 PM, huizhe wang > wrote: Hi Martin, You're welcome in the jaxp land :-) Bandaid is what we need for now. There are many things we would like to do to this aging code b

Re: Loading classes with many methods is very expensive

Hi Peter, The removal of value wrapper is a clever approach to reduce the new instances created although it feels very unnatural (at least to me). Small optimization; eagerly calculate the hash in the c'tor, hash = 149 method.getReturnType().hashCode() ^ 150 Syst

Re: RFR 7156085: ArrayIndexOutOfBoundsException throws in UTF8Reader of SAXParser

On Wed, Oct 29, 2014 at 2:37 PM, huizhe wang wrote: > Hi Martin, > > You're welcome in the jaxp land :-) Bandaid is what we need for now. > There are many things we would like to do to this aging code base, > unfortunately, we have to focus on a few. > > The change looks okay. I did a full-test

Re: RFR 7156085: ArrayIndexOutOfBoundsException throws in UTF8Reader of SAXParser

Hi Martin, You're welcome in the jaxp land :-) Bandaid is what we need for now. There are many things we would like to do to this aging code base, unfortunately, we have to focus on a few. The change looks okay. I did a full-test run and saw no failures. One thing to note is that the SQE t

Re: Losing features of JVM_Open, e.g. CLOEXEC

+1 We should have spotted it in the review though. Cheers, Mario Il 29/ott/2014 21:47 "Christos Zoulas" ha scritto: > On Oct 29, 1:12pm, marti...@google.com (Martin Buchholz) wrote: > -- Subject: Losing features of JVM_Open, e.g. CLOEXEC > > | throwing away use of old shared infrastructure and

Re: Losing features of JVM_Open, e.g. CLOEXEC

On Oct 29, 1:12pm, marti...@google.com (Martin Buchholz) wrote: -- Subject: Losing features of JVM_Open, e.g. CLOEXEC | throwing away use of old shared infrastructure and replacing with "naked" | calls to the OS. Although understandable, this abandons benefits of using | shared infrastructure.

Losing features of JVM_Open, e.g. CLOEXEC

Hi guys, In your change 805: Cleanup of old and unused VM interfaces you have made changes like this: -zfd = JVM_Open(path, flag, 0); +zfd = open(path, flag, 0); throwing away use of old shared infrastructure and replacing with "naked" calls to the OS. Although und

Re: inconsistency between Class.getMethod and Class.getMethods Was: Loading classes with many methods is very expensive

Hi Peter, On 29 Oct 2014, at 18:16, Peter Levart wrote: > On 10/29/2014 02:08 PM, Joel Borggrén-Franck wrote: >> Hi Peter, >> >> I’m not entirely convinced this is a bug. >> >> The lookup order for getMethod has for a long time been walk up superclasses >> and return what you find there first

Re: RFR (M) 8061651 - Interface to the Lookup Index Cache to improve URLClassPath search time (round 3)

On 10/29/2014 7:16 AM, Karen Kinnear wrote: Sorry, I was confused about who wrote what. Sounds like David and I are in agreement that you can remove the synchronization - I believe that would be much cleaner. I agree that the class loader lock is not really needed in the knownToNotExist case

Re: Loading classes with many methods is very expensive

On 10/29/2014 02:08 PM, Joel Borggrén-Franck wrote: Hi Peter, I’m not entirely convinced this is a bug. The lookup order for getMethod has for a long time been walk up superclasses and return what you find there first without even looking at interfaces. It might be desirable to change that bu

Re: [9] [8u40] RFR (M): 8059877: GWT branch frequencies pollution due to LF sharing

Thanks, John. Best regards, Vladimir Ivanov On 10/29/14, 12:21 AM, John Rose wrote: Good, I'm happy. Reviewed. — John On Oct 28, 2014, at 12:04 PM, Vladimir Ivanov mailto:vladimir.x.iva...@oracle.com>> wrote: John, thanks for the feedback! See my answers inline.

Re: [9] Review request : JDK-8059070: [TESTBUG] java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed - timeout

Please, review a test bug fix. http://cr.openjdk.java.net/~kshefov/8059070/webrev.01/ -Konstantin On 27.10.2014 13:16, Konstantin Shefov wrote: Kindly reminder On 23.10.2014 19:04, Paul Sandoz wrote: On Oct 23, 2014, at 1:25 PM, Konstantin Shefov wrote: Gently reminder On 17.10.2014 13:38,

Re: RFR (M) 8061651 - Interface to the Lookup Index Cache to improve URLClassPath search time (round 3)

Sorry, I was confused about who wrote what. Sounds like David and I are in agreement that you can remove the synchronization - I believe that would be much cleaner. And resolveClass does nothing and is final so no worries there. thanks, Karen On Oct 29, 2014, at 2:37 AM, David Holmes wrote: >

Re: RFR (M) 8061651 - Interface to the Lookup Index Cache to improve URLClassPath search time (round 3)

David, On Oct 29, 2014, at 2:04 AM, Ioi Lam wrote: > > On 10/28/14, 7:34 PM, David Holmes wrote: >> Hi Karen, >> >> I haven't been tracking the details of this and am unclear on the overall >> caching strategy however ... >> >> On 29/10/2014 8:49 AM, Karen Kinnear wrote: >>> Ioi, >>> >>>

Re: java.util.Optional: a better implementation?

On 10/29/2014 01:43 PM, Aleksey Shipilev wrote: On 29.10.2014 15:25, David Holmes wrote: On 29/10/2014 10:06 PM, nicar...@gmail.com wrote: The JVM probably optimizes and throws away the null checks yielding in equal performance compared to the proposed implementation (above) ---I haven't done

Re: Loading classes with many methods is very expensive

Hi Peter, I’m not entirely convinced this is a bug. The lookup order for getMethod has for a long time been walk up superclasses and return what you find there first without even looking at interfaces. It might be desirable to change that but I’m not sure. cheers /Joel On 29 okt 2014, at 12:2

Re: java.util.Optional: a better implementation?

On 29.10.2014 15:25, David Holmes wrote: > On 29/10/2014 10:06 PM, nicar...@gmail.com wrote: >> The JVM probably optimizes and throws away the null checks yielding in >> equal performance compared to the proposed implementation (above) ---I >> haven't done any performance tests, but why wait fo

Re: java.util.Optional: a better implementation?

Nicolas, core-libs-dev is the right mailing list for this so I've cc'd it. Please drop the discuss list from any follow up. David On 29/10/2014 10:06 PM, nicar...@gmail.com wrote: Hi, I'm evaluating java.util.Optional to use it all around my code. I noticed that its current implementation c

Re: Loading classes with many methods is very expensive

Hi Joel, I found an inconsistency between getMethod() and getMethods() results that is present in current JDK8/9 code and in my latest webrev.02. The following program: import java.util.stream.Collectors; import java.util.stream.Stream; public class GetMethodTest { static void test(Clas

Re: Request for review/advice from langtools team Re: Covariant overrides on the Buffer Hierarchy redux

On Oct 28, 2014, at 1:59 PM, Joel Borggrén-Franck wrote: > Hi Paul, > > Sorry for the delay. > > So if I understand this correctly, we get 4 warnings (and because of -Werror > a build failure) in langtools when compiling vs Jdk 9, but need the casts > because we bootstrap with Jdk 8. > Ye