From Xiaohong.Gong at arm.com  Mon Sep  2 02:03:54 2019
From: Xiaohong.Gong at arm.com (Xiaohong Gong (Arm Technology China))
Date: Mon, 2 Sep 2019 02:03:54 +0000
Subject: RFR: 8230129: Add jtreg "serviceability/sa/ClhsdbInspect.java" to
 graal problem list.
In-Reply-To: <5c3dffcc-12bc-48a8-3edf-99e0ac415ced@oracle.com>
References: <AM0PR08MB34109182F30FAF582DC5452CF5A00@AM0PR08MB3410.eurprd08.prod.outlook.com>
 <5c3dffcc-12bc-48a8-3edf-99e0ac415ced@oracle.com>
Message-ID: <AM0PR08MB3410DD18948F1DFA1B0FFE13F5BE0@AM0PR08MB3410.eurprd08.prod.outlook.com>

Hi dean,

  Currently there is not a master bug for this issue. A similar issue is JDK-8216181, but it is not entirely same. I'm not sure whether the root cause is the same one. So I will make this issue as the master bug and create another SubTask for it. Thanks.

Thanks,
Xiaohong Gong

-----Original Message-----
From: dean.long at oracle.com <dean.long at oracle.com> 
Sent: Friday, August 30, 2019 7:40 AM
To: Xiaohong Gong (Arm Technology China) <Xiaohong.Gong at arm.com>; hotspot-compiler-dev at openjdk.java.net; graal-dev at openjdk.java.net
Cc: nd <nd at arm.com>
Subject: Re: RFR: 8230129: Add jtreg "serviceability/sa/ClhsdbInspect.java" to graal problem list.

Isn't it the correct process that there should be a master bug for fixing the test or underlying issue, then use that bug number for the problem list entry, and push it using a SubTask.? For example, see the relationship between JDK-8229447 and JDK-8229446 as an example.

dl

On 8/27/19 12:14 AM, Xiaohong Gong (Arm Technology China) wrote:
> Hi,
>
>    Please help to review this small patch:
>    Webrew: http://cr.openjdk.java.net/~pli/rfr/8230129/webrev.00/
>    JBS: https://bugs.openjdk.java.net/browse/JDK-8230129
>
>    Jtreg test "serviceability/sa/ClhsdbInspect.java" fails when running with Graal. It fails when inspecting an address to check whether it's pointing to an expected oop
> or method, which is printed by running "jstack -v" firstly.
>    When running with graal, it needs more java heap for the JVMCI initialization and the compiler working. So it's inevitable to make GC happen during the application
> running. If GC happens after runnning "jstack", the actual address of the oops and methods may be different when running "inpsect". And the address inspected may
> point to other object or nothing.
>    A simple fix is to add this test to the graal problem list.
>
> Thanks,
> Xiaohong Gong


From Xiaohong.Gong at arm.com  Mon Sep  2 02:24:27 2019
From: Xiaohong.Gong at arm.com (Xiaohong Gong (Arm Technology China))
Date: Mon, 2 Sep 2019 02:24:27 +0000
Subject: RFR: 8230129: Add jtreg "serviceability/sa/ClhsdbInspect.java" to
 graal problem list.
In-Reply-To: <AM0PR08MB3410DD18948F1DFA1B0FFE13F5BE0@AM0PR08MB3410.eurprd08.prod.outlook.com>
References: <AM0PR08MB34109182F30FAF582DC5452CF5A00@AM0PR08MB3410.eurprd08.prod.outlook.com>
 <5c3dffcc-12bc-48a8-3edf-99e0ac415ced@oracle.com>
 <AM0PR08MB3410DD18948F1DFA1B0FFE13F5BE0@AM0PR08MB3410.eurprd08.prod.outlook.com>
Message-ID: <AM0PR08MB3410520B7B813BBF99301A45F5BE0@AM0PR08MB3410.eurprd08.prod.outlook.com>

Hi dean,

  Sorry for my misunderstanding. I created a master bug JDK-8230419, and changed this issue as a Sub-Task for it.

Thanks,
Xiaohong Gong 

-----Original Message-----
From: Xiaohong Gong (Arm Technology China) 
Sent: Monday, September 2, 2019 10:04 AM
To: dean.long at oracle.com; hotspot-compiler-dev at openjdk.java.net; graal-dev at openjdk.java.net
Cc: nd <nd at arm.com>
Subject: RE: RFR: 8230129: Add jtreg "serviceability/sa/ClhsdbInspect.java" to graal problem list.

Hi dean,

  Currently there is not a master bug for this issue. A similar issue is JDK-8216181, but it is not entirely same. I'm not sure whether the root cause is the same one. So I will make this issue as the master bug and create another SubTask for it. Thanks.

Thanks,
Xiaohong Gong

-----Original Message-----
From: dean.long at oracle.com <dean.long at oracle.com>
Sent: Friday, August 30, 2019 7:40 AM
To: Xiaohong Gong (Arm Technology China) <Xiaohong.Gong at arm.com>; hotspot-compiler-dev at openjdk.java.net; graal-dev at openjdk.java.net
Cc: nd <nd at arm.com>
Subject: Re: RFR: 8230129: Add jtreg "serviceability/sa/ClhsdbInspect.java" to graal problem list.

Isn't it the correct process that there should be a master bug for fixing the test or underlying issue, then use that bug number for the problem list entry, and push it using a SubTask.? For example, see the relationship between JDK-8229447 and JDK-8229446 as an example.

dl

On 8/27/19 12:14 AM, Xiaohong Gong (Arm Technology China) wrote:
> Hi,
>
>    Please help to review this small patch:
>    Webrew: http://cr.openjdk.java.net/~pli/rfr/8230129/webrev.00/
>    JBS: https://bugs.openjdk.java.net/browse/JDK-8230129
>
>    Jtreg test "serviceability/sa/ClhsdbInspect.java" fails when 
> running with Graal. It fails when inspecting an address to check whether it's pointing to an expected oop or method, which is printed by running "jstack -v" firstly.
>    When running with graal, it needs more java heap for the JVMCI 
> initialization and the compiler working. So it's inevitable to make GC 
> happen during the application running. If GC happens after runnning "jstack", the actual address of the oops and methods may be different when running "inpsect". And the address inspected may point to other object or nothing.
>    A simple fix is to add this test to the graal problem list.
>
> Thanks,
> Xiaohong Gong


From Xiaohong.Gong at arm.com  Mon Sep  2 05:06:10 2019
From: Xiaohong.Gong at arm.com (Xiaohong Gong (Arm Technology China))
Date: Mon, 2 Sep 2019 05:06:10 +0000
Subject: RFR: 8230129: Add jtreg "serviceability/sa/ClhsdbInspect.java" to
 graal problem list.
In-Reply-To: <AM0PR08MB3410520B7B813BBF99301A45F5BE0@AM0PR08MB3410.eurprd08.prod.outlook.com>
References: <AM0PR08MB34109182F30FAF582DC5452CF5A00@AM0PR08MB3410.eurprd08.prod.outlook.com>
 <5c3dffcc-12bc-48a8-3edf-99e0ac415ced@oracle.com>
 <AM0PR08MB3410DD18948F1DFA1B0FFE13F5BE0@AM0PR08MB3410.eurprd08.prod.outlook.com>
 <AM0PR08MB3410520B7B813BBF99301A45F5BE0@AM0PR08MB3410.eurprd08.prod.outlook.com>
Message-ID: <AM0PR08MB34107D63AB97CA45514AD60AF5BE0@AM0PR08MB3410.eurprd08.prod.outlook.com>

Hi,

    This is the update version of this issue which changes the JBS id in ProblemList-graal.txt to the master bug id:
    Webrev: http://cr.openjdk.java.net/~xgong/rfr/8230129/webrev.00/webrev/
    JBS: https://bugs.openjdk.java.net/browse/JDK-8230129

    Please help to review. Thanks!

Thanks,
Xiaohong Gong
     
  
-----Original Message-----
From: Xiaohong Gong (Arm Technology China) 
Sent: Monday, September 2, 2019 10:24 AM
To: 'dean.long at oracle.com' <dean.long at oracle.com>; 'hotspot-compiler-dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>; 'graal-dev at openjdk.java.net' <graal-dev at openjdk.java.net>
Cc: nd <nd at arm.com>
Subject: RE: RFR: 8230129: Add jtreg "serviceability/sa/ClhsdbInspect.java" to graal problem list.

Hi dean,

  Sorry for my misunderstanding. I created a master bug JDK-8230419, and changed this issue as a Sub-Task for it.

Thanks,
Xiaohong Gong 

-----Original Message-----
From: Xiaohong Gong (Arm Technology China)
Sent: Monday, September 2, 2019 10:04 AM
To: dean.long at oracle.com; hotspot-compiler-dev at openjdk.java.net; graal-dev at openjdk.java.net
Cc: nd <nd at arm.com>
Subject: RE: RFR: 8230129: Add jtreg "serviceability/sa/ClhsdbInspect.java" to graal problem list.

Hi dean,

  Currently there is not a master bug for this issue. A similar issue is JDK-8216181, but it is not entirely same. I'm not sure whether the root cause is the same one. So I will make this issue as the master bug and create another SubTask for it. Thanks.

Thanks,
Xiaohong Gong

-----Original Message-----
From: dean.long at oracle.com <dean.long at oracle.com>
Sent: Friday, August 30, 2019 7:40 AM
To: Xiaohong Gong (Arm Technology China) <Xiaohong.Gong at arm.com>; hotspot-compiler-dev at openjdk.java.net; graal-dev at openjdk.java.net
Cc: nd <nd at arm.com>
Subject: Re: RFR: 8230129: Add jtreg "serviceability/sa/ClhsdbInspect.java" to graal problem list.

Isn't it the correct process that there should be a master bug for fixing the test or underlying issue, then use that bug number for the problem list entry, and push it using a SubTask.? For example, see the relationship between JDK-8229447 and JDK-8229446 as an example.

dl

On 8/27/19 12:14 AM, Xiaohong Gong (Arm Technology China) wrote:
> Hi,
>
>    Please help to review this small patch:
>    Webrew: http://cr.openjdk.java.net/~pli/rfr/8230129/webrev.00/
>    JBS: https://bugs.openjdk.java.net/browse/JDK-8230129
>
>    Jtreg test "serviceability/sa/ClhsdbInspect.java" fails when 
> running with Graal. It fails when inspecting an address to check whether it's pointing to an expected oop or method, which is printed by running "jstack -v" firstly.
>    When running with graal, it needs more java heap for the JVMCI 
> initialization and the compiler working. So it's inevitable to make GC 
> happen during the application running. If GC happens after runnning "jstack", the actual address of the oops and methods may be different when running "inpsect". And the address inspected may point to other object or nothing.
>    A simple fix is to add this test to the graal problem list.
>
> Thanks,
> Xiaohong Gong


From tobias.hartmann at oracle.com  Mon Sep  2 09:06:20 2019
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 2 Sep 2019 11:06:20 +0200
Subject: RFR: 8230129: Add jtreg "serviceability/sa/ClhsdbInspect.java" to
 graal problem list.
In-Reply-To: <AM0PR08MB34107D63AB97CA45514AD60AF5BE0@AM0PR08MB3410.eurprd08.prod.outlook.com>
References: <AM0PR08MB34109182F30FAF582DC5452CF5A00@AM0PR08MB3410.eurprd08.prod.outlook.com>
 <5c3dffcc-12bc-48a8-3edf-99e0ac415ced@oracle.com>
 <AM0PR08MB3410DD18948F1DFA1B0FFE13F5BE0@AM0PR08MB3410.eurprd08.prod.outlook.com>
 <AM0PR08MB3410520B7B813BBF99301A45F5BE0@AM0PR08MB3410.eurprd08.prod.outlook.com>
 <AM0PR08MB34107D63AB97CA45514AD60AF5BE0@AM0PR08MB3410.eurprd08.prod.outlook.com>
Message-ID: <6690b4bc-ef99-4b46-bd8e-890b40b7bb30@oracle.com>


On 02.09.19 07:06, Xiaohong Gong (Arm Technology China) wrote:
>     This is the update version of this issue which changes the JBS id in ProblemList-graal.txt to the master bug id:
>     Webrev: http://cr.openjdk.java.net/~xgong/rfr/8230129/webrev.00/webrev/
>     JBS: https://bugs.openjdk.java.net/browse/JDK-8230129

Looks good to me.

Best regards,
Tobias


From dean.long at oracle.com  Wed Sep  4 08:00:00 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Wed, 4 Sep 2019 01:00:00 -0700
Subject: RFR: 8230129: Add jtreg "serviceability/sa/ClhsdbInspect.java" to
 graal problem list.
In-Reply-To: <6690b4bc-ef99-4b46-bd8e-890b40b7bb30@oracle.com>
References: <AM0PR08MB34109182F30FAF582DC5452CF5A00@AM0PR08MB3410.eurprd08.prod.outlook.com>
 <5c3dffcc-12bc-48a8-3edf-99e0ac415ced@oracle.com>
 <AM0PR08MB3410DD18948F1DFA1B0FFE13F5BE0@AM0PR08MB3410.eurprd08.prod.outlook.com>
 <AM0PR08MB3410520B7B813BBF99301A45F5BE0@AM0PR08MB3410.eurprd08.prod.outlook.com>
 <AM0PR08MB34107D63AB97CA45514AD60AF5BE0@AM0PR08MB3410.eurprd08.prod.outlook.com>
 <6690b4bc-ef99-4b46-bd8e-890b40b7bb30@oracle.com>
Message-ID: <0995cadd-3b69-271b-080a-37abe18f888d@oracle.com>

+1

dl

On 9/2/19 2:06 AM, Tobias Hartmann wrote:
> On 02.09.19 07:06, Xiaohong Gong (Arm Technology China) wrote:
>>      This is the update version of this issue which changes the JBS id in ProblemList-graal.txt to the master bug id:
>>      Webrev: http://cr.openjdk.java.net/~xgong/rfr/8230129/webrev.00/webrev/
>>      JBS: https://bugs.openjdk.java.net/browse/JDK-8230129
> Looks good to me.
>
> Best regards,
> Tobias
>


From Xiaohong.Gong at arm.com  Thu Sep  5 02:50:41 2019
From: Xiaohong.Gong at arm.com (Xiaohong Gong (Arm Technology China))
Date: Thu, 5 Sep 2019 02:50:41 +0000
Subject: RFR: 8230454: [Graal] Add
 "com/sun/crypto/provider/KeyFactory/TestProviderLeak.java" to Graal problem
 list.
Message-ID: <VI1PR08MB34216243348E32AC08A2DD32F5BB0@VI1PR08MB3421.eurprd08.prod.outlook.com>

Hi,

  Please help to review this small patch:
  Webrev: http://cr.openjdk.java.net/~xgong/rfr/8230454/webrev.00/
  JBS: https://bugs.openjdk.java.net/browse/JDK-8230454
  Jtreg test  "com/sun/crypto/provider/KeyFactory/TestProviderLeak.java" unstably fails with graal
by throwing the OOME during JVMCI compiler initialization.
  It is caused by setting "-Xmx20m" for the application, which makes the java heap not enough for
the VM. A simple fix is to add it to the graal problem list. Hope it's ok for libgraal, so that we can
move it out from the list once libgraal is enabled.

Thanks,
Xiaohong Gong

From lists at fniephaus.com  Thu Sep  5 10:45:32 2019
From: lists at fniephaus.com (Fabio Niephaus)
Date: Thu, 5 Sep 2019 12:45:32 +0200
Subject: Call for Workshop Proposals for <Programming> 2020
Message-ID: <CADfnKi7cxurax-27-BzjvqesTzpewuvPSaUitY1HjEDhr0zXkg@mail.gmail.com>

<Programming> 2020 : The Art, Science, and Engineering of Programming

March 23-26, 2020, Porto, Portugal
http://2020.programming-conference.org

********************************************************
 CALL FOR WORKSHOPS
********************************************************

https://2020.programming-conference.org/track/programming-2020-workshops

To build a community and to foster an environment where participants can
exchange ideas and experiences related to practical software
development, ?Programming? will host a number of workshops, during the
days before the main conference. The workshops will provide a
collaborative forum to exchange recent and/or preliminary results, to
conduct intensive discussions on a particular topic, or to coordinate
efforts between representatives of a technical community. They are
intended as a forum for lively discussion of innovative ideas, recent
progress, or practical experience on programming and applied software
development in general for specific aspects, specific problems, or
domain-specific needs.

This year, we would like to host various types of meetings as well as
traditional workshops.  Possible types of workshops include a meeting
like a Dagstuhl Seminar or Shonan meeting, a gathering for an
international research project, a tool demo/tutorial, hands-on workshops
in which participants experience one or several aspects of practical
software development, and so on. Open meetings are preferable but
closed ones could be accepted. We are flexible; if you have any ideas
or questions, please contact the workshops co-chairs.

The duration of workshops is in general one day, but we encourage the
submission of half-day workshop proposals on focused topics as well. In
exceptional situations, e.g., for workshops that involve actual practice
of programming-related activities, workshop organizers can request a 2
day workshop slot. If desired, the workshop proceedings can be published
in the post-conference Companion Proceedings, in the ACM Digital Library.


### Submission Deadlines

Deadline: October 3rd, 2019

Notifications will go out as soon as possible, within a week after the deadline.

### Workshop Selection Committee

Shigeru Chiba (University of Tokyo, Japan)
Elisa Gonzalez Boix (Vrije Universiteit Brussel, Belgium)

### Submission and Workshop Process

Please submit your workshop proposal electronically via the submission system:
https://2020.programming-conference.org/createProposal/44137ee0-57de-4f75-aa62-84a4d0e53634
Please adhere to the workshop proposal guidelines given below and
provide all requested information about the proposed workshop.

Please keep it brief and use the provided form. The intention is not
to spend time on proposal writing, but on preparing the organization
of the workshop.

To coordinate with the deadlines of the main conference, the following
deadlines have to be respected by workshops:

**Workshop web page/site and CFP:** October 14th 2019

**Deadline for submissions to the workshops:**

  - after December 1st 2019 (first notification issue 3)
  - possibly after January 7th 2020 (final notification issue 3), if
this is feasible
  - no later than January 15th 2020

**Notification of authors:** February 15th 2020, the latest, to be
before the early registration deadline.

**Deadline for Camera-Ready Papers (ACM DL):**

  - for pre-proceedings before March 1st
  - for post-proceedings before May 1st

**Workshop dates:** March 23rd or 24th 2020

### Workshop Proposal Guidelines

Please include the following information either directly in the
proposal, or CFP.
The submission system has a form that includes an abstract (for the
website), the CFP, and the remaining proposal. CFPs often cover the
same information, duplication is not necessary for such cases.
Organizers of a workshop previously co-located at <Programming> are
allowed to submit a minimal proposal including information for the
questions marked with (*).

1. What is the motivation for the workshop?
    - Objectives
    - Intended audience
    - Relevance (with respect to the topics of the <Programming> conference)
2(*). Who organizes the workshop?
    - Organizers and primary contact (name / affiliation / email)
    - Brief details on the organizers (previous workshop organizing
experience, etc.)
    - Data on potential previous iterations of the workshop
        - How many participants do you expect (please make at least an
educated guess)
        - What kind of equipment do you need (e.g., data projector,
computer, whiteboard)
    - Advertisement: Planed advertisement strategy to ensure
sufficient participation
3. Is there going to be a workshop program committee?
    - if so, please list the members (indicated as finalized or expected)
4. What is the planed workshop format?
    - Planned deadlines
    - Intended submission format (e.g. intended format for articles,
posters, abstracts, or any other kind of submission requested to
participate in the workshop)
    - Evaluation process for submissions
    - Intended workshop format (including duration, number of
presentations, and planned invited talks/keynotes)
5(*). What is the intended publication of accepted submissions?
- ACM DL proceedings or website
- either as pre or post companion

### Notes on Proceedings

Workshops that wish to have their proceedings published in the ACM DL
will have the opportunity to have either a pre or post proceedings.
However, chairs will be responsible for making sure that camera ready
deadlines are respected so that final copies and metadata are
collected on time. The deadlines mentioned above are **strict** and we
won't be able to extend them. Please consider them carefully when
determining your deadlines for the workshop.

From mohamed.ez.zarghili at oracle.com  Tue Sep 10 11:23:20 2019
From: mohamed.ez.zarghili at oracle.com (Mohamed EZZARGHILI)
Date: Tue, 10 Sep 2019 12:23:20 +0100
Subject: JVMCI Release 19.3-b02
Message-ID: <4E4DF981-3777-44DF-A75A-3B826CA45C96@oracle.com>

Hi

The 19.3-b02 release includes:

[GR-17920] Handle missing or non-cloneable SHA-1 implementation.
[GR-16353] Added a getter of an address of current JavaThread into HotSpotJVMCIRuntime.


The binaries are available at:

https://github.com/graalvm/openjdk8-jvmci-builder/releases/tag/jvmci-19.3-b02 <https://github.com/graalvm/openjdk8-jvmci-builder/releases/tag/jvmci-19.3-b02>

- Mohamed

From dean.long at oracle.com  Tue Sep 17 05:09:46 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Mon, 16 Sep 2019 22:09:46 -0700
Subject: RFR(XL) 8229201: Update Graal
Message-ID: <f5a0b71f-c49b-90af-ba90-26b07ffefc71@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8229201
http://cr.openjdk.java.net/~dlong/8229201/webrev/

This is a Graal update.? Changes since JDK-8226771 are listed here:

http://cr.openjdk.java.net/~dlong/8229201/changes-since-JDK-8226771.txt

dl


From vladimir.kozlov at oracle.com  Tue Sep 24 16:22:08 2019
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 24 Sep 2019 09:22:08 -0700
Subject: RFR(XL) 8229201: Update Graal
In-Reply-To: <f5a0b71f-c49b-90af-ba90-26b07ffefc71@oracle.com>
References: <f5a0b71f-c49b-90af-ba90-26b07ffefc71@oracle.com>
Message-ID: <a7e93bfe-5ab3-3b83-d87e-7f6ea184490c@oracle.com>

Looks good. And tests results seem good.

Thanks,
Vladimir

On 9/16/19 10:09 PM, dean.long at oracle.com wrote:
> https://bugs.openjdk.java.net/browse/JDK-8229201
> http://cr.openjdk.java.net/~dlong/8229201/webrev/
> 
> This is a Graal update.? Changes since JDK-8226771 are listed here:
> 
> http://cr.openjdk.java.net/~dlong/8229201/changes-since-JDK-8226771.txt
> 
> dl
> 

From dean.long at oracle.com  Tue Sep 24 16:51:28 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Tue, 24 Sep 2019 09:51:28 -0700
Subject: RFR(XL) 8229201: Update Graal
In-Reply-To: <a7e93bfe-5ab3-3b83-d87e-7f6ea184490c@oracle.com>
References: <f5a0b71f-c49b-90af-ba90-26b07ffefc71@oracle.com>
 <a7e93bfe-5ab3-3b83-d87e-7f6ea184490c@oracle.com>
Message-ID: <f6dce5a8-b884-dd9a-face-5373a43aeb23@oracle.com>

Thanks Vladimir.

dl

On 9/24/19 9:22 AM, Vladimir Kozlov wrote:
> Looks good. And tests results seem good.
>
> Thanks,
> Vladimir
>
> On 9/16/19 10:09 PM, dean.long at oracle.com wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8229201
>> http://cr.openjdk.java.net/~dlong/8229201/webrev/
>>
>> This is a Graal update.? Changes since JDK-8226771 are listed here:
>>
>> http://cr.openjdk.java.net/~dlong/8229201/changes-since-JDK-8226771.txt
>>
>> dl
>>


From mohamed.ez.zarghili at oracle.com  Sun Sep 29 22:11:41 2019
From: mohamed.ez.zarghili at oracle.com (Mohamed EZZARGHILI)
Date: Sun, 29 Sep 2019 23:11:41 +0100
Subject: JVMCI Release 19.3-b03
Message-ID: <E1E3453D-BCDA-4F85-925E-DCDA1434DDDF@oracle.com>

Hi

The 19.3-b03 release includes:

[GR-18349] Add default implementation for encoded SpeculationReasons.
[GR-18347] Reduce bits required for OopMapValue::oop_types.
[GR-18524] Fix some build errors.
[GR-16685] Deoptimization can recover a virtualized byte array.
[GR-17318] Add isBeingInitialized.
[GR-18537] Fix bug in debug code from OopMap changes.

The binaries are available at:

https://github.com/graalvm/openjdk8-jvmci-builder/releases/tag/jvmci-19.3-b03

- Mohamed