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.


> -- Sebastian

More information about the hotspot-dev mailing list