Closed Bug 459851 Opened 12 years ago Closed 11 years ago
windows mobile System
.private Bytes and -memstats private Bytes always returns 0
In windows mobile the privateBytes in memstats and System.privateBytes is unimplemented and always returns 0. linux is also unimplemented see bug 459038 testcase: add to end of an existing test: import avmplus.System; print('private bytes: '+System.privateBytes); in acceptance tests see test in: as3/ShellClasses/toplevel.as
Assignee: nobody → treilly
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → Future
Comment on attachment 385390 [details] [diff] [review] Implement private bytes for winmo I'm +1 this b/c its coming from the player where it work supposedly, I don't get it. Getting Lar's to suprev.
Comment on attachment 385390 [details] [diff] [review] Implement private bytes for winmo I want to see reasonably good documentation of the winmo mechanism, notably the meaning of addr and endAddr which both seem arbitrary without that info. (Notably the correctness of both.) I also think that instead of ifdeffing the function to death you should have a function for non-WINCE and another one for WINCE. Attaching the doc'n to the WINCE function would be appropriate.
Attachment #385390 - Flags: superreview?(lhansen) → superreview-
I looked into the addr/endAddr stuff and found this link from MS explaining the memory layout under CE: http://msdn.microsoft.com/en-us/library/bb331824.aspx So it looks like 0x10000 - 0x2000000 is the 32mb that makes up the "process slot" (figure 2 in the link). I believe GCHeap allocates memory out of the large memory area (0x42000000 - 0x80000000) to avoid the 32mb limit, so the 2nd half of the code tries to walk through those regions and account for the memory used. However, according to the link this is how CE 5.0 and earlier works, so I'm not sure if any of this applies to CE 6.0, and I think we're mostly running on 6.0 now. I'll have to ask rob about it, as he wrote this code, but he's out this week. And I will change the ifdef madness too.
Added documentation to patch, broke WinMo version into its own ifdef'ed function instead of ifdefing the implementation. Talked to rob, and it turns out that WinMo 6.0 is built on top of WinCE 5.0, so that is why we have to do all the funky memory walking.
Comment on attachment 386976 [details] [diff] [review] Updated patch Nice.
Attachment #386976 - Flags: superreview?(lhansen) → superreview+
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.