RFR: 8062247: Allow WhiteBox test to access JVM offsets
Christian Tornqvist
christian.tornqvist at oracle.com
Tue Oct 28 18:21:40 UTC 2014
I agree with Coleen, we shouldn't create and pass a Java hash table back. There has to be a better solution using native data structures.
Thanks.
Christian
-----Original Message-----
From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore
Sent: Tuesday, October 28, 2014 2:10 PM
To: hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR: 8062247: Allow WhiteBox test to access JVM offsets
Hi Yumin,
Can you not create Java hashtables from C++? This is really convoluted. I think there may be a more direct way to encode these offsets and get their values. Eg. Have a WB API to
get_offset("value") and have a table coded in the WB api to associate the value string with the offset. At worst, use a C++ hashtable to perform this association.
Because the WB api calls up to Java for each hashtable insert, it's not like calling back to WB api for the offset is going to be less efficient.
I don't like this change.
Thanks,
Coleen
On 10/28/2014 12:01 AM, Yumin Qi wrote:
> Please review
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8062247
> webrev: http://cr.openjdk.java.net/~minqi/8062247/webrev00/
>
> Summary: Internal test failed since the variable offsets changed in
> hotspot. The way to get offset in the test is hard-coded. To reduce
> the risk of future changes of hotspot offsets, the fix add a WhiteBox
> API function to get a map for FileMapHeaderInfo, which return the
> members' offsets in a Hashtable.
>
> Tests: JPRT, jtreg.
>
> Thanks
> Yumin
More information about the hotspot-runtime-dev
mailing list