RFC: 8136978 Much nearly duplicated code for vmError support

[Sebastian Sickelmann]

[move to hotspot-runtime-dev]

Hi, i started a discussion-thread[0] at hotspot-dev about RFE JDK-8136978,
where i discussed two possible solutions to remove duplicated code.

The abstract of the main open question inside this thread would be:
Is is ok to move methods that are declared in
os/[*]/os_[*].hpp ([*] are linux,bsd,ais,solaris) to
os/posix/os_posix.hpp into
the class os::Posix and change the implementation in
os_cpu/[*]_[**]/os_[*]_[**].cpp ([**] are the given architectures) to be
in the
class os::Posix ?

See the comment of Kim below to this question. Please consult [0] for
details of the other solution.

Is Posix the right target? Or should it be in the os class (by defining
it top-level
in os/posix/os_posix.hpp)?

What to you think?

-- Sebastian


[0]
http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-October/020249.html



On 10/13/2015 11:03 PM, Kim Barrett wrote:
> On Oct 13, 2015, at 3:21 PM, Sebastian Sickelmann <sebastian.sickelmann at gmx.de> wrote:
>> 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.........
>>
>> 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.
> I prefer the second as well, but you should get an opinion from someone on the
> runtime team, as they’re the folks who will end up maintaining the result.
>
> Having multiple scattered os::Posix:: implementations would be consistent in style with
> the multiple scattered os:: implementations, but still a new thing to know about.
>
>