Re: RFR(S): 8071999: SA's buildreplayjars fail with exception

Hi Roland, On 5/02/2015 1:04 AM, Roland Westrelin wrote: buildreplayjars sometimes fail with an exception and I think that's caused by the lack of support for default methods when the SA dumps classes. This change fixes it at least partially. It may not be the cleanest way to support default me

RE: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available

This is obsolete, it stuck in the queue waiting moderator approval. Sorry, Goetz. -Original Message- From: serviceability-dev [mailto:serviceability-dev-boun...@openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Wednesday, January 21, 2015 11:40 AM To: hotspot-...@openjdk.java.net

Re: Fwd: Patch: Clean up fix for JDK-8047720

Dear David, I took a look at all occurrences of PeriodicTask_lock. We are in luck: PeriodicTask::enroll and PeriodicTask::disenroll check for safepoints when acquiring PeriodicTask_lock. PeriodicTask::time_to_wait and PeriodicTask::real_time_tick are called only by the watcher thread. WatcherTh

Re: RFR(XXS): 8072472: serviceability/dcmd/framework/* should be quarantined

Thanks for the review. Would you help me push this (exported changeset attached)? Thanks, Mikael On 2015-02-04 17:56, Jaroslav Bachorik wrote: > Looks good! > > -JB- > > On 4.2.2015 16:13, Mikael Auno wrote: >> Hi, could I have a review for this small change to ignore three tests. >> >> Issue:

Re: RFR(XXS): 8072472: serviceability/dcmd/framework/* should be quarantined

Looks good! -JB- On 4.2.2015 16:13, Mikael Auno wrote: Hi, could I have a review for this small change to ignore three tests. Issue: https://bugs.openjdk.java.net/browse/JDK-8072472 Webrev: http://cr.openjdk.java.net/~miauno/8072472/webrev.00/ Thanks, Mikael

RFR 8067447: Factor out the shared implementation of the VM flags manipulation code

Hi, this is a round 2 review of the proposed solution. Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.02 This patch is a precursor for implementing https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a part of

RE: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available

Hi, could please somebody from servicability sponsor this tiny change? Thanks, Goetz. -Original Message- From: hotspot-dev [mailto:hotspot-dev-boun...@openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Freitag, 16. Januar 2015 23:56 To: hotspot-...@openjdk.java.net Subject: Re: RF

Re: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc()

Looks good. -Tao (tamao) On Mon, Feb 2, 2015 at 7:51 AM, Yasumasa Suenaga wrote: > Hi, > > I need more reviewer. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.02/ > > Thanks, > > Yasumasa > 2015/01/28 17:24 "Staffan Larsen" : > > Looks good! >> >> Thanks, >>

Re: RewriteFrequentPairs flag was disabled in debug model(and discussion for fix)

Hi, Just add a few more words to explain the benefit on debug experience... If with that fix(hmmm, I just assumed that the fix in previous discussion already covered all the cases to make the RewriteFrequentPairs work in debug mode) we at least give the user another option to enable the RewriteF

Re: RFR(S): 8071999: SA's buildreplayjars fail with exception

On 04.02.2015 17:16, Christian Thalinger wrote: > Since you’re saying it only fixes it partially should we file a followup bug > and maybe leave a comment behind? I think this one is related: https://bugs.openjdk.java.net/browse/JDK-8015848 Best, Tobias > >> On Feb 4, 2015, at 7:04 AM, Roland

Re: RFR(S): 8071999: SA's buildreplayjars fail with exception

Since you’re saying it only fixes it partially should we file a followup bug and maybe leave a comment behind? > On Feb 4, 2015, at 7:04 AM, Roland Westrelin > wrote: > > > buildreplayjars sometimes fail with an exception and I think that's > caused by the lack of support for default methods

Re: RFR(S): 8071999: SA's buildreplayjars fail with exception

Looks good. Best regards, Vladimir Ivanov On 2/4/15 4:04 PM, Roland Westrelin wrote: buildreplayjars sometimes fail with an exception and I think that's caused by the lack of support for default methods when the SA dumps classes. This change fixes it at least partially. It may not be the clean

RFR(XXS): 8072472: serviceability/dcmd/framework/* should be quarantined

Hi, could I have a review for this small change to ignore three tests. Issue: https://bugs.openjdk.java.net/browse/JDK-8072472 Webrev: http://cr.openjdk.java.net/~miauno/8072472/webrev.00/ Thanks, Mikael

Re: RFR(S): 8071999: SA's buildreplayjars fail with exception

Roland, Looks good for me! (not a reviewer) Thank you for doing it. -Dmitry On 2015-02-04 18:04, Roland Westrelin wrote: > > buildreplayjars sometimes fail with an exception and I think that's > caused by the lack of support for default methods when the SA dumps > classes. This change fixes it

RFR(S): 8071999: SA's buildreplayjars fail with exception

buildreplayjars sometimes fail with an exception and I think that's caused by the lack of support for default methods when the SA dumps classes. This change fixes it at least partially. It may not be the cleanest way to support default methods but it already proved useful when investigating a comp

Re: RFR(S, testonly): JDK-8072395: LingeredAppTest.java and JMapHeapConfigTest.java fail due to LingeredApp ERROR: java.io.IOException: Lock is too old. Aborting

Staffan, Are you OK to push the changes? -Dmitry On 2015-02-03 16:01, Dmitry Samersoff wrote: > Everyone, > > Please review the fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8072395/webrev.01/ > > 1. I was wrong in my assumption that the test can't run more than an > hour of physical m