I suspected that, but you sent it to build-dev and I was expecting makefile changes.
So good to go from build-dev -kto On Dec 18, 2012, at 1:18 PM, Ron Durbin wrote: > > Dan is correct. > -----Original Message----- > From: Daniel D. Daugherty > Sent: Tuesday, December 18, 2012 2:14 PM > To: Kelly O'Hair > Cc: serviceability-...@openjdk.java.net; build-dev; > hotspot-runtime-...@openjdk.java.net > Subject: Re: Code Review fix for 8005044 remove crufty '_g' support from HS > runtime code > > Kelly, > > The Makefile changes were reviewed under 7153050 last week and pushed to > RT_Baseline. > > See the attached notification. > > Dan > > > > On 12/18/12 2:06 PM, Kelly O'Hair wrote: >> I don't see any makefile changes. >> >> -kto >> >> On Dec 18, 2012, at 12:46 PM, Daniel D. Daugherty wrote: >> >>> Greetings, >>> >>> I'm sponsoring this code review request from Ron Durbin. This change >>> is targeted at JDK8/HSX-25 in the RT_Baseline repo. >>> >>> Dan >>> >>> Sending again with correct subject line, bug URLs and webrev URL. >>> >>> >>> Intro: >>> >>> This set of changes removes the runtimesupport for generation of debug >>> versions that follow _g semantics. >>> >>> Defect: >>> JDK-8005044 remove crufty '_g' support from HS runtime code >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005044 >>> https://jbs.oracle.com/bugs/browse/JDK-8005044 >>> >>> >>> Webrev >>> http://cr.openjdk.java.net/~dcubed/for_rdurbin/8005044-webrev/0 >>> >>> >>> Details: >>> Files have been modified to remove all reference and support for debug >>> versions that follow _g semantics. >>> >>> Testing: >>> >>> Passed JPRT last night: >>> >>> Additional Testing In process: (suggested by Dan): >>> >>> src/share/vm/runtime/arguments.cpp >>> - test with shared archive creation and use; see the e-mail >>> from Coleen >>> >>> src/share/tools/ProjectCreator/ProjectCreator.java >>> - just a usage message; visual inspection of the code >>> >>> src/os/windows/vm/os_windows.cpp >>> - comments only; no testing needed >>> >>> src/os/{bsd,linux,solaris}/vm/os_{bsd,linux,solaris}.cpp >>> - the only code changes come into play when the "gamma" >>> launcher is used >>> - and when JAVA_HOME refers to a valid JDK, the function >>> fakes up a JVM path so that callers using the JVM path >>> to find other things in the JDK will work. >>> - I can't find any way that the actual JVM path value >>> that is returned is exposed >>> - I don't see a way to test this other than have a debug >>> printf() or manual code inspection. >
