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.
