Hi ! I think most of the developers must have tested Google Chrome by now. I have one query for all of you.According to Google Chrome is accessing the memory through pointers and It does some garbage collection through pointers. Is it really possible that BROWSERS can have direct access to physical memory through POINTERS for Garbage Collection? Is it really safe? Or is it a threat? I am also attaching an image of Google Chrome Comic book explaining more about the pointers' concept.
Accessing through pointers is something any application can do and chrome is no exception and the safety of it depends on how well you have checked and toiled with your pointers and I am sure there is nothing unsafe about it if you use it correctly
Brother ! Can you give me some idea where a browser needs to access physical memory to manage its processes ?
SomeObject obj = new SomeObject() is accessing memory and then if SomeObject does cleaning then it does through physical memory
well i dont know much abt it, but from little what i know abt pointers is tht they give u access to RAM, and not the actual HDD... like far pointer is just a trick to bypass into the priviledged area.. so i dont think thrs is much of a problem with it accessing the physical memory. let me know if i missed anything..or if i am wrong
FAR pointers are nothing to do with privileged memory, they are to do with pointer size. In earlier versions of Windows and other x86 environments (because this is a CPU issue), memory addresses comprised two parts: base and offset, both 16-bit. They would typically overlap by three nybbles, e.g. base could be 0x1000 and offset could be 0x2345, which would access 0x12345, and with this approach you had access to 1MB of address space (20 bits) without having to use 32-bit pointers. This goes back a way, it was c.1992 when I was fnertling around with this stuff so it's getting a bit hazy now, but IIRC the base pointer would be the segment base address with an implied "0" appended (e.g. 0x1000 actually refers to 0x10000), and a NEAR pointer was a 16-bit pointer into that segment. You would have stack segment (SS), data segment (DS) and others, and DLL writers would have to handle the SS!=DS problem; in EXEs, SS=DS and the stuff on the stack and in the heap would be in the same segment so you didn't really need to worry about whether allocated memory was on the stack or in static or heap memory. But in a DLL DS!=SS and it really mattered where variables were kept because you could get some nasty bugs if you thought they were on the stack when they weren't. As memory increased the overlap decreased but the base+offset idea stuck around; 16-bit pointers obviously took up half the space of 32-bit pointers and for most operations were fine, and operations were quicker because you were only doing pointer arithmetic on half the amount of data. The problem was that you had to think about both parts of the pointer all the time which led to annoyingly difficult hard to find bugs. Eventually 32-bit pointers (FAR pointers) became the norm and we all breathed out a collective sigh of relief when NEAR pointers pretty much disappeared in Win32. You can probably still have NEAR pointers if you want but believe me as someone who's been there, bought the T-shirt and squashed the bugs, you don't. Actually NEAR pointers are quite common, although not known as such. Code: char str[32]; for (int i=0; i<20; i++) str[i]='a'+i; In the above code, i is effectively a near pointer, and the overall address at any point is str+i.
