Re: RFR: 8279194: Add Annotated Memory Viewer feature to SA's HSDB [v3]

2022-01-03 Thread Chris Plummer
> HSDB has a Memory Viewer feature that brings up a window that shows the 
> memory contents in a specific address range. It basically looks just like the 
> clhsdb "mem" output. The recently revived "mem" command (see 
> [JDK-824466](https://bugs.openjdk.java.net/browse/JDK-8244669) and PR #6902) 
> adds a -v options which causes PointerFinder (aka findpc) to be called on 
> each value in memory to provide details about what the value points to (if it 
> is an address). This PR adds this same feature to HSDB by adding a new 
> Annotated Memory Viewer window. See the [this 
> image](https://bugs.openjdk.java.net/secure/attachment/97439/memory_viewer.png)
>  which shows the current Memory Viewer window, and just below it the new 
> Annotated Memory Viewer window showing the same address range. 
> 
> A couple of implementation notes. Both types of memory viewers share the 
> MemoryPanel class. The traditional viewer uses two columns, one for the  
> address and one for its contents. The annotated viewer uses just one column 
> which contains the entire line. For example:
> 
>   0x7f7eb010c330: 0x7f7eb6c9dfb0 vtable for os::PlatformMonitor + 0x10
> 
> This approach was chosen rather than using 3 columns because it was a 
> difficult to get the first two columns to be just wide enough for the 64-bit 
> values while having the 3rd column be a long line of text. You end up with a 
> lot of wasted space in the first two columns as you make the window wider 
> while trying to get all the text of the 3rd column into view.
> 
> Regarding the changes in MemoryPanel.handleImport(), Memory Viewer supports 
> clicking on a value that's an address and dragging it back onto the window to 
> start displaying memory at that address. This dropped text ends up being 
> processed by MemoryPanel.handleImport(). When you try this with Annotated 
> Memory Viewer, you end up with the entire line being passed to 
> MemoryPanel.handleImport(), not just an address (one downside of going with 
> just 1 column instead of 3). So the changes in MemoryPanel.handleImport() 
> detect this and pull the desired address out of the string.

Chris Plummer has updated the pull request incrementally with one additional 
commit since the last revision:

  Fixed indentation.

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6923/files
  - new: https://git.openjdk.java.net/jdk/pull/6923/files/0143116d..f3768300

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=6923=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6923=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6923.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6923/head:pull/6923

PR: https://git.openjdk.java.net/jdk/pull/6923


Re: RFR: 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 [v2]

2022-01-03 Thread Daniel D . Daugherty
On Fri, 31 Dec 2021 23:54:22 GMT, David Nadlinger  wrote:

>> @gerard-ziemski - Thanks for the re-review!
>
> @dcubed-ojdk: I just ran into this in the Julia runtime and reached a similar 
> conclusion/fix. Did you find out anything more about why this happens? At a 
> glance, I didn't see any blatant `addr == -1`-style checks in the latest dyld 
> open-source dump.

@dnadlinger - No I haven't chased this any further.

Also please see this note in the bug report:

https://bugs.openjdk.java.net/browse/JDK-8273967?focusedCommentId=14455403=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14455403

-

PR: https://git.openjdk.java.net/jdk/pull/6193