8290840: Refactor the "os" class #9600

iklam · 2022-07-21T19:45:13Z

Please see JDK-8290840 for the detailed proposal.

The os class, declared in os.hpp, forms the major part of the HotSpot porting interface. Its structure has gradually deteriorated over the years as new ports are created and new APIs are added.

This RFE tries to address the following:

Clearly specify where a porting API should be declared and defined among the various os*.cpp and os*.hpp files.
Avoid the inappropriate inclusion of OS-specific APIs (such as the os::Linux class) by platform-independent source files.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8290840: Refactor the "os" class

Reviewers

David Holmes (@dholmes-ora - Reviewer) ⚠️ Review applies to 06ae96b9
Gerard Ziemski (@gerard-ziemski - Committer) ⚠️ Review applies to 11c3c3d3
Thomas Stuefe (@tstuefe - Reviewer) ⚠️ Review applies to 1c7f8ebe
Stefan Karlsson (@stefank - Reviewer) ⚠️ Review applies to cf93fb74

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/9600/head:pull/9600
$ git checkout pull/9600

Update a local copy of the PR:
$ git checkout pull/9600
$ git pull https://git.openjdk.org/jdk pull/9600/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 9600

View PR using the GUI difftool:
$ git pr show -t 9600

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/9600.diff

bridgekeeper · 2022-07-21T19:46:58Z

👋 Welcome back iklam! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2022-07-21T19:49:48Z

@iklam The following label will be automatically applied to this pull request:

hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2022-07-21T21:37:51Z

Webrevs

src/hotspot/share/runtime/os.hpp

src/hotspot/os/aix/os_aix.cpp

dholmes-ora · 2022-07-25T23:59:33Z

src/hotspot/os/posix/os_posix.cpp

  ::umask(umsk);
  st->print("umask: %04o (", (unsigned) umsk);
-  print_umask(st, umsk);
+  os::Posix::print_umask(st, umsk);


There's really no reason print_umask has to be part of the os::Posix class, it could just be a static file function in os_posix.cpp. I suspect the same may be true for other things in os::Posix - I would think we only need things in os::Posix that are explicitly called from os::Linux or os::Bsd etc.

dholmes-ora

Updates look good thanks. Overall this seems good to me. I think there may be more refinement possible with regards to the os::XXX classes, but that can be future cleanup if you want to proceed with this version for now.

Thanks.

dholmes-ora

Mis-clicked. Approved.

openjdk · 2022-07-26T00:03:52Z

@iklam This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8290840: Refactor the "os" class

Reviewed-by: dholmes, gziemski, stuefe, stefank

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been no new commits pushed to the master branch. If another commit should be pushed before you perform the /integrate command, your PR will be automatically rebased. If you prefer to avoid any potential automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

gerard-ziemski

Looks good, however, I would prefer not to have to provide the default implementations for register_code_area() or resolve_function_descriptor()

src/hotspot/share/runtime/os.inline.hpp

gerard-ziemski · 2022-07-29T18:51:29Z

src/hotspot/share/runtime/os.inline.hpp

+#ifndef HAVE_FUNCTION_DESCRIPTORS
+inline void* os::resolve_function_descriptor(void* p) {
+  return NULL;
+}


This is unnecessary and could be removed if we did:

+#ifdef HAVE_FUNCTION_DESCRIPTORS // Used only on PPC. inline static void* resolve_function_descriptor(void* p); +#endif

in os.hpp

After this PR, os.hpp no longer includes any os- or cpu-specific os_xxx.hpp files. I did this to avoid including large amount of os-specific declarations (such as os::Linux, which is about 400 lines) into generic source files, which aren't interested in these declarations.

As a result of this change, there's no way to let os.hpp know whether HAVE_FUNCTION_DESCRIPTORS is defined for the current OS+CPU. If we want to do that, we need to either:

include os_xxx.hpp back in os.hpp (which I want to avoid)

add new header files such as os_<os>.defs.hpp os_<os>_<cpu>.defs.hpp to define HAVE_FUNCTION_DESCRIPTORS (this will result in lots of header files that usually have nothing inside)

Since there are only 4 functions that fall under this pattern (functions that are used in generic code but most platforms have dummy implementations), I think what I have is a good compromise

Could we do:

#if defined(LINUX) && defined(PPC) && !defined(ABI_ELFv2) #define HAVE_FUNCTION_DESCRIPTORS #endif

in os.hpp and whatever the equivalent for AIX/PPC is?

#if defined(PPC) && !defined(ABI_ELFv2) #define HAVE_FUNCTION_DESCRIPTORS #endif

should do the trick. AIX uses XCOFF, not Elf, so ABI_ELFv2 should never be defined.

But I have no emotions. We can leave it like this. Or do it in a follow up.

gerard-ziemski · 2022-07-29T18:52:56Z

src/hotspot/share/runtime/os.inline.hpp

+#ifndef _WINDOWS
+// Currently used only on Windows.
+inline bool os::register_code_area(char *low, char *high) {
+  return true;
+}
+#endif


We could use some custom define, similar to HAVE_FUNCTION_DESCRIPTORS and remove this default impl just like with resolve_function_descriptor()?

tstuefe

Very good work. Only small remarks/nitpickings.

One question though, how does it work if I want to use an API implemented on a per-platform base in shared code? E.g. zero_page_read_protected()? I include os.hpp to get the definition, but how do I get the implementation? I have to include the platform-specific inline header too? Still with the OS_HEADER macro?

Cheers, Thomas

tstuefe · 2022-08-01T18:48:12Z

src/hotspot/share/runtime/os.hpp

+//
+//   The Porting APIs declared as "inline" in os.hpp must be
+//   implemented in one of the two .inline.hpp files, depending on whether
+//   the feature is generic to the OS, or specific to a particular CPU


generic? Did you mean specific? E.g. "depending on whether the feature is specific to a certain OS or an OS+CPU combination" ?

I clarified the comment:

// The Porting APIs declared as "inline" in os.hpp must be // implemented in one of the two .inline.hpp files, depending on // whether the feature is specific to a particular CPU architecture // for this OS.

tstuefe · 2022-08-01T18:55:59Z

src/hotspot/os/aix/os_aix.hpp

  // Returns true if ok, false if error.
  static bool get_meminfo(meminfo_t* pmi);
+
+  // PPC only


Since your are here, remove comment? There has not been an AIX on something other than power for ~25 years.

tstuefe · 2022-08-01T19:01:05Z

src/hotspot/share/runtime/os.inline.hpp

+// Below are inline functions that are rarely implemented by the platforms.
+// Provide default empty implementation.
+
+#ifndef PLATFORM_PRINT_NATIVE_STACK


Could you rename this to HAVE_PLATFORM_PRINT_NATIVE_STACK?

tstuefe · 2022-08-01T19:03:06Z

src/hotspot/os/aix/os_aix.inline.hpp

+// Information about the protection of the page at address '0' on this os.
+inline bool os::zero_page_read_protected() {
+  return false;
+}


I have the feeling many of these functions are really just global constants and that the coding could be simplified further in followup RFEs.

Yeah lets do more clean up in follow-up RFEs.

tstuefe · 2022-08-01T19:08:34Z

src/hotspot/os/linux/os_linux.cpp

  // perform the workaround
  Linux::capture_initial_stack(JavaThread::stack_size_at_create());
-  workaround_expand_exec_shield_cs_limit();
+  Linux::workaround_expand_exec_shield_cs_limit();


You could move workaround_expand_exec_shield_cs_limit() into this file, declare it static, and remove all mentionings from headers. It now lives in os_linux_x86.cpp, but since it has to be wrapped with !zero !64bit already it is an odd misfit anyway. So its not much more "wrong" for it to live here.

…_linux.cpp

iklam · 2022-08-02T06:50:51Z

Very good work. Only small remarks/nitpickings.

One question though, how does it work if I want to use an API implemented on a per-platform base in shared code? E.g. zero_page_read_protected()? I include os.hpp to get the definition, but how do I get the implementation? I have to include the platform-specific inline header too? Still with the OS_HEADER macro?

Cheers, Thomas

I think we should avoid creating non-portable os::xxx APIs and then call them from shared code. There were some calls to os::Posix::xxx from the shared code that I fixed in this PR.

If you really want to make a platform-specific call, you should just do this (sadly we have many such cases)

#ifdef LINUX
linux_blah();
#endif

Putting linux_blah() into the os class seems pointless.

tstuefe

Still good.

tstuefe · 2022-08-02T06:53:18Z

src/hotspot/os/linux/os_linux.cpp

+ * Affects IA32: RHEL 5 & 6, Ubuntu 10.04 (LTS), 10.10, 11.04, 11.10, 12.04.
+ * @see JDK-8023956
+ */
+void workaround_expand_exec_shield_cs_limit() {


Make static?

iklam · 2022-08-02T07:00:45Z

@tstuefe @gerard-ziemski

I've simplified os::resolve_function_descriptor() according to your suggestions, but I changed the #ifdefs to be more exact:

  // Used only on PPC for AIX, or LINUX (ppc but not ppcle). 
  static void* resolve_function_descriptor(void* p)
#if defined(PPC) && (defined(AIX) || (defined(LINUX) && !defined(ABI_ELFv2)))
    ;
#else
  { return NULL; }
#endif

If we use "#if defined(PPC) && !defined(ABI_ELFv2)))" it would be very difficult to understand.

To be honest, I am not a big fan of adding #ifdefs into os.hpp just to save a few lines of code. The #ifdefs are hard to understand. They are also fragile if you need to add a new platform that also support this functionality.

I am (semi) OK with doing this for resolve_function_descriptor(), as that's a PPC-only thing that's unlikely to apply for other platforms. However, I don't want to use the same pattern for os::platform_print_native_stack() because we may want to implement this for other planforms.

dholmes-ora

Still seems okay to me.

dholmes-ora · 2022-08-02T07:06:57Z

src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp


-#ifdef HAVE_FUNCTION_DESCRIPTORS
-void* os::Linux::resolve_function_descriptor(void* p) {
+#if !defined(ABI_ELFv2)


I don't think many people will be able to map this to any specific platform. At a minimum some comment is needed to explain this.

tstuefe · 2022-08-02T07:12:33Z

I think we should avoid creating non-portable os::xxx APIs and then call them from shared code. There were some calls to os::Posix::xxx from the shared code that I fixed in this PR.

I don't think that's what I meant. I meant APIs that exist for all OSes but have different expressions on each OS. So the prototype should live in shared os. But I want to pull a different implementation for each OS.

This only affects inline functions. If the different implementations live in os_xx.cpp it works automatically through link time resolution.

I see there are only a few examples for what I meant. Many inline functions return platform dependend values and those live in variables in shared code (e.g. os::vm_page_size(), ...). Others are just not inline (os.create_thread(), ...). Which leaves us with the likes of zero_page_read_protected() etc, and I see you put them into os.inline.hpp and there you include the OS specific headers too.

I guess this can mostly be avoided. E.g. there is zero reason why zero_page_read_protected() cannot be a static boolean variable in os. For future RFEs.

…nts for os::resolve_function_descriptor()

iklam · 2022-08-02T16:08:35Z

I think we should avoid creating non-portable os::xxx APIs and then call them from shared code. There were some calls to os::Posix::xxx from the shared code that I fixed in this PR.

I don't think that's what I meant. I meant APIs that exist for all OSes but have different expressions on each OS. So the prototype should live in shared os. But I want to pull a different implementation for each OS.

This only affects inline functions. If the different implementations live in os_xx.cpp it works automatically through link time resolution.

I see there are only a few examples for what I meant. Many inline functions return platform dependend values and those live in variables in shared code (e.g. os::vm_page_size(), ...). Others are just not inline (os.create_thread(), ...). Which leaves us with the likes of zero_page_read_protected() etc, and I see you put them into os.inline.hpp and there you include the OS specific headers too.

I guess this can mostly be avoided. E.g. there is zero reason why zero_page_read_protected() cannot be a static boolean variable in os. For future RFEs.

Thanks for pointing this out. I've updated the comments in os.hpp to be more clear about the inline functions.

The design is -- if os.hpp declares an "inline" function without a body, the implementation must be in os_<os>.inline.hpp or os_<os>_<cpu>.inline.hpp. It's not possible for some platforms to choose to implement such a function in a .cpp file.

Conversely, if a function is NOT declared "inline" in os.hpp, it must NOT be implemented in any of the os*inline.hpp files.

Hence, any source file that references this function must include os.inline.hpp.

Without such a rule, it's possible for the build to succeed on some platforms (especially if the compiler is more lenient on missing inline function definitions) and fail on others. As a result, it would be easier to break the repo as not everyone is able to build all platforms before integrating a PR.

This rule is similar to how we handle "inline" declarations in regular HotSpot headers.

iklam · 2022-08-02T16:10:34Z

I see there are only a few examples for what I meant. Many inline functions return platform dependend values and those live in variables in shared code (e.g. os::vm_page_size(), ...). Others are just not inline (os.create_thread(), ...). Which leaves us with the likes of zero_page_read_protected() etc, and I see you put them into os.inline.hpp and there you include the OS specific headers too.

I guess this can mostly be avoided. E.g. there is zero reason why zero_page_read_protected() cannot be a static boolean variable in os. For future RFEs.

Yes, this can certainly be improved in follow-up RFE.

stefank

I love seeing the os files being cleaned up and restructured.

I started to look at the patch and found a significant number of nits that I think would be good to fix.

stefank · 2022-08-02T13:57:37Z

src/hotspot/os/posix/os_posix.cpp

 #include "utilities/globalDefinitions.hpp"
 #include "utilities/macros.hpp"
 #include "utilities/vmError.hpp"



Other files don't add a blank line before the conditional includes.

stefank · 2022-08-02T13:58:26Z

src/hotspot/os/posix/os_posix.hpp

 #define OS_POSIX_OS_POSIX_HPP

+#include "runtime/os.hpp"
+#include <errno.h>


We usually add blank lines before system includes

stefank · 2022-08-02T14:01:33Z

src/hotspot/os/posix/os_posix.inline.hpp

-
 #include "runtime/mutex.hpp"
 #include "runtime/os.hpp"
+#include "os_posix.hpp"


The .hpp file of an .inline.hpp file should be included as the first include. The comment above was an indication that we previously didn't follow that rule, because of how we sometimes structure platform includes. But it seems like you are changing this now, and I hope that we now can follow that rule and change the code to:

#include "os_posix.hpp" #include "runtime/mutex.hpp" #include "runtime/os.hpp"

stefank · 2022-08-02T14:01:53Z

src/hotspot/os/posix/perfMemory_posix.cpp

 #include "runtime/perfMemory.hpp"
 #include "services/memTracker.hpp"
 #include "utilities/exceptions.hpp"



Remove blank line

stefank · 2022-08-02T14:03:29Z

src/hotspot/os/posix/perfMemory_posix.cpp

+#if defined(LINUX)
+#include "os_linux.hpp"
+#endif
+


It feels "wrong" that the posix files include linux files. Maybe that's something that future restructuring of code could fix.

stefank · 2022-08-02T14:05:55Z

src/hotspot/os/windows/pdh_interface.cpp


 #include "precompiled.hpp"
 #include "pdh_interface.hpp"
+#include "os_windows.hpp"


stefank · 2022-08-02T14:11:14Z

src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp

+#include "os_posix.hpp"
+#include "os_linux.hpp"


stefank · 2022-08-02T16:41:02Z

src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp

+#include "os_posix.hpp"
+#include "os_linux.hpp"


stefank · 2022-08-02T16:46:51Z

src/hotspot/share/runtime/os.inline.hpp

+#include OS_HEADER(os)
 #include OS_HEADER_INLINE(os)


We usually only explicitly include .inline.hpp and don't and let that file bring in the corresponding .hpp file.

stefank · 2022-08-02T16:47:46Z

test/hotspot/gtest/runtime/test_os.cpp

 #include "unittest.hpp"
 #include "runtime/frame.inline.hpp"
 #include "runtime/threads.hpp"



Remove blank line

gerard-ziemski · 2022-08-02T21:09:55Z

@tstuefe @gerard-ziemski

I've simplified os::resolve_function_descriptor() according to your suggestions, but I changed the #ifdefs to be more exact:
  // Used only on PPC for AIX, or LINUX (ppc but not ppcle). 
  static void* resolve_function_descriptor(void* p)
#if defined(PPC) && (defined(AIX) || (defined(LINUX) && !defined(ABI_ELFv2)))
    ;
#else
  { return NULL; }
#endif
If we use "#if defined(PPC) && !defined(ABI_ELFv2)))" it would be very difficult to understand.

To be honest, I am not a big fan of adding #ifdefs into os.hpp just to save a few lines of code. The #ifdefs are hard to understand. They are also fragile if you need to add a new platform that also support this functionality.

I am (semi) OK with doing this for resolve_function_descriptor(), as that's a PPC-only thing that's unlikely to apply for other platforms. However, I don't want to use the same pattern for os::platform_print_native_stack() because we may want to implement this for other planforms.

Thank you for trying. I am not completely happy about the new #ifdef and it doesn't look as clean to me as I imagined it would, so I am OK with you going with the original way it way. I guess, we could address it in a follow up if we come up with a nicer way of doing this...

…iptor()" This reverts commit 72efa9c.

iklam · 2022-08-03T04:17:25Z

@tstuefe @gerard-ziemski
I've simplified os::resolve_function_descriptor() according to your suggestions, but I changed the #ifdefs to be more exact:
  // Used only on PPC for AIX, or LINUX (ppc but not ppcle). 
  static void* resolve_function_descriptor(void* p)
#if defined(PPC) && (defined(AIX) || (defined(LINUX) && !defined(ABI_ELFv2)))
    ;
#else
  { return NULL; }
#endif
If we use "#if defined(PPC) && !defined(ABI_ELFv2)))" it would be very difficult to understand.
To be honest, I am not a big fan of adding #ifdefs into os.hpp just to save a few lines of code. The #ifdefs are hard to understand. They are also fragile if you need to add a new platform that also support this functionality.
I am (semi) OK with doing this for resolve_function_descriptor(), as that's a PPC-only thing that's unlikely to apply for other platforms. However, I don't want to use the same pattern for os::platform_print_native_stack() because we may want to implement this for other planforms.
Thank you for trying. I am not completely happy about the new #ifdef and it doesn't look as clean to me as I imagined it would, so I am OK with you going with the original way it way. I guess, we could address it in a follow up if we come up with a nicer way of doing this...

Hi Gerard, thanks for the review. I've reverted the #ifdef change and gone back to the original way. See commit cf93fb7

stefank

Three more nits, otherwise looks good.

stefank · 2022-08-03T07:10:36Z

src/hotspot/os/bsd/os_bsd.inline.hpp

 #include "runtime/os.hpp"
+#include "os_bsd.hpp"


Change to:

#include "os_bsd.hpp" #include "runtime/os.hpp"

stefank · 2022-08-03T07:12:57Z

src/hotspot/os/linux/os_linux.inline.hpp

 #include "runtime/os.hpp"
+#include "os_linux.hpp"
 #include "os_posix.inline.hpp"


Change to:

#include "os_linux.hpp" #include "runtime/os.hpp" #include "os_posix.inline.hpp"

stefank · 2022-08-03T07:15:00Z

src/hotspot/os/windows/os_windows.inline.hpp

 // os_windows.hpp included by os.hpp

+#include "os_windows.hpp"
 #include "runtime/javaThread.hpp"
 #include "runtime/mutex.hpp"


Change to:

#include "os_windows.hpp" #include "runtime/javaThread.hpp" #include "runtime/mutex.hpp"

…refactor-the-os-class

iklam · 2022-08-04T01:15:27Z

Thanks @tstuefe @gerard-ziemski @stefank @dholmes-ora for the review.
Passed build tiers 1 and 5.
/integrate

openjdk · 2022-08-04T01:20:40Z

Going to push as commit b6b0317.

openjdk · 2022-08-04T01:20:56Z

@iklam Pushed as commit b6b0317.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8290840: Refactor the "os" class

82ac389

openjdk bot added the hotspot hotspot-dev@openjdk.org label Jul 21, 2022

fixed whitespaces

5516640

iklam mentioned this pull request Jul 21, 2022

8265473: Move os::Linux to its own header file #9423

Closed

3 tasks

iklam marked this pull request as ready for review July 21, 2022 21:31

openjdk bot added the rfr Pull request is ready for review label Jul 21, 2022

dholmes-ora reviewed Jul 25, 2022

View reviewed changes

src/hotspot/share/runtime/os.hpp Outdated Show resolved Hide resolved

src/hotspot/share/runtime/os.hpp Outdated Show resolved Hide resolved

src/hotspot/share/runtime/os.hpp Show resolved Hide resolved

src/hotspot/os/aix/os_aix.cpp Outdated Show resolved Hide resolved

iklam added 2 commits July 25, 2022 15:39

Fixed os.hpp comments per @dholmes-ora review

2bf5b59

moved os::{print_active_locale, print_user_info} to os_posix.cpp

9f85329

dholmes-ora reviewed Jul 25, 2022

View reviewed changes

dholmes-ora reviewed Jul 26, 2022

View reviewed changes

dholmes-ora approved these changes Jul 26, 2022

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jul 26, 2022

gerard-ziemski suggested changes Jul 29, 2022

View reviewed changes

fixed typo

560e67c

tstuefe approved these changes Aug 1, 2022

View reviewed changes

iklam added 4 commits August 1, 2022 23:16

Made workaround_expand_exec_shield_cs_limit() a static function in os…

1bae6bb

…_linux.cpp

simplified rarely-defined function os::resolve_function_descriptor()

72efa9c

PLATFORM_PRINT_NATIVE_STACK -> HAVE_PLATFORM_PRINT_NATIVE_STACK

79c33e6

clarify comment

1c7f8eb

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Aug 2, 2022

tstuefe approved these changes Aug 2, 2022

View reviewed changes

fixed whitespace

06ae96b

openjdk bot added ready Pull request is ready to be integrated rfr Pull request is ready for review labels Aug 2, 2022

dholmes-ora approved these changes Aug 2, 2022

View reviewed changes

iklam added 3 commits August 2, 2022 08:37

made workaround_expand_exec_shield_cs_limit() static; added PPC comme…

2a28a5d

…nts for os::resolve_function_descriptor()

Merge branch 'master' into 8290840-refactor-the-os-class

3a21e11

clarified comments about inline functions declared in os.hpp

b6e60a5

stefank suggested changes Aug 2, 2022

View reviewed changes

@stefank comments

11c3c3d

gerard-ziemski approved these changes Aug 2, 2022

View reviewed changes

Revert "simplified rarely-defined function os::resolve_function_descr…

cf93fb7

…iptor()" This reverts commit 72efa9c.

stefank approved these changes Aug 3, 2022

View reviewed changes

iklam added 2 commits August 3, 2022 12:56

fixed more inline.hpp #include order

8ed25f4

Merge branch 'master' of https://github.com/openjdk/jdk into 8290840-…

7764c9e

…refactor-the-os-class

openjdk bot added the integrated Pull request has been integrated label Aug 4, 2022

openjdk bot closed this Aug 4, 2022

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Aug 4, 2022

iklam mentioned this pull request Aug 4, 2022

8291945: Add OSInfo API for static OS information #9758

Closed

3 tasks

8290840: Refactor the "os" class #9600

8290840: Refactor the "os" class #9600

Uh oh!

Conversation

iklam commented Jul 21, 2022 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Jul 21, 2022

Uh oh!

openjdk bot commented Jul 21, 2022

Uh oh!

mlbridge bot commented Jul 21, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dholmes-ora left a comment

Choose a reason for hiding this comment

Uh oh!

dholmes-ora left a comment

Choose a reason for hiding this comment

Uh oh!

openjdk bot commented Jul 26, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gerard-ziemski left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

gerard-ziemski Jul 29, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gerard-ziemski Aug 1, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gerard-ziemski Jul 29, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tstuefe left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

iklam commented Aug 2, 2022

Uh oh!

tstuefe left a comment

iklam commented Jul 21, 2022 •

edited by openjdk bot

Loading

mlbridge bot commented Jul 21, 2022 •

edited

Loading

openjdk bot commented Jul 26, 2022 •

edited

Loading

gerard-ziemski Jul 29, 2022 •

edited

Loading

gerard-ziemski Aug 1, 2022 •

edited

Loading

gerard-ziemski Jul 29, 2022 •

edited

Loading

tstuefe commented Aug 2, 2022 •

edited

Loading