Supporting inline types in Java debugger

[Frederic Parain]

Thank you for looking at these changes!
Comments are inlined below.

> On Oct 8, 2019, at 06:33, David Simms <david.simms at oracle.com> wrote:
> 
> 
> Sorry for the delayed reply...
> 
> src/hotspot/share/prims/jni.cpp:2075
> 
> Isn't this dance repeated some where else (interpreter runtime) ?  Is it worth refactoring, maybe moving to instanceKlass ?
> 

Good point. I’ve added two methods to ValueKlass:

  oop read_flattened_field(oop obj, int offset, TRAPS);
  void write_flattened_field(oop obj, int offset, oop value, TRAPS);

and I’ve refactored all places where flattened fields were read from
or written to in runtime code (interpreter runtime: getfield/withfield/putfield,
JNI, and Unsafe).

> 
> General:
> 	• Testing is there any automated jdb testing ?
> 		• I assume this is actually a first pass for Daniil to get initial manual testing up ?

I guess he did manual testing (I did the same).

Testing the changes in this patch would require to:
  - update jdb tests in test/hotspot/jtreg/vmTestbase/nsk/jdb
  - update JDI tests in test/hotspot/jtreg/vmTestbase/nsk/jdi
  - update JDWP tests in test/hotspot/jtreg/vmTestbase/nsk/jdwp
  - update JVMTI tests in test/hotspot/jtreg/vmTestbase/nsk/jvmti
  - update JNI tests  (they are spread over several places)

I would prefer to wait until the user model is finalized, and we already
have a good idea how all the different specifications will be updated
to support inline types. All these components of the JPDA are highly
dependent on signatures, and we are expecting big changes to happen in
this area. 


> 	• Draft spec changes will need to be tracked somewhere
> 		• New RFE ?

I could create a new RFE, but as stated above, I don’t think we have
all the data yet to start drafting the new JPDA specs.

> 
> Otherwise, looks good as is.
> 
> 

The new webrev is here:

http://cr.openjdk.java.net/~fparain/jpda/webrev.01/index.html


Thank you,

Fred

> 
> 
> On 4/10/19 7:23 PM, Frederic Parain wrote:
>> This patch would address two open bugs:
>> 
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8211032
>> https://bugs.openjdk.java.net/browse/JDK-8211030
>> 
>> 
>> Fred
>> 
>> 
>> 
>>> On Oct 4, 2019, at 11:07, Frederic Parain <frederic.parain at oracle.com>
>>>  wrote:
>>> 
>>> I’ve just updated the webrev in place to fix an issue with fast JNI accessors
>>> (hard coded constants dependent on data structures elsewhere in the VM are bad).
>>> This issue exists on all platforms.
>>> 
>>> Fred
>>> 
>>> 
>>> 
>>>> On Oct 3, 2019, at 08:51, Frederic Parain <frederic.parain at oracle.com>
>>>>  wrote:
>>>> 
>>>> Greetings,
>>>> 
>>>> Here’s a patch to enable Java debugging with inline types:
>>>> 
>>>> 
>>>> http://cr.openjdk.java.net/~fparain/jpda/webrev.00/index.html
>>>> 
>>>> 
>>>> Using jdb, it enables the following operations:
>>>> - inspection of inline classes
>>>> - read/write operations on local variables containing inline values
>>>> - read/write operations on flattened fields
>>>> - read/write operations on flattened arrays
>>>> 
>>>> Those changes are relatively limited, but they impact all layers of
>>>> the JPDA: JDI, JDWP, JVMTI and JNI. Several of these changes will require
>>>> some spec updates. They also highlight some future issues with current
>>>> API (like com.sun.jdi.VirtualMachine.classesByName(String className)
>>>> which takes a class name to convert it into a L-type before sending
>>>> the request to the debuggee).
>>>> 
>>>> Debugging has been tested with jdb.
>>>> Other Java debugger are not guaranteed to work, for instance IntelliJ Idea
>>>> debugger still gets confused with Q-signatures.
>>>> 
>>>> We can decide to either push this code if people are interested in using Java
>>>> debuggers with inline types, or keep it has an exploration result that we can
>>>> exploit when finalizing inline types support for the whole Java platform.
>>>> 
>>>> Regards,
>>>> 
>>>> Fred
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
> 
>