[PATCH 0 of 3] Add support for dtrace compatible sdt probes on GNU/Linux
Keith McGuigan
keith.mcguigan at oracle.com
Wed May 23 07:23:11 PDT 2012
On 5/23/2012 9:56 AM, Mark Wielaard wrote:
>> It's (of course) just a style thing, but traditionally in hotspot
>> we've wanted the os or arch specific code in os or arch specific
>> directories, instead of littering the code with #ifdefs. I know the OSX
>> stuff started violated this some, but I hope we're going to resolve that
>> rather than continue down that path.
>
> I wouldn't have mind if the OSX stuff was split out this way, but now I
> don't have any example to follow here. What/How do you suggest it is
> done?
My first thought would be to create a dtrace_solaris.hpp file in
src/os/solaris/vm and a dtrace_linux.hpp file in src/os/linux/vm (and
maybe the same for bsd and windows?) for any OS-specific stuff, like the
macro definitions and maybe even that solaris workaround. Leave
anything common in the original file (like the default empty definitions
and such). Then you include the specific-file based on the target OS,
similar to what's done here:
http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/file/03d61caacd1e/src/share/vm/runtime/interfaceSupport.hpp
Yeah... it's a bit of a pain, and maybe in this case it's a little
overkill. But it's definitely nice to have a location for the
OS-specific stuff and it keeps the code rather neat.
I think the only reason it wasn't done like this in the first place is
that originally the DTrace code was either on or off based upon a 'make'
variable so there wasn't many OS-based decisions (except in the Makefile
of course). Probably it should have been done this way (split out)
originally. My bad.
--
- Keith
More information about the serviceability-dev
mailing list