Re: [webkit-dev] Some queries regarding WebKit 2.x
Thanks for the information. By WebKit 2.x, I meant WebKit "Tip of tree". Does WebKit "Tip of tree" support any w3c specifications for HTML, xHTML, CSS, DOM, SVG and JavaScript? Thanks, Tuheen -Original Message- From: Mark Rowe [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2008 11:13 PM To: Sinha Tuheen-A19034 Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Some queries regarding WebKit 2.x On Jun 4, 2008, at 3:29 AM, Sinha Tuheen-A19034 wrote: > Hi All, > I had some queries regarding WebKit 2.x. I would really > appreciate if someone can help me. > > 1. Do we have some stable version of WebKit 2.x available? I have seen > several nightly builds, but not sure if we have a place where we > release stable versions too. > > 2. Is WebKit 2.x compliant with any W3C standards for HTML, CSS, DOM, > JavaScript and CSS? > What is "WebKit 2.x" that you are referring to? Historically the WebKit project has not used version number, nor done releases of WebKit beyond the nightly development builds. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit memory management?
I have implemented a version of Maciej's suggestion #2 below, with basic
documentation and a basic test. A slight alternative would be to change
the 'new' syntax to to use a macro which would allow for a simpler
reference version that used global new/delete, but would introduce a
preprocessor macro. I can also create an example of Maciej's suggestion
#1, though it will have to wait a few hours while I finish some other work.
// Customizable overrides of operator new/delete
//
// Provided functionality:
//T* wk_new();
//T* wk_new_array(count);
//void wk_delete(T* p);
//void wk_delete_array(T* p);
//
// Example usage:
//char* pChar = wk_new();
//wk_delete(pChar);
//
//char* pCharArray = wk_new_array(37);
//wk_delete_array(pCharArray);
//
//POD* pPOD = wk_new();
//wk_delete(pPOD);
//
//POD* pPODArray = wk_new_array(37);
//wk_delete_array(pPODArray);
//
//Object* pObject = wk_new();
//wk_delete(pObject);
//
//Object* pObjectArray = wk_new_array(37);
//wk_delete_array(pObjectArray);
//
template
inline T* wk_new()
{
void* p = malloc(sizeof(T));
if(p)
return new(p) T;
return NULL;
}
// Note that the code below is similar to what the compiler generates
for built-in array operator new.
// This can be specialized for POD types to avoid the array size prefix
altogether.
// It can be specialized for types with natural alignment less than
uint64_t and save 4 bytes on 32 bit systems.
template
inline T* wk_new_array(size_t count)
{
uint64_t* p = (uint64_t*)malloc(sizeof(uint64_t) + (sizeof(T) * count));
if(p)
{
*p++ = (uint64_t)count;
for(T* pObject = (T*)(void*)p, *pObjectEnd = pObject + count;
pObject != pObjectEnd; ++pObject)
new(pObject) T; // To consider: handle ctor exceptions.
}
return (T*)(void*)p;
}
// Note that the code below is similar to what the compiler generates
for built-in array operator new.
template
inline void wk_delete(T* p)
{
if(p) // As per the C++ standard, test for NULL.
{
p->~T();
free(p);
}
}
// Note that the code below is similar to what the compiler generates
for built-in array operator delete.
// This can be specialized for POD types to avoid the array size prefix
altogether.
// It can be specialized for types with natural alignment less than
uint64_t and save 4 bytes on 32 bit systems.
template
void wk_delete_array(T* p)
{
if(p) // As per the C++ standard, test for NULL.
{
T* pEnd = p + *((uint64_t*)p - 1);
while(pEnd-- != p)
pEnd->~T();
free((void*)((uint64_t*)p - 1));
}
}
Basic test code:
struct Object
{
static int ctorCount;
static int dtorCount;
Object() { ++ctorCount; }
Object(const Object&) { ++ctorCount; }
~Object() { ++dtorCount; }
Object& operator =(const Object&) { }
};
int Object::ctorCount = 0;
int Object::dtorCount = 0;
struct POD
{
int x;
};
template
void VerifyIsAligned(T* p)
{
assert((size_t)uintptr_t)p ^ ((uintptr_t)p - 1)) >> 1) + 1) >=
sizeof(T));
}
void DoSomething()
{
// char
char* pChar = wk_new();
wk_delete(pChar);
char* pCharArray = wk_new_array(37);
wk_delete_array(pCharArray);
// double
double* pDouble = wk_new();
VerifyIsAligned(pDouble);
wk_delete(pDouble);
double* pDoubleArray = wk_new_array(37);
VerifyIsAligned(pDoubleArray);
wk_delete_array(pDoubleArray);
// POD
POD* pPOD = wk_new();
VerifyIsAligned(pPOD);
wk_delete(pPOD);
POD* pPODArray = wk_new_array(37);
VerifyIsAligned(pPODArray);
wk_delete_array(pPODArray);
// Object
Object* pObject = wk_new();
VerifyIsAligned(pObject);
wk_delete(pObject);
Object* pObjectArray = wk_new_array(37);
VerifyIsAligned(pObjectArray);
wk_delete_array(pObjectArray);
assert((Object::ctorCount == 38) && (Object::dtorCount == 38));
}
>
> On Jun 3, 2008, at 10:58 PM, Paul Pedriana wrote:
>> Thanks for the response. I'm sorry, and perhaps I misunderstand, but
>> I believe your statement about inline operator new is incorrect.
>> Unless I misunderstand you, what you say is not supported by any
>> existing compiler nor is it supported by the C++ language standard.
>> In summary, the 'inline' keyword does not negate or obviate the One
>> Definition Rule. You can demonstrate the problem with the code below.
>> Feel free to correct any misunderstanding that I may have of your
>> explanation.
>
> This happens to work as intended on Mac OS X because
> WTF_PRIVATE_INLINE expands to:
>
> __private_extern__ inline __attribute__((always_inline
Re: [webkit-dev] WebKit memory management?
Hi Chris, On Jun 4, 2008, at 2:37 PM, Chris Brichford wrote: > I have two "clever" ideas, which might be bad ones, that would not > involve massive changes to the existing code: Interesting ideas. It appears that both of these would impost runtime cost (since calls to allocator-related functions would always be indirect through a pointer), unlike the two proposals I made. They also seem to be geared towards switching the allocator at runtime (possibly even per--instance), which is something we're not really looking at here. The main issues we'd like to address are: 1) Overloading global operator new and delete can interfere with other C++ code in the same program, making FastMalloc unusable for some ports. 2) We'd like to have ways for ports to replace FastMalloc at compile- time, but this is blocked by #1. I will also note that Nokia in their S60 port made a conservative low-memory allocator that allows allocations to be strictly bounded, but this work has not been merged to WebKit trunk. > 1) Have a global variable that points to context that code in the > platform layer ( including things like malloc, free, operator new, > and operator delete ) can use. Then have a class that is > instantiated on the stack before any call in to WebKit. The > constructor for this class would copy the value of the global into a > member variable and set the global variable to point to the correct > context. The destructor for this class would restore the previous > value of the global variable store in the member variable. This proposal in particular seems like it still involves overloading global operator new and operator delete, which I think still creates a problem for linking with non-WebKit C++ code. > > 2) Use llvm ( http://llvm.org/) to create a C++ compiler that > compiles WebKit into a C or C++ program ( you could also directly > generate machine code ) where every function ( including class > methods ) in webkit has an addition argument that points to the > "global" state. The generated code would reference all global state > ( including static variables in classes and function ) relative to > this additional argument. The client of webkit would have to > allocate a buffer large enough to contain this global state ( the > compiler would have to figure out how big the buffer needed to be ) > and pass it into all WebKit entry points. You'd be able to have > multiple copies of WebKit's global state in the same process. You'd > have to hooks you need to destroy an instance of WebKit such that > you know all resources given to WebKit have been destroyed. Similar > to the way an OS can tear down a process and reclaim an resources > give to that process. Adding an extra parameter to every function would be a pretty big runtime hit, and source-to-source translation at build time is, I think, not so great for debuggability. I'm thinking we'll probably have to bite the bullet and make some sort of pervasive code change to use our custom allocator in a sound way. It's unfortunate but I think the semantics of C++ force our hand. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit memory management?
I have two "clever" ideas, which might be bad ones, that would not involve massive changes to the existing code: 1) Have a global variable that points to context that code in the platform layer ( including things like malloc, free, operator new, and operator delete ) can use. Then have a class that is instantiated on the stack before any call in to WebKit. The constructor for this class would copy the value of the global into a member variable and set the global variable to point to the correct context. The destructor for this class would restore the previous value of the global variable store in the member variable. 2) Use llvm ( http://llvm.org/) to create a C++ compiler that compiles WebKit into a C or C++ program ( you could also directly generate machine code ) where every function ( including class methods ) in webkit has an addition argument that points to the "global" state. The generated code would reference all global state ( including static variables in classes and function ) relative to this additional argument. The client of webkit would have to allocate a buffer large enough to contain this global state ( the compiler would have to figure out how big the buffer needed to be ) and pass it into all WebKit entry points. You'd be able to have multiple copies of WebKit's global state in the same process. You'd have to hooks you need to destroy an instance of WebKit such that you know all resources given to WebKit have been destroyed. Similar to the way an OS can tear down a process and reclaim an resources give to that process. Chris. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak Sent: Wednesday, June 04, 2008 12:49 PM To: Paul Pedriana Cc: WebKit-Dev; Mark Rowe Subject: Re: [webkit-dev] WebKit memory management? . . . . I can think of two possible solutions: 1) Instead of overloading the global operator new and delete, have a FastAllocated base class that overloads the class operator new and delete, and make every class in WebCore and JavaScriptCore inherit from it; for non-class types, avoid using new, delete, new[] or delete[] (perhaps template functions could be provided). The downside is that I can't think of an easy way to then flag mistaken use of new/delete on primitive types, or forgetting to inherit from the FastAllocated base class. Then again, we don't try to flag mistaken use of malloc() instead of fastMalloc() and that has been ok. 2) Require allocation to happen in some way other than "new" and "delete", for instance always with template functions. Then perhaps we could use #defines to make any actual use of "new" and "delete" an error. Either of these would be a large change to the source, especially #2 (#1 only needs to affect classes with no other subclass and the few places we use new[] on non-class types to make arrays). Perhaps someone else has a more clever idea. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit memory management?
On 4-Jun-08, at 3:49 PM, Maciej Stachowiak wrote: > > On Jun 3, 2008, at 10:58 PM, Paul Pedriana wrote: >> Thanks for the response. I'm sorry, and perhaps I misunderstand, >> but I believe your statement about inline operator new is >> incorrect. Unless I misunderstand you, what you say is not >> supported by any existing compiler nor is it supported by the C++ >> language standard. In summary, the 'inline' keyword does not >> negate or obviate the One Definition Rule. You can demonstrate the >> problem with the code below. Feel free to correct any >> misunderstanding that I may have of your explanation. > > This happens to work as intended on Mac OS X because > WTF_PRIVATE_INLINE expands to: > > __private_extern__ inline __attribute__((always_inline)) > > This prevents an externally visible definition of global operator > new and delete from being seen. > > I agree this is technically wrong and I suspect it may cause > problems on, for example, Linux platforms. I think the Qt port has > turned off FastMalloc for this reason. That's correct. It's definitely a problem there. -- George Staikos Torch Mobile Inc. http://www.torchmobile.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit memory management?
On Jun 3, 2008, at 10:58 PM, Paul Pedriana wrote:
Thanks for the response. I'm sorry, and perhaps I misunderstand, but
I believe your statement about inline operator new is incorrect.
Unless I misunderstand you, what you say is not supported by any
existing compiler nor is it supported by the C++ language standard.
In summary, the 'inline' keyword does not negate or obviate the One
Definition Rule. You can demonstrate the problem with the code
below. Feel free to correct any misunderstanding that I may have of
your explanation.
This happens to work as intended on Mac OS X because
WTF_PRIVATE_INLINE expands to:
__private_extern__ inline __attribute__((always_inline))
This prevents an externally visible definition of global operator new
and delete from being seen.
I agree this is technically wrong and I suspect it may cause problems
on, for example, Linux platforms. I think the Qt port has turned off
FastMalloc for this reason.
I can think of two possible solutions:
1) Instead of overloading the global operator new and delete, have a
FastAllocated base class that overloads the class operator new and
delete, and make every class in WebCore and JavaScriptCore inherit
from it; for non-class types, avoid using new, delete, new[] or
delete[] (perhaps template functions could be provided). The downside
is that I can't think of an easy way to then flag mistaken use of new/
delete on primitive types, or forgetting to inherit from the
FastAllocated base class. Then again, we don't try to flag mistaken
use of malloc() instead of fastMalloc() and that has been ok.
2) Require allocation to happen in some way other than "new" and
"delete", for instance always with template functions. Then perhaps we
could use #defines to make any actual use of "new" and "delete" an
error.
Either of these would be a large change to the source, especially #2
(#1 only needs to affect classes with no other subclass and the few
places we use new[] on non-class types to make arrays).
Perhaps someone else has a more clever idea.
Regards,
Maciej
I do not mean to criticize WebKit. We think it is a great thing
which in general is surprisingly well coded. We would love to work
with any resolution which has the desired effect in the way of
memory management.
The error you get:
SomeLib.lib: error LNK2005: "void * __cdecl operator new(unsigned
int)" ([EMAIL PROTECTED]@Z) already defined in main.obj
SomeLib.lib: error LNK2005: "void __cdecl operator delete(void
*)" ([EMAIL PROTECTED]@Z) already defined in main.obj
Source code:
// Main.cpp
#include
extern void DoSomething();
void* operator new(size_t s){ return malloc(s); }
void operator delete(void* p) { free(p); }
void* operator new[](size_t s) { return malloc(s); }
void operator delete[](void* p){ free(p); }
int main(int, char*[]) {
void* p = malloc(10);
free(p);
DoSomething();
return 0;
}
// SomeLib.cpp - compiled in a separate lib
#include
inline void* operator new(size_t s) { return malloc(s); }
inline void operator delete(void* p) { free(p); }
inline void* operator new[](size_t s) { return malloc(s); }
inline void operator delete[](void* p) { free(p); }
void DoSomething(){
void* p = malloc(10);
free(p);
}
Thanks.
On 03/06/2008, at 21:13, Paul Pedriana wrote:
Thanks for the info. IMHO, tcmalloc is not appropriate for console,
embedded, and mobile platforms. It trades space for speed, and
that's
the opposite of what you want outside the desktop. This is why the
Nokia
S60 people replaced tcmalloc, for example.
As far as I can tell, Nokia's S60 port predates the adoption of
tcmalloc by WebKit. The code in their latest svn.webkit.org source
tree contains a variant of dlmalloc that was used up until Safari
2.0, though I have not checked to see whether it is compiled in to
their build. That said, it is obvious that the space vs. speed
tradeoffs differ between devices, and that flexibility in the
memory allocator used is desirable.
Unfortunately, overriding operator new and delete does not do the
right
thing. These operators are application-global functions and when you
redirect them for one library you are thus redirecting them for the
entire rest of the app. Needless to say, that is a bad thing. In
console
and embedded development, as I note in the aforementioned paper,
it is
typically verboten for a library to use operator new/delete.
On the platforms with which I am familiar, the implementation that
I linked to has no effect outside of the library in which it is
defined. I've not worked with consoles or embedded devices so the
toolchain and environment may differ there, but I would be a little
surprised to see an inline function that is implemented in a header
become visible to an object file that did not include the header.
Neither will you see professional commercial software do this.
It's also a problem to hav
Re: [webkit-dev] WebKit memory management?
WebKit already has the concept of a arena allocator. I've always thought this could be expanded and formalized right now its restricted to rendering. On Wed, Jun 4, 2008 at 11:59 AM, Darin Adler <[EMAIL PROTECTED]> wrote: > On Jun 4, 2008, at 11:38 AM, Paul Pedriana wrote: > >> I can understand that some developers who have spent a lot of time >> developing monolithic desktop or server software are used to using >> the built-in global operator new. The concept of controlling memory >> like I am proposing is the rule in commercial library development >> and not the exception. I humbly ask that the WebKit team consider >> migrating towards this type of development. It will make WebKit >> considerably stronger outside the desktop market, and yet is rather >> easy to apply. It's largely a matter of accepting an idea that is a >> little different from what some have done in the past. > > Your tone here stinks. Many others working on WebKit are > professionals, probably with more commercial library experience than > you, and many of the WebKit contributors work on software for > constrained mobile devices. > > That having been said, I think this is a great suggestion. Are you > willing to do this work, or are you expecting someone else to do it? > > -- Darin > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit memory management?
I am honestly sorry for any poor tone; it is not intended. Email has a way of doing this kind of thing, and I was hoping that my other statements of how I am otherwise impressed with the quality of WebKit might help make up for this. I didn't mean to say that because it's common in commercial libraries that people working on WebKit don't have experience in commercial libraries. I meant to use commercial libraries as a good design precedent to follow and which I believe WebKit is not currently aligned with. I can understand how the latter statement may be interpreted by some as the former. I am not expecting somebody else to work on this. I would completely take this on myself, though I expect others may have useful suggestions and improvements. Actually I wish I could contribute even more to this project, though my current employment keeps me busy enough that this is hard to do. Thanks. > I can understand that some developers who have spent a lot of time > developing monolithic desktop or server software are used to using the > built-in global operator new. The concept of controlling memory like I > am proposing is the rule in commercial library development and not the > exception. I humbly ask that the WebKit team consider migrating > towards this type of development. It will make WebKit considerably > stronger outside the desktop market, and yet is rather easy to apply. > It's largely a matter of accepting an idea that is a little different > from what some have done in the past. > > Your tone here stinks. Many others working on WebKit are > professionals, probably with more commercial library experience than > you, and many of the WebKit contributors work on software for > constrained mobile devices. > > That having been said, I think this is a great suggestion. Are you > willing to do this work, or are you expecting someone else to do it? > > -- Darin > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit memory management?
On Jun 4, 2008, at 11:38 AM, Paul Pedriana wrote: > I can understand that some developers who have spent a lot of time > developing monolithic desktop or server software are used to using > the built-in global operator new. The concept of controlling memory > like I am proposing is the rule in commercial library development > and not the exception. I humbly ask that the WebKit team consider > migrating towards this type of development. It will make WebKit > considerably stronger outside the desktop market, and yet is rather > easy to apply. It's largely a matter of accepting an idea that is a > little different from what some have done in the past. Your tone here stinks. Many others working on WebKit are professionals, probably with more commercial library experience than you, and many of the WebKit contributors work on software for constrained mobile devices. That having been said, I think this is a great suggestion. Are you willing to do this work, or are you expecting someone else to do it? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit memory management?
>> Did you try it, or is that just something you know without testing? >> I understand the principle, but I haven't seen the problem in practice on any platform. It happens on all platforms. I posted an example which can be seen in the 'scrubbed html' at https://lists.webkit.org/pipermail/webkit-dev/2008-June/004073.html. >> If the problem is a real practical issue, do you have a suggested fix? >> Would you be willing to make a patch to show what it would look like? I provide a description of the primary typical solution that is used at: https://lists.webkit.org/pipermail/webkit-dev/2008-June/004071.html. Basically you don't directly invoke global operator new but instead use either a redirecting macro or use a custom version of new which takes an argument which identifies the heap you are targeting (possibly even single one for all of WebKit). I can understand that some developers who have spent a lot of time developing monolithic desktop or server software are used to using the built-in global operator new. The concept of controlling memory like I am proposing is the rule in commercial library development and not the exception. I humbly ask that the WebKit team consider migrating towards this type of development. It will make WebKit considerably stronger outside the desktop market, and yet is rather easy to apply. It's largely a matter of accepting an idea that is a little different from what some have done in the past. Thanks. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit memory management?
Based on my (limited) understanding: * Inside the same linked executable (an EXE, DLL, etc..), you can only have a single implementation of something, such as operator new, operator delete, etc.. * Inside different linked executables that are dynamically linked (or statically linked using shared libraries), you can have one implementation per shared library For instance: MyCoolGame.exe can use its own custom implementation of operator new/operater delete WebKit.dll can use another custom implementation that is different from MyCoolGame.exe UberGraphicsLibrary.dll can use yet another custom implementation that is different from both WebKit.dll and MyCoolGame.exe However, WebCore.lib and JavaScriptCore.lib, which are linked into WebKit.dll, have to use the same implementation, since even though they are different static libraries, they are linked into a single linkable executable. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darin Adler Sent: Wednesday, June 04, 2008 2:01 PM To: Paul Pedriana Cc: WebKit-Dev Subject: Re: [webkit-dev] WebKit memory management? On Jun 4, 2008, at 10:57 AM, Paul Pedriana wrote: > As I mentioned in a previous response, this unfortunately doesn't > work because all operator new is directed to FastMalloc, not just > WebKit's usage of operator new. Operator new is global in a linkage > unit. Did you try it, or is that just something you know without testing? I understand the principle, but I haven't seen the problem in practice on any platform. If the problem is a real practical issue, do you have a suggested fix? Would you be willing to make a patch to show what it would look like? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit memory management?
On Jun 4, 2008, at 10:57 AM, Paul Pedriana wrote: > As I mentioned in a previous response, this unfortunately doesn't > work because all operator new is directed to FastMalloc, not just > WebKit's usage of operator new. Operator new is global in a linkage > unit. Did you try it, or is that just something you know without testing? I understand the principle, but I haven't seen the problem in practice on any platform. If the problem is a real practical issue, do you have a suggested fix? Would you be willing to make a patch to show what it would look like? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit memory management?
As I mentioned in a previous response, this unfortunately doesn't work because all operator new is directed to FastMalloc, not just WebKit's usage of operator new. Operator new is global in a linkage unit. Thanks. Paul > On Jun 3, 2008, at 7:58 PM, Paul Pedriana wrote: >> The application should be able to set aside a block of RAM and have >> the library use that block of RAM via a user-supplied memory >> allocator. At no time should the library attempt to use any other >> memory nor use its own means to access the user-provided memory. This >> pattern of library development is very important, and most >> professional commercial library software follows this pattern >> (including all commercial peers of WebKit). I am wondering how I >> might achieve this with WebKit. > Here's how: > > 1) Change the source file to invoke this > memory allocator instead of TCMalloc. > 2) Let us know about any concrete problems you encounter where > that allocator isn't used, and we'll help you fix them and investigate > putting those fixes in the WebKit trunk too. > > Good luck! > > -- Darin > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Some queries regarding WebKit 2.x
On Jun 4, 2008, at 3:29 AM, Sinha Tuheen-A19034 wrote: > Hi All, > I had some queries regarding WebKit 2.x. I would really > appreciate if someone can help me. > > 1. Do we have some stable version of WebKit 2.x available? I have > seen several nightly builds, but not sure if we have a place where > we release stable versions too. > > 2. Is WebKit 2.x compliant with any W3C standards for HTML, CSS, > DOM, JavaScript and CSS? > What is "WebKit 2.x" that you are referring to? Historically the WebKit project has not used version number, nor done releases of WebKit beyond the nightly development builds. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] construct the dom tree of non Xml valid page
On Wed, 6/4/08, nina <[EMAIL PROTECTED]> wrote: > I want to construct the dom tree of an html page. > This page must be Xml valid for construct his dom tree? No, it doesn't have to be valid. Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit memory management?
On Jun 3, 2008, at 7:58 PM, Paul Pedriana wrote: > The application should be able to set aside a block of RAM and have > the library use that block of RAM via a user-supplied memory > allocator. At no time should the library attempt to use any other > memory nor use its own means to access the user-provided memory. > This pattern of library development is very important, and most > professional commercial library software follows this pattern > (including all commercial peers of WebKit). I am wondering how I > might achieve this with WebKit. Here's how: 1) Change the source file to invoke this memory allocator instead of TCMalloc. 2) Let us know about any concrete problems you encounter where that allocator isn't used, and we'll help you fix them and investigate putting those fixes in the WebKit trunk too. Good luck! -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] construct the dom tree of non Xml valid page
Hello, I want to construct the dom tree of an html page. This page must be Xml valid for construct his dom tree? Thanks Cheers ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Some queries regarding WebKit 2.x
Hi All, I had some queries regarding WebKit 2.x. I would really appreciate if someone can help me. 1. Do we have some stable version of WebKit 2.x available? I have seen several nightly builds, but not sure if we have a place where we release stable versions too. 2. Is WebKit 2.x compliant with any W3C standards for HTML, CSS, DOM, JavaScript and CSS? Thanks and Regards, Tuheen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit memory management?
However, I am not aware of any platforms where an
overridden operator new would have effect across a DLL boundary ...
A DLL on Windows is treated rather like an EXE for the purposes of
linkage. However, DLLs are a Windows-specific feature which don't exist
on other platforms, though some desktop platforms have similar 'shared
library' concepts. Some gaming and embedded platforms have the concept
of shared libraries, though they often don't treat them as
independently linkable units like Windows DLLs but instead think of
them more like a code overlay within the current process and thus share
symbols.
As I understand the LGPL (an abbreviated description:
http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License),
statically linking is fine. What matters is that derivative software be
available in linkable library form, and that explicitly includes
statically linked software. This makes sense because many platforms
other than Unix and Windows platforms don't have the concept of dynamic
linking, and it wouldn't make sense for LGPL to apply to some platforms
and not others. The key point of LGPL relative to GPL is to recognize
the concept of libraries as opposed to applications.
So far, we've been quite happy using platform tools for
memory
debugging. Personally, I do not think that explicitly tagging memory in
this way would be cost-effective, although this is certainly not out of
the question.
I understand. It's just one approach, and a good set of stack/module
trawling tools can help achieve much the same thing. My main point is
of course to be able to control where memory comes from, and this
merely provides an easy means of achieving some explicit metrics
functionality. It's been useful in the gaming industry as a complement
to the other usual tools.
Thanks.
Paul
On Jun 4, 2008, at 9:58 AM, Paul Pedriana wrote:
Thanks for the response. I'm sorry, and
perhaps I misunderstand, but I believe your statement about inline
operator new is incorrect. Unless I misunderstand you, what you say is
not supported by any existing compiler nor is it supported by the C++
language standard. In summary, the 'inline' keyword does not negate or
obviate the One Definition Rule. You can demonstrate the problem with
the code below. Feel free to correct any misunderstanding that I may
have of your explanation.
You are right that the presence of a declaration or inlining do not
affect the behavior of overridden global operator new, other than via
possible implementation-specific quirks (because compilers are not
required to detect ODF violations).
However, I am not aware of any platforms where an overridden operator
new would have effect across a DLL boundary (note that the C++ standard
doesn't talk about dynamic linking at all). So, this is only an issue
if you link WebCore to your application statically, or specifically
export operator new from your DLL. There is no need to do the latter,
and the former sounds like a violation of LGPL to me. If your platform
does not support dynamic linking, or you cannot use it for some other
reason, you may want to investigate the legal feasibility of using
LGPL-licensed code in your projects before pursuing technical
solutions.
Thus you could use WC_NEW("WebCore/page") to
flag the memory
as belonging to that subsystem. This is invaluable in identifying
memory, producing subsystem metrics, optimizing memory coherence, and
deducing memory leaks (though other means also help find leaks).
So far, we've been quite happy using platform tools for memory
debugging. Personally, I do not think that explicitly tagging memory in
this way would be cost-effective, although this is certainly not out of
the question.
- WBR, Alexey Proskuryakov
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit memory management?
On Jun 4, 2008, at 9:58 AM, Paul Pedriana wrote:
> Thanks for the response. I'm sorry, and perhaps I misunderstand, but
> I believe your statement about inline operator new is incorrect.
> Unless I misunderstand you, what you say is not supported by any
> existing compiler nor is it supported by the C++ language standard.
> In summary, the 'inline' keyword does not negate or obviate the One
> Definition Rule. You can demonstrate the problem with the code
> below. Feel free to correct any misunderstanding that I may have of
> your explanation.
You are right that the presence of a declaration or inlining do not
affect the behavior of overridden global operator new, other than via
possible implementation-specific quirks (because compilers are not
required to detect ODF violations).
However, I am not aware of any platforms where an overridden operator
new would have effect across a DLL boundary (note that the C++
standard doesn't talk about dynamic linking at all). So, this is only
an issue if you link WebCore to your application statically, or
specifically export operator new from your DLL. There is no need to do
the latter, and the former sounds like a violation of LGPL to me. If
your platform does not support dynamic linking, or you cannot use it
for some other reason, you may want to investigate the legal
feasibility of using LGPL-licensed code in your projects before
pursuing technical solutions.
> Thus you could use WC_NEW("WebCore/page") to flag the memory
> as belonging to that subsystem. This is invaluable in identifying
> memory, producing subsystem metrics, optimizing memory coherence, and
> deducing memory leaks (though other means also help find leaks).
So far, we've been quite happy using platform tools for memory
debugging. Personally, I do not think that explicitly tagging memory
in this way would be cost-effective, although this is certainly not
out of the question.
- WBR, Alexey Proskuryakov
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
