search

eclipse-openj9 / openj9

Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput. Builds on Eclipse OMR (https://github.com/eclipse/omr) and combines with the Extensions for OpenJDK for OpenJ9 repo.
Other
3.27k stars 721 forks source link

JIT compiler I/O: benefit of J9 I/O? #13902

Open jdmpapin opened 2 years ago

jdmpapin commented 2 years ago

OMR gives us TR::FILE with a default definition of (stdio) ::FILE and a few operations that by default simply call stdio functions, but OpenJ9 overrides both the type definition and the operations. The implementing type TR::FilePointer can itself be a wrapper around ::FILE, but it also has the "J9 I/O" mode distinguished by _useJ9IO.

OMR's trfopen() is an alias for TR::IO::fopen(), whose J9 implementation uses TR::FilePointer with stdio.

Currently, the stdio mode is used for compilation log files (1, 2, 3) and JIT dump files, while the J9 I/O mode is used for verbose and rt log files and perfTool.

Is there any particular benefit to the J9 I/O mode as compared to stdio? I've heard that once upon a time it was necessary because J9 ran in environments without a C runtime library, but I expect that we can now take the C runtime library for granted—we even use the STL now.

The motivation for this question is that if there is no longer a particular advantage to using J9 I/O, then the J9 I/O mode can be eliminated, and so too can be TR::FilePointer itself. Going further, the OMR compiler component might have no other motivation for TR::FILE, and if so, that too could be removed in favour of direct use of stdio. I think that these changes, if possible, would be a great simplification of I/O in the compiler.

keithc-ca commented 2 years ago

I suggest JIT should be using I/O functionality provided by OMR instead of duplicating the work of managing platform differences.

jdmpapin commented 2 years ago

What are the platform differences that need to be managed? I'm not aware of any platform-specific code related to the current uses of TR::FilePointer as a stdio wrapper

keithc-ca commented 2 years ago

For example, different platforms have differing support for various % format and specifiers for fprintf() and printf(). It's true that we have OMR_PRIxxx defined in omrformatconsts.h, but they're not being used consistently. On the other hand, omrfile_printf() supports a consistent set for format specifiers independent of the platform.

jdmpapin commented 2 years ago

OK, access to a consistent set of supported format specifiers and such is definitely a plus

I was wondering about size_t, uintptr_t, etc., but it looks like the z modifier should cover those (e.g. %zx)

When using OMR's printf, we can't make use of format string checking in the build compiler, but I suppose the JIT has mostly been going without that anyway

My main concern in this issue is that to the extent possible I'd like to do away with this whole TR::FILE and TR::FilePointer business, which might be done just as well by switching entirely to the port library

Is the port library consistently available within the JIT? I see that we have TR::Compiler->omrPortLib used for CPU detection, but many of the uses of it appear to have a redundant implementation of the functionality to guard against the unavailability of omrPortLib. Here's an example

jdmpapin commented 2 years ago

It looks like switching to port library I/O would require eclipse/omr#1644 to be resolved first, whereas stdio is just always there