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

[Ron Durbin]

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.