RFC: 8136978 Much nearly duplicated code for vmError support (original) (raw)

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Wed Oct 14 03:24:01 UTC 2015

[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 ucontextsetpc and ucontextgetpc i see two variants:

Implement in in os/[]/vm/os[].cpp like this: address os::Posix::ucontextgetpc(ucontextt* ctx) { return os::Linux::ucontextgetpc(ctx); } and call the existing methods from the oscpu directory. Or remove the ucontextgetpc and ucontextsetpc from the os/[]/vm/os[].hpp and change the implementations in oscpu//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.

More information about the hotspot-runtime-dev mailing list