RFC: 8136978 Much nearly duplicated code for vmError support
Coleen Phillimore
coleen.phillimore at oracle.com
Tue Oct 13 23:09:34 UTC 2015
Hi Sebastian,
Thank you for taking this RFE. It's really a bug that we have all this
duplicate code.
On 10/13/15 3:21 PM, Sebastian Sickelmann wrote:
> Hi,
>
> i have looked at the enhancement JDK-8136978 and have 2 solutions how
> this could be handled and want to ask which seems to be more
> "hotspot-code-style" like.
>
> The common idea behind the change is to move os/linux/vmError_linux.cpp
> to os/posix/vmError_posix.cpp and change the methods appropriate. Remove
> of os_[*]/vmError_[*].cpp (for [*] = aix,bsd,solaris and linux)
>
> I want to concentrate on the "signals stuff" in this mail.
>
> Calls to os::Linux::ucontext_set_pc and os::Linux::ucontext_get_pc will
> be changed to os::Posix::.......
> Calls to pthread_sigmask will be replaced with
> os::Posix::unblock_signals(const sigset_t *set).
>
> These methods are defined in os/posix/os_posix.hpp.
> I think unblock_signals should be implemented in os/[*]/vm/os_[*].cpp
> like this:
>
> int os::Posix::unblock_signals(const sigset_t *set) {
> return pthread_sigmask(SIG_UNBLOCK, set, NULL);
> }
>
> But for ucontext_set_pc and ucontext_get_pc i see two variants:
>
> Implement in in os/[*]/vm/os_[*].cpp like this:
>
> address os::Posix::ucontext_get_pc(ucontext_t* ctx) {
> return os::Linux::ucontext_get_pc(ctx);
> }
>
> and call the existing methods from the os_cpu directory.
>
> Or remove the ucontext_get_pc and ucontext_set_pc from the
> os/[*]/vm/os_[*].hpp and change the implementations in
> os_cpu/*/vm/os_[*]_[**].cpp from os::[*]::ucontext....... to
> os::Posix::ucontext.........
Yes, please!
>
> I think the solutions are identically from the view of the compile
> result at least when inlining is used.
>
> I think the first solutions would creates a smaller changeset.
> I think the second solution would lead to a slightly smaller codebase.
>
> What do you think? I personally prefer the second.
Yes, I prefer the second also.
Thanks!!
Coleen
>
> -- Sebastian
More information about the hotspot-dev
mailing list