Add processor version in javacore file

[gaolibj]

Add processor version in javacore file.

3XHCPUVERS Version : PROCESSOR_PPC_P7

NULL           ------------------------------------------------------------------------
0SECTION       GPINFO subcomponent dump routine
NULL           ================================
2XHOSLEVEL     OS Level         : OS/400 V7R3M0
2XHCPUS        Processors -
3XHCPUARCH       Architecture   : ppc
3XHNUMCPUS       How Many       : 16
3XHCPUVERS       Version        : PROCESSOR_PPC_P7
3XHNUMASUP       NUMA is either not supported or has been disabled by user
NULL

[DanHeidinga]

Thanks for the contribution @gaolibj.

Can you explain the benefit of adding this information to the javacore? What does having it in the javacore enable you to do?

I'm also concerned about the approach taken here as it's very IBM i specific and it doesn't feel like it's well factored with the rest of the code base.

The mapping from enum to char * at a minimum should live as close to the definition of the enum as possible so that they are more likely to be kept up to date together.

[DanHeidinga]

See previous discussion comment

[gaolibj]

On IBM i, we have some limitation for different processor types, especially for the new released processor. To accelerate issue fixing, we want to get the processor version quickly from javacore file. So, we added this line for IBM i platform.

[gaolibj]

Yes, this change should be kept up to date with enum J9ProcessorArchitecture. Seems the definition of the enum will not change frequently. We will keep an eye on it?

Or do you have any other better solutions?

[fjeremic]

IMO if we're going down this route we need to make the solution robust enough so we print the detected processor information for all platforms. I do agree though the processor information is useful in the javacore especially for JIT related problems since you don't have to dig through the core or ask for additional logging to extract the processor info.

[gaolibj]

@DanHeidinga do you have more comments？ Or better solutions？

[DanHeidinga]

This should handle the return value, not cast it away

[gaolibj]

Searched all codes in eclipse/openj9. Seems most of the case doesn't handle the return value.

[DanHeidinga]

The mapping from enum to char * at a minimum should live as close to the definition of the enum as possible so that they are more likely to be kept up to date together.

As I've dug into this code, I'm not enthusiastic about this feature as it's the kind of thing that tends to rot without a lot of deliberate effort.

This PR would add an enum -> string mapping for the J9ProcessorArchitecture enum. Digging through the code, there's already an incomplete mapping available in the JIT for this info:

https://github.com/eclipse/openj9/blob/9ba8115605ee87d37cb4ab2f4e7c91c48b54693f/runtime/compiler/env/ProcessorDetection.cpp#L470

And the J9ProcessorArchitecture enum appears to be missing several kinds of processors - in particular newer x86-64 processors and all versions of ARM.

I think we need to find a better way to consistently get this information rather than relying on enum to string mappings which will always be out of date.

Options to provide this info in the javacore:

• Use getauxval though it's not available on our lowest supported glibc level (2.11 I think)
• Parse /proc/cpuinfo and get the information there
• Something else?

In the bigger picture, the JIT and port library should share a common implementation of the processor detection code so there's only 1 place to keep up to date.

If that were the case, it becomes reasonable to rely on the common processor detection code to name the processor in the javacore

[fjeremic]

In the bigger picture, the JIT and port library should share a common implementation of the processor detection code so there's only 1 place to keep up to date.

Indeed this is the true solution. We have been doing cleanup in this area recently with the final goal of moving processor detection into the OMR port library.

[gaolibj]

I think we need to find a better way to consistently get this information rather than relying on enum to string mappings which will always be out of date.

Options to provide this info in the javacore:

* Use `getauxval` though it's not available on our lowest supported glibc level (2.11 I think)

* Parse ` /proc/cpuinfo` and get the information there

* Something else?

In the bigger picture, the JIT and port library should share a common implementation of the processor detection code so there's only 1 place to keep up to date.

If that were the case, it becomes reasonable to rely on the common processor detection code to name the processor in the javacore

Seems it's a common requirement for all platforms. I agree it's better if we can find a better way to consistently get this information instead of relying on enum to string mappings. BUT the options you mentioned in your update doesn't work on i platform as we don't have /proc directory on i.

[gaolibj]

In the bigger picture, the JIT and port library should share a common implementation of the processor detection code so there's only 1 place to keep up to date.

Indeed this is the true solution. We have been doing cleanup in this area recently with the final goal of moving processor detection into the OMR port library.

Can I know your detailed changes related to processor detection?

[fjeremic]

Can I know your detailed changes related to processor detection?

My most recent work was on Z in #3956. I have not had time since to work on this however.

[SueChaplain]

Do we need a docs:external label for this one please?

[DanHeidinga]

@SueChaplain This might qualify for a release note. Has the javacore format been documented? I was under the impression it hadn't been as it occasionally changes

[DanHeidinga]

Closing due to lack of updates. We can reopen or restart this if interest picks up again later

[SueChaplain]

@DanHeidinga - I know this is closed now, but for future reference we do try and keep up with changes in the javacore files: https://www.eclipse.org/openj9/docs/dump_javadump/

If this gets re-opened, we should assign a docs-external and update the doc.

[gaolibj]

Sorry for missing this issue. Can we reopen this issue? Seems I don't have authority to do it. We still have requirement to update javacore. @DanHeidinga

[pshipton]

Reopened.

[pshipton]

Reopened.

[fjeremic]

Indeed this is the true solution. We have been doing cleanup in this area recently with the final goal of moving processor detection into the OMR port library.

This is nearly complete as part of #7710 and eclipse-omr/omr#1644. The processor detection has already sunk into the OMR port library, and the JIT compiler has been hooked up to consume the port library processor detection. The last step that is needed is to initialize the port library for use in the compiler.

Whatever solution we come up with here should be cross platform and available on all architectures via the port library.

[gaolibj]

@fjeremic Do you mean the processor information will be print into javacore file for all platforms by your solution? If so, let me know when the feature is available. Then I will verify it on IBM i platform. Thanks.

[fjeremic]

@fjeremic Do you mean the processor information will be print into javacore file for all platforms by your solution? If so, let me know when the feature is available. Then I will verify it on IBM i platform. Thanks.

No, I meant the processor detection is sunk into OMR port library, so it is a common place where both the JIT compiler and RAS utility (javacore) can query. What you have here, i.e. using the j9sysinfo_get_processor_description API is the correct way of obtaining that information which is cross platform.

[gaolibj]

@fjeremic Got it. Thanks for your explanation.

[genie-openj9]

Can one of the admins verify this patch?