RFR: 8203290: [PPC64, s390] Check functionality of JDK-8199712 (Flight Recorder) [v16]
Tyler Steele
duke at openjdk.java.net
Tue Feb 1 21:36:58 UTC 2022
On Sat, 29 Jan 2022 06:51:59 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>> Tyler Steele has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - Changes macoss -> macosx in problem list
>> - Refactors loadlib_aix: Removes redundant c++ class
>
> src/hotspot/os/aix/os_perf_aix.cpp line 631:
>
>> 629: net_stats[i].ibytes,
>> 630: net_stats[i].obytes,
>> 631: *network_interfaces);
>
> When looking at NetworkInterface, I saw that it copies the name into its own resource-area allocated string in the constructor. This is all over the place, SystemProcess assumes C-heap storage, NetworkInterface uses RA... :(
>
> The problem now is that your ResourceMark above may also destroy the internal string in NetworkInterface when the Stack is unwound beyond this function.
>
> Side note: this is what I don't like about how hotspot uses RA. Its often not clear which data are RA allocated without looking at the code. In Objective-C (at least how its used on Mac) they had a clear naming convention for methods that returned storage from the AutoReleasePool.
>
> The problem is also that with ResourceMarks cutting off your data, you may not see the problem until much later. Usually you only see immediate problems if the underlying arena (a chained list of malloced slabs) added a new slab under your ResourceMark, which then gets free'd when the ResourceMark goes out of scope.
>
> How to fix this:
> 1) revert to NEW_C_HEAP_ARRAY for your records array here, with appropriate cleanup, and remove ResourceMark
> 3) Change NetworkInterface class to use C-heap instead.
>
> I'd opt for (1) since it avoids discussions about changing shared code. I opened https://bugs.openjdk.java.net/browse/JDK-8280912 to change NetworkInterface, but don't wait for me.
I made the change in (1) as recommended.
-------------
PR: https://git.openjdk.java.net/jdk/pull/6885
More information about the build-dev
mailing list