Fwd: Boolean valueOf instead of new Boolean

-- Forwarded message -- From: roger riggs Date: Tue, May 27, 2014 at 3:02 PM Subject: Re: Boolean valueOf instead of new Boolean To: core-libs-dev@openjdk.java.net Hi Otávio, I can sponsor these two (Boolean and single char strings) for you. Because they cross over different r

RFR: 5043030 (reflect) unnecessary object creation in reflection

Hi Joe, I have prepared a patch for the issue JDK-5043030. The patch consists of two parts: one for jdk and one for hotspot. You can find the webrevs here: JDK-patch: https://db.tt/7DYph0OH Hotspot-patch: https://db.tt/hHsN0yn4 The JDK-patch has two tests to verify the changes. Please review it

Re: JVM crash when I use google gperftools Non Heap profiler

Hello, ask there: https://groups.google.com/forum/#!forum/google-perftools It is (does not look) related to openjdk core libraries at all. Gruss Bernd schrieb fuyou : > crash log > > A fatal error has been detected by the Java Runtime Environment: > SIGSEGV (0xb) at pc=0x2b626db6c304, pid

Doubles with large exponents overflow to Infinity incorrectly (Re: Intent to work on 8043740)

Continuing this thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-May/027030.html under a new subject line … Hi Sandipan, Per the contribution page information I sent earlier, I can sponsor the patch and assign the issue to myself and mark it as “in progress” while you are work

Re: Intent to work on 8043740

Thanks Brian - My concern is that, despite the unassigned status, someone just like me could be working on it. Since I don't have a Jira login I cannot update the status to communicate this to others. Cheers, SR Sandipan Razzaque | www.sandipan.net On Wed, May 28, 2014 at 10:36 AM, Brian Burkha

Re: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation

It’s difficult to develop a useful test that is cross-platform so let’s skip the testcase for this fix. On 28 May 2014, at 17:21, Jeremy Manson wrote: > You can defer the change if you need to. I'm going on vacation from the 6th > to the 16th, so there are timing issues around that. > > At

Re: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation

I’ll begin reviewing your changeset and get back to you. Thanks. On 28 May 2014, at 16:28, Jeremy Manson wrote: > Ah, okay. Thanks, Iris. I should already know known that - Martin has > explained it to me before. > > Vincent - let me know how you want to proceed. > > Jeremy > > > On Tue,

JVM crash when I use google gperftools Non Heap profiler

crash log A fatal error has been detected by the Java Runtime Environment: SIGSEGV (0xb) at pc=0x2b626db6c304, pid=15640, tid=1167100224 JRE version: Java(TM) SE Runtime Environment (7.0_55-b13) (build 1.7.0_55-b13) Java VM: Java HotSpot(TM) 64-Bit Server VM (24.55-b03 mixed mode linux-amd64 >

Re: Intent to work on 8043740

It'd help immensely if you'd include the title of the bug in question in the subject line of messages such as this. That way people can more easily decide whether and how to respond to your query. - Mark

Re: Intent to work on 8043740

On May 28, 2014, at 5:33 AM, Sandipan Razzaque wrote: > Hi all, > > Ready to contribute another patch - I intend to try and fix the following: > > https://bugs.openjdk.java.net/browse/JDK-8043740 > > Any thoughts/objections and/or is anyone already working on it? It is unassigned so I have t

Intent to work on 8043740

Hi all, Ready to contribute another patch - I intend to try and fix the following: https://bugs.openjdk.java.net/browse/JDK-8043740 Any thoughts/objections and/or is anyone already working on it? Cheers, SR Sandipan Razzaque | www.sandipan.net

Re: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache

Looks good. It should be safe to sync on MTF instance since it's not accessible outside (MTF and MT.form() are package-private). Best regards, Vladimir Ivanov On 5/28/14 1:49 PM, Tobias Hartmann wrote: Hi, thanks everyone for the feedback! @Remi: I agree with Paul. This is not a problem be

Re: [9] RFR (XXS): 8035186: j2se_jdk/jdk/test/java/lang/invoke/lambda/LogGeneratedClassesTest.java - assertion error

Thanks, Paul. I agree your comments and will address them before the push. Best regards, Vladimir Ivanov On 5/28/14 2:04 PM, Paul Sandoz wrote: On May 27, 2014, at 6:16 PM, Vladimir Ivanov wrote: Good catch! One more iteration: http://cr.openjdk.java.net/~vlivanov/8035186/webrev.02/ Loo

Re: [9] RFR (XXS): 8035186: j2se_jdk/jdk/test/java/lang/invoke/lambda/LogGeneratedClassesTest.java - assertion error

On May 27, 2014, at 6:16 PM, Vladimir Ivanov wrote: > Good catch! > One more iteration: > http://cr.openjdk.java.net/~vlivanov/8035186/webrev.02/ > Looks good. Some minor points, no need for another review round either way: - don't need the nested try blocks in isWriteableDirectory, just ta

Re: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache

Hi, thanks everyone for the feedback! @Remi: I agree with Paul. This is not a problem because if the normal read sees an outdated null value, a new LambdaForm is created and setCachedLambdaForm(...) is executed. This will guarantee that the non-null value is seen and used. The unnecessary cre