1147680 - Consider using PR_MemMap when deserializing heap snapshots

Status: RESOLVED FIXED

(DevTools :: Memory, defect)

Description

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

> ::: toolkit/devtools/server/ChromeUtils.cpp
> @@ +425,5 @@
> > +
> > +  uint32_t bytesRead = 0;
> > +  while (bytesRead < size) {
> > +    uint32_t bytesLeft = size - bytesRead;
> > +    int32_t bytesReadThisTime = PR_Read(fd, buffer.get() + bytesRead, bytesLeft);
> 
> For the future: there is a PR_MemMap.

Comment 1

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Attachment: Use PR_MemMap when deserializing heap snapshots

Comment 2

[Jim Blandy :jimb]

Comment on attachment 8614945 [details] [diff] [review]
Use PR_MemMap when deserializing heap snapshots

Review of attachment 8614945 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/devtools/server/AutoMemMap.h
@@ +32,5 @@
> +{
> +  MOZ_DECL_USE_GUARD_OBJECT_NOTIFIER;
> +
> +  PRFileInfo64 fileInfo;
> +  PRFileDesc*  fd;

Just curious, does NSPR actually require you to keep fd open while the memory is mapped? On POSIX, at least, you can map the file, and then close the fd, and the mapping holds its own reference to the file that is automatically dropped when the memory is freed. If NSPR works this way, then we could open the fd in init, do the mapping, and then close it. No need to keep it around.

Comment 3

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=5f2fdcefa7db

Comment 4

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ddadcaa630f0

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/ddadcaa630f0