RFR(M): 8030812 : Change the solaris DTrace implementation to use USDT2 instead of USDT1

[Coleen Phillimore]

Staffan,
This looks good.   The cleanup looks good.  I was hoping that you were 
going to remove !USDT2 code under those macros.  I assume that's a 
further change.  I look forward to that.
Thanks,
Coleen

On 01/07/2014 01:24 PM, serguei.spitsyn at oracle.com wrote:
> On 1/7/14 3:47 AM, Staffan Larsen wrote:
>> On 20 dec 2013, at 22:07, serguei.spitsyn at oracle.com wrote:
>>
>>> Staffan,
>>>
>>> This is nice change and cleanup.
>>> I do not see any issues.
>> Thanks.
>>
>>> The make/bsd/makefiles/dtrace.make shows that the jhelper.d is 
>>> disabled for bsd
>>> which means that the jstack action is not supported there.
>>> I'm not very familiar with the BSD DTrace implementation and wonder 
>>> if you know any details.
>>> Does it mean there is no jstack action there, or just more work is 
>>> needed to make the jhelper.d functional?
>>> Do we have a bug filed on this?
>> Short answer: I don’t know anything about jstack or jhelper.d.
>
> The jstack action in a d-script prints mixed java+native stack trace.
> The jhelper.d is a provider from JVM side (as a part of the DTrace 
> support) that helps
> the DTrace to translate hexa-decimal pc's to Java symbolic method names.
> The jhelper.d code is linked into the libjvm.so DOF section where 
> DTrace can find it.
>
> Thanks,
> Serguei
>
>>
>> /Staffan
>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>> On 12/20/13 3:58 AM, Staffan Larsen wrote:
>>>> The DTrace static probe implementation in Hotspot was written with 
>>>> an earlier version of DTrace. With newer versions, DTrace can 
>>>> create a header file from the contents of the .d file that 
>>>> describes the probes. This newer version (called USDT2) has been 
>>>> used on OS X. Because we have had both versions active, the code 
>>>> has ended up looking ugly because of all the extra macros.
>>>>
>>>> This is a first step in cleaning that up by moving the solaris 
>>>> implementation to use USDT2. The remaining step before USDT1 can be 
>>>> removed is to change the Linux system tap implementation to also 
>>>> use USDT2.
>>>>
>>>> What I have changed is:
>>>> - Update the solaris dtrace.make to generate the header files. I 
>>>> have used the same code as on bsd.
>>>> - While I was there, I removed a lot of commented out code from the 
>>>> bsd dtrace.make file.
>>>> - Updated the hotspot.d files on bsd and solaris so that they have 
>>>> the same contents.
>>>> - Fixed some compilation errors in compileBroker.cpp with const char*.
>>>> - May of the USDT2 macro invocations had an extra line break in 
>>>> them. This both looked ugly and confused the solaris compiler, so I 
>>>> removed them. This lead to a _lot_ of changes in jni.cpp - enough 
>>>> changes so that webrev couldn’t handle it, which is why some of the 
>>>> webrev views are broken for this file.
>>>> -
>>>>
>>>> Testing: I have run the vm.dtrace.testlist on both Solaris and OS X.
>>>>
>>>> webrev: http://cr.openjdk.java.net/~sla/8030812/webrev.00/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8030812
>>>>
>>>> Thanks,
>>>> /Staffan
>