Code Review fix for 8005044 remove crufty '_g' support from HS runtime code

[Kelly O'Hair]

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-dev at openjdk.java.net; build-dev; hotspot-runtime-dev at 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.
>