[PATCH 0 of 4] Add support for dtrace compatible sdt probes on GNU/Linux

David Holmes david.holmes at oracle.com
Sun Jul 22 01:09:31 PDT 2012


On 22/07/2012 5:51 PM, Mark Wielaard wrote:
> On Sun, 2012-07-22 at 08:10 +1000, David Holmes wrote:
>> On 21/07/2012 7:08 PM, Mark Wielaard wrote:
>>> On Sat, Jul 21, 2012 at 05:48:21PM +1000, David Holmes wrote:
>>>> I'd love to see webrevs for these patches.
>>>
>>> Patches as webrevs here: http://icedtea.classpath.org/~mjw/webrev/7170638/
>>
>> Thanks. Unfortunately it didn't help with patch 1 as I can't mentally
>> expand all those nested macros (in original or new). :(
>
> It just follows the pattern from the rest of jni.h. That patch is really
> just a cleanup to make things more consistent. From my explanation:

I'm having trouble understanding the orignal FP_SELECT_##Result macro 
and the inversion between its use with respect to the probe in the old 
and new code. I need to spend some time seeing what it does.

But I understand what you are saying about using the DTRACE_PROBE[N] forms.

Thanks,
David

>          The first patch is just a consistency cleanup patch. The JNI Set
>          and
>          SetStatic Field methods used HS_DTRACE_PROBE_CDECL_N and HS_DTRACE_PROBE_N
>          directly instead of just using DTRACE_PROBE[N] like all other JNI methods.
>          This doesn't matter for the Solaris macros, but on GNU/Linux the macros
>          don't use direct function declarations (which is introduced in the second
>          patch).
>
> Back in May Keith said:
>
>          Ok, might be that it's fine.  I don't remember if there was a
>          reason that SetStatic was different from the other JNI calls,
>          but it certainly could just have been an omission in refactoring
>          or something.  We just need to make sure that it still works
>          (solaris-dtrace-wise).  It's certainly better this way!
>
> So if at least this patch can now finally be applied we are making at
> least some progress.
>
> Thanks,
>
> Mark
>


More information about the serviceability-dev mailing list